Бизнес-ланч

Почитал злоключения tema'ы Лебедева. Поразмышлял о том, как устроено питание в нашем районе, и решил все обстоятельно описать. Итак, мы находимся в забытом богом уголке суши, известном также как Марьино. Несмотря на то, что людей здесь вроде как нет, и быть не может, обилие ресторанчиков, кафешек, саун и клубов различной направленности не может не удивлять. Чувствуешь себя рублевским бомжом. В данном случае - марьинским. Здесь идет вполне реальная борьба за клиента. Притом не совсем понятен смысл, так как по-моему мнению бизнес-ланч не может быть рентабельным. Но наверно я не знаю всей кухни (и слава роботам, что не знаю). Итак, представляем участников нашего забега (названия намеренно изменены до неузнаваемости):

"101 жаркая марьинская ночь" - в это заведение я бы никогда не заглянул, но мои более небрезгливые коллеги все же пару раз туда сходили, когда хозяева вывесили гордый транспарант про бизнес-ланч. На деле инфраструктуры бизнес-ланча нет, посетителей тоже нет, поэтому пищи готовой тоже нет. По ощущениям, скармливают то, чем кормят обслугу. Особых претензий к еде нет, просто она начиная от первого до второго с салатом идентична по вкусу и содержанию. Ходить мы туда перестали после того, как очередная трапеза сопровождалась допросом с понятыми некоего посетителя данного заведения, который не удержался, и пырнул кого то ножичком. Итоговая оценка - 3.

"Аля барокка" - почти что самое близкое к нам заведение. Пользуемся им как резервом, если не работают по каким-либо причинам другие места. Нельзя сказать, что этим все сказано, так как это было бы не совсем справедливо. Не так давно (по меркам медленной и нерасторопной марьинской жизни) в заведении сменился хозяин, и мы даже первое время ходили и радовались переменам. Но главный недостаток - цена, на 10% выше, чем в других местах. В бизнес-ланче каждая копейка на счету, и потраченное время. Т.е. это должна быть быстрая, в меру вкусная, и недорогая еда. 10% и на 5 минут дольше обслуживание - и мы идем уже чуть дальше. Итоговая оценка - 4.

"Созвездие" - пару лет назад мы впервые посетили это заведение. Налаженный технический процесс, умеренная ценовая политика. Попытки измениться в лучшую сторону. Все это создает ощущение спокойствия. Цены за это время выросли в 2 раза, но все равно - лучшее соотношение цена/качество среди участвующих и неучаствующих (а их у нас действительно много). Официанты всегда вежливые, персонал дружелюбный. За все время только один случай отравления (что-то не так было с окрошкой). Это действительно долгий положительный опыт. Итог - 5.

Что интересно, и характерно - здесь каждый день (ну с учетом протяженности марьинских дней) что-то меняется, клиентов немного и за них идет борьба. Как бы это ни странно звучало. Сравнивая с другим местом наших пищевых прогулок, Владыкино, которое расположено в гостиничном комплексе (т.е. вроде как само расположение обязывает кормить всех вкусно), марьинское изобилие и качество услуг просто поражают.

К сожалению, сейчас политика сводится к тому, что марьинский офис прикроют, а значит - прикроется и питание в марьинском общепите. Что очень печально. И придется жрать в какой нибудь аля-лебедевской тошниловке и задорого.

ЮАР: А судьи кто?

Чемпионат поражает уровнем судейства, такого даже в местных чемпионатах не увидишь, а тут - в каждом матче примеры полнейшей некомпетентности.

Итальянцам пора паковать чемоданы. С такой игрой можно забыть о финале.

Французы ищут внутреннего врага. Неспортивному поведению не может быть оправдания. Так же, как и неубедительной игре.

Судя по всему, после группового этапа может подобраться на редкость скучный состав участников. Для меня это очень печально, так как мой личный интерес к футболу получит серьезный удар.

