Re: RSA + EC - ocsp stapling ?

2019-10-15 Пенетрантность Maxim Dounin
Hello!

On Tue, Oct 15, 2019 at 07:01:56PM +0500, Илья Шипицин wrote:

> вт, 15 окт. 2019 г. в 18:52, Maxim Dounin :
> 
> > Hello!
> >
> > On Tue, Oct 15, 2019 at 10:49:17AM +0500, Илья Шипицин wrote:
> >
> > > допустим, у нас сайт на двух сертификатах. включаем директиву
> > >
> > > ssl_stapling on;
> > >
> > > для обоих сертификатов должно включиться ?
> >
> > Да.
> >
> > > а что надо указывать в директиве
> > >
> > > *ssl_stapling_file* *файл*;
> > >
> > > ответ для обоих сертификатов ?
> >
> > Ничего.  Если что-либо указать - то всё содержимое файла будет
> > возвращаться всем клиентам в рамках OCSP stapling'а, вне
> > зависимости от используемого сертификата, и работать это не будет.
> >
> 
> с дилетанской точки зрения выглядит разумным сценарий - первый раз взять
> OCSP ответ, сохранить его в файл, дальше отдавать из файла.
> такого не ренализовано?

Нет.  Поведение директивы ssl_stapling_file явно описано в 
документации (http://nginx.org/r/ssl_stapling_file).

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

Re: RSA + EC - ocsp stapling ?

2019-10-15 Пенетрантность Maxim Dounin
Hello!

On Tue, Oct 15, 2019 at 10:49:17AM +0500, Илья Шипицин wrote:

> допустим, у нас сайт на двух сертификатах. включаем директиву
> 
> ssl_stapling on;
> 
> для обоих сертификатов должно включиться ?

Да.

> а что надо указывать в директиве
> 
> *ssl_stapling_file* *файл*;
> 
> ответ для обоих сертификатов ?

Ничего.  Если что-либо указать - то всё содержимое файла будет 
возвращаться всем клиентам в рамках OCSP stapling'а, вне 
зависимости от используемого сертификата, и работать это не будет.

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

Re: поведение куки userid на preflight запросах

2019-10-14 Пенетрантность Maxim Dounin
Hello!

On Sun, Oct 13, 2019 at 06:19:22PM +0500, Илья Шипицин wrote:

> привет,
> 
> столкнулись с тем, что модуль
> 
> https://nginx.org/en/docs/http/ngx_http_userid_module.html#userid
> 
> 
> выставляет куку в том числе на OPTIONS, который браузер отправляет без кук,
> потому что CORS
> 
> https://stackoverflow.com/questions/41478229/set-cookie-header-behaviour-in-a-preflight-options-request
> при
> 
> поведение браузеров разное. MSIE принимает новую куку (была старая, сделал
> OPTIONS без кук, получил новую, принял).
> 
> может есть смысл перестать отправлять эту куку на OPTIONS ?

С учётом того, что 

: Browser discards Set-Cookie in the response to OPTIONS.
: 
: (Tried Chrome, Firefox, and Opera. Set-Cookie in the response to 
: OPTIONS is always ignored.)

а равно текста спецификации CORS (которая предписывает для 
preflight-запросов не только не отправлять cookie, но и не 
принимать их) - это выглядит как проблема MSIE.

Ну то есть не отправлять Set-Cookie с целью оптимизации - можно, но в 
общем случае неизвестно же, что это за OPTIONS и используется ли 
он как preflight-запрос в рамках CORS, или это какая-нибудь другая 
экзотика.  А с функциональной точки зрения - нет разницы, 
отправлять или не отправлять (а если вдруг есть - то это ошибка 
клиента).

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

Re: ошибка "upstream prematurely closed connection" - обсудим ?

2019-10-14 Пенетрантность Maxim Dounin
Hello!

On Sun, Oct 13, 2019 at 02:18:30PM +0500, Илья Шипицин wrote:

> привет,
> 
> предыстория. видим ошибку в логах. вспоминаем концепцию, что с уровнем
> error логируются ошибки на стороне сервера. считаем, что ошибка
> действительно была. идем к клиенту - у клиента статус 200, ему хорошо, все,
> что он хотел считать, он вычитал. повторяем несколько раз, в большинстве
> случаев ситуация повторяется, в логах ошибка, у клиента все хорошо.
> 
> ок. идем смотреть исходники
> 
> вывод сообщения об ошибке встречается три раза
> 
> ./nginx-1.17.4/src/http/ngx_http_upstream.c:
>  "upstream prematurely closed connection");
> ./nginx-1.17.4/src/http/ngx_http_upstream.c:
>"upstream prematurely closed connection");
> ./nginx-1.17.4/src/http/ngx_http_upstream.c:
>  "upstream prematurely closed connection");
> 
> в двух случаях запрос завершается статусом 502
> 
> ngx_http_upstream_finalize_request(r, u, NGX_HTTP_BAD_GATEWAY);
> 
> 
> в одном месте - не завершается:
> http://hg.nginx.org/nginx/file/tip/src/http/ngx_http_upstream.c#l2369

Да, если ошибка происходит при чтении заголовка ответа - nginx 
пробует перейти к следующему бэкенду, так как это ещё возможно.  
Что, однако же, не означает, что ошибки нет - она есть.

> собственно, recv в некоторых случаях может выдавать 0 и это не всегда
> ошибка (у нас CentOS 7, возможно, там какая-то своя магия еще, с
> какими-нибудь сетевыми штуками бекпортированными в ядро 3.10)
> 
> man recv
> ...
> "The value 0 may also be returned if the requested number of bytes to
> receive from a stream socket was 0."
> 
> собственно, в этом месте меняем текст. и, чудо, после этого залогированные
> "upstream prematurely closed connection" идеально кореллируют с реальными
> обрывами.
> 
> вопрос - в этом месте действительно стоит логировать ошибку с таким текстом
> ? может поменять уровень на info (или debug), а текст сделать что-то типа
> "zero bytes read from recv" ?

Если recv() возвращает 0 байт - в предположении, что буфер был не 
нулевого размера - то это означает, что соединение закрыто "той 
стороной".  Если это происходит в момент времени, не 
предусмотренный протоколом - то это ошибка, и она логгируется 
соответственно.

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

Re: Время ssl handshake RSA & ECDSA

2019-09-26 Пенетрантность Maxim Dounin
Hello!

On Thu, Sep 26, 2019 at 07:47:41PM +0300, Vasiliy Tolstov wrote:

> ср, 25 сент. 2019 г. в 16:27, Maxim Dounin :
> >
> > Начать стоит с вопроса как именно и где вы измеряете время (и
> > зачем).  Если время измерять на клиенте - то ECDSA медленнее RSA,
> > такак операция проверки подписи в ECDSA сильно дороже.
> >
> > Скажем, для ECDSA P-256 и RSA 2048 ситуация выглядит так:
> >
> > $ openssl speed rsa2048 ecdsap256
> > ...
> >   signverifysign/s verify/s
> > rsa 2048 bits 0.005821s 0.000168s171.8   5958.5
> >   signverifysign/s verify/s
> >  256 bit ecdsa (nistp256)   0.0003s   0.0012s   3588.2858.3
> >
> > То есть операция проверки подписи для ECDSA в разы дороже, чем для
> > RSA.  Соответственно если измерять время handshake'а между ничего
> > не делающим быстрым сервером и клиентом фиксированной и не очень
> > большой производительности - от ECDSA-сертификатов будет сплошной
> > вред, ибо на него ляжет на порядок больше вычислительной работы.
> >
> > Основная польза от ECDSA-сертификатов - это существенно меньшая
> > нагрузка на сервер, и соответственно возможность обслуживать
> > существенно большее количество клиентов.  Но её в таком тесте
> > просто не будет видно.
> 
> Прошу прощения за небольшой оффтоп, а если используется mTLS - что
> выгоднее использовать в плане производительности ECDSA или RSA?
> Учитывая что там все друг другу клиенты и серверы.

Ну вот выше циферки же по аналогичным размерам ключей - в случае 
RSA 2048 вы получите максимальную производительность, ограниченную 
количеством подписей в секунду - 171.8 sign/s (стоимость 
верификации в разы меньше, и ей можно пренебречь), а в случае 
ECDSA P-256 - количеством верификаций, 858.3 verify/s (стоимостью 
подписи, опять же, можно пренебречь).  То есть ECDSA на круг 
получается раз в 5 выгоднее.

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

Re: Время ssl handshake RSA & ECDSA

2019-09-25 Пенетрантность Maxim Dounin
Hello!

On Wed, Sep 25, 2019 at 02:19:55PM +0200, Дмитрий Рыбалка wrote:

> Добрый день,  прошу помочь разобраться с проблемой:
> Nginx 1.16.1 (проблема была и на прошлых версиях) из оф репозитория nginx
> для debian,  openssl 1.1.1c (проблема есть и на openssl 1.1.0)
> Прописываю два ключа RSA & *ECDSA*. Пробовал ключи как от LE так и от comoda
> 
> Пример настроек:
> 
> >   ssl_session_cache   shared:SSL:5m;
> >   ssl_session_timeout 30m;
> >   ssl_ecdh_curve X25519:prime256v1;
> >   ssl_buffer_size 4k;
> >   ssl_session_tickets off;
> >   resolver 8.8.8.8 8.8.4.4 valid=5m; #ipv6=off
> >   resolver_timeout 1s;
> >   ssl_prefer_server_ciphers   on;
> >   ssl_protocols TLSv1.2 TLSv1.3;
> >   ssl_ciphers
> > 'TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384';
> >  ssl_stapling on; - включал выключал, разницы нет.
> 
> 
> 
> Время хендшейка около 40мс.
> Если оставить только RSA то время уменьшается до 10мс
> Если оставить только EDSA, то время незначительно меняется и равно 38-39мс
> Если проверять скорость подписей openssl то ECDSA реально быстрее RSA, но
> почему при https подключении этого не видно?
> Проверял как чистым curl, так и black box экспортером для отслеживания
> динамики.
> Прошу помочь разобраться с данным нюансом

Начать стоит с вопроса как именно и где вы измеряете время (и 
зачем).  Если время измерять на клиенте - то ECDSA медленнее RSA, 
такак операция проверки подписи в ECDSA сильно дороже.

Скажем, для ECDSA P-256 и RSA 2048 ситуация выглядит так:

$ openssl speed rsa2048 ecdsap256
...
  signverifysign/s verify/s
rsa 2048 bits 0.005821s 0.000168s171.8   5958.5
  signverifysign/s verify/s
 256 bit ecdsa (nistp256)   0.0003s   0.0012s   3588.2858.3

То есть операция проверки подписи для ECDSA в разы дороже, чем для 
RSA.  Соответственно если измерять время handshake'а между ничего 
не делающим быстрым сервером и клиентом фиксированной и не очень 
большой производительности - от ECDSA-сертификатов будет сплошной 
вред, ибо на него ляжет на порядок больше вычислительной работы.

Основная польза от ECDSA-сертификатов - это существенно меньшая 
нагрузка на сервер, и соответственно возможность обслуживать 
существенно большее количество клиентов.  Но её в таком тесте 
просто не будет видно.

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

[nginx-ru-announce] nginx-1.17.4

2019-09-24 Пенетрантность Maxim Dounin
Изменения в nginx 1.17.4  24.09.2019

*) Изменение: улучшено детектирование некорректного поведения клиентов в
   HTTP/2.

*) Изменение: в обработке непрочитанного тела запроса при возврате
   ошибок в HTTP/2.

*) Исправление: директива worker_shutdown_timeout могла не работать при
   использовании HTTP/2.

*) Исправление: при использовании HTTP/2 и директивы
   proxy_request_buffering в рабочем процессе мог произойти segmentation
   fault.

*) Исправление: на Windows при использовании SSL уровень записи в лог
   ошибки ECONNABORTED был "crit" вместо "error".

*) Исправление: nginx игнорировал лишние данные при использовании
   chunked transfer encoding.

*) Исправление: если использовалась директива return и при чтении тела
   запроса возникала ошибка, nginx всегда возвращал ошибку 500.

*) Исправление: в обработке ошибок выделения памяти.


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

nginx-1.17.4

2019-09-24 Пенетрантность Maxim Dounin
Изменения в nginx 1.17.4  24.09.2019

*) Изменение: улучшено детектирование некорректного поведения клиентов в
   HTTP/2.

*) Изменение: в обработке непрочитанного тела запроса при возврате
   ошибок в HTTP/2.

*) Исправление: директива worker_shutdown_timeout могла не работать при
   использовании HTTP/2.

*) Исправление: при использовании HTTP/2 и директивы
   proxy_request_buffering в рабочем процессе мог произойти segmentation
   fault.

*) Исправление: на Windows при использовании SSL уровень записи в лог
   ошибки ECONNABORTED был "crit" вместо "error".

*) Исправление: nginx игнорировал лишние данные при использовании
   chunked transfer encoding.

*) Исправление: если использовалась директива return и при чтении тела
   запроса возникала ошибка, nginx всегда возвращал ошибку 500.

*) Исправление: в обработке ошибок выделения памяти.


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

Re: Ответ в зависимости от переданного параметра.

2019-09-20 Пенетрантность Maxim Dounin
Hello!

On Fri, Sep 20, 2019 at 05:01:06AM -0400, darksmoke wrote:

> Добрый день
> подскажите, пожалуйста как такое можно реализовать.
> Есть GET запрос, в нем передается параметр, varID=car
> 
> Вопрос:
> Как в зависимости от того что пришло в  varID вернуть разный ответ
> 
> 
>  if ($arg_varID !~* ("car"|"moto") ) {
>Вернуть JSON
> }
> else
> {
>root $root_path/modules;
> }
> 
> Т.е. если НЕ car или Не moto, то вернуть JSON.  А если совпало, то загрузить
> статику

Вариантов масса.  Например, можно сделать ровно то, что у вас 
написано, с точностью до правильно составленного регулярного 
выражения:

if ($arg_varid ~ "^(?!car$|moto$).*$") {
return 200 '{ "json": 1 }';
}

То, что внутрь if'а не попадёт - будет обработано обработчиком по 
умолчанию, то есть как статика.  Директиву root можно задать в 
любом месте (вот только не надо в неё совать переменные без нужды).

Или же можно воспользоваться инструкцией break для окончания 
обработки инструкций модуля rewrite:

if ($arg_varid = "car") {
break;
}

if ($arg_varid = "moto") {
break;
}

return 200 '{ "json": 1 }';

Так как дальнейшая обработка инстураций rewrite-модуля после break 
прекращается, то return сработает только если $arg_varid не "car" 
и не "moto".

Если возможных значений может быть много, то эффективнее всего 
сделать map, с помощью которого получить готовое условие для 
проверки:

map $arg_varid $need_json {
default1;
car0;
moto   0;
}

if ($need_json) {
return 200 '{ "json": 1 }';
}

Подробнее в документации тут:

http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html
http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html#if
http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html#return
http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html#break
http://nginx.org/ru/docs/http/ngx_http_map_module.html

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

Re: Ошибка при использовании переменных в ssl_certificate и ssl_certificate_key

2019-09-09 Пенетрантность Maxim Dounin
Hello!

On Mon, Sep 09, 2019 at 06:55:46PM +0300, actionmana...@gmail.com wrote:

> ubuntu 18.04
> 
> nginx/1.17.3
> 
> nginx не может считать файл fullchain.cer при использовании  переменной  в  
> директиве  ssl_certificate.
> 
> ssl_certificate /root/.acme.sh/$ssl_key_name/fullchain.cer;
> 
> 
> 2019/09/09  15:30:46 [error] 15246#15246: *546 cannot load certificate
> "/root/.acme.sh/site.org/fullchain.cer": BIO_new_file() failed (SSL: 
> error:0200100D:system library:fopen:Permission 
> denied:fopen('/root/.acme.sh/site.org/fullchain.cer','r') error:2006D002:BIO 
> routines:BIO_new_file:system lib) while SSL handshaking
> 
> 
> прописываю путь без переменной, всё работает.
> 
> видимо  при  запуске  nginx  читает  от  root  ,  а  при  использовании
> переменных  в  ssl_certificate от пользователя из конфига ( www-data )
> т.к. путь формируется динамически.

Да, именно так.  Рабочие процессы в норме работают не от рута, и 
чтобы они могли читать сертификаты - сертификаты и ключи должны 
быть доступны рабочим процессам на чтение.

Необходимость давать рабочим процессам право на чтение ключей - 
одна из причин, почему использовать динамическую загрузку 
сертификатов без нужды - не стоит.

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

Re: nginx полностью загружает весь процессор при reload'e

2019-09-03 Пенетрантность Maxim Dounin
Hello!

On Tue, Sep 03, 2019 at 03:18:36PM +0500, Dmitry Sergeev wrote:

> Добрый день,  спасибо за ответ.
> 
> On 02/09/2019 22:11, Maxim Dounin wrote:
> > Just in case, для работы такая конфигурация смысла не имеет - если
> > тикеты выключены, то ключ для их шифрования не нужен.  Ключ имеет
> > смысл задавать, если тикеты включены.
> >
> > С точки зрения влияния на reload - внешний ключ позволит сохранить
> > тикеты при reload'ах, а выключение тикетов - уведёт всё в кэш
> > сессий.
> >
> > Ну выключать тикеты - это, безусловно, плохой путь.  Тикеты -
> > способ переложить хранение сессий на клиентов, и отказываться от
> > этого - очевидно недальновидно с точки зрения нагрузки на сервер.
> >
> Да, я неверно понял доки.
> 
> > Отмечу также, что даже в наиболее экстремальных случаях из
> > представленных на графике - рост потребления процессора с ~200% до
> > ~300% не выглядит сколько-нибудь фатальным.  Какой-то рост
> > потребления процессора при релоадах - нормален, здесь же
> > наблюдается рост всего в 1.5 раза.  Если это проблема - то стоит
> > задуматься о добавлении мощностей и/или заняться оптимизацией
> Да, сейчас это для меня просто представляет интерес, после перехода на 
> openssl 1.0.2g и включение http2, проблем это особых не вызывает.
> > А вот то, что средняя нагрузка без тикетов заметно выше - это
> > немного странно.  Само хранение сессий - должно бы стоить очень
> > недорого с точки зрения процессора, а в остальном разница не
> > принципиальна.  Но, возможно, тут дело в том, что размер кэша
> > SSL-сессий просто мал для имеющегося количества клиентов, и
> > поэтому при выключении тикетов handshake'и начинают происходить
> > чаще, что и приводит к росту потребления процессора.
> Возможно. Это немного не то, но мне было интересно как увеличение кэша 
> ssl сессий повлияет на нагрузку при reload'e:
> 
> http://dl4.joxi.net/drive/2019/09/03/0030/2608/1985072/72/8608b87db7.jpg
> 
> Числами отметил разное количество ssl_session_cache от 20m до 256m. 
> Вроде никак не влияет.  Сегодня тестил при 8K rps (вчера 5-6K). Поэтому 
> нагрузка скачет чуть выше.

От размера кэша сессий должна зависеть высота "полки" между 
reload'ами.  Если кэш мал - то полных handshake'ов будет больше, 
чем могло бы быть, и соответственно CPU usage в полке будет 
больше.  Ну и всё это имеет смысл скорее при выключенных тикетах, 
о чём и шла речь выше.  А на графике - они, похоже, включены.

> А вот тикеты помогли вообще круто.  Нагрузка поднимается всего-лишь на 
> 5%-10%:
> http://dl3.joxi.net/drive/2019/09/03/0030/2608/1985072/72/ac00a4d2d0.jpg
> 
> Здесь 1 - это без ssl_session_ticket_key, а 2,3,4 - c включенными 
> тикетами и указанными постояным ключем ssl_session_ticket_key.

