From b1os на bk.ru Thu Nov 1 08:31:27 2018 From: b1os на bk.ru (=?UTF-8?B?QW5kcmVpIEVuc2hpbg==?=) Date: Thu, 01 Nov 2018 11:31:27 +0300 Subject: =?UTF-8?B?0LTQvtC60YPQvNC10L3RgtCw0YbQuNGPOiBhZGRfaGVhZGVyINGBINC/0YPRgdGC?= =?UTF-8?B?0YvQvCDQt9C90LDRh9C10L3QuNC10Lw=?= Message-ID: <1541061087.790855889@f492.i.mail.ru> Привет! add_header может принимать в качестве значения переменную. Если переменная - это пустая строка, то заголовок добавлен не будет. В документации я не нашёл упоминания об этом (1). Однако дока proxy_set_header описывает похожий случай(2) Признаться, мне неизвестно, "легальны" ли пустые заголовки в HTTP. Если протокол не допускает пустых заголовков, то, наверное, обновление документации не требуется. С другой стороны в (2) есть, а в (1) нет. (1) http://nginx.org/ru/docs/http/ngx_http_headers_module.html#add_header (2) https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_set_header --- Best Regards, Andrei Enshin ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Nov 1 13:30:40 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 1 Nov 2018 16:30:40 +0300 Subject: =?UTF-8?B?UmU6INC00L7QutGD0LzQtdC90YLQsNGG0LjRjzogYWRkX2hlYWRlciDRgSDQv9GD?= =?UTF-8?B?0YHRgtGL0Lwg0LfQvdCw0YfQtdC90LjQtdC8?= In-Reply-To: <1541061087.790855889@f492.i.mail.ru> References: <1541061087.790855889@f492.i.mail.ru> Message-ID: <20181101133040.GZ56558@mdounin.ru> Hello! On Thu, Nov 01, 2018 at 11:31:27AM +0300, Andrei Enshin wrote: > add_header может принимать в качестве значения переменную. Если > переменная - это пустая строка, то заголовок добавлен не будет. > В документации я не нашёл упоминания об этом (1). > Однако дока proxy_set_header описывает похожий случай(2) > > Признаться, мне неизвестно, "легальны" ли пустые заголовки в > HTTP. Если протокол не допускает пустых заголовков, то, > наверное, обновление документации не требуется. С другой стороны > в (2) есть, а в (1) нет. Семантически в HTTP пустое значение заголовка эквивалентно отсутствию соответствующего заголовка, поэтому добавлять заголовки с пустым значением смысла не имеет. В случае proxy_set_header - речь в документации в первую очередь про то, что использование пустого значения позволяет не передавать на бэкенд соответствующий заголовок, в том числе если его прислал клиент. То есть позволяет убрать заголовок при проксировании. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Fri Nov 2 07:00:32 2018 From: nginx-forum на forum.nginx.org (zxek) Date: Fri, 02 Nov 2018 03:00:32 -0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiByZWxvYWQ=?= In-Reply-To: <065416b59958332294a6452f34610fed.NginxMailingListRussian@forum.nginx.org> References: <065416b59958332294a6452f34610fed.NginxMailingListRussian@forum.nginx.org> Message-ID: <3445101f41688acee754a8dcc744a64a.NginxMailingListRussian@forum.nginx.org> Добрый день. Колво активных сайтов выросло и точно такая же ситуация. при reload в журнал пишется 2018/11/02 11:55:11 [emerg] 1615#1615: open() "/var/www/httpd-logs/*.ru.access.log" failed (24: Too many open files) в настройках nginx === user www-data; worker_processes 16; worker_rlimit_nofile 200000; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { #-worker_connections 10000; worker_connections 5120; multi_accept on; use epoll; } === # ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 64232 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 300000 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 64232 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited кто может подсказать, в какую сторону смотреть? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,179057,281770#msg-281770 From raven_kg на megaline.kg Fri Nov 2 07:03:29 2018 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Fri, 2 Nov 2018 13:03:29 +0600 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiByZWxvYWQ=?= In-Reply-To: <3445101f41688acee754a8dcc744a64a.NginxMailingListRussian@forum.nginx.org> References: <065416b59958332294a6452f34610fed.NginxMailingListRussian@forum.nginx.org> <3445101f41688acee754a8dcc744a64a.NginxMailingListRussian@forum.nginx.org> Message-ID: <084018b1-4209-b835-ecbe-f489ffd44c62@megaline.kg> В сторону systemd, если он есть. В /etc/systemd/system/ создать каталог nginx.service.d, в который положить rlimit_nofile.conf со сл. содержимым: [Service] LimitNOFILE=65536 и systemctl daemon-reload 02.11.2018 13:00, zxek пишет: > Добрый день. > > Колво активных сайтов выросло и точно такая же ситуация. > при reload в журнал пишется > 2018/11/02 11:55:11 [emerg] 1615#1615: open() > "/var/www/httpd-logs/*.ru.access.log" failed (24: Too many open files) > > в настройках nginx > === > user www-data; > worker_processes 16; > > worker_rlimit_nofile 200000; > > error_log /var/log/nginx/error.log warn; > pid /var/run/nginx.pid; > > events { > #-worker_connections 10000; > worker_connections 5120; > multi_accept on; > use epoll; > } > === > > # ulimit -a > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 64232 > max locked memory (kbytes, -l) 64 > max memory size (kbytes, -m) unlimited > open files (-n) 300000 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) 64232 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > > кто может подсказать, в какую сторону смотреть? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,179057,281770#msg-281770 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum на forum.nginx.org Fri Nov 2 07:57:11 2018 From: nginx-forum на forum.nginx.org (zxek) Date: Fri, 02 Nov 2018 03:57:11 -0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiByZWxvYWQ=?= In-Reply-To: <084018b1-4209-b835-ecbe-f489ffd44c62@megaline.kg> References: <084018b1-4209-b835-ecbe-f489ffd44c62@megaline.kg> Message-ID: raven_kg на megaline.kg Wrote: ------------------------------------------------------- ...skip.... спасибо! все заработало! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,179057,281772#msg-281772 From nginx-forum на forum.nginx.org Fri Nov 2 09:32:31 2018 From: nginx-forum на forum.nginx.org (kseleznyov) Date: Fri, 02 Nov 2018 05:32:31 -0400 Subject: =?UTF-8?B?UmU6INCd0LDRgdGC0YDQvtC50LrQsCDQv9GA0L7RgtC+0LrQvtC70LAgRmFzdENH?= =?UTF-8?B?SSDQtNC70Y8gaGlnaCBsb2Fk?= In-Reply-To: <20181031160807.GY56558@mdounin.ru> References: <20181031160807.GY56558@mdounin.ru> Message-ID: Спасибо за ответ. Но теперь есть дополнительные вопрос. Как nginx решает: нужно ли ему открывать новое FastCgi-соединение или можно прокэшировать запрос и потом обработать его по старому (уже существующему) соединению? Какие настройки nginx на это влияют? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281762,281773#msg-281773 From kulmaks на gmail.com Fri Nov 2 13:28:17 2018 From: kulmaks на gmail.com (Maksim Kulik) Date: Fri, 2 Nov 2018 16:28:17 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdGC0YDQvtC50LrQsCDQv9GA0L7RgtC+0LrQvtC70LAgRmFzdENH?= =?UTF-8?B?SSDQtNC70Y8gaGlnaCBsb2Fk?= In-Reply-To: References: <20181031160807.GY56558@mdounin.ru> Message-ID: Максим же написал выше: по умолчанию каждое соединение используется только для обработки одного запроса. Т.е. nginx открывает новое соединение на каждый новый запрос. Ссылки на настройки там также есть. пт, 2 нояб. 2018 г. в 12:32, kseleznyov : > Спасибо за ответ. > > Но теперь есть дополнительные вопрос. Как nginx решает: нужно ли ему > открывать новое FastCgi-соединение или можно прокэшировать запрос и потом > обработать его по старому (уже существующему) соединению? Какие настройки > nginx на это влияют? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,281762,281773#msg-281773 > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Fri Nov 2 13:39:10 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 02 Nov 2018 16:39:10 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdGC0YDQvtC50LrQsCDQv9GA0L7RgtC+0LrQvtC70LAgRmFzdENH?= =?UTF-8?B?SSDQtNC70Y8gaGlnaCBsb2Fk?= In-Reply-To: References: <20181031160807.GY56558@mdounin.ru> Message-ID: <1676831.cuj3O2ObT0@vbart-workstation> On Friday 02 November 2018 05:32:31 kseleznyov wrote: > Спасибо за ответ. > > Но теперь есть дополнительные вопрос. Как nginx решает: нужно ли ему > открывать новое FastCgi-соединение или можно прокэшировать запрос и потом > обработать его по старому (уже существующему) соединению? Какие настройки > nginx на это влияют? > Всё очень просто. Если есть свободное соединение на данный хост, то используется оно, если нет, то открывается новое. Максимальное количество соединений, которые можно сложить в кэш после обработки запроса, настраивается директивой keepalive: http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#keepalive Также эти соединения можно ограничить по времени нахождения в кэше и количеству запросов директивами keepalive_timeout и keepalive_requests соответственно. -- Валентин Бартенев From nginx-forum на forum.nginx.org Mon Nov 5 12:28:42 2018 From: nginx-forum на forum.nginx.org (I0Result) Date: Mon, 05 Nov 2018 07:28:42 -0500 Subject: =?UTF-8?B?0JrQsNC6INC/0YDQuNC+0YDQuNGC0LjQt9C40YDQvtCy0LDRgtGMINGI0LjRhNGA?= =?UTF-8?B?0Ysg0LTQu9GPIFRMU3YxLjM/?= Message-ID: <93b752bb7e431b8a3a6524b2600efd3c.NginxMailingListRussian@forum.nginx.org> у меня не получается установить приоритет для шифров. в конфиге прописываю ssl_ciphers TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:EECDH+CHACHA20:EECDH+AESGCM:EECDH+AES; ssl_prefer_server_ciphers on; запускаю тест на SSL Labs https://angristan.xyz/content/images/2018/11/ssl-labs-tls-13-ciphers.png Шифры выдает в другом порядке TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256 пытаюсь поставить приоритезацию с помощью openssl openssl ciphers -s -v TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:EECDH+CHACHA20:EECDH+AESGCM | column -t в ответе нет изменений. TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD Как поставить шифр TLS_CHACHA20_POLY1305_SHA256 на первое место? Спасибо Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281784,281784#msg-281784 From nginx-forum на forum.nginx.org Mon Nov 5 12:38:46 2018 From: nginx-forum на forum.nginx.org (I0Result) Date: Mon, 05 Nov 2018 07:38:46 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LjQvtGA0LjRgtC40LfQuNGA0L7QstCw0YLRjCDRiNC4?= =?UTF-8?B?0YTRgNGLINC00LvRjyBUTFN2MS4zPw==?= In-Reply-To: <93b752bb7e431b8a3a6524b2600efd3c.NginxMailingListRussian@forum.nginx.org> References: <93b752bb7e431b8a3a6524b2600efd3c.NginxMailingListRussian@forum.nginx.org> Message-ID: <3ca3e1f4ad37a36533bea6736f0166e8.NginxMailingListRussian@forum.nginx.org> я смотрю openssl добавил другой параметр для сортировки шифров -ciphersuites (https://www.openssl.org/docs/man1.1.1/man1/ciphers.html) Если запускать команду, то шифры начинают приоритезироваться openssl ciphers -ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256 -s -v EECDH+CHACHA20:EECDH+AESGCM | column -t TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD Как быть с настройками nignx? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281784,281785#msg-281785 From nginx-forum на forum.nginx.org Tue Nov 6 10:09:10 2018 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Tue, 06 Nov 2018 05:09:10 -0500 Subject: =?UTF-8?B?0LrQsNC6INC/0YDQsNCy0LjQu9GM0L3QviDQv9GA0L7Qv9C40YHQsNGC0Ywg0L8=?= =?UTF-8?B?0YPRgtGMINC00L4g0YHRgtCw0YLQuNC60Lg=?= Message-ID: <0a81be623270ad4355a1ddf2aa4c19b5.NginxMailingListRussian@forum.nginx.org> server { ... root /srv/www/app/web; index index.php index.html; port_in_redirect off; if (!-e $request_filename) { rewrite ^/(.*)/$ https://$host/$1 permanent; } location /restore { alias /srv/www/frontend/build/; rewrite ^/restore$ /restore/; ... При открытии страницы localhost/restore не может найти статику static/css/main.css Status Code: 404 Not Found /srv/www/frontend/build/static/css/ /srv/www/frontend/build/static/js/ /srv/www/frontend/build/static/media/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281795,281795#msg-281795 From nginx-forum на forum.nginx.org Tue Nov 6 10:24:58 2018 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Tue, 06 Nov 2018 05:24:58 -0500 Subject: =?UTF-8?B?QmFzaWNBdXRoINGC0L7Qu9GM0LrQviDRgSDQvtC/0YDQtdC00LXQu9C10L3QvdGL?= =?UTF-8?B?0YUgSVA=?= Message-ID: <7e20b91347f363b7d06b970a56a3ee39.NginxMailingListRussian@forum.nginx.org> Модуль ngx_http_access_module позволяет ограничить доступ для определённых адресов клиентов. ngx_http_auth_basic_module позволяет ограничить доступ к ресурсам с проверкой имени и пароля. Можно ли реализовать проверку имени и пароля при условии входа с определенных ip адресов?, если да то как? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281796,281796#msg-281796 From chipitsine на gmail.com Tue Nov 6 11:24:24 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 6 Nov 2018 16:24:24 +0500 Subject: =?UTF-8?B?UmU6INC60LDQuiDQv9GA0LDQstC40LvRjNC90L4g0L/RgNC+0L/QuNGB0LDRgtGM?= =?UTF-8?B?INC/0YPRgtGMINC00L4g0YHRgtCw0YLQuNC60Lg=?= In-Reply-To: <0a81be623270ad4355a1ddf2aa4c19b5.NginxMailingListRussian@forum.nginx.org> References: <0a81be623270ad4355a1ddf2aa4c19b5.NginxMailingListRussian@forum.nginx.org> Message-ID: вт, 6 нояб. 2018 г. в 15:09, inkognito0609 : > server { > ... > root /srv/www/app/web; > > index index.php index.html; > > port_in_redirect off; > if (!-e $request_filename) { > rewrite ^/(.*)/$ https://$host/$1 permanent; > } > безотносительно вашего исходного вопроса (я не в курсе, что у вас сломалось) .... есть няшная штука для проверки, есть файл или нет файла - try_files там под капотом ровно то же, что у вас, но синтаксис получается читаемый > > location /restore { > alias /srv/www/frontend/build/; > rewrite ^/restore$ /restore/; > ... > При открытии страницы localhost/restore не может найти статику > static/css/main.css > Status Code: 404 Not Found > > /srv/www/frontend/build/static/css/ > /srv/www/frontend/build/static/js/ > /srv/www/frontend/build/static/media/ > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,281795,281795#msg-281795 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Nov 6 11:25:36 2018 From: nginx-forum на forum.nginx.org (kseleznyov) Date: Tue, 06 Nov 2018 06:25:36 -0500 Subject: =?UTF-8?B?UmU6INCd0LDRgdGC0YDQvtC50LrQsCDQv9GA0L7RgtC+0LrQvtC70LAgRmFzdENH?= =?UTF-8?B?SSDQtNC70Y8gaGlnaCBsb2Fk?= In-Reply-To: <1676831.cuj3O2ObT0@vbart-workstation> References: <1676831.cuj3O2ObT0@vbart-workstation> Message-ID: Добрый день! Проблема такая. Мы используем библиотеку libfcgi. Она популярная, хорошо про тестированная и т.д. и т.п., но... она не поддерживает переиспользование соединений. Может быть посоветуете другую библиотеку для c++? Если же использовать libfcgi, то поясню свой предыдущий вопрос. Допустим nginx уже открыл N соединений FastCGI и по каждому из них уже обрабатывается FastCGI-запрос. Допустим приходит ещё один HTTP-запрос и у nginx есть три пути: либо открывать ещё одно FastCGI-соединение для обработки нового HTTP-запроса, либо откладывать этот HTTP-запрос (пока не отработает один из N запросов), либо вообще возвращать ошибку. Как поступает nginx? Какие настройки на это влияют? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281762,281797#msg-281797 From chipitsine на gmail.com Tue Nov 6 11:28:48 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 6 Nov 2018 16:28:48 +0500 Subject: =?UTF-8?B?UmU6INCd0LDRgdGC0YDQvtC50LrQsCDQv9GA0L7RgtC+0LrQvtC70LAgRmFzdENH?= =?UTF-8?B?SSDQtNC70Y8gaGlnaCBsb2Fk?= In-Reply-To: References: <1676831.cuj3O2ObT0@vbart-workstation> Message-ID: вт, 6 нояб. 2018 г. в 16:25, kseleznyov : > Добрый день! > > Проблема такая. Мы используем библиотеку libfcgi. Она популярная, хорошо > про > тестированная и т.д. и т.п., но... она не поддерживает переиспользование > соединений. Может быть посоветуете другую библиотеку для c++? > > Если же использовать libfcgi, то поясню свой предыдущий вопрос. Допустим > nginx уже открыл N соединений FastCGI и по каждому из них уже > обрабатывается > FastCGI-запрос. Допустим приходит ещё один HTTP-запрос и у nginx есть три > пути: либо открывать ещё одно FastCGI-соединение для обработки нового > HTTP-запроса, либо откладывать этот HTTP-запрос (пока не отработает один из > N запросов), либо вообще возвращать ошибку. Как поступает nginx? Какие > настройки на это влияют? > как уже ответил Валентин - nginx будет пытаться оставить соединение в пуле, если а) вы сделали настройки (которые он показал) б) если бекенд его не закроет > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,281762,281797#msg-281797 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Tue Nov 6 12:52:19 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 06 Nov 2018 15:52:19 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdGC0YDQvtC50LrQsCDQv9GA0L7RgtC+0LrQvtC70LAgRmFzdENH?= =?UTF-8?B?SSDQtNC70Y8gaGlnaCBsb2Fk?= In-Reply-To: References: <1676831.cuj3O2ObT0@vbart-workstation> Message-ID: <3498969.yGKK7fscst@vbart-workstation> On Tuesday 06 November 2018 06:25:36 kseleznyov wrote: > Добрый день! > > Проблема такая. Мы используем библиотеку libfcgi. Она популярная, хорошо про > тестированная и т.д. и т.п., но... она не поддерживает переиспользование > соединений. Может быть посоветуете другую библиотеку для c++? > > Если же использовать libfcgi, то поясню свой предыдущий вопрос. Допустим > nginx уже открыл N соединений FastCGI и по каждому из них уже обрабатывается > FastCGI-запрос. Допустим приходит ещё один HTTP-запрос и у nginx есть три > пути: либо открывать ещё одно FastCGI-соединение для обработки нового > HTTP-запроса, либо откладывать этот HTTP-запрос (пока не отработает один из > N запросов), либо вообще возвращать ошибку. Как поступает nginx? Какие > настройки на это влияют? > 1. nginx по умолчанию _всегда_ открывает новое соединение. И это должно работать с libfcgi без проблем. 2. Если вы настроили keepalive (http://nginx.org/r/keepalive/ru), то при наличии свободного соединения (в котором не обрабатывается запрос) - будет использоваться это соединение, в противном случае открываться новое. 3. Если вы установили параметр max_conns у директивы server, то при превышении данного значения nginx будет пытаться выбрать другой сервер, а при неудаче - возвращать ошибку. 4. Откладывать nginx умеет только в коммерческой версии с помощью директивы queue (http://nginx.org/r/queue/ru). -- Валентин Бартенев From mdounin на mdounin.ru Tue Nov 6 15:27:32 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 6 Nov 2018 18:27:32 +0300 Subject: nginx-1.15.6 Message-ID: <20181106152732.GG56558@mdounin.ru> Изменения в nginx 1.15.6 06.11.2018 *) Безопасность: при использовании HTTP/2 клиент мог вызвать чрезмерное потреблению памяти (CVE-2018-16843) и ресурсов процессора (CVE-2018-16844). *) Безопасность: при обработке специально созданного mp4-файла модулем ngx_http_mp4_module содержимое памяти рабочего процесса могло быть отправлено клиенту (CVE-2018-16845). *) Добавление: директивы proxy_socket_keepalive, fastcgi_socket_keepalive, grpc_socket_keepalive, memcached_socket_keepalive, scgi_socket_keepalive и uwsgi_socket_keepalive. *) Исправление: если nginx был собран с OpenSSL 1.1.0, а использовался с OpenSSL 1.1.1, протокол TLS 1.3 всегда был разрешён. *) Исправление: при работе с gRPC-бэкендами могло расходоваться большое количество памяти. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Tue Nov 6 15:27:53 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 6 Nov 2018 18:27:53 +0300 Subject: nginx-1.14.1 Message-ID: <20181106152753.GK56558@mdounin.ru> Изменения в nginx 1.14.1 06.11.2018 *) Безопасность: при использовании HTTP/2 клиент мог вызвать чрезмерное потреблению памяти (CVE-2018-16843) и ресурсов процессора (CVE-2018-16844). *) Безопасность: при обработке специально созданного mp4-файла модулем ngx_http_mp4_module содержимое памяти рабочего процесса могло быть отправлено клиенту (CVE-2018-16845). *) Исправление: при работе с gRPC-бэкендами могло расходоваться большое количество памяти. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Tue Nov 6 15:28:19 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 6 Nov 2018 18:28:19 +0300 Subject: nginx security advisory (CVE-2018-16843, CVE-2018-16844) Message-ID: <20181106152819.GO56558@mdounin.ru> Hello! В реализации HTTP/2 в nginx были обнаружены две проблемы безопасности, которые могут преводить к чрезмерному потреблению памяти (CVE-2018-16843) и ресурсов процессора (CVE-2018-16844). Проблемам подвержен nginx, собранный с модулем ngx_http_v2_module (по умолчанию не собирается), если в конфигурационном файле используется параметр http2 директивы listen. Проблемам подвержен nginx 1.9.5 - 1.15.5. Проблемы исправлены в nginx 1.15.6, 1.14.1. Спасибо Gal Goldshtein из F5 Networks за исходное сообщение о проблеме с потреблением ресурсов процессора. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Tue Nov 6 15:28:40 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 6 Nov 2018 18:28:40 +0300 Subject: nginx security advisory (CVE-2018-16845) Message-ID: <20181106152840.GS56558@mdounin.ru> Hello! В модуле ngx_http_mp4_module была обнаружена ошибка, которая позволяет с помощью специально созданного mp4-файла вызвать бесконечный цикл в рабочем процессе, падение рабочего процесса, либо же могла приводить к отправке клиенту содержимого памяти рабочего процесса (CVE-2018-16845). Проблеме подвержен nginx, если он собран с модулем ngx_http_mp4_module (по умолчанию не собирается) и директива mp4 используется в конфигурационном файле. При этом атака возможна только в случае, если атакующий имеет возможность обеспечить обработку специально созданного mp4-файла с помощью модуля ngx_http_mp4_module. Проблеме подвержен nginx 1.1.3+, 1.0.7+. Проблема исправлена в 1.15.6, 1.14.1. Патч, исправляющий проблему, доступен тут: http://nginx.org/download/patch.2018.mp4.txt -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Tue Nov 6 17:00:56 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 6 Nov 2018 20:00:56 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LjQvtGA0LjRgtC40LfQuNGA0L7QstCw0YLRjCDRiNC4?= =?UTF-8?B?0YTRgNGLINC00LvRjyBUTFN2MS4zPw==?= In-Reply-To: <3ca3e1f4ad37a36533bea6736f0166e8.NginxMailingListRussian@forum.nginx.org> References: <93b752bb7e431b8a3a6524b2600efd3c.NginxMailingListRussian@forum.nginx.org> <3ca3e1f4ad37a36533bea6736f0166e8.NginxMailingListRussian@forum.nginx.org> Message-ID: <20181106170056.GV56558@mdounin.ru> Hello! On Mon, Nov 05, 2018 at 07:38:46AM -0500, I0Result wrote: > я смотрю openssl добавил другой параметр для сортировки шифров -ciphersuites > (https://www.openssl.org/docs/man1.1.1/man1/ciphers.html) > Если запускать команду, то шифры начинают приоритезироваться > openssl ciphers -ciphersuites > TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256 > -s -v EECDH+CHACHA20:EECDH+AESGCM | column -t > > TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any > Enc=CHACHA20/POLY1305(256) Mac=AEAD > TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) > Mac=AEAD > TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) > Mac=AEAD > ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA > Enc=CHACHA20/POLY1305(256) Mac=AEAD > ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA > Enc=CHACHA20/POLY1305(256) Mac=AEAD > ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) > Mac=AEAD > ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) > Mac=AEAD > ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) > Mac=AEAD > ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) > Mac=AEAD > > Как быть с настройками nignx? Напрямую через конфигурацию nginx настроить шифры для TLSv1.3 сейчас нельзя - подробнее почитать о том, почему так, можно тут: https://trac.nginx.org/nginx/ticket/1529 In short: в OpenSSL выпилили управление шифрами для TLSv1.3 из стандартного интерфейса, и непонятно, запилят ли обратно. Делать же отдельную директиву аналогично "-ciphersuites" крайне не хочется, ибо это выглядит как идиотизм чуть менее, чем полностью. Если очень хочется - сейчас шифры для TLSv1.3 можно задать через конфиг OpenSSL'я, openssl.conf. Как-то так: openssl_conf = default_conf [default_conf] ssl_conf = ssl_sect [ssl_sect] system_default = system_default_sect [system_default_sect] Ciphersuites = TLS_CHACHA20_POLY1305_SHA256 -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Nov 6 17:57:30 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 6 Nov 2018 20:57:30 +0300 Subject: =?UTF-8?B?UmU6IEJhc2ljQXV0aCDRgtC+0LvRjNC60L4g0YEg0L7Qv9GA0LXQtNC10LvQtdC9?= =?UTF-8?B?0L3Ri9GFIElQ?= In-Reply-To: <7e20b91347f363b7d06b970a56a3ee39.NginxMailingListRussian@forum.nginx.org> References: <7e20b91347f363b7d06b970a56a3ee39.NginxMailingListRussian@forum.nginx.org> Message-ID: <20181106175730.GX56558@mdounin.ru> Hello! On Tue, Nov 06, 2018 at 05:24:58AM -0500, inkognito0609 wrote: > Модуль ngx_http_access_module позволяет ограничить доступ для определённых > адресов клиентов. > ngx_http_auth_basic_module позволяет ограничить доступ к ресурсам с > проверкой имени и пароля. > > Можно ли реализовать проверку имени и пароля при условии входа с > определенных ip адресов?, если да то как? Есть директива satisfy, она позволяет произвольно комбинировать access (allow/deny) и auth_basic. Подробнее про неё рассказано в документации тут: http://nginx.org/ru/docs/http/ngx_http_core_module.html#satisfy Поведение по умолчанию - "satisfy all", то есть проверяются результаты как allow/deny, так и auth_basic. То есть для того, чтобы доступ был разрешён только с определённых IP-адресов, и при этом у пришедших с этих адресов спрашивалась авторизация, достаточно написать: allow 192.168.0.0/24; deny all; auth_basic "restricted site"; auth_basic_user_file /path/to/htpasswd; При этом nginx сначала проверит IP-адрес, и если доступ с этого IP-адреса запрещён - вернёт ошибку. Если же вдруг я неверно понял вопрос и на самом деле зачем-то хочется, чтобы доступ был разрешён всем, но с определённых IP-адресов - только с авторизацией, то можно использовать "satisfy any", и разрешить доступ от всех адресов, кроме тех, у которых нужно спрашивать авторизацию: satisfy any; deny 192.168.0.0/24; allow all; auth_basic "restricted site"; auth_basic_user_file /path/to/htpasswd; -- Maxim Dounin http://mdounin.ru/ From mail на knutov.com Wed Nov 7 00:59:13 2018 From: mail на knutov.com (Nick Knutov) Date: Wed, 7 Nov 2018 05:59:13 +0500 Subject: pipe to http Message-ID: Доброго времени суток, подскажите, как лучше реализовать такую задачу: запрос приходит к nginx, отправляется некоторому скрипту (uwsgi->perl), который проверяет авторизацию, и если всё ок, то необходимо запустить какой-то процесс, который отдаст много гигабайт данных в stdout и это надо отдать хттп-клиенту. Причем, важно, если клиент отвалился - процесс нужно убить. Сейчас я запускаю процесс скриптом и перекладываю его ответ дальше перловым скриптом, но он ест неприемлемо много проца и имеет непонятные проблемы с буферизацией и медленными клиентами. Нельзя ли в скрипте ограничиться чем-то вроде внутреннего редиректа и остальную работу сделать на уровне nginx? -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From nginx-forum на forum.nginx.org Wed Nov 7 04:16:58 2018 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Tue, 06 Nov 2018 23:16:58 -0500 Subject: =?UTF-8?B?UmU6IEJhc2ljQXV0aCDRgtC+0LvRjNC60L4g0YEg0L7Qv9GA0LXQtNC10LvQtdC9?= =?UTF-8?B?0L3Ri9GFIElQ?= In-Reply-To: <20181106175730.GX56558@mdounin.ru> References: <20181106175730.GX56558@mdounin.ru> Message-ID: Необходимо чтобы из внутренней сети доступ был без авторизации, из внешней сети для разрешенных определенных адресов запрашивался пароль Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281796,281846#msg-281846 From nginx-forum на forum.nginx.org Wed Nov 7 04:41:28 2018 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Tue, 06 Nov 2018 23:41:28 -0500 Subject: =?UTF-8?B?UmU6INC60LDQuiDQv9GA0LDQstC40LvRjNC90L4g0L/RgNC+0L/QuNGB0LDRgtGM?= =?UTF-8?B?INC/0YPRgtGMINC00L4g0YHRgtCw0YLQuNC60Lg=?= In-Reply-To: References: Message-ID: <6ae7ea7e07ce93d6bd054e0ae16ccb2c.NginxMailingListRussian@forum.nginx.org> в /srv/www/frontend/build/ лежит html файл в котором прописан путь до статики - /static/css/main.0a23196b.css Но при обработке-> location /restore { alias /srv/www/frontend/build/; rewrite ^/restore$ /restore/; Статику ищет с добавлением restore localhost/restore/static/css/main.0a23196b.css как убрать restore, так как планируется добавление новых location по данному шаблону? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281795,281847#msg-281847 From dmitriy на lyalyuev.info Wed Nov 7 07:07:59 2018 From: dmitriy на lyalyuev.info (Dmitriy Lyalyuev) Date: Wed, 7 Nov 2018 09:07:59 +0200 Subject: pipe to http In-Reply-To: References: Message-ID: <5B177178-6393-4218-B0D5-D1EFDDB96AC9@lyalyuev.info> X-Accel-Redirect похоже то, что вам нужно. -- With best regards, Dmitriy Lyalyuev dmitriy на lyalyuev.info > On Nov 7, 2018, at 02:59, Nick Knutov wrote: > > Доброго времени суток, > > подскажите, как лучше реализовать такую задачу: > > запрос приходит к nginx, отправляется некоторому скрипту (uwsgi->perl), который проверяет авторизацию, и если всё ок, то необходимо запустить какой-то процесс, который отдаст много гигабайт данных в stdout и это надо отдать хттп-клиенту. > > Причем, важно, если клиент отвалился - процесс нужно убить. > > Сейчас я запускаю процесс скриптом и перекладываю его ответ дальше перловым скриптом, но он ест неприемлемо много проца и имеет непонятные проблемы с буферизацией и медленными клиентами. Нельзя ли в скрипте ограничиться чем-то вроде внутреннего редиректа и остальную работу сделать на уровне nginx? > > -- > Best Regards, > Nick Knutov > http://knutov.com > ICQ: 272873706 > Voice: +7-904-84-23-130 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: ----------- следущая часть ----------- Вложение не в текстовом формате было извлечено… Имя: smime.p7s Тип: application/pkcs7-signature Размер: 3884 байтов Описание: отсутствует URL: From dmitriy на lyalyuev.info Wed Nov 7 07:08:48 2018 From: dmitriy на lyalyuev.info (Dmitriy Lyalyuev) Date: Wed, 7 Nov 2018 09:08:48 +0200 Subject: =?UTF-8?B?UmU6IEJhc2ljQXV0aCDRgtC+0LvRjNC60L4g0YEg0L7Qv9GA0LXQtNC10LvQtdC9?= =?UTF-8?B?0L3Ri9GFIElQ?= In-Reply-To: References: <20181106175730.GX56558@mdounin.ru> Message-ID: satisfy any; -- With best regards, Dmitriy Lyalyuev dmitriy на lyalyuev.info > On Nov 7, 2018, at 06:16, inkognito0609 wrote: > > Необходимо чтобы из внутренней сети доступ был без авторизации, из внешней > сети для разрешенных определенных адресов запрашивался пароль > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281796,281846#msg-281846 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: ----------- следущая часть ----------- Вложение не в текстовом формате было извлечено… Имя: smime.p7s Тип: application/pkcs7-signature Размер: 3884 байтов Описание: отсутствует URL: From nginx-forum на forum.nginx.org Wed Nov 7 12:19:34 2018 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Wed, 07 Nov 2018 07:19:34 -0500 Subject: =?UTF-8?B?UmU6INC60LDQuiDQv9GA0LDQstC40LvRjNC90L4g0L/RgNC+0L/QuNGB0LDRgtGM?= =?UTF-8?B?INC/0YPRgtGMINC00L4g0YHRgtCw0YLQuNC60Lg=?= In-Reply-To: <6ae7ea7e07ce93d6bd054e0ae16ccb2c.NginxMailingListRussian@forum.nginx.org> References: <6ae7ea7e07ce93d6bd054e0ae16ccb2c.NginxMailingListRussian@forum.nginx.org> Message-ID: Добавил отдельный location для статики, все работает location /static/ { alias /srv/www/frontend/build/static/; if env "CI_BUILD_TAG" expires 14d; add_header Cache-Control s-maxage=3600; end } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281795,281853#msg-281853 From nginx-forum на forum.nginx.org Wed Nov 7 12:34:18 2018 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Wed, 07 Nov 2018 07:34:18 -0500 Subject: =?UTF-8?B?0L7QtNC40L0gYWxpYXM=?= Message-ID: <6bb405864fd6b10584586115547b3f17.NginxMailingListRussian@forum.nginx.org> кейс такой: Основной проект лежит root /srv/www/app/web; Появился новый проект по url /restore, отдаем html по другому адресу location /restore { alias /srv/www/frontend/build/; В дальнейшем планируется n количество url, например /some для которого придется пилить свой и т.д. location /some { alias /srv/www/frontend/build/; Какие есть практики чтоб не кошмарить такой большой конф файл, со своим location для каждого будущего url. На ум приходит создать location в который вкладывать остальные.. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281855,281855#msg-281855 From ano на bestmx.net Wed Nov 7 12:49:26 2018 From: ano на bestmx.net (Andrey Oktyabrskiy) Date: Wed, 7 Nov 2018 15:49:26 +0300 Subject: =?UTF-8?B?UmU6INC+0LTQuNC9IGFsaWFz?= In-Reply-To: <6bb405864fd6b10584586115547b3f17.NginxMailingListRussian@forum.nginx.org> References: <6bb405864fd6b10584586115547b3f17.NginxMailingListRussian@forum.nginx.org> Message-ID: <2d0babc6-3048-2357-1eaa-ab609b2c8085@bestmx.net> On 07.11.2018 15:34, inkognito0609 wrote: > кейс такой: > Основной проект лежит > root /srv/www/app/web; > > Появился новый проект по url /restore, отдаем html по другому адресу > location /restore { > alias /srv/www/frontend/build/; > > В дальнейшем планируется n количество url, например /some для которого > придется пилить свой и т.д. > location /some { > alias /srv/www/frontend/build/; > > Какие есть практики чтоб не кошмарить такой большой конф файл, со своим > location для каждого будущего url. > На ум приходит создать location в который вкладывать остальные.. echo '/restore /srv/www/frontend/build /some /srv/www/frontend/build' \ |awk '{printf "location %s { alias %s; }\n", $1, $2}' \ >/path/to/nginx/conf/inc/project.inc include inc/project.inc From slw на zxy.spb.ru Wed Nov 7 13:07:43 2018 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Wed, 7 Nov 2018 16:07:43 +0300 Subject: =?UTF-8?B?UmU6INC+0LTQuNC9IGFsaWFz?= In-Reply-To: <6bb405864fd6b10584586115547b3f17.NginxMailingListRussian@forum.nginx.org> References: <6bb405864fd6b10584586115547b3f17.NginxMailingListRussian@forum.nginx.org> Message-ID: <20181107130743.GF1794@zxy.spb.ru> On Wed, Nov 07, 2018 at 07:34:18AM -0500, inkognito0609 wrote: > кейс такой: > Основной проект лежит > root /srv/www/app/web; > > Появился новый проект по url /restore, отдаем html по другому адресу > location /restore { > alias /srv/www/frontend/build/; > > В дальнейшем планируется n количество url, например /some для которого > придется пилить свой и т.д. > location /some { > alias /srv/www/frontend/build/; > > Какие есть практики чтоб не кошмарить такой большой конф файл, со своим > location для каждого будущего url. > На ум приходит создать location в который вкладывать остальные.. я сделал скрипт на lua и он из редиса достает мапинги From nginx-forum на forum.nginx.org Thu Nov 8 03:49:02 2018 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Wed, 07 Nov 2018 22:49:02 -0500 Subject: =?UTF-8?B?UmU6INC+0LTQuNC9IGFsaWFz?= In-Reply-To: <2d0babc6-3048-2357-1eaa-ab609b2c8085@bestmx.net> References: <2d0babc6-3048-2357-1eaa-ab609b2c8085@bestmx.net> Message-ID: <335764bf2401f035afa52697237d4a8d.NginxMailingListRussian@forum.nginx.org> Andrey Oktyabrskiy Wrote: ------------------------------------------------------- > On 07.11.2018 15:34, inkognito0609 wrote: > > кейс такой: > > Основной проект лежит > > root /srv/www/app/web; > > > > Появился новый проект по url /restore, отдаем html по другому адресу > > location /restore { > > alias /srv/www/frontend/build/; > > > > В дальнейшем планируется n количество url, например /some для > которого > > придется пилить свой и т.д. > > location /some { > > alias /srv/www/frontend/build/; > > > > Какие есть практики чтоб не кошмарить такой большой конф файл, со > своим > > location для каждого будущего url. > > На ум приходит создать location в который вкладывать остальные.. > echo '/restore /srv/www/frontend/build > /some /srv/www/frontend/build' \ > |awk '{printf "location %s { alias %s; }\n", $1, $2}' \ > >/path/to/nginx/conf/inc/project.inc > > include inc/project.inc > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Спасибо, но через include так же ручками придется добавлять новый и новый location Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281855,281867#msg-281867 From nginx-forum на forum.nginx.org Thu Nov 8 04:00:06 2018 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Wed, 07 Nov 2018 23:00:06 -0500 Subject: =?UTF-8?B?UmU6INC+0LTQuNC9IGFsaWFz?= In-Reply-To: <20181107130743.GF1794@zxy.spb.ru> References: <20181107130743.GF1794@zxy.spb.ru> Message-ID: <26dd944005a84e3ed20a61771574f54c.NginxMailingListRussian@forum.nginx.org> Slawa Olhovchenkov Wrote: ------------------------------------------------------- > On Wed, Nov 07, 2018 at 07:34:18AM -0500, inkognito0609 wrote: > > > кейс такой: > > Основной проект лежит > > root /srv/www/app/web; > > > > Появился новый проект по url /restore, отдаем html по другому адресу > > location /restore { > > alias /srv/www/frontend/build/; > > > > В дальнейшем планируется n количество url, например /some для > которого > > придется пилить свой и т.д. > > location /some { > > alias /srv/www/frontend/build/; > > > > Какие есть практики чтоб не кошмарить такой большой конф файл, со > своим > > location для каждого будущего url. > > На ум приходит создать location в который вкладывать остальные.. > > я сделал скрипт на lua и он из редиса достает мапинги > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru установка дополнительного софта не вариант, необходимо решить в рамках самого nginx Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281855,281868#msg-281868 From kulmaks на gmail.com Thu Nov 8 08:33:43 2018 From: kulmaks на gmail.com (Maksim Kulik) Date: Thu, 8 Nov 2018 11:33:43 +0300 Subject: =?UTF-8?B?UmU6INC+0LTQuNC9IGFsaWFz?= In-Reply-To: <26dd944005a84e3ed20a61771574f54c.NginxMailingListRussian@forum.nginx.org> References: <20181107130743.GF1794@zxy.spb.ru> <26dd944005a84e3ed20a61771574f54c.NginxMailingListRussian@forum.nginx.org> Message-ID: Может просто на уровне server прописать root /srv/www/frontend/build/, а для основного проекта прописать alias, либо root для location / ? Не проверял, но мне кажется, что должно работать. чт, 8 нояб. 2018 г. в 7:00, inkognito0609 : > Slawa Olhovchenkov Wrote: > ------------------------------------------------------- > > On Wed, Nov 07, 2018 at 07:34:18AM -0500, inkognito0609 wrote: > > > > > кейс такой: > > > Основной проект лежит > > > root /srv/www/app/web; > > > > > > Появился новый проект по url /restore, отдаем html по другому адресу > > > location /restore { > > > alias /srv/www/frontend/build/; > > > > > > В дальнейшем планируется n количество url, например /some для > > которого > > > придется пилить свой и т.д. > > > location /some { > > > alias /srv/www/frontend/build/; > > > > > > Какие есть практики чтоб не кошмарить такой большой конф файл, со > > своим > > > location для каждого будущего url. > > > На ум приходит создать location в который вкладывать остальные.. > > > > я сделал скрипт на lua и он из редиса достает мапинги > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > установка дополнительного софта не вариант, необходимо решить в рамках > самого nginx > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,281855,281868#msg-281868 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From s.bondarev на southbridge.ru Thu Nov 8 09:10:57 2018 From: s.bondarev на southbridge.ru (Sergey Bondarev) Date: Thu, 8 Nov 2018 12:10:57 +0300 Subject: =?UTF-8?B?0J7RgtC60LvRjtGH0LXQvdC40LUgU1NMLCDQtdGB0LvQuCDQvdC10YIg0YHQtdGA?= =?UTF-8?B?0YLQuNGE0LjQutCw0YLQvtCy?= Message-ID: <1787465997.20181108121057@southbridge.ru> Здравствуйте, Nginx-ru. При использовании сертификатов от letsencrypt, возникает проблема при первоначальном запуске. Как правило новые вирт. хосты с новыми доменами добавляются в уже существующий nginx, и на момент добавления у нас еще нет сертификатов. соответсвенно приходится сначала руками добавлять конфиг nginx без SSL, запускать cert-bot, для получения сертификата, менять конфиг nginx, добавляя туда listen ssl и сертификаты. Жизнеспособна ли такая идея ? Если при запуске nginx не находит сертификатов по тем путям, что есть в конфиге он пишет ворнинг, и генерирует самоподписанный сертификат, который и начинает использовать для обслуживания хоста. -- С уважением, Sergey mailto:s.bondarev на southbridge.ru From gmm на csdoc.com Thu Nov 8 10:16:33 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 8 Nov 2018 12:16:33 +0200 Subject: =?UTF-8?B?UmU6INCe0YLQutC70Y7Rh9C10L3QuNC1IFNTTCwg0LXRgdC70Lgg0L3QtdGCINGB?= =?UTF-8?B?0LXRgNGC0LjRhNC40LrQsNGC0L7Qsg==?= In-Reply-To: <1787465997.20181108121057@southbridge.ru> References: <1787465997.20181108121057@southbridge.ru> Message-ID: On 08.11.2018 11:10, Sergey Bondarev wrote: > При использовании сертификатов от letsencrypt, возникает проблема при > первоначальном запуске. > > Как правило новые вирт. хосты с новыми доменами добавляются в уже > существующий nginx, и на момент добавления у нас еще нет сертификатов. > > соответсвенно приходится сначала руками добавлять конфиг nginx без > SSL, запускать cert-bot, для получения сертификата, менять конфиг > nginx, добавляя туда listen ssl и сертификаты. Можно изначально генерировать конфиг для сайта с настройками для SSL, только закомментировать в конфиге директивы ssl_certificate и ssl_certificate_key, так тоже все будет работать. После того как certbot сгенерирует сертификат - достаточно будет только раскоментировать эти две директивы и сделать systemctl reload nginx - после этого сайт будет полностью рабочим. > Жизнеспособна ли такая идея ? Если при запуске nginx не находит > сертификатов по тем путям, что есть в конфиге он пишет ворнинг, и > генерирует самоподписанный сертификат, который и начинает использовать > для обслуживания хоста. Или просто пишет warning о том, что не удалось найти файлов на диске и ведет себя так, словно в конфиге для хоста нет директивы/директив ssl_certificate и/или ssl_certificate_key. -- Best regards, Gena From pavel2000 на ngs.ru Thu Nov 8 12:47:28 2018 From: pavel2000 на ngs.ru (Pavel) Date: Thu, 08 Nov 2018 19:47:28 +0700 Subject: =?UTF-8?B?UmU6INCe0YLQutC70Y7Rh9C10L3QuNC1IFNTTCwg0LXRgdC70Lgg0L3QtdGCINGB?= =?UTF-8?B?0LXRgNGC0LjRhNC40LrQsNGC0L7Qsg==?= In-Reply-To: <1787465997.20181108121057@southbridge.ru> References: <1787465997.20181108121057@southbridge.ru> Message-ID: On Thu, 8 Nov 2018 12:10:57 +0300 Sergey Bondarev wrote: > соответсвенно приходится сначала руками добавлять > конфиг nginx без SSL, запускать cert-bot Настройте конфиг таким образом, чтобы в хосте по-умолчанию отдавались правильные ответы на запросы проверки домена. > для получения сертификата, менять конфиг > nginx, добавляя туда listen ssl и сертификаты. После получения сертификата всёравно будет необходимо изменение конфига и reload. В моей конфигурации за один запуск скрипта получаются необходимые сертификаты (в частном случае, по списку из файла), затем производится модификация конфигов nginx (генератор генерирует опять же по тому же списку) и nginx reload. Всё это не требует никаких промежуточных самоподписанных автоматически формируемых сертификатов. > Жизнеспособна ли такая идея ? Если при запуске > nginx не находит сертификатов по тем путям, что есть в конфиге он > пишет ворнинг, и генерирует самоподписанный сертификат, который и > начинает использовать для обслуживания хоста. Описанная идея приведет к усложнению обнаружения ошибок и, как следствие, к хаосу. Я бы так делать не рекомендовал. Напишите себе правильные скрипты. From mdounin на mdounin.ru Thu Nov 8 12:57:23 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 8 Nov 2018 15:57:23 +0300 Subject: =?UTF-8?B?UmU6INCe0YLQutC70Y7Rh9C10L3QuNC1IFNTTCwg0LXRgdC70Lgg0L3QtdGCINGB?= =?UTF-8?B?0LXRgNGC0LjRhNC40LrQsNGC0L7Qsg==?= In-Reply-To: <1787465997.20181108121057@southbridge.ru> References: <1787465997.20181108121057@southbridge.ru> Message-ID: <20181108125723.GI56558@mdounin.ru> Hello! On Thu, Nov 08, 2018 at 12:10:57PM +0300, Sergey Bondarev wrote: > Здравствуйте, Nginx-ru. > > При использовании сертификатов от letsencrypt, возникает проблема при > первоначальном запуске. > > Как правило новые вирт. хосты с новыми доменами добавляются в уже > существующий nginx, и на момент добавления у нас еще нет сертификатов. > > соответсвенно приходится сначала руками добавлять конфиг nginx без > SSL, запускать cert-bot, для получения сертификата, менять конфиг > nginx, добавляя туда listen ssl и сертификаты. > > Жизнеспособна ли такая идея ? Если при запуске nginx не находит > сертификатов по тем путям, что есть в конфиге он пишет ворнинг, и > генерирует самоподписанный сертификат, который и начинает использовать > для обслуживания хоста. Мой (и не только мой) опыт говорит, что в большинстве случаев "сгенерировать, если не нашлось то, что указано в конфиге" - это стратегия, которая приводит к тому, что при каких-нибудь опечатках - оно таки сгенерируется и будет работать, а в том, почему оно работает неправильно - придётся отдельно и долго разбираться. Поэтому nginx требует, чтобы указанное в конфиге - существовало, а если оно не существует и/или некорректно - то отказывается применять такую конфигурацию. Это, в частности, отлично спасает от замены работающей конфигурации на неработающую при перезагрузке конфигурации. Если хочется не менять конфигурацию после исходного запуска certbot'а - то очевидным решением видится сгенерировать самоподписанный сертификат перед исходным запуском и положить его по указанному в конфиге пути. Когда certbot получит настоящий сертификат - он его обновит, и будет достаточно перезагрузить конфигурацию nginx'а для начала работы с новым сертификатом. Впрочем, лично я - предпочитаю явно менять конфигурацию. -- Maxim Dounin http://mdounin.ru/ From mail на knutov.com Fri Nov 9 02:29:39 2018 From: mail на knutov.com (Nick Knutov) Date: Fri, 9 Nov 2018 07:29:39 +0500 Subject: pipe to http In-Reply-To: <5B177178-6393-4218-B0D5-D1EFDDB96AC9@lyalyuev.info> References: <5B177178-6393-4218-B0D5-D1EFDDB96AC9@lyalyuev.info> Message-ID: <0240aa7c-c93e-d91f-4c17-d45fc3e82156@knutov.com> Очевидно, но nginx ведь не умеет сам ничего запускать. Попробовал fcgiwrap, но или я что-то делаю неправильно, или когда клиент отваливается - sigpipe до скрипта не доходит. 07.11.2018 12:07, Dmitriy Lyalyuev пишет: > X-Accel-Redirect похоже то, что вам нужно. > > -- > With best regards, > Dmitriy Lyalyuev > dmitriy на lyalyuev.info > > > >> On Nov 7, 2018, at 02:59, Nick Knutov > > wrote: >> >> Доброго времени суток, >> >> подскажите, как лучше реализовать такую задачу: >> >> запрос приходит к nginx, отправляется некоторому скрипту >> (uwsgi->perl), который проверяет авторизацию, и если всё ок, то >> необходимо запустить какой-то процесс, который отдаст много гигабайт >> данных в stdout и это надо отдать хттп-клиенту. >> >> Причем, важно, если клиент отвалился - процесс нужно убить. >> >> Сейчас я запускаю процесс скриптом и перекладываю его ответ дальше >> перловым скриптом, но он ест неприемлемо много проца и имеет >> непонятные проблемы с буферизацией и медленными клиентами. Нельзя ли >> в скрипте ограничиться чем-то вроде внутреннего редиректа и остальную >> работу сделать на уровне nginx? >> >> -- >> Best Regards, >> Nick Knutov >> http://knutov.com >> ICQ: 272873706 >> Voice: +7-904-84-23-130 >> >> _______________________________________________ >> 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 -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 -------------- next part -------------- An HTML attachment was scrubbed... URL: From coddoc на mail.ru Fri Nov 9 07:18:30 2018 From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=) Date: Fri, 09 Nov 2018 10:18:30 +0300 Subject: =?UTF-8?B?0KHRgtGA0LDQvdC90LDRjyDRgdC40YLRg9Cw0YbQuNGPINGBIGxldmVscw==?= Message-ID: <1541747910.744566099@f455.i.mail.ru> nginx-debug -v nginx version: nginx/1.15.6 Специально обновился, до этого была версия 1.13.12, там то же самое. Изменение levels в proxy_cache_path применяется только после полного рестарта (service nginx-debug restart) nginx-debug -s reload ожидаемого результата не дает Как воспроизвести: 1. В контексте http: proxy_cache_path /var/www/html/cache levels=1:2:1 use_temp_path=off keys_zone=testcache:5m inactive=10m max_size=50m; 2. service nginx-debug restart 3. В error.log: cache manager process exited with code 0 start cache manager process start cache loader process 4. Делаю запрос в локейшен, для которого активирована зона testcache 5. Получаю ожидаемое: /var/www/html/cache/3/05/8/e62d74fdc44e220f0225168323c28053 6. Удаляю ветку '3/05/8/e62d74fdc44e220f0225168323c28053' 7. Меняю levels 1:2:1 -> levels 1 8. nginx-debug -s reload 9. В error.log: cache "testcache" had previously different levels 10. Запрос в тот же локейшен дает тот же результат: /var/www/html/cache/3/05/8/e62d74fdc44e220f0225168323c28053 11. Опять удаляю '3/05/8/e62d74fdc44e220f0225168323c28053' 12. service nginx-debug restart 13. В error.log: cache manager process exited with code 0 start cache manager process start cache loader process 14. Запрос в тот же локейшен опять дает ожидаемое: /var/www/html/cache/3/e62d74fdc44e220f0225168323c28053 Если это нормальное поведение, может, имеет смысл как-то отметить в документации необходимость рестарта? Спасибо. -- ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Nov 9 09:04:43 2018 From: nginx-forum на forum.nginx.org (Set) Date: Fri, 09 Nov 2018 04:04:43 -0500 Subject: error_page 404 Message-ID: Добрый день. Коллеги, как заставить nginx игнорировать заголовки Cache-Control и Expires для 404 ответа. Делаю так: error_page 404 /error404.php; location = /error404.php { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_ignore_headers "Cache-Control" "Expires"; proxy_cache_valid 404 10m; proxy_cache cache; proxy_pass http://url; } Не работает. Что делаю не так? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281880,281880#msg-281880 From mdounin на mdounin.ru Fri Nov 9 13:33:59 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 9 Nov 2018 16:33:59 +0300 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdCw0Y8g0YHQuNGC0YPQsNGG0LjRjyDRgSBsZXZlbHM=?= In-Reply-To: <1541747910.744566099@f455.i.mail.ru> References: <1541747910.744566099@f455.i.mail.ru> Message-ID: <20181109133359.GC99070@mdounin.ru> Hello! On Fri, Nov 09, 2018 at 10:18:30AM +0300, CoDDoC wrote: > nginx-debug -v > nginx version: nginx/1.15.6 > > Специально обновился, до этого была версия 1.13.12, там то же самое. > Изменение levels в proxy_cache_path применяется только после полного рестарта (service nginx-debug restart) > nginx-debug -s reload ожидаемого результата не дает > > Как воспроизвести: > 1. В контексте http: > proxy_cache_path /var/www/html/cache levels=1:2:1 use_temp_path=off keys_zone=testcache:5m inactive=10m max_size=50m; > 2. service nginx-debug restart > 3. В error.log: > cache manager process exited with code 0 > start cache manager process > start cache loader process > 4. Делаю запрос в локейшен, для которого активирована зона testcache > 5. Получаю ожидаемое: > /var/www/html/cache/3/05/8/e62d74fdc44e220f0225168323c28053 > 6. Удаляю ветку '3/05/8/e62d74fdc44e220f0225168323c28053' > > 7. Меняю levels 1:2:1 -> levels 1 > 8. nginx-debug -s reload > 9. В error.log: > cache "testcache" had previously different levels > 10. Запрос в тот же локейшен дает тот же результат: > /var/www/html/cache/3/05/8/e62d74fdc44e220f0225168323c28053 > 11. Опять удаляю '3/05/8/e62d74fdc44e220f0225168323c28053' > 12. service nginx-debug restart > 13. В error.log: > cache manager process exited with code 0 > start cache manager process > start cache loader process > 14. Запрос в тот же локейшен опять дает ожидаемое: > /var/www/html/cache/3/e62d74fdc44e220f0225168323c28053 > > Если это нормальное поведение, может, имеет смысл как-то отметить в документации необходимость рестарта? Это нормальное поведение. Многие вещи, работа с которыми происходит через зоны разделяемой памяти из всех процессов, поменять без пересоздания зоны разделяемой памяти - нельзя. Наиболее банальный пример - нельзя поменять собственно размер зоны разделяемой памяти. В чуть более сложных случаях - нельзя менять параметры, которые меняют поведение рабочих процессов на несовместимое с другими рабочими процессами или с уже имеющейся в разделяемой памяти информацией. В частности, levels в кэше - определяют, в каком именно виде лежат данные на диске, и каким именно файлам на диске соответствуют элементы в разделяемой памяти. То есть поменять levels просто так нельзя - фактически, надо выкинуть из памяти всю информацию, которая становится негодной, и презагрузить содержимое кэша заново. Кроме того, всё ещё осложняется тем, что у нас есть старые рабочи процессы, которые могут работать неопределённо долго, и эти рабочие процессы предполагают старое значение levels, то есть если мы таки выкинем и перезагрузим содержимое разделяемой памяти - начнут вести себя некорретно они. Чтобы подобных проблем не возникало - при применении новой конфигурации nginx проверяет, что конфигурация совместима с тем, как использовались зоны разделяемой памяти ранее. И если обнаруживает, что попытались поменять что-то, что менять нельзя - логгирует соответствующую ошибку в error log, и откатывается к старой конфигурации. Если тем не менее хочется соответствующие параметры поменять, то это можно сделать одним из следующих способов: - Переименовать зону разделяемой памяти (в случае кэша - лучше при этом заодно задать новый путь), и использовать её в конфигурации с новыми параметрами. При таком изменении конфликтов между старой и новой конфигурацией не будет, можно будет сделать reload. И при этом сохранится содержимое остальных зон разделяемой памяти, конфигурацию которых не меняли. - Сделать binary upgrade. При этом все зоны разделяемой памяти будут созданы заново, однако потерь запросов не будет. - Ну и собственно сделать restart. Всё тоже заработает с новой конфигурацией, но смысла в этом приблизительно никакого - binary upgrade даст тот же результат, но без потери запросов. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Fri Nov 9 13:35:43 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 9 Nov 2018 16:35:43 +0300 Subject: error_page 404 In-Reply-To: References: Message-ID: <20181109133543.GD99070@mdounin.ru> Hello! On Fri, Nov 09, 2018 at 04:04:43AM -0500, Set wrote: > Добрый день. > > Коллеги, как заставить nginx игнорировать заголовки Cache-Control и Expires > для 404 ответа. > > Делаю так: > error_page 404 /error404.php; > location = /error404.php { > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For > $proxy_add_x_forwarded_for; > proxy_ignore_headers "Cache-Control" "Expires"; > proxy_cache_valid 404 10m; > proxy_cache cache; > proxy_pass http://url; > } > > Не работает. Что делаю не так? В чём заключается "не работает" и что именно возвращается в ответе? -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Fri Nov 9 14:11:45 2018 From: nginx-forum на forum.nginx.org (kseleznyov) Date: Fri, 09 Nov 2018 09:11:45 -0500 Subject: =?UTF-8?B?0JHQsNC70LDQvdGB0LjRgNC+0LLQutCwINC90LDQs9GA0YPQt9C60Lgg0L/RgNC4?= =?UTF-8?B?INC90LXQtNC+0YHRgtGD0L/QvdC+0YHRgtC4IGJhY2tlbmQ=?= Message-ID: <8453807bd995760f4eb296dfb71bc77e.NginxMailingListRussian@forum.nginx.org> Ситуация такая: слушаем порт 80 и перекидываем запрос с него на порты 8080 и 8081. За каждым из этих портов стоит FCGI-бекэнд. Примерный файл конфигурации: # настройка upstream - делаем балансировку на два разных порта upstream http_stream { server 127.0.0.1:8080; server 127.0.0.1:8081; } # основная точка входа, нагрузка на которую балансируется между портами 8080 и 8081 server { listen 80 default_server; listen [::]:80 default_server; location / { proxy_pass http://http_stream; } } # первый бекэнд - пробрасываем на FCGI по Unix Socket server { listen 8080 default_server; listen [::]:8080 default_server; server_name _; location / { fastcgi_pass unix:/home/skostik/sockets/1.sock; } } # второй бекэнд - пробрасываем на FCGI по Unix Socket server { listen 8081 default_server; listen [::]:8081 default_server; server_name _; location / { fastcgi_pass unix:/home/skostik/sockets/2.sock; } } Проблема: если бекэнд не отвечает по сокету unix:/home/skostik/sockets/1.sock (т.е. nginx не может установить соединение), то nginx не делает балансировку (не перекидывает запрос на порт 8081), а возвращает ошибку. Можно ли настроить систему так, чтобы: если один бекэнд недоступен, то нужно слать исходный HTTP-запрос на другой порт. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281886,281886#msg-281886 From mdounin на mdounin.ru Fri Nov 9 14:42:58 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 9 Nov 2018 17:42:58 +0300 Subject: =?UTF-8?B?UmU6INCR0LDQu9Cw0L3RgdC40YDQvtCy0LrQsCDQvdCw0LPRgNGD0LfQutC4INC/?= =?UTF-8?B?0YDQuCDQvdC10LTQvtGB0YLRg9C/0L3QvtGB0YLQuCBiYWNrZW5k?= In-Reply-To: <8453807bd995760f4eb296dfb71bc77e.NginxMailingListRussian@forum.nginx.org> References: <8453807bd995760f4eb296dfb71bc77e.NginxMailingListRussian@forum.nginx.org> Message-ID: <20181109144258.GF99070@mdounin.ru> Hello! On Fri, Nov 09, 2018 at 09:11:45AM -0500, kseleznyov wrote: > Ситуация такая: слушаем порт 80 и перекидываем запрос с него на порты 8080 и > 8081. За каждым из этих портов стоит FCGI-бекэнд. Примерный файл > конфигурации: > > > # настройка upstream - делаем балансировку на два разных порта > upstream http_stream { > server 127.0.0.1:8080; > server 127.0.0.1:8081; > } > > # основная точка входа, нагрузка на которую балансируется между портами 8080 > и 8081 > server { > listen 80 default_server; > listen [::]:80 default_server; > location / { > proxy_pass http://http_stream; > } > } > > # первый бекэнд - пробрасываем на FCGI по Unix Socket > server { > listen 8080 default_server; > listen [::]:8080 default_server; > > server_name _; > > location / { > fastcgi_pass unix:/home/skostik/sockets/1.sock; > } > } > > # второй бекэнд - пробрасываем на FCGI по Unix Socket > server { > listen 8081 default_server; > listen [::]:8081 default_server; > > server_name _; > > location / { > fastcgi_pass unix:/home/skostik/sockets/2.sock; > } > } > > > Проблема: если бекэнд не отвечает по сокету > unix:/home/skostik/sockets/1.sock (т.е. nginx не может установить > соединение), то nginx не делает балансировку (не перекидывает запрос на порт > 8081), а возвращает ошибку. Можно ли настроить систему так, чтобы: если один > бекэнд недоступен, то нужно слать исходный HTTP-запрос на другой порт. А зачем в этой конструкции "бэкенды", которые не делают ничего полезного? Добавьте оба unix-сокета в один upstream и сделайте на него fastcgi_pass прямо из основного сервера - и всё будет работать без дополнительных настроек. Если очень хочется, чтобы nginx видел ошибки работы с fastcgi-бэкендами именно в такой конструкции - то вам нужно в proxy_next_upstream добавить http_502 и http_504, подробнее в документации тут: http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_next_upstream -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Fri Nov 9 17:40:54 2018 From: nginx-forum на forum.nginx.org (actionmanager) Date: Fri, 09 Nov 2018 12:40:54 -0500 Subject: FreeBSD 11.1-RELEASE-p4 - nginx/1.15.6 accept4() ERR#35 'Resource temporarily unavailable' Message-ID: Здравствуйте, FreeBSD 11.1-RELEASE-p4 Связка nginx + phpfpm nginx version: nginx/1.15.6 built by clang 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) built with OpenSSL 1.0.2k-freebsd 26 Jan 2017 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_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gzip_static_module --with-http_gunzip_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_stub_status_module --with-http_sub_module --with-pcre --with-http_v2_module --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --with-mail=dynamic --without-mail_imap_module --without-mail_pop3_module --without-mail_smtp_module --with-http_ssl_module --with-http_geoip_module=dynamic --add-module=/root/ngx_brotli решил проверить процесс nginx через truss truss -p PID Наблюдаю множество записей: kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 1.021000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 1.013000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.987000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.980000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.973000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.962000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.933000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.875000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.871000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.805000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 203,EVFILT_READ,EV_CLEAR|EV_EOF,0x0,0x0,0x84ec02be0 },512,{ 0.711000000 }) = 1 (0x1) close(203) = 0 (0x0) kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.703000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 15,EVFILT_READ,0x0,0x0,0x1,0x84ec00000 },512,{ 0.687000000 }) = 1 (0x1) accept4(0xf,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 15,EVFILT_READ,0x0,0x0,0x1,0x84ec00000 },512,{ 0.653000000 }) = 1 (0x1) accept4(0xf,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 213,EVFILT_READ,EV_CLEAR,0x0,0x23e,0x84ec02f20 },512,{ 0.645000000 }) = 1 (0x1) read(213,"\^V\^C\^C\^B\^F\^P\0\^B\^B\^B\0{"...,33093) = 574 (0x23e) getpid() = 76503 (0x12ad7) write(213,"\^T\^C\^C\0\^A\^A\^V\^C\^C\0("...,51) = 51 (0x33) read(213,0x8049e84c3,33093) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.632000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 213,EVFILT_READ,EV_CLEAR,0x0,0x278,0x84ec02f20 },512,{ 0.593000000 }) = 1 (0x1) read(213,"\^W\^C\^C\^Bs\0\0\0\0\0\0\0\^A"...,33093) = 632 (0x278) read(213,0x8049e84c3,33093) ERR#35 'Resource temporarily unavailable' openat(AT_FDCWD,"/var/tmp/nginx/cache/1/19/fabbe70058e6eb7798a4535817eef191",O_RDONLY|O_NONBLOCK,00) = 93 (0x5d) fstat(93,{ mode=-rw------- ,inode=707517,size=98306,blksize=98816 }) = 0 (0x0) pread(0x5d,0x8046f0040,0x10000,0x0) = 65536 (0x10000) pread(0x5d,0x804827780,0x8000,0x2a8) = 32768 (0x8000) pread(0x5d,0x804827780,0x8000,0x82a8) = 32768 (0x8000) pread(0x5d,0x804827780,0x7d5a,0x102a8) = 32090 (0x7d5a) write(213,"\^W\^C\^C)\^R\M--Yq'\M-e\^O#jW"...,10519) = 10519 (0x2917) close(93) = 0 (0x0) kevent(80,{ 213,EVFILT_WRITE,EV_ADD|EV_ENABLE|EV_CLEAR,0x0,0x0,0x850c02f20 },1,{ 213,EVFILT_WRITE,EV_CLEAR,0x0,0x1dac5,0x850c02f20 },512,{ 0.535000000 }) = 1 (0x1) kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.532000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 213,EVFILT_WRITE,EV_CLEAR,0x0,0x20199,0x850c02f20 },512,{ 0.490000000 }) = 1 (0x1) kevent(80,{ },0,{ 213,EVFILT_WRITE,EV_CLEAR,0x0,0x203dc,0x850c02f20 },512,{ 0.475000000 }) = 1 (0x1) kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.475000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.450000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.407000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.394000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.359000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.330000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.322000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.318000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.258000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 15,EVFILT_READ,0x0,0x0,0x1,0x84ec00000 },512,{ 0.194000000 }) = 1 (0x1) accept4(0xf,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.191000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.140000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.106000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.080000000 }) = 1 (0x1) accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource temporarily unavailable' kevent(80,{ },0,{ },512,{ 0.060000000 }) = 0 (0x0) close(162) = 0 (0x0) Это нормальное поведение ? ERR#35 'Resource temporarily unavailable' или что-то не так ? Сайт открывается отлично, никаких сбоев не наблюдаю. Пытаюсь понять что это за ошибки и с чем они могут быть связаны. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281893,281893#msg-281893 From coddoc на mail.ru Sat Nov 10 13:27:35 2018 From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=) Date: Sat, 10 Nov 2018 16:27:35 +0300 Subject: =?UTF-8?B?UmVbMl06INCh0YLRgNCw0L3QvdCw0Y8g0YHQuNGC0YPQsNGG0LjRjyDRgSBsZXZl?= =?UTF-8?B?bHM=?= In-Reply-To: <20181109133359.GC99070@mdounin.ru> References: <1541747910.744566099@f455.i.mail.ru> <20181109133359.GC99070@mdounin.ru> Message-ID: <1541856455.748946613@f514.i.mail.ru> Да, спасибо. До переименования зоны я уже догадался. Но не сразу заметил. Экспериментировал с довольно сложным SSI, пришлось часто заглядывать в кэш, многоуровневый оказался неудобен, переключил в один уровень, вот только тогда. Потом уже полез в дебаг. Себе в шпаргалку на заметку. Но все-таки, неплохо было бы сказать в доке о рестарте (ИМХО). >Пятница, 9 ноября 2018, 16:34 +03:00 от Maxim Dounin : > >Hello! > >On Fri, Nov 09, 2018 at 10:18:30AM +0300, CoDDoC wrote: > >> nginx-debug -v >> nginx version: nginx/1.15.6 >> >> Специально обновился, до этого была версия 1.13.12, там то же самое. >> Изменение levels в proxy_cache_path применяется только после полного рестарта (service nginx-debug restart) >> nginx-debug -s reload ожидаемого результата не дает >> >> Как воспроизвести: >> 1. В контексте http: >> proxy_cache_path /var/www/html/cache levels=1:2:1 use_temp_path=off keys_zone=testcache:5m inactive=10m max_size=50m; >> 2. service nginx-debug restart >> 3. В error.log: >> cache manager process exited with code 0 >> start cache manager process >> start cache loader process >> 4. Делаю запрос в локейшен, для которого активирована зона testcache >> 5. Получаю ожидаемое: >> /var/www/html/cache/3/05/8/e62d74fdc44e220f0225168323c28053 >> 6. Удаляю ветку '3/05/8/e62d74fdc44e220f0225168323c28053' >> >> 7. Меняю levels 1:2:1 -> levels 1 >> 8. nginx-debug -s reload >> 9. В error.log: >> cache "testcache" had previously different levels >> 10. Запрос в тот же локейшен дает тот же результат: >> /var/www/html/cache/3/05/8/e62d74fdc44e220f0225168323c28053 >> 11. Опять удаляю '3/05/8/e62d74fdc44e220f0225168323c28053' >> 12. service nginx-debug restart >> 13. В error.log: >> cache manager process exited with code 0 >> start cache manager process >> start cache loader process >> 14. Запрос в тот же локейшен опять дает ожидаемое: >> /var/www/html/cache/3/e62d74fdc44e220f0225168323c28053 >> >> Если это нормальное поведение, может, имеет смысл как-то отметить в документации необходимость рестарта? > >Это нормальное поведение. > >Многие вещи, работа с которыми происходит через зоны разделяемой >памяти из всех процессов, поменять без пересоздания зоны >разделяемой памяти - нельзя. Наиболее банальный пример - нельзя >поменять собственно размер зоны разделяемой памяти. > >В чуть более сложных случаях - нельзя менять параметры, которые >меняют поведение рабочих процессов на несовместимое с другими >рабочими процессами или с уже имеющейся в разделяемой памяти >информацией. В частности, levels в кэше - определяют, в каком >именно виде лежат данные на диске, и каким именно файлам на диске >соответствуют элементы в разделяемой памяти. То есть поменять >levels просто так нельзя - фактически, надо выкинуть из памяти всю >информацию, которая становится негодной, и презагрузить содержимое >кэша заново. Кроме того, всё ещё осложняется тем, что у нас есть >старые рабочи процессы, которые могут работать неопределённо >долго, и эти рабочие процессы предполагают старое значение levels, то >есть если мы таки выкинем и перезагрузим содержимое разделяемой >памяти - начнут вести себя некорретно они. > >Чтобы подобных проблем не возникало - при применении новой >конфигурации nginx проверяет, что конфигурация совместима с тем, >как использовались зоны разделяемой памяти ранее. И если >обнаруживает, что попытались поменять что-то, что менять нельзя - >логгирует соответствующую ошибку в error log, и откатывается к >старой конфигурации. > >Если тем не менее хочется соответствующие параметры поменять, то >это можно сделать одним из следующих способов: > >- Переименовать зону разделяемой памяти (в случае кэша - лучше >  при этом заодно задать новый путь), и использовать её в >  конфигурации с новыми параметрами. При таком изменении >  конфликтов между старой и новой конфигурацией не будет, можно >  будет сделать reload. И при этом сохранится содержимое >  остальных зон разделяемой памяти, конфигурацию которых не меняли. > >- Сделать binary upgrade. При этом все зоны разделяемой памяти будут >  созданы заново, однако потерь запросов не будет. > >- Ну и собственно сделать restart. Всё тоже заработает с новой >  конфигурацией, но смысла в этом приблизительно никакого - binary >  upgrade даст тот же результат, но без потери запросов. > >-- >Maxim Dounin >http://mdounin.ru/ >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -- ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From pavel.odintsov на gmail.com Sun Nov 11 21:22:34 2018 From: pavel.odintsov на gmail.com (Pavel Odintsov) Date: Sun, 11 Nov 2018 21:22:34 +0000 Subject: =?UTF-8?B?0JHQuNC90LDRgNC90YvQtSDQv9Cw0LrQtdGC0Ysg0L/QvtC0IEFSTTY0INC00Ls=?= =?UTF-8?B?0Y8gVWJ1bnR1IDE4LjA0?= Message-ID: Добрый день! Успешно использовали ARM64 билды Nginx на Ubuntu 16.04, но после апгрейда на 18.04 неожиданно заметили, что пакетов для новых версий нету. И правда, согласно http://nginx.org/en/linux_packages.html пакетов Nginx для ARM64 под Ubuntu 18.04 не заявлено. Отсутствие пакетов http://nginx.org/packages/ubuntu/dists/bionic/ для ARM64 это, собственно, подтверждает. В связи с чем вопрос, есть ли планы их добавить? Спасибо! -- Sincerely yours, Pavel Odintsov ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From iippolitov на nginx.com Mon Nov 12 09:33:26 2018 From: iippolitov на nginx.com (Igor A. Ippolitov) Date: Mon, 12 Nov 2018 12:33:26 +0300 Subject: FreeBSD 11.1-RELEASE-p4 - nginx/1.15.6 accept4() ERR#35 'Resource temporarily unavailable' In-Reply-To: References: Message-ID: <7278e508-2a81-889f-4800-5e4644bf9c91@nginx.com> Добрый день. Отдельно любопытно, зачем вы решили проверить процесс, если всё работает. Насколько я понимаю, сокет в неблокирующем режиме, процесс пытается принять соединение и не успевает этого сделать (принимает другой процесс). Процесс получает "ошибку", которая говорит процессу, что он опоздал. Всё хорошо, можно ничего не трогать. On 09.11.2018 20:40, actionmanager wrote: > Здравствуйте, > > FreeBSD 11.1-RELEASE-p4 > > Связка nginx + phpfpm > > nginx version: nginx/1.15.6 > built by clang 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) > built with OpenSSL 1.0.2k-freebsd 26 Jan 2017 > 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_addition_module > --with-http_auth_request_module --with-http_dav_module > --with-http_flv_module --with-http_gzip_static_module > --with-http_gunzip_module --with-http_mp4_module > --with-http_random_index_module --with-http_realip_module > --with-http_secure_link_module --with-http_slice_module > --with-http_stub_status_module --with-http_sub_module --with-pcre > --with-http_v2_module --with-stream=dynamic --with-stream_ssl_module > --with-stream_ssl_preread_module --with-threads --with-mail=dynamic > --without-mail_imap_module --without-mail_pop3_module > --without-mail_smtp_module --with-http_ssl_module > --with-http_geoip_module=dynamic --add-module=/root/ngx_brotli > > > решил проверить процесс nginx через truss > > truss -p PID > > Наблюдаю множество записей: > > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 1.021000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 1.013000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.987000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.980000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.973000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.962000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.933000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.875000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.871000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.805000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 203,EVFILT_READ,EV_CLEAR|EV_EOF,0x0,0x0,0x84ec02be0 > },512,{ 0.711000000 }) = 1 (0x1) > close(203) = 0 (0x0) > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.703000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 15,EVFILT_READ,0x0,0x0,0x1,0x84ec00000 },512,{ 0.687000000 > }) = 1 (0x1) > accept4(0xf,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 15,EVFILT_READ,0x0,0x0,0x1,0x84ec00000 },512,{ 0.653000000 > }) = 1 (0x1) > accept4(0xf,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 213,EVFILT_READ,EV_CLEAR,0x0,0x23e,0x84ec02f20 },512,{ > 0.645000000 }) = 1 (0x1) > read(213,"\^V\^C\^C\^B\^F\^P\0\^B\^B\^B\0{"...,33093) = 574 (0x23e) > getpid() = 76503 (0x12ad7) > write(213,"\^T\^C\^C\0\^A\^A\^V\^C\^C\0("...,51) = 51 (0x33) > read(213,0x8049e84c3,33093) ERR#35 'Resource temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.632000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 213,EVFILT_READ,EV_CLEAR,0x0,0x278,0x84ec02f20 },512,{ > 0.593000000 }) = 1 (0x1) > read(213,"\^W\^C\^C\^Bs\0\0\0\0\0\0\0\^A"...,33093) = 632 (0x278) > read(213,0x8049e84c3,33093) ERR#35 'Resource temporarily unavailable' > openat(AT_FDCWD,"/var/tmp/nginx/cache/1/19/fabbe70058e6eb7798a4535817eef191",O_RDONLY|O_NONBLOCK,00) > = 93 (0x5d) > fstat(93,{ mode=-rw------- ,inode=707517,size=98306,blksize=98816 }) = 0 > (0x0) > pread(0x5d,0x8046f0040,0x10000,0x0) = 65536 (0x10000) > pread(0x5d,0x804827780,0x8000,0x2a8) = 32768 (0x8000) > pread(0x5d,0x804827780,0x8000,0x82a8) = 32768 (0x8000) > pread(0x5d,0x804827780,0x7d5a,0x102a8) = 32090 (0x7d5a) > write(213,"\^W\^C\^C)\^R\M--Yq'\M-e\^O#jW"...,10519) = 10519 (0x2917) > close(93) = 0 (0x0) > kevent(80,{ 213,EVFILT_WRITE,EV_ADD|EV_ENABLE|EV_CLEAR,0x0,0x0,0x850c02f20 > },1,{ 213,EVFILT_WRITE,EV_CLEAR,0x0,0x1dac5,0x850c02f20 },512,{ 0.535000000 > }) = 1 (0x1) > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.532000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 213,EVFILT_WRITE,EV_CLEAR,0x0,0x20199,0x850c02f20 },512,{ > 0.490000000 }) = 1 (0x1) > kevent(80,{ },0,{ 213,EVFILT_WRITE,EV_CLEAR,0x0,0x203dc,0x850c02f20 },512,{ > 0.475000000 }) = 1 (0x1) > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.475000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.450000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.407000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.394000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.359000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.330000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.322000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.318000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.258000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 15,EVFILT_READ,0x0,0x0,0x1,0x84ec00000 },512,{ 0.194000000 > }) = 1 (0x1) > accept4(0xf,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.191000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.140000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.106000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ 16,EVFILT_READ,0x0,0x0,0x1,0x84ec00068 },512,{ 0.080000000 > }) = 1 (0x1) > accept4(0x10,0x7fffffffe7c0,0x7fffffffe854,0x20000000) ERR#35 'Resource > temporarily unavailable' > kevent(80,{ },0,{ },512,{ 0.060000000 }) = 0 (0x0) > close(162) = 0 (0x0) > > > Это нормальное поведение ? ERR#35 'Resource temporarily unavailable' или > что-то не так ? > Сайт открывается отлично, никаких сбоев не наблюдаю. Пытаюсь понять что это > за ошибки и с чем они могут быть связаны. > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281893,281893#msg-281893 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From thresh на nginx.com Mon Nov 12 16:39:00 2018 From: thresh на nginx.com (Konstantin Pavlov) Date: Mon, 12 Nov 2018 19:39:00 +0300 Subject: =?UTF-8?B?UmU6INCR0LjQvdCw0YDQvdGL0LUg0L/QsNC60LXRgtGLINC/0L7QtCBBUk02NCA=?= =?UTF-8?B?0LTQu9GPIFVidW50dSAxOC4wNA==?= In-Reply-To: References: Message-ID: Здравствуйте, 12.11.2018 0:22, Pavel Odintsov wrote: > Добрый день! > > Успешно использовали ARM64 билды Nginx на Ubuntu 16.04, но после > апгрейда на 18.04 неожиданно заметили, что пакетов для новых версий нету. > > И правда, согласно http://nginx.org/en/linux_packages.html пакетов Nginx > для ARM64 под Ubuntu 18.04 не заявлено. Отсутствие > пакетов http://nginx.org/packages/ubuntu/dists/bionic/ для ARM64 это, > собственно, подтверждает.  > > В связи с чем вопрос, есть ли планы их добавить? Добавим. Прямых запросов на сборки для 18.04 на ARM64 до Вас не было, так что нам будет необходимо подготовить инфраструктуру сборки. Каких-то конкретных сроков пока пообещать не могу, постараемся побыстрее. Если не секрет, для чего Вы используете наши пакеты на этой довольно экзотической архитектуре? Меняете или используете as-is? Спасибо, -- Konstantin Pavlov https://www.nginx.com/ From chipitsine на gmail.com Mon Nov 12 16:47:09 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 12 Nov 2018 21:47:09 +0500 Subject: =?UTF-8?B?UmU6INCR0LjQvdCw0YDQvdGL0LUg0L/QsNC60LXRgtGLINC/0L7QtCBBUk02NCA=?= =?UTF-8?B?0LTQu9GPIFVidW50dSAxOC4wNA==?= In-Reply-To: References: Message-ID: пн, 12 нояб. 2018 г. в 21:45, Konstantin Pavlov : > Здравствуйте, > > 12.11.2018 0:22, Pavel Odintsov wrote: > > Добрый день! > > > > Успешно использовали ARM64 билды Nginx на Ubuntu 16.04, но после > > апгрейда на 18.04 неожиданно заметили, что пакетов для новых версий нету. > > > > И правда, согласно http://nginx.org/en/linux_packages.html пакетов Nginx > > для ARM64 под Ubuntu 18.04 не заявлено. Отсутствие > > пакетов http://nginx.org/packages/ubuntu/dists/bionic/ для ARM64 это, > > собственно, подтверждает. > > > > В связи с чем вопрос, есть ли планы их добавить? > > Добавим. Прямых запросов на сборки для 18.04 на ARM64 до Вас не было, > так что нам будет необходимо подготовить инфраструктуру сборки. > на AppVeyor есть образы ARM64 > Каких-то конкретных сроков пока пообещать не могу, постараемся побыстрее. > > Если не секрет, для чего Вы используете наши пакеты на этой довольно > экзотической архитектуре? Меняете или используете as-is? > > Спасибо, > > -- > Konstantin Pavlov > https://www.nginx.com/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx на mva.name Mon Nov 12 18:28:52 2018 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Tue, 13 Nov 2018 01:28:52 +0700 Subject: =?UTF-8?B?UmU6INCR0LjQvdCw0YDQvdGL0LUg0L/QsNC60LXRgtGLINC/0L7QtCBBUk02NCA=?= =?UTF-8?B?0LTQu9GPIFVidW50dSAxOC4wNA==?= In-Reply-To: References: Message-ID: <8663192.mKZlNA4VNi@note> > Если не секрет, для чего Вы используете наши пакеты на этой довольно > экзотической архитектуре? Меняете или используете as-is? На самом деле, не такая уж она и экзотическая. У меня, например, более десятка армоборд и иных всевозможных девайсов на данной архитектуре. И практически на всех (самосборный) NgX. From pavel.odintsov на gmail.com Mon Nov 12 21:38:18 2018 From: pavel.odintsov на gmail.com (Pavel Odintsov) Date: Mon, 12 Nov 2018 21:38:18 +0000 Subject: =?UTF-8?B?UmU6INCR0LjQvdCw0YDQvdGL0LUg0L/QsNC60LXRgtGLINC/0L7QtCBBUk02NCA=?= =?UTF-8?B?0LTQu9GPIFVidW50dSAxOC4wNA==?= In-Reply-To: References: Message-ID: Добрый день! Update: добавил рассылку в копию Спасибо за ответ! Будем ждать пакетов :) Да, как и сказали выше, не сказать, что сильно экзотичная архитектура. У нас есть довольно большое число различных плат на данной архитектуре, в основном небольшие SBC с 2-4 ядрами 4GB памяти. Сейчас используем Nginx из Ubuntu 18.04, но для consistency мы предпочитаем использовать именно Ваши сборки, чтобы на всех версиях ОС держать идентичные версии Nginx. Задача, которую решаем довольно обычная - легкий веб сервер / роутер API. Какое-то время назад также тестировали Cavium Thunder от https://www.worksonarm.com/ с 96 ядрами, уже довольно серьезное железо под серьезную нагрузку (в отличие от платок, на которых довольно сложно что-то серьезное бывает запустить) Спасибо! On Mon, Nov 12, 2018 at 4:39 PM Konstantin Pavlov wrote: > Здравствуйте, > > 12.11.2018 0:22, Pavel Odintsov wrote: > > Добрый день! > > > > Успешно использовали ARM64 билды Nginx на Ubuntu 16.04, но после > > апгрейда на 18.04 неожиданно заметили, что пакетов для новых версий нету. > > > > И правда, согласно http://nginx.org/en/linux_packages.html пакетов Nginx > > для ARM64 под Ubuntu 18.04 не заявлено. Отсутствие > > пакетов http://nginx.org/packages/ubuntu/dists/bionic/ для ARM64 это, > > собственно, подтверждает. > > > > В связи с чем вопрос, есть ли планы их добавить? > > Добавим. Прямых запросов на сборки для 18.04 на ARM64 до Вас не было, > так что нам будет необходимо подготовить инфраструктуру сборки. > Каких-то конкретных сроков пока пообещать не могу, постараемся побыстрее. > > Если не секрет, для чего Вы используете наши пакеты на этой довольно > экзотической архитектуре? Меняете или используете as-is? > > Спасибо, > > -- > Konstantin Pavlov > https://www.nginx.com/ > -- Sincerely yours, Pavel Odintsov ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From annulen на yandex.ru Tue Nov 13 15:10:09 2018 From: annulen на yandex.ru (Konstantin Tokarev) Date: Tue, 13 Nov 2018 18:10:09 +0300 Subject: pipe to http In-Reply-To: References: Message-ID: <8479611542121809@sas2-9bd6ba081e5d.qloud-c.yandex.net> 07.11.2018, 03:59, "Nick Knutov" : > Доброго времени суток, > > подскажите, как лучше реализовать такую задачу: > > запрос приходит к nginx, отправляется некоторому скрипту (uwsgi->perl), > который проверяет авторизацию, и если всё ок, то необходимо запустить > какой-то процесс, который отдаст много гигабайт данных в stdout и это > надо отдать хттп-клиенту. > > Причем, важно, если клиент отвалился - процесс нужно убить. > > Сейчас я запускаю процесс скриптом и перекладываю его ответ дальше > перловым скриптом, но он ест неприемлемо много проца и имеет непонятные > проблемы с буферизацией и медленными клиентами. Эта задача не для nginx, а для скрипта, который должен после проверки форкнуться и запустить нужный процесс с имеющимся клиентским tcp сокетом в качестве stdout -- Regards, Konstantin From annulen на yandex.ru Tue Nov 13 15:45:22 2018 From: annulen на yandex.ru (Konstantin Tokarev) Date: Tue, 13 Nov 2018 18:45:22 +0300 Subject: pipe to http In-Reply-To: <8479611542121809@sas2-9bd6ba081e5d.qloud-c.yandex.net> References: <8479611542121809@sas2-9bd6ba081e5d.qloud-c.yandex.net> Message-ID: <21611891542123922@myt4-bf1cdac1d2eb.qloud-c.yandex.net> 13.11.2018, 18:10, "Konstantin Tokarev" : > 07.11.2018, 03:59, "Nick Knutov" : >>  Доброго времени суток, >> >>  подскажите, как лучше реализовать такую задачу: >> >>  запрос приходит к nginx, отправляется некоторому скрипту (uwsgi->perl), >>  который проверяет авторизацию, и если всё ок, то необходимо запустить >>  какой-то процесс, который отдаст много гигабайт данных в stdout и это >>  надо отдать хттп-клиенту. >> >>  Причем, важно, если клиент отвалился - процесс нужно убить. >> >>  Сейчас я запускаю процесс скриптом и перекладываю его ответ дальше >>  перловым скриптом, но он ест неприемлемо много проца и имеет непонятные >>  проблемы с буферизацией и медленными клиентами. > > Эта задача не для nginx, а для скрипта, который должен после проверки форкнуться > и запустить нужный процесс с имеющимся клиентским tcp сокетом в качестве stdout Хотя в принципе можно и через CGI реализовать, сделав редирект на отдельный локейшен где прикрутить [1] либо пасс на другой веб-сервер умеющий в CGI [1] Где-то был скрипт для встроенного перла, реализующий поддержку CGI в nginx, но с ходу найти не получилось > > -- > Regards, > Konstantin > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From kpoxa на kpoxa.net Tue Nov 13 17:23:03 2018 From: kpoxa на kpoxa.net (kpoxa) Date: Tue, 13 Nov 2018 20:23:03 +0300 Subject: =?UTF-8?B?0J/RgNC+0LvQsNCz0LjQstCw0L3QuNC1INC60L7QvdC90LXQutGC0L7QsiDQv9GA?= =?UTF-8?B?0Lgg0L/RgNC+0LLQtdGA0LrQtSDRgdC40L3RgtCw0LrRgdC40YHQsA==?= Message-ID: Добрый день. Есть сервер (Dual Xeon E5620, средняя нагрузка проца в праймтайм 20%) с nginx в главной и по сути единственной роли, задача которого проксирование и больше ничего. В конфиге 101 listen на уникальные ip:port, nginx без сторонних модулей. 1.15.4, но думаю что версия тут не при чем. Debian Linux Jessy с ядром 3.16. В среднем одновременных коннектов открыто 150-200 тыс. 70% из них по 443 порту. в логе собирается время отвремя апстрима и было замечено, то раз в 30 секунд оно пролагивает у части коннектов на лишнюю секунду, т.е. обычно 0.01, а тут 1.01 сек. Выяснилось что раз в 30 секунд срабатывает проверка конфига заббиксом, т.е. вызывается nginx -t Ручной вызов nginx -t привел к появлению в логах лагающих запросов в это время, выключение аббикс агента такие запросы убирает вообще. команда time nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful real 0m0.601s user 0m0.044s sys 0m0.432s показывает 0.4 с лишним секунды в режиме ядра. а попытка разобраться чем же занято ядра выдало ниже следующее strace -Ttt nginx -t 2>&1 | grep bind т.е. bind на 443 порты занимает 15 тысячных секунды, против стотысячных долей у прочих биндов. Есть ли идеи, как решить проблему пролагиваний при проверке конфига? Вариант убрать её из заббикса считаю академически неправильным, просьба его не рассматривать. reuseport не используется, может он помочь? 20:06:08.293194 bind(57, {sa_family=AF_INET, sin_port=htons(515), sin_addr=inet_addr("192.168.72.55")}, 16) = -1 EADDRINUSE (Address already in use) <0.000013> 20:06:08.293372 bind(57, {sa_family=AF_INET, sin_port=htons(8186), sin_addr=inet_addr("192.168.72.149")}, 16) = -1 EADDRINUSE (Address already in use) <0.000012> 20:06:08.293560 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.208")}, 16) = -1 EADDRINUSE (Address already in use) <0.016715> 20:06:08.310458 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.149")}, 16) = -1 EADDRINUSE (Address already in use) <0.015673> 20:06:08.326346 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.148")}, 16) = -1 EADDRINUSE (Address already in use) <0.015727> 20:06:08.342292 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.214")}, 16) = -1 EADDRINUSE (Address already in use) <0.015751> 20:06:08.358260 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.235")}, 16) = -1 EADDRINUSE (Address already in use) <0.015733> 20:06:08.374236 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.230")}, 16) = -1 EADDRINUSE (Address already in use) <0.015803> 20:06:08.390575 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.217")}, 16) = -1 EADDRINUSE (Address already in use) <0.016433> 20:06:08.407377 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.213")}, 16) = -1 EADDRINUSE (Address already in use) <0.016389> 20:06:08.423989 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.229")}, 16) = -1 EADDRINUSE (Address already in use) <0.015756> 20:06:08.440013 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.239")}, 16) = -1 EADDRINUSE (Address already in use) <0.015815> 20:06:08.456204 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.219")}, 16) = -1 EADDRINUSE (Address already in use) <0.014685> 20:06:08.471140 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.212")}, 16) = -1 EADDRINUSE (Address already in use) <0.016018> 20:06:08.487397 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.228")}, 16) = -1 EADDRINUSE (Address already in use) <0.014647> 20:06:08.502250 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.222")}, 16) = -1 EADDRINUSE (Address already in use) <0.014635> 20:06:08.517105 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.238")}, 16) = -1 EADDRINUSE (Address already in use) <0.014834> 20:06:08.532162 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.220")}, 16) = -1 EADDRINUSE (Address already in use) <0.014635> 20:06:08.547049 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.236")}, 16) = -1 EADDRINUSE (Address already in use) <0.014566> 20:06:08.561946 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.221")}, 16) = -1 EADDRINUSE (Address already in use) <0.015155> 20:06:08.577406 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.237")}, 16) = -1 EADDRINUSE (Address already in use) <0.014706> 20:06:08.592334 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.210")}, 16) = -1 EADDRINUSE (Address already in use) <0.014753> 20:06:08.607351 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.226")}, 16) = -1 EADDRINUSE (Address already in use) <0.014676> 20:06:08.622244 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.209")}, 16) = -1 EADDRINUSE (Address already in use) <0.014591> 20:06:08.637050 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.225")}, 16) = -1 EADDRINUSE (Address already in use) <0.014654> 20:06:08.651926 bind(57, {sa_family=AF_INET, sin_port=htons(2843), sin_addr=inet_addr("192.168.72.149")}, 16) = -1 EADDRINUSE (Address already in use) <0.000015> 20:06:08.652115 bind(57, {sa_family=AF_INET, sin_port=htons(2080), sin_addr=inet_addr("192.168.72.149")}, 16) = -1 EADDRINUSE (Address already in use) <0.000010> 20:06:08.652284 bind(57, {sa_family=AF_INET, sin_port=htons(2080), sin_addr=inet_addr("192.168.72.148")}, 16) = -1 EADDRINUSE (Address already in use) <0.000009> 20:06:08.652444 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.214")}, 16) = -1 EADDRINUSE (Address already in use) <0.000044> 20:06:08.652645 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.235")}, 16) = -1 EADDRINUSE (Address already in use) <0.000016> 20:06:08.652834 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.230")}, 16) = -1 EADDRINUSE (Address already in use) <0.000026> 20:06:08.653012 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.217")}, 16) = -1 EADDRINUSE (Address already in use) <0.000018> 20:06:08.653175 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.213")}, 16) = -1 EADDRINUSE (Address already in use) <0.000015> 20:06:08.653336 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.229")}, 16) = -1 EADDRINUSE (Address already in use) <0.000014> 20:06:08.653522 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.212")}, 16) = -1 EADDRINUSE (Address already in use) <0.000026> 20:06:08.653762 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.228")}, 16) = -1 EADDRINUSE (Address already in use) <0.000070> 20:06:08.654010 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.220")}, 16) = -1 EADDRINUSE (Address already in use) <0.000022> 20:06:08.654203 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.236")}, 16) = -1 EADDRINUSE (Address already in use) <0.000033> 20:06:08.654403 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.221")}, 16) = -1 EADDRINUSE (Address already in use) <0.000021> 20:06:08.654604 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.237")}, 16) = -1 EADDRINUSE (Address already in use) <0.000016> 20:06:08.654766 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.210")}, 16) = -1 EADDRINUSE (Address already in use) <0.000014> 20:06:08.654915 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.226")}, 16) = -1 EADDRINUSE (Address already in use) <0.000013> 20:06:08.655060 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.209")}, 16) = -1 EADDRINUSE (Address already in use) <0.000013> 20:06:08.655223 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.225")}, 16) = -1 EADDRINUSE (Address already in use) <0.000027> 20:06:08.655405 bind(57, {sa_family=AF_INET, sin_port=htons(62002), sin_addr=inet_addr("192.168.72.214")}, 16) = -1 EADDRINUSE (Address already in use) <0.000011> 20:06:08.655574 bind(57, {sa_family=AF_INET, sin_port=htons(62003), sin_addr=inet_addr("192.168.72.214")}, 16) = -1 EADDRINUSE (Address already in use) <0.000009> 20:06:08.655726 bind(57, {sa_family=AF_INET, sin_port=htons(843), sin_addr=inet_addr("192.168.72.224")}, 16) = -1 EADDRINUSE (Address already in use) <0.000394> 20:06:08.656262 bind(57, {sa_family=AF_INET, sin_port=htons(843), sin_addr=inet_addr("192.168.72.211")}, 16) = -1 EADDRINUSE (Address already in use) <0.000100> 20:06:08.656506 bind(57, {sa_family=AF_INET, sin_port=htons(843), sin_addr=inet_addr("192.168.72.208")}, 16) = -1 EADDRINUSE (Address already in use) <0.000100> 20:06:08.656748 bind(57, {sa_family=AF_INET, sin_port=htons(843), sin_addr=inet_addr("192.168.72.234")}, 16) = -1 EADDRINUSE (Address already in use) <0.000100> 20:06:08.656988 bind(57, {sa_family=AF_INET, sin_port=htons(843), sin_addr=inet_addr("192.168.72.231")}, 16) = -1 EADDRINUSE (Address already in use) <0.000105> 20:06:08.657239 bind(57, {sa_family=AF_INET, sin_port=htons(843), sin_addr=inet_addr("192.168.72.227")}, 16) = -1 EADDRINUSE (Address already in use) <0.000101> 20:06:08.657483 bind(57, {sa_family=AF_INET, sin_port=htons(843), sin_addr=inet_addr("192.168.72.223")}, 16) = -1 EADDRINUSE (Address already in use) <0.000116> 20:06:08.657810 bind(57, {sa_family=AF_INET, sin_port=htons(843), sin_addr=inet_addr("192.168.72.218")}, 16) = -1 EADDRINUSE (Address already in use) <0.000132> 20:06:08.658155 bind(57, {sa_family=AF_INET, sin_port=htons(843), sin_addr=inet_addr("192.168.72.219")}, 16) = -1 EADDRINUSE (Address already in use) <0.000131> 20:06:08.658494 bind(57, {sa_family=AF_INET, sin_port=htons(843), sin_addr=inet_addr("192.168.72.221")}, 16) = -1 EADDRINUSE (Address already in use) <0.000134> 20:06:08.658903 bind(57, {sa_family=AF_INET, sin_port=htons(843), sin_addr=inet_addr("192.168.72.237")}, 16) = -1 EADDRINUSE (Address already in use) <0.000184> 20:06:08.659339 bind(57, {sa_family=AF_INET, sin_port=htons(8161), sin_addr=inet_addr("192.168.72.230")}, 16) = -1 EADDRINUSE (Address already in use) <0.000018> 20:06:08.659580 bind(57, {sa_family=AF_INET, sin_port=htons(8162), sin_addr=inet_addr("192.168.72.230")}, 16) = -1 EADDRINUSE (Address already in use) <0.000013> 20:06:08.659815 bind(57, {sa_family=AF_INET, sin_port=htons(8188), sin_addr=inet_addr("192.168.72.212")}, 16) = -1 EADDRINUSE (Address already in use) <0.000029> 20:06:08.660066 bind(57, {sa_family=AF_INET, sin_port=htons(8188), sin_addr=inet_addr("192.168.72.228")}, 16) = -1 EADDRINUSE (Address already in use) <0.000014> 20:06:08.660253 bind(57, {sa_family=AF_INET, sin_port=htons(8189), sin_addr=inet_addr("192.168.72.212")}, 16) = -1 EADDRINUSE (Address already in use) <0.000012> 20:06:08.660435 bind(57, {sa_family=AF_INET, sin_port=htons(8189), sin_addr=inet_addr("192.168.72.228")}, 16) = -1 EADDRINUSE (Address already in use) <0.000010> 20:06:08.660622 bind(57, {sa_family=AF_INET, sin_port=htons(2003), sin_addr=inet_addr("192.168.72.220")}, 16) = -1 EADDRINUSE (Address already in use) <0.000013> 20:06:08.660799 bind(57, {sa_family=AF_INET, sin_port=htons(2003), sin_addr=inet_addr("192.168.72.236")}, 16) = -1 EADDRINUSE (Address already in use) <0.000010> 20:06:08.660980 bind(57, {sa_family=AF_INET, sin_port=htons(2003), sin_addr=inet_addr("192.168.72.221")}, 16) = -1 EADDRINUSE (Address already in use) <0.000015> 20:06:08.661200 bind(57, {sa_family=AF_INET, sin_port=htons(2003), sin_addr=inet_addr("192.168.72.237")}, 16) = -1 EADDRINUSE (Address already in use) <0.000011> 20:06:08.661399 bind(57, {sa_family=AF_INET, sin_port=htons(2003), sin_addr=inet_addr("192.168.72.210")}, 16) = -1 EADDRINUSE (Address already in use) <0.000014> 20:06:08.661606 bind(57, {sa_family=AF_INET, sin_port=htons(2003), sin_addr=inet_addr("192.168.72.226")}, 16) = -1 EADDRINUSE (Address already in use) <0.000009> 20:06:08.661773 bind(57, {sa_family=AF_INET, sin_port=htons(2003), sin_addr=inet_addr("192.168.72.209")}, 16) = -1 EADDRINUSE (Address already in use) <0.000009> 20:06:08.661938 bind(57, {sa_family=AF_INET, sin_port=htons(2003), sin_addr=inet_addr("192.168.72.225")}, 16) = -1 EADDRINUSE (Address already in use) <0.000010> 20:06:08.662102 bind(57, {sa_family=AF_INET, sin_port=htons(22443), sin_addr=inet_addr("192.168.72.221")}, 16) = -1 EADDRINUSE (Address already in use) <0.000010> 20:06:08.662330 bind(57, {sa_family=AF_INET, sin_port=htons(22443), sin_addr=inet_addr("192.168.72.237")}, 16) = -1 EADDRINUSE (Address already in use) <0.000009> 20:06:08.662497 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.133")}, 16) = -1 EADDRINUSE (Address already in use) <0.000027> 20:06:08.662681 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.146")}, 16) = -1 EADDRINUSE (Address already in use) <0.000018> 20:06:08.662871 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.211")}, 16) = -1 EADDRINUSE (Address already in use) <0.000026> 20:06:08.663061 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.55")}, 16) = -1 EADDRINUSE (Address already in use) <0.000024> 20:06:08.663243 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.216")}, 16) = -1 EADDRINUSE (Address already in use) <0.000018> 20:06:08.663479 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.143")}, 16) = -1 EADDRINUSE (Address already in use) <0.000017> 20:06:08.663665 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.233")}, 16) = -1 EADDRINUSE (Address already in use) <0.000018> 20:06:08.663839 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.142")}, 16) = -1 EADDRINUSE (Address already in use) <0.000017> 20:06:08.664053 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("10.13.177.64")}, 16) = -1 EADDRINUSE (Address already in use) <0.000017> 20:06:08.664230 bind(57, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.72.135")}, 16) = -1 EADDRINUSE (Address already in use) <0.000016> 20:06:08.664403 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.133")}, 16) = -1 EADDRINUSE (Address already in use) <0.016182> 20:06:08.680876 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.146")}, 16) = -1 EADDRINUSE (Address already in use) <0.016322> 20:06:08.697446 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.211")}, 16) = -1 EADDRINUSE (Address already in use) <0.014816> 20:06:08.712585 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.55")}, 16) = -1 EADDRINUSE (Address already in use) <0.016207> 20:06:08.729253 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.216")}, 16) = -1 EADDRINUSE (Address already in use) <0.014857> 20:06:08.744430 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.143")}, 16) = -1 EADDRINUSE (Address already in use) <0.015272> 20:06:08.760014 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.233")}, 16) = -1 EADDRINUSE (Address already in use) <0.015102> 20:06:08.775590 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.142")}, 16) = -1 EADDRINUSE (Address already in use) <0.015129> 20:06:08.791125 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.57")}, 16) = -1 EADDRINUSE (Address already in use) <0.015431> 20:06:08.806845 bind(57, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.72.135")}, 16) = -1 EADDRINUSE (Address already in use) <0.016197> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Tue Nov 13 18:58:22 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 13 Nov 2018 21:58:22 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtC70LDQs9C40LLQsNC90LjQtSDQutC+0L3QvdC10LrRgtC+0LIg?= =?UTF-8?B?0L/RgNC4INC/0YDQvtCy0LXRgNC60LUg0YHQuNC90YLQsNC60YHQuNGB0LA=?= In-Reply-To: References: Message-ID: <20181113185822.GQ99070@mdounin.ru> Hello! On Tue, Nov 13, 2018 at 08:23:03PM +0300, kpoxa wrote: > Добрый день. > > Есть сервер (Dual Xeon E5620, средняя нагрузка проца в праймтайм 20%) с > nginx в главной и по сути единственной роли, задача которого проксирование > и больше ничего. > > В конфиге 101 listen на уникальные ip:port, nginx без сторонних модулей. > 1.15.4, но думаю что версия тут не при чем. > Debian Linux Jessy с ядром 3.16. > > В среднем одновременных коннектов открыто 150-200 тыс. 70% из них по 443 > порту. > в логе собирается время отвремя апстрима и было замечено, то раз в 30 > секунд оно пролагивает у части коннектов на лишнюю секунду, т.е. обычно > 0.01, а тут 1.01 сек. > Выяснилось что раз в 30 секунд срабатывает проверка конфига заббиксом, т.е. > вызывается > nginx -t > > Ручной вызов nginx -t привел к появлению в логах лагающих запросов в это > время, выключение аббикс агента такие запросы убирает вообще. > команда > time nginx -t > nginx: the configuration file /etc/nginx/nginx.conf syntax is ok > nginx: configuration file /etc/nginx/nginx.conf test is successful > real 0m0.601s > user 0m0.044s > sys 0m0.432s > показывает 0.4 с лишним секунды в режиме ядра. > а попытка разобраться чем же занято ядра выдало ниже следующее > > strace -Ttt nginx -t 2>&1 | grep bind > > т.е. bind на 443 порты занимает 15 тысячных секунды, против стотысячных > долей у прочих биндов. > > Есть ли идеи, как решить проблему пролагиваний при проверке конфига? > Вариант убрать её из заббикса считаю академически неправильным, просьба его > не рассматривать. > > reuseport не используется, может он помочь? Из общих соображений я бы скорее предположил, что reuseport в данной ситуации сделает хуже, а не лучше. Потому что сокетов станет только больше, а bind() должен проверить конфликты с открытыми сокетами. Очевидное решение - добавить listen на *:443, тогда listen-сокет будет один, и проблема исчезнет. Впрочем, запускать "nginx -t" раз в 30 секунд - это, скажем так, очень странное решение, если не сказать грубее. Особенно с учётом того, что только парсинг конфигурации вполне может занимать несколько минут. -- Maxim Dounin http://mdounin.ru/ From vbart на nginx.com Tue Nov 13 19:46:59 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 13 Nov 2018 22:46:59 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtC70LDQs9C40LLQsNC90LjQtSDQutC+0L3QvdC10LrRgtC+0LIg?= =?UTF-8?B?0L/RgNC4INC/0YDQvtCy0LXRgNC60LUg0YHQuNC90YLQsNC60YHQuNGB0LA=?= In-Reply-To: References: Message-ID: <4160214.QVMnBEVJre@vbart-workstation> On Tuesday 13 November 2018 20:23:03 kpoxa wrote: [..] > Есть ли идеи, как решить проблему пролагиваний при проверке конфига? > Вариант убрать её из заббикса считаю академически неправильным, просьба его > не рассматривать. [..] А в чем академическая правильность заключается? Какую задачу это решает? -- Валентин Бартенев From chipitsine на gmail.com Tue Nov 13 19:53:42 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 14 Nov 2018 00:53:42 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC70LDQs9C40LLQsNC90LjQtSDQutC+0L3QvdC10LrRgtC+0LIg?= =?UTF-8?B?0L/RgNC4INC/0YDQvtCy0LXRgNC60LUg0YHQuNC90YLQsNC60YHQuNGB0LA=?= In-Reply-To: <4160214.QVMnBEVJre@vbart-workstation> References: <4160214.QVMnBEVJre@vbart-workstation> Message-ID: ср, 14 нояб. 2018 г. в 0:47, Валентин Бартенев : > On Tuesday 13 November 2018 20:23:03 kpoxa wrote: > [..] > > Есть ли идеи, как решить проблему пролагиваний при проверке конфига? > > Вариант убрать её из заббикса считаю академически неправильным, просьба > его > > не рассматривать. > [..] > > А в чем академическая правильность заключается? Какую задачу это решает? > например, у вас есть блок server, про который все забыли, и который проксируется на бекенд, заданный в виде днс имени. если бекенд удалили, то он перестанет ресолвиться, и reload зафейлится. о таких сюрпризах можно узнавать при помощи "nginx -t" другое дело, что делать это раз в 30 сек весьма странно. но допустим, мы делаем раз в сутки. это ведь не странно ? > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From kpoxa на kpoxa.net Wed Nov 14 08:45:03 2018 From: kpoxa на kpoxa.net (kpoxa) Date: Wed, 14 Nov 2018 11:45:03 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtC70LDQs9C40LLQsNC90LjQtSDQutC+0L3QvdC10LrRgtC+0LIg?= =?UTF-8?B?0L/RgNC4INC/0YDQvtCy0LXRgNC60LUg0YHQuNC90YLQsNC60YHQuNGB0LA=?= In-Reply-To: <20181113185822.GQ99070@mdounin.ru> References: <20181113185822.GQ99070@mdounin.ru> Message-ID: Сокеты в основном в stream, поэтому их агрегировать не получится, как я понимаю, с http то проблем нет. Парзинг конфига занимает около секунды, а вот знание того, что получился невалидный конфиг очень помогает избежать простоев. Основная проблема в долгом syscall bind, который долгий при определенных обстоятельствах. И почему он долгий не понятно. в strace видно время вызовов и видно, что для бинда по 443 порту оно в сотни раз дольше, чем для других портов. вт, 13 нояб. 2018 г. в 21:58, Maxim Dounin : > Hello! > > On Tue, Nov 13, 2018 at 08:23:03PM +0300, kpoxa wrote: > > > Добрый день. > > > > Есть сервер (Dual Xeon E5620, средняя нагрузка проца в праймтайм 20%) с > > nginx в главной и по сути единственной роли, задача которого > проксирование > > и больше ничего. > > > > В конфиге 101 listen на уникальные ip:port, nginx без сторонних модулей. > > 1.15.4, но думаю что версия тут не при чем. > > Debian Linux Jessy с ядром 3.16. > > > > В среднем одновременных коннектов открыто 150-200 тыс. 70% из них по 443 > > порту. > > в логе собирается время отвремя апстрима и было замечено, то раз в 30 > > секунд оно пролагивает у части коннектов на лишнюю секунду, т.е. обычно > > 0.01, а тут 1.01 сек. > > Выяснилось что раз в 30 секунд срабатывает проверка конфига заббиксом, > т.е. > > вызывается > > nginx -t > > > > Ручной вызов nginx -t привел к появлению в логах лагающих запросов в это > > время, выключение аббикс агента такие запросы убирает вообще. > > команда > > time nginx -t > > nginx: the configuration file /etc/nginx/nginx.conf syntax is ok > > nginx: configuration file /etc/nginx/nginx.conf test is successful > > real 0m0.601s > > user 0m0.044s > > sys 0m0.432s > > показывает 0.4 с лишним секунды в режиме ядра. > > а попытка разобраться чем же занято ядра выдало ниже следующее > > > > strace -Ttt nginx -t 2>&1 | grep bind > > > > т.е. bind на 443 порты занимает 15 тысячных секунды, против стотысячных > > долей у прочих биндов. > > > > Есть ли идеи, как решить проблему пролагиваний при проверке конфига? > > Вариант убрать её из заббикса считаю академически неправильным, просьба > его > > не рассматривать. > > > > reuseport не используется, может он помочь? > > Из общих соображений я бы скорее предположил, что reuseport в > данной ситуации сделает хуже, а не лучше. Потому что сокетов > станет только больше, а bind() должен проверить конфликты с > открытыми сокетами. > > Очевидное решение - добавить listen на *:443, тогда listen-сокет > будет один, и проблема исчезнет. > > Впрочем, запускать "nginx -t" раз в 30 секунд - это, скажем так, > очень странное решение, если не сказать грубее. Особенно с учётом > того, что только парсинг конфигурации вполне может занимать > несколько минут. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Wed Nov 14 12:59:10 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Nov 2018 15:59:10 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtC70LDQs9C40LLQsNC90LjQtSDQutC+0L3QvdC10LrRgtC+0LIg?= =?UTF-8?B?0L/RgNC4INC/0YDQvtCy0LXRgNC60LUg0YHQuNC90YLQsNC60YHQuNGB0LA=?= In-Reply-To: References: <20181113185822.GQ99070@mdounin.ru> Message-ID: <20181114125910.GT99070@mdounin.ru> Hello! On Wed, Nov 14, 2018 at 11:45:03AM +0300, kpoxa wrote: > Сокеты в основном в stream, поэтому их агрегировать не получится, как я > понимаю, с http то проблем нет. При наличии в конфиге listen-сокетов на wildcard-адресе и на конкретном ip-адресе - nginx будет использовать общий listen-сокет на wildcard-адресе, иначе на Linux'е просто нельзя работать. Это работает как для http, так и для stream/mail. Проблемы будут, только если один и тот же порт пытаться использовать в разных модулях. > Парзинг конфига занимает около секунды, а вот знание того, что получился > невалидный конфиг очень помогает избежать простоев. При перезагрузке конфигурации в случае ошибок nginx откатывается на старую конфигурацию, так что простой даже при невалидной конфиге - возможен только в случае, если сервер в таком состоянии перезагрузили, либо же зачем-то вместо reload'а сделали restart. > Основная проблема в долгом syscall bind, который долгий при определенных > обстоятельствах. И почему он долгий не понятно. > в strace видно время вызовов и видно, что для бинда по 443 порту оно в > сотни раз дольше, чем для других портов. Как раз почему он долгий - вполне понятно. В ядре делается обход всех сокетов на 443 порту, чтобы узнать, можно ли сделать bind() на этот сокет, или открыты какие-то конфликтующие сокеты. Соответственно, где сокетов больше - там syscall дольше. -- Maxim Dounin http://mdounin.ru/ From kpoxa на kpoxa.net Wed Nov 14 14:11:01 2018 From: kpoxa на kpoxa.net (kpoxa) Date: Wed, 14 Nov 2018 17:11:01 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtC70LDQs9C40LLQsNC90LjQtSDQutC+0L3QvdC10LrRgtC+0LIg?= =?UTF-8?B?0L/RgNC4INC/0YDQvtCy0LXRgNC60LUg0YHQuNC90YLQsNC60YHQuNGB0LA=?= In-Reply-To: <20181114125910.GT99070@mdounin.ru> References: <20181113185822.GQ99070@mdounin.ru> <20181114125910.GT99070@mdounin.ru> Message-ID: Я правильно понимаю, что можно сделать один listen 443 в специально сделанном сайте, который по другому никак не будет использоваться, а во всех остальных местах, и в HTTP и в стримах оставить listen ip:443 и все будет работать? ср, 14 нояб. 2018 г. в 15:59, Maxim Dounin : > Hello! > > On Wed, Nov 14, 2018 at 11:45:03AM +0300, kpoxa wrote: > > > Сокеты в основном в stream, поэтому их агрегировать не получится, как я > > понимаю, с http то проблем нет. > > При наличии в конфиге listen-сокетов на wildcard-адресе и на > конкретном ip-адресе - nginx будет использовать общий listen-сокет > на wildcard-адресе, иначе на Linux'е просто нельзя работать. Это > работает как для http, так и для stream/mail. Проблемы будут, > только если один и тот же порт пытаться использовать в разных > модулях. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx на mva.name Thu Nov 15 05:22:56 2018 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Thu, 15 Nov 2018 12:22:56 +0700 Subject: =?UTF-8?B?UmU6INCf0YDQvtC70LDQs9C40LLQsNC90LjQtSDQutC+0L3QvdC10LrRgtC+0LIg?= =?UTF-8?B?0L/RgNC4INC/0YDQvtCy0LXRgNC60LUg0YHQuNC90YLQsNC60YHQuNGB0LA=?= In-Reply-To: References: <20181114125910.GT99070@mdounin.ru> Message-ID: <4202346.VoJpnRx6hR@note> В письме от среда, 14 ноября 2018 г. 21:11:01 +07 пользователь kpoxa написал: > Я правильно понимаю, что можно сделать один listen 443 в специально > сделанном сайте, > который по другому никак не будет использоваться, а во всех остальных > местах, > и в HTTP и в стримах оставить listen ip:443 и все будет работать? Лучше, всё же в "дефолтном" `server {}`-блоке, который будет загружаться самым первым (т.е. либо дать ему такое имя, чтобы в алфавитном порядке при разыменовывании вайлдкарда оказался первым, либо в явном виде первым заинклудить. Плюс, лучше, всё же, в явном виде ``` listen *:443 listen [::]:443 ``` чтобы не надеяться на поведение "по умолчанию" From kpoxa на kpoxa.net Thu Nov 15 09:42:51 2018 From: kpoxa на kpoxa.net (kpoxa) Date: Thu, 15 Nov 2018 12:42:51 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtC70LDQs9C40LLQsNC90LjQtSDQutC+0L3QvdC10LrRgtC+0LIg?= =?UTF-8?B?0L/RgNC4INC/0YDQvtCy0LXRgNC60LUg0YHQuNC90YLQsNC60YHQuNGB0LA=?= In-Reply-To: <4202346.VoJpnRx6hR@note> References: <20181114125910.GT99070@mdounin.ru> <4202346.VoJpnRx6hR@note> Message-ID: Добрый день. Не помогает такой вариант: http { server { server_name bind_only; listen 80; listen 443 ssl; location / { return 200;} } server { listen ip10:443; } server { listen ip11:443; } } stream { server { listen ip1:443; } server { listen ip2:443; } server { listen ip3:443; } } Всё равно nginx при проверке синтаксиса делает bind ко всем адресам, которые указаны в listen; чт, 15 нояб. 2018 г. в 08:23, Vadim A. Misbakh-Soloviov : > В письме от среда, 14 ноября 2018 г. 21:11:01 +07 пользователь kpoxa > написал: > > Я правильно понимаю, что можно сделать один listen 443 в специально > > сделанном сайте, > > который по другому никак не будет использоваться, а во всех остальных > > местах, > > и в HTTP и в стримах оставить listen ip:443 и все будет работать? > > Лучше, всё же в "дефолтном" `server {}`-блоке, который будет загружаться > самым > первым (т.е. либо дать ему такое имя, чтобы в алфавитном порядке при > разыменовывании вайлдкарда оказался первым, либо в явном виде первым > заинклудить. > > Плюс, лучше, всё же, в явном виде > ``` > listen *:443 > listen [::]:443 > ``` > чтобы не надеяться на поведение "по умолчанию" > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx на mva.name Thu Nov 15 13:04:41 2018 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Thu, 15 Nov 2018 20:04:41 +0700 Subject: =?UTF-8?B?UmU6INCf0YDQvtC70LDQs9C40LLQsNC90LjQtSDQutC+0L3QvdC10LrRgtC+0LIg?= =?UTF-8?B?0L/RgNC4INC/0YDQvtCy0LXRgNC60LUg0YHQuNC90YLQsNC60YHQuNGB0LA=?= In-Reply-To: References: <4202346.VoJpnRx6hR@note> Message-ID: <9639299.BWq0Wh0RCn@note> В письме от четверг, 15 ноября 2018 г. 16:42:51 +07 пользователь kpoxa написал: > Добрый день. > > Не помогает такой вариант: > > http { ... > listen 80; ... > } > stream { > } А теперь, пожалуйста, вернитесь на пару писем назад по цепочке, и прочитайте ответ Максима. http и stream - разные модули. И вполне логично, что сокеты, объявленные в http{} не имеют отношения к сокетам, объявленным в stream{}. Как вы думаете? Вам, практически в явном виде, предлагалось создать вайлдкардный server{} в stream-модуле. И да, кстати, 1) можно указать `server_name _;` (нужен любой невалидный, а _ - самый короткий из них. 2) почему вы, всё же, не хотите в явном виде указать вайлдкард listen'у? From kpoxa на kpoxa.net Thu Nov 15 13:55:06 2018 From: kpoxa на kpoxa.net (kpoxa) Date: Thu, 15 Nov 2018 16:55:06 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtC70LDQs9C40LLQsNC90LjQtSDQutC+0L3QvdC10LrRgtC+0LIg?= =?UTF-8?B?0L/RgNC4INC/0YDQvtCy0LXRgNC60LUg0YHQuNC90YLQsNC60YHQuNGB0LA=?= In-Reply-To: <9639299.BWq0Wh0RCn@note> References: <4202346.VoJpnRx6hR@note> <9639299.BWq0Wh0RCn@note> Message-ID: У меня на сервере 200 IP адресов, на части из 443 портов висят HTTP сервера, на второй части 443 портов висят стримы. Соответственно ведут каждый из серверов в разные места. В моем случае нельзя сделать вилдкардный сервер в одном модуле, не пересекающийся с другим модулем. Перечитал ответ Максима, не увидел там противоречий описанному мною конфигу. Конфиг даже работает. Просто это не приводит к тому, что nginx при проверке не делал бы лишних bind. В целом какая разница сколько раз в сутки вызывается проверка синтаксиса, на мой взгляд даже ручной вызов проверки, приводящий к тормозам продовского сервера это плохо. чт, 15 нояб. 2018 г. в 16:05, Vadim A. Misbakh-Soloviov : > В письме от четверг, 15 ноября 2018 г. 16:42:51 +07 пользователь kpoxa > написал: > > Добрый день. > > > > Не помогает такой вариант: > > > > http { > ... > > listen 80; > ... > > } > > stream { > > } > > А теперь, пожалуйста, вернитесь на пару писем назад по цепочке, и > прочитайте > ответ Максима. > http и stream - разные модули. > И вполне логично, что сокеты, объявленные в http{} не имеют отношения к > сокетам, объявленным в stream{}. Как вы думаете? > Вам, практически в явном виде, предлагалось создать вайлдкардный server{} > в > stream-модуле. > > И да, кстати, > 1) можно указать `server_name _;` (нужен любой невалидный, а _ - самый > короткий из них. > 2) почему вы, всё же, не хотите в явном виде указать вайлдкард listen'у? > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Thu Nov 15 13:55:45 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 15 Nov 2018 16:55:45 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtC70LDQs9C40LLQsNC90LjQtSDQutC+0L3QvdC10LrRgtC+0LIg?= =?UTF-8?B?0L/RgNC4INC/0YDQvtCy0LXRgNC60LUg0YHQuNC90YLQsNC60YHQuNGB0LA=?= In-Reply-To: References: <20181114125910.GT99070@mdounin.ru> <4202346.VoJpnRx6hR@note> Message-ID: <20181115135545.GX99070@mdounin.ru> Hello! On Thu, Nov 15, 2018 at 12:42:51PM +0300, kpoxa wrote: > Добрый день. > > Не помогает такой вариант: > > http { > server { > server_name bind_only; > listen 80; > listen 443 ssl; > location / { return 200;} > } > server { > listen ip10:443; > } > server { > listen ip11:443; > } > } > stream { > server { > listen ip1:443; > } > server { > listen ip2:443; > } > server { > listen ip3:443; > } > } > > Всё равно nginx при проверке синтаксиса делает bind ко всем адресам, > которые указаны в listen; Как я уже писал ранее, если один и тот же порт пытаться использовать в разных модулях - будут проблемы. В приведённой конфигурации - в http-модуле будет создан listen-сокет на *:443, а в stream-модуле - сокеты на ip1:443, ip2:443, ip3:443. Вероятно, именно попытки bind'а на ip1:443, ip2:443 и ip3:443 вы приняли за "делает bind ко всем адресам". На самом деле не ко всем, а только к тем, что указаны в stream-модуле. Однако проблема не в этом, а в том, что на Линуксе такая конфигурация банально не заработает, так как открыть сокет на ip:443 при имеющемся открытом сокете на *:443 - на Линуксе нельзя. -- Maxim Dounin http://mdounin.ru/ From kpoxa на kpoxa.net Thu Nov 15 14:17:30 2018 From: kpoxa на kpoxa.net (kpoxa) Date: Thu, 15 Nov 2018 17:17:30 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtC70LDQs9C40LLQsNC90LjQtSDQutC+0L3QvdC10LrRgtC+0LIg?= =?UTF-8?B?0L/RgNC4INC/0YDQvtCy0LXRgNC60LUg0YHQuNC90YLQsNC60YHQuNGB0LA=?= In-Reply-To: <20181115135545.GX99070@mdounin.ru> References: <20181114125910.GT99070@mdounin.ru> <4202346.VoJpnRx6hR@note> <20181115135545.GX99070@mdounin.ru> Message-ID: Руками пересчитал количество bind в выводе strace, да, их стало меньше. Да, этот вариант действительно не рабочий. Пока что сделано через fake bind, загружаемый через LD_PRELOAD. Костыль, конечно. чт, 15 нояб. 2018 г. в 16:55, Maxim Dounin : > Hello! > > On Thu, Nov 15, 2018 at 12:42:51PM +0300, kpoxa wrote: > > > Добрый день. > > > > Не помогает такой вариант: > > > > http { > > server { > > server_name bind_only; > > listen 80; > > listen 443 ssl; > > location / { return 200;} > > } > > server { > > listen ip10:443; > > } > > server { > > listen ip11:443; > > } > > } > > stream { > > server { > > listen ip1:443; > > } > > server { > > listen ip2:443; > > } > > server { > > listen ip3:443; > > } > > } > > > > Всё равно nginx при проверке синтаксиса делает bind ко всем адресам, > > которые указаны в listen; > > Как я уже писал ранее, если один и тот же порт пытаться > использовать в разных модулях - будут проблемы. > > В приведённой конфигурации - в http-модуле будет создан > listen-сокет на *:443, а в stream-модуле - сокеты на ip1:443, > ip2:443, ip3:443. Вероятно, именно попытки bind'а на ip1:443, > ip2:443 и ip3:443 вы приняли за "делает bind ко всем адресам". На > самом деле не ко всем, а только к тем, что указаны в > stream-модуле. > > Однако проблема не в этом, а в том, что на Линуксе такая > конфигурация банально не заработает, так как открыть сокет на > ip:443 при имеющемся открытом сокете на *:443 - на Линуксе > нельзя. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine на gmail.com Thu Nov 15 14:20:27 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 15 Nov 2018 19:20:27 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC70LDQs9C40LLQsNC90LjQtSDQutC+0L3QvdC10LrRgtC+0LIg?= =?UTF-8?B?0L/RgNC4INC/0YDQvtCy0LXRgNC60LUg0YHQuNC90YLQsNC60YHQuNGB0LA=?= In-Reply-To: References: <4202346.VoJpnRx6hR@note> <9639299.BWq0Wh0RCn@note> Message-ID: чт, 15 нояб. 2018 г. в 18:55, kpoxa : > У меня на сервере 200 IP адресов, на части из 443 портов висят HTTP > сервера, на второй части 443 портов висят стримы. > если у вас systemd-шное, посмотрите в сторону "instantiated units" мы разнесли http и stream на разные инстансы, красота > Соответственно ведут каждый из серверов в разные места. В моем случае > нельзя сделать вилдкардный сервер в одном модуле, не пересекающийся с > другим модулем. > Перечитал ответ Максима, не увидел там противоречий описанному мною > конфигу. Конфиг даже работает. Просто это не приводит к тому, что nginx при > проверке не делал бы лишних bind. > > В целом какая разница сколько раз в сутки вызывается проверка синтаксиса, > на мой взгляд даже ручной вызов проверки, приводящий к тормозам продовского > сервера это плохо. > > чт, 15 нояб. 2018 г. в 16:05, Vadim A. Misbakh-Soloviov : > >> В письме от четверг, 15 ноября 2018 г. 16:42:51 +07 пользователь kpoxa >> написал: >> > Добрый день. >> > >> > Не помогает такой вариант: >> > >> > http { >> ... >> > listen 80; >> ... >> > } >> > stream { >> > } >> >> А теперь, пожалуйста, вернитесь на пару писем назад по цепочке, и >> прочитайте >> ответ Максима. >> http и stream - разные модули. >> И вполне логично, что сокеты, объявленные в http{} не имеют отношения к >> сокетам, объявленным в stream{}. Как вы думаете? >> Вам, практически в явном виде, предлагалось создать вайлдкардный server{} >> в >> stream-модуле. >> >> И да, кстати, >> 1) можно указать `server_name _;` (нужен любой невалидный, а _ - самый >> короткий из них. >> 2) почему вы, всё же, не хотите в явном виде указать вайлдкард listen'у? >> _______________________________________________ >> 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 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Thu Nov 15 14:46:32 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 15 Nov 2018 17:46:32 +0300 Subject: =?UTF-8?B?0KDQtdC70LjQtyBVbml0IDEuNg==?= Message-ID: <1547311.QE54pxguhk@vbart-workstation> Здравствуйте. Рад сообщить о выпуске новой версии NGINX Unit. Этот выпуск в основном посвящен улучшениям совместимости модуля Node.js с приложениями; благодаря активной помощи сообщества нам удалось добиться существенных успехов. Пожалуйста сообщайте нам обо всех найденных проблемах и трудностях в: - Github: https://github.com/nginx/unit/issues - список рассылки: https://mailman.nginx.org/mailman/listinfo/unit Если модуль unit-http был установлен из npm, то не забудьте обновить его вместе с Unit. Подробные инструкции по установке Node.js находятся на сайте: - http://unit.nginx.org/installation/#node-js-package Изменения в Unit 1.6 15.11.2018 *) Изменение: команда "make install" теперь также устанавливает модуль Node.js, если он был настроен. *) Добавление: параметр "--local" в ./configure для локальной установки модуля Node.js. *) Исправление: модуль Node.js мог падать из-за неправильного подсчета ссылок. *) Исправление: могли не работать асинхронные операции в Node.js. *) Исправление: различные проблемы совместимости с Node.js приложениями. *) Исправление: в журнале могли появляться оповещения "freed pointer is out of pool". *) Исправление: обнаружение модулей не работало на 64-битных системах с обратным порядком байтов, например IBM/S390x. -- Валентин Бартенев From nginx на mva.name Thu Nov 15 18:43:26 2018 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 16 Nov 2018 01:43:26 +0700 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjY=?= In-Reply-To: <1547311.QE54pxguhk@vbart-workstation> References: <1547311.QE54pxguhk@vbart-workstation> Message-ID: <12539089.jCcMOuG9Ho@note> > *) Изменение: команда "make install" теперь также устанавливает модуль > Node.js, если он был настроен. > > *) Добавление: параметр "--local" в ./configure для локальной установки > модуля Node.js. 1) я пока не смог вычислить, каким именно образом, но в новом релизе сборка nodejs-модуля "по умолчанию" (без патчинга auto/modules/nodejs на добавление --unsafe к вызову npm install) и наличии DESTDIR впадает в бесконечный цикл вот этого вот: https://github.com/nodejs/node-gyp/issues/1236 (собственно, идея про --unsafe и взята оттуда, но это костыль, и там советуют править билдконфиги проекта) 2) такое вот: ``` GOPATH=/var/tmp/portage/www-servers/nginx-unit-9999/image//usr/lib/go-gentoo go build nginx/unit export UNIT_SRC_PATH=/var/tmp/portage/www-servers/nginx-unit-9999/work/nginx- unit-9999/src && export UNIT_LIB_STATIC_PATH=/var/tmp/portage/www-servers/ nginx-unit-9999/work/nginx-unit-9999/build/libunit.a && \ npm install --unsafe -g /var/tmp/portage/www-servers/nginx-unit-9999/work/ nginx-unit-9999/build/node-unit-http.tar.gz > unit-http на 1.0.0 install /var/tmp/portage/www-servers/nginx-unit-9999/image/ usr/lib64/node_modules/unit-http > node-gyp configure build make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. make[1]: Entering directory '/var/tmp/portage/www-servers/nginx-unit-9999/ image/usr/lib64/node_modules/unit-http/build' CXX(target) Release/obj.target/unit-http/unit.o CXX(target) Release/obj.target/unit-http/addon.o SOLINK_MODULE(target) Release/obj.target/unit-http.node COPY Release/unit-http.node make[1]: Leaving directory '/var/tmp/portage/www-servers/nginx-unit-9999/ image/usr/lib64/node_modules/unit-http/build' + unit-http на 1.0.0 added 2 packages in 3.962s ``` (в частности, речь про `warning: jobserver unavailable`) Очень похоже на то, что, опять-таки, что-то не так с билд-конфигом gyp'а... Не могли бы вы ещё немного ковырнуть билд-систему, чтобы починить это дело? P.S. если нужно, то я даже готов помочь в тестировании фиксов из какого-нибудь девелоперского git-репозитория (пакетный менеджер ОС предоставляет возможность переопределения git-репозитория откуда качать исходники пакета) From bgx на protva.ru Thu Nov 15 19:50:15 2018 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 15 Nov 2018 22:50:15 +0300 Subject: =?UTF-8?B?0JLRi9Cx0L7RgCDQstC10YDRgdC40LggVExTINCyIHByb3h5X3NzbF9wcm90b2Nv?= =?UTF-8?B?bHM=?= Message-ID: <20181115195015.GB2312@protva.ru> Коллеги, добрый вечер. Есть задача спроксировать соединение до сервера с Exchange 2013, который не умеет TLSv1.2 и выше -- он просто обрывает соединение. Это выяснено с помощью "openssl s_client" перебором ключей -tlsXXX. Openssl с ключами -tls1 и -tls1_1 соединение устанавливает. Смотрим то же самое на nginx, для начала TLSv1.2. Конфиг стенда: server { listen *:8080 ; server_name cio.protva.ru ; location /owa/ { proxy_pass https://172.23.0.4/owa/ ; proxy_ssl_protocols TLSv1.2 ; ... } } Запрос принимается, nginx отсылает эксчейнджу нормальный пакет ClientHello (это подтверждается анализатором трафика, виден список шифров и прочие потроха), эксчейндж тупо рвёт коннекцию, в лог пишется: 2018/11/15 21:47:35 [error] 12393#12393: *1 peer closed connection in SSL handshake (104: Connection reset by peer) while SSL handshaking to upstream, client: 192.168.27.13, server: cio.protva.ru, request: "GET /owa/ HTTP/1.1", upstream: "https://172.23.0.4:443/owa/", host: "cio.protva.ru:8080" Здесь всё нормально и совпадает с результатом "openssl s_client -tls1_2". Теперь понижаем версию, чтобы получить желаемый коннект: прописываем в конфиге "TLSv1.1" и получаем в логе 2018/11/15 21:50:25 [crit] 12454#12454: *1 SSL_do_handshake() failed (SSL: error:141E70BF:SSL routines:tls_construct_client_hello:no protocols available) while SSL handshaking to upstream, client: 192.168.27.13, server: cio.protva.ru, request: "GET /owa/ HTTP/1.1", upstream: "https://172.23.0.4:443/owa/", host: "cio.protva.ru:8080" при этом по сети эксчейнджу летит такой пакет: ------------------------------------------------------------------------ Internet Protocol Version 4, Src: 192.168.30.31, Dst: 172.23.0.4 Transmission Control Protocol, Src Port: 33938, Dst Port: 443, Seq: 1, Ack: 1, Len: 7 Secure Sockets Layer TLSv1 Record Layer: Alert (Level: Fatal, Description: Internal Error) Content Type: Alert (21) Version: TLS 1.0 (0x0301) Length: 2 Alert Message Level: Fatal (2) Description: Internal Error (80) ------------------------------------------------------------------------ То есть вместо изменения версии происходит какая-то внутренняя ошибка "tls_construct_client_hello:no protocols available". Такой же результат получается если указать TLSv1, SSLv3 или несколько версий протокола. Это бага или я что-то упустил? Информация о стендовой системе: Debian/unstable (32bit), пакеты nginx-light_1.14.1-1_i386 и libssl_1.1.1-2_i386. # nginx -V nginx version: nginx/1.14.1 built with OpenSSL 1.1.1 11 Sep 2018 TLS SNI support enabled configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-AZYb5D/nginx-1.14.1=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_gzip_static_module --without-http_browser_module --without-http_geo_module --without-http_limit_req_module --without-http_limit_conn_module --without-http_memcached_module --without-http_referer_module --without-http_split_clients_module --without-http_userid_module --add-dynamic-module=/build/nginx-AZYb5D/nginx-1.14.1/debian/modules/http-echo PS. Пытался прописывать proxy_ssl_name, но шаманство не помогло, конечно. -- Eugene Berdnikov From vbart на nginx.com Thu Nov 15 20:32:03 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 15 Nov 2018 23:32:03 +0300 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjY=?= In-Reply-To: <12539089.jCcMOuG9Ho@note> References: <1547311.QE54pxguhk@vbart-workstation> <12539089.jCcMOuG9Ho@note> Message-ID: <51412480.APbJ2MuIZE@vbart-laptop> On Thursday, 15 November 2018 21:43:26 MSK Vadim A. Misbakh-Soloviov wrote: > > *) Изменение: команда "make install" теперь также устанавливает модуль > > Node.js, если он был настроен. > > > > *) Добавление: параметр "--local" в ./configure для локальной установки > > модуля Node.js. > > 1) я пока не смог вычислить, каким именно образом, но в новом релизе сборка > nodejs-модуля "по умолчанию" (без патчинга auto/modules/nodejs на добавление > --unsafe к вызову npm install) и наличии DESTDIR впадает в бесконечный цикл > вот этого вот: > https://github.com/nodejs/node-gyp/issues/1236 > (собственно, идея про --unsafe и взята оттуда, но это костыль, и там советуют > править билдконфиги проекта) А make install делается из под рута? Если не была задана опция --local, то npm будет пытаеться установить модуль в систему глобально, а для этого нужны соответсвующие привилегии. Если нужно поместить модуль в отдельную директорию, то следует указать опцию --local, либо использовать make node-local-install с соответсвующим DESTDIR. Или я неправильно понял проблему? Тогда хотелось бы подробностей, что за система и с какими опциями зовут ./configure, make и т.д.? > > 2) такое вот: [..] > > (в частности, речь про `warning: jobserver unavailable`) > Очень похоже на то, что, опять-таки, что-то не так с билд-конфигом gyp'а... [..] Очень похоже вот на этот баг: https://github.com/nodejs/node/issues/22457 -- Валентин Бартенев From nginx на mva.name Thu Nov 15 20:46:33 2018 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 16 Nov 2018 03:46:33 +0700 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjY=?= In-Reply-To: <51412480.APbJ2MuIZE@vbart-laptop> References: <1547311.QE54pxguhk@vbart-workstation> <12539089.jCcMOuG9Ho@note> <51412480.APbJ2MuIZE@vbart-laptop> Message-ID: <19773271.PlxTis7jc5@note> В письме от пятница, 16 ноября 2018 г. 3:32:03 +07 пользователь Валентин Бартенев написал: > А make install делается из под рута? да Но в sandbox (который пресекает попытки вылезти куда не следует) и, возможно, с fakeroot (завтра поконкретнее подебажу, используется ли он именно на этой стадии). > Если не была задана опция --local, > то npm будет пытаеться установить модуль в систему глобально, а для этого > нужны соответсвующие привилегии. Если нужно поместить модуль в отдельную > директорию, то следует указать опцию --local, либо использовать > make node-local-install с соответсвующим DESTDIR. Опция --local задана не была, но была задана переменная DESTDIR, а, согласно содержимому auto/modules/nodejs этого, вроде как, достаточно для того чтобы вызывался node-local-install. И, он, собственно, и вызывается. Но потом случается непонятно что и происходит бесконечный цикл про права доступа, хотя `id` и возвращает "root". Я даже пробовал объявить в стадии src_install'а переменную USER (которая и в самом деле пуста), но не помогало. Помог только --unsafe... > Или я неправильно понял проблему? Тогда хотелось бы подробностей, > что за система и с какими опциями зовут ./configure, make и т.д.? 1) Gentoo, 2) как-то вот так: ``` _unit_go_configure() { ./configure go --go-path="$(get_golibdir_gopath)" # multislot? } _unit_nodejs_configure() { ./configure nodejs --node-gyp="/usr/$(get_libdir)/node_modules/npm/bin/ node-gyp-bin/node-gyp" } _unit_perl_configure() { ./configure perl # multislot? } _unit_php_configure() { for impl in $(php_get_slots); do ./configure php --config="/usr/$(get_libdir)/${impl}/bin/php-config" --module="${impl/.}" --lib-path="/usr/lib/${impl}/$(get_libdir)" done } _unit_python_configure() { _unit_python_configure_each() { ./configure python --config="${EPYTHON}-config" --module="$ {EPYTHON/.}" } python_foreach_impl _unit_python_configure_each } _unit_ruby_configure() { _ruby_each_implementation_each() { cd "${WORKDIR}/${MY_P}" ./configure ruby --ruby="${RUBY}" --module="$(basename ${RUBY})" } _ruby_each_implementation _ruby_each_implementation_each } src_configure() { ./configure \ --cc="${CC}" \ --cc-opt="${CFLAGS}" \ --ld-opt="${LDFLAGS}" \ --bindir="/usr/bin" \ --sbindir="/usr/sbin" \ --prefix="/var/lib/${PN}" \ --modules="/usr/lib/${PN}/modules" \ --state="/var/lib/${PN}" \ --pid="/run/${PN}.pid" \ --log="/var/log/${PN}.log" \ --control="unix:/run/${PN}.sock" \ $(usex ipv6 '' "--no-ipv6") \ $(usex unix-sockets '' "--no-unix-sockets") \ $(usex debug "--debug" "") for mod in $UNIT_MODULES; do use "unit_modules_${mod}" && "_unit_${mod}_configure" done } ``` > Очень похоже вот на этот баг: > https://github.com/nodejs/node/issues/22457 Возможно. Но, увы, обновить nodejs пока что никакой возможности (10+ заблокированы дистрибутивом ибо тянут заблокированный openssl-1.1 (который ломает кучу всего). Да и 9.х не хочет пересобираться, ибо хочет старый icu, которого уже нету). Так что приходится жевать то, что было установлено когда-то давно (9.8.0) :) From vbart на nginx.com Thu Nov 15 21:11:47 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 16 Nov 2018 00:11:47 +0300 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjY=?= In-Reply-To: <19773271.PlxTis7jc5@note> References: <1547311.QE54pxguhk@vbart-workstation> <51412480.APbJ2MuIZE@vbart-laptop> <19773271.PlxTis7jc5@note> Message-ID: <2086227.3KAItuY3YC@vbart-laptop> On Thursday, 15 November 2018 23:46:33 MSK Vadim A. Misbakh-Soloviov wrote: > В письме от пятница, 16 ноября 2018 г. 3:32:03 +07 пользователь Валентин > Бартенев написал: > > А make install делается из под рута? > да > Но в sandbox (который пресекает попытки вылезти куда не следует) и, возможно, > с fakeroot (завтра поконкретнее подебажу, используется ли он именно на этой > стадии). > > Если не была задана опция --local, > > то npm будет пытаеться установить модуль в систему глобально, а для этого > > нужны соответсвующие привилегии. Если нужно поместить модуль в отдельную > > директорию, то следует указать опцию --local, либо использовать > > make node-local-install с соответсвующим DESTDIR. > Опция --local задана не была, но была задана переменная DESTDIR, а, согласно > содержимому auto/modules/nodejs этого, вроде как, достаточно для того чтобы > вызывался node-local-install. И, он, собственно, и вызывается. Но потом [..] Опция --local устанавливает NXT_NODE_LOCAL. --local=*) NXT_NODE_LOCAL="$value" ;; иначе тот пустой: NXT_NODE_LOCAL=${NXT_NODE_LOCAL=} а далее проверка и если он пустой, то будет использоваться node-install и только если не пустой, то node-local-install: if [ -n "$NXT_NODE_LOCAL" ]; then NXT_NODE_INSTALL=local-install else NXT_NODE_INSTALL=install fi install: ${NXT_NODE}-$NXT_NODE_INSTALL ну и судя по тому, что было приведено в предыдущем письме, npm install вызывается с флагом -g, а это установка в глобальную директорию npm в системе. > случается непонятно что и происходит бесконечный цикл про права доступа, хотя > `id` и возвращает "root". Я даже пробовал объявить в стадии src_install'а > переменную USER (которая и в самом деле пуста), но не помогало. Помог только > --unsafe... sandbox скорее всего мешает npm поставить в свою глобальную директорию модулей в системе и от этого все приключения. Подозреваю, что сам npm при этом на DESTDIR не смотрит или делает как-то странно. > > Или я неправильно понял проблему? Тогда хотелось бы подробностей, > > что за система и с какими опциями зовут ./configure, make и т.д.? > 1) Gentoo, > 2) как-то вот так: Ok, посмотрю на это повнимательнее. Последний раз, когда я пытался поставить в Gentoo, то обнаружил из коробки сломанный npm: % npm -v fs.js:1657 binding.lstat(baseLong); ^ Error: ENOENT: no such file or directory, lstat '/lib64/node_modules' at Object.realpathSync (fs.js:1657:15) at toRealPath (module.js:164:13) at Function.Module._findPath (module.js:213:22) at Function.Module._resolveFilename (module.js:546:25) at Function.Module._load (module.js:475:25) at Function.Module.runMain (module.js:694:10) at startup (bootstrap_node.js:204:16) at bootstrap_node.js:625:3 и сходу не смог это побороть. -- Валентин Бартенев From nginx на mva.name Fri Nov 16 05:32:33 2018 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 16 Nov 2018 12:32:33 +0700 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjY=?= In-Reply-To: <2086227.3KAItuY3YC@vbart-laptop> References: <1547311.QE54pxguhk@vbart-workstation> <19773271.PlxTis7jc5@note> <2086227.3KAItuY3YC@vbart-laptop> Message-ID: <2432727.SVqKNXJ2Ek@note> > Опция --local устанавливает NXT_NODE_LOCAL. Хм... Значит текст в node-local-check обманывает :) > echo "error: to make ${NXT_NODE}-local-install you need **either**"; > either :) > ну и судя по тому, что было приведено в предыдущем письме, npm install > вызывается с флагом -g, а это установка в глобальную директорию npm в > системе. Что-то, да, я как-то и не приметил -g, прошу пардону :) > sandbox скорее всего мешает npm поставить в свою глобальную директорию > модулей в системе и от этого все приключения. На самом деле, нет. Если бы мешал sandbox, то вываливались бы сообщения об access violation от него самого, а их нет (к тому же, в `.../image/...` он ставить разрешает. Он не разрешает ставить в систему игнорируя DESTDIR. А установка, когда появляется бесконечный цикл, идёт как раз в директорию с учётом DESTDIR). > Подозреваю, что сам npm при этом на DESTDIR не смотрит или делает как-то > странно. Судя по всему, таки не игнорирует (или она ему как-то иначе передаётся). Потому что: ``` gyp WARN EACCES user "undefined" does not have permission to access the dev dir "/var/tmp/portage/www-servers/nginx-unit-9999/image/usr/lib64/ node_modules/unit-http/.node-gyp/9.8.0" gyp WARN EACCES attempting to reinstall using temporary dev dir "/var/tmp/ portage/www-servers/nginx-unit-9999/image/usr/lib64/node_modules/unit- http/.node-gyp" gyp WARN EACCES user "nobody" does not have permission to access the dev dir "/var/tmp/portage/www-servers/nginx-unit-9999/image/usr/lib64/node_modules/ unit-http/.node-gyp/9.8.0" gyp WARN EACCES attempting to reinstall using temporary dev dir "/var/tmp/ portage/www-servers/nginx-unit-9999/image/usr/lib64/node_modules/unit- http/.node-gyp" ``` При этом, `/var/tmp/portage/www-servers/nginx-unit-9999/image/` - это как раз и есть DESTDIR. > Ok, посмотрю на это повнимательнее. > > Последний раз, когда я пытался поставить в Gentoo, то обнаружил > из коробки сломанный npm: > > > % npm -v Ну, у меня npm, вроде и рабочий, не смотря на "старую" версию nodejs'а в системе (9.8.0) и описанные выше проблемы (10+ версии замаскированы из-за зависимости от openssl-1.1, а 9.х привередничает про icu) :) К слову, для лучшей воспроизводимости - немного обнаглею и попрошу ставить из моего оверлея (у меня там более фичастый unit, в отличие от того, что в главном репозитории, да и там - последний 1.5). Его можно добавить либо layman'ом, либо eselect-repository (в зависимости от новизны системы и того, что из них используется для управления репозиториями). Соответственно, > layman -a mva или > eselect repository enable mva После чего > USE="unit_modules_nodejs" sudo emerge -va nginx-unit::mva Кстати, я сейчас попробовал подобавлять `--local`... Получил такое вот: ``` gyp WARN EACCES user "root" does not have permission to access the dev dir "/ var/tmp/portage/www-servers/nginx-unit-9999/homedir/.node-gyp/9.8.0" gyp WARN EACCES attempting to reinstall using temporary dev dir "/var/tmp/ portage/www-servers/nginx-unit-9999/image/usr/lib64/node_modules/unit- http/.node-gyp" make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. CXX(target) Release/obj.target/unit-http/unit.o cc1plus: error: /var/tmp/portage/www-servers/nginx-unit-9999/work/nginx- unit-9999/src: Permission denied make[1]: *** [unit-http.target.mk:96: Release/obj.target/unit-http/unit.o] Error 1 gyp ERR! build error gyp ERR! stack Error: `make` failed with exit code: 2 gyp ERR! stack at ChildProcess.onExit (/usr/lib64/node_modules/npm/ node_modules/node-gyp/lib/build.js:258:23) gyp ERR! stack at ChildProcess.emit (events.js:180:13) gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/ child_process.js:209:12) gyp ERR! System Linux 4.18.10 gyp ERR! command "/usr/bin/node" "/usr/lib64/node_modules/npm/node_modules/ node-gyp/bin/node-gyp.js" "configure" "build" gyp ERR! cwd /var/tmp/portage/www-servers/nginx-unit-9999/image/usr/lib64/ node_modules/unit-http gyp ERR! node -v v9.8.0 gyp ERR! node-gyp -v v3.6.2 gyp ERR! not ok npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR! unit-http на 1.0.0 install: `node-gyp configure build` npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the unit-http на 1.0.0 install script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above. npm ERR! A complete log of this run can be found in: npm ERR! /var/tmp/portage/www-servers/nginx-unit-9999/homedir/.npm/_logs/ 2018-11-16T05_31_22_466Z-debug.log make: *** [build/Makefile:1831: node-local-install] Error 1 ``` Даже при выключенном fakeroot... Что-то странное... From mdounin на mdounin.ru Fri Nov 16 11:23:52 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 16 Nov 2018 14:23:52 +0300 Subject: =?UTF-8?B?UmU6INCS0YvQsdC+0YAg0LLQtdGA0YHQuNC4IFRMUyDQsiBwcm94eV9zc2xfcHJv?= =?UTF-8?B?dG9jb2xz?= In-Reply-To: <20181115195015.GB2312@protva.ru> References: <20181115195015.GB2312@protva.ru> Message-ID: <20181116112352.GH99070@mdounin.ru> Hello! On Thu, Nov 15, 2018 at 10:50:15PM +0300, Evgeniy Berdnikov wrote: > Есть задача спроксировать соединение до сервера с Exchange 2013, > который не умеет TLSv1.2 и выше -- он просто обрывает соединение. > Это выяснено с помощью "openssl s_client" перебором ключей -tlsXXX. > Openssl с ключами -tls1 и -tls1_1 соединение устанавливает. [...] > Теперь понижаем версию, чтобы получить желаемый коннект: прописываем > в конфиге "TLSv1.1" и получаем в логе > > 2018/11/15 21:50:25 [crit] 12454#12454: *1 SSL_do_handshake() failed (SSL: error:141E70BF:SSL routines:tls_construct_client_hello:no protocols available) while SSL handshaking to upstream, client: 192.168.27.13, server: cio.protva.ru, request: "GET /owa/ HTTP/1.1", upstream: "https://172.23.0.4:443/owa/", host: "cio.protva.ru:8080" [...] > То есть вместо изменения версии происходит какая-то внутренняя ошибка > "tls_construct_client_hello:no protocols available". Такой же результат > получается если указать TLSv1, SSLv3 или несколько версий протокола. > Это бага или я что-то упустил? > > Информация о стендовой системе: Debian/unstable (32bit), пакеты > nginx-light_1.14.1-1_i386 и libssl_1.1.1-2_i386. Проблема в том, что в Debian на системном уровне запрещены протоколы меньше TLS 1.2. Соответственно в вашей конфигурации оказываются запрещены вообще все протоколы - об этом и говорит ошибка "no protocols available". Исправить это можно, обновившись на nginx 1.15.3+, где соответствующая проблема полечена на уровне nginx[1], либо же убрав ограничение в системном конфиге OpenSSL и/или задав для nginx'а отдельный конфиг, без соответствующего ограничения. [1] http://hg.nginx.org/nginx/rev/7ad0f4ace359 -- Maxim Dounin http://mdounin.ru/ From bgx на protva.ru Fri Nov 16 12:33:41 2018 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 16 Nov 2018 15:33:41 +0300 Subject: =?UTF-8?B?UmU6INCS0YvQsdC+0YAg0LLQtdGA0YHQuNC4IFRMUyDQsiBwcm94eV9zc2xfcHJv?= =?UTF-8?B?dG9jb2xz?= In-Reply-To: <20181116112352.GH99070@mdounin.ru> References: <20181115195015.GB2312@protva.ru> <20181116112352.GH99070@mdounin.ru> Message-ID: <20181116123341.GD2312@protva.ru> Добрый день. On Fri, Nov 16, 2018 at 02:23:52PM +0300, Maxim Dounin wrote: > Проблема в том, что в Debian на системном уровне запрещены > протоколы меньше TLS 1.2. Соответственно в вашей конфигурации > оказываются запрещены вообще все протоколы - об этом и говорит > ошибка "no protocols available". Действительно, изменение MinProtocol в системном конфиге openssl решает проблему. Спасибо. > Исправить это можно, обновившись на nginx 1.15.3+, где > соответствующая проблема полечена на уровне nginx[1], либо же > убрав ограничение в системном конфиге OpenSSL и/или задав для > nginx'а отдельный конфиг, без соответствующего ограничения. Каким образом можно задать для nginx отдельный конфиг без системного ограничения на версии TLS? Предлагаю описание директив ssl_protocols и proxy_ssl_protocols дополнить словами о том, что версия может быть ограничена в системном конфиге openssl вплоть до некоторых версий nginx. Хотя бы на сайте (в дистрибутивах с младшими версиями nginx менять документацию уже поздно). -- Eugene Berdnikov From mdounin на mdounin.ru Fri Nov 16 13:08:00 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 16 Nov 2018 16:08:00 +0300 Subject: =?UTF-8?B?UmU6INCS0YvQsdC+0YAg0LLQtdGA0YHQuNC4IFRMUyDQsiBwcm94eV9zc2xfcHJv?= =?UTF-8?B?dG9jb2xz?= In-Reply-To: <20181116123341.GD2312@protva.ru> References: <20181115195015.GB2312@protva.ru> <20181116112352.GH99070@mdounin.ru> <20181116123341.GD2312@protva.ru> Message-ID: <20181116130800.GL99070@mdounin.ru> Hello! On Fri, Nov 16, 2018 at 03:33:41PM +0300, Evgeniy Berdnikov wrote: > On Fri, Nov 16, 2018 at 02:23:52PM +0300, Maxim Dounin wrote: > > Проблема в том, что в Debian на системном уровне запрещены > > протоколы меньше TLS 1.2. Соответственно в вашей конфигурации > > оказываются запрещены вообще все протоколы - об этом и говорит > > ошибка "no protocols available". > > Действительно, изменение MinProtocol в системном конфиге openssl > решает проблему. Спасибо. > > > Исправить это можно, обновившись на nginx 1.15.3+, где > > соответствующая проблема полечена на уровне nginx[1], либо же > > убрав ограничение в системном конфиге OpenSSL и/или задав для > > nginx'а отдельный конфиг, без соответствующего ограничения. > > Каким образом можно задать для nginx отдельный конфиг > без системного ограничения на версии TLS? Конфиг для openssl, отличный от используемого по умолчанию, можно задать с помощью переменной окружения OPENSSL_CONF. > Предлагаю описание директив ssl_protocols и proxy_ssl_protocols > дополнить словами о том, что версия может быть ограничена в > системном конфиге openssl вплоть до некоторых версий nginx. > Хотя бы на сайте (в дистрибутивах с младшими версиями nginx > менять документацию уже поздно). Как я уже писал ранее, начиная с версии 1.15.3 nginx умеет бороться с попытками ограничить протоколы через конфиг OpenSSL'я, а равно с аналогичными ограничениями, заданными на уровне библиотеки. -- Maxim Dounin http://mdounin.ru/ From nginx на mva.name Sat Nov 17 05:16:41 2018 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Sat, 17 Nov 2018 12:16:41 +0700 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjY=?= In-Reply-To: <2432727.SVqKNXJ2Ek@note> References: <1547311.QE54pxguhk@vbart-workstation> <2086227.3KAItuY3YC@vbart-laptop> <2432727.SVqKNXJ2Ek@note> Message-ID: <12747375.pBCUH394yM@note> Что-то я тут подебажил ещё, и заметил вообще страннейшую вещь: нижеуказанная ошибка вываливается если использовать --local=/usr/lib64 и export USER=root (потому что под ним и происходит install-фаза, просто переменная пуста). > ``` > gyp WARN EACCES user "root" does not have permission to access the dev dir > "/ var/tmp/portage/www-servers/nginx-unit-9999/homedir/.node-gyp/9.8.0" gyp > cc1plus: error: /var/tmp/portage/www-servers/nginx-unit-9999/work/nginx- > unit-9999/src: Permission denied > ``` Однако (!!!) 1) не просто у юзера root есть права доступа в директории, на которые ссылается билдлог, но и прямо даже из секции src_install (откуда потом вызывается `make install`), непосредственно перед этим `make install`'ом я прекрасно могу создать (touch'ем) файлы в указанных директориях... Ну, точнее, первая не существует, но прекрасно создаётся `mkdir -p` (хотя это и не помогает, а приводит к другой ошибке с правами), а вот во второй прекрасно создаютмя любые файлы. А вот gyp почему-то выкабенивается... From vbart на nginx.com Sat Nov 17 14:12:13 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 17 Nov 2018 17:12:13 +0300 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjY=?= In-Reply-To: <12747375.pBCUH394yM@note> References: <1547311.QE54pxguhk@vbart-workstation> <2432727.SVqKNXJ2Ek@note> <12747375.pBCUH394yM@note> Message-ID: <10864443.pLbeIu2Nvj@vbart-laptop> On Saturday, 17 November 2018 08:16:41 MSK Vadim A. Misbakh-Soloviov wrote: > Что-то я тут подебажил ещё, и заметил вообще страннейшую вещь: > нижеуказанная ошибка вываливается если использовать --local=/usr/lib64 и > export USER=root (потому что под ним и происходит install-фаза, просто > переменная пуста). > > > ``` > > gyp WARN EACCES user "root" does not have permission to access the dev dir > > "/ var/tmp/portage/www-servers/nginx-unit-9999/homedir/.node-gyp/9.8.0" gyp > > cc1plus: error: /var/tmp/portage/www-servers/nginx-unit-9999/work/nginx- > > unit-9999/src: Permission denied > > ``` > > Однако (!!!) > 1) не просто у юзера root есть права доступа в директории, на которые > ссылается билдлог, но и прямо даже из секции src_install (откуда потом > вызывается `make install`), непосредственно перед этим `make install`'ом я > прекрасно могу создать (touch'ем) файлы в указанных директориях... > Ну, точнее, первая не существует, но прекрасно создаётся `mkdir -p` (хотя это > и не помогает, а приводит к другой ошибке с правами), а вот во второй > прекрасно создаютмя любые файлы. > > А вот gyp почему-то выкабенивается... Я ровно это сейчас и наблюдаю, но только без --local: npm install -g /tmp/portage/www-servers/nginx-unit-9999/work/nginx-unit-9999/build/node-unit-http.tar.gz > unit-http на 1.0.0 install /tmp/portage/www-servers/nginx-unit-9999/image/usr/lib64/node_modules/unit-http > node-gyp configure build gyp WARN EACCES user "root" does not have permission to access the dev dir "/tmp/portage/www-servers/nginx-unit-9999/homedir/.node-gyp/8.12.0" gyp WARN EACCES attempting to reinstall using temporary dev dir "/tmp/portage/www-servers/nginx-unit-9999/image/usr/lib64/node_modules/unit-http/.node-gyp" gyp WARN install got an error, rolling back install gyp WARN install got an error, rolling back install gyp ERR! configure error gyp ERR! stack Error: EACCES: permission denied, mkdir '/tmp/portage/www-servers/nginx-unit-9999/image/usr/lib64/node_modules/unit-http/.node-gyp' gyp ERR! System Linux 4.14.81-gentoo gyp ERR! command "/usr/bin/node" "/usr/lib64/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "configure" "build" И пока непонятно, что с этим делать. Будем разбираться. -- Валентин Бартенев From vbart на nginx.com Sat Nov 17 15:03:25 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 17 Nov 2018 18:03:25 +0300 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjY=?= In-Reply-To: <10864443.pLbeIu2Nvj@vbart-laptop> References: <1547311.QE54pxguhk@vbart-workstation> <12747375.pBCUH394yM@note> <10864443.pLbeIu2Nvj@vbart-laptop> Message-ID: <2135447.blEbgMueuS@vbart-laptop> On Saturday, 17 November 2018 17:12:13 MSK Валентин Бартенев wrote: > On Saturday, 17 November 2018 08:16:41 MSK Vadim A. Misbakh-Soloviov wrote: > > Что-то я тут подебажил ещё, и заметил вообще страннейшую вещь: > > нижеуказанная ошибка вываливается если использовать --local=/usr/lib64 и > > export USER=root (потому что под ним и происходит install-фаза, просто > > переменная пуста). > > > > > ``` > > > gyp WARN EACCES user "root" does not have permission to access the dev dir > > > "/ var/tmp/portage/www-servers/nginx-unit-9999/homedir/.node-gyp/9.8.0" gyp > > > cc1plus: error: /var/tmp/portage/www-servers/nginx-unit-9999/work/nginx- > > > unit-9999/src: Permission denied > > > ``` > > > > Однако (!!!) > > 1) не просто у юзера root есть права доступа в директории, на которые > > ссылается билдлог, но и прямо даже из секции src_install (откуда потом > > вызывается `make install`), непосредственно перед этим `make install`'ом я > > прекрасно могу создать (touch'ем) файлы в указанных директориях... > > Ну, точнее, первая не существует, но прекрасно создаётся `mkdir -p` (хотя это > > и не помогает, а приводит к другой ошибке с правами), а вот во второй > > прекрасно создаютмя любые файлы. > > > > А вот gyp почему-то выкабенивается... > > > Я ровно это сейчас и наблюдаю, но только без --local: > > npm install -g /tmp/portage/www-servers/nginx-unit-9999/work/nginx-unit-9999/build/node-unit-http.tar.gz > > > unit-http на 1.0.0 install /tmp/portage/www-servers/nginx-unit-9999/image/usr/lib64/node_modules/unit-http > > node-gyp configure build > > gyp WARN EACCES user "root" does not have permission to access the dev dir "/tmp/portage/www-servers/nginx-unit-9999/homedir/.node-gyp/8.12.0" > gyp WARN EACCES attempting to reinstall using temporary dev dir "/tmp/portage/www-servers/nginx-unit-9999/image/usr/lib64/node_modules/unit-http/.node-gyp" > gyp WARN install got an error, rolling back install > gyp WARN install got an error, rolling back install > gyp ERR! configure error > gyp ERR! stack Error: EACCES: permission denied, mkdir '/tmp/portage/www-servers/nginx-unit-9999/image/usr/lib64/node_modules/unit-http/.node-gyp' > gyp ERR! System Linux 4.14.81-gentoo > gyp ERR! command "/usr/bin/node" "/usr/lib64/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "configure" "build" > > > И пока непонятно, что с этим делать. Будем разбираться. > По всей видимости, опция USER влияет исключительно на вывод ошибки в логе, а пользователь при этом остается тем, что был указан в конфигах npm, а по умолчанию это "nobody". Очень удобно! Если в npm install скормить явно --user=root, то всё успешно отрабатывает. Похоже --unsafe-perm там необходим, иначе оно неработоспособно при таких сборках. У меня установка (без опции --local) прошла успешно с таким патчем: diff -r cb3595d83966 auto/modules/nodejs --- a/auto/modules/nodejs Thu Nov 15 21:50:00 2018 +0300 +++ b/auto/modules/nodejs Sat Nov 17 17:21:05 2018 +0300 @@ -161,7 +161,7 @@ install: ${NXT_NODE}-$NXT_NODE_INSTALL ${NXT_NODE}-install: ${NXT_NODE_TARBALL} \ $NXT_BUILD_DIR/$NXT_LIB_UNIT_STATIC ${NXT_NODE_EXPORTS} && \\ - ${NXT_NPM} install -g ${PWD}/${NXT_NODE_TARBALL} + ${NXT_NPM} install -g --user=root ${PWD}/${NXT_NODE_TARBALL} ${NXT_NODE}-uninstall: ${NXT_NPM} uninstall -g unit-http Либо с таким: diff -r cb3595d83966 auto/modules/nodejs --- a/auto/modules/nodejs Thu Nov 15 21:50:00 2018 +0300 +++ b/auto/modules/nodejs Sat Nov 17 17:21:05 2018 +0300 @@ -161,7 +161,7 @@ install: ${NXT_NODE}-$NXT_NODE_INSTALL ${NXT_NODE}-install: ${NXT_NODE_TARBALL} \ $NXT_BUILD_DIR/$NXT_LIB_UNIT_STATIC ${NXT_NODE_EXPORTS} && \\ - ${NXT_NPM} install -g ${PWD}/${NXT_NODE_TARBALL} + ${NXT_NPM} install -g --unsafe-perm ${PWD}/${NXT_NODE_TARBALL} ${NXT_NODE}-uninstall: ${NXT_NPM} uninstall -g unit-http -- Валетин Бартенев From nginx на mva.name Sat Nov 17 16:12:41 2018 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Sat, 17 Nov 2018 23:12:41 +0700 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjY=?= In-Reply-To: <2135447.blEbgMueuS@vbart-laptop> References: <1547311.QE54pxguhk@vbart-workstation> <10864443.pLbeIu2Nvj@vbart-laptop> <2135447.blEbgMueuS@vbart-laptop> Message-ID: <1810417.Q4SvZkHIkL@note> > У меня установка (без опции --local) прошла успешно с таким патчем: > + ${NXT_NPM} install -g --user=root ${PWD}/${NXT_NODE_TARBALL} > Либо с таким: > + ${NXT_NPM} install -g --unsafe-perm ${PWD}/${NXT_NODE_TARBALL} Ну, вот, у меня тоже она успешно проходит только с `--unsafe` И да, я, похоже, закоммитив, забыл запушить на гитхаб изменения с добавленным sed'о'патчем на `--unsafe`, вот и не собирается :) // а всё потому, что экспериментировал с --local Собственно, теперь встаёт вопрос о том, что же делать? Сильно для вас будет проблематично "апстримно" добавить туда что-нибудь типа > --user=$(whoami) или как-нибудь так? :) Ну, чтобы, с одной стороны, в *этом* кейсе оно превращалось в --user=root, а с другой - не мешало другим юзерам ставить не-под-рутом (если таковые есть)? From vbart на nginx.com Mon Nov 19 14:03:47 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 19 Nov 2018 17:03:47 +0300 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjY=?= In-Reply-To: <1810417.Q4SvZkHIkL@note> References: <1547311.QE54pxguhk@vbart-workstation> <2135447.blEbgMueuS@vbart-laptop> <1810417.Q4SvZkHIkL@note> Message-ID: <5416237.0ZquYHsRLQ@vbart-workstation> On Saturday 17 November 2018 23:12:41 Vadim A. Misbakh-Soloviov wrote: [..] > Собственно, теперь встаёт вопрос о том, что же делать? > Сильно для вас будет проблематично "апстримно" добавить туда что-нибудь типа > > --user=$(whoami) > > или как-нибудь так? :) > Ну, чтобы, с одной стороны, в *этом* кейсе оно превращалось в --user=root, а с > другой - не мешало другим юзерам ставить не-под-рутом (если таковые есть)? Думаю, что нужно просто добавить туда --unsafe-perm. Едва ли это может как-то помещать. Если я правильно понимаю, то сказывается это только на том от какого пользователя запускаются скрипты сборки (а именно node-gyp). Более того, если запускать не из под root, то значение этой опции и так true по умолчанию. -- Валентин Бартенев From nginx на mva.name Mon Nov 19 17:17:41 2018 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Tue, 20 Nov 2018 00:17:41 +0700 Subject: =?UTF-8?B?UmU6INCg0LXQu9C40LcgVW5pdCAxLjY=?= In-Reply-To: <5416237.0ZquYHsRLQ@vbart-workstation> References: <1547311.QE54pxguhk@vbart-workstation> <1810417.Q4SvZkHIkL@note> <5416237.0ZquYHsRLQ@vbart-workstation> Message-ID: <4577595.qXaYJQFISI@note> > Думаю, что нужно просто добавить туда --unsafe-perm. Ну, тут уж вам там, как апстриму виднее :) Вы только маякните, пожалуйста, когда можно будет манки-патч седовый убирать :) From nginx на mva.name Tue Nov 20 18:07:11 2018 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Wed, 21 Nov 2018 01:07:11 +0700 Subject: =?UTF-8?B?W1VuaXRdINCw0L3QsNC70L7QsyB0b3VjaCAkZG9jdW1lbnRfcm9vdC90bXAvcmVz?= =?UTF-8?B?dGFydA==?= Message-ID: <27548884.zrriyEzTO8@note> Коллеги, и подскажите, пожалуйста, есть ли у Юнита какой-нибудь способ сообщить ему (после деплоя изменений в рабочую директорию проекта) что нужно перезапустить текущее приложение "во прямо сейчас"? А-ля touch tmp/restart.txt у пассажира и всяких рубишных аппликейшн-серверов Что-то, в документации такого не нахожу. То ли совсем плохой стал, то ли такой кейс там не описан. Максимально приближенное что я нашёл в документации - limits.requests, но это, всё же, не совсем то... From vbart на nginx.com Tue Nov 20 18:21:32 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 20 Nov 2018 21:21:32 +0300 Subject: =?UTF-8?B?UmU6IFtVbml0XSDQsNC90LDQu9C+0LMgdG91Y2ggJGRvY3VtZW50X3Jvb3QvdG1w?= =?UTF-8?B?L3Jlc3RhcnQ=?= In-Reply-To: <27548884.zrriyEzTO8@note> References: <27548884.zrriyEzTO8@note> Message-ID: <5197880.atHDly2LMT@vbart-workstation> On Wednesday 21 November 2018 01:07:11 Vadim A. Misbakh-Soloviov wrote: > Коллеги, и подскажите, пожалуйста, есть ли у Юнита какой-нибудь способ > сообщить ему (после деплоя изменений в рабочую директорию проекта) что нужно > перезапустить текущее приложение "во прямо сейчас"? > > А-ля touch tmp/restart.txt у пассажира и всяких рубишных аппликейшн-серверов > > Что-то, в документации такого не нахожу. То ли совсем плохой стал, то ли такой > кейс там не описан. > > Максимально приближенное что я нашёл в документации - limits.requests, но это, > всё же, не совсем то... В будущем планируется механизм для управления процессами вручную. Что-то вроде: curl 127.1:8443/control/applications//restart Сейчас самый простой способ перезагрузить приложение - это обновить его переменные окружения. Например одной командой: curl -X PUT -d "{\"gen\":\"$RANDOM\"}" 127.1:8443/config/applications//environment -- Валентин Бартенев From thresh на nginx.com Thu Nov 22 11:57:37 2018 From: thresh на nginx.com (Konstantin Pavlov) Date: Thu, 22 Nov 2018 14:57:37 +0300 Subject: =?UTF-8?B?UmU6INCR0LjQvdCw0YDQvdGL0LUg0L/QsNC60LXRgtGLINC/0L7QtCBBUk02NCA=?= =?UTF-8?B?0LTQu9GPIFVidW50dSAxOC4wNA==?= In-Reply-To: References: Message-ID: <101a7725-df82-c69b-5e33-6e4d571995f4@nginx.com> Здравствуйте, 13.11.2018 0:38, Pavel Odintsov wrote: > Добрый день! > > Update: добавил рассылку в копию > > Спасибо за ответ! Будем ждать пакетов :) И Вам спасибо. Пакеты для stable и mainline готовы и выложены, в будущем будут выпускаться для каждого релиза в общем порядке. -- Konstantin Pavlov https://www.nginx.com/ From pavel.odintsov на gmail.com Mon Nov 26 21:05:03 2018 From: pavel.odintsov на gmail.com (Pavel Odintsov) Date: Mon, 26 Nov 2018 21:05:03 +0000 Subject: =?UTF-8?B?UmU6INCR0LjQvdCw0YDQvdGL0LUg0L/QsNC60LXRgtGLINC/0L7QtCBBUk02NCA=?= =?UTF-8?B?0LTQu9GPIFVidW50dSAxOC4wNA==?= In-Reply-To: <101a7725-df82-c69b-5e33-6e4d571995f4@nginx.com> References: <101a7725-df82-c69b-5e33-6e4d571995f4@nginx.com> Message-ID: Добрый день! ОГРОМНОЕ спасибо за столь быструю реакцию :) Пакеты проверили - работает прекрасно! On Thu, Nov 22, 2018 at 11:57 AM Konstantin Pavlov wrote: > Здравствуйте, > > 13.11.2018 0:38, Pavel Odintsov wrote: > > Добрый день! > > > > Update: добавил рассылку в копию > > > > Спасибо за ответ! Будем ждать пакетов :) > > И Вам спасибо. > > Пакеты для stable и mainline готовы и выложены, в будущем будут > выпускаться для каждого релиза в общем порядке. > > -- > Konstantin Pavlov > https://www.nginx.com/ > -- Sincerely yours, Pavel Odintsov ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Nov 27 15:02:31 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 27 Nov 2018 18:02:31 +0300 Subject: nginx-1.15.7 Message-ID: <20181127150231.GT99070@mdounin.ru> Изменения в nginx 1.15.7 27.11.2018 *) Добавление: директива proxy_requests в модуле stream. *) Добавление: параметр "delay" директивы "limit_req". Спасибо Владиславу Шабанову и Петру Щучкину. *) Исправление: утечки памяти в случае ошибок при переконфигурации. *) Исправление: в переменных $upstream_response_time, $upstream_connect_time и $upstream_header_time. *) Исправление: в рабочем процессе мог произойти segmentation fault, если использовался модуль ngx_http_mp4_module на 32-битных платформах. -- Maxim Dounin http://nginx.org/ From vovansystems на gmail.com Tue Nov 27 21:45:27 2018 From: vovansystems на gmail.com (VovansystemS) Date: Wed, 28 Nov 2018 00:45:27 +0300 Subject: nginx-1.15.7 In-Reply-To: <20181127150231.GT99070@mdounin.ru> References: <20181127150231.GT99070@mdounin.ru> Message-ID: Добрый вечер, > *) Добавление: параметр "delay" директивы "limit_req". > Спасибо Владиславу Шабанову и Петру Щучкину. прочитал документацию несколько раз, но мне кажется я так и не понял как именно работает delay: > Если же избыточные запросы в пределах лимита всплесков > задерживать не требуется, то следует использовать параметр nodelay: > limit_req zone=one burst=5 nodelay; > Параметр delay (1.15.7) задаёт лимит, по достижении которого > избыточные запросы задерживаются. > Значение по умолчанию равно нулю и означает, > что задерживаются все избыточные запросы. Не могли бы Вы привести пример и объяснить это подробнее? Правильно ли я понимаю, что при limit_req zone=one burst=5 delay=5; пять первых запросов отправленные в ту же секунду к серверу будут обслужены сразу же, а шестой и последующие уже будут завершены с ошибкой, если скорость поступления запросов превышает описанную в зоне? From pluknet на nginx.com Tue Nov 27 22:47:54 2018 From: pluknet на nginx.com (Sergey Kandaurov) Date: Wed, 28 Nov 2018 01:47:54 +0300 Subject: nginx-1.15.7 In-Reply-To: References: <20181127150231.GT99070@mdounin.ru> Message-ID: <663D89F9-9893-4E46-BECB-11B574C1D33F@nginx.com> > On 28 Nov 2018, at 00:45, VovansystemS wrote: > > Добрый вечер, > >> *) Добавление: параметр "delay" директивы "limit_req". >> Спасибо Владиславу Шабанову и Петру Щучкину. > > прочитал документацию несколько раз, но мне кажется я так и не понял > как именно работает delay: > >> Если же избыточные запросы в пределах лимита всплесков >> задерживать не требуется, то следует использовать параметр nodelay: >> limit_req zone=one burst=5 nodelay; >> Параметр delay (1.15.7) задаёт лимит, по достижении которого >> избыточные запросы задерживаются. >> Значение по умолчанию равно нулю и означает, >> что задерживаются все избыточные запросы. > > Не могли бы Вы привести пример и объяснить это подробнее? > Следует читать так: : Избыточные запросы задерживаются до тех пор, пока их число не превысит : максимальный размер всплеска. И далее: : Параметр delay (1.15.7) задаёт лимит, по достижении которого избыточные : запросы задерживаются. Т.е. параметр имеет смысл при условии delay < burst. > Правильно ли я понимаю, что при > limit_req zone=one burst=5 delay=5; > пять первых запросов отправленные в ту же секунду к серверу будут > обслужены сразу же, > а шестой и последующие уже будут завершены с ошибкой, > если скорость поступления запросов превышает описанную в зоне? Это эквивалентно limit_req zone=one burst=5 nodelay; Следовательно, шестой и последующие будут отклонены. -- Sergey Kandaurov From vladget на gmail.com Wed Nov 28 16:20:12 2018 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Wed, 28 Nov 2018 18:20:12 +0200 Subject: SSL lags Message-ID: Странная ситуация с SSL - жуткий лаг на отдаче: # curl -w "time_connect: %{time_connect}\ntime_total: %{time_total}\n" -X GET -s -q http://1.1.1.1/google663dfea033864f54.html -o /dev/null time_connect: 0.000 time_total: 0.001 # curl -w "time_connect: %{time_connect}\ntime_total: %{time_total}\n" -X GET -s -q https://1.1.1.1/google663dfea033864f54.html --insecure -o /dev/null time_connect: 0.000 time_total: *0.106* # nginx -V nginx version: nginx/1.14.1 built by gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9) built with OpenSSL 1.0.2g 1 Mar 2016 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --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-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' # cat /etc/nginx/conf.d/ssl.conf ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_dhparam /etc/nginx/ssl/dhparam.pem; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_session_timeout 1d; ssl_session_cache shared:SSL:1024m; ssl_stapling on; ssl_stapling_verify on; -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Nov 28 17:06:52 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 28 Nov 2018 20:06:52 +0300 Subject: SSL lags In-Reply-To: References: Message-ID: <20181128170652.GC99070@mdounin.ru> Hello! On Wed, Nov 28, 2018 at 06:20:12PM +0200, Vladimir Getmanshchuk wrote: > Странная ситуация с SSL - жуткий лаг на отдаче: > > > # curl -w "time_connect: %{time_connect}\ntime_total: %{time_total}\n" -X > GET -s -q http://1.1.1.1/google663dfea033864f54.html -o /dev/null > > time_connect: 0.000 > > time_total: 0.001 > > > # curl -w "time_connect: %{time_connect}\ntime_total: %{time_total}\n" -X > GET -s -q https://1.1.1.1/google663dfea033864f54.html --insecure -o > /dev/null > > time_connect: 0.000 > > time_total: *0.106* В SSL есть операция SSL handshake, и в зависимости от используемых шифров и сертификатов - она может занимать как просто много времени, так и очень много времени. (Ну и поскольку curl между запусками не может сохранять ранее установленную сессию - каждый запуск будет требовать полного handshake'а.) В частности, если вдруг используется обмен ключами с помощью алгоритма Диффи-Хеллмана - будет тормозить. Особенно если задать параметры где-нибудь на 4096 бит. Смотрите внимательно, что именно за шифры у вас используются, и если DHE - то что именно у вас лежит в ssl_dhparam. Ну или просто уберите ssl_dhparam из конфига - по умолчанию nginx просто не будет использовать DHE. Кроме того, будет тормозить, если используются RSA-сертификаты больше 2048 бит. Смотрите, что за сертификат используется. RSA-сертификаты на 4096 бит - зачастую по умолчанию прилетают из модных и молодёжных инструментов получения сертификатов от LetsEncrypt, но малопригодны для работы web-сервера. -- Maxim Dounin http://mdounin.ru/ From vladget на gmail.com Wed Nov 28 17:48:54 2018 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Wed, 28 Nov 2018 19:48:54 +0200 Subject: SSL lags In-Reply-To: <20181128170652.GC99070@mdounin.ru> References: <20181128170652.GC99070@mdounin.ru> Message-ID: Максим, спасибо за ответ! Сертификат действительно от LetsEncrypt, отключение ssl_dhparam не помогло, на подобном сервере тоже с LetsEncrypt тем же curl: time_connect: 0.010 Подскажите куда можно еще глянуть? Могу прислать debug или strace или что еще... On Wed, Nov 28, 2018 at 7:07 PM Maxim Dounin wrote: > Hello! > > On Wed, Nov 28, 2018 at 06:20:12PM +0200, Vladimir Getmanshchuk wrote: > > > Странная ситуация с SSL - жуткий лаг на отдаче: > > > > > > # curl -w "time_connect: %{time_connect}\ntime_total: %{time_total}\n" -X > > GET -s -q http://1.1.1.1/google663dfea033864f54.html -o /dev/null > > > > time_connect: 0.000 > > > > time_total: 0.001 > > > > > > # curl -w "time_connect: %{time_connect}\ntime_total: %{time_total}\n" -X > > GET -s -q https://1.1.1.1/google663dfea033864f54.html --insecure -o > > /dev/null > > > > time_connect: 0.000 > > > > time_total: *0.106* > > В SSL есть операция SSL handshake, и в зависимости от используемых > шифров и сертификатов - она может занимать как просто много > времени, так и очень много времени. (Ну и поскольку curl между > запусками не может сохранять ранее установленную сессию - каждый > запуск будет требовать полного handshake'а.) > > В частности, если вдруг используется обмен ключами с помощью > алгоритма Диффи-Хеллмана - будет тормозить. Особенно если задать > параметры где-нибудь на 4096 бит. Смотрите внимательно, что > именно за шифры у вас используются, и если DHE - то что именно у > вас лежит в ssl_dhparam. Ну или просто уберите ssl_dhparam из > конфига - по умолчанию nginx просто не будет использовать DHE. > > Кроме того, будет тормозить, если используются RSA-сертификаты > больше 2048 бит. Смотрите, что за сертификат используется. > RSA-сертификаты на 4096 бит - зачастую по умолчанию прилетают из > модных и молодёжных инструментов получения сертификатов от > LetsEncrypt, но малопригодны для работы web-сервера. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Nov 28 19:09:39 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 28 Nov 2018 22:09:39 +0300 Subject: SSL lags In-Reply-To: References: <20181128170652.GC99070@mdounin.ru> Message-ID: <20181128190939.GD99070@mdounin.ru> Hello! On Wed, Nov 28, 2018 at 07:48:54PM +0200, Vladimir Getmanshchuk wrote: > Максим, спасибо за ответ! > > Сертификат действительно от LetsEncrypt, > отключение ssl_dhparam не помогло, на подобном сервере тоже с LetsEncrypt > тем же curl: > time_connect: 0.010 Время time_connect - это время установления TCP-соединения, и в контексте исходного вопроса не интересно совершенно, в обоих приведённых в исходном письме примерах оно просто 0. Сравнивать имеет смысл time_total. > Подскажите куда можно еще глянуть? > Могу прислать debug или strace или что еще... Для начала - как уже было предложено, глянуть в сертификат ("openssl x509 -text -noout -in /path/to/cert.pem") и посмотреть, какой алгоритм используется и сколько бит ключ. Если RSA и больше 2048 бит - поменять на 2048 бит или ECDSA. Если не поможет - имеет смысл снять дамп трафика с помощью tcpdump'а и посмотреть, где именно тратится время. Возможно, из-за чего-то вылезают сетевые проблемы, или проблема вообще на стороне клиента. -- Maxim Dounin http://mdounin.ru/ From skom на skom.ru Wed Nov 28 20:31:31 2018 From: skom на skom.ru (Sergey Komarov) Date: Wed, 28 Nov 2018 23:31:31 +0300 Subject: SSL lags In-Reply-To: <20181128170652.GC99070@mdounin.ru> References: <20181128170652.GC99070@mdounin.ru> Message-ID: <283db2ae-f3c7-e74e-1758-b01573d4fbe9@skom.ru> Здравствуйте, Простите за, возможно, глупый вопрос. Правильно ли я понимаю, что для выключения ДХ в nginx необходимо только выключить ssl_dhparams? Или же, нужно в ssl_ciphers выпилить все ECDHE и DHE? Best Regards Sergey Komarov 28.11.2018 20:06, Maxim Dounin пишет: > Hello! > > On Wed, Nov 28, 2018 at 06:20:12PM +0200, Vladimir Getmanshchuk wrote: > >> Странная ситуация с SSL - жуткий лаг на отдаче: >> >> >> # curl -w "time_connect: %{time_connect}\ntime_total: %{time_total}\n" -X >> GET -s -q http://1.1.1.1/google663dfea033864f54.html -o /dev/null >> >> time_connect: 0.000 >> >> time_total: 0.001 >> >> >> # curl -w "time_connect: %{time_connect}\ntime_total: %{time_total}\n" -X >> GET -s -q https://1.1.1.1/google663dfea033864f54.html --insecure -o >> /dev/null >> >> time_connect: 0.000 >> >> time_total: *0.106* > В SSL есть операция SSL handshake, и в зависимости от используемых > шифров и сертификатов - она может занимать как просто много > времени, так и очень много времени. (Ну и поскольку curl между > запусками не может сохранять ранее установленную сессию - каждый > запуск будет требовать полного handshake'а.) > > В частности, если вдруг используется обмен ключами с помощью > алгоритма Диффи-Хеллмана - будет тормозить. Особенно если задать > параметры где-нибудь на 4096 бит. Смотрите внимательно, что > именно за шифры у вас используются, и если DHE - то что именно у > вас лежит в ssl_dhparam. Ну или просто уберите ssl_dhparam из > конфига - по умолчанию nginx просто не будет использовать DHE. > > Кроме того, будет тормозить, если используются RSA-сертификаты > больше 2048 бит. Смотрите, что за сертификат используется. > RSA-сертификаты на 4096 бит - зачастую по умолчанию прилетают из > модных и молодёжных инструментов получения сертификатов от > LetsEncrypt, но малопригодны для работы web-сервера. > From marck на rinet.ru Wed Nov 28 21:42:48 2018 From: marck на rinet.ru (Dmitry Morozovsky) Date: Thu, 29 Nov 2018 00:42:48 +0300 (MSK) Subject: SSL lags In-Reply-To: <283db2ae-f3c7-e74e-1758-b01573d4fbe9@skom.ru> References: <20181128170652.GC99070@mdounin.ru> <283db2ae-f3c7-e74e-1758-b01573d4fbe9@skom.ru> Message-ID: On Wed, 28 Nov 2018, Sergey Komarov wrote: > Простите за, возможно, глупый вопрос. > Правильно ли я понимаю, что для выключения ДХ в nginx необходимо только > выключить ssl_dhparams? > Или же, нужно в ssl_ciphers выпилить все ECDHE и DHE? кажется, в современном мире ECD* как раз надо удерживать (в паре с RSA2048, чтоб совместимость была приемлемой) [snip] -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck на FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck на rinet.ru *** ------------------------------------------------------------------------ From pluknet на nginx.com Wed Nov 28 21:47:48 2018 From: pluknet на nginx.com (Sergey Kandaurov) Date: Thu, 29 Nov 2018 00:47:48 +0300 Subject: SSL lags In-Reply-To: <283db2ae-f3c7-e74e-1758-b01573d4fbe9@skom.ru> References: <20181128170652.GC99070@mdounin.ru> <283db2ae-f3c7-e74e-1758-b01573d4fbe9@skom.ru> Message-ID: > On 28 Nov 2018, at 23:31, Sergey Komarov wrote: > > Здравствуйте, > Простите за, возможно, глупый вопрос. > Правильно ли я понимаю, что для выключения ДХ в nginx необходимо только выключить ssl_dhparams? Не совсем так, см. http://nginx.org/r/ssl_dhparam Более полный ответ здесь: https://www.mail-archive.com/openssl-users на openssl.org/msg71878.html https://tools.ietf.org/html/rfc5246#section-7.4.3 > Или же, нужно в ssl_ciphers выпилить все ECDHE и DHE? -- Sergey Kandaurov From vladget на gmail.com Thu Nov 29 10:44:05 2018 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Thu, 29 Nov 2018 12:44:05 +0200 Subject: SSL lags In-Reply-To: <20181128190939.GD99070@mdounin.ru> References: <20181128170652.GC99070@mdounin.ru> <20181128190939.GD99070@mdounin.ru> Message-ID: Очень похоже это какой-то глюк curl(запускаю с той же машины), я тут случайно сделал time wget https://server/object, и вот что получил: WGET real 0m0.004s (http) real 0m0.012s (https) CURL real 0m0.012s (http) real 0m0.139s (https) On Wed, Nov 28, 2018 at 9:09 PM Maxim Dounin wrote: > Hello! > > On Wed, Nov 28, 2018 at 07:48:54PM +0200, Vladimir Getmanshchuk wrote: > > > Максим, спасибо за ответ! > > > > Сертификат действительно от LetsEncrypt, > > отключение ssl_dhparam не помогло, на подобном сервере тоже с LetsEncrypt > > тем же curl: > > time_connect: 0.010 > > Время time_connect - это время установления TCP-соединения, и в > контексте исходного вопроса не интересно совершенно, в обоих > приведённых в исходном письме примерах оно просто 0. Сравнивать > имеет смысл time_total. > > > Подскажите куда можно еще глянуть? > > Могу прислать debug или strace или что еще... > > Для начала - как уже было предложено, глянуть в сертификат > ("openssl x509 -text -noout -in /path/to/cert.pem") и посмотреть, > какой алгоритм используется и сколько бит ключ. Если RSA и больше > 2048 бит - поменять на 2048 бит или ECDSA. > > Если не поможет - имеет смысл снять дамп трафика с помощью > tcpdump'а и посмотреть, где именно тратится время. Возможно, > из-за чего-то вылезают сетевые проблемы, или проблема вообще на > стороне клиента. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Nov 29 11:09:09 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 29 Nov 2018 16:09:09 +0500 Subject: SSL lags In-Reply-To: References: <20181128170652.GC99070@mdounin.ru> <20181128190939.GD99070@mdounin.ru> Message-ID: так срисуйте tcpdump/wireshark оно же с раскладкой по времени все пакеты покажет (в случае https прекрасно видна стадия установки соединения) чт, 29 нояб. 2018 г. в 15:44, Vladimir Getmanshchuk : > Очень похоже это какой-то глюк curl(запускаю с той же машины), > я тут случайно сделал time wget https://server/object, и вот что получил: > > WGET > real 0m0.004s (http) > real 0m0.012s (https) > CURL > real 0m0.012s (http) > real 0m0.139s (https) > > On Wed, Nov 28, 2018 at 9:09 PM Maxim Dounin wrote: > >> Hello! >> >> On Wed, Nov 28, 2018 at 07:48:54PM +0200, Vladimir Getmanshchuk wrote: >> >> > Максим, спасибо за ответ! >> > >> > Сертификат действительно от LetsEncrypt, >> > отключение ssl_dhparam не помогло, на подобном сервере тоже с >> LetsEncrypt >> > тем же curl: >> > time_connect: 0.010 >> >> Время time_connect - это время установления TCP-соединения, и в >> контексте исходного вопроса не интересно совершенно, в обоих >> приведённых в исходном письме примерах оно просто 0. Сравнивать >> имеет смысл time_total. >> >> > Подскажите куда можно еще глянуть? >> > Могу прислать debug или strace или что еще... >> >> Для начала - как уже было предложено, глянуть в сертификат >> ("openssl x509 -text -noout -in /path/to/cert.pem") и посмотреть, >> какой алгоритм используется и сколько бит ключ. Если RSA и больше >> 2048 бит - поменять на 2048 бит или ECDSA. >> >> Если не поможет - имеет смысл снять дамп трафика с помощью >> tcpdump'а и посмотреть, где именно тратится время. Возможно, >> из-за чего-то вылезают сетевые проблемы, или проблема вообще на >> стороне клиента. >> >> -- >> Maxim Dounin >> http://mdounin.ru/ >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > Yours sincerely, > Vladimir Getmanshchuk > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vladget на gmail.com Thu Nov 29 11:54:34 2018 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Thu, 29 Nov 2018 13:54:34 +0200 Subject: SSL lags In-Reply-To: References: <20181128170652.GC99070@mdounin.ru> <20181128190939.GD99070@mdounin.ru> Message-ID: Ага, спасибо, че-то я сам всем советую, а сам забываю... Вообщем после TCP handshake 0.1s пауза от curl, а потом только TSLv1.2 Client Hello On Thu, Nov 29, 2018 at 1:09 PM Илья Шипицин wrote: > так срисуйте tcpdump/wireshark > оно же с раскладкой по времени все пакеты покажет > > (в случае https прекрасно видна стадия установки соединения) > > чт, 29 нояб. 2018 г. в 15:44, Vladimir Getmanshchuk : > >> Очень похоже это какой-то глюк curl(запускаю с той же машины), >> я тут случайно сделал time wget https://server/object, и вот что получил: >> >> WGET >> real 0m0.004s (http) >> real 0m0.012s (https) >> CURL >> real 0m0.012s (http) >> real 0m0.139s (https) >> >> On Wed, Nov 28, 2018 at 9:09 PM Maxim Dounin wrote: >> >>> Hello! >>> >>> On Wed, Nov 28, 2018 at 07:48:54PM +0200, Vladimir Getmanshchuk wrote: >>> >>> > Максим, спасибо за ответ! >>> > >>> > Сертификат действительно от LetsEncrypt, >>> > отключение ssl_dhparam не помогло, на подобном сервере тоже с >>> LetsEncrypt >>> > тем же curl: >>> > time_connect: 0.010 >>> >>> Время time_connect - это время установления TCP-соединения, и в >>> контексте исходного вопроса не интересно совершенно, в обоих >>> приведённых в исходном письме примерах оно просто 0. Сравнивать >>> имеет смысл time_total. >>> >>> > Подскажите куда можно еще глянуть? >>> > Могу прислать debug или strace или что еще... >>> >>> Для начала - как уже было предложено, глянуть в сертификат >>> ("openssl x509 -text -noout -in /path/to/cert.pem") и посмотреть, >>> какой алгоритм используется и сколько бит ключ. Если RSA и больше >>> 2048 бит - поменять на 2048 бит или ECDSA. >>> >>> Если не поможет - имеет смысл снять дамп трафика с помощью >>> tcpdump'а и посмотреть, где именно тратится время. Возможно, >>> из-за чего-то вылезают сетевые проблемы, или проблема вообще на >>> стороне клиента. >>> >>> -- >>> Maxim Dounin >>> http://mdounin.ru/ >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> >> -- >> Yours sincerely, >> Vladimir Getmanshchuk >> _______________________________________________ >> 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 -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Nov 29 14:18:44 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 29 Nov 2018 17:18:44 +0300 Subject: SSL lags In-Reply-To: <283db2ae-f3c7-e74e-1758-b01573d4fbe9@skom.ru> References: <20181128170652.GC99070@mdounin.ru> <283db2ae-f3c7-e74e-1758-b01573d4fbe9@skom.ru> Message-ID: <20181129141843.GH99070@mdounin.ru> Hello! On Wed, Nov 28, 2018 at 11:31:31PM +0300, Sergey Komarov wrote: > Здравствуйте, > Простите за, возможно, глупый вопрос. > Правильно ли я понимаю, что для выключения ДХ в nginx необходимо только > выключить ssl_dhparams? > Или же, нужно в ssl_ciphers выпилить все ECDHE и DHE? ECDHE выпиливать вообще не нужно, ECDHE - это Elliptic Curve Diffie-Hellman и работает быстро. Для выпиливания классического Диффи-Хеллмана - да, достаточно убрать из конфига директиву ssl_dhparam. До версии nginx 1.11.0 в случае отсутствия в конфиге ssl_dhparam использовались стандартные вкомпилированные в nginx параметры на 1024 бита. В nginx 1.11.0 мы эти стандартные параметры убрали - потому что стандартные параметры могут быть проблемой, см. weakdh.org, и потому что увеличивать битность - это в случае классического DH очень медленно. Так что теперь DHE-шифры используются только если в конфиге явно задать ssl_dhparam. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Thu Nov 29 14:33:22 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 29 Nov 2018 17:33:22 +0300 Subject: SSL lags In-Reply-To: References: <20181128170652.GC99070@mdounin.ru> <283db2ae-f3c7-e74e-1758-b01573d4fbe9@skom.ru> Message-ID: <20181129143322.GI99070@mdounin.ru> Hello! On Thu, Nov 29, 2018 at 12:47:48AM +0300, Sergey Kandaurov wrote: > > On 28 Nov 2018, at 23:31, Sergey Komarov wrote: > > > > Здравствуйте, > > Простите за, возможно, глупый вопрос. > > Правильно ли я понимаю, что для выключения ДХ в nginx необходимо только выключить ssl_dhparams? > > Не совсем так, см. http://nginx.org/r/ssl_dhparam > > Более полный ответ здесь: > https://www.mail-archive.com/openssl-users на openssl.org/msg71878.html > https://tools.ietf.org/html/rfc5246#section-7.4.3 Серёж, вот лично я - не понял, что ты хотел сказать этими ссылками, и в чём именно заключается "не совсем так". Поясни? Или ты про то, что DH может работать без явного задания ssl_dhparam в случае использования DH-сертификатов aka fixed-DH? (И, кстати, у нас в документации по первой ссылке - отсутствует какое-либо описание того, что встроенные параметры мы выпили в 1.11.0. Наверное, его туда надо добавить.) -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Thu Nov 29 14:59:09 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 29 Nov 2018 16:59:09 +0200 Subject: =?UTF-8?B?0JTQvtC60YPQvNC10L3RgtCw0YbQuNGPINC6INC00LjRgNC10LrRgtC40LLQtSBm?= =?UTF-8?B?YXN0Y2dpX2NhY2hlX2tleQ==?= Message-ID: <65806589-b909-0ae2-fa6a-dfaf6e2920a3@csdoc.com> Здравствуйте, All! В документации к директиве fastcgi_cache_key приведен такой пример: fastcgi_cache_key localhost:9000$request_uri; У этого примера есть несколько проблем: 1. Если кто-то сделает к бекенду HEAD-запрос, то в кеш запишется пустой ответ и на последующие GET-запросы будет отдаваться пустая страница. 2. Как правило на современных серверах размещено больше одного сайта. При такой настройке как рекомендуется в документации - кеш будет представлять собой смесь из содержимого разных сайтов и нормально работать не будет. 3. если бекенд возвращает для HTTP-версии сайта редирект на HTTPS версию сайта, такое значение fastcgi_cache_key бужет приводить к проблемам, так как для HTTPS-запроса будет возвращаться 301 редирект из кеша. Можно ли исправить документацию и написать там в качестве примера такой фрагмент: fastcgi_cache_key "$request_method $scheme://$host$request_uri"; такая директива работает нормально, нет трех вышеперечисленных проблем. P.S. Недавно в очередной раз столкнулся в проблемой, когда люди бездумно копируют в конфиг рекомендуемые варианты директивы fastcgi_cache_key из документации, не подозревая, что в документации записано в качестве рекомендуемого варианта то, что нормально работать у них не будет. -- Best regards, Gena From chipitsine на gmail.com Thu Nov 29 15:00:59 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 29 Nov 2018 20:00:59 +0500 Subject: SSL lags In-Reply-To: References: <20181128170652.GC99070@mdounin.ru> <20181128190939.GD99070@mdounin.ru> Message-ID: Кароч, мы ждём вторую серию)) On Thu, Nov 29, 2018, 4:54 PM Vladimir Getmanshchuk Ага, спасибо, че-то я сам всем советую, а сам забываю... > Вообщем после TCP handshake 0.1s пауза от curl, а потом только TSLv1.2 > Client Hello > > On Thu, Nov 29, 2018 at 1:09 PM Илья Шипицин wrote: > >> так срисуйте tcpdump/wireshark >> оно же с раскладкой по времени все пакеты покажет >> >> (в случае https прекрасно видна стадия установки соединения) >> >> чт, 29 нояб. 2018 г. в 15:44, Vladimir Getmanshchuk : >> >>> Очень похоже это какой-то глюк curl(запускаю с той же машины), >>> я тут случайно сделал time wget https://server/object, и вот что >>> получил: >>> >>> WGET >>> real 0m0.004s (http) >>> real 0m0.012s (https) >>> CURL >>> real 0m0.012s (http) >>> real 0m0.139s (https) >>> >>> On Wed, Nov 28, 2018 at 9:09 PM Maxim Dounin wrote: >>> >>>> Hello! >>>> >>>> On Wed, Nov 28, 2018 at 07:48:54PM +0200, Vladimir Getmanshchuk wrote: >>>> >>>> > Максим, спасибо за ответ! >>>> > >>>> > Сертификат действительно от LetsEncrypt, >>>> > отключение ssl_dhparam не помогло, на подобном сервере тоже с >>>> LetsEncrypt >>>> > тем же curl: >>>> > time_connect: 0.010 >>>> >>>> Время time_connect - это время установления TCP-соединения, и в >>>> контексте исходного вопроса не интересно совершенно, в обоих >>>> приведённых в исходном письме примерах оно просто 0. Сравнивать >>>> имеет смысл time_total. >>>> >>>> > Подскажите куда можно еще глянуть? >>>> > Могу прислать debug или strace или что еще... >>>> >>>> Для начала - как уже было предложено, глянуть в сертификат >>>> ("openssl x509 -text -noout -in /path/to/cert.pem") и посмотреть, >>>> какой алгоритм используется и сколько бит ключ. Если RSA и больше >>>> 2048 бит - поменять на 2048 бит или ECDSA. >>>> >>>> Если не поможет - имеет смысл снять дамп трафика с помощью >>>> tcpdump'а и посмотреть, где именно тратится время. Возможно, >>>> из-за чего-то вылезают сетевые проблемы, или проблема вообще на >>>> стороне клиента. >>>> >>>> -- >>>> Maxim Dounin >>>> http://mdounin.ru/ >>>> _______________________________________________ >>>> nginx-ru mailing list >>>> nginx-ru на nginx.org >>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >>> >>> >>> -- >>> Yours sincerely, >>> Vladimir Getmanshchuk >>> _______________________________________________ >>> 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 > > > > -- > Yours sincerely, > Vladimir Getmanshchuk > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From pluknet на nginx.com Thu Nov 29 15:03:32 2018 From: pluknet на nginx.com (Sergey Kandaurov) Date: Thu, 29 Nov 2018 18:03:32 +0300 Subject: SSL lags In-Reply-To: <20181129143322.GI99070@mdounin.ru> References: <20181128170652.GC99070@mdounin.ru> <283db2ae-f3c7-e74e-1758-b01573d4fbe9@skom.ru> <20181129143322.GI99070@mdounin.ru> Message-ID: > On 29 Nov 2018, at 17:33, Maxim Dounin wrote: > > Hello! > > On Thu, Nov 29, 2018 at 12:47:48AM +0300, Sergey Kandaurov wrote: > >>> On 28 Nov 2018, at 23:31, Sergey Komarov wrote: >>> >>> Здравствуйте, >>> Простите за, возможно, глупый вопрос. >>> Правильно ли я понимаю, что для выключения ДХ в nginx необходимо только выключить ssl_dhparams? >> >> Не совсем так, см. http://nginx.org/r/ssl_dhparam >> >> Более полный ответ здесь: >> https://www.mail-archive.com/openssl-users на openssl.org/msg71878.html >> https://tools.ietf.org/html/rfc5246#section-7.4.3 > > Серёж, вот лично я - не понял, что ты хотел сказать этими > ссылками, и в чём именно заключается "не совсем так". Поясни? > Или ты про то, что DH может работать без явного задания > ssl_dhparam в случае использования DH-сертификатов aka fixed-DH? > Да, про fixed-DH (при котором параметры отсылаются в сертификате). Первая ссылка про уточнение, что директива относится к DHE-шифрам. В остальных бекграунд вопроса: какие бывают DH и зачем это нужно. К слову, параметры с большой битностью не всегда хорошо. E.g., Java до некоторых пор не умела параметры больше 1024: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8137303 -- Sergey Kandaurov From mdounin на mdounin.ru Thu Nov 29 16:30:17 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 29 Nov 2018 19:30:17 +0300 Subject: =?UTF-8?B?UmU6INCU0L7QutGD0LzQtdC90YLQsNGG0LjRjyDQuiDQtNC40YDQtdC60YLQuNCy?= =?UTF-8?B?0LUgZmFzdGNnaV9jYWNoZV9rZXk=?= In-Reply-To: <65806589-b909-0ae2-fa6a-dfaf6e2920a3@csdoc.com> References: <65806589-b909-0ae2-fa6a-dfaf6e2920a3@csdoc.com> Message-ID: <20181129163017.GL99070@mdounin.ru> Hello! On Thu, Nov 29, 2018 at 04:59:09PM +0200, Gena Makhomed wrote: > Здравствуйте, All! > > В документации к директиве fastcgi_cache_key приведен такой пример: > > fastcgi_cache_key localhost:9000$request_uri; > > У этого примера есть несколько проблем: > > 1. Если кто-то сделает к бекенду HEAD-запрос, то в кеш запишется пустой > ответ и на последующие GET-запросы будет отдаваться пустая страница. AFAIK, никакой специальной обработки HEAD-запросов в FastCGI не предусмотрено. И в том числе не предсмотрено в каком-нибудь PHP из коробки. Соответственно всё будет работать штатно. Речь про какие-то фреймворки, которые обрабатывают HEAD автоматически, не донося соответствующую информацию до кода? Или про какой-то стандартный софт, который не возвращает тело для HEAD-запросов? Отдельно отмечу, что правильный вариант работы с HEAD-запросами для целей кэширования - это отправлять на бэкенд GET-запросы, и кэшировать ответ. Именно так делает proxy-модуль. В случае FastCGI подобная автоматическая конвертация не работает, так как метод запроса не отправляется на бэкенд иначе как через произвольно заданный fastcgi_param, да и сама конвертация представляется ненужной, так как в типичном случае ответы на HEAD-запросы не отличаются от таковых на GET-запросы. Однако если вдруг она нужна - это можно сделать, просто передав в fastcgi_param GET вместо HEAD. > 2. Как правило на современных серверах размещено больше одного сайта. > При такой настройке как рекомендуется в документации - кеш будет > представлять собой смесь из содержимого разных сайтов и нормально > работать не будет. Вопрос тут в том, что именно является идентификатором запрашиваемого ресурса. Пример в документации предполагает, что мы коннектимся на localhost:9000, и получаем там ответы, идентифицируемые URI запроса. Это в общем случае верно для конфигурации, которая приводится в описании модуля fastcgi, и с этой конфигурацией приведённый пример fastcgi_cache_key будет работать корректно. Если конфигурация другая - fastcgi_cache_key может потребоваться другой. Однако проблема в том, что без знания конфигурации - неизвестно, какой именно fastcgi_cache_key потребуется. > 3. если бекенд возвращает для HTTP-версии сайта редирект на HTTPS версию > сайта, такое значение fastcgi_cache_key бужет приводить к проблемам, > так как для HTTPS-запроса будет возвращаться 301 редирект из кеша. > > Можно ли исправить документацию и написать там в качестве примера > такой фрагмент: > > fastcgi_cache_key "$request_method $scheme://$host$request_uri"; > > такая директива работает нормально, нет трех вышеперечисленных проблем. Ключём кэширования должен выступать идентификатор ресурса, который запрашивается с бэкенда. В предложенном варианте - отсутствует какая-либо информация о бэкенде вообще, так что он представляется мне идеалогически неверным. У нас, конечно, уже есть подобная конструкция в описании proxy_cach_key, но там за счёт $cookie_user куда более очевидно, что это именно пример, а не что-то, отлитое в граните и пригодное для всех конфигов. Возможно, по какому-то такому пути и стоит пойти. > P.S. > > Недавно в очередной раз столкнулся в проблемой, когда люди бездумно > копируют в конфиг рекомендуемые варианты директивы fastcgi_cache_key > из документации, не подозревая, что в документации записано в качестве > рекомендуемого варианта то, что нормально работать у них не будет. Кажется, что правильным будет для начала написать в описании fastcgi_cache_key (uwsgi_cache_key, scgi_cache_key), что ключ должен идентифицировать запрашиваемый ресурс, а не ставится "абы как, авось повезёт". -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Thu Nov 29 18:35:18 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 29 Nov 2018 20:35:18 +0200 Subject: =?UTF-8?B?UmU6INCU0L7QutGD0LzQtdC90YLQsNGG0LjRjyDQuiDQtNC40YDQtdC60YLQuNCy?= =?UTF-8?B?0LUgZmFzdGNnaV9jYWNoZV9rZXk=?= In-Reply-To: <20181129163017.GL99070@mdounin.ru> References: <65806589-b909-0ae2-fa6a-dfaf6e2920a3@csdoc.com> <20181129163017.GL99070@mdounin.ru> Message-ID: <08f691cf-3d76-9223-6d23-4a83c20ff585@csdoc.com> On 29.11.2018 18:30, Maxim Dounin wrote: >> В документации к директиве fastcgi_cache_key приведен такой пример: >> >> fastcgi_cache_key localhost:9000$request_uri; >> >> У этого примера есть несколько проблем: >> >> 1. Если кто-то сделает к бекенду HEAD-запрос, то в кеш запишется пустой >> ответ и на последующие GET-запросы будет отдаваться пустая страница. > AFAIK, никакой специальной обработки HEAD-запросов в FastCGI не > предусмотрено. И в том числе не предсмотрено в каком-нибудь PHP > из коробки. Соответственно всё будет работать штатно. Специальная обработка HEAD-запросов предусмотрена в HTTP протоколе: https://tools.ietf.org/html/rfc7231#section-4.3.2 The HEAD method is identical to GET except that the server MUST NOT send a message body in the response (i.e., the response terminates at the end of the header section). В nginx присутствует workaround, который исправляет поведение бекендов, которые на HEAD-запрос *ошибочно* отвечают так же, как и на GET-запрос. Но далеко не все бекенды содержат в себе эту ошибку, многие из них ведут себя именно так, как этого от них требует спецификация HTTP протокола. > Речь про какие-то фреймворки, которые обрабатывают > HEAD автоматически, не донося соответствующую информацию до кода? > Или про какой-то стандартный софт, который не возвращает тело для > HEAD-запросов? Какая разница, сам софт или фрейморк используемый софтом в каждом конкретном случае обрабатывает HEAD запросы согласно требований RFC? Эта проблема встречается не только у меня, вот например: https://www.claudiokuenzler.com/blog/705/empty-blank-page-nginx-fastcgi-cache-head-get https://serverfault.com/a/612729 > Отдельно отмечу, что правильный вариант работы с HEAD-запросами > для целей кэширования - это отправлять на бэкенд GET-запросы, и > кэшировать ответ. Именно так делает proxy-модуль. В proxy модуле есть директива proxy_cache_convert_head, которая имеет значение on по-умолчанию, поэтому там все работает нормально. В fastcgi/uwsgi/scgi модулях аналогичной директивы нет. > В случае > FastCGI подобная автоматическая конвертация не работает, так как > метод запроса не отправляется на бэкенд иначе как через > произвольно заданный fastcgi_param, Нет. FastCGI - это расширение протокола CGI, а протокол CGI *требует*, чтобы параметр REQUEST_METHOD присутствовал в каждом запросе: https://tools.ietf.org/html/rfc3875#section-4.1.12 The REQUEST_METHOD meta-variable MUST be set to the method which should be used by the script to process the request, as described in section 4.3. REQUEST_METHOD = method method = "GET" | "POST" | "HEAD" | extension-method extension-method = "PUT" | "DELETE" | token > да и сама конвертация > представляется ненужной, так как в типичном случае ответы на > HEAD-запросы не отличаются от таковых на GET-запросы. Но ведь не все бекенды нарушают требование HTTP протокола, есть и такие, которые обрабатывают HEAD-запросы правильно. > Однако если > вдруг она нужна - это можно сделать, просто передав в > fastcgi_param GET вместо HEAD. Можете привести фрагмент конфига, как это можно сделать? >> 2. Как правило на современных серверах размещено больше одного сайта. >> При такой настройке как рекомендуется в документации - кеш будет >> представлять собой смесь из содержимого разных сайтов и нормально >> работать не будет. > Вопрос тут в том, что именно является идентификатором > запрашиваемого ресурса. Пример в документации предполагает, что > мы коннектимся на localhost:9000, и получаем там ответы, > идентифицируемые URI запроса. Идентификатором ресурса является https://en.wikipedia.org/wiki/URI который включает в себя и scheme и host и path[?query] ($request_uri) > Это в общем случае верно для конфигурации, которая приводится в > описании модуля fastcgi, и с этой конфигурацией приведённый пример > fastcgi_cache_key будет работать корректно. Если конфигурация > другая - fastcgi_cache_key может потребоваться другой. Однако > проблема в том, что без знания конфигурации - неизвестно, какой > именно fastcgi_cache_key потребуется. Поэтому я и предлагаю написать в документации пример директивы, который будет корректно работать *всегда*. >> 3. если бекенд возвращает для HTTP-версии сайта редирект на HTTPS версию >> сайта, такое значение fastcgi_cache_key бужет приводить к проблемам, >> так как для HTTPS-запроса будет возвращаться 301 редирект из кеша. >> >> Можно ли исправить документацию и написать там в качестве примера >> такой фрагмент: >> >> fastcgi_cache_key "$request_method $scheme://$host$request_uri"; >> >> такая директива работает нормально, нет трех вышеперечисленных проблем. > Ключём кэширования должен выступать идентификатор ресурса, > который запрашивается с бэкенда. Идентификатор ресурса - это URI, в случае HTTP протокола. > В предложенном варианте - > отсутствует какая-либо информация о бэкенде вообще, так что он > представляется мне идеалогически неверным. А в чем тут практическая проблема, если в fastcgi_cache_key отсутствует информация о бекенде? Или проблемы никакой нет? > У нас, конечно, уже есть подобная конструкция в описании > proxy_cach_key, но там за счёт $cookie_user куда более очевидно, > что это именно пример, а не что-то, отлитое в граните и пригодное > для всех конфигов. Возможно, по какому-то такому пути и стоит пойти. В документации к директиве proxy_cache_convert_head написано: When the conversion is disabled, the cache key should be configured to include the $request_method. А поскольку для fastcgi/uwsgi/scgi аналогичной директивы fastcgi/uwsgi/scgi_cache_convert_head нет, то и требование the cache key should be configured to include the $request_method должно выполняться всегда. >> Недавно в очередной раз столкнулся в проблемой, когда люди бездумно >> копируют в конфиг рекомендуемые варианты директивы fastcgi_cache_key >> из документации, не подозревая, что в документации записано в качестве >> рекомендуемого варианта то, что нормально работать у них не будет. > > Кажется, что правильным будет для начала написать в описании > fastcgi_cache_key (uwsgi_cache_key, scgi_cache_key), что ключ > должен идентифицировать запрашиваемый ресурс, а не ставится "абы > как, авось повезёт". Максим, так я ведь именно об этом и говорю. Идентификатором ресурса является URI в случае HTTP протокола, из этого следует, что fastcgi_cache_key (uwsgi_cache_key, scgi_cache_key) *должны* включать в себя и $scheme и $host а не только path[?query], которые в nginx хранятся в переменной $request_uri. https://tools.ietf.org/html/rfc7230#section-2.7 Uniform Resource Identifiers (URIs) [RFC3986] are used throughout HTTP as the means for identifying resources (Section 2 of [RFC7231]). -- Best regards, Gena From mdounin на mdounin.ru Thu Nov 29 19:02:57 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 29 Nov 2018 22:02:57 +0300 Subject: =?UTF-8?B?UmU6INCU0L7QutGD0LzQtdC90YLQsNGG0LjRjyDQuiDQtNC40YDQtdC60YLQuNCy?= =?UTF-8?B?0LUgZmFzdGNnaV9jYWNoZV9rZXk=?= In-Reply-To: <08f691cf-3d76-9223-6d23-4a83c20ff585@csdoc.com> References: <65806589-b909-0ae2-fa6a-dfaf6e2920a3@csdoc.com> <20181129163017.GL99070@mdounin.ru> <08f691cf-3d76-9223-6d23-4a83c20ff585@csdoc.com> Message-ID: <20181129190257.GO99070@mdounin.ru> Hello! On Thu, Nov 29, 2018 at 08:35:18PM +0200, Gena Makhomed wrote: > On 29.11.2018 18:30, Maxim Dounin wrote: > > >> В документации к директиве fastcgi_cache_key приведен такой пример: > >> > >> fastcgi_cache_key localhost:9000$request_uri; > >> > >> У этого примера есть несколько проблем: > >> > >> 1. Если кто-то сделает к бекенду HEAD-запрос, то в кеш запишется пустой > >> ответ и на последующие GET-запросы будет отдаваться пустая страница. > > > AFAIK, никакой специальной обработки HEAD-запросов в FastCGI не > > предусмотрено. И в том числе не предсмотрено в каком-нибудь PHP > > из коробки. Соответственно всё будет работать штатно. > > Специальная обработка HEAD-запросов предусмотрена в HTTP протоколе: > https://tools.ietf.org/html/rfc7231#section-4.3.2 > > The HEAD method is identical to GET except that the server MUST NOT > send a message body in the response (i.e., the response terminates at > the end of the header section). > > В nginx присутствует workaround, который исправляет поведение бекендов, > которые на HEAD-запрос *ошибочно* отвечают так же, как и на GET-запрос. > > Но далеко не все бекенды содержат в себе эту ошибку, многие из них ведут > себя именно так, как этого от них требует спецификация HTTP протокола. CGI и HTTP - это два разных протокола. В последних вариациях на тему спецификации CGI записано, что на HEAD-запросы тело возвращать не надо (а если вдруг вернули - то сервер его должен поскипать), https://tools.ietf.org/html/rfc3875#section-4.3.3: The HEAD method requests the script to do sufficient processing to return the response header fields, without providing a response message-body. The script MUST NOT provide a response message-body for a HEAD request. If it does, then the server MUST discard the message-body when reading the response from the script. Однако на момент собственно появления и активного распространения CGI никаких подобных требований не существовало, см. https://www.w3.org/CGI/ и в частности https://tools.ietf.org/html/draft-robinson-www-interface-00. И на практике я не встречал скрипты, которые бы отдельно обрабатывали HEAD-запросы. > > Речь про какие-то фреймворки, которые обрабатывают > > HEAD автоматически, не донося соответствующую информацию до кода? > > Или про какой-то стандартный софт, который не возвращает тело для > > HEAD-запросов? > > Какая разница, сам софт или фрейморк используемый софтом в каждом > конкретном случае обрабатывает HEAD запросы согласно требований RFC? Никакой. Но с этой точки зрения так же нет разницы, что именно написано в примерах в описании директивы fastcgi_cache_key. [...] -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Fri Nov 30 09:30:27 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 30 Nov 2018 11:30:27 +0200 Subject: =?UTF-8?B?UmU6INCU0L7QutGD0LzQtdC90YLQsNGG0LjRjyDQuiDQtNC40YDQtdC60YLQuNCy?= =?UTF-8?B?0LUgZmFzdGNnaV9jYWNoZV9rZXk=?= In-Reply-To: <20181129190257.GO99070@mdounin.ru> References: <65806589-b909-0ae2-fa6a-dfaf6e2920a3@csdoc.com> <20181129163017.GL99070@mdounin.ru> <08f691cf-3d76-9223-6d23-4a83c20ff585@csdoc.com> <20181129190257.GO99070@mdounin.ru> Message-ID: <32393d60-7cdf-a3fe-2ad1-3de6c82ec2a0@csdoc.com> On 29.11.2018 21:02, Maxim Dounin wrote: > CGI и HTTP - это два разных протокола. В последних вариациях на > тему спецификации CGI записано, что на HEAD-запросы тело > возвращать не надо (а если вдруг вернули - то сервер его должен > поскипать), https://tools.ietf.org/html/rfc3875#section-4.3.3: > > The HEAD method requests the script to do sufficient processing to > return the response header fields, without providing a response > message-body. The script MUST NOT provide a response message-body > for a HEAD request. If it does, then the server MUST discard the > message-body when reading the response from the script. > > Однако на момент собственно появления и активного распространения > CGI никаких подобных требований не существовало, см. > https://www.w3.org/CGI/ и в частности > https://tools.ietf.org/html/draft-robinson-www-interface-00. Там написано: REQUEST_METHOD This variable is specific to requests made with HTTP. The method with which the request was made, as described in section 5.1.1 of the HTTP/1.0 specification [3]. http-method = "GET" | "HEAD" | "POST" | extension-method "described in HTTP/1.0 specification" - написано где смотреть семантику. А в HTTP/1.0 specification написано, что "server must not return any Entity-Body in the response". CGI и HTTP - это два разных протокола, но первый ссылается на второй. При этом CGI протокол не запрещает бекенду отвечать на HEAD-запросы так, как этого требует от веб-сервера спецификация HTTP протокола. > И на > практике я не встречал скрипты, которые бы отдельно обрабатывали > HEAD-запросы. Но они есть. И их поведение ничем не противоречит спецификации FastCGI протокола. >>> Речь про какие-то фреймворки, которые обрабатывают >>> HEAD автоматически, не донося соответствующую информацию до кода? >>> Или про какой-то стандартный софт, который не возвращает тело для >>> HEAD-запросов? >> >> Какая разница, сам софт или фрейморк используемый софтом в каждом >> конкретном случае обрабатывает HEAD запросы согласно требований RFC? > > Никакой. Но с этой точки зрения так же нет разницы, что именно > написано в примерах в описании директивы fastcgi_cache_key. Вы не против, если я создам на хабре статью, в которой напишу про эту проблему с ошибочными примерами в документации nginx к директиве fastcgi_cache_key и ее аналогам? -- Best regards, Gena From coddoc на mail.ru Fri Nov 30 10:07:49 2018 From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=) Date: Fri, 30 Nov 2018 13:07:49 +0300 Subject: =?UTF-8?B?0JLQvtC/0YDQvtGBINC+INCx0LDQu9Cw0L3RgdC40YDQvtCy0LrQtSDQvdCw0LM=?= =?UTF-8?B?0YDRg9C30LrQuC4=?= Message-ID: <1543572469.752677744@f386.i.mail.ru> Доброе время суток! Существует ли в принципе возможность получить в какую-то переменную имя бэкенд-сервера, выбранное в директиве upstream? Задача такая. Есть основной сервер example.com, на котором: nginx <=> php <=> БД и несколько бэкендов-хранилок в том же домене, но в разных ДЦ (допустим, s1.example.com, s2.example.com и т.д.) Соответственно: upstream backends {     server s1.example.com;     server s2.example.com;     server s3.example.com;     ..... } Пользователь авторизуется на основном сервере, получает сессию и куки. Каждому пользователю выдаются куки с одинаковами именами, но разными значениями. Кроме того, для каждого пользователя создаются хэши, привязанные к его сессии и кукам. Требуется отдать с ОСНОВНОГО сервера html, содержащую ссылки вида: - для пользователя A - , - для пользователя B - , После чего каждый из них тянет нужный файл с выбранной хранилки. Т.е. не пробрасывать запрос на хранилку через proxy_pass backends, а только получить имя бэкенда, выбранного с учетом правил в upstream. И получив это имя в какую-то переменную, передать его в php, отвечающий за выдачу html страницы из соответствующего локейшена. Заранее благодарю за любые конструктивные идеи. -- ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Fri Nov 30 10:36:08 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 30 Nov 2018 15:36:08 +0500 Subject: =?UTF-8?B?UmU6INCU0L7QutGD0LzQtdC90YLQsNGG0LjRjyDQuiDQtNC40YDQtdC60YLQuNCy?= =?UTF-8?B?0LUgZmFzdGNnaV9jYWNoZV9rZXk=?= In-Reply-To: <32393d60-7cdf-a3fe-2ad1-3de6c82ec2a0@csdoc.com> References: <65806589-b909-0ae2-fa6a-dfaf6e2920a3@csdoc.com> <20181129163017.GL99070@mdounin.ru> <08f691cf-3d76-9223-6d23-4a83c20ff585@csdoc.com> <20181129190257.GO99070@mdounin.ru> <32393d60-7cdf-a3fe-2ad1-3de6c82ec2a0@csdoc.com> Message-ID: протоколы действительно разные. но выглядит так, что предложение Гены поможет написать документацию, более устойчивую к тупому копипасту (есть такой патерн, что глядя на пример документации на авторитетном сайте, его копируют) пт, 30 нояб. 2018 г. в 14:30, Gena Makhomed : > On 29.11.2018 21:02, Maxim Dounin wrote: > > > CGI и HTTP - это два разных протокола. В последних вариациях на > > тему спецификации CGI записано, что на HEAD-запросы тело > > возвращать не надо (а если вдруг вернули - то сервер его должен > > поскипать), https://tools.ietf.org/html/rfc3875#section-4.3.3: > > > > The HEAD method requests the script to do sufficient processing to > > return the response header fields, without providing a response > > message-body. The script MUST NOT provide a response message-body > > for a HEAD request. If it does, then the server MUST discard the > > message-body when reading the response from the script. > > > > Однако на момент собственно появления и активного распространения > > CGI никаких подобных требований не существовало, см. > > https://www.w3.org/CGI/ и в частности > > https://tools.ietf.org/html/draft-robinson-www-interface-00. > > Там написано: > > REQUEST_METHOD > > This variable is specific to requests made with HTTP. > > The method with which the request was made, as described in > section 5.1.1 of the HTTP/1.0 specification [3]. > > http-method = "GET" | "HEAD" | "POST" | extension-method > > "described in HTTP/1.0 specification" - написано где смотреть семантику. > А в HTTP/1.0 specification написано, что "server must not return any > Entity-Body in the response". > > CGI и HTTP - это два разных протокола, но первый ссылается на второй. > При этом CGI протокол не запрещает бекенду отвечать на HEAD-запросы > так, как этого требует от веб-сервера спецификация HTTP протокола. > > > И на > > практике я не встречал скрипты, которые бы отдельно обрабатывали > > HEAD-запросы. > > Но они есть. > И их поведение ничем не противоречит спецификации FastCGI протокола. > > >>> Речь про какие-то фреймворки, которые обрабатывают > >>> HEAD автоматически, не донося соответствующую информацию до кода? > >>> Или про какой-то стандартный софт, который не возвращает тело для > >>> HEAD-запросов? > >> > >> Какая разница, сам софт или фрейморк используемый софтом в каждом > >> конкретном случае обрабатывает HEAD запросы согласно требований RFC? > > > > Никакой. Но с этой точки зрения так же нет разницы, что именно > > написано в примерах в описании директивы fastcgi_cache_key. > > Вы не против, если я создам на хабре статью, в которой напишу > про эту проблему с ошибочными примерами в документации nginx > к директиве fastcgi_cache_key и ее аналогам? > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Fri Nov 30 13:07:18 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 30 Nov 2018 16:07:18 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQviDQsdCw0LvQsNC90YHQuNGA0L7QstC60LUg0L0=?= =?UTF-8?B?0LDQs9GA0YPQt9C60Lgu?= In-Reply-To: <1543572469.752677744@f386.i.mail.ru> References: <1543572469.752677744@f386.i.mail.ru> Message-ID: <20181130130718.GQ99070@mdounin.ru> Hello! On Fri, Nov 30, 2018 at 01:07:49PM +0300, CoDDoC via nginx-ru wrote: > Существует ли в принципе возможность получить в какую-то переменную имя бэкенд-сервера, выбранное в директиве upstream? > > Задача такая. > Есть основной сервер example.com, на котором: nginx <=> php <=> БД > и несколько бэкендов-хранилок в том же домене, но в разных ДЦ (допустим, s1.example.com, s2.example.com и т.д.) > Соответственно: > upstream backends { >     server s1.example.com; >     server s2.example.com; >     server s3.example.com; >     ..... > } > Пользователь авторизуется на основном сервере, получает сессию и куки. > Каждому пользователю выдаются куки с одинаковами именами, но разными значениями. > Кроме того, для каждого пользователя создаются хэши, привязанные к его сессии и кукам. > > Требуется отдать с ОСНОВНОГО сервера html, содержащую ссылки вида: > - для пользователя A - , > - для пользователя B - , > > После чего каждый из них тянет нужный файл с выбранной хранилки. > > Т.е. не пробрасывать запрос на хранилку через proxy_pass backends, а только получить имя бэкенда, выбранного с учетом правил в upstream. И получив это имя в какую-то переменную, передать его в php, отвечающий за выдачу html страницы из соответствующего локейшена. > > Заранее благодарю за любые конструктивные идеи. http://nginx.org/r/split_clients -- Maxim Dounin http://mdounin.ru/