Re: Управление бэкендами

2013-11-01 Пенетрантность Sergey Kobzar 

On 11/01/13 17:02, Валентин Бартенев wrote:


Альтернативный, и даже наверное лучший и более простой вариант всего
этого: использовать аналогичным образом модуль ngx_http_auth_request.

http://nginx.org/ru/docs/http/ngx_http_auth_request_module.html


Хм. А этот модуль при чем? Мне не нужно авторизовывать пользователей.



Авторизация - лишь одно из применений.  В каком-то смысле ваша задача тоже
авторизация, вы авторизуете пользовательский запрос быть переданным на
определенный бэкенд.

Для вас важно, что модуль отправляет запрос на access-фазе на указанный
сервер и позволяет из его ответа извлечь адрес бэкенда, на который потом
запрос будет передан.

Основной плюс тут в том, что на конечный бэкенд будет уходить оригинальный
запрос, а не перенаправленный, как в предложенном мной ранее решении с
X-Accel-Redirect.  Не потребуется хака с сохранением $request_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: Управление бэкендами

2013-11-01 Пенетрантность Валентин Бартенев 
On Friday 01 November 2013 17:50:51 Sergey Kobzar wrote:
> 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/(?.+)$ {
> >>
> >>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
> 
> Хм. А этот модуль при чем? Мне не нужно авторизовывать пользователей.
> 

Авторизация - лишь одно из применений.  В каком-то смысле ваша задача тоже 
авторизация, вы авторизуете пользовательский запрос быть переданным на 
определенный бэкенд.

Для вас важно, что модуль отправляет запрос на access-фазе на указанный
сервер и позволяет из его ответа извлечь адрес бэкенда, на который потом
запрос будет передан.

Основной плюс тут в том, что на конечный бэкенд будет уходить оригинальный 
запрос, а не перенаправленный, как в предложенном мной ранее решении с
X-Accel-Redirect.  Не потребуется хака с сохранением $request_uri.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Управление бэкендами

2013-11-01 Пенетрантность Sergey Kobzar 

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/(?.+)$ {
   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

Re: Управление бэкендами

2013-11-01 Пенетрантность Sergey Kobzar 

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/(?.+)$ {
   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: Управление бэкендами

2013-11-01 Пенетрантность Валентин Бартенев 
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/(?.+)$ {
>   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: Управление бэкендами

2013-11-01 Пенетрантность Валентин Бартенев 
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/(?.+)$ {
  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: Управление бэкендами

2013-11-01 Пенетрантность Sergey Kobzar 

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: Управление бэкендами

2013-11-01 Пенетрантность Валентин Бартенев 
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: Управление бэкендами

2013-11-01 Пенетрантность Sergey Kobzar 

On 11/01/13 14:41, Валентин Бартенев wrote:

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



___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Управление бэкендами

2013-11-01 Пенетрантность Sergey Kobzar 

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: Управление бэкендами

2013-11-01 Пенетрантность Валентин Бартенев 
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: Управление бэкендами

2013-11-01 Пенетрантность Sergey Kobzar 

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: Управление бэкендами

2013-11-01 Пенетрантность Валентин Бартенев 
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: Управление бэкендами

2013-11-01 Пенетрантность Oleksandr V. Typlyns'kyi 
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: Сервер по-умолчанию для конкретного домена

2013-11-01 Пенетрантность Валентин Бартенев 
On Friday 01 November 2013 14:07:16 Никита Кардашин wrote:
[..]
> Т.е. проблема моя не в том, что мне нужно иметь несколько SSL-сервисов на
> одном IP (это-то прекрасно работает, тут проблем нет), а в том, что мне
> нужно каким-то образом иметь несколько default-серверов с поддержкой SSL
> (либо иметь возможность задавать приоритеты серверам, чтобы запрос всегда
> попадал в более точный сервер (appX.domainX.tld), а не в wildcard
> *.domainX.tld).
> 

Запрос всегда попадает "в более точный сервер".  См. документацию:
http://nginx.org/r/server_name/ru со строк "При поиске виртуального
сервера по имени...".

Если у вас не так, то либо просто не работает SNI, либо вы что-то
перемудрили.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Сервер по-умолчанию для конкретного домена

2013-11-01 Пенетрантность Oleksandr V. Typlyns'kyi 
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

Управление бэкендами

2013-11-01 Пенетрантность Sergey Kobzar 

Приветсвую

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: Сервер по-умолчанию для конкретного домена

2013-11-01 Пенетрантность Vladimir Skubriev 

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 
(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

upstream prematurely closed connection while reading response header from upstream

2013-11-01 Пенетрантность Vladimir Skubriev 

Вопрос, если в логе 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: Сервер по-умолчанию для конкретного домена

2013-11-01 Пенетрантность Igor Sysoev 
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

Сервер по-умолчанию для конкретного домена

2013-11-01 Пенетрантность Nikita A Kardashin 
Всем привет,

Возникла задача:

- На один 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