Ну ок, то есть как и ожидалось - пик явно из-за SSL handshake'ов, 
использование постоянных ключей для тикетов - лечит.

> Итого:
> 
> Сущесвтенно решить проблему помогло следующее:
> 1) переход на http2 (openssl 1.02.g) - понизилась нагрузка в целом, и 
> при reload'e нагрузка конечно возрастала, но не надолго (5-20 секунд, а 
> раньше от 30-40 секунд, до 5 минут).
> 2) И вообще убрать хоть какое-то сущесвтенное повышение нагрзуки помогло 
> включение ssl_session_tickets(по умолчанию включено) с установелнным 
> ssl_session_ticket_key (по умолчанию генерируется заново при каждом 
> reload'e, его лучше указать чтобы этого не происходило).
> 
> Оставил такие параметры:
> 
>      ssl_session_cache   shared:SSL:20m;
>      ssl_session_timeout 30m;
>      ssl_session_tickets on;
>      ssl_session_ticket_key /etc/nginx/ssl/ticket.key; # ticket.key - 
> файл с рандомными 80 или 48 байт
> 
> Кэш ssl сессий оставил, хоть в моем случае он вроде как сильно не влияет 
> (по крайней мере я этого не заметил).

Использовать "ssl_session_tickets on;" - не нужно, это поведение 
по умолчанию.  И отмечу также, что ключ для тикетов - надо 
периодически менять, ибо получив этот ключ - можно расшифровать 
весь трафик.

И я бы ещё рекомендовал посмотреть в сторону ECDSA-сертификатов, 
там handshake банально на порядок быстрее при той же 
криптостойкости:

$ openssl speed rsa2048 ecdsap256
...
  signverifysign/s verify/s
rsa 2048 bits 0.000992s 0.33s   1008.1  30297.9
  signverifysign/s verify/s
 256 bit ecdsa (nistp256)   0.0001s   0.0001s  17145.0   9276.9

То есть 1008.1 подписей в секунду в случае RSA 2048 bit, и 17145.0 
подписей в секунду для ECDSA 256 bit.

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

Re: nginx полностью загружает весь процессор при reload'e

2019-09-02 Пенетрантность Maxim Dounin
Hello!

On Mon, Sep 02, 2019 at 08:54:51PM +0500, Dmitry Sergeev wrote:

> Спасибо большое за ответ.
> 
> Потестил  с параметрами:
> 
> ssl_session_tickets off;
> ssl_session_ticket_key /etc/nginx/ssl/ticket.key;

Just in case, для работы такая конфигурация смысла не имеет - если 
тикеты выключены, то ключ для их шифрования не нужен.  Ключ имеет 
смысл задавать, если тикеты включены.

С точки зрения влияния на reload - внешний ключ позволит сохранить 
тикеты при reload'ах, а выключение тикетов - уведёт всё в кэш 
сессий.

> И довольно интересно получилось:
> http://joxi.net/krD6q0jTKkV9R2.jpg
> 
> На картинке числами отмечены reload'ы
> 1,2,6,7,10  - без настроек tickets (по умоланию включен)
> 3,4,5,8,9 - с отключенным tickets и файлом ssl_session_ticket_key.
> 
> При этом всегда был включен кэш сессий:
> 
>      ssl_session_cache   shared:SSL:20m;
>      ssl_session_timeout 30m;
> 
> Пока сделал вывод, что с отключенным ssl_session_tickets средняя 
> нагрузка выше, но при этом при reload'e нагрузка не так сильно 
> возрастает по отношению к средней. Тесты не совсем чистые, постараюсь 
> сделать более чистый эксперимент.

Ну выключать тикеты - это, безусловно, плохой путь.  Тикеты - 
способ переложить хранение сессий на клиентов, и отказываться от 
этого - очевидно недальновидно с точки зрения нагрузки на сервер.

А вот то, что средняя нагрузка без тикетов заметно выше - это 
немного странно.  Само хранение сессий - должно бы стоить очень 
недорого с точки зрения процессора, а в остальном разница не 
принципиальна.  Но, возможно, тут дело в том, что размер кэша 
SSL-сессий просто мал для имеющегося количества клиентов, и 
поэтому при выключении тикетов handshake'и начинают происходить 
чаще, что и приводит к росту потребления процессора.

Отмечу также, что даже в наиболее экстремальных случаях из 
представленных на графике - рост потребления процессора с ~200% до 
~300% не выглядит сколько-нибудь фатальным.  Какой-то рост 
потребления процессора при релоадах - нормален, здесь же 
наблюдается рост всего в 1.5 раза.  Если это проблема - то стоит 
задуматься о добавлении мощностей и/или заняться оптимизацией.

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

Re: Вопреки утверждениям в changelog нет поддержки poll метода в Windows

2019-09-02 Пенетрантность Maxim Dounin
Hello!

On Mon, Sep 02, 2019 at 10:25:06AM -0400, pavlusha23 wrote:

> Вопреки утверждениям в changelog никакой поддержки poll метода в Windows не
> появилось, пробовал как стабильную версию, так и разрабатываемую. Скачал оба
> файла, ни в стабильной ветке ни в основной этой фичи не нашел. Пишет такой
> метод не поддерживается. Нехорошо(
> 
> *) Добавление: метод poll теперь доступен на Windows при использовании
>Windows Vista и новее.
> 
> Объявив новую фичу вы даже забыли добавить  её компиляцию для Windows
> сборки, жесть(

Доступность метода poll определяется во время выполнения, и 
зависит от используемой версии Windows.  Что-либо добавлять также 
не надо - методы select и poll на Windows собираются 
автоматически.

Если у вас что-то не работает, а вы считаете, что должно, начните 
с простого: покажите ошибку, а равно лог запуска на уровне info 
или подробнее.  Ну и укажите версию Windows, которую вы 
используете.

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

Re: Иногда в логах проскакивает SSL write() failed

2019-09-02 Пенетрантность Maxim Dounin
Hello!

On Fri, Aug 30, 2019 at 11:08:54AM -0400, spanjokus wrote:

> У меня такое то же иногда проскакивает, был бы признателен, если бы кто-то
> подсказал из-за чего это

http://mailman.nginx.org/pipermail/nginx-ru/2019-August/062366.html

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

Re: Ошибка "[warn] conflicting server name "site.ru" on 0.0.0.0:80, ignored"

2019-09-02 Пенетрантность Maxim Dounin
Hello!

On Mon, Sep 02, 2019 at 09:38:30AM -0400, grey wrote:

> Приветствую.
> 
> 
> Решил перевести сайт на https, заодно убрать www в имени домена. Раньше
> делал это через if-ы, но тут говорят, что они зло, потому захотел сделать
> всё по уму...
> 
> # редирект с http на https
>   server {
>   listen   80;
>   server_name  site.ru www.site.ru;
>   return 301 https://site.ru$request_uri;
>   }
> 
> # редирект с www на non-www
>   server {
>   server_name www.site.ru; # < ошибка
>   rewrite ^(.*)$ https://site.ru$1 permanent;
>   }
> 
>   server {
>   listen   443 ssl default_server;
>   server_name  site.ru;
> ...
> 
> 
> В результате получаю ошибку "[warn] conflicting server name "www.site.ru" on
> 0.0.0.0:80, ignored". Ругает на строку "server_name  www.site.ru;", но как
> сделать по другому - не пойму. Убрать строку наверно будет не правильно,
> т.к. хостов может быть много, а мне нужно для конкретного хоста сделать те
> или иные манипуляции.
> 
> Подскажите, плз, что я делаю не так?

У вас имя "www.site.ru" для порта 80 используется и в первом, и во 
втором блоке server{}.  Это не имеет смысла, так как запрос может 
быть обработан только в одном блоке server{}.  То есть в данном 
конкретном конфиге - второй блок server{}, фактически, не имеет 
смысла.  Именно из-за этого nginx и ругается.

Подозреваю, что на самом деле второй блок server{} должен был быть 
про перенаправление с www на без-www для https, то есть содержать 
"listen 443 ssl;".

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

Re: common location for all virtual hosts

2019-09-02 Пенетрантность Maxim Dounin
Hello!

On Mon, Sep 02, 2019 at 10:21:07AM +0300, Igor Savenko wrote:

> Добрый день! Есть задача сделать общий location для всех virtual hosts,
> чтобы при выполнении определенного условия происходил inner redirect на
> этот location из любого virtualhost. Можно хоть намек, как это сделать
> программно, в модуле? На уровне конфига, похоже, не получится -- нужно
> будет скорее всего делать в каждом virtual host include конфига с этим
> location. Спасибо!

Общих location'ов для разных виртуальных хостов - в nginx'е не 
бывает.  Одинаковые - проще всего сделать с помощью директивы 
include и соответствующего конфигурационного файла.

Отмечу на всякий случай, что "одинаковые" - это достаточно 
условное понятие, так как в любой location наследуется 
конфигурация с предыдущих уровней, и если значения каких-то 
директив в блоках server{} различаются, то и результирующая 
конфигурация соответствующих location'ов будет разная.

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

Re: Заметил еще что в логах редно проскакивает SSL read() failed

2019-09-02 Пенетрантность Maxim Dounin
Hello!

On Sun, Sep 01, 2019 at 02:36:37PM -0400, grey wrote:

> Вот ошибка:
> 
> 2019/09/01 21:30:07 [crit] 1512#1784: *29234169 SSL_read() failed (SSL:
> error:14191044:SSL routines:tls1_enc:internal error) while waiting for
> request, client: 109.252.*.*, server: 0.0.0.0:443
> 
> версия 1.17.2
> 
> Это с чем связно?

Причина "internal error" как бы намекает, что проблема где-то 
внутри OpenSSL.  Если смотреть на код функции tls1_enc() - то это 
преимущественно ситуации, которых быть не должно.  С редкими 
вкраплениями ошибок от разных других вызываемых функций - но в 
этом случае на стеке ошибок скорее всего будет что-то ещё.

Что именно служит причиной - надо подробно разбираться с кодом 
OpenSSL и конкретной ситуацией.  Скорее всего - какая-то ошибка в 
обработке краевых случаев в OpenSSL.  Скажем, может быть к 
подобной ошибке приводит что-нибудь вроде закрытия соединения в 
неподходящий момент.  Впрочем, если речь идёт про винды - то может 
быть вообще всё, что угодно.

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

Re: nginx полностью загружает весь процессор при reload'e

2019-09-02 Пенетрантность Maxim Dounin
Hello!

On Sat, Aug 31, 2019 at 12:54:06PM +0500, Dmitry Sergeev wrote:

> Добрый день!
> Спасибо за ответ.
> 
> Конфиг полный, просто сократил количетсво виртуальных хостов, так как они 
> одинаковые.

В конфиге значилось:

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

Так что понять по нему, полный он, или нет - не представляется 
возможным, отсюда и вопросы.

> ssl_session_cache - действительно не настроено.
> ssl_dhparam - аналогично.
> сертификат один общий для всех, сгенерировал его для wildcard домена от let's 
> encrypt (Signature Algorithm: sha256WithRSAEncryption, Public-Key: 
> rsaEncryption (2048 bit)).
> 
> Пытался оптимизировать ssl и посмотреть влияние его настроек на эту проблему. 
> В частности пробовал глобально добавлять опции:
> 
> *ssl_session_cache shared:SSL:20m;*
> *ssl_session_timeout 30m; *вроде никак не влияло, но я проверю еще раз 
> конечно, и более чательно.

Если большая часть клиентов использует тикеты - то может и не 
повлиять.  Для теста можно попробовать отключить тикеты 
(ssl_session_tickets) и/или настроить внешний ключ 
(ssl_session_ticket_key), так как автоматически сгенерированные 
ключи при reload'е обновляются.

> Про ssl_dhparam не понял, с точки зрения производительности - 
> его лучше добавлять но с небольшой битностью (2048 и меньше) или 
> лучше совсем не использовать?

Лучше - не использовать.  Даже 2048 для классического 
Диффи-Хеллмана - это очень медленно.

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

Re: Количество одновременно ипользуемых proxy pass в в нескольких location

2019-08-30 Пенетрантность Maxim Dounin
Hello!

On Wed, Aug 21, 2019 at 01:57:10AM -0400, glareboa wrote:

> Приветствую.
> 
> Использую такую конструкцию.
> 
> http {
> ...
> server {
>   listen 80 default_server;
> ...
> location /qwe/
> {
>proxy_pass "http://192.168.1.2:9000;;
> }
> 
> location /qwe/
> {
>proxy_pass "http://192.168.1.2:9001;;
> }
> 
> location /rty/
> {
>proxy_pass "http://192.168.1.2:9002;;
> }
> 
> ...
> 
> location /uio/
> {
>proxy_pass "http://192.168.1.2:9012;;
> }
> 
> 
> }
> }
> Но в браузере отображаются только для 6 или меньше
> источников(http://192.168.1.2:90хх).
> Если вставить адреса http://192.168.1.2:9012 непосредственно в html-файл,
> отображаются все источники.
> 
> Получается, что есть ограничение в nginx?

Нет, в nginx ограничений нет.  А вот в браузерах - есть 
ограничение на максимум 6 соединений к одному доменному имени в 
рамках HTTP/1.x, так что если речь идёт про какие-то потоки 
данных - то скорее всего вы просто упёрлись в ограничение 
бразуера.  Обычно это обходят, используя на html-странице 
несколько доменных имён, указывающих на один и тот же сервер.

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

Re: Как записать ключи pre-master от tls-соединений, обрабатываемых nginx?

2019-08-30 Пенетрантность Maxim Dounin
Hello!

On Tue, Aug 27, 2019 at 11:50:18PM +0300, Pavel wrote:

> Мы  состоим  в  реестре  организаторов  распространения  информации  и
> поэтому обязаны предоставлять в надзорный орган ключи tls сессий.
> 
> Для  таких случаев существует механизм по перехвату вызовов библиотеки
> openssl: https://git.lekensteyn.nl/peter/wireshark-notes/tree/src/
> Суть  простая - перед запуском демона, обрабатывающего TLS-соединения
> клиентов,   через   LD_PRELOAD   подгружается  эта  библиотека  и  она
> сбрасывает в текстовый файл, указанный в переменой SSLKEYLOGFILE, ключи 
> pre-master.
> 
> Эта  схема  срабатывает с апачем, но с энжинксом ключи не пишутся. Нет
> ли  идей  или подсказок из-за чего это может быть и как вообще  можно записать
> эти самые pre-master keys в энжинксе?

[...]

> [Service]
> Environment=SSLKEYLOGFILE=/tmp/premaster.txt
> Environment=LD_PRELOAD=/usr/local/lib/libsslkeylog.so

[...]

> но  тем  не  менее  ключи  в файл при обращении к энжинксу по https не
> пишутся.

Скорее всего причина в том, что переменные 
окружения очищаются при запуске, подробнее тут:

http://nginx.org/r/env

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

Re: nginx полностью загружает весь процессор при reload'e

2019-08-30 Пенетрантность Maxim Dounin
Hello!

On Wed, Aug 28, 2019 at 09:18:44PM +0500, Dmitry Sergeev wrote:

> Вообще мне это конечно помогло, но  не полностью. На версии 1.0.2g во 
> время reload'а проц грузит полностью  около 5-10 секунд (вместо 40-300 
> секунд на 1.0.1u), теперь просто оно особо проблем не вызывает у 
> клиентов. Но в целом проблема осталась, просто теперь она не так сильно 
> беспокоит.
> 
> Сейчас задача замедлилась, но в итоге буду поднимать тестовый стенд с 
> нагрузкой, и смотреть можно ли как-то повлиять на это.
> Если конечно тут не подскажут, что еще можно подкрутить.

Судя по perf top, проблема в том, что клиенты после reload'а 
переустанавливают соединения, и это выливается в полный SSL 
handshake - что и приводит к потреблению CPU.

Посмотреть стоит на:

- ssl_session_cache - в конфиге его, судя по всему, нет (или 
  соответствующие части конфига не показаны);

- сертификаты, в частности - их битность (just in case, RSA более 
  2048 использовать не надо, это тупо очень дорого с точки зрения 
  процессора) и тип (лучше использовать ECDSA, но тут уже может 
  встать вопрос совместимости; при желании можно использовать и RSA 
  и ECDSA одновременно);

- используемые шифры, особенно - шифры с классическим DH для 
  обмена ключами (по умолчанию эти шифры не используются начиная с 
  nginx 1.11.0, но некоторые любят указывать ssl_dhparam в конфиге, 
  да ещё и с параметрами большой битности; не надо так);

> Насчет старых клиентов, точно не могу сказать, но есть такой кейс 
> http://mailman.nginx.org/pipermail/nginx-ru/2019-April/062014.html. Я 
> хорошо не изучал этот вопрос, но факт остается, на старой версии openssl 
> ошибок у клиентов в 3-4 раза было меньше. В итоге решили что это клиенты 
> с очень старым ssl.

Как уже говорилось в треде по ссылке, использование OpenSSL 
1.0.1u автоматически означет, что HTTP/2 с большинством клиентов 
работать не будет.  С учётом "listen ... http2" в конфиге - 
обновление до 1.0.2 могло "помочь" просто за счёт того, что HTTP/2 
заработал, и количество устанавливаемых соединений соответственно 
уменьшилось.

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

Re: nginx полностью загружает весь процессор при reload'e

2019-08-27 Пенетрантность Maxim Dounin
Hello!

On Tue, Aug 27, 2019 at 04:10:31PM +0500, Dmitry Sergeev wrote:

> Добрый день. Спасибо за ответ!

Пожалуйста.  Не надо отвечать мне лично, от этого карма портится.  
Спасибо.

> На сервере всего 64GB памяти, nginx кушает обычно около 2GB при релоадет 
> не сильно больше - 2-3GB, swap не задействуется. Свободно памяти обычно 
> больше 60GB.
> 
> Сейчас протестил. При релоаде съедает весь проц ровно 35-40 секунд. 
> Провел около 10 тестов, время всегда примерно такое.

Значит проблема не в памяти, а в чём-то ещё.  Что в конфиге?

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

Re: nginx полностью загружает весь процессор при reload'e

2019-08-27 Пенетрантность Maxim Dounin
Hello!

On Tue, Aug 27, 2019 at 03:24:03PM +0500, Dmitry Sergeev wrote:

> Версия: 1.14.2
> ОС: ubuntu 16.04
> Процессор: Intel Core i7-6700 CPU 3.40GHz
> 
> Средняя нагрузка: 5 000 rps, пиковые значения 12 000 rps.  Статики 
> практически нет, все запросы проксируются либо на бэкенды с nodejs через 
> proxy_pass либо на php-fpm через fastcgi_pass. Виртуальных хостов 16, 
> несколько из них имеют среднюю нагрузку 2K rps, остальные 500 rps.
> 
> С бэкендами nodejs включен keepalive, с php отключен.
> 
> Кроме nginx на сервере ничего нет.
> 
> Проблема в том, что при reload'e конфигурации, несколько минут nginx 
> начинает жрать весь процессор, все ядра под 100%, и запросы начинают 
> обрабатываться медленно либо совсем сбрасываются, отсюда куча ошибок у 
> клиентов. Такая проблема наблюдается только на серверах, где много 
> виртуальных хостов (15-30). На серверах с аналогичной нагрузкой, но 
> например 1-3 виртуальными хостами. Таких проблем не наблюдаю.
> 
> Может быть кто-нибудь подскажет, как можно это оптимизировать, что-то 
> подкрутить. Может можно как-то плавнее релоадить, чтобы медленее, но при 
> этом нагрузка на CPU как-то плавнее распределялась.

Для начала - имеет смысл посмотреть на количество доступной 
памяти.  При релоаде количество рабочих процессов увеличивается 
вдвое, и если памяти мало - система может уходить в свап с 
печальными последствиями.

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

Re: Битые файлы в кеше при gzip ответах

2019-08-20 Пенетрантность Maxim Dounin
Hello!

On Mon, Aug 19, 2019 at 08:08:21PM -0400, Vladislavik wrote:

> В общем, более менее разобрался, виноват был open_file_cache, интересная
> ситуация с ним выходит:
> у нас есть файл 10 кбайт, мы его запросили единожды и он попал в этот кэш.
> (если срок жизни кэша большой) Далее файл изменился, стал 15 кбайт и nginx
> при запросе файла отдает с диска уже измененный файл, НО обрезает его до
> длины, данные о которой все еще лежат в open_file_cache (10 кбайт) в итоге
> мы получаем обрезанный / не полный файл на выходе.

"Виноват" open_file_cache быть не может - он может лишь сделать 
проблему, которую вы себе создали, изменяя файлы неатомарно, более 
видимой.  А даты изменений приведены в предыдущем письме, речь 
явно не идёт о единичном случае.  То есть у вас явно процесс, 
который наступает на одни и те же грабли раз за разом.  Выключение 
open_file_cache проблему, скорее всего, спрячет до 
сложнонаблюдаемых масштабов, но не решит.

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

Re: Битые файлы в кеше при gzip ответах

2019-08-19 Пенетрантность Maxim Dounin
Hello!

On Mon, Aug 19, 2019 at 05:32:55PM -0400, Vladislavik wrote:

> chunked_transfer_encoding on;
> 
> Не может быть причиной?

Нет - как видно из ответа в кэше, используется Content-Length, 
chunked transfer encoding не используется вообще.  Не говоря уже о 
том, что эта директива со значением "on" не имеет смысла, это 
поведение по умолчанию.

> Файл никто не переписывает, лежит и никак не меняется не обновляется, а
> nginx порой отдает его обрезанным...

Опять же из заголовков ответов в кэше очевидно, что это не так:

Last-Modified: Sun, 18 Aug 2019 12:06:39 GMT
Last-Modified: Sun, 18 Aug 2019 13:49:45 GMT 

То есть у файла менялся не только размер, но и дата последнего 
изменения.  В файл явно кто-то лазил, как и чем - искать вам.

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

Re: Актуальна ли proxy cache path inactive=NNN между рестартами?

2019-08-19 Пенетрантность Maxim Dounin
Hello!

On Sun, Aug 18, 2019 at 07:04:32AM -0400, rihad wrote:

> У нас на некоторых серверах inactive стоит 90 дней, что будет если  nginx
> перезагрузить до этого времени, сохранится ли время последнего запроса к
> кешированному ресурсу? Я попытался сам разобраться по коду но там сложно.
> 
> file->accessed = now;
> 
> в ./src/core/ngx_open_file_cache.c
> 
> И потом в ngx_http_file_cache_update() не увидел что поле acessed пишется.
> Может в другом месте где-то?

Нет, при загрузке кэша с диска - в качестве времени последнего 
обращения будет использоватся время загрузки соответствующего 
элемента кэша.  Соответственно не имеет особого смысла 
использовать время inactive, превышающее среднее время между 
перезапусками nginx'а.

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

Re: Битые файлы в кеше при gzip ответах

2019-08-19 Пенетрантность Maxim Dounin
Hello!

On Sun, Aug 18, 2019 at 11:12:31AM -0400, Vladislavik wrote:

> этот запрос был без gzip, файл каким-то образом nginx был отдан не
> полностью, с указанием размера 3492 вместо 3518, как это может быть? Файл
> лежит на диске,

Как уже говорилось - если файл отдаёт nginx, то наиболее вероятная 
причина - файл на диске кто-то переписывает по месту.  Если файл 
не меняется - это может быть какая-нибудь забытая синхронизация, 
которая просто копирует все файлы с другой машины / из другого 
каталога.  

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

Re: nginx.service start operation timed out. Terminating.

2019-08-14 Пенетрантность Maxim Dounin
Hello!

On Wed, Aug 14, 2019 at 05:17:25PM +0300, Gena Makhomed wrote:

> Здравствуйте, All!
> 
> Столкнулся с проблемой
> 
> nginx.service start operation timed out. Terminating.

[...]

> Failover IP привязан к первому физическому серверу,
> поэтому если запустить эту же виртуальную машину на втором
> физическом сервере - у нее не будет доступа в интернет.
> 
> тем не менее, виртуальная машина нормально стартует и все работает.
> 
> кроме nginx.
> 
> который падает с такой ошибкой в логах:
> 
> Aug 14 16:22:35 vm nginx: nginx: [warn] "ssl_stapling" ignored, host not 
> found in OCSP responder "ocsp.int-x3.letsencrypt .org" in the 
> certificate "/etc/letsencrypt/live/example.com/fullchain.pem"
> Aug 14 16:23:03 vm systemd: nginx.service start operation timed out. 
> Terminating.
> Aug 14 16:23:03 vm systemd: Failed to start nginx - high performance web 
> server.
> Aug 14 16:23:03 vm systemd: Unit nginx.service entered failed state.
> Aug 14 16:23:03 vm systemd: nginx.service failed.
> 
> Подскажите пожалуйста, каким образом можно сконфигурировать nginx, чтобы 
> он нормально запускался и работал на втором узле кластера даже в том
> случае, когда Failover IP указывает на первый физический сервер и 
> виртуальная машина, запускаемая на втором физическом сервере не имеет 
> доступа в интернет?

Нужно либо убрать из из конфигурации всё, что требует резолвинга 
имён, и соответственно требует доступа в интернет, либо сделать 
этот резолвинг возможным (добавив соответствующие имена в 
/etc/hosts или обеспечив работу DNS).

Включённый OCSP stapling - пытается резолвить имена OCSP-серверов 
из сертификатов на старте.  Он, при этом, умеет автоматически 
выключаться, если разрезолвить имя не удаётся, но, судя по всему, 
сертификатов больше одного, а системный резолвер про отсутствие 
интернета не в курсе и тупо ждёт таймаутов, так что случается уже 
таймаут на запуск nginx'а в systemd.


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

Re: Битые файлы в кеше при gzip ответах

2019-08-14 Пенетрантность Maxim Dounin
Hello!

On Wed, Aug 14, 2019 at 08:43:39AM -0400, Vladislavik wrote:

> Ничего не генерится, файлы лежат на диске, созданы один раз и записаны на
> диск. Nginx должен сжать его на лету и отдать, вот, что от него требуется,
> он это выполняет, но иногда в кэше браузера/клаудфлера лежит обрезанный

Что лежит в кэшах браузера и клаудфлера - вопрос к браузеру и 
клаудфлеру соответственно.  Исходный вопрос был про proxy cache - 
что лежит в нём, когда наблюдается проблема?

> файл, например половина его (уже разжатый, тупо не весь, не хватает куска
> кода в конце файла) возникает ли ошибка при разжатии я не знаю, видно
> только, что файл читаемый, но код не полный, чаще только половина его) я так
> понял, что в процессе передачи или упаковки возникает какая-то проблема и
> nginx принимает файл от другого nginx/браузера без проверки его на
> целостность...Размеры файлов не более 20кб.
> Вопрос такой: возможно ли распаковать архив, если он получен не полностью?
> (Тк тест в js файла читаемый, но файл состоит только из половины того, что
> должно быть)

Распаковать - возможно.  При распаковке будет известно, полностью 
получен ответ или нет - по наличию/отсутствию gzip trailer'а (8 
байт с CRC32 и размером несжатого ответа).  Что делает с этой 
информацией конкретный распаковщик - тайна сия великая есть, да и 
не важно.  Смотреть надо строго на то, что лежит в кэше nginx'а, 
см. выше.

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

