From nginx-forum на forum.nginx.org Tue Oct 2 03:15:39 2018 From: nginx-forum на forum.nginx.org (RekGRpth) Date: Mon, 01 Oct 2018 23:15:39 -0400 Subject: =?UTF-8?B?0JzQvtC20L3QviDQu9C4INCyIG5naW54INGB0L7Qt9C00LDRgtGMINC30LDQv9GA?= =?UTF-8?B?0L7RgT8=?= Message-ID: Имеются два модуля nginx: один работает с веб-сокетами, а второй с базой данных постгрес. Чтобы отправить сообщение в веб-сокет - надо выполнить запрос на определённый location (первого модуля) Второй же модуль может получать от базы асинхронные уведомления (listen/notify) И теперь надо как-то при получении асинхронного уведомления во втором модуле как-то создать запрос, который вызовет location первого модуля, чтобы тот отправил данные в веб-сокет Можно ли это как-то сделать? В какую сторону копать? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281468,281468#msg-281468 From raven_kg на megaline.kg Tue Oct 2 12:11:53 2018 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Tue, 2 Oct 2018 18:11:53 +0600 Subject: =?UTF-8?B?0J3QtdCy0L7Qt9C80L7QttC90L4g0L7RgtC60LvRjtGH0LjRgtGMIGh0dHAy?= Message-ID: Приветствую! Потребовалось отключить http2 для всех хостов, убрал из всех listen упоминания http2, перезапустил nginx. В логах так и продолжают сыпаться запросы HTTP/2.0. Чем может быть обусловлено такое поведение? # nginx -V nginx version: nginx/1.14.0 built with LibreSSL 2.7.4 TLS SNI support enabled configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error_log --http-log-path=/var/log/nginx/access_log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-file-aio --with-threads --with-http_ssl_module --with-http_v2_module --with-http_v2_hpack_enc --with-http_realip_module --with-http_addition_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_slice_module --with-http_stub_status_module --with-http_perl_module=dynamic --with-mail=dynamic --with-mail_ssl_module --with-pcre --with-pcre-jit --with-stream=dynamic --with-stream_ssl_module --with-google_perftools_module --with-debug --add-dynamic-module=headers-more-nginx-module-0.32 --add-dynamic-module=ngx_devel_kit-0.3.1rc1 --add-dynamic-module=lua-nginx-module-0.10.13 --add-dynamic-module=nginx-eval-module-master --add-dynamic-module=ngx_brotli --with-ld-opt='-lcrypto -lssl -ltls -L/opt/libressl/lib -Wl,-rpath=/opt/libressl/lib -lrt -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-E' --with-cc-opt='-DNGX_LUA_ABORT_AT_PANIC -I/opt/libressl/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -DTCP_FASTOPEN=23' From mdounin на mdounin.ru Tue Oct 2 12:32:02 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 2 Oct 2018 15:32:02 +0300 Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC+0YLQutC70Y7Rh9C40YLRjCBodHRw?= =?UTF-8?B?Mg==?= In-Reply-To: References: Message-ID: <20181002123201.GB56558@mdounin.ru> Hello! On Tue, Oct 02, 2018 at 06:11:53PM +0600, raven_kg на megaline.kg wrote: > Потребовалось отключить http2 для всех хостов, убрал из всех listen > упоминания http2, перезапустил nginx. В логах так и продолжают сыпаться > запросы HTTP/2.0. Чем может быть обусловлено такое поведение? Наиболее вероятна одна из двух причин: - из какой-то директивы listen параметр http2 не убран, и соответственно HTTP/2 используется для данного listen-сокета. - nginx продолжает работать со старой конфигурацией - такое может быть, например, если под "перезапустил nginx" подразумевается reload, и новую конфигурацию применить не удалось (подробности будут в логе ошибок). -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Oct 2 15:29:06 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 2 Oct 2018 18:29:06 +0300 Subject: nginx-1.15.5 Message-ID: <20181002152906.GK56558@mdounin.ru> Изменения в nginx 1.15.5 02.10.2018 *) Исправление: при использовании OpenSSL 1.1.0h и новее в рабочем процессе мог произойти segmentation fault; ошибка появилась в 1.15.4. *) Исправление: незначительных потенциальных ошибок. -- Maxim Dounin http://nginx.org/ From self на alaz.me Wed Oct 3 05:10:13 2018 From: self на alaz.me (Alexander Azarov) Date: Wed, 3 Oct 2018 08:10:13 +0300 Subject: =?UTF-8?B?bWlycm9yINGC0L7Qu9GM0LrQviAqX3Bhc3M=?= Message-ID: Здравствуйте! У меня вопрос про mirror. Он у меня срабатывает, только если в локейшне есть proxy_pass. Если там rewrite..redirect или return, то подзапрос не случается, в логе совсем пусто (даже в debug логе). Так и должно быть? Если да, то может быть имеет смысл что-то в лог писать, а то нелогично как-то получается, директива в конфиге есть, а действия никакого нет. Версию nginx и конфиг прикладываю ниже. С уважением, Александр nginx version: nginx/1.15.4 configure arguments: --prefix=/opt/local --with-cc-opt='-I/opt/local/include -Os' --with-ld-opt='-L/opt/local/lib -Wl,-headerpad_max_install_names' --conf-path=/opt/local/etc/nginx/nginx.conf --error-log-path=/opt/local/var/log/nginx/error.log --http-log-path=/opt/local/var/log/nginx/access.log --pid-path=/opt/local/var/run/nginx/nginx.pid --lock-path=/opt/local/var/run/nginx/nginx.lock --http-client-body-temp-path=/opt/local/var/run/nginx/client_body_temp --http-proxy-temp-path=/opt/local/var/run/nginx/proxy_temp --http-fastcgi-temp-path=/opt/local/var/run/nginx/fastcgi_temp --http-uwsgi-temp-path=/opt/local/var/run/nginx/uwsgi_temp --with-debug --with-http_mp4_module --with-stream http { include mime.types; default_type application/octet-stream; log_format stat '[$time_local] $server_port $status "$request" "$uri"'; log_subrequest on; access_log /dev/stdout stat; server { listen 8000 default_server; location /r { mirror /stats; return 200 "OK"; } location = /stats { proxy_pass http://127.0.0.1:8001$uri; } } server { listen 8001 default_server; location /o { return 200 "OK"; } location /stats { return 204; } } } ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Wed Oct 3 05:23:40 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 3 Oct 2018 10:23:40 +0500 Subject: =?UTF-8?B?UmU6IG1pcnJvciDRgtC+0LvRjNC60L4gKl9wYXNz?= In-Reply-To: References: Message-ID: зеркалить на удаленный сервер - понятно зачем. а расскажите, зачем вы зеркалите на локальный (по сути на тот же nginx) ? это выдуманный пример или так реально сделано ? ср, 3 окт. 2018 г. в 10:10, Alexander Azarov : > Здравствуйте! > > У меня вопрос про mirror. Он у меня срабатывает, только если в локейшне > есть proxy_pass. Если там rewrite..redirect или return, то подзапрос не > случается, в логе совсем пусто (даже в debug логе). Так и должно быть? Если > да, то может быть имеет смысл что-то в лог писать, а то нелогично как-то > получается, директива в конфиге есть, а действия никакого нет. > > Версию nginx и конфиг прикладываю ниже. > > С уважением, > Александр > > nginx version: nginx/1.15.4 > > configure arguments: --prefix=/opt/local > --with-cc-opt='-I/opt/local/include -Os' --with-ld-opt='-L/opt/local/lib > -Wl,-headerpad_max_install_names' > --conf-path=/opt/local/etc/nginx/nginx.conf > --error-log-path=/opt/local/var/log/nginx/error.log > --http-log-path=/opt/local/var/log/nginx/access.log > --pid-path=/opt/local/var/run/nginx/nginx.pid > --lock-path=/opt/local/var/run/nginx/nginx.lock > --http-client-body-temp-path=/opt/local/var/run/nginx/client_body_temp > --http-proxy-temp-path=/opt/local/var/run/nginx/proxy_temp > --http-fastcgi-temp-path=/opt/local/var/run/nginx/fastcgi_temp > --http-uwsgi-temp-path=/opt/local/var/run/nginx/uwsgi_temp --with-debug > --with-http_mp4_module --with-stream > > http { > > include mime.types; > > default_type application/octet-stream; > > > log_format stat '[$time_local] $server_port $status "$request" "$uri"'; > > log_subrequest on; > > access_log /dev/stdout stat; > > > server { > > listen 8000 default_server; > > > location /r { > > mirror /stats; > > return 200 "OK"; > > } > > > location = /stats { > > proxy_pass http://127.0.0.1:8001$uri; > > } > > } > > > server { > > listen 8001 default_server; > > > location /o { > > return 200 "OK"; > > } > > > location /stats { > > return 204; > > } > > } > > } > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From self на alaz.me Wed Oct 3 05:26:40 2018 From: self на alaz.me (Alexander Azarov) Date: Wed, 3 Oct 2018 08:26:40 +0300 Subject: =?UTF-8?B?UmU6IG1pcnJvciDRgtC+0LvRjNC60L4gKl9wYXNz?= In-Reply-To: References: Message-ID: Да, выдуманный конечно же. Я искал проблему и собрал два минимальных примера – рабочий (с proxy_pass) и нерабочий, который Вы видели (у меня там лишний локейшн /o завалялся от предыдущего). ср, 3 окт. 2018 г. в 8:23, Илья Шипицин : > зеркалить на удаленный сервер - понятно зачем. > а расскажите, зачем вы зеркалите на локальный (по сути на тот же nginx) ? > > это выдуманный пример или так реально сделано ? > > ср, 3 окт. 2018 г. в 10:10, Alexander Azarov : > >> Здравствуйте! >> >> У меня вопрос про mirror. Он у меня срабатывает, только если в локейшне >> есть proxy_pass. Если там rewrite..redirect или return, то подзапрос не >> случается, в логе совсем пусто (даже в debug логе). Так и должно быть? Если >> да, то может быть имеет смысл что-то в лог писать, а то нелогично как-то >> получается, директива в конфиге есть, а действия никакого нет. >> >> Версию nginx и конфиг прикладываю ниже. >> >> С уважением, >> Александр >> >> nginx version: nginx/1.15.4 >> >> configure arguments: --prefix=/opt/local >> --with-cc-opt='-I/opt/local/include -Os' --with-ld-opt='-L/opt/local/lib >> -Wl,-headerpad_max_install_names' >> --conf-path=/opt/local/etc/nginx/nginx.conf >> --error-log-path=/opt/local/var/log/nginx/error.log >> --http-log-path=/opt/local/var/log/nginx/access.log >> --pid-path=/opt/local/var/run/nginx/nginx.pid >> --lock-path=/opt/local/var/run/nginx/nginx.lock >> --http-client-body-temp-path=/opt/local/var/run/nginx/client_body_temp >> --http-proxy-temp-path=/opt/local/var/run/nginx/proxy_temp >> --http-fastcgi-temp-path=/opt/local/var/run/nginx/fastcgi_temp >> --http-uwsgi-temp-path=/opt/local/var/run/nginx/uwsgi_temp --with-debug >> --with-http_mp4_module --with-stream >> >> http { >> >> include mime.types; >> >> default_type application/octet-stream; >> >> >> log_format stat '[$time_local] $server_port $status "$request" "$uri"'; >> >> log_subrequest on; >> >> access_log /dev/stdout stat; >> >> >> server { >> >> listen 8000 default_server; >> >> >> location /r { >> >> mirror /stats; >> >> return 200 "OK"; >> >> } >> >> >> location = /stats { >> >> proxy_pass http://127.0.0.1:8001$uri; >> >> } >> >> } >> >> >> server { >> >> listen 8001 default_server; >> >> >> location /o { >> >> return 200 "OK"; >> >> } >> >> >> location /stats { >> >> return 204; >> >> } >> >> } >> >> } >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From arut на nginx.com Wed Oct 3 07:10:58 2018 From: arut на nginx.com (Roman Arutyunyan) Date: Wed, 3 Oct 2018 10:10:58 +0300 Subject: =?UTF-8?B?UmU6IG1pcnJvciDRgtC+0LvRjNC60L4gKl9wYXNz?= In-Reply-To: References: Message-ID: <20181003071058.GB62311@Romans-MacBook-Air.local> Добрый день, Александр. On Wed, Oct 03, 2018 at 08:10:13AM +0300, Alexander Azarov wrote: > Здравствуйте! > > У меня вопрос про mirror. Он у меня срабатывает, только если в локейшне > есть proxy_pass. Если там rewrite..redirect или return, то подзапрос не > случается, в логе совсем пусто (даже в debug логе). Так и должно быть? Если > да, то может быть имеет смысл что-то в лог писать, а то нелогично как-то > получается, директива в конфиге есть, а действия никакого нет. Миррор создается в фазе precontent, а rewrite и return - на более ранней фазе rewrite. В вашем случае запрос завершается в фазе rewite и не доходит до фазы precontent, в которой создается mirror. Дело тут не в proxy_pass, а в rewrite/return. Если бы в локейшене просто отдавалась статика, то mirror бы также работал. Непонятно что можно в этом случае писать в лог, если запрос просто завершается на более ранней стадии. В nginx devguide есть глава про фазы: http://nginx.org/en/docs/dev/development_guide.html#http_phases > Версию nginx и конфиг прикладываю ниже. > > С уважением, > Александр > > nginx version: nginx/1.15.4 > > configure arguments: --prefix=/opt/local > --with-cc-opt='-I/opt/local/include -Os' --with-ld-opt='-L/opt/local/lib > -Wl,-headerpad_max_install_names' > --conf-path=/opt/local/etc/nginx/nginx.conf > --error-log-path=/opt/local/var/log/nginx/error.log > --http-log-path=/opt/local/var/log/nginx/access.log > --pid-path=/opt/local/var/run/nginx/nginx.pid > --lock-path=/opt/local/var/run/nginx/nginx.lock > --http-client-body-temp-path=/opt/local/var/run/nginx/client_body_temp > --http-proxy-temp-path=/opt/local/var/run/nginx/proxy_temp > --http-fastcgi-temp-path=/opt/local/var/run/nginx/fastcgi_temp > --http-uwsgi-temp-path=/opt/local/var/run/nginx/uwsgi_temp --with-debug > --with-http_mp4_module --with-stream > > http { > > include mime.types; > > default_type application/octet-stream; > > > log_format stat '[$time_local] $server_port $status "$request" "$uri"'; > > log_subrequest on; > > access_log /dev/stdout stat; > > > server { > > listen 8000 default_server; > > > location /r { > > mirror /stats; > > return 200 "OK"; > > } > > > location = /stats { > > proxy_pass http://127.0.0.1:8001$uri; > > } > > } > > > server { > > listen 8001 default_server; > > > location /o { > > return 200 "OK"; > > } > > > location /stats { > > return 204; > > } > > } > > } > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Roman Arutyunyan From self на alaz.me Wed Oct 3 07:43:40 2018 From: self на alaz.me (Alexander Azarov) Date: Wed, 3 Oct 2018 10:43:40 +0300 Subject: =?UTF-8?B?UmU6IG1pcnJvciDRgtC+0LvRjNC60L4gKl9wYXNz?= In-Reply-To: <20181003071058.GB62311@Romans-MacBook-Air.local> References: <20181003071058.GB62311@Romans-MacBook-Air.local> Message-ID: Здравствуйте, Роман! Понятно, спасибо за объяснение и за ссылку. Я не могу подсказать что писать в лог, да и что вообще с этим делать. Но получается, что админу Nginx надо знать про фазы обработки запроса, чтобы смочь себе объяснить, почему директива в конфиге не приводит вообще ни к чему. С уважением, Александр ср, 3 окт. 2018 г. в 10:11, Roman Arutyunyan : > Добрый день, Александр. > > On Wed, Oct 03, 2018 at 08:10:13AM +0300, Alexander Azarov wrote: > > Здравствуйте! > > > > У меня вопрос про mirror. Он у меня срабатывает, только если в локейшне > > есть proxy_pass. Если там rewrite..redirect или return, то подзапрос не > > случается, в логе совсем пусто (даже в debug логе). Так и должно быть? > Если > > да, то может быть имеет смысл что-то в лог писать, а то нелогично как-то > > получается, директива в конфиге есть, а действия никакого нет. > > Миррор создается в фазе precontent, а rewrite и return - на более ранней > фазе > rewrite. В вашем случае запрос завершается в фазе rewite и не доходит до > фазы precontent, в которой создается mirror. Дело тут не в proxy_pass, а > в rewrite/return. Если бы в локейшене просто отдавалась статика, то mirror > бы также работал. Непонятно что можно в этом случае писать в лог, если > запрос просто завершается на более ранней стадии. > > В nginx devguide есть глава про фазы: > > http://nginx.org/en/docs/dev/development_guide.html#http_phases > > > Версию nginx и конфиг прикладываю ниже. > > > > С уважением, > > Александр > > > > nginx version: nginx/1.15.4 > > > > configure arguments: --prefix=/opt/local > > --with-cc-opt='-I/opt/local/include -Os' --with-ld-opt='-L/opt/local/lib > > -Wl,-headerpad_max_install_names' > > --conf-path=/opt/local/etc/nginx/nginx.conf > > --error-log-path=/opt/local/var/log/nginx/error.log > > --http-log-path=/opt/local/var/log/nginx/access.log > > --pid-path=/opt/local/var/run/nginx/nginx.pid > > --lock-path=/opt/local/var/run/nginx/nginx.lock > > --http-client-body-temp-path=/opt/local/var/run/nginx/client_body_temp > > --http-proxy-temp-path=/opt/local/var/run/nginx/proxy_temp > > --http-fastcgi-temp-path=/opt/local/var/run/nginx/fastcgi_temp > > --http-uwsgi-temp-path=/opt/local/var/run/nginx/uwsgi_temp --with-debug > > --with-http_mp4_module --with-stream > > > > http { > > > > include mime.types; > > > > default_type application/octet-stream; > > > > > > log_format stat '[$time_local] $server_port $status "$request" "$uri"'; > > > > log_subrequest on; > > > > access_log /dev/stdout stat; > > > > > > server { > > > > listen 8000 default_server; > > > > > > location /r { > > > > mirror /stats; > > > > return 200 "OK"; > > > > } > > > > > > location = /stats { > > > > proxy_pass http://127.0.0.1:8001$uri; > > > > } > > > > } > > > > > > server { > > > > listen 8001 default_server; > > > > > > location /o { > > > > return 200 "OK"; > > > > } > > > > > > location /stats { > > > > return 204; > > > > } > > > > } > > > > } > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > -- > Roman Arutyunyan > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From ano на bestmx.net Wed Oct 3 07:47:30 2018 From: ano на bestmx.net (Andrey Oktyabrskiy) Date: Wed, 3 Oct 2018 10:47:30 +0300 Subject: =?UTF-8?B?UmU6IG1pcnJvciDRgtC+0LvRjNC60L4gKl9wYXNz?= In-Reply-To: References: <20181003071058.GB62311@Romans-MacBook-Air.local> Message-ID: On 03.10.2018 10:43, Alexander Azarov wrote: > Я не могу подсказать что писать в лог, да и что вообще с этим делать. Но > получается, что админу Nginx надо знать про фазы обработки запроса, > чтобы смочь себе объяснить, почему директива в конфиге не приводит > вообще ни к чему. По-моему, эта информация должна лежать на самом видном месте в документации. Часто нужна. From chipitsine на gmail.com Wed Oct 3 08:23:46 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 3 Oct 2018 13:23:46 +0500 Subject: =?UTF-8?B?UmU6IG1pcnJvciDRgtC+0LvRjNC60L4gKl9wYXNz?= In-Reply-To: <20181003071058.GB62311@Romans-MacBook-Air.local> References: <20181003071058.GB62311@Romans-MacBook-Air.local> Message-ID: ср, 3 окт. 2018 г. в 12:11, Roman Arutyunyan : > Добрый день, Александр. > > On Wed, Oct 03, 2018 at 08:10:13AM +0300, Alexander Azarov wrote: > > Здравствуйте! > > > > У меня вопрос про mirror. Он у меня срабатывает, только если в локейшне > > есть proxy_pass. Если там rewrite..redirect или return, то подзапрос не > > случается, в логе совсем пусто (даже в debug логе). Так и должно быть? > Если > > да, то может быть имеет смысл что-то в лог писать, а то нелогично как-то > > получается, директива в конфиге есть, а действия никакого нет. > > Миррор создается в фазе precontent, а rewrite и return - на более ранней > фазе > rewrite. В вашем случае запрос завершается в фазе rewite и не доходит до > фазы precontent, в которой создается mirror. Дело тут не в proxy_pass, а > в rewrite/return. Если бы в локейшене просто отдавалась статика, то mirror > бы также работал. Непонятно что можно в этом случае писать в лог, если > запрос просто завершается на более ранней стадии. > я наверное, неправильно поступлю. но у меня два вопроса )) 1) мы игрались с mirror - штука годная. но когда мы хотели ее подебажить, мы добавили access_log, в него ничего не записалось. мы включили снифер - запросы увидели. не совсем понятно, лог можно указать, с точки зрения nginx директива access_log в локейшене миррора не является ошибкой. но не логирует. надо доки читать. оченьсложна 2) вот допустим, у меня точка, на которую я делаю зеркалирование - тормозная. то соединения не устанавливаются, то запросы подтупливают... не будет ли это приводить к деградации воркера ? > > В nginx devguide есть глава про фазы: > > http://nginx.org/en/docs/dev/development_guide.html#http_phases > > > Версию nginx и конфиг прикладываю ниже. > > > > С уважением, > > Александр > > > > nginx version: nginx/1.15.4 > > > > configure arguments: --prefix=/opt/local > > --with-cc-opt='-I/opt/local/include -Os' --with-ld-opt='-L/opt/local/lib > > -Wl,-headerpad_max_install_names' > > --conf-path=/opt/local/etc/nginx/nginx.conf > > --error-log-path=/opt/local/var/log/nginx/error.log > > --http-log-path=/opt/local/var/log/nginx/access.log > > --pid-path=/opt/local/var/run/nginx/nginx.pid > > --lock-path=/opt/local/var/run/nginx/nginx.lock > > --http-client-body-temp-path=/opt/local/var/run/nginx/client_body_temp > > --http-proxy-temp-path=/opt/local/var/run/nginx/proxy_temp > > --http-fastcgi-temp-path=/opt/local/var/run/nginx/fastcgi_temp > > --http-uwsgi-temp-path=/opt/local/var/run/nginx/uwsgi_temp --with-debug > > --with-http_mp4_module --with-stream > > > > http { > > > > include mime.types; > > > > default_type application/octet-stream; > > > > > > log_format stat '[$time_local] $server_port $status "$request" "$uri"'; > > > > log_subrequest on; > > > > access_log /dev/stdout stat; > > > > > > server { > > > > listen 8000 default_server; > > > > > > location /r { > > > > mirror /stats; > > > > return 200 "OK"; > > > > } > > > > > > location = /stats { > > > > proxy_pass http://127.0.0.1:8001$uri; > > > > } > > > > } > > > > > > server { > > > > listen 8001 default_server; > > > > > > location /o { > > > > return 200 "OK"; > > > > } > > > > > > location /stats { > > > > return 204; > > > > } > > > > } > > > > } > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > -- > Roman Arutyunyan > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From self на alaz.me Wed Oct 3 08:34:56 2018 From: self на alaz.me (Alexander Azarov) Date: Wed, 3 Oct 2018 11:34:56 +0300 Subject: =?UTF-8?B?UmU6IG1pcnJvciDRgtC+0LvRjNC60L4gKl9wYXNz?= In-Reply-To: References: <20181003071058.GB62311@Romans-MacBook-Air.local> Message-ID: ср, 3 окт. 2018 г. в 11:24, Илья Шипицин : > > 1) мы игрались с mirror - штука годная. но когда мы хотели ее подебажить, > мы добавили access_log, в него ничего не записалось. мы включили снифер - > запросы увидели. не совсем понятно, лог можно указать, с точки зрения nginx > директива access_log в локейшене миррора не является ошибкой. но не > логирует. надо доки читать. оченьсложна > Вот мой второй тестовый конфиг, там логгирует. Но log_subrequest ему надо, да. http { include mime.types; default_type application/octet-stream; log_format stat '[$time_local] $server_port $status "$request" "$uri"'; log_subrequest on; access_log /dev/stdout stat; server { listen 8000 default_server; location /r { mirror /stats; proxy_pass http://127.0.0.1:8001/o; } location = /stats { proxy_pass http://127.0.0.1:8001$uri; } } server { listen 8001 default_server; location /o { return 200 "OK"; } location /stats { return 204; } } > 2) вот допустим, у меня точка, на которую я делаю зеркалирование - > тормозная. то соединения не устанавливаются, то запросы подтупливают... не > будет ли это приводить к деградации воркера ? > > >> >> В nginx devguide есть глава про фазы: >> >> http://nginx.org/en/docs/dev/development_guide.html#http_phases >> >> > Версию nginx и конфиг прикладываю ниже. >> > >> > С уважением, >> > Александр >> > >> > nginx version: nginx/1.15.4 >> > >> > configure arguments: --prefix=/opt/local >> > --with-cc-opt='-I/opt/local/include -Os' --with-ld-opt='-L/opt/local/lib >> > -Wl,-headerpad_max_install_names' >> > --conf-path=/opt/local/etc/nginx/nginx.conf >> > --error-log-path=/opt/local/var/log/nginx/error.log >> > --http-log-path=/opt/local/var/log/nginx/access.log >> > --pid-path=/opt/local/var/run/nginx/nginx.pid >> > --lock-path=/opt/local/var/run/nginx/nginx.lock >> > --http-client-body-temp-path=/opt/local/var/run/nginx/client_body_temp >> > --http-proxy-temp-path=/opt/local/var/run/nginx/proxy_temp >> > --http-fastcgi-temp-path=/opt/local/var/run/nginx/fastcgi_temp >> > --http-uwsgi-temp-path=/opt/local/var/run/nginx/uwsgi_temp --with-debug >> > --with-http_mp4_module --with-stream >> > >> > http { >> > >> > include mime.types; >> > >> > default_type application/octet-stream; >> > >> > >> > log_format stat '[$time_local] $server_port $status "$request" >> "$uri"'; >> > >> > log_subrequest on; >> > >> > access_log /dev/stdout stat; >> > >> > >> > server { >> > >> > listen 8000 default_server; >> > >> > >> > location /r { >> > >> > mirror /stats; >> > >> > return 200 "OK"; >> > >> > } >> > >> > >> > location = /stats { >> > >> > proxy_pass http://127.0.0.1:8001$uri; >> > >> > } >> > >> > } >> > >> > >> > server { >> > >> > listen 8001 default_server; >> > >> > >> > location /o { >> > >> > return 200 "OK"; >> > >> > } >> > >> > >> > location /stats { >> > >> > return 204; >> > >> > } >> > >> > } >> > >> > } >> >> > _______________________________________________ >> > nginx-ru mailing list >> > nginx-ru на nginx.org >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> -- >> Roman Arutyunyan >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Oct 3 12:18:32 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 3 Oct 2018 15:18:32 +0300 Subject: =?UTF-8?B?UmU6IG1pcnJvciDRgtC+0LvRjNC60L4gKl9wYXNz?= In-Reply-To: <20181003071058.GB62311@Romans-MacBook-Air.local> References: <20181003071058.GB62311@Romans-MacBook-Air.local> Message-ID: <20181003121831.GM56558@mdounin.ru> Hello! On Wed, Oct 03, 2018 at 10:10:58AM +0300, Roman Arutyunyan wrote: > Добрый день, Александр. > > On Wed, Oct 03, 2018 at 08:10:13AM +0300, Alexander Azarov wrote: > > Здравствуйте! > > > > У меня вопрос про mirror. Он у меня срабатывает, только если в локейшне > > есть proxy_pass. Если там rewrite..redirect или return, то подзапрос не > > случается, в логе совсем пусто (даже в debug логе). Так и должно быть? Если > > да, то может быть имеет смысл что-то в лог писать, а то нелогично как-то > > получается, директива в конфиге есть, а действия никакого нет. > > Миррор создается в фазе precontent, а rewrite и return - на более ранней фазе > rewrite. В вашем случае запрос завершается в фазе rewite и не доходит до > фазы precontent, в которой создается mirror. Дело тут не в proxy_pass, а > в rewrite/return. Если бы в локейшене просто отдавалась статика, то mirror > бы также работал. Непонятно что можно в этом случае писать в лог, если > запрос просто завершается на более ранней стадии. На самом деле, в документации про это тоже есть, в описании модуля rewrite: : Модуль ngx_http_rewrite_module позволяет изменять URI запроса с : помощью регулярных выражений PCRE, делать перенаправления и : выбирать конфигурацию по условию. То, что делает rewrite - это выбирает конфигурацию перед собственно обработкой запроса. А mirror - часть этой самой выбираемой конфигурации, и зеркалирует собственно обрабатываемые запросы. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Wed Oct 3 12:36:08 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 3 Oct 2018 15:36:08 +0300 Subject: =?UTF-8?B?UmU6IG1pcnJvciDRgtC+0LvRjNC60L4gKl9wYXNz?= In-Reply-To: References: <20181003071058.GB62311@Romans-MacBook-Air.local> Message-ID: <20181003123607.GN56558@mdounin.ru> Hello! On Wed, Oct 03, 2018 at 01:23:46PM +0500, Илья Шипицин wrote: > ср, 3 окт. 2018 г. в 12:11, Roman Arutyunyan : > > > On Wed, Oct 03, 2018 at 08:10:13AM +0300, Alexander Azarov wrote: > > > Здравствуйте! > > > > > > У меня вопрос про mirror. Он у меня срабатывает, только если в локейшне > > > есть proxy_pass. Если там rewrite..redirect или return, то подзапрос не > > > случается, в логе совсем пусто (даже в debug логе). Так и должно быть? > > Если > > > да, то может быть имеет смысл что-то в лог писать, а то нелогично как-то > > > получается, директива в конфиге есть, а действия никакого нет. > > > > Миррор создается в фазе precontent, а rewrite и return - на более ранней > > фазе > > rewrite. В вашем случае запрос завершается в фазе rewite и не доходит до > > фазы precontent, в которой создается mirror. Дело тут не в proxy_pass, а > > в rewrite/return. Если бы в локейшене просто отдавалась статика, то mirror > > бы также работал. Непонятно что можно в этом случае писать в лог, если > > запрос просто завершается на более ранней стадии. > > > > я наверное, неправильно поступлю. но у меня два вопроса )) > > 1) мы игрались с mirror - штука годная. но когда мы хотели ее подебажить, > мы добавили access_log, в него ничего не записалось. мы включили снифер - > запросы увидели. не совсем понятно, лог можно указать, с точки зрения nginx > директива access_log в локейшене миррора не является ошибкой. но не > логирует. надо доки читать. оченьсложна Mirror использует подзапросы, аналогично SSI и add_after_body. Подзапросы рассматриваются как часть основного запроса, и отдельно логгируются, только если это специально разрешить, http://nginx.org/r/log_subrequest. > 2) вот допустим, у меня точка, на которую я делаю зеркалирование - > тормозная. то соединения не устанавливаются, то запросы подтупливают... не > будет ли это приводить к деградации воркера ? Подзапрос mirror'а выполняются параллельно основному запросу. Однако если он не успеет завершиться к моменту окончания основного запроса - это завершение запроса задержит, и соответственно задержит последующие запросы в этом же соединении в случае постоянных соединений в HTTP/1.x. То есть плохо работающий mirror-бэкенд - может увеличивать latency. -- Maxim Dounin http://mdounin.ru/ From alex.hha на gmail.com Wed Oct 3 12:49:02 2018 From: alex.hha на gmail.com (Alex Domoradov) Date: Wed, 3 Oct 2018 15:49:02 +0300 Subject: =?UTF-8?B?UmU6IG1pcnJvciDRgtC+0LvRjNC60L4gKl9wYXNz?= In-Reply-To: <20181003123607.GN56558@mdounin.ru> References: <20181003071058.GB62311@Romans-MacBook-Air.local> <20181003123607.GN56558@mdounin.ru> Message-ID: > То есть плохо работающий mirror-бэкенд - может увеличивать latency может или однозначно будет увеличивать? On Wed, Oct 3, 2018 at 3:36 PM Maxim Dounin wrote: > Hello! > > On Wed, Oct 03, 2018 at 01:23:46PM +0500, Илья Шипицин wrote: > > > ср, 3 окт. 2018 г. в 12:11, Roman Arutyunyan : > > > > > On Wed, Oct 03, 2018 at 08:10:13AM +0300, Alexander Azarov wrote: > > > > Здравствуйте! > > > > > > > > У меня вопрос про mirror. Он у меня срабатывает, только если в > локейшне > > > > есть proxy_pass. Если там rewrite..redirect или return, то подзапрос > не > > > > случается, в логе совсем пусто (даже в debug логе). Так и должно > быть? > > > Если > > > > да, то может быть имеет смысл что-то в лог писать, а то нелогично > как-то > > > > получается, директива в конфиге есть, а действия никакого нет. > > > > > > Миррор создается в фазе precontent, а rewrite и return - на более > ранней > > > фазе > > > rewrite. В вашем случае запрос завершается в фазе rewite и не доходит > до > > > фазы precontent, в которой создается mirror. Дело тут не в > proxy_pass, а > > > в rewrite/return. Если бы в локейшене просто отдавалась статика, то > mirror > > > бы также работал. Непонятно что можно в этом случае писать в лог, если > > > запрос просто завершается на более ранней стадии. > > > > > > > я наверное, неправильно поступлю. но у меня два вопроса )) > > > > 1) мы игрались с mirror - штука годная. но когда мы хотели ее подебажить, > > мы добавили access_log, в него ничего не записалось. мы включили снифер - > > запросы увидели. не совсем понятно, лог можно указать, с точки зрения > nginx > > директива access_log в локейшене миррора не является ошибкой. но не > > логирует. надо доки читать. оченьсложна > > Mirror использует подзапросы, аналогично SSI и add_after_body. > Подзапросы рассматриваются как часть основного запроса, и отдельно > логгируются, только если это специально разрешить, > http://nginx.org/r/log_subrequest. > > > 2) вот допустим, у меня точка, на которую я делаю зеркалирование - > > тормозная. то соединения не устанавливаются, то запросы подтупливают... > не > > будет ли это приводить к деградации воркера ? > > Подзапрос mirror'а выполняются параллельно основному запросу. > Однако если он не успеет завершиться к моменту окончания основного > запроса - это завершение запроса задержит, и соответственно > задержит последующие запросы в этом же соединении в случае > постоянных соединений в HTTP/1.x. То есть плохо работающий > mirror-бэкенд - может увеличивать latency. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Oct 3 14:36:24 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 3 Oct 2018 17:36:24 +0300 Subject: =?UTF-8?B?UmU6IG1pcnJvciDRgtC+0LvRjNC60L4gKl9wYXNz?= In-Reply-To: References: <20181003071058.GB62311@Romans-MacBook-Air.local> <20181003123607.GN56558@mdounin.ru> Message-ID: <20181003143624.GO56558@mdounin.ru> Hello! On Wed, Oct 03, 2018 at 03:49:02PM +0300, Alex Domoradov wrote: > > То есть плохо работающий mirror-бэкенд - может увеличивать latency > > может или однозначно будет увеличивать? Может увеличивать, может - не увеличивать, зависит от многих факторов. В частности, a) Как соотносится время обработки mirror-подзапроса с временем обработки основного запроса и отправки ответа на основной запрос. Скажем, если ответ большой и отправляется клиенту минуту - то даже если mirror-подзапрос будет выполняться 30 секунд - это ни на что не повлияет. б) Какой именно протокол используется. Mirror может влияеть на latency только в случае постоянных соединений HTTP/1.x. Если keepalive выключен - то на latency mirror никак не повлияет, и равно не повлияет при использовании HTTP/2. в) Какой именно временной паттерн запросов. Если запросов мало, и промежутки между keepalive-запросами в одном соединении превышают время задержки из-за тормозящего mirror-бэкенда - на latency влияния не будет. В целом - я бы не рекомендовал использовать плохо работающие бэкенды. Если таки приходится - в качестве превентивной меры борьбы с возможными негативными последствиями - для mirror-бэкендов имеет смысл прописывать жёсткие таймауты. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Wed Oct 3 15:04:25 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 3 Oct 2018 20:04:25 +0500 Subject: =?UTF-8?B?UmU6IG1pcnJvciDRgtC+0LvRjNC60L4gKl9wYXNz?= In-Reply-To: <20181003123607.GN56558@mdounin.ru> References: <20181003071058.GB62311@Romans-MacBook-Air.local> <20181003123607.GN56558@mdounin.ru> Message-ID: ср, 3 окт. 2018 г. в 17:36, Maxim Dounin : > Hello! > > On Wed, Oct 03, 2018 at 01:23:46PM +0500, Илья Шипицин wrote: > > > ср, 3 окт. 2018 г. в 12:11, Roman Arutyunyan : > > > > > On Wed, Oct 03, 2018 at 08:10:13AM +0300, Alexander Azarov wrote: > > > > Здравствуйте! > > > > > > > > У меня вопрос про mirror. Он у меня срабатывает, только если в > локейшне > > > > есть proxy_pass. Если там rewrite..redirect или return, то подзапрос > не > > > > случается, в логе совсем пусто (даже в debug логе). Так и должно > быть? > > > Если > > > > да, то может быть имеет смысл что-то в лог писать, а то нелогично > как-то > > > > получается, директива в конфиге есть, а действия никакого нет. > > > > > > Миррор создается в фазе precontent, а rewrite и return - на более > ранней > > > фазе > > > rewrite. В вашем случае запрос завершается в фазе rewite и не доходит > до > > > фазы precontent, в которой создается mirror. Дело тут не в > proxy_pass, а > > > в rewrite/return. Если бы в локейшене просто отдавалась статика, то > mirror > > > бы также работал. Непонятно что можно в этом случае писать в лог, если > > > запрос просто завершается на более ранней стадии. > > > > > > > я наверное, неправильно поступлю. но у меня два вопроса )) > > > > 1) мы игрались с mirror - штука годная. но когда мы хотели ее подебажить, > > мы добавили access_log, в него ничего не записалось. мы включили снифер - > > запросы увидели. не совсем понятно, лог можно указать, с точки зрения > nginx > > директива access_log в локейшене миррора не является ошибкой. но не > > логирует. надо доки читать. оченьсложна > > Mirror использует подзапросы, аналогично SSI и add_after_body. > Подзапросы рассматриваются как часть основного запроса, и отдельно > логгируются, только если это специально разрешить, > http://nginx.org/r/log_subrequest. > > т.е. это гибкость ? могу в локейшене с митррором указать access_log, не указать логирование подзапросов, и ничего логироваться не будет ? с какой целью заложено такое ? > > 2) вот допустим, у меня точка, на которую я делаю зеркалирование - > > тормозная. то соединения не устанавливаются, то запросы подтупливают... > не > > будет ли это приводить к деградации воркера ? > > Подзапрос mirror'а выполняются параллельно основному запросу. > Однако если он не успеет завершиться к моменту окончания основного > запроса - это завершение запроса задержит, и соответственно > задержит последующие запросы в этом же соединении в случае > постоянных соединений в HTTP/1.x. То есть плохо работающий > mirror-бэкенд - может увеличивать latency. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Oct 3 15:26:51 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 3 Oct 2018 18:26:51 +0300 Subject: =?UTF-8?B?UmU6IG1pcnJvciDRgtC+0LvRjNC60L4gKl9wYXNz?= In-Reply-To: References: <20181003071058.GB62311@Romans-MacBook-Air.local> <20181003123607.GN56558@mdounin.ru> Message-ID: <20181003152651.GP56558@mdounin.ru> Hello! On Wed, Oct 03, 2018 at 08:04:25PM +0500, Илья Шипицин wrote: > ср, 3 окт. 2018 г. в 17:36, Maxim Dounin : > > > Hello! > > > > On Wed, Oct 03, 2018 at 01:23:46PM +0500, Илья Шипицин wrote: > > > > > ср, 3 окт. 2018 г. в 12:11, Roman Arutyunyan : > > > > > > > On Wed, Oct 03, 2018 at 08:10:13AM +0300, Alexander Azarov wrote: > > > > > Здравствуйте! > > > > > > > > > > У меня вопрос про mirror. Он у меня срабатывает, только если в > > локейшне > > > > > есть proxy_pass. Если там rewrite..redirect или return, то подзапрос > > не > > > > > случается, в логе совсем пусто (даже в debug логе). Так и должно > > быть? > > > > Если > > > > > да, то может быть имеет смысл что-то в лог писать, а то нелогично > > как-то > > > > > получается, директива в конфиге есть, а действия никакого нет. > > > > > > > > Миррор создается в фазе precontent, а rewrite и return - на более > > ранней > > > > фазе > > > > rewrite. В вашем случае запрос завершается в фазе rewite и не доходит > > до > > > > фазы precontent, в которой создается mirror. Дело тут не в > > proxy_pass, а > > > > в rewrite/return. Если бы в локейшене просто отдавалась статика, то > > mirror > > > > бы также работал. Непонятно что можно в этом случае писать в лог, если > > > > запрос просто завершается на более ранней стадии. > > > > > > > > > > я наверное, неправильно поступлю. но у меня два вопроса )) > > > > > > 1) мы игрались с mirror - штука годная. но когда мы хотели ее подебажить, > > > мы добавили access_log, в него ничего не записалось. мы включили снифер - > > > запросы увидели. не совсем понятно, лог можно указать, с точки зрения > > nginx > > > директива access_log в локейшене миррора не является ошибкой. но не > > > логирует. надо доки читать. оченьсложна > > > > Mirror использует подзапросы, аналогично SSI и add_after_body. > > Подзапросы рассматриваются как часть основного запроса, и отдельно > > логгируются, только если это специально разрешить, > > http://nginx.org/r/log_subrequest. > > > > > т.е. это гибкость ? могу в локейшене с митррором указать access_log, не > указать логирование подзапросов, и ничего > логироваться не будет ? с какой целью заложено такое ? Заложено - то, что подзапросы не логгируются. Смысла их логгировать - в подавляющем большинстве случаев нет, они неразрывно связаны с основным запросом и отдельного интереса не представляют. То есть в access_log логгируются запросы, полученные от клиентов, и результат выполнения этих запросов. А не некие внутренние сущности, которые nginx породил в процессе обработки этих запросов, и у которых нет ни своего ip-адреса клиента, ни своей строки запроса, ни своих заголовков запроса, ни даже, строго говоря, своих заголовков ответа. Если очень хочется эти внутренние сущности таки увидеть - есть ручка log_subrequest, которая позволяет это сделать. Но надо понимать, что результат может оказаться несколько не такой, как ожидалось, потому что смотри выше - собственной информации у этих подзапросов очень немного, и, скажем, log-формат по умолчанию - непригоден для их логгирования чуть менее, чем полностью. -- Maxim Dounin http://mdounin.ru/ From raven_kg на megaline.kg Thu Oct 4 06:04:31 2018 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Thu, 4 Oct 2018 12:04:31 +0600 Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC+0YLQutC70Y7Rh9C40YLRjCBodHRw?= =?UTF-8?B?Mg==?= In-Reply-To: <20181002123201.GB56558@mdounin.ru> References: <20181002123201.GB56558@mdounin.ru> Message-ID: Да, вы оказались правы, в одной из listen все же остался параметр http2. В связи с этим возник следующий вопрос - получается, мне не обязательно вписывать http2 в listen каждого блока server {}, если все они слушают один и тот же сокет, например 0.0.0.0:443, а достаточно указать только в одном? 02.10.2018 18:32, Maxim Dounin пишет: > Hello! > > On Tue, Oct 02, 2018 at 06:11:53PM +0600, raven_kg на megaline.kg wrote: > >> Потребовалось отключить http2 для всех хостов, убрал из всех listen >> упоминания http2, перезапустил nginx. В логах так и продолжают сыпаться >> запросы HTTP/2.0. Чем может быть обусловлено такое поведение? > Наиболее вероятна одна из двух причин: > > - из какой-то директивы listen параметр http2 не убран, и > соответственно HTTP/2 используется для данного listen-сокета. > > - nginx продолжает работать со старой конфигурацией - такое может > быть, например, если под "перезапустил nginx" подразумевается > reload, и новую конфигурацию применить не удалось (подробности > будут в логе ошибок). > From chipitsine на gmail.com Thu Oct 4 06:44:37 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 4 Oct 2018 11:44:37 +0500 Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC+0YLQutC70Y7Rh9C40YLRjCBodHRw?= =?UTF-8?B?Mg==?= In-Reply-To: References: <20181002123201.GB56558@mdounin.ru> Message-ID: это на самом деле больной вопрос. хочется в этом месте каких-то более согласованных действий со стороны nginx. если есть несколько listen с разными параметрами (в части http2, например), хочется, чтобы на стадии "nginx -t" это приводило бы к ошибке (а не к тому, что какой-то из параметров применится, но надо еще вычислить, какой именно). чт, 4 окт. 2018 г. в 11:04, raven_kg на megaline.kg : > Да, вы оказались правы, в одной из listen все же остался параметр http2. > В связи с этим возник следующий вопрос - получается, мне не > обязательно вписывать http2 в listen каждого блока server {}, если > все они слушают один и тот же сокет, например 0.0.0.0:443, а достаточно > указать только в одном? > > 02.10.2018 18:32, Maxim Dounin пишет: > > Hello! > > > > On Tue, Oct 02, 2018 at 06:11:53PM +0600, raven_kg на megaline.kg wrote: > > > >> Потребовалось отключить http2 для всех хостов, убрал из всех listen > >> упоминания http2, перезапустил nginx. В логах так и продолжают сыпаться > >> запросы HTTP/2.0. Чем может быть обусловлено такое поведение? > > Наиболее вероятна одна из двух причин: > > > > - из какой-то директивы listen параметр http2 не убран, и > > соответственно HTTP/2 используется для данного listen-сокета. > > > > - nginx продолжает работать со старой конфигурацией - такое может > > быть, например, если под "перезапустил nginx" подразумевается > > reload, и новую конфигурацию применить не удалось (подробности > > будут в логе ошибок). > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From self на alaz.me Thu Oct 4 10:51:04 2018 From: self на alaz.me (Alexander Azarov) Date: Thu, 4 Oct 2018 13:51:04 +0300 Subject: =?UTF-8?B?UmU6IG1pcnJvciDRgtC+0LvRjNC60L4gKl9wYXNz?= In-Reply-To: <20181003121831.GM56558@mdounin.ru> References: <20181003071058.GB62311@Romans-MacBook-Air.local> <20181003121831.GM56558@mdounin.ru> Message-ID: ср, 3 окт. 2018 г. в 15:18, Maxim Dounin : > On Wed, Oct 03, 2018 at 10:10:58AM +0300, Roman Arutyunyan wrote: > > > Миррор создается в фазе precontent, а rewrite и return - на более ранней > фазе > > rewrite. В вашем случае запрос завершается в фазе rewite и не доходит до > > фазы precontent, в которой создается mirror. Дело тут не в proxy_pass, а > > в rewrite/return. Если бы в локейшене просто отдавалась статика, то > mirror > > бы также работал. Непонятно что можно в этом случае писать в лог, если > > запрос просто завершается на более ранней стадии. > > На самом деле, в документации про это тоже есть, в описании > модуля rewrite: > > : Модуль ngx_http_rewrite_module позволяет изменять URI запроса с > : помощью регулярных выражений PCRE, делать перенаправления и > : выбирать конфигурацию по условию. > > "в документации про это тоже есть" = "и это тоже зашифровано в документации" :) Простой рабочий человек, если написал return 204; , то он думает, что "выполнил запрос", а не "завершил запрос на фазе REWRITE, т.е. досрочно, до PRЕCONTENT". Александр. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Oct 4 12:22:03 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 4 Oct 2018 15:22:03 +0300 Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INC+0YLQutC70Y7Rh9C40YLRjCBodHRw?= =?UTF-8?B?Mg==?= In-Reply-To: References: <20181002123201.GB56558@mdounin.ru> Message-ID: <20181004122203.GS56558@mdounin.ru> Hello! On Thu, Oct 04, 2018 at 12:04:31PM +0600, raven_kg на megaline.kg wrote: > Да, вы оказались правы, в одной из listen все же остался параметр http2. > В связи с этим возник следующий вопрос - получается, мне не > обязательно вписывать http2 в listen каждого блока server {}, если > все они слушают один и тот же сокет, например 0.0.0.0:443, а достаточно > указать только в одном? Как и со всеми другими опциями listen-сокета, достаточно их указать один раз. В остальных блоках server достаточно указывать просто директиву listen и адрес. Более того, для большинства опций - повторное указание явно запрещено, и при попытке сделать это nginx будет ругаться. В этом смысле параметры ssl, http2 и proxy_protocol - исключения, их можно продублировать во всех директивах, для большей выразительности конфигурации, так как server { listen 80; listen 443 ssl; ... } читается логичнее, чем то же самое без параметра "ssl". Но можно и не дублировать. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Sat Oct 13 16:26:12 2018 From: nginx-forum на forum.nginx.org (serzh82) Date: Sat, 13 Oct 2018 12:26:12 -0400 Subject: =?UTF-8?B?0JrQsNC6INC30LDQtNCw0YLRjCDRg9GB0LvQvtCy0LjQtSDQsiByZXdyaXRlPw==?= Message-ID: <0303ea829f5e6fac5cf4d73b1f387e3b.NginxMailingListRussian@forum.nginx.org> Здравствуйте! Я убрал слеш в конце урл с помощью: location ~ .+/$ { rewrite (.+)/$ $1 permanent; } Но дело в том, что этот код убирает слеш там, где это не нужно. Например, есть урл sait.ru/en/?page=2 из-за кода убирается слеш и получается урл sait.ru/en?page=2, что дает ошибку 404. Подскажите пожалуйста, как можно задать условие, чтобы код не убирал слеш, если после него стоит вопросительный знак ? Так возможно сделать? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281580,281580#msg-281580 From mdounin на mdounin.ru Sun Oct 14 03:34:17 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sun, 14 Oct 2018 06:34:17 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0LTQsNGC0Ywg0YPRgdC70L7QstC40LUg0LIgcmV3cml0?= =?UTF-8?B?ZT8=?= In-Reply-To: <0303ea829f5e6fac5cf4d73b1f387e3b.NginxMailingListRussian@forum.nginx.org> References: <0303ea829f5e6fac5cf4d73b1f387e3b.NginxMailingListRussian@forum.nginx.org> Message-ID: <20181014033417.GZ56558@mdounin.ru> Hello! On Sat, Oct 13, 2018 at 12:26:12PM -0400, serzh82 wrote: > Здравствуйте! Я убрал слеш в конце урл с помощью: > location ~ .+/$ { > rewrite (.+)/$ $1 permanent; > } > > Но дело в том, что этот код убирает слеш там, где это не нужно. Например, > есть урл sait.ru/en/?page=2 из-за кода убирается слеш и получается урл > sait.ru/en?page=2, что дает ошибку 404. Подскажите пожалуйста, как можно > задать условие, чтобы код не убирал слеш, если после него стоит > вопросительный знак ? Так возможно сделать? Произвольные условия делаются с помощью директивы if. Скажем, убрать слэш, только если в запросе нет аргументов, можно так: if ($is_args = "") { rewrite (.+)/$ $1 redirect; } Подробнее в документации тут: http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html#if Но вообще я бы не рекомендовал заниматься подобными действиями, особенно - в рамках сколько-нибудь сложных сайтов целиком. В частности потому, что стандартное поведение nginx'а - это добавление слэша, если каталог пытаются запрашиваеть без слэша в конце, и таким образом очень легко можно плучить, например, бесконечный цикл редиректов. Ну и других проблем, скорее всего, вы тоже получите - как в рассматриваемом случае со "/en/?page=2". Адреса со слэшом в конце и без него - это разные адреса. Они могут быть взаимозаменяемы, если так написан код сайта, а могут и не быть. Соответственно если хочется поменять одно на другое - это следует делать локально, и строго там, где соответствующие адреса точно взаимозаменямемы. -- Maxim Dounin http://mdounin.ru/ From pnz.stalker на mail.ru Sun Oct 14 17:46:23 2018 From: pnz.stalker на mail.ru (=?UTF-8?B?0JDQvdGC0L7QvSDQk9C+0YDQu9C+0LI=?=) Date: Sun, 14 Oct 2018 20:46:23 +0300 Subject: captive portal Message-ID: Коллеги нужна помощь. Понадобилось тут изобразить captive portal. Завёл на стенде тестовую сеть, на шлюзе сделал -A PREROUTING ! -d 192.168.11.3/32 -i ens4 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.11.3 Далее в nginx заведено 2 виртуальных хоста: === server { # # Listening on IP Address. # # This is the website iptables redirects to listen 80 default_server; root /var/www/html/portal; access_log /var/log/nginx/access1.log atop; port_in_redirect off; keepalive_timeout 0; location / { return 302 http://test.ppcom:82; } } server { listen 82; server_name test.ppcom; root /var/www/html/portal; access_log /var/log/nginx/access2.log atop; add_header Cache-Control no-cache; # set the Expires header to 31 December 2037 23:59:59 GMT, and the Cache-Control max-age to 10 years expires 0; location / { try_files $uri $uri/ /index.html; } } === Локальный DNS резолвит test.ppcom так же в 192.168.11.3. Но не выходит каменный цветок. Но если портал повесить на 80 порт сразу,куда заворачивает трафик iptables то на андроидах всё таки рисуется страница от портала. Вопрос - что упускаю их вида,что не отрабатывает вариант с редиректом из nginx на страницу портала? Причём в дампе я вижу, что nginx отдаёт Hypertext Transfer Protocol HTTP/1.1 302 Moved Temporarily\r\n Server: nginx/1.14.0\r\n Date: Sun, 14 Oct 2018 17:07:54 GMT\r\n Content-Type: text/html\r\n Content-Length: 161\r\n Connection: close\r\n Location: http://test.ppcom:82\r\n \r\n правда при этом вижу в дампе ещё ниже Line-based text data: text/html (7 lines) 302 Found\r\n \r\n

