WiMAX

これまで外出中にネットワークに接続する手段として e-mobile を使用していました。ですが、この度 UQ WiMAX に乗り換えることにしました。因みに乗り換えの理由は通信速度です。

WiMAX は前々から気になっていたのですが、エリアカバー率にはあまり期待していなかったのと e-mobile の二年縛りもあって e-mobile を使い続けていました。しかし 4月頃 に Try WiMAX なるお試しサービスがあることを知り、とりあえず試してみるかということで try wimax に申し込んでみて、僕の良く行く場所で実用的に使えるのかどうか検査してみました。

WEB から Try WiMAX を申し込むと、申込日を含めて三日程で端末が手元に届きました。Try WiMAX では試用するにあたって端末を選択することができます。僕はホストマシンを Ubuntu にしてしまっているので OS を制約される端末は使用できないということで、ルータタイプの端末を選択しました。(ただ現在は試用機からは失くなっているようです) ルータタイプの端末があるというのはかなりポイント高い(逆になかったとすると、WiMAX は選択肢に入らないということなんですけどね)。

実機がきてから端末のセットアップをしますが、このセットアップには別マシンの Windows 機を使用しました。セットアップツールは大概 Windows にフォーカスされているものなので、ここは努めて従うのが吉ですね。電波が入る場所であればセットアップは難なく完了です(自宅では窓際でようやく電波が入るというところでした)。

で、僕の活動域各地に出向いて電波を確認してみたところ、電波状況はかなり良好で最大 5Mbps くらいの速度が出ています。遅くても 1Mbps は出ているので、今使っている e-mobile と比べればこれでも十分です。自宅は窓際に端末を置かないと電波が入らないですが、自宅では自宅の光回線を使うのでこれは問題なし。もし自宅で光などのネット環境を整備していない方で WiMAX の電波が届く場所に住んでいる方にとっては WiMAX だけで十分実用に耐える気がします。契約が住所に縛られる訳でもないので、取り回しの良さで言えば光回線等の上を行きますね。と個人的には思っています。

ということで Try WiMAX にて WiMAX は問題なく使えることを確認し、e-mobile を使用していたときに比べて速度も速いし、端末は無線LANルータとして使えるので iPhone 等も同時に同じネットワークで同じ速度で使えるし、無線LAN なので USB ポートは一つ空くしということで僕にとっては WiMAX は素晴らしい魅力的なネットワーク環境ということが分かりました。

いやほんとに素晴らしいですね。

Try WiMAX を終えてからしばらく経ってしまいましたが、先週末にようやく新宿のヨドバシで NEC AtermWM3300R PA-WM3300R(AT) の端末をかなりの安さで購入して現在実運用中です。今はキャンペーンをやっているらしく、来月から一年間は 月額 3,780円 で済むそうなので価格面でも 月単位で e-mobile より 1,000円 以上も安くなる計算です。とりあえずのところ僕にとってはかなりいいことづくめですね。NEC AtermWM3300R PA-WM3300R(AT) は持ち運べる無線LANルータなので、外でも自宅とほぼ同じような環境を確保したことになります。

蛇足ですが e-mobile を使い続ける場合は Pocket WiFi が同じ欲求を満たしてくれそうですね。それでも WiMAX にするのは、若干月額の料金が安いのと、二年縛りなどの契約の分かりにくさが WiMAX にはないということですかね。e-mobile は今月で二年縛りが解けるのでささっと解約してしまおうと思っています。さて今使ってる e-mobile の端末はどうしようかな…

では Bye Bye e-mobile. Hello WiMAX!!! ということで。

しかし subversion はリビジョンの管理レベルがディレクトリ単位であったり(.svn はディレクトリ毎に作られる)マージする際のマージ対象を自分で把握しなければならない等、不便なことも多いなと感じるようになりました。

