openbooth

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 を入力して [作業ツリーオプション] の [このブランチのローカルコピーを作成] を選択します。

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

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

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

以下のページの通りにセットアップすればセットアップは完了です。

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

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

うむ、丸投げ、以上w

windows 環境で Cygwin + OpenSSH で SSH のクライアント環境を作ったときのメモです。公開鍵暗号のみ許可していて、パスワードでのログインを許可していないような SSH サーバを想定しています。

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

他にインストールしたいものがあれば適宜インストールしますが、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 を使った接続はおしまい。

openbooth.org は今現在(2009-06-01) ブログシステムに WordPress を使用しています。WordPress を使っている理由はプラグインが豊富でかつ、まだ開発が活発なのでずーっと使い続けていけるかなぁと思ったからです。

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

という背景があるので、今はこのシステム自体を 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 - Git リポジトリ群の管理とアクセス制御 vol.1 の続編です。

前回までで、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 をいじっていくかもしれません。