Comments 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
UFO just landed and posted this here
UFO just landed and posted this here
По-моему, проще парсить SERVER_NAME в php на лету, выцепляя поддомен, а в nginx'е только лишь alias * указать.
0
ИМХО это два подхода к решению одной проблемы. Хотя мне больше нравится метод с nginx - т.к. в поддоменах могут обитать не только PHP-скрипты
+1
UFO just landed and posted this here
Итак, товарищи! Как все Вы прекрасно понимаете подобный способ накладывает некоторые ограничения!
Например, особенно неприятно, что невозможно, без квадратоколёсных велосипедов, создавать свои поддомены. Типа 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
Only those users with full accounts are able to leave comments. Log in, please.
nginx, пользовательские поддомены и rewrite