Настраиваем раздачу множества 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. К сожалению, сейчас нет настроения описывать проблему. Могу лишь сказать, что в вышеуказанном конфиге она есть :-) Усё. Конец.
Add post to:   Delicious Reddit Slashdot Digg Technorati Google
Make comment

Comments

Можно не перечислять репо по одному в [paths], а в [collections] описать путь к дире с репозиториями. В этом случае при добавлении репо не нужно править конфиг.

Что-то типа

[collections]
/web/mercurial/repos = /web/mercurial/repos

У меня в каталоге /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 )

Ну, я так и делаю. :)

Required. 30 chars of fewer.

Required.

captcha image Please, enter symbols, which you see on the image