昨今明日2013/07/20GitLabをインストールする際に陥った問題のまとめGitLabはGitHubのようなGitホスト環境を手元で構築できる、大変有益なツールです。1.9で利用しています。動作させるコツと共に、ハマった点をまとめておきます。インストールには、gitlab-freebsd/gitlabhqで公開されているインストールガイドが、大変参考になります。概ねこの手順に従えば、トラブルなくインストールが完了します。gitlab-freebsd/gitlabhqではgitlabhq/gitlabhqのforkが公開されていますが、GitLabのコード自体へ特殊な変更が行われているわけではありません。オリジナルリポジトリへ、FreeBSDのportsと親和性の良い各種設定ファイルを同梱している、と捉えると分かりやすいと思います。実際、forkされているコードは比較的古い版であるため、設定ファイルを参考に、オリジナルの最新版を動作させると良いでしょう。FreeBSDではgitlab-shellへ注意GitLabのv5系はgitlabhq/gitlab-shellへ依存しています。v1.6までのコードはFreeBSDでは動作しません。gitlab-shellをFreeBSDで利用する場合にはf13afa2db3以降のコード利用する必要があります。sedの-iオプション引数取り扱いの差あり、変更差分はわずかです。Blogで公開されているスクリプトが綺麗にまとまっており、利用させていただいています。ここで公開されているスクリプトの最新版にはバグが有り、重要な外部プログラムであるsidekiqが動作しません。修正した版をgistで公開していますので、こちらの利用をお薦めします。本質は変数の初期設定ミス修正です。へはrepositoryを格納するディレクトリを設定するrepos_pathがあります。linkを含んではいけません。linkとしてインストールされることです。linkを含んでしまうことになります。このディレクトリを使いたい場合には、明示的に/usr/home/git/repositoriesと設定するか、/homeの位置を再調整する必要があります。限った話ではありませんが、GitLabではsidekiqプロセスが正しく動作していることが非常に重要です。sidekiqプロセスが動作していない場合、表面上は正常に動作しているように見えるものの、実際には正常動作しない、という、分かりにくい状況へ陥ります。Web画面ではssh鍵の登録が正常終了したように見えたにも関わらず、実際には、authorized_keysへ鍵が登録されていない、といった状況や、プロジェクトの作成指示が正常動作したように見えたにも関わらず、repos_pathで指定したディレクトリ内へはリポジトリが作られていない、という状況になった場合、sidekiqプロセスが、正しく動作していることを確認すると良いでしょう。sidekiqが正常動作している場合、psでは次のように見えます。(ruby19なおsidekiqプロセスは、GitLabの起動スクリプト内で起動されることが一般的です。うまく動作しない場合にはスクリプトを確認すると良いでしょう。ファイルは、リポジトリアクセス権管理に使われる重要なファイルです。何らかの不具合により、このファイル内へ同一の鍵が複数個登録されてしまった場合、GitLabが正常に動作できなくなる可能性があります。正しいかどうかを確認すると良いでしょう。NAME>はGitLabで登録したユーザ名です)。この応答が返らない場合、鍵設定に問題のある可能性があります。GitLabは大変便利なツールです。ツールの規模がやや大きいため、トラブルシュートでやや混乱しがちですが、設定ファイル自体はシンプルなため、問題を適宜切り分ければ、対処は難しくないと思います。ユーティリティ(バージョン6.3.6)に基づいています。経由でアクセス出来るように設定する必要がありました。して、HostBasedAuthentication(以下、ホストベース認証)の設定方法をまとめました。G(VGN-G2)のディスクが壊れてしまいました。実行してみると不良セクタが存在しています。セクタ破壊が進んで再読込が繰り返されているのか、動きも緩慢になってきています。