Гм. Немного не понял о чем Вы. В приведенной конфигурации вам достаточно прописать одну строчку в вашем ДНС сервере и все - как только создается новая папка - новый поддомен уже доступен. Даже не надо перезагружать nginx
не понял немного. Т.е. я например регистрирую домен president.org.ua у Вас на сайте и он на лету становится доступным? ИМХО малореально - как минимум из-за задержек обновления DNS по всему миру+регистрация не моментальный процесс.
Если я Вас не понял - поясните на примере :)
Задержки обновления ДНСа - это другое. Я говорю о возможности добавления домена к nginx без его перезагрузки. Создал папку "president.org.ua" и сервер уже может отвечать на запросы к этому домену.
а в чем проблема-то. Только что проверил вот-так - работает: http://paste.org.ru/?9br60m . Т.е. пишу xanf.org.ua - сервер лезет в папку /usr/www/xanf.org.ua/
да и почему на один и тот же скрипт. У нас на подобной системе обитают совершенно разные поддомены. Всего-то делов:
fastcgi_param SCRIPT_FILENAME /usr/www/example.com/$subdomain/$fastcgi_script_name;
Итак, товарищи! Как все Вы прекрасно понимаете подобный способ накладывает некоторые ограничения!
Например, особенно неприятно, что невозможно, без квадратоколёсных велосипедов, создавать свои поддомены. Типа forum.mysite.com.
И что же делать, спросите Вы?
Так всё просто!
* Apache уже давно научился перечитывать конфигурационные файлы, без перезагрузки.
* У Apache есть отличная директива Include (http://httpd.apache.org/docs/2.0/mod/core.html#include).
Выносим с помощью Include место с виртуальными хостами куда нам надо. Обрабатываем скриптово. После чего выполняем команду apachectl graceful.
Но, можем пойти ещё дальше! Как? Да просто, дать пользователю возможность прикручивать свои домены к своему блогу (или что там у Вас?).
Например можно DNS записи хранить в какой-нибудь базе (MySQL, PostgreSQL etc). А туда их загонять скриптом, дописав чуток веб-интерфейс. При этом демон named можно так же заставлять перечитывать конфиги после отработки MySQL запроса, либо по расписанию в crontab.
Для этого надо исполнить следующие команды:
$ps aux | grep имя_процесса_вашего_named_демона
$kill -HUP
Если говорить о ручном управлении, то все сводиться, в случае управления зоной, к редактированию файла конфигурации. named синтаксис там простой, и если когда-нибудь Вы управляли зоной скажем у регистратора какого-нибудь, то Вам не составит труда по аналогии разобраться и со своей.
как раз собирался статью написать на эту тему но я чёто в слишкомглубоком минусе, надеюсь, из комментария тоже суть понятна.
Гм. Ну метод с include понятен и прост как апельсин. Про ДНС записи - зачем? Ведь давно есть формат * IN A 1.2.3.4 позволяющий завернуть все поддомены неявно описанные на один IP. Да и в предложенной мною конфигурации для создания нового поддомена автоматически ничего не надо - просто добавь воды создай папку
Про DNS записи я говорил для доменов пользователей (допустим хочу я к используемому сервису прикрутить свой домен второго уровня) - тут без правки DNS никак.
Ваш способ прост и понятен, но имеет недостаток, о котором я писал выше геморрой с зарезервированными именами (forum, static etc). Раньше так же как и вы заворачивал все поддомены на основной а там уже разбирался. Меня такой способ больше не устраивает.
Да, если вы даете юзеру доменное имя вида user.example.org - то с форумом уже не выйдет (вспомним хабр с его ns1). Но я не понимаю как предложенный Вами метод помогает решать эту проблему.
Мы скриптом прописываем виртуальные хосты пользователей в конфиг веб-сервера.
pratevara, не в этом дело! дело в том, что все поддомены форвардятся в одно и тоже место (на какую-нибудь папку с блоговским движком, где уже по имени домена происходит определение того, чей это блог).
наилучший способ, имхо, записывать ручками поддомены пользователей в virtualhosts апачевского конфига и затем перечитывать конфиг. Только я не знаю одного, насколько долго будут перечитываться конфиги апача в случае с 10 тысячами поддоменов...
На боевом шареде использую технологию подобную virtualdocroot для апача только в нгинкс для отдачи с статичного контента и проксирования динамических страниц в апач2. Данная схема работает уже около года без нареканий и переписываний логики в конфигах веб серверов.
Апач занимается обработкой динамических страниц а nginx статикой и проксированием динамики с возможностью распределения нагрузки (балансировки) среди апачей. (в представленных ниже конфигах балансировка не используется)
Рассмотрим некоторые принципы работы nginx для шаред хостинга.
Конфигурация -> http://trash.pronskiy.ru/shared/nginx.conf
Клиентские директории выглядят таким образом:
/home/namedomain/www.namedomain.ru/www
/home/namedomain/www.namedomain.ru/logs
Также существуют служебные поддомены для каждого домена у клиента: mysql.namedomain.ru, mail... и тд. для них в апаче прописаны виртуалхосты с директивами serveralias mysql.* и соответствующим докрутом.
Виртуалхост клиента -> http://trash.pronskiy.ru/shared/namedomain-apache2.conf
Я нарочно не стал менять домен внутри виртуалхоста. Вы можете зайти по адресу указанному в servername и протестировать работу некоторых локейшнов описаных в nginx ;-)
nginx, пользовательские поддомены и rewrite