Re: Открытые файлы растут после обновления до 1.14

2018-06-27 Пенетрантность rihad
joneum@ пока не ответил, отписал другому девелоперу osa@ и он ответил, что
проблему пофиксили в www/nginx-devel (1.15.x)


Hi there,

fixed for www/nginx-devel with r473338.
Thanks for the report!

Jochen,

could you please review the r473338 revision and
update www/nginx.

--
Sergey A. Osokin

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,280196,280297#msg-280297

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

Re: nginx mainline vs nginx stable

2018-06-27 Пенетрантность rihad
> Наверное есть смысл перейти на использование ветки mainline 1.15.х
> Она не менее стабильная, чем stable, и на основании ветки mainline
> создается коммерческая версия "NGINX Plus".

Спасибо за детальный обзор, но пора энтузиазма давно прошла )) Сейчас важно
чтобы штука стабильно работала, чтобы секьюрные дырки лечились вовремя,
чтобы нововведений несовместимых не было и так далее - т.е. чтобы будни
админа упрощались, а не усложнялись )) В этом плане stable вполне
устраивает. Но вот такой косяк вышел с относительно новой технологией
Brotli, и то потому, что начальство решило на передовой волне идти когда это
было совсем не обязательно )) Кстати баг затрагивал mainline
(www/nginx-devel) тоже, просто там по стечению обстоятельств раньше
пофиксилось - разные майнтейнеры.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,280196,280307#msg-280307

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

Re: Открытые файлы растут после обновления до 1.14

2018-06-21 Пенетрантность rihad
Dmytro Lavryk Wrote:
---
> Точно. Там люди ходят. Не самые посещаемые сайты, но все же...
> 
> curl -H 'Accept-Encoding: br' -I https://site.address/
> ...
> content-encoding: br


Вы используете brotli on? Контент ложится в кэш br, или в сыром виде и
зажимается на лету? 
Можете посмотреть файл, просто грепните по ключу что используется в
fastcgi_cache_key 
Например если у вас $http_host$uri и вы запросили https://site.address/
то ищется по 

nice sudo fgrep -ax 'KEY: site.address/' /path/to/nginx/cache -rl

это даст название файла кэша в котором лежит https://site.address/ и который
сможете открыть через less и посмотреть тело.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,280196,280218#msg-280218

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

Re: Открытые файлы растут после обновления до 1.14

2018-06-20 Пенетрантность rihad
Вот на данный момент через 1 час 20 минут после последнего SIGHUP:

$ sudo lsof +L1 | grep -w ^nginx | wc -l
   39903
$ sysctl kern.openfiles
kern.openfiles: 64706

(разницу можно игнорировать, там и postgres есть, я sysctl привел просто
чтобы показать что они оба растут).

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,280196,280197#msg-280197

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

Re: Открытые файлы растут после обновления до 1.14

2018-06-20 Пенетрантность rihad
Dmytro Lavryk Wrote:
---
> BROTLI off
> 
> cache:
> fastcgi_cache_path /var/tmp/nginx/fastcgi_cache levels=1:2 keys_zone=
> ССС:100m inactive=240m;
> 
> lsof +L1 | grep -w ^nginx | wc -l
> 20
> 
> sysctl kern.openfiles
> kern.openfiles: 3481
> 
> reload последний раз был не помню точно когда... как раз как версия
> 1.14 в портах вышла - пересобрал и ребутнул.


Brotli убрать к сожалению не вариант, да и зачем воркараундить,
HTTP/2+Brotli, Accept-Encoding: br - норма в наши дни.
Причем еще раз замечу что такой сетап работает без глюков с 1.12.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,280196,280202#msg-280202

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

Re: Открытые файлы растут после обновления до 1.14

2018-06-20 Пенетрантность rihad
Илья Шипицин Wrote:
---
> OPTIONS_FILE_SET+=BROTLI
> 
> это недефолтная настройка ?

Недефолтная. 

> 
> у нас примерно такой набор модулей. есть инсталяции на freebsd.
> но кешем не пользуемся
> 
> спецэффекта не наблюдаем
> 

Потому что кешем не пользуетесь )

> 
> попробуйте на вашей сборке прогнать тесты вот эти
> https://github.com/nginx/nginx-tests  ?
> 