そこで僕も色々とリビジョン管理ツールを試してきましたが、git を経由して、今のところは bzr に落ち着いています。最近は雑誌等にも多くとりあげられる git の普及率の方が高いのでしょうが、subversion を無視できないという理由とファイル名のエンコーディングの扱いの関係で bzr を選択しています。最近の git 動向には詳しくないので既に改善されている面もあるかもしれませんが…

bzr はチェックアウトとブランチを明示的に使い分けられるところも良いです。この辺の使い分けについてはそのうちエントリを書くかもしれません。

では本題。 ubuntu に apt で bzr (と bzr-svn)をパッケージインストールする方法です。bzr のサイト に行けばすぐ分かるのですが、自分用のメモとしてここに残します。

まず、apt が警告を出さないように ppa の鍵を apt に登録しておきます。

% sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-key 0xece2800bacf028b31ee3657cd702bf6b8c6c1efd

鍵を登録したら /etc/apt/sources.list を編集して下記のエントリを追加します。僕はちょっと古めの ubuntu(hardy) を使っているので下記のようにしていますが、https://launchpad.net/~bzr/+archive/ppa のサイトに行けばそれぞれのバージョン用のエントリを調べられますので、自分にあったものを登録して下さい。

% sudo vim /etc/apt/sources.list
deb http://ppa.launchpad.net/bzr/ppa/ubuntu hardy main
deb-src http://ppa.launchpad.net/bzr/ppa/ubuntu hardy main

そうしたら、あとは下記のコマンドを叩いて bzr と bzr-svn をインストールするだけです。

% sudo aptitude install bzr
% sudo aptitude install bzr-svn

bzr 1.16 を利用している時までは、ubuntu パッケージだと bzr-svn が動かなかったりしたので bzr は apt で、bzr-svn プラグインは個別にダウンロードしてバージョンを管理していました。が、 2.0.x系になってからどうやら上手く動くことが確認できたので bzr-svn プラグインも apt で管理するようにしました。その方が管理が楽ですし統一できますからね。

別に bzr をすすめようという気はありませんが、bzr は中々良いツールです。

Linode を契約したのは大分前(2009-07頃)ですが、忙しさが続いて中々移行することができませんでした。ようやく bzr のリポジトリも含めて移行が完了しそうです。

Bazaar

Windows で Bazaar を使うときのメモです。リポジトリは ssh 経由でアクセスできる状態であることを想定しています。

僕がセットアップした環境は以下の通りです。

• Windows2000
• Bazaar 1.15final

まず Windows に Bazaar をインストールするため http://bazaar-vcs.org/Download から windows 用の bzr バイナリをダウンロードします。ダウンロードした exe ファイルをダブルクリックで起動すればインストールウィザードが起動するので、ウィザードの指示に従ってインストールを完了させます。このインストールバイナリには TortoiseBzr も収録されているため、別途 TortoiseBzr をインストールする必要はありません。インストールが完了すると、既にエクスプローラの右クリック項目に Bazaar リポジトリ操作用の項目が追加されているはずです。

さて、Bazaar のインストールは完了したので Bazaar の基本的な操作は使用できる状態になりました。

しかし Windows の場合、リポジトリの中にシンボリックリンクが使われていると、Bazaar をインストールしただけではリポジトリの clone に失敗してしまいます(clone 自体は成功するようですが、ローカルディレクトリにディレクトリツリーを展開するところで例外が発生している模様、Windows にはシンボリックリンクなんてものはないから)。そこで、Windows 環境でもシンボリックリンクを扱えるようにするプラグインをインストールします(但し、以下でインストールするプラグインは例外を発生しないようにするためのプラグインであって、Windows でシンボリックリンクが利用できるようにするといったものではないので注意)。

http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#how-to-install-a-plugin を参考に https://launchpad.net/bzr-win32symlinks をインストールことにします。

プラグインの配置場所は上記のページに書いてあるのですが、ここに引用します。

http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#how-to-install-a-plugin
On a Windows installation, the system location might be C:\\Program Files\\Bazaar\\plugins while the personal location might be C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\plugins.

