「 サーバー構築 」一覧

gitをhttp経由で使いたい その2


先日の追記情報だけではまだ不十分でした。
確かにclone, commit, push まで成功するのですが、それは最初にcloneしたリポジトリでの操作に限定したものでした。他のcloneした場所で編集して push しようとして失敗したり、そもそもcloneで失敗(空っぽリポジトリ)といった現象が見られました。

再度確認してみると足りなかったのは以下の2点

  • hooks/post-update.sampleを post-update として配置
  • サーバー側のリポジトリのアクセス権が全てapache(wwwのユーザー)になっていること

これらをまず確認してみることが必要かと思います。

意外に、git update-server-info を実行するとファイルが作成されて、それが実行したユーザーになっていたりするので、apacheユーザーが所有者ではないファイルができてしまっていたりします。
また、pushのたびに update-server-info の実行が必要なようで、それをやってくれるのが post-updateのスクリプト内となっています。

他に、リバースプロキシ背後で動かそうとするとまたパスの問題が出てきそうなので、それはまたいずれ調査と言うことで。


gitをhttp経由で使いたい(ついでにgitweb)


以前にGitLabのインストールや使い方を書いてみたのですが、どうやらあれはsshをつかえる環境でないといけないようで、簡単にhttp(やhttps)を経由してのclone, pushなどはできないようでした。おまけに各ユーザーのプライベートリポジトリを作ることが前提で、非登録のユーザーが閲覧することもできないようです。(言い分としてはその場合はGitHubでいいでしょ、ということだそうで)。

さて、なぜHttp経由かという理由ですが、httpプロトコルしか通過できないファイアウォールがあるところも多いです。特に開発の現場ではまだまだ多く存在するようです。こういった場合にはgitを使う場合にclone,pushらをhttpによって行う必要が出てきます。
Subversionでもsvnプロトコルではなくhttp経由のWebDAVを用いて使っている例も多いのはその理由によるところもあるのかなと思ったりしています。

前提条件

次のものはインストール済みで設定も終わっているものとします。

  • Apache(WebDAV有効状態で)
  • git

設定

リポジトリらを /var/www/html/repos-git に配置するとして、ディレクトリを用意しておきます。
これから説明するディレクトリらの所有者はapacheとしておきます。

Apacheの設定ファイル(httpd.conf)を開いて、リポジトリらをWebDAVでアクセスできるように修正します。

※上記で指定するWebDAVを有効にするディレクトリを指定する際には、gitリポジトリそのものである必要があります。
SVNのよう な親ディレクトリを指定すればOKな感じでは無く、各リポジトリそれぞれでDAV ONとしなくてはならないようです。この点にはまりました(5/29追記)

apacheを再起動した上で、テストのためにリポジトリを用意してみます。

動作チェック

次のコマンドを実行していき、リモートリポジトリを用意します。

入力するアドレスは、 http://(サーバーのIP)/repos-git/test です。
うまくいけば、Success を表示されて、リポジトリが取得できます。

gitを試していると、リポジトリが取得できても、push ができないことが割と発生しますので、ここでpushも正常にできるかを確認しておきます。
適当なファイルを追加して、編集した後で、commit, push してリモートリポジトリにpushが成功するかを確認してみてください。

Gitwebのインストール

せっかくなのでGitwebも入れてみました。

このコマンドで簡単にインストールが完了します。
あとは設定ファイル /etc/gitweb.conf を編集するだけです。

$projectroot という変数にGitリポジトリの場所を設定するようになっているので、次のように書き換えます。

そして、apacheを再起動して、http://(サーバーのIP)/git/ にアクセスしてみます。
問題なければ、testリポジトリが一覧に並んでいることでしょう。

まとめ

とりあえずユーザー認証はなしでまずはサーバーにgitを用意してhttpによるアクセスをさせるというところを目的として、環境設定を行ってみました。今のところやっぱりWebDAVによってhttp経由のアクセスをさせるというところに落ち着いてしまいました。 ただWebDAVを使っていると遅いという話もあるようなので、別の方法でhttp経由のgitリポジトリ取得の方法がないかを、もうしばらく探してみたいと思います。


