From phoedos16 на gmail.com Thu May 6 19:58:48 2021 From: phoedos16 на gmail.com (Alex F) Date: Fri, 7 May 2021 00:58:48 +0500 Subject: =?UTF-8?B?0LfQsNC/0YDQtdGCINGA0LXQtNC40YDQtdC60YLQsCDQvdCwINCy0L3QtdGI0L0=?= =?UTF-8?B?0LjQuSDRgNC10YHRg9GA0YE=?= Message-ID: Здравствуйте! nginx 1.19.3 1.20.0 есть следующая конфигурация сервера *mysite.org.ssl.conf* server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name mysite.org; access_log /var/log/nginx/mysite.org/access.log extended; error_log /var/log/nginx/mysite.org/error.log; ssl_certificate "/etc/letsencrypt/live/mysite.org/fullchain.pem"; ssl_certificate_key "/etc/letsencrypt/live/mysite.org/privkey.pem"; include ssl_config; location / { proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_set_header Connection "Keep-Alive"; proxy_set_header Proxy-Connection "Keep-Alive"; proxy_connect_timeout 7200s; proxy_read_timeout 7200s; proxy_send_timeout 7200s; client_max_body_size 7M; proxy_pass http://mysite.backend.local:80; } } нашел потенциальный фишинговый кейс, если клиент перейдет по ссылке типа https://*mysite.org//example.org * nginx сделает 301 редирект на сайт злоумышленника (example.org) даже не переходя на апстрим / GET ///example.org/ HTTP/2.0 301 291 219 "-" "useragent" "-" 0.000 - - подскажите, как контролировать подобные кейсы, запретив переход по на сторонний ресурс ? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Fri May 7 15:25:18 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 7 May 2021 18:25:18 +0300 Subject: ignore long locked inactive cache entry Message-ID: <1f7e1077-ff20-1c24-550b-bfb4bad1b8ed@csdoc.com> Здравствуйте, All! Использую nginx 1.19.10 из официального репозитория на сайте nginx.org, без сторонних модулей. При этом в логах наблюдаются такие строки: [alert] 2569378#2569378: *449013402 open socket #29 left in connection 3 [alert] 2569378#2569378: *449013403 open socket #32 left in connection 8 [alert] 2569378#2569378: aborting Насколько я понимаю - это означает что worker-процесс nginx аварийно завершил свою работу. Можно ли как-то настроить nginx или систему таким образом, чтобы в этот момент создавался дамп памяти процесса, чтобы можно было бы найти причину этого аварийного завершения работы? Дальше в логе наблюдаются такие строки: [alert] 3459906#3459906: ignore long locked inactive cache entry de41775189dd3dbc95ae14cfa9fa5813, count:2 Насколько я понимаю - это означает, что worker-процесс nginx аварийно завершил свою работу в момент обновления записи в cache, и эта запись осталась залоченной в памяти. Можно ли сделать так, чтобы в разделяемой памяти в качестве признака блокировки использовался бы PID процесса? Т.е. если 0 - то запись не заблокирована, если какое-то ненулевое значение - значит она заблокирована worker-процессом nginx с таким PID. И в случае обнаружения long locked inactive cache entry можно было бы проверить - существует ли в системе worker-процесс nginx с таким PID, и если нет - тогда просто разблокировать эту cache entry и продолжить нормальную работу. Альтернативный вариант - это сделать так, чтобы nginx не падал, но насколько я понимаю, программ без ошибок не бывает и они есть даже и в nginx в настоящий момент времени. Конфиг бекенда, на котором была эта ошибка, примерно такой: aio threads; aio_write on; sendfile on; sendfile_max_chunk 1M; server { listen 80; server_name example.com; root /home/www/example.com/static.www/; location / { error_page 404 = @php; location ~ \.xml$ { log_not_found off; } location ~ \. { expires 24h; } return 404; } location @php { include /etc/nginx/fastcgi_params; fastcgi_param SCRIPT_FILENAME /home/www/example.com/engine/index.php; fastcgi_param HTTPS $http_x_forwarded_https if_not_empty; fastcgi_pass unix:/run/php-fpm/www.sock; fastcgi_cache one; fastcgi_cache_key "$request_method $scheme://$host$request_uri"; fastcgi_cache_min_uses 1; fastcgi_cache_valid 200 301 302 404 10m; fastcgi_cache_use_stale error timeout invalid_header updating http_500 http_503; fastcgi_cache_lock on; fastcgi_cache_revalidate on; fastcgi_cache_background_update on; add_header X-Cache-Status $upstream_cache_status; fastcgi_cache_bypass $http_update_nginx_cache; fastcgi_cache_bypass $cookie_no_nginx_cache; fastcgi_no_cache $cookie_no_nginx_cache; } location /static/ { root /home/www/example.com; add_header Access-Control-Allow-Origin *; add_header Cache-control public; expires 1y; error_page 404 = @static; log_not_found off; } location @static { include /etc/nginx/fastcgi_params; fastcgi_param SCRIPT_FILENAME /home/www/example.com/engine/static.php; fastcgi_param HTTPS $http_x_forwarded_https if_not_empty; fastcgi_pass unix:/run/php-fpm/www.sock; } } Возможно получится воспроизвести эту ошибку и падение воркер-процесса nginx с таким конфигом с помощью рандомного нагрузочного тестирования? Память на сервере ECC и в /var/log/messages нет информации про ошибки памяти, так что вероятность того, что это hardware related проблема - близка к нулю. -- Best regards, Gena From mdounin на mdounin.ru Fri May 7 18:19:37 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 7 May 2021 21:19:37 +0300 Subject: ignore long locked inactive cache entry In-Reply-To: <1f7e1077-ff20-1c24-550b-bfb4bad1b8ed@csdoc.com> References: <1f7e1077-ff20-1c24-550b-bfb4bad1b8ed@csdoc.com> Message-ID: Hello! On Fri, May 07, 2021 at 06:25:18PM +0300, Gena Makhomed wrote: > Здравствуйте, All! > > Использую nginx 1.19.10 из официального репозитория на сайте nginx.org, > без сторонних модулей. При этом в логах наблюдаются такие строки: > > [alert] 2569378#2569378: *449013402 open socket #29 left in connection 3 > [alert] 2569378#2569378: *449013403 open socket #32 left in connection 8 > [alert] 2569378#2569378: aborting > > Насколько я понимаю - это означает что worker-процесс nginx аварийно > завершил свою работу. Можно ли как-то настроить nginx или систему > таким образом, чтобы в этот момент создавался дамп памяти процесса, > чтобы можно было бы найти причину этого аварийного завершения работы? В данном случае "aborting" означает, что следом за сообщением стоит ngx_debug_point(), и если в настройках будет "debug_points abort;", то случится abort с последующей записью дампа (http://nginx.org/r/debug_points). > Дальше в логе наблюдаются такие строки: > > [alert] 3459906#3459906: ignore long locked inactive cache entry > de41775189dd3dbc95ae14cfa9fa5813, count:2 > > Насколько я понимаю - это означает, что worker-процесс nginx аварийно > завершил свою работу в момент обновления записи в cache, и эта запись > осталась залоченной в памяти. Можно ли сделать так, чтобы в разделяемой > памяти в качестве признака блокировки использовался бы PID процесса? > > Т.е. если 0 - то запись не заблокирована, если какое-то ненулевое > значение - значит она заблокирована worker-процессом nginx с таким PID. > > И в случае обнаружения long locked inactive cache entry можно было бы > проверить - существует ли в системе worker-процесс nginx с таким PID, > и если нет - тогда просто разблокировать эту cache entry и продолжить > нормальную работу. > > Альтернативный вариант - это сделать так, чтобы nginx не падал, > но насколько я понимаю, программ без ошибок не бывает > и они есть даже и в nginx в настоящий момент времени. > > Конфиг бекенда, на котором была эта ошибка, примерно такой: > > aio threads; > aio_write on; Скорее всего в данном случае дело в aio_write, см. https://trac.nginx.org/nginx/ticket/2162. [...] -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Fri May 7 19:40:52 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 7 May 2021 22:40:52 +0300 Subject: ignore long locked inactive cache entry In-Reply-To: References: <1f7e1077-ff20-1c24-550b-bfb4bad1b8ed@csdoc.com> Message-ID: On 07.05.2021 21:19, Maxim Dounin wrote: >> [alert] 2569378#2569378: *449013402 open socket #29 left in connection 3 >> [alert] 2569378#2569378: *449013403 open socket #32 left in connection 8 >> [alert] 2569378#2569378: aborting [...] >> Конфиг бекенда, на котором была эта ошибка, примерно такой: >> >> aio threads; >> aio_write on; > > Скорее всего в данном случае дело в aio_write, см. > https://trac.nginx.org/nginx/ticket/2162. Понятно, спасибо! Максим, Вы говорите в комментариях к этому тикету: > It is not expected to affect real-world use cases, > though probably worth fixing anyway. У меня этот bug проявился именно что в real-world use case. > If the worker process exits prematurely while a requests updates > the cache with proxy_cache_use_stale updating;, the cache item > is stuck in the UPDATING state and won't be updated till the cache > is reloaded (for example, due to nginx restart or binary upgrade). > As already explained in comment:2, this is not expected to happen > in real-world use cases. If you want to be completely safe from > the particular issue, avoid using aio, > most notably avoid aio_write on;. Другими словами aio и aio_write пока что еще не production ready. Неожиданно, что этот момент не отображен в документации к nginx. -- Best regards, Gena From mdounin на mdounin.ru Fri May 7 21:36:10 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sat, 8 May 2021 00:36:10 +0300 Subject: ignore long locked inactive cache entry In-Reply-To: References: <1f7e1077-ff20-1c24-550b-bfb4bad1b8ed@csdoc.com> Message-ID: Hello! On Fri, May 07, 2021 at 10:40:52PM +0300, Gena Makhomed wrote: > On 07.05.2021 21:19, Maxim Dounin wrote: > > >> [alert] 2569378#2569378: *449013402 open socket #29 left in connection 3 > >> [alert] 2569378#2569378: *449013403 open socket #32 left in connection 8 > >> [alert] 2569378#2569378: aborting > > [...] > > >> Конфиг бекенда, на котором была эта ошибка, примерно такой: > >> > >> aio threads; > >> aio_write on; > > > > Скорее всего в данном случае дело в aio_write, см. > > https://trac.nginx.org/nginx/ticket/2162. > > Понятно, спасибо! > > Максим, Вы говорите в комментариях к этому тикету: > > > It is not expected to affect real-world use cases, > > though probably worth fixing anyway. > > У меня этот bug проявился именно что в real-world use case. Ну видимо сильно зависит от use case'а. Такое может быть, когда кроме aio-записи в кэш ничего больше в рабочем процессе не остаётся, тогда shutdown может случиться раньше, чем надо. В норме такого не бывает, т.к. shutdown задерживают медленные клиенты. > > If the worker process exits prematurely while a requests updates > > the cache with proxy_cache_use_stale updating;, the cache item > > is stuck in the UPDATING state and won't be updated till the cache > > is reloaded (for example, due to nginx restart or binary upgrade). > > > As already explained in comment:2, this is not expected to happen > > in real-world use cases. If you want to be completely safe from > > the particular issue, avoid using aio, > > most notably avoid aio_write on;. > > Другими словами aio и aio_write пока что еще не production ready. > Неожиданно, что этот момент не отображен в документации к nginx. Тут зависит от того, с чем сравнивать. Если, скажем, с пригодностью протокола HTTP/2 к production-использованию в современном интернете - то и aio, и даже aio_write существенно более production ready. Но вообще сама по себе функциональность aio_write - достаточно новая и достаточно сложная, и предназначена в первую очередь для очень специфических конфигураций, где по другому никак. Если её включать просто так для всего, да ещё и комбинировать с механизмами, крайне чувствительными к любым отклонениям - можно найти себе приключений. Как, впрочем, и много где ещё. Патчи, что называется, welcome. Тем более, что основной вопрос там - как это красиво исправить, по возможности вписав в существующую инфраструктуру, не изобретая новых механизмов для задержки shutdown'а. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Sat May 8 09:25:17 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Sat, 8 May 2021 12:25:17 +0300 Subject: ignore long locked inactive cache entry In-Reply-To: References: <1f7e1077-ff20-1c24-550b-bfb4bad1b8ed@csdoc.com> Message-ID: <511b2f1b-cb5f-fc48-5b81-a782fb8644f6@csdoc.com> On 08.05.2021 0:36, Maxim Dounin wrote: >>> Скорее всего в данном случае дело в aio_write, см. >>> https://trac.nginx.org/nginx/ticket/2162. >> Максим, Вы говорите в комментариях к этому тикету: >> >> > It is not expected to affect real-world use cases, >> > though probably worth fixing anyway. >> >> У меня этот bug проявился именно что в real-world use case. > > Ну видимо сильно зависит от use case'а. Такое может быть, когда кроме > aio-записи в кэш ничего больше в рабочем процессе не остаётся, > тогда shutdown может случиться раньше, чем надо. В норме такого > не бывает, т.к. shutdown задерживают медленные клиенты. У меня перед nginx-backend стоит nginx-frontend, так что все медленные клиенты подключаются к nginx-frontend, а nginx-backend только очень быстро обрабатывает запросы и очень быстро отдает их на сторону nginx-frontend, медленных клиентов nginx-backend никогда не увидит. > Но вообще сама по себе функциональность aio_write - достаточно > новая и достаточно сложная, и предназначена в первую очередь для > очень специфических конфигураций, где по другому никак. Если её > включать просто так для всего, да ещё и комбинировать с > механизмами, крайне чувствительными к любым отклонениям - можно > найти себе приключений. Как, впрочем, и много где ещё. В документации эти моменты не описаны вообще, откуда же обычный пользователь nginx, вроде меня, может узнать какие опции можно безопасно включать, а какие следует включать с большой осторожностью? Насколько я знаю, в интернете нет в электронном виде книги/сайта где были бы описаны в доступном виде все такие нюансы настроек. Использовать конфиг-по-умолчанию - это тоже не вариант, потому что там по-умолчанию отключено практически все, что только можно отключить. > Патчи, что называется, welcome. Тем более, что основной вопрос > там - как это красиво исправить, по возможности вписав > в существующую инфраструктуру, не изобретая новых механизмов > для задержки shutdown'а. Если для всех thread_pool`ов сделать корректное закрытие перед shutdown`ом worker-процесса nginx, тогда и проблемы тогда не будет. Ведь aio-запись происходит в отдельных thread`ах, и проблема в том, что в момент shutdown`а worker-процесса nginx эти thread`ы еще активны. В файле ngx_thread_pool.c есть функция ngx_thread_pool_exit_worker, но она нигде в коде не используется, в частности, не используется в функции ngx_worker_process_exit из файла ngx_process_cycle.c Было бы логично сначала закрыть все thread_pool`ы, перед тем, как делать проверку на утечку сокетов. -- Best regards, Gena From nginx-forum на forum.nginx.org Tue May 11 08:52:37 2021 From: nginx-forum на forum.nginx.org (maximkherson) Date: Tue, 11 May 2021 04:52:37 -0400 Subject: =?UTF-8?B?0J/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUg0LIgbmdpbnggLyDQvtGC0LrRgNGL?= =?UTF-8?B?0YLRjCDQtNGA0YPQs9C+0Lkg0YHQsNC50YIg0L3QtSDQvNC10L3Rj9GPINGC?= =?UTF-8?B?0LXQutGD0YnQuNC5INCw0LTRgNC10YE=?= Message-ID: <35971b862e1789390b8ad9b506a841df.NginxMailingListRussian@forum.nginx.org> Делаю проксирование с локального хоста на google. Задача слудующая: В браузере ввожу proxy.localhost, нажимаю enter Открывается google.com, но в браузере в адресной строке остаётся proxy.localhost (т.е. выполняется проксирование) ПРОБЛЕМА. У меня работает как в случае редиректа, а не проксирования, т.е. после пункта 1 открывается google и запись в адресной строке меняется с proxy.localhost на https://www.google.com. ВОПРОС. Как сделать так, чтобы адрес оставался proxy.localhost, но открывался https://www.google.com ? Помогите пожалуйста, перепробовал множество вариантов, откатил до более менее рабочего, вот мой актуальный код: server { <------>listen *:80; <------>server_name proxy.localhost; <------>location / { <------><------> proxy_pass https://google.com/; <------>} } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291478,291478#msg-291478 From bgx на protva.ru Tue May 11 09:15:30 2021 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Tue, 11 May 2021 12:15:30 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INCyIG5naW54IC8g0L7RgtC6?= =?UTF-8?B?0YDRi9GC0Ywg0LTRgNGD0LPQvtC5INGB0LDQudGCINC90LUg0LzQtdC90Y8=?= =?UTF-8?B?0Y8g0YLQtdC60YPRidC40Lkg0LDQtNGA0LXRgQ==?= In-Reply-To: <35971b862e1789390b8ad9b506a841df.NginxMailingListRussian@forum.nginx.org> References: <35971b862e1789390b8ad9b506a841df.NginxMailingListRussian@forum.nginx.org> Message-ID: <20210511091530.GB2768@protva.ru> On Tue, May 11, 2021 at 04:52:37AM -0400, maximkherson wrote: > Делаю проксирование с локального хоста на google. Задача слудующая: > > В браузере ввожу proxy.localhost, нажимаю enter > Открывается google.com, но в браузере в адресной строке остаётся > proxy.localhost (т.е. выполняется проксирование) > ПРОБЛЕМА. У меня работает как в случае редиректа, а не проксирования, т.е. > после пункта 1 открывается google и запись в адресной строке меняется с > proxy.localhost на https://www.google.com. > > ВОПРОС. Как сделать так, чтобы адрес оставался proxy.localhost, но > открывался https://www.google.com ? Вы для какой бизнес-задачи пытаетесь изобрести такое витиеватое решение? :) Прежде всего следовало бы ответить на вопрос, нужно ли переписывать абсолютные url-ы в возвращаемых страницах на "proxy.localhost", и если да, то чем это делать. А если нет, то зачем такое проксирование? -- Eugene Berdnikov From red-fox0 на ya.ru Tue May 11 11:56:43 2021 From: red-fox0 на ya.ru (fox) Date: Tue, 11 May 2021 18:56:43 +0700 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INCyIG5naW54IC8g0L7RgtC6?= =?UTF-8?B?0YDRi9GC0Ywg0LTRgNGD0LPQvtC5INGB0LDQudGCINC90LUg0LzQtdC90Y8=?= =?UTF-8?B?0Y8g0YLQtdC60YPRidC40Lkg0LDQtNGA0LXRgQ==?= In-Reply-To: <20210511091530.GB2768@protva.ru> References: <35971b862e1789390b8ad9b506a841df.NginxMailingListRussian@forum.nginx.org> <20210511091530.GB2768@protva.ru> Message-ID: https://nginx.org/ru/docs/http/ngx_http_sub_module.html#sub_filter Но тебе всё равно не поможет. 11.05.2021 16:15, Evgeniy Berdnikov пишет: > On Tue, May 11, 2021 at 04:52:37AM -0400, maximkherson wrote: >> Делаю проксирование с локального хоста на google. Задача слудующая: >> >> В браузере ввожу proxy.localhost, нажимаю enter >> Открывается google.com, но в браузере в адресной строке остаётся >> proxy.localhost (т.е. выполняется проксирование) >> ПРОБЛЕМА. У меня работает как в случае редиректа, а не проксирования, т.е. >> после пункта 1 открывается google и запись в адресной строке меняется с >> proxy.localhost на https://www.google.com. >> >> ВОПРОС. Как сделать так, чтобы адрес оставался proxy.localhost, но >> открывался https://www.google.com ? > > Вы для какой бизнес-задачи пытаетесь изобрести такое витиеватое решение? :) > > Прежде всего следовало бы ответить на вопрос, нужно ли переписывать > абсолютные url-ы в возвращаемых страницах на "proxy.localhost", > и если да, то чем это делать. А если нет, то зачем такое проксирование? > From chipitsine на gmail.com Tue May 11 12:21:48 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 11 May 2021 17:21:48 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INCyIG5naW54IC8g0L7RgtC6?= =?UTF-8?B?0YDRi9GC0Ywg0LTRgNGD0LPQvtC5INGB0LDQudGCINC90LUg0LzQtdC90Y8=?= =?UTF-8?B?0Y8g0YLQtdC60YPRidC40Lkg0LDQtNGA0LXRgQ==?= In-Reply-To: <35971b862e1789390b8ad9b506a841df.NginxMailingListRussian@forum.nginx.org> References: <35971b862e1789390b8ad9b506a841df.NginxMailingListRussian@forum.nginx.org> Message-ID: если вы хотите проксировать на google, то это сайт, выставляющий HSTS заголовок (http strict), в вашем варианте вы отдадите эти заголовки на 80-м нешифрованном порту. браузер скорее всего сделает редирект. вт, 11 мая 2021 г. в 13:52, maximkherson : > Делаю проксирование с локального хоста на google. Задача слудующая: > > В браузере ввожу proxy.localhost, нажимаю enter > Открывается google.com, но в браузере в адресной строке остаётся > proxy.localhost (т.е. выполняется проксирование) > ПРОБЛЕМА. У меня работает как в случае редиректа, а не проксирования, т.е. > после пункта 1 открывается google и запись в адресной строке меняется с > proxy.localhost на https://www.google.com. > > ВОПРОС. Как сделать так, чтобы адрес оставался proxy.localhost, но > открывался https://www.google.com ? > > Помогите пожалуйста, перепробовал множество вариантов, откатил до более > менее рабочего, вот мой актуальный код: > > server { > <------>listen *:80; > <------>server_name proxy.localhost; > <------>location / { > <------><------> proxy_pass https://google.com/; > <------>} > } > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,291478,291478#msg-291478 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From izorkin на gmail.com Wed May 12 12:43:30 2021 From: izorkin на gmail.com (izorkin на gmail.com) Date: Wed, 12 May 2021 15:43:30 +0300 Subject: nginx: sandboxing Message-ID: <965399330.20210512154330@gmail.com> Здравствуйте. SystemD поддерживает возможность запуска сервисов в режиме песочницы. В параметрах есть опция RemoveIPC - https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RemoveIPC= Приложение nginx использует IPC вызовы? Можно ли фильтровать эти события, а так же системные вызовы @ipc - https://www.freedesktop.org/software/systemd/man/systemd.exec.html#SystemCallFilter= Набор фильтров @ipc фильруется такие системные вызовы: ``` # SysV IPC, POSIX Message Queues or other IPC ipc memfd_create mq_getsetattr mq_notify mq_open mq_timedreceive mq_timedreceive_time64 mq_timedsend mq_timedsend_time64 mq_unlink msgctl msgget msgrcv msgsnd pipe pipe2 process_vm_readv process_vm_writev semctl semget semop semtimedop semtimedop_time64 shmat shmctl shmdt shmget ``` В коде nginx используются эти вызовы? Тут - https://github.com/nginx/nginx/blob/master/src/event/ngx_event_pipe.c#L119 вроде используется вызов pipe. Или это разные вещи? nginx.service: ``` AmbientCapabilities=CAP_NET_BIND_SERVICE AmbientCapabilities=CAP_SYS_RESOURCE CapabilityBoundingSet=CAP_NET_BIND_SERVICE CapabilityBoundingSet=CAP_SYS_RESOURCE LockPersonality=true MemoryDenyWriteExecute=true NoNewPrivileges=true PrivateDevices=true PrivateMounts=true PrivateTmp=true ProcSubset=pid ProtectClock=true ProtectControlGroups=true ProtectHome=true ProtectHostname=true ProtectKernelLogs=true ProtectKernelModules=true ProtectKernelTunables=true ProtectProc=invisible ProtectSystem=strict RemoveIPC=true RestrictAddressFamilies=AF_UNIX RestrictAddressFamilies=AF_INET RestrictAddressFamilies=AF_INET6 RestrictNamespaces=true RestrictRealtime=true RestrictSUIDSGID=true SystemCallArchitectures=native SystemCallFilter=~@cpu-emulation @debug @keyring @ipc @mount @obsolete @privileged @setuid UMask=0027 ``` -- С уважением, Izorkin mailto:izorkin на gmail.com From chipitsine на gmail.com Wed May 12 15:39:33 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 12 May 2021 20:39:33 +0500 Subject: nginx: sandboxing In-Reply-To: <965399330.20210512154330@gmail.com> References: <965399330.20210512154330@gmail.com> Message-ID: а как предполагается, это должно работать ? типа, программа использует эти вызовы, а мы такие бац, и запретили. и что должно произойти ? всё сломается ? какая модель угроз ? есть какие-нибудь примеры ? ср, 12 мая 2021 г. в 17:43, : > Здравствуйте. > SystemD поддерживает возможность запуска сервисов в режиме песочницы. В > параметрах есть опция RemoveIPC - > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RemoveIPC= > Приложение nginx использует IPC вызовы? Можно ли фильтровать эти события, > а так же системные вызовы @ipc - > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#SystemCallFilter= > Набор фильтров @ipc фильруется такие системные вызовы: > ``` > # SysV IPC, POSIX Message Queues or other IPC > ipc > memfd_create > mq_getsetattr > mq_notify > mq_open > mq_timedreceive > mq_timedreceive_time64 > mq_timedsend > mq_timedsend_time64 > mq_unlink > msgctl > msgget > msgrcv > msgsnd > pipe > pipe2 > process_vm_readv > process_vm_writev > semctl > semget > semop > semtimedop > semtimedop_time64 > shmat > shmctl > shmdt > shmget > ``` > В коде nginx используются эти вызовы? > Тут - > https://github.com/nginx/nginx/blob/master/src/event/ngx_event_pipe.c#L119 > вроде используется вызов pipe. Или это разные вещи? > > nginx.service: > ``` > AmbientCapabilities=CAP_NET_BIND_SERVICE > AmbientCapabilities=CAP_SYS_RESOURCE > CapabilityBoundingSet=CAP_NET_BIND_SERVICE > CapabilityBoundingSet=CAP_SYS_RESOURCE > LockPersonality=true > MemoryDenyWriteExecute=true > NoNewPrivileges=true > PrivateDevices=true > PrivateMounts=true > PrivateTmp=true > ProcSubset=pid > ProtectClock=true > ProtectControlGroups=true > ProtectHome=true > ProtectHostname=true > ProtectKernelLogs=true > ProtectKernelModules=true > ProtectKernelTunables=true > ProtectProc=invisible > ProtectSystem=strict > RemoveIPC=true > RestrictAddressFamilies=AF_UNIX > RestrictAddressFamilies=AF_INET > RestrictAddressFamilies=AF_INET6 > RestrictNamespaces=true > RestrictRealtime=true > RestrictSUIDSGID=true > SystemCallArchitectures=native > SystemCallFilter=~@cpu-emulation @debug @keyring @ipc @mount @obsolete > @privileged @setuid > UMask=0027 > ``` > > > -- > С уважением, > Izorkin mailto:izorkin на gmail.com > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From izorkin на gmail.com Wed May 12 16:44:18 2021 From: izorkin на gmail.com (izorkin на gmail.com) Date: Wed, 12 May 2021 19:44:18 +0300 Subject: nginx: sandboxing In-Reply-To: References: <965399330.20210512154330@gmail.com> Message-ID: <1332532346.20210512194418@gmail.com> Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Wed May 12 16:54:30 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 12 May 2021 21:54:30 +0500 Subject: nginx: sandboxing In-Reply-To: <1332532346.20210512194418@gmail.com> References: <965399330.20210512154330@gmail.com> <1332532346.20210512194418@gmail.com> Message-ID: какие преимущества и в каких сценариях может дать такая настройка? ср, 12 мая 2021 г. в 21:44, : > Здравствуйте, Илья. > > Если nginx использует эти вызовы, то в конфигурацию сервиса добавить > строки, которые разрешают эти вызовы: > ``` > SystemCallFilter=pipe > SystemCallFilter=pipe2 > ``` > > Хотелось немного повысить безопасность службы и изолировать от других > сервисов, запущенных в системе. С большинство параметров > изоляции nginx работает нормально, а вот с системными вызовами уже сложнее > маленько разобраться. > > Вы писали 12 мая 2021 г., 18:39:33: > > > а как предполагается, это должно работать ? > > типа, программа использует эти вызовы, а мы такие бац, и запретили. > и что должно произойти ? всё сломается ? > > какая модель угроз ? есть какие-нибудь примеры ? > > > > > *-- С уважением, Izorkin * > mailto:izorkin на gmail.com > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From maxim на nginx.com Wed May 12 17:12:35 2021 From: maxim на nginx.com (Maxim Konovalov) Date: Wed, 12 May 2021 20:12:35 +0300 Subject: nginx: sandboxing In-Reply-To: References: <965399330.20210512154330@gmail.com> <1332532346.20210512194418@gmail.com> Message-ID: <26bf8d84-f8e4-f239-c84e-ee072e2bbdce@nginx.com> Привет. On 12.05.2021 19:54, Илья Шипицин wrote: > какие преимущества и в каких сценариях может дать такая настройка? > Илья, вы спрашиваете про sandboxing как технологию вообще или применительно к nginx/systemd? -- Maxim Konovalov From chipitsine на gmail.com Wed May 12 17:26:58 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 12 May 2021 22:26:58 +0500 Subject: nginx: sandboxing In-Reply-To: <26bf8d84-f8e4-f239-c84e-ee072e2bbdce@nginx.com> References: <965399330.20210512154330@gmail.com> <1332532346.20210512194418@gmail.com> <26bf8d84-f8e4-f239-c84e-ee072e2bbdce@nginx.com> Message-ID: На примере nginx, раз уж про него речь. Штука выглядит прикольной, но не могу придумать, когда она полезна и в чём On Wed, May 12, 2021, 10:12 PM Maxim Konovalov wrote: > Привет. > > On 12.05.2021 19:54, Илья Шипицин wrote: > > какие преимущества и в каких сценариях может дать такая настройка? > > > Илья, вы спрашиваете про sandboxing как технологию вообще или > применительно к nginx/systemd? > > -- > Maxim Konovalov > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From izorkin на gmail.com Wed May 12 17:29:54 2021 From: izorkin на gmail.com (izorkin на gmail.com) Date: Wed, 12 May 2021 20:29:54 +0300 Subject: nginx: sandboxing In-Reply-To: References: <965399330.20210512154330@gmail.com> <1332532346.20210512194418@gmail.com> <26bf8d84-f8e4-f239-c84e-ee072e2bbdce@nginx.com> Message-ID: <1769355228.20210512202954@gmail.com> Вложение в формате HTML было извлечено… URL: From maxim на nginx.com Wed May 12 17:32:20 2021 From: maxim на nginx.com (Maxim Konovalov) Date: Wed, 12 May 2021 20:32:20 +0300 Subject: nginx: sandboxing In-Reply-To: References: <965399330.20210512154330@gmail.com> <1332532346.20210512194418@gmail.com> <26bf8d84-f8e4-f239-c84e-ee072e2bbdce@nginx.com> Message-ID: <1dd853e1-9f3c-695e-5b53-ec223617c61c@nginx.com> On 12.05.2021 20:26, Илья Шипицин wrote: > На примере nginx, раз уж про него речь. > > Штука выглядит прикольной, но не могу придумать, когда она полезна и в чём > Допустим, известно, что в дикой природе программа X ни при каких случаях не должна делать execve(2). Отличная идея исключить этот вызов из списка разрешенных на тот случай, если вдруг в программе X найдут RCE. Видимо, лучше начать с https://en.wikipedia.org/wiki/Sandbox_(computer_security) Вряд ли я доступнее и нагляднее расскажу. Вот это еще можно поизучать в кач-ве старта: https://wiki.freebsd.org/Capsicum > On Wed, May 12, 2021, 10:12 PM Maxim Konovalov > wrote: > > Привет. > > On 12.05.2021 19:54, Илья Шипицин wrote: > > какие преимущества и в каких сценариях может дать такая настройка? > > > Илья, вы спрашиваете про sandboxing как технологию вообще или > применительно к nginx/systemd? > > -- > Maxim Konovalov > -- Maxim Konovalov From nginx-forum на forum.nginx.org Wed May 12 18:13:05 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Wed, 12 May 2021 14:13:05 -0400 Subject: =?UTF-8?B?0J/QvtGH0LXQvNGDINC90LUg0L/RgNC40LzQtdC90Y7RgtGB0Y8g0LfQsNCz0L4=?= =?UTF-8?B?0LvQvtC60Lgg0LTQu9GPIGxvY2F0aW9ucywg0L7Qv9GA0LXQtNC10LvQtdC9?= =?UTF-8?B?0L3Ri9C1INCyIHNlcnZlcj8=?= Message-ID: <7b1fc506c3e1b415a2fd3cbde778fd5b.NginxMailingListRussian@forum.nginx.org> /etc/nginx/config/system/security.conf ------------------------------------------------------------------------------------------------- server_tokens off; add_header X-Frame-Options "deny"; add_header X-XSS-Protection "1; mode=block" always; .... nginx.conf ------------------------------------------------------------------------------------------------- server { ... include /etc/nginx/config/system/security.conf; <- если разместить тут то заголовки не применяются location /log { ... include /etc/nginx/config/system/security.conf; proxy_pass http://logger; } location / { ... include /etc/nginx/config/system/security.conf; proxy_pass http://web_app; } } Имеем конфиг показанный выше Если импортировать security.conf на уровне server - заголовки не применяются к запросам в locations Заголовки применяются только если разместить импорт security.conf внутри каждой секции location Почему? В описании add_header написано что директива наследуется, а по факту - нет! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291500,291500#msg-291500 From nginx-forum на forum.nginx.org Wed May 12 18:22:56 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Wed, 12 May 2021 14:22:56 -0400 Subject: =?UTF-8?B?0JrQsNC6INC30LDQv9GA0LXRgtC40YLRjCDQtNC70Y8gbG9jYXRpb24gZXJyb3Ig?= =?UTF-8?B?cGFnZXMg0L7Qv9GA0LXQtNC10LvQtdC90L3Ri9C1INC90LAg0YPRgNC+0LI=?= =?UTF-8?B?0L3QtSBzZXJ2ZXI/?= Message-ID: На уровне server определены error_pages для location "/" Для остальных locations не нужно отдавать эти страницы, в случае возникновения ошибок Пытаюсь в этих секциях выставлять proxy_intercept_errors off; но бесполезно - при возникновении ошибки отдается страница а не ответ из upstream Как победить? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291501,291501#msg-291501 From nginx-forum на forum.nginx.org Wed May 12 19:24:09 2021 From: nginx-forum на forum.nginx.org (Helper code) Date: Wed, 12 May 2021 15:24:09 -0400 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQvdC1INC/0YDQuNC80LXQvdGO0YLRgdGPINC30LA=?= =?UTF-8?B?0LPQvtC70L7QutC4INC00LvRjyBsb2NhdGlvbnMsINC+0L/RgNC10LTQtdC7?= =?UTF-8?B?0LXQvdC90YvQtSDQsiBzZXJ2ZXI/?= In-Reply-To: <7b1fc506c3e1b415a2fd3cbde778fd5b.NginxMailingListRussian@forum.nginx.org> References: <7b1fc506c3e1b415a2fd3cbde778fd5b.NginxMailingListRussian@forum.nginx.org> Message-ID: <43a6a632d689f3bf020e6f4e43492d83.NginxMailingListRussian@forum.nginx.org> Директивы наследуются с предыдущего уровня конфигурации при условии, что на данном уровне не описаны свои директивы add_header. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291500,291502#msg-291502 From nginx-forum на forum.nginx.org Wed May 12 19:35:34 2021 From: nginx-forum на forum.nginx.org (Helper code) Date: Wed, 12 May 2021 15:35:34 -0400 Subject: =?UTF-8?B?0J3QtdGB0LrQvtC70YzQutC+INGB0YLRgNCw0L3QuNGGINC+0YjQuNCx0LrQuCAo?= =?UTF-8?B?NDA0KQ==?= Message-ID: <52934415a52fd7d71fda2696e7a5e02e.NginxMailingListRussian@forum.nginx.org> У меня есть двуязычный статический сайт, русскоязычный вариант которого находится в каталоге /rus/, а английский в корневом каталоге. Как сделать что бы для каталога /rus/ была бы своя русскоязычная страница 404? Казалось бы нужно добавить location /rus/ {error_page 404 /rus/404.htm;}, но в конфигурации есть регулярка location ~ \.htm$ {add_header Cache-Control no-cache;} , которая перехватывает поиск. server { error_page 404 /404.htm; location /rus/ {error_page 404 /rus/404.htm;} location ~ \.htm$ {add_header Cache-Control no-cache;} } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291503,291503#msg-291503 From nginx-forum на forum.nginx.org Wed May 12 19:38:06 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Wed, 12 May 2021 15:38:06 -0400 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQvdC1INC/0YDQuNC80LXQvdGO0YLRgdGPINC30LA=?= =?UTF-8?B?0LPQvtC70L7QutC4INC00LvRjyBsb2NhdGlvbnMsINC+0L/RgNC10LTQtdC7?= =?UTF-8?B?0LXQvdC90YvQtSDQsiBzZXJ2ZXI/?= In-Reply-To: <43a6a632d689f3bf020e6f4e43492d83.NginxMailingListRussian@forum.nginx.org> References: <7b1fc506c3e1b415a2fd3cbde778fd5b.NginxMailingListRussian@forum.nginx.org> <43a6a632d689f3bf020e6f4e43492d83.NginxMailingListRussian@forum.nginx.org> Message-ID: не очень понятно >> на данном уровне не описаны свои директивы add_header. не описаны любые или такие же??? речь как раз о случае когда я описываю в server и не описываю в location - заголовки не появляются в запросах к location Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291500,291504#msg-291504 From ngnx8810773a83 на avksrv.org Wed May 12 20:09:57 2021 From: ngnx8810773a83 на avksrv.org (Alexey) Date: Wed, 12 May 2021 23:09:57 +0300 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQvdC1INC/0YDQuNC80LXQvdGO0YLRgdGPINC30LA=?= =?UTF-8?B?0LPQvtC70L7QutC4INC00LvRjyBsb2NhdGlvbnMsINC+0L/RgNC10LTQtdC7?= =?UTF-8?B?0LXQvdC90YvQtSDQsiBzZXJ2ZXI/?= In-Reply-To: References: <7b1fc506c3e1b415a2fd3cbde778fd5b.NginxMailingListRussian@forum.nginx.org> <43a6a632d689f3bf020e6f4e43492d83.NginxMailingListRussian@forum.nginx.org> Message-ID: 12.05.2021 22:38, budarin пишет: > не очень понятно >> на данном уровне не описаны свои директивы add_header. > > не описаны любые или такие же??? > речь как раз о случае когда я описываю в server и не описываю в location - > заголовки не появляются в запросах к location > Скореее всего они (add_header) есть в /etc/nginx/config/system/security.conf или если там тоже есть инклюды, то там. Считайте тчо содердимое include файла просто вставлено на месте комманды include. команда расположена на уровне какого то include, соотв если во включаемом файле есть любые команды add_header, то всё что было описано выше не существует. From nginx-forum на forum.nginx.org Wed May 12 20:11:07 2021 From: nginx-forum на forum.nginx.org (Helper code) Date: Wed, 12 May 2021 16:11:07 -0400 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQvdC1INC/0YDQuNC80LXQvdGO0YLRgdGPINC30LA=?= =?UTF-8?B?0LPQvtC70L7QutC4INC00LvRjyBsb2NhdGlvbnMsINC+0L/RgNC10LTQtdC7?= =?UTF-8?B?0LXQvdC90YvQtSDQsiBzZXJ2ZXI/?= In-Reply-To: References: <7b1fc506c3e1b415a2fd3cbde778fd5b.NginxMailingListRussian@forum.nginx.org> <43a6a632d689f3bf020e6f4e43492d83.NginxMailingListRussian@forum.nginx.org> Message-ID: budarin Wrote: ------------------------------------------------------- > не описаны любые или такие же??? Любые. И не забывайте, что заголовки может добавлять не только add_header. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291500,291505#msg-291505 From nginx-forum на forum.nginx.org Thu May 13 00:07:38 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Wed, 12 May 2021 20:07:38 -0400 Subject: =?UTF-8?B?0JzQvtC20L3QviDQu9C4INGB0LPQtdC90LXRgNC40YDQvtCy0LDRgtGMINGB0Ls=?= =?UTF-8?B?0YPRh9Cw0LnQvdGD0Y4g0YHRgtGA0L7QutGDINCyINC/0LXRgNC10LzQtdC9?= =?UTF-8?B?0L3RgyDRgtCw0Log0LrQsNC6INGN0YLQviDQtNC10LvQsNC10YIgbmdpbngg?= =?UTF-8?B?0LTQu9GPIHJlcXVlc3QgaWQ/?= Message-ID: <4d4e1f1ccfdd3d540c5424f27d508c70.NginxMailingListRussian@forum.nginx.org> Мне нужно для CSP политики генерировать случайный nonce для каждого запроса и записывать его в заголовок политики и затем этот же none передать в заголовках апстриму Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291507,291507#msg-291507 From nginx-forum на forum.nginx.org Thu May 13 13:05:51 2021 From: nginx-forum на forum.nginx.org (maximkherson) Date: Thu, 13 May 2021 09:05:51 -0400 Subject: =?UTF-8?B?0JrQsNC6INC/0YDQvtC60YHQuNGA0L7QstCw0YLRjCDQsiBuZ2lueCDQv9C+0Lg=?= =?UTF-8?B?0YHQutC+0LLRi9C5INC30LDQv9GA0L7RgSDQvdCwINGB0LDQudGC0LU/?= Message-ID: <2c36d9109a672b54d164c15166cc06da.NginxMailingListRussian@forum.nginx.org> ЗАДАЧА. В адресной строке браузера ввожу proxy.localhost/godzilla (proxy.localhost мой виртальный хост). Nginx проксирует этот запрос, после чего в адресной строке дожно остаться proxy.localhost/godzilla но по факту дожно перейти на https://rezka.ag/search/?do=search&subaction=search&q=godzilla Мой код: server { <------>listen *:80; <------>server_name proxy.localhost; <------>location /(.*) { <------><------> proxy_pass https://rezka.ag/search/?do=search&subaction=search&q=$1; <------><------> proxy_set_header Host rezka.ag; <------>} } Пожалуйста помогите, а то уже всё перепробовал. P.S. У меня выдаёт 403 ошибку. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291508,291508#msg-291508 From nginx-forum на forum.nginx.org Thu May 13 14:02:25 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Thu, 13 May 2021 10:02:25 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0L/RgNC10YLQuNGC0Ywg0LTQu9GPIGxvY2F0aW9uIGVy?= =?UTF-8?B?cm9yIHBhZ2VzINC+0L/RgNC10LTQtdC70LXQvdC90YvQtSDQvdCwINGD0YA=?= =?UTF-8?B?0L7QstC90LUgc2VydmVyPw==?= In-Reply-To: References: Message-ID: <54d38b81586fab6986409999bcba6226.NginxMailingListRussian@forum.nginx.org> server { error_page 404 /404.html; error_page 404 /404.html; error_page 502 504 /502.html; error_page 503 /503.html; error_page 500 501 504 /500.html; location ~ [4-5][0-9][0-9].html { internal; } location / { proxy_intercept_errors on; .... } location /api { proxy_intercept_errors off; <-- вот тут не нужно перехватывать ошибки и поменять их файлами но они перехватываются (( .... } } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291501,291509#msg-291509 From andrey на kopeyko.ru Thu May 13 16:06:54 2021 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Thu, 13 May 2021 19:06:54 +0300 (MSK) Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0L7QutGB0LjRgNC+0LLQsNGC0Ywg0LIgbmdpbngg0L8=?= =?UTF-8?B?0L7QuNGB0LrQvtCy0YvQuSDQt9Cw0L/RgNC+0YEg0L3QsCDRgdCw0LnRgtC1?= =?UTF-8?B?Pw==?= In-Reply-To: <2c36d9109a672b54d164c15166cc06da.NginxMailingListRussian@forum.nginx.org> References: <2c36d9109a672b54d164c15166cc06da.NginxMailingListRussian@forum.nginx.org> Message-ID: On Thu, 13 May 2021, maximkherson wrote: > ЗАДАЧА. В адресной строке браузера ввожу proxy.localhost/godzilla > (proxy.localhost мой виртальный хост). Nginx проксирует этот запрос, после > чего в адресной строке дожно остаться proxy.localhost/godzilla но по факту > дожно перейти на > https://rezka.ag/search/?do=search&subaction=search&q=godzilla > > Мой код: > > server { > <------>listen *:80; > <------>server_name proxy.localhost; > <------>location /(.*) { > <------><------> proxy_pass > https://rezka.ag/search/?do=search&subaction=search&q=$1; > <------><------> proxy_set_header Host rezka.ag; > <------>} > } > Пожалуйста помогите, а то уже всё перепробовал. > > P.S. У меня выдаёт 403 ошибку. Сайт rezka.ag вас заблокировал. -- Best regards, Andrey A. Kopeyko From swood на fotofor.biz Thu May 13 19:33:59 2021 From: swood на fotofor.biz (Anton Kiryushkin) Date: Thu, 13 May 2021 20:33:59 +0100 Subject: =?UTF-8?B?UmU6INCc0L7QttC90L4g0LvQuCDRgdCz0LXQvdC10YDQuNGA0L7QstCw0YLRjCA=?= =?UTF-8?B?0YHQu9GD0YfQsNC50L3Rg9GOINGB0YLRgNC+0LrRgyDQsiDQv9C10YDQtdC8?= =?UTF-8?B?0LXQvdC90YMg0YLQsNC6INC60LDQuiDRjdGC0L4g0LTQtdC70LDQtdGCIG5n?= =?UTF-8?B?aW54INC00LvRjyByZXF1ZXN0IGlkPw==?= In-Reply-To: <4d4e1f1ccfdd3d540c5424f27d508c70.NginxMailingListRussian@forum.nginx.org> References: <4d4e1f1ccfdd3d540c5424f27d508c70.NginxMailingListRussian@forum.nginx.org> Message-ID: Можно попробовать сторонние модули, вроде lua или js. On Thu, 13 May 2021 at 01:07, budarin wrote: > Мне нужно для CSP политики генерировать случайный nonce для каждого запроса > и записывать его в заголовок политики и затем этот же none передать в > заголовках апстриму > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,291507,291507#msg-291507 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey на kopeyko.ru Thu May 13 19:40:23 2021 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Thu, 13 May 2021 22:40:23 +0300 Subject: =?UTF-8?B?UmU6INCc0L7QttC90L4g0LvQuCDRgdCz0LXQvdC10YDQuNGA0L7QstCw0YLRjCA=?= =?UTF-8?B?0YHQu9GD0YfQsNC50L3Rg9GOINGB0YLRgNC+0LrRgyDQsiDQv9C10YDQtdC8?= =?UTF-8?B?0LXQvdC90YMg0YLQsNC6INC60LDQuiDRjdGC0L4g0LTQtdC70LDQtdGCIG5n?= =?UTF-8?B?aW54INC00LvRjyByZXF1ZXN0IGlkPw==?= In-Reply-To: <4d4e1f1ccfdd3d540c5424f27d508c70.NginxMailingListRussian@forum.nginx.org> References: <4d4e1f1ccfdd3d540c5424f27d508c70.NginxMailingListRussian@forum.nginx.org> Message-ID: <510a42beadd3e91d14a3b2427e0048de@kopeyko.ru> budarin писал 2021-05-13 03:07: > Мне нужно для CSP политики генерировать случайный nonce для каждого > запроса > и записывать его в заголовок политики и затем этот же none передать в > заголовках апстриму perl_set $rand 'sub { return int rand 20 }'; И дальше используйте по вкусу. -- Best regards, Andrey A. Kopeyko From nginx-forum на forum.nginx.org Thu May 13 20:10:21 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Thu, 13 May 2021 16:10:21 -0400 Subject: =?UTF-8?B?UmU6INCc0L7QttC90L4g0LvQuCDRgdCz0LXQvdC10YDQuNGA0L7QstCw0YLRjCA=?= =?UTF-8?B?0YHQu9GD0YfQsNC50L3Rg9GOINGB0YLRgNC+0LrRgyDQsiDQv9C10YDQtdC8?= =?UTF-8?B?0LXQvdC90YMg0YLQsNC6INC60LDQuiDRjdGC0L4g0LTQtdC70LDQtdGCIG5n?= =?UTF-8?B?aW54INC00LvRjyByZXF1ZXN0IGlkPw==?= In-Reply-To: <510a42beadd3e91d14a3b2427e0048de@kopeyko.ru> References: <510a42beadd3e91d14a3b2427e0048de@kopeyko.ru> Message-ID: <3c9b91db48b74a6182bb49450af5b5ee.NginxMailingListRussian@forum.nginx.org> спасибо, но перл не очень хочется решил использовать саму переменную request_id - она ведь для каждого запроса уникальна Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291513,291514#msg-291514 From nginx-forum на forum.nginx.org Thu May 13 20:11:11 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Thu, 13 May 2021 16:11:11 -0400 Subject: =?UTF-8?B?UmU6INCc0L7QttC90L4g0LvQuCDRgdCz0LXQvdC10YDQuNGA0L7QstCw0YLRjCA=?= =?UTF-8?B?0YHQu9GD0YfQsNC50L3Rg9GOINGB0YLRgNC+0LrRgyDQsiDQv9C10YDQtdC8?= =?UTF-8?B?0LXQvdC90YMg0YLQsNC6INC60LDQuiDRjdGC0L4g0LTQtdC70LDQtdGCIG5n?= =?UTF-8?B?aW54INC00LvRjyByZXF1ZXN0IGlkPw==?= In-Reply-To: References: Message-ID: спасибо Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291512,291515#msg-291515 From nginx-forum на forum.nginx.org Thu May 13 20:12:17 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Thu, 13 May 2021 16:12:17 -0400 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQvdC1INC/0YDQuNC80LXQvdGO0YLRgdGPINC30LA=?= =?UTF-8?B?0LPQvtC70L7QutC4INC00LvRjyBsb2NhdGlvbnMsINC+0L/RgNC10LTQtdC7?= =?UTF-8?B?0LXQvdC90YvQtSDQsiBzZXJ2ZXI/?= In-Reply-To: References: Message-ID: <4d28835b4b70baf29699db39314934be.NginxMailingListRussian@forum.nginx.org> понял, спасибо Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291500,291516#msg-291516 From nginx-forum на forum.nginx.org Thu May 13 20:20:20 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Thu, 13 May 2021 16:20:20 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0L/RgNC10YLQuNGC0Ywg0LTQu9GPIGxvY2F0aW9uIGVy?= =?UTF-8?B?cm9yIHBhZ2VzINC+0L/RgNC10LTQtdC70LXQvdC90YvQtSDQvdCwINGD0YA=?= =?UTF-8?B?0L7QstC90LUgc2VydmVyPw==?= In-Reply-To: <54d38b81586fab6986409999bcba6226.NginxMailingListRussian@forum.nginx.org> References: <54d38b81586fab6986409999bcba6226.NginxMailingListRussian@forum.nginx.org> Message-ID: есть ли хоть какие-то идеи как это исправить? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291501,291517#msg-291517 From nginx-forum на forum.nginx.org Fri May 14 06:38:31 2021 From: nginx-forum на forum.nginx.org (sf2015) Date: Fri, 14 May 2021 02:38:31 -0400 Subject: =?UTF-8?B?0JrQsNC6INGD0YHRgtCw0L3QvtCy0LjRgtGMIFJhcGlkIFNTTCAyMDE4?= Message-ID: <825ce72835273bf7809bff93b9fbbbe1.NginxMailingListRussian@forum.nginx.org> Для домена test.ru и всех поддоменов приобретен сеттификат Rapid SSL 2018 Имеется: сам сертификат test_ru.crt промежуточный intermediate_pem_geotrust_rapidssl_wildcard_1.crt промежуточный intermediate_pem_geotrust_rapidssl_wildcard_2.crt приватный ключ key.txt корневой сертификат root_pem_geotrust_rapidssl_wildcard_1.crt сертификат test.ru.ca-bundle Nginx установлен на Ubuntu 20 с IP 192.168.0.43. общая задача такая. Есть некий вебсервис (https:// t1.test.ru), который крутится на серваке в локалке с адресом 192.168.0.230. Сейчас При вводе адреса https://t1.test.ru клиент проваливается на192.168.0.230. Нужна схема с проксированием так, чтобы При вводе адреса https://t1.test.ru клиент проваливается на192.168.0.43, а затем перенаправлялся на 192.168.0.230 В перспективе будут еще https://t2.test.ru, которые пойдут на 192.168.0.232 и т.п. ----------------- 1. Подскажите какие как быть с сертификатами. Какие из приведённых выше прописать в файле конфигурации. server { #listen 80; listen 443 ssl default_server; listen [::]:443 ssl default_server; ssl on; ssl_certificate /etc/ssl/test.ru/dcli.ru.ca-bundle; #ssl_certificate_key /etc/ssl/test.ru/key.txt; #ssl_session_timeout 5m; #ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #ssl_dhparam /etc/ssl/certs/dhparam.pem; #ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH'; #ssl_prefer_server_ciphers on; #ssl_session_cache shared:SSL:10m; server_name t1.test.ru; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; location / { proxy_pass https://192.168.0.230; } } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291518,291518#msg-291518 From red-fox0 на ya.ru Fri May 14 11:15:13 2021 From: red-fox0 на ya.ru (fox) Date: Fri, 14 May 2021 18:15:13 +0700 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0L/RgNC10YLQuNGC0Ywg0LTQu9GPIGxvY2F0aW9uIGVy?= =?UTF-8?B?cm9yIHBhZ2VzINC+0L/RgNC10LTQtdC70LXQvdC90YvQtSDQvdCwINGD0YA=?= =?UTF-8?B?0L7QstC90LUgc2VydmVyPw==?= In-Reply-To: References: <54d38b81586fab6986409999bcba6226.NginxMailingListRussian@forum.nginx.org> Message-ID: <912ecaf8-7223-7dd4-7391-85f7a7ff7a09@ya.ru> Что если переместить error_page из блока server в location / 14.05.2021 03:20, budarin пишет: > есть ли хоть какие-то идеи как это исправить? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291501,291517#msg-291517 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From andrey на kopeyko.ru Fri May 14 13:22:19 2021 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Fri, 14 May 2021 16:22:19 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9GB0YLQsNC90L7QstC40YLRjCBSYXBpZCBTU0wgMjAxOA==?= In-Reply-To: <825ce72835273bf7809bff93b9fbbbe1.NginxMailingListRussian@forum.nginx.org> References: <825ce72835273bf7809bff93b9fbbbe1.NginxMailingListRussian@forum.nginx.org> Message-ID: <50031bfbb768b0b743fcbee452b9d7e2@kopeyko.ru> sf2015 писал 2021-05-14 09:38: > Для домена test.ru и всех поддоменов приобретен сеттификат Rapid SSL > 2018 Если ваш сертификат допустимо ставить на несколько серверов одновременно (ищите в договоре "server licences" или аналогичные слова), то можете просто размножить ключ+серт по нужному кол-ву железок\виртуалок. С соответствующими рисками для безопасности. Если такое вам не разрешено, то * или раскладывайте ключ+серт на свой страх и риск * или докупайте опцию "server licences" * или докупайте нужное кол-во сертификатов для уникальных ключей > Имеется: > сам сертификат test_ru.crt > промежуточный intermediate_pem_geotrust_rapidssl_wildcard_1.crt > промежуточный intermediate_pem_geotrust_rapidssl_wildcard_2.crt > приватный ключ key.txt > корневой сертификат root_pem_geotrust_rapidssl_wildcard_1.crt > сертификат test.ru.ca-bundle > > Nginx установлен на Ubuntu 20 с IP 192.168.0.43. > > общая задача такая. Есть некий вебсервис (https:// t1.test.ru), который > крутится на серваке в локалке с адресом 192.168.0.230. > > Сейчас При вводе адреса https://t1.test.ru клиент проваливается > на192.168.0.230. > Нужна схема с проксированием так, чтобы При вводе адреса > https://t1.test.ru > клиент проваливается на192.168.0.43, а затем перенаправлялся на > 192.168.0.230 > > В перспективе будут еще https://t2.test.ru, которые пойдут на > 192.168.0.232 > и т.п. > > > ----------------- > 1. Подскажите какие как быть с сертификатами. Какие из приведённых выше > прописать в файле конфигурации. > > > > > server { > #listen 80; > listen 443 ssl default_server; > listen [::]:443 ssl default_server; > ssl on; > ssl_certificate /etc/ssl/test.ru/dcli.ru.ca-bundle; > #ssl_certificate_key /etc/ssl/test.ru/key.txt; > #ssl_session_timeout 5m; > #ssl_protocols TLSv1 TLSv1.1 TLSv1.2; > #ssl_dhparam /etc/ssl/certs/dhparam.pem; > #ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH'; > #ssl_prefer_server_ciphers on; > #ssl_session_cache shared:SSL:10m; > > > server_name t1.test.ru; > access_log /var/log/nginx/access.log; > error_log /var/log/nginx/error.log; > > location / { > proxy_pass https://192.168.0.230; > } > } > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,291518,291518#msg-291518 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Andrey A. Kopeyko From chipitsine на gmail.com Fri May 14 13:42:39 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 14 May 2021 18:42:39 +0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9GB0YLQsNC90L7QstC40YLRjCBSYXBpZCBTU0wgMjAxOA==?= In-Reply-To: <50031bfbb768b0b743fcbee452b9d7e2@kopeyko.ru> References: <825ce72835273bf7809bff93b9fbbbe1.NginxMailingListRussian@forum.nginx.org> <50031bfbb768b0b743fcbee452b9d7e2@kopeyko.ru> Message-ID: рискну предположить, что бест практис "как использовать выданный нами сертификат" можно ожидать от тех, кто сертификат выдал. вы же им деньги заплатили, почему бы им не сделать всё по красоте. по крайней мере я такие рекомендации припоминаю. пт, 14 мая 2021 г. в 18:22, Andrey Kopeyko : > sf2015 писал 2021-05-14 09:38: > > Для домена test.ru и всех поддоменов приобретен сеттификат Rapid SSL > > 2018 > > Если ваш сертификат допустимо ставить на несколько серверов одновременно > (ищите в договоре "server licences" или аналогичные слова), то можете > просто размножить ключ+серт по нужному кол-ву железок\виртуалок. С > соответствующими рисками для безопасности. > > Если такое вам не разрешено, то > * или раскладывайте ключ+серт на свой страх и риск > * или докупайте опцию "server licences" > * или докупайте нужное кол-во сертификатов для уникальных ключей > > > Имеется: > > сам сертификат test_ru.crt > > промежуточный intermediate_pem_geotrust_rapidssl_wildcard_1.crt > > промежуточный intermediate_pem_geotrust_rapidssl_wildcard_2.crt > > приватный ключ key.txt > > корневой сертификат root_pem_geotrust_rapidssl_wildcard_1.crt > > сертификат test.ru.ca-bundle > > > > Nginx установлен на Ubuntu 20 с IP 192.168.0.43. > > > > общая задача такая. Есть некий вебсервис (https:// t1.test.ru), который > > крутится на серваке в локалке с адресом 192.168.0.230. > > > > Сейчас При вводе адреса https://t1.test.ru клиент проваливается > > на192.168.0.230. > > Нужна схема с проксированием так, чтобы При вводе адреса > > https://t1.test.ru > > клиент проваливается на192.168.0.43, а затем перенаправлялся на > > 192.168.0.230 > > > > В перспективе будут еще https://t2.test.ru, которые пойдут на > > 192.168.0.232 > > и т.п. > > > > > > ----------------- > > 1. Подскажите какие как быть с сертификатами. Какие из приведённых выше > > прописать в файле конфигурации. > > > > > > > > > > server { > > #listen 80; > > listen 443 ssl default_server; > > listen [::]:443 ssl default_server; > > ssl on; > > ssl_certificate /etc/ssl/test.ru/dcli.ru.ca-bundle; > > #ssl_certificate_key /etc/ssl/test.ru/key.txt; > > #ssl_session_timeout 5m; > > #ssl_protocols TLSv1 TLSv1.1 TLSv1.2; > > #ssl_dhparam /etc/ssl/certs/dhparam.pem; > > #ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH'; > > #ssl_prefer_server_ciphers on; > > #ssl_session_cache shared:SSL:10m; > > > > > > server_name t1.test.ru; > > access_log /var/log/nginx/access.log; > > error_log /var/log/nginx/error.log; > > > > location / { > > proxy_pass https://192.168.0.230; > > } > > } > > > > Posted at Nginx Forum: > > https://forum.nginx.org/read.php?21,291518,291518#msg-291518 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > -- > Best regards, > Andrey A. Kopeyko > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri May 14 14:00:40 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Fri, 14 May 2021 10:00:40 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0L/RgNC10YLQuNGC0Ywg0LTQu9GPIGxvY2F0aW9uIGVy?= =?UTF-8?B?cm9yIHBhZ2VzINC+0L/RgNC10LTQtdC70LXQvdC90YvQtSDQvdCwINGD0YA=?= =?UTF-8?B?0L7QstC90LUgc2VydmVyPw==?= In-Reply-To: <912ecaf8-7223-7dd4-7391-85f7a7ff7a09@ya.ru> References: <912ecaf8-7223-7dd4-7391-85f7a7ff7a09@ya.ru> Message-ID: <20b8b8805a9cbfa8c716954012b70936.NginxMailingListRussian@forum.nginx.org> не могу туда все перенести - нужно если сервис перезапускается ободряющую клиента страницу отдавать на 502ю ошибку Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291519,291522#msg-291522 From nginx-forum на forum.nginx.org Fri May 14 14:38:56 2021 From: nginx-forum на forum.nginx.org (sf2015) Date: Fri, 14 May 2021 10:38:56 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9GB0YLQsNC90L7QstC40YLRjCBSYXBpZCBTU0wgMjAxOA==?= In-Reply-To: References: Message-ID: Сертификат куплен на домен и поддомены. Покупался на nic.ru. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291518,291523#msg-291523 From chipitsine на gmail.com Fri May 14 14:57:31 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 14 May 2021 19:57:31 +0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9GB0YLQsNC90L7QstC40YLRjCBSYXBpZCBTU0wgMjAxOA==?= In-Reply-To: References: Message-ID: сертификат это очень контекстная тема. в момент покупки предполагается, что он будет единственным образом использован - настроен на веб-сервере. nginx входит в пятерку по распространенности. и это очень контекстно, в момент покупки выдать покупателю инструкцию "а использовать купленный сертификат лучше всего вот так (для самых популярных реализаций)" пт, 14 мая 2021 г. в 19:39, sf2015 : > Сертификат куплен на домен и поддомены. Покупался на nic.ru. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,291518,291523#msg-291523 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Fri May 14 15:04:13 2021 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 14 May 2021 18:04:13 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9GB0YLQsNC90L7QstC40YLRjCBSYXBpZCBTU0wgMjAxOA==?= In-Reply-To: References: Message-ID: On Fri, May 14, 2021 at 07:57:31PM +0500, Илья Шипицин wrote: > сертификат это очень контекстная тема. в момент покупки предполагается, > что он будет единственным образом использован - настроен на веб-сервере. > nginx входит в пятерку по распространенности. и это очень контекстно, в > момент покупки выдать покупателю инструкцию "а использовать купленный > сертификат лучше всего вот так (для самых популярных реализаций)" Не скажу насчёт "контекстности", но на nic.ru есть подробнейшие инструкции, в том числе для Nginx. Ткнуть в л/к ссылку на купленный сертификат и промотать вниз, до абзаца "Как установить SSL-сертификат". > пт, 14 мая 2021 г. в 19:39, sf2015 : > Сертификат куплен на домен и поддомены. Покупался на nic.ru. -- Eugene Berdnikov From andrey на kopeyko.ru Fri May 14 15:05:43 2021 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Fri, 14 May 2021 18:05:43 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9GB0YLQsNC90L7QstC40YLRjCBSYXBpZCBTU0wgMjAxOA==?= In-Reply-To: References: Message-ID: sf2015 писал 2021-05-14 17:38: > Сертификат куплен на домен и поддомены. Покупался на nic.ru. У Ру-Центра шикарная и подробная документация по настройке SSL - смотрите на их сайте. (сам писал некоторые её части ;-) -- Best regards, Andrey A. Kopeyko From chipitsine на gmail.com Fri May 14 15:11:51 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 14 May 2021 20:11:51 +0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9GB0YLQsNC90L7QstC40YLRjCBSYXBpZCBTU0wgMjAxOA==?= In-Reply-To: References: Message-ID: пт, 14 мая 2021 г. в 20:04, Evgeniy Berdnikov : > On Fri, May 14, 2021 at 07:57:31PM +0500, Илья Шипицин wrote: > > сертификат это очень контекстная тема. в момент покупки > предполагается, > > что он будет единственным образом использован - настроен на > веб-сервере. > > nginx входит в пятерку по распространенности. и это очень контекстно, > в > > момент покупки выдать покупателю инструкцию "а использовать купленный > > сертификат лучше всего вот так (для самых популярных реализаций)" > > Не скажу насчёт "контекстности", но на nic.ru есть подробнейшие > инструкции, > в том числе для Nginx. Ткнуть в л/к ссылку на купленный сертификат и > промотать вниз, до абзаца "Как установить SSL-сертификат". > контекстность не помешает. в списке файлов - два промежуточных УЦ. я затрудняюсь представить детали, но, было бы логично прямо носом ткнуть "вот мы выдали замудренный сертик с двумя промежуточными УЦ, а вот у нас есть инструкция для этого случая" > > > пт, 14 мая 2021 г. в 19:39, sf2015 : > > Сертификат куплен на домен и поддомены. Покупался на nic.ru. > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From andrey на kopeyko.ru Fri May 14 15:17:24 2021 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Fri, 14 May 2021 18:17:24 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9GB0YLQsNC90L7QstC40YLRjCBSYXBpZCBTU0wgMjAxOA==?= In-Reply-To: References: Message-ID: Илья Шипицин писал 2021-05-14 18:11: > контекстность не помешает. > в списке файлов - два промежуточных УЦ. > я затрудняюсь представить детали, но, > было бы логично прямо носом ткнуть > "вот мы выдали замудренный сертик с > двумя промежуточными УЦ, а вот у нас > есть инструкция для этого случая" А эта инструкция есть на nginx.org - там отдельно расписывается что и как делать ровно в таком случае. Даже shell команды приведены ЕМНИП. -- Best regards, Andrey A. Kopeyko From bgx на protva.ru Fri May 14 15:19:35 2021 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 14 May 2021 18:19:35 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9GB0YLQsNC90L7QstC40YLRjCBSYXBpZCBTU0wgMjAxOA==?= In-Reply-To: References: Message-ID: On Fri, May 14, 2021 at 08:11:51PM +0500, Илья Шипицин wrote: > в списке файлов - два промежуточных УЦ. > я затрудняюсь представить детали, но, было бы логично прямо носом ткнуть > "вот мы выдали замудренный сертик с двумя промежуточными УЦ, а вот у нас > есть инструкция для этого случая" Именно так и есть. Не написано лишь про такую засаду, что некоторые CA (и вроде копеечный RapidSSL среди них) выдают некоторые файлики без перевода строки в конце. Это же просто вай-вай как больно... :) -- Eugene Berdnikov From marck на rinet.ru Fri May 14 20:52:50 2021 From: marck на rinet.ru (Dmitry Morozovsky) Date: Fri, 14 May 2021 23:52:50 +0300 (MSK) Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9GB0YLQsNC90L7QstC40YLRjCBSYXBpZCBTU0wgMjAxOA==?= In-Reply-To: References: Message-ID: On Fri, 14 May 2021, Evgeniy Berdnikov wrote: > On Fri, May 14, 2021 at 08:11:51PM +0500, Илья Шипицин wrote: > > в списке файлов - два промежуточных УЦ. > > я затрудняюсь представить детали, но, было бы логично прямо носом ткнуть > > "вот мы выдали замудренный сертик с двумя промежуточными УЦ, а вот у нас > > есть инструкция для этого случая" > > Именно так и есть. Не написано лишь про такую засаду, что некоторые CA > (и вроде копеечный RapidSSL среди них) выдают некоторые файлики без > перевода строки в конце. Это же просто вай-вай как больно... :) пустые строки игнорируются, так что всё несложно (да, просто cat domain.crt interca.crt subca.crt уже не хватит, но) ну и openssl x509 -noout -text такое должен словить, не помню только какую опцию ему затолкать, чтоб промежуточные проверял -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck на FreeBSD.org ] --------------------------------------------------------------------------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- woozle на woozle.net *** --------------------------------------------------------------------------- From nginx-forum на forum.nginx.org Sat May 15 16:56:45 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Sat, 15 May 2021 12:56:45 -0400 Subject: =?UTF-8?B?0KLQvtC70YzQutC+IGNzcyDQuCBtYW5pZmVzdCDQvdC1INC+0YLQtNCw0Y7RgiBj?= =?UTF-8?B?aGFyc2V0?= Message-ID: <048b9edb5e2eba54195a8cd39c907d74.NginxMailingListRussian@forum.nginx.org> В секции http добавляю charset utf-8 Описываю ресурсы location ~* \.(?:css|js|json|txt)$ { etag on; add_header Cache-Control "public, max-age=31536000, immutable"; } location ~* \.(?:manifest|webmanifest)$ { etag on; add_header Cache-Control "public, max-age=31536000, immutable"; } location ~* \.(?:css|js|json|txt)$ { etag on; expires max; add_header Cache-Control "public, max-age=31536000, immutable"; } все ресурсы (html, js) отдаются с заголовком content-type: ...; charset=utf-8, а css и manifest отдаются без него Почему? как исправить? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291531,291531#msg-291531 From nginx-forum на forum.nginx.org Sun May 16 12:45:19 2021 From: nginx-forum на forum.nginx.org (budarin) Date: Sun, 16 May 2021 08:45:19 -0400 Subject: =?UTF-8?B?UmU6INCi0L7Qu9GM0LrQviBjc3Mg0LggbWFuaWZlc3Qg0L3QtSDQvtGC0LTQsNGO?= =?UTF-8?B?0YIgY2hhcnNldA==?= In-Reply-To: <048b9edb5e2eba54195a8cd39c907d74.NginxMailingListRussian@forum.nginx.org> References: <048b9edb5e2eba54195a8cd39c907d74.NginxMailingListRussian@forum.nginx.org> Message-ID: <54c073a85b8ff23ecc1fd19962a7256b.NginxMailingListRussian@forum.nginx.org> добавление в location для css и manifest инструкции charset utf-8 не приводит к желаемому результату Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291531,291532#msg-291532 From nginx-forum на forum.nginx.org Tue May 18 08:21:48 2021 From: nginx-forum на forum.nginx.org (sf2015) Date: Tue, 18 May 2021 04:21:48 -0400 Subject: =?UTF-8?B?cHJveHkg0LggINC/0LXRgNC40L7QtNC40YfQtdGB0LrQuCBUaW1lT3V0IDQwNQ==?= Message-ID: <77528ab61498d49362c85b0d36f9d2d7.NginxMailingListRussian@forum.nginx.org> Установлен сервер Ubuntu 20.04 со свежим nginx. Nginx настроен в режиме proxy на два внутренних сервера (сервера в локалке) На одном из них очень часто вываливается TimeOut ошибка 504. Почитав инет, добавил в секцию location proxy_connect_timeout location / { proxy_connect_timeout 600; proxy_send_timeout 600; proxy_read_timeout 600; send_timeout 600; proxy_pass http://192.168.0.200; } Теперь через 600 сек (не раньше) вываливается ошибка с TimeOut 504. До ecnfyjdrb nginx сервер 192.168.0.200 работал стабильно без TimeOut. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291543,291543#msg-291543 From nginx-forum на forum.nginx.org Tue May 18 08:23:04 2021 From: nginx-forum на forum.nginx.org (sf2015) Date: Tue, 18 May 2021 04:23:04 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5INC4ICDQv9C10YDQuNC+0LTQuNGH0LXRgdC60LggVGltZU91dCA1?= =?UTF-8?B?MDQ=?= In-Reply-To: <77528ab61498d49362c85b0d36f9d2d7.NginxMailingListRussian@forum.nginx.org> References: <77528ab61498d49362c85b0d36f9d2d7.NginxMailingListRussian@forum.nginx.org> Message-ID: TimeOut 504 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291543,291544#msg-291544 From mdounin на mdounin.ru Tue May 18 13:29:39 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 18 May 2021 16:29:39 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5INC4ICDQv9C10YDQuNC+0LTQuNGH0LXRgdC60LggVGltZU91dCA0?= =?UTF-8?B?MDU=?= In-Reply-To: <77528ab61498d49362c85b0d36f9d2d7.NginxMailingListRussian@forum.nginx.org> References: <77528ab61498d49362c85b0d36f9d2d7.NginxMailingListRussian@forum.nginx.org> Message-ID: Hello! On Tue, May 18, 2021 at 04:21:48AM -0400, sf2015 wrote: > Установлен сервер Ubuntu 20.04 со свежим nginx. > Nginx настроен в режиме proxy на два внутренних сервера (сервера в локалке) > На одном из них очень часто вываливается TimeOut ошибка 504. > > Почитав инет, добавил в секцию location proxy_connect_timeout > > location / { > proxy_connect_timeout 600; > proxy_send_timeout 600; > proxy_read_timeout 600; > send_timeout 600; > proxy_pass http://192.168.0.200; > } > Теперь через 600 сек (не раньше) вываливается ошибка с TimeOut 504. > > До ecnfyjdrb nginx сервер 192.168.0.200 работал стабильно без TimeOut. Ошибка 504 Gateway Timeout означает, что получить ответ от бэкенда за заданное время не удалось. Обычно это означает проблемы с бэкендом или с сетью до него. Я бы начал с того, что проверил, что бэкенд отвечает на запрос, отправленный руками с сервера, на котором работает nginx. Скажем, как-то так: $ curl -v http://192.168.0.200/ Ещё рекомендую заглянуть в лог ошибок nginx'а, там обычно есть дополнительная информация. В частности, в какой момент случается таймаут (в процессе установления соединения или уже после отправки запроса и в процессе ожидания ответа), и какой именно запрос nginx обрабатывал. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue May 18 14:22:57 2021 From: nginx-forum на forum.nginx.org (TheJohnnyMnemonic) Date: Tue, 18 May 2021 10:22:57 -0400 Subject: =?UTF-8?B?0JrQutC40YDQuNC70LvQuNGG0LAg0Lgg0YHQtdGA0YLQuNGE0LjQutCw0YLRiw==?= Message-ID: Добрый день коллеги! Windows/nginx 1.20/php-cgi 7.3.28 + https://github.com/Seb35/nginx-ssl-variables/blob/master/fastcgi_ssl_variables.conf В конфиге присутствует charset utf-8; Настроил использование сертификатов для авторизации, все прекрасно работает. Но при использовании отличных от латиницы символов (читать кириллицы и прочих) в сертификатах (сертификаты сгенерированы OpenSSL 1.1.1k, с параметром utf8), получаем на выходе нечто похожее на quoted printable(в принципе оно и есть, только вместо = используется \). Сертификат https://i.postimg.cc/nrhxC1kn/IvanonII.jpg nginx https://i.postimg.cc/4dZsTGH7/SSL-Ivanov-II.jpg Может я что-то не верно делаю? Или это баг? PS:Апач отображает все пракрасно в utf8 PSs: Так же $ssl_server_name ( fastcgi_param SSL_TLS_SNI $ssl_server_name; ) не возвращает ничего ($server_name возвращает верный параметр), вероятно это тоже баг. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291549,291549#msg-291549 From mdounin на mdounin.ru Tue May 18 15:13:37 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 18 May 2021 18:13:37 +0300 Subject: =?UTF-8?B?UmU6INCa0LrQuNGA0LjQu9C70LjRhtCwINC4INGB0LXRgNGC0LjRhNC40LrQsNGC?= =?UTF-8?B?0Ys=?= In-Reply-To: References: Message-ID: Hello! On Tue, May 18, 2021 at 10:22:57AM -0400, TheJohnnyMnemonic wrote: > Добрый день коллеги! > > Windows/nginx 1.20/php-cgi 7.3.28 > + > https://github.com/Seb35/nginx-ssl-variables/blob/master/fastcgi_ssl_variables.conf > > В конфиге присутствует > charset utf-8; > > Настроил использование сертификатов для авторизации, все прекрасно > работает. > Но при использовании отличных от латиницы символов (читать кириллицы и > прочих) в сертификатах (сертификаты сгенерированы OpenSSL 1.1.1k, с > параметром utf8), получаем на выходе нечто похожее на quoted printable(в > принципе оно и есть, только вместо = используется \). > > Сертификат > https://i.postimg.cc/nrhxC1kn/IvanonII.jpg > > nginx > https://i.postimg.cc/4dZsTGH7/SSL-Ivanov-II.jpg > > > Может я что-то не верно делаю? Или это баг? Выводимые в переменных $ssl_client_s_dn / $ssl_client_i_dn строки экранируются в соответствии с RFC 2253 (см. например описание $ssl_client_s_dn тут: http://nginx.org/r/$ssl_client_s_dn/ru), все символы за пределами ASCII всегда экранируются вне зависимости от наличия в где-либо в конфигурации указаний на используемые для различных целей кодовые страницы. Если вы хотите использовать в сертификатах значения за пределами ASCII и при этом полученные из переменных значения использовать где-то, где удобнее представить, скажем, символы русского языка без экранирования - вы можете снять экранирование самостоятельно. Отмечу, впрочем, что для целей представления данных людям снимать экранирование более чем с одного языка за раз обычно не стоит, это может привести к уязвимостям. > PS:Апач отображает все пракрасно в utf8 > > PSs: Так же $ssl_server_name ( fastcgi_param SSL_TLS_SNI $ssl_server_name; ) > не возвращает ничего ($server_name возвращает верный параметр), вероятно это > тоже баг. На скриншое у вас написано "localhost", так что скорее всего это вы где-то в своих оценках ошиблись. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue May 18 15:49:59 2021 From: nginx-forum на forum.nginx.org (TheJohnnyMnemonic) Date: Tue, 18 May 2021 11:49:59 -0400 Subject: =?UTF-8?B?UmU6INCa0LrQuNGA0LjQu9C70LjRhtCwINC4INGB0LXRgNGC0LjRhNC40LrQsNGC?= =?UTF-8?B?0Ys=?= In-Reply-To: References: Message-ID: <57e2ef8ece8c01833828babc3d3fe3f0.NginxMailingListRussian@forum.nginx.org> Maxim Dounin Wrote: ------------------------------------------------------- > > PSs: Так же $ssl_server_name ( fastcgi_param SSL_TLS_SNI $ssl_server_name; ) > > не возвращает ничего ($server_name возвращает верный параметр), вероятно это тоже баг. > > На скриншое у вас написано "localhost", так что скорее всего это вы где-то в своих оценках ошиблись. На скриншоте использована переменная $server_name (fastcgi_param SSL_TLS_SNI $server_name;). Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291549,291551#msg-291551 From mdounin на mdounin.ru Tue May 18 16:18:45 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 18 May 2021 19:18:45 +0300 Subject: =?UTF-8?B?UmU6INCa0LrQuNGA0LjQu9C70LjRhtCwINC4INGB0LXRgNGC0LjRhNC40LrQsNGC?= =?UTF-8?B?0Ys=?= In-Reply-To: <57e2ef8ece8c01833828babc3d3fe3f0.NginxMailingListRussian@forum.nginx.org> References: <57e2ef8ece8c01833828babc3d3fe3f0.NginxMailingListRussian@forum.nginx.org> Message-ID: Hello! On Tue, May 18, 2021 at 11:49:59AM -0400, TheJohnnyMnemonic wrote: > Maxim Dounin Wrote: > ------------------------------------------------------- > > > PSs: Так же $ssl_server_name ( fastcgi_param SSL_TLS_SNI > $ssl_server_name; ) > > > не возвращает ничего ($server_name возвращает верный параметр), вероятно > это тоже баг. > > > > На скриншое у вас написано "localhost", так что скорее всего это вы где-то > в своих оценках ошиблись. > На скриншоте использована переменная $server_name (fastcgi_param SSL_TLS_SNI > $server_name;). Значит, видимо, ошиблись где-то ещё. Совет: конфигурация вида server { listen 8443 ssl; ssl_certificate ...; ssl_certificate_key ...; return 200 name:$ssl_server_name; } позволяет замечательно протестировать, что именно возвращает переменная. А дальше уже разбираться либо почему в ней пусто (обычно это значит, что вы ходили на IP-адрес, что исключает использование SNI, или воспользовались клиентом, не передающим SNI), либо почему она не долетела до вашего бэкенда. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue May 18 16:41:08 2021 From: nginx-forum на forum.nginx.org (TheJohnnyMnemonic) Date: Tue, 18 May 2021 12:41:08 -0400 Subject: =?UTF-8?B?UmU6INCa0LrQuNGA0LjQu9C70LjRhtCwINC4INGB0LXRgNGC0LjRhNC40LrQsNGC?= =?UTF-8?B?0Ys=?= In-Reply-To: References: Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > On Tue, May 18, 2021 at 11:49:59AM -0400, TheJohnnyMnemonic wrote: > > > Maxim Dounin Wrote: > > ------------------------------------------------------- > > > > PSs: Так же $ssl_server_name ( fastcgi_param SSL_TLS_SNI $ssl_server_name; ) > > > > не возвращает ничего ($server_name возвращает верный параметр), вероятно это тоже баг. > > > > > > На скриншое у вас написано "localhost", так что скорее всего это вы где-то в своих оценках ошиблись. > > На скриншоте использована переменная $server_name (fastcgi_param SSL_TLS_SNI $server_name;). > Значит, видимо, ошиблись где-то ещё. Да, нашел ошибку у себя, спасибо. > Выводимые в переменных $ssl_client_s_dn / $ssl_client_i_dn строки экранируются в соответствии с RFC 2253 (см. например описание $ssl_client_s_dn тут: http://nginx.org/r/$ssl_client_s_dn/ru), все символы за пределами ASCII всегда экранируются вне зависимости от наличия в где-либо в конфигурации указаний на используемые для различных целей кодовые страницы. Планируется ли добавить вывод (опционально) в utf8/Юникод, что бы возможно было конвертировать нативными методами php (без костылей)? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291549,291553#msg-291553 From mdounin на mdounin.ru Tue May 18 18:05:57 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 18 May 2021 21:05:57 +0300 Subject: =?UTF-8?B?UmU6INCa0LrQuNGA0LjQu9C70LjRhtCwINC4INGB0LXRgNGC0LjRhNC40LrQsNGC?= =?UTF-8?B?0Ys=?= In-Reply-To: References: Message-ID: Hello! On Tue, May 18, 2021 at 12:41:08PM -0400, TheJohnnyMnemonic wrote: > > Выводимые в переменных $ssl_client_s_dn / $ssl_client_i_dn строки > > экранируются в соответствии с RFC 2253 (см. например описание > > $ssl_client_s_dn тут: http://nginx.org/r/$ssl_client_s_dn/ru), все символы > > за пределами ASCII всегда экранируются вне зависимости от наличия в где-либо > > в конфигурации указаний на используемые для различных целей кодовые > > страницы. > > Планируется ли добавить вывод (опционально) в utf8/Юникод, что бы возможно > было конвертировать нативными методами php (без костылей)? Нет. Если у вас есть парсер RFC 2253 - то проблем быть не должно, если нет - то для любого корректного использования вам так или иначе понадобится парсер. Парсер при необходимости пишется тривиально, в том числе на PHP, в комментариях к ldap_explode_dn() прогрессивное человечество уже понаписало пучок, разной степени кривости[1]. [1] https://www.php.net/manual/en/function.ldap-explode-dn.php -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue May 18 18:35:22 2021 From: nginx-forum на forum.nginx.org (TheJohnnyMnemonic) Date: Tue, 18 May 2021 14:35:22 -0400 Subject: =?UTF-8?B?UmU6INCa0LrQuNGA0LjQu9C70LjRhtCwINC4INGB0LXRgNGC0LjRhNC40LrQsNGC?= =?UTF-8?B?0Ys=?= In-Reply-To: References: Message-ID: <4a7788acabd49406ceb2a57a6166f5cf.NginxMailingListRussian@forum.nginx.org> Maxim Dounin Wrote: > On Tue, May 18, 2021 at 12:41:08PM -0400, TheJohnnyMnemonic wrote: > > > > Выводимые в переменных $ssl_client_s_dn / $ssl_client_i_dn строки экранируются в соответствии с RFC 2253 (см. например описание $ssl_client_s_dn тут: http://nginx.org/r/$ssl_client_s_dn/ru), все символы за пределами ASCII всегда экранируются вне зависимости от наличия в где-либо в конфигурации указаний на используемые для различных целей кодовые страницы. > > > > Планируется ли добавить вывод (опционально) в utf8/Юникод, что бы возможно было конвертировать нативными методами php (без костылей)? > Нет. Печально, не приходилось бы использовать разные костыли. > > Если у вас есть парсер RFC 2253 - то проблем быть не должно, если нет - то для любого корректного использования вам так или иначе понадобится парсер. Парсер при необходимости пишется тривиально, в том числе на PHP, в комментариях к ldap_explode_dn() прогрессивное человечество уже понаписало пучок, разной степени кривости[1]. > [1] https://www.php.net/manual/en/function.ldap-explode-dn.php Спасибо за ссылку с костылями! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291549,291555#msg-291555 From gmm на csdoc.com Thu May 20 21:05:45 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 21 May 2021 00:05:45 +0300 Subject: Configuring nginx to retry a single upstream server Message-ID: <718a0dba-0a58-b43b-4ace-415ab1641b64@csdoc.com> Здравствуйте, All! Есть nginx, который проксирует запросы на единственный бекенд php-fpm. Во время перезапуска php-fpm клиентам сразу сыпятся 5хх ошибки. Каким образом можно настроить nginx так, чтобы он в случае ошибки связи с бекендом пытался достучаться до него в течении N секунд (например, 30 сек), с интервалом, например, в K секунд (например, 0.1 сек) ? Тогда клиент вместо сообщения про ошибку видел бы просто небольшое замедление ответа сервера на секунду или максимум несколько секунд, что гораздо лучше, чем мгновенный возврат сообщения про ошибку 5хх. Может быть как-то с помощью njs или nginx-module-perl или с помощью ngx_http_upstream_module это можно сделать? Или тут единственно возможный вариант - писать патч на С для решения этой задачи? -- Best regards, Gena From bgx на protva.ru Fri May 21 07:09:02 2021 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 21 May 2021 10:09:02 +0300 Subject: Configuring nginx to retry a single upstream server In-Reply-To: <718a0dba-0a58-b43b-4ace-415ab1641b64@csdoc.com> References: <718a0dba-0a58-b43b-4ace-415ab1641b64@csdoc.com> Message-ID: On Fri, May 21, 2021 at 12:05:45AM +0300, Gena Makhomed wrote: > Есть nginx, который проксирует запросы на единственный бекенд php-fpm. > Во время перезапуска php-fpm клиентам сразу сыпятся 5хх ошибки. > > Каким образом можно настроить nginx так, чтобы он в случае ошибки > связи с бекендом пытался достучаться до него в течении N секунд > (например, 30 сек), с интервалом, например, в K секунд > (например, 0.1 сек) ? > > Тогда клиент вместо сообщения про ошибку видел бы просто небольшое > замедление ответа сервера на секунду или максимум несколько секунд, > что гораздо лучше, чем мгновенный возврат сообщения про ошибку 5хх. Возврат 5xx говорит о том, что либо 1. хост недоступен по сети (возможно, ребутается), по сисколу connect(2) возвращается EHOSTUNREACH. 2. хост доступен, но порт в этот момент не прослушивается, тогда возвращается ECONNREFUSED, 3. приложение возвращает 5xx и nginx форвардит этот ответ клиенту. Ели речь о п.2 и п.3 (перезапуск php-fpm), то это вовсе не ситуация "нет связи с бэкендом", которая п.1. Если же речь о ребуте хоста php-fpm, то либо бэкенд в локальной сети и оказывается недоступен по arp-у, тогда EHOSTUNREACH возвращается после arp-овского таймаута (обычно это 3 секунды), если бэкенд в другой подсети, то обычно шлюз возвращает icmp[host-unreachable] по той же причине, через те же 2-3 секунды. > Может быть как-то с помощью njs или nginx-module-perl или с помощью > ngx_http_upstream_module это можно сделать? Или тут единственно возможный > вариант - писать патч на С для решения этой задачи? Ох... да просто отрубить пакетным фильтром (файрволом) этот бэкенд на время всех манипуляций по перезапуску php-fpm. А когда запустится, открыть обратно. Конечно, proxy_connect_timeout подкрутить. И заскриптовать всё. -- Eugene Berdnikov From gmm на csdoc.com Fri May 21 08:03:47 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 21 May 2021 11:03:47 +0300 Subject: Configuring nginx to retry a single upstream server In-Reply-To: References: <718a0dba-0a58-b43b-4ace-415ab1641b64@csdoc.com> Message-ID: <14d534cd-7245-b5ba-b996-4103cacb405e@csdoc.com> On 21.05.2021 10:09, Evgeniy Berdnikov wrote: >> Есть nginx, который проксирует запросы на единственный бекенд php-fpm. >> Во время перезапуска php-fpm клиентам сразу сыпятся 5хх ошибки. >> >> Каким образом можно настроить nginx так, чтобы он в случае ошибки >> связи с бекендом пытался достучаться до него в течении N секунд >> (например, 30 сек), с интервалом, например, в K секунд >> (например, 0.1 сек) ? >> >> Тогда клиент вместо сообщения про ошибку видел бы просто небольшое >> замедление ответа сервера на секунду или максимум несколько секунд, >> что гораздо лучше, чем мгновенный возврат сообщения про ошибку 5хх. > > Возврат 5xx говорит о том, что либо > > 1. хост недоступен по сети (возможно, ребутается), по сисколу connect(2) > возвращается EHOSTUNREACH. > 2. хост доступен, но порт в этот момент не прослушивается, тогда > возвращается ECONNREFUSED, > 3. приложение возвращает 5xx и nginx форвардит этот ответ клиенту. > > Ели речь о п.2 и п.3 (перезапуск php-fpm), то это вовсе не ситуация > "нет связи с бэкендом", которая п.1. nginx и php-fpm у меня находятся на одном и том же хосте, связь между ними идет через unix domain socket по протоколу fastcgi. Обрабатывать таким образом, через повтор запроса имеет смысл, разумеется, только 502 и 504 статусы на стороне nginx. Если же бекенд вернул 500 ошибку - это внутренняя ошибка бекенда, повтор тут ничем не поможет, эту ошибку надо сразу вернуть клиенту. Возврат 502 бывает в случае такой записи в логах: connect() to unix:/run/php-fpm/www.sock failed (2: No such file or directory) while connecting to upstream Сокет /run/php-fpm/www.sock отсутствует во время перезапуска php-fpm. > Если же речь о ребуте хоста php-fpm, то либо бэкенд в локальной сети и > оказывается недоступен по arp-у, тогда EHOSTUNREACH возвращается после > arp-овского таймаута (обычно это 3 секунды), если бэкенд в другой > подсети, то обычно шлюз возвращает icmp[host-unreachable] по той же > причине, через те же 2-3 секунды. Речь идет о перезапуске php-fpm командой "systemctl restart php-fpm" Если делать "systemctl reload php-fpm" - это не всегра срабатывает, иногда после релоада php-fpm оказывается в нерабочем состоянии, поэтому использую именно "systemctl restart php-fpm" для изменения конфигурации php-fpm, тогда и случаются 502 ошибки с сайтами. Кроме того, иногда, время от времени, бывает еще такая ошибка: upstream timed out (110: Connection timed out) while reading response header from upstream - тогда клиенту возвращается 504 статус. Причину этих таймаутов найти не могу, поэтому и хотелось бы сделать workaround средствами nginx. >> Может быть как-то с помощью njs или nginx-module-perl или с помощью >> ngx_http_upstream_module это можно сделать? Или тут единственно возможный >> вариант - писать патч на С для решения этой задачи? > > Ох... да просто отрубить пакетным фильтром (файрволом) этот бэкенд > на время всех манипуляций по перезапуску php-fpm. А когда запустится, > открыть обратно. Конечно, proxy_connect_timeout подкрутить. > И заскриптовать всё. Там unix domain socket, какой пакетный фильтр может быть? Кроме того, чем поможет отрубать этот бекенд, ведь он единственный? (см. тему: Re: Configuring nginx to retry a single upstream server) Будет точно так же 502 ошибка. А ведь именно этого я и хочу избежать. P.S. Понятное дело, что в случае ддос-атаки это даст amplification, но ддос-атаки можно легко детектировать, например, по количеству запросов в минуту, и если превышен какой-то предел - отключать эту функциональность с повторами запросов и возвращаться к старому поведению, так как это есть сейчас. -- Best regards, Gena From bgx на protva.ru Fri May 21 08:20:55 2021 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 21 May 2021 11:20:55 +0300 Subject: Configuring nginx to retry a single upstream server In-Reply-To: <14d534cd-7245-b5ba-b996-4103cacb405e@csdoc.com> References: <718a0dba-0a58-b43b-4ace-415ab1641b64@csdoc.com> <14d534cd-7245-b5ba-b996-4103cacb405e@csdoc.com> Message-ID: On Fri, May 21, 2021 at 11:03:47AM +0300, Gena Makhomed wrote: > nginx и php-fpm у меня находятся на одном и том же хосте, > связь между ними идет через unix domain socket по протоколу fastcgi. ... > Речь идет о перезапуске php-fpm командой "systemctl restart php-fpm" > Если делать "systemctl reload php-fpm" - это не всегра срабатывает, > иногда после релоада php-fpm оказывается в нерабочем состоянии, > поэтому использую именно "systemctl restart php-fpm" для изменения > конфигурации php-fpm, тогда и случаются 502 ошибки с сайтами. В таком случае, может быть, сконфигурить 2 бэкенда, отличающиеся лишь сокетами (и какими-нибудь pid-файлами), описать их в одном upstream{} и не перезапускать php-fpm, а поднимать 2й и гасить 1й? -- Eugene Berdnikov From chipitsine на gmail.com Fri May 21 08:34:58 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 21 May 2021 13:34:58 +0500 Subject: Configuring nginx to retry a single upstream server In-Reply-To: <718a0dba-0a58-b43b-4ace-415ab1641b64@csdoc.com> References: <718a0dba-0a58-b43b-4ace-415ab1641b64@csdoc.com> Message-ID: есть несколько лайфхаков, которые упрощают жизнь, когда у вас единственный бекенд (но ответа на ваш вопрос у меня нет) 1) можно, и пожалуй, нужно указывать max_fails=0 (чтобы не держать бекенд в грейлисте, а максимально пытаться отправлять на него запросы) 2) можно продублировать бекенд несколько раз, как будто у вас несколько серверов, это позволяет улучшить ситуацию, когда деградировала сеть между балансером и бекендом, тогда timeout while connecting будет переотправлен на якобы следующий бекенд пт, 21 мая 2021 г. в 02:05, Gena Makhomed : > Здравствуйте, All! > > Есть nginx, который проксирует запросы на единственный бекенд php-fpm. > Во время перезапуска php-fpm клиентам сразу сыпятся 5хх ошибки. > > Каким образом можно настроить nginx так, чтобы он в случае ошибки > связи с бекендом пытался достучаться до него в течении N секунд > (например, 30 сек), с интервалом, например, в K секунд > (например, 0.1 сек) ? > > Тогда клиент вместо сообщения про ошибку видел бы просто небольшое > замедление ответа сервера на секунду или максимум несколько секунд, > что гораздо лучше, чем мгновенный возврат сообщения про ошибку 5хх. > > Может быть как-то с помощью njs или nginx-module-perl или с помощью > ngx_http_upstream_module это можно сделать? Или тут единственно > возможный вариант - писать патч на С для решения этой задачи? > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Sat May 22 12:26:36 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Sat, 22 May 2021 15:26:36 +0300 Subject: Configuring nginx to retry a single upstream server In-Reply-To: References: <718a0dba-0a58-b43b-4ace-415ab1641b64@csdoc.com> <14d534cd-7245-b5ba-b996-4103cacb405e@csdoc.com> Message-ID: <902b9927-ac21-24d7-cae4-cae53b3a8d48@csdoc.com> On 21.05.2021 11:20, Evgeniy Berdnikov wrote: >> nginx и php-fpm у меня находятся на одном и том же хосте, >> связь между ними идет через unix domain socket по протоколу fastcgi. > ... >> Речь идет о перезапуске php-fpm командой "systemctl restart php-fpm" >> Если делать "systemctl reload php-fpm" - это не всегра срабатывает, >> иногда после релоада php-fpm оказывается в нерабочем состоянии, >> поэтому использую именно "systemctl restart php-fpm" для изменения >> конфигурации php-fpm, тогда и случаются 502 ошибки с сайтами. > > В таком случае, может быть, сконфигурить 2 бэкенда, отличающиеся лишь > сокетами (и какими-нибудь pid-файлами), описать их в одном upstream{} > и не перезапускать php-fpm, а поднимать 2й и гасить 1й? Да, так работает. Но поднимать на сервере два бэкенда - это - в два раза больше работы. Поэтому очень хочется этой лишней работы избежать и обойтись одним бэкендом. Но скорее всего, средствами nginx этого сделать нельзя. -- Best regards, Gena From red-fox0 на ya.ru Sat May 22 12:31:24 2021 From: red-fox0 на ya.ru (fox) Date: Sat, 22 May 2021 19:31:24 +0700 Subject: Configuring nginx to retry a single upstream server In-Reply-To: <902b9927-ac21-24d7-cae4-cae53b3a8d48@csdoc.com> References: <718a0dba-0a58-b43b-4ace-415ab1641b64@csdoc.com> <14d534cd-7245-b5ba-b996-4103cacb405e@csdoc.com> <902b9927-ac21-24d7-cae4-cae53b3a8d48@csdoc.com> Message-ID: Можете поставить haproxy - он как раз будет держать клиента секунд 10, пока бекэнды перезагружаются. Браузеру придётся ждать эти 10 секунд, но зато он не получит 5хх ошибку. 22.05.2021 19:26, Gena Makhomed пишет: > On 21.05.2021 11:20, Evgeniy Berdnikov wrote: > >>> nginx и php-fpm у меня находятся на одном и том же хосте, >>> связь между ними идет через unix domain socket по протоколу fastcgi. >> ... >>> Речь идет о перезапуске php-fpm командой "systemctl restart php-fpm" >>> Если делать "systemctl reload php-fpm" - это не всегра срабатывает, >>> иногда после релоада php-fpm оказывается в нерабочем состоянии, >>> поэтому использую именно "systemctl restart php-fpm" для изменения >>> конфигурации php-fpm, тогда и случаются 502 ошибки с сайтами. >> >> В таком случае, может быть, сконфигурить 2 бэкенда, отличающиеся лишь >> сокетами (и какими-нибудь pid-файлами), описать их в одном upstream{} >> и не перезапускать php-fpm, а поднимать 2й и гасить 1й? > > Да, так работает. Но поднимать на сервере два бэкенда - > это - в два раза больше работы. Поэтому очень хочется > этой лишней работы избежать и обойтись одним бэкендом. > Но скорее всего, средствами nginx этого сделать нельзя. > From gmm на csdoc.com Sat May 22 12:49:01 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Sat, 22 May 2021 15:49:01 +0300 Subject: Configuring nginx to retry a single upstream server In-Reply-To: References: <718a0dba-0a58-b43b-4ace-415ab1641b64@csdoc.com> <14d534cd-7245-b5ba-b996-4103cacb405e@csdoc.com> <902b9927-ac21-24d7-cae4-cae53b3a8d48@csdoc.com> Message-ID: <95026b44-9035-660c-a826-764bf9b47126@csdoc.com> On 22.05.2021 15:31, fox wrote: > Можете поставить haproxy - он как раз будет держать клиента секунд 10, > пока бекэнды перезагружаются. Браузеру придётся ждать эти 10 секунд, > но зато он не получит 5хх ошибку. Могу поставить haproxy, но haproxy - это не веб-сервер, он не умеет отдавать статику. Значит надо будет использовать одновременно и haproxy и nginx - а это будет примерно в два раза больше работы. Хотелось бы этой лишней работы избежать и обойтись одним только nginx. To: Maxim Dounin: Как я понял, сейчас nginx этого не умеет. Планируется ли в будущем добавить такую функциональность в nginx? -- Best regards, Gena From oleg на mamontov.net Sat May 22 15:22:54 2021 From: oleg на mamontov.net (Oleg A. Mamontov) Date: Sat, 22 May 2021 18:22:54 +0300 Subject: Configuring nginx to retry a single upstream server In-Reply-To: <95026b44-9035-660c-a826-764bf9b47126@csdoc.com> References: <718a0dba-0a58-b43b-4ace-415ab1641b64@csdoc.com> <14d534cd-7245-b5ba-b996-4103cacb405e@csdoc.com> <902b9927-ac21-24d7-cae4-cae53b3a8d48@csdoc.com> <95026b44-9035-660c-a826-764bf9b47126@csdoc.com> Message-ID: <20210522152254.66iw6osq776nmyks@xenon.mamontov.net> On Sat, May 22, 2021 at 03:49:01PM +0300, Gena Makhomed wrote: >On 22.05.2021 15:31, fox wrote: > >>Можете поставить haproxy - он как раз будет держать клиента секунд >>10, пока бекэнды перезагружаются. Браузеру придётся ждать эти 10 >>секунд, >>но зато он не получит 5хх ошибку. > >Могу поставить haproxy, но haproxy - это не веб-сервер, он не умеет >отдавать статику. Значит надо будет использовать одновременно и haproxy >и nginx - а это будет примерно в два раза больше работы. Хотелось бы >этой лишней работы избежать и обойтись одним только nginx. > >To: Maxim Dounin: Как я понял, сейчас nginx этого не умеет. >Планируется ли в будущем добавить такую функциональность в nginx? Функциональность, позволяющая реализовать подобную логику, имеется в коммерческой версии: http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#queue >-- >Best regards, > Gena > >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Cheers, Oleg A. Mamontov From gmm на csdoc.com Sat May 22 18:40:45 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Sat, 22 May 2021 21:40:45 +0300 Subject: Configuring nginx to retry a single upstream server In-Reply-To: <20210522152254.66iw6osq776nmyks@xenon.mamontov.net> References: <718a0dba-0a58-b43b-4ace-415ab1641b64@csdoc.com> <14d534cd-7245-b5ba-b996-4103cacb405e@csdoc.com> <902b9927-ac21-24d7-cae4-cae53b3a8d48@csdoc.com> <95026b44-9035-660c-a826-764bf9b47126@csdoc.com> <20210522152254.66iw6osq776nmyks@xenon.mamontov.net> Message-ID: <930feda4-e710-5281-8896-20d7b4941e1d@csdoc.com> On 22.05.2021 18:22, Oleg A. Mamontov wrote: > Функциональность, позволяющая реализовать подобную логику, > имеется в коммерческой версии: > > http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#queue Хостинг сайтов на PHP - это не тот бизнес, который даст возможность купить коммерческую версию nginx, мы столько денег не зарабатываем. Когда-то параметр max_conns=number директивы server был частью только коммерческой подписки, а потом он стал доступен и в open source версии. Может быть имеет смысл продолжить эту добрую традицию, может быть имеет смысл и директиву queue сделать доступной в open source версии nginx? -- Best regards, Gena From gmm на csdoc.com Sat May 22 22:00:18 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Sun, 23 May 2021 01:00:18 +0300 Subject: How to write $upstream_trailer_{name} into access.log Message-ID: <26bffbdf-eb1d-0089-1d39-7d1fce117da9@csdoc.com> Здравствуйте, All! Использую nginx/1.19.10 из официального репозитория nginx.org На бэкенде в секции http прописал такие директивы: add_trailer X-Response-Time $upstream_response_time always; add_trailer X-Cache-Status $upstream_cache_status always; На фронтенде в секции http прописал proxy_http_version 1.1; Также на фронтенде в директиву log_format добавил переменные: $upstream_trailer_x_response_time $upstream_trailer_x_cache_status Ожидается что в лог будут записаны полученные значения этих переменных, но вместо них в лог пишутся символы - - обозначающие пустые значения. Почему так происходит? Это ошибка в nginx или я что-то делаю не так? -- Best regards, Gena From andrey на kopeyko.ru Sat May 22 22:25:22 2021 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Sun, 23 May 2021 01:25:22 +0300 Subject: How to write $upstream_trailer_{name} into access.log In-Reply-To: <26bffbdf-eb1d-0089-1d39-7d1fce117da9@csdoc.com> References: <26bffbdf-eb1d-0089-1d39-7d1fce117da9@csdoc.com> Message-ID: Gena Makhomed писал 2021-05-23 01:00: > Здравствуйте, All! Добрый день, Геннадий! > Использую nginx/1.19.10 из официального репозитория nginx.org > > На бэкенде в секции http прописал такие директивы: > > add_trailer X-Response-Time $upstream_response_time always; > add_trailer X-Cache-Status $upstream_cache_status always; > > На фронтенде в секции http прописал proxy_http_version 1.1; > Также на фронтенде в директиву log_format добавил переменные: > > $upstream_trailer_x_response_time $upstream_trailer_x_cache_status > > Ожидается что в лог будут записаны полученные значения этих переменных, > но вместо них в лог пишутся символы - - обозначающие пустые значения. > > Почему так происходит? Очевидно, потому что бэкенд _не_ возвращал вам заголовков "trailer-x-response-time: " - вы их сами выдумали. А что вам мешает писать в лог значения $upstream_response_time и $upstream_cache_status из которых вы свои кастомные заголовки строите? > Это ошибка в nginx или я что-то делаю не так? -- Best regards, Andrey A. Kopeyko From gmm на csdoc.com Sat May 22 22:50:54 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Sun, 23 May 2021 01:50:54 +0300 Subject: How to write $upstream_trailer_{name} into access.log In-Reply-To: References: <26bffbdf-eb1d-0089-1d39-7d1fce117da9@csdoc.com> Message-ID: <23934153-06e9-f202-7acb-03864767b570@csdoc.com> On 23.05.2021 1:25, Andrey Kopeyko wrote: > Добрый день, Геннадий! Здравствуйте, Андрей! >> Использую nginx/1.19.10 из официального репозитория nginx.org >> >> На бэкенде в секции http прописал такие директивы: >> >> add_trailer X-Response-Time $upstream_response_time always; >> add_trailer X-Cache-Status $upstream_cache_status always; >> >> На фронтенде в секции http прописал proxy_http_version 1.1; >> Также на фронтенде в директиву log_format добавил переменные: >> >> $upstream_trailer_x_response_time $upstream_trailer_x_cache_status >> >> Ожидается что в лог будут записаны полученные значения этих переменных, >> но вместо них в лог пишутся символы - - обозначающие пустые значения. >> >> Почему так происходит? > > Очевидно, потому что бэкенд _не_ возвращал вам заголовков > "trailer-x-response-time: " - вы их сами выдумали. trailer fields at the end of the message - это не заголовки. Бэкенд эти trailers возвращает, я проверял переменные $sent_trailer_x_response_time $sent_trailer_x_cache_status на бэкенде они имеют не пустые значения и пишутся в лог бэкенда. Подробнее - см. в документации описание переменных $sent_trailer_{name} $upstream_trailer_{name} http://nginx.org/en/docs/varindex.html http://nginx.org/ru/docs/varindex.html > А что вам мешает писать в лог значения $upstream_response_time и > $upstream_cache_status из которых вы свои кастомные заголовки строите? В лог бэкенда я их так и пишу, напрямую, как $upstream_response_time $upstream_cache_status Но хотелось бы эти же самые значения видеть и в логе фронтенда. (Это надо для более эффективной борьбы с DDoS-атаками на сайты) Передать их с бэкенда на фронтенд удобнее всего будет с помощью директивы add_trailer - она у меня больше нигде в конфиге не используется, так что описать эти две директивы можно будет всего один раз на уровне http и они будут работать для всех сайтов. -- Best regards, Gena From andrey на kopeyko.ru Sun May 23 00:57:07 2021 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Sun, 23 May 2021 03:57:07 +0300 Subject: How to write $upstream_trailer_{name} into access.log In-Reply-To: <23934153-06e9-f202-7acb-03864767b570@csdoc.com> References: <26bffbdf-eb1d-0089-1d39-7d1fce117da9@csdoc.com> <23934153-06e9-f202-7acb-03864767b570@csdoc.com> Message-ID: <1b555cc933c2e4b5ced14ede4d5623a0@kopeyko.ru> Gena Makhomed писал 2021-05-23 01:50: > On 23.05.2021 1:25, Andrey Kopeyko wrote: > >> Добрый день, Геннадий! > > Здравствуйте, Андрей! > >>> Использую nginx/1.19.10 из официального репозитория nginx.org >>> >>> На бэкенде в секции http прописал такие директивы: >>> >>> add_trailer X-Response-Time $upstream_response_time always; >>> add_trailer X-Cache-Status $upstream_cache_status always; >>> >>> На фронтенде в секции http прописал proxy_http_version 1.1; >>> Также на фронтенде в директиву log_format добавил переменные: >>> >>> $upstream_trailer_x_response_time $upstream_trailer_x_cache_status >>> >>> Ожидается что в лог будут записаны полученные значения этих >>> переменных, >>> но вместо них в лог пишутся символы - - обозначающие пустые значения. >>> >>> Почему так происходит? >> >> Очевидно, потому что бэкенд _не_ возвращал вам заголовков >> "trailer-x-response-time: " - вы их сами выдумали. > > trailer fields at the end of the message - это не заголовки. > > Бэкенд эти trailers возвращает, я проверял переменные > > $sent_trailer_x_response_time $sent_trailer_x_cache_status > > на бэкенде они имеют не пустые значения и пишутся в лог бэкенда. Стало понятнее. Предположу, что в переменные $upstream_ они не попадают, т.к. передаются бэкендом _после_ тела ответа, а заголовки nginx ожидает увидеть _до_ тела. -- Best regards, Andrey A. Kopeyko From andrey на kopeyko.ru Sun May 23 01:04:26 2021 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Sun, 23 May 2021 04:04:26 +0300 Subject: How to write $upstream_trailer_{name} into access.log In-Reply-To: <1b555cc933c2e4b5ced14ede4d5623a0@kopeyko.ru> References: <26bffbdf-eb1d-0089-1d39-7d1fce117da9@csdoc.com> <23934153-06e9-f202-7acb-03864767b570@csdoc.com> <1b555cc933c2e4b5ced14ede4d5623a0@kopeyko.ru> Message-ID: <0746e45aa8566dfe466610c1558d2988@kopeyko.ru> Andrey Kopeyko писал 2021-05-23 03:57: > Gena Makhomed писал 2021-05-23 01:50: >> On 23.05.2021 1:25, Andrey Kopeyko wrote: >> >>> Добрый день, Геннадий! >> >> Здравствуйте, Андрей! >> >>>> Использую nginx/1.19.10 из официального репозитория nginx.org >>>> >>>> На бэкенде в секции http прописал такие директивы: >>>> >>>> add_trailer X-Response-Time $upstream_response_time always; >>>> add_trailer X-Cache-Status $upstream_cache_status always; >>>> >>>> На фронтенде в секции http прописал proxy_http_version 1.1; >>>> Также на фронтенде в директиву log_format добавил переменные: >>>> >>>> $upstream_trailer_x_response_time $upstream_trailer_x_cache_status >>>> >>>> Ожидается что в лог будут записаны полученные значения этих >>>> переменных, >>>> но вместо них в лог пишутся символы - - обозначающие пустые >>>> значения. >>>> >>>> Почему так происходит? >>> >>> Очевидно, потому что бэкенд _не_ возвращал вам заголовков >>> "trailer-x-response-time: " - вы их сами выдумали. >> >> trailer fields at the end of the message - это не заголовки. >> >> Бэкенд эти trailers возвращает, я проверял переменные >> >> $sent_trailer_x_response_time $sent_trailer_x_cache_status >> >> на бэкенде они имеют не пустые значения и пишутся в лог бэкенда. > > Стало понятнее. > > Предположу, что в переменные $upstream_ они не попадают, т.к. > передаются бэкендом _после_ тела ответа, а заголовки nginx ожидает > увидеть _до_ тела. Наверное, я не прав - судя по документации, они должны "подкладываться" к $upstream_ переменным $upstream_trailer_имя хранит поля из конца ответа, полученного от сервера группы (1.13.10). https://nginx.org/ru/docs/http/ngx_http_upstream_module.html#variables Похоже на багу, раз "не подкладываются". -- Best regards, Andrey A. Kopeyko From mdounin на mdounin.ru Mon May 24 01:19:18 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 24 May 2021 04:19:18 +0300 Subject: How to write $upstream_trailer_{name} into access.log In-Reply-To: <26bffbdf-eb1d-0089-1d39-7d1fce117da9@csdoc.com> References: <26bffbdf-eb1d-0089-1d39-7d1fce117da9@csdoc.com> Message-ID: Hello! On Sun, May 23, 2021 at 01:00:18AM +0300, Gena Makhomed wrote: > Здравствуйте, All! > > Использую nginx/1.19.10 из официального репозитория nginx.org > > На бэкенде в секции http прописал такие директивы: > > add_trailer X-Response-Time $upstream_response_time always; > add_trailer X-Cache-Status $upstream_cache_status always; > > На фронтенде в секции http прописал proxy_http_version 1.1; > Также на фронтенде в директиву log_format добавил переменные: > > $upstream_trailer_x_response_time $upstream_trailer_x_cache_status > > Ожидается что в лог будут записаны полученные значения этих переменных, > но вместо них в лог пишутся символы - - обозначающие пустые значения. > > Почему так происходит? Это ошибка в nginx или я что-то делаю не так? Чтение трейлеров от бэкендов сейчас поддерживается только для gRPC-бэкендов. Если хочется, чтобы работало и для HTTP/1.1 с chunked - присылайте патчи. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Mon May 24 03:05:20 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 24 May 2021 06:05:20 +0300 Subject: Configuring nginx to retry a single upstream server In-Reply-To: <95026b44-9035-660c-a826-764bf9b47126@csdoc.com> References: <718a0dba-0a58-b43b-4ace-415ab1641b64@csdoc.com> <14d534cd-7245-b5ba-b996-4103cacb405e@csdoc.com> <902b9927-ac21-24d7-cae4-cae53b3a8d48@csdoc.com> <95026b44-9035-660c-a826-764bf9b47126@csdoc.com> Message-ID: Hello! On Sat, May 22, 2021 at 03:49:01PM +0300, Gena Makhomed wrote: > On 22.05.2021 15:31, fox wrote: > > > Можете поставить haproxy - он как раз будет держать клиента секунд 10, > > пока бекэнды перезагружаются. Браузеру придётся ждать эти 10 секунд, > > но зато он не получит 5хх ошибку. > > Могу поставить haproxy, но haproxy - это не веб-сервер, он не умеет > отдавать статику. Значит надо будет использовать одновременно и haproxy > и nginx - а это будет примерно в два раза больше работы. Хотелось бы > этой лишней работы избежать и обойтись одним только nginx. > > To: Maxim Dounin: Как я понял, сейчас nginx этого не умеет. > Планируется ли в будущем добавить такую функциональность в nginx? Если это зачем-то надо - то это можно сделать с помощью конфигурации, error_page + delay + повторное обращение к тому же бэкенду. Но вообще если перезапуск php-бэкенда под боевой нагрузкой считается нормальным рабочим действием, то браузер так или иначе имеет шанс получить неполный ответ же. Пытаться в подобной ситуации ещё и ошибки обрабатывать - как по мне, выглядит излишним. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Mon May 24 03:40:35 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 24 May 2021 08:40:35 +0500 Subject: How to write $upstream_trailer_{name} into access.log In-Reply-To: References: <26bffbdf-eb1d-0089-1d39-7d1fce117da9@csdoc.com> Message-ID: Из документации как это понять On Mon, May 24, 2021, 6:19 AM Maxim Dounin wrote: > Hello! > > On Sun, May 23, 2021 at 01:00:18AM +0300, Gena Makhomed wrote: > > > Здравствуйте, All! > > > > Использую nginx/1.19.10 из официального репозитория nginx.org > > > > На бэкенде в секции http прописал такие директивы: > > > > add_trailer X-Response-Time $upstream_response_time always; > > add_trailer X-Cache-Status $upstream_cache_status always; > > > > На фронтенде в секции http прописал proxy_http_version 1.1; > > Также на фронтенде в директиву log_format добавил переменные: > > > > $upstream_trailer_x_response_time $upstream_trailer_x_cache_status > > > > Ожидается что в лог будут записаны полученные значения этих переменных, > > но вместо них в лог пишутся символы - - обозначающие пустые значения. > > > > Почему так происходит? Это ошибка в nginx или я что-то делаю не так? > > Чтение трейлеров от бэкендов сейчас поддерживается только для > gRPC-бэкендов. Если хочется, чтобы работало и для HTTP/1.1 с > chunked - присылайте патчи. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Tue May 25 08:07:38 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 25 May 2021 11:07:38 +0300 Subject: How to write $upstream_trailer_{name} into access.log In-Reply-To: References: <26bffbdf-eb1d-0089-1d39-7d1fce117da9@csdoc.com> Message-ID: <09c22132-2805-adfe-6bed-534b570e218a@csdoc.com> On 24.05.2021 4:19, Maxim Dounin wrote: >> add_trailer X-Response-Time $upstream_response_time always; >> add_trailer X-Cache-Status $upstream_cache_status always; > Чтение трейлеров от бэкендов сейчас поддерживается только для > gRPC-бэкендов. Если хочется, чтобы работало и для HTTP/1.1 > с chunked - присылайте патчи. У trailers есть один существенный недостаток - они отсутствуют в ответах, состоящих из одних только заголовков, например, в ответах на HEAD-запросы. Поэтому trailers мне не подходят. Если использовать вариант: add_header X-Cache-Status $upstream_cache_status always; add_header X-Response-Time $upstream_header_time always; $upstream_header_time примерно равно $upstream_response_time, для большинства обычных сайтов, кроме того - эти два заголовка будуть присутствовать в ответах бэкенда всегда, даже для ответов на HEAD-запросы. Это есть примерно то, чего и хотелось получить. Остается только одна небольшая проблема - если в server или в location присутствуют свои директивы add_header, то там надо будет продублировать вручную эти две директивы add_header с уровня http. Можно ли добавить в nginx директиву, например, force_add_header, которая будет почти во всем аналогична директиве add_header, но только директива add_header не будет отменять действие директивы force_add_header, а директива force_add_header не будет отменять действие директивы add_header. В случае коллизии - одно и то же имя заголовка задается и директивой force_add_header и директивой add_header в каком-то location - тогда пишется warning во время тестирования конфигурации и действует только директива force_add_header, два заголовка с одним и тем же именем не добавляются в ответ сервера. Тогда можно было бы всего один раз на уровне http прописать force_add_header X-Cache-Status $upstream_cache_status always; force_add_header X-Response-Time $upstream_header_time always; и тогда в каждом ответе бэкенда присутствовали бы эти два заголовка, вне зависимости от того, где в server или в location встречаются директивы add_header и в каком количестве. Это было бы очень удобно. -- Best regards, Gena From gmm на csdoc.com Tue May 25 09:15:54 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 25 May 2021 12:15:54 +0300 Subject: Configuring nginx to retry a single upstream server In-Reply-To: References: <718a0dba-0a58-b43b-4ace-415ab1641b64@csdoc.com> <14d534cd-7245-b5ba-b996-4103cacb405e@csdoc.com> <902b9927-ac21-24d7-cae4-cae53b3a8d48@csdoc.com> <95026b44-9035-660c-a826-764bf9b47126@csdoc.com> Message-ID: <09ed43c5-ed49-f601-192d-11b4ced59dc3@csdoc.com> On 24.05.2021 6:05, Maxim Dounin wrote: >>> Можете поставить haproxy - он как раз будет держать клиента секунд 10, >>> пока бекэнды перезагружаются. Браузеру придётся ждать эти 10 секунд, >>> но зато он не получит 5хх ошибку. >> >> Могу поставить haproxy, но haproxy - это не веб-сервер, он не умеет >> отдавать статику. Значит надо будет использовать одновременно и haproxy >> и nginx - а это будет примерно в два раза больше работы. Хотелось бы >> этой лишней работы избежать и обойтись одним только nginx. >> >> To: Maxim Dounin: Как я понял, сейчас nginx этого не умеет. >> Планируется ли в будущем добавить такую функциональность в nginx? > > Если это зачем-то надо - то это можно сделать с помощью > конфигурации, error_page + delay + повторное обращение к тому же > бэкенду. Каким образом можно сделать delay обработки запроса в nginx? И если надо будет сделать timeout в 10 секунд с интервалом между попытками обращения к бэкенду в 1 секунду - это надо будет описать 10 различных locations в конфигурации nginx? > Но вообще если перезапуск php-бэкенда под боевой нагрузкой > считается нормальным рабочим действием, то браузер так или иначе > имеет шанс получить неполный ответ же. Пытаться в подобной > ситуации ещё и ошибки обрабатывать - как по мне, выглядит > излишним. Это не обязательно может быть перезапуск php-бэкенда под боевой нагрузкой, может быть и просто временная деградация сети между nginx-фронтендом и бэкендом. Есть ли шансы, что директива queue появится в open source версии nginx? -- Best regards, Gena From bgx на protva.ru Tue May 25 10:17:57 2021 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Tue, 25 May 2021 13:17:57 +0300 Subject: Configuring nginx to retry a single upstream server In-Reply-To: <09ed43c5-ed49-f601-192d-11b4ced59dc3@csdoc.com> References: <718a0dba-0a58-b43b-4ace-415ab1641b64@csdoc.com> <14d534cd-7245-b5ba-b996-4103cacb405e@csdoc.com> <902b9927-ac21-24d7-cae4-cae53b3a8d48@csdoc.com> <95026b44-9035-660c-a826-764bf9b47126@csdoc.com> <09ed43c5-ed49-f601-192d-11b4ced59dc3@csdoc.com> Message-ID: <20210525101757.GE2751@protva.ru> On Tue, May 25, 2021 at 12:15:54PM +0300, Gena Makhomed wrote: > >Но вообще если перезапуск php-бэкенда под боевой нагрузкой > >считается нормальным рабочим действием, то браузер так или иначе > >имеет шанс получить неполный ответ же. Пытаться в подобной > >ситуации ещё и ошибки обрабатывать - как по мне, выглядит > >излишним. > > Это не обязательно может быть перезапуск php-бэкенда > под боевой нагрузкой, может быть и просто временная > деградация сети между nginx-фронтендом и бэкендом. Временная деградация сети приводит к ретрансмиссиям пакетов, это делается ядром ОС и процесс неуправляем со стороны пользователя, за исключением общего таймаута. А если таймаут не достигнут, то 500-х ошибок от деградации сети не может быть. К тому же изначально речь шла о unix-сокетах, там совершенно иные правила игры. -- Eugene Berdnikov From mdounin на mdounin.ru Tue May 25 12:01:49 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 25 May 2021 15:01:49 +0300 Subject: How to write $upstream_trailer_{name} into access.log In-Reply-To: <09c22132-2805-adfe-6bed-534b570e218a@csdoc.com> References: <26bffbdf-eb1d-0089-1d39-7d1fce117da9@csdoc.com> <09c22132-2805-adfe-6bed-534b570e218a@csdoc.com> Message-ID: Hello! On Tue, May 25, 2021 at 11:07:38AM +0300, Gena Makhomed wrote: [...] > Остается только одна небольшая проблема - если в server или в location > присутствуют свои директивы add_header, то там надо будет продублировать > вручную эти две директивы add_header с уровня http. Традиционное решение - использовать include-файл со "стандартными" заголовками, и при необходимости включать его там, где нужно не переопределить, а дополнить добавляемые заголовки. > Можно ли добавить в nginx директиву, например, force_add_header, > которая будет почти во всем аналогична директиве add_header, > но только директива add_header не будет отменять действие > директивы force_add_header, а директива force_add_header > не будет отменять действие директивы add_header. > > В случае коллизии - одно и то же имя заголовка задается > и директивой force_add_header и директивой add_header > в каком-то location - тогда пишется warning во время > тестирования конфигурации и действует только директива > force_add_header, два заголовка с одним и тем же именем > не добавляются в ответ сервера. Нет, нельзя. Возможно, когда-нибудь добавится концепция "явно унаследовать список с предыдущего уровня и дать возможность дополнить его", что-нибудь вроде add_header inherit; add_header Foo bar; Что по сути аналогично использованию include-файла, но чуть проще синтаксически. Но это, скажем так, очень абстрактная идея, реализация которой под очень большим вопросом. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue May 25 12:15:33 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 25 May 2021 15:15:33 +0300 Subject: Configuring nginx to retry a single upstream server In-Reply-To: <09ed43c5-ed49-f601-192d-11b4ced59dc3@csdoc.com> References: <718a0dba-0a58-b43b-4ace-415ab1641b64@csdoc.com> <14d534cd-7245-b5ba-b996-4103cacb405e@csdoc.com> <902b9927-ac21-24d7-cae4-cae53b3a8d48@csdoc.com> <95026b44-9035-660c-a826-764bf9b47126@csdoc.com> <09ed43c5-ed49-f601-192d-11b4ced59dc3@csdoc.com> Message-ID: Hello! On Tue, May 25, 2021 at 12:15:54PM +0300, Gena Makhomed wrote: > On 24.05.2021 6:05, Maxim Dounin wrote: > > >>> Можете поставить haproxy - он как раз будет держать клиента секунд 10, > >>> пока бекэнды перезагружаются. Браузеру придётся ждать эти 10 секунд, > >>> но зато он не получит 5хх ошибку. > >> > >> Могу поставить haproxy, но haproxy - это не веб-сервер, он не умеет > >> отдавать статику. Значит надо будет использовать одновременно и haproxy > >> и nginx - а это будет примерно в два раза больше работы. Хотелось бы > >> этой лишней работы избежать и обойтись одним только nginx. > >> > >> To: Maxim Dounin: Как я понял, сейчас nginx этого не умеет. > >> Планируется ли в будущем добавить такую функциональность в nginx? > > > > Если это зачем-то надо - то это можно сделать с помощью > > конфигурации, error_page + delay + повторное обращение к тому же > > бэкенду. > > Каким образом можно сделать delay обработки запроса в nginx? Есть более одного способа, из штатного - задержки умеют делать limit_req (но время контролируется плохо), perl и njs. Из нештатного - лет десять назад я сделал простой модуль для этого, и с тех пор пользуюсь регулярно: http://mdounin.ru/hg/ngx_http_delay_module/ Возможно затащим в базу. [...] > Есть ли шансы, что директива queue появится в open source версии nginx? Я бы на это не рассчитывал. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Tue May 25 13:42:29 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 25 May 2021 16:42:29 +0300 Subject: add_header In-Reply-To: References: <26bffbdf-eb1d-0089-1d39-7d1fce117da9@csdoc.com> <09c22132-2805-adfe-6bed-534b570e218a@csdoc.com> Message-ID: <03bdff7d-3bb1-d643-b039-018c305c2cad@csdoc.com> On 25.05.2021 15:01, Maxim Dounin wrote: > Возможно, когда-нибудь добавится концепция "явно унаследовать > список с предыдущего уровня и дать возможность дополнить его", > что-нибудь вроде > > add_header inherit; > add_header Foo bar; > > Что по сути аналогично использованию include-файла, но чуть проще > синтаксически. Но это, скажем так, очень абстрактная идея, > реализация которой под очень большим вопросом. Кроме add_header аналогичные проблемы и с директивой proxy_set_header Может быть имеет смысл сделать новую директиву join с помощью которой и регулировать объединение или отмену обединения для других директив? Syntax: join on|off; Context: http, server, location, if in location По умолчанию: join add_header off; join proxy_set_header off; Например, на уровне http объединение может быть включено, а на уровне какого-то конкретного location - явно выключено, при необходимости. Кроме директивы add_header было бы удобно иметь директиву set_header, которая не добавляет новый заголовок, а переопределяет, если заголовок с таким именем уже был определен ранее, в режиме join add_header on; -- Best regards, Gena From chipitsine на gmail.com Tue May 25 13:53:18 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 25 May 2021 18:53:18 +0500 Subject: add_header In-Reply-To: <03bdff7d-3bb1-d643-b039-018c305c2cad@csdoc.com> References: <26bffbdf-eb1d-0089-1d39-7d1fce117da9@csdoc.com> <09c22132-2805-adfe-6bed-534b570e218a@csdoc.com> <03bdff7d-3bb1-d643-b039-018c305c2cad@csdoc.com> Message-ID: вт, 25 мая 2021 г. в 18:42, Gena Makhomed : > On 25.05.2021 15:01, Maxim Dounin wrote: > > > Возможно, когда-нибудь добавится концепция "явно унаследовать > > список с предыдущего уровня и дать возможность дополнить его", > > что-нибудь вроде > > > > add_header inherit; > > add_header Foo bar; > > > > Что по сути аналогично использованию include-файла, но чуть проще > > синтаксически. Но это, скажем так, очень абстрактная идея, > > реализация которой под очень большим вопросом. > > Кроме add_header аналогичные проблемы и с директивой proxy_set_header > > Может быть имеет смысл сделать новую директиву join с помощью которой > и регулировать объединение или отмену обединения для других директив? > > Syntax: join on|off; > Context: http, server, location, if in location > > По умолчанию: > > join add_header off; > > join proxy_set_header off; > > Например, на уровне http объединение может быть включено, а на уровне > какого-то конкретного location - явно выключено, при необходимости. > > Кроме директивы add_header было бы удобно иметь директиву set_header, > которая не добавляет новый заголовок, а переопределяет, если заголовок > с таким именем уже был определен ранее, в режиме join add_header on; > какой глубинный смысл усложнения парсинга конфигов ? вы ведь не руками конфиг делаете. скорее всего у вас есть некий DSL поверх. из которого вы можете делать любое представление, с учетом примитивного и дуракоупорного поведение нижележащих слоев > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue May 25 14:48:47 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 25 May 2021 17:48:47 +0300 Subject: add_header In-Reply-To: <03bdff7d-3bb1-d643-b039-018c305c2cad@csdoc.com> References: <26bffbdf-eb1d-0089-1d39-7d1fce117da9@csdoc.com> <09c22132-2805-adfe-6bed-534b570e218a@csdoc.com> <03bdff7d-3bb1-d643-b039-018c305c2cad@csdoc.com> Message-ID: Hello! On Tue, May 25, 2021 at 04:42:29PM +0300, Gena Makhomed wrote: > On 25.05.2021 15:01, Maxim Dounin wrote: > > > Возможно, когда-нибудь добавится концепция "явно унаследовать > > список с предыдущего уровня и дать возможность дополнить его", > > что-нибудь вроде > > > > add_header inherit; > > add_header Foo bar; > > > > Что по сути аналогично использованию include-файла, но чуть проще > > синтаксически. Но это, скажем так, очень абстрактная идея, > > реализация которой под очень большим вопросом. > > Кроме add_header аналогичные проблемы и с директивой proxy_set_header Hint: так ведут себя вообще все директивы. > Может быть имеет смысл сделать новую директиву join с помощью которой > и регулировать объединение или отмену обединения для других директив? Чтобы сделать "объединение" с помощью другой директивы - нужно, чтобы эта директива знала и умела работать со всеми директивами, которые она должна уметь объединять. Такой самолёт не полетит по очевидным причинам. [...] -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue May 25 15:37:26 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 25 May 2021 18:37:26 +0300 Subject: nginx-1.21.0 Message-ID: Изменения в nginx 1.21.0 25.05.2021 *) Безопасность: при использовании директивы resolver во время обработки ответа DNS-сервера могла происходить перезапись одного байта памяти, что позволяло атакующему, имеющему возможность подделывать UDP-пакеты от DNS-сервера, вызвать падение рабочего процесса или, потенциально, выполнение произвольного кода (CVE-2021-23017). *) Добавление: директивы proxy_ssl_certificate, proxy_ssl_certificate_key, grpc_ssl_certificate, grpc_ssl_certificate_key, uwsgi_ssl_certificate и uwsgi_ssl_certificate_key поддерживают переменные. *) Добавление: директива max_errors в почтовом прокси-сервере. *) Добавление: почтовый прокси-сервер поддерживает POP3 и IMAP pipelining. *) Добавление: параметр fastopen директивы listen в модуле stream. Спасибо Anbang Wen. *) Исправление: специальные символы не экранировались при автоматическом перенаправлении с добавлением завершающего слэша. *) Исправление: при использовании SMTP pipelining соединения с клиентами в почтовом прокси-сервере могли неожиданно закрываться. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Tue May 25 15:37:56 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 25 May 2021 18:37:56 +0300 Subject: nginx-1.20.1 Message-ID: Изменения в nginx 1.20.1 25.05.2021 *) Безопасность: при использовании директивы resolver во время обработки ответа DNS-сервера могла происходить перезапись одного байта памяти, что позволяло атакующему, имеющему возможность подделывать UDP-пакеты от DNS-сервера, вызвать падение рабочего процесса или, потенциально, выполнение произвольного кода (CVE-2021-23017). -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Tue May 25 15:39:44 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 25 May 2021 18:39:44 +0300 Subject: nginx security advisory (CVE-2021-23017) Message-ID: Hello! В nginx resolver была обнаружена ошибка, которая позволяла с помощью специально созданного DNS-ответа вызвать перезапись одного байта памяти, что в свою очередь могло вызвать крах рабочего процесса, а также потенциально могло приводить к выполнению произвольного кода (CVE-2021-23017). Проблеме подвержен nginx, если директива resolver используется в конфигурационном файле. При этом атака возможна только в случае, если атакующий имеет возможность подделывать UDP-пакеты от DNS-сервера. Проблеме подвержен nginx 0.6.18 - 1.20.0. Проблема исправлена в nginx 1.21.0, 1.20.1. Патч, исправляющий проблему, доступен тут: http://nginx.org/download/patch.2021.resolver.txt Спасибо Luis Merino, Markus Vervier, Eric Sesterhenn, X41 D-Sec GmbH. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Thu May 27 18:25:42 2021 From: nginx-forum на forum.nginx.org (azlk) Date: Thu, 27 May 2021 14:25:42 -0400 Subject: =?UTF-8?B?0JvQvtC60LDQu9C40LfQsNGG0LjRjyBmYW55aW5kZXg=?= Message-ID: <4c824a9e638f928f385dd8d9ff61d40a.NginxMailingListRussian@forum.nginx.org> Может быть, вопрос всем настолько очевиден, что в поиске о нём ничего нигде не удалось найти.. У меня есть каталог, выставленный для свободного скачивания файлов, причёсан с помощью fancyindex. Всё прекрасно, но мне бы хотелось, чтобы линки Parent directory, а также названия колонок File Name, File Size, Date были бы по-русски. Можно ли это сделать и если да, то как? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291670,291670#msg-291670 From nginx-forum на forum.nginx.org Thu May 27 18:33:18 2021 From: nginx-forum на forum.nginx.org (azlk) Date: Thu, 27 May 2021 14:33:18 -0400 Subject: =?UTF-8?B?0JXRidC1INCy0L7Qv9GA0L7RgSDQv9C+IGZhbmN5aW5kZXg=?= Message-ID: <1b2d8dabf763f46108fcea69220c2255.NginxMailingListRussian@forum.nginx.org> Можно ли сделать breadcrums в fancyindex и как? Чтобы в заголовке было видно, где мы находимся? p.s. не ругайтесь, только начинаю разбираться и не смог найти ответов... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291671,291671#msg-291671 From nginx-forum на forum.nginx.org Thu May 27 18:38:28 2021 From: nginx-forum на forum.nginx.org (azlk) Date: Thu, 27 May 2021 14:38:28 -0400 Subject: =?UTF-8?B?UmU6INCV0YnQtSDQstC+0L/RgNC+0YEg0L/QviBmYW5jeWluZGV4?= In-Reply-To: <1b2d8dabf763f46108fcea69220c2255.NginxMailingListRussian@forum.nginx.org> References: <1b2d8dabf763f46108fcea69220c2255.NginxMailingListRussian@forum.nginx.org> Message-ID: дополню: я хотел обойтись без скриптов, чтобы все быстрее работало, и (в основном) потому, что я не знаю ни php ни чего-то другого :( Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291671,291672#msg-291672