А для чего? Одни конфиг, одни опции сборки, этого глюка нет на 1.12 и есть
на 1.14.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,280196,280200#msg-280200

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

Re: Открытые файлы растут после обновления до 1.14

2018-06-20 Пенетрантность rihad
Gena Makhomed Wrote:
---
> On 20.06.2018 22:05, rihad wrote:
> 
> > Brotli убрать к сожалению не вариант
> 
> Довольно странное занятие для сервера - вытаскивать несжатые страницы
> из кеша и потом тратить время и процессор сервера на компрессию
> этих страниц новым и модным алгоритмом brotli.

Да, знаю, на практике мизер по cpu из-за многоуровневного кэша.
Вопрос даже не в этом, а в том, что:

> 
> > Причем еще раз замечу что такой сетап работает без глюков с 1.12.
> 
> Проблема явно не в nginx, а в этом стороннем модуле.
> 

От этого ничуть не легче ( Т.к. в 1.12 вся эта связка не глючила с FD leak.
Правда и archivers/brotli тоже обновился с 0.6.0 до 1.0.4
Лечишь секьюрные дырки (в данном случае обновление дыры libressl потребовало
перестройки и обновления nginx) и вот такие скрытые дыры.


> -- 
> Best regards,
>   Gena
> 
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,280196,280209#msg-280209

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

Открытые файлы растут после обновления до 1.14

2018-06-20 Пенетрантность rihad
После обновления nginx с 1.12 до 1.14 на FreeBSD 10 открытые удаленные файлы
(lsof +L1) стремительно растут для nginx.
В обеих версиях один конфиг, и одни опции постройки.

OPTIONS_FILE_SET+=DSO
OPTIONS_FILE_SET+=FILE_AIO
OPTIONS_FILE_SET+=THREADS
OPTIONS_FILE_SET+=HTTP
OPTIONS_FILE_SET+=HTTP_CACHE
OPTIONS_FILE_SET+=HTTP_GZIP_STATIC
OPTIONS_FILE_SET+=HTTP_REALIP
OPTIONS_FILE_SET+=HTTP_REWRITE
OPTIONS_FILE_SET+=HTTP_SSL
OPTIONS_FILE_SET+=HTTPV2
OPTIONS_FILE_SET+=STREAM_SSL_PREREAD
OPTIONS_FILE_SET+=BROTLI

Используется proxy_cache_path  /usr/home/nginx/cache/foo/html levels=1:2
keys_zone=foo:64m inactive=1d max_size=8g;


Единственный выход пока - периодически запускать service nginx reload
(SIGHUP) - тогда старые воркеры отмирают и освобождают занятые дескрипторы.
Есть еще сетапы с nginx 1.12 - там lsof +L1 тоже показывает такие файлы, но
они измеряются в нескольких десятках и не растут.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,280196,280196#msg-280196

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

Re: Открытые файлы растут после обновления до 1.14

2018-06-21 Пенетрантность rihad
Отлключение компрессии brotli на лету решило проблему утечки FD:

brotli off;

Теперь осталось понять почему оно глючит.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,280196,280210#msg-280210

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

Re: Открытые файлы растут после обновления до 1.14

2018-06-21 Пенетрантность rihad
Dmytro Lavryk Wrote:
---
> Собрал, включил, перезапустил.
> Работает часа 3. Описаного эффекта не наблюдается - все работает.


Точно зажимает? Попробуйте плиз на своем ресурсе запросить что-то по https.

curl -H 'Accept-Encoding: br' -I https://example.com/

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,280196,280212#msg-280212

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

Re: Открытые файлы растут после обновления до 1.14

2018-06-21 Пенетрантность rihad
Спасибо, отписал майнтейнеру порта www/nginx joneum@

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,280196,280225#msg-280225

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

Re: Открытые файлы растут после обновления до 1.14

2018-06-28 Пенетрантность rihad
Jochen Neumeister  наконец ответил:

i work on it :-)

joneum

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,280196,280313#msg-280313

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

Re: Открытые файлы растут после обновления до 1.14

2018-06-29 Пенетрантность rihad
Отлично, проверил - проблема решилась. Всем спасибо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,280196,280336#msg-280336

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

