そのため、私はFreeBSDに特化しており、Linuxがあまり得意ではありませんでした。 そして、Apache httpdの代わりにNginxを使用できる場所を好みます。 そのため、無制限の数のリポジトリを保存できる統合アーキテクチャを自分で作成し、このプラットフォーム上の異なるグループの人々へのアクセスを区別することにしました。
もちろん、Bitbucketがすべてです。 しかし、開発者は私が公開したくないプロジェクトを閉じています。 もちろん、25のプロジェクトをbitbucketでホストする機会に対して月額50ドルを支払うことができます。 個人的には、このお金を専用サーバーに費やして、好きなだけプロジェクトを調達する方が良いと思います。 それはそれほど便利ではありませんが、それ自体で、チューニング、バックアップ、およびその他の利点があります。
問題の声明
Web経由でアクセスできるMercurialリポジトリのリポジトリが必要です。 アクセス権は、特定のユーザーに対して読み取り/書き込みを指定する必要があります。
特定のポイント
- リポジトリはディレクトリ/ usr / home / www / repos /に保存する必要があります
- Mercurial設定は/ usr / home / www / repos / cgi /に保存されます
- ホスティングはローカルサーバーで行われます。 したがって、アクセスはhttp経由のみです。 外部では、httpsを介したアクセスもnginxに基づく別のサーバーによって処理され、ローカルポート80に転送されます。
- サーバーがdev.example.comと呼ばれているとしましょう。 リポジトリのリストは、次の場所にあります。
http://dev.example.com/hg/
前提条件のインストール
複数のリポジトリの展開の詳細については、 公式ページをご覧ください 。 これを行うには、cgi hgwebdir.cgiスクリプトを使用します。 もちろん、hgwebdir.fcgiのFastCGIバージョンを使用します。
Mercurialには、必要なポートで実行できる自己完結型のFastCGIサーバーは含まれていません。 hgwebdir.fcgiは、apache httpdまたはlighttpdによって起動されることを前提としています。 この問題を解決するには、fastcgiラッパーspawn-fcgiを使用します。
したがって、まず、次のポートをインストールします
- www / spawn-fcgi
- 開発/水銀
- www / nginx
- www / py-flup
hgwebdirをカスタマイズする
デフォルトのスクリプトを設定ディレクトリにコピーします
sudo -u www mkdir /usr/home/www/cgi/
cp /usr/local/share/mercurial/www/hgwebdir.fcgi /usr/home/www/cgi/
hgwebdir.fcgiを編集します。 私にはこんな感じ
#!/usr/bin/env python
from mercurial import demandimport; demandimport.enable()
from mercurial.hgweb.hgwebdir_mod import hgwebdir
from flup.server.fcgi import WSGIServer
WSGIServer(hgwebdir('/usr/home/www/cgi/hgweb.config')).run()
次に、構成ファイル/usr/home/www/cgi/hgweb.configで、コレクションへのパスとアドレス設定を指定します
[collections]
/usr/home/www/repos = /usr/home/www/repos
[web]
baseurl = /hg
baseurlパラメーターは、hgwebdirが生成するすべてのリンクにパスの先頭に/ hgが含まれることを示します(dev.example.com/hg/リポジトリーにアクセスできるアドレスがあることを思い出してください)
spawn-fcgiを構成する
FreeBSD構成ファイル/etc/rc.confで、次の行を追加します
# Mercurial
spawn_fcgi_enable="YES"
spawn_fcgi_app="/usr/local/bin/python"
spawn_fcgi_app_args="/usr/home/www/cgi/hgwebdir.fcgi"
spawn_fcgi_pidfile="/var/run/hg.pid"
spawn_fcgi_bindsocket="/var/run/hg.socket"
スクリプト自体をpythonインタープリターへのパスではなく、spawn_fcgi_appとして指定できます。 しかし、その後、サービスは正しく停止しません。 システムスクリプトはhgwebdir.fcgiというプロセスを探して停止しますが、実際にはプロセスはpythonと呼ばれます。 hgwebdir.fcgiは、インタープリターを使用して実行されるプログラムです。
これでデーモンを実行できます
sudo /usr/local/etc/rc.d/spawn-fcgi start
nginxを構成する
構成ファイル/usr/local/etc/nginx/nginx.confで、次の内容の新しいサーバーセクションを作成します
サーバー{ 80を聞きます。 server_name dev.example.com; set_real_ip_from 172.16.224.1; real_ip_header X-Forwarded-For; 場所/ { root / usr / local / www / nginx; index index.html index.htm; } 場所/ hg { if($ uri〜/hg(/.*)$){ set $ path $ 1; } client_max_body_size 100M; fastcgi_pass unix:/var/run/hg.socket; fastcgi_paramsを含めます。 fastcgi_param PATH_INFO $ path; fastcgi_param REMOTE_USER $ remote_user; auth_basic "Mercurialリポジトリ"; auth_basic_user_file hg_htpasswd; } }
この時点で、非常に注意してください。 Nginxはデフォルトでは、mercurialでの正しい動作に必要な変数を設定しません。 したがって、各行の意味を説明しようとします。 彼らは、水銀の源を研究することによって私に与えられました:)
set_real_ip_from 、 real_ip_header-上で述べたように、外部httpsアクセスは、 世界を覗き込むサーバー上にある別個のnginxによって提供されます。 ローカルサーバーでクライアントの実際のアドレスがログに到達し、リクエストをプロキシするこの外部サーバーのアドレスではなく、これらのディレクティブが追加されました。
ifブロックとPATH_INFO変数-アクセスされているリポジトリを判別するために、hgwebdirはPATH_INFO変数を使用します。 パス/ hgの先頭をカットする必要があります、なぜなら そうでない場合、hgwebdirは、「hg」という名前でリポジトリにアクセスしようとしていると判断します。 ここでは、インターネット上のいくつかのマニュアルで言及されているように、PATH_INFOを計算するために、注意して、$ request_uriではなくnginxの$ uri変数を使用する必要があります。 なぜなら $ request_uriには、パスに加えて$ argsも含まれています。 PATH_INFOに渡すと、リポジトリを操作しようとしたときに404 Not Foundを受け取ります。
client_max_body_size-デフォルトでは、nginxへのリクエストの最大長は1Mです。 当然、1M以上変更をコミットしようとしたり、大きなリポジトリを最初にプッシュしようとすると、リクエストは失敗します。 したがって、このサイズは100Mに増加します。 ほとんどの場合、これで十分だと思います。
fastcgi_paramsを含める-QUERY_STRINGなどの他の標準変数を接続します
REMOTE_USER-この変数では、hgwebdirはユーザー名を取得することを想定しています。
さて、最後の2行-HTTP基本認証の許可の設定。
すべて、nginx.confのhgに関連しない他のパラメーター(ログの保存場所など)を修正し、Webサーバーを起動できるようになりました。
nginx_enable="YES"
を/etc/rc.confに追加し、
sudo /usr/local/etc/rc.d/nginx start
を実行します
リポジトリ作成の例
これで、最初のリポジトリを作成する準備が整いました。 すべてはユーザーwwwから行われます。なぜなら、 nginxとhgwebdirが動作するのは彼の下であり、このディレクトリへの書き込み権限が必要です。 テストリポジトリを作成しましょう。 ユーザーuser1に読み取り権限を付与し、user2に読み取り/書き込み権限を付与します。
#
cd /usr/home/www/repos
#
sudo -u www hg init test
# nginx
# -c -
# htpasswd - www/apache22
sudo htpasswd -b -c /usr/local/etc/nginx/hg_htpasswd user1 pass1
sudo htpasswd -b /usr/local/etc/nginx/hg_htpasswd user2 pass2
test / .hg / hgrcを編集して、次のようにします
[web]
# ssl, nginx
push_ssl = False
allow_push = user2
allow_read = user1,user2
完了、アクセスを確認できます。
結論の代わりに
SubversionからMercurialへの一般的な移行に加えて、tracではなくredmineを熱心に見ています。 ユーザー自身がプロジェクトを登録して作成できるというアイデアが気に入りました。 残念ながら、作成したプロジェクトのhgリポジトリを自動的に作成する方法に関する既製のソリューションは見つかりませんでした。 さらに、この記事で説明されているアクセス権のクローンを作成します。 誰かが知っていれば-私は参照に感謝します。 いずれにせよ、私は近い将来、redmineのプラグインを作成するか、より異なる/正しい方法でこの問題を解決するつもりです。
この記事が気に入り、続編をご覧になりたい場合は、フィードバックをお寄せください。 次に、新しい環境とredmineの統合に関する新しい知識を共有します。