Apache + Subversion все

Остановил apache. Долгие годы он служил верой и правдой, никогда не пытался в нем разобраться, он просто работал в достаточном для меня объеме. Теперь пришло время отправиться на покой.

И subversion. Ему тоже пришлось уйти с арены.

Новые времена - новый гемморой. Обожаю перемены...

Публикация репозиториев mercurial через связку nginx + uwsgi

В процесс развития инфраструктуры домашнего сервера решил перейти со связки
apache + subversion на более интересный вариант с nginx + mercurial. Покопался в сети и не нашел интересного мне варианта на uwsgi, поэтому разбирался сам. Результат естественно публикую для пользы коммунити.

1. Постановка задачи

Надо обеспечить web-доступ к репозиторию mercurial. Требуется иметь две схемы доступа, приватную и публичную. Приватная требует авторизации пользователя на чтение и запись, публичная - только на запись. Работать должно через nginx и uwsgi.

2. Решение

Я не рассматриваю установку nginx, uwsgi и mercurial. Предполагается, что они установлены и собраны в нужной конфигурации (т.е. nginx собран с модулем для uwsgi). Будем рассматривать только процесс настройки. Хост система у меня gentoo, кое что относится только к этому дистрибутиву, большая же часть полезна всем.

По пунктам:
1. Создание выделенного пользователя для mercurial и репозиториев под ним, запуск через uwsgi;
2. Подключение uwsgi в nginx;
3. Настройка доступа;
4. Создание сервиса для запуска uwsgi средствами gentoo.

2.1. Создание выделенного пользователя для mercurial и репозиториев под ним

В качестве базы я пользовался материалом отсюда.

Создаем пользователя:

sudo useradd --home-dir /home/hg -m hg

Директории:

sudo -u hg mkdir -p /home/hg/repos/{private,public}

Права:

sudo chmod u=rwx,g=rwx,o= -R /home/hg

Информация о пользователе и настройки push:

sudo su - hg
echo -e "[ui]\nusername = kilork.org \n[web]\nallow_push = *\npush_ssl = false" > ~/.hgrc

Создаем конфигурации для коллекций репозиториев (все еще из под пользователя hg):

echo -e "[collections]\n/home/hg/repos/public = /home/hg/repos/public" > /home/hg/public.config
echo -e "[collections]\n/home/hg/repos/private = /home/hg/repos/private" > /home/hg/private.config

Теперь создаем wsgi-запускалки (за образец я беру пример из поставки mercurial, и заменяю там config):

echo -e "from mercurial import demandimport; demandimport.enable()\nfrom mercurial.hgweb.hgwebdir_mod import hgwebdir\n\napplication = hgwebdir('public.config')" > /home/hg/public.py
echo -e "from mercurial import demandimport; demandimport.enable()\nfrom mercurial.hgweb.hgwebdir_mod import hgwebdir\n\napplication = hgwebdir('private.config')" > /home/hg/private.py

Все готово к запуску uwsgi (все еще под пользователем hg):

uwsgi -s /tmp/uwsgi.sock -C -m -M

Запускаем без указания модуля, модули будут загружаться динамически соответствующей директивой в конфигурации nginx.

2.2. Подключение uwsgi в nginx

Идем в /etc/nginx и правим через sudo или под root.

В /etc/nginx/nginx.conf прописываем upstream для uwsgi:

upstream uwsgicluster {
  server unix:///tmp/uwsgi.sock;
}

Затем в нужном нам server добавляем обработчики location для uwsgi, например так:

server {
  listen localhost;
  server_name localhost;
  location /public {
    uwsgi_pass uwsgicluster;
    include uwsgi_params;
    uwsgi_param SCRIPT_NAME /public;
    uwsgi_param UWSGI_SCRIPT public;
    uwsgi_modifier1 30;
  }
  location /private {
    uwsgi_pass uwsgicluster;
    include uwsgi_params;
    uwsgi_param SCRIPT_NAME /private;
    uwsgi_param UWSGI_SCRIPT private;
    uwsgi_modifier1 30;
  }
}

Перезапускаем nginx. Заходим в браузер по одному из адресов http://localhost/public или http://localhost/private и убеждаемся, что нигде не ошиблись.

Осталось настроить доступ.

2.3. Настройка доступа

До этого мы настроили сервер в localhost с полным доступом, теперь цепляемся к внешнему адресу (kilork.org) с разграничением доступа:

server {
  listen kilork.org;
  server_name kilork.org www.kilork.org;
  location /public {
    limit_except GET {
      auth_basic "Restricted";
      auth_basic_user_file /etc/nginx/.hg.public.htpasswd;
      proxy_pass http://localhost;
    }
    uwsgi_pass uwsgicluster;
    include uwsgi_params;
    uwsgi_param SCRIPT_NAME /public;
    uwsgi_param UWSGI_SCRIPT public;
    uwsgi_modifier1 30;
  }
  location /private {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.hg.private.htpasswd;
    uwsgi_pass uwsgicluster;
    include uwsgi_params;
    uwsgi_param SCRIPT_NAME /private;
    uwsgi_param UWSGI_SCRIPT private;
    uwsgi_modifier1 30;
  }
}