HTTPからのIRC


IRCクライアントをインストールできない環境や、そもそもHTTP通信しかできない状況で、
IRCを使ってやりとりをしたいということがあります。そんなときに、http2irc的なものが欲しくなります。

以前、http2ircみたいなプログラムが手元にあったのですが、紛失してしまって誰か作っていないかなと思って調べてみるとありました。数は少なそうですが、ありました。

  • WebIRC
  • CGIIRC

今回、CGIIRCを試してみたので導入までの流れをメモとして残しておきます。

CGIIRCのセットアップ

本家、http://cgiirc.org/ からCGIをダウンロードしてきます。
そして、 httpとしてアクセスできる場所に配置します。
ここで配置した場所でCGIを許可する設定となるように httpd.conf を編集しておきます。

cgiirc-0.5.10.tar.gz を展開すると、cgiirc.config という設定ファイルがあります。
このファイルに設定を書き込んで、セットアップは完了します。非常に簡単です。

cgiirc.configの編集

下記の項目くらいを編集するくらいで十分でしょう。

  • default_server 接続する標準のサーバー
  • default_channel 接続する先のチャンネル名
  • image_path imageが配置されているパス。ブラウザーから見えるアドレスで記述すること.
  • irc charset = iso-2022-jp という行を追記する。日本語環境で使う際に必要です。
  • interface timestamp = 1 時刻の表示を有効にします。

GitLabのインストール


前回の予告通りGitLabのインストール手順を説明します。

準備

CentOS 6(x64)を
Minimum Server構成でインストールしたものを使用します。

まずこの環境下で以下の設定を行っておきます。

  • 外Webを見れるように環境を設定(ifcfg-eth0の編集)
  • SELinuxの無効化(/etc/sysconfig/selinuxの編集)
  • ファイアウォールの無効化(iptables -Fでクリアして設定保存)

依存関係インストール

GitLabが依存するプログラム群を下記のコマンドでインストールします。

pygmentsのインストール

redisのインストール

サーバーをここで起動させておきます。

ユーザーの追加

ここでいろいろと聞かれるのですが、パスフレーズも含め空Enter連打で設定します。
特に、パスフレーズは設定してはいけません。

gitユーザーとしてログインを試みます。
新規ホストなので、接続に関して問われますが yes と入力します。
gitユーザーにはパスワードを設定していないため、ログインは完了しません。
Permission deniedとなっても以下の処理を続けます。
ちなみに、gitユーザーにパスワード等設定してあってログインできた場合でも特に問題はありません。

ログインしたユーザー(gitlabhqやgitユーザー)を一度抜けて、再びrootで作業します。

gitoliteのインストール

gitoliteはgitlabhqから使用され、gitリポジトリを管理します。

実行すると設定ファイルが開くので下記のように変更を行います。

設定ファイルのセーブして終了は、”:wq” をタイプしてenter
rootユーザーに戻って作業を続けます。

gitlabhq のインストール

Ruby 1.9.2と、passengerをインストールします。

この最後のほうに出てくる Apache2への設定行(LoadModuleの周辺)をメモしておきます。あとで、httpd.confを編集する際に必要となります。

起動していなければ、mysqlサーバーを起動させます。

この時点で後で必要になる管理者ユーザーの情報が出力されるのでメモしておきます。

ホスト名の部分(git_hostセクションの host部)にIPかドメイン名を記述します。

rootユーザーに戻ってApacheの作業を行います。

末尾に以下のように記述を追加します。

LoadModule行がたくさん並んでいるところで、先ほどメモしておいたpassenger関連の記述を追加します。

Apacheを起動します。

ブラウザで “http://(IPアドレス)/gitlabhq/” に アクセスしてみます。

右図のように画面が出てきたら成功しています。ここでのログインのアカウントは先ほど、rake db:seed_fu を実行したときのアカウント情報でログインすることができます。

ログインがうまくできると次に示すような画面が表示されます。