proxy_next_upstream & HTTP 502

2019-05-12 Пенетрантность rihad
У нас стоит:
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;

Иногда в случае если один из апстримов в дауне в access.log появляются
подобные строчки:


10.10.10.10 - S387DE34EI-1557637722 [12/May/2019:05:08:42 +] "GET
/blah/blah HTTP/1.1" 502 12001 "-" "- example.com" "-"

nginx логирует запрос только если попробовал все апстримы, или после
каждого? Здесь больше похоже на второе. Можно ли как-то настроить чтобы
логировался только результат последнего попробованного апстрима? Он и будет
результатом запроса.

nginx version: nginx/1.14.0

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284130,284130#msg-284130

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

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

2019-05-07 Пенетрантность rihad
Эти варны возникли при чтении конфига после обновления до 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 сидят два сертификата, второй из которых всегда
одинаков для всех.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284082,284082#msg-284082

___
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 Пенетрантность rihad
-BEGIN CERTIFICATE-
MIIFsjCCBJqgAwIBAgISA1J3jfFIPKXDLBQ8ihTsBqlrMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xOTA0MDkxODIyNDFaFw0x
OTA3MDgxODIyNDFaMCcxJTAjBgNVBAMTHHR1cmJvYXotMTM5NTEwNjc0LmF6c3Rh
Z2UuaW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDNww06PtB5nP25
rQ2hYlhqx4POuTxCaDcHRg36t2oGeMTkFC75qBl+DjyXxJmlMsObEO5nt5zgaqcL
Jl49s0acI/yA+hSh7vQpZRZ+4/jQ11R8QLd/9oOrhUqJ9fxgzHitsFIRFeh0pNxW
eROmDqYJlSMEr5wxmmJtWEEMbLlFxIm/2/NUovXrZJOsoc5bx1sdsJnFpumdeFbU
aYG1vPxD9NN5sGgwLFHdK3QDp8RdLGqV5ylhN6kadgnQElRpIaX9QNyRANUnNeGX
jj3wuiovL9xx0gR+wcatMFc4y3JJORkcLtEk28y6qEcNQ0g5jYbqh1317Y7ByH0d
BVJLm7djAgMBAAGjggKzMIICrzAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYI
KwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFHE9h0j5
aniSTd8SMYcz0E08fFe4MB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyh
MG8GCCsGAQUFBwEBBGMwYTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AuaW50LXgz
LmxldHNlbmNyeXB0Lm9yZzAvBggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgz
LmxldHNlbmNyeXB0Lm9yZy8wagYDVR0RBGMwYYIfcnUudHVyYm9hei0xMzk1MTA2
NzQuYXpzdGFnZS5pboIgc3NsLnR1cmJvYXotMTM5NTEwNjc0LmF6c3RhZ2UuaW6C
HHR1cmJvYXotMTM5NTEwNjc0LmF6c3RhZ2UuaW4wTAYDVR0gBEUwQzAIBgZngQwB
AgEwNwYLKwYBBAGC3xMBAQEwKDAmBggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRz
ZW5jcnlwdC5vcmcwggEDBgorBgEEAdZ5AgQCBIH0BIHxAO8AdgDiaUuuJujpQAno
hhu2O4PUPuf+dIj7pI8okwGd3fHb/gAAAWoDjW7TAAAEAwBHMEUCIQDpdUACdcIx
U0al7y8pAA6mfkDmXqKVSU8gOGc3YihxywIgE8+nQjzXKYSLCoDLA+fB27SjVwrS
mtVec9UN/cf+IvgAdQApPFGWVMg5ZbqqUPxYB9S3b79Yeily3KTDDPTlRUf0eAAA
AWoDjWzkAAAEAwBGMEQCIDxpqP3iNu0/PpXG9UDV6cKYLrhKNIs8TTvaTUMV0o4S
AiBy+XNTIij/IjcwEOcG/GVWlTVQMq2vH9N9nmSCUwviuDANBgkqhkiG9w0BAQsF
AAOCAQEACto3pd6I2VMWl5mgbw+/A9SDgFW2saw1Ju3iIcYP37uWeCzFwZZXg1pP
Lf4mgfxiE2Qyv3J9KFZNklBGJ2Ga/PaP861uib0Y1l8dOcADFPNvjuThpm3537Zy
I7hr63bE6qnDrwitleZJcb4SOW46cme81DmW9uZBtMSUrAlL2dbU5/PH+YjSeNwq
JYndjTX4NAUmLyTF/H4IpsOLsWcIprGMUX+CvmoonN/Ona8gUSvQS3UzCdfgzgHZ
KW3m6iYwz3GeAJ1gK0XKZKMK31jDV3S1rNWcXuClgRHKQq75JpCfL3Iu50soiH5p
es5SViQLNlbEjdAOSS55Jic36Nog3Q==
-END CERTIFICATE-
-BEGIN CERTIFICATE-
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow
SjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxIzAhBgNVBAMT
GkxldCdzIEVuY3J5cHQgQXV0aG9yaXR5IFgzMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAnNMM8FrlLke3cl03g7NoYzDq1zUmGSXhvb418XCSL7e4S0EF
q6meNQhY7LEqxGiHC6PjdeTm86dicbp5gWAf15Gan/PQeGdxyGkOlZHP/uaZ6WA8
SMx+yk13EiSdRxta67nsHjcAHJyse6cF6s5K671B5TaYucv9bTyWaN8jKkKQDIZ0
Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWA
a6xK8xuQSXgvopZPKiAlKQTGdMDQMc2PMTiVFrqoM7hD8bEfwzB/onkxEz0tNvjj
/PIzark5McWvxI0NHWQWM6r6hCm21AvA2H3DkwIDAQABo4IBfTCCAXkwEgYDVR0T
AQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwfwYIKwYBBQUHAQEEczBxMDIG
CCsGAQUFBzABhiZodHRwOi8vaXNyZy50cnVzdGlkLm9jc3AuaWRlbnRydXN0LmNv
bTA7BggrBgEFBQcwAoYvaHR0cDovL2FwcHMuaWRlbnRydXN0LmNvbS9yb290cy9k
c3Ryb290Y2F4My5wN2MwHwYDVR0jBBgwFoAUxKexpHsscfrb4UuQdf/EFWCFiRAw
VAYDVR0gBE0wSzAIBgZngQwBAgEwPwYLKwYBBAGC3xMBAQEwMDAuBggrBgEFBQcC
ARYiaHR0cDovL2Nwcy5yb290LXgxLmxldHNlbmNyeXB0Lm9yZzA8BgNVHR8ENTAz
MDGgL6AthitodHRwOi8vY3JsLmlkZW50cnVzdC5jb20vRFNUUk9PVENBWDNDUkwu
Y3JsMB0GA1UdDgQWBBSoSmpjBH3duubRObemRWXv86jsoTANBgkqhkiG9w0BAQsF
AAOCAQEA3TPXEfNjWDjdGBX7CVW+dla5cEilaUcne8IkCJLxWh9KEik3JHRRHGJo
uM2VcGfl96S8TihRzZvoroed6ti6WqEBmtzw3Wodatg+VyOeph4EYpr/1wXKtx8/
wApIvJSwtmVi4MFU5aMqrSDE6ea73Mj2tcMyo5jMd6jmeWUHK8so/joWUoHOUgwu
X4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlG
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-END CERTIFICATE-

