2012/11/05

【解決】GitLabでGit HTTPが使えない問題 (※サブディレクトリ環境)

昨日に引き続き、GitLabの話です。
GitLab 2.7から"Git HTTP"(Git Smart-HTTP)が実装されていたのですが、

いつもはSSH経由で利用しているため、これまでは使っていませんでした。
(※ Git HTTP = HTTP経由でGitLabを通してリポジトリにアクセスする機能)

さて...今日はこのGit HTTP機能をいざ使ってみようと...

GitLab3.0の画面。[SSH]ボタンと並んだ [HTTPS]ボタンをクリックすると
Git HTTPによるURLが表示される。
(URLは、プロジェクトの通常のURLに".git"を付加したものとなる)
表示されたURLをブラウザから開いてみる...と...
回やっても認証画面がwww

正しいメールアドレス+パスワードを入力しているのに
401エラーが出るという・・・(汗;)w

ところで。GitLabでは、サブディレクトリ下での運用を本来サポートしていません。
ですので、私はリバースプロキシ(nginx)を通して少々無理やり運用しています。
(それについては、記事:Gitlabの導入 (Unicorn+nginxでサブディレクトリへ配置)を参照)

今回は恐らく、そのための問題なのだろう...と仮定して調べてみました。
(他の可能性としては、gitlab.ymlの設定ミスもありますが、今回は問題ありませんでした。)

→ 結果...その通り!やはりサブディレクトリ下で運用していることが問題なようですorz

とりあえず...手探りで試行錯誤してみましたので、
対策方法を以下に残しておきます。

[注意] GitLabのサブディレクトリでの運用が本来サポート外であるうえに、
私はいまのところ Ruby/Unicornに全く詳しくありませんww
そのため保障はできませんが、参考にまで。
...もっと良い方法があればアドバイスお願いします m(_ _)m )





/gitlab/lib/gitlab/backend/grack_auth.rb : 17行目付近〜

@env['PATH_INFO'] = @request.path
@env['SCRIPT_NAME'] = ""

# Find project by PATH_INFO from env
#if m = /^\/([\w-]+).git/.match(@request.path_info).to_a #コメントアウト
if m = /^(\/([\w-]+))*?\.git/.match(@request.path_info).to_a
    self.project = Project.find_by_path(m.last)
    if m2 = /\/([\w-]+*?.git\/.*)/.match(@request.path).to_a
        @env['PATH_INFO'] = "/#{m2.last}"
    end
    return false unless project
end

変更点としてはこれくらいです。



以下に、何を行ったかの解説&メモを書いておきます。

まずGitLabでは、Grackというモジュールを用いることで
このGit HTTPを実現しているようです。
GitLabのルーター(/gitlab/config/routes.rb)はユーザからアクセスを受けると、
Git HTTPのためのアクセスをここで受け取ります。

Grackの認証(Basic認証)には、GitLab上のアカウント情報が用いられます。
実際にその処理を行なっているのは/gitlab/backend/grack_auth.rb ですね。


上のgrack_auth.rbでコメントアウトした行とその次行の
# if m = /^\/([\w-]+).git/.match(@request.path_info).to_a
    self.project = Project.find_by_path(m.last)
はリクエストされたパス(@request.path_info)からプロジェクト名を抜き出しています。
本来、パスが"/hoge.git/aaaa"だとしたら、
hogeという部分が正規表現で抜き出され、self.projectに代入されるわけです。

ただ当然これでは、パスがサブディレクトリを含んでいると正しく抜き出せないですね。

ですので...コメントアウトした行の代わりにこのように追加しました:
if m = /^(\/([\w-]+))*?\.git/.match(@request.path_info).to_a

これにより、サブディレクトリであっても正しくプロジェクト名が抜き出せます。

さて...この修正だけで、事態(?)には光が見えてきます(笑)w
プロジェクト名が正しく抜き出せなかったために、
プロジェクトを探せず、401エラーになっていたようです。

これでとりあえず、401エラーが改善し、認証は正常に通るようになります。

が...。

ここでまだ、git cloneしてもうまく行かないはず・・・。