302 Found

\r\n
nginx/1.14.0
\r\n \r\n \r\n From pnz.stalker на mail.ru Wed Oct 17 08:37:26 2018 From: pnz.stalker на mail.ru (=?UTF-8?B?0JDQvdGC0L7QvSDQk9C+0YDQu9C+0LI=?=) Date: Wed, 17 Oct 2018 11:37:26 +0300 Subject: captive portal In-Reply-To: References: Message-ID: <9e32efca-29b0-ea43-2f3d-4e71c94a9bae@mail.ru> Очень интерсно откуда всё таки пролетает 302 Found\r\n посравнивал дамп трафика со стенда и с captiv portal на микротике..там вот этого 302 Found ,только Hypertext Transfer Protocol HTTP/1.1 302 Hotspot login required\r\n nginx -V nginx version: nginx/1.14.0 built with OpenSSL 1.0.2n 7 Dec 2017 TLS SNI support enabled configure arguments: --prefix=/ --conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/sbin --modules-path=/usr/lib64/nginx --error-log-path=/var/log/nginx/nginx.error.log --http-log-path=/var/log/nginx/nginx.log --http-client-body-temp-path=/var/spool/nginx/tmp/client --http-proxy-temp-path=/var/spool/nginx/tmp/proxy --http-fastcgi-temp-path=/var/spool/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/spool/nginx/tmp/uwsgi --http-scgi-temp-path=/var/spool/nginx/tmp/scgi --pid-path=/var/run/nginx.pid --user=_nginx --group=_nginx --with-cc-opt='-I /usr/include/pcre/' --with-http_ssl_module --with-select_module --with-poll_module --with-threads --with-file-aio --with-ipv6 --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_addition_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --add-dynamic-module=spnego-http-auth-nginx-module --add-dynamic-module=ngx_http_auth_pam_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_auth_request_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_slice_module --with-http_stub_status_module --with-http_perl_module=dynamic --with-mail=dynamic --with-mail_ssl_module --with-stream=dynamic --with-stream_ssl_module --add-module=cache_purge --add-dynamic-module=nginx-rtmp-module --with-md5=/usr/lib64 --with-sha1=/usr/lib64 14.10.2018 20:46, Антон Горлов пишет: > 302 Found\r\n From chipitsine на gmail.com Wed Oct 17 12:12:31 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 17 Oct 2018 17:12:31 +0500 Subject: =?UTF-8?B?ZmFpbF90aW1lb3V0IC0g0L7QsdGB0YPQtNC40LwgPw==?= Message-ID: привет! беру стоковый 1.15.5 вот такой конфиг upstream root-upstream { server 127.0.0.1:999 fail_timeout=30000ms; } server { listen 80; server_name localhost; location / { proxy_pass http://root-upstream; } } и, собственно, вот [root на localhost]# nginx -t nginx: [emerg] invalid parameter "fail_timeout=30000ms" in /etc/nginx/conf.d/default.conf:2 nginx: configuration file /etc/nginx/nginx.conf test failed [root на localhost]# в документации сказано, что так можно ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Oct 17 13:25:00 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 17 Oct 2018 16:25:00 +0300 Subject: =?UTF-8?B?UmU6IGZhaWxfdGltZW91dCAtINC+0LHRgdGD0LTQuNC8ID8=?= In-Reply-To: References: Message-ID: <20181017132500.GF56558@mdounin.ru> Hello! On Wed, Oct 17, 2018 at 05:12:31PM +0500, Илья Шипицин wrote: > привет! > > беру стоковый 1.15.5 > вот такой конфиг > > upstream root-upstream { > server 127.0.0.1:999 fail_timeout=30000ms; > } > > > server { > listen 80; > server_name localhost; > > location / { > proxy_pass http://root-upstream; > } > > } > > и, собственно, вот > > [root на localhost]# nginx -t > nginx: [emerg] invalid parameter "fail_timeout=30000ms" in > /etc/nginx/conf.d/default.conf:2 > nginx: configuration file /etc/nginx/nginx.conf test failed > [root на localhost]# > > в документации сказано, что так можно Параметр fail_timeout принимает время в секундах, поэтому так нельзя. У меня валяется старый патч, меняющий таймауты на миллисекундные, но в нём есть вот такой комментарий: There is a problem: if an error happens and peer->fails (failed, checked) are set in ngx_http_upstream_free_round_robin_peer(), we are not guaranteed to see the peer again in a reasonable time. If more than 24 days passes, the "now - peer->checked <= peer->fail_timeout" check in ngx_http_upstream_get_peer() will be incorrect on 32-bit platforms. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Wed Oct 17 14:47:26 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 17 Oct 2018 19:47:26 +0500 Subject: =?UTF-8?B?UmU6IGZhaWxfdGltZW91dCAtINC+0LHRgdGD0LTQuNC8ID8=?= In-Reply-To: <20181017132500.GF56558@mdounin.ru> References: <20181017132500.GF56558@mdounin.ru> Message-ID: On Wed, Oct 17, 2018, 6:25 PM Maxim Dounin wrote: > Hello! > > On Wed, Oct 17, 2018 at 05:12:31PM +0500, Илья Шипицин wrote: > > > привет! > > > > беру стоковый 1.15.5 > > вот такой конфиг > > > > upstream root-upstream { > > server 127.0.0.1:999 fail_timeout=30000ms; > > } > > > > > > server { > > listen 80; > > server_name localhost; > > > > location / { > > proxy_pass http://root-upstream; > > } > > > > } > > > > и, собственно, вот > > > > [root на localhost]# nginx -t > > nginx: [emerg] invalid parameter "fail_timeout=30000ms" in > > /etc/nginx/conf.d/default.conf:2 > > nginx: configuration file /etc/nginx/nginx.conf test failed > > [root на localhost]# > > > > в документации сказано, что так можно > > Параметр fail_timeout принимает время в секундах, поэтому так нельзя. > документацию поправите ? > > У меня валяется старый патч, меняющий таймауты на миллисекундные, > но в нём есть вот такой комментарий: > нафиг такие спецэффекты )) думаю, никто не обидится, если fail_timeout нельзя указать в миллисекундах > > There is a problem: if an error happens and peer->fails (failed, > checked) are set in ngx_http_upstream_free_round_robin_peer(), we > are not guaranteed to see the peer again in a reasonable time. If > more than 24 days passes, the "now - peer->checked <= peer->fail_timeout" > check in ngx_http_upstream_get_peer() will be incorrect on 32-bit > platforms. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Oct 17 16:31:55 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 17 Oct 2018 19:31:55 +0300 Subject: =?UTF-8?B?UmU6IGZhaWxfdGltZW91dCAtINC+0LHRgdGD0LTQuNC8ID8=?= In-Reply-To: References: <20181017132500.GF56558@mdounin.ru> Message-ID: <20181017163155.GH56558@mdounin.ru> Hello! On Wed, Oct 17, 2018 at 07:47:26PM +0500, Илья Шипицин wrote: > On Wed, Oct 17, 2018, 6:25 PM Maxim Dounin wrote: > > > Hello! > > > > On Wed, Oct 17, 2018 at 05:12:31PM +0500, Илья Шипицин wrote: > > > > > привет! > > > > > > беру стоковый 1.15.5 > > > вот такой конфиг > > > > > > upstream root-upstream { > > > server 127.0.0.1:999 fail_timeout=30000ms; > > > } > > > > > > > > > server { > > > listen 80; > > > server_name localhost; > > > > > > location / { > > > proxy_pass http://root-upstream; > > > } > > > > > > } > > > > > > и, собственно, вот > > > > > > [root на localhost]# nginx -t > > > nginx: [emerg] invalid parameter "fail_timeout=30000ms" in > > > /etc/nginx/conf.d/default.conf:2 > > > nginx: configuration file /etc/nginx/nginx.conf test failed > > > [root на localhost]# > > > > > > в документации сказано, что так можно > > > > Параметр fail_timeout принимает время в секундах, поэтому так нельзя. > > > > документацию поправите ? В документации сказано (http://nginx.org/ru/docs/syntax.html): : Некоторые интервалы времени можно задать лишь с точностью до : секунд. Добавить явное указание на то, что fail_timeout относится именно к таким интервалам - наверное стоит. Ну или таки сделать, чтобы миллисекунды работали. > > У меня валяется старый патч, меняющий таймауты на миллисекундные, > > но в нём есть вот такой комментарий: > > нафиг такие спецэффекты )) > > думаю, никто не обидится, если fail_timeout нельзя указать в миллисекундах По хорошему, IMHO, надо - выключение бэкендов из-за ошибок на годы точно никому не нужно, а времена меньше секунды - вполне могут пригодиться. Тем более, что заодно это позволит избавиться от спецэффектов при изменениях системного времени. -- Maxim Dounin http://mdounin.ru/ From simplebox66 на gmail.com Fri Oct 19 14:55:28 2018 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 19 Oct 2018 17:55:28 +0300 Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDRgSBTU2w=?= Message-ID: Есть такой конфиг: server { > listen 443 ssl; > server_name test.ru; > > ssl_certificate /etc/nginx/include/test/lich-2012-srv.pem; > ssl_certificate_key > 'engine:gostengy:s38g83e8ae2e2183b3624f880eb1ca12ggcdfebf'; > ssl_verify_client off; > ssl_protocols TLSv1 TLSv1.1 TLSv1.2; > ssl_ciphers GOST2012-GOST8912:GOST2001-GOST89:HIGH; > ssl_prefer_server_ciphers on; > location / { > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For > $proxy_add_x_forwarded_for; > proxy_hide_header Host; > proxy_set_header X-NginX-Proxy true; > proxy_set_header Host test.loc; > proxy_pass http://test.loc; > proxy_redirect off; > client_max_body_size 300M; > sendfile on; > send_timeout 300s; > } > } Со временем сервер либо перестает работать совсем, либо работает через раз. при этом в логах вот такая ошибка: > [crit] 28474#28474: *401018 SSL_do_handshake() failed (SSL: > error:8001B035:lib(128):gng_keyhandle_getset:GNG_ERR_EXPORT_IMPORT > error:1419D093:SSL routines:tls_process_cke_gost:decryption failed) while > SSL handshaking, client: x.x.x.x, server: 0.0.0.0:443 Просьба помочь с решением проблемы. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Oct 19 15:06:34 2018 From: nginx-forum на forum.nginx.org (onlinebd) Date: Fri, 19 Oct 2018 11:06:34 -0400 Subject: Bitrix + php-fpm In-Reply-To: References: Message-ID: <0d3cc89e4af12c8aa3245fd035efc6a2.NginxMailingListRussian@forum.nginx.org> Наш вариант конфигурационного файла, полный фарш: https://onlinebd.ru/blog/1s-bitriks-nginx-php-fpm-kompozit Posted at Nginx Forum: https://forum.nginx.org/read.php?21,255205,281648#msg-281648 From chipitsine на gmail.com Fri Oct 19 15:12:12 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 19 Oct 2018 20:12:12 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgU1Ns?= In-Reply-To: References: Message-ID: Это крипто про? On Fri, Oct 19, 2018, 7:55 PM Иван Мишин wrote: > Есть такой конфиг: > > server { >> listen 443 ssl; >> server_name test.ru; >> >> ssl_certificate /etc/nginx/include/test/lich-2012-srv.pem; >> ssl_certificate_key >> 'engine:gostengy:s38g83e8ae2e2183b3624f880eb1ca12ggcdfebf'; >> ssl_verify_client off; >> ssl_protocols TLSv1 TLSv1.1 TLSv1.2; >> ssl_ciphers GOST2012-GOST8912:GOST2001-GOST89:HIGH; >> ssl_prefer_server_ciphers on; >> location / { >> proxy_set_header X-Real-IP $remote_addr; >> proxy_set_header X-Forwarded-For >> $proxy_add_x_forwarded_for; >> proxy_hide_header Host; >> proxy_set_header X-NginX-Proxy true; >> proxy_set_header Host test.loc; >> proxy_pass http://test.loc; >> proxy_redirect off; >> client_max_body_size 300M; >> sendfile on; >> send_timeout 300s; >> } >> } > > > Со временем сервер либо перестает работать совсем, либо работает через > раз. при этом в логах вот такая ошибка: > >> [crit] 28474#28474: *401018 SSL_do_handshake() failed (SSL: >> error:8001B035:lib(128):gng_keyhandle_getset:GNG_ERR_EXPORT_IMPORT >> error:1419D093:SSL routines:tls_process_cke_gost:decryption failed) while >> SSL handshaking, client: x.x.x.x, server: 0.0.0.0:443 > > > Просьба помочь с решением проблемы. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From simplebox66 на gmail.com Fri Oct 19 16:17:11 2018 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 19 Oct 2018 19:17:11 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgU1Ns?= In-Reply-To: References: Message-ID: Не совсем понял вопрос. Но да, тут используется крипто про пт, 19 окт. 2018 г. в 18:12, Илья Шипицин : > Это крипто про? > > On Fri, Oct 19, 2018, 7:55 PM Иван Мишин wrote: > >> Есть такой конфиг: >> >> server { >>> listen 443 ssl; >>> server_name test.ru; >>> >>> ssl_certificate /etc/nginx/include/test/lich-2012-srv.pem; >>> ssl_certificate_key >>> 'engine:gostengy:s38g83e8ae2e2183b3624f880eb1ca12ggcdfebf'; >>> ssl_verify_client off; >>> ssl_protocols TLSv1 TLSv1.1 TLSv1.2; >>> ssl_ciphers GOST2012-GOST8912:GOST2001-GOST89:HIGH; >>> ssl_prefer_server_ciphers on; >>> location / { >>> proxy_set_header X-Real-IP $remote_addr; >>> proxy_set_header X-Forwarded-For >>> $proxy_add_x_forwarded_for; >>> proxy_hide_header Host; >>> proxy_set_header X-NginX-Proxy true; >>> proxy_set_header Host test.loc; >>> proxy_pass http://test.loc; >>> proxy_redirect off; >>> client_max_body_size 300M; >>> sendfile on; >>> send_timeout 300s; >>> } >>> } >> >> >> Со временем сервер либо перестает работать совсем, либо работает через >> раз. при этом в логах вот такая ошибка: >> >>> [crit] 28474#28474: *401018 SSL_do_handshake() failed (SSL: >>> error:8001B035:lib(128):gng_keyhandle_getset:GNG_ERR_EXPORT_IMPORT >>> error:1419D093:SSL routines:tls_process_cke_gost:decryption failed) while >>> SSL handshaking, client: x.x.x.x, server: 0.0.0.0:443 >> >> >> Просьба помочь с решением проблемы. >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Oct 22 11:18:35 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 22 Oct 2018 14:18:35 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgU1Ns?= In-Reply-To: References: Message-ID: <20181022111835.GS56558@mdounin.ru> Hello! On Fri, Oct 19, 2018 at 05:55:28PM +0300, Иван Мишин wrote: > Есть такой конфиг: > > server { > > listen 443 ssl; > > server_name test.ru; > > > > ssl_certificate /etc/nginx/include/test/lich-2012-srv.pem; > > ssl_certificate_key > > 'engine:gostengy:s38g83e8ae2e2183b3624f880eb1ca12ggcdfebf'; > > ssl_verify_client off; > > ssl_protocols TLSv1 TLSv1.1 TLSv1.2; > > ssl_ciphers GOST2012-GOST8912:GOST2001-GOST89:HIGH; > > ssl_prefer_server_ciphers on; > > location / { > > proxy_set_header X-Real-IP $remote_addr; > > proxy_set_header X-Forwarded-For > > $proxy_add_x_forwarded_for; > > proxy_hide_header Host; > > proxy_set_header X-NginX-Proxy true; > > proxy_set_header Host test.loc; > > proxy_pass http://test.loc; > > proxy_redirect off; > > client_max_body_size 300M; > > sendfile on; > > send_timeout 300s; > > } > > } > > > Со временем сервер либо перестает работать совсем, либо работает через раз. > при этом в логах вот такая ошибка: > > > [crit] 28474#28474: *401018 SSL_do_handshake() failed (SSL: > > error:8001B035:lib(128):gng_keyhandle_getset:GNG_ERR_EXPORT_IMPORT > > error:1419D093:SSL routines:tls_process_cke_gost:decryption failed) while > > SSL handshaking, client: x.x.x.x, server: 0.0.0.0:443 > > Просьба помочь с решением проблемы. Судя по диагностики, ваши проблемы - где-то в GOST engine. Если по условиям задачи её можно выкинуть - очевидным решением будет выкинуть. Если выкинуть нельзя - попробуйте поиграться с версиями OpenSSL'я и GOST engine, а равно попробуйте грузить ключ из файла, а не через engine. Если ничего из этого не поможет - стоит стучаться непосредственно к ребятам, занимающимся оной GOST engine. -- Maxim Dounin http://mdounin.ru/ From simplebox66 на gmail.com Mon Oct 22 15:24:09 2018 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 22 Oct 2018 18:24:09 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgU1Ns?= In-Reply-To: <20181022111835.GS56558@mdounin.ru> References: <20181022111835.GS56558@mdounin.ru> Message-ID: если проблема в утилите openssl то почему servicen nignx reload исцеляет систему? На том же сервере работает еще и apache (очевидно с тем же openssl) и он такой проблемы не имеет пн, 22 окт. 2018 г. в 14:18, Maxim Dounin : > Hello! > > On Fri, Oct 19, 2018 at 05:55:28PM +0300, Иван Мишин wrote: > > > Есть такой конфиг: > > > > server { > > > listen 443 ssl; > > > server_name test.ru; > > > > > > ssl_certificate /etc/nginx/include/test/lich-2012-srv.pem; > > > ssl_certificate_key > > > 'engine:gostengy:s38g83e8ae2e2183b3624f880eb1ca12ggcdfebf'; > > > ssl_verify_client off; > > > ssl_protocols TLSv1 TLSv1.1 TLSv1.2; > > > ssl_ciphers GOST2012-GOST8912:GOST2001-GOST89:HIGH; > > > ssl_prefer_server_ciphers on; > > > location / { > > > proxy_set_header X-Real-IP $remote_addr; > > > proxy_set_header X-Forwarded-For > > > $proxy_add_x_forwarded_for; > > > proxy_hide_header Host; > > > proxy_set_header X-NginX-Proxy true; > > > proxy_set_header Host test.loc; > > > proxy_pass http://test.loc; > > > proxy_redirect off; > > > client_max_body_size 300M; > > > sendfile on; > > > send_timeout 300s; > > > } > > > } > > > > > > Со временем сервер либо перестает работать совсем, либо работает через > раз. > > при этом в логах вот такая ошибка: > > > > > [crit] 28474#28474: *401018 SSL_do_handshake() failed (SSL: > > > error:8001B035:lib(128):gng_keyhandle_getset:GNG_ERR_EXPORT_IMPORT > > > error:1419D093:SSL routines:tls_process_cke_gost:decryption failed) > while > > > SSL handshaking, client: x.x.x.x, server: 0.0.0.0:443 > > > > Просьба помочь с решением проблемы. > > Судя по диагностики, ваши проблемы - где-то в GOST engine. Если > по условиям задачи её можно выкинуть - очевидным решением будет > выкинуть. Если выкинуть нельзя - попробуйте поиграться с версиями > OpenSSL'я и GOST engine, а равно попробуйте грузить ключ из файла, > а не через engine. Если ничего из этого не поможет - стоит > стучаться непосредственно к ребятам, занимающимся оной GOST > engine. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Oct 22 17:51:11 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 22 Oct 2018 20:51:11 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgU1Ns?= In-Reply-To: References: <20181022111835.GS56558@mdounin.ru> Message-ID: <20181022175111.GU56558@mdounin.ru> Hello! On Mon, Oct 22, 2018 at 06:24:09PM +0300, Иван Мишин wrote: > если проблема в утилите openssl то почему servicen nignx reload исцеляет > систему? Потому что OpenSSL - это библиотека, которую использует nginx. А баги - часто проявляются не сразу, а только после определённого времени работы процесса. Наиболее простой пример ошибки, которая начинает проявляться только после некоторого времени работы процесса - отсутствующая инициализация выделенной памяти в 0, когда таковая инициализация нужна. Сразу после запуска процесса проблемы не будет - так как свежеполученные от системы страницы всё равно проинициализированы в 0. Однако со временем часть аллокаций начинает получать память не из системы, а из ранее освобождённых аллокаций в том же процессе - и там уже будут не обязательно нули, и могут начать вылезать ошибки. > На том же сервере работает еще и apache (очевидно с тем же openssl) и он > такой проблемы не имеет Баги имеют свойство проявляться по разному в зависимости от того, что именно и как используется. Даже если у вас рядом стоит Apache с той же нагрузкой, теми же GOST-шифрами и тоже с загрузкой ключей через engine (что сомнительно, потому что Apache, AFAIK, так просто не умеет) - это говорит лишь о том, что проблема почему-то не проявляется в Apache, но проявляется в nginx. О природе проблемы это говорит приблизительно ничего. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue Oct 23 15:40:19 2018 From: nginx-forum на forum.nginx.org (analytic) Date: Tue, 23 Oct 2018 11:40:19 -0400 Subject: =?UTF-8?B?0J7RiNC40LHQutCwINGB0LHQvtGA0LrQuCBkZWIgbmdpbnggMS4xNS41?= Message-ID: <9e897008e2d1181efc63345697d76c91.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Подскажите, пожалуйста, как устранить ошибку сборки ./configure: error: invalid option "--includedir=${prefix}/include". После запуска ./configure ошибок не выявлено. Все зависимости удовлетворены. Makefle собирается. В процессе выполнения команды dh_make --single --createorig получаю такую ошибку Скрин: https://bit.ly/2PNipiq Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281670,281670#msg-281670 From mdounin на mdounin.ru Tue Oct 23 16:09:58 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 23 Oct 2018 19:09:58 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDRgdCx0L7RgNC60LggZGViIG5naW54IDEuMTUuNQ==?= In-Reply-To: <9e897008e2d1181efc63345697d76c91.NginxMailingListRussian@forum.nginx.org> References: <9e897008e2d1181efc63345697d76c91.NginxMailingListRussian@forum.nginx.org> Message-ID: <20181023160958.GA56558@mdounin.ru> Hello! On Tue, Oct 23, 2018 at 11:40:19AM -0400, analytic wrote: > Здравствуйте. > Подскажите, пожалуйста, как устранить ошибку сборки ./configure: error: > invalid option "--includedir=${prefix}/include". > После запуска ./configure ошибок не выявлено. Все зависимости удовлетворены. > Makefle собирается. В процессе выполнения команды > dh_make --single --createorig > получаю такую ошибку > Скрин: https://bit.ly/2PNipiq Скрипт ./configure ничего не знает про параметр "--includedir", который ему пытается передавать dh_auto_configure. Очевидное решение - не использовать dh_auto_configure. -- Maxim Dounin http://mdounin.ru/ From defan на nginx.com Tue Oct 23 16:22:08 2018 From: defan на nginx.com (Andrei Belov) Date: Tue, 23 Oct 2018 19:22:08 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDRgdCx0L7RgNC60LggZGViIG5naW54IDEuMTUuNQ==?= In-Reply-To: <20181023160958.GA56558@mdounin.ru> References: <9e897008e2d1181efc63345697d76c91.NginxMailingListRussian@forum.nginx.org> <20181023160958.GA56558@mdounin.ru> Message-ID: <98C5377D-E425-4D5A-B5E7-404A670466F0@nginx.com> > On 23 Oct 2018, at 19:09, Maxim Dounin wrote: > > Hello! > > On Tue, Oct 23, 2018 at 11:40:19AM -0400, analytic wrote: > >> Здравствуйте. >> Подскажите, пожалуйста, как устранить ошибку сборки ./configure: error: >> invalid option "--includedir=${prefix}/include". >> После запуска ./configure ошибок не выявлено. Все зависимости удовлетворены. >> Makefle собирается. В процессе выполнения команды >> dh_make --single --createorig >> получаю такую ошибку >> Скрин: https://bit.ly/2PNipiq > > Скрипт ./configure ничего не знает про параметр "--includedir", > который ему пытается передавать dh_auto_configure. Очевидное > решение - не использовать dh_auto_configure. Добавлю, что исходные файлы сборок официальных пакетов, распространяемых с nginx.org , доступны публично и могут быть использованы как отправная точка при внесении каких-либо кастомизаций в собственные процессы сборок: http://hg.nginx.org/pkg-oss/file/tip/debian -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum на forum.nginx.org Tue Oct 23 17:31:41 2018 From: nginx-forum на forum.nginx.org (analytic) Date: Tue, 23 Oct 2018 13:31:41 -0400 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDRgdCx0L7RgNC60LggZGViIG5naW54IDEuMTUuNQ==?= In-Reply-To: <20181023160958.GA56558@mdounin.ru> References: <20181023160958.GA56558@mdounin.ru> Message-ID: <95823c9f7d12efa509f4808718479808.NginxMailingListRussian@forum.nginx.org> Я попробовал собрать nginx 1.15.5 checkinstall 1.6.2 в итоге в системе (ubuntu 16.04.05x64) не видно nginx. скрин: https://bit.ly/2yus5aE Ни при выполнении ./configure \ --prefix=/usr/share/nginx \ --conf-path=/etc/nginx/nginx.conf \ --http-log-path=/var/log/nginx/access.log \ --error-log-path=/var/log/nginx/error.log \ --lock-path=/var/lock/nginx.lock \ --pid-path=/run/nginx.pid \ --modules-path=/usr/lib/nginx/modules \ --http-client-body-temp-path=/var/lib/nginx/body \ --http-fastcgi-temp-path=/var/lib/nginx/fastcgi \ --http-proxy-temp-path=/var/lib/nginx/proxy \ --http-scgi-temp-path=/var/lib/nginx/scgi \ --http-uwsgi-temp-path=/var/lib/nginx/uwsgi \ --with-debug \ --with-pcre-jit \ --with-http_stub_status_module \ --with-http_realip_module \ --with-http_auth_request_module \ --with-http_v2_module \ --with-http_dav_module \ --with-http_slice_module \ --with-threads \ --with-http_addition_module \ --with-http_geoip_module=dynamic \ --with-http_gunzip_module \ --with-http_gzip_static_module \ --with-http_sub_module \ --with-http_xslt_module=dynamic \ --with-stream=dynamic \ --with-mail=dynamic ни при make ошибок не было обнаружено. Подскажите, пожалуйста, в чем может быть причина? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281670,281673#msg-281673 From nginx на kinetiksoft.com Tue Oct 23 17:47:25 2018 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Tue, 23 Oct 2018 20:47:25 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDRgdCx0L7RgNC60LggZGViIG5naW54IDEuMTUuNQ==?= In-Reply-To: <95823c9f7d12efa509f4808718479808.NginxMailingListRussian@forum.nginx.org> References: <20181023160958.GA56558@mdounin.ru> <95823c9f7d12efa509f4808718479808.NginxMailingListRussian@forum.nginx.org> Message-ID: <38c264c3-137f-c0e9-de46-7f8e8e0d3597@kinetiksoft.com> Здравствуйте. Причина в том, что Вы не там смотрите. бинарник nginx скорее всего в одной из директорий sbin. Пробуйте искать его из-под рута. Если не найдете внимательно изучите вывод checkinstall он совершенно точно пишет куда какие файлы кладёт. Но для начала, прежде, чем заниматься самосборкой пакетов, рекомендую получше освоится в используемой ОС. В частности с https://wiki.debian.org/BuildingTutorial или аналогичным под ubuntu. 23.10.2018 20:31, analytic пишет: > Я попробовал собрать nginx 1.15.5 checkinstall 1.6.2 в итоге в системе > (ubuntu 16.04.05x64) не видно nginx. > скрин: https://bit.ly/2yus5aE > Ни при выполнении > ./configure \ > --prefix=/usr/share/nginx \ > --conf-path=/etc/nginx/nginx.conf \ > --http-log-path=/var/log/nginx/access.log \ > --error-log-path=/var/log/nginx/error.log \ > --lock-path=/var/lock/nginx.lock \ > --pid-path=/run/nginx.pid \ > --modules-path=/usr/lib/nginx/modules \ > --http-client-body-temp-path=/var/lib/nginx/body \ > --http-fastcgi-temp-path=/var/lib/nginx/fastcgi \ > --http-proxy-temp-path=/var/lib/nginx/proxy \ > --http-scgi-temp-path=/var/lib/nginx/scgi \ > --http-uwsgi-temp-path=/var/lib/nginx/uwsgi \ > --with-debug \ > --with-pcre-jit \ > --with-http_stub_status_module \ > --with-http_realip_module \ > --with-http_auth_request_module \ > --with-http_v2_module \ > --with-http_dav_module \ > --with-http_slice_module \ > --with-threads \ > --with-http_addition_module \ > --with-http_geoip_module=dynamic \ > --with-http_gunzip_module \ > --with-http_gzip_static_module \ > --with-http_sub_module \ > --with-http_xslt_module=dynamic \ > --with-stream=dynamic \ > --with-mail=dynamic > > ни при make ошибок не было обнаружено. > Подскажите, пожалуйста, в чем может быть причина? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281670,281673#msg-281673 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart на nginx.com Thu Oct 25 18:49:31 2018 From: vbart на nginx.com (Valentin V. Bartenev) Date: Thu, 25 Oct 2018 21:49:31 +0300 Subject: =?UTF-8?B?0KDQtdC70LjQtyBVbml0IDEuNQ==?= Message-ID: <8285619.O4d345SvCC@vbart-workstation> Здравствуйте. Рад сообщить о выпуске новой версии NGINX Unit. Основным новшеством выпуска является предварительная поддержка Node.js. К сожалению, пока ещё не поддерживаются WebSockets и есть проблема с работой "promises". Тем не менее, некоторые наши пользователи уже начали тестирование ещё до выпуска: - https://medium.com/house-organ/what-an-absolute-unit-a36851e72554 Теперь это сделать ещё проще, т.к. пакет для Node.js опубликован в npm: - https://www.npmjs.com/package/unit-http Пробуйте и сообщайте нам о своих впечатлениях: - Github: https://github.com/nginx/unit/issues - список рассылки: https://mailman.nginx.org/mailman/listinfo/unit Работа по улучшению поддержки Node.js будет продолжаться в будущих версиях. Кроме того, ведется работа над поддержкой WebSockets, модулем для Java, гибкой маршрутизацией запросов и отдачей статического контента. Изменения в Unit 1.5 25.10.2018 *) Изменение: у объекта приложения для Go "type" изменен на "external". *) Добавление: начальная версия пакета для Node.js с базовой поддержкой запросов и ответов по HTTP. *) Добавление: совместимость с LibreSSL. *) Добавление: в ./configure добавлены параметры --libdir и --incdir для установки заголовков и статической библиотеки libunit. *) Исправление: при отправке ответа могло преждевременно закрываться соединение; ошибка появилась в версии 1.3. *) Исправление: процессы приложений могли прекращать обработку запросов, при этом в лог записывался alert "last message send failed: Resource temporarily unavailable"; ошибка появилась в версии 1.4. *) Исправление: приложения на Go не работали, если Unit был собран с использованием Си библиотеки musl. -- Валентин Бартенев From ilya.strahov на gmail.com Fri Oct 26 06:10:07 2018 From: ilya.strahov на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KHRgtGA0LDRhdC+0LI=?=) Date: Fri, 26 Oct 2018 09:10:07 +0300 Subject: Nginx+memcached Message-ID: Здравствуйте. Если кто-то использовал на проде конструкцию Nginx+memcached, поделитесь опытом пожалуйста. Если есть под рукой годный cookbook, буду благодарен. Возможно существуют какие-то альтернативы с redis, couchbase, etc... По нагрузке, в пике 2000 tps от клиентов, обновление кэша предположим 100 tps. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Fri Oct 26 07:35:21 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 26 Oct 2018 12:35:21 +0500 Subject: =?UTF-8?B?0LrQsNC6INGB0L7Qs9C70LDRgdC+0LLQsNGC0YwgcHJveHlfY29ubmVjdF90aW1l?= =?UTF-8?B?b3V0INC4IEluaXRpYWwgUlRPID8=?= Message-ID: привет, возьмем, к примеру, Linux, у него ретрансмит первоначального SYN жестко задан 3 сек (меняется только патчем ядра) допустим, мы хотим отзывчивость нашего приложения, у нас достаточно реплик, мы задаем proxy_connect_timeout 100ms; выглядит логично, но в случае пиковой загрузки канала и сброса первоначального SYN получается следующее а) ядро переотправило бы пакет и все было бы хорошо, но это было бы через 3 сек б) мы ждем ACK в течение 100мс есть какие-то бест практисы, как с этим работать ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From s.pishulin на yandex.ru Fri Oct 26 12:52:47 2018 From: s.pishulin на yandex.ru (=?utf-8?B?0J/QuNGJ0YPQu9C40L0g0KHQtdGA0LPQtdC5?=) Date: Fri, 26 Oct 2018 15:52:47 +0300 Subject: Без темы Message-ID: <10239981540558367@iva3-294f9af87d55.qloud-c.yandex.net> Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Fri Oct 26 15:09:56 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 26 Oct 2018 18:09:56 +0300 Subject: =?UTF-8?B?UmU6INC60LDQuiDRgdC+0LPQu9Cw0YHQvtCy0LDRgtGMIHByb3h5X2Nvbm5lY3Rf?= =?UTF-8?B?dGltZW91dCDQuCBJbml0aWFsIFJUTyA/?= In-Reply-To: References: Message-ID: <20181026150956.GJ56558@mdounin.ru> Hello! On Fri, Oct 26, 2018 at 12:35:21PM +0500, Илья Шипицин wrote: > привет, > > возьмем, к примеру, Linux, у него ретрансмит первоначального SYN жестко > задан 3 сек (меняется только патчем ядра) > > допустим, мы хотим отзывчивость нашего приложения, у нас достаточно реплик, > мы задаем > > proxy_connect_timeout 100ms; > > выглядит логично, но в случае пиковой загрузки канала и сброса > первоначального SYN получается следующее > > а) ядро переотправило бы пакет и все было бы хорошо, но это было бы через 3 > сек > б) мы ждем ACK в течение 100мс > > есть какие-то бест практисы, как с этим работать ? IMHO, в зависимости от внешних факторов имеет смысл использовать два подхода: 1. Ставить таймауты так, чтобы хотя бы один ретрансмит оно переживало. BTW, на современных линуксах RTO уже давно 1 секунда, RFC6298. 2. Ставить таймауты как угодно, и при необходимости полагаться на proxy_next_upstream и/или error_page. Если бэкенд один - то для работы proxy_next_upstream можно добавить тот же IP-адрес ещё раз. -- Maxim Dounin http://mdounin.ru/ From bgx на protva.ru Fri Oct 26 16:19:16 2018 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 26 Oct 2018 19:19:16 +0300 Subject: =?UTF-8?B?UmU6INC60LDQuiDRgdC+0LPQu9Cw0YHQvtCy0LDRgtGMIHByb3h5X2Nvbm5lY3Rf?= =?UTF-8?B?dGltZW91dCDQuCBJbml0aWFsIFJUTyA/?= In-Reply-To: References: Message-ID: <20181026161916.GT5158@protva.ru> On Fri, Oct 26, 2018 at 12:35:21PM +0500, Илья Шипицин wrote: > возьмем, к примеру, Linux, у него ретрансмит первоначального SYN жестко > задан 3 сек (меняется только патчем ядра) Время для ретрансмита первоначального syn'a (rto) в большинстве реализаций tcp/ip (в том числе в линуксе) вычисляется динамически, в зависимости от накопленной статистики по маршруту. В ядре есть ограничения для таймеров: по умолчанию rto_min в 200ms и rto_max в 120s. Поменять rto_min можно через ip route. Это популярно обсуждается, например, здесь: https://unix.stackexchange.com/questions/210367/changing-the-tcp-rto-value-in-linux там есть ссылка на заметку по вычислению таймеров и rfc. -- Eugene Berdnikov From chipitsine на gmail.com Fri Oct 26 16:48:49 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 26 Oct 2018 21:48:49 +0500 Subject: =?UTF-8?B?UmU6INC60LDQuiDRgdC+0LPQu9Cw0YHQvtCy0LDRgtGMIHByb3h5X2Nvbm5lY3Rf?= =?UTF-8?B?dGltZW91dCDQuCBJbml0aWFsIFJUTyA/?= In-Reply-To: <20181026161916.GT5158@protva.ru> References: <20181026161916.GT5158@protva.ru> Message-ID: пт, 26 окт. 2018 г. в 21:19, Evgeniy Berdnikov : > On Fri, Oct 26, 2018 at 12:35:21PM +0500, Илья Шипицин wrote: > > возьмем, к примеру, Linux, у него ретрансмит первоначального SYN > жестко > > задан 3 сек (меняется только патчем ядра) > > Время для ретрансмита первоначального syn'a (rto) в большинстве > реализаций tcp/ip (в том числе в линуксе) вычисляется динамически, > в зависимости от накопленной статистики по маршруту. > В ядре есть ограничения для таймеров: по умолчанию rto_min в 200ms > 200ms это ретрансмит любого пакета кроме первоначального SYN ? или именно первоначального ? > и rto_max в 120s. Поменять rto_min можно через ip route. > Это популярно обсуждается, например, здесь: > > https://unix.stackexchange.com/questions/210367/changing-the-tcp-rto-value-in-linux > там есть ссылка на заметку по вычислению таймеров и rfc. > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sat Oct 27 11:03:31 2018 From: nginx-forum на forum.nginx.org (Pavel-1) Date: Sat, 27 Oct 2018 07:03:31 -0400 Subject: =?UTF-8?B?TmdpbngsINC+0YjQuNCx0LrQuC4=?= Message-ID: привет. 1) отправляю команду - service nginx start 2) вот такой ответ - Job for nginx.service failed because the control process exited with error code. See "systemctl status nginx.service" and "journalctl -xe" for details. 3) отправляю команду - service nginx status 4) вырезал из ответа - Active: failed (Result: exit-code) since Sat 2018-10-27 19:55:47 +09; 1min 31s ago Docs: http://nginx.org/en/docs/ Process: 7561 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=1/FAILURE) окт 27 19:55:47 Tigina-Debian nginx[7561]: nginx: [emerg] still could not bind() окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Control process exited, code=exited status=1 окт 27 19:55:47 Tigina-Debian systemd[1]: Failed to start nginx - high performance web server. окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Unit entered failed state. окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Failed with result 'exit-code'. Посоветуйте как решить проблему с запуском. !!Версию показывает нормально!! P.S. много форумов просмотрел, пока проблему не решил. P.S.S. если кто может помочь решить ошибку в реальном времени, пишите в личку свой скайп. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281707,281707#msg-281707 From nginx-forum на forum.nginx.org Sat Oct 27 11:05:02 2018 From: nginx-forum на forum.nginx.org (Pavel-1) Date: Sat, 27 Oct 2018 07:05:02 -0400 Subject: =?UTF-8?B?UmU6IE5naW54LCDQvtGI0LjQsdC60LguIChEZWJpYW4gOSk=?= In-Reply-To: References: Message-ID: Pavel-1 Wrote: ------------------------------------------------------- > привет. > 1) отправляю команду - > service nginx start > > 2) вот такой ответ - > Job for nginx.service failed because the control process exited > with error code. > See "systemctl status nginx.service" and "journalctl -xe" for > details. > > 3) отправляю команду - > service nginx status > > 4) вырезал из ответа - > Active: failed (Result: exit-code) since Sat 2018-10-27 19:55:47 > +09; 1min 31s ago > Docs: http://nginx.org/en/docs/ > Process: 7561 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf > (code=exited, status=1/FAILURE) > окт 27 19:55:47 Tigina-Debian nginx[7561]: nginx: [emerg] still > could not bind() > окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Control > process exited, code=exited status=1 > окт 27 19:55:47 Tigina-Debian systemd[1]: Failed to start nginx - > high performance web server. > окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Unit > entered failed state. > окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Failed > with result 'exit-code'. > > Посоветуйте как решить проблему с запуском. !!Версию показывает > нормально!! > > P.S. много форумов просмотрел, пока проблему не решил. > P.S.S. если кто может помочь решить ошибку в реальном времени, пишите > в личку свой скайп. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281707,281708#msg-281708 From s.pishulin на yandex.ru Sat Oct 27 16:33:59 2018 From: s.pishulin на yandex.ru (=?utf-8?B?0J/QuNGJ0YPQu9C40L0g0KHQtdGA0LPQtdC5?=) Date: Sat, 27 Oct 2018 19:33:59 +0300 Subject: =?UTF-8?B?0LIg0L/QsNC/0LrQtSAvdmFyL2NhY2hlL25naW54L3BpY2NhY2hlINGE0LDQudC7?= =?UTF-8?B?0Ysg0L3QtSDRgdC+0LfQtNCw0Y7RgtGB0Y8sINCwINC/0LDQv9C60LAg0LQ=?= =?UTF-8?B?0LvRjyDQstGA0LXQvNC10L3QvdGL0YUg0YTQsNC50LvQvtCyINC90LUg0L4=?= =?UTF-8?B?0YfQuNGJ0LDQtdGC0YHRjyAvdmFyL2NhY2hlL25naW54L3Byb3h5X3RlbXA=?= Message-ID: <16434131540658039@iva7-7c2970ec7645.qloud-c.yandex.net> Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sat Oct 27 16:49:54 2018 From: nginx-forum на forum.nginx.org (analytic) Date: Sat, 27 Oct 2018 12:49:54 -0400 Subject: =?UTF-8?B?UmU6IE5naW54LCDQvtGI0LjQsdC60Lgu?= In-Reply-To: References: Message-ID: <4be59b3b895287415ce6570b42926e7e.NginxMailingListRussian@forum.nginx.org> Попробуйте выполнить journalctl -u nginx и посмотрите что там в ошибках. Так же проверьте лог error. Какие там ошибки. Обычно он находится здесь /var/log/nginx/error.log Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281707,281710#msg-281710 From gmm на csdoc.com Sat Oct 27 16:54:05 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Sat, 27 Oct 2018 19:54:05 +0300 Subject: =?UTF-8?B?UmU6INCyINC/0LDQv9C60LUgL3Zhci9jYWNoZS9uZ2lueC9waWNjYWNoZSDRhNCw?= =?UTF-8?B?0LnQu9GLINC90LUg0YHQvtC30LTQsNGO0YLRgdGPLCDQsCDQv9Cw0L/QutCw?= =?UTF-8?B?INC00LvRjyDQstGA0LXQvNC10L3QvdGL0YUg0YTQsNC50LvQvtCyINC90LUg?= =?UTF-8?B?0L7Rh9C40YnQsNC10YLRgdGPIC92YXIvY2FjaGUvbmdpbngvcHJveHlfdGVt?= =?UTF-8?B?cA==?= In-Reply-To: <16434131540658039@iva7-7c2970ec7645.qloud-c.yandex.net> References: <16434131540658039@iva7-7c2970ec7645.qloud-c.yandex.net> Message-ID: On 27.10.2018 19:33, Пищулин Сергей wrote: > nginx version: nginx/1.6.2 > я так понял у rename это какой то код ошибки4294967294нигде не нашел что это значит > кто может подсказать, в чем проблема > заранее спасибо. Первым делом - имеет смысл взять самую последнюю версию nginx 1.15.5 и проверить, воспроизводится ли проблема там. Скачать самую последнюю версию можно с официального сайта: http://nginx.org/en/linux_packages.html#mainline -- Best regards, Gena From nginx-forum на forum.nginx.org Sat Oct 27 16:56:46 2018 From: nginx-forum на forum.nginx.org (sergwed) Date: Sat, 27 Oct 2018 12:56:46 -0400 Subject: =?UTF-8?B?0L3QsNGB0YLRgNC+0LnQutCwINC60LXRiNC40YDQvtCy0LDQvdC40Y8=?= Message-ID: Добрый день! Настроил кеширование nginx proxy_cache_path /var/cache/nginx/piccache levels=2 keys_zone=piccache:15m inactive=15m max_size=200m; server { listen 81; proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504 http_403 http_404; location /pic/ { proxy_cache_valid 200 15m; proxy_cache_key "$request_uri|$request_body"; proxy_hide_header "Set-Cookie"; proxy_cache_methods POST; proxy_ignore_headers "Cache-Control" "Expires"; proxy_cache piccache; proxy_pass http://backend; } proxy_set_header Host $host:$server_port; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-Proto $scheme; } server { listen 82; proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504 http_403 http_404; location /pic/ { proxy_cache_valid 200 15m; proxy_cache_key "$request_uri|$request_body"; proxy_hide_header "Set-Cookie"; proxy_cache_methods POST; proxy_ignore_headers "Cache-Control" "Expires"; proxy_cache piccache; proxy_pass http://backend; proxy_set_header Host $host:$server_port; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-Proto $scheme; } server { listen 83; location /pic/ { proxy_cache_valid 200 15m; proxy_cache_key "$request_uri|$request_body"; proxy_hide_header "Set-Cookie"; proxy_cache_methods POST; proxy_ignore_headers "Cache-Control" "Expires"; proxy_cache piccache; proxy_pass http://backend; } proxy_set_header Host $host:$server_port; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-Proto $scheme; } Но почему-то в папке /var/cache/nginx/piccache файлы не создаются, а папка для временных файлов не очищается /var/cache/nginx/proxy_temp Через strace вижу такое chmod("/var/cache/nginx/proxy_temp/5/18/0000554185", 0600) = 0 rename("/var/cache/nginx/proxy_temp/5/18/0000554185", "/var/cache/nginx/piccache/b7/6d45a7319a3cf5d68022b0c8b55147b7") = 4294967294 fstat(32, {st_mode=S_IFREG|0600, st_size=797, ...}) = 0 close(31) Версия nginx -v nginx version: nginx/1.6.2 я так понял у rename это какой то код ошибки 4294967294 нигде не нашел что это значит кто может подсказать, в чем проблема заранее спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281712,281712#msg-281712 From nginx-forum на forum.nginx.org Sat Oct 27 18:19:43 2018 From: nginx-forum на forum.nginx.org (analytic) Date: Sat, 27 Oct 2018 14:19:43 -0400 Subject: =?UTF-8?B?0J/QvtC00LTQtdGA0LbQutCwIFRMUzEuMw==?= Message-ID: <024489c081a6ffe6e691919d985e4864.NginxMailingListRussian@forum.nginx.org> Всем привет. Ситуация следующая. Собрал nginx 1.15.5 с openssl 1.1.1. nginx version: nginx/1.15.5 built by gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10) built with OpenSSL 1.1.1 11 Sep 2018 TLS SNI support enabled configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/run/nginx.pid --lock-path=/run/lock/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=www-data --group=www-data --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_slice_module --with-threads --with-stream --with-stream_ssl_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_v2_module --with-openssl=/opt/cpf/nginx/nginx-1.15.5/openssl-1.1.1 --with-openssl-opt=enable-tls1_3 --add-module=/opt/cpf/nginx/nginx-1.15.5/brotli --add-module=/opt/cpf/nginx/nginx-1.15.5/ngx_cache_purge-2.3 Включил в настройках поддержку TLS1.3 ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; ssl_ciphers 'TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM- SHA256:TLS13-AES-256-GCM-SHA384:ECDHE:!COMPLEMENTOFDEFAULT'; Однако при проверки через ssllabs.com TLS1.3 нет. Что еще нужно сделать, что бы заработал этот TLS1.3? Я правильно понимаю, что Nginx собирается со статической версией OpenSSL и это дает ему независимость от версии OpenSSL в операционной системе? P.S. Проверил cloudflare.com все через тот же ssllabs.com, там поддержка TLS1.3 есть. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281713,281713#msg-281713 From nginx-forum на forum.nginx.org Sun Oct 28 00:28:00 2018 From: nginx-forum на forum.nginx.org (Pavel-1) Date: Sat, 27 Oct 2018 20:28:00 -0400 Subject: =?UTF-8?B?UmU6IE5naW54LCDQvtGI0LjQsdC60Lgu?= In-Reply-To: <4be59b3b895287415ce6570b42926e7e.NginxMailingListRussian@forum.nginx.org> References: <4be59b3b895287415ce6570b42926e7e.NginxMailingListRussian@forum.nginx.org> Message-ID: <9a32f2c90396d21cdf9c673d2dc5edd3.NginxMailingListRussian@forum.nginx.org> ошибки те же, что и при проверке статуса. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281707,281714#msg-281714 From chipitsine на gmail.com Sun Oct 28 07:16:29 2018 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 28 Oct 2018 12:16:29 +0500 Subject: =?UTF-8?B?UmU6IE5naW54LCDQvtGI0LjQsdC60Lgu?= In-Reply-To: References: Message-ID: Покажите вывод от команды nginx -t On Sat, Oct 27, 2018, 4:03 PM Pavel-1 wrote: > привет. > 1) отправляю команду - > service nginx start > > 2) вот такой ответ - > Job for nginx.service failed because the control process exited with > error code. > See "systemctl status nginx.service" and "journalctl -xe" for details. > > 3) отправляю команду - > service nginx status > > 4) вырезал из ответа - > Active: failed (Result: exit-code) since Sat 2018-10-27 19:55:47 +09; > 1min 31s ago > Docs: http://nginx.org/en/docs/ > Process: 7561 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf > (code=exited, status=1/FAILURE) > окт 27 19:55:47 Tigina-Debian nginx[7561]: nginx: [emerg] still could > not bind() > окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Control > process > exited, code=exited status=1 > окт 27 19:55:47 Tigina-Debian systemd[1]: Failed to start nginx - high > performance web server. > окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Unit entered > failed state. > окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Failed with > result 'exit-code'. > > Посоветуйте как решить проблему с запуском. !!Версию показывает нормально!! > > P.S. много форумов просмотрел, пока проблему не решил. > P.S.S. если кто может помочь решить ошибку в реальном времени, пишите в > личку свой скайп. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,281707,281707#msg-281707 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon Oct 29 11:37:36 2018 From: nginx-forum на forum.nginx.org (Pavel-1) Date: Mon, 29 Oct 2018 07:37:36 -0400 Subject: =?UTF-8?B?UmU6IE5naW54LCDQvtGI0LjQsdC60Lgu?= In-Reply-To: References: Message-ID: <9af5ac82cf45ae40f6d05324b1bf49d1.NginxMailingListRussian@forum.nginx.org> nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281707,281722#msg-281722 From gmm на csdoc.com Mon Oct 29 11:57:38 2018 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 29 Oct 2018 13:57:38 +0200 Subject: =?UTF-8?B?UmU6IE5naW54LCDQvtGI0LjQsdC60Lgu?= In-Reply-To: <9a32f2c90396d21cdf9c673d2dc5edd3.NginxMailingListRussian@forum.nginx.org> References: <4be59b3b895287415ce6570b42926e7e.NginxMailingListRussian@forum.nginx.org> <9a32f2c90396d21cdf9c673d2dc5edd3.NginxMailingListRussian@forum.nginx.org> Message-ID: On 28.10.2018 3:28, Pavel-1 wrote: > ошибки те же, что и при проверке статуса. Какую ошибку nginx пишет в файле /var/log/nginx/error.log ? Если "[emerg] still could not bind()" то это говорит о том, что кто-то уже занял порт, например, 80 или 443, или что там написано у вас в конфигурации nginx. Занять этот порт может другой веб-сервер, например, httpd. Кто именно слушает на 80 и 433 порту можно посмотреть с помощью команды # netstat -tunlp Как решать проблему: надо выключить другой веб-сервер перед запуском nginx, тогда все будет работать нормально. -- Best regards, Gena From mdounin на mdounin.ru Mon Oct 29 12:15:47 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 29 Oct 2018 15:15:47 +0300 Subject: =?UTF-8?B?UmU6IE5naW54LCDQvtGI0LjQsdC60Lgu?= In-Reply-To: References: Message-ID: <20181029121547.GL56558@mdounin.ru> Hello! On Sat, Oct 27, 2018 at 07:03:31AM -0400, Pavel-1 wrote: > привет. > 1) отправляю команду - > service nginx start > > 2) вот такой ответ - > Job for nginx.service failed because the control process exited with > error code. > See "systemctl status nginx.service" and "journalctl -xe" for details. > > 3) отправляю команду - > service nginx status > > 4) вырезал из ответа - > Active: failed (Result: exit-code) since Sat 2018-10-27 19:55:47 +09; > 1min 31s ago > Docs: http://nginx.org/en/docs/ > Process: 7561 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf > (code=exited, status=1/FAILURE) > окт 27 19:55:47 Tigina-Debian nginx[7561]: nginx: [emerg] still could > not bind() > окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Control process > exited, code=exited status=1 > окт 27 19:55:47 Tigina-Debian systemd[1]: Failed to start nginx - high > performance web server. > окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Unit entered > failed state. > окт 27 19:55:47 Tigina-Debian systemd[1]: nginx.service: Failed with > result 'exit-code'. > > Посоветуйте как решить проблему с запуском. !!Версию показывает нормально!! Сообщение от nginx тут видно ровно одно: nginx: [emerg] still could not bind() Чуть ранее должно быть ещё пять сообщений на уровне emerg, содержащих детали о том, на какой адрес nginx пытался сделать bind(), и почему у него это не получилось. Как-то так: nginx: [emerg] bind() to 0.0.0.0:8080 failed (48: Address already in use) nginx: [emerg] bind() to 0.0.0.0:8080 failed (48: Address already in use) nginx: [emerg] bind() to 0.0.0.0:8080 failed (48: Address already in use) nginx: [emerg] bind() to 0.0.0.0:8080 failed (48: Address already in use) nginx: [emerg] bind() to 0.0.0.0:8080 failed (48: Address already in use) nginx: [emerg] still could not bind() Странно, что в вашем случае их нет - но, возможно, по какой-то причине systemd их не показывает. Загляните в лог nginx'а и/или попробуйте запустить nginx руками. Обычно такие проблемы случаются, если вы пытаетесь запустить nginx на порту, который уже занят другим сервером. Смотрите вывод "ss -nltp" или "netstat -an | grep LISTEN" и сравните с тем, что у вас в конфигурации nginx и на какие сокеты он ругается . Кроме того, такие же проблемы будут, если вы пытаетесь заставить nginx для одного и того же порта сделать отдельные bind()'ы на wildcard-адресе и на конкретном IP-адресе - на Линуксе такое запрещено. Либо же если у вас в конфиге nginx'а в разных модулях сконфигурированы конфликтующие listen-сокеты (e.g., "listen 80" в http и "listen 80" в stream) - сам nginx проблемы не увидет, но запуститься из-за конфликта не сможет. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Mon Oct 29 12:30:09 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 29 Oct 2018 15:30:09 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LrQsCBUTFMxLjM=?= In-Reply-To: <024489c081a6ffe6e691919d985e4864.NginxMailingListRussian@forum.nginx.org> References: <024489c081a6ffe6e691919d985e4864.NginxMailingListRussian@forum.nginx.org> Message-ID: <20181029123009.GM56558@mdounin.ru> Hello! On Sat, Oct 27, 2018 at 02:19:43PM -0400, analytic wrote: > Всем привет. > Ситуация следующая. Собрал nginx 1.15.5 с openssl 1.1.1. > > nginx version: nginx/1.15.5 > built by gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10) > built with OpenSSL 1.1.1 11 Sep 2018 > TLS SNI support enabled > configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong > -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' > --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now > -fPIC' --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx > --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf > --error-log-path=/var/log/nginx/error.log > --http-log-path=/var/log/nginx/access.log --pid-path=/run/nginx.pid > --lock-path=/run/lock/nginx.lock > --http-client-body-temp-path=/var/cache/nginx/client_temp > --http-proxy-temp-path=/var/cache/nginx/proxy_temp > --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp > --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp > --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=www-data > --group=www-data --with-http_ssl_module --with-http_realip_module > --with-http_addition_module --with-http_sub_module --with-http_dav_module > --with-http_flv_module --with-http_gunzip_module > --with-http_gzip_static_module --with-http_random_index_module > --with-http_secure_link_module --with-http_stub_status_module > --with-http_auth_request_module --with-http_slice_module --with-threads > --with-stream --with-stream_ssl_module --with-mail --with-mail_ssl_module > --with-file-aio --with-http_v2_module > --with-openssl=/opt/cpf/nginx/nginx-1.15.5/openssl-1.1.1 > --with-openssl-opt=enable-tls1_3 > --add-module=/opt/cpf/nginx/nginx-1.15.5/brotli > --add-module=/opt/cpf/nginx/nginx-1.15.5/ngx_cache_purge-2.3 > > Включил в настройках поддержку TLS1.3 > > ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE > ssl_prefer_server_ciphers on; > ssl_session_cache shared:SSL:10m; > ssl_session_timeout 10m; > ssl_ciphers 'TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM- > SHA256:TLS13-AES-256-GCM-SHA384:ECDHE:!COMPLEMENTOFDEFAULT'; > > Однако при проверки через ssllabs.com TLS1.3 нет. Что еще нужно сделать, что > бы заработал этот TLS1.3? > Я правильно понимаю, что Nginx собирается со статической версией OpenSSL и > это дает ему независимость от версии OpenSSL в операционной системе? > > P.S. Проверил cloudflare.com все через тот же ssllabs.com, там поддержка > TLS1.3 есть. AFAIK, ssllabs.com пока не научился корректно тестировать поддержку TLS 1.3, и умеет только Draft 28. Попробуйте dev.ssllabs.com, возможно там уже. Подробнее в этих тикетах, например: https://github.com/ssllabs/ssllabs-scan/issues/651 https://github.com/ssllabs/ssllabs-scan/issues/641 Но вообще я бы не рекомендовал полагаться в таких вопросах на SSL Labs. Пользуйтесь "openssl s_client" от OpenSSL 1.1.1 (с которым и собрали nginx). -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Mon Oct 29 21:17:34 2018 From: nginx-forum на forum.nginx.org (analytic) Date: Mon, 29 Oct 2018 17:17:34 -0400 Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LrQsCBUTFMxLjM=?= In-Reply-To: <20181029123009.GM56558@mdounin.ru> References: <20181029123009.GM56558@mdounin.ru> Message-ID: <5ecd9f4ac637ec6cac913754af22dff6.NginxMailingListRussian@forum.nginx.org> Проверил через openssl s_client, не работает TLSv1.3. https://bit.ly/2Ddn7U3 Просто не знаю уже куда копать. А точно не требуется отдельно устанавливать openssl 1.1.1 на сервер? Хватает той, что собралась вместе с nginx? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281713,281734#msg-281734 From vbart на nginx.com Mon Oct 29 21:22:44 2018 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 30 Oct 2018 00:22:44 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LrQsCBUTFMxLjM=?= In-Reply-To: <5ecd9f4ac637ec6cac913754af22dff6.NginxMailingListRussian@forum.nginx.org> References: <20181029123009.GM56558@mdounin.ru> <5ecd9f4ac637ec6cac913754af22dff6.NginxMailingListRussian@forum.nginx.org> Message-ID: <3844538.Zv4KQDC8FQ@vbart-laptop> On Tuesday, 30 October 2018 00:17:34 MSK analytic wrote: > Проверил через openssl s_client, не работает TLSv1.3. > https://bit.ly/2Ddn7U3 > Просто не знаю уже куда копать. > А точно не требуется отдельно устанавливать openssl 1.1.1 на сервер? Хватает > той, что собралась вместе с nginx? > А openssl s_client, что вы запускали для проверки - той же версии, 1.1.1? -- Валентин Бартенев From nginx-forum на forum.nginx.org Mon Oct 29 21:50:32 2018 From: nginx-forum на forum.nginx.org (analytic) Date: Mon, 29 Oct 2018 17:50:32 -0400 Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LrQsCBUTFMxLjM=?= In-Reply-To: <3844538.Zv4KQDC8FQ@vbart-laptop> References: <3844538.Zv4KQDC8FQ@vbart-laptop> Message-ID: <70858e5a309a382369943dd8bffab96b.NginxMailingListRussian@forum.nginx.org> Я точно знаю что это 1.1.1. Я собрал его на другой машине и проводил проверку. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281713,281736#msg-281736 From nginx-forum на forum.nginx.org Tue Oct 30 00:02:01 2018 From: nginx-forum на forum.nginx.org (analytic) Date: Mon, 29 Oct 2018 20:02:01 -0400 Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LrQsCBUTFMxLjM=?= In-Reply-To: <70858e5a309a382369943dd8bffab96b.NginxMailingListRussian@forum.nginx.org> References: <3844538.Zv4KQDC8FQ@vbart-laptop> <70858e5a309a382369943dd8bffab96b.NginxMailingListRussian@forum.nginx.org> Message-ID: <3dcf0eb4f03f5f2a032258ffa0ace5f5.NginxMailingListRussian@forum.nginx.org> Я нашел причину. Как всегда виной не внимательность. У меня завалялся в одной из папок конфиг в котором тоже были настройки TLS, только 1.2. В итоге все привел к правильному виду и TLS1.3 заработал. Теперь бы шифры подобрать, что бы они мобилы маломощные не убивали и в тоже время надежность была нормальная. Всем, спасибо, за помощь. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281713,281738#msg-281738 From nginx-forum на forum.nginx.org Wed Oct 31 15:50:54 2018 From: nginx-forum на forum.nginx.org (kseleznyov) Date: Wed, 31 Oct 2018 11:50:54 -0400 Subject: =?UTF-8?B?0J3QsNGB0YLRgNC+0LnQutCwINC/0YDQvtGC0L7QutC+0LvQsCBGYXN0Q0dJINC0?= =?UTF-8?B?0LvRjyBoaWdoIGxvYWQ=?= Message-ID: <5791b599d293547859d50ce974eadd76.NginxMailingListRussian@forum.nginx.org> Добрый день! Согласно спецификациям, протокол FastCGI позволяет использовать две вещи: 1. Работу по нескольким соединениям, когда веб-сервер открывает не одно, на несколько соединений, по которым передаёт данные Fast CGI. 2. Мультиплексирование, когда по одному FastCGI-соединению одновременно передаются данные нескольких HTTP-запросов. Вопросы: 1. Поддерживает ли nginx указанные выше режимы? 2. Если поддерживает, то как их настроить? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,281762,281762#msg-281762 From mdounin на mdounin.ru Wed Oct 31 16:08:07 2018 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 31 Oct 2018 19:08:07 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdGC0YDQvtC50LrQsCDQv9GA0L7RgtC+0LrQvtC70LAgRmFzdENH?= =?UTF-8?B?SSDQtNC70Y8gaGlnaCBsb2Fk?= In-Reply-To: <5791b599d293547859d50ce974eadd76.NginxMailingListRussian@forum.nginx.org> References: <5791b599d293547859d50ce974eadd76.NginxMailingListRussian@forum.nginx.org> Message-ID: <20181031160807.GY56558@mdounin.ru> Hello! On Wed, Oct 31, 2018 at 11:50:54AM -0400, kseleznyov wrote: > Согласно спецификациям, протокол FastCGI позволяет использовать две вещи: > 1. Работу по нескольким соединениям, когда веб-сервер открывает не одно, на > несколько соединений, по которым передаёт данные Fast CGI. > 2. Мультиплексирование, когда по одному FastCGI-соединению одновременно > передаются данные нескольких HTTP-запросов. > > Вопросы: > 1. Поддерживает ли nginx указанные выше режимы? > 2. Если поддерживает, то как их настроить? Работу по нескольким соединениям nginx поддерживает и работает так без каких-либо дополнительных настроек. По умолчанию для каждого HTTP-запроса открывается отдельное соединение. Мультиплексирование - не поддерживает, каждое соединение в один момент времени используется строго для одного запроса. Если речь идёт про высокие нагрузки в части количества запросов в секунду, может иметь смысл настроить использование постоянных соединений, чтобы единожды открытое соединение после завершения запроса не закрывалось, а использовалось для последующих запросов. Подробнее в документации: http://nginx.org/r/keepalive http://nginx.org/r/fastcgi_keep_conn -- Maxim Dounin http://mdounin.ru/