自分が最初よくわからなかったので、ちょっとだけ書き込みを入れてみました。

あまり目立たなさそうですが、管理者メニューのアイコンが出ています。ここから新規のユーザーを追加することができます。また単なる画像に見える右上の部分では、プロフィールの編集ができるようになっています。後日説明しますが、ユーザーがsshキーを登録する際にはここからたどることになります。

ここまででひとまずGitLabの設置は完了です。
次回には、tortoiseGitを使って、このGitLabにリポジトリの登録をゴールにして、環境設定を記事にしたいと思います。


GitLabを試してみた


GitHubクローンである、GitLabを導入して Git+GitHubの操作感を体験してみたいと思います。
詳しい導入方法は次回以降に書くとして、試してみたときの感想を先に書いておきます。

環境

  • CentOS 6(x64) (ただしVM上)
  • GitLab 2.3
  • クライアントは tortoiseGit + msysgit (1.7.10)

感想

GitLabへの登録がsshキーを要求する点でいろいろと大変でした。この部分がSVNと比較してわかりにくい気がする。最初の手順なので、通常運用が始まってしまえばそこまで問題にはならないのだろうけど。

GitHub, GitLabの問題なのだろうけど、ソースコードをWebから確認したい際に、Shift-JISで書かれたソースコードで、日本語コメントが文字化けしてしまう。UTF-8のソースコードであればこれは大丈夫。既存SJISソースでGitへの移行を検討するなど、UTF-8のソースコードが使えない場合はちょっとGitLab使う利点が減る気がする。

それでもGitリポジトリの管理を集約でき、Web上からユーザーの追加やキーの登録ができるという点は魅力。複数ユーザーがいるときには管理者はちょっと楽ができる。SVNのときには、最初のリポジトリはサーバーのコンソールで操作する必要があったし…。

Redmineのリポジトリブラウザのように、優先するエンコーディングを設定する機能がGitLabのプロジェクトごとに設定できるようにならないか、期待していきたいと思います。


WindowsStorageServer2008 その2


iSCSIターゲットのインストール(環境設定)

en_windows_storage_server_2008_iscsi_cd_x64_x86_x15-49563.iso
をマウントして、iSCSI Target用のソフトウェアをインストールします。
x64フォルダ内に、iSCSI Target用インストーラーがあるのでそれを実行します。
なお、x86フォルダ内には、クライアントのソフトウェアしか存在しません。

en_windows_storage_server_2008_iscsi_tools_cd_x64_x86_x15-63368.iso
ではない点に注意。ツールという点で少しだけだまされました。

インストール後、管理ツールから Microsoft iSCSI Software Targetという項目が増えているので、ここからツールを起動します。
右クリックして、iSCSIターゲットの作成を選び、名称およびIQNの値を入力して、ターゲットを作成します。
その後、iSCSIターゲット用の仮想ディスクの作成を行います。

iSCSIターゲットの動作確認&イニシエータの設定

動作確認のために、iSCSIイニシエータがインストールされている環境で作業します。
イニシエータのプロパティで設定する項目は以下の内容です。

  • 構成タブ
    • イニシエータ名。ターゲットで設定したイニシエータを識別するためのiqn名と同じになるように設定します。
  • 探索タブ
    • ポータルの探索ボタンを押して、先ほどまで設定していた環境のIPアドレスを入力します。
  • ターゲットタブ
    • 最新の情報に更新ボタンを押します。
    • 上記の設定ができていれば、ここで検出されたターゲットの中に今まで設定していたiSCSIターゲットがみえるはずです。
    • その検出されたターゲットを選択して、接続を行えばクライアントから使用可能になります。

これらの設定はWindows7のクライアント環境で行いました。
また、動作確認のため、WindowsStorageServer上のファイアウォールは無効化して行いました。

接続状態になると、

  • クライアント(イニシエータ側)は、そのターゲットに対して接続完了ステータスになります。
  • ターゲット側は、ステータス使用中になります。