Последняя версия acme.sh сует пустую строку между первым и вторым, это никак
не влияет ни на что.

$ nginx -V
nginx version: nginx/1.14.2
built with OpenSSL 1.0.2o-freebsd  27 Mar 2018
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
/usr/local/include' --with-ld-opt='-L /usr/local/lib'
--conf-path=/usr/local/etc/nginx/nginx.conf
--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx/error.log --user=www --group=www
--modules-path=/usr/local/libexec/nginx --with-file-aio
--http-client-body-temp-path=/var/tmp/nginx/client_body_temp
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
--http-proxy-temp-path=/var/tmp/nginx/proxy_temp
--http-scgi-temp-path=/var/tmp/nginx/scgi_temp
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
--http-log-path=/var/log/nginx/access.log --with-http_v2_module
--with-http_addition_module --with-http_auth_request_module
--with-http_dav_module --with-http_flv_module --with-http_gunzip_module
--with-http_gzip_static_module --with-http_mp4_module
--with-http_random_index_module --with-http_realip_module --with-pcre
--with-http_secure_link_module --with-http_slice_module
--with-http_ssl_module --with-http_stub_status_module --with-http_sub_module
--without-mail_imap_module 

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

2019-05-07 Пенетрантность rihad
Вот эта сборка с 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
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
/usr/local/include' --with-ld-opt='-L /usr/local/lib'
--conf-path=/usr/local/etc/nginx/nginx.conf
--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx/error.log --user=www --group=www
--with-debug --modules-path=/usr/local/libexec/nginx --with-file-aio
--http-client-body-temp-path=/var/tmp/nginx/client_body_temp
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
--http-proxy-temp-path=/var/tmp/nginx/proxy_temp
--http-scgi-temp-path=/var/tmp/nginx/scgi_temp
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
--http-log-path=/var/log/nginx/access.log --with-http_v2_module
--with-http_addition_module --with-http_auth_request_module
--with-http_gunzip_module --with-http_gzip_static_module
--with-http_realip_module --with-pcre --with-http_secure_link_module
--with-http_slice_module --with-http_ssl_module
--with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include'
--without-mail_imap_module --without-mail_pop3_module
--without-mail_smtp_module --with-stream_ssl_preread_module --with-threads
--add-dynamic-module=/usr/ports/www/nginx/work/ngx_brotli-8104036

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284082,284089#msg-284089

