Настраиваем раздачу множества mercurial репозиториев через fastcgi
Я уже писал раньше про то, как сделать веб-доступ к меркуриал репозиториям через fastcgi, но там было несколько извращённое решение, для того чтобы привязывать репозитории к корням доменов/поддоменов, а не к каталагам на одном домене. Сейчас же я расскажу именно про привязку к разным директориям т.е. про функциональность которая доступна из коробки без всяких извращений.
Итак, для начала нам понадобится написать простенький скрипт-обёртку, который будет через fastcgi (посредством flup) связывать с веб-сервером wsgi-приложение, идущее в поставке меркуриала, для раздачи репозиториев.
Скрипт очень простой:
#!/usr/bin/env python
import sys
from mercurial.hgweb.hgwebdir_mod import hgwebdir
from mercurial.hgweb.request import wsgiapplication
from flup.server.fcgi import WSGIServer
def make_web_app():
return hgwebdir('/web/hgwebdir.conf')
WSGIServer(wsgiapplication(make_web_app),
umask=0000,
bindAddress='/var/run/www/hg.pydev.ru.sock').run()
Этот скрипт запускает wsgi-приложение и с помощью flup обрабатывает fastcgi-запросы веб-сервера через указанный сокет. Обратите внимание на файл hgwebdir.conf, в котором лежат указания, какие репозитории можно раздавать, а какие нет. Мой файл выглядит так:
[paths]
django-account = /web/django-account
django-captcha = /web/django-captcha
django-auth-openid = /web/django-auth-openid
django-flash = /web/django-flash
Это значит, что по адресу http://somedomain.com/django-account мы сможем получить доступ к веб-интерфейсу для работы с репозиторием, лежащим в /web/django-account. Ну, и, конечно, hg clone может также работать с этим адресом.
Учтите, этот файл нужно запустить. lighttpd умеет запускать fcgi-скрипты сам, nginx (который я юзаю) не умеет. Поэтому я не мудрствуя лукаво просто выполняю в консоли следующую команду
nohup ./hgwebdir.py &
Конечно, со стороны веб-сервера надо тоже сделать кой-какие телодвижения ;-)
Вот мой nginx-конфиг:
server {
server_name .hg.pydev.ru;
include fastcgi.conf;
location / {
auth_basic "closed site";
limit_except GET {
auth_basic_user_file /web/hg.passwd;
}
fastcgi_pass unix:/var/run/www/hg.pydev.ru.sock;
}
}
Кстати — позор на мою голову — я до сих пор не решил проблему прикручивания http-авторизации для того, чтобы позволить push’ить через http. К сожалению, сейчас нет настроения описывать проблему. Могу лишь сказать, что в вышеуказанном конфиге она есть :-)
Усё. Конец.





Comments
Можно не перечислять репо по одному в [paths], а в [collections] описать путь к дире с репозиториями. В этом случае при добавлении репо не нужно править конфиг.
Что-то типа
У меня в каталоге /web/ уйма репозиториев. Они все попадут в веб-интерфейс? Это не true :-)
Хе-хе. Вот не труъ как раз иметь в одной директории кучу репов, часть из которых публична, а часть нет. Лучше сделать что-нибудь вроде
/web/repos/privateи/web/repos/public. И push’ить из/web/repos/private/fooв/web/repos/public/fooкогда надо :)Всё IMHO, конечно же. Лично у меня публичные репо просто лежат у хостера в
~/mercurial/repos/и я push’у в них через ssh://FastCGI — не нужно %)
насамом деле, есть mod_wsgi — универсатльное средство для питона
Как обстоит дело с mod_wsgi в nginx? Ничего не глючит, не лагает, не ликает, нет проблем с безопасностью, можно уже использовать?
Он имел в виду Apache.
Я понял, тока вот я писал в заметке, что юзаю nginx. Не проксировать же мне каждый wsgi-пук через апачи с егоным mod_wsgi )
Ну, я так и делаю. :)