C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\ に plugins というディレクトリが存在しなければディレクトリを作っておきます。次にこの plugins ディレクトリ下にインストールするプラグインを配置します。既に Bazaar を使用できる環境になっているはずなのでコマンドプロンプトで plugins ディレクトリに cd し、以下のコマンドをタイプします。もしくはエクスプローラ上からリポジトリをクローンしても構いません。

> bzr branch lp:bzr-win32symlinks
> move bzr-win32symlinks win32symlinks

ここでは、プラグインプロジェクトのリポジトリのクローンを作成してディレクトリ名を変更しています。ディレクトリ名の変更を行なわないと、プラグインは動作しないので注意して下さい。

これでシンボリックリンクを使用しているリポジトリがあっても、途中で例外を発生することなく branch(clone), checkout することができるようになります。

続いて SSH プロトコルを使用して Bazaar リポジトリにアクセスする環境をセットアップすることにします。

ここではサーバ側には既に ssh の公開鍵暗号方式で Bazaar リポジトリにアクセスできる環境が整っていることを前提とします。以下の作業では Bazaar クライアントのセットアップのみ行います。

実は、現時点で Windows の Bazaar GUIフロントエンドの TortoiseBzr(0.2rc1) はリポジトリを push することができないようです。そこで、最低限コマンドプロンプト上から push できる環境を確保するために Cygwin 上の OpenSSH と PuTTY 付属の Pageant の二つの環境をセットアップすることにします。

まずは Cygwin + OpenSSH の環境を整えます。セットアップ自体は以下の URL を参考にします。
http://openbooth.org/archives/118.html

上記 URL の説明で SSH 接続環境はセットアップされたはずなので、接続確認をしておきます(下記のサーバとプロジェクトは架空のものです)。

> bzr branch bzr+ssh://bzr@remote-x.org/home/bzr/project-a

無事にローカルにブランチが作成されれば確認終了です。

Cygwin + OpenSSH の次は TortoiseBzr で bzr+ssh プロトコルを扱えるようにします。
TortoiseBzr で SSH プロトコルを扱うためには、PuTTY に付属の PuTTYgen と Pageant を使って Pageant に公開鍵/秘密鍵のうち、秘密鍵を登録しておかなければなりません。下記 URL に従って PuTTY のセットアップを行ないます。
http://openbooth.org/archives/128.html

上記 URL の通り作業すれば Pageant に秘密鍵を登録することができたはずです。それでは接続確認をします。

適当なディレクトリで右クリックから TortoiseBzr のチェックアウト項目を選択します。
ブランチ元 URL を bzr+ssh からはじまる URL を入力して [作業ツリーオプション] の [このブランチのローカルコピーを作成] を選択します。

TortoiseBzr でリモートブランチをクローン

上のダイアログで [OK] をクリックして暫くすると以下のように Pageant から「認証のために鍵を使って良いか？」と尋ねられるので [Yes] をクリックします。

Pageant の認証ダイアログ

無事にリポジトリのクローンを作成できれば動作確認は終了です。

Windows での Bazaar 環境のセットアップはまだちょっと面倒臭いですね。

http://www.st.ryukoku.ac.jp/security/ssh/publickey/win.html

手元に 公開鍵/秘密鍵 のペアがある場合は PuTTY Key Generator ダイアログで [Generate] ボタンではなく [Load] ボタンをクリックして、秘密鍵ファイルを選択すれば OK です。後の手順は上記ページの通り。

うむ、丸投げ、以上w

まず http://cygwin.com/setup.exe をダウンロードします。ダウンロードできたら setup.exe をダブルクリックして Cygwin のインストールウィザードを起動します。インストールウィザードの中に Select Packages というフェーズがあり、インストールするパッケージを選択する画面が表示されます。この画面で [Net > openssh] の項目にチェックを入れます(openssh の行を一度クリックすれば ok、インストールされるバージョンに行の表示が切り換わります)。

openssh パッケージを選択