___
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 Пенетрантность rihad
Нашел причину. Дело в том, что нам нужен модуль brotli, а его в дефолтном
пакете nginx на FreeBSD нет, поэтому строим сами www/nginx из порта, и она
строится с LibreSSL. Вот с ней эти SSL stapling ворнинги бывают. Не уверен
кому адресовать )

[rihad@master /usr/local/etc/nginx]$ nginx -V
nginx version: nginx/1.16.0
built with LibreSSL 2.9.1
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
/usr/local/include' --with-ld-opt='-L /usr/local/lib'
--conf-path=/usr/local/etc/nginx/nginx.conf
--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx/error.log --user=www --group=www
--with-debug --modules-path=/usr/local/libexec/nginx --with-file-aio
--http-client-body-temp-path=/var/tmp/nginx/client_body_temp
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
--http-proxy-temp-path=/var/tmp/nginx/proxy_temp
--http-scgi-temp-path=/var/tmp/nginx/scgi_temp
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
--http-log-path=/var/log/nginx/access.log --with-http_v2_module
--with-http_addition_module --with-http_auth_request_module
--with-http_gunzip_module --with-http_gzip_static_module
--with-http_realip_module --with-pcre --with-http_secure_link_module
--with-http_slice_module --with-http_ssl_module
--with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include'
--without-mail_imap_module --without-mail_pop3_module
--without-mail_smtp_module --with-stream_ssl_preread_module --with-threads
--add-dynamic-module=/usr/ports/www/nginx/work/ngx_brotli-8104036

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284082,284088#msg-284088

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

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

2019-08-18 Пенетрантность rihad
У нас на некоторых серверах inactive стоит 90 дней, что будет если  nginx
перезагрузить до этого времени, сохранится ли время последнего запроса к
кешированному ресурсу? Я попытался сам разобраться по коду но там сложно.

file->accessed = now;

в ./src/core/ngx_open_file_cache.c

И потом в ngx_http_file_cache_update() не увидел что поле acessed пишется.
Может в другом месте где-то?

Спасибо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285333,285333#msg-285333

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

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

2019-08-15 Пенетрантность rihad
Не знаете есть ли обновления? Сейчас в nginx вышла дырка в http2 и пришлось
обновляться с 1.16.0 до 1.16.1, но ворнинги от ssl_stapling вернулись.
Дело в том что сайтов много, релоад в рамках общей задачи мы делаем довольно
часто и это видит каждый пользователь, это засоряет экран и неизбежно
приведет к увеличению вопросов в саппорт, т.е. ко мне ) Не хотелось бы
переходить на openssl пока это есть.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284203,285297#msg-285297

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

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

