Комментарии 104
Спасибо, очень полезно!
А для других серверов, например, Apache?
Apache никаким образом не должен быть на передовой
Что первое приходит на ум, это, конечно, mod_rewrite, но там всё получается довольно муторно и неэфективно, так что даже особо задумываться про это не хочется
Что первое приходит на ум, это, конечно, mod_rewrite, но там всё получается довольно муторно и неэфективно, так что даже особо задумываться про это не хочется
и все же поделитесь решением для Апаче.
В апаче все тоже просто, нужно перевести домейн по принципу wildcard на ваш хостинг,
на хостинге направить весь домен в корневую директорию домена
и в .htaccess прописать вот это:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^([^\.]+)\.someblog\.com$ [NC]
RewriteCond %{HTTP_HOST} !^www\.someblog\.com$ [NC]
RewriteRule ^(.*)$ index.php?user=%1 [L,QSA]
После этого, при обращении к саб-домену, например, bob.someblog.com вы получаете
переменную $user='bob'; в index.php, а дальше все просто
на хостинге направить весь домен в корневую директорию домена
и в .htaccess прописать вот это:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^([^\.]+)\.someblog\.com$ [NC]
RewriteCond %{HTTP_HOST} !^www\.someblog\.com$ [NC]
RewriteRule ^(.*)$ index.php?user=%1 [L,QSA]
После этого, при обращении к саб-домену, например, bob.someblog.com вы получаете
переменную $user='bob'; в index.php, а дальше все просто
а что мешает разобрать HTTP_HOST в самом PHP?
Полезненько :)
Спасибочки.
Спасибочки.
Спасибо, полезно для всех. В данном случае не нужно создавать пользовательские директории, и обработка ведется на уровне PHP и mod_rewrite
Как раз хотел предложить тот же самый вариант, который использую у себя на одном из проектов. Не муторно и вполне себе эффективно :).
>переменную $user
Откуда? Смотрим глобальную $_GET['user']
Откуда? Смотрим глобальную $_GET['user']
для Apache основное это указать перенаправление всех суб-доменов на основной домен (если как на хабре)
а далее уже (на примере php) сам суб-домен можно уже через REQUEST_URI разбирать, ибо незачем плодить дополнительные переменные на уровне mod_rewrite
а далее уже (на примере php) сам суб-домен можно уже через REQUEST_URI разбирать, ибо незачем плодить дополнительные переменные на уровне mod_rewrite
как человек умеющий пользоваться предоставленными ссылками спасаю вас http://server-tuning.info/apache/auto-subdomains.html
Почему?
тяжеловат
Тем не менее Апач обслуживает 50% серверов прямо на передовой.
при малом количестве статики и большом динамики - зачем что-то еще?
Пожалуй, внесу в текст поправку: имеется виду определённый класс проектов, где без nginx никуда.
Другое дело. Потому что первый камент попахивает фанатизмом: пихать nginx куда ни попадя - это то же самое, что использовать для всех целей Apache. Думаю, все согласятся, что для каждой задачи есть свои лучшие решения.
Ну да, есть такой момент "со своей колокольни" :-)
Я, по правде сказать, уже плохо понимаю, как что-то сделать без nginx, да и вообще уже, мне кажется, это дефакто для серьёзных проектов.
Апача у нас скоро не будет вообще.
Я, по правде сказать, уже плохо понимаю, как что-то сделать без nginx, да и вообще уже, мне кажется, это дефакто для серьёзных проектов.
Апача у нас скоро не будет вообще.
Не знаю, где это "у нас" :), но Апач будет всегда - nginx всё-таки придуман для быстрой отдачи статики, и как бы к нему не прикручивали модули сбоку, скорее это будет извращением, чем использование признанных модулей для Апача. mod_perl + Апач - великолепная связка, которую никогда не заменит nginx.
И посмотрите как-нибудь "голенький" Апач 2.2 - с отключенными лишними модулями. Удивитесь :).
И посмотрите как-нибудь "голенький" Апач 2.2 - с отключенными лишними модулями. Удивитесь :).
Речь о nginx+fastcgi. Эксперементально проверили: автокадабра работает без проблем.
И толку от голого апача? Он жи нифига от nginxa и не будет отличаться - только статитку и отдаст.
Nginx + FastCGI эффективнее, но для его использования, нужны большие знания, чем для апача. Так что апач не умрёт. Он будет использоваться и дальше на сайтах средней и низкой тяжести
Nginx + FastCGI эффективнее, но для его использования, нужны большие знания, чем для апача. Так что апач не умрёт. Он будет использоваться и дальше на сайтах средней и низкой тяжести
Для апача можно делать так:
Вместо DocumentRoot пишем VirtualDocumentRoot /var/www/%-3+
Про описание параметров можно почитать тут http://httpd.apache.org/docs/2.0/mod/mod…
Вместо DocumentRoot пишем VirtualDocumentRoot /var/www/%-3+
Про описание параметров можно почитать тут http://httpd.apache.org/docs/2.0/mod/mod…
Ничего не понял, но круто :)
Это чтоли в привязке к какому-то движку?
зачем проксировать домен на папку?
зачем проксировать домен на папку?
Чтобы не выделять этому домену отдельный ip
Причем здесь IP?
Представь, что каждому адресу name1.host.com, name2.host.com, ... ,nameN.host.com пришлось бы выделять отдельную машину и адрес - затратно и нерационально. А так все данные лежат на сервере в директориях типа host.com/users/name1 и т.д., что более удобно для администрирования ресурса, при том, что конечный пользователь ни о чем не подозревает.
Ну, как бы известно, что "по умолчанию" многие размещают пользовательские страницы таким образом, а как уже реализовать конечную обработку, это уже дело каждого в отдельности.
В разработанном нами движке, например, есть такая служебная директория, как [hole], таким образом работают адреса вида /users/bob/profile/. А в самом обработчике уже есть массив $holes, где последовательно хранятся всё то, что "провалилось" в папку hole.
То есть, на сервере обработчик находится по адресу /users/[hole]/profile/index.php, а при использовании данного метода, он доступен по адресу bob.someblog.com/profile/. При этом $holes[0] == 'bob'. От этого и определяются дальнейшие действия.
Но это всё только ради примера. Описанный выше способ можно прозрачно применить к множеству существующих проектов, так чтобы без каких-то хлопот пользовательские адреса превратились в поддомены.
В разработанном нами движке, например, есть такая служебная директория, как [hole], таким образом работают адреса вида /users/bob/profile/. А в самом обработчике уже есть массив $holes, где последовательно хранятся всё то, что "провалилось" в папку hole.
То есть, на сервере обработчик находится по адресу /users/[hole]/profile/index.php, а при использовании данного метода, он доступен по адресу bob.someblog.com/profile/. При этом $holes[0] == 'bob'. От этого и определяются дальнейшие действия.
Но это всё только ради примера. Описанный выше способ можно прозрачно применить к множеству существующих проектов, так чтобы без каких-то хлопот пользовательские адреса превратились в поддомены.
Ну вот, получается все-же в привязке к конкретному движку.
У меня, например в вашей терминологии в [hole] проваливается вообще все.
У меня, например в вашей терминологии в [hole] проваливается вообще все.
exit(header("Location: http://{$user}.domain.com/"));
сделает что-же самое.
сделает что-же самое.
У меня нет времени собирать адреса доменов, которые хранят пользовательские страницы на адресах вида /users/bob/.
Или может кто-то подумал, что если поменять
rewrite ^(.*)$ /users/$uid$1 break;
на
rewrite ^(.*)$ /silly/bots/$uid$1 break;
то всё сломается?
rewrite ^(.*)$ /users/$uid$1 break;
на
rewrite ^(.*)$ /silly/bots/$uid$1 break;
то всё сломается?
Я ничего против вашего метода не имею. Просто лично мне кажется нелогичным хоть как-то привязывать конкретный движек к настройкам сервера. Как и в комментариях выше - нагружать его лишними строчками в htacces, т.к. есть подозрения что лишняя строчка там тормозит гораздо больше чем разница между print и echo.
Это не будет работать, если DNS зона someblog.com не настроена для всех пользователей, которым вы желаете выдать поддомен.
user1 IN CNAME someblog.com.
user2 IN CNAME someblog.com.
...
user1 IN CNAME someblog.com.
user2 IN CNAME someblog.com.
...
Легче настроить конфиг Апача
А разве нижнее подчеркивание можно использовать в имени домена?
Оказывается все элементарно и просто, спасибо за пример с Apache'м
Разбор URL лучше всё таки делать на уровне приложения, в таком случае мы получим кросс-вебсерверность.
А на веб-сервере просто прописывается перенаправление всех запросов на скрипт обработчик.
А на веб-сервере просто прописывается перенаправление всех запросов на скрипт обработчик.
Может посоветуете простенький DNS-сервер, чтобы реализовать *.domain.local на ноуте. Ато забодался лазить в hosts.
Посоветую простенький скрипт, который правит hosts
Есть такой, но хочется "по настоящему" :)
А в чем проблема поставить BIND и в нем сделать свою зону с записью * ?
Типа такого:
Типа такого:
$ORIGIN domain.local.
@ 1H IN SOA ns.domain.local. hostmaster.domain.local. (
200611140 ; serial
7200 ; refresh
7200 ; retry
1W ; expiry
600 ) ; minimum
1H IN NS ns.domain.local.
* IN A 127.0.0.1
Если разберусь с этим http://www.wikihow.com/Build-Isc-Bind-Dn…
то обязательно поставлю. но моежт есть еще варианты (под винду)?
то обязательно поставлю. но моежт есть еще варианты (под винду)?
Под винду не в курсе - я только на юниксах днсы поднимал.
Поковыряю пока IdDNSServer в Delphi. Информации тоже 0, даже нет помощи, но кто-то ведь его написал.
Попробуйте Small HTTP Server, он кроме всего прочего является еще и небольшим DNS-сервером :)
Так на оффсайте свежая сборка под винды лежит:
http://www.isc.org/index.pl?/sw/bind/ind…
http://www.isc.org/index.pl?/sw/bind/ind…
Да бросьте. DNS для таких задач - это моветон :)
Вот еще простой батник который применяет изменения hosts
ipconfig /flushdns
nbtstat -R
ipconfig /flushdns
nbtstat -R
В составе denwer есть perl-скрипт, который при запуске обходит директорию веб-сервера, и прописывается все папки оттуда как локальные домены.
Например у вас есть сайт в папке C:\WebServers\localhost\aaa для него будут созданы такие записи в etc/hosts:
127.0.0.1 aaa.localhost
127.0.0.1 http://www.aaa.localhost
Например у вас есть сайт в папке C:\WebServers\localhost\aaa для него будут созданы такие записи в etc/hosts:
127.0.0.1 aaa.localhost
127.0.0.1 http://www.aaa.localhost
Есть такой свой:
1. смотрит папки.
2. смотрит базу.
3. прописывает при необходимости хоты которые инклудятся в httpd.conf
4. прописывает hosts
5. выводит нужные ссылочки на "стартовую страничку", там же обход "Избранного" с прописыванием ссылок и favicon'ов
Все что требуется: открыть браузер и если добавился сайт или пользователь - нажать F5. Но это неправильно :)
1. смотрит папки.
2. смотрит базу.
3. прописывает при необходимости хоты которые инклудятся в httpd.conf
4. прописывает hosts
5. выводит нужные ссылочки на "стартовую страничку", там же обход "Избранного" с прописыванием ссылок и favicon'ов
Все что требуется: открыть браузер и если добавился сайт или пользователь - нажать F5. Но это неправильно :)
Подскажите, пожалуйста, можно ли такую систему настроить у провайдера?
Или без доступа к настройкам самого апача не обойтись?
есть доступ до .htaccess .
Или без доступа к настройкам самого апача не обойтись?
есть доступ до .htaccess .
А есть ли подобные решения для IIS?
Спасибо, интересное решение. Мне как-то довелось помимо виртуальных хостов ещё и настраивать связку Apache + Tomcat, получилось довольно удобно. Если кому-то интересно, то могу описать данное решение более подробно.
=) с подобными задачами достаточно просто работает любой серверный язык, как уже было сказано. На php это может выглядеть примерно так:
<?
switch($_SERVER['HTTP_HOST']){
case 'www.site.ru':
case 'site.ru':{
echo 'index';
break;
}
case 'wiki.site.ru':{
echo 'wiki';
break;
}
default:{
echo 'user: '.$_SERVER['HTTP_HOST'];
break;
}
}
…
Соответственно заранее указать DNS`у, чтобы он принимал любые поддомены.
Но есть у меня задачка для nginx`а по-интереснее. Задача такая, в зависимости от домена писать разные переменные root окружения апача. Т.е.:
client1.dev.site.ru -> root=/usr/local/www/client1/
client2.dev.site.ru -> root=/usr/local/www/client2/
blabla.dev.site.ru -> root=/usr/local/www/blabla/
Причем желательно все это решить без реврайтов, ибо они тормозят.
<?
switch($_SERVER['HTTP_HOST']){
case 'www.site.ru':
case 'site.ru':{
echo 'index';
break;
}
case 'wiki.site.ru':{
echo 'wiki';
break;
}
default:{
echo 'user: '.$_SERVER['HTTP_HOST'];
break;
}
}
…
Соответственно заранее указать DNS`у, чтобы он принимал любые поддомены.
Но есть у меня задачка для nginx`а по-интереснее. Задача такая, в зависимости от домена писать разные переменные root окружения апача. Т.е.:
client1.dev.site.ru -> root=/usr/local/www/client1/
client2.dev.site.ru -> root=/usr/local/www/client2/
blabla.dev.site.ru -> root=/usr/local/www/blabla/
Причем желательно все это решить без реврайтов, ибо они тормозят.
Вот конфиг для nginx, где решена проблема с "www": http://server-tuning.info/nginx/auto-sub…
А вот для Apache: http://server-tuning.info/apache/auto-su…
Про настройку DNS тоже написано.
А вот для Apache: http://server-tuning.info/apache/auto-su…
Про настройку DNS тоже написано.
Про апаче - проблем в том, что не всегда есть доступ к httpd.conf, многие еще работают на обычном хостинге. В таком случае лучше уж все то же самое только .htaccess, со включенным mod_rewrite , или просто обрабатывать HTTP_HOST в самом PHP, как писали выше
Признаться да, моё решение устарело. Я делал это ещё тогда, когда нельзя было пользоваться произвольными переменными и ещё много чем
Отличный материал, спасибо!
Джукс, ты олдскул! :-)
сразу видно хорошие люди собрались в этом обсуждении: почти каждый комментарий с плюсиком!
тупо всех заплюсовали(жду минуса, нарушу закономерность :))) )
---
[a-z0-9_\-] — этот символьный класс определяется правилами регистрации пользователей, а именно набором допустимых символов, из которых может состоять имя.
---
Интересные имена со знаком "_" :) Особенно в поддоменах. IE не берет с такого домена куки, а опера ругается, что введенный урл не соответствет стандартам (потому что не соответствует) и не грузит страницу совсем. Или нет?
[a-z0-9_\-] — этот символьный класс определяется правилами регистрации пользователей, а именно набором допустимых символов, из которых может состоять имя.
---
Интересные имена со знаком "_" :) Особенно в поддоменах. IE не берет с такого домена куки, а опера ругается, что введенный урл не соответствет стандартам (потому что не соответствует) и не грузит страницу совсем. Или нет?
На сколько я помню, в рассылке не один раз говорилось о том, что использование условной конструкции не лучшее решеение. А тут и с реврайтом, и с регулярками...
Подскажите, реально ли «за одну минуту» реализовать эту возможность в рамках форума на движке IP.Board версии 2.3.5? К примеру, чтобы регистрации пользователя с ником Qwerty создавался поодомен qwerty.hostname.ru, а по этому адресу отображалось бы содержимое профайла пользователя.
все довольно просто, но за готовое решение - спасибо!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пользовательские поддомены