またこの時点では、単にドライブを接続しただけの状態なので、
クライアントからディスクのフォーマット等を行って通常の使用可能状態となります。
コンピューターの管理→ディスクの管理で、物理ドライブが1つ増えていることが確認できます。

ファイアウォールの設定

先ほど接続状態にしたターゲットを切断しておきます。
ここでStorageServer側のWindowsファイアウォールを有効化します。
そして”セキュリティが強化されたWindowsファイアウォール”という画面で設定を行っておきます。

受信の規則を右クリックして新規の規則を選択

  • ポート
    • TCP
    • 3260ポート

を許可するように設定します。

先ほどと同じように、ターゲットタブ/最新の情報に更新 ボタンをおして、
ターゲットが表示され、さらにそれに対して接続が出来ることを確認します。
接続が出来ないようであれば、ファイアウォールの設定箇所が間違っていると考えられます。
(どのプロファイルに対して設定するとか、そのあたりに引っかかるかもしれません)

まとめ

これでiSCSIの使用準備が整いました。
今回 Target 3.2の設定でしたが、 3.3が既に出ているようです。
これについては、よく分からなかったため当面 3.2 で実験かと思っています。

iSCSIの環境も整ったので、次回は目的の内容について実験して行きたいと思います。


WindowsStorageServer2008 その1


WindowsStorageServerでiSCSIターゲットをやってみようと思い、
色々とインストール作業中です。
認証とか通せないから、猶予期間があるうちにやりたいことをがんばります。

インストール

ディスク自体は英語版しかないので、それをインストールします。
その後、LanguagePackを用いて日本語化します。
このときに、LanguagePackをどう適用させるのかで悩みました。

コントロールパネル/Regional and Language Optiopns/Keyboards and Languages
とたどって、Display language グループ内のInstall/Uninstall languagesボタンを押します。
その後、Language Packディスクのja-jpフォルダを選択させれば、
後はそのままインストールできます。

参考にしたのは、こちら → http://jehupc.exblog.jp/13223828/

そういえば、WSS2008は、パスワードが設定されているんでした。
chm内部にかかれているので、見ておくのも忘れないようにしないと。

WSS2008_OEMGUIDE.CHM ヘルプファイルの “Preinstallation Preview” を押下すると掲載されてるようです。

ここで日本語化は完了です。

今日は力尽きたので、iSCSIターゲット用の設定らは次回に。


ドメインサーバーを2003からWin2008R2へ


2003R2で構築しているドメインに、2008R2のサーバーをメンバーサーバーとして追加して、その後昇格させる方向でドメインサーバーのアップグレードを図ってみた。

メンバーサーバとして追加

まず、サーバー構成マネージャでドメインサーバー用の設定をした後で、
dcpromoを実行したところ、以下の失敗メッセージが出てきました。
「このActive Directory フォレストにドメインコントローラーをインストールするには、最初に”adprep /forestprep”を使用してフォレストの準備をする必要があります。」

よって、Win2008R2のディスク内 support/adprep にあるツールを実行します。

対象の2003R2のサーバーで2008R2のディスクを挿入して、

その後、”C”キーを押してからEnterキーを押す。
すると準備が開始されます。
ここで”C”を押さずにEnterを直接押してしまって、あれ?って状態になりました。
メッセージはきちんと読みましょう。

このまま、再度dcproom.exeの実行するとまた別のメッセージが出てきます。
「このActive Directory フォレストにドメインコントローラーをインストールするには、最初に”adprep /domainprep”を使用してドメインの準備をする必要があります。」

よって、同じように対象のWin2003R2サーバーで先ほどのツールを実行してみました。
しかし、今度はツールが正常完了せず、以下のエラーメッセージが出てきました。

「Adprep は、ドメインがネイティブ モードではないことを検出しました。」
どうやら、以前環境構築したのが旧バージョンでも問題ないモード(混在モード)で動いていたらしく、
Windows2000ネイティブ以上の機能で構成しないとダメのようです。

  • “Active Directoryユーザーとコンピュータ”で、機能レベルを更新
    • ドメイン部で右クリック「ドメインの機能レベルを上げる」を選択
    • 現在”Windows2000混在モード”→”Windows Server 2003″
  • コマンドラインで adprep /domainprep /gpprep を実行する
  • adprep /rodcprep を実行する。
    • これを忘れると、あとで警告が出てくる。

