8.1.3. Configuring Apache with mod_wsgi

Using mod_wsgi is recommended over using mod_python. It's one of the faster and more efficient ways of serving hgweb(dir).

You can use the hgwebdir.wsgi script (it lives where other Mercurial scripts live, and works with Mercurial 1.0 and later), which references a hgwebdir.conf file in the CONFIG variable:

from mercurial.hgweb.hgweb_mod import hgweb
from mercurial.hgweb.hgwebdir_mod import hgwebdir

CONFIG = '/var/hg/public.config'
application = hgwebdir(CONFIG)

This is really an ordinary Python module, but it uses a wsgi extension to make it clear what its use is.

You then need to add this to your httpd.conf (or the vhost config):

WSGIScriptAlias / /var/hg/script/public.wsgi
<Directory /var/hg/script>
    Order deny,allow
    Allow from all
</Directory>

Since you're allowing some permissions to the directory the .wsgi script is in, you probably don't want to put the script in a directory that also contains your repositories.

NOTE: the default hgwebdir.wsgi uses 'hgweb.config' as configuration path. This may not be what you expect. If you find yourself with a working but empty installation, try to set this to the full path where your hgweb.config is situated

バーチャルホストの設定

lighttpd.conf に設定を追加します。先程書いた fastcgi.server = ( ... ) の部分は置き換えちゃってください。

"mod_rewrite" # コメントを解除する

$HTTP["host"] == "hg.example.com" {
  fastcgi.server = (
    "/hgwebdir" => (
      "hgwebdir" => (
        "socket" => "/opt/local/var/run/lighttpd/hgwebdir.sock",
        "bin-path" => "/var/www/fcgi/hgwebdir.fcgi",
        "check-local" => "disable"
      )
    )
  )

  url.rewrite-once = (
    "^/(.*)" => "/hgwebdir/$1"
  )
}

ここの設定が曲者で、/ の位置を間違えるとルートだけリンクが壊れるという不可解な現象で半日悩む羽目になります。sudo lighttpd restart を忘れずに。

上手く行けば http://hg.example.com/ でリポジトリ一覧が見られるようになっているはずです。

ダイジェスト認証の設定

現在 http 経由のコミットは全て弾く設定になっています。認証は lighttpd に任せるので、Mercurial 側のアクセス制限は取っ払ってやります。

% sudo mkdir /etc/mercurial
% sudo cat > /etc/mercurial/hgrc
[web]
push_ssl = false
allow_push = *
^C

続いてダイジェスト認証用のパスワードファイルを作成します。

% mkdir /var/www/auth
% htdigest -c /var/www/auth/hg_push.htdigest "repos" hoge
% sudo vi /opt/local/etc/lighttpd/lighttpd.conf

lighttpd.conf に設定を追加します。$HTTP["host"] == "hg.example.com" { ... } の部分は置き換えです。

"mod_access" # コメントを解除する

$HTTP["host"] == "hg.example.com" {
  fastcgi.server = (
    "/hgwebdir" => (
      "hgwebdir" => (
        "socket" => "/opt/local/var/run/lighttpd/hgwebdir.sock",
        "bin-path" => "/var/www/fcgi/hgwebdir.fcgi",
        "check-local" => "disable"
      )
    )
  )

  url.rewrite-once = (
    "^/(.*)" => "/hgwebdir/$1"
  )

  $HTTP["querystring"] =~ "cmd=unbundle" {
    auth.backend = "htdigest"
    auth.backend.htdigest.userfile = "/var/www/auth/hg_push.htdigest"

    auth.require = (
      "" => (
        "method" => "digest",
        "realm"  => "repos",
        "require" => "valid-user"
      )
    )
  }
}

wsgiの場合もURLはリライトして対応するのかな？

再度push

pushing to http://192.168.30.46/hg/
searching for changes
1 changesets found
abort: authorization failed
[command interrupted]

またエラー

# vi .hg/hgrc
[web]
push_ssl = false
allow_push = *

