FastCGI в Lighttpd и Nginx

Сравнение настроек, приводящих к одинаковому результату в Lighttpd и Nginx.

Настройки Lighttpd:

url.rewrite-once += ( "^/testfc$" => "/testfc/", )

fastcgi.server += ( 
        "/testfc" => ((
                        "bin-path" => "/path/to/fcgi/server.py",
                        "socket" => socket_dir + "/viewvc.sock",
                        "max-procs" => 1,
                        "check-local" => "disable",
                        "fix-root-scriptname" => "enable",
        ))
)

Настройки Nginx:

location /testfc/ {
                fastcgi_pass unix:/path/to/fcgi/sock;
                fastcgi_split_path_info ^(/testfc)(.*)$;
                fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param  PATH_INFO $fastcgi_path_info;
                fastcgi_param  PATH_TRANSLATED $document_root$fastcgi_path_info;
                include        fastcgi_params;
        }

Nginx сам запускать приложения не умеет, поэтому об этом нужно заботиться заранее. Например можно использовать изысканное решение с помощью systemd.

Mercurial

Минимальная инфраструктура для работы с распределенной системой контроля версий Mercurial настраивается следующим образом.

Во-первых, нужно где-то разместить репозитории. Поскольку никаких других рекомендаций не поступало, по аналогии с cvs и svn будем класть все в /srv/hg/repos. Во-вторых, нужно обеспечить теперь доступ разным пользователям, которые счастливо существуют на компьютере и что-то там делают. Основная инструкция тут: http://mercurial.selenic.com/wiki/MultipleCommitters. Краткая инструкция: по аналогии с cvs и svn, создаем системную группу hg, системного пользователя hg, добавляем всех пользователей в группу hg.

Схема создания нового репозитория выглядит следующим образом:

cd repos/
mkdir test
chown -R hg:hg test
cd test/
hg init
chown -R hg:hg .hg
chmod -R g+w .hg
chmod g+s .hg .hg/store .hg/store/data

Mercurial >1.0 сам, о чудо, разбирается с правами доступа и делает так, чтобы все кому надо могли туда писать. Вообще говоря, данный подход (пулить всем вместе в один репозиторий) полностью противоречит идеологии hg.

В-третьих, никак не обойтись без веб-интерфейса. В /usr/share/doc/packages/mercurial живет пример под названием hgweb.cgi. Кладем его в /srv/hg/bin/hgweb.fcgi и меняем примерно следующим образом (чтобы через FastCGI работал):

#!/usr/bin/python

config = "/srv/hg/config"

from mercurial import demandimport; demandimport.enable()
from mercurial.hgweb import hgweb, wsgicgi
from flup.server import fcgi
application = hgweb(config)
fcgi.WSGIServer(application).run()

Конфигурация для lighttpd (обычно кладется куда-нибудь в /etc/lighttpd/vhosts.d/hgweb.conf):

fastcgi.server += (
        "/hg" => ((
                        "bin-path" => "/srv/hg/bin/hgweb.fcgi",
                        "socket" => socket_dir + "/hgweb.sock",
                        "max-procs" => 1,
                        "check-local" => "disable",
                        "fix-root-scriptname" => "enable",
        ))
)

Что писать в /srv/hg/config подсказывают в hg help hgweb:

[paths]
/ = /srv/hg/repos/*
/home/user = /home/user/hg/**

Последняя строчка для того, чтобы пользователям было не обидно, там они хранят свои личные репозитории. Вот только . Поля "Description" и "Contact" настраиваются в .hg/hgrc персонально для каждого репозитория. Кроме того, теперь через http возможно анонимное клонирование.

django + lighttpd

Как заставить вместе работать lighttpd и django. Готовый пример конфигурации, которую необходимо складывать в vhosts.d:

$SERVER["socket"] == "0.0.0.0:8888" {
        server.document-root = "/srv/www/django/htdocs"

        url.access-deny = ( "~", ".inc", ".svn/" )

        fastcgi.server = (
                "/dispatch.fcgi" => (
                "main" => (
                        "socket" => "/srv/www/django/run/fcgi.sock",
                        "bin-path" => "/srv/www/django/manage.py runfcgi --pythonpath=/srv/www/django --settings=djangoapp.settings-production method=threaded",
                        "max-procs" => 2,
                        "check-local" => "disable",
                        "fix-root-scriptname" => "enable",
                )
                ),
        )

        alias.url = ( "/static" => "/srv/www/django/htdocs", )

        url.rewrite-once = (
                "^(/static.*)$" => "$1",
                "^/favicon\.ico$" => "/static/favicon.ico",
                "^(/.*)$" => "/dispatch.fcgi$1"
        )
}

Предполагается, что проект лежит в /srv/www/django/, где для него существует рабочая версия настроек в файле settings-production.py. lighttpd сам запустит fcgi-сервер в количестве max-procs экземпляров. Опция check-local необходима для того, чтобы отключить проверку существования файлов на локальной машине, которую делает lighttpd; так как запрашиваемые URL существуют лишь в логике django, а не в файловой системе.

Для правильной работы тегов типа {% url %} необходимо добавить строчку FORCE_SCRIPT_NAME = '' в настройки проекта написанного на django, иначе ко всем ссылкам в начало будет добавляться название /dispatch.fcgi.