GitLabをインストールする際に陥った問題のまとめ

GitLabはGitHubのようなGitホスト環境を手元で構築できる、大変有益なツールです。

主なサポートプラットフォームはLinuxの各ディストリビューションですが、私はGitLab v5.3をFreeBSD 8.4 + ruby 1.9で利用しています。

やや環境設定で戸惑う事があったので、FreeBSD で動作させるコツと共に、ハマった点をまとめておきます。

FreeBSD へインストールする際の参考ドキュメント

FreeBSD へのインストールには、gitlab-freebsd/gitlabhqで公開されているインストールガイドが、大変参考になります。概ねこの手順に従えば、トラブルなくインストールが完了します。

なおgitlab-freebsd/gitlabhqではgitlabhq/gitlabhqのforkが公開されていますが、GitLabのコード自体へ特殊な変更が行われているわけではありません。オリジナルリポジトリへ、FreeBSDのportsと親和性の良い各種設定ファイルを同梱している、と捉えると分かりやすいと思います。

実際、forkされているコードは比較的古い版であるため、設定ファイルを参考に、オリジナルの最新版を動作させると良いでしょう。

FreeBSDではgitlab-shellへ注意

GitLabのv5系はgitlabhq/gitlab-shellへ依存しています。但し、gitlab-shell v1.6までのコードはFreeBSDでは動作しません。

gitlab-shellをFreeBSDで利用する場合にはf13afa2db3以降のコード利用する必要があります。

問題の本質はGNU sedとBSD sedの-iオプション引数取り扱いの差あり、変更差分はわずかです。

FreeBSD向けGitLab起動スクリプト

FreeBSD向けGitLab起動スクリプトとしては、Eyes JAPAN Blogで公開されているスクリプトが綺麗にまとまっており、利用させていただいています。

但し、ここで公開されているスクリプトの最新版にはバグが有り、重要な外部プログラムであるsidekiqが動作しません。

修正した版をgistで公開していますので、こちらの利用をお薦めします。本質は変数の初期設定ミス修正です。

repos_path へは symbolic link を含んではならない

gitlab/config/gitlab.yml ならびに gitlab-shell/config.yml へはrepositoryを格納するディレクトリを設定するrepos_pathがあります。コメントへ書かれている通り、この値はsymbolic linkを含んではいけません。

ここで注意すべきは、FreeBSDを標準設定でインストールした場合、/homeディレクトリが、usr/homeへのsymbolic linkとしてインストールされることです。

結果、GitLab標準設定に基づき、repos_pathとして/home/git/repositories/を指定すると、結果的にsymbolic linkを含んでしまうことになります。

もしこのディレクトリを使いたい場合には、明示的に/usr/home/git/repositoriesと設定するか、/homeの位置を再調整する必要があります。

sidekiq が動作していることを確認する

FreeBSD へ限った話ではありませんが、GitLabではsidekiqプロセスが正しく動作していることが非常に重要です。

sidekiqプロセスが動作していない場合、表面上は正常に動作しているように見えるものの、実際には正常動作しない、という、分かりにくい状況へ陥ります。

例えば、Web画面ではssh鍵の登録が正常終了したように見えたにも関わらず、実際には、authorized_keysへ鍵が登録されていない、といった状況や、プロジェクトの作成指示が正常動作したように見えたにも関わらず、repos_pathで指定したディレクトリ内へはリポジトリが作られていない、という状況になった場合、sidekiqプロセスが、正しく動作していることを確認すると良いでしょう。 

例えばsidekiqが正常動作している場合、psでは次のように見えます。