他にインストールしたいものがあれば適宜インストールしますが、SSH を利用したいだけであれば [Net > openssh] のみで OK です。
あとはウィザードの支持に従って「次へ」をクリックしていけば、しばらくすると Windows に Cygwin がイントールされます。

次に接続確認です。

ここでは「手元に 公開鍵/秘密鍵 のペアがあり、かつログインするサーバには鍵ペアのうち、公開鍵がサーバ側の ~/.ssh/authorized_keys に登録されている」ことを前提とします。

まず、Cygwin を起動します。Cygwin のターミナルが表示され、Bash が起動するので以下のコマンドを叩いて秘密鍵を適切な場所(~/.ssh/id_rsa) に配置します。

% cd
% ls
id_rsa
% mkdir .ssh
% mv id_rsa .ssh

パーミッションは以下のように設定しておきます。

% cd
% ls -al .ssh
drwx------+ 2 keiji なし    0 Jun  4 16:35 .ssh
% cd .ssh
% ls -l
-rw------- 1 keiji なし 1675 Jun  4 16:34 id_rsa

ここまでできれば、サーバに対して SSH で接続できるようになっているはずです。鍵にパスフレーズを設定していなければ、以下のコマンドを叩けばサーバに接続できるはずです。

% ssh test@openbooth.org

ここでは、サーバ名を仮に openbooth.org、ログインユーザ名を test としています。

以上で Cygwin を使った接続はおしまい。

ただ開発が活発な分、システムをアップグレードする時の不安はあります。「システムのアップグレードに失敗したらどうしよう」といった。アップグレードする際に、事前にバックアップを取っておけば良いのでしょうが、面倒臭く感じてしまう。あまりコピーを持っておきたくないのです。

という背景があるので、今はこのシステム自体を Git でバージョニングしています。別に Git である必要はないのですが (Subversion でも Bazaar でも…) このブログを開設した当時「これはいい」と思ったバージョン管理システムが git だったのでそれを使ってます。

以下はシステムアップグレードの際の作業メモです。

% cd ~/public_html_openbooth.org/public
% git commit -m 'for now'
% git tag -a wp2.6.3 # 念のためタグ付けして、パッチあてに失敗したときのための保険としておく

% cd
% mkdir workspace
% cd workspace
% wget http://ja.wordpress.org/wordpress-2.6.3-ja.zip # 現在のバージョンのコードをダウンロード
% wget http://ja.wordpress.org/wordpress-2.7.1-ja.zip # アップグレードしたいバージョンのコードをダウンロード
% unzip wordpress-2.6.3-ja.zip
% mv wordpress wordpress-2.6.3
% unzip wordpress-2.7.1-ja.zip
% mv wordpress wordpress-2.7.1
% diff -urN wordpress-2.6.3 wordpress-2.7.1 > wp2.6.3_to_wp2.7.1.patch # 2つのバージョン間の差異を取ってパッチを作る

% cd ~/public_html/openbooth.org/public
% patch -p1 < ~/workspace/wp2.6.3_to_wp2.7.1.patch # パッチをあてる

ここまで終わったら動作確認。正常に稼動していたら

% git commit -m 'upgrade to wordpress-2.7.1'

で変更をコミットしておく。

上手く動かなかったら

% git checkout -f

でシステムをパッチ適用前に巻き戻す。バージョニングしていると、「やりなおし」が効くので便利ですね。
バージョン管理システムは素晴しい保険だ！

前回までで、gitosis のインストールと疎通確認まで終わりました。もしエントリの通りに手を動かしていれば、手元には gitosis-admin.git のクローンがある状態のはずです。このエントリは gitosis の設定編ということで、gitosis-admin.git の説明をしていきます。

gitosis はアカウント情報やアクセス制御の情報を gitosis-admin.git を用いて管理します。アカウントの追加や削除やアクセス制御の変更を行うときには、僕たちは gitosis-admin.git の内容を変更することになります。

gitosis の設定変更の基本は以下の2ステップです。