誰でもpushできるように設定。

再々度push

pushing to http://192.168.30.46/hg/
searching for changes
1 changesets found
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
[command completed successfully Mon Dec 07 13:31:03 2009]

今度は通った。

リポジトリの公開（http経由）

hg serveコマンドでhttpによるリポジトリの公開ができます。リポジトリ（.hg）のあるディレクトリで、hg serve　とコマンドを実行するだけです。デフォルトで8000ポート、ポート番号はコマンドラインオプション(-p)で指定できるようです。

ssl required

WindowsマシンからUNIX(Solaris)マシンへpushしたときに、"ssl required"エラーが発生しました。Mercurialのhg serveはデフォルトでSSLを使用するのですが、push側でSSLを使う設定が別途必要なようです。

なお、MercurialのFAQには、SSLを無効にする設定が記載されていました。リポジトリのhgrcファイルに以下を記述します。これはhttpサーバ側（pushされる側）のリポジトリ（.hg/hgrcなど）に記述します。

[web]
push_ssl = false

もし、下記のようなエラーが出る場合は、

*** failed to import extension hgext.hbisect: No module named hbisect
*** failed to import extension hgext.imerge: No module named imerge

などと出る場合は、以前にaptitudeで入れた古いMercurial(0.9相当)の設定が残っている可能性があります。(hbisect等相当は標準で組み込まれたみたいです)

その場合は、/etc/mercurial/hgrc.d/hgext.rc を修正して、
hgext.hbisect= と hgext.imerge= をコメントアウトしてやればいいみたいです。
例：

sudo vim /etc/mercurial/hgrc.d/hgext.rc

hgext.rc にて、

# Dichotomic search in the DAG of changesets
# add the 'bisect' command
#hgext.hbisect=

 :

# lets you split a merge into pieces
# add the 'imerge' command
#hgext.imerge=

The Big Idea

The Hg-Git plugin can convert commits/changesets losslessly from one system to another, so you can push via a Mercurial repository and another Mercurial client can pull it and their changeset node ids will be identical - Mercurial data does not get lost in translation.

It is intended that Hg users may wish to use this to collaborate even if no Git users are involved in the project, as it may provide some advantages if you're using Bookmarks (it will transfer bookmarks on push, which Mercurial doesn't do).

今度はぐぐっても発見できない。って、素直に付属のドキュメント見ればいいやんけ、と自己突っ込みしながらdoc/hgrc.5.htmlを眺める。pushを許可するには以下の設定が必要らしい。

[web]
allow_push = *

8.1.3. Configuring Apache with mod_wsgi

Using mod_wsgi is recommended over using mod_python. It's one of the faster and more efficient ways of serving hgweb(dir).

You can use the hgwebdir.wsgi script (it lives where other Mercurial scripts live, and works with Mercurial 1.0 and later), which references a hgwebdir.conf file in the CONFIG variable:

from mercurial.hgweb.hgweb_mod import hgweb
from mercurial.hgweb.hgwebdir_mod import hgwebdir

CONFIG = '/var/hg/public.config'
application = hgwebdir(CONFIG)

This is really an ordinary Python module, but it uses a wsgi extension to make it clear what its use is.

You then need to add this to your httpd.conf (or the vhost config):

WSGIScriptAlias / /var/hg/script/public.wsgi
<Directory /var/hg/script>
    Order deny,allow
    Allow from all
</Directory>

Since you're allowing some permissions to the directory the .wsgi script is in, you probably don't want to put the script in a directory that also contains your repositories.

　分散バージョン管理システムを利用した場合でも、成果物を共有するよりどころとして中央リポジトリは必要となります。現時点では、中央リポジトリとしてSVNを利用し、各自の作業を行うローカルリポジトリに分散バージョン管理システムを利用するのがベストだと筆者は考えています。各自のローカルリポジトリを管理するツールを変更するのであれば、中央リポジトリへは影響を与えないので、後々ツールを変更してもオーバーヘッドにはなりません。