Сергей Ломаков, Simtech. «Использование key-value хранилища redis в боевых условиях».

Рассказал о юзкейсах редиса, об основных возможностях и опыте работы с ним. Редис достаточно простой и производительный, но в нем нет встроенных инструментов горизонтального масштабирования. Поддерживает хранимые процедуры на Lua (применяли ли их на практике не понял). Упомянул, что можно на основе редиса сделать простую MQ (массив и RPUSH + LPOP), есть возможности pub-sub. Довольно интересные способы сортировки с возможностью сохранить результат как отдельный ключ. Для персистентности существуют снепшоты (позволяют быстро запускаться с него, но работает на основе fork, т.е. возможен перерасход памяти) и append-only файл (снижает производительность, довольно медленный старт сервера). Довольно быстрая и устойчивая master-slave репликация. Посоветовал использовать 32-битную сборку для экономии памяти, запускать несколько экземпляров по числу ядер. Полезно разделять экземпляры по назначению (кому-то важна персистентность, например статистике, кому-то нет, напр. кеш).

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

Юрий Бушмелев, echo. «Облако в подсобке. Строим правильную локальную инфраструктуру».

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

Виртуализация серверов позволяет:

• Избавиться от зависимости от конкретного оборудования
• Запускать разные сервисы в разных VM
• Более эффективно использовать ресурсы (т.к. на одном хосте можно размещать одновременно виртуалки с разными профилями нагрузки (IO/процессор/память)
• упрощение бэкапов за счет снапшотов
• повышается отказоустойчивость

Для надежного и удобного хранения данных виртуальных машин нужно использовать «Системы хранения данных», в том числе для Live Migration между хост-серверами. Процесс роста такой:

1. Один сервер виртуализации
2. Несколько серверов виртуализации и СХД
3. Несколько серверов СХД для надежности

Системы виртуализации тоже не все одинаковые. Основные типы: автономная (не нужна ОС-хост, работает сразу на железе) и на основе хостовой ОС. Автономная лучше т.к. не требуется установка хостовой ОС.

Пример реального бюджетного облака: автономный или гибридный гипервизор, СХД из 2-х серверов с SCSI-failover и софт-raid, не брендовые сервера.

Основные тормоза — на дисковом IO.

От себя — не знаю есть ли реальный смысл поднимать собственные «облака на коленке» когда есть амазоны-ракспейсы-селектелы. Скорее всего оправданы когда нужны какие-то специальные условия или имеются особые требования.

Василий Сошников, SimbirSoft. «Кроссплатформенная разработка: Windows, Linux, MacOS,  iOS, Android»

Доклад читали 2 докладчика по очереди. Я не очень хорошо вник в суть, но кажется описывали опыт разработки мультиплатформенного софта на низкоуровневых языках (C++).

Структура такая: [бэкенд] <-> [Notification center] <->[фронтенд]. Важно разработать простой гибкий протокол для которого можно создать биндинг в C. Обсуждали какие-то Pimpl vs Factory, во время доклада попытался выяснить у соседей что такое pimpl — безуспешно) Отметили что важно, чтобы система сборки поддерживала командную строку и pipelining. Посоветовали иметь в проекте минимум внешних зависимостей для облегчения портирования. В качестве платформонезависимого способа передачи бинарных данных посоветовали Thrift или ProtocolBuffers.

Честно говоря, мало что понял из доклада, плюс по времени затянулся а мне нужно было из гостиницы съезжать, так что на вопросы/ответы даже не остался.

Дальше уже начинаются более интересные доклады… Хотел попасть на доклад Михаила Табунова про Backbone.JS, но из за затянувшегося доклада и гостинницы так на него и не попал. так что дальше идет

Константин Осипов, mail.ru. «Tarantool/Box 1.5. опыт оптимизации производительности NoSQL СУБД»

Tarantool — это т.н. Relaxed-relational база данных. Есть базы, есть таблицы, в них есть кортежи, часть из них описываются схемой, часть без схемы (фиксированная и нефиксированная части), есть btree и hash индексы (только на фиксированную часть, на нефиксированную появятся в след. версиях). Инкрементальное перестроение индексов/хешей. Отличается очень высокой производительностью и очень тесной интеграцией с Lua — на нем пишутся хранимые процедуры, есть множество процедур из коробки. Существуют упрощенный SQL интерфейс, собственный бинарный протокол и эмуляция Memcached протокола. При этом SQL интерфейс существует только на клиенте где сразу преобразуется в бинарный протокол. Основной «потребитель» — собственно Mail.ru. В tarantool хранятся сессии и данные о присутствии на сайте. Фактически — при каждом клике пользователя на проектах Mail.ru идет обращение к Tarantool. У mail.ru 20млн онлайн пользователей создают 100 тыс запросов к Tarantool в ссекунду. База работает на кластере из 2-х боевых серверов и 2-х реплик для надежности. На каждом сервере запущено по 2 копии tarantool и вполне справляется с нагрузкой.

В Tarantool нет транзакций, но операции атомарные, с записью на диск. Более-менее сложные вещи лучше реализовывать на хранимых процедурах.

На вопрос «чем вы лучше редиса» ответил, что у них более гибкие структуры данных, лучше интеграция с LUA, лучше организована работа с диском. Проблемы со сборщиком мусора в LUA решили.

От себя — судя по описанию, довольно интересная база с широкими возможностями, но у нее очень маленькое комьюнити и мало внешних проектов, использующих Tarantool. Создается впечатление, что автор не очень-то хочет/старается его (комьюнити) поддерживать. «Мне и так каждый день приходят советы как мне БД продвинуть, улучшить, пропиарить. Какой-то секс посреди красной площади получается». Ну что-ж, пожелаю удачи и развития, возможно найду время поковыряться.

Алексей Рыбак, badoo. «Архитектура badoo».

«Когда у вас в руках молоток, любая проблема кажется гвоздем»

Badoo — один из популярных на западе и в европе сайтов знакомств с командой разработки в России. У них 2000 серверов в 2-х датацентрах. Список используемых технологий очень короткий: Linux, Nginx,PHP, C, C++, MySQL с HandlerSocket, Memcached; есть немного MongoDB и немного Python, но их стараются выпилить О_о.

Значительная часть кода пишется как эксперимент, в случае чего можно безболезненно выкинуть. В badoo консервативны к выбору технологий и инструментов (очень!).

Для того чтобы выбрать в какой из датацентров «приземлить» пользователя используется GeoIP DNS.

Существует внутренний стандарт-соглашение что время сборки страничек не должно превышать 0.1 секунду. Сборка странички происходит синхронно в PHP, данные берутся из MySQL, C/C++ демонов,Memcached. Все обращения к другим серверам обернуты в таймеры (pinba). Для кеширования байткода PHP используют APC или eAccelerator. Создали и поддерживают шаблонизатор Blitz и менеджер процессов PHP-fpm. Логи ошибок собирают в Scribe.

Весь SQL — в коде приложения. Не используют триггеров/хранимых процедур и т.п. Используют только простые запросы, без view, без вложенных запросов, не используют  внешних ключей (вроде используют JOIN). Контроль целостности, как я понял, осуществляется тоже вручную в коде. Активно используют шардинг. Написана собственная система репликации шардов между ДЦ для MySQL. Используют параллельный апгрейд  схем таблиц на шардах. Используют транзакционные очереди (?). На серверах Memcached регулярно делают полный flush. Для шардинга ключей используют простой $i/n или crc32($s)/n. Активно используют время жизни ключей, используют prolongate для мемкеша (увеличение времени жизни при обращении к ключу). Есть система очередей в MySQL с периодическим поллингом в 20-30 секунд O_o (вроде так сделано чтобы использовать транзакции и с очередями в том числе). Какое-то время использовали RabbitMQ, но выпилили.

Для администрирования используют puppet и собственную библиотеку для PHP mssh (multi-ssh).

У меня этот доклад вызвал какой-то butthurt. Неужели оправданно так жестко подходить к выбору инструментов и, при возможности,  выпиливать »проявления вольности» некоторых разработчиков (Python, Mongo, RabbitMQ)? В чем проблема развести небольшой зоопарк не понимаю. Учитывая, что у них все-таки уже довольно большая команда и найти спецов по новым  технологиям не будет такой уж проблемой. Однозначно могу сказать, что в Badoo я бы работать не хотел… Возможно чего-то не понимаю конечно.

Лев Валкин, echo. «Инь и янь масштабированиия»

Шардинг! Шардинг! Шардинг!

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

Echo предоставляет огромным медийным и контентным западным площадкам и брендам различные социальные реалтайм социальные виджеты (комментарии, лайки, топы, голосования, шаринг и пр) плюс конструктор на основе этих виджетов и SQL — подобный язык запросов к платформе. Учитывая объемы траффика и данных, множество связей в сочетании с гибкостью платформы, получается довольно уникальная штука. 50 000 запросов в секунду, 200 серверов, куча реалтайма.

На докладе рассказал об Incident Command System — систему реагирования на внештатные ситуации, позаимствованную у пожарных: тот, кто первым обнаружил проблему становится ответственным за нее и руководит процессом «ремонта».

Затем некоторые размышления на тему программирования, когда лучше применять бесконечные очереди (RabbitMQ) а когда что-то простое (Nginx + воркеры). Рассказал, что в Echo активно используют фичи Erlang, например часто используют горячую замену кода прямо на production, но это несколько расслабляет программистов и они начинают этой возможностью злоупотреблять. Упомянул, что важно допускать остановку части серверов без потери работоспособности всей системы (устранять единые точки отказа).

Отдельно коснулся важности интроспекции и рассказал как с этим все хорошо в Эрланге. Помимо бенчмарков у них используются замеры с историей во времени чтобы наблюдать аномалии и отклонения.

Отдельно рассказал про продвинутую систему логгирования: при каждом запросе к их сервису в Erlang собираются все возможные данные и метрики и на лету анализируются и фильтруются. В среднем на каждый запрос может накопиться несколько десятков мегабайт такой отладочной информации. В случае необходимости эти данные логгируются на диск, иначе просто отбрасываются. Оверхед на такое логгирование существенный, от 5 до 30 процентов, но он размазывается по кластеру.

Значительная часть серверов живет в Amazon, но это дорого и часто встречаются аномалии и нестабильности, поэтому поддерживают и свою инфраструктуру в Colocation. В частности, все сервера баз данных свои. Главный плюс амазона — можно в случае необходимости быстро отмасштабироваться в 10 раз, но не более.

Языки разработки: в первую очередь Erlang и OCaml, так же используются Python, PHP, Haskell, C, Perl. В команде есть много хороших специалистов знающих по несколько языков. Так что выбирают язык если хорошо подходит для решения конкретных задач или есть какая-то хорошая библиотечка на нем.

Хоть и большая часть софта на Erlang, нанимают не Erlang-программистов, а просто хороших инженеров, в случае необходимости обучают Erlang-у в процессе работы.

От себя: хоть доклад был, на мой взгляд, немного несвязным, но тем не менее было весьма интересно. Радует, что не боятся новых технологий и «языкового зоопарка».

Кстати, после доклада, в кулуарах обсуждали проблемы с масштабированием, с которыми в Echo приходится сталкиваться: у них хранится сложная структура данных — социальный граф со множеством связей. А т.к. клиентам предоставляются гибкие средства работы с ним (EQL — SQL-подобный язык) то шардирование реализовать не получается, т.к. не ясно по какому критерию разбивать данные и Materialized View так же не подходит, т.к. приведет к копированию огромных количеств данных. Как с этим бороться — еще не придумали)

Ну вот и все, конференция закончена. Огромное спасибо всем, отдельно организаторам и докладчикам. Пожалуй, одна из лучших конференций на которых я побывал. Буду надеяться что мероприятие станет как минимум ежегодным и будет держать планку на уровне. А мне пора на поезд.

Теперь расскажу о докладах (в общем-то краткий пересказ докладов, много букв! Если нужны подробности — смотрите видео на сайте).

Илья Космодемьянский. «Теория и практика распределенных баз данных».

Свой доклад посвятил следующим темам:

• Области применения репликаций
• Транзакции, локальные и распределенные
• Очереди сообщений
• Materialized View

Довольно общий доклад, обзорный. Если кто-то планирует начать работать с распределенными БД (или неожиданно столкнулся с необходимостью с ними работать) будет полезен. Опять же, отличия подходов к работе с БД в локальном и распределенном случаях.

Роман Павлушко, avito.ru «Нагруженный поиск на Sphinx».

Доклад о том, как создавался и как поддерживается поиск на крупнейшем сайте объявлений в рунете Avito.ru. Докладчик в начале нервничал, но потом разошелся)

Изначальная архитектура сайта была завязана на базу данных. Использовались различные хранимые процедуры, кеш так же укладывался в базу, поиск был реализован на встроенном в PostgreSQL полнотекстовом индексе (tsearch). Когда же столкнулись с серьезными нагрузками, то начали максимально разгружать БД, упростили схему, вынесли кеш в In-memory базу а поиск перенесли в Sphinx.

На сайте Sphinx используется для 2-х вещей: непосредственно поиск и «похожие объявления» и эти 2 части генерируют большую часть траффика на сайте. Поиск обрабатывает около 140 млн запросов в сутки, размер индекса — 3Гб. В кластере 16 серверов и на всех серверах одинаковые индексы.

Каждые 20 минут запускается ПОЛНАЯ переиндексация, которая  длится 20 минут. Есть несколько различных индексов для разных целей + главный индекс. В качестве источника данных для индексации используют отдельную реплику базы данных, в которую реплицируют только нужные таблицы и Matreialized Views — ы только с активными объявлениями. При этом индексы строятся параллельно — просто через bash запускаются несколько экземпляров Sphinx indexer, каждый на свой индекс. После окончания процесса новые индексы разносятся по поисковым серверам с помощью uftp + rsync где запускается процедура ротации индексов.

Помимо фронтенда, Sphinx используют в бэкофисе, где успешно используют распределенный индекс.

Лайфхаки:

• не используют MVA ибо работает медленнее, для каждого параметра отдельный атрибут.
• при пагинации если offset > total_matches / 2 то сортируют результат в обратном порядке
• Индексы хранят в tmpfs (фактически в памяти).
• В качестве протокола общения используют SphinxQL.
• Не используют Live Update индексов, т.к. когда пробовали, получили быстрое снижение производительности, ну и нет необходимости.
• Стараются использовать Multi Query, ибо быстрее.
• Не один индекс! Разбивают индекс по  категориям на кусочки.

Меня впечатлило в этом докладе то, что использовали простые и, в каком-то смысле, наколенные решения. Ну и здорово, что реальный опыт, конкретные примеры, success story) Люблю такие доклады.

Макс Лапшин. «erlyvideo. Использование эрланг в видеостриминговом сервере».

Я сам уже достаточно давно интересуюсь этим языком и OTP платформой, почитываю книжечку, пишу HelloWorld-ы и думаю даже в будущем начать разрабатывать на нем. Python уже поднадоел, а другие языки не имеют принципиально ничего особенного.

Так вот, про доклад. В Java-подобных языках имеются проблемы с параллельным программированием: Stop The World сборщик мусора, проблемы с обработкой ошибок (утечка ресурсов, слишком много кода посвящено обработке ошибок). Ну и всякие синхронизации/дедлоки само собой.

В отличие от них, у Erlang совершенно другой подход. Для параллелизма и изоляции ошибок используются легковесные процессы, существующие только внутри Erlang VM и дающие очень маленький оверхед (можно запускать миллионы таких процессов на одной машине). Ссылки отсутствуют как таковые, все данные немутабельны. Ошибки не обрабатываются программистом, описывается только HappyPath, в случае возникновения ошибки падает только процесс-обработчик (освобождая свои ресурсы) и тут-же перезапускается процессом — супервизором. У каждого микропотока собственный сборщик мусора, который работает независимо от остальных (т.е. нет моментов, когда вся система целиком встает колом из за активации GC). Дополнительные плюшки:

• Обновление кода сервисов без перезапуска и без даунтайма
• Прозрачная работа в кластере (можно запустить микропроцесс и общаться с ним на удаленной машине точно так же как и на локальной)
• Встроенный в VM асинхронный IO с синхронным API (нет лапши из коллбеков).
• Удобная интроспекция работающей системы (можно удаленно подключиться к работающей системе и посмотреть где что происходит, какой процесс потребляет ресурсы и чем он именно занимается).
• Удобная работа с бинарными данными.
• Автоматическое распараллеливание по ядрам процессора.

Ну и конечно же упомянул проблемы Node.JS, спасибо, это всегда полезно)

Рассказал немного про удобство работы с видео-потоками в Erlang (долгоживущие соединения, неустойчивая внешняя среда, битые данные. ошибки). Легко поддерживать старый код, т.к. кода мало)

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

Александр Титов, skype. «Инженерный дзен. Непрерывные изменения»

Долгие релиз-циклы это потеря денег для компании и увеличение числа ошибок в продакшне. Нельзя допускать долгих релиз-циклов. Каждая новая фича — релиз, но с возможностью быстро откатиться в случае необходимости.

Инструментарий:

• Chef — основной инструмент. Управление конфигурацией серверов, инфраструктурой, одновременно и живая документация на инфраструктуру, версионирование.
• vagrant — удобная оболочка для virtualbox + DSL для эмуляции различных инфраструктур
• Юнит-тесты само собой
• Jenkins

«Проповедует» devops — т.е. когда разработчики являются одновременно и админами: «Уметь и софт написать и конфиг Nginx подправить».

Доклад понравился, нужно обдумать и посмотреть как сейчас в нашей организации это устроено. Возникла идея пригласить докладчика к нам на консультацию… еще посоветуюсь с руководством.

Лев Валкин в кулуарах.

Успел поспрашивать как в Echo используются фичи Erlang, так вот:

• Активно используют живое обновление кода
• Активно используют  Erlang-кластеризацию (межнодное взаимодействие). В кластер объединены не все сервера, а разбиты по группам.
• Используют message-passing без хаков
• Используют юнит-тесты и какую-то библиотеку для «фаззинга» (кажется QuickCheck)
• Часто тестируют код «на живую»-прямо на продакшне: «У нас 50 000 запросов в секунду, если и есть ошибка, то это проявляется сразу».
• Не используют dialyzer, но собираются начать.
• Для тяжелой математики используют OCaml

Лев Валкин, echo. «Ульяновск как яйцо силиконовой долины. Инкубация».

Единственный доклад не по программированию, который я посетил. Для начала предистория. Лев Валкин — основатель стартапа Echo родом из Ульяновска. Сейчас живет в USA, а команда разработки находится в Ульяновске. Ну и он всячески, не безуспешно, старается развивать и поддерживать IT движуху в этом городе. В докладе рассказал о том, в чем, по его мнению, заключается секрет развития силиконовой долины и чего не хватает Ульяновску для того чтобы стать «Российской силиконовой долиной».

Успешному развитию силиконовой долины (для краткости далее — СД) поспособствовали:

• удаленность от крупных городов бизнес-центров, в которых существовали крупные агрессивные компании
• Хороший климат) Упрощает коммуникацию.
• Взаимодействие с университетами
• Отсутствие государства и политиков
• Кажется, упоминалась небольшая территория (все рядом)

Так же пояснил важный момент: в СД развиваются и всячески поощряются горизонтальные связи между компаниями между специалистами из одной области. Т.е. программисты одной компании обмениваются знаниями с программистами другой, менеджеры — с менеджерами, техподдержка с техподдержкой и т.п. И это очень важно в ситуациях, когда знания специалиста бывают не до конца востребованы в его компании, но могут пригодиться кому то еще. Не менее важен и «обмен» специалистами.

Про Ульяновск: плюсы это то, что он удален от Москвы (мало сильных конкурентов, спецы не сбегают в Москву), довольно большая концентрация IT компаний, погода, небольшая территория. Минусы — не развиты горизонтальные связи и обмен опытом.

Порекомендовал для удержания и повышения мотивации сотрудников использовать profit-sharing (опционы и т.п.).

От себя — давно наблюдаю, не особо в курсе как развиваются IT бизнесы, появляются ли новые компании в Ульяновске, но какая-то IT движуха там явно есть. Тот — же UlCamp например, присутствие Echo с вакансиями на которые люди из Москвы приезжают…

Аня Степанян, Undev. «Как мы делали webvybory2012″

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

Трудно выбрать хорошие камеры. Медленный интернет на многих участках (до 128кбит/с), часть компьютеров за NAT. Есть специальные требования к компьютерам. Заказы в огромных количествах. В итоге имелось 10 различных комбинаций оборудования. На тестирование очередного релиза на всех конфигурациях уходят сутки. Были проблемы связанные с тем, что официально адреса участков публикуются за месяц до выборов, поэтому пришлось составлять свою базу адресов, с которой были проблемы и неточности — корректировали вручную.

Сам сайт был практически статическим (JSON дампы), база данных — PostgreSQL. Языки программирования: Ruby, Python, CoffeeScript, работа с видео на ObjC.

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

Допилил сегодня плагин для Network Manager с поддержкой L2TP. Поддерживает VPN через L2TP и, теоретически, L2TP через IPSec.
Я проверял на «beeline домашний интернет» (http://help.internet.beeline.ru/internet/install/windows7/l2tp) и в общем-то для этого его и взялся дорабатывать. В принципе, можно даже озаглавить статью типа «Настройка beeline l2tp vpn через NetworkManager«.

Установка

Можно установить из PPA:
https://launchpad.net/~seriy-pr/+archive/network-manager-l2tp

sudo apt-add-repository ppa:seriy-pr/network-manager-l2tp
sudo apt-get update
sudo apt-get install network-manager-l2tp-gnome

После установки настоятельно рекомендую выполнить

sudo service xl2tpd stop
sudo update-rc.d xl2tpd disable

После этого можно будет создать новое VPN подключение «Layer 2 Tunnelling Protocol (L2TP)» (см. скриншот).
Напомню как:

1. Кликаем по иконке NM в трее
2. Выбираем «Изменить соединения»
3. Открываем вкладку VPN
4. Жмем «Добавить»
5. В выпадающем списке выбираем «Layer 2 Tunnelling Protocol (L2TP)» жмем создать
6. Дальше уже заполняем окно с настройками для нового соединения

Можно сразу попасть на 5-й пункт если запустить в консоли nm-connection-editor --type=vpn --create

Если что-то не работает

Можете пожаловаться мне. Делать это следует так:
Сперва выполняем команды lsb_release -a и uname -a и отправляем мне что они напечатают.
В идеале прикладывайте еще ссылку на инструкцию вашего провайдера по настройке VPN для Windows.
Дальше в зависимости от того какая возникла проблема:

Не устанавливается пакет

Присылайте вывод команды
apt-cache policy network-manager-l2tp
Ну и какую ошибку пишет при установке.

Не получается Добавить новое VPN подключение

Имеется в виду что пакет установился, но при попытке создать и настроить новое VPN подключение возникают проблемы (нет пункта «Layer 2 Tunnelling Protocol (L2TP)» или программа вылетает или не сохраняются настройки).
В консоли запускаете команду
nm-connection-editor --type=vpn --create
И пробуете добавить и настроить новое подключение. Присылайте что напечатает в консоль и опишите саму проблему конечно же.

При попытке подключения происходят ошибки

Открываете 2 консоли, в одной запускаете

sudo /usr/lib/NetworkManager/nm-l2tp-service --debug

в другой

tail -f -n 0 /var/log/syslog

и пробуете подключиться. После того как случится фейл, присылайте что напечатает за это время в обоих терминалах (в выводе первой команды может засветиться ваш пароль — замените его звездочками!).

Альтернативные GUI программы для подключения к L2TP VPN в Linux

Если этот плагин почему то так у вас и не заработал, можете попробовать одну из следующих GUI-программ (к слову, все эти L2TP-GUI, в т.ч. и мой плагин, «внутри себя» используют одни и те же консольные программы: xl2tpd (для L2TP), pppd (для VPN) и openswan (для IPSec), но генерируют к ним немного разные конфиги и запускают их немного по разному).

vpnpptp

Официальный сайт vpnpptp. Программа написана на Pascal и Bash с использованием Qt. Из плюсов — много настроек, разрабатывается нашими соотечественниками, оптимизирована для подключения к beeline. Из минусов, пожалуй, довольно нестабильная работа, необходимость вводить root-пароль для подключения и не очень удобный интерфейс. (Ну и еще сам код программы жуткий).

L2tp-IPsec-VPN

Сайт, Wiki. Написана на C++ и Qt. Из плюсов — очень хорошая поддержка IPsec, неплохой интерфейс, можно подключаться без root пароля, активно разрабатывается, дружелюбный разработчик =). Из минусов — опять же, недостаточно стабильная работа, поддержку работы БЕЗ IPSec (нужно для работы с beeline) добавили совсем недавно (по моей просьбе), но заставить его работать с beeline так и не получилось.

Эпилог

Разработку веду на Github https://github.com/seriyps/NetworkManager-l2tp.
Пожелания, багрепорты, комментарии, благодарности приветствуются.

Тикеты с просьбой добавить поддержку L2TP в NM появились на Launchpad и Gnome в сентябре 2008г. Изначально плагин разработал Alexey Torkhov, но затем прекратил его поддержку.

В качестве основы использовалкод модуля django-standalone и статью Django ORM без Джанги - эта статья практически полностью решает проблему, но есть и несколько недостатков:

• Модели для создания таблиц нужно перечислять вручную
• Не создаются внешние ключи
• По — мелочи — нужно каждой модели вручную задавать app_label

Попытаемся исправить эти недостатки.

Сразу предупреждаю, что от необходимости устанавливать Django нас статья не освобождает. Так что первым шагом устанавливаем Django:

sudo pip install Django

Собственно, приведу сразу код с комментариями

#/usr/bin/env python
# -*- coding: utf8 -*-

from django.conf import settings
settings.configure(
    # задаем параметры подключения к БД
    DATABASES={
        'default': {
            'ENGINE': 'postgresql_psycopg2', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
            'NAME': '***', # Or path to database file if using sqlite3.
            'USER': '***', # Not used with sqlite3.
            'PASSWORD': '***', # Not used with sqlite3.
            'HOST': '****', # Set to empty string for localhost. Not used with sqlite3.
            'PORT': '****', # Set to empty string for default. Not used with sqlite3.
        }
    },
    # этот префикс будет добавляться к именам таблиц вместо имени приложения
    # его нужно указывать только при использовании в скрипте. При использовании в
    # Django этот параметр лучше убрать.
    STANDALONE_APP_NAME='some_prefix'
)

from django.db import models

class StandAloneMetaclass(models.base.ModelBase):
    """Метакласс, который задает app_label моделям используя
    значение из STANDALONE_APP_NAME"""
    def __new__(cls, name, bases, attrs):
        app_name = settings.STANDALONE_APP_NAME or None
        if app_name:
            if 'Meta' in attrs:
                if not hasattr(attrs['Meta'], 'app_label'):
                    # устанавливаем app_label только если он уже не указан в самой модели
                    setattr(attrs['Meta'], 'app_label', app_name)
        return super(StandAloneMetaclass, cls).__new__(cls, name, bases, attrs)

class BlogNote(models.Model):
    __metaclass__ = StandAloneMetaclass  # всем моделям нужно прописать этот метакласс
    text=models.TextField()
    # необходимо добавить атрибут Meta всем моделям для корректной работы метакласса
    class Meta:
        pass

class BlogComment(models.Model):
    __metaclass__ = StandAloneMetaclass
    text=models.TextField()
    note=models.ForeignKey(BlogNote)  # внешние ключи тоже работают

    class Meta:
        pass

def create_tables(tables):
    from django.db import connection, transaction
    from django.core.management.color import no_style
    pending_references = {}  # список внешних колючей, ожидающих создания связываемых таблиц
    seen_models = set()  # список созданных
    style = no_style()  # указывает, что не нужно раскрашивать синтаксис сгенерированного SQL
    for model in tables:  # проходим по списку моделей
        sql, references = connection.creation.sql_create_model(model, style) # генерируем SQL и объекты внешних ключей
        seen_models.add(model)
        for refto, refs in references.items():
            pending_references.setdefault(refto, []).extend(refs)
            if refto in seen_models:
                sql.extend(  # если все таблицы внешнего ключа существуют, то добавляем сам ключ
                    connection.creation.sql_for_pending_references(
                            refto,
                            style,
                            pending_references))
        sql.extend(
            connection.creation.sql_for_pending_references(
                model,
                style,
                pending_references))
        cursor = connection.cursor()
        for stmt in sql:  # выполняем запросы к БД
            print stmt
            try:
                cursor.execute(stmt)
            except Exception, e:
                print e
                pass
        print
    transaction.commit_unless_managed()  # завершаем транзакцию
    for model in tables:  # создаем индексы
        index_sql = connection.creation.sql_indexes_for_model(model, style)
        if index_sql:
            try:
                for stmt in index_sql:
                    print stmt
                    cursor.execute(stmt)
            except Exception, e:
                transaction.rollback_unless_managed()
            else:
                transaction.commit_unless_managed()

if __name__ == "__main__":
    # находим все классы Django моделей в локальной области видимости и создаем для них
    # таблицы в БД
    create_tables(model for model in locals().values() if type(model) == StandAloneMetaclass)

Большая часть содержимого create_table() скопировано из файла django/core/management/commands/syncdb.py. По сравнению с оригинальной статьей отпала необходимость вручную указывать для каждой модели app_label и вручную передавать список моделей для создания. Но появилась необходимость прописывать __metaclass__. Успокаивает то, что он один и тот же для всех классов. Ну и необходимо всем прописывать class Meta: pass. Можно это поправить, если создать базовый класс абстрактной модели с этими атрибутами и наследовать все модели от него.

Ну и общее впечатление — Django ORM не самое удачное решение для использования отдельно от  Django. Если есть возможность, стоит использовать более подходящие библиотеки, например SQLAlchemy. Она хоть и более сложна для освоения, но и более мощная, поддерживает пуллинг соединений, более управляемая и рассчитана на такое использование.

Не так давно решил вплотную познакомиться со всей кухней OpenSource со стороны разработчика и в качестве первой пробы решил написать плагин к Gwibber для поддержки Вконтакте. Надо сказать, что тикет на Launchpad на эту тему висит с середины 2010 года (датирован 2010-05-01) с довольно длинным обсуждением, было несколько попыток реализовать поддержку, но готового решения никто не предложил. Помимо Launchpad, появился топик на форуме Ubuntu.ru, в котором топикстартер сообщил, что реализовал поддержку ВК, но код так никому и не показал.

Так что в начале декабря взялся за работу и через 2 месяца рабочая протестированная версия плагина была готова. На данный момент я уже отправил запрос о включении плагина в официальную ветку Gwibber и буквально сегодня разработчики отметили его для включения в релиз 2.91.5.
Описание функционала, инструкция для желающих протестировать плагин в работе уже сейчас под катом…

Доступный функционал

На данный момент работает:

• Загрузка текстовых постов из новостей
• Загрузка видео — постов
• Загрузка постов — ссылок
• Загрузка постов  с фото и граффити
• Отправка сообщений на свою стену
• Комментирование постов
• «Мне нравится» (сердечко)
• Удаление моих постов

Хочется добавить:

• Поддержку «ретвитов» («Мне нравится»+»Рассказать друзьям») Пока архитектура Gwibber не позволяет это сделать
• Поддержку mentions (упоминание). Вконтакте выглядит как ссылка «ответить на моей странице». В Gwibber сейчас отображается как «[id535397|Сергей Прохоров], «. Примитивную поддержку сейчас добавить ничего не мешает.
• Поддержку личных сообщений (Пока что в сомнениях нужно ли это. В любом случае будет отдельная галочка в настройках аккаунта)

Известные проблемы:

• После смены IP адреса появляется сообщение об ошибке «Unknown method passed». Дело в том, что авторизационный «токен» API вконтакте привязан к IP адресу (видимо для защиты от взлома аккаунта) и после каждой смены IP его нужно обновлять. Делать это в фоновом режиме в текущей реализации самого Gwibber сейчас нельзя. Особенно доставляет тот факт, что сообщение об ошибке ни о чем не говорит… Так что нажимаем «редактировать» и заново проходим процедуру авторизации, жмем F5 для получения последних сообщений.

Инструкция по установке

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

Подготовка

UPD: для natty этот пункт можно пропустить, т.к. там установлена новая версия Gwibber.

Важно! Не пропустите! Т.к. поддержка плагинов появилась только в ветке 2.91.x, а в Ubuntu Maverick установлена версия 2.32.x, то необходимо сперва установить последнюю версию из девелоперского PPA «deb http://ppa.launchpad.net/gwibber-daily/ppa/ubuntu maverick main #Gwibber-Daily PPA» командами

sudo add-apt-repository ppa:gwibber-daily/ppa
sudo apt-get update
sudo apt-get upgrade

Эти команды обновят основные модули Gwibber. Важно! Т.к. все протоколы теперь поставляются в виде отдельных пакетов, нужные протоколы необходимо устанавливать самостоятельно. Если этого не сделать, то Gwibber не запустится, а при запуске gwibber из консоли увидим

Traceback (most recent call last):
  File "/usr/bin/gwibber", line 87, in
    client.Client()
  File "/usr/lib/python2.6/dist-packages/gwibber/client.py", line 621, in __init__
    self.w = GwibberClient()
.........
  File "/usr/lib/pymodules/python2.6/mako/runtime.py", line 278, in
    return lambda *args, **kwargs:callable_(self.context, *args, **kwargs)
  File "base_mako", line 251, in render_image
  File "base_mako", line 192, in profile_url
  File "base_mako", line 829, in render_profile_url
KeyError: u'twitter'

Посмотреть список протоколов можно командой

aptitude search gwibber-service-+

Установим минимум — протоколы facebook и twitter:

sudo aptitude install gwibber-service-{twitter,facebook}

После этого можете попробовать запустить Gwibber и убедиться что версия обновилась.

Установка плагина Vkontakte.ru

UPD 2011-05-22: Вариант номер ноль. Используйте его! — установка из PPA

Для поддержки плагина создан PPA на Launchpad. Можно установить плагин, подключив этот PPA:

sudo apt-add-repository ppa:gwibber-vkontakte-plugin/ppa
sudo apt-get update
sudo aptitude install gwibber-service-vkontakte

Обновляться теперь будет автоматически!

Вариант номер раз — установка из DEB пакета

Добрый товарищ ZwS (Антон Судак?) с форума Ubuntu.ru собрал .DEB пакет, многие уже писали что установили этот пакет и у них все успешно заработало. Вот ссылки для скачивания DEB пакета для установки плагина
(оригинальная), (мое зеркало) md5 e3ce23c5328fec6b54c2d549a4870812
UPD: новая версия (оригинальная), (мое зеркало) md5 d9cdb8299eebf8d7145dd219a3f75219

Просто скачиваете файл, запускаете, все подтверждаете, перезапускаете Gwibber, готово. Преимущества такого подхода — легко удалить если что-то сломается (sudo aptitude remove gwibber-service-vkontakte) и если выйдет официальная версия плагина, то она без проблем установится поверх этой.

Вариант номер два (им пользуюсь я) — установка симлинков из bzr исходного кода

Пользуюсь потому что так можно запускать код написанный прямо сейчас, но просто так им пользоваться не советую.

Устанавливаем bazaar

sudo aptitude install bzr

Загружаем исходники Gwibber из моего репозитория Launchpad

bzr branch lp:~seriy-pr/gwibber/vkontakte-ru-plugin

После этого главная магия — делаем симлинки на некоторые кукски моего кода в директории откуда Gwibber их подхватит:

sudo ln -s /home/$USER/vkontakte-ru-plugin/gwibber/microblog/plugins/vkontakte/ /usr/share/gwibber/plugins/
sudo ln -s /home/$USER/vkontakte-ru-plugin/ui/icons/breakdance/16x16/vkontakte.* /usr/share/gwibber/ui/icons/breakdance/16x16/
sudo ln -s /home/$USER/vkontakte-ru-plugin/ui/icons/breakdance/22x22/vkontakte.* /usr/share/gwibber/ui/icons/breakdance/22x22/
sudo ln -s /home/$USER/vkontakte-ru-plugin/ui/icons/breakdance/scalable/vkontakte.* /usr/share/gwibber/ui/icons/breakdance/scalable/

И тогда должно заработать (только это небезопасно т.к. содержимое /home/$USER/vkontakte-ru-plugin доступно для записи). Если удалить директорию vkontakte-ru-plugin из домашней папки то работать перестанет. Чтобы этого избежать можно в предыдущем списке команд заменить команды «ln -s» на «cp»
Преимущества — для НЕразработчика — вам будет доступна самая последняя-распоследняя версия плагина. Недостатки — относительно сложно, небезопасно, могут возникнуть проблемы при обновлении.
Если после этого у вас Gwibber вдруг перестанет стартовать, можно подчистить следы деятельности командами