2019-08-15 Пенетрантность rihad
Я избавился от ворнингов временно просто перестроив с openssl :(

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284203,285298#msg-285298

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

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

2019-08-15 Пенетрантность rihad
А можно вообще вернуться на родную openssl из фришки 11.х? Как она,
стабильна? Вопросы лицензии и разного уровня "свободы" между "open" и
"libre" мне безразличны.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284203,285300#msg-285300

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

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

2019-08-15 Пенетрантность rihad
В портах фришки есть еще libressl-devel, там версия 3.0.0, пересобрал nginx
с ней - то же самое.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284203,285299#msg-285299

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

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

2019-08-07 Пенетрантность rihad
Меня вот это немного смутило:

"When buffering is disabled, the response is passed to a client
synchronously, immediately as it is received. nginx will not try to read the
whole response from the proxied server. "

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffering

Получается когда buffering включен, то наоборот, контент читается полностью
перед началом отдачи клиенту.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285149,285150#msg-285150

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

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

2019-08-07 Пенетрантность rihad
Допустим если включено кеширование через proxy_cache, а также включено
proxy_buffering (по умолчанию). Что происходит когда клиент запрашивает
ресурс которого нет в кеше? Он сначала полностью скачивается из апстрима,
кешируется, и только потом начинает отдаваться клиенту? И если таких уровней
апстримов 2 или более, то лаг получения контента клиентом увеличивается
грубо говоря в 2 или более раз?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285149,285149#msg-285149

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

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

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

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285149,285153#msg-285153

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

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

2019-08-07 Пенетрантность rihad
Спасибо за ответ. Буферизация конечно включена, мне просто показалось что
желаемое поведение (одновременный прием от апстрима и отправка клиенту)
происходит только при выключенной буферизации. Размер буфера в несколько
десятков кб роли не играет, это почти одновременно. У нас в основном
картинки по несколько сот кб.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285149,285155#msg-285155

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

could not allocate node in cache keys zone "xxx"

2019-07-29 Пенетрантность rihad
Когда cache loader читает эакешированные файлы при запуске nginx, если
proxy_cache_path max_size недостаточно велика, вот такие ошибки начинают
сыпаться под конец. Насколько это плохо? Может это повлиять на невозможность
кэшировать новые файлы, и в целом на нормальную работу? Можно чтобы это
предотвратить выделить сразу много памяти, все равно как я понял nginx
выделяет эту память мелкими порциями и используется в RSS не больше, чем
нужно, так ли это?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285024,285024#msg-285024

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

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

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

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

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284950,284958#msg-284958

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

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

2019-07-22 Пенетрантность rihad
Можно как-то обойтись без reload (SIGHUP) nginx для того чтобы он перечитал
с диска сертификаты (ssl_certificate)? Без этого он не бывает в курсе что
они были обновлены. Но у релоад есть плохая штука что он наверняка забывает
такие вещи как inactive=nnn в директиве proxy_cache_path, и если reload
происходит раз в неделю, то любой inactive выше недели по сути ничего не
делает. Также каждый релоад требует перечтения всех имеющихся данных cache
loader'ом, а когда таких данных сотни гигов и диски (пока :)) крутящиеся,
директива max_size не способна ограничивать дисковое пространство (т.к. пока
loader все файлы не перечитает nginx не знает сколько пространства занято,
если не ошибаюсь).

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284950,284950#msg-284950

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

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

2019-07-22 Пенетрантность rihad
Спасибо! Да, проверил, если не меняется ничего, то cache loader при релоаде
не запускается. Я просто релоадил когда что-то менял, поэтому подумал что
всегда так )

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284950,284952#msg-284952

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

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

2019-07-22 Пенетрантность rihad
И еще параллельно такой вопрос возник: у нас крутящиеся диски на одном из
серверов, и proxy_cache_path levels=1:2 все это приводит к тому, что в
каждой директории где-то 3-4 тысячи файлов (я так понимаю поменять на 2:2 +
reload уже нельзя?). cache_loader при старте работает довольно долго, но не
грузит. Он очень мало CPU времени тратит или дискового, за сутки работы
сейчас он потратил 0:04.37 (согласно ps) это 4 минуты, но он не
заканчивается. lsof показывает что он очень много времени проводит на каждой
из директорий кэша. А их тысячи. Надеюсь он не читает весь файл
(преимущественно картинки), а только его начало с заголовками? )) Может ли
его такая тормознутость привести к повторному запросу ресурса из источника и
повторному кэшированию? Что делает nginx когда в кэше пока объекта нет,
пытается ли сам к диску обратиться?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284950,284953#msg-284953

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

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