Grackの認証が済むと...
プロジェクト名やパスを環境変数(@env)で渡して次の処理を
/gitlab/vendor/bundle/ruby/*.*.*/bundler/gems/grack-*/lib/grack/*.rb
が行うわけですが・・・。

ここでリポジトリ上のファイルを読み込む時・・・
サブディレクトリのせいでパスを正常に扱えず、ファイルが見つからないのですw
なのでエラーとなります。

この対策のために、前のステップでパスを直しておくことにしました。
先ほどとおなじくgrack_auth.rbでやってしまいましょうw

以上の理由から、先ほどの行の後に2行追加しました:

        if m2 = /\/([\w-]+*?.git\/.*)/.match(@request.path).to_a
                @env['PATH_INFO'] = "/#{m2.last}"

正規表現マッチもあれな書き方ですが、未だ詳しくないので許してください(><;)

これににより、環境変数に入れるパスからサブディレクトリ部分が削られます。
つまり、本来、GitLabが意図しているパスになるわけです(>ω<)♪

これで一応、解決です。

試しに...クライアントから
$ git clone https://example.com/git/hoge.git
を実行してみてください。正しくcloneできるはずです。

今回は以上となります。

今回もこのヒントを得るためにGitHubやコミュニティを参考にさせていただきました。
ありがとうございました m(_ _)m♪


p.s.

そもそもサブディレクトリじゃなくルートでGitLabを運用したらいいのに...
と思われる方もいらっしゃるかもしれません・・・。

私は学生個人でサーバを運用しています。
そしてこういったものに、HTTPSは必須だと考えております。
ところで、ルートディでGitLabを運用するには、当然、サブドメインなり別サーバ/IPアドレスなりの方法を取らなければなりませんが、
それをするとなると、サーバ証明書もGitLab用に別途用意することになります・・・。
サブドメインでも使える証明書は高価ですし・・・。
そこまでの余裕は無いのです(´・ω・`)...。

尚、GitLabはサブディレクトリへの対応を実装することは今のところないそうです。


2012/11/04

GitLab 2.8→3.0にバージョンアップ

前回の記事(Gitlab 2.7 → 2.8にバージョンアップ)から約2ヶ月...
9月末にGitLab 2.9が公開されていたんですが...
つい先月(10月)末に、GitLab 3.0が公開されたようです。
http://blog.gitlabhq.com/gitlab-3-dot-0-released/

とりあえず変更点を...(適当に翻訳しましたw)

2.9での変更点は以下の通り (公式ブログより抄訳)
  • 400コミット以上の素晴らしいコード
  • コメントの表示順を変更 (Wallを除く)
  • omniauthのサポート (twitter, google…)
  • Bunch of stuff の修正 (訳注: たくさんのモノ/諸々 とでも訳しておきますかw)
  • 多くのコードのリファクタリング
  • Gitolite v3への対応
  • 絵文字機能
  • LDAPとOAuth設定を一つに集約 -> config/gitlab.yml
  • ProfileとAdmin画面に新機能
  • 多くのAPIを追加

そして 3.0での変更点は以下の通り (こちらも公式ブログより抄訳)
  • 300コミット以上の素晴らしいコード
  • ウェブエディタ機能
  • より多くのAPIを追加
  • ファイルブラウザの改善
  • SSH鍵の追加と削除についての致命的な不具合修正
  • (非公式な) Postgreサポート
  • プロジェクトグループ機能
  • ファイルとコミットについてのパフォーマンスがかなーり改善
  • コードのリファクタリングとクリーンアップ など...
うーん。これは楽しみ!!
ということで、3.0へのバージョンアップを行いたいと思います(>ω<)

私の場合、2.9→3.0ではなく2.8→3.0のバージョンアップとなるため・・・
こちらのドキュメントを参考にしたいと思います:

https://github.com/gitlabhq/gitlabhq/wiki/From-2.6-to-3.0
(そうじゃなくてすでに2.9をお使いの方はこちらを参照)

毎度のことですが、更新はgit pullして取得できて楽ですね。
今回はそれに加えて、hooks(post-receive)の上書きと、
gitlab.ymlの再設定が必要になりました。
必要に応じて、バージョンアップ前にバックアップをとっておくといいかもしれません。
(さらに私の環境では、サブディレクトリで動作させる等々しているので殆ど前回同様に再設定が必要でした。)


GitLab 3.0にバージョンアップ完了

それにしてもGitLab、友人と一緒の開発に使っていますが...使いやすいですね。
(元々のアイデアであるGitHubもそうですけれど)
他のプロジェクト管理システムよりも色んなモノを削って、またGitに特化している分、
使いやすさがあるんだろうな〜と思います。

GitLab 2.9から追加された Issueでの+1 機能。
コメントを書く時、"+1"という文字を入れておくと、カウントしてくれます。
こういう機能も他のプロジェクト管理システムだとプラグインで使えたりしますが、
標準で実装されるのはちょっと嬉しいですねw
(尚、軽めにぼかし入れてますが、開発中のモノです。見えてもいいんですけど一応軽くw )
Trac,Redmine,etc...を使っていると、
欲を言えば、GitLabはモノ足りないかなーと思うことが無いこともないんですけど、
それでも...必要十分以上の機能は揃っているわけです。
毎日のように使うツールですから、”シンプル”であることは大切だと思います。
開発メンバーが増えたときの慣れやすさを考えてもそうですしね。