ここまで処理して続いて 2008R2側でメンバーサーバー追加の再チャレンジ。
警告および確認が出てくるので、問題なければ続行。

これらの処理が完了すると、2008R2でのドメインサーバーがメンバとして登録されます。

新しくドメインコントローラーとするために

メンバーサーバーとしての登録が終わったので、ドメインコントローラーへ昇格させます。

操作マスタの役割を転送します。

  • ActiveDirectoryユーザーとコンピュータ
    • 右クリックで操作マスタを開く
      • 各マスタを旧サーバーから新サーバーへ転送する。
      • (RID, PDC, インフラストラクチャ)

旧ドメインサーバーのグローバルカタログを無効にします。

  • ActiveDirectoryサイトとサービス
    • Sites
      • (ドメインコントローラのあるサイト)
        • Servers
          • (ドメインコントローラー)
            • NTDS Settings

とたどっていき、NTDS Settingの部分で右クリックしてプロパティを開きます。
そのなかで、グローバルカタログという項目にチェックボックスがあるので、
このチェックを外すことでグローバルカタログを無効化できます。

その後、旧サーバーでdcpromoを実行して、降格処理を行います。
ActiveDirectoryの削除が実行され、単なるメンバーに降格します。

参考

MSのサイト以外のところで参考にした部分。
http://pnpk.net/cms/archives/373
http://norimaki2000.blog48.fc2.com/blog-entry-507.html
http://blog.tsukuba-bunko.jp/ppoi/archives/2008/04/3.html

この部分を参考にさせていただきました。
ありがとうございました。


続・RemoteApp試してみた


以前に電卓くらいでRemoteAppを試してみましたが、
今回はOffice 2007 Enterpriseで試してみました。

  1. WindowsServer2008R2の環境へOfficeをインストール
  2. RemoteAppで使いたいアプリケーション(WordとかExcelとか)を登録
  3. 登録したアプリのrdpファイルを作成し、使う側へ持ってくる

今回実験なので、シリアルキー入力もしていなければ、ライセンス認証もしていません。
もしかしたら、ライセンス認証したあとでの挙動は変わってしまうかもしれません。

2008R2側でOfficeをインストールした後、RemoteAppに登録したOfficeアプリケーションは1度は実行しておく必要がありそうです。
シリアルキーや認証のダイアログが出てくるための挙動と言えそうですが。
これさえやっておけば、クライアントから接続して使うことが出来ました。


リバースプロキシ背後でRedmine


2010/4/16現在の環境で、
リバースプロキシ背後でRedmineを動かそうとして、
ちょっとばかり苦戦したのでそのメモです。

redmine動作サーバー(バックエンド)

サーバーを設定して準備できているものとします。
仮にここでは 192.168.1.1 というマシンAで動いていると仮定します。
また、redmineのページへアクセスするのに、
http://192.168.1.1/ というようにDocumentRoot設定が成されているとします。

リバースプロキシ側(フロントエンド)

リバースプロキシは、192.168.1.254で動いてるとします。
ここにアクセスして、特定のURL時にredmineのサーバーへ転送するようにするのが目的です。

設定について

本来素直にやるならば、リバースプロキシ側の httpd.confにて下記のように書けば終了です。

しかしこれではうまくいきません。
スタイルシートが読み込まれないし、画面上のリンクを押しても対象のページへジャンプ出来ません。

そこで、redmine側の設定を変更します。
設置してある場所で config/routes.rb を開きます。
そして2行目に、次の1文を入力します。

旧バージョンでは、ActionController::AbstractRequest.relative_url_root という設定項目だったとのこと。
これがどうやら現在のRailsで変更になっているようで、この修正に到達できるまでが大変でした。

この変更を適用することで、http://youraddress/redmine/ というアクセスを正しく処理できるようになります。