From arut на nginx.com Fri Jul 1 13:14:27 2022 From: arut на nginx.com (Roman Arutyunyan) Date: Fri, 1 Jul 2022 17:14:27 +0400 Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0LzQtdC00LvQtdC90L3Ri9C5INC+0YI=?= =?utf-8?B?0LLQtdGCINC+0YIg0YHQtdGA0LLQtdGA0LAu?= In-Reply-To: <53850416.20220628080102@gmail.com> References: <329150630.20220611142212@gmail.com> <03C1EF10-D735-4ED5-BE6A-4125F1C04983@nginx.com> <53850416.20220628080102@gmail.com> Message-ID: <74F1526C-2910-4BD6-A34A-B4505A6143FC@nginx.com> Добрый день, > On 28 Jun 2022, at 09:01, izorkin на gmail.com wrote: > > Добрый день, Роман. > > Я ещё заметил одну ошибку в работе HTTP 3 протокола. > Через очень долгое время (5-8 часов), браузер начинает отправлять запросы по HTTP 2 протоколу, вместо > HTTP 3. Собрал debug-лог, но не смог проследить с какого момента прошло переключение. Если понадобится, > то к вечеру смогу отправить вам логи. Проблема появилась тогда, когда вы начали реконфигурацию nginx (послали SIGHUP). При появлении новых воркеров ломается логика распределения квиковых соединений по воркерам. В итоге, например, новый пакет может прийти в старый воркер, которым он будет проигнорирован. Все бы могло относительно быстро рассосаться после череды ошибок, если бы у вас не висел один запрос с проксировнием вебсокетов, который не давал завершиться старому воркеру. Кроме того, похоже, у вас выключен таймаут на шатдаун воркеров. Если у вас (свежий) Linux, то проблема с распределением квиковых клиентов по воркерам решается включением bpf-модуля. Для этого укажите следующую директиву на верхнем уровне конфига: quic_bpf on; При этом nginx должен иметь админские права (CAP_SYS_ADMIN) при запуске. ---- Roman Arutyunyan arut на nginx.com ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From tit на irk.ru Mon Jul 4 06:45:05 2022 From: tit на irk.ru (Alexander Titaev) Date: Mon, 4 Jul 2022 14:45:05 +0800 Subject: Requests to the new URL In-Reply-To: References: Message-ID: <972361593.20220704144505@irk.ru> Здравствуйте, Rasin. Вы писали 29 июня 2022 г., 22:33:30: > Добрый день. > Подскажите пожалуйста, есть софт, в докере поднятый. > Работает только с location / { > proxy_pass http://127.0.0.1:3333; > ... > } > Хочу сделать чтобы открывался location /soft { > proxy_pass http://127.0.0.1:3333; > ... > } > Но с последним выдаёт, что не может найти скрипты и прочее. > Я так понимаю он посылает заголовок, который непонятен софту. > Что необходимо сделать, куда копнуть, подскажите пожалуйста. в последнем случае проксируемый url будет содержать /soft, вот его и надо реврайтить в / -- С уважением, Alexander mailto:tit на irk.ru From mdounin на mdounin.ru Mon Jul 4 18:30:20 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 4 Jul 2022 21:30:20 +0300 Subject: Requests to the new URL In-Reply-To: <972361593.20220704144505@irk.ru> References: <972361593.20220704144505@irk.ru> Message-ID: Hello! On Mon, Jul 04, 2022 at 02:45:05PM +0800, Alexander Titaev wrote: > Здравствуйте, Rasin. > > Вы писали 29 июня 2022 г., 22:33:30: > > > Добрый день. > > Подскажите пожалуйста, есть софт, в докере поднятый. > > Работает только с location / { > > proxy_pass http://127.0.0.1:3333; > > ... > > } > > Хочу сделать чтобы открывался location /soft { > > proxy_pass http://127.0.0.1:3333; > > ... > > } > > Но с последним выдаёт, что не может найти скрипты и прочее. > > Я так понимаю он посылает заголовок, который непонятен софту. > > Что необходимо сделать, куда копнуть, подскажите пожалуйста. > > в последнем случае проксируемый url будет содержать /soft, вот его и надо реврайтить в / Цитата из документации (http://nginx.org/r/proxy_pass/ru): : Если директива proxy_pass указана с URI, то при передаче запроса : серверу часть нормализованного URI запроса, соответствующая : location, заменяется на URI, указанный в директиве: : : location /name/ { : proxy_pass http://127.0.0.1/remote/; : } То есть надо написать: location /soft/ { proxy_pass http://127.0.0.1:3333/; ... } Обращаю внимание на "/" в конце префикса location и в конце параметра proxy_pass. Стоит, однако, помнить, что в общем случае это может не работать, так как если внутри запрашиваемых страниц есть ссылки на другие ресурсы, оно могут быть не относительными, и соответственно просто так не заработают. Если софт умеет относительные ссылки и/или даёт возможность задать префикс для загружаемых дополнительных ресурсов - то хорошо. Если же нет, то увы (можно пытаться переписывать ссылки в nginx'е с помощью sub_filter, но в общем случае это не решение). -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue Jul 5 09:49:57 2022 From: nginx-forum на forum.nginx.org (milov) Date: Tue, 05 Jul 2022 05:49:57 -0400 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port Message-ID: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> Прошу посильной помощи, появилась ошибка 400 Bad Request с http на https после обновления сертификата летс энкрипт Конфиг nginx не менялся уже года 3 как минимум, редиректы хорошо работали. Вчера обновил сертификат летс энкрипт и тут понеслись ошибки редиректа, хотя и раньше обновлял этот сертификат и было всё хорошо. Вот конфиг: server { listen 80; server_name .local.map; rewrite ^(.*) https://$host$1 permanent; #return 301 https://$host$request_uri; } server { listen 443 ssl http2; ssl_certificate /etc/letsencrypt/live/local.map/fullchain.pem; ssl_trusted_certificate /etc/letsencrypt/live/local.map/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/local.map/privkey.pem; server_name .local.map; set $root /var/www/msk/data/local.map; root $root; access_log off; и т.д.... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294635,294635#msg-294635 From chipitsine на gmail.com Tue Jul 5 10:31:43 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 5 Jul 2022 15:31:43 +0500 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port In-Reply-To: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> Message-ID: добавьте error_log уровня info Основная функциональность (nginx.org) в соответствующий сайт и на уровне сервера. в некоторых случаях 400-ка это bad request и запрос не попадает в сайт, а логируется на уровне выше вт, 5 июл. 2022 г. в 14:50, milov : > Прошу посильной помощи, появилась ошибка 400 Bad Request с http на https > после обновления сертификата летс энкрипт > > Конфиг nginx не менялся уже года 3 как минимум, редиректы хорошо работали. > Вчера обновил сертификат летс энкрипт и тут понеслись ошибки редиректа, > хотя > и раньше обновлял этот сертификат и было всё хорошо. > > Вот конфиг: > > server { > listen 80; > server_name .local.map; > rewrite ^(.*) https://$host$1 permanent; > #return 301 https://$host$request_uri; > } > > server { > listen 443 ssl http2; > > ssl_certificate /etc/letsencrypt/live/local.map/fullchain.pem; > ssl_trusted_certificate /etc/letsencrypt/live/local.map/fullchain.pem; > ssl_certificate_key /etc/letsencrypt/live/local.map/privkey.pem; > > server_name .local.map; > set $root /var/www/msk/data/local.map; > root $root; > access_log off; > и т.д.... > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,294635,294635#msg-294635 > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Jul 5 10:57:24 2022 From: nginx-forum на forum.nginx.org (milov) Date: Tue, 05 Jul 2022 06:57:24 -0400 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port In-Reply-To: References: Message-ID: <0f69ccede6a61f5cda99c7e6e028eea8.NginxMailingListRussian@forum.nginx.org> [info] 23978#0: *221 client sent plain HTTP request to HTTPS port while reading client request headers closed keepalive connection вот такие логи полезли Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294635,294637#msg-294637 From chipitsine на gmail.com Tue Jul 5 11:15:05 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 5 Jul 2022 16:15:05 +0500 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port In-Reply-To: <0f69ccede6a61f5cda99c7e6e028eea8.NginxMailingListRussian@forum.nginx.org> References: <0f69ccede6a61f5cda99c7e6e028eea8.NginxMailingListRussian@forum.nginx.org> Message-ID: не могу соотнести это сообщение об ошибке с 400-кой. есть еще мысль (если вдруг error_log не поможет), попробовать отключить http2. помнится какие-то очень экзотические ошибки на уровне http2 давали 400 и не логировались. вт, 5 июл. 2022 г. в 15:57, milov : > [info] 23978#0: *221 client sent plain HTTP request to HTTPS port while > reading client request headers > > closed keepalive connection > > вот такие логи полезли > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,294635,294637#msg-294637 > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Jul 5 12:55:07 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 5 Jul 2022 15:55:07 +0300 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port In-Reply-To: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> Message-ID: Hello! On Tue, Jul 05, 2022 at 05:49:57AM -0400, milov wrote: > Прошу посильной помощи, появилась ошибка 400 Bad Request с http на https > после обновления сертификата летс энкрипт > > Конфиг nginx не менялся уже года 3 как минимум, редиректы хорошо работали. > Вчера обновил сертификат летс энкрипт и тут понеслись ошибки редиректа, хотя > и раньше обновлял этот сертификат и было всё хорошо. > > Вот конфиг: > > server { > listen 80; > server_name .local.map; > rewrite ^(.*) https://$host$1 permanent; > #return 301 https://$host$request_uri; > } > > server { > listen 443 ssl http2; > > ssl_certificate /etc/letsencrypt/live/local.map/fullchain.pem; > ssl_trusted_certificate /etc/letsencrypt/live/local.map/fullchain.pem; > ssl_certificate_key /etc/letsencrypt/live/local.map/privkey.pem; > > server_name .local.map; > set $root /var/www/msk/data/local.map; > root $root; > access_log off; > и т.д.... Начать с простого: перегрузить конфиг (или просто рестартовать nginx), если не поможет - внимательно его проверить на предмет "ssl on;" и "listen ... ssl;". Проверять лучше через "nginx -T", дабы случайно не упустить какие-либо include'ы. Отмечу, что если сертификаты обновлялись с помощью Certbot, то он при обновлении модифицирует конфиги nginx'а (а потом возвращает всё "как было"). Это может заканчиваться, скажем так, неожиданно. Лично я рекомендую для выпуска сертификатов использовать Dehydrated и необходимые дополнения в конфиг прописывать руками. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue Jul 5 18:12:13 2022 From: nginx-forum на forum.nginx.org (milov) Date: Tue, 05 Jul 2022 14:12:13 -0400 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port In-Reply-To: References: Message-ID: <5a15870377dfe793f14f5a196b4099db.NginxMailingListRussian@forum.nginx.org> Почему проблема с http2 это в другой же секции? Редирект то здесь не срабатывает server { listen 80; server_name .local.map; rewrite ^(.*) https://$host$1 permanent; #return 301 https://$host$request_uri; } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294635,294641#msg-294641 From gmm на csdoc.com Tue Jul 5 19:09:33 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 5 Jul 2022 22:09:33 +0300 Subject: certbot In-Reply-To: References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> Message-ID: <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> On 05.07.2022 15:55, Maxim Dounin wrote: > Отмечу, что если сертификаты обновлялись с помощью Certbot, то он > при обновлении модифицирует конфиги nginx'а (а потом возвращает > всё "как было"). Это может заканчиваться, скажем так, неожиданно. > Лично я рекомендую для выпуска сертификатов использовать > Dehydrated и необходимые дополнения в конфиг прописывать руками. certbot так криво себя ведет только в дефолтовой конфигурации. Если настроить его соответствующим образом: # cat /etc/letsencrypt/cli.ini key-type = ecdsa elliptic-curve = secp256r1 authenticator = webroot webroot-path = /opt/letsencrypt agree-tos = True reuse-key = False no-eff-email = True и прописать в default.conf server { listen 80 bind default_server; server_name default-server; location / { return 444; } location /.well-known/acme-challenge { default_type text/plain; root /opt/letsencrypt; } } тогда получить сертификат для нового (даже еще не прописанного в конфигурации nginx) сервера можно одной командой: certbot certonly -d example.com -d www.example.com разумеется, потом для этого нового сервера тоже нужно будет прописать аналогичный location /.well-known/acme-challenge { ... } на 80 порту. в таком случае - certbot не будет пытаться модифицировать конфиги nginx. а то что он криво работает в дефолтовой конфигурации - это ничего не значит, в дефолтовой конфигурации и nginx работает не самым лучшим образом (мягко говоря). certbot - это хорошая утилита, продуманная, и качественно сделанная. dehydrated - это скрипт на bash со всеми вытекающими отсюда проблемами: https://github.com/dehydrated-io/dehydrated/commits/master/dehydrated -- Best regards, Gena From nginx-forum на forum.nginx.org Tue Jul 5 19:40:47 2022 From: nginx-forum на forum.nginx.org (milov) Date: Tue, 05 Jul 2022 15:40:47 -0400 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port In-Reply-To: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> Message-ID: <019839b6ce6683a6a79ea0d6fe90942d.NginxMailingListRussian@forum.nginx.org> В общем решил проблему. У меня на одном айпи висит несколько сайтов и в конфигах nginx прописано у двух сайтов default_server, оставил только у одного и проблема решилась. Возможно это баг какой-то и стоит куда-то сообщить. Странно только почему раньше работали редиректы ) Спасибо всем за помощь. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294635,294643#msg-294643 From mdounin на mdounin.ru Tue Jul 5 21:52:53 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 6 Jul 2022 00:52:53 +0300 Subject: certbot In-Reply-To: <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> Message-ID: Hello! On Tue, Jul 05, 2022 at 10:09:33PM +0300, Gena Makhomed wrote: > On 05.07.2022 15:55, Maxim Dounin wrote: > > > Отмечу, что если сертификаты обновлялись с помощью Certbot, то он > > при обновлении модифицирует конфиги nginx'а (а потом возвращает > > всё "как было"). Это может заканчиваться, скажем так, неожиданно. > > Лично я рекомендую для выпуска сертификатов использовать > > Dehydrated и необходимые дополнения в конфиг прописывать руками. > > certbot так криво себя ведет только в дефолтовой конфигурации. Этого достаточно, чтобы им не пользоваться. И уж тем более не рекомендовать другим, ибо они с вероятностью, близкой к 100%, будут использовать его именно в конфигурации по умолчанию. Тем более, что есть Dehydrated, который подобным идиотизмом по умолчанию не страдает, да и представляет из себя вполне читаемый bash-скрипт без дополнительных зависимостей. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Jul 5 23:04:11 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 6 Jul 2022 02:04:11 +0300 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port In-Reply-To: <019839b6ce6683a6a79ea0d6fe90942d.NginxMailingListRussian@forum.nginx.org> References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <019839b6ce6683a6a79ea0d6fe90942d.NginxMailingListRussian@forum.nginx.org> Message-ID: Hello! On Tue, Jul 05, 2022 at 03:40:47PM -0400, milov wrote: > В общем решил проблему. > > У меня на одном айпи висит несколько сайтов и в конфигах nginx прописано у > двух сайтов default_server, оставил только у одного и проблема решилась. > Возможно это баг какой-то и стоит куда-то сообщить. > > Странно только почему раньше работали редиректы ) Если у одного и того же listen-сокета используется флаг default_server в двух разных блоках server{} - это фатальная ошибка, nginx с таким конфигом работать не будет. В логах и при тестировании конфигурации будет ошибка вида: 2022/07/06 01:40:43 [emerg] 900#100127: a duplicate default server for 0.0.0.0:8080 in ... Если раньше работало - возможно, nginx не перезапускали, и он работал со старым конфигом, до появления ошибки в конфиге. Если же флаг default_server использовался у разных listen-сокетов, то убрав его у одного из listen-сокетов вы просто изменили сервер по умолчанию для этого listen-сокета. Это может исправить проблему с "client sent plain HTTP request to HTTPS port", если использовалась кривая конфигурация с "ssl on;" в блоке server с listen-сокетами, которые не должны использовать SSL. Директива "ssl" объявлена устаревшей 4 года назад, в nginx 1.15.0, причём именно потому, что её использование легко приводит к подобным ошибкам. Если директива "ssl" действительно используется - конфигурацию следует переписать с использованием "listen ... ssl;" вместо неё. Подробнее смотри http://nginx.org/r/ssl/ru и http://nginx.org/r/listen/ru. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue Jul 5 23:20:46 2022 From: nginx-forum на forum.nginx.org (milov) Date: Tue, 05 Jul 2022 19:20:46 -0400 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port In-Reply-To: References: Message-ID: <25ce637043fa83bc86a6b7c1794e9594.NginxMailingListRussian@forum.nginx.org> возможно вы правы но у меня версия nginx 1.13 ещё заметил такое, что если несколько сайтов на одном айпи то проблема возвращается, развел по разным айпи и работает, что уже хорошо. непонятно почему проблема вылезла после обновления сертификата. а нжинкс перегружаю после каждого обновления сертификата. почему раньше всегда работало, а сейчас вылезло, в логах ничего подозрительного нет, что и побудило меня обратиться на форум. спасибо за ответы. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294635,294646#msg-294646 From mdounin на mdounin.ru Wed Jul 6 01:52:20 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 6 Jul 2022 04:52:20 +0300 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port In-Reply-To: <25ce637043fa83bc86a6b7c1794e9594.NginxMailingListRussian@forum.nginx.org> References: <25ce637043fa83bc86a6b7c1794e9594.NginxMailingListRussian@forum.nginx.org> Message-ID: Hello! On Tue, Jul 05, 2022 at 07:20:46PM -0400, milov wrote: > возможно вы правы но у меня версия nginx 1.13 Возможность задавать конфигурацию с помощью "listen ... ssl" появилась в nginx 0.7.14. Но, конечно, использовать nginx 1.13.x в продакшне я бы не рекомендовал. > ещё заметил такое, что если несколько сайтов на одном айпи то проблема > возвращается, развел по разным айпи и работает, что уже хорошо. непонятно > почему проблема вылезла после обновления сертификата. а нжинкс перегружаю > после каждого обновления сертификата. > > почему раньше всегда работало, а сейчас вылезло, в логах ничего > подозрительного нет, что и побудило меня обратиться на форум. У вас явно некорректная конфигурация, использующая "ssl on;". Основное правило при использовании "ssl on;" очень простое: SSL и не-SSL listen-сокеты должны использоваться строго в разных блоках server{}. Любые попытки совместить - чреваты. Ибо если вдруг у вас в сервере по умолчанию для не-SSL listen-сокета окажется "ssl on;", то сокет станет SSL-сокетом. Скорее всего "раньше всегда работало" потому, что в сервера по умолчанию для не-SSL listen-сокетов стояли корректные, а сейчас из-за каких-то минимальных изменений конфига (скажем, кто-то добавил блок server с несколькими listen-сокетами и "ssl on;") - ситуация поменялась. Если по каким-то причинам хочется исправить конфигурацию, не переходя на "listen ... ssl" - показывайте полную конфигурацию, поможем найти источник проблем. Но проще и правильнее сразу переделать всё на использование "listen ... ssl", благо это тривиально: "ssl on;" из конфига убрать, а у listen-сокетов, которые должны использовать SSL, добавить флаг "ssl" (как минимум один раз, например, в сервере по умолчанию, но можно во всех директивах listen). -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Wed Jul 6 05:15:43 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 6 Jul 2022 08:15:43 +0300 Subject: long deprecated directives In-Reply-To: References: <25ce637043fa83bc86a6b7c1794e9594.NginxMailingListRussian@forum.nginx.org> Message-ID: <39bcd991-ba67-6dec-6fed-e002b58c4dcc@csdoc.com> On 06.07.2022 4:52, Maxim Dounin wrote: > Возможность задавать конфигурацию с помощью "listen ... ssl" > появилась в nginx 0.7.14. > У вас явно некорректная конфигурация, использующая "ssl on;". Кстати, директива "ssl on;" находится в состоянии deprecated начиная с версии 1.15.0, вышедшей 05 Jun 2018, более 4 лет тому назад. Может быть имеет смысл превратить warning в error, удалив эту директиву из nginx и оставив только возможность "listen ... ssl" ? Тогда у пользователей будет меньше возможностей для создания конфигураций, которые будут приводить к ошибкам такого вида: 400 Bad Request The plain HTTP request was sent to HTTPS port Аналогичный вопрос и по остальным deprecated директивам: proxy_downstream_buffer proxy_upstream_buffer http2_idle_timeout http2_max_field_size http2_max_header_size http2_max_requests http2_recv_timeout - может быть имеет смысл их удалить из nginx? Раньше такое уже происходило неоднократно, вот записи из файла CHANGES: *) Change: some long deprecated directives are not supported anymore. *) Change: the deprecated "limit_zone" directive is not supported anymore. *) Change: some long deprecated directives are not supported anymore. -- Best regards, Gena From gmm на csdoc.com Wed Jul 6 06:00:05 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 6 Jul 2022 09:00:05 +0300 Subject: certbot In-Reply-To: References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> Message-ID: <1bacf805-e79f-2b1a-46d3-042fae3ea8fd@csdoc.com> On 06.07.2022 0:52, Maxim Dounin wrote: >>> Отмечу, что если сертификаты обновлялись с помощью Certbot, то он >>> при обновлении модифицирует конфиги nginx'а (а потом возвращает >>> всё "как было"). Это может заканчиваться, скажем так, неожиданно. >>> Лично я рекомендую для выпуска сертификатов использовать >>> Dehydrated и необходимые дополнения в конфиг прописывать руками. >> certbot так криво себя ведет только в дефолтовой конфигурации. > Этого достаточно, чтобы им не пользоваться. И уж тем более не > рекомендовать другим, ибо они с вероятностью, близкой к 100%, > будут использовать его именно в конфигурации по умолчанию. Если быть уж совсем точным, то при установке пакета certbot пакет python3-certbot-nginx не устанавливается. python3-certbot-nginx - это Plugin for certbot that allows for automatic configuration of nginx. Поэтому при выполнении команды certbot run -d example.com он выдает ошибку: Certbot doesn't know how to automatically configure the web server on this system. However, it can still get a certificate for you. Please run "certbot certonly" to do so. You'll need to manually configure your web server to use the resulting certificate. Поэтому единственным рабочим вариантом получения сертификата для nginx является только команда certbot certonly -d example.com которая никаких автоматических изменений в конфиги nginx не вносит. certbot - это очень хорошо продуманный и качественно сделанный софт. > Тем более, что есть Dehydrated, который подобным идиотизмом по > умолчанию не страдает, да и представляет из себя вполне читаемый > bash-скрипт без дополнительных зависимостей. этот bash-скрипт имеет серьезные проблемы даже с парсингом json: https://www.opennet.ru/opennews/art.shtml?num=53279 тем более, что разработчик dehydrated - это всего лишь студент: https://www.opennet.ru/opennews/art.shtml?num=52294 История исправлений этого bash-скрипта тоже впечетляет: https://github.com/dehydrated-io/dehydrated/commits/master/dehydrated really reverted regression in somehow broken array expansion from e96… reverted regression in somehow broken array expansion from e963438 ... -- Best regards, Gena From raven_kg на megaline.kg Wed Jul 6 06:08:06 2022 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Wed, 6 Jul 2022 12:08:06 +0600 Subject: certbot In-Reply-To: References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> Message-ID: Если уж хочется bash-скриптов, то acme.sh хорошая альтернатива, однако, врочем как и в случае с ЛЮБЫМ софтом - сперва нужно ознакомиться с мануалами или хотя бы с тем, что в --help. certbot тоже вполне вменяемо выписывает сертификаты без манипуляций с конфигами веб-серверов))) 06.07.2022 03:52, Maxim Dounin пишет: > Hello! > > On Tue, Jul 05, 2022 at 10:09:33PM +0300, Gena Makhomed wrote: > >> On 05.07.2022 15:55, Maxim Dounin wrote: >> >>> Отмечу, что если сертификаты обновлялись с помощью Certbot, то он >>> при обновлении модифицирует конфиги nginx'а (а потом возвращает >>> всё "как было"). Это может заканчиваться, скажем так, неожиданно. >>> Лично я рекомендую для выпуска сертификатов использовать >>> Dehydrated и необходимые дополнения в конфиг прописывать руками. >> certbot так криво себя ведет только в дефолтовой конфигурации. > Этого достаточно, чтобы им не пользоваться. И уж тем более не > рекомендовать другим, ибо они с вероятностью, близкой к 100%, > будут использовать его именно в конфигурации по умолчанию. > > Тем более, что есть Dehydrated, который подобным идиотизмом по > умолчанию не страдает, да и представляет из себя вполне читаемый > bash-скрипт без дополнительных зависимостей. > From maxim на nginx.com Wed Jul 6 06:27:48 2022 From: maxim на nginx.com (Maxim Konovalov) Date: Wed, 6 Jul 2022 10:27:48 +0400 Subject: long deprecated directives In-Reply-To: <39bcd991-ba67-6dec-6fed-e002b58c4dcc@csdoc.com> References: <25ce637043fa83bc86a6b7c1794e9594.NginxMailingListRussian@forum.nginx.org> <39bcd991-ba67-6dec-6fed-e002b58c4dcc@csdoc.com> Message-ID: <877b93ee-daf7-01af-e699-cb4e3df2e1a3@nginx.com> On 06.07.2022 09:15, Gena Makhomed wrote: [...] > Может быть имеет смысл превратить warning в error, удалив > эту директиву из nginx и оставив только возможность "listen ... ssl" ? > > Тогда у пользователей будет меньше возможностей для создания > конфигураций, которые будут приводить к ошибкам такого вида: > 400 Bad Request The plain HTTP request was sent to HTTPS port Тогда у них просто nginx не запустится, что, подозреваю, немного печальнее. Особенно, когда речь идет о пользователях, апгрейдящих nginx раз в пятилетку. И если с http2_* директивами вероятность их наличия в конфиге скорее всего в принципе не слишком высокая (задеприкейчены они сравнительно недавно, по меркам nginx -- вчера), то "ssl on" въелось за добрый десяток лет настолько плотно, что мы сегодня видим эту директиву в живых конфигах довольно часто. -- Maxim Konovalov From nginx-forum на forum.nginx.org Wed Jul 6 08:44:41 2022 From: nginx-forum на forum.nginx.org (milov) Date: Wed, 06 Jul 2022 04:44:41 -0400 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port In-Reply-To: References: Message-ID: <8c4146965a4a28eda720fc45b6e2bdd0.NginxMailingListRussian@forum.nginx.org> Maxim Dounin Wrote: ------------------------------------------------------- > У вас явно некорректная конфигурация, использующая "ssl on;". > Основное правило при использовании "ssl on;" очень простое: SSL и > не-SSL listen-сокеты должны использоваться строго в разных блоках > server{}. Любые попытки совместить - чреваты. Ибо если вдруг у > вас в сервере по умолчанию для не-SSL listen-сокета окажется "ssl > on;", то сокет станет SSL-сокетом. > > Скорее всего "раньше всегда работало" потому, что в сервера по > умолчанию для не-SSL listen-сокетов стояли корректные, а сейчас > из-за каких-то минимальных изменений конфига (скажем, кто-то > добавил блок server с несколькими listen-сокетами и "ssl on;") - > ситуация поменялась. > > Если по каким-то причинам хочется исправить конфигурацию, не > переходя на "listen ... ssl" - показывайте полную конфигурацию, > поможем найти источник проблем. > > Но проще и правильнее сразу переделать всё на использование > "listen ... ssl", благо это тривиально: "ssl on;" из конфига > убрать, а у listen-сокетов, которые должны использовать SSL, > добавить флаг "ssl" (как минимум один раз, например, в сервере по > умолчанию, но можно во всех директивах listen). > Вот конфиг, я его постил в самом начале, как видите разнесено по разным блокам server{} server { listen 80; server_name .local.map; rewrite ^(.*) https://$host$1 permanent; #return 301 https://$host$request_uri; } server { listen 443 ssl http2 default_server; ssl_certificate /etc/letsencrypt/live/local.map/fullchain.pem; ssl_trusted_certificate /etc/letsencrypt/live/local.map/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/local.map/privkey.pem; server_name .local.map; set $root /var/www/msk/data/local.map; root $root; access_log off; ..... есть второй сайт, у которого конфиг такой-же, только пути разные плюс убрал на другой айпи сокет и убрал default_server после чего заработало. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294635,294657#msg-294657 From nginx-forum на forum.nginx.org Wed Jul 6 08:49:45 2022 From: nginx-forum на forum.nginx.org (milov) Date: Wed, 06 Jul 2022 04:49:45 -0400 Subject: certbot In-Reply-To: References: Message-ID: <20710170925b7d081e20414450f80d82.NginxMailingListRussian@forum.nginx.org> Использую команду certbot certonly и конфиги nginx не меняются, работает хорошо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294635,294658#msg-294658 From chipitsine на gmail.com Wed Jul 6 11:44:26 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 6 Jul 2022 16:44:26 +0500 Subject: certbot In-Reply-To: References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> Message-ID: ср, 6 июл. 2022 г. в 02:53, Maxim Dounin : > Hello! > > On Tue, Jul 05, 2022 at 10:09:33PM +0300, Gena Makhomed wrote: > > > On 05.07.2022 15:55, Maxim Dounin wrote: > > > > > Отмечу, что если сертификаты обновлялись с помощью Certbot, то он > > > при обновлении модифицирует конфиги nginx'а (а потом возвращает > > > всё "как было"). Это может заканчиваться, скажем так, неожиданно. > > > Лично я рекомендую для выпуска сертификатов использовать > > > Dehydrated и необходимые дополнения в конфиг прописывать руками. > > > > certbot так криво себя ведет только в дефолтовой конфигурации. > > Этого достаточно, чтобы им не пользоваться. И уж тем более не > рекомендовать другим, ибо они с вероятностью, близкой к 100%, > будут использовать его именно в конфигурации по умолчанию. > > Тем более, что есть Dehydrated, который подобным идиотизмом по > умолчанию не страдает, да и представляет из себя вполне читаемый > bash-скрипт без дополнительных зависимостей. > там весьма запутанная ситуация с "официальным" клиентом LetsEncrypt. с одной стороны, есть ACME и к нему примерно миллион реализаций, среди которых и certbot. с другой стороны http://github.com/letsencrypt/letsencrypt --> https://github.com/certbot/certbot dehydrated и acme.sh - отличные примеры программирования на shell. без шуток. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Jul 6 19:00:22 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 6 Jul 2022 22:00:22 +0300 Subject: certbot In-Reply-To: <1bacf805-e79f-2b1a-46d3-042fae3ea8fd@csdoc.com> References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> <1bacf805-e79f-2b1a-46d3-042fae3ea8fd@csdoc.com> Message-ID: Hello! On Wed, Jul 06, 2022 at 09:00:05AM +0300, Gena Makhomed wrote: > On 06.07.2022 0:52, Maxim Dounin wrote: > > >>> Отмечу, что если сертификаты обновлялись с помощью Certbot, то он > >>> при обновлении модифицирует конфиги nginx'а (а потом возвращает > >>> всё "как было"). Это может заканчиваться, скажем так, неожиданно. > >>> Лично я рекомендую для выпуска сертификатов использовать > >>> Dehydrated и необходимые дополнения в конфиг прописывать руками. > > >> certbot так криво себя ведет только в дефолтовой конфигурации. > > > Этого достаточно, чтобы им не пользоваться. И уж тем более не > > рекомендовать другим, ибо они с вероятностью, близкой к 100%, > > будут использовать его именно в конфигурации по умолчанию. > > Если быть уж совсем точным, то при установке пакета certbot > пакет python3-certbot-nginx не устанавливается. python3-certbot-nginx - > это Plugin for certbot that allows for automatic configuration of nginx. > > Поэтому при выполнении команды certbot run -d example.com он выдает ошибку: > > Certbot doesn't know how to automatically configure the web server on > this system. However, it can still get a certificate for you. Please run > "certbot certonly" to do so. You'll need to manually configure your web > server to use the resulting certificate. > > Поэтому единственным рабочим вариантом получения сертификата > для nginx является только команда certbot certonly -d example.com > которая никаких автоматических изменений в конфиги nginx не вносит. > > certbot - это очень хорошо продуманный и качественно сделанный софт. Я наблюдал Certbot с Apache, где все приседания с изменением конфигурации на работающем сервере используются по умолчанию. Точнее, помогал разобраться, почему оно не работает. Мне хватило, чтобы не считать Certbot "хорошо продуманным и качественно сделанным". > > Тем более, что есть Dehydrated, который подобным идиотизмом по > > умолчанию не страдает, да и представляет из себя вполне читаемый > > bash-скрипт без дополнительных зависимостей. > > этот bash-скрипт имеет серьезные проблемы даже с парсингом json: > > https://www.opennet.ru/opennews/art.shtml?num=53279 > > тем более, что разработчик dehydrated - это всего лишь студент: > > https://www.opennet.ru/opennews/art.shtml?num=52294 Каждый выбирает приоритеты для себя. Кому-то не нравится парсинг json'а, возвращаемого конкретным сервисом, с помощью регулярных выражений, чтобы не тащить зависимости, а кому-то - переписывание конфига работающего сервера (с помощью тех же регулярных выражений, если продраться через зависимости) с непредсказуемыми последствиями. Я могу рекомендовать Dehydrated, он сделан хорошо и просто работает. И не могу рекомендовать Certbot, там проблема дизайна: конфиг сервера нельзя менять, не понимая всех аспектов работы этого конфига (и тем более нельзя менять в фоне и не говоря об этом пользователю), а авторы Certbot'а этого явного не понимают. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Wed Jul 6 19:15:19 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 6 Jul 2022 22:15:19 +0300 Subject: long deprecated directives In-Reply-To: <39bcd991-ba67-6dec-6fed-e002b58c4dcc@csdoc.com> References: <25ce637043fa83bc86a6b7c1794e9594.NginxMailingListRussian@forum.nginx.org> <39bcd991-ba67-6dec-6fed-e002b58c4dcc@csdoc.com> Message-ID: Hello! On Wed, Jul 06, 2022 at 08:15:43AM +0300, Gena Makhomed wrote: > On 06.07.2022 4:52, Maxim Dounin wrote: > > > Возможность задавать конфигурацию с помощью "listen ... ssl" > > появилась в nginx 0.7.14. > > > У вас явно некорректная конфигурация, использующая "ssl on;". > > Кстати, директива "ssl on;" находится в состоянии deprecated > начиная с версии 1.15.0, вышедшей 05 Jun 2018, более 4 лет тому назад. > > Может быть имеет смысл превратить warning в error, удалив > эту директиву из nginx и оставив только возможность "listen ... ssl" ? > > Тогда у пользователей будет меньше возможностей для создания > конфигураций, которые будут приводить к ошибкам такого вида: > 400 Bad Request The plain HTTP request was sent to HTTPS port > > Аналогичный вопрос и по остальным deprecated директивам: > > proxy_downstream_buffer > proxy_upstream_buffer > http2_idle_timeout > http2_max_field_size > http2_max_header_size > http2_max_requests > http2_recv_timeout > > - может быть имеет смысл их удалить из nginx? Удалить и заменить warning на фатальную ошибку - это два разных действия. Удаление директив позволяет избавиться от лишнего кода и больше об этом не думать. Обычно это делается, когда про существование директив забывают практически все, и/или наличие соответствующего кода начинает раздражать/мешать. Для упомянутых директив такой момент, кажется, ещё не наступил. Заменить warning на фатальную ошибку - как показала практика, не имеет смысла примерно никогда. Пока директива реально встречается в конфигах - warning даёт возможность переписать их в удобном администратору темпе, и соответственно предпочтительнее. А когда встречаться перестаёт - наступает момент для удаления директивы. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Wed Jul 6 19:21:21 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 6 Jul 2022 22:21:21 +0300 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port In-Reply-To: <8c4146965a4a28eda720fc45b6e2bdd0.NginxMailingListRussian@forum.nginx.org> References: <8c4146965a4a28eda720fc45b6e2bdd0.NginxMailingListRussian@forum.nginx.org> Message-ID: Hello! On Wed, Jul 06, 2022 at 04:44:41AM -0400, milov wrote: > Maxim Dounin Wrote: > ------------------------------------------------------- > > У вас явно некорректная конфигурация, использующая "ssl on;". > > Основное правило при использовании "ssl on;" очень простое: SSL и > > не-SSL listen-сокеты должны использоваться строго в разных блоках > > server{}. Любые попытки совместить - чреваты. Ибо если вдруг у > > вас в сервере по умолчанию для не-SSL listen-сокета окажется "ssl > > on;", то сокет станет SSL-сокетом. > > > > Скорее всего "раньше всегда работало" потому, что в сервера по > > умолчанию для не-SSL listen-сокетов стояли корректные, а сейчас > > из-за каких-то минимальных изменений конфига (скажем, кто-то > > добавил блок server с несколькими listen-сокетами и "ssl on;") - > > ситуация поменялась. > > > > Если по каким-то причинам хочется исправить конфигурацию, не > > переходя на "listen ... ssl" - показывайте полную конфигурацию, > > поможем найти источник проблем. > > > > Но проще и правильнее сразу переделать всё на использование > > "listen ... ssl", благо это тривиально: "ssl on;" из конфига > > убрать, а у listen-сокетов, которые должны использовать SSL, > > добавить флаг "ssl" (как минимум один раз, например, в сервере по > > умолчанию, но можно во всех директивах listen). > > > > Вот конфиг, я его постил в самом начале, как видите разнесено по разным > блокам server{} > > server { > listen 80; > server_name .local.map; > rewrite ^(.*) https://$host$1 permanent; > #return 301 https://$host$request_uri; > } > > server { > listen 443 ssl http2 default_server; > > ssl_certificate /etc/letsencrypt/live/local.map/fullchain.pem; > ssl_trusted_certificate /etc/letsencrypt/live/local.map/fullchain.pem; > ssl_certificate_key /etc/letsencrypt/live/local.map/privkey.pem; > > server_name .local.map; > set $root /var/www/msk/data/local.map; > root $root; > access_log off; ..... > > есть второй сайт, у которого конфиг такой-же, только пути разные плюс убрал > на другой айпи сокет и убрал default_server после чего заработало. Покажите полную конфигурацию - вывод "nginx -T". Как уже сказано выше, судя по симптомам у вас в конфиге где-то "ssl on;", и от этого проблемы. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Wed Jul 6 20:38:52 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 6 Jul 2022 23:38:52 +0300 Subject: certbot In-Reply-To: References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> <1bacf805-e79f-2b1a-46d3-042fae3ea8fd@csdoc.com> Message-ID: On 06.07.2022 22:00, Maxim Dounin wrote: >>>>> Отмечу, что если сертификаты обновлялись с помощью Certbot, то он >>>>> при обновлении модифицирует конфиги nginx'а (а потом возвращает >>>>> всё "как было"). Это может заканчиваться, скажем так, неожиданно. >>>>> Лично я рекомендую для выпуска сертификатов использовать >>>>> Dehydrated и необходимые дополнения в конфиг прописывать руками. >> >>>> certbot так криво себя ведет только в дефолтовой конфигурации. >> >>> Этого достаточно, чтобы им не пользоваться. И уж тем более не >>> рекомендовать другим, ибо они с вероятностью, близкой к 100%, >>> будут использовать его именно в конфигурации по умолчанию. Максим, я ошибся. В дефолтовой конфигурации он себя ведет несколько иначе. При установке пакета certbot и в RHEL-дистрибутивах и в Ubuntu плагины для модификации конфигов nginx и apache не устанавливаются. Если кто-то хочет их использовать - они устанавливаются отдельно, с помощью пакетов python3-certbot-nginx и python3-certbot-apache И даже в том случае, если эти плагины установлены - они по умолчанию, насколько я понимаю, не активируются - необходимо в командной строке задать соответствующий параметр активации плагина: --nginx или --apache Cлучайно испортить с certbot конфиг nginx или apache не получится - каждый пользователь делает это вполне осознанно и целенаправленно, вручную устанавливая на сервер и активируя соответствующий плагин. > Я могу рекомендовать Dehydrated, он сделан хорошо и просто > работает. И не могу рекомендовать Certbot, там проблема дизайна: > конфиг сервера нельзя менять, не понимая всех аспектов работы > этого конфига (и тем более нельзя менять в фоне и не говоря об > этом пользователю), а авторы Certbot'а этого явного не понимают. Проблема дизайна, о которой Вы говорите, есть только у двух плагинов: nginx и apache. Остальные плагины (standalone, manual, webroot, dns-*) работают очень даже хорошо, и к ним ведь у Вас нет никаких претензий? -- Best regards, Gena From mdounin на mdounin.ru Wed Jul 6 22:19:01 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 7 Jul 2022 01:19:01 +0300 Subject: certbot In-Reply-To: References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> <1bacf805-e79f-2b1a-46d3-042fae3ea8fd@csdoc.com> Message-ID: Hello! On Wed, Jul 06, 2022 at 11:38:52PM +0300, Gena Makhomed wrote: > On 06.07.2022 22:00, Maxim Dounin wrote: > > >>>>> Отмечу, что если сертификаты обновлялись с помощью Certbot, то он > >>>>> при обновлении модифицирует конфиги nginx'а (а потом возвращает > >>>>> всё "как было"). Это может заканчиваться, скажем так, неожиданно. > >>>>> Лично я рекомендую для выпуска сертификатов использовать > >>>>> Dehydrated и необходимые дополнения в конфиг прописывать руками. > >> > >>>> certbot так криво себя ведет только в дефолтовой конфигурации. > >> > >>> Этого достаточно, чтобы им не пользоваться. И уж тем более не > >>> рекомендовать другим, ибо они с вероятностью, близкой к 100%, > >>> будут использовать его именно в конфигурации по умолчанию. > > Максим, я ошибся. > В дефолтовой конфигурации он себя ведет несколько иначе. > > При установке пакета certbot и в RHEL-дистрибутивах и в Ubuntu > плагины для модификации конфигов nginx и apache не устанавливаются. > > Если кто-то хочет их использовать - они устанавливаются отдельно, > с помощью пакетов python3-certbot-nginx и python3-certbot-apache > > И даже в том случае, если эти плагины установлены - они по умолчанию, > насколько я понимаю, не активируются - необходимо в командной строке > задать соответствующий параметр активации плагина: --nginx или --apache > > Cлучайно испортить с certbot конфиг nginx или apache не получится - > каждый пользователь делает это вполне осознанно и целенаправленно, > вручную устанавливая на сервер и активируя соответствующий плагин. > > > Я могу рекомендовать Dehydrated, он сделан хорошо и просто > > работает. И не могу рекомендовать Certbot, там проблема дизайна: > > конфиг сервера нельзя менять, не понимая всех аспектов работы > > этого конфига (и тем более нельзя менять в фоне и не говоря об > > этом пользователю), а авторы Certbot'а этого явного не понимают. > > Проблема дизайна, о которой Вы говорите, есть только у двух плагинов: > nginx и apache. Остальные плагины (standalone, manual, webroot, dns-*) > работают очень даже хорошо, и к ним ведь у Вас нет никаких претензий? Документация на сайте предлагает "certbot --apache" в качестве основного варианта использования (например, тут: https://certbot.eff.org/instructions?ws=apache&os=ubuntufocal), и дальше уже не важно, какие ещё варианты есть: заметный процент пользователей будет делать именно то, что сказали. И получать предсказуемый (точнее, непредсказуемый) результат. И нет, наличие проблемы "авторы считают возможным менять конфиги" в одном из вариантов использования - не означает, что в других вариантах использования проблем нет. Наличие такой проблемы означает, что авторы не понимают проблему, и что там ещё и где разложено или будет разложено в будущем - неизвестно. И лично я предпочитаю пользоваться тем, что работает, и рекомендовать его же. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Thu Jul 7 08:34:26 2022 From: nginx-forum на forum.nginx.org (milov) Date: Thu, 07 Jul 2022 04:34:26 -0400 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port In-Reply-To: References: Message-ID: <14cd2382a613c4c118bc334ec279aeef.NginxMailingListRussian@forum.nginx.org> А как тут прикрепить файл? полотно длинное сюда постить. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294635,294667#msg-294667 From pnz.stalker на mail.ru Thu Jul 7 08:43:51 2022 From: pnz.stalker на mail.ru (=?UTF-8?B?0JDQvdGC0L7QvSDQk9C+0YDQu9C+0LI=?=) Date: Thu, 7 Jul 2022 11:43:51 +0300 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port In-Reply-To: <14cd2382a613c4c118bc334ec279aeef.NginxMailingListRussian@forum.nginx.org> References: <14cd2382a613c4c118bc334ec279aeef.NginxMailingListRussian@forum.nginx.org> Message-ID: 07.07.2022 11:34, milov пишет: > А как тут прикрепить файл? полотно длинное сюда постить. Нет сюда простыню не надо. Запостите содержимое например на http://paste.org.ru/ ,а сюда ссылку From nginx-forum на forum.nginx.org Thu Jul 7 08:52:26 2022 From: nginx-forum на forum.nginx.org (ru4ag) Date: Thu, 07 Jul 2022 04:52:26 -0400 Subject: =?UTF-8?Q?=D0=9F=D0=B5=D1=80=D0=B5=D1=87=D0=B8=D1=82=D0=BA=D0=B0=20?= =?UTF-8?Q?=D0=BA=D0=BE=D0=BD=D1=84=D0=B8=D0=B3=D1=83=D1=80=D0=B0=D1?= =?UTF-8?Q?=86=D0=B8=D0=B9=20nginx?= Message-ID: <54ffce8e0c3ae92f0e7ff4a109d54900.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Испольузем на больших серверах панель ISPmanager, в качестве веб-сервов связка nginx+apache(в некоторых случая nginx+php-fpm), столкнулись с такой ситуация что выполнение команды nginx -t может происходить более чем 5-8 секунд, что напрямую влияет на работу панели и т.д., в ходе анализа выявленно что для каждого домена панель создает несколько include, и один из них "подключает" 7-8 стандартных файлов с директории /etc/nginx/vhosts-includes/ и выходит что при каждом nginx -t проверяеться конфигурация домена, и каждого из его includ'ов, и в результате из общего количества открытия файлов во время nginx -t(используя просмотр через strace) в ~60тис файлов, 30тис обращений являються обращениями к одним и тем же 8 файлам. То есть по 3,5тис обращений на одини тот же файл. Вот и возникакет вопрос, ести ли какой то функционал возможно-го кеша, что бы подключенные через include одни и те же файлы не проверялись при 2,3,4...проверке(т.к. достаточно 1 раз проверить), и если нет(что скорее всего), стоит ли ожидать какой-то такой реализации в ядре nginx(как по мне "загнать" файл в кеш, и при последующей его проверка во время выполнения nginx -t/reload/restart уже не проверять)? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294669,294669#msg-294669 From swood на fotofor.biz Thu Jul 7 08:55:51 2022 From: swood на fotofor.biz (Anton Kiryushkin) Date: Thu, 7 Jul 2022 09:55:51 +0100 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10YfQuNGC0LrQsCDQutC+0L3RhNC40LPRg9GA0LDRhtC40Lkgbmdpbg==?= =?UTF-8?B?eA==?= In-Reply-To: <54ffce8e0c3ae92f0e7ff4a109d54900.NginxMailingListRussian@forum.nginx.org> References: <54ffce8e0c3ae92f0e7ff4a109d54900.NginxMailingListRussian@forum.nginx.org> Message-ID: 5-7 секунд еще не долго. Вот минут 5 - это было больно. И насколько я помню, влияет не число инклудов, а число локейшенов и апстримов. On Thu, 7 Jul 2022 at 09:54, ru4ag wrote: > Здравствуйте. > > Испольузем на больших серверах панель ISPmanager, в качестве веб-сервов > связка nginx+apache(в некоторых случая nginx+php-fpm), столкнулись с такой > ситуация что выполнение команды nginx -t может происходить более чем 5-8 > секунд, что напрямую влияет на работу панели и т.д., в ходе анализа > выявленно что для каждого домена панель создает несколько include, и один > из > них "подключает" 7-8 стандартных файлов с директории > /etc/nginx/vhosts-includes/ и выходит что при каждом nginx -t проверяеться > конфигурация домена, и каждого из его includ'ов, и в результате из общего > количества открытия файлов во время nginx -t(используя просмотр через > strace) в ~60тис файлов, 30тис обращений являються обращениями к одним и > тем > же 8 файлам. То есть по 3,5тис обращений на одини тот же файл. > > Вот и возникакет вопрос, ести ли какой то функционал возможно-го кеша, что > бы подключенные через include одни и те же файлы не проверялись при > 2,3,4...проверке(т.к. достаточно 1 раз проверить), и если нет(что скорее > всего), стоит ли ожидать какой-то такой реализации в ядре nginx(как по мне > "загнать" файл в кеш, и при последующей его проверка во время выполнения > nginx -t/reload/restart уже не проверять)? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,294669,294669#msg-294669 > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > -- Best regards, Anton Kiryushkin ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu Jul 7 08:57:27 2022 From: nginx-forum на forum.nginx.org (milov) Date: Thu, 07 Jul 2022 04:57:27 -0400 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port In-Reply-To: References: Message-ID: <2435335fd89a37302d7c95b11998cdb7.NginxMailingListRussian@forum.nginx.org> http://paste.org.ru/?j76h3l Изменил айпи, пути и домены. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294635,294670#msg-294670 From nginx-forum на forum.nginx.org Thu Jul 7 09:16:38 2022 From: nginx-forum на forum.nginx.org (ru4ag) Date: Thu, 07 Jul 2022 05:16:38 -0400 Subject: =?UTF-8?Q?Re:=20=D0=9F=D0=B5=D1=80=D0=B5=D1=87=D0=B8=D1=82=D0=BA=D0?= =?UTF-8?Q?=B0=20=D0=BA=D0=BE=D0=BD=D1=84=D0=B8=D0=B3=D1=83=D1=80=D0?= =?UTF-8?Q?=B0=D1=86=D0=B8=D0=B9=20nginx?= In-Reply-To: References: Message-ID: отключение данной директории(просто переименовав в /etc/nginx/vhosts-includes_) снижало время на перечитывание до 1.8-2сек, что в 2-3 раза быстрее. и проблема не в числе инклюдов, а в том что перечитываеться один и тот же файл(что идет в инклюде каждого хоста) множество раз, хотя логично было бы его перечитать 1 раз. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294669,294672#msg-294672 From bgx на protva.ru Thu Jul 7 09:17:40 2022 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 7 Jul 2022 12:17:40 +0300 Subject: certbot In-Reply-To: References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> <1bacf805-e79f-2b1a-46d3-042fae3ea8fd@csdoc.com> Message-ID: On Thu, Jul 07, 2022 at 01:19:01AM +0300, Maxim Dounin wrote: > Документация на сайте предлагает "certbot --apache" в качестве > основного варианта использования (например, тут: > https://certbot.eff.org/instructions?ws=apache&os=ubuntufocal), и > дальше уже не важно, какие ещё варианты есть: заметный процент > пользователей будет делать именно то, что сказали. И получать > предсказуемый (точнее, непредсказуемый) результат. Вставлю свои 2 копейки. Certbot пытается хоть как-то помочь чайникам. А для чайника, как для маленького ребёнка, весь мир -- бесконечное нагромождение проблем. Чайнику в паре строк конфига разобраться трудно, спасти предыдущую конфигурацию он не додумается, работу http-сервера он представляет себе смутно, а уж PKI и X509 это вообще ужас... Смешная вроде задача "выставить в интернет свою страничку так, чтобы гугл и яндекс не опустили сходу в рейтинге" становится неподъёмной. Certbot предлагает решение, работающее для дефолтных конфигураций наиболее популярных дистрибутивов. Понятно, что это решение для чайников, но писать явно об этом нельзя, чтобы не травмировать психику детей. :) Главное, это не единственный вариант у certbot'a. > И нет, наличие проблемы "авторы считают возможным менять конфиги" > в одном из вариантов использования - не означает, что в других > вариантах использования проблем нет. Наличие такой проблемы > означает, что авторы не понимают проблему, Может быть, понимают... Но одно дело написать код, а другое -- написать адекватную документацию к нему, которая будет одинково удобна и полезна как для новичка, так и для эксперта. Certbot в вариантах, не предполагающих правки конфигов, вполне себе работает. Можно сказать, "поставил и забыл". Думаю, для командны Nginx было бы неплохо вставить в дистрибутивный конфиг некую заготовку для "location /.well-known/acme-challenge {..}", и написать там комментарии как ею пользоваться. Возможно, пообщаться ещё с писателями certbot'a, чтобы вместе с ними сделать использование этой заготовки удобным и безопасным. Тогда всем новичкам станет легче. -- Eugene Berdnikov From bgx на protva.ru Thu Jul 7 09:29:20 2022 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 7 Jul 2022 12:29:20 +0300 Subject: =?utf-8?B?0J/QtdGA0LXRh9C40YLQutCwINC6?= =?utf-8?B?0L7QvdGE0LjQs9GD0YDQsNGG0LjQuQ==?= nginx In-Reply-To: References: Message-ID: On Thu, Jul 07, 2022 at 05:16:38AM -0400, ru4ag wrote: > и проблема не в числе инклюдов, а в том что перечитываеться один и тот же > файл(что идет в инклюде каждого хоста) множество раз, хотя логично было бы > его перечитать 1 раз. Интерпретация инклуда зависит от того, в какой блок он считывается... Если хочется сэкономить на на сисколах open() и close(), то что мешает генерить общий конфиг (через m4, cpp, etc), и затем загружать его целиком? -- Eugene Berdnikov From nginx-forum на forum.nginx.org Thu Jul 7 09:38:57 2022 From: nginx-forum на forum.nginx.org (ru4ag) Date: Thu, 07 Jul 2022 05:38:57 -0400 Subject: =?UTF-8?Q?Re:=20=D0=9F=D0=B5=D1=80=D0=B5=D1=87=D0=B8=D1=82=D0=BA=D0?= =?UTF-8?Q?=B0=20=D0=BA=D0=BE=D0=BD=D1=84=D0=B8=D0=B3=D1=83=D1=80=D0?= =?UTF-8?Q?=B0=D1=86=D0=B8=D0=B9=20nginx?= In-Reply-To: References: Message-ID: <3cfff62d6af3509a91a6f58c6aa79bf0.NginxMailingListRussian@forum.nginx.org> увы, такая логика панели по построению конфигураций, мы рассматриваем еще вариант свести все ти 8 файлов из инклуда в один файл, тогда вместо 30тис перечитываний, будет 3,5 тис. перечитывания конкретно него. Но не уверены что какое-то обновление панели это все не сломает, да и все-равно остаеться момент что один и тот жефайл перечитыветься 3 тис раз. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294669,294675#msg-294675 From chipitsine на gmail.com Thu Jul 7 09:40:21 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 7 Jul 2022 14:40:21 +0500 Subject: certbot In-Reply-To: References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> <1bacf805-e79f-2b1a-46d3-042fae3ea8fd@csdoc.com> Message-ID: чт, 7 июл. 2022 г. в 14:18, Evgeniy Berdnikov : > On Thu, Jul 07, 2022 at 01:19:01AM +0300, Maxim Dounin wrote: > > Документация на сайте предлагает "certbot --apache" в качестве > > основного варианта использования (например, тут: > > https://certbot.eff.org/instructions?ws=apache&os=ubuntufocal), и > > дальше уже не важно, какие ещё варианты есть: заметный процент > > пользователей будет делать именно то, что сказали. И получать > > предсказуемый (точнее, непредсказуемый) результат. > > Вставлю свои 2 копейки. Certbot пытается хоть как-то помочь чайникам. > А для чайника, как для маленького ребёнка, весь мир -- бесконечное > нагромождение проблем. Чайнику в паре строк конфига разобраться трудно, > спасти предыдущую конфигурацию он не додумается, работу http-сервера > он представляет себе смутно, а уж PKI и X509 это вообще ужас... > Смешная вроде задача "выставить в интернет свою страничку так, чтобы > гугл и яндекс не опустили сходу в рейтинге" становится неподъёмной. > > Certbot предлагает решение, работающее для дефолтных конфигураций > наиболее популярных дистрибутивов. Понятно, что это решение для чайников, > но писать явно об этом нельзя, чтобы не травмировать психику детей. :) > Главное, это не единственный вариант у certbot'a. > > > И нет, наличие проблемы "авторы считают возможным менять конфиги" > > в одном из вариантов использования - не означает, что в других > > вариантах использования проблем нет. Наличие такой проблемы > > означает, что авторы не понимают проблему, > > Может быть, понимают... Но одно дело написать код, а другое -- написать > адекватную документацию к нему, которая будет одинково удобна и полезна > как для новичка, так и для эксперта. > > Certbot в вариантах, не предполагающих правки конфигов, вполне себе > работает. Можно сказать, "поставил и забыл". > > Думаю, для командны Nginx было бы неплохо вставить в дистрибутивный > конфиг некую заготовку для "location /.well-known/acme-challenge {..}", > с документированием механизмов интеграции ACME с веб-серверами вообще не хватает качественной документации. например, мы партизанским способом узнали, что можно из .well-known/acme-challenge редиректить по 301, и таким образом, сильно централизовать и упростить внедрение lets encrypt > и написать там комментарии как ею пользоваться. Возможно, пообщаться > ещё с писателями certbot'a, чтобы вместе с ними сделать использование > этой заготовки удобным и безопасным. Тогда всем новичкам станет легче. > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Thu Jul 7 09:57:35 2022 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 7 Jul 2022 12:57:35 +0300 Subject: =?utf-8?B?0J/QtdGA0LXRh9C40YLQutCwINC6?= =?utf-8?B?0L7QvdGE0LjQs9GD0YDQsNGG0LjQuQ==?= nginx In-Reply-To: <3cfff62d6af3509a91a6f58c6aa79bf0.NginxMailingListRussian@forum.nginx.org> References: <3cfff62d6af3509a91a6f58c6aa79bf0.NginxMailingListRussian@forum.nginx.org> Message-ID: On Thu, Jul 07, 2022 at 05:38:57AM -0400, ru4ag wrote: > увы, такая логика панели по построению конфигураций, мы рассматриваем еще > вариант свести все ти 8 файлов из инклуда в один файл, тогда вместо 30тис > перечитываний, будет 3,5 тис. перечитывания конкретно него. Но не уверены > что какое-то обновление панели это все не сломает, да и все-равно остаеться > момент что один и тот жефайл перечитыветься 3 тис раз. Логика панели тут побоку. Панель раскладывает конфигурацию в набор файлов. Вам нужно этот набор превратить в один файл. Для этого делаете свой парсер директив "include", возможно, применяя для этого штатные средства других препроцессоров, чтобы include объявить макросом. -- Eugene Berdnikov From bgx на protva.ru Thu Jul 7 10:14:42 2022 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 7 Jul 2022 13:14:42 +0300 Subject: certbot In-Reply-To: References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> <1bacf805-e79f-2b1a-46d3-042fae3ea8fd@csdoc.com> Message-ID: On Thu, Jul 07, 2022 at 02:40:21PM +0500, Илья Шипицин wrote: > например, мы партизанским способом узнали, что можно из > .well-known/acme-challenge редиректить по 301, и таким образом, > сильно централизовать и упростить внедрение lets encrypt Зачем редиректить? Можно же проксировать .well-known/acme-challenge. Всё равно такой локейшн в конфиг нужно вставлять. И проксировать ведь безопасней, потому что при проксировании узел с certbot-ом може сделать вообще недоступным для соединений из интернета. А доступ к сайтам для передачи сертификатов дать лишь узлу с certbot-ом. -- Eugene Berdnikov From chipitsine на gmail.com Thu Jul 7 10:15:20 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 7 Jul 2022 15:15:20 +0500 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10YfQuNGC0LrQsCDQutC+0L3RhNC40LPRg9GA0LDRhtC40Lkgbmdpbg==?= =?UTF-8?B?eA==?= In-Reply-To: <54ffce8e0c3ae92f0e7ff4a109d54900.NginxMailingListRussian@forum.nginx.org> References: <54ffce8e0c3ae92f0e7ff4a109d54900.NginxMailingListRussian@forum.nginx.org> Message-ID: а у вас в конфигах много днс имен ? у нас основное время на "nginx -t" складывалось из днс запросов. кеш днс (systemd-resolved .... nscd .... dnsmasq ...) включен ? еще SSL серты могут много занимать на первоначальном парсинге чт, 7 июл. 2022 г. в 13:52, ru4ag : > Здравствуйте. > > Испольузем на больших серверах панель ISPmanager, в качестве веб-сервов > связка nginx+apache(в некоторых случая nginx+php-fpm), столкнулись с такой > ситуация что выполнение команды nginx -t может происходить более чем 5-8 > секунд, что напрямую влияет на работу панели и т.д., в ходе анализа > выявленно что для каждого домена панель создает несколько include, и один > из > них "подключает" 7-8 стандартных файлов с директории > /etc/nginx/vhosts-includes/ и выходит что при каждом nginx -t проверяеться > конфигурация домена, и каждого из его includ'ов, и в результате из общего > количества открытия файлов во время nginx -t(используя просмотр через > strace) в ~60тис файлов, 30тис обращений являються обращениями к одним и > тем > же 8 файлам. То есть по 3,5тис обращений на одини тот же файл. > > Вот и возникакет вопрос, ести ли какой то функционал возможно-го кеша, что > бы подключенные через include одни и те же файлы не проверялись при > 2,3,4...проверке(т.к. достаточно 1 раз проверить), и если нет(что скорее > всего), стоит ли ожидать какой-то такой реализации в ядре nginx(как по мне > "загнать" файл в кеш, и при последующей его проверка во время выполнения > nginx -t/reload/restart уже не проверять)? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,294669,294669#msg-294669 > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Jul 7 10:37:21 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 7 Jul 2022 15:37:21 +0500 Subject: certbot In-Reply-To: References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> <1bacf805-e79f-2b1a-46d3-042fae3ea8fd@csdoc.com> Message-ID: чт, 7 июл. 2022 г. в 15:15, Evgeniy Berdnikov : > On Thu, Jul 07, 2022 at 02:40:21PM +0500, Илья Шипицин wrote: > > например, мы партизанским способом узнали, что можно из > > .well-known/acme-challenge редиректить по 301, и таким образом, > > сильно централизовать и упростить внедрение lets encrypt > > Зачем редиректить? Можно же проксировать .well-known/acme-challenge. > в сети датацетров обычно доступ между сетевыми сегментами ограничен. и запроксировать из кучи разных мест в единственную виртуалку с certbot - ну так себе развлечение. вот, например Certera > Всё равно такой локейшн в конфиг нужно вставлять. И проксировать ведь > безопасней, потому что при проксировании узел с certbot-ом може сделать > вообще недоступным для соединений из интернета. А доступ к сайтам для > передачи сертификатов дать лишь узлу с certbot-ом. > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From vovansystems на gmail.com Thu Jul 7 11:59:34 2022 From: vovansystems на gmail.com (VovansystemS) Date: Thu, 7 Jul 2022 14:59:34 +0300 Subject: =?UTF-8?B?0LrQtdGI0LjRgNC+0LLQsNGC0Ywg0YLQvtC70YzQutC+INC+0YLQstC10YLRiyDQs9C0?= =?UTF-8?B?0LUg0LXRgdGC0Ywg0L7Qv9GA0LXQtNC10LvRkdC90L3Ri9C5IFNldC1Db29raWU=?= Message-ID: Добрый день, нужно избирательно кешировать ответы бэкэнда в nginx. Некоторые ответы содержат Set-Cookie заголовки.По-умолчанию их кешировать не нужно, но если встречается определённая куки, то такой ответ нужно кешировать. пример: кешируем ответ с заголовком: Set-Cookie: pll_language=en; expires=Fri, 07-Jul-2023 11:37:39 GMT; Max-Age=31536000; path=/; secure; SameSite=Lax не кешируем ответ с сессией пользователя с заголовком: Set-Cookie: login=i324iuhkj324; expires=Fri, 10-Jul-2023 11:37:39 GMT; Max-Age=31536000; path=/; secure пытаюсь делать так: map $upstream_http_set_cookie $bypass_cache { "~*.pll" 0; default 1; } server { [..] location @granted { [..] proxy_ignore_headers Set-cookie; proxy_no_cache $bypass_cache; proxy_cache_bypass $bypass_cache; add_header X-Bypass $bypass_cache; add_header X-upstream-set-cookie "aaa $upstream_http_set_cookie"; [..] } [..] } в ответе получаю: X-Bypass: 1 X-upstream-set-cookie: aaa pll_language=en; expires=Fri, 07-Jul-2023 11:37:39 GMT; Max-Age=31536000; path=/; secure; SameSite=Lax такое впечатление, что директива add_header корректно видит содержимое заголовка ответа апстрима, а вот map (и if тоже пытался) - не видят содержимого ни $upstream_http_set_cookie ни $upstream_cookie_pll_language. Может быть есть какие-то мысли как такое лучше реализовать и возможно ли это вообще? nginx -v nginx version: nginx/1.19.2 nginx -V nginx version: nginx/1.19.2 built by gcc 8.3.0 (Debian 8.3.0-6) built with OpenSSL 1.1.1d 10 Sep 2019 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 -fdebug-prefix-map=/data/builder/debuild/nginx-1.19.2/debian/debuild-base/nginx-1.19.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' From mdounin на mdounin.ru Thu Jul 7 19:15:02 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 7 Jul 2022 22:15:02 +0300 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port In-Reply-To: <2435335fd89a37302d7c95b11998cdb7.NginxMailingListRussian@forum.nginx.org> References: <2435335fd89a37302d7c95b11998cdb7.NginxMailingListRussian@forum.nginx.org> Message-ID: Hello! On Thu, Jul 07, 2022 at 04:57:27AM -0400, milov wrote: > http://paste.org.ru/?j76h3l Изменил айпи, пути и домены. Каких-либо проблем в конфиге, относящихся к обсуждаемому вопросу, я не вижу: директива "ssl" в конфиге не используется вообще, каких-либо перенаправлений, где бы мог быть указан порт (и соответственно могло бы вылезти несовпадение схемы и порта), опять же нет. А как выглядят сообщения об ошибках в error log'е полностью? Интересует в первую очередь дополнительные поля, указанные после ошибки, в частности, server, request, host, и referrer. Ну и если проблема воспроизводится из браузера (а тема как бы намекает, что да) - посмотрите, какие именно запросы делаются, и что именно на них отвечают. Возможно, причина где-то в php-коде, и в некорректных перенаправлениях, возвращаемых из него. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Fri Jul 8 02:45:00 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 8 Jul 2022 05:45:00 +0300 Subject: =?koi8-r?B?y8XbydLP18HU2CDUz8zYy88g?= =?koi8-r?B?z9TXxdTZIMfExSDF09TYIM/Q0sXExcyjzs7Zyg==?= Set-Cookie In-Reply-To: References: Message-ID: Hello! On Thu, Jul 07, 2022 at 02:59:34PM +0300, VovansystemS wrote: > Добрый день, > > нужно избирательно кешировать ответы бэкэнда в nginx. Некоторые ответы > содержат Set-Cookie заголовки.По-умолчанию их кешировать не нужно, но > если встречается определённая куки, то такой ответ нужно кешировать. > > пример: > > кешируем ответ с заголовком: > Set-Cookie: pll_language=en; expires=Fri, 07-Jul-2023 11:37:39 GMT; > Max-Age=31536000; path=/; secure; SameSite=Lax > > не кешируем ответ с сессией пользователя с заголовком: > Set-Cookie: login=i324iuhkj324; expires=Fri, 10-Jul-2023 11:37:39 GMT; > Max-Age=31536000; path=/; secure > > пытаюсь делать так: > > map $upstream_http_set_cookie $bypass_cache { > "~*.pll" 0; > default 1; > } > > server { > [..] > location @granted { > [..] > proxy_ignore_headers Set-cookie; > proxy_no_cache $bypass_cache; > proxy_cache_bypass $bypass_cache; > add_header X-Bypass $bypass_cache; > add_header X-upstream-set-cookie "aaa $upstream_http_set_cookie"; > [..] > } > [..] > } > > в ответе получаю: > X-Bypass: 1 > X-upstream-set-cookie: aaa pll_language=en; expires=Fri, 07-Jul-2023 > 11:37:39 GMT; Max-Age=31536000; path=/; secure; SameSite=Lax > > такое впечатление, что директива add_header корректно видит содержимое > заголовка ответа апстрима, а вот map (и if тоже пытался) - не видят > содержимого ни $upstream_http_set_cookie ни > $upstream_cookie_pll_language. > > Может быть есть какие-то мысли как такое лучше реализовать и возможно > ли это вообще? У вас map выполняется в proxy_cache_bypass, то есть до отправки запроса на бэкенд, и запоминает результат (некорректный, так как он основан на ещё не полученных от бэкенда заголовках ответа). Очевидное решение - директиву proxy_cache_bypass убрать, она тут работать не может. Решение "сохранять ли в кэш полученный от бэкенда ответ" принимается с помощью директивы proxy_no_cache, её одной вполне достаточно. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Fri Jul 8 18:02:02 2022 From: nginx-forum на forum.nginx.org (milov) Date: Fri, 08 Jul 2022 14:02:02 -0400 Subject: =?UTF-8?Q?Re:=20=D0=BA=D0=B5=D1=88=D0=B8=D1=80=D0=BE=D0=B2=D0=B0=D1?= =?UTF-8?Q?=82=D1=8C=20=D1=82=D0=BE=D0=BB=D1=8C=D0=BA=D0=BE=20=D0=BE?= =?UTF-8?Q?=D1=82=D0=B2=D0=B5=D1=82=D1=8B=20=D0=B3=D0=B4=D0=B5=20=D0?= =?UTF-8?Q?=B5=D1=81=D1=82=D1=8C=20=D0=BE=D0=BF=D1=80=D0=B5=D0=B4=D0?= =?UTF-8?Q?=B5=D0=BB=D1=91=D0=BD=D0=BD=D1=8B=D0=B9=20Set-Cookie?= In-Reply-To: References: Message-ID: Тоже вопрос на ту же тему, чтоб не плодить темы. Есть код set $no_cache 0; if ($request_method = POST){set $no_cache 1;} if ($http_host ~* success.html$){set $no_cache 1;} if ($remote_addr ~* ^(192.168.0*)$){set $no_cache 1;} # Не берется из кеша fastcgi_cache_bypass $no_cache; # Не сохраняется в кеш fastcgi_no_cache $no_cache; Ни один if не срабатывает. Куда смотреть, копать? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294681,294690#msg-294690 From vovansystems на gmail.com Sat Jul 9 08:10:32 2022 From: vovansystems на gmail.com (VovansystemS) Date: Sat, 9 Jul 2022 11:10:32 +0300 Subject: =?UTF-8?B?UmU6INC60LXRiNC40YDQvtCy0LDRgtGMINGC0L7Qu9GM0LrQviDQvtGC0LLQtdGC0Ysg?= =?UTF-8?B?0LPQtNC1INC10YHRgtGMINC+0L/RgNC10LTQtdC70ZHQvdC90YvQuSBTZXQtQ29va2ll?= In-Reply-To: References: Message-ID: Добрый день, > У вас map выполняется в proxy_cache_bypass, то есть до отправки > запроса на бэкенд, и запоминает результат (некорректный, так как > он основан на ещё не полученных от бэкенда заголовках ответа). Спасибо большое за быстрый ответ, - помогло! Результирующая конфигурация для моих целей получилась такая: map $upstream_http_set_cookie $bypass_cache { "~*pll" 0; "~*=" 1; } proxy_ignore_headers "Set-cookie"; proxy_no_cache $bypass_cache; Ответы содержащие заголовок Set-cookie могут кешироваться. Если в заголовке Set-cookie встречается pll - такой ответ кешируется. Если в заголовке Set-cookie встречается любое другое установленное значение (есть символ "="), то такой ответ кешироваться не будет. Если же заголовок Set-cookie пустой, то такой ответ будет кешироваться. From nginx-forum на forum.nginx.org Sat Jul 9 08:46:23 2022 From: nginx-forum на forum.nginx.org (milov) Date: Sat, 09 Jul 2022 04:46:23 -0400 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port In-Reply-To: References: Message-ID: Как выловить такие ошибки в логе? я их не вижу, есть ошибки типа warn Но это не то. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294635,294697#msg-294697 From mdounin на mdounin.ru Sun Jul 10 08:41:30 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sun, 10 Jul 2022 11:41:30 +0300 Subject: 400 Bad Request The plain HTTP request was sent to HTTPS port In-Reply-To: References: Message-ID: Hello! On Sat, Jul 09, 2022 at 04:46:23AM -0400, milov wrote: > Как выловить такие ошибки в логе? я их не вижу, есть ошибки типа warn Но это > не то. Вы чуть раньше в этом треде писали Илье, "client sent plain HTTP request to HTTPS port". Как и другие ошибки в клиентских запросах, эти ошибки логгируются на уровне info. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Mon Jul 11 18:06:53 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 11 Jul 2022 21:06:53 +0300 Subject: SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking In-Reply-To: References: Message-ID: <9765032e-3b9a-4d03-64c7-93964f695529@csdoc.com> On 10.07.2022 11:41, Maxim Dounin wrote: >> Как выловить такие ошибки в логе? >> я их не вижу, есть ошибки типа warn Но это не то. > Вы чуть раньше в этом треде писали Илье, "client sent plain HTTP > request to HTTPS port". Как и другие ошибки в клиентских > запросах, эти ошибки логгируются на уровне info. nginx/1.23.0 из официального репозитория nginx.org пишет в лог: 2022/07/11 13:14:48 [crit] 67688#67688: *154358 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 192.241.214.22, server: 0.0.0.0:443 проблема тут https://stackoverflow.com/a/67424645 на стороне клиента, но в лог информация пишется на уровне [crit] - так и должно быть? -- Best regards, Gena From mdounin на mdounin.ru Tue Jul 12 01:23:59 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 12 Jul 2022 04:23:59 +0300 Subject: SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking In-Reply-To: <9765032e-3b9a-4d03-64c7-93964f695529@csdoc.com> References: <9765032e-3b9a-4d03-64c7-93964f695529@csdoc.com> Message-ID: Hello! On Mon, Jul 11, 2022 at 09:06:53PM +0300, Gena Makhomed wrote: > On 10.07.2022 11:41, Maxim Dounin wrote: > > >> Как выловить такие ошибки в логе? > >> я их не вижу, есть ошибки типа warn Но это не то. > > > Вы чуть раньше в этом треде писали Илье, "client sent plain HTTP > > request to HTTPS port". Как и другие ошибки в клиентских > > запросах, эти ошибки логгируются на уровне info. > > nginx/1.23.0 из официального репозитория nginx.org пишет в лог: > > 2022/07/11 13:14:48 [crit] 67688#67688: *154358 SSL_do_handshake() > failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad > key share) while SSL handshaking, client: 192.241.214.22, server: > 0.0.0.0:443 > > проблема тут https://stackoverflow.com/a/67424645 на стороне клиента, > но в лог информация пишется на уровне [crit] - так и должно быть? Нет, так не должно быть. Просто это относительно новая ошибка, добавленная в OpenSSL 1.1.1 / TLSv1.3, и ей пока не прибит правильный уровень логгирования. Патч ниже. Если в логах вылезает что-то ещё - можно и нужно жаловаться. # HG changeset patch # User Maxim Dounin # Date 1657587735 -10800 # Tue Jul 12 04:02:15 2022 +0300 # Node ID ae4b86fa92e6eb0c1fa13482695218b334f2adc3 # Parent 219217ea49a8d648f5cadd046f1b1294ef05693c SSL: logging levels of various errors added in OpenSSL 1.1.1. Starting with OpenSSL 1.1.1, various additional errors can be reported by OpenSSL in case of client-related issues, most notably during TLSv1.3 handshakes. In particular, SSL_R_BAD_KEY_SHARE ("bad key share"), SSL_R_BAD_EXTENSION ("bad extension"), SSL_R_BAD_CIPHER ("bad cipher"), SSL_R_BAD_ECPOINT ("bad ecpoint"). These are now logged at the "info" level. diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c --- a/src/event/ngx_event_openssl.c +++ b/src/event/ngx_event_openssl.c @@ -3343,6 +3343,12 @@ ngx_ssl_connection_error(ngx_connection_ #ifdef SSL_R_NO_SUITABLE_KEY_SHARE || n == SSL_R_NO_SUITABLE_KEY_SHARE /* 101 */ #endif +#ifdef SSL_R_BAD_KEY_SHARE + || n == SSL_R_BAD_KEY_SHARE /* 108 */ +#endif +#ifdef SSL_R_BAD_EXTENSION + || n == SSL_R_BAD_EXTENSION /* 110 */ +#endif #ifdef SSL_R_NO_SUITABLE_SIGNATURE_ALGORITHM || n == SSL_R_NO_SUITABLE_SIGNATURE_ALGORITHM /* 118 */ #endif @@ -3357,6 +3363,9 @@ ngx_ssl_connection_error(ngx_connection_ || n == SSL_R_NO_CIPHERS_PASSED /* 182 */ #endif || n == SSL_R_NO_CIPHERS_SPECIFIED /* 183 */ +#ifdef SSL_R_BAD_CIPHER + || n == SSL_R_BAD_CIPHER /* 186 */ +#endif || n == SSL_R_NO_COMPRESSION_SPECIFIED /* 187 */ || n == SSL_R_NO_SHARED_CIPHER /* 193 */ || n == SSL_R_RECORD_LENGTH_MISMATCH /* 213 */ @@ -3391,6 +3400,9 @@ ngx_ssl_connection_error(ngx_connection_ #ifdef SSL_R_APPLICATION_DATA_ON_SHUTDOWN || n == SSL_R_APPLICATION_DATA_ON_SHUTDOWN /* 291 */ #endif +#ifdef SSL_R_BAD_ECPOINT + || n == SSL_R_BAD_ECPOINT /* 306 */ +#endif #ifdef SSL_R_RENEGOTIATE_EXT_TOO_LONG || n == SSL_R_RENEGOTIATE_EXT_TOO_LONG /* 335 */ || n == SSL_R_RENEGOTIATION_ENCODING_ERR /* 336 */ -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Tue Jul 12 11:42:44 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 12 Jul 2022 14:42:44 +0300 Subject: [warn] a client request body is buffered to a temporary file Message-ID: <7c24483a-2eec-0902-ec66-70cf6e79e00f@csdoc.com> Здравствуйте, All! nginx/1.23.0 из официального репозитория nginx.org В логах есть такой варнинг: 2022/07/12 13:56:37 [warn] 14352#14352: *183 a client request body is buffered to a temporary file /var/cache/nginx/client_temp/0000000011, client: 10.23.154.207, server: sentry.example.com, request: "POST /api/22/envelope/ HTTP/2.0", host: "sentry.example.com" Судя по информации из access-лога - размер контента - 41 байт: # grep /api/22/envelope/ access.log | grep 13:56:37 | less 2022-07-12T13:56:37+03:00 GB 10.23.154.207 https sentry.example.com POST "/api/22/envelope/" 200 41 "-" "sentry.php.laravel/2.9.0" 0.010 0.002 Если прописать в nginx.conf директиву client_body_buffer_size 32k; - тогда варнинг из error.log пропадает, но если вернуть дефолтовое значение client_body_buffer_size 16k; - варнинг снова появляется логах. Размер контента - всего 41 байт. Как такое может быть? client_body_buffer_size - эта переменная задает только статический размер буфера, и в nginx сейчас нельзя сделать динамическое выделение буфера по необходимости, как это сделано в директиве proxy_buffers ? Возможно было бы логичним, для экономии памяти сделать возможность задавать client_body_buffer_size по аналогии с proxy_buffers, например так: client_body_buffer_size 8k; client_body_buffers 32 8k; -- Best regards, Gena From pluknet на nginx.com Tue Jul 12 11:52:16 2022 From: pluknet на nginx.com (Sergey Kandaurov) Date: Tue, 12 Jul 2022 15:52:16 +0400 Subject: SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking In-Reply-To: References: <9765032e-3b9a-4d03-64c7-93964f695529@csdoc.com> Message-ID: <20220712115216.cg47u3wphbgzwyet@Y9MQ9X2QVV> On Tue, Jul 12, 2022 at 04:23:59AM +0300, Maxim Dounin wrote: > Hello! > > On Mon, Jul 11, 2022 at 09:06:53PM +0300, Gena Makhomed wrote: > > > On 10.07.2022 11:41, Maxim Dounin wrote: > > > > >> Как выловить такие ошибки в логе? > > >> я их не вижу, есть ошибки типа warn Но это не то. > > > > > Вы чуть раньше в этом треде писали Илье, "client sent plain HTTP > > > request to HTTPS port". Как и другие ошибки в клиентских > > > запросах, эти ошибки логгируются на уровне info. > > > > nginx/1.23.0 из официального репозитория nginx.org пишет в лог: > > > > 2022/07/11 13:14:48 [crit] 67688#67688: *154358 SSL_do_handshake() > > failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad > > key share) while SSL handshaking, client: 192.241.214.22, server: > > 0.0.0.0:443 > > > > проблема тут https://stackoverflow.com/a/67424645 на стороне клиента, > > но в лог информация пишется на уровне [crit] - так и должно быть? > > Нет, так не должно быть. Просто это относительно новая ошибка, > добавленная в OpenSSL 1.1.1 / TLSv1.3, и ей пока не прибит > правильный уровень логгирования. Патч ниже. > > Если в логах вылезает что-то ещё - можно и нужно жаловаться. > > # HG changeset patch > # User Maxim Dounin > # Date 1657587735 -10800 > # Tue Jul 12 04:02:15 2022 +0300 > # Node ID ae4b86fa92e6eb0c1fa13482695218b334f2adc3 > # Parent 219217ea49a8d648f5cadd046f1b1294ef05693c > SSL: logging levels of various errors added in OpenSSL 1.1.1. > > Starting with OpenSSL 1.1.1, various additional errors can be reported > by OpenSSL in case of client-related issues, most notably during TLSv1.3 > handshakes. In particular, SSL_R_BAD_KEY_SHARE ("bad key share"), > SSL_R_BAD_EXTENSION ("bad extension"), SSL_R_BAD_CIPHER ("bad cipher"), > SSL_R_BAD_ECPOINT ("bad ecpoint"). These are now logged at the "info" > level. Looks good. I managed to repoduce all of the errors except SSL_R_BAD_CIPHER, which requires extra effort to implement HRR in order to trigger it. Others are easy to trigger. If trying to enumerate TLSv1.3-specific client errors, I'd also add these I catched with my QUIC tests adjusted to generic TLSv1.3 over TCP: boringssl/include/openssl/ssl.h:#define SSL_R_MISSING_KEY_SHARE 258 boringssl/include/openssl/ssl.h:#define SSL_R_DUPLICATE_KEY_SHARE 264 - extension is either missing or includes a dublicate group OpenSSL has a similar error "no suitable key share" for MISSING_KEY_SHARE. I couldn't find an equivalent for DUPLICATE_KEY_SHARE, though. boringssl/include/openssl/ssl.h:#define SSL_R_ERROR_PARSING_EXTENSION 149 boringssl/include/openssl/ssl.h:#define SSL_R_PARSE_TLSEXT 190 - both enqueued when e.g. receiving QUIC transport params in generic TLSv1.3: "SSL: error:10000095:SSL routines:OPENSSL_internal:ERROR_PARSING_EXTENSION:extension 57 error:100000be:SSL routines:OPENSSL_internal:PARSE_TLSEXT) while SSL handshaking" PARSE_TLSEXT seems to be a rough replacement for SSL_R_BAD_EXTENSION. Note: several of these BoringSSL-specific errors have number reused. > > diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c > --- a/src/event/ngx_event_openssl.c > +++ b/src/event/ngx_event_openssl.c > @@ -3343,6 +3343,12 @@ ngx_ssl_connection_error(ngx_connection_ > #ifdef SSL_R_NO_SUITABLE_KEY_SHARE > || n == SSL_R_NO_SUITABLE_KEY_SHARE /* 101 */ > #endif > +#ifdef SSL_R_BAD_KEY_SHARE > + || n == SSL_R_BAD_KEY_SHARE /* 108 */ > +#endif > +#ifdef SSL_R_BAD_EXTENSION > + || n == SSL_R_BAD_EXTENSION /* 110 */ > +#endif > #ifdef SSL_R_NO_SUITABLE_SIGNATURE_ALGORITHM > || n == SSL_R_NO_SUITABLE_SIGNATURE_ALGORITHM /* 118 */ > #endif > @@ -3357,6 +3363,9 @@ ngx_ssl_connection_error(ngx_connection_ > || n == SSL_R_NO_CIPHERS_PASSED /* 182 */ > #endif > || n == SSL_R_NO_CIPHERS_SPECIFIED /* 183 */ > +#ifdef SSL_R_BAD_CIPHER > + || n == SSL_R_BAD_CIPHER /* 186 */ > +#endif > || n == SSL_R_NO_COMPRESSION_SPECIFIED /* 187 */ > || n == SSL_R_NO_SHARED_CIPHER /* 193 */ > || n == SSL_R_RECORD_LENGTH_MISMATCH /* 213 */ > @@ -3391,6 +3400,9 @@ ngx_ssl_connection_error(ngx_connection_ > #ifdef SSL_R_APPLICATION_DATA_ON_SHUTDOWN > || n == SSL_R_APPLICATION_DATA_ON_SHUTDOWN /* 291 */ > #endif > +#ifdef SSL_R_BAD_ECPOINT > + || n == SSL_R_BAD_ECPOINT /* 306 */ > +#endif > #ifdef SSL_R_RENEGOTIATE_EXT_TOO_LONG > || n == SSL_R_RENEGOTIATE_EXT_TOO_LONG /* 335 */ > || n == SSL_R_RENEGOTIATION_ENCODING_ERR /* 336 */ > diff -r 6d0fd3d3b91e src/event/ngx_event_openssl.c --- a/src/event/ngx_event_openssl.c Wed Jun 22 13:15:15 2022 +0400 +++ b/src/event/ngx_event_openssl.c Tue Jul 12 15:42:26 2022 +0400 @@ -3355,6 +3355,9 @@ ngx_ssl_connection_error(ngx_connection_ #endif || n == SSL_R_BLOCK_CIPHER_PAD_IS_WRONG /* 129 */ || n == SSL_R_DIGEST_CHECK_FAILED /* 149 */ +#ifdef SSL_R_ERROR_PARSING_EXTENSION + || n == SSL_R_ERROR_PARSING_EXTENSION /* 149 */ +#endif || n == SSL_R_ERROR_IN_RECEIVED_CIPHER_LIST /* 151 */ || n == SSL_R_EXCESSIVE_MESSAGE_SIZE /* 152 */ || n == SSL_R_HTTPS_PROXY_REQUEST /* 155 */ @@ -3387,6 +3390,12 @@ ngx_ssl_connection_error(ngx_connection_ || n == SSL_R_NO_COMMON_SIGNATURE_ALGORITHMS /* 253 */ #endif || n == SSL_R_UNSUPPORTED_PROTOCOL /* 258 */ +#ifdef SSL_R_MISSING_KEY_SHARE + || n == SSL_R_MISSING_KEY_SHARE /* 258 */ +#endif +#ifdef SSL_R_DUPLICATE_KEY_SHARE + || n == SSL_R_DUPLICATE_KEY_SHARE /* 264 */ +#endif #ifdef SSL_R_NO_SHARED_GROUP || n == SSL_R_NO_SHARED_GROUP /* 266 */ #endif From gmm на csdoc.com Tue Jul 12 13:45:45 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 12 Jul 2022 16:45:45 +0300 Subject: [error] access forbidden by rule In-Reply-To: References: Message-ID: <56969995-8a38-9f5b-9401-546474fb8028@csdoc.com> On 10.07.2022 11:41, Maxim Dounin wrote: > Вы чуть раньше в этом треде писали Илье, "client sent plain HTTP > request to HTTPS port". Как и другие ошибки в клиентских > запросах, эти ошибки логгируются на уровне info. nginx/1.23.0 из официального репозитория nginx.org В error.log есть такая запись: 2022/07/12 16:00:00 [error] 16594#16594: *21415 access forbidden by rule, client: 62.46.205.111, server: gitlab.example.com, request: "GET /api/v4/user HTTP/2.0", host: "gitlab.example.com" То, что какому-то клиенту возвращается 403 статус - разве это ошибка, которую необходимо писать в error.log на уровне [error] а не [info] ? Кстати, директивы limit_conn_log_level и limit_req_log_level зачем-то по умолчанию стоят на уровне error, как будто это есть ошибка на стороне сервера, если какому-то клиенту будет запрещен доступ. Директива deny_log_level в nginx вообще отсутствует. Может быть имеет смысл сделать директиву deny_log_level и для всех трех директив: limit_conn_log_level, limit_req_log_level и deny_log_level сделать значением по умолчанию info ? Это было бы логично и соответствовало бы общему правилу, что все ошибки в клиентских запросах логгируются на уровне info. P.S. Конфиг /etc/nginx/conf.d/gitlab.example.com.conf: server { listen 443 ssl http2; server_name gitlab.example.com; ssl_certificate /etc/letsencrypt/live/gitlab.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/gitlab.example.com/privkey.pem; location / { allow 111.222.33.144; allow 172.17.113.100; allow 172.17.113.101; allow 172.17.113.102; allow 172.17.113.103; deny all; proxy_pass http://172.17.113.100:9000; } location /users/auth/google_oauth2/callback { proxy_pass http://172.17.113.100:9000; } location /-/google_api/auth/callback { proxy_pass http://172.17.113.100:9000; } } server { listen 80; server_name gitlab.example.com; location / { return 301 https://gitlab.example.com$request_uri; } location /.well-known/acme-challenge { default_type text/plain; root /opt/letsencrypt; } } Конфиг /etc/gitlab/gitlab.rb на сервере 172.17.113.100: nginx['listen_port'] = 9000 nginx['listen_https'] = false -- Best regards, Gena From mdounin на mdounin.ru Tue Jul 12 13:58:21 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 12 Jul 2022 16:58:21 +0300 Subject: SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking In-Reply-To: <20220712115216.cg47u3wphbgzwyet@Y9MQ9X2QVV> References: <9765032e-3b9a-4d03-64c7-93964f695529@csdoc.com> <20220712115216.cg47u3wphbgzwyet@Y9MQ9X2QVV> Message-ID: Hello! On Tue, Jul 12, 2022 at 03:52:16PM +0400, Sergey Kandaurov wrote: > On Tue, Jul 12, 2022 at 04:23:59AM +0300, Maxim Dounin wrote: > > Hello! > > > > On Mon, Jul 11, 2022 at 09:06:53PM +0300, Gena Makhomed wrote: > > > > > On 10.07.2022 11:41, Maxim Dounin wrote: > > > > > > >> Как выловить такие ошибки в логе? > > > >> я их не вижу, есть ошибки типа warn Но это не то. > > > > > > > Вы чуть раньше в этом треде писали Илье, "client sent plain HTTP > > > > request to HTTPS port". Как и другие ошибки в клиентских > > > > запросах, эти ошибки логгируются на уровне info. > > > > > > nginx/1.23.0 из официального репозитория nginx.org пишет в лог: > > > > > > 2022/07/11 13:14:48 [crit] 67688#67688: *154358 SSL_do_handshake() > > > failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad > > > key share) while SSL handshaking, client: 192.241.214.22, server: > > > 0.0.0.0:443 > > > > > > проблема тут https://stackoverflow.com/a/67424645 на стороне клиента, > > > но в лог информация пишется на уровне [crit] - так и должно быть? > > > > Нет, так не должно быть. Просто это относительно новая ошибка, > > добавленная в OpenSSL 1.1.1 / TLSv1.3, и ей пока не прибит > > правильный уровень логгирования. Патч ниже. > > > > Если в логах вылезает что-то ещё - можно и нужно жаловаться. > > > > # HG changeset patch > > # User Maxim Dounin > > # Date 1657587735 -10800 > > # Tue Jul 12 04:02:15 2022 +0300 > > # Node ID ae4b86fa92e6eb0c1fa13482695218b334f2adc3 > > # Parent 219217ea49a8d648f5cadd046f1b1294ef05693c > > SSL: logging levels of various errors added in OpenSSL 1.1.1. > > > > Starting with OpenSSL 1.1.1, various additional errors can be reported > > by OpenSSL in case of client-related issues, most notably during TLSv1.3 > > handshakes. In particular, SSL_R_BAD_KEY_SHARE ("bad key share"), > > SSL_R_BAD_EXTENSION ("bad extension"), SSL_R_BAD_CIPHER ("bad cipher"), > > SSL_R_BAD_ECPOINT ("bad ecpoint"). These are now logged at the "info" > > level. > > Looks good. > > I managed to repoduce all of the errors except SSL_R_BAD_CIPHER, > which requires extra effort to implement HRR in order to trigger it. > Others are easy to trigger. Pushed to http://mdounin.ru/hg/nginx/. > If trying to enumerate TLSv1.3-specific client errors, I'd also add these > I catched with my QUIC tests adjusted to generic TLSv1.3 over TCP: > > boringssl/include/openssl/ssl.h:#define SSL_R_MISSING_KEY_SHARE 258 > boringssl/include/openssl/ssl.h:#define SSL_R_DUPLICATE_KEY_SHARE 264 > - extension is either missing or includes a dublicate group > > OpenSSL has a similar error "no suitable key share" for MISSING_KEY_SHARE. > I couldn't find an equivalent for DUPLICATE_KEY_SHARE, though. > > boringssl/include/openssl/ssl.h:#define SSL_R_ERROR_PARSING_EXTENSION 149 > boringssl/include/openssl/ssl.h:#define SSL_R_PARSE_TLSEXT 190 > - both enqueued when e.g. receiving QUIC transport params in generic TLSv1.3: > "SSL: error:10000095:SSL routines:OPENSSL_internal:ERROR_PARSING_EXTENSION:extension 57 > error:100000be:SSL routines:OPENSSL_internal:PARSE_TLSEXT) while SSL handshaking" > > PARSE_TLSEXT seems to be a rough replacement for SSL_R_BAD_EXTENSION. I don't think I see any of these in nginx-related user reports, so I would rather postpone these for now. (Either way, it looks like something for a separate patch.) -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Tue Jul 12 14:39:34 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 12 Jul 2022 19:39:34 +0500 Subject: [error] access forbidden by rule In-Reply-To: <56969995-8a38-9f5b-9401-546474fb8028@csdoc.com> References: <56969995-8a38-9f5b-9401-546474fb8028@csdoc.com> Message-ID: вт, 12 июл. 2022 г. в 18:46, Gena Makhomed : > On 10.07.2022 11:41, Maxim Dounin wrote: > > > Вы чуть раньше в этом треде писали Илье, "client sent plain HTTP > > request to HTTPS port". Как и другие ошибки в клиентских > > запросах, эти ошибки логгируются на уровне info. > > nginx/1.23.0 из официального репозитория nginx.org > > В error.log есть такая запись: > > 2022/07/12 16:00:00 [error] 16594#16594: *21415 access forbidden by > rule, client: 62.46.205.111, server: gitlab.example.com, request: "GET > /api/v4/user HTTP/2.0", host: "gitlab.example.com" > > То, что какому-то клиенту возвращается 403 статус - разве это ошибка, > которую необходимо писать в error.log на уровне [error] а не [info] ? > > Кстати, директивы limit_conn_log_level и limit_req_log_level > зачем-то по умолчанию стоят на уровне error, как будто это есть > ошибка на стороне сервера, если какому-то клиенту будет запрещен > доступ. > эта штука выглядит на первый взгляд противоречащей логике, но при изучении документации, понимаешь, как с этим жить, кажется, что те или иные настройки по умолчанию, при условии, что их можно поменять, это не проблема. > > Директива deny_log_level в nginx вообще отсутствует. > отсутствие возможности поменять - да, это реальная проблема > > Может быть имеет смысл сделать директиву deny_log_level > и для всех трех директив: limit_conn_log_level, > limit_req_log_level и deny_log_level сделать значением > по умолчанию info ? > > Это было бы логично и соответствовало бы общему правилу, > что все ошибки в клиентских запросах логгируются на уровне info. > > P.S. > > Конфиг /etc/nginx/conf.d/gitlab.example.com.conf: > > server { > > listen 443 ssl http2; > > server_name gitlab.example.com; > > ssl_certificate > /etc/letsencrypt/live/gitlab.example.com/fullchain.pem; > ssl_certificate_key > /etc/letsencrypt/live/gitlab.example.com/privkey.pem; > > location / { > allow 111.222.33.144; > allow 172.17.113.100; > allow 172.17.113.101; > allow 172.17.113.102; > allow 172.17.113.103; > deny all; > proxy_pass http://172.17.113.100:9000; > } > > location /users/auth/google_oauth2/callback { > proxy_pass http://172.17.113.100:9000; > } > > location /-/google_api/auth/callback { > proxy_pass http://172.17.113.100:9000; > } > } > > server { > > listen 80; > > server_name gitlab.example.com; > > location / { > return 301 https://gitlab.example.com$request_uri; > } > > location /.well-known/acme-challenge { default_type text/plain; > root /opt/letsencrypt; } > } > > Конфиг /etc/gitlab/gitlab.rb на сервере 172.17.113.100: > > nginx['listen_port'] = 9000 > > nginx['listen_https'] = false > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Jul 12 14:51:23 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 12 Jul 2022 17:51:23 +0300 Subject: [error] access forbidden by rule In-Reply-To: <56969995-8a38-9f5b-9401-546474fb8028@csdoc.com> References: <56969995-8a38-9f5b-9401-546474fb8028@csdoc.com> Message-ID: Hello! On Tue, Jul 12, 2022 at 04:45:45PM +0300, Gena Makhomed wrote: > On 10.07.2022 11:41, Maxim Dounin wrote: > > > Вы чуть раньше в этом треде писали Илье, "client sent plain HTTP > > request to HTTPS port". Как и другие ошибки в клиентских > > запросах, эти ошибки логгируются на уровне info. > > nginx/1.23.0 из официального репозитория nginx.org > > В error.log есть такая запись: > > 2022/07/12 16:00:00 [error] 16594#16594: *21415 access forbidden by > rule, client: 62.46.205.111, server: gitlab.example.com, request: "GET > /api/v4/user HTTP/2.0", host: "gitlab.example.com" > > То, что какому-то клиенту возвращается 403 статус - разве это ошибка, > которую необходимо писать в error.log на уровне [error] а не [info] ? > > Кстати, директивы limit_conn_log_level и limit_req_log_level > зачем-то по умолчанию стоят на уровне error, как будто это есть > ошибка на стороне сервера, если какому-то клиенту будет запрещен > доступ. > > Директива deny_log_level в nginx вообще отсутствует. Ограничения и ошибки доступа логгируются на уровне error, так как считаются важными (и, вообще говоря, не являются ошибками в клиентских запросах, а являются ошибками обработки клиентских запросов). Как в случае access forbidden by rule в allow/deny, так и в случае user not found / password mismatch в auth_basic, а равно "directory index ... forbidden", "open() ... failed (2: No such file or directory)" и limit_conn/limit_req. Для гибкого изменения уровней логгирования (или вообще логгирования) в сложных случаях - есть некоторое количество ручек, позволяющих гибко управлять логгированием конкретных событий (limit_conn_log_level, limit_req_log_level, log_not_found, rewrite_log). В общем случае - таких ручек нет, и события попадают в лог на фиксированном уровне логгирования. > Может быть имеет смысл сделать директиву deny_log_level > и для всех трех директив: limit_conn_log_level, > limit_req_log_level и deny_log_level сделать значением > по умолчанию info ? > > Это было бы логично и соответствовало бы общему правилу, > что все ошибки в клиентских запросах логгируются на уровне info. Менять на info - совершенно точно нет, это противоречит как логике выбора уровня логгирования ошибок (см. выше), так и логике работы, скажем, limit_req - при уровне логгирования info не остаётся разницы между фатальными ошибками и задержками запросов. Добавить возможность настройки уровня логгирования ошибок deny - возможно, но пока кажется, что это скорее не нужно. Что касается общих правил, то см. выше. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Jul 12 15:40:27 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 12 Jul 2022 18:40:27 +0300 Subject: [warn] a client request body is buffered to a temporary file In-Reply-To: <7c24483a-2eec-0902-ec66-70cf6e79e00f@csdoc.com> References: <7c24483a-2eec-0902-ec66-70cf6e79e00f@csdoc.com> Message-ID: Hello! On Tue, Jul 12, 2022 at 02:42:44PM +0300, Gena Makhomed wrote: > Здравствуйте, All! > > nginx/1.23.0 из официального репозитория nginx.org > > В логах есть такой варнинг: > > 2022/07/12 13:56:37 [warn] 14352#14352: *183 a client request body is > buffered to a temporary file /var/cache/nginx/client_temp/0000000011, > client: 10.23.154.207, server: sentry.example.com, request: "POST > /api/22/envelope/ HTTP/2.0", host: "sentry.example.com" > > Судя по информации из access-лога - размер контента - 41 байт: > > # grep /api/22/envelope/ access.log | grep 13:56:37 | less > 2022-07-12T13:56:37+03:00 GB 10.23.154.207 https > sentry.example.com POST "/api/22/envelope/" 200 41 > "-" "sentry.php.laravel/2.9.0" 0.010 0.002 > > Если прописать в nginx.conf директиву client_body_buffer_size 32k; > - тогда варнинг из error.log пропадает, но если вернуть дефолтовое > значение client_body_buffer_size 16k; - варнинг снова появляется логах. > > Размер контента - всего 41 байт. Как такое может быть? А что у вас по осям? (c) В смысле - что в log_format? Следом за $status обычно идёт $body_bytes_sent, и это размер тела ответа, имеющий приблизительно никакого отношения к размеру тела запроса. > client_body_buffer_size - эта переменная задает только статический > размер буфера, и в nginx сейчас нельзя сделать динамическое выделение > буфера по необходимости, как это сделано в директиве proxy_buffers ? > > Возможно было бы логичним, для экономии памяти сделать возможность > задавать client_body_buffer_size по аналогии с proxy_buffers, > например так: > > client_body_buffer_size 8k; > client_body_buffers 32 8k; Возможно так когда-нибудь будет, но пока так нельзя. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Tue Jul 12 16:55:32 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 12 Jul 2022 19:55:32 +0300 Subject: [error] access forbidden by rule In-Reply-To: References: <56969995-8a38-9f5b-9401-546474fb8028@csdoc.com> Message-ID: <2d9230f8-951d-a6ae-4cab-cda2b1642682@csdoc.com> On 12.07.2022 17:51, Maxim Dounin wrote: > Ограничения и ошибки доступа логгируются на уровне error, так как > считаются важными (и, вообще говоря, не являются ошибками в > клиентских запросах, а являются ошибками обработки клиентских > запросов). Как в случае access forbidden by rule в allow/deny, > так и в случае user not found / password mismatch в auth_basic, а > равно "directory index ... forbidden", "open() ... failed (2: > No such file or directory)" и limit_conn/limit_req. > > Для гибкого изменения уровней логгирования (или вообще > логгирования) в сложных случаях - есть некоторое количество ручек, > позволяющих гибко управлять логгированием конкретных событий > (limit_conn_log_level, limit_req_log_level, log_not_found, > rewrite_log). В общем случае - таких ручек нет, и события > попадают в лог на фиксированном уровне логгирования. >> Может быть имеет смысл сделать директиву deny_log_level > Добавить возможность настройки уровня логгирования ошибок deny - > возможно, но пока кажется, что это скорее не нужно. Директивы limit_conn_log_level и limit_req_log_level были добавлены в nginx с какой целью / мотивацией, если не секрет? Разве мотивация добавить директиву deny_log_level не такая же, как и была в случае с директивами limit_{conn,req}_log_level ? В чем проблема - логи nginx находятся в каталоге /var/log/nginx/ http-client-body-temp-path в каталоге /var/cache/nginx/client_temp поэтому когда логи занимают все свободное место на разделе - перестает работать аплоад файлов и тогда пользователям возвращается 500 ошибка. Чтобы решить проблему - поменял rotate 52 на rotate 7 в файле /etc/logrotate.d/nginx. Отключать access-логи не могу, менять log level для файла error.log с warn на crit не хочу, чтобы не пропустить какую-то действительно важную ошибку. Поэтому лично для меня - наличие директивы deny_log_level было бы полезно, потому что примерно 80% содержимого файла error.log - это "ошибки" access forbidden by rule и еще примерно 20% - это "предупреждения" о том, что a client request body is buffered to a temporary file Еще - было бы очень хорошо, чтобы nginx умел писать логи на диск не до тех пор, пока там останется 0 байт свободного места, а хотя бы оставлял 1 гигабайт для файлов в /var/cache/nginx/client_temp но наверное это отрицательно скажется на его производительности, и поэтому такая возможность никогда не будет реализована в nginx? Хотя, с другой стороны, nginx master может ведь мониторить свободное место на диске с интервалом, например, раз в 10 или 20 или 30 секунд, отключая запись в access.log, когда свободного места меньше 1 гигабайта и отключая запись в error.log на уровне меньше crit, когда свободного места на диске меньше, например, 512 мегабайт? (И включая обратно запись в логи в той же последовательности в случае появления свободного места на диске) Вы наверное скажете, что по нормальному надо было бы где-то установить и настроить какой-нибудь Zabbix и настроить в нем мониторинг свободного места на разделе /var/log/nginx/ и /var/cache/nginx/client_temp и потом вручную чистить логи, когда придет сообщение о том, что low free space? -- Best regards, Gena From chipitsine на gmail.com Tue Jul 12 17:12:05 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 12 Jul 2022 22:12:05 +0500 Subject: [error] access forbidden by rule In-Reply-To: <2d9230f8-951d-a6ae-4cab-cda2b1642682@csdoc.com> References: <56969995-8a38-9f5b-9401-546474fb8028@csdoc.com> <2d9230f8-951d-a6ae-4cab-cda2b1642682@csdoc.com> Message-ID: вт, 12 июл. 2022 г. в 21:55, Gena Makhomed : > On 12.07.2022 17:51, Maxim Dounin wrote: > > > Ограничения и ошибки доступа логгируются на уровне error, так как > > считаются важными (и, вообще говоря, не являются ошибками в > > клиентских запросах, а являются ошибками обработки клиентских > > запросов). Как в случае access forbidden by rule в allow/deny, > > так и в случае user not found / password mismatch в auth_basic, а > > равно "directory index ... forbidden", "open() ... failed (2: > > No such file or directory)" и limit_conn/limit_req. > > > > Для гибкого изменения уровней логгирования (или вообще > > логгирования) в сложных случаях - есть некоторое количество ручек, > > позволяющих гибко управлять логгированием конкретных событий > > (limit_conn_log_level, limit_req_log_level, log_not_found, > > rewrite_log). В общем случае - таких ручек нет, и события > > попадают в лог на фиксированном уровне логгирования. > > >> Может быть имеет смысл сделать директиву deny_log_level > > > Добавить возможность настройки уровня логгирования ошибок deny - > > возможно, но пока кажется, что это скорее не нужно. > > Директивы limit_conn_log_level и limit_req_log_level были > добавлены в nginx с какой целью / мотивацией, если не секрет? > > Разве мотивация добавить директиву deny_log_level не такая же, > как и была в случае с директивами limit_{conn,req}_log_level ? > > В чем проблема - логи nginx находятся в каталоге /var/log/nginx/ > http-client-body-temp-path в каталоге /var/cache/nginx/client_temp > поэтому когда логи занимают все свободное место на разделе > - перестает работать аплоад файлов и тогда пользователям > возвращается 500 ошибка. > > Чтобы решить проблему - поменял rotate 52 на rotate 7 > в файле /etc/logrotate.d/nginx. Отключать access-логи не могу, > менять log level для файла error.log с warn на crit не хочу, > чтобы не пропустить какую-то действительно важную ошибку. > > Поэтому лично для меня - наличие директивы deny_log_level > было бы полезно, потому что примерно 80% содержимого > файла error.log - это "ошибки" access forbidden by rule > я не пробовал, но кажется, можно выкрутиться через error_page, и настроив логи в локейшене в /dev/null (неизящно, но может сработать) > и еще примерно 20% - это "предупреждения" о том, что > a client request body is buffered to a temporary file > это же можно выключить через proxy_request_buffering ? из побочных эффектов, если вдруг понадобилось ретраить запрос, то сохраненного тела запроса уже не будет, увы. > > Еще - было бы очень хорошо, чтобы nginx умел писать логи на диск > не до тех пор, пока там останется 0 байт свободного места, а хотя > бы оставлял 1 гигабайт для файлов в /var/cache/nginx/client_temp > буферизация на диск имеет кучу побочных эффектов. можно через Модуль ngx_http_proxy_module (nginx.org) выключить дисковую часть (оставив буферизацию в памяти) > но наверное это отрицательно скажется на его производительности, > и поэтому такая возможность никогда не будет реализована в nginx? > > Хотя, с другой стороны, nginx master может ведь мониторить свободное > место на диске с интервалом, например, раз в 10 или 20 или 30 секунд, > отключая запись в access.log, когда свободного места меньше 1 гигабайта > и отключая запись в error.log на уровне меньше crit, когда свободного > места на диске меньше, например, 512 мегабайт? (И включая обратно > запись в логи в той же последовательности в случае появления > свободного места на диске) > > Вы наверное скажете, что по нормальному надо было бы где-то установить > и настроить какой-нибудь Zabbix и настроить в нем мониторинг свободного > места на разделе /var/log/nginx/ и /var/cache/nginx/client_temp и потом > вручную чистить логи, когда придет сообщение о том, что low free space? > я бы скорее смотрел в сторону, что диск для реверс прокси не особо нужен. можно транзитом туда-сюда трафик гонять. разве что для логов. > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue Jul 12 17:16:31 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 12 Jul 2022 22:16:31 +0500 Subject: [error] access forbidden by rule In-Reply-To: References: <56969995-8a38-9f5b-9401-546474fb8028@csdoc.com> Message-ID: вт, 12 июл. 2022 г. в 19:51, Maxim Dounin : > Hello! > > On Tue, Jul 12, 2022 at 04:45:45PM +0300, Gena Makhomed wrote: > > > On 10.07.2022 11:41, Maxim Dounin wrote: > > > > > Вы чуть раньше в этом треде писали Илье, "client sent plain HTTP > > > request to HTTPS port". Как и другие ошибки в клиентских > > > запросах, эти ошибки логгируются на уровне info. > > > > nginx/1.23.0 из официального репозитория nginx.org > > > > В error.log есть такая запись: > > > > 2022/07/12 16:00:00 [error] 16594#16594: *21415 access forbidden by > > rule, client: 62.46.205.111, server: gitlab.example.com, request: "GET > > /api/v4/user HTTP/2.0", host: "gitlab.example.com" > > > > То, что какому-то клиенту возвращается 403 статус - разве это ошибка, > > которую необходимо писать в error.log на уровне [error] а не [info] ? > > > > Кстати, директивы limit_conn_log_level и limit_req_log_level > > зачем-то по умолчанию стоят на уровне error, как будто это есть > > ошибка на стороне сервера, если какому-то клиенту будет запрещен > > доступ. > > > > Директива deny_log_level в nginx вообще отсутствует. > > Ограничения и ошибки доступа логгируются на уровне error, так как > считаются важными (и, вообще говоря, не являются ошибками в если я в конфиге пишу deny, и применяется заданное мной правило, в чем же тут ошибка, о которой надо мне сообщить в лог ? > > клиентских запросах, а являются ошибками обработки клиентских > запросов). Как в случае access forbidden by rule в allow/deny, > так и в случае user not found / password mismatch в auth_basic, а > равно "directory index ... forbidden", "open() ... failed (2: > No such file or directory)" и limit_conn/limit_req. > > Для гибкого изменения уровней логгирования (или вообще > логгирования) в сложных случаях - есть некоторое количество ручек, > позволяющих гибко управлять логгированием конкретных событий > (limit_conn_log_level, limit_req_log_level, log_not_found, > rewrite_log). В общем случае - таких ручек нет, и события > попадают в лог на фиксированном уровне логгирования. > > > Может быть имеет смысл сделать директиву deny_log_level > > и для всех трех директив: limit_conn_log_level, > > limit_req_log_level и deny_log_level сделать значением > > по умолчанию info ? > > > > Это было бы логично и соответствовало бы общему правилу, > > что все ошибки в клиентских запросах логгируются на уровне info. > > Менять на info - совершенно точно нет, это противоречит как логике > выбора уровня логгирования ошибок (см. выше), так и логике работы, > скажем, limit_req - при уровне логгирования info не остаётся > разницы между фатальными ошибками и задержками запросов. > > Добавить возможность настройки уровня логгирования ошибок deny - > возможно, но пока кажется, что это скорее не нужно. > > Что касается общих правил, то см. выше. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Tue Jul 12 17:55:35 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 12 Jul 2022 20:55:35 +0300 Subject: [warn] a client request body is buffered to a temporary file In-Reply-To: References: <7c24483a-2eec-0902-ec66-70cf6e79e00f@csdoc.com> Message-ID: <5c5b6e78-4c30-bb3a-f8de-e9b43c51659f@csdoc.com> On 12.07.2022 18:40, Maxim Dounin wrote: > А что у вас по осям? (c) > > В смысле - что в log_format? Следом за $status обычно идёт > $body_bytes_sent, и это размер тела ответа, имеющий приблизительно > никакого отношения к размеру тела запроса. На том сервере log_format такой: log_format frontend '$time_iso8601\t$geoip_country_code\t$remote_addr\t' '$scheme\t$host\t$request_method\t"$request_uri"\t' '$status\t$body_bytes_sent\t"$http_referer"\t' '"$http_user_agent"\t$request_time\t' '$upstream_response_time'; Очень удобно использовать символ табуляции в качестве разделителя, логи тогда без проблем читаются в mc и с помощью grep | less -S Софтом лог с разделителем в виде символа табуляции парсить удобно: time, geoip_country_code, remote_addr, ... = line.split('\t') Применяю этот метод в https://github.com/makhomed/autofilter потому что NGINX App Protect Denial of Service слишком дорого. Вот еще раз все проверил только что: # nginx -q -T | grep client_body_buffer_size client_body_buffer_size 16k; error.log: 2022/07/12 20:23:26 [warn] 2479#2479: *63684 a client request body is buffered to a temporary file /var/cache/nginx/client_temp/0000000290, client: 111.222.33.44, server: sentry.example.com, request: "POST /api/8/envelope/?sentry_key=xxxxxxxxxx&sentry_version=7 HTTP/2.0", host: "sentry.example.com", referrer: "https://example.com/" access.log: 2022-07-12T20:23:26+03:00 XX 111.222.33.44 https sentry.example.com POST "/api/8/envelope/?sentry_key=xxxxxxxxxx&sentry_version=7" 200 41 "https://example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36" 0.037 0.002 Размер контента - всего 41 байт, что гораздо меньше чем 16 килобайт, и тем не менее, контент все равно пишется на диск зачем-то. Как такое может быть? -- Best regards, Gena From gmm на csdoc.com Tue Jul 12 19:15:31 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 12 Jul 2022 22:15:31 +0300 Subject: [warn] a client request body is buffered to a temporary file In-Reply-To: References: <56969995-8a38-9f5b-9401-546474fb8028@csdoc.com> <2d9230f8-951d-a6ae-4cab-cda2b1642682@csdoc.com> Message-ID: <03651cd1-d53a-b3d2-e40a-dc372c936311@csdoc.com> On 12.07.2022 20:12, Илья Шипицин wrote: >> и еще примерно 20% - это "предупреждения" о том, что >> a client request body is buffered to a temporary file > это же можно выключить через proxy_request_buffering ? Да, в моем случае - это вполне подходит, спасибо. proxy_http_version 1.1; proxy_request_buffering off; Потому что у меня у каждого nginx frontend есть всего один nginx backend для каждого сайта: nginx frontend <=> nginx backend <=> php-fpm Самое главное - не забыть включить директиву proxy_http_version 1.1; на nginx frontend, иначе будут проблемы из-за использования HTTP/1.0 https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_request_buffering When HTTP/1.1 chunked transfer encoding is used to send the original request body, the request body will be buffered regardless of the directive value unless HTTP/1.1 is enabled for proxying. >> Еще - было бы очень хорошо, чтобы nginx умел писать логи на диск >> не до тех пор, пока там останется 0 байт свободного места, а хотя >> бы оставлял 1 гигабайт для файлов в /var/cache/nginx/client_temp > буферизация на диск имеет кучу побочных эффектов. > можно через Модуль ngx_http_proxy_module (nginx.org) > > выключить дисковую часть (оставив буферизацию в памяти) Директива proxy_max_temp_file_size 0; на nginx frontend у меня прописана Но она влияет только на буферизацию проксируемых от backend`ов ответов. Полностью отключить использование диска nginx frontend для проксирования и запросов и ответов можно с помощью такого набора директив: proxy_http_version 1.1; proxy_request_buffering off; proxy_max_temp_file_size 0; Однако это имеет смысл только в том случае, если nginx frontend проксирует запросы на nginx backend, на котором включена буферизация запросов и ответов на диск. Если в качестве backend`а используется httpd apache - использование диска для буферизации наверное лучше будет не выключать. -- Best regards, Gena From chipitsine на gmail.com Tue Jul 12 19:27:32 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 13 Jul 2022 00:27:32 +0500 Subject: [warn] a client request body is buffered to a temporary file In-Reply-To: <03651cd1-d53a-b3d2-e40a-dc372c936311@csdoc.com> References: <56969995-8a38-9f5b-9401-546474fb8028@csdoc.com> <2d9230f8-951d-a6ae-4cab-cda2b1642682@csdoc.com> <03651cd1-d53a-b3d2-e40a-dc372c936311@csdoc.com> Message-ID: ср, 13 июл. 2022 г. в 00:16, Gena Makhomed : > On 12.07.2022 20:12, Илья Шипицин wrote: > > >> и еще примерно 20% - это "предупреждения" о том, что > >> a client request body is buffered to a temporary file > > > это же можно выключить через proxy_request_buffering ? > > Да, в моем случае - это вполне подходит, спасибо. > > proxy_http_version 1.1; > proxy_request_buffering off; > > Потому что у меня у каждого nginx frontend > есть всего один nginx backend для каждого сайта: > nginx frontend <=> nginx backend <=> php-fpm > > Самое главное - не забыть включить директиву proxy_http_version 1.1; > на nginx frontend, иначе будут проблемы из-за использования HTTP/1.0 > > > https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_request_buffering > > When HTTP/1.1 chunked transfer encoding is used to send the original > request body, the request body will be buffered regardless of the > directive value unless HTTP/1.1 is enabled for proxying. > HTTP/1.1 обычно включаю, но до этого места в документации про chunked не дочитал )) > > >> Еще - было бы очень хорошо, чтобы nginx умел писать логи на диск > >> не до тех пор, пока там останется 0 байт свободного места, а хотя > >> бы оставлял 1 гигабайт для файлов в /var/cache/nginx/client_temp > > > буферизация на диск имеет кучу побочных эффектов. > > можно через Модуль ngx_http_proxy_module (nginx.org) > > < > https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size > > > > выключить дисковую часть (оставив буферизацию в памяти) > > Директива proxy_max_temp_file_size 0; на nginx frontend у меня прописана > Но она влияет только на буферизацию проксируемых от backend`ов ответов. > > Полностью отключить использование диска nginx frontend > для проксирования и запросов и ответов можно > с помощью такого набора директив: > > proxy_http_version 1.1; > proxy_request_buffering off; > proxy_max_temp_file_size 0; > не совсем верно. если не трогать proxy_buffering, то ответы буферизуются (в памяти, но не на диске) > > Однако это имеет смысл только в том случае, если nginx frontend > проксирует запросы на nginx backend, на котором включена буферизация если у бекенда форк-модель, и дорогое подключение, которое желательно максимально быстро освободить, даже ценой буферизации на диск, то да. для многих современных бекендов, включач php-fpm, поддержание 10к одновременных подключений не является проблемой, кажется, что буферизация на диск скорее избыточна, и по факту не решает никаких проблем, но может их создать > > запросов и ответов на диск. Если в качестве backend`а используется > httpd apache - использование диска для буферизации > наверное лучше будет не выключать. > верно > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue Jul 12 19:59:04 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 13 Jul 2022 00:59:04 +0500 Subject: [warn] a client request body is buffered to a temporary file In-Reply-To: <5c5b6e78-4c30-bb3a-f8de-e9b43c51659f@csdoc.com> References: <7c24483a-2eec-0902-ec66-70cf6e79e00f@csdoc.com> <5c5b6e78-4c30-bb3a-f8de-e9b43c51659f@csdoc.com> Message-ID: вт, 12 июл. 2022 г. в 22:56, Gena Makhomed : > On 12.07.2022 18:40, Maxim Dounin wrote: > > > А что у вас по осям? (c) > > > > В смысле - что в log_format? Следом за $status обычно идёт > > $body_bytes_sent, и это размер тела ответа, имеющий приблизительно > > никакого отношения к размеру тела запроса. > > На том сервере log_format такой: > > log_format frontend '$time_iso8601\t$geoip_country_code\t$remote_addr\t' > '$scheme\t$host\t$request_method\t"$request_uri"\t' > '$status\t$body_bytes_sent\t"$http_referer"\t' > '"$http_user_agent"\t$request_time\t' > '$upstream_response_time'; > если рассматривать с точки зрения эффективного использования диска, то поля $scheme, $host являются практически константами, можно не логировать их на каждую строчку лога (а, например, разнести разные host-ы по разным логам). и, если поля разделяются табуляцией, то кавычки избыточны в качестве ориентира удобно брать число байт в 1 строке лога > > Очень удобно использовать символ табуляции в качестве разделителя, > логи тогда без проблем читаются в mc и с помощью grep | less -S > и еще в Microsoft LogParser, Clickhouse, awk, .... > > Софтом лог с разделителем в виде символа табуляции парсить удобно: > time, geoip_country_code, remote_addr, ... = line.split('\t') > > Применяю этот метод в https://github.com/makhomed/autofilter > потому что NGINX App Protect Denial of Service слишком дорого. > > Вот еще раз все проверил только что: > > # nginx -q -T | grep client_body_buffer_size > client_body_buffer_size 16k; > > error.log: > > 2022/07/12 20:23:26 [warn] 2479#2479: *63684 a client request body is > buffered to a temporary file /var/cache/nginx/client_temp/0000000290, > client: 111.222.33.44, server: sentry.example.com, request: "POST > /api/8/envelope/?sentry_key=xxxxxxxxxx&sentry_version=7 HTTP/2.0", host: > "sentry.example.com", referrer: "https://example.com/" > > access.log: > > 2022-07-12T20:23:26+03:00 XX 111.222.33.44 https > sentry.example.com POST > "/api/8/envelope/?sentry_key=xxxxxxxxxx&sentry_version=7" 200 41 > "https://example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36" > 0.037 0.002 > > Размер контента - всего 41 байт, что гораздо меньше чем 16 килобайт, > и тем не менее, контент все равно пишется на диск зачем-то. > Как такое может быть? > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Jul 12 20:37:08 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 12 Jul 2022 23:37:08 +0300 Subject: [warn] a client request body is buffered to a temporary file In-Reply-To: <5c5b6e78-4c30-bb3a-f8de-e9b43c51659f@csdoc.com> References: <7c24483a-2eec-0902-ec66-70cf6e79e00f@csdoc.com> <5c5b6e78-4c30-bb3a-f8de-e9b43c51659f@csdoc.com> Message-ID: Hello! On Tue, Jul 12, 2022 at 08:55:35PM +0300, Gena Makhomed wrote: > On 12.07.2022 18:40, Maxim Dounin wrote: > > > А что у вас по осям? (c) > > > > В смысле - что в log_format? Следом за $status обычно идёт > > $body_bytes_sent, и это размер тела ответа, имеющий приблизительно > > никакого отношения к размеру тела запроса. > > На том сервере log_format такой: > > log_format frontend '$time_iso8601\t$geoip_country_code\t$remote_addr\t' > '$scheme\t$host\t$request_method\t"$request_uri"\t' > '$status\t$body_bytes_sent\t"$http_referer"\t' > '"$http_user_agent"\t$request_time\t' > '$upstream_response_time'; > > Очень удобно использовать символ табуляции в качестве разделителя, > логи тогда без проблем читаются в mc и с помощью grep | less -S Историческая справка, не имеющая отношения к обсуждаемому вопросу: эскейпинг специальных символов в access-логах делался как раз для удобного автоматического парсинга tab separated логов. Hint: кавычки вокруг произвольных строковых полей использовать не нужно, так как табы экранируются. [...] > Вот еще раз все проверил только что: > > # nginx -q -T | grep client_body_buffer_size > client_body_buffer_size 16k; > > error.log: > > 2022/07/12 20:23:26 [warn] 2479#2479: *63684 a client request body is > buffered to a temporary file /var/cache/nginx/client_temp/0000000290, > client: 111.222.33.44, server: sentry.example.com, request: "POST > /api/8/envelope/?sentry_key=xxxxxxxxxx&sentry_version=7 HTTP/2.0", host: > "sentry.example.com", referrer: "https://example.com/" > > access.log: > > 2022-07-12T20:23:26+03:00 XX 111.222.33.44 https > sentry.example.com POST > "/api/8/envelope/?sentry_key=xxxxxxxxxx&sentry_version=7" 200 41 > "https://example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36" > 0.037 0.002 > > Размер контента - всего 41 байт, что гораздо меньше чем 16 килобайт, > и тем не менее, контент все равно пишется на диск зачем-то. > Как такое может быть? Процитирую ещё раз написанное в прошлом письме: > > В смысле - что в log_format? Следом за $status обычно идёт > > $body_bytes_sent, и это размер тела ответа, имеющий приблизительно > > никакого отношения к размеру тела запроса. Из приведённой строки лога мы не знаем размер тела запроса, он может быть любой. Видимое значение 41 - это размер ответа, и он не имеет к телу запроса примерно никакого отношения. Судя по тому, что тело запроса в буфер не помещается - оно больше 16 килобайт. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Tue Jul 12 21:00:20 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 13 Jul 2022 00:00:20 +0300 Subject: [warn] a client request body is buffered to a temporary file In-Reply-To: References: <56969995-8a38-9f5b-9401-546474fb8028@csdoc.com> <2d9230f8-951d-a6ae-4cab-cda2b1642682@csdoc.com> <03651cd1-d53a-b3d2-e40a-dc372c936311@csdoc.com> Message-ID: On 12.07.2022 22:27, Илья Шипицин wrote: >> Директива proxy_max_temp_file_size 0; на nginx frontend у меня прописана >> Но она влияет только на буферизацию проксируемых от backend`ов ответов. >> >> Полностью отключить использование диска nginx frontend >> для проксирования и запросов и ответов можно >> с помощью такого набора директив: >> >> proxy_http_version 1.1; >> proxy_request_buffering off; >> proxy_max_temp_file_size 0; > не совсем верно. если не трогать proxy_buffering, то ответы буферизуются (в > памяти, но не на диске) proxy_buffering почти всегда лучше оставлять включенным, потому что nginx работает более эффективно, если буферизация в памяти включена подробности здесь: https://marc.info/?l=nginx&m=131739590508332&w=2 >> Однако это имеет смысл только в том случае, если nginx frontend >> проксирует запросы на nginx backend, на котором включена буферизация > если у бекенда форк-модель, и дорогое подключение, которое желательно > максимально быстро освободить, даже ценой буферизации на диск, то да. > для многих современных бекендов, включач php-fpm, поддержание 10к > одновременных подключений не является проблемой, кажется, что буферизация > на диск скорее избыточна, и по факту не решает никаких проблем, но может их > создать У бэкенда php-fpm ведь форк-модель, и количество воркеров ограничено. То есть, другими словами, php-fpm - это то же самое что и httpd apache, только используется fastcgi протокол вместо http для подключения, вот и вся существенная разница между ними. Подробнее об этом написано в файле /etc/php-fpm.d/www.conf в описании директивы pm.max_children Для php-fpm, поддержание 10к одновременных подключений является огромной проблемой - если каждый воркер использует, например, 128 мегабайт оперативной памяти, то для 10_000 одновременных подключений необходимо будет на сервере примерно 1.2 терабайта оперативной памяти выделить только для одного лишь php-fpm. Если клиент будет медленно-медленно забирать ответ от веб-сервера, при выключенной буферизации на диск воркер php-fpm будет оставаться занятым и таким образом сервер будет легко уязвим к простой DoS-атаке. https://en.wikipedia.org/wiki/Denial-of-service_attack#Slow_Read_attack -- Best regards, Gena From gmm на csdoc.com Tue Jul 12 21:30:37 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 13 Jul 2022 00:30:37 +0300 Subject: [warn] a client request body is buffered to a temporary file In-Reply-To: References: <7c24483a-2eec-0902-ec66-70cf6e79e00f@csdoc.com> <5c5b6e78-4c30-bb3a-f8de-e9b43c51659f@csdoc.com> Message-ID: <43dfa0f1-2c8e-4599-80d8-7c51ec771236@csdoc.com> On 12.07.2022 23:37, Maxim Dounin wrote: > Историческая справка, не имеющая отношения к обсуждаемому вопросу: > эскейпинг специальных символов в access-логах делался как раз для > удобного автоматического парсинга tab separated логов. Hint: > кавычки вокруг произвольных строковых полей использовать не нужно, > так как табы экранируются. Понял, спасибо! > Процитирую ещё раз написанное в прошлом письме: > >>> В смысле - что в log_format? Следом за $status обычно идёт >>> $body_bytes_sent, и это размер тела ответа, имеющий приблизительно >>> никакого отношения к размеру тела запроса. > > Из приведённой строки лога мы не знаем размер тела запроса, он > может быть любой. Видимое значение 41 - это размер ответа, и он > не имеет к телу запроса примерно никакого отношения. Судя по > тому, что тело запроса в буфер не помещается - оно больше 16 > килобайт. Да, Вы правы, размер тела запроса был больше 16 килобайт, поэтому он и буферизировался на диск. Теперь понял, спасибо! Прописал в конфиге nginx frontend такие директивы: proxy_http_version 1.1; proxy_request_buffering off; proxy_max_temp_file_size 0; И теперь у меня в логах nginx frontend вообще нет варнингов о том, что a client request body is buffered to a temporary file. Теперь на том сервере - в логах все 100% сообщений про ошибки - это "ошибки" access forbidden by rule -- Best regards, Gena From chipitsine на gmail.com Wed Jul 13 03:42:08 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 13 Jul 2022 08:42:08 +0500 Subject: [warn] a client request body is buffered to a temporary file In-Reply-To: References: <56969995-8a38-9f5b-9401-546474fb8028@csdoc.com> <2d9230f8-951d-a6ae-4cab-cda2b1642682@csdoc.com> <03651cd1-d53a-b3d2-e40a-dc372c936311@csdoc.com> Message-ID: On Wed, Jul 13, 2022, 2:01 AM Gena Makhomed wrote: > On 12.07.2022 22:27, Илья Шипицин wrote: > > >> Директива proxy_max_temp_file_size 0; на nginx frontend у меня прописана > >> Но она влияет только на буферизацию проксируемых от backend`ов ответов. > >> > >> Полностью отключить использование диска nginx frontend > >> для проксирования и запросов и ответов можно > >> с помощью такого набора директив: > >> > >> proxy_http_version 1.1; > >> proxy_request_buffering off; > >> proxy_max_temp_file_size 0; > > > не совсем верно. если не трогать proxy_buffering, то ответы буферизуются > (в > > памяти, но не на диске) > > proxy_buffering почти всегда лучше оставлять включенным, потому что > nginx работает более эффективно, если буферизация в памяти включена > подробности здесь: https://marc.info/?l=nginx&m=131739590508332&w=2 > > >> Однако это имеет смысл только в том случае, если nginx frontend > >> проксирует запросы на nginx backend, на котором включена буферизация > > > если у бекенда форк-модель, и дорогое подключение, которое желательно > > максимально быстро освободить, даже ценой буферизации на диск, то да. > > > для многих современных бекендов, включач php-fpm, поддержание 10к > > одновременных подключений не является проблемой, кажется, что буферизация > > на диск скорее избыточна, и по факту не решает никаких проблем, но может > их > > создать > > У бэкенда php-fpm ведь форк-модель, и количество воркеров ограничено. > Мне почему-то помнится, что количество запущенных php-fpm процессов была константа и они не росли от нагрузки. Но, возможно fork модель, при случае проверю То есть, другими словами, php-fpm - это то же самое что и httpd apache, > только используется fastcgi протокол вместо http для подключения, > вот и вся существенная разница между ними. Подробнее об этом написано > в файле /etc/php-fpm.d/www.conf в описании директивы pm.max_children > > Для php-fpm, поддержание 10к одновременных подключений является > огромной проблемой - если каждый воркер использует, например, > 128 мегабайт оперативной памяти, то для 10_000 одновременных > подключений необходимо будет на сервере примерно 1.2 терабайта > оперативной памяти выделить только для одного лишь php-fpm. > > Если клиент будет медленно-медленно забирать ответ от веб-сервера, > при выключенной буферизации на диск воркер php-fpm будет оставаться > занятым и таким образом сервер будет легко уязвим к простой DoS-атаке. > https://en.wikipedia.org/wiki/Denial-of-service_attack#Slow_Read_attack > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Wed Jul 13 08:48:50 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 13 Jul 2022 11:48:50 +0300 Subject: access.log In-Reply-To: References: <7c24483a-2eec-0902-ec66-70cf6e79e00f@csdoc.com> <5c5b6e78-4c30-bb3a-f8de-e9b43c51659f@csdoc.com> Message-ID: On 12.07.2022 22:59, Илья Шипицин wrote: > если рассматривать с точки зрения эффективного использования диска, то поля > $scheme, $host являются практически константами, можно не логировать их на > каждую строчку лога (а, например, разнести разные host-ы по разным логам). Разнести разные host-ы по разным логам - это на самом деле плохая идея. Когда различных хостов десятки и сотни - это становится очень неудобно. Кроме того, это отрицательно сказывается на производительности сервера, особенно если используется HDD а не SSD. Имея в наличии один access.log с помощью grep можно легко получить из него access.log для любого сайта: grep -P '\texample.com\t' access.log | less -S $scheme занимает всего несколько байт, и лучше уж пусть будет, для полноты картины, по сравнению с $http_user_agent - это мелочь. Для удобства чтения лога и для уменьшения его размера - можно из лога убрать информацию про таймзону: map $time_iso8601 $time { "~([0-9-]+)T([0-9:]+)" "$1 $2"; volatile; } log_format frontend '$time\t...'; Тогда время в логе будет выглядеть примерно так: 2022-07-13 11:34:40 а не так: 2022-07-13T11:34:40+03:00 Переменная $time вместо $time_iso8601 в логе дает и меньший объем лога и его лучшую читаемость. Недостаток у этого варианта с переменной $time только один - приходится программировать на конфигах nginx, используя map и регулярные выражения, - это несколько увеличивает объем конфига, но должно работать достаточно быстро. -- Best regards, Gena From chipitsine на gmail.com Wed Jul 13 09:00:30 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 13 Jul 2022 14:00:30 +0500 Subject: access.log In-Reply-To: References: <7c24483a-2eec-0902-ec66-70cf6e79e00f@csdoc.com> <5c5b6e78-4c30-bb3a-f8de-e9b43c51659f@csdoc.com> Message-ID: ср, 13 июл. 2022 г. в 13:49, Gena Makhomed : > On 12.07.2022 22:59, Илья Шипицин wrote: > > > если рассматривать с точки зрения эффективного использования диска, то > поля > > $scheme, $host являются практически константами, можно не логировать их > на > > каждую строчку лога (а, например, разнести разные host-ы по разным > логам). > > Разнести разные host-ы по разным логам - это на самом деле плохая идея. > Когда различных хостов десятки и сотни - это становится очень неудобно. > Кроме того, это отрицательно сказывается на производительности сервера, > особенно если используется HDD а не SSD. > это полностью в вашей власти, писать в каждую строку host или делать отдельные логи. насчет производительности в случае HDD - не соглашусь, если писать с буферизацией (buffer=... и flush=...), то HDD отлично справляется вплоть до тысяч запросов в сек, выше не проверял. > > Имея в наличии один access.log с помощью grep > можно легко получить из него access.log для любого сайта: > grep -P '\texample.com\t' access.log | less -S > удобство или неудобство действительно рассматривается в зависимости от используемых инструментов. что-то подсказывает, что использование grep как ежедневного инструмента - ну такое. и grep это опять же требует ssh доступа. навряд ли аналитикам это удобно. > > $scheme занимает всего несколько байт, и лучше уж пусть будет, > для полноты картины, по сравнению с $http_user_agent - это мелочь. > > Для удобства чтения лога и для уменьшения его размера > - можно из лога убрать информацию про таймзону: > > map $time_iso8601 $time { > "~([0-9-]+)T([0-9:]+)" "$1 $2"; > volatile; > } > > log_format frontend '$time\t...'; > > Тогда время в логе будет выглядеть примерно так: > > 2022-07-13 11:34:40 > > а не так: > > 2022-07-13T11:34:40+03:00 > > Переменная $time вместо $time_iso8601 в логе > дает и меньший объем лога и его лучшую читаемость. > iso8601 удобен тем, что он поддерживается для импорта во что угодно. соглашусь, что можно его убрать в логе, а потом добавить при импорте, если надо > > Недостаток у этого варианта с переменной $time только > ко мне как-то приставали, чтобы сделать map, которая добавляет миллисекунды )) > один - приходится программировать на конфигах nginx, > используя map и регулярные выражения, - это несколько > увеличивает объем конфига, но должно работать достаточно быстро. > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Wed Jul 13 09:07:55 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 13 Jul 2022 14:07:55 +0500 Subject: access.log In-Reply-To: References: <7c24483a-2eec-0902-ec66-70cf6e79e00f@csdoc.com> <5c5b6e78-4c30-bb3a-f8de-e9b43c51659f@csdoc.com> Message-ID: ср, 13 июл. 2022 г. в 14:00, Илья Шипицин : > > > ср, 13 июл. 2022 г. в 13:49, Gena Makhomed : > >> On 12.07.2022 22:59, Илья Шипицин wrote: >> >> > если рассматривать с точки зрения эффективного использования диска, то >> поля >> > $scheme, $host являются практически константами, можно не логировать их >> на >> > каждую строчку лога (а, например, разнести разные host-ы по разным >> логам). >> >> Разнести разные host-ы по разным логам - это на самом деле плохая идея. >> Когда различных хостов десятки и сотни - это становится очень неудобно. >> Кроме того, это отрицательно сказывается на производительности сервера, >> особенно если используется HDD а не SSD. >> > > это полностью в вашей власти, писать в каждую строку host или делать > отдельные логи. насчет производительности в случае HDD - не соглашусь, > если писать с буферизацией (buffer=... и flush=...), то HDD отлично > справляется вплоть до тысяч запросов в сек, выше не проверял. > > >> >> Имея в наличии один access.log с помощью grep >> можно легко получить из него access.log для любого сайта: >> grep -P '\texample.com\t' access.log | less -S >> > > удобство или неудобство действительно рассматривается в зависимости от > используемых инструментов. > что-то подсказывает, что использование grep как ежедневного инструмента - > ну такое. и grep это опять же > требует ssh доступа. навряд ли аналитикам это удобно. > про grep приходится постоянно иметь в виду "ну вот я сейчас запускаю обработку файла на .... 50 гигабайт, не повлияет ли это на функции сервера" > > > >> >> $scheme занимает всего несколько байт, и лучше уж пусть будет, >> для полноты картины, по сравнению с $http_user_agent - это мелочь. >> >> Для удобства чтения лога и для уменьшения его размера >> - можно из лога убрать информацию про таймзону: >> >> map $time_iso8601 $time { >> "~([0-9-]+)T([0-9:]+)" "$1 $2"; >> volatile; >> } >> >> log_format frontend '$time\t...'; >> >> Тогда время в логе будет выглядеть примерно так: >> >> 2022-07-13 11:34:40 >> >> а не так: >> >> 2022-07-13T11:34:40+03:00 >> >> Переменная $time вместо $time_iso8601 в логе >> дает и меньший объем лога и его лучшую читаемость. >> > > iso8601 удобен тем, что он поддерживается для импорта во что угодно. > соглашусь, что можно его убрать в логе, а потом добавить при импорте, если > надо > > >> >> Недостаток у этого варианта с переменной $time только >> > > ко мне как-то приставали, чтобы сделать map, которая добавляет > миллисекунды )) > > >> один - приходится программировать на конфигах nginx, >> используя map и регулярные выражения, - это несколько >> увеличивает объем конфига, но должно работать достаточно быстро. >> >> -- >> Best regards, >> Gena >> _______________________________________________ >> nginx-ru mailing list -- nginx-ru на nginx.org >> To unsubscribe send an email to nginx-ru-leave на nginx.org >> > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Jul 19 15:06:49 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 19 Jul 2022 18:06:49 +0300 Subject: nginx-1.23.1 Message-ID: Изменения в nginx 1.23.1 19.07.2022 *) Добавление: оптимизация использования памяти в конфигурациях с SSL-проксированием. *) Добавление: теперь с помощью параметра "ipv4=off" директивы "resolver" можно запретить поиск IPv4-адресов при преобразовании имён в адреса. *) Изменение: уровень логгирования ошибок SSL "bad key share", "bad extension", "bad cipher" и "bad ecpoint" понижен с уровня crit до info. *) Исправление: при возврате диапазонов nginx не удалял строку заголовка "Content-Range", если она присутствовала в исходном ответе бэкенда. *) Исправление: проксированный ответ мог быть отправлен не полностью при переконфигурации на Linux; ошибка появилась в 1.17.5. -- Maxim Dounin http://nginx.org/ From marck на rinet.ru Wed Jul 20 16:59:26 2022 From: marck на rinet.ru (Dmitry Morozovsky) Date: Wed, 20 Jul 2022 19:59:26 +0300 (MSK) Subject: certbot In-Reply-To: References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> <1bacf805-e79f-2b1a-46d3-042fae3ea8fd@csdoc.com> Message-ID: Коллеги, (чуть запоздало) On Thu, 7 Jul 2022, Maxim Dounin wrote: [snip] > И нет, наличие проблемы "авторы считают возможным менять конфиги" > в одном из вариантов использования - не означает, что в других > вариантах использования проблем нет. Наличие такой проблемы > означает, что авторы не понимают проблему, и что там ещё и где > разложено или будет разложено в будущем - неизвестно. И лично я > предпочитаю пользоваться тем, что работает, и рекомендовать его > же. вот шесть лет назад Пит Уэмм довольно подробно расписал как и что (с тех пор скриптовать стало проще и, что ли, "повторяемее") https://blog.crashed.org/letsencrypt-in-freebsd-org/ -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck на FreeBSD.org ] --------------------------------------------------------------------------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- woozle на woozle.net *** --------------------------------------------------------------------------- From mdounin на mdounin.ru Wed Jul 20 20:01:22 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 20 Jul 2022 23:01:22 +0300 Subject: certbot In-Reply-To: References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> <1bacf805-e79f-2b1a-46d3-042fae3ea8fd@csdoc.com> Message-ID: Hello! On Wed, Jul 20, 2022 at 07:59:26PM +0300, Dmitry Morozovsky wrote: > Коллеги, > > (чуть запоздало) > > On Thu, 7 Jul 2022, Maxim Dounin wrote: > > [snip] > > > И нет, наличие проблемы "авторы считают возможным менять конфиги" > > в одном из вариантов использования - не означает, что в других > > вариантах использования проблем нет. Наличие такой проблемы > > означает, что авторы не понимают проблему, и что там ещё и где > > разложено или будет разложено в будущем - неизвестно. И лично я > > предпочитаю пользоваться тем, что работает, и рекомендовать его > > же. > > вот шесть лет назад Пит Уэмм довольно подробно расписал как и что (с тех пор > скриптовать стало проще и, что ли, "повторяемее") > > https://blog.crashed.org/letsencrypt-in-freebsd-org/ Я, конечно, дико извиняюсь, но всерьёз воспринимать написанное не могу: начиная от утверждений про "servers require a full restart to re-load the certificates if the filename is unchanged", что применительно к nginx'у совершенно точно неправда, и заканчивая утверждениями про "nginx is broken" в части ocsp-must-staple, что явно показывает непонимание разницы между OCSP Stapling и требованиями OCSP Must Staple. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Thu Jul 21 10:42:32 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 21 Jul 2022 15:42:32 +0500 Subject: certbot In-Reply-To: References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> <1bacf805-e79f-2b1a-46d3-042fae3ea8fd@csdoc.com> Message-ID: чт, 21 июл. 2022 г. в 01:01, Maxim Dounin : > Hello! > > On Wed, Jul 20, 2022 at 07:59:26PM +0300, Dmitry Morozovsky wrote: > > > Коллеги, > > > > (чуть запоздало) > > > > On Thu, 7 Jul 2022, Maxim Dounin wrote: > > > > [snip] > > > > > И нет, наличие проблемы "авторы считают возможным менять конфиги" > > > в одном из вариантов использования - не означает, что в других > > > вариантах использования проблем нет. Наличие такой проблемы > > > означает, что авторы не понимают проблему, и что там ещё и где > > > разложено или будет разложено в будущем - неизвестно. И лично я > > > предпочитаю пользоваться тем, что работает, и рекомендовать его > > > же. > > > > вот шесть лет назад Пит Уэмм довольно подробно расписал как и что (с тех > пор > > скриптовать стало проще и, что ли, "повторяемее") > > > > https://blog.crashed.org/letsencrypt-in-freebsd-org/ > > Я, конечно, дико извиняюсь, но всерьёз воспринимать написанное не > могу: начиная от утверждений про "servers require a full restart > to re-load the certificates if the filename is unchanged", что > применительно к nginx'у совершенно точно неправда, и заканчивая > утверждениями про "nginx is broken" в части ocsp-must-staple, что > явно показывает непонимание разницы между OCSP Stapling и > требованиями OCSP Must Staple. > не собираюсь оправдывать автора статьи, но насчет OCSP Stapling есть вопросы. на что мы налетали. пишу я допустим "ssl_ocsp on" включаю - все работает, все счастливы. всем шампанское. потом, случайным образом - не работает. потом опять работает. смотрим под капот - при старте nginx идет обращение к OCSP и формируется (или не формируется) staple. не формируется в зависимости от миллиона причин. в нашем случае nginx стартовал при недоступных днс серверах (это один из штатных режимов запуска). по логу - ок, пишем warning, и едем дальше с отключенным OCSP. как-то в подобной ситуации включать MUST Staple - ну такое. страшновато. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Jul 21 10:47:21 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 21 Jul 2022 15:47:21 +0500 Subject: certbot In-Reply-To: References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> <1bacf805-e79f-2b1a-46d3-042fae3ea8fd@csdoc.com> Message-ID: чт, 21 июл. 2022 г. в 15:42, Илья Шипицин : > > > чт, 21 июл. 2022 г. в 01:01, Maxim Dounin : > >> Hello! >> >> On Wed, Jul 20, 2022 at 07:59:26PM +0300, Dmitry Morozovsky wrote: >> >> > Коллеги, >> > >> > (чуть запоздало) >> > >> > On Thu, 7 Jul 2022, Maxim Dounin wrote: >> > >> > [snip] >> > >> > > И нет, наличие проблемы "авторы считают возможным менять конфиги" >> > > в одном из вариантов использования - не означает, что в других >> > > вариантах использования проблем нет. Наличие такой проблемы >> > > означает, что авторы не понимают проблему, и что там ещё и где >> > > разложено или будет разложено в будущем - неизвестно. И лично я >> > > предпочитаю пользоваться тем, что работает, и рекомендовать его >> > > же. >> > >> > вот шесть лет назад Пит Уэмм довольно подробно расписал как и что (с >> тех пор >> > скриптовать стало проще и, что ли, "повторяемее") >> > >> > https://blog.crashed.org/letsencrypt-in-freebsd-org/ >> >> Я, конечно, дико извиняюсь, но всерьёз воспринимать написанное не >> могу: начиная от утверждений про "servers require a full restart >> to re-load the certificates if the filename is unchanged", что >> применительно к nginx'у совершенно точно неправда, и заканчивая >> утверждениями про "nginx is broken" в части ocsp-must-staple, что >> явно показывает непонимание разницы между OCSP Stapling и >> требованиями OCSP Must Staple. >> > > не собираюсь оправдывать автора статьи, но насчет OCSP Stapling есть > вопросы. > > на что мы налетали. > пишу я допустим "ssl_ocsp on" > тут наврал, мы писали "ssl_stapling on;" > > включаю - все работает, все счастливы. > всем шампанское. > > > потом, случайным образом - не работает. потом опять работает. > > смотрим под капот - при старте nginx идет обращение к OCSP и формируется > (или не формируется) staple. > не формируется в зависимости от миллиона причин. в нашем случае nginx > стартовал при недоступных днс серверах (это один из штатных режимов > запуска). > > по логу - ок, пишем warning, и едем дальше с отключенным OCSP. > > как-то в подобной ситуации включать MUST Staple - ну такое. страшновато. > >> >> -- >> Maxim Dounin >> http://mdounin.ru/ >> _______________________________________________ >> nginx-ru mailing list -- nginx-ru на nginx.org >> To unsubscribe send an email to nginx-ru-leave на nginx.org >> > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Thu Jul 21 11:03:48 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 21 Jul 2022 14:03:48 +0300 Subject: OCSP Must Staple In-Reply-To: References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> <1bacf805-e79f-2b1a-46d3-042fae3ea8fd@csdoc.com> Message-ID: On 21.07.2022 13:42, Илья Шипицин wrote: > как-то в подобной ситуации включать MUST Staple - ну такое. страшновато. Это подробно обсуждалось в 2018 году в этом списке рассылки: https://mailman.nginx.org/pipermail/nginx-ru/2018-September/thread.html#61447 Наиболее интересные сообщения из этого треда: https://mailman.nginx.org/pipermail/nginx-ru/2018-September/061496.html https://mailman.nginx.org/pipermail/nginx-ru/2018-September/061506.html https://mailman.nginx.org/pipermail/nginx-ru/2018-September/061509.html Если кратко, то суть в том, что OCSP Must Staple включать не нужно. -- Best regards, Gena From chipitsine на gmail.com Thu Jul 21 11:12:37 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 21 Jul 2022 16:12:37 +0500 Subject: OCSP Must Staple In-Reply-To: References: <0ba0aa9e29833b602acdea8c3062e93f.NginxMailingListRussian@forum.nginx.org> <7ad8c6b5-ee96-38cc-00e6-bd6a7f2cf906@csdoc.com> <1bacf805-e79f-2b1a-46d3-042fae3ea8fd@csdoc.com> Message-ID: чт, 21 июл. 2022 г. в 16:04, Gena Makhomed : > On 21.07.2022 13:42, Илья Шипицин wrote: > > > как-то в подобной ситуации включать MUST Staple - ну такое. страшновато. > > Это подробно обсуждалось в 2018 году в этом списке рассылки: > > > https://mailman.nginx.org/pipermail/nginx-ru/2018-September/thread.html#61447 > > Наиболее интересные сообщения из этого треда: > > https://mailman.nginx.org/pipermail/nginx-ru/2018-September/061496.html > > https://mailman.nginx.org/pipermail/nginx-ru/2018-September/061506.html > > https://mailman.nginx.org/pipermail/nginx-ru/2018-September/061509.html > > Если кратко, то суть в том, что OCSP Must Staple включать не нужно. > .... что в зависимости от экспрессивности может быть кем-то сформулировано как "OCSP поломан в nginx" технология неоднозначная, соглашусь > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Fri Jul 22 01:28:52 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 22 Jul 2022 04:28:52 +0300 Subject: OCSP Must Staple In-Reply-To: References: <1bacf805-e79f-2b1a-46d3-042fae3ea8fd@csdoc.com> Message-ID: Hello! On Thu, Jul 21, 2022 at 04:12:37PM +0500, Илья Шипицин wrote: > чт, 21 июл. 2022 г. в 16:04, Gena Makhomed : > > > On 21.07.2022 13:42, Илья Шипицин wrote: > > > > > как-то в подобной ситуации включать MUST Staple - ну такое. страшновато. > > > > Это подробно обсуждалось в 2018 году в этом списке рассылки: > > > > > > https://mailman.nginx.org/pipermail/nginx-ru/2018-September/thread.html#61447 > > > > Наиболее интересные сообщения из этого треда: > > > > https://mailman.nginx.org/pipermail/nginx-ru/2018-September/061496.html > > > > https://mailman.nginx.org/pipermail/nginx-ru/2018-September/061506.html > > > > https://mailman.nginx.org/pipermail/nginx-ru/2018-September/061509.html > > > > Если кратко, то суть в том, что OCSP Must Staple включать не нужно. > > > > .... что в зависимости от экспрессивности может быть кем-то сформулировано > как "OCSP поломан в nginx" > технология неоднозначная, соглашусь Безотносительно неоднозначности технологии, повторю ещё раз то, что написал: "что явно показывает непонимание разницы между OCSP Stapling и требованиями OCSP Must Staple" OCSP Stapling - это технология, которую nginx поддерживает и использование которой можно включить с помощью директивы ssl_stapling. OCSP Must Staple - это _другая_ технология, которая основывается на OCSP Stapling'е и предполагает дополнительные требования к его работе. Реализация OCSP Stapling в nginx'е далека от тех требований, которые предполагает OCSP Must Staple, и поддержку OCSP Must Staple никто никогда не заявлял. Формулировка же "поломан", вне зависимости от экспрессивности, предполагает непонимание того, что OCSP Stapling и OCSP Must Staple - это разные технологии. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Fri Jul 22 09:26:12 2022 From: nginx-forum на forum.nginx.org (sipopo) Date: Fri, 22 Jul 2022 05:26:12 -0400 Subject: 400 Bad request (spaces in request) Message-ID: <4f025e69e736741f9a917bd7be2d322d.NginxMailingListRussian@forum.nginx.org> Приветствую, знаю что с версии 1.21.1 nginx пишет ошибку 400, в случае пробелов в запросе к серверу. Но есть старые клиенты, которых нужно поддерживать, подскажите, может есть какие-то варианты обойти проблему? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294819,294819#msg-294819 From slw на zxy.spb.ru Fri Jul 22 15:13:14 2022 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Fri, 22 Jul 2022 18:13:14 +0300 Subject: =?utf-8?B?0J/QvtC80LXQvdGP0YLRjCDQtNC10YQ=?= =?utf-8?B?0L7Qu9GC0L3Rg9GOICRzY2hlbWUg0YEgaHR0cCDQvdCw?= https Message-ID: <20220722151314.GB14170@zxy.spb.ru> Как на уровне сервера для return задать другую схему? т.е. в конфиге что бы можно было писать 'return 301 /path' сам nginx работает на http, но есть вариант что через проксю с терминацией https на ней и в этом случае хотелось бы что бы 'return 301 /path' использовал https. и map и set на $scheme ругаются: the duplicate "scheme" variable From chipitsine на gmail.com Fri Jul 22 15:47:12 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 22 Jul 2022 20:47:12 +0500 Subject: =?UTF-8?B?UmU6INCf0L7QvNC10L3Rj9GC0Ywg0LTQtdGE0L7Qu9GC0L3Rg9GOICRzY2hlbWUg0YEgaA==?= =?UTF-8?B?dHRwINC90LAgaHR0cHM=?= In-Reply-To: <20220722151314.GB14170@zxy.spb.ru> References: <20220722151314.GB14170@zxy.spb.ru> Message-ID: а что показывает в хедере Location, если сделать "return 301 /path" ? там абсолютный адрес со схемой или относительный ? пт, 22 июл. 2022 г. в 20:13, Slawa Olhovchenkov : > Как на уровне сервера для return задать другую схему? > т.е. в конфиге что бы можно было писать 'return 301 /path' > сам nginx работает на http, но есть вариант что через проксю с > терминацией https на ней и в этом случае хотелось бы что бы > 'return 301 /path' использовал https. > > и map и set на $scheme ругаются: the duplicate "scheme" variable > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From slw на zxy.spb.ru Fri Jul 22 15:57:53 2022 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Fri, 22 Jul 2022 18:57:53 +0300 Subject: =?utf-8?B?0J/QvtC80LXQvdGP0YLRjCDQtNC1?= =?utf-8?B?0YTQvtC70YLQvdGD0Y4gJHNjaGVtZSDRgSBodHRwINC90LA=?= https In-Reply-To: References: <20220722151314.GB14170@zxy.spb.ru> Message-ID: <20220722155753.GC14170@zxy.spb.ru> On Fri, Jul 22, 2022 at 08:47:12PM +0500, Илья Шипицин wrote: > а что показывает в хедере Location, если сделать "return 301 /path" ? > там абсолютный адрес со схемой или относительный ? абсолютный со схемой > пт, 22 июл. 2022 г. в 20:13, Slawa Olhovchenkov : > > > Как на уровне сервера для return задать другую схему? > > т.е. в конфиге что бы можно было писать 'return 301 /path' > > сам nginx работает на http, но есть вариант что через проксю с > > терминацией https на ней и в этом случае хотелось бы что бы > > 'return 301 /path' использовал https. > > > > и map и set на $scheme ругаются: the duplicate "scheme" variable > > _______________________________________________ > > nginx-ru mailing list -- nginx-ru на nginx.org > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org From chipitsine на gmail.com Fri Jul 22 16:09:14 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 22 Jul 2022 21:09:14 +0500 Subject: =?UTF-8?B?UmU6INCf0L7QvNC10L3Rj9GC0Ywg0LTQtdGE0L7Qu9GC0L3Rg9GOICRzY2hlbWUg0YEgaA==?= =?UTF-8?B?dHRwINC90LAgaHR0cHM=?= In-Reply-To: <20220722155753.GC14170@zxy.spb.ru> References: <20220722151314.GB14170@zxy.spb.ru> <20220722155753.GC14170@zxy.spb.ru> Message-ID: а если сделать не "return 301 /path", а абсолютный урл, так работает ? или задача именно в том, чтобы возвращать https не указывая абсолютного урла ? пт, 22 июл. 2022 г. в 20:57, Slawa Olhovchenkov : > On Fri, Jul 22, 2022 at 08:47:12PM +0500, Илья Шипицин wrote: > > > а что показывает в хедере Location, если сделать "return 301 /path" ? > > там абсолютный адрес со схемой или относительный ? > > абсолютный со схемой > > > пт, 22 июл. 2022 г. в 20:13, Slawa Olhovchenkov : > > > > > Как на уровне сервера для return задать другую схему? > > > т.е. в конфиге что бы можно было писать 'return 301 /path' > > > сам nginx работает на http, но есть вариант что через проксю с > > > терминацией https на ней и в этом случае хотелось бы что бы > > > 'return 301 /path' использовал https. > > > > > > и map и set на $scheme ругаются: the duplicate "scheme" variable > > > _______________________________________________ > > > nginx-ru mailing list -- nginx-ru на nginx.org > > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > > > > > _______________________________________________ > > nginx-ru mailing list -- nginx-ru на nginx.org > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From slw на zxy.spb.ru Fri Jul 22 16:23:50 2022 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Fri, 22 Jul 2022 19:23:50 +0300 Subject: =?utf-8?B?0J/QvtC80LXQvdGP0YLRjCDQtNC1?= =?utf-8?B?0YTQvtC70YLQvdGD0Y4gJHNjaGVtZSDRgSBodHRwINC90LA=?= https In-Reply-To: References: <20220722151314.GB14170@zxy.spb.ru> <20220722155753.GC14170@zxy.spb.ru> Message-ID: <20220722162350.GD14170@zxy.spb.ru> On Fri, Jul 22, 2022 at 09:09:14PM +0500, Илья Шипицин wrote: > а если сделать не "return 301 /path", а абсолютный урл, так работает ? > или задача именно в том, чтобы возвращать https не указывая абсолютного > урла ? задача в том, что бы не переписывать конфиг сервера (который типа от какого nextcloud и этих ретурнов там до жопы и может не только return) > пт, 22 июл. 2022 г. в 20:57, Slawa Olhovchenkov : > > > On Fri, Jul 22, 2022 at 08:47:12PM +0500, Илья Шипицин wrote: > > > > > а что показывает в хедере Location, если сделать "return 301 /path" ? > > > там абсолютный адрес со схемой или относительный ? > > > > абсолютный со схемой > > > > > пт, 22 июл. 2022 г. в 20:13, Slawa Olhovchenkov : > > > > > > > Как на уровне сервера для return задать другую схему? > > > > т.е. в конфиге что бы можно было писать 'return 301 /path' > > > > сам nginx работает на http, но есть вариант что через проксю с > > > > терминацией https на ней и в этом случае хотелось бы что бы > > > > 'return 301 /path' использовал https. > > > > > > > > и map и set на $scheme ругаются: the duplicate "scheme" variable > > > > _______________________________________________ > > > > nginx-ru mailing list -- nginx-ru на nginx.org > > > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > > > > > > > > _______________________________________________ > > > nginx-ru mailing list -- nginx-ru на nginx.org > > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > > > _______________________________________________ > > nginx-ru mailing list -- nginx-ru на nginx.org > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org From chipitsine на gmail.com Fri Jul 22 17:52:08 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 22 Jul 2022 22:52:08 +0500 Subject: =?UTF-8?B?UmU6INCf0L7QvNC10L3Rj9GC0Ywg0LTQtdGE0L7Qu9GC0L3Rg9GOICRzY2hlbWUg0YEgaA==?= =?UTF-8?B?dHRwINC90LAgaHR0cHM=?= In-Reply-To: <20220722162350.GD14170@zxy.spb.ru> References: <20220722151314.GB14170@zxy.spb.ru> <20220722155753.GC14170@zxy.spb.ru> <20220722162350.GD14170@zxy.spb.ru> Message-ID: есть proxy_redirect https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_redirect но это влияет на модификацию (или не модификацию) редиректа, полученного от proxy_pass. у вас ведь не эта ситуация ? 301 вы сами генерите ? пт, 22 июл. 2022 г. в 21:24, Slawa Olhovchenkov : > On Fri, Jul 22, 2022 at 09:09:14PM +0500, Илья Шипицин wrote: > > > а если сделать не "return 301 /path", а абсолютный урл, так работает ? > > или задача именно в том, чтобы возвращать https не указывая абсолютного > > урла ? > > задача в том, что бы не переписывать конфиг сервера (который типа от > какого nextcloud и этих ретурнов там до жопы и может не только return) > > > пт, 22 июл. 2022 г. в 20:57, Slawa Olhovchenkov : > > > > > On Fri, Jul 22, 2022 at 08:47:12PM +0500, Илья Шипицин wrote: > > > > > > > а что показывает в хедере Location, если сделать "return 301 /path" ? > > > > там абсолютный адрес со схемой или относительный ? > > > > > > абсолютный со схемой > > > > > > > пт, 22 июл. 2022 г. в 20:13, Slawa Olhovchenkov : > > > > > > > > > Как на уровне сервера для return задать другую схему? > > > > > т.е. в конфиге что бы можно было писать 'return 301 /path' > > > > > сам nginx работает на http, но есть вариант что через проксю с > > > > > терминацией https на ней и в этом случае хотелось бы что бы > > > > > 'return 301 /path' использовал https. > > > > > > > > > > и map и set на $scheme ругаются: the duplicate "scheme" variable > > > > > _______________________________________________ > > > > > nginx-ru mailing list -- nginx-ru на nginx.org > > > > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > > > > > > > > > > > _______________________________________________ > > > > nginx-ru mailing list -- nginx-ru на nginx.org > > > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > > > > > _______________________________________________ > > > nginx-ru mailing list -- nginx-ru на nginx.org > > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > > > > > _______________________________________________ > > nginx-ru mailing list -- nginx-ru на nginx.org > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From pluknet на nginx.com Sat Jul 23 00:11:01 2022 From: pluknet на nginx.com (Sergey Kandaurov) Date: Sat, 23 Jul 2022 04:11:01 +0400 Subject: =?utf-8?B?0J/QvtC80LXQvdGP0YLRjCDQtNC10YTQvtC70YLQvdGD0Y4g?= =?utf-8?B?JHNjaGVtZSDRgSBodHRwINC90LA=?= https In-Reply-To: <20220722155753.GC14170@zxy.spb.ru> References: <20220722151314.GB14170@zxy.spb.ru> <20220722155753.GC14170@zxy.spb.ru> Message-ID: <20220723001101.vhfk6pnal47vcfgw@Y9MQ9X2QVV> On Fri, Jul 22, 2022 at 06:57:53PM +0300, Slawa Olhovchenkov wrote: > On Fri, Jul 22, 2022 at 08:47:12PM +0500, Илья Шипицин wrote: > > > а что показывает в хедере Location, если сделать "return 301 /path" ? > > там абсолютный адрес со схемой или относительный ? > > абсолютный со схемой Используйте директиву absolute_redirect для относительных редиректов. > > > пт, 22 июл. 2022 г. в 20:13, Slawa Olhovchenkov : > > > > > Как на уровне сервера для return задать другую схему? > > > т.е. в конфиге что бы можно было писать 'return 301 /path' > > > сам nginx работает на http, но есть вариант что через проксю с > > > терминацией https на ней и в этом случае хотелось бы что бы > > > 'return 301 /path' использовал https. > > > > > > и map и set на $scheme ругаются: the duplicate "scheme" variable From slw на zxy.spb.ru Sat Jul 23 07:36:14 2022 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Sat, 23 Jul 2022 10:36:14 +0300 Subject: =?utf-8?B?0J/QvtC80LXQvdGP0YLRjCDQtNC1?= =?utf-8?B?0YTQvtC70YLQvdGD0Y4gJHNjaGVtZSDRgSBodHRwINC90LA=?= https In-Reply-To: <20220723001101.vhfk6pnal47vcfgw@Y9MQ9X2QVV> References: <20220722151314.GB14170@zxy.spb.ru> <20220722155753.GC14170@zxy.spb.ru> <20220723001101.vhfk6pnal47vcfgw@Y9MQ9X2QVV> Message-ID: <20220723073614.GE14170@zxy.spb.ru> On Sat, Jul 23, 2022 at 04:11:01AM +0400, Sergey Kandaurov wrote: > On Fri, Jul 22, 2022 at 06:57:53PM +0300, Slawa Olhovchenkov wrote: > > On Fri, Jul 22, 2022 at 08:47:12PM +0500, Илья Шипицин wrote: > > > > > а что показывает в хедере Location, если сделать "return 301 /path" ? > > > там абсолютный адрес со схемой или относительный ? > > > > абсолютный со схемой > > Используйте директиву absolute_redirect для относительных редиректов. я же прямо пишу в конфиге директива return 301 /path и менять эти (и другие аналогичные места) я не хочу. > > > > > пт, 22 июл. 2022 г. в 20:13, Slawa Olhovchenkov : > > > > > > > Как на уровне сервера для return задать другую схему? > > > > т.е. в конфиге что бы можно было писать 'return 301 /path' > > > > сам nginx работает на http, но есть вариант что через проксю с > > > > терминацией https на ней и в этом случае хотелось бы что бы > > > > 'return 301 /path' использовал https. > > > > > > > > и map и set на $scheme ругаются: the duplicate "scheme" variable > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org From andrey на kopeyko.ru Sat Jul 23 09:08:48 2022 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Sat, 23 Jul 2022 12:08:48 +0300 Subject: 400 Bad request (spaces in request) In-Reply-To: <4f025e69e736741f9a917bd7be2d322d.NginxMailingListRussian@forum.nginx.org> References: <4f025e69e736741f9a917bd7be2d322d.NginxMailingListRussian@forum.nginx.org> Message-ID: <970d99adc06dd45b9e8332436f8ee22a@kopeyko.ru> sipopo писал 2022-07-22 12:26: Добрый день, sipopo! > Приветствую, знаю что с версии 1.21.1 nginx пишет ошибку 400, в случае > пробелов в запросе к серверу. > Но есть старые клиенты, которых нужно поддерживать, подскажите, может > есть > какие-то варианты обойти проблему? Запросы от старых клиентов принимайте на старом nginx, и проксируйте на новый. При проксировании старый nginx выполнит urlencoding запроса к новому nginx, и тот его не отлупит. -- Best regards, Andrey A. Kopeyko From mdounin на mdounin.ru Sat Jul 23 14:59:09 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sat, 23 Jul 2022 17:59:09 +0300 Subject: =?koi8-r?B?8M/Nxc7R1NggxMXGz8zUztXA?= =?koi8-r?Q?_$scheme_=D3_http_=CE=C1?= https In-Reply-To: <20220723073614.GE14170@zxy.spb.ru> References: <20220722151314.GB14170@zxy.spb.ru> <20220722155753.GC14170@zxy.spb.ru> <20220723001101.vhfk6pnal47vcfgw@Y9MQ9X2QVV> <20220723073614.GE14170@zxy.spb.ru> Message-ID: Hello! On Sat, Jul 23, 2022 at 10:36:14AM +0300, Slawa Olhovchenkov wrote: > On Sat, Jul 23, 2022 at 04:11:01AM +0400, Sergey Kandaurov wrote: > > > On Fri, Jul 22, 2022 at 06:57:53PM +0300, Slawa Olhovchenkov wrote: > > > On Fri, Jul 22, 2022 at 08:47:12PM +0500, Илья Шипицин wrote: > > > > > > > а что показывает в хедере Location, если сделать "return 301 /path" ? > > > > там абсолютный адрес со схемой или относительный ? > > > > > > абсолютный со схемой > > > > Используйте директиву absolute_redirect для относительных редиректов. > > я же прямо пишу в конфиге директива return 301 /path > и менять эти (и другие аналогичные места) я не хочу. А не надо ничего менять. Использование "absolute_redirect off;" в конфиге - выключает преобразование относительных перенаправлений в абсолютные, и "return 301 /path;" будет возвращать "Location: /path", без каких-либо попыток добавить схему и имя сайта. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Mon Jul 25 08:05:56 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 25 Jul 2022 11:05:56 +0300 Subject: Error log question In-Reply-To: References: <20220722151314.GB14170@zxy.spb.ru> <20220722155753.GC14170@zxy.spb.ru> <20220723001101.vhfk6pnal47vcfgw@Y9MQ9X2QVV> <20220723073614.GE14170@zxy.spb.ru> Message-ID: <0ff8b077-5844-39c8-442b-fd9d40675829@csdoc.com> On 24.07.2022 1:15, Maxim Dounin wrote: >> My nginx error log is being filled with errors which I believe are being >> surfaced from OpenSSL. The log entries number in the hundreds of >> thousands per day and I understand they are most likely due to >> conditions beyond my control. Examples of the log entries are: [...] >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not allocate >> new session in SSL session shared cache "le_nginx_SSL" while SSL >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443 > > This error indicate that nginx wasn't able to allocate new session > in the SSL session cache defined by the "ssl_session_cache" > directive, and removing an old session didn't help. This > basically indicate that the SSL session cache is too small, and it > would be a good idea to either configure a larger cache or reduce > ssl_session_timeout. The logging level is probably a bit too > scary, see https://trac.nginx.org/nginx/ticket/621 for details. Максим, Вы говорите, что "The message is probably a bit too scary (while the situation itself is mostly harmless)". Тикету https://trac.nginx.org/nginx/ticket/621 уже 8 лет. Разве не проще один раз пофиксить эту проблему в исходниках nginx, чем постоянно рассказывать пользователям в списках рассылки о том, что "The logging level is probably a bit too scary"? Если просто поменять [alert] на [warn] - ничего ведь не сломается? Почему же Вы этого не хочете или не можете сделать? Ведь это не сложно. Сейчас в nginx trac открыто 263 тикета https://trac.nginx.org/nginx/report/1 разве не было бы логично уменьшить их количество до минимально возможного числа, в идеале - до нуля? -- Best regards, Gena From mdounin на mdounin.ru Mon Jul 25 21:34:54 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 26 Jul 2022 00:34:54 +0300 Subject: Error log question In-Reply-To: <0ff8b077-5844-39c8-442b-fd9d40675829@csdoc.com> References: <20220722151314.GB14170@zxy.spb.ru> <20220722155753.GC14170@zxy.spb.ru> <20220723001101.vhfk6pnal47vcfgw@Y9MQ9X2QVV> <20220723073614.GE14170@zxy.spb.ru> <0ff8b077-5844-39c8-442b-fd9d40675829@csdoc.com> Message-ID: Hello! On Mon, Jul 25, 2022 at 11:05:56AM +0300, Gena Makhomed wrote: > On 24.07.2022 1:15, Maxim Dounin wrote: > > >> My nginx error log is being filled with errors which I believe are being > >> surfaced from OpenSSL. The log entries number in the hundreds of > >> thousands per day and I understand they are most likely due to > >> conditions beyond my control. Examples of the log entries are: > > [...] > > >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not allocate > >> new session in SSL session shared cache "le_nginx_SSL" while SSL > >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443 > > > > This error indicate that nginx wasn't able to allocate new session > > in the SSL session cache defined by the "ssl_session_cache" > > directive, and removing an old session didn't help. This > > basically indicate that the SSL session cache is too small, and it > > would be a good idea to either configure a larger cache or reduce > > ssl_session_timeout. The logging level is probably a bit too > > scary, see https://trac.nginx.org/nginx/ticket/621 for details. > > Максим, Вы говорите, что "The message is probably a bit too scary > (while the situation itself is mostly harmless)". > > Тикету https://trac.nginx.org/nginx/ticket/621 уже 8 лет. > > Разве не проще один раз пофиксить эту проблему в исходниках nginx, > чем постоянно рассказывать пользователям в списках рассылки о том, > что "The logging level is probably a bit too scary"? > > Если просто поменять [alert] на [warn] - ничего ведь не сломается? > Почему же Вы этого не хочете или не можете сделать? Ведь это не сложно. По конкретному тикету есть несколько моментов: - Перед тем, как менять уровень логгирования - надо как минимум проверить, что в случае невозможности выделения памяти для сессии действительно ничего не ломается. - А ещё неплохо бы сесть и внимательно посмотреть, не имеет ли смысла изменить логику удаления старых сессий в случае нехватки памяти, чтобы ошибок не возникало. Или даже переделать логику выделения памяти под сессии, дабы минимизировать вероятность неуспеха. Или прикрутить логику, аналогичную реализованной для памяти под элементы кэша (http://hg.nginx.org/nginx/rev/c9d680b00744). Всё это требует времени, которое конечно. Кроме того, "постоянно рассказывать" - на моей памяти примерно первый раз за прошедшие с момента появления этого тикета 8 лет. То есть проблемы, фактически, нет. > Сейчас в nginx trac открыто 263 тикета > https://trac.nginx.org/nginx/report/1 > разве не было бы логично уменьшить их количество > до минимально возможного числа, в идеале - до нуля? Было бы логично, конечно. Лично я регулярно занимаюсь тем, что уменьшаю количество открытых тикетов. Открытых тикетов про проблемы в коде сейчас - 70 штук, большую часть просто так не закрыть. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue Jul 26 08:35:48 2022 From: nginx-forum на forum.nginx.org (sipopo) Date: Tue, 26 Jul 2022 04:35:48 -0400 Subject: 400 Bad request (spaces in request) In-Reply-To: <970d99adc06dd45b9e8332436f8ee22a@kopeyko.ru> References: <970d99adc06dd45b9e8332436f8ee22a@kopeyko.ru> Message-ID: <6f4a96a6fbc5c106bf6d741e85174c9e.NginxMailingListRussian@forum.nginx.org> Андрей, спасибо за совет. Но, подсказали раочий вариант, использовать контекст stream и NJS Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294819,294857#msg-294857 From chipitsine на gmail.com Tue Jul 26 08:57:46 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 26 Jul 2022 13:57:46 +0500 Subject: Error log question In-Reply-To: References: <20220722151314.GB14170@zxy.spb.ru> <20220722155753.GC14170@zxy.spb.ru> <20220723001101.vhfk6pnal47vcfgw@Y9MQ9X2QVV> <20220723073614.GE14170@zxy.spb.ru> <0ff8b077-5844-39c8-442b-fd9d40675829@csdoc.com> Message-ID: вт, 26 июл. 2022 г. в 02:35, Maxim Dounin : > Hello! > > On Mon, Jul 25, 2022 at 11:05:56AM +0300, Gena Makhomed wrote: > > > On 24.07.2022 1:15, Maxim Dounin wrote: > > > > >> My nginx error log is being filled with errors which I believe are > being > > >> surfaced from OpenSSL. The log entries number in the hundreds of > > >> thousands per day and I understand they are most likely due to > > >> conditions beyond my control. Examples of the log entries are: > > > > [...] > > > > >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not > allocate > > >> new session in SSL session shared cache "le_nginx_SSL" while SSL > > >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443 > > > > > > This error indicate that nginx wasn't able to allocate new session > > > in the SSL session cache defined by the "ssl_session_cache" > > > directive, and removing an old session didn't help. This > > > basically indicate that the SSL session cache is too small, and it > > > would be a good idea to either configure a larger cache or reduce > > > ssl_session_timeout. The logging level is probably a bit too > > > scary, see https://trac.nginx.org/nginx/ticket/621 for details. > > > > Максим, Вы говорите, что "The message is probably a bit too scary > > (while the situation itself is mostly harmless)". > > > > Тикету https://trac.nginx.org/nginx/ticket/621 уже 8 лет. > > > > Разве не проще один раз пофиксить эту проблему в исходниках nginx, > > чем постоянно рассказывать пользователям в списках рассылки о том, > > что "The logging level is probably a bit too scary"? > > > > Если просто поменять [alert] на [warn] - ничего ведь не сломается? > > Почему же Вы этого не хочете или не можете сделать? Ведь это не сложно. > > По конкретному тикету есть несколько моментов: > > - Перед тем, как менять уровень логгирования - надо как минимум > проверить, что в случае невозможности выделения памяти для сессии > действительно ничего не ломается. > можно, наверное, поменять alert на warn, а потом еще лет 8 исследовать описанные моменты, которые действительно требуют время > > - А ещё неплохо бы сесть и внимательно посмотреть, не имеет ли > смысла изменить логику удаления старых сессий в случае нехватки > памяти, чтобы ошибок не возникало. Или даже переделать логику > выделения памяти под сессии, дабы минимизировать вероятность > неуспеха. Или прикрутить логику, аналогичную реализованной для > памяти под элементы кэша (http://hg.nginx.org/nginx/rev/c9d680b00744). > > Всё это требует времени, которое конечно. > > Кроме того, "постоянно рассказывать" - на моей памяти примерно > первый раз за прошедшие с момента появления этого тикета 8 лет. > То есть проблемы, фактически, нет. > > > Сейчас в nginx trac открыто 263 тикета > > https://trac.nginx.org/nginx/report/1 > > разве не было бы логично уменьшить их количество > > до минимально возможного числа, в идеале - до нуля? > > Было бы логично, конечно. Лично я регулярно занимаюсь тем, что > уменьшаю количество открытых тикетов. Открытых тикетов про > проблемы в коде сейчас - 70 штук, большую часть просто так не > закрыть. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Tue Jul 26 11:54:36 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 26 Jul 2022 14:54:36 +0300 Subject: Error log question In-Reply-To: References: <20220722151314.GB14170@zxy.spb.ru> <20220722155753.GC14170@zxy.spb.ru> <20220723001101.vhfk6pnal47vcfgw@Y9MQ9X2QVV> <20220723073614.GE14170@zxy.spb.ru> <0ff8b077-5844-39c8-442b-fd9d40675829@csdoc.com> Message-ID: <02a570c7-b3dd-5d93-144f-a63ef00b48f2@csdoc.com> On 26.07.2022 0:34, Maxim Dounin wrote: >> >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not allocate >> >> new session in SSL session shared cache "le_nginx_SSL" while SSL >> >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443 >> > >> > This error indicate that nginx wasn't able to allocate new session >> > in the SSL session cache defined by the "ssl_session_cache" >> > directive, and removing an old session didn't help. This >> > basically indicate that the SSL session cache is too small, and it >> > would be a good idea to either configure a larger cache or reduce >> > ssl_session_timeout. The logging level is probably a bit too >> > scary, see https://trac.nginx.org/nginx/ticket/621 for details. >> >> Максим, Вы говорите, что "The message is probably a bit too scary >> (while the situation itself is mostly harmless)". >> >> Тикету https://trac.nginx.org/nginx/ticket/621 уже 8 лет. >> >> Разве не проще один раз пофиксить эту проблему в исходниках nginx, >> чем постоянно рассказывать пользователям в списках рассылки о том, >> что "The logging level is probably a bit too scary"? >> >> Если просто поменять [alert] на [warn] - ничего ведь не сломается? >> Почему же Вы этого не хочете или не можете сделать? Ведь это не сложно. > > По конкретному тикету есть несколько моментов: > > - Перед тем, как менять уровень логгирования - надо как минимум > проверить, что в случае невозможности выделения памяти для сессии > действительно ничего не ломается. > > - А ещё неплохо бы сесть и внимательно посмотреть, не имеет ли > смысла изменить логику удаления старых сессий в случае нехватки > памяти, чтобы ошибок не возникало. Или даже переделать логику > выделения памяти под сессии, дабы минимизировать вероятность > неуспеха. Или прикрутить логику, аналогичную реализованной для > памяти под элементы кэша (http://hg.nginx.org/nginx/rev/c9d680b00744). Если не будет в логах ошибок - каким образом тогда пользователь сможет понять, что размер кэша для сессий SSL слишком маленький? Может же быть так, что установлен размер кэша для примерно 4000 сессий, а активных клиентов будет примерно в десять раз больше - в этом случае nginx будет постоянно удалять "старые" сессии, ничего при этом в логах не сообщая пользователю. Наверное это не самый лучший вариант поведения? Или наоборот, когда выставлен очень большой размер для кэша сессий SSL, а используется не более 10% - это тоже неоптимальная настройка nginx. Пользователи nginx-plus наверное смогут установить на свои сервера nginx-amplify-agent и возможно смогут увидеть в NGINX Amplify, что кэш для сессий SSL переполнен и его следует увеличить. (?) Но что в таком случае делать пользователям open source версии nginx? Насколько я понимаю, в NGINX Amplify для open source версии nginx метрик для кэша сессий SSL нет. Особенно, если пользователи nginx используют Rocky Linux 8.6, при запуске скрипта install.sh выдается такое сообщение про ошибку: Checking OS compatibility ... rocky is currently unsupported, apologies! Хотя по своей сути Rocky Linux 8.6 ведь ничем не отличается от RHEL 8.6. Это же 1:1 бинарно совместимая с RHEL8 сборка EL8 из тех же исходников. Если вручную прописать в файле /etc/yum.repos.d/nginx-amplify.repo [nginx-amplify] name=nginx amplify repo baseurl=http://packages.amplify.nginx.com/py3/rhel/8/$basearch gpgcheck=1 enabled=1 В таком случае NGINX Amplify Agent нормально устанавливается на Rocky Linux 8.6 и даже нормально запускается. Этот список рассылки, nginx-ru наверное не очень подходит для обсуждения NGINX Amplify Agent и NGINX Amplify? Куда лучше всего будет писать bug reports и feature requests по NGINX Amplify Agent и NGINX Amplify, напрямую емейлом разработчикам? -- Best regards, Gena From mdounin на mdounin.ru Tue Jul 26 13:59:12 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 26 Jul 2022 16:59:12 +0300 Subject: Error log question In-Reply-To: <02a570c7-b3dd-5d93-144f-a63ef00b48f2@csdoc.com> References: <20220722151314.GB14170@zxy.spb.ru> <20220722155753.GC14170@zxy.spb.ru> <20220723001101.vhfk6pnal47vcfgw@Y9MQ9X2QVV> <20220723073614.GE14170@zxy.spb.ru> <0ff8b077-5844-39c8-442b-fd9d40675829@csdoc.com> <02a570c7-b3dd-5d93-144f-a63ef00b48f2@csdoc.com> Message-ID: Hello! On Tue, Jul 26, 2022 at 02:54:36PM +0300, Gena Makhomed wrote: > On 26.07.2022 0:34, Maxim Dounin wrote: > > >> >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not allocate > >> >> new session in SSL session shared cache "le_nginx_SSL" while SSL > >> >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443 > >> > > >> > This error indicate that nginx wasn't able to allocate new session > >> > in the SSL session cache defined by the "ssl_session_cache" > >> > directive, and removing an old session didn't help. This > >> > basically indicate that the SSL session cache is too small, and it > >> > would be a good idea to either configure a larger cache or reduce > >> > ssl_session_timeout. The logging level is probably a bit too > >> > scary, see https://trac.nginx.org/nginx/ticket/621 for details. > >> > >> Максим, Вы говорите, что "The message is probably a bit too scary > >> (while the situation itself is mostly harmless)". > >> > >> Тикету https://trac.nginx.org/nginx/ticket/621 уже 8 лет. > >> > >> Разве не проще один раз пофиксить эту проблему в исходниках nginx, > >> чем постоянно рассказывать пользователям в списках рассылки о том, > >> что "The logging level is probably a bit too scary"? > >> > >> Если просто поменять [alert] на [warn] - ничего ведь не сломается? > >> Почему же Вы этого не хочете или не можете сделать? Ведь это не сложно. > > > > По конкретному тикету есть несколько моментов: > > > > - Перед тем, как менять уровень логгирования - надо как минимум > > проверить, что в случае невозможности выделения памяти для сессии > > действительно ничего не ломается. > > > > - А ещё неплохо бы сесть и внимательно посмотреть, не имеет ли > > смысла изменить логику удаления старых сессий в случае нехватки > > памяти, чтобы ошибок не возникало. Или даже переделать логику > > выделения памяти под сессии, дабы минимизировать вероятность > > неуспеха. Или прикрутить логику, аналогичную реализованной для > > памяти под элементы кэша (http://hg.nginx.org/nginx/rev/c9d680b00744). > > Если не будет в логах ошибок - каким образом тогда пользователь > сможет понять, что размер кэша для сессий SSL слишком маленький? Точно так же, как и сейчас - по статистике повторного использования сессий, других способов нет. Обсуждаемое сообщение об ошибке возникает тогда и только тогда, когда не удаётся выделить память после удаления одной из старых сессий. Такое может происходить, например, если удалённая сессия заметно отличается по размеру от создаваемой, и попадает в другой диапазон выделений slab-аллокатора. [...] > Этот список рассылки, nginx-ru наверное не очень подходит > для обсуждения NGINX Amplify Agent и NGINX Amplify? Совершенно не подходит. Впрочем, не уверен, что подходящее место вообще существует. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Tue Jul 26 14:33:15 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 26 Jul 2022 17:33:15 +0300 Subject: Error log question In-Reply-To: References: <20220722151314.GB14170@zxy.spb.ru> <20220722155753.GC14170@zxy.spb.ru> <20220723001101.vhfk6pnal47vcfgw@Y9MQ9X2QVV> <20220723073614.GE14170@zxy.spb.ru> <0ff8b077-5844-39c8-442b-fd9d40675829@csdoc.com> <02a570c7-b3dd-5d93-144f-a63ef00b48f2@csdoc.com> Message-ID: <38a50637-4a1e-57d1-1414-344ab18a4887@csdoc.com> On 26.07.2022 16:59, Maxim Dounin wrote: >>>> >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not allocate >>>> >> new session in SSL session shared cache "le_nginx_SSL" while SSL >>>> >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443 [...] >> Если не будет в логах ошибок - каким образом тогда пользователь >> сможет понять, что размер кэша для сессий SSL слишком маленький? > Точно так же, как и сейчас - по статистике повторного > использования сессий, других способов нет. Обсуждаемое сообщение > об ошибке возникает тогда и только тогда, когда не удаётся > выделить память после удаления одной из старых сессий. Такое > может происходить, например, если удалённая сессия заметно > отличается по размеру от создаваемой, и попадает в другой диапазон > выделений slab-аллокатора. А каким образом эту статистику повторного использования сессий можно получить? Для этого надо писать в лог значение переменной $ssl_session_reused потом скриптом вычислять процент запросов, у которых $ssl_session_reused возвращает значение "r" ? И в том случае, если этот процент стал меньше обычно наблюдаемого значения - это будет означать, что размер кэша для сессий SSL возможно стал слишком мал и его желательно увеличить? -- Best regards, Gena From chipitsine на gmail.com Tue Jul 26 14:46:50 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 26 Jul 2022 19:46:50 +0500 Subject: Error log question In-Reply-To: <38a50637-4a1e-57d1-1414-344ab18a4887@csdoc.com> References: <20220722151314.GB14170@zxy.spb.ru> <20220722155753.GC14170@zxy.spb.ru> <20220723001101.vhfk6pnal47vcfgw@Y9MQ9X2QVV> <20220723073614.GE14170@zxy.spb.ru> <0ff8b077-5844-39c8-442b-fd9d40675829@csdoc.com> <02a570c7-b3dd-5d93-144f-a63ef00b48f2@csdoc.com> <38a50637-4a1e-57d1-1414-344ab18a4887@csdoc.com> Message-ID: вт, 26 июл. 2022 г. в 19:33, Gena Makhomed : > On 26.07.2022 16:59, Maxim Dounin wrote: > > >>>> >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not > allocate > >>>> >> new session in SSL session shared cache "le_nginx_SSL" while SSL > >>>> >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443 > > [...] > > >> Если не будет в логах ошибок - каким образом тогда пользователь > >> сможет понять, что размер кэша для сессий SSL слишком маленький? > > > Точно так же, как и сейчас - по статистике повторного > > использования сессий, других способов нет. Обсуждаемое сообщение > > об ошибке возникает тогда и только тогда, когда не удаётся > > выделить память после удаления одной из старых сессий. Такое > > может происходить, например, если удалённая сессия заметно > > отличается по размеру от создаваемой, и попадает в другой диапазон > > выделений slab-аллокатора. > > А каким образом эту статистику повторного использования сессий > можно получить? Для этого надо писать в лог значение переменной > $ssl_session_reused потом скриптом вычислять процент запросов, > и да, и нет. действительно, сессию можно логировать, но это не значит, что сессия была использована. сессии это устаревший механизм, сейчас 100% современных браузеров используют tls tickets SSL session tickets vs session ids - Stack Overflow это примерно как сессии, но хранятся на клиенте. > у которых $ssl_session_reused возвращает значение "r" ? И в том случае, > если этот процент стал меньше обычно наблюдаемого значения - > вопрос хороший, но, не уверен, что актуальный. из того, с чем реально сталкивались - ротация тикетов и сессий. есть два пограничных подхода а) никогда не делать релоад. (сессии вечные, безопасники несчастны) б) иногда делать релоад. сессии ротируются, но по вам со всей дури прилетает cpu storm на полных хендшейках как-то управляемо ротировать сессии, без привязки к релоаду, было бы идеально > это будет означать, что размер кэша для сессий SSL > возможно стал слишком мал и его желательно увеличить? > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue Jul 26 15:40:02 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 26 Jul 2022 20:40:02 +0500 Subject: Error log question In-Reply-To: <38a50637-4a1e-57d1-1414-344ab18a4887@csdoc.com> References: <20220722151314.GB14170@zxy.spb.ru> <20220722155753.GC14170@zxy.spb.ru> <20220723001101.vhfk6pnal47vcfgw@Y9MQ9X2QVV> <20220723073614.GE14170@zxy.spb.ru> <0ff8b077-5844-39c8-442b-fd9d40675829@csdoc.com> <02a570c7-b3dd-5d93-144f-a63ef00b48f2@csdoc.com> <38a50637-4a1e-57d1-1414-344ab18a4887@csdoc.com> Message-ID: вт, 26 июл. 2022 г. в 19:33, Gena Makhomed : > On 26.07.2022 16:59, Maxim Dounin wrote: > > >>>> >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not > allocate > >>>> >> new session in SSL session shared cache "le_nginx_SSL" while SSL > >>>> >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443 > > [...] > > >> Если не будет в логах ошибок - каким образом тогда пользователь > >> сможет понять, что размер кэша для сессий SSL слишком маленький? > > > Точно так же, как и сейчас - по статистике повторного > > использования сессий, других способов нет. Обсуждаемое сообщение > > об ошибке возникает тогда и только тогда, когда не удаётся > > выделить память после удаления одной из старых сессий. Такое > > может происходить, например, если удалённая сессия заметно > > отличается по размеру от создаваемой, и попадает в другой диапазон > > выделений slab-аллокатора. > > А каким образом эту статистику повторного использования сессий > можно получить? Для этого надо писать в лог значение переменной > $ssl_session_reused потом скриптом вычислять процент запросов, > у которых $ssl_session_reused возвращает значение "r" ? И в том случае, > подобные штуки можно логировать в nginx-lua (модуль не всеми считается production ready, ваше использование его предполагает осознанный выбор) в log_by_lua добавить обработчик, который в зависимости от $ssl_session_reused будет увеличивать счетчик общих запросов и счетчик кешированных Lua Ngx API - OpenResty Reference (openresty-reference.readthedocs.io) и в каком-нибудь локейшене через content_by_lua отдавать эти счетчики правда, с релоадом счетчики обнулятся > если этот процент стал меньше обычно наблюдаемого значения - > это будет означать, что размер кэша для сессий SSL > возможно стал слишком мал и его желательно увеличить? > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Jul 26 21:08:10 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 27 Jul 2022 00:08:10 +0300 Subject: Error log question In-Reply-To: References: <20220722155753.GC14170@zxy.spb.ru> <20220723001101.vhfk6pnal47vcfgw@Y9MQ9X2QVV> <20220723073614.GE14170@zxy.spb.ru> <0ff8b077-5844-39c8-442b-fd9d40675829@csdoc.com> <02a570c7-b3dd-5d93-144f-a63ef00b48f2@csdoc.com> <38a50637-4a1e-57d1-1414-344ab18a4887@csdoc.com> Message-ID: Hello! On Tue, Jul 26, 2022 at 07:46:50PM +0500, Илья Шипицин wrote: > вт, 26 июл. 2022 г. в 19:33, Gena Makhomed : > > > On 26.07.2022 16:59, Maxim Dounin wrote: > > > > >>>> >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not > > allocate > > >>>> >> new session in SSL session shared cache "le_nginx_SSL" while SSL > > >>>> >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443 > > > > [...] > > > > >> Если не будет в логах ошибок - каким образом тогда пользователь > > >> сможет понять, что размер кэша для сессий SSL слишком маленький? > > > > > Точно так же, как и сейчас - по статистике повторного > > > использования сессий, других способов нет. Обсуждаемое сообщение > > > об ошибке возникает тогда и только тогда, когда не удаётся > > > выделить память после удаления одной из старых сессий. Такое > > > может происходить, например, если удалённая сессия заметно > > > отличается по размеру от создаваемой, и попадает в другой диапазон > > > выделений slab-аллокатора. > > > > А каким образом эту статистику повторного использования сессий > > можно получить? Для этого надо писать в лог значение переменной > > $ssl_session_reused потом скриптом вычислять процент запросов, > > > > и да, и нет. действительно, сессию можно логировать, но это не значит, что > сессия была использована. > сессии это устаревший механизм, сейчас 100% современных браузеров > используют tls tickets Когда я последний раз проверял (полгода назад в рамках ticket #1892, https://trac.nginx.org/nginx/ticket/1892) - в тикеты не умел Safari. Возможно, имеет смысл таки добраться до ticket #927 (https://trac.nginx.org/nginx/ticket/927), и сделать, чтобы reuse сессий через тикеты можно было легко отличить от такового через кэш сессий. Сейчас использование тикетов от кэша сессий отличается по отсутствию $ssl_session_id после первого хендшейка - что в принципе позволяет их отличать, но делать это, скажем так, неудобно. [...] > из того, с чем реально сталкивались - ротация тикетов и сессий. есть два > пограничных подхода > > а) никогда не делать релоад. (сессии вечные, безопасники несчастны) > б) иногда делать релоад. сессии ротируются, но по вам со всей дури > прилетает cpu storm на полных хендшейках > > как-то управляемо ротировать сессии, без привязки к релоаду, было бы > идеально Проблема не в "сессии вечные", проблема, о которой любят плакаться безопасники - это то, что ключ шифрования тикетов меняется только при релоаде. Соответственно если кто-нибудь сможет получить этот ключ - он сможет расшифровать записанный трафик после последнего релоада. Ключ - симметричный ключ на 256-бит, то есть единственная реальная возможность его получить - это доступ к оперативной памяти работающего сервера. Если это действительно проблема, то сейчас есть два работающих варианта её решения, не приводящих к увеличению числа полных хендшейков: - Выключить тикеты, и использовать кэш сессий. В этом случае сессионные ключи будут удаляться из памяти сервера по мере перезаписи другими сессиями, и соответственно возможность расшифровки ранее записанного трафика ограничена последними сессиями. - Использовать несколько ключей для шифрования тикетов, заданных через директиву ssl_session_ticket_key, и периодически их вращать (добавлять новый и убирать самый старый). В этом случае ключи для шифрования тикетов обновляются с любой удобной частотой, а количество полных хендшейков не увеличивается (так как для шифрования новых тикетов используется первый ключ, и старые ключи становятся не нужны после истечения ssl_session_timeout с того момента, как ключ перестал быть первым). В планах - сделать-таки автоматическое вращение ключей в памяти, но пока этого нет. В частности потому, что модель угроз, в которой это важно - выглядит немного оторванной от реальности. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Wed Jul 27 04:39:43 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 27 Jul 2022 09:39:43 +0500 Subject: Error log question In-Reply-To: References: <20220722155753.GC14170@zxy.spb.ru> <20220723001101.vhfk6pnal47vcfgw@Y9MQ9X2QVV> <20220723073614.GE14170@zxy.spb.ru> <0ff8b077-5844-39c8-442b-fd9d40675829@csdoc.com> <02a570c7-b3dd-5d93-144f-a63ef00b48f2@csdoc.com> <38a50637-4a1e-57d1-1414-344ab18a4887@csdoc.com> Message-ID: ср, 27 июл. 2022 г. в 02:08, Maxim Dounin : > Hello! > > On Tue, Jul 26, 2022 at 07:46:50PM +0500, Илья Шипицин wrote: > > > вт, 26 июл. 2022 г. в 19:33, Gena Makhomed : > > > > > On 26.07.2022 16:59, Maxim Dounin wrote: > > > > > > >>>> >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not > > > allocate > > > >>>> >> new session in SSL session shared cache "le_nginx_SSL" while > SSL > > > >>>> >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443 > > > > > > [...] > > > > > > >> Если не будет в логах ошибок - каким образом тогда пользователь > > > >> сможет понять, что размер кэша для сессий SSL слишком маленький? > > > > > > > Точно так же, как и сейчас - по статистике повторного > > > > использования сессий, других способов нет. Обсуждаемое сообщение > > > > об ошибке возникает тогда и только тогда, когда не удаётся > > > > выделить память после удаления одной из старых сессий. Такое > > > > может происходить, например, если удалённая сессия заметно > > > > отличается по размеру от создаваемой, и попадает в другой диапазон > > > > выделений slab-аллокатора. > > > > > > А каким образом эту статистику повторного использования сессий > > > можно получить? Для этого надо писать в лог значение переменной > > > $ssl_session_reused потом скриптом вычислять процент запросов, > > > > > > > и да, и нет. действительно, сессию можно логировать, но это не значит, > что > > сессия была использована. > > сессии это устаревший механизм, сейчас 100% современных браузеров > > используют tls tickets > > Когда я последний раз проверял (полгода назад в рамках ticket > #1892, https://trac.nginx.org/nginx/ticket/1892) - в тикеты не > умел Safari. > > Возможно, имеет смысл таки добраться до ticket #927 > (https://trac.nginx.org/nginx/ticket/927), и сделать, чтобы reuse > сессий через тикеты можно было легко отличить от такового через > кэш сессий. Сейчас использование тикетов от кэша сессий > отличается по отсутствию $ssl_session_id после первого хендшейка - > что в принципе позволяет их отличать, но делать это, скажем так, > неудобно. > > [...] > > > из того, с чем реально сталкивались - ротация тикетов и сессий. есть два > > пограничных подхода > > > > а) никогда не делать релоад. (сессии вечные, безопасники несчастны) > > б) иногда делать релоад. сессии ротируются, но по вам со всей дури > > прилетает cpu storm на полных хендшейках > > > > как-то управляемо ротировать сессии, без привязки к релоаду, было бы > > идеально > > Проблема не в "сессии вечные", проблема, о которой любят плакаться > безопасники - это то, что ключ шифрования тикетов меняется только > при релоаде. Соответственно если кто-нибудь сможет получить этот > ключ - он сможет расшифровать записанный трафик после последнего > релоада. Ключ - симметричный ключ на 256-бит, то есть > единственная реальная возможность его получить - это доступ к > оперативной памяти работающего сервера. > > Если это действительно проблема, то сейчас есть два работающих > варианта её решения, не приводящих к увеличению числа полных > хендшейков: > > - Выключить тикеты, и использовать кэш сессий. В этом случае > сессионные ключи будут удаляться из памяти сервера по мере > перезаписи другими сессиями, и соответственно возможность > расшифровки ранее записанного трафика ограничена последними > сессиями. > > - Использовать несколько ключей для шифрования тикетов, заданных > через директиву ssl_session_ticket_key, и периодически их > вращать (добавлять новый и убирать самый старый). В этом случае > ключи для шифрования тикетов обновляются с любой удобной частотой, > а количество полных хендшейков не увеличивается (так как для > шифрования новых тикетов используется первый ключ, и старые ключи > становятся не нужны после истечения ssl_session_timeout с того > момента, как ключ перестал быть первым). > я почему-то был уверен, что ключ может быть только один. надо будет затестить несколько ключей > > В планах - сделать-таки автоматическое вращение ключей в памяти, > но пока этого нет. В частности потому, что модель угроз, в > которой это важно - выглядит немного оторванной от реальности. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: