Вечер прогулок по городу, ночь в гостинице и вот он - второй день конференции. Решил доклады не пропускать (не зря же 12 часов в поезде ехал!) и пошел сразу на первый доклад.

(далее...)

Давненько не бывал на конференциях, наконец-то удалось совместить наличие хорошей конференции с возможностью на нее пойти. И так, 13 и 14-го апреля в г. Ульяновск проходила конференция "Стачка!" на которой я имел удовольствие поприсутствовать. Сразу отмечу, что несмотря на то, что конференция была бесплатной, уровень организации и качество докладов были на уровне вполне известных платных конференций. Выбрали отличное живописное место, организовали онлайн трансляцию (на сайте выложены архивы с видео докладов). Спасибо организаторам, постарались на славу!

 

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

TL;DR: теперь подключаться к L2TP VPN можно через NetworkManager.

Допилил сегодня плагин для 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 ORM вне контекста самой Django. Конечно, проще и правильнее было бы использовать SQLAlchemy т.к. она рассчитана на такое использование, но мне нужно было написать паука, сохраняющего данные в БД и веб-интерфейс к этим данным. Веб-интерфейс точно решил делать на Django, а в пауке использовать те-же самые модели, чтобы не проделывать одну и ту же работу дважды. Т.к. паук был первым этапом работ а админка - вторым, появилась необходимость создавать таблицы из моделей без использования "syncdb".

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

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

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

(далее...)

Вступление

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

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

Побывал 23-24 сентября на конференции Application developer days в Ярославле. Вот решил написать краткий отчет. (далее...)

Вступление

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

В принципе это тривиальная операция описанная в документации к Nginx, но немного усложняет этот процесс необходимость создавать htpasswd файл, причем в самом Nginx средств для его создания нет (и это правильно), но предлагается создавать его используя утилиту htpasswd  входящую в состав Apache. Что самое смешное, на многих серверах, где используется Nginx, апача нет и не ожидается. Более того, большинство администраторов хостингов, "познавших" для себя Nginx начинают нескрываемо недолюбливать апач и верят, что наступит тот час, когда для Nginx наконец сделают аналог htaccess и апач, исправно служивший им долгие годы, наконец-то сгинет в небытие. Чтобы исправить сей досадный факт, добавлю в статью онлайн-формочку для генерации 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.1static.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!

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

(далее...)

В статье кратко описано как импортировать существующий GIT репозиторий в чистенький SVN со всей историей коммитов и пр.

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

Отвечаю - просто проект разрабатывался в моем локальном репозитории, а после заказчик попросил разместить его в SVN. Можно, конечно, сделать это все одним большим Initial коммитом, но хочется чтоб история тоже импортировалась. (далее...)

Проблема в том, что если настроить уведомления по email через smtp стандартным методом:

# 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 из коробки не поддерживает.
Добавить такой функционал несложно... (далее...)

Продолжение статьи Установка Redmine на Ubuntu 9.10 под Nginx (далее...)

Redmine - это довольно популярная в последнее время платформа для управления проектами и отслеживания ошибок. По идее, его установка - стандартная процедура, но мне, как совершенно незнакомому с Ruby и тонкостями установки Ruby софта пришлось повозиться.

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

(далее...)

Если быть точным, опишу переход с режима работы Nginx <-> Apache backend на Nginx <-> php-fcgi backend.

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

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

(далее...)