Одно радует, великая сила футбола берет свое, все обезьянки отфильтровались. Может быть хоть вувузел будет поменьше. Потому что смотреть на кривляния мартышек, из-за которых страдают замечательные игроки уже порядком надоело.

Публикация репозиториев 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, и о последнем можно будет забыть. С чем я себя и поздравляю.

Футбол: первые матчи, первые впечатления.

Прошли первые два дня чемпионата. Потрясающие эмоции, которые дает футбол. Маленький смешной Марадонна, руководящий великолепной сборной Аргентины. Чопорный Бэкхем, чем-то похожий на Зверева. Судьи, которых непонятно зачем выпустили на поле. Неплохая игра хозяев чемпионата. Пока у меня не было ни одного разочарования. Отчаянные уругвайцы, схватившиеся с напыщенными французами. Наказанные футболом мексиканцы. Глупейший гол американцев. Все вписывается в футбольную мозаику.

На выходные уехал на дачу, и обычная экономия траффика была забыта, смотрел субботние матчи по sportbox через skylink-модем. Ушло где-то 400 метров трафика, но оно того естественно стоило. Skylink вытянул трансляции и я почти ничего не пропустил.

Оле Оле Оле!!!

Зависимости между службами в Gentoo: наводим порядок в net.ppp0, nginx и xdm/gdm

В gentoo иногда сталкиваешься с неприятными моментами в старте сервисов. После отключения hal, перестал стартовать xdm, так как dbus стартовал пойзже. А nginx стартовал раньше apache2 (что вообщем-то не так важно), но еще и хотел директории /var/tmp/nginx, а /var/tmp у меня - это раздел в памяти. Если отваливался net.ppp0, то останавливались все сетевые сервисы, хотя локальная сеть и вайфай вполне себе продолжали работать. Вообщем, так дальше жить было нельзя.

Первым делом идем в /etc/rc.conf и ставим:

rc_depend_strict="NO"

Тем самым мы говорим, что достаточно хотя бы одного поставщика net, а не всех сразу. Это решает проблему с net.ppp0.

Дальше, я добавил сервис для создания каталога для nginx, и для установки некоторого порядка в старте, у меня этот файлик я назвал /etc/init.d/kilork и выглядит он так:

#!/sbin/runscript

description="kilork"

depend()
{
 after apache2
 after dbus
}

start()
{
 ebegin "Starting local"

 mkdir /var/tmp/nginx

 eend $? "Failed to start local"
}

stop()
{
 ebegin "Stopping local"

 eend $? "Failed to stop local"
}

Здесь мы говорим, что запускаемся после apache2 (для nginx) и после dbus (для gdm).

Добавляем в сервисы в default (у меня они там все кучей):

rc-config add kilork default

Теперь создаем или правим настройки по порядку старта для nginx и xdm:

kilork@phoenix ~ $ cat /etc/conf.d/nginx 
rc_after="kilork"

kilork@phoenix ~ $ cat /etc/conf.d/xdm
CHECKVT=7
DISPLAYMANAGER="gdm"
rc_after="kilork"

В обоих скриптах добавляется строчка rc_after="kilork", которая говорит, что запускаемся мы после старта сервиса kilork.

Вот теперь вроде все замечательно стартует, ничто не отваливается и все поднимается когда надо. Буду смотреть, насколько рабоче решение, до этого я пользовался парочкой дурацких скриптов, которые смотрели, висит ли соединение, после чего переподнимали все сервисы, но это было естественно неправильно.

К слову сказать, для целей, под которые я сделал kilork - есть стандартный local, но вот только у него стоит "after *", что немного идет в разрез с тем, что мне надо запустить после него gdm и nginx. Поэтому вот так.

Программа лояльности

Так как меня все же кто-то читает в rss, в рамках программы лояльности - отключаю рекламу, хватит кормить Google.

Готовимся к чемпионату миру по футболу

Пришла пора определиться с чемпионатом мира. Для меня тут все достаточно просто, я болею за итальянцев и аргентинцев. За первых исторически, а за вторых - хочу посмотреть, как голый тренер их будет бегать.