В принципе это тривиальная операция описанная в документации к Nginx, но немного усложняет этот процесс необходимость создавать htpasswd файл, причем в самом Nginx средств для его создания нет (и это правильно), но предлагается создавать его используя утилиту htpasswd входящую в состав Apache. Что самое смешное, на многих серверах, где используется Nginx, апача нет и не ожидается. Более того, большинство администраторов хостингов, “познавших” для себя Nginx начинают нескрываемо недолюбливать апач и верят, что наступит тот час, когда для Nginx наконец сделают аналог htaccess и апач, исправно служивший им долгие годы, наконец-то сгинет в небытие. Чтобы исправить сей досадный факт, добавлю в статью онлайн-формочку для генерации htpasswd фйла.
Continue reading
Author Archives: P.S.
Настраиваем девелоперский DNS сервер
Рассмотрим эволюцию организации работы веб-разработчика с несколькими проектами на разных адресах и поможем поскорее перескочить через первые ступеньки!
Все на 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 существенных недостатка:
- Для того чтобы к имени 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 забивается мусором и в нем становится трудно что-то найти. - Если вы разрабатываете ваше приложение не в одиночку а целым офисом, в котором стоит девелоперский веб-сервер, то для того чтобы дать коллеге ссылку на домен из вашего файла hosts вам как минимум нужно будет убедиться что этот адрес есть и в его файле hosts. Согласитесь, это даже звучит смешно!
Свой девелоперский DNS сервер
Ну вот мы и добрались до самого праведного способа организации разработки интернет-приложения для доменов – это использование своего DNS сервера. Имеется в виду конечно не “каждому девелоперу – по DNS серверу” а установка централизованного DNS сервера для офиса. Хотя даже для единоличной разработки свой DNS все равно удобнее hosts файла хотя бы из за наличия wildcards. Собственно преимущества такого подхода очевидны:
- Проект разрабатывается в той среде, в которой он будет использоваться в продакшене. Никаких посторонних файлов и настроек веб-сервера как в случае с расположением проектов в поддиректориях localhost
- Настоящие доменные ЗОНЫ со всеми типами записей в т.ч. и wildcard… @, *, MX, CNAME и пр.
- Все пользователи, прописавшие себе этот 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
Замена для ifconfig, route, arp, etc.: утилиты iproute2
Вот недавно познакомился с этим набором утилит…
Этот пакет утилит представляет из себя замену таким заслужившим почет и уважение утилитам, как route, ifconfig, arp, netstat (т.н. net-tools).
Особенно хочу в нем отметить структуру ввода команд – похоже на работу с GIT, но еще гибче – можно вместо названия команды ввести любое количество первых букв и, если не возникнет конфликтов, команда отработает как положено. Ну это так, лирическое отступление.
Вообще-же, если по честному, то есть мнение, что net-tools утилиты сейчас фактически существуют только для обратной совместимости. Плюс к этому, они не всегда корректно показывают и обрабатывают интерфейсы, настроенные утилитами более нового iproute2.
В то-же время iproute2 мало того, что полностью покрывают функционал net-tools утилит, но и поддерживают значительное количество новых возможностей сетевой подсистемы Linux!
Пара примеров под катом..
Импорт GIT репозитория в пустой SVN
В статье кратко описано как импортировать существующий GIT репозиторий в чистенький SVN со всей историей коммитов и пр.
Первый вопрос, который напрашивается – ЗАЧЕМ?
Отвечаю – просто проект разрабатывался в моем локальном репозитории, а после заказчик попросил разместить его в SVN. Можно, конечно, сделать это все одним большим Initial коммитом, но хочется чтоб история тоже импортировалась. Continue reading
Учим Redmine рассылать почту через Gmail
Проблема в том, что если настроить уведомления по 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 из коробки не поддерживает.
Добавить такой функционал несложно… Continue reading
Установка Redmine на Ubuntu 9.10 под Nginx часть 2
Продолжение статьи Установка Redmine на Ubuntu 9.10 под Nginx Continue reading
Установка Redmine на Ubuntu под Nginx
Redmine – это довольно популярная в последнее время платформа для управления проектами и отслеживания ошибок. По идее, его установка – стандартная процедура, но мне, как совершенно незнакомому с Ruby и тонкостями установки Ruby софта пришлось повозиться.
Кроме того, в большинстве инструкций описывается использование Apache в качестве веб-сервера. У меня для этой цели будет использован Nginx
Nginx + PHP-fcgi на Ubuntu
Если быть точным, опишу переход с режима работы Nginx <-> Apache backend на Nginx <-> php-fcgi backend.
Т.е. об отказе от промежуточного, в общем-то бесполезного слоя в виде апача между Nginx (http сервер) и PHP (application сервер)
Отдельно хочу заметить, что в этом руководстве мы обойдемся без компиляции чего-бы то ни было
SVN хак – пишу граббер
Сегодня на хабре был опубликован отчет об обнаруженной уязвимости (точнее о распространенной ошибке при работе через) SVN.
Суть его заключается в том, что если сайт разрабатывается через систему SVN, то многие разработчики вместо команды svn export просто копируют директорию проекта из рабочих файлов SVN на продакшн – сервер и забывают, что при этом копируются скрытые папки ./svn в том числе ./svn/entries – список содержимого каталога и ./svn/text-base/ в которой и находятся исходники с дополнительным расширением .svn-base В результате можно стянуть исходный код сайта, т.к. веб-сервер не всегда передает интерпретатору файлы с расширением .svn-base и они будут передаваться plaintext-ом
Так что, не теряя времени, написал на Python граббер для сайтов, которые еще не успели дыры закрыть…
Версия 0.5 – СКАЧАТЬ
Версия 0.4 – СКАЧАТЬ
Версия 0.3 – СКАЧАТЬ
Версия 0.2 – СКАЧАТЬ
Версия 0.1 – СКАЧАТЬ
Тюнинг PHP – установка XCache на Ubuntu
Каждый раз, когда вы открываете страничку динамического веб-приложения, веб-сервер обращается к PHP, который загружает запрошенный .php файл и все include и require, затем парсит их, компилирует в промежуточный байт-код (opcode) и исполняет. Причем в больших проектах процесс включения всех include файлов может занимать весьма продолжительное время.
Поэтому были разработаны многочисленные PHP-кешеры. Наиболее популярные из них – APC (Alternative PHP Cache), XCache и eAcelerator. Все они позволяют сохранять и повторно использовать скомпилированный байт-код PHP, что позволяет экономить время на сборку всех включений и их компиляцию, экономит процессорное время и оперативную память (причем весьма значительно). Помимо этого, они позволяют хранить в кеше переменные PHP и обращаться к ним при следующем вызове скрипта. Какой из этих кешеров использовать – не особо принципиально, по производительности они не сильно отличаются. Я выбрал XCache т.к. на него никто не ругается как на eAcelerator и я уже работал с APC и было интересно попробовать что-то новое Continue reading
Изучаю Python
Давно хотел изучить какой-нибудь новый для меня язык программирования. А то все PHP да JavaScript… Скучновато становится))
Собственно, самостоятельно начать было сложно, создал топик на Хабре чтобы поинтересоваться, что могут посоветовать по этому поводу бывалые программисты. В итоге к единому мнению не пришли, но почву для размышлений мне подкинули.
Приступим! Continue reading
Ubuntu 9.04 – решение частых проблем
Хоть Ubuntu 9.04 Jaunty вышла уже с месяц назад, но за это время успел встретиться с несколькими неприятными багами, с которыми благополучно справился. На всякий случай опишу эти баги и их “ремонт” Continue reading
Меняем favicon с помощью Jquery
Фавикон (иконка для веб-странички) добавляется таким тегом в HEAD страницы:
<link rel="shortcut icon" href="favicon.ico" type="image/x-icon" />
Если вдруг появится необходимость его динамически поменять, то, по аналогии с картинками, должно быть достаточно сменить href атрибут, но на самом деле браузеры на это никак не реагируют. Поэтому нужно удалить и создать заново этот тег.
Как это сделать на чистом JavaScript описано тут Управление иконками favicon из JavaScript – видим, что способ достаточно громоздкий.
В Jquery можно эту операцию проделать всего тремя строчками.
[codesyntax lang=”javascript”]function chFavicon(iconHref){
//получаем объект тега иконки
icon=$(":[rel=’shortcut icon’]");
//создаем копию объекта иконки
cache=icon.clone();
//меняем атрибут href на переданный функции
cache.attr("href", iconHref);
//переписываем тег иконки
icon.replaceWith(cache);
}[/codesyntax]
Протоколы прикладного уровня: Jabber/XMPP часть1
Прочитав статью и испробовав команды, научимся
–Соединяться с Jabber сервером
–Логиниться
–Менять статусы
–Отправлять сообщения
–Отключаться
И все это на чистом XML
В принципе, можно статью назвать “Введение в XMPP” или типа того… Но суть не изменится
Приступим-же! Continue reading
Попал на хабр
Угу, получил инвайт от “неизвестного доброжелателя”))
Просто опубликовал в песочнице немного переработанную статью про SMTP протокол, через пару дней пришло на мыло письмо со ссылкой на инвайт.