Стоит отметить, что в случае public доступа конфигурация немного странная (приходится писать proxy_pass http://localhost). Для private добавляется только доступ. Либо тут мне не хватает познаний, либо это какая-то ошибка с передачей параметров при ограничении доступа.

Заводим пользователей:

sudo htpasswd -c /etc/nginx/.hg.public.htpasswd hguser
sudo htpasswd -c /etc/nginx/.hg.private.htpasswd hguser
sudo htpasswd /etc/nginx/.hg.private.htpasswd hguser2

Перезапускаем nginx. Проверяем.

Если все работает, то осталось только привести в порядок скрипты в gentoo, так как запускать руками сервер не сильно правильно.

2.4. Создание сервиса для запуска uwsgi средствами gentoo

Подозреваю, что скоро эта часть станет неактуальной и скрипт будет идти в составе ebuild'а. Но пока его нет, сделаем простейший скрипт для упрощения себе жизни.

Создаем исполняемый файл /etc/init.d/uwsgi_hg со следующим содержимым:

#!/sbin/runscript
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

depend() {
 need net
}

start() {
 ebegin "Start uwsgi for hg"
 cd /home/hg
 start-stop-daemon --start  \
  --exec /usr/bin/uwsgi -- --uid 1002 --pidfile /home/hg/uwsgi_hg.pid -s /tmp/uwsgi.sock -C -m -M -d /home/hg/uwsgi_hg.log
 eend $? "Failed to start uwsgi for hg"
}

stop() {
 ebegin "Stopping uwsgi for hg"
 if [ -f /home/hg/uwsgi_hg.pid ]; then
  pkill -9 uwsgi &> /dev/null
  rm /home/hg/uwsgi_hg.pid
 fi
 eend $? "Failed to stop uwsgi for hg"
}

1002 надо заменить на id пользователя hg. Пока скрипт ужасно грязный, как разберусь получше, или кто может поможет - улучшу обязательно.

Теперь мы можем спокойно стартовать, останавливать, добавлять в загрузку наш новый сервис:

sudo rc-config start uwsgi_hg
sudo rc-config stop uwsgi_hg
sudo rc-config add uwsgi_hg default

Осталось перенести статику на nginx, переписать парочку скриптов, которые взаимодействуют с subversion на apache, и о последнем можно будет забыть. С чем я себя и поздравляю.

Все говно, кроме мочи

В очередной раз нашел этому подтверждение в интервью с Brad Fitzpatrick: "...The implementation of libraries that look like they could be beatiful are shit...".

Очень точно подмечено. То что с виду кажется не г..., при ближайшем рассмотрении все равно оказывается им самым.

В эти выходные наконец таки реализовал скрипт для сборки нового ядра и почистки старых. Экономия нервных клеток на этой операции будет оценена не скоро, но думаю - будет приятно. Мне кажется, именно в этом суть программистского подхода к делу, все рутинные операции учить делать машину. Если мы делаем это больше чем один раз, это уже надо автоматизировать. Очередной пункт в личном todo-листе выполнен. Выложу тут и код этого сокровища в следующий раз. А пока оставшиеся пункты:
1. python-скрипт для заполнения ежедневных отчетов на работе
2. perl-скрипт Finance::Quote::Sberbank - исправить накопившиеся ошибки (есть 9-месячный багрепорт, а это ужасно)
3. локализовать openerp
4. lfs-нуть нетбук
5. найти или написать штуку для проверки торговой стратегии на архивных данных
6. написать собственно штуку для торговой стратегии
7. сделать информеры на svn репозитории в виде notify в gnome

И еще много чего, что мне хочется сделать. Каждый день я сижу где-то до 2-х часов ночи, стараясь сделать сегодня чуть-чуть больше чем вчера. И главное - ни один день не должен пройти без познания или создания чего-то нового. Это настоящее счастье - узнавать новое.

Эволюция

Занятно, еще вчера cvs был вполне неплох, потом пришел svn, а теперь каждая тварь считает своим долгом пользоваться git. Но ведь рано или поздно должен появиться действительно лучший?

Статистика и скука

Посмотрел свою статистику в svn с начала года. 6 (ШЕСТЬ) коммитов, около одного коммита в неделю. Размеры коммитов не больше 50 строчек, большинство 1-2.

Если пересчитать в у.е. за коммит, получится очень круто, хотя - у.е. за строчку будет тоже немало. Ну а что вы хотели, класс то растет, скоро даже мой взгляд на репозиторий будет стоить как текущая месячная зарплата.

При этом работы на самом деле сделано очень много. Но чужими руками, или результаты не попадают в svn (например, старые клиенты, для которых все еще используется PVCS).

В последнее время убеждаюсь, как хорошо быть хорошим программистом, и как плохо быть хорошим программистом и руководить людьми, с целью получить программный продукт. Если бы я был плохим программистом, меня бы так не трясло от всей ереси, которую приходится фильтровать. Поэтому наверно, менеджеры не должны уметь программировать, не чтобы получать более качественный продукт в заданные сроки, а совсем с другой целью, чтобы в мире не прибавлялось вселенского зла. Люди, утверждающие, что управление людьми интересное занятие - не искрени до безобразия. Это все равно, что шахтеры будут утверждать, что их работа легка и полезна для здоровья. Ну или уборщица, с радостью стирающая блевотину в подъезде. Утешение находится в том, что хоть какие-то вещи можно делать интересными и на такой позиции. И их немало, так что скуку удается побороть.