sudo rm -r /usr/share/gwibber/plugins/vkontakte
sudo rm -r /usr/share/gwibber/ui/icons/breakdance/*/vkontakte*

Способ номер три (я не проверял, но есть люди у которых он работает) — установка из «исходного кода» с помощью setup.py

Gwibber поддерживает distutils, соответственно его можно установить непосредственно из исходного кода с помощью файла setup.py. Преимущества и недостатки у этого метода примерно такие — же как у второго, но в случае неудачи подчистить следы будет сложнее. Сам я этот метод не проверял, поэтому скопирую краткое резюме из инструкции, приведенной товарищем M.CoRN в его блоге (мои благодарности ему):

bzr branch lp:~seriy-pr/gwibber/vkontakte-ru-plugin
sudo apt-get install python-dbus python-gtk2 python-gconf python-notify python-simplejson python-egenix-mxdatetime python-distutils-extra python-feedparser
cd vkontakte-ru-plugin
sudo python setup.py install

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

Настройка учетной записи вконтакте в Gwibber

Ну тут как обычно все. Редактировать -> Учетные записи (или запустить приложение «gwibber-accounts») -> Добавить -> в выпадающем списке выбрать « Vkontakte» -> Добавить -> Выставьте галочки («Получать сообщения» — чтобы получать сообщения вообще, «Посылать сообщения» — чтобы можно было отправлять сообщения и комментарии, «Receive groups» — это уже моя самодеятельность, если отмечено, будет загружать новости от групп, помимо новостей от друзей) -> Авторизовать -> Вводим логин-пароль, выставляем все галочки, жмем «Разрешить». Если все прошло успешно, закрываем окно, жмем F5 для обновления и пользуемся!

Что дальше?

Если есть какие-то пожелания/советы/отчеты об ошибках милости прошу в комментарии. Если хотите помочь и у вас есть аккаунт на Launchpad, отпишитесь тут https://bugs.launchpad.net/gwibber/+bug/572753 и тут https://code.launchpad.net/~seriy-pr/gwibber/vkontakte-ru-plugin/+merge/47651 что у вас все работает или наоборот ничего не работает, так этот плагин быстрее попадет в официальную поставку.

Как водится, выражаю благодарность Stanislav Hanzhin, sergeyreym за активное участие, советы и багрепорты,  Nazar Vinnichuk и остальным разработчикам Rhythmbox’s plugin for Vkontakte.ru — их наработки послужили основой для плагина, ZwS (Антон Судак?) за .DEB пакет, ну и всем остальным кто принимал и принимает посильное участие.

Организация

В целом организация неплохая. Неудобно было только то, что добираться в Ярославль к началу конференции было практически не на чем (не считая собственного транспорта). Поэтому пришлось выезжать за день до начала конференции. С жильем решили не выпендриваться и поселились в Профилактории Железнодорожник, который расположен в пяти минутах ходьбы от места проведения конференции и ЖД вокзала (и в 2-х минутах от кладбища).

Само мероприятие проходило в ДК Железнодорожник.

Профилакторий «Железнодорожник»	ДК «Железнодорожник»
ДК изнутри. Холл перед секцией А	ДК изнутри. Холл перед секцией А

Доклады

Сама по себе конференция общего профиля, т.е. не тематическая. Просто посвящена программированию и программистам. Доклады шли в три потока, соответственно по секциям A, B и C. Зал секции A раза в 3 больше других, в нем предполагается проводить доклады, на которые придет больше всего слушателей (почему-то все время был заполнен процентов на 10-20). Секция B — секция для докладов с аудиторией поменьше (тут места практически всегда не хватало) и секция C — это зал совещаний с круглым столом, здесь читали некоторые доклады и проводили непосредственно круглые столы.

С программой конференции можно ознакомиться по ссылке http://it-conf.ru/ru/content/331.htm

День первый

После церемонии открытия конференции и отпаивания кофе с пирожками, первый доклад на который мы решили пойти:

Стас Фомин, «Золотая середина. Открытые системы поддержки разработки»

Вообще, докладчик довольно примечательный, эмоциональный. Для иллюстрации доклада использовал не презентацию PP а какие-то Mind Maps, было немного непривычно.

Рассматривал варианты выбора систем поддержки разработки (багтрекеры, Wiki, VCS). Противопоставлялись коммерческие системы и открытые. Плюсы коммерческих систем — коммерческая поддержка и, как правило, более широкий функционал, у открытых — открытый код и возможность расширять и дописывать системы самостоятельно.

Так же обсуждался выбор между интегрированными системами — комбайн «все в одном», когда и Wiki и трекер и прочие компоненты это один проект (такие как Redmine, Trac и т.п.) и специализированные системы собранные и собственноручно склееные из отдельных компонентов. В первом варианте указывают на то, что компоненты такого «комбайна» будут уступать по функционалу специализированным решениям (Wiki редмайна будет уступать Mediawiki а трекер BugZill-е). Таким образом докладчик высказался в пользу последнего варианта, рассказал как в своей компании они связывали MediaWiki, BugZilla и SVN, сказал, что эту связку они планируют выложить на SourceForge в свободный доступ.

От себя/вывод: я все же считаю, что объем работы по интеграции отдельных систем будет довольно большой и оправдан только для действительно крупных команд. Лично меня Redmine устраивает абсолютно всем.

Олег царев, Кирилл Коринский, «Сравнительный анализ хранилищ данных»

Выступление примечательно тем, что его читают два докладчика (когда по очереди, когда одновременно).

Начали с оценки требований к серверу на котором может храниться база графа друзей на FaceBook, Vkontakte и Мой мир. Пришли к выводу, что на одном сервере такая база не сможет храниться физически из-за ограничений на пропускную способность RAM, соответственно не обойтись без распределения БД… и через несколько минут кто-то из слушателей сообщил, что только что написал на коленке программу-эмулятор, прогнал ее и получил результат в 200 раз отличающийся от результатов докладчика. Забавно.

Далее лично я (как, думаю и все остальные) ожидали какого-то реального сравнительного обзора существующих решений хранилищ данных, холиваров SQL/NoSQL, рекомендаций в каких случаях какую БД стоит использовать, но на самом деле я даже не понял, что происходило на второй части доклада — докладчики постоянно друг друга перебивали, немного обсудили CAP теорему, толком не рассмотрели ни одной БД и пришли к выводу, что «серебрянной пули нет, для каждой проблемы нужно подбирать свое решение». Привет Капитану Очевидность ((.

От себя/вывод: для меня доклад запомнился как «разочарование конференции». Все-таки ожидал какого-то практического обзора, опыта внедрения, конкретики короче,а получил абстрактного коня в вакууме и вывод от КО. К тому же докладчики постоянно друг друга перебивали, что только еще больше портило впечатление. Все надежды на круглый стол SQL vs NoSQL…

Круглый стол, «Системы управления версиями»

Первый круглый стол. Обсуждаем системы контроля версий. Вспомнили наиболее популярные сейчас системы: Subversion, GIT, Mercurial, Bazaar и даже коллекции патчей. Обсуджали модели разработки с блокировкой доступа к файлам (locking) и со слиянием (merging). Дискуссия завязалась довольно живая, мне даже показалось, что не обошлось без троллинга, т.к. 90% времени говорили 2 или 3 человека.

Насчет merging vs locking: метод с блокировкой неудобен тем, что над файлом одновременно может работать только один человек. Если он вдруг заболеет/уйдет в отпуск и забудет снять блокировку, то доступ к файлу кому-то еще получить будет проблематично. В то же время о merging говорили, что сам процесс слияния довольно сложный и может стать причиной множества багов. Проскользнула мысль, что locking эффективен в команде низкоквалифицированных разработчиков/Junior Developer-ов или студентов, т.к. меньше шанс что-то сломать при слиянии.

Subversion ругали за то, что в нем особенно сильно проявляются проблемы слияния ветвей и что реализовано это в нем крайне примитивно. На этом фоне GIT смотрится гораздо приятнее. Из плюсов Subversion/централизованных VCS — централизованный контроль прав доступа, удобство составления плана релизов и то, что централизованные репозитории не дают разработчикам расслабиться (т.к. все коммиты попадают в центральный репозиторий и за этим процессом может наблюдать начальство). Таким образом Subversion хорош в основном для корпоративных разработок.

Распределенные системы хороши простотой установки и использования, концепцией локальных ветвей и микрокоммитов, более продвинутым слиянием веток, высокой скоростью работы за счет уменьшения работы с сетью и взаимодействия с центральным репозиторием ну и возможность коммитить даже не имея интернета. Из минусов отметили… отсутствие центрального репозитория. Отметили что DVCS лучше подходят для OpenSource и некоммерческой разработки.

Немного касались платформ для разработки. Поговорили о Launchpad, GitHub, GoogleCode.

От себя/вывод: еще раз подтвердилась мысль о том, что использовать Git в качестве основного репозитория в компании не очень удобно, SVN с этой задачей справляется достаточно хорошо. А для своих проектиков Git и другие DVCS — самое то. Хотя на работе я все равно использую git-svn: на рабочем месте использую Git, а потом экспортирую коммиты в корпоративный SVN. Довольно удобно, я уже привык.

Максим Лапшин, «Разработка видеохостинга на Erlang»

Пожалуй этот доклад мне понравился больше всего. Хороший докладчик, рассказывал о разработанном им сервере для потокового вещания аудио/видео ErlyVideo http://erlyvideo.org/ и о языке Erlang в целом.

Erlang — функциональный интерпретируемый язык программирования enterprise уровня с динамической типизацией и простым синтаксисом. Основные преимущества — легковесные независимые потоки/нити, простота создания параллельных программ и поддержка горячего обновления кода. На нем написан самый популярный Jabber сервер ejabberd и еще множество различных хорошо масштабируемых отказоустойчивых сервисов. В частности, докладчик разрабатывал на Erlang бэкенд для лидирующей в рейтинге приложений Вконтакте игры «Лицемер».

Сам видеосервер успешно работает на нескольких видеохостингах и уделывает всех конкурентов по производительности и стабильности.

От себя/вывод: все-таки разрабатывать параллельные и асинхронные программы на объектно ориентированных языках менее эффективно, чем на функциональных. Думаю в ближайшем будущем попробовать поучить Erlang. Заинтересовало. До этого из функциональных ЯП работал только с XSLT и впечатления остались исключительно положительные.

Андрей Аксенов, «3D — графика на трех пальцах»

Андрей Аксенов больше всего прославился как разработчик поискового сервера Sphinx, на этой конференции про Sphinx не прочитал ни одного доклада, зато рассказал об основах 3D графики.

Основная идея — все улучшения в современных техниках рендеринга представляют из себя микрооптимизации направленные не столько на реалистичность, сколько на улучшение восприятия. «Главное не чтобы было реалистично, главное чтобы было красиво».

От себя/вывод: В вопросах 3D графики разбираюсь слабо, но для общего развития послушать можно.

Алексей Алексеев, Николай Гребнев, «Предупреждение ошибок программиста с помощью статического анализа кода и доменной модели»

Докладчики разрабатывают на C# или .NET с которыми я не знаком, поэтому понимал о чем говорят с трудом. Обсуждали ORM, Linq и еще что-то. Так ничего и не поняв, решил переместиться на параллельный доклад.

Кирилл Коринский, «Информирование о загрузке базовых станций Yota»

К сожалению, когда мы подошли доклад уже заканчивался. Что успел понять: нагрузки в их системе огромные, они написали и внедрили свою InMemory базу данных, которая отлично справляется с возложенными на нее задачами, и за время эксплуатации не было ни одного сбоя. Ну что ж, замечательно. Остается порадоваться.

Елена Сагалаева, «Искусственный интеллект в играх»

Елена Сагалаева ведет довольно популярный блог посвященный разработке на C++ http://alenacpp.blogpost.com/, прочитала доклад о том, как создаются боты в компьютерных играх. Хоть игрушки и не мой профиль, но было довольно интересно.

Узнал что по настоящему «Искусственный интеллект» — нейронные сети в играх не используются, т.к. это не удобно по ряду причин. Основная — поведение обученной сети довольно трудно менять, поэтому в играх сейчас используют ботов работающих на обычных алгоритмах. Рассказали об алгоритмах поиска оптимального пути бота на карте, об алгоритмах следования за лидером, о приемах применяемых в компьютерных гонках.

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

От себя/вывод: просто довольно интересный обзорный доклад. В принципе получился коротковатый, можно было сделать подлиннее.

День второй

Думали на первую линейку докладов не ходить, но пересилили соблазн. Заинтересовал:

Андрей Карпов, «Современный статический анализ кода»

Андрей Карпов — разработчик статического анализатора кода C++ для 64-битных и многопоточных программ PVS-studio. Много статей писал на Хабре о разработке на 64-битной платформе и параллельном программировании http://habrahabr.ru/search/?q=viva64

Прочитал доклад о современном статическом анализе, о возможностях анализаторов кода, сделал краткий обзор современных анализаторов, приводил примеры нетривиальных ошибок в C++ коде. В целом весьма интересно. Только говорит очень быстро, такой поток слов мозг не всегда успевал обработать))

От себя/вывод: как я понимаю, во все современные IDE встроен статический анализатор, так что его работу как-то не замечаешь и не задумываешься. А ведь без него было бы гораздо тяжелее. Открыл для себя, что статические анализаторы бывают и отдельно от IDE. Надо будет поискать какие решения существуют для PHP, Python, JavaScript. А ведь они помимо поиска ошибок умеют еще и за стилем кода следить (всякие там отступы/табуляции, где ставить открывающую скобку и т.п.) и отслеживать неоптимальные решения.

Владимир Климонтович, «Apache Hadoop»

Здесь рассказали о запатентованном Google алгоритме Map-Reduce и основанной на нем распределенной базе данных Apache Hadoop

Сам алгоритм Map-reduce довольно прост, но чтобы понять всю его мощность и потенциал, надо немного вникнуть. Основное его преимущество — легкость масштабирования. Т.е. написав задачу для обсчета на map-reduce можно запустить ее хоть на одном, хоть на любом другом количестве серверов без изменения кода. Еще интересно было увидеть как SQL запросы выражаются с помощью map-reduce. Жаль что сам map-reduce в докладе был рассмотрен не так подробно — непосвященным было бы трудно понять. Неплохо было бы добавить несколько примеров и картинок и было бы вообще отлично.

Apache Hadoop — нереляционная распределенная база данных основанная на принципе map-reduce. Для хранения своих баз использует собственную распределенную файловую систему. Предназначена для обработки огромных объемов данных на кластерах. На устраиваемом Yahoo соревновании по скоростной сортировке 100GB массива заняла первое место. На практике эта БД применялась в поисковике Yahoo для создания поискового индекса; на last.fm для подсчета рейтинга композиций (чартов) и еще много где. Сам докладчик сказал, что они успешно используют эту БД для анализа (на кластере) логов показов в сети контекстной рекламы, которых накапливается под сотню Гб в сутки.

От себя/вывод: вообще map-reduce довольно интересная технология но, как я понимаю, реальные ее преимущества можно почувствовать только при больших объемах данных и распределенной архитектуре. Так что по мере появления необходимости буду вникать, а пока отложу на будущее. Опять же, процедуры для hadoop пишут на Java, с которой я на Вы.

Круглый стол, «SQL vs NoSQL»

Вот он, долгожданный холивар.

Обсуждение было довольно сбивчивым и к какому-то однозначному выводу прийти не смогли. Но все же, как мне показалось, верх одержали реляционные базы данных как более надежные, ынтырпрайзные и привычные. Прежде чем решаться использовать какую-то новую/экзотическую БД нужно 10 раз подумать. В качестве примера вспоминали уволенного начальника отдела разработки digg.com, т.к. под его руководством целый год безуспешно пытались перевести digg на Cassandra.

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

Довольно часто упоминался Яндекс маркет, т.к. у него довольно сложная структура данных со множеством различных атрибутов товаров, по которым необходимо делать фильтрацию, сортировку и пр., что довольно проблематично реализуется в рамках реляционных SQL БД. Представители Яндекса сознались, что в Маркете действительно используется самописная InMemory база данных.

Андрей Майоров рассказал об успешном использовании XML полей в MSSQL (оказывается по ним можно строить индексы и делать выборки/фильтрации с помощью XPath). XML поля имеются в MSSQL и Oracle.

От себя/вывод: ждем когда допилят нереляционные БД до enterprise уровня, а пока продолжаем использовать старый добрый MySQL/Postgres. Хотя, конечно, в не самых ответственных или очень специфических случаях можно и пробовать прикручивать экзотику, но только если это на самом деле оправдано. Например Redis рекомендуют использовать в качестве менеджера очередей, Hadoop для распределенной обработки больших объемов информации. И еще — создание собственной БД для своего специфического проекта вполне реально и иногда оправдано (на примере Яндекс Маркета и Yota).

Илья Кантор, «Удобная кросс-доменная авторизация»

Илья Кантор — создатель сайта http://javascript.ru. Проводит мастер-классы по JavaScript и основанных на нем технологиях. Рассказал одновременно и как противостоять DDOS атакам, и как организовать кроссдоменную авторизацию и как реализовать персонализацию сайта для незарегистрированных пользователей.

Для отражения DDOS предлагается использовать связку Varnish и Redis. Varnish — это быстрый кеширующий прокси-сервер, позволяющий подключать свои модули, Redis — нереляционная key-value база данных, преимущественно InMemory. Суть трюка в том, что версия сайта для незарегистрированных пользователей (и, соответственно, ботов) загоняется в глубокий кеш Varnish-а, а персональные версии для зарегистрированных пользователей уже генерирует бэкенд. Главная хитрость заключается в том, что авторизация проверяется не на бэкенде, а непосредственно в Varnish. Клиент обращается к Varnish, varnish обращается к Redis (в котором хранятся сессии пользователей) для проверки залогинен ли пользователь. Если да — перенаправляет к бэкенду, если нет — отдает версию из своего кеша. Нагрузка на бэкенд снята, DDOS отражен.

Персонализация достигается за счет хранения сессий и прочих персональных данных на основе сессионной куки в Redis.

А кросс-доменная авторизация работает с использованием мастер-сервера авторизации с которого подключается специальный JavaScript файл, выставляющий авторизационную Cookie. Не все браузеры позволяют выставлять cookie с другого домена, для регулирования этих политик используются P3P HTTP заголовки. Но Safari не всегда доверяет этим заголовкам. В таком случае используется хак с отправкой POST запроса через IFRAME на мастер-домен.

От себя/вывод: технологии довольно интересные и прогрессивные, думаю найдут применение в наших проектах. Насколько я помню, кросс-доменная авторизация используется на vkontakte.ru и vk.com.

Илья Кантор, «Приватности в интернете нет» (секретный доклад)

Доклад не анонсированный в программе конференции, занял половину обеденного времени). Было рассказано о способах идентификации в интернете не только с помощью Cookie. Довольно интересные и неочевидные способы идентификации через комбинации HTTP заголовков браузера, через Flash, Java, HTML5 LocalStorage и прочее.

От себя/вывод: может пригодиться как для защиты от идентификации, так и для отслеживания или надежного «забанивания» пользователя.

Евгений Кирпичев, «Многопоточное программирование»

Рассказали о Линейной темпоральной логике (LTL), следование которой позволяет писать корректные параллельные программы. Есть анализаторы кода, позволяющие выявлять, используя LTL, потенциальные проблемы в параллельных программах (deadlocks etc.). Рассмотрены подходы и основные паттерны параллельной разработки (семафоры, мьютексы, блокировки). Не обошли стороной и асинхронное программирование. Мне показалось, что многовато математической теории, поэтому не все моменты были понятны.

Далее были рассмотрены возможности реализации параллельных программ на языках программирования Haskell, Erlang, Clojure, F#.

От себя/вывод: все-таки параллельные и асинхронные программы гораздо аккуратнее выглядят и легче пишутся на языках, которые специально предназначены для написания таких программ. Приведенный пример на F# это наглядно подтвердил. Пожалуй, функциональные ЯП для параллельного программирования подходят больше других. Хотя есть и такие паттерны как, например, Deferred, которые позволяют довольно успешно писать параллельные программы на ОО языках без потери читаемости.

Домой

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

Общие впечатления

Понравилось что вокзал, гостиница и место проведения конференции расположены максимально близко, так что во время обеда успевали дойти до номера и передохнуть. Так же приятно порадовало что нас обеспечивали стабильным WiFi интернетом на протяжении всей конференции. Сам ДК Железнодорожник оказался весьма удачным местом для мероприятия — чистенькие отремонтированные залы, много свободного места, где можно пообщаться, пирожки и чай/кофе в неограниченном количестве. В общем атмосфера была дружелюбной и располагающей к общению.

Теперь негатив. Мне не понравилось то, что конференция была уж очень широкого профиля. Каждый рассказывал о том, о чем хотел. Секции тоже не тематические. На любой секции могли расказывать про БД, потом про Java, после про разработку игр, поэтому приходилось часто бегать из зала в зал.

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

Еще немного подвел слабенький проектор в секции А — на многих интересных докладах трудно было разглядеть иллюстрации. Мелочь конечно, но отметить стоит.

Далее, обеды были ну совсем никакие. Спасли ситуацию только пирожки с кофе.

В общем и целом считаю, что конференция прошла удачно, но хотелось бы больше тематичности. Спасибо!

Большую часть времени разработчики проводят в двух местах — в IDE и в багтрекере/системе управления задачами (ну и, естественно, за гуглением/чтением всяких блогов, литературы etc). При этом, как правило, работая над конкретной задачей, разработчик использует весьма небольшое количество файлов проекта и возможностей IDE. Таким образом, все остальное окружение, не затронутое данной конкретной задачей, только отвлекает и сбивает с толку. Помочь решить эту проблему призван замечательный плагин для не менее замечательной IDE Eclipse под названием mylyn.

Суть работы плагина следующая: вы создаете какое-либо задание (точь в точь как в багтрекере), например «Пофиксить баг XXX», помечаете его как активное и начинаете как обычно над ним работать. При этом mylyn будет внимательно следить какие файлы вы открывали, сколько времени вы проводили над их правкой, какими функциями Eclipse пользовались. И затем на основе накопленной статистики начинает просто напросто часто используемые в данной задаче файлы подсвечивать более ярким и жирным цветом в списке файлов, затемняя неиспользуемые. Вроде даже некоторые элементы интерфейса также скрывает/выделяет, не замечал.  Это и есть основная фича. Кажется очень просто, но на самом деле крайне эффективна т.к. позволяет сконцентрироваться непосредственно над текущей задачей.

Вторая фича — то что задания можно создавать не только непосредственно в Eclipse, можно загружать тикеты напрямую используя вашу систему управления задачами. Мало того, Mylyn позволяет оперировать тикетами в системе управления задачами непосредственно из Eclipse: создавать тикеты, редактировать опции (%выполнения, оцененное время, статус), добавлять комментарии. К тому же он умеет считать затраченное на выполнение задачи время! Для этого используются специальные адаптеры (коннекторы) mylyn для различных систем управления задачами, т.н. «Task Repository Connectors», которые взаимодействуют с системой через REST или какое то другое API либо вообще парся веб-страничку тикета. Существуют множество коннекторов для распространенных систем, таких как Bugzilla, Jira, Mantiss, Trac и многих других. Причем некоторые из них можно установить непосредственно из интерфейса Eclipse, для чего нужно открыть Window > Show view > Task list , в появившемся блоке списков задач кликнуть по иконке New task > add repository…  > Install more connectors. К сожалению, в этом списке отсутствует коннектор для Redmine, поэтому придется повозиться дополнительно.

Подключение Eclipse mylyn к redmine

Для редмайн так же существует mylyn конектор, его проект расположен на SourceForge . Помимо установки самого коннектора необходимо установить плагин для редмайн. На сайте проекта есть подробная инструкция по установке, я могу далее просто описать свой опыт.

Установка плагина redmine

Довольно простая. Для этого на серверепереходим в директорию с установленным redmine и выполняем

ruby script/plugin install -x http://redmin-mylyncon.svn.sourceforge.net/svnroot/redmin-mylyncon/redmine_mylyn_connector/tags/CURRENT/redmine_mylyn_connector

В общем то все, переходим по адресу /admin/plugins вашего редмайна и видим «Mylyn Connector plugin» — значит все прошло хорошо. Если нет — попробуйте перезапустить Redmine.

UPD 2011.06.03: Помимо установки плагина, нужно включить Redmine REST API. Для этого нужно перейти в Administration -> Settings -> Authentication и поставить галку на Enable REST API.

Для обновления плагина можно воспользоваться командой

ruby script/plugin update

Установка Eclipse mylyn конектора Redmine

Для начала нужно подключить Update site для плагина. Адрес http://redmin-mylyncon.sourceforge.net/update-site/N/ о том как устанавливать дополнения в Eclipse я уже писал в этой статье. Если вкратце — открываем Help > Install New Software > Add в окошке в поле Name вводим что то вроде «Redmine mylyn connector», в поле Location » http://redmin-mylyncon.sourceforge.net/update-site/N/» и жмем ok. Далее после загрузка списка плагинов отмечаем галочкой «Mylyn Connector: Redmine», щелкаем Next-ы, рестартуем eclipse… Мы уже у финишной черты!

Подключение redmine проектов к mylyn

Теперь мы можем загрузить тикеты из существующего redmine проекта в mylyn и затем обновлять/редактировать их прямо из eclipse. Для этого в табе «Task list» (Window > Show view > Task list если уже забыли) щелкаем по иконке New task > add repository…

В этом окошке выбираем появившийся теперь «Redmine», жмем Next. В следующем окне вводим параметры подключения к веб-серверу Redmine («репозиторий тикетов» в терминах mylyn).

Здесь в поле Server вводим адрес, на котором у вас живет redmine, например «http://redmine.example.com/»; поле Label — понятное для вас название этого репозитория (будет показываться в списке доступных репозиториев); User id и Password соответственно ваши логин и пароль от учетки в redmine. Остальные опции можно оставить по умолчаню.

Жмем Finish и попадаем на страницу создания запроса на получение тикетов. По сути эта страница соответствует таковой по адресу «http://redmine.example.com/projects» с фильтрами со страницы «http://redmine.example.com/projects/myproject/issues» — какие задачи загружать с сервера а какие нет.

Выбираем в выпадающем списке «Select a project or create a Cross-Project-Query» какой-либо из проектов вашего redmine (либо оставляем как есть — тогда подгрузятся тикеты для всех проектов). В поле Query title вводим что-то осмысленное, например название проекта. Проверяем фильтры (например можно попросить загружать только тикеты назначенные мне или только открытые тикеты) и жмем Finish

Тадам! Думаю не стоит уточнять, что таким образом можно делать несколько запросов к одному репозиторию тикетов.

Теперь щелкаем по любому тикету в списке и попадаем на такую страничку

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

Удачных экспериментов!

Почитать

Сайт mylyn
Статья в wikipedia
Преимущества mylyn в статье на хабре
Сайт redmine — mylyn коннектора (есть wiki)

Создадим виртуалхост Nginx

Допустим, для поддомена adminka.example.com. Для этого создадим файл

sudo nano /etc/nginx/sites-available/adminka.example.com

со следующим содержимым:

server {
	listen   80;
	server_name  adminka.example.com;
	access_log  /var/log/nginx/adminka_example_com.log;#можно написать /var/log/nginx/$host.log но придется заранее создать лог-файл и выставить на него правильные права
	root   /var/www/$host/htdocs;
	index  index.html index.htm index.php;
}

Ок, сохраняем, делаем этот хост доступным (включаем в конфиг нджинкса):

sudo ln -s /etc/nginx/sites-available/adminka.example.com /etc/nginx/sites-enabled/adminka.example.com

Создаем директории для htdocs

mkdir /var/www/{adminka.example.com,adminka.example.com/htdocs,adminka.example.com/htdocs/{otherpass,listed}

Если кто не понял, эта команда делает то же, что и 4 следующие:

mkdir /var/www/adminka.example.com
mkdir /var/www/adminka.example.com/htdocs
mkdir /var/www/adminka.example.com/htdocs/otherpass
mkdir /var/www/adminka.example.com/htdocs/listed

Рестартим Nginx

sudo service nginx configtest
sudo service nginx restart

Проверяем: http://adminka.example.com/
Ага

403 Forbidden
nginx/0.7.64

Пароли не просит, листинг директории у нас не включен и index файла мы не создавали. То же самое для директорий otherpass и listed. Соответственно получаем 403 ошибку «доступ запрещен».

Добавим листинг (если нужен)

Мы договорились, что в директории listed у нас разрешен просмотр содержимого директории… Редактируем конфиг

sudo nano /etc/nginx/sites-available/adminka.example.com

server {
	listen   80;
	server_name  adminka.example.com;
	access_log  /var/log/nginx/adminka_example_com.log;
	root   /var/www/$host/htdocs;
	index  index.html index.htm index.php;
	location /listed/ {
		autoindex on;
	}
}

Сохраняем, перезапускаем, пробуем: http://adminka.example.com/listed/
Ага, работает:

Index of /listed/
_________
../
_________

Но где же обещанные пароли? Спокойно, сейчас все будет!

Добавляем Basic HTTP authorization.

Пароли для разных директорий будем хранить в разных htpasswd файлах за пределами htdocs. Например так:

/var/www/adminka.example.com/
--/root_htpasswd
--/listed_htpasswd
--/otherpass_htpasswd

server {
	listen   80;
	server_name  adminka.example.com;
	access_log  /var/log/nginx/adminka_example_com.log;
	root   /var/www/$host/htdocs;
	index  index.html index.htm index.php;
	location / {
		auth_basic "Unauthorized"; # текст сообщения сервера с предложением ввести пароль
		auth_basic_user_file /var/www/$host/root_htpasswd; # путь к htpasswd файлу
	}
	location /listed/ {
		auth_basic "Unauthorized";
		auth_basic_user_file /var/www/$host/listed_htpasswd;
		autoindex on;
	}
	location /otherpass/ {
		auth_basic "Unauthorized";
		auth_basic_user_file /var/www/$host/otherpass_htpasswd;
		autoindex on;
	}
}

Создаем htpasswd файлы (см. далее), сохраняем, перезапускаем, проверяем!

Генерация хеша пароля

HTTP авторизация в Nginx работает так же как и в Apache, т.е. с использованием htpasswd файла, но с тем лишь ограничением, что для шифрования пароля можно использовать только стандартный алгоритм DES с двухсимвольной солью. В Linux для этого используется C-функция crypt() (см man 3 crypt).

Можно использовать утилиту htpasswd из комплекта поставки Apache

htpasswd -nd seriy
New password:
Re-type new password:

seriy:4lQ0JcanrGr9E

Вывод этой утилиты состоит из 3-х частей: первая, до двоеточия «seriy» — это имя пользователя, «4l» — это двухсимвольная соль для функции crypt() и остальная часть «Q0JcanrGr9E» — это сам хеш пароля. Единственная проблема такого подхода — придется устанавливать apache.

Вот пара примеров кода для генерации htpasswd (your_password — ваш пароль, salt — соль для пароля, должна содержать 2(!!!) символа из набора «./0-9A-Za-z»):
используя php:

php -r 'echo crypt("your_password", "salt");'

используя Python:

python -c 'import crypt; print crypt.crypt("your_password", "salt")'

Если кто предложит примеры на других языках — (perl, ruby) буду благодарен. Возможно для этого можно использовать утилиту mcrypt но я в ней не смог разобраться.

В завершение — вот простенькая веб-формочка для генерации htpasswd онлайн.

Все на localhost

Когда ты в одиночку разрабатываешь один единственный веб-сервис или сетевое приложение, то, как правило, вполне хватает локального домена localhost. Но что происходит, когда появляется необходимость разрабатывать и поддерживать одновременно два или более совершенно разных приложения? Сперва ты пытаешься рассовывать разные приложения по подпапкам одного домена вроде http://localhost/app1/ http://localhost/app2/ и т.д. Ок, при более-менее простых приложениях такой вариант еще может работать. Но когда возникает необходимость в привязке приложения к корню сайта в относительных внутренних ссылках, когда необходимы специфические настройки веб-сервера (например специфические реврайт-правила), то сложность и запутанность полученной системы крайне резко возрастает, начинают появляться различные баги и замедляется процесс разработки.

Файл hosts

Позже, изрядно помучавшись с однодоменным расположением проектов, вдруг узнаешь про существование волшебного файлика hosts (/etc/hosts) с помошью которого можно создавать для себя дополнительные «локалхосты», т.е. получаем возможность любое конкретное доменное имя направить на любой конкретный IP адрес. Отлично! Теперь можно разнести все свои «локалхосты» по отдельным «поддоменам» типа app1.loc app2.loc просто прописав в /etc/hosts (WINDOWS\system32\drivers\etc\hosts для виндов) всего пару строк
127.0.0.1 app1.loc
127.0.0.1 app2.loc
Выглядит просто и понятно, все записи под рукой, можно легко добавить и удалить нужный домен, изменения, как правило, вступают в силу мгновенно. В принципе этим можно ограничиться если у тебя не так много проектов, меняются они нечасто и ты работаешь над ними неторопясь и ОДИН. Но есть у такого подхода 2 существенных недостатка:

1. Для того чтобы к имени app1.loc добавить поддомен, например static.app1.loc допустим, для хранения статических файлов, приходится создавать в файле hosts дополнительную запись типа 127.0.0.1 static.app2.loc т.к. hosts файл не поддерживает wildcard формы записи — прописать в нем 127.0.0.1 *.app1.loc нельзя!
   Такую ситуацию еще можно терпеть если у вас действительно нужно добавить всего 1-2 поддомена, но что, если ваше приложение предоставляет своим пользователям отдельные поддомены? http://user.app1.loc, http://pi_es.seriyps.ru/, http://seriyps.habrahabr.ru/ ? Отладка такого проекта с использованием файла hosts становится практически невыполнимой задачей. Опять же при росте количества проектов файл hosts забивается мусором и в нем становится трудно что-то найти.
2. Если вы разрабатываете ваше приложение не в одиночку а целым офисом, в котором стоит девелоперский веб-сервер, то для того чтобы дать коллеге ссылку на домен из вашего файла hosts вам как минимум нужно будет убедиться что этот адрес есть и в его файле hosts. Согласитесь, это даже звучит смешно!

Свой девелоперский DNS сервер

Ну вот мы и добрались до самого праведного способа организации разработки интернет-приложения для доменов — это использование своего DNS сервера. Имеется в виду конечно не «каждому девелоперу — по DNS серверу» а установка централизованного DNS сервера для офиса. Хотя даже для единоличной разработки свой DNS все равно удобнее hosts файла хотя бы из за наличия wildcards. Собственно преимущества такого подхода очевидны:

1. Проект разрабатывается в той среде, в которой он будет использоваться в продакшене. Никаких посторонних файлов и настроек веб-сервера как в случае с расположением проектов в поддиректориях localhost
2. Настоящие доменные ЗОНЫ со всеми типами записей в т.ч. и wildcard… @, *, MX, CNAME и пр.
3. Все пользователи, прописавшие себе этот DNS (а если он включается автоматом по DHCP то все еще больше упрощается) смогут открывать ваши ссылки не задумываясь «a прописал-ли я ее себе в hosts файл..»

Устанавливаем и настраиваем DNS сервер.

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

Настройка простейшей dev зоны для DNS сервера BIND9 (named) на Ubuntu/Debian

Т.к. мы настраиваем DNS для небольшой сети «для своих», можно пренебречь некоторыми мерами безопасности. Например, мы не будем запускать bind в chroot окружении и не будем ограничивать подключение к ним с различных IP. К тому же для named уде при установке создаются вполне приемлемые правила для apparmor.
Для начала установим сам bind

sudo apt-get install bind9

В Ubuntu/Debian конфигурационные файлы Bind хранятся в директории /etc/bind, файлы, создаваемые при работе Bind хранятся в /var/cache/bind , главный конфигурационный файл bind находится по адресу /etc/bind/named.conf . В принципе, все опции можно вносить в него, но рекомендуется использовать для этого подключаемые файлы: named.conf.options — для настроек сервера и named.conf.local — для добавления зон. Таким образом нас интересуют именно эти файлы. Кстати, их синтаксис похож на C код, поэтому даже можно использовать подсветку синтаксиса C. Приступим:
Открываем файл /etc/bind/named.conf.options и приводим его содержимое к виду

options {
        directory       "/var/named";
	//раскомментировать строчки ниже, если хотим кешировать ответы DNS провайдера.. может немного "ускорить интернет"
	// forwarders {
	// 	192.0.2.1; IP адреса DNS провайдера из "cat /etc/resolv.conf" при подключенном интернете
	// 	192.0.2.2;
	// };
};

directory — указывает на директорию, в которой хранятся файлы сервера, такие как кеш, в forvarders можно добавить адреса DNS серверов вашего провайдера для кеширования их ответов и таким образом несколько сократить сетевые издержки на DNS запросы. Существует еще куча опций, но в нашем простейшем сервере они не нужны.
Прекрасно, общие настройки сделаны. Уже сейчас можно использовать наш сервер в качестве кеширующего DNS. Но нас интересует возможность создания и администрирования собственной зоны!
Открываем /etc/bind/named.conf.local и пишем в него

zone "dev" {
	type master;
	file "/etc/bind/db.dev";

};

type master означает что мы являемся единственным авторитетным источником информации о зоне dev, file указывает на расположение файла с информацией о зоне. Остается только создать этот файл
/etc/bind/db.dev

@ IN SOA dev. root.dev.    ( ; dev. - имя зоны, root.dev. - e-mail администратора зоны, в котором @ заменено на . т.е. это было root@dev но лучше вставить настоящий e-mail
        20100506        ; Серийный номер зоны. Обычно - текущая дата
        3h              ; обновление каждые 3 часа
        1h              ; повтор каждый час
        1w              ; информация хранится 1 неделю
        1d    )         ; TTL записи - 1 день

@   IN    NS    dev.        ; сервер имен. Рекомендую оставить как тут
@   IN    A  198.51.100.1       ; A - запись - IP адрес сервера для данной зоны (ваш девелоперский сервер). @ для имени домена означает "корень зоны"
*   IN    CNAME  @              ; CNAME запись. По сути - символическая ссылка. * для имени домена означает "любой поддомен".
                                  ; Т.е. при обращении на любой поддомен в зоне dev будет возвращаться IP 198.51.100.1
database IN A 198.51.100.2      ; Но поддомен database.dev будет расположен на другом IP адресе

Не забывайте ставить завершающие точки в имени домена!
Сохраняем, заставляем bind перечитать конфигурацию

sudo service bind9 reload

проверяем

nslookup any.dev

Server:		127.0.0.1
Address:	127.0.0.1#53

any.dev	canonical name = dev.
Name:	dev
Address: 198.51.100.1

nslookup database.dev

Server:		127.0.0.1
Address:	127.0.0.1#53

Name:	database.dev
Address: 198.51.100.2

В случае возникновения каких-то проблем смотрим syslog — как правило bind сообщает об ошибках именно туда.
Понятно что таким-же образом можно создавать или переопределять любые другие зоны — добавляется блок zone в named.conf.local и создается соответствующий файл с информацией зоны.

Использование DNS сервера

Сервер есть, осталось его подключить!

Ubuntu

Если вы не пользуетесь NetworkManager-ом, то достаточно в самое начало файла /etc/resolv.conf прописать ваш DNS сервер.
Если NetworkManager используется, открываем «Изменить соединения», выбираем нужное соединение (проводное, VPN, etc), открываем вкладку «Параметры IPv4″ и заменяем «Автоматически (DHCP)» на «Автоматически (DHCP, только адрес)», затем в поле «Серверы DNS» вписываем первым IP вашего DNS сервера и дальше через запятую ip адреса из /etc/resolv.conf
Переподключаем сеть.

Windows

В свойствах соединения в настройках TCP/IP прописываем первым наш DNS и после DNS провайдера.

Удачных экспериментов!
Почитать:
Официальный сайт bind
Кеширующий DNS сервер для локальной сети на основе BIND 9
Установка Bind (named) на CentOS
Установка и настройка DNS сервера bind9 Ubuntu-Debian HOWTO

Этот пакет утилит представляет из себя замену таким заслужившим почет и уважение утилитам, как route, ifconfig, arp, netstat (т.н. net-tools).

Особенно хочу в нем отметить структуру ввода команд — похоже на работу с GIT, но еще гибче — можно вместо названия команды ввести любое количество первых букв и, если не возникнет конфликтов, команда отработает как положено. Ну это так, лирическое отступление.

Вообще-же, если по честному, то есть мнение, что net-tools утилиты сейчас фактически существуют только для обратной совместимости. Плюс к этому, они не всегда корректно показывают и обрабатывают интерфейсы, настроенные утилитами более нового iproute2.

В то-же время iproute2 мало того, что полностью покрывают функционал net-tools утилит, но и поддерживают значительное количество новых возможностей сетевой подсистемы Linux!

Пара примеров под катом..

получим список сетевых адресов нашей системы
ip addr
(вывод будет немного похож на вывод ifconfig)
Получим таблицу маршрутов
ip route
(результат похож на route -n)
добавим адрес 192.168.35.110/24 на сетевой интерфейс eth0
sudo ip addr add 192.168.35.110/24 dev eth0
теперь наш компьютер будет принимать запросы сразу по двум IP адресам с одной сетевой карты! Т.е. у нас фактически теперь 2 IP адреса.
Хочу отметить, что ifconfig, например, этого факта не заметит и будет по-прежнему показывать только один адрес для eth0. Хотя соединения по .35.110 будут прекрасно приниматься и обрабатываться. Так что снова используем ip addr [show]
Удалим этот адрес
sudo ip addr del 192.168.35.110/24 dev eth0

Это только коротенький список примеров, довольно общирный мануал можно найти в переводе Linux Advanced Routing & Traffic Control HOWTO

Как видите, «интерфейс» тут интуитивно понятный, крайне дружелюбный и выполненный в одном стиле (вот уж не думал, что скажу такое когда-нибудь о консольной программе). Новых полезных возможностей просто гора, так что если вы все еще кипя… используете ifconfig и route, не теряйте время напрасно! Начните изучать и применять на практике iproute2 сейчас! Не пожалеете.

Первый вопрос, который напрашивается — ЗАЧЕМ?

Отвечаю — просто проект разрабатывался в моем локальном репозитории, а после заказчик попросил разместить его в SVN. Можно, конечно, сделать это все одним большим Initial коммитом, но хочется чтоб история тоже импортировалась. Так вот, допустим имеется SVN репозиторий https://svn.example.com/repos/someproject/ со стандартной иерархией

https://svn.example.com/repos/someproject/

—-/trunk
—-/tags
—-/branches

и локальный git репозиторий ~/workspace/someproject/ в котором находятся папочки

~/workspace/someproject/
—-/.git
—-/lib
—-/config
—-/…..

И мы хотим в SVN получить структуру

https://svn.example.com/repos/someproject/trunk/

—-/lib
—-/config
—-/…..

Для работы с SVN из GIT устанавливаем пакет git-svn

sudo apt-get install git-svn

Если делать по стандартной инструкции

cd ~/workspace/someproject/
git-svn clone https://svn.example.com/repos/someproject/trunk/ .
git svn rebase
git-svn dcommit

То появляется ошибка

Use of uninitialized value in concatenation (.) or string at /usr/bin/git-svn line 411.
Committing to …
Unable to determine upstream SVN information from HEAD history

Для исправления положения, после этой попытки, делаем следующее:
Убеждаемся, что версия GIT не ниже, чем 1.6.3

git --version

Если так, то командуем

git branch -a

который должен вывести что-то наподобие

* master
remotes/git-svn

Обратим внимание на строку remotes/git-svn (может отличаться)

Командуем:

git rebase --onto <strong>remotes/git-svn</strong> --root master

И вуаля:

git-svn dcommit

работает!! Коммиты пошли отправляться в SVN.

Если теперь выполнить

git log

То в каждом коммите будет дополнительно строка типа git-svn-id: https://svn.example.com/repos/someproject/trunk@49 78ca4877-544d-4e5c-8d06-6abf935*****

Еще раз, все команды по-порядку:

cd ~/workspace/someproject/ #переходим в папку проекта (в которой находится папка .git)
git-svn clone https://svn.example.com/repos/someproject/trunk/ . #"копируем" SVN репозиторий (на сам. деле при этом соответствующим образом конфигурируется GIT
git branch -a #смотрим название ветки remotes/blablabla
git rebase --onto remotes/git-svn --root master # remotes/git-svn берем из предыдущей команды
git-svn dcommit # копируем GIT репозиторий в SVN со всей историей коммитов и пр.

# File: config/email.yml
production:
  delivery_method: :smtp
  smtp_settings:
    address: "smtp.gmail.com"
    port: '587'
    domain: "smtp.gmail.com"
    authentication: :plain
    user_name: "your_email@gmail.com"
    password: "your_password"

То при попытке отправить пробный email http://redmine.example.com/admin/test_email, он выдает ошибку
Во время отправки письма произошла ошибка (530 5.7.0 Must issue a STARTTLS command first. 16sm1075274ewy.14 )
Причиной тому служит обязательное использование TLS шифрования при работе с почтовым сервером Gmail, которое Redmine из коробки не поддерживает.
Добавить такой функционал несложно…
Для начала установим плагин action_mailer_optional_tls
Если у вас установлен GIT, то просто в папке с установленным redmine выполняете команду

ruby script/plugin install git://github.com/collectiveidea/action_mailer_optional_tls.git

Иначе переходите на сайт http://github.com/collectiveidea/action_mailer_optional_tls , щелкаете Download source и распаковываете архив в vendor/plugins/ (чтобы получилась папка vendor/plugins/action_mailer_optional_tls с файлами init.rb и т.п.)

Приводите конфиг к виду

# File: config/email.yml
production:
  delivery_method: :smtp
  smtp_settings:
    address: "smtp.gmail.com"
    port: '587'
    domain: "gmail.com"
    authentication: :plain
    user_name: "your_email@gmail.com"
    password: "your_password"
    tls: true

Или, если пользуетесь службой Google apps для вашего домена example.com, то

# File: config/email.yml
production:
  delivery_method: :smtp
  smtp_settings:
    address: "smtp.gmail.com"
    port: '587'
    domain: "example.com"
    authentication: :plain
    user_name: "your_email@example.com"
    password: "your_password"
    tls: true

Перезапускаете сервер, например так (смотря как вы настраивали):

sudo service mongrel_cluster restart

И пользуетесь!

Настройка Ruby веб-сервера Mongrel

Сам по себе Nginx работать с Redmine не может, т.к. fcgi для redmine фактически нет, поэтому для начала настроим mongrel, и будем проксировать на него запросы из Nginx. (На самом деле я не знаю, зачем нужно настраивать mongrel, когда есть встроенный сервер webrick, но везде пишут про mongrel, я решил «не выделяться слишком»)

Так вот, устанавливаемые с помощью gem исполняемые файлы устанавливаются в папку /var/lib/gems/1.8/bin/, которая не включена в стандартный PATH, соответственно просто вызывать их из командной строки не получится. Чтобы это исправить, есть несколько путей. Сперва предлагаю сделать

export PATH=$PATH":/var/lib/gems/1.8/bin/"

— это добавит нужный путь в переменную PATH до окончания сессии. Уже сейчас можно запустить mongrel — находясь в домашней директории /home/redmine выполните

mongrel_rails start –p 3000 -e production

По адресу http://localhost:3000/ снова должен работать редмайн.

Если все ок — делаем доступными бинарники из /var/lib/gems/1.8/bin/ перманентно. Можно сделать их доступными для всех пользователей, сделав символические ссылки

sudo ln -s /var/lib/gems/1.8/bin/mongrel_rails /usr/bin/mongrel_rails
sudo ln -s /var/lib/gems/1.8/bin/rails /usr/bin/rails
sudo ln -s /var/lib/gems/1.8/bin/mongrel_cluster_ctl /usr/bin/mongrel_cluster_ctl

Можно добавить экспорт пути в PATH в файле /etc/profile

echo 'export PATH=$PATH":/var/lib/gems/1.8/bin/"' >> /etc/profile

Но я бы посоветовал просто добавить экспорт этого пути в PATH только для юзера redmine. Находясь в его домашнем каталоге выполните

echo 'export PATH=$PATH":/var/lib/gems/1.8/bin/"' >> .bashrc

И перелогиньтесь.

Теперь сгенерируем конфиг-файл для работы mongrel с redmine

mongrel_rails cluster::configure -e production -p 3000 -a 127.0.0.1 -N 2 -P /var/run/mongrel_cluster/mongrel.pid -c /home/redmine --user redmine --group redmine

Где -e production рабочее окружение Redmine, -p 3000 порт, на который будет слушать Mongrel, -a 127.0.0.1 IP адрес, на котором он будет принимать запросы, -N 2 количество запущенных процессов Mongrel, -P /var/run/mongrel_cluster/mongrel.pid адрес для записи pid файла  -c /home/redmine домашняя директория, —user redmine —group redmine имя и группа пользователя, от имени которого будет работать mongrel (настоятельно рекомендую эти настройки не менять!! разве что изменить количество запущенных процессов — каждый процесс занимает отдельный порт, начиная с указанного в -p и дальше). Советую попробовать

mongrel_rails cluster::configure --help

Для того, чтобы сервер запускался при перезапуске компьютера, сделаем следующее: создадим каталог /etc/mongrel_cluster и скопируем туда полученный конфиг

sudo mkdir /etc/mongrel_cluster
sudo cp /home/redmine/config/mongrel_cluster.yml /etc/mongrel_cluster/redmine.yml

Скопируем init.d файл для mongrel  в /etc/init.d

sudo cp /var/lib/gems/1.8/gems/mongrel_cluster-1.0.5/resources/mongrel_cluster /etc/init.d/
sudo chmod +x /etc/init.d/mongrel_cluster

И, на всякий случай, добавим в этот файл в начале (после комментариев, перед строкой CONF_DIR=/etc/mongrel_cluster) строчку export PATH=$PATH»:/var/lib/gems/1.8/bin/» и исправим USER=mongrel на USER=redmine

Пробуем:

sudo service mongrel_cluster start

Сервис должен запуститься и работать на 3000 порту.

Обновляем rc.d правила для автоматического запуска и остановки mongrel

sudo update-rc.d mongrel_cluster defaults

Теперь Mongrel будет самостоятельно запускаться при старте компьютера!

Настройка NGINX для проксирования Mongrel

В принципе практически ничем не отличается от настройки проксирования Apache, разве что, если у вас запущено больше одного процесса mongrel, нужно настроить апстрим для балансировки нагрузки:

upstream mongrel {
  server 127.0.0.1:3000;
  server 127.0.0.1:3001;
#и т.д., в зависимости от количества запущенных Mongrel
}
server {
        listen       80;
        server_name  redmine.yoursite.ru;
        root    /home/redmine/public;
        location / {
                try_files $uri @fallback;
        }
        location @fallback {
                proxy_pass     http://mongrel/;
                proxy_connect_timeout 15;
                proxy_redirect  off;
                proxy_set_header        Host    $host;
                proxy_set_header        X-Real-IP $remote_addr;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}

Сохраняем, перезапускаем Nginx, идем по адресу http://redmine.yoursite.ru

Кроме того, в большинстве инструкций описывается использование Apache в качестве веб-сервера. У меня для этой цели будет использован Nginx

Подготовка системы

Для начала установим минимально необходимые для работы Ruby пакеты

sudo apt-get install ruby rubygems ruby1.8-dev libgemplugin-ruby libgemplugin-ruby1.8  libruby-extras libruby1.8-extras rubygems1.8 libsqlite3-ruby libopenssl-ruby

Пакеты ruby,  ruby1.8-dev, libruby-extras, libruby1.8-extras нужны для работы самого руби, rubygemslib, gemplugin-ruby, libgemplugin-ruby1.8, rubygems1.8 нужны для установки Ruby библиотек из самого руби (эт такой руби-пакетный менеджер), libopenssl-ruby — для SSL, libsqlite3-ruby — для работы с sqlite3 базой данных. Хочу заметить, что это НЕОБХОДИМЫЙ МИНИМУМ пакетов.

Далее устанавливаем необходимые для работы Redmine Ruby — библиотеки через встроенный пакетный менеджер gem

sudo gem install -v=2.3.5 rails
sudo gem install i18n
sudo gem install mysql mongrel mongrel_cluster

mysql — C-библиотека для работы с MySQL базой данных (см UPD), rails — знаменитые RubyOnRails (таблица совместимости различных версий redmine с версиями rails есть тут), mongrel и mongrel_cluster — родной веб-сервер для Ruby веб-приложений, i18n — библиотека для перевода интерфейса.

Создание учетных записей

В принципе, этот шаг можно пропустить и использовать существующего пользователя, например www-data, но я крайне рекомендую все-же не полениться и, ради безопасности, проделать и эту часть инструкции.

Создаем нового пользователя с домашней директорией /home/redmine , и именем redmine

sudo useradd -d /home/redmine -m -s /bin/bash redmine ; sudo passwd redmine

После ввода этой команды придумайте пароль для нового пользователя и введите его в появившемся запросе.

Переключаемся на созданного пользователя

sudo su redmine ; cd ~

.

Загрузка и настройка Redmine

Если у вас есть GIT, то

git clone git://github.com/edavis10/redmine.git

Если нет:

svn co http://redmine.rubyforge.org/svn/trunk redmine

Можно в общем-то и tarball скачать тут http://rubyforge.org/frs/?group_id=1850:

wget http://rubyforge.org/frs/download.php/75097/redmine-1.2.1.tar.gz
tar -xzf redmine-1.2.1.tar.gz

Перемещаем полученные файлы в корень домашней директории и подчищаем мусор

mv redmine/* . ; rm -r redmine

Теперь нужно настроить соединение Redmine с базой данных… Redmine поддерживает работу с базами данных sqlite, mysql и postgre-sql. MySQL у меня на сервере есть, но его версия 5.1. Проблема в том, что текущая версия Ruby библиотеки не поддерживает работу с версией 5.1 сервера MySQL, поэтому я решил использовать sqlite3 базу данных. Так вот, копируем пример конфиг-файла

cp config/database.yml.example config/database.yml

И редактируем этот конфиг

nano config/database.yml

Меняем строки production на что-то вроде backup_production а строку test_sqlite3 на production, сохраняем. Т.е. вся база данных будет храниться в sqlite3 файле db/test.db (создастся автоматически)

После создаем некое рандомное значение, необходимое для кодирования Cookies

rake config/initializers/session_store.rb

Генерируем структуру базы данных

rake db:migrate RAILS_ENV="production"

Загружаем и импортируем в базу данных стандартные данные

RAILS_ENV=production rake redmine:load_default_data

Выставляем необходимые права доступа

mkdir tmp public/plugin_assets sudo chown -R redmine:redmine files log tmp public/plugin_assets sudo chmod -R 755 files log tmp public/plugin_assets

В принципе, теперь можно попробовать запустить:

ruby script/server webrick -e production

При этом запустится простенький веб-сервер по адресу http://localhost:3000/ Можно открыть в браузере, зайти под учеткой admin/admin, сменить пароль на нормальный. Для остановки сервера жмем Ctrl+C. Если хотите использовать redmine локально — на этом можно остановиться, а для совместной работы через интернет нужно настроить веб-сервер для работы с Ruby и Redmine. Как это сделать — см во 2-й части

UPD: для использования Redmine с базой данных MySQL необходимо установить драйвер MySQL для Ruby т.к. без этого будет выскакивать сообщение «!!! The bundled mysql.rb driver has been removed from Ruby 2.2″. Т.е. выполняем

sudo gem install mysql

Если при этом у вас появляется сообщение об ошибке типа

ERROR: Error installing mysql:
ERROR: Failed to build gem native extension.

/usr/bin/ruby1.8 extconf.rb
checking for mysql_query() in -lmysqlclient… no
checking for main() in -lm… yes
………..
*** extconf.rb failed ***

То нужно немного настроить окружение:

sudo apt-get install build-essential libmysqlclient-dev

Возможно понадобится libmysql-cil-dev пакет. После этого повторяем sudo gem install mysql и спокойненько пользуемся MySQL в качестве БД для Redmine.

Т.е. об отказе от промежуточного, в общем-то бесполезного слоя в виде апача между Nginx (http сервер) и PHP (application сервер)

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

Что имеем на данный момент:

Имеется домен с поддоменами, сервер на Ubuntu 9.10 с веб-сервером Nginx, который слушает 80 порт, и Апач с mod-php, висящий на localhost:8080 (в качестве прокси-бэкенда нгинкса). Для коннекта к апачу в /etc/nginx/sites-enabled лежит симлинк на файлик 100apache_proxy следующего содержания:

server {
listen       80;
server_name  seriyps.ru *.seriyps.ru localhost;
access_log  /var/log/nginx/apache_proxy.access.log;
location / {
	proxy_pass      http://localhost:8080;#проксируем данные на апач
	proxy_connect_timeout 15;#время ожидания ответа от апача - 15 секунд, можно больше
	proxy_redirect  off;
	proxy_set_header	Host    $host;#Ставим HTTP заголовок Host
	proxy_set_header	X-Real-IP $remote_addr;#Заголовок X_Real-Ip т.к. внешние запросы принимает NGINX а апачу достаются в качестве IP только 172.0.0.1
	proxy_set_header	X-Forwarded-For $proxy_add_x_forwarded_for;#то-же самое
}

В итоге хотим:

ПЛАВНО перейти с использования apache прослойки на полное использование nginx<->php-fcgi с минимальными простоями сервера.

Приступим!

Настройка PHP для работы в режиме fast-CGI

Для начала поставим пакет php5-cgi (он нужен для использования PHP отдельно от apache)

sudo apt-get install php5-cgi

Затем ставим пакетик spawn-fcgi Эта утилитка нужна для удобного управления fast-cgi процессами независимо от веб-сервера.

sudo apt-get install spawn-fcgi

После чего создаем скрипт для запуска php5-fcgi процесса через spawn-fcgi

#!/bin/sh
### BEGIN INIT INFO
# Provides:          php5-fcgi
# Required-Start:    $all
# Required-Stop:     $all
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts the php5-cgi in fast-cgi mode
# Description:       configure and starts php5-cgi processes in fast-cgi mode using spawn-fcgi
### END INIT INFO

PATH=/sbin:/bin:/usr/sbin:/usr/bin
SCRIPTNAME="/etc/init.d/php5-fcgi"

FCGI_PIDFILE="/var/run/spawn-php5-fcgi.pid"
## Абсолютный путь до spawn-fcgi
FCGI_DAEMON="/usr/bin/spawn-fcgi"

## php переключится на этого юзера и группу (делать такими-же, как у апача)
USER=www-data
GROUP=www-data
## Абсолютный путь до  php
FCGI_PROGRAM="/usr/bin/php5-cgi"
## Количество запущенных процессов PHP-fcgi, см http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs:PerformanceFastCGI#How-many-PHP-processes-do-I-need
PHP_FCGI_CHILDREN=10
## максимальное количество запросов, которое обработает отдельный PHP - fcgi процесс до своего перезапуска
PHP_FCGI_MAX_REQUESTS=1000
## TCP порт, который будет слушать php-fcgi
FCGI_PORT="9000"
## IP адреса, по которым будет доступен PHP-fcgi (через запятую)
FCGI_IP="127.0.0.1"

test -x $FCGI_PROGRAM || exit 0
test -x $FCGI_DAEMON || exit 0

set -e

export PHP_FCGI_CHILDREN PHP_FCGI_MAX_REQUESTS

. /lib/lsb/init-functions

case "$1" in
  start)
        log_daemon_msg "Starting spawn-fcgi"
        if ! $FCGI_DAEMON -a $FCGI_IP -p $FCGI_PORT -f $FCGI_PROGRAM -u $USER -g $GROUP -C $PHP_FCGI_CHILDREN -P $FCGI_PIDFILE; then
            log_end_msg 1
        else
            log_end_msg 0
        fi
        RETVAL=$?
  ;;
  stop)
        log_daemon_msg "Killing all spawn-fcgi processes"
	start-stop-daemon --stop --pidfile $FCGI_PIDFILE --signal 2 & log_end_msg 0 || log_end_msg 1
        #if killall --signal 2 php5-cgi > /dev/null 2 > /dev/null; then
        #    log_end_msg 0
        #else
        #    log_end_msg 1
        #fi
        RETVAL=$?
  ;;
  restart|force-reload)
        $0 stop
        #sleep 1
        $0 start
  ;;
  *)
        echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
        exit 1
  ;;
esac

exit $RETVAL

Этот скрипт — несколько адаптированная версия скрипта из примера в документации сервера lighttpd http://redmine.lighttpd.net/projects/lighttpd/wiki/ScriptsUbuntu приспособленная для работы с rc.d правилами Ubuntu/Debian. Можно сделать попроще — см http://redmine.lighttpd.net/projects/spawn-fcgi/wiki/Basic_Ideas но в таком случае за перезапуском PHP при загрузке придется следить самостоятельно

Сохраняем этот скрипт как /etc/init.d/php5-fcgi и даем права на исполнение:

sudo chmod +x /etc/init.d/php5-fcgi

Обновляем правила rc.d для автоматического запуска php5-fcgi при старте системы:

sudo update-rc.d php5-fcgi defaults

Запускаем:

sudo service php5-fcgi start

spawn-fcgi: child spawned successfully: PID: 23620

Проверяем:

ps xa | grep php5-cgi

Должен выдать что-то вроде

23620 ?        Ss     0:00 /usr/bin/php5-cgi
23622 ?        S      0:00 /usr/bin/php5-cgi
23623 ?        S      0:00 /usr/bin/php5-cgi
23624 ?        S      0:00 /usr/bin/php5-cgi
23625 ?        S      0:00 /usr/bin/php5-cgi
23626 ?        S      0:00 /usr/bin/php5-cgi
23627 ?        S      0:00 /usr/bin/php5-cgi
23628 ?        S      0:00 /usr/bin/php5-cgi
23629 ?        S      0:00 /usr/bin/php5-cgi
23630 ?        S      0:00 /usr/bin/php5-cgi
23631 ?        S      0:00 /usr/bin/php5-cgi

Если вы видите то-же самое, значит, скорее всего, все сделано правильно! Обратите внимание на процесс 23620 ? Ss 0:00 /usr/bin/php5-cgi — это что-то наподобие мастер-процесса, он является родителем для остальных процессов php5-cgi. Убиваем его — убиваем все процессы php5-cgi.
Первая часть настройки закончена!

Настройка Nginx для работы с php-fcgi

Тут все просто (если не нужно настраивать url-rewrite правила).
В папочке /etc/nginx/sites-available создаем файлик, например 20yourdomain.com примерно следующего содержания:

#/etc/nginx/sites-available/20yourdomain.com
server {
	listen   80;
	server_name  yourdomain.com;

	access_log  /var/log/nginx/yourdomain_com.log;
	root   /var/www/yourdomain.com;
	index  index.php index.html index.htm;

	# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9090
	#
	location ~ \.php$ {
		fastcgi_pass   127.0.0.1:9000;
		fastcgi_index  index.php;
		fastcgi_param  SCRIPT_FILENAME  /var/www/yourdomain.com$fastcgi_script_name;
		include fastcgi_params;
	}
	# deny access to .htaccess files, if Apache's document root
	# concurs with nginx's one
	location ~ /\.ht {
		deny  all;
	}

}

(места, выделенные жирным шрифтом замените на ваши данные)

Создаем на него символическую ссылку в /etc/nginx/sites-enabled

sudo ln -s /etc/nginx/sites-available/<strong>20yourdomain.com </strong>/etc/nginx/sites-enabled/<strong>20yourdomain.com</strong>

Проверяем правильность конфига

sudo service nginx configtest

Testing nginx configuration: the configuration file /etc/nginx/nginx.conf syntax is ok
configuration file /etc/nginx/nginx.conf test is successful
nginx.

Готово! перезапускаем Nginx

sudo service nginx restart

и наслаждаемся! При необходимости проделываем эту процедуру для каждого поддомена, добавляем правила URL-rewrite и наслаждаемся еще больше.