Re: Битые файлы в кеше при gzip ответах

2019-08-14 Пенетрантность Maxim Dounin
Hello!

On Wed, Aug 14, 2019 at 07:53:54AM -0400, Vladislavik wrote:

> Бэкэенд это nginx который шлет обычные файлы js сжатые с помощью встроенного
> gzip

Так, а "обычные файлы js", случайно, не перегенерятся (и/или 
редактируюстся) регулярно?

Ну и отступая на пару шагов назад: битые файлы - это что?  
Обрезанный gzip-контейнер, при распаковке возникает ошибка? Или 
структура gzip-контейнера не нарушена, всё штатно распаковывается 
без ошибок, но по результатом распаковки получается только часть 
того, что ожидалось в файле?

Если второе - то это выглядит как проблема с генерацией файлов.  
Такое бывает, если генерить файлы "по месту" - если к файлу 
обрататься, пока пишется новая версия, то из него прочитается 
только часть, уже записанная, но никто не обещал, что это будет 
ожидаемый файл полностью.  Соответственно эта часть и будет 
отправлена клиенту и закэширована.

Чтобы такого не было - надо менять файлы атомарно: написать новый 
файл рядом с временным именем, потом сделать rename() / mv в 
нужное имя.

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

Re: Битые файлы в кеше при gzip ответах

2019-08-14 Пенетрантность Maxim Dounin
Hello!

On Wed, Aug 14, 2019 at 07:30:41AM -0400, Vladislavik wrote:

> Максим, прокси версии 1.1 итак установлен, битые файлы на нем и получаются.
> Клаудфлер тоже использует 1.1 у них так же битые файлы часто лежат в кеше,
> проверял лично.

Если так, то наиболее вероятная причина - бэкенд так прислал.  
Почему и как вылечить - уже, видимо, вопрос к бэкенду.

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

Re: Битые файлы в кеше при gzip ответах

2019-08-14 Пенетрантность Maxim Dounin
Hello!

On Tue, Aug 13, 2019 at 09:52:16PM +0300, Владислав Толмачев wrote:

> Добрый день, не пойму как исправить ситуацию, nginx иногда хранит в proxy
> кеше битые обрезанные файлы, при использовании на бэкенде gzip, тот же баг
> замечен на клаудфлер, иногда в его кеше лешит обрезанный файл, например
> половина js файла и помогает только сброс кеша и запрос файла еще раз, что
> бы файл стал полный. Что подкрутить, что бы не выключать gzip и http1.1? В
> клаудфлере даже замечено то, что половина кэш серверов сохраняет полный
> файл, половина хранит его обрезанную версию и выдает ее как правильную

Использование сжатия на бэкенде обычно означает, что заголовка 
Content-Length в ответах бэкенда не будет.  Соответственно в 
HTTP/1.0 окончание ответа будет определяться по закрытию соединения, и 
если бэкенд по каким-то причинам закрывает соединение, не дослав 
ответ полностью, то такой ответ имеет шансы быть сохранённым в кэш 
частично.

Лучше всего в подобной ситуации - разобраться, почему таки 
закрываются соединения, и полечить.  Но в качестве workaround'а 
скорее всего сработает "proxy_http_version 1.1;" в конфиге.

Подробнее тут:

http://nginx.org/r/proxy_http_version/ru

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

[nginx-ru-announce] nginx-1.16.1

2019-08-13 Пенетрантность Maxim Dounin
Изменения в nginx 1.16.1  13.08.2019

*) Безопасность: при использовании HTTP/2 клиент мог вызвать чрезмерное
   потребление памяти и ресурсов процессора (CVE-2019-9511,
   CVE-2019-9513, CVE-2019-9516).


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

[nginx-ru-announce] nginx security advisory (CVE-2019-9511, CVE-2019-9513, CVE-2019-9516)

2019-08-13 Пенетрантность Maxim Dounin
Hello!

В реализации HTTP/2 в nginx было обнаружено несколько проблем
безопасности, которые могут приводить к чрезмерному потреблению
памяти и ресурсов процессора (CVE-2019-9511, CVE-2019-9513, CVE-2019-9516).

Проблемам подвержен nginx, собранный с модулем ngx_http_v2_module (по
умолчанию не собирается), если в конфигурационном файле используется
параметр http2 директивы listen.

Проблемам подвержен nginx 1.9.5 - 1.17.2.
Проблемы исправлены в nginx 1.17.3, 1.16.1.

Спасибо Jonathan Looney из Netflix за обнаружение проблем.


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

[nginx-ru-announce] nginx-1.17.3

2019-08-13 Пенетрантность Maxim Dounin
Изменения в nginx 1.17.3  13.08.2019

*) Безопасность: при использовании HTTP/2 клиент мог вызвать чрезмерное
   потребление памяти и ресурсов процессора (CVE-2019-9511,
   CVE-2019-9513, CVE-2019-9516).

*) Исправление: при использовании сжатия в логах могли появляться
   сообщения "zero size buf"; ошибка появилась в 1.17.2.

*) Исправление: при использовании директивы resolver в SMTP
   прокси-сервере в рабочем процессе мог произойти segmentation fault.


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

nginx-1.17.3

2019-08-13 Пенетрантность Maxim Dounin
Изменения в nginx 1.17.3  13.08.2019

*) Безопасность: при использовании HTTP/2 клиент мог вызвать чрезмерное
   потребление памяти и ресурсов процессора (CVE-2019-9511,
   CVE-2019-9513, CVE-2019-9516).

*) Исправление: при использовании сжатия в логах могли появляться
   сообщения "zero size buf"; ошибка появилась в 1.17.2.

*) Исправление: при использовании директивы resolver в SMTP
   прокси-сервере в рабочем процессе мог произойти segmentation fault.


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

nginx security advisory (CVE-2019-9511, CVE-2019-9513, CVE-2019-9516)

2019-08-13 Пенетрантность Maxim Dounin
Hello!

В реализации HTTP/2 в nginx было обнаружено несколько проблем
безопасности, которые могут приводить к чрезмерному потреблению
памяти и ресурсов процессора (CVE-2019-9511, CVE-2019-9513, CVE-2019-9516).

Проблемам подвержен nginx, собранный с модулем ngx_http_v2_module (по
умолчанию не собирается), если в конфигурационном файле используется
параметр http2 директивы listen.

Проблемам подвержен nginx 1.9.5 - 1.17.2.
Проблемы исправлены в nginx 1.17.3, 1.16.1.

Спасибо Jonathan Looney из Netflix за обнаружение проблем.


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

nginx-1.16.1

2019-08-13 Пенетрантность Maxim Dounin
Изменения в nginx 1.16.1  13.08.2019

*) Безопасность: при использовании HTTP/2 клиент мог вызвать чрезмерное
   потребление памяти и ресурсов процессора (CVE-2019-9511,
   CVE-2019-9513, CVE-2019-9516).


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

Re: Проксирование, буфер, лаги

2019-08-07 Пенетрантность Maxim Dounin
Hello!

On Wed, Aug 07, 2019 at 12:56:18PM -0400, rihad wrote:

> Просто эта цитата в доках на английском говорит, что такое бывает при
> выключенном буферинге.

Приведённая цитата говорит, что бывает при _выключенной_ 
буферизации.  Что бывает при включённой - написано в предыдущем 
абзаце.

Принципиальный момент, на самом деле, приблизительно один:

- В случае выключенной буферизации отправка будет происходить 
  сразу после получения данных от бэкенда.  Включая сброс буферов 
  всяких других уровней, как то gzip или SSL.  Если же буферизация 
  включена - nginx будет ждать заполнения очередного буфера, и 
  только после его заполнения будет пытаться отправить его 
  содержимое клиенту.  Поэтому буферизированное проксирование 
  эффективнее, но может быть непригодно, если HTTP-ответы 
  используются для потоковой отправки данных с небольшой скоростью 
  (и тогда буферизацию имеет смысл отключать).

Кроме того, стоит помнить, что:

- В случае выключенной буферизации nginx не будет пытаться 
  прочитать целиком ответ от бэкенда, а вместо этого прекратит 
  чтение, как только у него закончится буфер и не будет 
  возможности отправить содержимое этого буфера клиенту.  В случае 
  со включённой буферизацией - похожего поведения можно 
  добиться, установив proxy_max_temp_file_size в 0 (с точностью до 
  того, что при этом будет используется не один буфер, а много).

- При выключенной буферизации невозможно сохранения ответа на 
  диск, и соответственно не будет работать кэширование и 
  proxy_store.

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

Re: Иногда в логах проскакивает SSL write() failed

2019-08-07 Пенетрантность Maxim Dounin
Hello!

On Mon, Aug 05, 2019 at 12:14:49PM -0400, grey wrote:

> Приветствую всех.
> 
> 
> Прикрутил к одному сайту защищенный протокол. Не сразу заметил, что во время
> наплыва посетителей сайт стал сильно тормозить, а в логах появляется
> ошибка:
> 
> 2019/08/05 17:32:57 [crit] 1832#2988: *131089 SSL_write() failed (10053:
> Программа на вашем хост-компьютере разорвала установленное подключение)
> while sending response to client, client: 5.18.*.*, server: ***.ru, request:
> "GET /logo.jpg HTTP/1.1", upstream: "http://127.0.0.1:81/logo.jpg;, host:
> "www.***.ru"
> 
> Версия nginx под Windows последняя 1.17.2. Сервер физический, но слабенький.
> Если отключить шифрование, то все летает. 
> upstream: "http://127.0.0.1:81; - это Апач. Может не хватает ресурсов
> процессора на шифрование трафика или я где-то накосячил?

Если я правильно понимаю, такая ошибка может (и должна) возникать, 
если клиент закрывает соединение в процессе получения ответа.

Уровень логгирования в данном случае завышен в случае 
SSL-соединений, так как SSL-код не учитывает особенности виндов.  
Какой-то такой патч должен проблему закрыть, снизив уровень 
логгирования до стандартного в подобных ситуациях:

# HG changeset patch
# User Maxim Dounin 
# Date 1565182777 -10800
#  Wed Aug 07 15:59:37 2019 +0300
# Node ID 50a68c37eb3b399aca25ffa06527f263d1961e07
# Parent  fcd92ad76b7bb04b46c4b8fdfe14b6065acadf7d
SSL: lowered log level for WSAECONNABORTED errors on Windows.

Winsock uses ECONNABORTED instead of ECONNRESET, for normal connections
this is already handled since baad3036086e.

Reported at
http://mailman.nginx.org/pipermail/nginx-ru/2019-August/062363.html.

diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c
--- a/src/event/ngx_event_openssl.c
+++ b/src/event/ngx_event_openssl.c
@@ -2814,6 +2814,9 @@ ngx_ssl_connection_error(ngx_connection_
 if (sslerr == SSL_ERROR_SYSCALL) {
 
 if (err == NGX_ECONNRESET
+#if (NGX_WIN32)
+|| err == NGX_ECONNABORTED
+#endif
 || err == NGX_EPIPE
     || err == NGX_ENOTCONN
 || err == NGX_ETIMEDOUT

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

Re: Падает nginx в случае истечения срока действия сертификата

2019-08-02 Пенетрантность Maxim Dounin
Hello!

On Fri, Aug 02, 2019 at 06:36:06PM +0300, Иван Мишин wrote:

> Добрый день. Есть множество хостов вида:
> 
> > server {
> > listen 80;
> > server_name example.com;
> > location / {
> > proxy_ssl_session_reuse off;
> > proxy_ssl_certificate /etc/nginx/include/client/client.cer;
> > proxy_ssl_certificate_key
> > 'engine:gostengy:n6e6e829f94729896d0e38a814354dcdec4e456';
> > proxy_ssl_ciphers
> > GOST2012-GOST8912-GOST8912:GOST2001-GOST89-GOST89:HIGH;
> > proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
> > proxy_pass https://world.cnet;
> > proxy_set_header Host world.net;
> > proxy_set_header X-Real-IP $remote_addr;
> >proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> > }
> > }
> 
> 
> В случае если у одного из хостов истекает срок действия сертификата, то
> отказывается работать nginx. Т.е. перестают работать абсолютно  все вирт
> хосты.
> В логах ошибка вида:
> 
> > [emerg] 2169#2169:
> > ENGINE_load_private_key("9867b5ab2b2c88342766gg5e99a6a7c6ddc7e324") failed
> > (SSL: error:80015033:lib(128):gng_support_getuserkey:GNG_ERR_LICENSE
> > error:26096080:engine routines:ENGINE_load_private_key:failed loading
> > private key)
> 
> 
> хеши сертов в примерах изменил на ненастоящие.
> 
> Как сделать так чтобы nginx не ронял все хосты из-за того что на одном
> хосте просрочился серт? Может есть какая-то деректива специальная чтобы
> отключить например проверку срока годности сертификатов?

Судя по ошибке - nginx не падает, а отказывается запускаться из-за 
ошибки, которая возникает при загрузке сертификата .  Если вы 
nginx при этом не останавливали зачем-то сами - всё продолжит 
работать.

А вообще - вам к авторам engine'а, который вы используете для 
загрузки сертификатов, ошибка случается именно там.  Если бы 
вместо ошибки был загружен-таки просроченный сертификат, как это 
происходит при загрузке сертификатов из файлов - проблемы бы 
вообще не было.  Ну или просто переходите на файлы, и будет вам 
счастье.

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

Re: обработка set_real_ip_from для 400-х статусов

2019-07-29 Пенетрантность Maxim Dounin
Hello!

On Fri, Jul 26, 2019 at 10:56:35AM +0300, Иван Мишин wrote:

> Столкнулся с такой же проблемой. Есть какое-то объяснение этому?

[...]

> > curl --header "X-Real-IP: 8.9.10.11" - -I  -k http://localhost/test
> > curl --header "X-Real-IP: 8.9.10.11" - -I  -k http://localhost/%
> >
> > получаю
> >
> > # cat /var/log/nginx/access.log
> > 8.9.10.11 8.9.10.11 200 /test
> > 127.0.0.1 - 400
> >
> >
> > почему магия с форматом лога и хедерами работает на 200-х статусах и не
> > работает на 400-х ? это такая задумка ? выглядит как баг.

Запрос к "/%" распарсить невозможно, так как сочетание "%%" 
недопустимо по стандартну HTTP.  Соответственно ошибка возникает 
уже на этапе парсинга request line, и ни о какой обработке такого 
запроса речи не идёт.  Соответственно не будет работать и 
realip-модуль.

Более того - в данном конкретном случае, так как ошибка возникает 
на этапе парсинга request line, то в тех ошмётках запроса, которые 
nginx успел распарсить - заголовка X-Real-IP не будет.  То есть 
в данном случае даже если бы модуль realip что-то попытался 
сделать с запросом - у него ничего бы не получилось.  А равно 
ничего не получится увидеть при логгировании $http_x_real_ip.

Отдельно отмечу, что с точки зрения логики работы - текущее 
поведение выглядит как наиболее правильное.  Если с IP-адреса 
приходит невалидный HTTP-запрос, то даже если этот адрес вдруг 
значится в set_real_ip_from - логгировать надо именно адрес, с 
которого нам прислали этот невалидный запрос, потому как 
разбираться надо именно с тем софтом, что на этом адресе стоит и 
невалидный запрос сформировал.

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

[nginx-ru-announce] nginx-1.17.2

2019-07-23 Пенетрантность Maxim Dounin
Изменения в nginx 1.17.2  23.07.2019

*) Изменение: минимальная поддерживаемая версия zlib - 1.2.0.4.
   Спасибо Илье Леошкевичу.

*) Изменение: метод $r->internal_redirect() встроенного перла теперь
   ожидает закодированный URI.

*) Добавление: теперь с помощью метода $r->internal_redirect()
   встроенного перла можно перейти в именованный location.

*) Исправление: в обработке ошибок во встроенном перле.

*) Исправление: на старте или во время переконфигурации мог произойти
   segmentation fault, если в конфигурации использовалось значение hash
   bucket size больше 64 килобайт.

*) Исправление: при использовании методов обработки соединений select,
   poll и /dev/poll nginx мог нагружать процессор во время
   небуферизованного проксирования и при проксировании
   WebSocket-соединений.

*) Исправление: в модуле ngx_http_xslt_filter_module.

*) Исправление: в модуле ngx_http_ssi_filter_module.


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

nginx-1.17.2

2019-07-23 Пенетрантность Maxim Dounin
Изменения в nginx 1.17.2  23.07.2019

*) Изменение: минимальная поддерживаемая версия zlib - 1.2.0.4.
   Спасибо Илье Леошкевичу.

*) Изменение: метод $r->internal_redirect() встроенного перла теперь
   ожидает закодированный URI.

*) Добавление: теперь с помощью метода $r->internal_redirect()
   встроенного перла можно перейти в именованный location.

*) Исправление: в обработке ошибок во встроенном перле.

*) Исправление: на старте или во время переконфигурации мог произойти
   segmentation fault, если в конфигурации использовалось значение hash
   bucket size больше 64 килобайт.

*) Исправление: при использовании методов обработки соединений select,
   poll и /dev/poll nginx мог нагружать процессор во время
   небуферизованного проксирования и при проксировании
   WebSocket-соединений.

*) Исправление: в модуле ngx_http_xslt_filter_module.

*) Исправление: в модуле ngx_http_ssi_filter_module.


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

Re: SSL сертификаты

2019-07-23 Пенетрантность Maxim Dounin
Hello!

On Tue, Jul 23, 2019 at 02:40:59AM -0400, rihad wrote:

> > Если загрузка кэша не завершена - nginx при обращении к элементу
> > кэша, которого ещё нет в памяти, явно проверяет, есть ли
> > соответствующий файл на диске. То есть к лишним обращениям на
> > бэкенд это не приводит.
> 
> Глядя на объемы памяти RSS, а также на текущий обрабатываемый каталог из
> вывода lsof,  у меня такое впечатление что при SIGHUP nginx и запуске
> второго cache loader (первый при этом не умирает, убиваю его через TERM
> вручную) уже прочитанные объекты из shared memory не стираются, т.е. он
> просто продолжает откуда его прервали. Так ли это? Спасибо.

Вообще если cache loader уже работает с кэшом, то новый cache loader 
при релоаде не запускается.  Может запуститься, если кэшей больше 
одного - и начнёт загружать другие кэши.  Каждый кэш загружается 
единожды, так что наличие больее чем одного cache loader'а - 
влияет разве что на параллелизм процесса.

Уже загруженные элементы из памяти, естественно, не стираются, но 
продолжать откуда прервали cache loader не умеет, и в случае чего 
будет обходить каталог кэша заново.  Если кэшей много, и какие-то 
полностью загружены - они загружаться заново не будут.

Но вообще убивать старый cache loader - это в любом случае плохая 
идея, с некоторой вероятностью не повезёт (практически 
гарантированно, если не успеть в первую минуту после запуска 
нового cache loader'а), и кэш, с которым он работал, так и 
останется незагруженным.

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

Re: SSL сертификаты

2019-07-22 Пенетрантность Maxim Dounin
Hello!

On Mon, Jul 22, 2019 at 01:12:38PM -0400, rihad wrote:

> И еще параллельно такой вопрос возник: у нас крутящиеся диски на одном из
> серверов, и proxy_cache_path levels=1:2 все это приводит к тому, что в
> каждой директории где-то 3-4 тысячи файлов

3-4 тысячи файлов на каталог - это плюс-минус нормально.

> (я так понимаю поменять на 2:2 + reload уже нельзя?).

Да, поменять levels можно только создав новый кэш, перекладывать 
из одной структуры в другую nginx не умеет.  Если попытаться 
поменять levels при reload'е - nginx выругается и откажется 
загружать новую конфигурацию.  Если остановить и запустить заново - 
сотрёт содержимое, не соответствующее заданным levels.

> cache_loader при старте работает довольно долго, но не
> грузит. Он очень мало CPU времени тратит или дискового, за сутки работы
> сейчас он потратил 0:04.37 (согласно ps) это 4 минуты, но он не
> заканчивается. lsof показывает что он очень много времени проводит на каждой
> из директорий кэша. А их тысячи. Надеюсь он не читает весь файл
> (преимущественно картинки), а только его начало с заголовками? ))

Сейчас cache loader вообще не читает файлы, только каталоги.
Чтобы работал побыстрее - можно поиграться с параметрами 
loader_files, loader_threshold и loader_sleep, подробности тут:

http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_path

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

При параметрах по умолчанию - loader_files 100, loader_sleep 50 
миллисекунд - и бесконечно быстрых дисках - загрузка кэша с 16 
миллионами файлов (16 x 16 x 16 x 4000 = 16384000) должна занимать 
чуть больше трёх часов (50ms * 16384000 / 100 = 8192000ms = 
8192s).

Если загрузка занимает больше - значит, срабатывает 
loader_threshold, и loader спит чаще, чем раз в 100 файлов.  Для 
вращающихся дисков это нормально.  Но это и в свою очередь означает, 
что если для ускорения загрузки начать увеличивать loader_files и 
loader_threshold, а равно уменьшать loader_sleep - нагрузка на 
диски станет больше, и кэш может начать тормозить.

> Может ли
> его такая тормознутость привести к повторному запросу ресурса из источника и
> повторному кэшированию? Что делает nginx когда в кэше пока объекта нет,
> пытается ли сам к диску обратиться?

Если загрузка кэша не завершена - nginx при обращении к элементу 
кэша, которого ещё нет в памяти, явно проверяет, есть ли 
соответствующий файл на диске.  То есть к лишним обращениям на 
бэкенд это не приводит.

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

Re: SSL сертификаты

2019-07-22 Пенетрантность Maxim Dounin
Hello!

On Mon, Jul 22, 2019 at 12:17:55PM -0400, rihad wrote:

> Можно как-то обойтись без reload (SIGHUP) nginx для того чтобы он перечитал
> с диска сертификаты (ssl_certificate)? Без этого он не бывает в курсе что
> они были обновлены.

В свежих версиях - можно, если в директиве ssl_certificate будут 
использоваться переменные, то nginx будет грузить эти сертификаты 
при каждом SSL handshake'е.

Но лучше так не делать без острой нужды, так как у этого подхода 
хватает своих проблем - начиная от производительности (так как 
сертификаты и ключи загружаются при каждом handshake'е) и 
заканчивая безопасностью (при такой схеме требуются права на 
чтение ключей не только root'у, но и рабочим процессам nginx'а).

> Но у релоад есть плохая штука что он наверняка забывает
> такие вещи как inactive=nnn в директиве proxy_cache_path, и если reload
> происходит раз в неделю, то любой inactive выше недели по сути ничего не
> делает.

Это не так.  Если конфигурация кэша не менялась - то данные о 
активности элементов кэша при reload'е не теряются.

> Также каждый релоад требует перечтения всех имеющихся данных cache
> loader'ом, а когда таких данных сотни гигов и диски (пока :)) крутящиеся,
> директива max_size не способна ограничивать дисковое пространство (т.к. пока
> loader все файлы не перечитает nginx не знает сколько пространства занято,
> если не ошибаюсь).

И это не так.  Если конфигурация кэша не менялась - информация о 
содержимом кэша при reload'е не перечитывается.

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

Re: too long parameter

2019-07-09 Пенетрантность Maxim Dounin
Hello!

On Tue, Jul 09, 2019 at 12:21:44PM +0100, Anton Kiryushkin wrote:

> Здравствуйте.
> 
> Пока не получается воспроизвести проблему, но в логе ошибок переодически
> возникает сообщение вида:
> 
> too long parameter "#
> На строке, которая, и является комментарием:
> # this is search location for service srv784
> 
> Таких строчек-комментариев (конфиг генерируется скриптом) у меня в файле
> довольно много.
> Все бы и ничего, но nginx по каким-то причинам после этого сообщения
> перестает слушать порты на какое-то время.
> 
> Что с этим можно сделать и вообще что это такое? Гугл не помог. Версия
> nginx 1.12.0.
> Сам конфиг, ну примитивный, 5 location без реврайтов и regexp.

Длина комментария, как и любого параметра, не может превышать 4096 
байт.  Если nginx ругается - скорее всего длина превышена.  Если и 
правда ругается сообщением вида:

> too long parameter "#

то есть без каких-либо дополнительных символов после "#", то 
скорее всего речь о том, что файл застали в процессе генерации, и 
следом прочитались нули в больших количествах.

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

Re: location

2019-07-09 Пенетрантность Maxim Dounin
Hello!

On Tue, Jul 09, 2019 at 12:07:52PM +0300, Slawa Olhovchenkov wrote:

> On Tue, Jul 09, 2019 at 11:51:19AM +0300, Maxim Dounin wrote:
> 
> > Hello!
> > 
> > On Mon, Jul 08, 2019 at 07:24:33PM +0300, Slawa Olhovchenkov wrote:
> > 
> > > On Mon, Jul 08, 2019 at 07:11:59PM +0300, Maxim Dounin wrote:
> > > 
> > > > > > > action тут разный. я на этом внимание не заострил, думал и так 
> > > > > > > понятно
> > > > > > 
> > > > > > Понятно.  И также понятно, что даже при одном и том же action - 
> > > > > > приведённые команды делают разное, и результаты могут кардинально 
> > > > > > отличаться в том числе из-за этого.  Именно поэтому я и указал на 
> > > > > > эту проблему как на одну из возможных причин наблюдаемого 
> > > > > > поведения.  Дабы подобную проблему гарантированно исключить - 
> > > > > > лучше всего использовать одну и ту же форму команды.
> > > > > 
> > > > > так не бывает же `nginx -s restart`, т.е. `nginx stop && nginx start`
> > > > 
> > > > Зато бывает "service nginx reload" и "service nginx restart".
> > > > 
> > > > (Ну и вообще, использовать "nginx -s ..." на юникс-системах - 
> > > > странно.  Как минимум попадаем на двойной парсинг конфигурации, 
> > > > как максимум - на невозможность использовать эти команды, если 
> > > > PID-файл надо переложить в другое место.)
> > > 
> > > набирать короче, давно заучил, а эти service вечно меняются...
> > 
> > Форма "service  " работает начиная с FreeBSD 7.3, и 
> > с момента появления не менялась.
> 
> есть еще линуксы в разных вариантах и они сбивают.
> а у них еще и имя сервиса различается в зависимости от пакета.
> ну и я с фрей работаю начиная с 2.0.5 :)

Если подходить к проблеме с точки зрения "есть ещё", то "nginx 
-s" вообще непоняно что делает, потому что a) nginx может быть 
более чем один, и б) в скриптах запуска может быть всяких опций 
прописано, включая другой конфиг.

