Вступление

Большую часть времени разработчики проводят в двух местах – в 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 сервер)

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

(далее…)

Сегодня на хабре был опубликован отчет об обнаруженной уязвимости (точнее о распространенной ошибке при работе через) SVN.

Суть его заключается в том, что если сайт разрабатывается через систему SVN, то многие разработчики вместо команды svn export просто копируют директорию проекта из рабочих файлов SVN на продакшн – сервер и забывают, что при этом копируются скрытые папки ./svn в том числе ./svn/entries – список содержимого каталога и ./svn/text-base/ в которой и находятся исходники с дополнительным расширением .svn-base В результате можно стянуть исходный код сайта, т.к. веб-сервер не всегда передает интерпретатору файлы с расширением .svn-base и они будут передаваться plaintext-ом

Так что, не теряя времени, написал на Python граббер для сайтов, которые еще не успели дыры закрыть…

Последняя версия – СКАЧАТЬ

Версия 0.4 – СКАЧАТЬ

Версия 0.3 – СКАЧАТЬ

Версия 0.2 – СКАЧАТЬ

Версия 0.1 – СКАЧАТЬ