Re: Сервер по-умолчанию для конкретного домена
http://nginx.org/ru/docs/http/configuring_https_servers.html#name_based_https_servers -- Igor Sysoev http://nginx.com On Nov 1, 2013, at 11:12 , Nikita A Kardashin wrote: Всем привет, Возникла задача: - На один nginx ссылаются 1 домена, при этом, для каждого из них должен быть доступен SSL (есть сертификаты). - Все запросы к несуществующим на сервере хостам должны попадать в некий хост по-умолчанию (и редиректиться оттуда rewrite-ом, но это частности). Т.е, поступает запрос. Если есть сервер, для которого запрошенный хост прописан в server_name - отправляем его туда. Если нет - в сервер по-умолчанию для domain.tld, откуда его регулярка отправляет по адресу (на главный сайт в зависимости от запрошенного домена). Классическая схема (сервера + один сервер с опцией default) прекрасно работала до тех пор, пока домен был один, а сейчас - не вариант, т.к. мы не можем прописать в сервере больше, чем 1 SSL-сертификат (в результате чего пользователь при обращении к несуществующему серверу по домену, отличному от первого вместо ожидаемого редиректа получает неожиданный FailedCertificateAlert от браузера и блокировку дальнейшего редиректа). Если же создать сервер с server_name = *.domain.tld для каждого домена, то туда попадают все запросы, даже те, для которых есть отдельные server-ы. Есть какой-то нормальный путь это обойти? Например, задавать приоритет серверу (тогда можно поставить минимальный умолчальному серверу и запрос таки будет улетать туда только тогда, когда более подходящих серверов нет). Или выбирать сертификат в зависимости от домена (по IF-у)? -- With best regards, differentlocal (www.differentlocal.ru | differentlo...@gmail.com), System administrator. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
upstream prematurely closed connection while reading response header from upstream
Вопрос, если в логе nginx появляется сообщение (раз в 10-20 обновлений страницы) upstream prematurely closed connection while reading response header from upstream и при этом на бэкенде в логах конкретно об этом запросе ни чего нет но предыдущие запросы и последующие запросы нормально логируются. Зачит куда нужно копать ? Я понимаю, что дело в бэкенде, тем более, что я менял бэкенд - со старым все работает нормально. Проверял работу через HTTPS поднятом на nginx c валидными сертификатами. Использовать для тестов 443 порт не могу, т.к. через него сейчас работают люди со старым сервером. Другой backend - очень старая версия redmine под apache и из старой ubuntu 10.04 Новый backend - lxc контейнер с новой версией redmine и новым apache из ubuntu 12.04 на том же же серевере где стоит прокси nginx. Спасибо. -- С Уважением, специалист по техническому и программному обеспечению, системный администратор Скубриев Владимир ~~~ Россия, Ростовская область, г. Таганрог тел. моб: +7 (918) 504 38 20 skype: v.skubriev icq: 214-800-502 www: skubriev.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Сервер по-умолчанию для конкретного домена
01.11.2013 14:07, Никита Кардашин пишет: Так, я, видимо, не очень правильно описал проблему. Попробую еще раз: - Есть домены: domain1.tld domain2.tld domain3.tld Сами главные домены хостятся где-то в другом, отличном от нашего сервера, месте. Для каждого из них есть wildcard SSL-сертификат. На нашем сервере хостятся приложения, доступные по поддоменам этих доменов (app1.domain2.tld, app10.domain3.tld, etc). Для каждого приложения создан конфиг в sites-enabled с описанием сервера (где задается и нужный SSL-сертификат, в зависимости от того, в каком домене находится приложение). Доступны они только по SSL (по сертификату *.domain.tld). Но иногда приложения удаляются, а ссылки на них где-то живут. Мне нужно каким-то образом реализовать возможность редиректить все запросы к адресам а-ля https://appX.domainX.tld/, в случае, если приложение уже не существует (т.е. сервер appX.domainX.tld не описан в конфиге nginx). Пока домен был один - я эту проблему решал просто, определил в конфиге один сервер с признаком default и там уже в location / осуществлял редирект на нужный сайт. Все прекрасно работало. А теперь сайтов стало три. В описании default-сервера я могу задать только одну пару сертификат:ключ, соответственно, те, кто придет по appX.domainX.tld (в случае, если домен отличается от того, чей сертификат прописан) в default-сервер получат в браузере ошибку (и не получат редирект). Прописать для каждого из доменов сервер с server_name *.domainX.tld я тоже не могу, т.к. тогда туда пойдут не только запросы к несуществующим приложениям, а вообще ВСЕ запросы (т.е. в приложение никто не попадет). Т.е. проблема моя не в том, что мне нужно иметь несколько SSL-сервисов на одном IP (это-то прекрасно работает, тут проблем нет), а в том, что мне нужно каким-то образом иметь несколько default-серверов с поддержкой SSL (либо иметь возможность задавать приоритеты серверам, чтобы запрос всегда попадал в более точный сервер (appX.domainX.tld), а не в wildcard *.domainX.tld). Как мне из этой ситуации выйти? Из документации Более общее решение для работы нескольких HTTPS-серверов на одном IP-адресе ---расширение Server Name Indication протокола TLS http://en.wikipedia.org/wiki/Server_Name_Indication(SNI, RFC 6066), которое позволяет браузеру передать запрашиваемое имя сервера во время SSL handshake, а значит сервер будет знать, какой сертификат ему следует использовать для соединения. Однако, поддержка SNI браузерами ограничена. Сейчас это поддерживается браузерами начиная со следующих версий: Другим способом является использование wildcard-сертификата, например|*.example.org|. Такой сертификат защищает все поддомены указанного домена, но только на заданном уровне. Под такой сертификат подходит|www.example.org|, но не подходят|example.org|и|www.sub.example.org|. Два вышеуказанных способа можно комбинировать. Сертификат может одновременно содержать и точное, и wildcard имена в поле SubjectAltName, например|example.org|и|*.example.org|. Боюсь что это не может быть, т.к. не могу все клиенты поддерживать SNI. -- С Уважением, специалист по техническому и программному обеспечению, системный администратор Скубриев Владимир ~~~ Россия, Ростовская область, г. Таганрог тел. моб: +7 (918) 504 38 20 skype: v.skubriev icq: 214-800-502 www: skubriev.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Управление бэкендами
Приветсвую Nginx стоит как frontend. За ним находится несколько десятков или более бэкендов (разные servername). Необходимо динамически управлять на какой бэкенд запрос упадет. Править nginx.conf и перечитывает его не вариант, т.к. это может происходить ежесекундно. Думал хранить соответствие servername - backend в memcached, но nginx похоже только умеет доставать http response и memcached. Остается только Nginx - Perl - Memcached. Или есть еще варинаты? lua? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Сервер по-умолчанию для конкретного домена
Today Nov 1, 2013 at 16:07 Никита Кардашин wrote: Прописать для каждого из доменов сервер с server_name *.domainX.tld я тоже не могу, т.к. тогда туда пойдут не только запросы к несуществующим приложениям, а вообще ВСЕ запросы (т.е. в приложение никто не попадет). http://nginx.org/r/server_name/ru При поиске виртуального сервера по имени, если имени соответствует несколько из указанных вариантов, например, одновременно подходят и имя с маской, и регулярное выражение, будет выбран первый подходящий вариант в следующем порядке приоритета: 1. точное имя 2. самое длинное имя с маской в начале, например .*.example.com. 3. самое длинное имя с маской в конце, например .mail.*. 4. первое подходящее регулярное выражение (в порядке следования в конфигурационном файле) Используйте точные имена в server_name для приложений или проследите дабы они были выше по конфигу чем с перенаправлением. -- WNGS-RIPE ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Управление бэкендами
Today Nov 1, 2013 at 14:23 Sergey Kobzar wrote: Приветсвую Nginx стоит как frontend. За ним находится несколько десятков или более бэкендов (разные servername). Необходимо динамически управлять на какой бэкенд запрос упадет. Править nginx.conf и перечитывает его не вариант, т.к. это может происходить ежесекундно. http://nginx.org/r/upstream_conf Одно но: This directive is available as part of our commercial subscription only. -- WNGS-RIPE ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Управление бэкендами
On Friday 01 November 2013 16:23:32 Sergey Kobzar wrote: Приветсвую Nginx стоит как frontend. За ним находится несколько десятков или более бэкендов (разные servername). Необходимо динамически управлять на какой бэкенд запрос упадет. Править nginx.conf и перечитывает его не вариант, т.к. это может происходить ежесекундно. Думал хранить соответствие servername - backend в memcached, но nginx похоже только умеет доставать http response и memcached. Остается только Nginx - Perl - Memcached. Или есть еще варинаты? lua? Самый лучший вариант - X-Accel-Redirect, смотрите например в описании директивы proxy_ignore_headers. http://nginx.org/r/proxy_ignore_headers/ru -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Управление бэкендами
On 11/01/13 14:28, Oleksandr V. Typlyns'kyi wrote: Today Nov 1, 2013 at 14:23 Sergey Kobzar wrote: Приветсвую Nginx стоит как frontend. За ним находится несколько десятков или более бэкендов (разные servername). Необходимо динамически управлять на какой бэкенд запрос упадет. Править nginx.conf и перечитывает его не вариант, т.к. это может происходить ежесекундно. http://nginx.org/r/upstream_conf Одно но: This directive is available as part of our commercial subscription only. Как вариант конечно... Вопрос к разработчикам: сколько стоит commercial subscription? Вот еще нашел то, что мне нужно: http://sosedoff.com/2012/06/11/dynamic-nginx-upstreams-with-lua-and-redis.html Но насколько lua модуль стабильный и выдерживает ли он high load. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Управление бэкендами
On Friday 01 November 2013 16:35:57 Sergey Kobzar wrote: On 11/01/13 14:28, Oleksandr V. Typlyns'kyi wrote: Today Nov 1, 2013 at 14:23 Sergey Kobzar wrote: Приветсвую Nginx стоит как frontend. За ним находится несколько десятков или более бэкендов (разные servername). Необходимо динамически управлять на какой бэкенд запрос упадет. Править nginx.conf и перечитывает его не вариант, т.к. это может происходить ежесекундно. http://nginx.org/r/upstream_conf Одно но: This directive is available as part of our commercial subscription only. Как вариант конечно... Вопрос к разработчикам: сколько стоит commercial subscription? [..] На сайте есть прайс: http://nginx.com/products/ и заказ онлайн https://cs.nginx.com/cart При желании, можно попросить trial. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Управление бэкендами
On 11/01/13 14:32, Валентин Бартенев wrote: On Friday 01 November 2013 16:23:32 Sergey Kobzar wrote: Приветсвую Nginx стоит как frontend. За ним находится несколько десятков или более бэкендов (разные servername). Необходимо динамически управлять на какой бэкенд запрос упадет. Править nginx.conf и перечитывает его не вариант, т.к. это может происходить ежесекундно. Думал хранить соответствие servername - backend в memcached, но nginx похоже только умеет доставать http response и memcached. Остается только Nginx - Perl - Memcached. Или есть еще варинаты? lua? Самый лучший вариант - X-Accel-Redirect, смотрите например в описании директивы proxy_ignore_headers. http://nginx.org/r/proxy_ignore_headers/ru Валентин, спасибо. Не совсем понял как это применить на практике. Т.е. мне все-равно нужно как-то динамически управлять на какой backend перенапрявлять запрос. P.S. Состоянием бэкендов управляет дополнительный сервер. На нем можно выдавать или состояние бэкенда или на какой бэкенд запрос перенаправить. Но что-то я не соображу как это дело применить... -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Управление бэкендами
On Friday 01 November 2013 16:41:47 Sergey Kobzar wrote: On 11/01/13 14:32, Валентин Бартенев wrote: On Friday 01 November 2013 16:23:32 Sergey Kobzar wrote: Приветсвую Nginx стоит как frontend. За ним находится несколько десятков или более бэкендов (разные servername). Необходимо динамически управлять на какой бэкенд запрос упадет. Править nginx.conf и перечитывает его не вариант, т.к. это может происходить ежесекундно. Думал хранить соответствие servername - backend в memcached, но nginx похоже только умеет доставать http response и memcached. Остается только Nginx - Perl - Memcached. Или есть еще варинаты? lua? Самый лучший вариант - X-Accel-Redirect, смотрите например в описании директивы proxy_ignore_headers. http://nginx.org/r/proxy_ignore_headers/ru Валентин, спасибо. Не совсем понял как это применить на практике. Т.е. мне все-равно нужно как-то динамически управлять на какой backend перенапрявлять запрос. P.S. Состоянием бэкендов управляет дополнительный сервер. На нем можно выдавать или состояние бэкенда или на какой бэкенд запрос перенаправить. Но что-то я не соображу как это дело применить... Зависит от того, что вам требуется. Как я первоначально понял ваш вопрос, требуется на каждый запрос решать на какой сервер он пойдет. В этом случае вы сначала с помощью proxy_pass/fastcgi_pass направляете запрос на скрипт/сервер/приложение/базу - который решает на какой бэкенд его отправить и возвращает в заголовках X-Accel-Redirect с указанием бэкенда. Далее у вас есть internal location, в котором тот же proxy_pass/fastcgi_pass с переменной и запрос отправляется на нужный сервер. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Управление бэкендами
On 11/01/13 14:47, Валентин Бартенев wrote: Зависит от того, что вам требуется. Как я первоначально понял ваш вопрос, требуется на каждый запрос решать на какой сервер он пойдет. Да - так и есть. В этом случае вы сначала с помощью proxy_pass/fastcgi_pass направляете запрос на скрипт/сервер/приложение/базу - который решает на какой бэкенд его отправить и возвращает в заголовках X-Accel-Redirect с указанием бэкенда. Тут понял. Далее у вас есть internal location, в котором тот же proxy_pass/fastcgi_pass с переменной и запрос отправляется на нужный сервер. А переменную как выковырять из ответа? -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Управление бэкендами
On Friday 01 November 2013 16:54:43 Sergey Kobzar wrote:
[..]
Далее у вас есть internal location, в котором тот же
proxy_pass/fastcgi_pass с переменной и запрос отправляется на нужный
сервер.
А переменную как выковырять из ответа?
Например так: возвращаете X-Accel-Redirect: /redirect_to/198.51.100.1
и он попадает в такой location:
location ~ ^/redirect_to/(?backend.+)$ {
internal;
proxy_pass http://$backend;
}
Если нужно сохранить оригинальный URI запроса, то это делается с помощью set:
set $original_uri $request_uri;
и proxy_pass в этом случает будет выглядеть так:
proxy_pass http://$backend$original_uri;
--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Управление бэкендами
On Friday 01 November 2013 17:02:43 Валентин Бартенев wrote:
On Friday 01 November 2013 16:54:43 Sergey Kobzar wrote:
[..]
Далее у вас есть internal location, в котором тот же
proxy_pass/fastcgi_pass с переменной и запрос отправляется на нужный
сервер.
А переменную как выковырять из ответа?
Например так: возвращаете X-Accel-Redirect: /redirect_to/198.51.100.1
и он попадает в такой location:
location ~ ^/redirect_to/(?backend.+)$ {
internal;
proxy_pass http://$backend;
}
Если нужно сохранить оригинальный URI запроса, то это делается с помощью
set:
set $original_uri $request_uri;
и proxy_pass в этом случает будет выглядеть так:
proxy_pass http://$backend$original_uri;
Альтернативный, и даже наверное лучший и более простой вариант всего этого:
использовать аналогичным образом модуль ngx_http_auth_request.
http://nginx.org/ru/docs/http/ngx_http_auth_request_module.html
--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Управление бэкендами
On 11/01/13 15:02, Валентин Бартенев wrote:
On Friday 01 November 2013 16:54:43 Sergey Kobzar wrote:
[..]
Далее у вас есть internal location, в котором тот же
proxy_pass/fastcgi_pass с переменной и запрос отправляется на нужный
сервер.
А переменную как выковырять из ответа?
Например так: возвращаете X-Accel-Redirect: /redirect_to/198.51.100.1
и он попадает в такой location:
location ~ ^/redirect_to/(?backend.+)$ {
internal;
proxy_pass http://$backend;
}
Если нужно сохранить оригинальный URI запроса, то это делается с помощью set:
set $original_uri $request_uri;
и proxy_pass в этом случает будет выглядеть так:
proxy_pass http://$backend$original_uri;
Теперь все понятно. Спасибо!
--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Управление бэкендами
On 11/01/13 15:09, Валентин Бартенев wrote:
On Friday 01 November 2013 17:02:43 Валентин Бартенев wrote:
On Friday 01 November 2013 16:54:43 Sergey Kobzar wrote:
[..]
Далее у вас есть internal location, в котором тот же
proxy_pass/fastcgi_pass с переменной и запрос отправляется на нужный
сервер.
А переменную как выковырять из ответа?
Например так: возвращаете X-Accel-Redirect: /redirect_to/198.51.100.1
и он попадает в такой location:
location ~ ^/redirect_to/(?backend.+)$ {
internal;
proxy_pass http://$backend;
}
Если нужно сохранить оригинальный URI запроса, то это делается с помощью
set:
set $original_uri $request_uri;
и proxy_pass в этом случает будет выглядеть так:
proxy_pass http://$backend$original_uri;
Альтернативный, и даже наверное лучший и более простой вариант всего этого:
использовать аналогичным образом модуль ngx_http_auth_request.
http://nginx.org/ru/docs/http/ngx_http_auth_request_module.html
Хм. А этот модуль при чем? Мне не нужно авторизовывать пользователей.
--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