> > > > > > - После чего был сделан reload - и привёл к той же ошибке "module 
> > > > > >   ... is already loaded", что было проигнорировано.  Так
> > > > > 
> > > > > нет, он не нашел ndk_* символов.
> > > > > после чего я добавил строку с загрузко ndk_http.
> > > > 
> > > > Не нашёл символов - в процессе тестирования конфигурации с помощью 
> > > > "nginx -t" и/или при парсинге конфигурации в процессе запуска 
> > > > "nginx -s"?
> > > 
> > > вот тут не помню.
> > > 
> > > > Ожидаемо, так как у свежезапущенных экземпляров nginx'а нет 
> > > > загруженных модулей, и они получают то, что было на диске.  И это 
> > > > одна из причин, почему reload не стоит предварять запуском "nginx -t", 
> > > > и не стоит использовать "nginx -s".
> > > 
> > > ничего не понял.
> > 
> > В рассматриваемом случае содержимое бинарных файлов на диске 
> > (nginx + модули) - поменялось.  Более того, поменялось - 
> > несовместимо, для работы старых бинарных файлов требовалась одна 
> > конфигурация, для работы новых - другая.
> > 
> > Когда такое происходит, использование "nginx -t" и "nginx -s 
> > " совместно с перезагрузкой конфигурации на лету - 
> > невозможно.  Проблема в том, что эти команды требуют конфигурацию, 
> > совместимую с новыми бинарными файлами, тогда как для перезагрузки 
> > конфигурации работающего nginx'а - нужна конфигурация, совместимая 
> > со старыми бинарными файлами.
> > 
> > Проще всего - в такую ситуацию не попадать, и после обновления 
> > бинарных файлов (что самого nginx'а, что модулей) - сразу делать 
> > upgrade, синхронизируя бинарники на дисках, и в памяти.  Но вообще 
> > говоря работа в несинхронизированном состоянии тоже возможна - 
> > просто надо пользоваться сигналами, а не пытаться использовать 
> > nginx с диска (который не совпадает с тем, что в памяти).
> 
> так, т.е. nginx -s reload не эквивалентно kill -HUP `cat /var/run/nginx.pid`?
> и вторая комманда срабоатла бы по старому варианту конфига и не стала
> бы ругаться на неопределенные символы?

Именно так.  Команда "nginx -s reload" сначала парсит конфиг, 
чтобы найти путь к этому самому /var/run/nginx.pid - и на этом 
пути делает много лишней (но неизбежной) работы, в частности - 
ругается, встретив неправильную с её точки зрения конфигурацию.

Впрочем, завести привычку после обновления модулей делать upgrade 
(равно как и после обновления самого nginx'а) - в любом случае 
стоит.  Если upgrade не сделать, а продолжать работать с тем, что 
в памяти, то при перезагрузке машины, например, может случиться 
неприятный сюрприз.

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

Re: location

2019-07-09 Пенетрантность Maxim Dounin
Hello!

On Mon, Jul 08, 2019 at 07:24:33PM +0300, Slawa Olhovchenkov wrote:

> On Mon, Jul 08, 2019 at 07:11:59PM +0300, Maxim Dounin wrote:
> 
> > > > > action тут разный. я на этом внимание не заострил, думал и так понятно
> > > > 
> > > > Понятно.  И также понятно, что даже при одном и том же action - 
> > > > приведённые команды делают разное, и результаты могут кардинально 
> > > > отличаться в том числе из-за этого.  Именно поэтому я и указал на 
> > > > эту проблему как на одну из возможных причин наблюдаемого 
> > > > поведения.  Дабы подобную проблему гарантированно исключить - 
> > > > лучше всего использовать одну и ту же форму команды.
> > > 
> > > так не бывает же `nginx -s restart`, т.е. `nginx stop && nginx start`
> > 
> > Зато бывает "service nginx reload" и "service nginx restart".
> > 
> > (Ну и вообще, использовать "nginx -s ..." на юникс-системах - 
> > странно.  Как минимум попадаем на двойной парсинг конфигурации, 
> > как максимум - на невозможность использовать эти команды, если 
> > PID-файл надо переложить в другое место.)
> 
> набирать короче, давно заучил, а эти service вечно меняются...

Форма "service  " работает начиная с FreeBSD 7.3, и 
с момента появления не менялась.

> > > > - После чего был сделан reload - и привёл к той же ошибке "module 
> > > >   ... is already loaded", что было проигнорировано.  Так
> > > 
> > > нет, он не нашел ndk_* символов.
> > > после чего я добавил строку с загрузко ndk_http.
> > 
> > Не нашёл символов - в процессе тестирования конфигурации с помощью 
> > "nginx -t" и/или при парсинге конфигурации в процессе запуска 
> > "nginx -s"?
> 
> вот тут не помню.
> 
> > Ожидаемо, так как у свежезапущенных экземпляров nginx'а нет 
> > загруженных модулей, и они получают то, что было на диске.  И это 
> > одна из причин, почему reload не стоит предварять запуском "nginx -t", 
> > и не стоит использовать "nginx -s".
> 
> ничего не понял.

В рассматриваемом случае содержимое бинарных файлов на диске 
(nginx + модули) - поменялось.  Более того, поменялось - 
несовместимо, для работы старых бинарных файлов требовалась одна 
конфигурация, для работы новых - другая.

Когда такое происходит, использование "nginx -t" и "nginx -s 
" совместно с перезагрузкой конфигурации на лету - 
невозможно.  Проблема в том, что эти команды требуют конфигурацию, 
совместимую с новыми бинарными файлами, тогда как для перезагрузки 
конфигурации работающего nginx'а - нужна конфигурация, совместимая 
со старыми бинарными файлами.

Проще всего - в такую ситуацию не попадать, и после обновления 
бинарных файлов (что самого nginx'а, что модулей) - сразу делать 
upgrade, синхронизируя бинарники на дисках, и в памяти.  Но вообще 
говоря работа в несинхронизированном состоянии тоже возможна - 
просто надо пользоваться сигналами, а не пытаться использовать 
nginx с диска (который не совпадает с тем, что в памяти).

> > > >   происходит, потому что с помощью reload'а нельзя изменить ранее 
> > > >   загруженный модуль - so-шка уже в памяти, и при попытке её снова 
> > > >   открыть - откроется старая so-шка.  Чтобы загрузить новые модули 
> > > >   после изменения их so-файлов на диске - нужно делать upgrade.
> > > 
> > > а чего он их тогда полез открывать-то?
> > > меня устроили бы старые модули.
> > 
> > В новой конфигурации - новый список модулей, они открываются / 
> > загружаются в соответствии с тем, что задано в директивах 
> > load_module в конфиге.  Поскольку в список добавился ndk - nginx 
> > его попытался загрузить, поскольку в результате оказалось 
> > загружено два одинаковых модуля - выдал ошибку и откатился на 
> > предыдущую конфигурацию.
> 
> погоди. изначально список модулей не менялся, но конфигурация не
> применилась потому что при открытии модуля выяснилось что его разбили
> на два и теперь у него символы не находятся.

Нет.  Если бы конфигурацию, не меняя, перегрузили в работающем 
nginx'е с помощью сигналов - она бы прекрасно применилась.  
Проблема именно в том, что конфигурацию - изменили на такую, 
которая не совместима с работающим nginx'ом.

> но как сказанно выше -- изменять загруженные модули нельзя, т.е. его и
> не надо было открывать и тогда этой ошибки и не было бы. так?

Когда дело дошло до загрузки конфигурации в работающем nginx'е - в 
этой самой конфигурации присутствовал как ранее загруженный 
модуль, так и дополнительный модуль, дублирующий часть ранее 
загруженного.  Ранее загруженный модуль - фактически, просто 
пер

Re: location

2019-07-08 Пенетрантность Maxim Dounin
Hello!

On Mon, Jul 08, 2019 at 04:55:40PM +0300, Slawa Olhovchenkov wrote:

> On Mon, Jul 08, 2019 at 04:29:06PM +0300, Maxim Dounin wrote:
> 
> > > > > есть кусок конфига
> > > > > location /pkg { alias /poudriere/data/packages; index  index.html 
> > > > > index.htm; }
> > > > > добавляем
> > > > > 
> > > > > location /pkg/edge12-default { proxy_pass http://X.Y.Z.Q; }
> > > > > nginx -s reload
> > > > > 
> > > > > и призапросе получеам такую ошибку:
> > > > > 
> > > > > 2019/07/05 19:07:05 [error] 23182#0: *102388 directory index of 
> > > > > "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 
> > > > > 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ 
> > > > > HTTP/1.1", host: "pkg.int.integros.com"
> > > > > 
> > > > > что за фигня?
> > > > > а если сделать
> > > > > 
> > > > > /usr/local/etc/rc.d/nginx restart
> > > > > 
> > > > > то все начинает работать
> > > > > что за нафиг?
> > > > 
> > > > In no particular order:
> > > > 
> > > > - "nginx -s " и "/usr/local/etc/rc.d/nginx " - не 
> > > 
> > > action тут разный. я на этом внимание не заострил, думал и так понятно
> > 
> > Понятно.  И также понятно, что даже при одном и том же action - 
> > приведённые команды делают разное, и результаты могут кардинально 
> > отличаться в том числе из-за этого.  Именно поэтому я и указал на 
> > эту проблему как на одну из возможных причин наблюдаемого 
> > поведения.  Дабы подобную проблему гарантированно исключить - 
> > лучше всего использовать одну и ту же форму команды.
> 
> так не бывает же `nginx -s restart`, т.е. `nginx stop && nginx start`

Зато бывает "service nginx reload" и "service nginx restart".

(Ну и вообще, использовать "nginx -s ..." на юникс-системах - 
странно.  Как минимум попадаем на двойной парсинг конфигурации, 
как максимум - на невозможность использовать эти команды, если 
PID-файл надо переложить в другое место.)

> > [...]
> > 
> > > > - reload может быть невозможен при некоторых изменениях - в 
> > > >   частности, "на лету" нельзя менять путь и levels у кэша, так как 
> > > >   для их изменения требуется повторная загрузка кэша - либо же 
> > > 
> > > кэш не менялся, я привел разницу в строках.
> > 
> > С учётом того, что ошибка reload'а нашлась только после явного 
> > указания на то, что надо искать - мы не знаем, что менялось, а что 
> > нет.
> > 
> > > >   может просто завершиться ошибкой по внешним причинам; ошибки об 
> > > >   этом будут в глобальном логе в процессе перезагрузки конфигурации;
> > > 
> > > а вот тут интересный момент.
> > > restart прошел успешно с тем же конфигом. значит конфиг норм, да?
> > > а reload -- нифига. было ли об этом сказанно в лог -- ну вот фиг
> > > поймешь (такой уж лог).
> > > 
> > > 2019/07/05 19:13:59 [warn] 81052#0: the number of "worker_processes" is 
> > > not equal to the number of "worker_cpu_affinity" masks, using last mask 
> > > for remaining worker processes
> > > 2019/07/05 19:13:59 [notice] 81052#0: signal process started
> > > 2019/07/05 19:13:59 [notice] 939#0: signal 1 (SIGHUP) received from 
> > > 81052, reconfiguring
> > > 2019/07/05 19:13:59 [notice] 939#0: reconfiguring
> > > 2019/07/05 19:13:59 [emerg] 939#0: module "ndk_http_module" is already 
> > > loaded in /usr/local/etc/nginx/nginx.conf:1
> > > 2019/07/05 19:14:03 [error] 23182#0: *102391 directory index of 
> > > "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 
> > > 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", 
> > > host: ""
> > > 
> > > ну вот что я должен заключить? вроде emerg. но написанно is already 
> > > loaded. т.е. фиг с ним?
> > 
> > Уровень emerg - это фатальная ошибка, после таких ошибок парсинг 
> > конфигурации прекращается.  Если бы nginx считал, что проблему 
> > можно игнорировать - уровень ошибки был бы другой, и, для высоких 
> > уровней, рядом было бы написано "ignored".
> 
> а alert у нас что?

Уровень alert используется для логгирования серьёзных проблем, 
однако, в отличи от emerg, он не означает, что дал

Re: location

2019-07-08 Пенетрантность Maxim Dounin
Hello!

On Sat, Jul 06, 2019 at 09:04:00PM +0300, Slawa Olhovchenkov wrote:

> On Sat, Jul 06, 2019 at 08:38:19PM +0300, Maxim Dounin wrote:
> 
> > Hello!
> > 
> > On Fri, Jul 05, 2019 at 07:17:01PM +0300, Slawa Olhovchenkov wrote:
> > 
> > > есть кусок конфига
> > > 
> > > location /pkg { alias /poudriere/data/packages; index  index.html 
> > > index.htm; }
> > > 
> > > добавляем
> > > 
> > > location /pkg/edge12-default { proxy_pass http://X.Y.Z.Q; }
> > > 
> > > nginx -s reload
> > > 
> > > и призапросе получеам такую ошибку:
> > > 
> > > 2019/07/05 19:07:05 [error] 23182#0: *102388 directory index of 
> > > "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 
> > > 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", 
> > > host: "pkg.int.integros.com"
> > > 
> > > что за фигня?
> > > а если сделать
> > > 
> > > /usr/local/etc/rc.d/nginx restart
> > > 
> > > то все начинает работать
> > > что за нафиг?
> > 
> > In no particular order:
> > 
> > - "nginx -s " и "/usr/local/etc/rc.d/nginx " - не 
> 
> action тут разный. я на этом внимание не заострил, думал и так понятно

Понятно.  И также понятно, что даже при одном и том же action - 
приведённые команды делают разное, и результаты могут кардинально 
отличаться в том числе из-за этого.  Именно поэтому я и указал на 
эту проблему как на одну из возможных причин наблюдаемого 
поведения.  Дабы подобную проблему гарантированно исключить - 
лучше всего использовать одну и ту же форму команды.

[...]

> > - reload может быть невозможен при некоторых изменениях - в 
> >   частности, "на лету" нельзя менять путь и levels у кэша, так как 
> >   для их изменения требуется повторная загрузка кэша - либо же 
> 
> кэш не менялся, я привел разницу в строках.

С учётом того, что ошибка reload'а нашлась только после явного 
указания на то, что надо искать - мы не знаем, что менялось, а что 
нет.

> >   может просто завершиться ошибкой по внешним причинам; ошибки об 
> >   этом будут в глобальном логе в процессе перезагрузки конфигурации;
> 
> а вот тут интересный момент.
> restart прошел успешно с тем же конфигом. значит конфиг норм, да?
> а reload -- нифига. было ли об этом сказанно в лог -- ну вот фиг
> поймешь (такой уж лог).
> 
> 2019/07/05 19:13:59 [warn] 81052#0: the number of "worker_processes" is not 
> equal to the number of "worker_cpu_affinity" masks, using last mask for 
> remaining worker processes
> 2019/07/05 19:13:59 [notice] 81052#0: signal process started
> 2019/07/05 19:13:59 [notice] 939#0: signal 1 (SIGHUP) received from 81052, 
> reconfiguring
> 2019/07/05 19:13:59 [notice] 939#0: reconfiguring
> 2019/07/05 19:13:59 [emerg] 939#0: module "ndk_http_module" is already loaded 
> in /usr/local/etc/nginx/nginx.conf:1
> 2019/07/05 19:14:03 [error] 23182#0: *102391 directory index of 
> "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 
> 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", 
> host: ""
> 
> ну вот что я должен заключить? вроде emerg. но написанно is already loaded. 
> т.е. фиг с ним?

Уровень emerg - это фатальная ошибка, после таких ошибок парсинг 
конфигурации прекращается.  Если бы nginx считал, что проблему 
можно игнорировать - уровень ошибки был бы другой, и, для высоких 
уровней, рядом было бы написано "ignored".

Что до самой ошибки и того факта, что ломается оно только на 
релоаде, но не на рестарте - то единственный сценарий, который 
приходит в голову, какой-то такой:

- Был загружен модуль, совмещающий в одном so-файле что-то ещё и 
  ndk_http_module;

- Файл *.so на диске поменялся, и теперь содержит только что-то ещё, 
  а ndk_http_module был добавлен отдельной директивой load_module.

- После чего был сделан reload - и привёл к той же ошибке "module 
  ... is already loaded", что было проигнорировано.  Так 
  происходит, потому что с помощью reload'а нельзя изменить ранее 
  загруженный модуль - so-шка уже в памяти, и при попытке её снова 
  открыть - откроется старая so-шка.  Чтобы загрузить новые модули 
  после изменения их so-файлов на диске - нужно делать upgrade.

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

Re: ssl_early_data для TLS1.2 ?

2019-07-06 Пенетрантность Maxim Dounin
Hello!

On Thu, Jul 04, 2019 at 12:09:22AM +0500, Илья Шипицин wrote:

> привет!
> 
> в конфиге на уровне http указано "ssl_early_data on;"
> 
> в сервере, в котором нужен TLS1.2 (не задан TLS1.3) не задан никак
> ssl_early_data.
> судя по debug-логу - наследуется от уровня http, и пытается найти в пакетах
> early data.
> 
> по спецификации, на TLS1.2 такого не должно быть.
> 
> может проверять наличие TLS1.3 для включения этой опции (даже
> унаследованной от более высоких уровней) ?

Чтобы что?  В случае, если соединение использует TLSv1.2 - 
соединение уйдёт в обычное чтение, как только OpenSSL нам об этом 
скажет.  Дублировать знание о том, где именно бывает early data, а 
где не бывает, в самом nginx'е - выглядит как ненужное усложнение.

Правильнее всего это место сделано в BoringSSL - там вообще один 
интерфейс для чтения, и если чтение early data включено - то этот 
интерфейс он просто возвращает 0-rtt-данные в случае их наличия.

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

Re: location

2019-07-06 Пенетрантность Maxim Dounin
Hello!

On Fri, Jul 05, 2019 at 07:17:01PM +0300, Slawa Olhovchenkov wrote:

> есть кусок конфига
> 
> location /pkg { alias /poudriere/data/packages; index  index.html index.htm; }
> 
> добавляем
> 
> location /pkg/edge12-default { proxy_pass http://X.Y.Z.Q; }
> 
> nginx -s reload
> 
> и призапросе получеам такую ошибку:
> 
> 2019/07/05 19:07:05 [error] 23182#0: *102388 directory index of 
> "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 
> 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", 
> host: "pkg.int.integros.com"
> 
> что за фигня?
> а если сделать
> 
> /usr/local/etc/rc.d/nginx restart
> 
> то все начинает работать
> что за нафиг?

In no particular order:

- "nginx -s " и "/usr/local/etc/rc.d/nginx " - не 
  одно и то же, и могут делать совсем разное, если, например, на 
  машине более чем один nginx;

- reload может быть невозможен при некоторых изменениях - в 
  частности, "на лету" нельзя менять путь и levels у кэша, так как 
  для их изменения требуется повторная загрузка кэша - либо же 
  может просто завершиться ошибкой по внешним причинам; ошибки об 
  этом будут в глобальном логе в процессе перезагрузки конфигурации;

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

Re: NginX крошится с libperl-5.30

2019-07-02 Пенетрантность Maxim Dounin
Hello!

On Sat, Jun 29, 2019 at 08:00:59PM +0300, Vadim A. Misbakh-Soloviov wrote:

> Поправка: оно не падает в таком положении (даже на той машине) ТОЛЬКО если 
> цепляться по -p (без дебага, замечу, падает. Так что странно).
> 
> Попробовал запустить напрямую под gdb, получил такое:
> 
> ```
> #0  0x7492d0c7 in raise () from /lib64/libc.so.6
> #1  0x7492eaf9 in abort () from /lib64/libc.so.6
> #2  0x749242a9 in ?? () from /lib64/libc.so.6
> #3  0x74924331 in __assert_fail () from /lib64/libc.so.6
> #4  0x74e1d28f in S__invlist_len (invlist=0x55ea8078) at 
> invlist_inline.h:49

[...]

> #11 0x74e5d0d2 in S_reg (my_perl=0x55dd5c60, 
> pRExC_state=0x7fff8da0, paren=0, flagp=0x7fff8ad8, depth=1) at 
> regcomp.c:12088
> #12 0x74e3ebf7 in Perl_re_op_compile (my_perl=0x55dd5c60, 
> patternp=0x0, pat_count=1, expr=0x55dee908, eng=0x7532b9a0 
> , old_re=0x0, is_bare_re=0x0, orig_rx_flags=0, 
> pm_flags=1073741824) at regcomp.c:7705

Всё это по прежнему выгядит как падение собственно перла в 
процессе компиляции регулярного выражения.  Судя по:

> #16 0x7500f64e in S_require_file (my_perl=0x55dd5c60, 
> sv=0x55b9ce10) at pp_ctl.c:4322
> #17 0x7500f7aa in Perl_pp_require (my_perl=0x55dd5c60) at 
> pp_ctl.c:4346

и по:

> #26 0x7500f64e in S_require_file (my_perl=0x55dd5c60, 
> sv=0x55e35038) at pp_ctl.c:4322
> #27 0x7500f7aa in Perl_pp_require (my_perl=0x55dd5c60) at 
> pp_ctl.c:4346

в процессе загрузки какого-то модуля, видимо второго по 
вложенности.  С учётом того, что при создании perl-интерпретатора 
nginx автоматически загружает модуль nginx - видимо, падение 
вызывает что-то, что подтягивается из nginx.pm.  Там в свою 
очередь используются Exporter и XSLoader, но ничего нетривиального 
в них не видно.  Впрочем, это может быть и что-то из site-local 
загрузки.

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

Впрочем, если перл в nginx'е не используется - проще всего 
perl-модуль убрать из сборки и заб(ы|и)ть.  

[...]

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

Re: NginX крошится с libperl-5.30

2019-06-29 Пенетрантность Maxim Dounin
Hello!

On Sat, Jun 29, 2019 at 03:24:35PM +0300, Vadim A. Misbakh-Soloviov wrote:

> > Судя по трейсу - Perl падает где-то в компиляции регулярных
> > выражений.  Это, конечно, может быть и какой-то проблемой в
> > nginx'е, но я бы поставил скорее на проблему в перле, которую
> > триггерят используемые в коде регулярные выражения.
> 
> Ну, в коде, вроде как, не используется никаких особо упоротых регулярок. В 
> основном - всякие `location ~* \.php$` и в таком ключе.

Нет, регулярные выражения в конфиге nginx'а - nginx обрабатывает 
сам.  Надо смотреть именно на perl-код.  В том числе это может 
быть код в используемых perl-модулях.

> Так что, по идее, не должно бы...
> 
> Ну и, я так понимаю, таки нужно пересобирать с дебагом и исходниками, чтобы 
> отсделить что где? :)

Для начала я бы попробовал получить простой способ воспроизведения 
проблемы - полный конфиг (включая perl-код) и последовательность действий, 
приводящие к падению.

Возможно - при использовании чего-нибудь простого вроде junk:true 
в malloc.conf (MALLOC_PERTURB_ на линуксе со стандартным аллокатором, 
подробности см. в mallopt(3)) оно начнёт падать сразу, и возможно 
даже без nginx'а.

А дальше - постараться вычленить, что именно вызывает проблему.  
Ну и неплохо бы проверить, не лечится ли всё банальным 
downgrade'ом на perl 5.28.x и/или upgrade'ом на 5.31.x.

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

Re: NginX крошится с libperl-5.30

2019-06-29 Пенетрантность Maxim Dounin
Hello!

On Sat, Jun 29, 2019 at 02:39:20PM +0300, Vadim A. Misbakh-Soloviov wrote:

> Уже в течение некоторого времени замечаю краши NgX при reload.
> 
> Сегодня дошли руки глянуть в чём дело, и обнаружил что крошится оно в 
> перловой 
> либе.
> 
> Попробовал подцепиться gdb'ом и получить трейс.
> 
> Вот что вышло:
> 
> 0x7f59c0c461f7 in Perl__invlist_intersection_maybe_complement_2nd () from 
> /usr/lib64/libperl.so.5.30
> (gdb)  bt full
> #0  0x7f59c0c461f7 in Perl__invlist_intersection_maybe_complement_2nd () 
> from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #1  0x7f59c0c46784 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #2  0x7f59c0c567b9 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #3  0x7f59c0c5c6a7 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #4  0x7f59c0c610f8 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #5  0x7f59c0c6156d in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #6  0x7f59c0c6647b in Perl_re_op_compile () from /usr/lib64/libperl.so.
> 5.30
> No symbol table info available.
> #7  0x7f59c0bfab3c in Perl_pmruntime () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #8  0x7f59c0c37851 in Perl_yyparse () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> #9  0x7f59c0ce1912 in ?? () from /usr/lib64/libperl.so.5.30
> No symbol table info available.
> 
> 
> 
> Если честно, не хочется пересобирать перл с дебагом (чтобы открыть символы от 
> #1 до #5), так что, надеюсь, этого трейса хватит. Но, если нет - скажите.

Судя по трейсу - Perl падает где-то в компиляции регулярных 
выражений.  Это, конечно, может быть и какой-то проблемой в 
nginx'е, но я бы поставил скорее на проблему в перле, которую 
триггерят используемые в коде регулярные выражения.

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

Re: проверка наличия файла ssl_trusted_certificate - обсудим ?

2019-06-29 Пенетрантность Maxim Dounin
Hello!

On Fri, Jun 28, 2019 at 01:27:50PM +0500, Илья Шипицин wrote:

> привет,
> 
> допустим, я указал ssl_trusted_certificate
> 
> [root@optional ilia]# grep ssl_trusted_certificate /etc/nginx/nginx.conf
> ssl_trusted_certificate /etc/nginx/ca.pem;
> [root@optional ilia]#
> 
> самого файла нет
> 
> [root@optional ilia]# ls -l /etc/nginx/ca.pem
> ls: cannot access /etc/nginx/ca.pem: No such file or directory
> [root@optional ilia]#
> 
> проверка синтаксиса проходит
> 
> [root@optional ilia]# nginx -t
> nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /etc/nginx/nginx.conf test is successful
> [root@optional ilia]#
> 
> 
> можно сделать, чтобы "nginx -t" фейлился ?

Такое может быть тогда и только тогда, когда файл из 
ssl_trusted_certificate не используется - e.g., переопределён во 
всех блоках server{}, где используется SSL, или SSL вообще не 
используется.

Заниматься проверкой ради проверки в подобных вырожденных
случаях - IMHO, особого смысла нет, в то время как кода придётся 
городить много.  А если/когда файл начнёт реально использоваться - 
будет ошибка при тестировании конфигурации.

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

[nginx-ru-announce] nginx-1.17.1

2019-06-25 Пенетрантность Maxim Dounin
Изменения в nginx 1.17.1  25.06.2019

*) Добавление: директива limit_req_dry_run.

*) Добавление: при использовании директивы hash в блоке upstream пустой
   ключ хэширования теперь приводит к переключению на round-robin
   балансировку.
   Спасибо Niklas Keller.

*) Исправление: в рабочем процессе мог произойти segmentation fault,
   если использовалось кэширование и директива image_filter, а ошибки с
   кодом 415 перенаправлялись с помощь директивы error_page; ошибка
   появилась в 1.11.10.

*) Исправление: в рабочем процессе мог произойти segmentation fault,
   если использовался встроенный перл; ошибка появилась в 1.7.3.


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

nginx-1.17.1

2019-06-25 Пенетрантность Maxim Dounin
Изменения в nginx 1.17.1  25.06.2019

*) Добавление: директива limit_req_dry_run.

*) Добавление: при использовании директивы hash в блоке upstream пустой
   ключ хэширования теперь приводит к переключению на round-robin
   балансировку.
   Спасибо Niklas Keller.

*) Исправление: в рабочем процессе мог произойти segmentation fault,
   если использовалось кэширование и директива image_filter, а ошибки с
   кодом 415 перенаправлялись с помощь директивы error_page; ошибка
   появилась в 1.11.10.

*) Исправление: в рабочем процессе мог произойти segmentation fault,
   если использовался встроенный перл; ошибка появилась в 1.7.3.


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

Re: location + rewrite и (де)кодирование URI

2019-06-19 Пенетрантность Maxim Dounin
Hello!

On Tue, Jun 18, 2019 at 04:45:13PM +0300, Gena Makhomed wrote:

> On 18.06.2019 15:26, Maxim Dounin wrote:
> 
> > И снова эксперимент плохой, негодный.
> 
> Вот полный конфиг тестового сервера:
> 
> server {
>  listen 8080;
> 
>  location /wiki1/ {
>  rewrite ^/wiki1/(.*) https://$host/$1;
>  }
> 
>  location /wiki2/ {
>  rewrite ^/wiki2/(?.*) https://$host/$title;
>  }
> }
> 
> Вот запросы к первому и второму location`у:
> 
> $ curl -I http://127.0.0.1:8080/wiki1/%D1%82%D0%B5%D1%81%D1%82
> Location: https://127.0.0.1/%D1%82%D0%B5%D1%81%D1%82
> 
> $ curl -I http://127.0.0.1:8080/wiki2/%D1%82%D0%B5%D1%81%D1%82
> Location: https://127.0.0.1/тест
> 
> Первый и второй location отличаются между собой только тем,
> что в первом используется неименованное выделение $1,
> а во втором - именованное выделение $title.
> 
> И в то же время получаем такие разные результаты. Почему так?

Потому что подстановка $1 делается из раскодированного URI 
запроса, и nginx знает, что данные в ней следует экранировать.  А 
$title - произвольная переменная, и как и любая произвольная 
переменная - подставляется в предположении, что данные в ней 
корректно экранированы.

В частности из-за этой магии обычно рекомендуют использовать 
return, где никакой подобной магии нет.  Но если речь идёт о 
изменениях URI с необходимостью снятия/восстановления 
экранирования - это один из наиболее простых путей.

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

Re: location + rewrite и (де)кодирование URI

2019-06-18 Пенетрантность Maxim Dounin
Hello!

On Tue, Jun 18, 2019 at 03:12:12PM +0300, Gena Makhomed wrote:

> On 18.06.2019 14:09, Maxim Dounin wrote:
> 
> > Проще всего сделать так:
> > 
> >  rewrite ^/wiki/(.*) https://$host/$1;
> 
> в таком случае в редиректе возвращается раскодированный урл:
> 
> $ curl -I https://example.com/wiki/%D1%82%D0%B5%D1%81%D1%82
> HTTP/1.1 301 Moved Permanently
> Location: https://example.com/тест

И снова эксперимент плохой, негодный.

$ curl -vvv http://127.0.0.1:8080/wiki/%d1%82%d0%b5%d1%81%d1%82
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> GET /wiki/%d1%82%d0%b5%d1%81%d1%82 HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.62.0
> Accept: */*
> 
< HTTP/1.1 302 Moved Temporarily
< Server: nginx/1.17.1
< Date: Tue, 18 Jun 2019 12:24:39 GMT
< Content-Type: text/html
< Content-Length: 145
< Connection: keep-alive
< Location: https://127.0.0.1/%D1%82%D0%B5%D1%81%D1%82
< 

302 Found

302 Found
nginx/1.17.1


* Connection #0 to host 127.0.0.1 left intact

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

Re: location + rewrite и (де)кодирование URI

2019-06-18 Пенетрантность Maxim Dounin
Hello!

On Tue, Jun 18, 2019 at 01:27:36PM +0300, Gena Makhomed wrote:

> On 18.06.2019 11:27, Maxim Dounin wrote:
> 
> >> Есть такой фрагмент документации на директиву location:
> >>
> >>   Синтаксис: location [ = | ~ | ~* | ^~ ] uri { ... }
> >>
> >>   Для сопоставления используется URI запроса в нормализованном виде,
> >>   после декодирования текста, заданного в виде “%XX”, преобразования
> >>   относительных элементов пути “.” и “..” в реальные и возможной
> >>   замены двух и более подряд идущих слэшей на один.
> 
> >> Есть такой фрагмент конфига:
> >>
> >>   location ~ ^/wiki/(?.*) {
> >>   return 301 https://$host/$title$is_args$args;
> >>   }
> >>
> 
> Получается, что в документации написано все правильно, приведенный
> фрагмент конфига содержит ошибку, и правильно будет переписать его
> таким образом:

[...]

> Только в этом случае поведение nginx будет полностью соответствовать
> RFC 3986 и более простого варианта решения этой задачи не существует?

Существует.  Проще всего сделать так:

rewrite ^/wiki/(.*) https://$host/$1;

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

Re: location + rewrite и (де)кодирование URI

2019-06-18 Пенетрантность Maxim Dounin
Hello!

On Tue, Jun 18, 2019 at 06:31:24AM +0300, Gena Makhomed wrote:

> Здравствуйте, All!
> 
> Есть такой фрагмент документации на директиву location:
> 
>  Синтаксис: location [ = | ~ | ~* | ^~ ] uri { ... }
> 
>  Для сопоставления используется URI запроса в нормализованном виде,
>  после декодирования текста, заданного в виде “%XX”, преобразования
>  относительных элементов пути “.” и “..” в реальные и возможной
>  замены двух и более подряд идущих слэшей на один.
> 
> Есть такой фрагмент конфига:
> 
>  location ~ ^/wiki/(?.*) {
>  return 301 https://$host/$title$is_args$args;
>  }
> 
> Судя по документации, этот фрагмент конфига не должен работать, потому
> что в $title ведь попадает уже декодированный русский текст из location?
> 
> Но почему-то эксперимент с помощью curl показывает, что в редиректе 
> возвращается текст закодированный в виде “%XX”, а не обычный Unicode.

Эксперимент, видимо, плохой, негодный.

$ curl -vvv http://127.0.0.1:8080/wiki/%d1%82%d0%b5%d1%81%d1%82
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> GET /wiki/%d1%82%d0%b5%d1%81%d1%82 HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.62.0
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.17.1
< Date: Tue, 18 Jun 2019 08:25:18 GMT
< Content-Type: text/html
< Content-Length: 169
< Connection: keep-alive
< Location: https://127.0.0.1/тест
< 

301 Moved Permanently

301 Moved Permanently
nginx/1.17.1


* Connection #0 to host 127.0.0.1 left intact

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

Re: Хотлинк работает как-то не так

2019-06-17 Пенетрантность Maxim Dounin
Hello!

On Mon, Jun 17, 2019 at 10:03:10AM -0400, grey wrote:

> Добрый день.
> 
> 
> Сам конфиг, блокирующий картинки хотлинка с сайтов из "черного" списка:
> 
>   map $http_referer $bad_referer {
>   hostnames;
> 
>   default 0;
> 
>   "~site.ru"  1;
>   "~test.ru"  1;
> }
> 
>   location ~* ^/secret-files/
>   {
>   internal;
> 
>   if ($bad_referer)
>   {
>   rewrite ^ /images/direct-url.gif last;
>   }
> 
>   root   /inetpub/wwwroot/qwerty.ru;
>   }
> 
> 
> Пока запрашиваемая картинка на моем сервере существует, правило отрабатывает
> верно и пользователи видят заглушку direct-url.gif, но если изображение на
> моем сайте удалить, то они видят сообщение, которое отдает скрипт:
> 
>  ...
>   header ("X-Accel-Redirect: /image-not-found.gif");
> ?>
> 
> 
> Не понимаю, почему дело доходит до скрипта, если nginx видя хотлинк сразу
> должен отдать заглушку.

У вас в "location ~* ^/secret-files/" запрос попадает только после 
обработки скриптом, судя по всему.  И если скрипт не делает 
перенаправления в /secret-files/, то и проверки по $bad_referer не 
происходит.

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

Re: Лимит подключений в Windows 1024 worker connections are not enough

2019-06-17 Пенетрантность Maxim Dounin
Hello!

On Fri, Jun 14, 2019 at 02:57:25AM -0400, Krelion wrote:

> Добрый день!
> 
> Nginx 1.15.9 для Windows
> 
> конфиг,
> 
> worker_processes  1;
> 
> events {
> worker_connections  8192;
> }
> 
> в логах:
> 
> 2019/06/07 14:17:20 [alert] 2424#2720: 1024 worker_connections are not
> enough
> 
> Как поднять количество соединений больше 1024 в версии под Windows ?
> В моем случае невозможно использовать Linux версию по ряду причин.

Если вам нужно больше 1024 соединений в Windows-версии, то вы, 
вероятно, используете nginx для Windows неправильно - не надо на 
этом гонять production, от этого может быть больно.  Впрочем, 
начиная с nginx 1.15.9 при условии использования Windows Vista и 
новее - это можно сделать, сказав к конфиге "use poll;" в секции 
events.

При этом, правда, отвалится детектирование ошибок на этапе 
установления соединения к бэкендам, так как правильную эмуляцию 
poll() в MS не осилили.

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

Re: непонятное поведение

2019-06-10 Пенетрантность Maxim Dounin
Hello!

On Mon, Jun 10, 2019 at 09:16:40AM +0300, Aln Kapa wrote:

> server {
> server_name xx..;
> listen 443 http2;
> 
> .
> 
> location / {
> proxy_pass http://127.0.0.1:10080;
> ..
> }
> }
> 
> server {
> listen   80;
> server_name xx..;
> return 302 https://xx../$request_uri;
> }
> Да у меня в конфигурации есть редирект, но разве "listen 80" означает любой
> в интернете IP адрес, по идеи тут должно быть любой мой?
> и потом указано же "server_name xx..;" как с этим быть?

"listen 80" означает - отвечать на любые запросы, поступающие по 
IPv4 на порт 80.  Что при этом написано в запросе - не важно, 
важно - куда было установлено TCP-соединение.  А оно, очевидно, 
было на 80-й порт.

Что до "server_name", то для выбора блока server это важно тогда и 
только тогда, когда в конфигурации есть другие блоки server, 
использующие тот же listen-сокет.  В данном случае блок server 
для 80-го порта - единственный, он же сервер по умолчанию, и 
запрос будет обработан именно в этом блоке server.

Как я уже писал, подробнее обо всём этом можно прочитать тут:

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

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

Re: white & bad bots Помогите

2019-06-10 Пенетрантность Maxim Dounin
Hello!

On Sun, Jun 09, 2019 at 07:00:45AM -0400, ocadihoh wrote:

> Здравствуйте помогите пожалуйста.
> есть список плохих ботов
> if ($http_user_agent ~*
> (360Spider|80legs.com|Abonti|AcoonBot|Acunetix||ZyBorg|google) ) {
>   return 410;
>   }
> там присутствует google - но в таком варианте банит всех ботов гугла,!
> Нужно забанить всех кроме мобильного бота
> 
> Обычные user agent
> Подскажите пожалуйста как пропускать только мобильного бота Google остальных
> банить
> Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
> Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible;
> Googlebot/2.1; +http://www.google.com/bot.html) Safari/537.36
> Googlebot/2.1 (+http://www.google.com/bot.html)
> 
> mobile
> Mozilla/5.0 (iPhone; CPU iPhone OS 9_1 like Mac OS X) AppleWebKit/601.1.46
> (KHTML, like Gecko) Version/9.0 Mobile/13B143 Safari/601.1 (compatible;
> AdsBot-Google-Mobile; +http://www.google.com/mobile/adsbot.html)
> 
> 4 день голову ломаю.
> Зарание огромное спасибо.

Читайте про negative look-ahead assertions, что-то вроде 
"google(?!.*mobile)" должно сработать.

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

Re: непонятное поведение

2019-06-07 Пенетрантность Maxim Dounin
Hello!

On Fri, Jun 07, 2019 at 11:36:31AM +0300, Aln Kapa wrote:

> Добрый день.
> 
> Случайно наткнулся вот на это:
> 
> 185.172.110.221 - - [07/Jun/2019:07:03:52 +0300] "GET
> http://185.172.110.221:80/proxy_get.php?ip=62.122.99.46=bar HTTP/1.0"
> 302 138 "-" "HTTP-Proxy-Tester"
> 
> Правильно ли я понимаю, так как 185.172.110.221 не мой IP, соответственно
> ответ должен быть 4xx.
> Почему 302 вот не разу не понял?

Неправильно понимаете.  Всё зависит от конфигруации.  При 
обращении к имени, не описанному в конфигурации - запрос 
обрабатывается в сервере по умолчанию, и ответ будет такой, как 
гласит конфигурация сервера по умолчанию.

Подробнее обо всём этот можно почитать тут:

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

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

Re: Проблема с апстримами

2019-06-05 Пенетрантность Maxim Dounin
Hello!

On Wed, Jun 05, 2019 at 04:12:39AM -0400, avinchakov wrote:

> Всем привет, уже долго время пытаюсь найти причину постоянных ошибок "no
> live upstreams while connecting to upstream". Флоу такой:
> Интернет->"Балансер" с nginx->Сервера с приложением Nginx+FPM в другой
> подсети.

Причина ошибок "no live upstreams ..." - в том, что все бэкенды 
выключены из-за ранее прозошедших ошибок, в соответствии с 
max_fails / fail_timeout в конфигурации.  Ищите, какие ошибки были 
до этого.

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

Re: upstream_response_time larger than request_time

2019-06-04 Пенетрантность Maxim Dounin
Hello!

On Tue, Jun 04, 2019 at 12:02:47PM -0400, kron wrote:

> Доброго дня.
> Наблюдаю странную картину в логах. Логируется две переменных - request_time
> и upstream_response_time.
> Судя по документации логично предположить, что request_time будет всегда
> либо больше, либо равной upstream_response_time, но по факту оказалось, что
> upstream_response_time хоть и не значительно, но бывает больше чем
> request_time. Хотелось бы понять в каких случаях такое возможно?
> 
> Пример таймингов:
> request_time upstream_response_time method
> 5.954 5.956 GET
> 5.421 5.424 GET
> 30.576 30.577 GET
> 2.302 2.304 GET
> 2.298 2.300 GET
> 1.923 1.924 GET
> 1.898 1.900 GET
> 1.802 1.804 GET
> 1.774 1.776 GET
> 1.683 1.684 GET
> 
> версия nginx - 1.15.5

Это связано с тем, что сейчас на Линуксе $upstream_response_time 
считается через clock_gettime(CLOCK_MONOTONIC_COARSE), и при 
типичных значениях CONFIG_HZ=250 оно может отставать на время до 4 
миллисекунд.  В то же время время для расчёта $request_time 
используется не монотонное время, а результат gettimeofday(), то 
есть время по настенным часам.  Так что в некоторых случаях 
$upstream_response_time может быть незначительно больше 
$request_time.

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

Re: proxy_pass to variable and upstream server temporarily disabled variable

2019-06-04 Пенетрантность Maxim Dounin
Hello!

On Tue, Jun 04, 2019 at 10:40:23AM -0400, kron wrote:

> > В случае если адрес сервера в proxy_pass с переменными определяется
> > с помощью resolver'а, то на каждый запрос создаётся новый апстрим.
> > Это может быть не так e.g. в случае алиасинга с неявным апстримом;
> > я бы проверил это в первую очередь. 
> 
> Да, в моем случае в переменной DNS адрес, который резолвится с помощью
> резолвера и адрес точно резолвится в несколько адресов.
> Таким образом получается, что при каждом запросе создается новый upstream с
> адресом в который разрезолвилась переменная и пока этот адрес есть в
> резолвере, каждый новый запрос будет фейлить?

Не совсем так.  Если у вас один из N возвращаемых из DNS бэкендов 
нерабочий - то при исползовании переменных с вероятностью 1/N 
nginx попытается сначала отправить запрос именно на него, и 
получит ошибку.  После чего пойдёт на другой бэкенд в соответствии 
с proxy_next_upstream.

> Кажется крутым решением было бы брать набор адресов из резолвера и из них
> уже делать апстрим с дефолтным фоллбэком. Хотя вероятно делать это на каждый
> запрос было бы ресурсоемко.

Если хочется, чтобы полученный набор серверов использовался не 
только для одного запроса - это можно сделать, описав блок 
upstream и/или написав в конфиге proxy_pass без переменных.  Так, 
собственно, nginx работает по умолчанию.

Если же хочется, чтобы полученный набор адресов периодечески 
обновлялся - то такая фича есть в платной версии, подробности тут:

http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#resolve

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

Re: Влияние на производительность проверок на существоание файла (-f) в rewrite модуле

2019-05-23 Пенетрантность Maxim Dounin
Hello!

On Thu, May 23, 2019 at 03:10:28PM +0500, Dmitry Sergeev wrote:

> Всем привет. Не поделится ли кто-нибудь опытом, сильно ли может повлиять 
> на произовдительность конструкция:
> 
> >  location / {
> >  if (-f /var/www/maintenance_on.html) {
> >  return 503;
> >  }
> >
> >
> >  ...
> >  }
> >
> >
> >  # Error pages.
> >  error_page 503 /maintenance_on.html;
> >  location = /maintenance_on.html {
> >  root /var/www;
> >  }
> Например 7-10 location  с такими проверками на хосте 4K запросов в секунду?
> На каждый запрос он будет проверять существование файла? Или как-то это 
> делает по таймауту, который можно настроить?

При такой конфигурации на каждый запрос[*] будет делаться 
системный вызов stat().  Скорее всего необходимые данные будут в 
кэше операционной системы, и этот системный вызов будет быстрым, 
так что на производительности это скажется минимально.

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

[*] Вообще-то в можно ещё и настроить кэширование внутри nginx'а, 
чтобы сэкономить системные вызовы (http://nginx.org/r/open_file_cache). 
Но практика показывает, что на производительность это влияет 
минимально, а вот выстрелить себе в ногу неатомарным изменением 
файлов станет легко.

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

Re: Немного про логику кеша

2019-05-22 Пенетрантность Maxim Dounin
Hello!

On Wed, May 22, 2019 at 05:29:33PM +0300, kpoxa wrote:

> Что-то у меня не сходится, не понимаю:
> 
> Запрос в 22/May/2019:17:15:43
> Файл элемента кеша создан  May 18 12:46
> inactive=1d
> ответ 302
> proxy_cache_valid 301 302 404 15s;
> 
> Более подробно:
> 
> 
> В логе запрос с попаданием в кеш
> 
> [22/May/2019:17:15:43 +0300] "/s13/27/public_pin_l/241/2352410650.jpg"
> ip=15.85.172.17 status=302 size=0 upTime=- upstream_addr=-
> upstream_status=- request_time=0.000 cache=HIT ref="-" http
> 
> Вычисляем файл кеша:
> 
> echo -n /s13/27/public_pin_l/241/2352410650.jpg | md5sum
> 044e2e2e9226a8f10d25d480a49d2000
> 
> Вот он
> 
> -rw--- 1 www-data www-data 684 May 18 12:46
> 044e2e2e9226a8f10d25d480a49d2000
> 
> Содержит он
> 
> 
> cat 044e2e2e9226a8f10d25d480a49d2000
> ђa]ђФЯ\ТYЁK~¬
> KEY: /s13/27/public_pin_l/241/2352410650.jpg
> HTTP/1.1 302 Found
> Server: nginx/1.15.8
> Date: Sat, 18 May 2019 09:46:56 GMT
> Content-Length: 0
> Connection: close
> Cache-Control: max-age=2592000
> Expires: Mon, 17 Jun 2019 09:46:56 GMT
> Location: /s107/797257fdf5bc88f5/2352410650.jpg
> Pragma: no-cache
> X-Powered: iconv
> Content-Type: image/jpeg

И что именно не сходится?
Вроде никаких противоречий не просматривается.

В соответствии с заголовком Cache-Control - ответ валиден 30 дней, 
если его спрашивают хотя бы раз в сутки (inactive=1d) - эти 30 
дней он и будет лежать в кэше.

Указанное в директиве proxy_cache_valid время в данном случае не 
не используется, так как время валидности ответа явно указано в 
заголовках Cache-Control и Expires (и директивы 
proxy_ignore_headers в конфиге нет).

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

[nginx-ru-announce] nginx-1.17.0

2019-05-21 Пенетрантность Maxim Dounin
Изменения в nginx 1.17.0  21.05.2019

*) Добавление: директивы limit_rate и limit_rate_after поддерживают
   переменные.

*) Добавление: директивы proxy_upload_rate и proxy_download_rate в
   модуле stream поддерживают переменные.

*) Изменение: минимальная поддерживаемая версия OpenSSL - 0.9.8.

*) Изменение: теперь postpone-фильтр собирается всегда.

*) Исправление: директива include не работала в блоках if и
   limit_except.

*) Исправление: в обработке byte ranges.


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

nginx-1.17.0

2019-05-21 Пенетрантность Maxim Dounin
Изменения в nginx 1.17.0  21.05.2019

*) Добавление: директивы limit_rate и limit_rate_after поддерживают
   переменные.

*) Добавление: директивы proxy_upload_rate и proxy_download_rate в
   модуле stream поддерживают переменные.

*) Изменение: минимальная поддерживаемая версия OpenSSL - 0.9.8.

*) Изменение: теперь postpone-фильтр собирается всегда.

*) Исправление: директива include не работала в блоках if и
   limit_except.

*) Исправление: в обработке byte ranges.


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

Re: Немного про логику кеша

2019-05-21 Пенетрантность Maxim Dounin
Hello!

On Tue, May 21, 2019 at 04:31:46PM +0300, kpoxa wrote:

> Есть некоторые директивы, про которые не совсем понятно, как они работают
> вместе, в частности у proxy_cache_path есть параметр inactive, который
> задаёт время жизни файла в кеше, считая с последнего обращения. А еще есть
> директива proxy_cache_valid, судя по описанию которой, которая тоже
> отвечает за что-то подобное, обозванное временем кеширования.
> 
> И в связи с этим у меня вопрос:
> как мне настроить кеш так, чтобы 302 редиректы кешировались на 15 секунд?
> При настройках inactive=7d никакие варианты прописать proxy_cache_valid 302
> 15s не работают, в кеше куча вчерашних редиректов.
> И второй вопрос - при каких условиях и как работает proxy_cache_valid ?
> Пока что у меня не сходятся реальное поведение с документацией.

Директива proxy_cache_valid - определяет, сколько времени ответ в 
кэше будет считаться валидным, то есть пригодным для возврата 
клиенту.  Используется, если клиент не вернул явного указания 
через Cache-Control/Expires/X-Accel-Expires (или они 
проигнорированы в соответствии с proxy_ignore_headers).

Параметр inactive директивы proxy_cache_path - определяет, сколько 
времени ответ, возможно уже устаревший, будет хранится в кэше 
после последнего обращения.  Этот параметр - используется в первую 
очередь для управления размером кэша на диске.

Когда inactive больше valid - в кэше будут храниться устаревшие 
ответы.  Такие ответы в норме не возвращаются клиентам, но могут 
быть использованы, скажем, в случае ошибок, с помощью директивы 
proxy_cache_use_stale.

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

Re: signer certificate not found после обновления

2019-05-17 Пенетрантность Maxim Dounin
Hello!

On Fri, May 17, 2019 at 05:49:09PM +0600, raven...@megaline.kg wrote:

> Приветствую.
> 
> Обновил Nginx c 1.14 до 1.16, посыпались ошибки в лог
> 
> 2019/05/17 11:22:50 [error] 2487#2487: OCSP_basic_verify() failed (SSL: 
> error:27FFF076:OCSP routines:CRYPTO_internal:signer certificate not 
> found) while requesting certificate status, responder: 
> ocsp.int-x3.letsencrypt.org, peer: 2.21.33.128:80, certificate: 
> "/etc/pki/letsencrypt/домен/fullchain.cer"
> 2019/05/17 11:33:46 [error] 2487#2487: OCSP_basic_verify() failed (SSL: 
> error:27FFF076:OCSP routines:CRYPTO_internal:signer certificate not 
> found) while requesting certificate status, responder: 
> ocsp.int-x3.letsencrypt.org, peer: 23.203.249.34:80, certificate: 
> "/etc/pki/letsencrypt/домен/fullchain.cer"
> 
> Сайты (их, к слову, куда больше чем один) при этом продолжают работать. 
> fullchain.cer содержит и сертификат домена и промежуточный сертификат.
> 
> Откатываюсь обратно на 1.14.2 - ошибки пропадают. С чем может быть 
> связано такое изменение поведения?

С вот этим:

> built with LibreSSL 2.9.1

Подробности тут:

http://mailman.nginx.org/pipermail/nginx-ru/2019-May/062150.html
http://mailman.nginx.org/pipermail/nginx-devel/2019-May/012212.html

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

Re: nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/path/to/example.com/fullchain.cer"

2019-05-08 Пенетрантность Maxim Dounin
Hello!

On Wed, May 08, 2019 at 12:10:32AM -0400, rihad wrote:

> Вот эта сборка с LibreSSL проблемная. Без нее (если убрать
> DEFAULT_VERSIONS+=ssl=libressl из /etc/make.conf или просто поставить пакет)
> нет ворнингов.
> 
> [rihad@master /usr/local/etc/nginx]$ nginx -V
> nginx version: nginx/1.16.0
> built with LibreSSL 2.9.1

[...]

Судя по всему, в LibreSSL неправильно реализована функция 
SSL_CTX_get_extra_chain_certs() - ведёт себя так, как должно вести 
функция SSL_CTX_get_extra_chain_certs_only(), и не возвращает 
цепочку дополнительных сертификатов, установленную для конкретного 
сертификата, а возвращает только общую цепочку для контекста.

Если я правильно понимаю, поддержку отдельных цепочек для 
сертификатов в LibreSSL только начали пилить в 2.9.x, и пока не 
допилили до конца.  Но поскольку в LibreSSL 2.9.1 появилась функция 
SSL_CTX_set0_chain() - nginx начал её использовать, и отсутствие 
соответствующей реализации SSL_CTX_get_extra_chain_certs() 
сказывается.

Стоит ребятам сообщить, чтобы починили.

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

Re: nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/path/to/example.com/fullchain.cer"

2019-05-07 Пенетрантность Maxim Dounin
Hello!

On Tue, May 07, 2019 at 01:13:44PM -0400, rihad wrote:

> Эти варны возникли при чтении конфига после обновления до nginx с 1.14.2 до
> 1.16.0 (ОС: FreeBSD 11.2). 
> Даунгрейд до 1.14.2 убирает сообщения..
> Используем сертфикаты Let's Encrypt и клиент acme.sh
> 
> Конфиг SSL Stapling:
> 
> ssl_stapling on;
> ssl_stapling_verify on;
> 
> Типичный конфиг домена (коих много):
> 
> ssl_certificate /home/acme/.acme.sh/example.com/fullchain.cer;
> ssl_certificate_key /home/acme/.acme.sh/example.com/example.com.key;
> 
> Внутри fullchain.cer сидят два сертификата, второй из которых всегда
> одинаков для всех.

Покажите пример fullchain.cer.  Кроме того, было бы неплохо 
увидеть вывод "nginx -V" для обоих версий, и пример минимального 
полного конфига, демонстрирующего проблему.

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

Re: epoll_ctl: file exists ?

2019-05-03 Пенетрантность Maxim Dounin
Hello!

On Thu, May 02, 2019 at 02:04:55PM +0500, Илья Шипицин wrote:

> Ну, в общем вопрос требует изучения мат части. Изучу - расскажу.
> 
> 
> Подобная ошибка возникает в единицах на сотню тысяч клиентов.
> 
> Вебсокеты активно используются. Я считал, что мы в ALPN только анонсируем,
> что мы умеем http2. В обязательном порядке мы не можем никого заставить

Скорее всего проблема в том, что клиент в нарушение стандарта 
HTTP/2 пытается присылать Upgrade, а у вас конфигурация такова, 
что этот заголовок для HTTP/2 не игнорируется, а передаётся на 
бэкенд - и бэкенд возвращает 101 Switching Protocols, что в свою 
очередь приводит к ошибке, когда nginx это переключение протоколов 
пытается обработать.  Лечится - игнорированием попыток клиентов 
использовать вебсокеты в рамках HTTP/2.

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

Re: epoll_ctl: file exists ?

2019-05-03 Пенетрантность Maxim Dounin
Hello!

On Thu, May 02, 2019 at 11:53:38AM +0300, Vladimir Getmanshchuk wrote:

> Максим, если найдете свободную минуту - расскажите пожалуйста почему.
> Спасибо.

Потому что HTTP/2 не предусматривает возможности что-то делать с 
соединением, в частности - connection-related-заголовки явно 
запрещены стандартом[1].  А вебсокеты работают через Upgrade 
соединения в другой протокол, с помощью заголовков "Upgrade: 
websocket" и "Connection: upgrade".  То есть вебсокеты явно 
запрещены стандартом HTTP/2.  И даже примечание есть:

  Note: HTTP/2 purposefully does not support upgrade to another
  protocol.  The handshake methods described in Section 3 are
  believed sufficient to negotiate the use of alternative protocols.

Если бы авторы протокола подумали головой и просто честно 
определили мультиплексирование stream'ов - проблемы бы не было, и 
мы бы это без особых проблем поддержали.  Но нет.  А поскольку 
явно запрещено - то и пытаться поддерживать смысла нет.

Так что вебсокеты продолжают работать по HTTP/1.1.  Что, впрочем, 
представляется мне правильным - как протокол HTTP/2 оставляет 
желать, и это далеко не единственная его проблема.

(Делались попытки вебсокеты таки в HTTP/2 впихнуть - в частности, в 
прошлом году принят RFC 8441, "Bootstrapping WebSockets with 
HTTP/2"[2].  Через 3 года после принятия стандарта HTTP/2.  Но 
это, скажем так, выглядит как хак, при этом малосовместимый с 
существующей логикой работы через Upgrade, и имеет мало шансов 
быть поддержанным.)

[1] https://tools.ietf.org/html/rfc7540#section-8.1.2.2
[2] https://tools.ietf.org/html/rfc8441

> On Tue, Apr 30, 2019 at 5:39 PM Maxim Dounin  wrote:
> 
> > Hello!
> >
> > On Tue, Apr 30, 2019 at 01:58:20PM +0500, Илья Шипицин wrote:
> >
> > > привет,
> > >
> > > насколько опасно вот такое ?
> > >
> > >
> > > 2019/04/29 21:52:39 [alert] 1714#1714: *168061675 epoll_ctl(1, 1188)
> > failed
> > > (17: File exists) while proxying upgraded connection, client:
> > > 82.114.112.115, server: market.kontur.ru, request: "GET /wsapi/
> > HTTP/2.0",
> > > upstream: "http://192.168.188.40:2339/wsapi/;, host: "xxx.xxx.xxx"
> >
> > Судя по всему, имеет место попытка запихнуть вебсокеты в HTTP/2.
> > Работать - не будет.

[...]

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

Re: epoll_ctl: file exists ?

2019-04-30 Пенетрантность Maxim Dounin
Hello!

On Tue, Apr 30, 2019 at 01:58:20PM +0500, Илья Шипицин wrote:

> привет,
> 
> насколько опасно вот такое ?
> 
> 
> 2019/04/29 21:52:39 [alert] 1714#1714: *168061675 epoll_ctl(1, 1188) failed
> (17: File exists) while proxying upgraded connection, client:
> 82.114.112.115, server: market.kontur.ru, request: "GET /wsapi/ HTTP/2.0",
> upstream: "http://192.168.188.40:2339/wsapi/;, host: "xxx.xxx.xxx"

Судя по всему, имеет место попытка запихнуть вебсокеты в HTTP/2.  
Работать - не будет.

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

Re: Файлы из кэша удаляются преждевременно

2019-04-25 Пенетрантность Maxim Dounin
Hello!

On Wed, Apr 24, 2019 at 01:21:06PM -0400, Ilya Evseev wrote:

> Nginx 1.15.11
> Система - CentOS 7 с ядром 4.18
> /data живёт на Cepf.
> 
> Обнаружено преждевременное удаление файлов из кэша Nginx.
> Кэш настроен так:
> 
> proxy_cache_path /data/user123/nginx_cache keys_zone=user123:3000m
> max_size=2g inactive=30d levels=1:2 use_temp_path=off;
> 
> В /data/user123/nginx_cache сейчас лежит около 5 миллионов файлов (т.е.
> примерно 20% от максимума 3000m),
> которые занимают 6 терабайт (30% от максимума 20TB).

На вскидку вспоминаются две причины, почему может быть так:

- При работе на экзотических файловых системах сообщаемый nginx'у 
  размер на диске может значительно отличаться от собственно 
  размера файла и/или значительно меняться в процессе.  Такое, 
  например, наблюдается на XFS 
  (https://trac.nginx.org/nginx/ticket/157).

- Если вдруг из каталога кэша кто-то удалил часть файлов в 
  процессе работы - nginx будет продолжать считать, что эти файлы 
  существуют, и учитывать их при очистке кэша по max_size.  Частным 
  случаем этой ситуации может являться запуск другого nginx'а, 
  использующего тот же каталог для хранения кэша - уже наблюдал, как 
  люди пытаются таким образом строить "общий кэш" на нескольких 
  серверах, однако следует понимать, что такой подход принципиально 
  неверен и чреват проблемами.

С учётом использования Ceph для хранения кэша (зачем?!) - я бы 
предположил, что причиной может быть как любая из этих причин, так 
и обе они вместе.

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

[nginx-ru-announce] nginx-1.16.0

2019-04-23 Пенетрантность Maxim Dounin
Изменения в nginx 1.16.0  23.04.2019

*) Стабильная ветка 1.16.x.


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

nginx-1.16.0

2019-04-23 Пенетрантность Maxim Dounin
Изменения в nginx 1.16.0  23.04.2019

*) Стабильная ветка 1.16.x.


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

Re: специальные символы в запросах

2019-04-23 Пенетрантность Maxim Dounin
Hello!

On Tue, Apr 23, 2019 at 04:59:38AM -0400, anatolr wrote:

> включаю debug как понять почему строку location не использует
> 
> location: ~ "^(.*)/\<(.*)$" {
> return 404;
> }
> 
> 2019/04/23 11:43:55 [debug] 2737#0: *23 test location: "/"
> 2019/04/23 11:43:55 [debug] 2737#0: *23 test location: "images/"
> 2019/04/23 11:43:55 [debug] 2737#0: *23 test location: ~ "^(.*)alert(.*)$"
> 2019/04/23 11:43:55 [debug] 2737#0: *23 test location: ~
> "^(.*)document(.*)$"
> 2019/04/23 11:43:55 [debug] 2737#0: *23 test location: ~ "\.php"
> 2019/04/23 11:43:55 [debug] 2737#0: *23 using configuration "\.php"

Когда речь идёт о location'ах, заданных регулярными выражениями - 
используется первое совпавшее.  В вашем случае это "location ~ \.php", 
как ясно видно из debug log'а.  Подробнее стоит почитать в 
документации:

http://nginx.org/ru/docs/http/ngx_http_core_module.html#location

Отдельно отмечу, что location отвечает только за проверку 
собственно URI запроса, без учёта аргументов.  Соответственно 
закрыть так наиболее типичные XSS-уязвимости - в аргументах 
запроса - не получится, надо вместо этого использовать if'ы.  И 
там кроме этого - вылезет отдельная проблема с необходимостью 
учитывать возможный URL encoding.

Но вообще, как вам уже совершенно верно сказали, подобный путь 
решения проблем безопасности - крайне сомнителен.

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

Re: длинные заголовки в msie11 / http2

2019-04-16 Пенетрантность Maxim Dounin
Hello!

On Tue, Apr 16, 2019 at 08:39:48PM +0500, Илья Шипицин wrote:

> я вижу упоминание SETTINGS_MAX_HEADER_LIST_SIZE в grpc.
> в http2 клиенту это передается ?

SETTINGS_MAX_HEADER_LIST_SIZE - это ограничение на суммарный 
размер заголовков, в то время как http2_max_field_size - 
ограничение на одно поле.

И нет, не передаётся.  Если бы передавалось - для честных клиентов 
ситуация могла бы стать только хуже: если бы вдруг клиент решил, 
что что раз сказали нельзя - то и нельзя, и не стал бы отправлять 
такой запрос - на сервере о проблеме бы вообще никогда не узнали.  

(Каждый раз, когда я смотрю на HTTP/2, мне становится грустно.)

> 
> вт, 16 апр. 2019 г. в 20:33, Maxim Dounin :
> 
> > Hello!
> >
> > On Tue, Apr 16, 2019 at 08:14:12PM +0500, Илья Шипицин wrote:
> >
> > > вт, 16 апр. 2019 г. в 19:23, Maxim Dounin :
> > >
> > > > Hello!
> > > >
> > > > On Tue, Apr 16, 2019 at 02:53:26PM +0500, Илья Шипицин wrote:
> > > >
> > > > > привет,
> > > > >
> > > > > столкнулись с ситуацией, когда msie11 пытается отправлять очень
> > длинную
> > > > куку
> > > > >
> > > > > в логах видим
> > > > >
> > > > > 2019/04/16 12:49:14 [info] 34390#34390: *2706157141 client exceeded
> > > > > http2_max_field_size limit while processing HTTP/2 connection,
> > client:
> > > > > 46.17.202.13, server: X.X.X.X:443
> > > > > 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 state
> > > > connection
> > > > > error
> > > > > 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 send
> > GOAWAY
> > > > > frame: last sid 17, error 11
> > > > >
> > > > >
> > > > > собственно, вопрос. на уровне "error" ни одного сообщения.
> > > > > (у нас был включен error, соответственно, мы ничего не видели).
> > > > > есть предложение поднять уровень "http2 state connection error" до
> > > > "error"
> > > >
> > > > Ошибки, которые вызываются некорректными действиями клиента, как
> > > > то попытки прислать некорректные или слишком длинные заголовки -
> > > > стандартно логгируются именно на уровне info.  На уровне error
> > > > логгируются те проблемы, решение которых - на серверной стороне.
> > > >
> > >
> > > а клиенту кто-то сказал, что 6 килобайт в хедере это некорректно ?
> > > в RFC такое ?
> >
> > Это не важно.
> >
> > Если ошибка может быть вызвана действиями клиента - используется
> > уровень info.
> >
> > --
> > Maxim Dounin
> > http://mdounin.ru/
> > ___
> > 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


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

Re: длинные заголовки в msie11 / http2

2019-04-16 Пенетрантность Maxim Dounin
Hello!

On Tue, Apr 16, 2019 at 08:14:12PM +0500, Илья Шипицин wrote:

> вт, 16 апр. 2019 г. в 19:23, Maxim Dounin :
> 
> > Hello!
> >
> > On Tue, Apr 16, 2019 at 02:53:26PM +0500, Илья Шипицин wrote:
> >
> > > привет,
> > >
> > > столкнулись с ситуацией, когда msie11 пытается отправлять очень длинную
> > куку
> > >
> > > в логах видим
> > >
> > > 2019/04/16 12:49:14 [info] 34390#34390: *2706157141 client exceeded
> > > http2_max_field_size limit while processing HTTP/2 connection, client:
> > > 46.17.202.13, server: X.X.X.X:443
> > > 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 state
> > connection
> > > error
> > > 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 send GOAWAY
> > > frame: last sid 17, error 11
> > >
> > >
> > > собственно, вопрос. на уровне "error" ни одного сообщения.
> > > (у нас был включен error, соответственно, мы ничего не видели).
> > > есть предложение поднять уровень "http2 state connection error" до
> > "error"
> >
> > Ошибки, которые вызываются некорректными действиями клиента, как
> > то попытки прислать некорректные или слишком длинные заголовки -
> > стандартно логгируются именно на уровне info.  На уровне error
> > логгируются те проблемы, решение которых - на серверной стороне.
> >
> 
> а клиенту кто-то сказал, что 6 килобайт в хедере это некорректно ?
> в RFC такое ?

Это не важно.

Если ошибка может быть вызвана действиями клиента - используется 
уровень info.

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

[nginx-ru-announce] nginx-1.15.12

2019-04-16 Пенетрантность Maxim Dounin
Изменения в nginx 1.15.12 16.04.2019

*) Исправление: в рабочем процессе мог произойти segmentation fault,
   если в директивах ssl_certificate или ssl_certificate_key
   использовались переменные и был включён OCSP stapling.


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

nginx-1.15.12

2019-04-16 Пенетрантность Maxim Dounin
Изменения в nginx 1.15.12 16.04.2019

*) Исправление: в рабочем процессе мог произойти segmentation fault,
   если в директивах ssl_certificate или ssl_certificate_key
   использовались переменные и был включён OCSP stapling.


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

Re: alias 301 redirect

2019-04-16 Пенетрантность Maxim Dounin
Hello!

On Tue, Apr 16, 2019 at 04:10:57PM +0300, chm...@yandex.ru wrote:

> Добрый день. 
> 
> Есть такая конфигурация: 
> 
> location ~ /folder/images/ {
>   alias /var/www/domain.com/folder/src/images/ 
> <http://domain.com/folder/src/images/>;
> }
> 
> при запросе domain.com/folder/images/test.png 
> <http://domain.com/folder/images/test.png> 
> 
> Я почему-то получаю 301 редирект на domain.com/folder/images/test.png/ 
> <http://domain.com/folder/images/test.png/>
> 
> Судя по логам запрос попадает именно в этот локейшен и больше никуда. 
> 
> Подскажите пожалуйста в чем может быть проблема ? 

При использовании директивы alias в location, заданном регулярным 
выражением, директива alias определяет полный путь к 
запрашиваемому ресурсу.  Соответственно у вас для любого запроса - 
путь в файловой системе указывает на каталог, и из-за этого на 
любой запрос возвращается перенаправление.

Если вы на самом деле хотели написать префиксный location 
для запросов в /folder/images/ - уберите "~".

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

Re: длинные заголовки в msie11 / http2

2019-04-16 Пенетрантность Maxim Dounin
Hello!

On Tue, Apr 16, 2019 at 02:53:26PM +0500, Илья Шипицин wrote:

> привет,
> 
> столкнулись с ситуацией, когда msie11 пытается отправлять очень длинную куку
> 
> в логах видим
> 
> 2019/04/16 12:49:14 [info] 34390#34390: *2706157141 client exceeded
> http2_max_field_size limit while processing HTTP/2 connection, client:
> 46.17.202.13, server: X.X.X.X:443
> 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 state connection
> error
> 2019/04/16 12:49:14 [debug] 34390#34390: *2706157141 http2 send GOAWAY
> frame: last sid 17, error 11
> 
> 
> собственно, вопрос. на уровне "error" ни одного сообщения.
> (у нас был включен error, соответственно, мы ничего не видели).
> есть предложение поднять уровень "http2 state connection error" до "error"

Ошибки, которые вызываются некорректными действиями клиента, как 
то попытки прислать некорректные или слишком длинные заголовки - 
стандартно логгируются именно на уровне info.  На уровне error 
логгируются те проблемы, решение которых - на серверной стороне.

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

Re: ssl_stapling without ssl_trusted_certificate

2019-04-12 Пенетрантность Maxim Dounin
Hello!

On Fri, Apr 12, 2019 at 12:02:39AM +0300, sergio via nginx-ru wrote:

> On 11/04/2019 22:56, Maxim Dounin wrote:
> 
> Я подписан, не надо меня в cc включать.

У вас в DMARC policy написано "p=quarantine", в результате Mailman 
в ваших письмах переписывает адрес отправителя на "sergio via 
nginx-ru " и добавляет Cc.  Соответственно при 
ответе на такое письмо - также случается Cc.  Подробнее тут:

https://wikitech.wikimedia.org/wiki/Mailman#DMARC_Compatibility

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

> > Директиву error_log следует указывать на глобальном уровне.
> 
> Ага!
> 
> > при каждом обращении к OCSP-серверу ругаясь в логи про "no resolver
> > defined to resolve ..." на уровне warn.
> 
> Действительно, ругается, всё встало на свои места, спасибо!
> 
> > В случае, если resolver не указан, и при этом включён OCSP stapling
> > - nginx будет пытаться использовать IP-адреса OCSP-сервера, полученные
> > при старте
> 
> Полученные от кого?

От системы, при помощи функции getaddrinfo() (или gethostbyname(), 
если getaddrinfo() нет).  Обычно это выливается в использование 
конфигурации в /etc/nsswitch.conf, а далее /etc/hosts и системного 
DNS-резолвера, с конфигурацией в /etc/resolv.conf, но бывают и 
другие реализации - всё зависит от конкретной операционной системы.

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

Re: ssl_stapling without ssl_trusted_certificate

2019-04-11 Пенетрантность Maxim Dounin
Hello!

On Thu, Apr 11, 2019 at 03:55:31AM +0300, sergio via nginx-ru wrote:

> On 01/04/2019 19:22, Maxim Dounin wrote:
> 
> > Давайте пойдём простым путём.
> 
> Не похож он на простой.

Он простой в том смысле, что результат не зависит от ваших 
оценочных суждений, а проверяем.

[...]

> > "nginx -T"
> 
> Тут очень много всего, куча серверов, 909 строк, и не всё я могу
> показать. Давайте так:
> 
> # nginx -T | grep "resol\|stapl"
> nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /etc/nginx/nginx.conf test is successful
> ssl_stapling on;
> ssl_stapling_verify on;
> #resolver localhost;

Нет, так не работает.  Если не хотите чего-то показывать - 
воспроизведите проблему в песочнице и давайте полный конфиг из 
неё.

Впрочем, я уже вижу проблему и без этого.  Как и предполагалось 
ранее - логов нужного уровня нет:

> > и debug log с обращением к OCSP-серверу
> 
> У меня дебиан, nginx-debug нету. Я просто взял и заменил warn на debug
> в error_log на уровне http и на уровне server'а

Директиву error_log следует указывать на глобальном уровне.  
Именно туда попадают сообщения, которые генерируются 
инфраструктурным кодом, не привязанным к конкретному соединению 
и/или модулю.

Поскольку на глобальном уровне error_log у вас, судя по всему, не 
задан вообще, то используется error log, заданный при сборке - 
/var/log/nginx/error.log - с уровнем логгирования error.  Но этого 
недостаточно, чтобы увидеть сообщения уровня warn, а тем более - 
debug.

В результат в логе видно, что был вызыван certificate status 
callback:

> вижу кучу невнятных записей в error.log со словами [debug], ни слова про
> ocsp:
> 
> [debug] 30320#30320: *1 SSL certificate status callback
> [debug] 30320#30320: *1 SSL_do_handshake: -1
> [debug] 30320#30320: *1 SSL_get_error: 2
> [debug] 30320#30320: *1 epoll add event: fd:55 op:1 ev:80002001
> [debug] 30320#30320: *1 event timer add: 55: 6:4031539074

но не видно всего того, что начинает происходить после этого 
callback'а уже без привязки к конкретному соединению.  Должно быть 
как-то так:

...
2019/04/11 22:37:56 [debug] 52632#100124: *1 SSL certificate status callback
2019/04/11 22:37:56 [debug] 52632#100124: posix_memalign: 29056000:2048 @16
2019/04/11 22:37:56 [debug] 52632#100124: ssl ocsp request
2019/04/11 22:37:56 [debug] 52632#100124: ssl ocsp request length 96, escape 3
2019/04/11 22:37:56 [warn] 52632#100124: no resolver defined to resolve 
ocsp.cacert.org while requesting certificate status, responder: 
ocsp.cacert.org, certificate: "/path/to/crt"
2019/04/11 22:37:56 [debug] 52632#100124: ssl ocsp connect
2019/04/11 22:37:56 [debug] 52632#100124: stream socket 9
2019/04/11 22:37:56 [debug] 52632#100124: connect to 213.154.225.237:80, fd:9 #2
2019/04/11 22:37:56 [debug] 52632#100124: kevent set event: 9: ft:-1 fl:0025
2019/04/11 22:37:56 [debug] 52632#100124: kevent set event: 9: ft:-2 fl:0025
2019/04/11 22:37:56 [debug] 52632#100124: ssl ocsp connect peer done
2019/04/11 22:37:56 [debug] 52632#100124: event timer add: 9: 6:351011347
2019/04/11 22:37:56 [debug] 52632#100124: event timer add: 9: 6:351011347
2019/04/11 22:37:56 [debug] 52632#100124: *1 SSL_do_handshake: 1
2019/04/11 22:37:56 [debug] 52632#100124: *1 SSL: TLSv1.2, cipher: 
"ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD"
...

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

nginx-1.15.11

2019-04-09 Пенетрантность Maxim Dounin
Изменения в nginx 1.15.11 09.04.2019

*) Исправление: в директиве ssl_stapling_file на Windows.


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

[nginx-ru-announce] nginx-1.15.11

2019-04-09 Пенетрантность Maxim Dounin
Изменения в nginx 1.15.11 09.04.2019

*) Исправление: в директиве ssl_stapling_file на Windows.


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

Re: nginx: [emerg] getpwnam("www-data") failed

2019-04-07 Пенетрантность Maxim Dounin
Hello!

On Mon, Apr 08, 2019 at 03:48:30AM +0300, Maxim Dounin wrote:

> On Sat, Apr 06, 2019 at 01:21:06PM +0100, Anton Kiryushkin wrote:
> 
> > При обновлении на 1.15.10 поймал такую картину. В конфиге полжизни было
> > написано:
> > user www-data;
> > 
> > Пользователь есть, группа есть. Все ищется по /etc/passwd и /etc/group. Что
> > поменялось в nginx?
> 
> Ничего.  Последнее изменение в соответствующей функции - 
> стилистическое - датируется 2015 годом, nginx 1.9.6, 7ac57369036c.  
> Последнее смысловое изменение - о том, чтобы сообщения об ошибках 
> были более детерминированы - было в 2007 году, nginx 0.6.3, 
> eb232400e829.
> 
> Сообщение как бы говорит о том, что библиотечный вызов 
> getpwnam() с параметром "www-data" вернул ошибку.  Если далее в 
> скобках не указано подробностей про собственно ошибку - это должно 
> случаться тогда и только тогда, когда такого пользователя нет.  
> Если это не соответствует реальности - стоит искать причины в 
> системе.

Соседний тред наводит на мысли о том, что nginx собран на Linux'е 
статически.  В этом случае линковщик выдаёт большую простыню 
warning'ов, в том числе - про getpwnam():

warning: Using 'getpwnam' in statically linked applications requires at runtime 
the shared libraries from the glibc version used for linking

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

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

Re: Статическая сборка nginx с GD

2019-04-07 Пенетрантность Maxim Dounin
Hello!

On Sun, Apr 07, 2019 at 10:41:22PM +0300, Igor Sysoev wrote:

> > On 7 Apr 2019, at 22:16, Anton Kiryushkin  wrote:
> > 
> > Я взял код из лога и попробовал его собрать ровно так, как написано.
> > Строка моего configure следующая:
> > ./configure --prefix=/usr --conf-path=/etc/nginx/nginx.conf 
> > --error-log-path=/var/log/nginx/error.log 
> > --http-client-body-temp-path=/var/lib/nginx/body 
> > --http-fastcgi-temp-path=/var/lib/nginx/fastcgi 
> > --http-log-path=/var/log/nginx/access.log 
> > --http-proxy-temp-path=/var/lib/nginx/proxy 
> > --http-scgi-temp-path=/var/lib/nginx/scgi 
> > --http-uwsgi-temp-path=/var/lib/nginx/uwsgi 
> > --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug 
> > --with-http_addition_module --with-http_dav_module --with-http_geoip_module 
> > --with-http_gzip_static_module  --with-http_realip_module 
> > --with-http_stub_status_module --with-http_ssl_module 
> > --with-http_sub_module --with-sha1=/usr/include/openssl 
> > --with-md5=/usr/include/openssl --add-module=/usr/src/naxsi/naxsi_src 
> > --with-debug --with-http_v2_module --with-cc-opt="-static -static-libgcc" 
> > --with-ld-opt="-static -lm" --with-cpu-opt=generic 
> > --with-openssl=./openssl-1.0.2r --with-stream --with-stream_ssl_module 
> > --user=www-data --with-http_image_filter_module
> > 
> > Что-то тут уже устаревшее, но это не очень важно.
> > Выпадает ошибка:
> > checking for GD library ... not found
> > checking for GD library in /usr/local/ ... not found
> > checking for GD library in /usr/pkg/ ... not found
> > checking for GD library in /opt/local/ ... not found
> > 
> > Окей. Берем код автотеста:
> > 
> > #include 
> > #include 
> > #include 
> > 
> > int main(void) {
> > gdImagePtr img = gdImageCreateFromGifPtr(1, NULL);
> >   (void) img;
> > return 0;
> > }
> > 
> > Собираем:
> > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I 
> > /usr/pkg/include -o objs/autotest objs/autotest.c -static -lm 
> > -L/usr/pkg/lib -lgd (строчка из того же лога).
> > Не собирается.
> > Однако, если подвинуть -lm в конец:
> > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I 
> > /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib 
> > -lgd -lm
> > 
> > Все соберется.
> > 
> > Вопрос, как передвинуть на уровне сборки?
> 
> Штатно не двигается.
> Можно добавить в auto/lib/libgd/conf:
> 
> -   ngx_feature_libs="-L/usr/pkg/lib -lgd"
> +   ngx_feature_libs="-L/usr/pkg/lib -lgd -lm"
> 
> В динамической libgd.so зависимость от libm.so записана,
> а в статической такой возможности нет.

Штатно аналогичный результат можно, если очень хочется, получить так:

./configure --with-http_image_filter_module \
--with-ld-opt="-L/usr/pkg/lib -static -lgd -lm"

Хотя вот лично я бы - не рекомендовал, особенно под Linux'ом.  Там 
warning'и при статической линковке - не просто так, и 
игнорирование их ведёт к вопросам "у меня всё сломалось, что вы 
поменяли в nginx'е" вполне очевидным образом.

Тем более, что у современного GD зависимостей - устанешь 
перечислять, -lm - это только верхушка айсберга.  Скажем, чтобы 
собраться статически со штатным пакетом GD на FreeBSD мне 
потребовалась какая-то такая простыня:

./auto/configure --with-http_image_filter_module \
--with-ld-opt="-L/usr/local/lib -static -lgd -lm \
-lpng -lm -lz -lfontconfig -lfreetype -ljpeg \
-ltiff -lwebp -lexpat -lbz2"

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

Re: nginx: [emerg] getpwnam("www-data") failed

2019-04-07 Пенетрантность Maxim Dounin
Hello!

On Sat, Apr 06, 2019 at 01:21:06PM +0100, Anton Kiryushkin wrote:

> При обновлении на 1.15.10 поймал такую картину. В конфиге полжизни было
> написано:
> user www-data;
> 
> Пользователь есть, группа есть. Все ищется по /etc/passwd и /etc/group. Что
> поменялось в nginx?

Ничего.  Последнее изменение в соответствующей функции - 
стилистическое - датируется 2015 годом, nginx 1.9.6, 7ac57369036c.  
Последнее смысловое изменение - о том, чтобы сообщения об ошибках 
были более детерминированы - было в 2007 году, nginx 0.6.3, 
eb232400e829.

Сообщение как бы говорит о том, что библиотечный вызов 
getpwnam() с параметром "www-data" вернул ошибку.  Если далее в 
скобках не указано подробностей про собственно ошибку - это должно 
случаться тогда и только тогда, когда такого пользователя нет.  
Если это не соответствует реальности - стоит искать причины в 
системе.

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

  1   2   3   4   5   6   7   8   9   10   >