インストールは
基本的にはGitLabのドキュメントの通り進めれば良いGitLabのinstallation.mdだけではだめで、
gitlab-recipesのドキュメントも参考にしながら進めていく。
とはいえ見落としなどいくつかの躓きがあったのでメモ。
躓きポイント1
CentOSのadduserはuseraddのエイリアスである。よってDebian系のadduserとは使えるオプションが違う。
useraddでgitという名前のユーザーを追加する場合は次の通り。
useradd -c "GitLab" git
躓きポイント2
nginx用の設定ファイルは
gitlab-recipesのこれを/etc/nginx/conf.d/gitlab.confとして書き込む。
さらに、/etc/nginx/conf.d/default.confと、/etc/nginx/conf.d/gitlab.confが重複するので、/etc/nginx/conf.d/default.confの中身を全てコメントアウトする。
躓きポイント3
そのままではnginxが/home/git以下にアクセス出来ないので、次のようにしてnginxをgitグループに加えることでアクセス権を与えるようにする。
usermod -G git nginx
ちなみに、アクセス出来ない時のエラーは以下のようにして確認できる。
tail -f /var/log/nginx/gitlab_error.log
躓きポイント4
アクセス権を適切に設定する。
chmod 710 /home/git
chmod 700 /home/git/.ssh
chmod 600 /home/git/.ssh/authorized_keys
git cloneやgit pushはssh経由で行われるが、関連するファイルやディレクトリのアクセス権を適切に設定しておかないとクライアントからのアクセス時にパスワード無しの鍵を登録しているにも関わらずパスワードの入力を求められ先に進めなくなる。
自分が犯した失敗は/home/gitのアクセス権が710以外になっていたのと、/home/git/.ssh/authorized_keysのモードが600以外になっていたことである。
特に/home/gitのグループアクセス権に実行権限のみを付けておくことは重要だ。この実行権限がないとwebからもgitからもアクセス出来なくなる。
設定を間違えたときのエラーの詳細はサーバー側で
tail -f /var/log/secure
としてログを眺めつつ、クライアントから
git clone git@servername:myrepo.git
などとすることで確認できる。
躓きポイント5 (2013.4.4追記)
インストール後にGitLabサーバーのFQDNを変えた場合への対応方法。
1. gitlab/config/gitlab.ymlの設定
gitlab:
host: 新しいFQDN
2.
Emails have incorrect URL in link to project の問題で配信されるメール中のリンクが変わらないので、gitlab/config/environments/production.rbに次の一文を追記。
config.action_mailer.default_url_options = { host: '新しいFQDN', port: 80 }
3. gitlab-shell/config.ymlのgitlab_urlの値の設定
gitlab_url: "http://新しいFQDN/"
4. 1〜3の対応をした上で、gitユーザーになってGitLabを再インストール
bundle install --deployment --without development test postgres
必須ではないかもしれないが、これを実行しないとgitlabサービスをリスタートした直後に配信されるメール中のURLが最初は新しく設定したURLになるものの、すぐに元に戻ってしまっていた。
想像だが非同期のタスクが動き出すとDB内の古い値でgitlabのスクリプト内の変数を書き換えてしまうのではないだろうか。
参考資料
gitlabhq / doc / install / installation.md
gitlab-recipes
GitLab 5.0 を CentOS 6.4 にインストールした
Linuxでマルチチャンネル録音がしたくなりUSBオーディオインターフェースをいくつか検討した結果、ついに手頃な物を見つけた。