# ps ax | grep sidekiq
41032   0  I      0:22.50 ruby19: sidekiq 2.11.1 gitlab [0 of 25 busy] (ruby19

なおsidekiqプロセスは、GitLabの起動スクリプト内で起動されることが一般的です。うまく動作しない場合にはスクリプトを確認すると良いでしょう。

.ssh/authorized_keys 内の鍵へ注意する

これもFreeBSD へ限った話ではありませんが、GitLabを動作させているユーザの .ssh/authorized_keys ファイルは、リポジトリアクセス権管理に使われる重要なファイルです。

何らかの不具合により、このファイル内へ同一の鍵が複数個登録されてしまった場合、GitLabが正常に動作できなくなる可能性があります。

GitLab 管理下にある repository へ push を行った際、

fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

といったメッセージが表示された場合、.ssh/authorized_keys が正しいかどうかを確認すると良いでしょう。

なお、鍵が正しくインストールされている場合、

% ssh -t gitlab@GitLabServerName.example.com

とのコマンドに対し、

Welcome to GitLab, <YOUR USER NAME>

との応答が返ります(<YOUR USER NAME>はGitLabで登録したユーザ名です)。この応答が返らない場合、鍵設定に問題のある可能性があります。

GitLabは大変便利なツールです。ツールの規模がやや大きいため、トラブルシュートでやや混乱しがちですが、設定ファイル自体はシンプルなため、問題を適宜切り分ければ、対処は難しくないと思います。

ssh で HostBased 認証を行うには ssh-keysign に setuid する必要がある

ssh で特定ホストからの login を、ユーザに依存せずに許可する場合には、HostBased 認証を使うと便利です。

例えば「他のマシンへ root ユーザとして ssh で login し、rsync でバックアップを取る」などの場合に利用したりします。

HostBased 認証の設定ですが、ssh プロトコルバージョン2を利用する場合、基本的には、「login される側(サーバ)」では、

• /etc/ssh/sshd_config で HostbasedAuthentication yes に設定
• /etc/ssh/ssh_known_hosts へクライアントホストの公開鍵を登録
• /etc/ssh/shosts.equiv へクライアントのホスト名(またはIPAddress)を記載

と設定し、一方「login する側(クライアント)」では、「/etc/ssh/ssh_config」へ該当サーバ限定用の設定として、

EnableSSHKeysign yes
Host foo.example.com
 HostbasedAuthentication yes
 PreferredAuthentications hostbased,publickey,password

と書きます(2011/05/02: 上記EnableSSHKeysignの位置を修正しました)。

ssh プロトコルバージョン2 を使った HostBased 認証を有効にする場合、クライアント側 ssh_config の EnableSSHKeysign が1つのポイントです。この指示により、ssh コマンドが ssh-keysign コマンド経由でローカルホストキーへアクセスすることが可能になります。

ただし、ssh-keysign が適切にホストキーを読み込むためには、ssh-keysign が root へ setuid されている必要があります。ここが第2のポイントです。

少なくとも FreeBSD 6.4 ならびに 7.2 では、デフォルトでは、このコマンドは setuid されていません。すなわち、sshd/ssh 側の設定を適切に行っても、上記 FreeBSD をクライアントにした場合、デフォルトのままでは、HostBased 認証を使って login 出来ない、ということになります。

対応は簡単で、該当コマンドを setuid するだけです。

# chmod u+s /usr/libexec/ssh-keysign
# ls -l /usr/libexec/ssh-keysign 
-r-sr-xr-x  1 root  wheel  23308 Nov 26  2008 /usr/libexec/ssh-keysign

これで上記FreeBSD でも HostBased 認証で login 出来るようになります。

このあたりは、ssh(1) の FILES や、ssh-keysign(8)のDESCRIPTIONで丁寧に言及されているのですが、一部 Linux では ssh-keysign がデフォルトで root へ setuid されていたため、今まで気がつきませんでした。

もし FreeBSD で HostBased認証がうまくいかない、とハマった場合には、/usr/libexec/ssh-keysign の permission を確認してみてください。

FreeBSD 6.4 から FreeBSD 7.2 へのアップデート

FreeBSD 7系 から、3回目のリリースとなる FreeBSD 7.2 が公開されました。

今まで FreeBSD 6.4 を使っていましたが、そろそろ良い頃合いかと思い、移行してみることに。

従来、FreeBSD の major アップデートは、cvsup で src を持ってきた後、/usr/src/UPDATINGを見つつ、大きく変更の加わった /etc 配下のファイルを mergemaster で制御しつつ、といった感じの作業となることから、私にとってはなかなか手間のかかる作業でした。

しかし今回の major アップデートでは freebsd-updateコマンドを使うことで、この作業を自動化することができます。これは嬉しい!

freebsd-update コマンドを使った major アップデートの方法は、詳細な手順が Web で公開されていますので、これに従うのが簡単です。

なお記事内にも書かれている通り、今回の移行元は upgrade 機能をサポートしたfreebsd-updateコマンドが最初から用意されている FreeBSD 6.4 になりますので、記事内のsh freebsd-update.sh -f freebsd-update.confをfreebsd-updateへ読み替えて実行することになります。

実際に作業を行って気のついた点は以下の通りです。

1. upgrade 処理は時間がかかる

取得ファイルを丹念に調べ上げ、その後に取得をはじめるため、 upgrade 処理には非常に長い時間がかかります。寝る前などに実行しておくと良いかもしれません。

2. portupgrade -a に時間がかかる

記事内では portupgrade -a を2度行うことが推奨されています。特にそのうち一回は -f 付きであり、インストールされている ports を full build することになりますので、ここでもそれなりの時間がかかります。package が使える人は、-P の併用も考えると良いでしょう。

なお、FreeBSD 7.x 系は thread をはじめ、各種ライブラリが変更になっていますから時間がかかるから、という理由で portupgrade を端折るのは避けた方が無難です。

3. 最後のfreebsd-update install の前に misc/compat6x を入れておくと良い

最後のfreebsd-update installを実行すると、古いライブラリを消去してくれます。が、私が portupgrade -af のやり方を間違えたのか、再構築後の一部 ports が、libc.so.7ではなく libc.so.6 を要求していたため、起動できない ports が出てしまいました。念のため、misc/compat6x を入れておくと良いかもしれません。

4. VMware 5.x の vmware-checkvm が起動できない

ここ数年 FreeBSD は Windows 上の VMware workstation 5.x で使っているのですが、FreeBSD 7.x に入れ替えたところ、vmware-checkvm が Bad system call でcore dump するようになってしまいました。VMware workstation 6.x 上では動作するようなのですが、5.x 系のvmware-checkvm は static link されているためか、うまく動作させることが出来ません。

折角の機会なので、VirtualBox上で稼働させることにしました。今まで使っていた vmdk をそのまま使っていますが、特に問題なく動作しています。

5. vje の ports が削除された

私は長い間 FreeBSD 上の仮名漢字変換サーバに VJE-Delta を使っていたのですが、とうとう ports から消えてしまいました(といっても、消えたのは、昨年の8月のようですが...)。依存している misc/compat3x がずいぶん前から FORBIDDEN になっていたので、致し方ないことです。

残念ながら VJE-Delta そのものもずいぶん前から販売終了となっていますので、これを機会に仮名漢字変換サーバを乗り換えることに。といっても、VJEをesecanna経由で使っていた関係で、最も簡単に移行できる canna を選択。VJE以前は、cannaを使っていたとは言え、10年以上のブランクがあるので、何か新鮮な感じです...。

FreeBSD 7.2 への入れ替えが終了した後は、快適に動作しています。current 時代を通しても7.x系は使っていなかったので楽しみです。

FreeBSD、Subversion へ移行開始

FreeBSD Project が SCM を CVS から Subversion への移行開始しを表明しました。

FreeBSDでは、public な箇所では CVS を、より内部的な開発では Perforce を使っていましたが、今回の移行は移行はこの public 用のリポジトリです。「少なくとも stable 系に関しては、support lifetime 中は、CVS tree を維持するからね」という堅実なアナウンスが、FreeBSDっぽいなぁ、と感じます。

基盤は CVS から Subversion へ、と、ある意味、順当な変更となりました。一方「ports などに関しては未定」と書かれていますので、これらがどうなるのかも、興味があります。いっそのこと、全部 SCM を変えてくれると、楽しいのですが(おぃ)。

しかし、14年間の歴史が詰まったCVSの移行は、本当に大変だったのでは、と思います。これを実現したこと、また、cvs2svnがこの作業に耐えたことは、両者とも、賞賛されるべきだなぁ、と感じました。

お疲れさまでした。

NFS + FreeBSD で Subversion を使うときには、1.5.0 以降を利用しよう

Subversion のリポジトリをNFSサーバ上に置き、その領域を FreeBSD から mount して使う場合、1.4.x の Subversion が では問題が起きる場合があります。

具体的には、

• Subversion のリポジトリが NFS サーバ上にあり、FreeBSD からは mount_nfs している。
• mount_nfs をしている FreeBSD には、Subversion 1.4.x 以前がインストールされている。
• 適当なクライアント(バージョン/OSは問わない)から、一定個数以上のファイルを commit する(schemeは、file、svn+ssh、httpを問わない)。

という条件がそろうと、

svn: Can't remove 'db/transactions/1-1.txn': Directory not empty 

というエラーメッセージが表示され、commit が fail してしまうことがあります。実際には commit 自体は成功し、ファイルの後片付けに失敗しているだけなのですが、ディレクトリ使用量が無駄に増加します (^^;。

原因は、FreeBSD の getdirentries(2) が、open されているディレクトリ内のエントリが削除された場合、それを上手くハンドリングできないためです。

この現象は、当初MacOS X上の問題として報告され、MacOS Xでのみ対策が施されました。

その後、同じ問題がFreeBSDでも発生することが報告され、それを受け、r20459では、修正範囲がOS非依存の形式へと拡張されました。但し、残念ながら、この修正は、当時の trunk へのみ commit されており、1.4.xには反映されていません。

幸いにして、上記修正の取り込まれたSubversion 1.5.0のリリースが間近に迫っています。もし上記現象で困っている場合には、1.5.0の利用を試してみてはいかがでしょうか?

FreeBSD 7.0 RELEASE

FreeBSD 7.0がリリースされました。おめでとうございます。

自分で使う分にはこんなところが面白そう。

• The ULE scheduler is vastly improved...


• Experimental support for Sun's ZFS filesystem.


• The unionfs filesystem has been fixed.

7.1Rになったら、手元のシステムを入れ替えよう。