Комментарии 27
Когда же появится пост об организации пользовательских доменов на лету? :)
+2
Гм. Немного не понял о чем Вы. В приведенной конфигурации вам достаточно прописать одну строчку в вашем ДНС сервере и все - как только создается новая папка - новый поддомен уже доступен. Даже не надо перезагружать nginx
0
Да. Но что насчёт именно доменов (не сабдоменов)?
0
не понял немного. Т.е. я например регистрирую домен president.org.ua у Вас на сайте и он на лету становится доступным? ИМХО малореально - как минимум из-за задержек обновления DNS по всему миру+регистрация не моментальный процесс.
Если я Вас не понял - поясните на примере :)
Если я Вас не понял - поясните на примере :)
0
Задержки обновления ДНСа - это другое. Я говорю о возможности добавления домена к nginx без его перезагрузки. Создал папку "president.org.ua" и сервер уже может отвечать на запросы к этому домену.
0
а в чем проблема-то. Только что проверил вот-так - работает: http://paste.org.ru/?9br60m . Т.е. пишу xanf.org.ua - сервер лезет в папку /usr/www/xanf.org.ua/
+1
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
По-моему, проще парсить SERVER_NAME в php на лету, выцепляя поддомен, а в nginx'е только лишь alias * указать.
0
ИМХО это два подхода к решению одной проблемы. Хотя мне больше нравится метод с nginx - т.к. в поддоменах могут обитать не только PHP-скрипты
+1
НЛО прилетело и опубликовало эту надпись здесь
Итак, товарищи! Как все Вы прекрасно понимаете подобный способ накладывает некоторые ограничения!
Например, особенно неприятно, что невозможно, без квадратоколёсных велосипедов, создавать свои поддомены. Типа 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 синтаксис там простой, и если когда-нибудь Вы управляли зоной скажем у регистратора какого-нибудь, то Вам не составит труда по аналогии разобраться и со своей.
как раз собирался статью написать на эту тему но я чёто в слишкомглубоком минусе, надеюсь, из комментария тоже суть понятна.
Например, особенно неприятно, что невозможно, без квадратоколёсных велосипедов, создавать свои поддомены. Типа 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 синтаксис там простой, и если когда-нибудь Вы управляли зоной скажем у регистратора какого-нибудь, то Вам не составит труда по аналогии разобраться и со своей.
как раз собирался статью написать на эту тему но я чёто в слишкомглубоком минусе, надеюсь, из комментария тоже суть понятна.
+2
Гм. Ну метод с include понятен и прост как апельсин. Про ДНС записи - зачем? Ведь давно есть формат * IN A 1.2.3.4 позволяющий завернуть все поддомены неявно описанные на один IP. Да и в предложенной мною конфигурации для создания нового поддомена автоматически ничего не надо - просто добавь воды создай папку
0
Про DNS записи я говорил для доменов пользователей (допустим хочу я к используемому сервису прикрутить свой домен второго уровня) - тут без правки DNS никак.
Ваш способ прост и понятен, но имеет недостаток, о котором я писал выше геморрой с зарезервированными именами (forum, static etc). Раньше так же как и вы заворачивал все поддомены на основной а там уже разбирался. Меня такой способ больше не устраивает.
Ваш способ прост и понятен, но имеет недостаток, о котором я писал выше геморрой с зарезервированными именами (forum, static etc). Раньше так же как и вы заворачивал все поддомены на основной а там уже разбирался. Меня такой способ больше не устраивает.
0
Да, если вы даете юзеру доменное имя вида user.example.org - то с форумом уже не выйдет (вспомним хабр с его ns1). Но я не понимаю как предложенный Вами метод помогает решать эту проблему.
З.Ы. Внес посильный вклад в Вашу карму
З.Ы. Внес посильный вклад в Вашу карму
0
*тупо* а почему не выйдет? Достаточно исключить возможность создания юзера forum к примеру, и проблема решена. Нет юзера - нет проблемы. :)
0
Мы скриптом прописываем виртуальные хосты пользователей в конфиг веб-сервера.
pratevara, не в этом дело! дело в том, что все поддомены форвардятся в одно и тоже место (на какую-нибудь папку с блоговским движком, где уже по имени домена происходит определение того, чей это блог).
наилучший способ, имхо, записывать ручками поддомены пользователей в virtualhosts апачевского конфига и затем перечитывать конфиг. Только я не знаю одного, насколько долго будут перечитываться конфиги апача в случае с 10 тысячами поддоменов...
pratevara, не в этом дело! дело в том, что все поддомены форвардятся в одно и тоже место (на какую-нибудь папку с блоговским движком, где уже по имени домена происходит определение того, чей это блог).
наилучший способ, имхо, записывать ручками поддомены пользователей в virtualhosts апачевского конфига и затем перечитывать конфиг. Только я не знаю одного, насколько долго будут перечитываться конфиги апача в случае с 10 тысячами поддоменов...
0
На боевом шареде использую технологию подобную virtualdocroot для апача только в нгинкс для отдачи с статичного контента и проксирования динамических страниц в апач2. Данная схема работает уже около года без нареканий и переписываний логики в конфигах веб серверов.
Апач занимается обработкой динамических страниц а nginx статикой и проксированием динамики с возможностью распределения нагрузки (балансировки) среди апачей. (в представленных ниже конфигах балансировка не используется)
Рассмотрим некоторые принципы работы nginx для шаред хостинга.
Конфигурация -> http://trash.pronskiy.ru/shared/nginx.conf
Клиентские директории выглядят таким образом:
/home/namedomain/www.namedomain.ru/www
/home/namedomain/www.namedomain.ru/logs
Поддомены:
/home/namedomain/pets.namedomain.ru/www
/home/namedomain/pets.namedomain.ru/logs
Также существуют служебные поддомены для каждого домена у клиента: mysql.namedomain.ru, mail... и тд. для них в апаче прописаны виртуалхосты с директивами serveralias mysql.* и соответствующим докрутом.
Виртуалхост клиента -> http://trash.pronskiy.ru/shared/namedomain-apache2.conf
Я нарочно не стал менять домен внутри виртуалхоста. Вы можете зайти по адресу указанному в servername и протестировать работу некоторых локейшнов описаных в nginx ;-)
Думаю с остальным сами разберётесь.
P.S Задонатте кармой если помог ;-]
Апач занимается обработкой динамических страниц а nginx статикой и проксированием динамики с возможностью распределения нагрузки (балансировки) среди апачей. (в представленных ниже конфигах балансировка не используется)
Рассмотрим некоторые принципы работы nginx для шаред хостинга.
Конфигурация -> http://trash.pronskiy.ru/shared/nginx.conf
Клиентские директории выглядят таким образом:
/home/namedomain/www.namedomain.ru/www
/home/namedomain/www.namedomain.ru/logs
Поддомены:
/home/namedomain/pets.namedomain.ru/www
/home/namedomain/pets.namedomain.ru/logs
Также существуют служебные поддомены для каждого домена у клиента: mysql.namedomain.ru, mail... и тд. для них в апаче прописаны виртуалхосты с директивами serveralias mysql.* и соответствующим докрутом.
Виртуалхост клиента -> http://trash.pronskiy.ru/shared/namedomain-apache2.conf
Я нарочно не стал менять домен внутри виртуалхоста. Вы можете зайти по адресу указанному в servername и протестировать работу некоторых локейшнов описаных в nginx ;-)
Думаю с остальным сами разберётесь.
P.S Задонатте кармой если помог ;-]
+3
зачётный номер статьи - 47777!
а вообще, нжикс - прикольный, но перед сном уже не воспринимается.
а вообще, нжикс - прикольный, но перед сном уже не воспринимается.
0
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
nginx, пользовательские поддомены и rewrite