2019-07-22 Пенетрантность rihad
Спасибо огромное за инфу!

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,284950,284955#msg-284955

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

cache file has too long header

2019-09-23 Пенетрантность rihad
Эта ошибка часто в логе для разных файлов. В гугле нашел что это решается
увеличением proxy_buffer_size, но он и так у нас 8k.
Подскажите как решить. Версия 1.16.1, OS FreeBSD 11.3. Из-за этой ошибки кеш
игнорируется и ресурс запрашивается из апстрима, а это дорогой контент
(google maps). Проблема только с этими ресурсами, другие кешируются
нормально. Урл не такой уж и длинный, вроде.

Пример ошибки:
2019/09/23 21:04:01 [crit] 95594#100948: *426913488 cache file
"/usr/home/nginx/cache/myproj/maps/d/2d/28889e499a0f9ef187ba9fb63270c2dd"
has too long header, client: 172.16.1.16, server: assets.example.com,
request: "GET
/maps/api/staticmap?key=AIzaSyBsXrvwBUBTrAMP0K-uCSJaH2cKU4xLPu4=12.412358%2C53.823786=320x100=11
HTTP/1.1", host: "assets.example.com", referrer:
"https://example.com/foo/bar;.

proxy_temp_path   /usr/home/nginx/temp;
proxy_http_version  1.1;

proxy_headers_hash_max_size 1024;
proxy_headers_hash_bucket_size 128;
proxy_buffer_size 8k;

proxy_connect_timeout 15s;
proxy_send_timeout 5s;

proxy_cache_path  /usr/home/nginx/cache/myproj/maps levels=1:2
keys_zone=myproj-maps:128m inactive=30d max_size=8g;

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285677,285677#msg-285677

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

Re: cache file has too long header

2019-09-24 Пенетрантность rihad
Спасибо, а чего оно за полтора года не перекочевало из devel в mainline? У
нас кеш 3 уровней, поддерживать патч на каждом из них как-то не то.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285677,285681#msg-285681

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

Re: cache file has too long header

2019-09-24 Пенетрантность rihad
Пропатчил, построил, перезапустил через роллинг апгрейд (USR+QUIT). Я так
понимаю изменение для новых файлов будет актуально т.к. хедер поменялся.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285677,285690#msg-285690

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

Re: cache file has too long header

2019-09-24 Пенетрантность rihad
Что любопытно после релоада нет ни одной ошибки, хотя раньше хотя бы раз в
минуту было. Наверное пока cache loader запущен этих ситуаций не возникает.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285677,285691#msg-285691

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

Re: cache file has too long header

2019-09-24 Пенетрантность rihad
cache loader давно вышел, новых записей "too long header" в логе пока нет.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285677,285692#msg-285692

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

Re: cache file has too long header

2019-09-24 Пенетрантность rihad
А это не повлияет на другие ресурсы, кроме maps? Например если будет
закеширован контент, отличающийся по языку, он правильно будет отдан?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285677,285686#msg-285686

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

Non-idempotent requests vs. upstream failover

2019-09-29 Пенетрантность rihad
В случае если proxy апстрим не доступен на уровне сокета (ECONNREFUSED, а не
просто вернулось HTTP 5хх), будет ли nginx ретраить POST запрос на следующих
апстримах? По идее должен т.к. запрос никем не был принят и обработан.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285751,285751#msg-285751

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

Re: Non-idempotent requests vs. upstream failover

2019-09-30 Пенетрантность rihad
Спасибо, а логируется ли в таких случаях в error log? Или только если все
апстримы фейлнули?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285751,285753#msg-285753

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

Re: cache file has too long header

2019-09-25 Пенетрантность rihad
Ни одной записи за сутки! Вот вам фидбяк ) Спасибо. Надеюсь патч появится в
релизах. Для его проявления не нужно каких-то крупных деплоев, если я
правильно понял, а только чтобы апстрим возвращал нгинксу  Vary для
кешируемого ресурса.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285677,285705#msg-285705

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