1. ローカルで gitosis-admin ディレクトリ以下のファイルを追加/変更/削除
2. サーバ上の gitosis-admin.git に反映(git push)

それでは、まずはサーバ上の gitosis-admin.git を git clone して、ディレクトリ階層を見てみます。まだ gitosis-admin.git を手元に落としていない場合は以下の操作で手元に落としておきます。

local% git clone ssh://git@remote-name.com/gitosis-admin.git

ディレクトリの中を眺めてみます。以下のような構成になっており、非常に単純です。

gitosis-admin
|-- gitosis.conf # アクセス制御用の設定ファイル
`-- keydir
    `-- keiji.pub # 登録されてるアカウントの公開鍵、keiji.pub は gitosis-init で指定した公開鍵

では gitosis.conf と keydir を個別に見ていきます。

gitosis.conf
gitosis.conf の中身は INIっぽいフォーマット で記述されいます。初期状態では以下のように自分自身(gitosis-admin)の設定のみが記述されています。

[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = keiji

上記の内容は、ユーザ keiji がサーバ上のリポジトリ gitosis-admin.git を編集可能(writable) であることを定義しています。リポジトリコンテナの管理アカウントは、現時点では keiji のみとなります。

それでは、fred というアカウントを追加してこのアカウントがリポジトリコンテナの管理者としてふるまえるようにしてみます。

まずは上記 gitosis.conf の内容を編集します。

[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = keiji fred

gitosis.conf の変更はこれだけです。簡単ですね。

ですが、これだけでは fred は git clone ssh://git@remote-name.com/gitosis-admin.git することはできません。fred はまだ gitosis のアカウントとして認証されていないからです。ここでようやく keydir の出番です。

keydir
keydir ディレクトリは認証された gitosis アカウントの公開鍵一覧を含みます。現時点では gitosis-init を実行したときに登録された最初のアカウント(keiji の公開鍵 keiji.pub)のみ登録されています。fred アカウントを有効にするには fred の公開鍵を keydir 以下に保存する必要があります。

ここでは仮に fred から公開鍵 id_rsa.pub を受け取ったとします。この鍵を gitosis-admin/keydir に保存します。

local% ls -F
id_rsa.pub gitosis-admin/
local% mv id_rsa.pub fred.pub
local% mv fred.pub gitosis-admin/keydir/
local% ls gitosis-admin/keydir/
keiji.pub fred.pub

id_rsa.pub のファイル名を変更したのには理由があります。gitosis はアカウント名として公開鍵のファイル名から拡張子 .pub を除いた部分を使用します。そのため keydir に保存するときは、公開鍵のファイル名を gitosis.conf で指定したアカウント名と併せておく必要があるのです。

さて、現時点ではローカル上では fred が存在して、サーバ上には存在しない状態です。これをサーバ上の gitosis-admin.git に反映する必要があります。ここからは git オペレーションになります。

local% cd gitosis-admin
local% git commit -a -m "account 'fred' added. this account is administrator."
local% git push

git push が上手くいけば、サーバ上の設定ファイルが自動的に更新されて fred が有効になります。¹

これで fred は gitosis-admin.git をクローンすることができるようになっているはずです。fred ユーザで試してみます。

local% sudo su - fred
local% mkdir -p workspace/hosting-self
local% cd workspace/hosting-self
local% git clone ssh://git@remote-name.com/gitosis-admin.git
Initialized empty Git repository in /home/fred/workspace/hosting-self/gitosis-admin/.git/
remote: Counting objects: 24, done.
remote: Compressing objects: 100% (24/24), done.
remote: Total 24 (delta 6), reused 3 (delta 0)
local% ls -F
gitosis-admin/

上記のように gitosis-admin.git をクローンできれば成功です。²

ここまでで、アカウント追加の作業は終了です。

次は、現在存在するアカウント(keiji, fred)にそれぞれプライベートな(それぞれ自分だけが編集できる)リポジトリを与えてみます。gitosis.conf を以下のように変更して git push します。

[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = keiji fred

[group keiji]
writable = private/keiji
members = keiji

[group fred]
writable = private/fred
members = fred

これで keiji は private/keiji.git、fred は private/fred.git。というリポジトリを与えられました。gitosis はコンテナ内にディレクトリ階層を作れるというのがポイントです。ここでは private というディレクトリを掘ってみました。private という名前に特に意味はありません(hoge でも fuga でも何でも良い)。

ただし gitosis.conf を push したら、サーバ上のコンテナに勝手に Git リポジトリが作られるわけではありません。単に push する権限を与えられるだけです。

ということで private/keiji の領域に収める Git リポジトリを作ってみたいと思います。まずはローカルの keiji ユーザで新しい Git リポジトリを用意します。

local% mkdir private-repo
local% cd private-repo
local% git init
local% git remote add origin ssh://git@remote-name.com/private/keiji.git
local% echo 'This git repository is private.' > README
local% git commit -a -m 'Initial commit'

git remote add ssh://git@remote-name.com/private/keiji.git の指定が重要ですので間違えないように気をつけて下さい。そうしたら後は git push するだけです。

local% git push origin master

サーバ上に存在しないリポジトリを push すると、gitosis は以下のプロセスを経てリポジトリを同期します。

1. コンテナ内にリポジトリが存在するかをチェック
2. gitosis.conf に記述されているリポジトリ名かチェック
3. 権限はあるかチェック
4. Bare リポジトリを新しく作成
5. git push されたリポジトリの内容とコンテナ内のリポジトリを同期

これで gitosis の一連の操作はカバーできたかなという感じがします。まだ触れていないものは、(現時点で僕が把握してる限り)以下の5つですね。

• アカウントの削除
• リポジトリの削除
• gitosis.conf のその他の細かい設定
• git-daemon について
• gitweb について

gitosis はリポジトリの削除はサポートしないようです。まぁ、削除は危険ですからね。リポジトリを本当に削除したい場合はサーバにログインして rm -rf すればいいでしょう。アカウントの削除は、単純に keydir ディレクトリから該当の公開鍵を削除して git push すれば ok です。簡単ですね。

git-daemon と gitweb については試してないので説明はできません。gitosis.conf の細かい設定については git://eagain.net/gitosis.git の中にある example.conf を見て頂ければ分かるでしょう。

ひとまずこれで終わりですが、gitosis 側で個々のリポジトリのフックを操れるようになれば post-receive にメール送信を仕込むとかより簡単に設定できるようになると思ってるので、今後ちょくちょく gitosis をいじっていくかもしれません。

前回のエントリでは、Git リポジトリの管理に対する不満と、それを少し改善してくれる gitosis を簡単に紹介をしました。このエントリでは gitosis のインストール編ということで話を進めていきます。

基本的に Hosting Git repositories, The Easy (and Secure) Way のエントリと同様です。本家の方が安心という人はそちらのエントリをどうぞ。

サーバ/クライアント(ローカル)両方で作業する必要があるので、識別しやすいように以下の表記をします。

サーバ作業のプロンプト表記

remote% 

クライアント(ローカル)作業のプロンプト表記

local% 

また、サーバアドレスを便宜上 remote-name.com とします。

まずは Git リポジトリをホストするサーバに git 及び gitosis をインストールします。サーバにログインしてインストールを開始します。

local% ssh keiji@remote-name.com
remote% sudo aptitude install git git-core
remote% sudo aptitude python python-setuptools # gitosis は python で書かれてるため必要に応じてインストールする。
remote% mkdir ~/src
remote% cd ~/src
remote% git clone git://eagain.net/gitosis.git
remote% cd gitosis
remote% sudo python setup.py install # gitosis をシステムにインストールする。

ここまでで gitosis のインストールは終了。僕は ubuntu 8.04 server edition で試していますが特に問題なくインストール完了しました。

次に、サーバ上にホストする Git リポジトリの管理用ユーザを作成します。gitosis は ~/.ssh/authorized_keys をいじる(生成する)ので、~/.ssh/authorized_keys を編集している場合は gitosis によって勝手に上書きされてしまって「うわーん」な状況になってしまいます。そのため Git 用に新しくユーザを作った方が無難です。

そういうことで、ここでは git ユーザを作成します。このユーザは公開鍵によるログインしか行わないのでパスワードログインは無効にしておきます。

remote% sudo adduser
--system
--shell /bin/sh
--gecos 'git version control'
--group
--disabled-password
--home /home/git
git

git ユーザの作成が完了したら、gitosis が管理する Gitリポジトリコンテナ¹ を作成します。このコンテナを作成するには、少なくとも一つはアカウントを登録しなければなりません(ここで登録するアカウントはコンテナの管理アカウントになります。管理アカウントは後で変更できます)。gitosis は公開鍵 によってアカウントを識別するので、まずは自分自身のアカウントを作るために自分の公開鍵をサーバに転送することにします(公開鍵を持っていない場合は適宜作成する)。

local% % scp ~/.ssh/id_rsa.pub keiji@remote-name.com:/home/keiji # 自分の公開鍵をサーバに転送

さて、ようやく gitosis のリポジトリコンテナを作成するときがきました！コンテナの作成には gitosis に付属する gitosis-init スクリプトを使用します。このスクリプトは gitosis のインストールが完了していれば、既にシステム上に存在しているはずです。

% sudo -H -u git gitosis-init < /home/keiji/id_rsa.pub # gitosis-init を用いて先程転送してきた鍵を登録。上で作ったユーザ(git)で実行
Initialized empty Git repository in ./
Initialized empty Git repository in ./
% sudo ls /home/git # git ユーザのホームディレクトリに gitosis と repositories という二つのディレクトリが作られてる
gitosis  repositories

gitosis-init を実行すると /home/git は以下のファイルとディレクトリが作られているはずです。

/home/git/
|-- .gitosis.conf -> /home/git/repositories/gitosis-admin.git/gitosis.conf
|-- .ssh
|   `-- authorized_keys # gitosis-admin.git の内容が push されると、gitosis-admin.git の内容に応じて再生成される
|-- gitosis
|   `-- projects.list
`-- repositories
    `-- gitosis-admin.git

そして最後に gitosis がアクセス制御に使用する Git リポジトリ(gitosis-admin.git) に含まれる post-update フックスクリプトのパーミッションをチェックしておきます。post-update フックスクリプトには実行権限が付与されている必要があります。通常 755 になっているはずですが、なっていなかったら適宜 chmod して下さい。これは重要な作業です。

パーミッションが以下のようになっていれば問題ありません。

remote% sudo ls -l /home/git/repositories/gitosis-admin.git/hooks/post-update
-rwxr-xr-x 1 git git 69 2008-11-06 15:26 /home/git/repositories/gitosis-admin.git/hooks/post-update

これでサーバ上のリポジトリコンテナのセットアップは完了！
クライアントからこのリポジトリコンテナにアクセスできるかどうか試してみます。

local% mkdir -p ~/workspace/hosting-self
local% cd ~/workspace/hosting-self
local% git clone git@remote-name.com:gitosis-admin.git # or ssh://git@remote-name/gitosis-admin.git

gitosis-admin.git を git clone することができれば完了です。

gitosis-admin.git リポジトリについて簡単に説明します。 このリポジトリはアカウントを登録/削除したり、アクセス制御を設定するために使用します。アカウントを追加登録したい場合には、リポジトリ内の keydir ディレクトリ以下に追加アカウント用の公開鍵を git add することで行います。アクセス制御を設定するにはリポジトリ内にある gitosis.conf を編集します。

もちろん、この gitosis-admin.git リポジトリ自体もアクセス制御の対象です。

gitosis-admin.git については次のエントリでもう少し詳しく紹介します。

しかし、このリモートリポジトリを自前のサーバでホストする、あるいは企業のバージョン管理ツールとして Git を使うとなると俄然敷居が高くなるように感じます。github のウェブアプリケーションとその周辺ツールがオプソで公開されていれば非常に嬉しいのですが、まぁ現時点ではそんなおいしい話はない訳で、ないものねだりになってしまいます。

そのため、特に企業で導入する際にはリポジトリ群を管理するスクリプトを自前で作る必要がでてきます。というのも、リポジトリの管理スクリプト(例えば、ローカルにあるリポジトリをリモートに配備する、リモートのリポジトリを削除する等々…)がないと、新しいプロジェクト用にリポジトリを作成する度に一々サーバにシェルログインして git init –bare hoge.git とかしなければならなくて非常に面倒です。しかも、皆がリポジトリをホストしているサーバにログインできる状態はセキュリティ的にも酷い状況になり良くありません(これは git-shell 使うという手はあります)。

僕もこのGitリポジトリ群の管理に関しては何か良い管理ツールはないものかと探していました。ですが、すぐに良いものを見つけることができなかったので、必要に迫られて結局自前でスクリプトを書くことにしました。サーバにリポジトリを作成して git remote add してサーバ側の bare リポジトリに push するとか、サーバ上に存在するリポジトリ一覧の URL を取得するとか、リモートリポジトリを削除するとか、そんなタスクをコマンド化しました。(中途半端な状態で開発止まってしまってますけどね…)

Git は、それを使ってプロジェクトのバージョン管理をするといった面ではブランチをバンバン切って、それらのブランチを簡単にマージすることができるので快適で良いです。好きです。Git を使って何かを開発している時はね。

開発中に恩恵をくれる Git も、リポジトリ自体を管理するということになると面倒になる(リポジトリの数が増えれば増える程しんどくなる)。責務の切りわけという意味で正しいですけど、Git 自体はそこをサポートしてくれません。

ここに一つ、Git 導入への壁が存在するような気がします。

さて、ここからが本題です。Git 導入には上に書いたような問題があります(少なくとも僕はそう思ってる)。これは解消しておきたいと思い、自分でそれっぽいもの作ったり、ググってそれっぽいものがないか調べたりしてきました(ごく最近ですけどね)。

そんなこんなでようやく gitosis というソフトウェアを見つけました。前フリがやたらと長くなってしまいましたが、このエントリは、この gitosis を紹介するというのが主旨です。

gitosis について書かれてるブログエントリの一部を引用します。

Hosting Git repositories, The Easy (and Secure) Way

how to host and manage Git repositories with access control, easily and safely. I use an up and coming tool called gitosis that my friend Tv wrote to help make hosting git repos easier and safer. It manages multiple repositories under one user account, using SSH keys to identify users. However, users do *not* need shell accounts on the server,

まじ！僕が欲しかったものですよ。エントリの上記の部分を読んで思わずニヤッとしてしまいましたw

gitosis にはこんな特徴があるようです。

• リポジトリに対するアクセス制御
• 安全 # 認証は公開鍵で行い、通信にはSSHを使う。設定が簡単かどうかは人によるので一概に簡単とは言えない
• 一つのアカウントで複数リポジトリを管理 # もちろん複数アカウントでも運用できる
• 公開鍵でユーザを識別する
• リポジトリにアクセスするアカウントはサーバへのログインを許可されてなくてイイ！ # 自分で ~/.ssh/authorized_keys を管理する必要はない

これを知らずに自前でスクリプト書いてしまったことを悔やむ。しかもリンク先のエントリは去年のだし…無念

無念なのは別に良いとして、良いもの見つけたので早速使ってみました。エントリが長くなってきたので次回に持ち越しますが、gitosis のインストールや設定やらをエントリにしておこうと思います。↑のエントリ読めば使えますけどね…

gitosis については何回かに分けてエントリを書きます。

1. gitosis - Git リポジトリ群の管理とアクセス制御 vol.1
2. gitosis - Git リポジトリ群の管理とアクセス制御 vol.2