Hello!
On Thu, Mar 28, 2013 at 02:24:53PM +0400, denis wrote:
> 28.03.2013 2:38, Maxim Dounin пишет:
> >>Не думал, что порядок вставки инклюда с виртуалхостами влияет на к
> >>ним применение директив описанных в http { }
> >Я стесняюсь спросить - а что показывает nginx -V? В nginx'е из
> >коробки - влиять не должно, но сторонние модули такие модули.
> >
> Опыт показывает, что влияет очень сильно, вплоть до того, что
> поддомены приходилось описывать с именами вида 000_sub.domain, иначе
> первым видело основной блок и привет. (инклуд вида sites/*)
> Хотя явно столкнулись только с 1 версией, не помню уже какой, но
> теперь поддомены всегда называем так, чем ниже уровень, тем больше
> нулей.
> Более того, на 1 сервере даже игнорировались эти нули и файлы
> читались в порядке их создания. Явный баг был.
"Правда, только ... и не выиграл, а проиграл." (c)
В некоторых случаях порядок написания директив или блоков в
конфиге, действительно, важен. Так, при описании нескольких
виртуальных серверов на одном и том же listen-сокете по умолчанию
используется тот виртуальный сервер, что описан первым:
http://nginx.org/ru/docs/http/ngx_http_core_module.html#listen
: Если у директивы есть параметр default_server, то сервер, в
: котором описана эта директива, будет сервером по умолчанию для
: указанной пары адрес:порт. Если же директив с параметром
: default_server нет, то сервером по умолчанию будет первый сервер,
: в котором описана пара адрес:порт.
При этом директива include - не гарантирует какой-либо порядок
включения файлов при использовании масок, что плохо отражается на
работоспособности конфигов, использующих директиву include для
включения множества блоков server{} и при этом не использующих
параметр default_server директивы listen.
Очевидных решений два:
1) Не использовать include "вида sites/*". Вообще конфигурить
nginx одним файлом - гораздо приятнее и удобнее, а главное -
понятнее, особенно новичкам.
2) Расставлять "listen ... default_server" правильно.
Отдельно может доставить попытка использовать имена серверов,
заданные регулярными выражениями, ибо оные регулярные выражения -
проверяются в порядке описания в конфигурационном файле
(http://nginx.org/r/server_name/ru). Каковой порядок, как мы уже
выяснили выше, в случае "include sites/*" не определён.
Всё это относится к типичных ошибкам при конфигурировании nginx'а
вообще, и к проблемам использованного по умолчанию конфига во
многих пакетах в linux'е - в частности. И, без сомнения, может
являться причиной наблюдаемых проблем. Однако проблема в этом
случае - в неконсистентности конфига, загружаемого по "include
sites/*", а не в том, что стоит раньше, client_max_body_size - или
include.
> И кстати порядок имеет значение, и когда описываем limit_zone, и
> кэши, и proxy_pass...
> Очень грустно, что нет вывода итоговой конфигурации, сильно
> облегчило бы жизнь. Думаю, задача максимум в 10 строк решается,
> nginx-у делаем ключик типа апачевского -S и на него вывод.
Может быть, но в ситуации, когда порядок вообще говоря не
определён - подобный вывод только собъёт с толку.
--
Maxim Dounin
http://nginx.org/en/donation.html
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
