From nginx-forum на forum.nginx.org Mon May 1 09:05:59 2017 From: nginx-forum на forum.nginx.org (Dothris) Date: Mon, 01 May 2017 05:05:59 -0400 Subject: =?UTF-8?B?Tmdpbngg0LrQsNC6IFNTTCDQutC70LjQtdC90YI=?= Message-ID: <9bf557cc85d0c31eafea7309dae82e5f.NginxMailingListRussian@forum.nginx.org> Добрый день! Подскажите пожалуйста, как сделать Nginx как SSL клиент? nginx version: nginx/1.8.1 Ниже конфиги nginx. server { listen 80; server_name roga-and-kopyta; access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log warn; 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; proxy_set_header Host $host; location = / { proxy_buffering off; proxy_set_header X-Forwarded-For $remote_addr; proxy_ssl_certificate ssl_subscription/client-cert.pem; proxy_ssl_certificate_key ssl_subscription/privkey.key; proxy_pass https://server-in-inet:443; } } Запрос curl -v --header "Content-Type:application/xml" -d "Запрос" http://server-in-inet:443/ В логах Nginx 2017/05/01 08:32:06 [error] 27245#0: *7 SSL_do_handshake() failed (SSL: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:SSL alert number 48) while SSL handshaking to upstream, client: ip-backend-server, server: server-in-inet, request: «POST / HTTP/1.1», upstream: "https://IP-adres-server-in-inet:443", host: «server-in-inet» Почему то upstream: "https://IP-adres-server-in-inet:443" в виде IP сервера, а должен быть в виде Hostname. Что может быть не так? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274002,274002#msg-274002 From andrey на kopeyko.ru Mon May 1 10:50:20 2017 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Mon, 01 May 2017 13:50:20 +0300 Subject: =?UTF-8?B?UmU6IE5naW54INC60LDQuiBTU0wg0LrQu9C40LXQvdGC?= In-Reply-To: <9bf557cc85d0c31eafea7309dae82e5f.NginxMailingListRussian@forum.nginx.org> References: <9bf557cc85d0c31eafea7309dae82e5f.NginxMailingListRussian@forum.nginx.org> Message-ID: Dothris писал 2017-05-01 12:05: > Добрый день! Добрый день, Dothris! > В логах Nginx > > 2017/05/01 08:32:06 [error] 27245#0: *7 SSL_do_handshake() failed (SSL: > error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:SSL > alert > number 48) while SSL handshaking to upstream, client: > ip-backend-server, > server: server-in-inet, request: «POST / HTTP/1.1», upstream: > "https://IP-adres-server-in-inet:443", host: «server-in-inet» > > Почему то upstream: "https://IP-adres-server-in-inet:443" в виде IP > сервера, > а должен быть в виде Hostname. Потому что ваше имя "server-in-inet" может разрешаться в несколько адресов, и в логе nginx точно указывает к какому именно IP он стучался. -- Best regards, Andrey A. Kopeyko From nginx-forum на forum.nginx.org Mon May 1 11:11:44 2017 From: nginx-forum на forum.nginx.org (=?UTF-8?Q? =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9=20=D0=93=D0=B5?= =?UTF-8?Q?=D1=80=D0=B0=D1=81=D0=B8=D0=BC=D0=BE=D0=B2 ?=) Date: Mon, 01 May 2017 07:11:44 -0400 Subject: =?UTF-8?B?dHJ5IGZpbGVzIC0g0L/RgNC40L3Rg9C00LjRgtC10LvRjNC90L4gItC/0LXRgNC1?= =?UTF-8?B?0LnRgtC4IiDQuiDRgdC70LXQtNGD0Y7RidC10LzRgyDQstCw0YDQuNCw0L0=?= =?UTF-8?B?0YLRgw==?= Message-ID: Всем доброго дня. В связи с переездом сайта на новое железо решил в появившееся время пересмотреть конфиги и вспомнил об одном "костыле" который так и не переделал. Итак часть конфига: location /gzipper { #сжималка статичных файлов internal; #Тут происходить создание .gz версии. Главное чтоб вернулся 200 ответ несмотря на результат } location ~* (.+?)(\.m[0-9]+)?\.(js|css)$ { gzip_static on; auth_request /gzipper; try_files $1.min.$3 $1.$3 $uri = @static-file-not-found; } Т.е. при запросе js, css (и ещё нескольких типов), запрос первоначально попадал в локейшн /gzipper. Там по возможности создавался .gz версия файла с нужными правами и временем модификации как у оригинала, а затем try_files отрабатывал как обычно и использовался gzip_static. Сейчас я это делаю с помощь. auth_request и "костыльность" меня не устраивает (хотя вполне себе работает). Отсюда вопрос - можно ли сделать локейшн наподобии location ~* (.+?)(\.m[0-9]+)?\.(js|css)$ { gzip_static on; try_files /gzipper $1.min.$3 $1.$3 $uri = @static-file-not-found; } Т,е. запрос попадал в /gzipper и в зависимости от ответа переходил дальше по цепочке? Заранее благодарен Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274006#msg-274006 From chipitsine на gmail.com Mon May 1 11:24:16 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 1 May 2017 16:24:16 +0500 Subject: =?UTF-8?B?UmU6IE5naW54INC60LDQuiBTU0wg0LrQu9C40LXQvdGC?= In-Reply-To: <9bf557cc85d0c31eafea7309dae82e5f.NginxMailingListRussian@forum.nginx.org> References: <9bf557cc85d0c31eafea7309dae82e5f.NginxMailingListRussian@forum.nginx.org> Message-ID: 2017-05-01 14:05 GMT+05:00 Dothris : > Добрый день! Подскажите пожалуйста, как сделать Nginx как SSL клиент? > nginx version: nginx/1.8.1 > Ниже конфиги nginx. > > server { > listen 80; > server_name roga-and-kopyta; > access_log /var/log/nginx/access.log main; > error_log /var/log/nginx/error.log warn; > 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; > proxy_set_header Host $host; > > location = / { > proxy_buffering off; > proxy_set_header X-Forwarded-For $remote_addr; > proxy_ssl_certificate ssl_subscription/client-cert.pem; > proxy_ssl_certificate_key ssl_subscription/privkey.key; > proxy_pass https://server-in-inet:443; > } > } > > Запрос > > curl -v --header "Content-Type:application/xml" -d "Запрос" > http://server-in-inet:443/ > > В логах Nginx > > 2017/05/01 08:32:06 [error] 27245#0: *7 SSL_do_handshake() failed (SSL: > error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:SSL > alert > number 48) while SSL handshaking to upstream, client: ip-backend-server, > server: server-in-inet, request: «POST / HTTP/1.1», upstream: > "https://IP-adres-server-in-inet:443", host: «server-in-inet» > > Почему то upstream: "https://IP-adres-server-in-inet:443" в виде IP > сервера, > а должен быть в виде Hostname. > "proxy_ssl_server_name on;" включено? > > Что может быть не так? > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,274002,274002#msg-274002 > > _______________________________________________ > 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 May 1 14:21:32 2017 From: nginx-forum на forum.nginx.org (AlexSYSka) Date: Mon, 01 May 2017 10:21:32 -0400 Subject: =?UTF-8?B?bmdpbngg0L3QtSDQvtGC0LLQtdGH0LDQtdGCINC90LAg0LfQsNC/0YDQvtGB0Ysg?= =?UTF-8?B?0LjQtyBWUE4g0YLRg9C90L3QtdC70Y8=?= Message-ID: <38833a8700856affbf2289936afc1cab.NginxMailingListRussian@forum.nginx.org> Всем доброго дня! Есть VPN сервер и VPN клиент. Туннель между ними успешно поднимается, пинги ходят как по IP так и по DNS. Конфиг NGINX: server { listen 80; server_name xxx-xxx.me; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; location ~ \.php$ { proxy_pass http://xxx-xxx:8008; } location / { proxy_pass http://xxx-xxx:8008; index find.php; } } На сервере работает IIS. Если захожу по адресу http://xxx-xxx:8008 - все открывается Если захожу по адресу http://xxx-xxx - ничего не открывается. Почему nginx не отдает в туннель страницу? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274011,274011#msg-274011 From nginx-forum на forum.nginx.org Mon May 1 14:49:46 2017 From: nginx-forum на forum.nginx.org (Dothris) Date: Mon, 01 May 2017 10:49:46 -0400 Subject: =?UTF-8?B?UmU6IE5naW54INC60LDQuiBTU0wg0LrQu9C40LXQvdGC?= In-Reply-To: References: Message-ID: <20901593942f95720a93b4b0d2f2a7cf.NginxMailingListRussian@forum.nginx.org> server { listen 443; server_name server-in-inet; access_log /var/log/nginx/subscription-access.log main; error_log /var/log/nginx/subscription-error.log warn; 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; proxy_set_header Host $host; location = / { proxy_buffering off; proxy_ssl_server_name on; proxy_set_header X-Forwarded-For $remote_addr; proxy_ssl_name "server-in-inet"; proxy_ssl_certificate ssl/client-cert.pem; proxy_ssl_certificate_key ssl/privkey.key; proxy_ssl_trusted_certificate ssl/trusted_ca_cert.pem; proxy_ssl_verify on; proxy_ssl_verify_depth 2; proxy_ssl_session_reuse on; proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2; proxy_ssl_ciphers HIGH:!aNULL:!MD5; proxy_pass https://server-in-inet:443; } } curl -H "Host: server-in-inet" ip-balancera -v --header "Content-Type:application/xml" -d 'CreateOrderRUid5464574descriptionhttp://localhost/approvehttp://localhost/cancelhttp://localhost/decline' http://server-in-inet:443/Exec Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274002,274013#msg-274013 From nginx-forum на forum.nginx.org Mon May 1 14:56:32 2017 From: nginx-forum на forum.nginx.org (Dothris) Date: Mon, 01 May 2017 10:56:32 -0400 Subject: =?UTF-8?B?UmU6IE5naW54INC60LDQuiBTU0wg0LrQu9C40LXQvdGC?= In-Reply-To: <20901593942f95720a93b4b0d2f2a7cf.NginxMailingListRussian@forum.nginx.org> References: <20901593942f95720a93b4b0d2f2a7cf.NginxMailingListRussian@forum.nginx.org> Message-ID: Лог nginx 2017/05/01 17:54:30 [error] 20248#0: *27 SSL_do_handshake() failed (SSL: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:SSL alert number 48) while SSL handshaking to upstream, client: ip-client, server: server-in-inet, request: "POST / HTTP/1.1", upstream: "https://IP-adres-server-in-inet:443/Exec", host: "server-in-inet" Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274002,274014#msg-274014 From nginx-forum на forum.nginx.org Mon May 1 16:53:41 2017 From: nginx-forum на forum.nginx.org (AlexSYSka) Date: Mon, 01 May 2017 12:53:41 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC90LUg0L7RgtCy0LXRh9Cw0LXRgiDQvdCwINC30LDQv9GA0L4=?= =?UTF-8?B?0YHRiyDQuNC3IFZQTiDRgtGD0L3QvdC10LvRjw==?= In-Reply-To: <38833a8700856affbf2289936afc1cab.NginxMailingListRussian@forum.nginx.org> References: <38833a8700856affbf2289936afc1cab.NginxMailingListRussian@forum.nginx.org> Message-ID: <3908fc1ad0b308a8d2831c58a46eaa11.NginxMailingListRussian@forum.nginx.org> Пардоньте, HA-Proxy косячил запросы... удалите тему Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274011,274015#msg-274015 From nginx-forum на forum.nginx.org Tue May 2 08:08:20 2017 From: nginx-forum на forum.nginx.org (Vasiliy P. Melnik) Date: Tue, 02 May 2017 04:08:20 -0400 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: References: Message-ID: <1c3163a63e2038c95e691b8297fff416.NginxMailingListRussian@forum.nginx.org> а чем ну устраивает стандартный путь? gzip on; gzip_min_length 1024; gzip_comp_level 1; gzip_proxied any; gzip_types text/plain text/xml text/css application/x-javascript text/javascript application/json; gzip_buffers 4 64k; Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274023#msg-274023 From nginx-forum на forum.nginx.org Tue May 2 08:26:32 2017 From: nginx-forum на forum.nginx.org (=?UTF-8?Q? =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9=20=D0=93=D0=B5?= =?UTF-8?Q?=D1=80=D0=B0=D1=81=D0=B8=D0=BC=D0=BE=D0=B2 ?=) Date: Tue, 02 May 2017 04:26:32 -0400 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: <1c3163a63e2038c95e691b8297fff416.NginxMailingListRussian@forum.nginx.org> References: <1c3163a63e2038c95e691b8297fff416.NginxMailingListRussian@forum.nginx.org> Message-ID: Vasiliy P. Melnik Wrote: ------------------------------------------------------- > а чем ну устраивает стандартный путь? > > gzip on; > gzip_min_length 1024; > gzip_comp_level 1; > gzip_proxied any; > gzip_types text/plain text/xml text/css application/x-javascript > text/javascript application/json; > gzip_buffers 4 64k; А смысл для каждого клиента "на лету" сжимать один и тот-же файл? По сути в /gzipper лежит простенький скрипт, который проверял наличие .gz файла и сравнивал с датой модификации оригинального файла. Ну и если хоть один пункт не совпадал, то (пере)создавал .gz версию. Опять-же старый сервер был слабенький и приходилось экономить на всём (тотальный кеш всему). И вариант с auth_request рабочий - просто не нравится то, что я его не по назначению использую Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274024#msg-274024 From mdounin на mdounin.ru Tue May 2 12:17:01 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 2 May 2017 15:17:01 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC/0LXRgNC10YHRgtCw0LXRgiDRgdC70LXQtNC40YLRjCDQt9Cw?= =?UTF-8?B?INGA0LDQt9C80LXRgNC+0Lwg0LrQsNGC0LDQu9C+0LPQsCBwcm94eV9jYWNo?= =?UTF-8?B?ZV9wYXRjaA==?= In-Reply-To: References: Message-ID: <20170502121700.GF43932@mdounin.ru> Hello! On Fri, Apr 28, 2017 at 12:22:20PM +0700, Владислав Толмачев wrote: > иногда, в не зависимости от нагрузки, nginx перестает следить за размером > каталога proxy_cache_patch и каталог начинает выходить за пределы > установленного размера и забивает полностью диск. Каталог находится на > raid0 из 12 ssd по 240G, там около 2.5М файлов кэша hls видео > > proxy_cache_path /var/www/nginx/nginx_proxy_cache levels=1:2 > keys_zone=two:1536m inactive=1y max_size=2350G loader_files=1000 > loader_sleep=10ms loader_threshold=8000ms manager_files=500 > manager_threshold=1000ms manager_sleep=50ms use_temp_path=off; > > не помогает kill процесс nginx cache manager, только полный рестарт nginx, > после чего он очищает забитый диск/папку до установленного лимита. > > Что сделать, что бы он не переставал следить за размером кэша? поймать > дебаг трудно так как это может произойти только раз в месяц, а может и > через 2 дня никакой зависимости не выявлено. Стандартные параметры > manager_file или те, которые я установил не дают эффекта, все равно в один > прекрасный момент диск забивается полностью. Кеш перестаёт чистится по max_size, если 20 самых старых элементов в кеше - кем-то заблокированы и не могут быть удалены (при очистке по inactive такие элементы приводят к alert'ам "ignore long locked inactive cache entry"). Появиться такие элементы могут из-за естественных причин - например, какой-то запрос с ними на самом деле очень долго получает ответ от бекенда. Однако на практике чаще всего причина наблюдаемых проблем - падение рабочего процесса, и соответственно оставшиеся от него блокировки. Так что начать стоит с простого - проверить логи на предмет падений рабочих процессов, если они есть - найти и устранить причину падений. Отмечу также, что к аналогичным падению результатам (неочищенные блокировки, и соответственно "сломавшаяся" очистка по max_size, alert'ы "long locked inactive cache entry" при очистке по inactive) может привести и некорректное управление рабочими процессами, в частности - использование SIGTERM (не говоря уже про SIGKILL) для быстрого завершения старых рабочих процессов. -- Maxim Dounin http://nginx.org/ From tolmachev.vlad на gmail.com Tue May 2 12:35:55 2017 From: tolmachev.vlad на gmail.com (=?UTF-8?B?0JLQu9Cw0LTQuNGB0LvQsNCyINCi0L7Qu9C80LDRh9C10LI=?=) Date: Tue, 02 May 2017 12:35:55 +0000 Subject: =?UTF-8?B?UmU6IG5naW54INC/0LXRgNC10YHRgtCw0LXRgiDRgdC70LXQtNC40YLRjCDQt9Cw?= =?UTF-8?B?INGA0LDQt9C80LXRgNC+0Lwg0LrQsNGC0LDQu9C+0LPQsCBwcm94eV9jYWNo?= =?UTF-8?B?ZV9wYXRjaA==?= In-Reply-To: <20170502121700.GF43932@mdounin.ru> References: <20170502121700.GF43932@mdounin.ru> Message-ID: Максим, нельзя ли как-то пофиксить это, я искал в гугле и нашел кучу проблем аналогичного характера и ни одного решения. У меня nginx занимается только проксированием, он без модулей и прочего, абсолютно чистый. Ок не смог он удалить 20 этих элементов, возможно там их тормоз качет (хотя если их сейчас качают то это уже не самый старый элемент), пусть пробует дальше и вернется к ним позже, если в кэше около 2 000 000 элементов. Никаких Sigterm и Sigkill перед переполнением точно нет, сервер никтотне трогает в это время. В логах critical пусто. вт, 2 мая 2017 г. в 19:17, Maxim Dounin : > Hello! > > On Fri, Apr 28, 2017 at 12:22:20PM +0700, Владислав Толмачев wrote: > > > иногда, в не зависимости от нагрузки, nginx перестает следить за размером > > каталога proxy_cache_patch и каталог начинает выходить за пределы > > установленного размера и забивает полностью диск. Каталог находится на > > raid0 из 12 ssd по 240G, там около 2.5М файлов кэша hls видео > > > > proxy_cache_path /var/www/nginx/nginx_proxy_cache levels=1:2 > > keys_zone=two:1536m inactive=1y max_size=2350G loader_files=1000 > > loader_sleep=10ms loader_threshold=8000ms manager_files=500 > > manager_threshold=1000ms manager_sleep=50ms use_temp_path=off; > > > > не помогает kill процесс nginx cache manager, только полный рестарт > nginx, > > после чего он очищает забитый диск/папку до установленного лимита. > > > > Что сделать, что бы он не переставал следить за размером кэша? поймать > > дебаг трудно так как это может произойти только раз в месяц, а может и > > через 2 дня никакой зависимости не выявлено. Стандартные параметры > > manager_file или те, которые я установил не дают эффекта, все равно в > один > > прекрасный момент диск забивается полностью. > > Кеш перестаёт чистится по max_size, если 20 самых старых элементов > в кеше - кем-то заблокированы и не могут быть удалены (при очистке > по inactive такие элементы приводят к alert'ам "ignore long locked > inactive cache entry"). Появиться такие элементы могут из-за > естественных причин - например, какой-то запрос с ними на самом > деле очень долго получает ответ от бекенда. Однако на практике > чаще всего причина наблюдаемых проблем - падение рабочего > процесса, и соответственно оставшиеся от него блокировки. > > Так что начать стоит с простого - проверить логи на предмет > падений рабочих процессов, если они есть - найти и устранить > причину падений. > > Отмечу также, что к аналогичным падению результатам (неочищенные > блокировки, и соответственно "сломавшаяся" очистка по max_size, > alert'ы "long locked inactive cache entry" при очистке по > inactive) может привести и некорректное управление рабочими > процессами, в частности - использование SIGTERM (не говоря уже про > SIGKILL) для быстрого завершения старых рабочих процессов. > > -- > Maxim Dounin > http://nginx.org/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением Толмачев Владислав. tolmachev.vlad на gmail.com skype: vladislaviki icq: 274888266 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From xeioex на nginx.com Tue May 2 14:05:32 2017 From: xeioex на nginx.com (Dmitry Volyntsev) Date: Tue, 2 May 2017 17:05:32 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC/0LXRgNC10YHRgtCw0LXRgiDRgdC70LXQtNC40YLRjCDQt9Cw?= =?UTF-8?B?INGA0LDQt9C80LXRgNC+0Lwg0LrQsNGC0LDQu9C+0LPQsCBwcm94eV9jYWNo?= =?UTF-8?B?ZV9wYXRjaA==?= In-Reply-To: References: <20170502121700.GF43932@mdounin.ru> Message-ID: On 02.05.2017 15:35, Владислав Толмачев wrote: > Максим, нельзя ли как-то пофиксить это, я искал в гугле и нашел кучу > проблем аналогичного характера и ни одного решения. У меня nginx > занимается только проксированием, он без модулей и прочего, абсолютно > чистый. Ок не смог он удалить 20 этих элементов, возможно там их тормоз > качет (хотя если их сейчас качают то это уже не самый старый элемент), > пусть пробует дальше и вернется к ним позже, если в кэше около 2 000 000 > элементов. Никаких Sigterm и Sigkill перед переполнением точно нет, > сервер никтотне трогает в это время. В логах critical пусто. > Вячеслав, а не могли бы вы предоставить более подробную информацию о своей конфигурации nginx? Как то: вывод nginx -V, версию операционной системы, информация о дисковых разделах и релевантный кусок конфига, кроме директивы proxy_cache_path. Лог уровня alert (до и после начала роста кеша), так же мог бы оказаться полезным. > > вт, 2 мая 2017 г. в 19:17, Maxim Dounin >: > > Hello! > > On Fri, Apr 28, 2017 at 12:22:20PM +0700, Владислав Толмачев wrote: > > > иногда, в не зависимости от нагрузки, nginx перестает следить за > размером > > каталога proxy_cache_patch и каталог начинает выходить за пределы > > установленного размера и забивает полностью диск. Каталог находится на > > raid0 из 12 ssd по 240G, там около 2.5М файлов кэша hls видео > > > > proxy_cache_path /var/www/nginx/nginx_proxy_cache levels=1:2 > > keys_zone=two:1536m inactive=1y max_size=2350G loader_files=1000 > > loader_sleep=10ms loader_threshold=8000ms manager_files=500 > > manager_threshold=1000ms manager_sleep=50ms use_temp_path=off; > > > > не помогает kill процесс nginx cache manager, только полный > рестарт nginx, > > после чего он очищает забитый диск/папку до установленного лимита. > > > > Что сделать, что бы он не переставал следить за размером кэша? поймать > > дебаг трудно так как это может произойти только раз в месяц, а может и > > через 2 дня никакой зависимости не выявлено. Стандартные параметры > > manager_file или те, которые я установил не дают эффекта, все > равно в один > > прекрасный момент диск забивается полностью. > > Кеш перестаёт чистится по max_size, если 20 самых старых элементов > в кеше - кем-то заблокированы и не могут быть удалены (при очистке > по inactive такие элементы приводят к alert'ам "ignore long locked > inactive cache entry"). Появиться такие элементы могут из-за > естественных причин - например, какой-то запрос с ними на самом > деле очень долго получает ответ от бекенда. Однако на практике > чаще всего причина наблюдаемых проблем - падение рабочего > процесса, и соответственно оставшиеся от него блокировки. > > Так что начать стоит с простого - проверить логи на предмет > падений рабочих процессов, если они есть - найти и устранить > причину падений. > > Отмечу также, что к аналогичным падению результатам (неочищенные > блокировки, и соответственно "сломавшаяся" очистка по max_size, > alert'ы "long locked inactive cache entry" при очистке по > inactive) может привести и некорректное управление рабочими > процессами, в частности - использование SIGTERM (не говоря уже про > SIGKILL) для быстрого завершения старых рабочих процессов. > > -- > Maxim Dounin > http://nginx.org/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > -- > > С уважением Толмачев Владислав. > tolmachev.vlad на gmail.com > skype: vladislaviki > icq: 274888266 > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From nginx-forum на forum.nginx.org Tue May 2 14:08:11 2017 From: nginx-forum на forum.nginx.org (Vasiliy P. Melnik) Date: Tue, 02 May 2017 10:08:11 -0400 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: References: Message-ID: <0be3ee25de24b2bf8359340131ce8d9f.NginxMailingListRussian@forum.nginx.org> я не понял как вы проверяете устаревание файла. Каждый раз дергать скрипт и он сверяет файл оригинальный и файл сжатый? try_files он ведь только наличие проверяет Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274030#msg-274030 From mdounin на mdounin.ru Tue May 2 14:31:33 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 2 May 2017 17:31:33 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC/0LXRgNC10YHRgtCw0LXRgiDRgdC70LXQtNC40YLRjCDQt9Cw?= =?UTF-8?B?INGA0LDQt9C80LXRgNC+0Lwg0LrQsNGC0LDQu9C+0LPQsCBwcm94eV9jYWNo?= =?UTF-8?B?ZV9wYXRjaA==?= In-Reply-To: References: <20170502121700.GF43932@mdounin.ru> Message-ID: <20170502143133.GI43932@mdounin.ru> Hello! On Tue, May 02, 2017 at 12:35:55PM +0000, Владислав Толмачев wrote: > Максим, нельзя ли как-то пофиксить это, я искал в гугле и нашел кучу > проблем аналогичного характера и ни одного решения. У меня nginx занимается > только проксированием, он без модулей и прочего, абсолютно чистый. Ок не > смог он удалить 20 этих элементов, возможно там их тормоз качет (хотя если > их сейчас качают то это уже не самый старый элемент), пусть пробует дальше > и вернется к ним позже, если в кэше около 2 000 000 элементов. Никаких > Sigterm и Sigkill перед переполнением точно нет, сервер никтотне трогает в > это время. В логах critical пусто. "Тормоз качает" - не должно быть причиной, nginx складывает в кеш ответ сразу, как получает его от бекенда, и от клиента тут ничего не зависит. Причиной может быть бекенд - если он кешируемый ответ возвращает очень долго. В старых версиях (до 1.11.6) та же проблема могла возникать, если при включённом кеше использовалось проксирование без буферизации и/или проксирование вебсокетов - элемент кеша оставался залоченным до окончания соединения. Получить более подробную информацию о происходящем можно, уменьшив inactive и добившись очистки по нему, в этом случае в аналогичной ситуации будет alert про "ignore long locked inactive cache entry". По идентификатору можно будет узнать, что за ресурс вызвал проблему, и проанализировать возможные причины. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Tue May 2 15:07:05 2017 From: nginx-forum на forum.nginx.org (=?UTF-8?Q? =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9=20=D0=93=D0=B5?= =?UTF-8?Q?=D1=80=D0=B0=D1=81=D0=B8=D0=BC=D0=BE=D0=B2 ?=) Date: Tue, 02 May 2017 11:07:05 -0400 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: <0be3ee25de24b2bf8359340131ce8d9f.NginxMailingListRussian@forum.nginx.org> References: <0be3ee25de24b2bf8359340131ce8d9f.NginxMailingListRussian@forum.nginx.org> Message-ID: <21d34baa1d338abef6c2fc5ada2586dd.NginxMailingListRussian@forum.nginx.org> Vasiliy P. Melnik Wrote: ------------------------------------------------------- > я не понял как вы проверяете устаревание файла. Каждый раз дергать > скрипт и он сверяет файл оригинальный и файл сжатый? try_files он ведь > только наличие проверяет Да. К сожалению сейчас так - при каждом обращении сверяю даты модификации оригинального и сжатого файла. Проблема в том, что с одной стороны есть несколько людей которые правят стили, скрипты и т.д. и заставить их создавать сжатую версию я не могу. С другой - на каждый запрос нового пользователя сжимать на лету было довольно накладно (одноядерный проц. на котором ещё и ssl/http2). Отсюда и возникла идея делать подзапрос, прежде чем отдать файл. И ничего лучше чем auth_request на тот момент не придумалось. А в идеале мне это виделось так, чтобы try_files в первом локейшене проверял даты модификации и если в нём пересоздавалась сжатая версия, то отдать её и одновременно сохранить (fastcgi_store). Если файл не менялся - то перейти на след. вариант и там как обычно Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274032#msg-274032 From nginx-forum на forum.nginx.org Tue May 2 15:21:21 2017 From: nginx-forum на forum.nginx.org (Vasiliy P. Melnik) Date: Tue, 02 May 2017 11:21:21 -0400 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: <21d34baa1d338abef6c2fc5ada2586dd.NginxMailingListRussian@forum.nginx.org> References: <0be3ee25de24b2bf8359340131ce8d9f.NginxMailingListRussian@forum.nginx.org> <21d34baa1d338abef6c2fc5ada2586dd.NginxMailingListRussian@forum.nginx.org> Message-ID: <119d2ac355f0ed4718f3628489902290.NginxMailingListRussian@forum.nginx.org> как по мне, то я бы использовал ngx_http_gzip_static_module , а проход и сверку версий стилей и если отличаются, компрессию - делал бы из скрипта деплоя. Опять же, если чего-то пропустил скрипт компрессии, то обычный gzip on решит вопрос в действительности то что вам хочется это стандартная конструкция - вызвать скрипт, если файл отсутствует З.Ы. с expires 7d; у меня были проблемы - кеш не чистился. Конструкция не моя - зачем была нужна хз. Разбираться не стал и просто переделал на стандартное кеширование нгинксом # location /pic { # root /var/www/i/cache/image/; # try_files $uri @pic_fetch; # expires 7d; # } # # location @pic_fetch { # proxy_pass http://Backend; # rewrite ^/pic/(.*) /image.php?params=$1 break; # } # Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274033#msg-274033 From chipitsine на gmail.com Tue May 2 15:22:27 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 2 May 2017 20:22:27 +0500 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: <21d34baa1d338abef6c2fc5ada2586dd.NginxMailingListRussian@forum.nginx.org> References: <0be3ee25de24b2bf8359340131ce8d9f.NginxMailingListRussian@forum.nginx.org> <21d34baa1d338abef6c2fc5ada2586dd.NginxMailingListRussian@forum.nginx.org> Message-ID: А на каком движке написан сайт? 2 мая 2017 г. 20:07 пользователь Дмитрий Герасимов < nginx-forum на forum.nginx.org> написал: > Vasiliy P. Melnik Wrote: > ------------------------------------------------------- > > я не понял как вы проверяете устаревание файла. Каждый раз дергать > > скрипт и он сверяет файл оригинальный и файл сжатый? try_files он ведь > > только наличие проверяет > > Да. К сожалению сейчас так - при каждом обращении сверяю даты модификации > оригинального и сжатого файла. Проблема в том, что с одной стороны есть > несколько людей которые правят стили, скрипты и т.д. и заставить их > создавать сжатую версию я не могу. С другой - на каждый запрос нового > пользователя сжимать на лету было довольно накладно (одноядерный проц. на > котором ещё и ssl/http2). > > Отсюда и возникла идея делать подзапрос, прежде чем отдать файл. И ничего > лучше чем auth_request на тот момент не придумалось. > А в идеале мне это виделось так, чтобы try_files в первом локейшене > проверял > даты модификации и если в нём пересоздавалась сжатая версия, то отдать её и > одновременно сохранить (fastcgi_store). Если файл не менялся - то перейти > на > след. вариант и там как обычно > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,274006,274032#msg-274032 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue May 2 15:31:43 2017 From: nginx-forum на forum.nginx.org (=?UTF-8?Q? =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9=20=D0=93=D0=B5?= =?UTF-8?Q?=D1=80=D0=B0=D1=81=D0=B8=D0=BC=D0=BE=D0=B2 ?=) Date: Tue, 02 May 2017 11:31:43 -0400 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: References: Message-ID: Илья Шипицин Wrote: ------------------------------------------------------- > А на каком движке написан сайт? Полностью рукописный Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274034,274035#msg-274035 From nginx-forum на forum.nginx.org Tue May 2 15:38:06 2017 From: nginx-forum на forum.nginx.org (=?UTF-8?Q? =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9=20=D0=93=D0=B5?= =?UTF-8?Q?=D1=80=D0=B0=D1=81=D0=B8=D0=BC=D0=BE=D0=B2 ?=) Date: Tue, 02 May 2017 11:38:06 -0400 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: References: Message-ID: P.S. я также рассматривал вариант сделать подзапрос после отдачи основного файла. Но так, чтобы nginx не дожидался его завершения (что-то типо javascript ajax, и да - nginScript установлен). В принципе задержка в один запрос (когда клиент получит старую версию из gz файла) это некритично. Но ничего похожего не нашел Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274034,274036#msg-274036 From nginx-forum на forum.nginx.org Tue May 2 15:39:31 2017 From: nginx-forum на forum.nginx.org (Vasiliy P. Melnik) Date: Tue, 02 May 2017 11:39:31 -0400 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: References: Message-ID: зачем такие сложности? как происходит деплой у Вас ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274034,274037#msg-274037 From chipitsine на gmail.com Tue May 2 15:56:27 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 2 May 2017 20:56:27 +0500 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: References: Message-ID: Попросите фронтендеров прикрутить webpack 2 мая 2017 г. 20:31 пользователь Дмитрий Герасимов < nginx-forum на forum.nginx.org> написал: > Илья Шипицин Wrote: > ------------------------------------------------------- > > А на каком движке написан сайт? > > Полностью рукописный > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,274034,274035#msg-274035 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue May 2 15:57:41 2017 From: nginx-forum на forum.nginx.org (=?UTF-8?Q? =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9=20=D0=93=D0=B5?= =?UTF-8?Q?=D1=80=D0=B0=D1=81=D0=B8=D0=BC=D0=BE=D0=B2 ?=) Date: Tue, 02 May 2017 11:57:41 -0400 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: References: Message-ID: <5c2741fdc10643a21a6b6d05a357667e.NginxMailingListRussian@forum.nginx.org> Vasiliy P. Melnik Wrote: ------------------------------------------------------- > зачем такие сложности? как происходит деплой у Вас ? Да его как такового нет :). Коллектив у нас небольшой. Вся техническая составляющая сайта на мне. Есть девочка дизайнер, которая хочет видеть свои правки "здесь и сейчас". Плюс начальник, который в моё отсутствие и под мою диктовку может что-нибудь подправить. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274034,274038#msg-274038 From nginx-forum на forum.nginx.org Tue May 2 16:09:25 2017 From: nginx-forum на forum.nginx.org (=?UTF-8?Q? =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9=20=D0=93=D0=B5?= =?UTF-8?Q?=D1=80=D0=B0=D1=81=D0=B8=D0=BC=D0=BE=D0=B2 ?=) Date: Tue, 02 May 2017 12:09:25 -0400 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: References: Message-ID: Илья Шипицин Wrote: ------------------------------------------------------- > Попросите фронтендеров прикрутить webpack Спасибо. Начал читать - пока похоже на "из пушки по воробьям". Но попробую разобраться Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274046#msg-274046 From chipitsine на gmail.com Tue May 2 16:22:21 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 2 May 2017 21:22:21 +0500 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: References: Message-ID: 2 мая 2017 г., 21:09 пользователь "Дмитрий Герасимов" < nginx-forum на forum.nginx.org> написал: > Илья Шипицин Wrote: > ------------------------------------------------------- > > Попросите фронтендеров прикрутить webpack > > > Спасибо. Начал читать - пока похоже на "из пушки по воробьям". Но попробую > разобраться > там есть как минимум 2 сценария - либо обработка стилей и скриптов в реальном времени, для этого нужен сервер на node.js, и это - да, из пушки по воробьям, либо предварительная упаковка скриптов и стилей в момент выкладки сайта. кажется, второе, это ваш случай > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,274006,274046#msg-274046 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue May 2 16:33:17 2017 From: nginx-forum на forum.nginx.org (=?UTF-8?Q? =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9=20=D0=93=D0=B5?= =?UTF-8?Q?=D1=80=D0=B0=D1=81=D0=B8=D0=BC=D0=BE=D0=B2 ?=) Date: Tue, 02 May 2017 12:33:17 -0400 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: References: Message-ID: <752bf44e01707bb50d02e53decfd8476.NginxMailingListRussian@forum.nginx.org> Илья Шипицин Wrote: ------------------------------------------------------- > > там есть как минимум 2 сценария - либо обработка стилей и скриптов в > реальном времени, для этого нужен сервер на node.js, и это - да, из > пушки > по воробьям, либо предварительная упаковка скриптов и стилей в момент > выкладки сайта. кажется, второе, это ваш случай > Если бы это были только скрипты и стили, то проблемы нет - я могу их сжимать на момент подключения к странице (изначально так и было). Но там ещё шрифты, xml-ки для разных сервисов, pdf, которые постоянно изменяются Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274049#msg-274049 From chipitsine на gmail.com Tue May 2 16:51:42 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 2 May 2017 21:51:42 +0500 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: <752bf44e01707bb50d02e53decfd8476.NginxMailingListRussian@forum.nginx.org> References: <752bf44e01707bb50d02e53decfd8476.NginxMailingListRussian@forum.nginx.org> Message-ID: 2 мая 2017 г., 21:33 пользователь "Дмитрий Герасимов" < nginx-forum на forum.nginx.org> написал: > Илья Шипицин Wrote: > ------------------------------------------------------- > > > > там есть как минимум 2 сценария - либо обработка стилей и скриптов в > > реальном времени, для этого нужен сервер на node.js, и это - да, из > > пушки > > по воробьям, либо предварительная упаковка скриптов и стилей в момент > > выкладки сайта. кажется, второе, это ваш случай > > > > > Если бы это были только скрипты и стили, то проблемы нет - я могу их > сжимать > на момент подключения к странице (изначально так и было). > Но там ещё шрифты, xml-ки для разных сервисов, pdf, которые постоянно > изменяются > > gzip не очень затратный по ресурсам вариант компрессии. мы в тесте видим производительность 24 мегабайта в секунду на 1 ядро. нет особых проблем с тем, чтобы жать на лету. вы точно считали, что предварительное сжатие вам дает выигрыш ? (в случае brotli это действительно так https://blog.cloudflare.com/results-experimenting-brotli/ ) > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,274006,274049#msg-274049 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue May 2 17:02:04 2017 From: nginx-forum на forum.nginx.org (=?UTF-8?Q? =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9=20=D0=93=D0=B5?= =?UTF-8?Q?=D1=80=D0=B0=D1=81=D0=B8=D0=BC=D0=BE=D0=B2 ?=) Date: Tue, 02 May 2017 13:02:04 -0400 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: References: Message-ID: <0166ede22a08cf3adb44aa81b04eb0b7.NginxMailingListRussian@forum.nginx.org> Илья Шипицин Wrote: ------------------------------------------------------- > gzip не очень затратный по ресурсам вариант компрессии. > мы в тесте видим производительность 24 мегабайта в секунду на 1 ядро. > нет особых проблем с тем, чтобы жать на лету. > > вы точно считали, что предварительное сжатие вам дает выигрыш ? > > (в случае brotli это действительно так > https://blog.cloudflare.com/results-experimenting-brotli/ ) Сейчас уже не могу сказать - старого сервера уже два дня нет. Но думаю, что всё-таки да - быстрей. По логике - просто отдать файл должно быть быстрей чем сжать (причём сжать для каждого нового клиента) и отдать сжатый контент. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274051#msg-274051 From chipitsine на gmail.com Tue May 2 17:05:17 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 2 May 2017 22:05:17 +0500 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: <0166ede22a08cf3adb44aa81b04eb0b7.NginxMailingListRussian@forum.nginx.org> References: <0166ede22a08cf3adb44aa81b04eb0b7.NginxMailingListRussian@forum.nginx.org> Message-ID: 2 мая 2017 г., 22:02 пользователь "Дмитрий Герасимов" < nginx-forum на forum.nginx.org> написал: > Илья Шипицин Wrote: > ------------------------------------------------------- > > > gzip не очень затратный по ресурсам вариант компрессии. > > мы в тесте видим производительность 24 мегабайта в секунду на 1 ядро. > > нет особых проблем с тем, чтобы жать на лету. > > > > вы точно считали, что предварительное сжатие вам дает выигрыш ? > > > > (в случае brotli это действительно так > > https://blog.cloudflare.com/results-experimenting-brotli/ ) > > > Сейчас уже не могу сказать - старого сервера уже два дня нет. Но думаю, что > всё-таки да - быстрей. По логике - просто отдать файл должно быть быстрей > чем сжать (причём сжать для каждого нового клиента) и отдать сжатый > контент. > > неважно, есть старый сервер или нет. решение перейти на эту схему было принято, когда он работал, и вероятно, было исследование на тему "как лучше". чтобы показать результаты исследования, необязательно, чтобы сервер был сейчас доступен > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,274006,274051#msg-274051 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue May 2 18:18:30 2017 From: nginx-forum на forum.nginx.org (Vasiliy P. Melnik) Date: Tue, 02 May 2017 14:18:30 -0400 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: <5c2741fdc10643a21a6b6d05a357667e.NginxMailingListRussian@forum.nginx.org> References: <5c2741fdc10643a21a6b6d05a357667e.NginxMailingListRussian@forum.nginx.org> Message-ID: гит - это не сложно, можно на гитлабе аккаунты сделать, там кажись 5 аккаунтов бесплатно, научить программеров его использовать - тоже ничего выдающегося. Дальше скрипт деплоя и в него же добавить архивирование нужных файлов, отдавать через gzip_static Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274055#msg-274055 From chipitsine на gmail.com Tue May 2 18:34:19 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 2 May 2017 23:34:19 +0500 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: References: <5c2741fdc10643a21a6b6d05a357667e.NginxMailingListRussian@forum.nginx.org> Message-ID: Если вы про gitlab.com, там из коробки есть gitlab-ci, т.е. выкладку можно привязать к комиту 2 мая 2017 г. 23:18 пользователь "Vasiliy P. Melnik" < nginx-forum на forum.nginx.org> написал: > гит - это не сложно, можно на гитлабе аккаунты сделать, там кажись 5 > аккаунтов бесплатно, научить программеров его использовать - тоже ничего > выдающегося. Дальше скрипт деплоя и в него же добавить архивирование нужных > файлов, отдавать через gzip_static > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,274006,274055#msg-274055 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed May 3 13:26:56 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Wed, 03 May 2017 09:26:56 -0400 Subject: client_body_temp_path - permissions Message-ID: Здравствуйте. Сейчас файлы создаются с правами 0600 нужно хотя бы 0660, в документации нашел только настройку прав для store proxy_store_access user:rw group:rw all:r; Есть аналогичная настройка для client_body_temp_path? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274059,274059#msg-274059 From nginx-forum на forum.nginx.org Wed May 3 15:14:35 2017 From: nginx-forum на forum.nginx.org (=?UTF-8?Q? =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9=20=D0=93=D0=B5?= =?UTF-8?Q?=D1=80=D0=B0=D1=81=D0=B8=D0=BC=D0=BE=D0=B2 ?=) Date: Wed, 03 May 2017 11:14:35 -0400 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: References: Message-ID: Вообщем всем спасибо. Сегодня узнал о существовании incron (век живи, век учись), при помощи онного и решил проблему Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274061#msg-274061 From nginx-forum на forum.nginx.org Wed May 3 15:35:05 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Wed, 03 May 2017 11:35:05 -0400 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyAtINC/0YDQuNC90YPQtNC40YLQtdC70YzQvdC+ICLQv9C1?= =?UTF-8?B?0YDQtdC50YLQuCIg0Log0YHQu9C10LTRg9GO0YnQtdC80YMg0LLQsNGA0Lg=?= =?UTF-8?B?0LDQvdGC0YM=?= In-Reply-To: References: Message-ID: Дмитрий Герасимов Wrote: ------------------------------------------------------- > Вообщем всем спасибо. Сегодня узнал о существовании incron (век живи, > век учись), при помощи онного и решил проблему Есть аналог API в systemd https://www.freedesktop.org/software/systemd/man/systemd.path.html Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274062#msg-274062 From alex.hha на gmail.com Thu May 4 13:57:56 2017 From: alex.hha на gmail.com (Alex Domoradov) Date: Thu, 4 May 2017 16:57:56 +0300 Subject: =?UTF-8?B?0J3QtSDRgNCw0LHQvtGC0LDQtdGCIHBlcmxfc2V0INC/0YDQuCDQuNGB0L/QvtC7?= =?UTF-8?B?0YzQt9C+0LLQsNC90LjQuCBwZXJsIG1vZHVsZQ==?= Message-ID: Привет всем, имеется $ nginx -V nginx version: nginx/1.12.0 built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) built with OpenSSL 1.0.1 14 Mar 2012 TLS SNI support enabled configure arguments: --prefix=/opt/nginx --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_gzip_static_module --with-http_stub_status_module --with-http_addition_module --with-cc-opt=-Wno-error --with-ld-opt= --add-module=/var/lib/gems/1.8/gems/passenger-5.1.3/src/nginx_module --with-http_perl_module Мне надо логировать определенную переменную окружения, сделал простейший конфиг user capistrano; worker_processes 1; env RACK_ENV; http { passenger_root /var/lib/gems/1.8/gems/passenger-5.1.3; passenger_ruby /usr/bin/ruby1.8; perl_set $RACK_ENV 'sub { return $ENV{"RACK_ENV"}; }'; log_format awslogs '[$time_local] env=TEST-$RACK_ENV\n'; } В итоге в логах получаю [04/May/2017:13:49:28 +0000] env=TEST- Я что то упускаю? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From diraria на yandex.ru Sat May 6 09:29:38 2017 From: diraria на yandex.ru (=?utf-8?B?0JTQvNC40YLRgNC40Lkg0JzRg9GA0LfQuNC9?=) Date: Sat, 06 May 2017 12:29:38 +0300 Subject: =?UTF-8?B?0JrQuNGA0LjQu9C70LjRh9C10YHQutC40LUg0YHQuNC80LLQvtC70Ysg0LIgJHVy?= =?UTF-8?B?aSDQsiBhY2Nlc3NfbG9n?= Message-ID: <4648961494062978@web31g.yandex.ru> Вложение в формате HTML было извлечено… URL: From diraria на yandex.ru Sat May 6 09:33:10 2017 From: diraria на yandex.ru (=?utf-8?B?0JTQvNC40YLRgNC40Lkg0JzRg9GA0LfQuNC9?=) Date: Sat, 06 May 2017 12:33:10 +0300 Subject: =?UTF-8?B?0JrQuNGA0LjQu9C70LjRh9C10YHQutC40LUg0YHQuNC80LLQvtC70Ysg0LIgJHVy?= =?UTF-8?B?aSDQsiBhY2Nlc3NfbG9n?= Message-ID: <4653601494063190@web31g.yandex.ru> Добрый день. Есть ли способ сделать так, чтобы при запросе на "http://example.com/привет" в лог записывался uri запроса в человекочитаемом формате (то есть "/привет")? Если сделать вот так: log_format main '$uri $request_uri'; access_log  logs/access.log  main; то при запросе на "http://example.com/привет" в лог запишется /\xD0\xBF\xD1\x80\xD0\xB8\xD0\xB2\xD0\xB5\xD1\x82 /%D0%BF%D1%80%D0%B8%D0%B2%D0%B5%D1%82, то есть $request_uri пишется с процентами, а каждый символ $uri кодируется как "\x??" Спасибо! --  С уважением, Дмитрий Мурзин From tolmachev.vlad на gmail.com Sat May 6 11:56:20 2017 From: tolmachev.vlad на gmail.com (=?UTF-8?B?0JLQu9Cw0LTQuNGB0LvQsNCyINCi0L7Qu9C80LDRh9C10LI=?=) Date: Sat, 6 May 2017 14:56:20 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC/0LXRgNC10YHRgtCw0LXRgiDRgdC70LXQtNC40YLRjCDQt9Cw?= =?UTF-8?B?INGA0LDQt9C80LXRgNC+0Lwg0LrQsNGC0LDQu9C+0LPQsCBwcm94eV9jYWNo?= =?UTF-8?B?ZV9wYXRjaA==?= In-Reply-To: <20170502143133.GI43932@mdounin.ru> References: <20170502121700.GF43932@mdounin.ru> <20170502143133.GI43932@mdounin.ru> Message-ID: nginx -V nginx version: nginx/1.13.0 built by gcc 4.9.2 (Debian 4.9.2-10) built with OpenSSL 1.0.2h 3 May 2016 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-openssl=/root/openssl-1.0.2h nginx.conf: user www-data www-data; worker_processes 50; worker_cpu_affinity auto; timer_resolution 100ms; worker_rlimit_nofile 65535; proxy_cache_path /var/www/nginx/nginx_proxy_cache levels=1:1 keys_zone=two:1536m inactive=1y max_size=2350G loader_files=1000 loader_sleep=10ms loader_threshold=8000ms manager_files=500 manager_threshold=1000ms manager_sleep=50ms use_temp_path=off; server { proxy_cache_min_uses 2; proxy_cache_revalidate on; proxy_cache two; proxy_cache_lock on; proxy_cache_lock_age 90s; proxy_cache_lock_timeout 90s; proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504 http_404; proxy_cache_key "$proxy_host$uri"; proxy_read_timeout 180s; proxy_connect_timeout 180s; proxy_send_timeout 180s; proxy_ignore_headers X-Accel-Limit-Rate X-Accel-Expires Expires Cache-Control Set-Cookie Vary; proxy_max_temp_file_size 0; proxy_read_timeout 70s; proxy_connect_timeout 70s; proxy_send_timeout 70s; proxy_buffers 32 384k; proxy_force_ranges on; output_buffers 32 384k; send_timeout 180s; sendfile on; sendfile_max_chunk 512k; location / { proxy_pass http://backend; } } Диск состоит из raid0 12 SSD по 240Gb, линк 10Gbps в мир, при пике выдает около 8-9Gbps iotop показывает, что в пик диск не занят на 100% Проблема с тем, что nginx перестает чистить папку proxy_cache_path может случиться в любой момент (не обязательно в пик посещаемости) например в 5 утра, когда трафик почти на нуле, помогает только рестарт nginx С уважением Толмачев Владислав. tolmachev.vlad на gmail.com skype: vladislaviki icq: 274888266 2 мая 2017 г., 17:31 пользователь Maxim Dounin написал: > Hello! > > On Tue, May 02, 2017 at 12:35:55PM +0000, Владислав Толмачев wrote: > > > Максим, нельзя ли как-то пофиксить это, я искал в гугле и нашел кучу > > проблем аналогичного характера и ни одного решения. У меня nginx > занимается > > только проксированием, он без модулей и прочего, абсолютно чистый. Ок не > > смог он удалить 20 этих элементов, возможно там их тормоз качет (хотя > если > > их сейчас качают то это уже не самый старый элемент), пусть пробует > дальше > > и вернется к ним позже, если в кэше около 2 000 000 элементов. Никаких > > Sigterm и Sigkill перед переполнением точно нет, сервер никтотне трогает > в > > это время. В логах critical пусто. > > "Тормоз качает" - не должно быть причиной, nginx складывает в кеш > ответ сразу, как получает его от бекенда, и от клиента тут ничего > не зависит. Причиной может быть бекенд - если он кешируемый ответ > возвращает очень долго. В старых версиях (до 1.11.6) та же > проблема могла возникать, если при включённом кеше использовалось > проксирование без буферизации и/или проксирование вебсокетов - > элемент кеша оставался залоченным до окончания соединения. > > Получить более подробную информацию о происходящем можно, уменьшив > inactive и добившись очистки по нему, в этом случае в аналогичной > ситуации будет alert про "ignore long locked inactive cache > entry". По идентификатору можно будет узнать, что за ресурс > вызвал проблему, и проанализировать возможные причины. > > -- > Maxim Dounin > http://nginx.org/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From basil на vpm.net.ua Sat May 6 14:53:27 2017 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Sat, 6 May 2017 17:53:27 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC/0LXRgNC10YHRgtCw0LXRgiDRgdC70LXQtNC40YLRjCDQt9Cw?= =?UTF-8?B?INGA0LDQt9C80LXRgNC+0Lwg0LrQsNGC0LDQu9C+0LPQsCBwcm94eV9jYWNo?= =?UTF-8?B?ZV9wYXRjaA==?= In-Reply-To: References: <20170502121700.GF43932@mdounin.ru> <20170502143133.GI43932@mdounin.ru> Message-ID: 1) а почему не сплит ? 2) почему так мало уровней? 3) зачем настраивать лоадер? как по мне то менять дефолтные настройки надо в случае, если четко понимаешь, что делаешь и зачем, а любые поиски решения проблем стоит начинать с возврата к дефолтным настройкам proxy_cache_path /var/lib/nginx/proxy levels=2:2 use_temp_path=off keys_zone=proxy:4m inactive=1h max_size=500m; proxy_cache_path /var/lib/nginx/sda1 levels=2:2 keys_zone=pic_cache_sda1:500m max_size=400g inactive=60d use_temp_path=off; proxy_cache_path /var/lib/nginx/sdb1 levels=2:2 keys_zone=pic_cache_sdb1:500m max_size=400g inactive=60d use_temp_path=off; proxy_cache_path /var/lib/nginx/sdc1 levels=2:2 keys_zone=pic_cache_sdc1:250m max_size=200g inactive=60d use_temp_path=off; proxy_cache_path /var/lib/nginx/sdd1 levels=2:2 keys_zone=pic_cache_sdd1:250m max_size=200g inactive=60d use_temp_path=off; split_clients http://$host$request_uri $domik_pic_cache { 33% pic_cache_sda1; 33% pic_cache_sdb1; 17% pic_cache_sdc1; * pic_cache_sdd1; } 6 мая 2017 г., 14:56 пользователь Владислав Толмачев < tolmachev.vlad на gmail.com> написал: > nginx -V > nginx version: nginx/1.13.0 > built by gcc 4.9.2 (Debian 4.9.2-10) > built with OpenSSL 1.0.2h 3 May 2016 > TLS SNI support enabled > configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx > --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf > --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log > --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock > --http-client-body-temp-path=/var/cache/nginx/client_temp > --http-proxy-temp-path=/var/cache/nginx/proxy_temp > --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp > --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp > --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx > --group=nginx --with-compat --with-file-aio --with-threads > --with-http_addition_module --with-http_auth_request_module > --with-http_dav_module --with-http_flv_module --with-http_gunzip_module > --with-http_gzip_static_module --with-http_mp4_module > --with-http_random_index_module --with-http_realip_module > --with-http_secure_link_module --with-http_slice_module > --with-http_ssl_module --with-http_stub_status_module > --with-http_sub_module --with-http_v2_module --with-mail > --with-mail_ssl_module --with-stream --with-stream_realip_module > --with-stream_ssl_module --with-stream_ssl_preread_module > --with-openssl=/root/openssl-1.0.2h > > nginx.conf: > > user www-data www-data; > worker_processes 50; > worker_cpu_affinity auto; > timer_resolution 100ms; > worker_rlimit_nofile 65535; > > proxy_cache_path /var/www/nginx/nginx_proxy_cache levels=1:1 > keys_zone=two:1536m inactive=1y max_size=2350G loader_files=1000 > loader_sleep=10ms loader_threshold=8000ms manager_files=500 > manager_threshold=1000ms manager_sleep=50ms use_temp_path=off; > > server { > proxy_cache_min_uses 2; > proxy_cache_revalidate on; > proxy_cache two; > proxy_cache_lock on; > proxy_cache_lock_age 90s; > proxy_cache_lock_timeout 90s; > proxy_cache_use_stale error timeout invalid_header updating > http_500 http_502 http_503 http_504 http_404; > proxy_cache_key "$proxy_host$uri"; > proxy_read_timeout 180s; > proxy_connect_timeout 180s; > proxy_send_timeout 180s; > proxy_ignore_headers X-Accel-Limit-Rate X-Accel-Expires > Expires Cache-Control Set-Cookie Vary; > proxy_max_temp_file_size 0; > proxy_read_timeout 70s; > proxy_connect_timeout 70s; > proxy_send_timeout 70s; > proxy_buffers 32 384k; > proxy_force_ranges on; > > output_buffers 32 384k; > send_timeout 180s; > sendfile on; > sendfile_max_chunk 512k; > > > location / { > proxy_pass http://backend; > } > } > > Диск состоит из raid0 12 SSD по 240Gb, линк 10Gbps в мир, при пике выдает > около 8-9Gbps iotop показывает, что в пик диск не занят на 100% > > Проблема с тем, что nginx перестает чистить папку proxy_cache_path может > случиться в любой момент (не обязательно в пик посещаемости) например в 5 > утра, когда трафик почти на нуле, помогает только рестарт nginx > > > > С уважением Толмачев Владислав. > tolmachev.vlad на gmail.com > skype: vladislaviki > icq: 274888266 > > 2 мая 2017 г., 17:31 пользователь Maxim Dounin > написал: > >> Hello! >> >> On Tue, May 02, 2017 at 12:35:55PM +0000, Владислав Толмачев wrote: >> >> > Максим, нельзя ли как-то пофиксить это, я искал в гугле и нашел кучу >> > проблем аналогичного характера и ни одного решения. У меня nginx >> занимается >> > только проксированием, он без модулей и прочего, абсолютно чистый. Ок не >> > смог он удалить 20 этих элементов, возможно там их тормоз качет (хотя >> если >> > их сейчас качают то это уже не самый старый элемент), пусть пробует >> дальше >> > и вернется к ним позже, если в кэше около 2 000 000 элементов. Никаких >> > Sigterm и Sigkill перед переполнением точно нет, сервер никтотне >> трогает в >> > это время. В логах critical пусто. >> >> "Тормоз качает" - не должно быть причиной, nginx складывает в кеш >> ответ сразу, как получает его от бекенда, и от клиента тут ничего >> не зависит. Причиной может быть бекенд - если он кешируемый ответ >> возвращает очень долго. В старых версиях (до 1.11.6) та же >> проблема могла возникать, если при включённом кеше использовалось >> проксирование без буферизации и/или проксирование вебсокетов - >> элемент кеша оставался залоченным до окончания соединения. >> >> Получить более подробную информацию о происходящем можно, уменьшив >> inactive и добившись очистки по нему, в этом случае в аналогичной >> ситуации будет alert про "ignore long locked inactive cache >> entry". По идентификатору можно будет узнать, что за ресурс >> вызвал проблему, и проанализировать возможные причины. >> >> -- >> Maxim Dounin >> http://nginx.org/ >> _______________________________________________ >> 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 tolmachev.vlad на gmail.com Sat May 6 15:02:52 2017 From: tolmachev.vlad на gmail.com (=?UTF-8?B?0JLQu9Cw0LTQuNGB0LvQsNCyINCi0L7Qu9C80LDRh9C10LI=?=) Date: Sat, 06 May 2017 15:02:52 +0000 Subject: =?UTF-8?B?UmU6IG5naW54INC/0LXRgNC10YHRgtCw0LXRgiDRgdC70LXQtNC40YLRjCDQt9Cw?= =?UTF-8?B?INGA0LDQt9C80LXRgNC+0Lwg0LrQsNGC0LDQu9C+0LPQsCBwcm94eV9jYWNo?= =?UTF-8?B?ZV9wYXRjaA==?= In-Reply-To: References: <20170502121700.GF43932@mdounin.ru> <20170502143133.GI43932@mdounin.ru> Message-ID: А зачем сплит, если есть raid0, уровней было 1:2, но это никак не влиет ни на что, как были глюки с переставанием чистки кэша так и остались. Настройки лоадера тоже ни на что не влияют, что стандартные, что нет, тут виснет сам nginx cache manager. сб, 6 мая 2017 г. в 17:53, Vasiliy P. Melnik : > 1) а почему не сплит ? > 2) почему так мало уровней? > 3) зачем настраивать лоадер? как по мне то менять дефолтные настройки надо > в случае, если четко понимаешь, что делаешь и зачем, а любые поиски решения > проблем стоит начинать с возврата к дефолтным настройкам > > proxy_cache_path /var/lib/nginx/proxy levels=2:2 use_temp_path=off > keys_zone=proxy:4m inactive=1h max_size=500m; > > proxy_cache_path /var/lib/nginx/sda1 levels=2:2 > keys_zone=pic_cache_sda1:500m max_size=400g inactive=60d use_temp_path=off; > proxy_cache_path /var/lib/nginx/sdb1 levels=2:2 > keys_zone=pic_cache_sdb1:500m max_size=400g inactive=60d use_temp_path=off; > proxy_cache_path /var/lib/nginx/sdc1 levels=2:2 > keys_zone=pic_cache_sdc1:250m max_size=200g inactive=60d use_temp_path=off; > proxy_cache_path /var/lib/nginx/sdd1 levels=2:2 > keys_zone=pic_cache_sdd1:250m max_size=200g inactive=60d use_temp_path=off; > > split_clients http://$host$request_uri $domik_pic_cache { > 33% pic_cache_sda1; > 33% pic_cache_sdb1; > 17% pic_cache_sdc1; > * pic_cache_sdd1; > } > > > 6 мая 2017 г., 14:56 пользователь Владислав Толмачев < > tolmachev.vlad на gmail.com> написал: > > nginx -V >> nginx version: nginx/1.13.0 >> built by gcc 4.9.2 (Debian 4.9.2-10) >> built with OpenSSL 1.0.2h 3 May 2016 >> TLS SNI support enabled >> configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx >> --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf >> --error-log-path=/var/log/nginx/error.log >> --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid >> --lock-path=/var/run/nginx.lock >> --http-client-body-temp-path=/var/cache/nginx/client_temp >> --http-proxy-temp-path=/var/cache/nginx/proxy_temp >> --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp >> --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp >> --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx >> --with-compat --with-file-aio --with-threads --with-http_addition_module >> --with-http_auth_request_module --with-http_dav_module >> --with-http_flv_module --with-http_gunzip_module >> --with-http_gzip_static_module --with-http_mp4_module >> --with-http_random_index_module --with-http_realip_module >> --with-http_secure_link_module --with-http_slice_module >> --with-http_ssl_module --with-http_stub_status_module >> --with-http_sub_module --with-http_v2_module --with-mail >> --with-mail_ssl_module --with-stream --with-stream_realip_module >> --with-stream_ssl_module --with-stream_ssl_preread_module >> --with-openssl=/root/openssl-1.0.2h >> >> nginx.conf: >> >> user www-data www-data; >> worker_processes 50; >> worker_cpu_affinity auto; >> timer_resolution 100ms; >> worker_rlimit_nofile 65535; >> >> proxy_cache_path /var/www/nginx/nginx_proxy_cache levels=1:1 >> keys_zone=two:1536m inactive=1y max_size=2350G loader_files=1000 >> loader_sleep=10ms loader_threshold=8000ms manager_files=500 >> manager_threshold=1000ms manager_sleep=50ms use_temp_path=off; >> >> server { >> proxy_cache_min_uses 2; >> proxy_cache_revalidate on; >> proxy_cache two; >> proxy_cache_lock on; >> proxy_cache_lock_age 90s; >> proxy_cache_lock_timeout 90s; >> proxy_cache_use_stale error timeout invalid_header updating >> http_500 http_502 http_503 http_504 http_404; >> proxy_cache_key "$proxy_host$uri"; >> proxy_read_timeout 180s; >> proxy_connect_timeout 180s; >> proxy_send_timeout 180s; >> proxy_ignore_headers X-Accel-Limit-Rate X-Accel-Expires >> Expires Cache-Control Set-Cookie Vary; >> proxy_max_temp_file_size 0; >> proxy_read_timeout 70s; >> proxy_connect_timeout 70s; >> proxy_send_timeout 70s; >> proxy_buffers 32 384k; >> proxy_force_ranges on; >> >> output_buffers 32 384k; >> send_timeout 180s; >> sendfile on; >> sendfile_max_chunk 512k; >> >> >> location / { >> proxy_pass http://backend; >> } >> } >> >> Диск состоит из raid0 12 SSD по 240Gb, линк 10Gbps в мир, при пике выдает >> около 8-9Gbps iotop показывает, что в пик диск не занят на 100% >> >> Проблема с тем, что nginx перестает чистить папку proxy_cache_path может >> случиться в любой момент (не обязательно в пик посещаемости) например в 5 >> утра, когда трафик почти на нуле, помогает только рестарт nginx >> >> >> >> С уважением Толмачев Владислав. >> tolmachev.vlad на gmail.com >> skype: vladislaviki >> icq: 274888266 >> >> 2 мая 2017 г., 17:31 пользователь Maxim Dounin >> написал: >> >>> Hello! >>> >>> On Tue, May 02, 2017 at 12:35:55PM +0000, Владислав Толмачев wrote: >>> >>> > Максим, нельзя ли как-то пофиксить это, я искал в гугле и нашел кучу >>> > проблем аналогичного характера и ни одного решения. У меня nginx >>> занимается >>> > только проксированием, он без модулей и прочего, абсолютно чистый. Ок >>> не >>> > смог он удалить 20 этих элементов, возможно там их тормоз качет (хотя >>> если >>> > их сейчас качают то это уже не самый старый элемент), пусть пробует >>> дальше >>> > и вернется к ним позже, если в кэше около 2 000 000 элементов. Никаких >>> > Sigterm и Sigkill перед переполнением точно нет, сервер никтотне >>> трогает в >>> > это время. В логах critical пусто. >>> >>> "Тормоз качает" - не должно быть причиной, nginx складывает в кеш >>> ответ сразу, как получает его от бекенда, и от клиента тут ничего >>> не зависит. Причиной может быть бекенд - если он кешируемый ответ >>> возвращает очень долго. В старых версиях (до 1.11.6) та же >>> проблема могла возникать, если при включённом кеше использовалось >>> проксирование без буферизации и/или проксирование вебсокетов - >>> элемент кеша оставался залоченным до окончания соединения. >>> >>> Получить более подробную информацию о происходящем можно, уменьшив >>> inactive и добившись очистки по нему, в этом случае в аналогичной >>> ситуации будет alert про "ignore long locked inactive cache >>> entry". По идентификатору можно будет узнать, что за ресурс >>> вызвал проблему, и проанализировать возможные причины. >>> >>> -- >>> Maxim Dounin >>> http://nginx.org/ >>> _______________________________________________ >>> 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 >> > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением Толмачев Владислав. tolmachev.vlad на gmail.com skype: vladislaviki icq: 274888266 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sun May 7 23:22:47 2017 From: nginx-forum на forum.nginx.org (ngnx8810773a83) Date: Sun, 07 May 2017 19:22:47 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC/0LXRgNC10YHRgtCw0LXRgiDRgdC70LXQtNC40YLRjCDQt9Cw?= =?UTF-8?B?INGA0LDQt9C80LXRgNC+0Lwg0LrQsNGC0LDQu9C+0LPQsCBwcm94eSBjYWNo?= =?UTF-8?B?ZSBwYXRjaA==?= In-Reply-To: References: Message-ID: Владислав, посмотрите в момент когда проблема с пухнущим кешом уже есть вывод ps axu все ли воркеры запущены в одно и тоже время ? Штатно они все запускаются или при старте или при применении изменений одновременно и все висят или до стопа или нового применения конифга. Но иногда бывет не так. У нас были ситуации, что из за некторых проблем воркеры убивались по 11 сигналу (мастер его перезапускал после смерти, т.е. появлялся новый воркер в замен умершего, в выводе ps у него свежее время старта) и тут все открытые в кеше в данный момент умершим воркером элементы оставались залоченными до смерти мастер процесса. Вообще 11 сигналы видны в логах сервера. У меня проявлялось в залипании в кеше файла, и отдачи его из кеша до посинения. до распухания кеша не доходило, раньше начинались жалобы-разборки с необновлением инофрмации. по некоторым путям (у меня умирание воркера возникало, например в моменты когда все апстримы (в количестве proxy_next_upstream_tries) обламывались в соединении, ну сеть там могрнула или еще что, и 50х ошибка пыталась получться с того же апстрима (скорее всего попадала в / локешн), я в первый раз до дебага даже добрел, там запрос уходит в закрытый сокет кажется, но это было лет 4-5 назад, не очень уже помню). Правка конфигов, чтобы ошибки (то, что указано в error_page, наверное критично толко для 5хх, но обычно и 404 так делаю) всегда оставались локальными у меня проблему снимало. Наверное есть другие варианты, когда воркеры начинают трапаться, но я по этим граблям уже 2 раза ходил именно в таком виде. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273918,274096#msg-274096 From tolmachev.vlad на gmail.com Mon May 8 09:33:36 2017 From: tolmachev.vlad на gmail.com (=?UTF-8?B?0JLQu9Cw0LTQuNGB0LvQsNCyINCi0L7Qu9C80LDRh9C10LI=?=) Date: Mon, 8 May 2017 12:33:36 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC/0LXRgNC10YHRgtCw0LXRgiDRgdC70LXQtNC40YLRjCDQt9Cw?= =?UTF-8?B?INGA0LDQt9C80LXRgNC+0Lwg0LrQsNGC0LDQu9C+0LPQsCBwcm94eSBjYWNo?= =?UTF-8?B?ZSBwYXRjaA==?= In-Reply-To: References: Message-ID: ps -ef | grep nginx root 11230 1 0 Apr28 ? 00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf www-data 11231 11230 0 Apr28 ? 00:38:30 nginx: worker process www-data 11232 11230 0 Apr28 ? 00:44:51 nginx: worker process www-data 11233 11230 0 Apr28 ? 00:39:12 nginx: worker process www-data 11234 11230 0 Apr28 ? 00:49:42 nginx: worker process www-data 11235 11230 0 Apr28 ? 00:41:25 nginx: worker process www-data 11236 11230 0 Apr28 ? 00:51:03 nginx: worker process www-data 11237 11230 0 Apr28 ? 00:47:59 nginx: worker process www-data 11239 11230 0 Apr28 ? 00:49:39 nginx: worker process www-data 11240 11230 0 Apr28 ? 00:48:36 nginx: worker process www-data 11241 11230 0 Apr28 ? 00:48:42 nginx: worker process www-data 11242 11230 0 Apr28 ? 02:01:53 nginx: worker process www-data 11243 11230 0 Apr28 ? 00:52:11 nginx: worker process www-data 11245 11230 1 Apr28 ? 03:08:09 nginx: worker process www-data 11246 11230 0 Apr28 ? 02:10:26 nginx: worker process www-data 11247 11230 0 Apr28 ? 00:35:46 nginx: worker process www-data 11248 11230 0 Apr28 ? 01:30:40 nginx: worker process www-data 11249 11230 0 Apr28 ? 00:55:12 nginx: worker process www-data 11250 11230 0 Apr28 ? 01:20:24 nginx: worker process www-data 11252 11230 1 Apr28 ? 03:19:38 nginx: worker process www-data 11253 11230 18 Apr28 ? 1-20:04:38 nginx: worker process www-data 11254 11230 1 Apr28 ? 02:29:02 nginx: worker process www-data 11255 11230 0 Apr28 ? 00:47:30 nginx: worker process www-data 11256 11230 1 Apr28 ? 02:48:07 nginx: worker process www-data 11257 11230 26 Apr28 ? 2-15:40:24 nginx: worker process www-data 11258 11230 0 Apr28 ? 01:49:24 nginx: worker process www-data 11260 11230 1 Apr28 ? 02:57:51 nginx: worker process www-data 11261 11230 4 Apr28 ? 10:51:18 nginx: worker process www-data 11262 11230 1 Apr28 ? 04:15:18 nginx: worker process www-data 11263 11230 2 Apr28 ? 05:09:28 nginx: worker process www-data 11264 11230 11 Apr28 ? 1-03:54:22 nginx: worker process www-data 11265 11230 0 Apr28 ? 02:21:51 nginx: worker process www-data 11266 11230 0 Apr28 ? 00:52:16 nginx: worker process www-data 11267 11230 1 Apr28 ? 02:39:07 nginx: worker process www-data 11268 11230 2 Apr28 ? 07:12:13 nginx: worker process www-data 11269 11230 0 Apr28 ? 00:58:03 nginx: worker process www-data 11270 11230 1 Apr28 ? 03:39:01 nginx: worker process www-data 11271 11230 0 Apr28 ? 01:06:36 nginx: worker process www-data 11272 11230 0 Apr28 ? 01:39:46 nginx: worker process www-data 11273 11230 0 Apr28 ? 01:00:59 nginx: worker process www-data 11274 11230 0 Apr28 ? 01:24:51 nginx: worker process www-data 11275 11230 0 Apr28 ? 01:11:12 nginx: worker process www-data 11276 11230 0 Apr28 ? 01:54:16 nginx: worker process www-data 11277 11230 0 Apr28 ? 01:04:58 nginx: worker process www-data 11278 11230 0 Apr28 ? 01:16:25 nginx: worker process www-data 11279 11230 34 Apr28 ? 3-13:33:26 nginx: worker process www-data 11280 11230 0 Apr28 ? 00:49:31 nginx: worker process www-data 11281 11230 6 Apr28 ? 16:59:39 nginx: worker process www-data 11282 11230 42 Apr28 ? 4-08:58:05 nginx: worker process www-data 11283 11230 0 Apr28 ? 00:50:54 nginx: worker process www-data 11284 11230 14 Apr28 ? 1-11:39:26 nginx: worker process www-data 11285 11230 0 Apr28 ? 00:39:16 nginx: cache manager process root 16612 16593 0 12:17 pts/0 00:00:00 grep nginx все процессы в момент засирания папки кэша старые, iotop показывает, что io диска на 0,01% занято, это не пик, трафика мало. Такое ощущение, что nginx: cache manager process просто перестает видеть файлы в кэше и не трогает их для удаления в логах error_log нет ничего интересного и похожего на кэш запросы 2017/05/08 12:18:37 [alert] 11263#11263: *110026886 open socket #109 left in connection 148 2017/05/08 12:18:37 [alert] 11263#11263: aborting 2017/05/08 12:18:37 [alert] 11252#11252: *142106454 open socket #76 left in connection 6 2017/05/08 12:18:37 [alert] 11252#11252: aborting 2017/05/08 12:18:37 [alert] 11261#11261: *6376207 open socket #63 left in connection 24 2017/05/08 12:18:37 [alert] 11261#11261: *69762352 open socket #136 left in connection 484 2017/05/08 12:18:37 [alert] 11261#11261: aborting 2017/05/08 12:18:39 [alert] 11270#11270: *41410475 open socket #117 left in connection 28 2017/05/08 12:18:39 [alert] 11270#11270: aborting 2017/05/08 12:18:40 [alert] 11262#11262: *79682996 open socket #5 left in connection 155 2017/05/08 12:18:40 [alert] 11262#11262: aborting 2017/05/08 12:18:41 [alert] 11267#11267: *139231732 open socket #62 left in connection 90 2017/05/08 12:18:41 [alert] 11267#11267: aborting 2017/05/08 12:18:42 [alert] 11268#11268: *140895163 open socket #87 left in connection 127 2017/05/08 12:18:42 [alert] 11268#11268: aborting 2017/05/08 12:19:14 [alert] 11264#11264: *141842028 open socket #457 left in connection 36 2017/05/08 12:19:14 [alert] 11264#11264: *59804808 open socket #113 left in connection 605 2017/05/08 12:19:14 [alert] 11264#11264: aborting 2017/05/08 12:20:33 [alert] 11253#11253: *9766808 open socket #793 left in connection 6 2017/05/08 12:20:33 [alert] 11253#11253: *2126581 open socket #233 left in connection 73 2017/05/08 12:20:33 [alert] 11253#11253: *119203640 open socket #108 left in connection 138 2017/05/08 12:20:33 [alert] 11253#11253: *25842753 open socket #988 left in connection 217 2017/05/08 12:20:33 [alert] 11253#11253: *106856882 open socket #184 left in connection 218 2017/05/08 12:20:33 [alert] 11253#11253: *22117720 open socket #658 left in connection 356 2017/05/08 12:20:33 [alert] 11253#11253: *55550949 open socket #92 left in connection 396 2017/05/08 12:20:33 [alert] 11253#11253: *142165136 open socket #692 left in connection 525 2017/05/08 12:20:33 [alert] 11253#11253: *20058006 open socket #130 left in connection 642 2017/05/08 12:20:33 [alert] 11253#11253: *16505597 open socket #243 left in connection 719 2017/05/08 12:20:33 [alert] 11253#11253: *107135866 open socket #511 left in connection 1069 2017/05/08 12:20:33 [alert] 11253#11253: *107687125 open socket #286 left in connection 1095 С уважением Толмачев Владислав. tolmachev.vlad на gmail.com skype: vladislaviki icq: 274888266 8 мая 2017 г., 2:22 пользователь ngnx8810773a83 написал: > Владислав, посмотрите в момент когда проблема с пухнущим кешом уже есть > вывод ps axu > все ли воркеры запущены в одно и тоже время ? Штатно они все запускаются > или > при старте или при применении изменений одновременно и все висят или до > стопа или нового применения конифга. Но иногда бывет не так. У нас были > ситуации, что из за некторых проблем воркеры убивались по 11 сигналу > (мастер > его перезапускал после смерти, т.е. появлялся новый воркер в замен > умершего, > в выводе ps у него свежее время старта) и тут все открытые в кеше в данный > момент умершим воркером элементы оставались залоченными до смерти мастер > процесса. Вообще 11 сигналы видны в логах сервера. У меня проявлялось в > залипании в кеше файла, и отдачи его из кеша до посинения. до распухания > кеша не доходило, раньше начинались жалобы-разборки с необновлением > инофрмации. по некоторым путям > > (у меня умирание воркера возникало, например в моменты когда все апстримы > (в > количестве proxy_next_upstream_tries) обламывались в соединении, ну сеть > там > могрнула или еще что, и 50х ошибка пыталась получться с того же апстрима > (скорее всего попадала в / локешн), я в первый раз до дебага даже добрел, > там запрос уходит в закрытый сокет кажется, но это было лет 4-5 назад, не > очень уже помню). Правка конфигов, чтобы ошибки (то, что указано в > error_page, наверное критично толко для 5хх, но обычно и 404 так делаю) > всегда оставались локальными у меня проблему снимало. Наверное есть другие > варианты, когда воркеры начинают трапаться, но я по этим граблям уже 2 раза > ходил именно в таком виде. > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,273918,274096#msg-274096 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue May 9 12:49:14 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 09 May 2017 08:49:14 -0400 Subject: Best practices - url versioning static cache In-Reply-To: <2a1b430104df08537a3add72c1eba7d1.NginxMailingListRussian@forum.nginx.org> References: <2a1b430104df08537a3add72c1eba7d1.NginxMailingListRussian@forum.nginx.org> Message-ID: <3e95cebfc3f1d55a0fb2e84b7a2dadeb.NginxMailingListRussian@forum.nginx.org> > Но это требует rewrite директив, в конфиге Nginx, мне это не очень > нравится. Можно без rewrite директив, просто alias location ~ ^/[0-9]+/(.+)$ { alias /var/www/dir/$1; } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272099,274108#msg-274108 From nginx-forum на forum.nginx.org Wed May 10 11:49:52 2017 From: nginx-forum на forum.nginx.org (akartkam) Date: Wed, 10 May 2017 07:49:52 -0400 Subject: =?UTF-8?B?bmdpbngg0LfQsNCz0YDRg9C30LrQsCDRhNCw0LnQu9C+0LIg0LrQsNGA0YLQuNC9?= =?UTF-8?B?0L7QuiDRgSDRgNGD0YHRgdC60LjQvNC4INC40LzQtdC90LDQvNC4INGBINC/?= =?UTF-8?B?0YDQuNGB0YLRi9C60L7QstCw0L3QvdGL0LwgO2pzZXNzaW9uaWQ=?= Message-ID: <720657bda5cdd66bc77a3811958910f1.NginxMailingListRussian@forum.nginx.org> Добрый день. Столкнулся с такой проблемой. На ubuntu сервере совместно работают tomcat8 и nginx 1.10. Второй проксирует запросы с первому. nginx настроен так : server { listen 80; server_name forpostnn.ru; charset utf-8; root /opt/tomcat/webapps/inShop; location ~* ^(/images/|/releated/).+\.(jpg|jpeg|gif|png|pdf)$ { root /usr/share/inShop/webcontent; expires 30d; add_header Pragma public; add_header Cache-Control "public"; rewrite "^(.*);jsessionid=(.*)$" $1 permanent; } location / { proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://127.0.0.1:8080/; } } Проблема в том, что так получилось, что в папке со статическим контентом оказались картинки с русскими именами. При первом открытии окна в браузере (когда еще нет куков и tomcat пристыковывает ко всем urlам ;jsessionid) , nginx не грузит картинки в именах которых есть русские буквы(естественно они url rwrited), говорит , 404. При чем, что интересно, если принудительно открыть картинку в браузере без ;jsessionid , то все ок. Так же никаких проблем не возникает и с картинками, в названии которых нет русских букв. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274123,274123#msg-274123 From mdounin на mdounin.ru Wed May 10 12:56:29 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 10 May 2017 15:56:29 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQs9GA0YPQt9C60LAg0YTQsNC50LvQvtCyINC60LDRgNGC?= =?UTF-8?B?0LjQvdC+0Log0YEg0YDRg9GB0YHQutC40LzQuCDQuNC80LXQvdCw0LzQuCA=?= =?UTF-8?B?0YEg0L/RgNC40YHRgtGL0LrQvtCy0LDQvdC90YvQvCA7anNlc3Npb25pZA==?= In-Reply-To: <720657bda5cdd66bc77a3811958910f1.NginxMailingListRussian@forum.nginx.org> References: <720657bda5cdd66bc77a3811958910f1.NginxMailingListRussian@forum.nginx.org> Message-ID: <20170510125629.GF55433@mdounin.ru> Hello! On Wed, May 10, 2017 at 07:49:52AM -0400, akartkam wrote: > Добрый день. Столкнулся с такой проблемой. На ubuntu сервере совместно > работают tomcat8 и nginx 1.10. Второй проксирует запросы с первому. nginx > настроен так : > > server { > listen 80; > server_name forpostnn.ru; > charset utf-8; > root /opt/tomcat/webapps/inShop; > > location ~* ^(/images/|/releated/).+\.(jpg|jpeg|gif|png|pdf)$ { > root /usr/share/inShop/webcontent; > expires 30d; > add_header Pragma public; > add_header Cache-Control "public"; > rewrite "^(.*);jsessionid=(.*)$" $1 permanent; > } > > > location / { > proxy_set_header X-Forwarded-Host $host; > proxy_set_header X-Forwarded-Server $host; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_pass http://127.0.0.1:8080/; > > } > } > > Проблема в том, что так получилось, что в папке со статическим контентом > оказались картинки с русскими именами. При первом открытии окна в браузере > (когда еще нет куков и tomcat пристыковывает ко всем urlам ;jsessionid) , > nginx не грузит картинки в именах которых есть русские буквы(естественно они > url rwrited), говорит , 404. При чем, что интересно, если принудительно > открыть картинку в браузере без ;jsessionid , то все ок. Так же никаких > проблем не возникает и с картинками, в названии которых нет русских букв. Написанный в конфиге rewrite, по моим представлениям, не должен работать вообще, т.к. если в конце url'а будет ";jsessionid=...", то запрос не попадёт в соответствующий location. Так что что именно у вас происходит - загадка, и в первую очередь непонятно, почему не возникает проблем с картинками без русских букв. Попробуйте начать с простого: возьмите конкретные URL'ы, и посмотрите, что именно с ними происходит, и на каком именно этапе ломается. Ну и посмотрите внимательно в логи nginx'а, там должно быть подробно написано, почему именно 404 - если её действительно вернул nginx. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Wed May 10 13:08:53 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 10 May 2017 16:08:53 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC/0LXRgNC10YHRgtCw0LXRgiDRgdC70LXQtNC40YLRjCDQt9Cw?= =?UTF-8?B?INGA0LDQt9C80LXRgNC+0Lwg0LrQsNGC0LDQu9C+0LPQsCBwcm94eSBjYWNo?= =?UTF-8?B?ZSBwYXRjaA==?= In-Reply-To: References: Message-ID: <20170510130853.GG55433@mdounin.ru> Hello! On Mon, May 08, 2017 at 12:33:36PM +0300, Владислав Толмачев wrote: > ps -ef | grep nginx > root 11230 1 0 Apr28 ? 00:00:00 nginx: master process > /usr/sbin/nginx -c /etc/nginx/nginx.conf > www-data 11231 11230 0 Apr28 ? 00:38:30 nginx: worker process [...] > в логах error_log нет ничего интересного и похожего на кэш запросы > > 2017/05/08 12:18:37 [alert] 11263#11263: *110026886 open socket #109 left > in connection 148 > 2017/05/08 12:18:37 [alert] 11263#11263: aborting > 2017/05/08 12:18:37 [alert] 11252#11252: *142106454 open socket #76 left in > connection 6 > 2017/05/08 12:18:37 [alert] 11252#11252: aborting У вас сокеты текут, nginx пишет об этом alert'ы в логи, и это называется "ничего интересного"? Надо разбираться, что это за сокеты, и почему они текут. Как уже говрилось ранее, двадцати таких утёкших соединений - достаточно, чтобы заблокировать очистку кеша по max_size. Про отладку утекающих сокетов я когда-то писал на http://wiki.nginx.org/Debugging, там ещё вроде даже что-то сохранилось. Если вдруг используется HTTP/2, то начать стоит с простого - отключить. -- Maxim Dounin http://nginx.org/ From alex.hha на gmail.com Wed May 10 13:16:48 2017 From: alex.hha на gmail.com (Alex Domoradov) Date: Wed, 10 May 2017 16:16:48 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiBwZXJsX3NldCDQv9GA0Lgg0LjRgdC/?= =?UTF-8?B?0L7Qu9GM0LfQvtCy0LDQvdC40LggcGVybCBtb2R1bGU=?= In-Reply-To: References: Message-ID: Какие-нибудь идеи/предположения? On Thu, May 4, 2017 at 4:57 PM, Alex Domoradov wrote: > Привет всем, > > имеется > > $ nginx -V > nginx version: nginx/1.12.0 > built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) > built with OpenSSL 1.0.1 14 Mar 2012 > TLS SNI support enabled > configure arguments: --prefix=/opt/nginx --with-http_ssl_module > --with-http_v2_module --with-http_realip_module > --with-http_gzip_static_module --with-http_stub_status_module > --with-http_addition_module --with-cc-opt=-Wno-error --with-ld-opt= > --add-module=/var/lib/gems/1.8/gems/passenger-5.1.3/src/nginx_module > --with-http_perl_module > > Мне надо логировать определенную переменную окружения, сделал простейший > конфиг > > user capistrano; > worker_processes 1; > > env RACK_ENV; > > http { > passenger_root /var/lib/gems/1.8/gems/passenger-5.1.3; > passenger_ruby /usr/bin/ruby1.8; > > perl_set $RACK_ENV 'sub { return $ENV{"RACK_ENV"}; }'; > > log_format awslogs '[$time_local] env=TEST-$RACK_ENV\n'; > } > > В итоге в логах получаю > > [04/May/2017:13:49:28 +0000] env=TEST- > > Я что то упускаю? > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed May 10 13:33:10 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 10 May 2017 16:33:10 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiBwZXJsX3NldCDQv9GA0Lgg0LjRgdC/?= =?UTF-8?B?0L7Qu9GM0LfQvtCy0LDQvdC40LggcGVybCBtb2R1bGU=?= In-Reply-To: References: Message-ID: <20170510133309.GH55433@mdounin.ru> Hello! On Wed, May 10, 2017 at 04:16:48PM +0300, Alex Domoradov wrote: > Какие-нибудь идеи/предположения? > > On Thu, May 4, 2017 at 4:57 PM, Alex Domoradov wrote: > > > Привет всем, > > > > имеется > > > > $ nginx -V > > nginx version: nginx/1.12.0 > > built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) > > built with OpenSSL 1.0.1 14 Mar 2012 > > TLS SNI support enabled > > configure arguments: --prefix=/opt/nginx --with-http_ssl_module > > --with-http_v2_module --with-http_realip_module > > --with-http_gzip_static_module --with-http_stub_status_module > > --with-http_addition_module --with-cc-opt=-Wno-error --with-ld-opt= > > --add-module=/var/lib/gems/1.8/gems/passenger-5.1.3/src/nginx_module > > --with-http_perl_module > > > > Мне надо логировать определенную переменную окружения, сделал простейший > > конфиг > > > > user capistrano; > > worker_processes 1; > > > > env RACK_ENV; > > > > http { > > passenger_root /var/lib/gems/1.8/gems/passenger-5.1.3; > > passenger_ruby /usr/bin/ruby1.8; > > > > perl_set $RACK_ENV 'sub { return $ENV{"RACK_ENV"}; }'; > > > > log_format awslogs '[$time_local] env=TEST-$RACK_ENV\n'; > > } > > > > В итоге в логах получаю > > > > [04/May/2017:13:49:28 +0000] env=TEST- > > > > Я что то упускаю? Переменная окружения, установленная при запуске nginx'а, при таком конфиге должна быть нормально доступна: # RACK_ENV=foo nginx/objs/nginx [10/May/2017:13:25:17 +0000] env=TEST-foo Не следует, однако, ожидать, что установленные где-то в коде на Ruby переменные окружения будут таким образом доступны nginx'у. Переменные окружения локальны для конкретного процесса, а passenger - запускает для выполнения Ruby-кода отдельные процессы. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Wed May 10 13:53:42 2017 From: nginx-forum на forum.nginx.org (akartkam) Date: Wed, 10 May 2017 09:53:42 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC30LDQs9GA0YPQt9C60LAg0YTQsNC50LvQvtCyINC60LDRgNGC?= =?UTF-8?B?0LjQvdC+0Log0YEg0YDRg9GB0YHQutC40LzQuCDQuNC80LXQvdCw0LzQuCA=?= =?UTF-8?B?0YEg0L/RgNC40YHRgtGL0LrQvtCy0LDQvdC90YvQvCA7anNlc3Npb25pZA==?= In-Reply-To: <20170510125629.GF55433@mdounin.ru> References: <20170510125629.GF55433@mdounin.ru> Message-ID: <22166a794f457e26c0810515bb5b33a9.NginxMailingListRussian@forum.nginx.org> Спасибо Вам что подсказали. Проблема в том, что почему то, если не настроен статический контент, он отказывается обрабатывать файлы с русскими именами. На сколько я понял, происходило следующее. Как Вы правильно заметили, файлы вида filename;jsessionid=... не попадали в соответствующий локейшн и статический контент обрабатывался как любой другой, через tomcat, именно поэтому картинки, в названии которых не было русских букв, загружались без проблем , даже с ;jsessionid=, а вот с русскими буквами, почему то нет. Я изменил регулярное выражение в локейшене на: location ~* ^(/images/|/releated/).+\.(jpg|jpeg|gif|png|pdf)?(\;jsessionid=.*)$ { root /usr/share/inShop/webcontent; expires 30d; add_header Pragma public; add_header Cache-Control "public"; rewrite "^(.*);jsessionid=.*$" $1 break; } теперь, вроде, картинки все грузятся нормально. Правда , пока не понятно, почему без настройки статического контента, urlы с русскими буквами не обрабатываются. Спасибо Вам. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274123,274130#msg-274130 From alex.hha на gmail.com Wed May 10 16:19:39 2017 From: alex.hha на gmail.com (Alex Domoradov) Date: Wed, 10 May 2017 19:19:39 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiBwZXJsX3NldCDQv9GA0Lgg0LjRgdC/?= =?UTF-8?B?0L7Qu9GM0LfQvtCy0LDQvdC40LggcGVybCBtb2R1bGU=?= In-Reply-To: <20170510133309.GH55433@mdounin.ru> References: <20170510133309.GH55433@mdounin.ru> Message-ID: Переменную задавал через /etc/profile.d 2017-05-10 16:33 GMT+03:00 Maxim Dounin : > Hello! > > On Wed, May 10, 2017 at 04:16:48PM +0300, Alex Domoradov wrote: > > > Какие-нибудь идеи/предположения? > > > > On Thu, May 4, 2017 at 4:57 PM, Alex Domoradov > wrote: > > > > > Привет всем, > > > > > > имеется > > > > > > $ nginx -V > > > nginx version: nginx/1.12.0 > > > built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) > > > built with OpenSSL 1.0.1 14 Mar 2012 > > > TLS SNI support enabled > > > configure arguments: --prefix=/opt/nginx --with-http_ssl_module > > > --with-http_v2_module --with-http_realip_module > > > --with-http_gzip_static_module --with-http_stub_status_module > > > --with-http_addition_module --with-cc-opt=-Wno-error --with-ld-opt= > > > --add-module=/var/lib/gems/1.8/gems/passenger-5.1.3/src/nginx_module > > > --with-http_perl_module > > > > > > Мне надо логировать определенную переменную окружения, сделал > простейший > > > конфиг > > > > > > user capistrano; > > > worker_processes 1; > > > > > > env RACK_ENV; > > > > > > http { > > > passenger_root /var/lib/gems/1.8/gems/passenger-5.1.3; > > > passenger_ruby /usr/bin/ruby1.8; > > > > > > perl_set $RACK_ENV 'sub { return $ENV{"RACK_ENV"}; }'; > > > > > > log_format awslogs '[$time_local] env=TEST-$RACK_ENV\n'; > > > } > > > > > > В итоге в логах получаю > > > > > > [04/May/2017:13:49:28 +0000] env=TEST- > > > > > > Я что то упускаю? > > Переменная окружения, установленная при запуске nginx'а, при таком > конфиге должна быть нормально доступна: > > # RACK_ENV=foo nginx/objs/nginx > > [10/May/2017:13:25:17 +0000] env=TEST-foo > > Не следует, однако, ожидать, что установленные где-то в коде на > Ruby переменные окружения будут таким образом доступны nginx'у. > Переменные окружения локальны для конкретного процесса, а > passenger - запускает для выполнения Ruby-кода отдельные процессы. > > -- > Maxim Dounin > http://nginx.org/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Wed May 10 16:35:50 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 10 May 2017 21:35:50 +0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiBwZXJsX3NldCDQv9GA0Lgg0LjRgdC/?= =?UTF-8?B?0L7Qu9GM0LfQvtCy0LDQvdC40LggcGVybCBtb2R1bGU=?= In-Reply-To: References: <20170510133309.GH55433@mdounin.ru> Message-ID: В /proc//environ есть? 10 мая 2017 г. 21:19 пользователь "Alex Domoradov" написал: > Переменную задавал через /etc/profile.d > > 2017-05-10 16:33 GMT+03:00 Maxim Dounin : > >> Hello! >> >> On Wed, May 10, 2017 at 04:16:48PM +0300, Alex Domoradov wrote: >> >> > Какие-нибудь идеи/предположения? >> > >> > On Thu, May 4, 2017 at 4:57 PM, Alex Domoradov >> wrote: >> > >> > > Привет всем, >> > > >> > > имеется >> > > >> > > $ nginx -V >> > > nginx version: nginx/1.12.0 >> > > built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) >> > > built with OpenSSL 1.0.1 14 Mar 2012 >> > > TLS SNI support enabled >> > > configure arguments: --prefix=/opt/nginx --with-http_ssl_module >> > > --with-http_v2_module --with-http_realip_module >> > > --with-http_gzip_static_module --with-http_stub_status_module >> > > --with-http_addition_module --with-cc-opt=-Wno-error --with-ld-opt= >> > > --add-module=/var/lib/gems/1.8/gems/passenger-5.1.3/src/nginx_module >> > > --with-http_perl_module >> > > >> > > Мне надо логировать определенную переменную окружения, сделал >> простейший >> > > конфиг >> > > >> > > user capistrano; >> > > worker_processes 1; >> > > >> > > env RACK_ENV; >> > > >> > > http { >> > > passenger_root /var/lib/gems/1.8/gems/passenger-5.1.3; >> > > passenger_ruby /usr/bin/ruby1.8; >> > > >> > > perl_set $RACK_ENV 'sub { return $ENV{"RACK_ENV"}; }'; >> > > >> > > log_format awslogs '[$time_local] env=TEST-$RACK_ENV\n'; >> > > } >> > > >> > > В итоге в логах получаю >> > > >> > > [04/May/2017:13:49:28 +0000] env=TEST- >> > > >> > > Я что то упускаю? >> >> Переменная окружения, установленная при запуске nginx'а, при таком >> конфиге должна быть нормально доступна: >> >> # RACK_ENV=foo nginx/objs/nginx >> >> [10/May/2017:13:25:17 +0000] env=TEST-foo >> >> Не следует, однако, ожидать, что установленные где-то в коде на >> Ruby переменные окружения будут таким образом доступны nginx'у. >> Переменные окружения локальны для конкретного процесса, а >> passenger - запускает для выполнения Ruby-кода отдельные процессы. >> >> -- >> Maxim Dounin >> http://nginx.org/ >> _______________________________________________ >> 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 May 10 16:48:33 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 10 May 2017 19:48:33 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiBwZXJsX3NldCDQv9GA0Lgg0LjRgdC/?= =?UTF-8?B?0L7Qu9GM0LfQvtCy0LDQvdC40LggcGVybCBtb2R1bGU=?= In-Reply-To: References: <20170510133309.GH55433@mdounin.ru> Message-ID: <20170510164833.GL55433@mdounin.ru> Hello! On Wed, May 10, 2017 at 07:19:39PM +0300, Alex Domoradov wrote: > Переменную задавал через /etc/profile.d Так не будет работать, если вы конечно не руками запускаете nginx из интерактивного shell'а. Файл /etc/profile (и содержимое /etc/profile.d соответственно) подгружаются шелом, и только в случае "invoked as an interactive login shell, or as a non-interactive shell with the --login option". -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Wed May 10 17:23:20 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Wed, 10 May 2017 13:23:20 -0400 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgYmFja2dyb3VuZCB1cGRhdGUgc3NpINC/0L7QtNC3?= =?UTF-8?B?0LDQv9GA0L7RgdC+0LI=?= In-Reply-To: <08bad806d8496672f0c391b9221be703.NginxMailingListEnglish@forum.nginx.org> References: <08bad806d8496672f0c391b9221be703.NginxMailingListEnglish@forum.nginx.org> Message-ID: <0d1b7dee7948da76672a8ac4b5734893.NginxMailingListRussian@forum.nginx.org> Офтоп - мы делаем по другому, части контента загружаем аяксом на клиенте и строим страницу на клиенте, есть и сервер рендер, который по сути является агрегатором, РНР делает НТТР запросы к другим РНР скриптам, те отдают JSON, и собираем страницу на сервере и отдаем готовый НТМЛ, в плане кеширование работает проще и гибче. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274136,274143#msg-274143 From alex.hha на gmail.com Wed May 10 21:28:42 2017 From: alex.hha на gmail.com (Alex Domoradov) Date: Thu, 11 May 2017 00:28:42 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiBwZXJsX3NldCDQv9GA0Lgg0LjRgdC/?= =?UTF-8?B?0L7Qu9GM0LfQvtCy0LDQvdC40LggcGVybCBtb2R1bGU=?= In-Reply-To: <20170510164833.GL55433@mdounin.ru> References: <20170510133309.GH55433@mdounin.ru> <20170510164833.GL55433@mdounin.ru> Message-ID: Запустил уже из командной строки # RACK_ENV=PROD /opt/nginx/sbin/nginx -c /opt/nginx/conf/nginx.conf все равно не логирует ничего 2017-05-10 19:48 GMT+03:00 Maxim Dounin : > Hello! > > On Wed, May 10, 2017 at 07:19:39PM +0300, Alex Domoradov wrote: > > > Переменную задавал через /etc/profile.d > > Так не будет работать, если вы конечно не руками запускаете nginx > из интерактивного shell'а. Файл /etc/profile (и содержимое > /etc/profile.d соответственно) подгружаются шелом, и только в > случае "invoked as an interactive login shell, or as a > non-interactive shell with the --login option". > > -- > Maxim Dounin > http://nginx.org/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx на mva.name Wed May 10 21:44:57 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Thu, 11 May 2017 04:44:57 +0700 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiBwZXJsX3NldCDQv9GA0Lgg0LjRgdC/?= =?UTF-8?B?0L7Qu9GM0LfQvtCy0LDQvdC40LggcGVybCBtb2R1bGU=?= In-Reply-To: References: <20170510164833.GL55433@mdounin.ru> Message-ID: <3685447.oGgvfVZNW1@note> В письме от четверг, 11 мая 2017 г. 4:28:42 +07 пользователь Alex Domoradov написал: > Запустил уже из командной строки > > # RACK_ENV=PROD /opt/nginx/sbin/nginx -c /opt/nginx/conf/nginx.conf > > все равно не логирует ничего Зайдём с другой стороны: зачем вам логгировать эту переменную? :) В любом случае она должна быть выставлена через `passenger_app_env` или более специфичные её варианты. А не через те костыли, которыми вы пытаетесь это сделать :) From mdounin на mdounin.ru Thu May 11 02:45:23 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 11 May 2017 05:45:23 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiBwZXJsX3NldCDQv9GA0Lgg0LjRgdC/?= =?UTF-8?B?0L7Qu9GM0LfQvtCy0LDQvdC40LggcGVybCBtb2R1bGU=?= In-Reply-To: References: <20170510133309.GH55433@mdounin.ru> <20170510164833.GL55433@mdounin.ru> Message-ID: <20170511024523.GP55433@mdounin.ru> Hello! On Thu, May 11, 2017 at 12:28:42AM +0300, Alex Domoradov wrote: > Запустил уже из командной строки > > # RACK_ENV=PROD /opt/nginx/sbin/nginx -c /opt/nginx/conf/nginx.conf > > все равно не логирует ничего Я бы начал с того, что задал бы значение непосредственно в конфиге nginx'а, env RACK_ENV=foo; И проверил бы сборку без сторонних модулей. Если проблема всё ещё будет наблюдаться - приносите подробную информацию о системе, в частности - версию перла, "uname -a", "nginx -V", а равно полный/минимальный конфиг, на котором воспроизводится проблема. -- Maxim Dounin http://nginx.org/ From chipitsine на gmail.com Thu May 11 03:03:46 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 11 May 2017 08:03:46 +0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiBwZXJsX3NldCDQv9GA0Lgg0LjRgdC/?= =?UTF-8?B?0L7Qu9GM0LfQvtCy0LDQvdC40LggcGVybCBtb2R1bGU=?= In-Reply-To: References: <20170510133309.GH55433@mdounin.ru> <20170510164833.GL55433@mdounin.ru> Message-ID: Таким образом вы задали переменную оболочки, а не переменную среды 11 мая 2017 г. 2:28 пользователь "Alex Domoradov" написал: > Запустил уже из командной строки > > # RACK_ENV=PROD /opt/nginx/sbin/nginx -c /opt/nginx/conf/nginx.conf > > все равно не логирует ничего > > > 2017-05-10 19:48 GMT+03:00 Maxim Dounin : > >> Hello! >> >> On Wed, May 10, 2017 at 07:19:39PM +0300, Alex Domoradov wrote: >> >> > Переменную задавал через /etc/profile.d >> >> Так не будет работать, если вы конечно не руками запускаете nginx >> из интерактивного shell'а. Файл /etc/profile (и содержимое >> /etc/profile.d соответственно) подгружаются шелом, и только в >> случае "invoked as an interactive login shell, or as a >> non-interactive shell with the --login option". >> >> -- >> Maxim Dounin >> http://nginx.org/ >> _______________________________________________ >> 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 nginx-forum на forum.nginx.org Thu May 11 07:58:58 2017 From: nginx-forum на forum.nginx.org (metalfm1) Date: Thu, 11 May 2017 03:58:58 -0400 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgYmFja2dyb3VuZCB1cGRhdGUgc3NpINC/0L7QtNC3?= =?UTF-8?B?0LDQv9GA0L7RgdC+0LI=?= In-Reply-To: <20170510171846.GG94542@Romans-MacBook-Air.local> References: <20170510171846.GG94542@Romans-MacBook-Air.local> Message-ID: <07c422771a3503eaa3ee80cd75e924b7.NginxMailingListRussian@forum.nginx.org> Роман, огромное вам спасибо! Приложенный патч полностью решает мои проблемы. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274142,274154#msg-274154 From yorick на ya.ru Thu May 11 12:53:45 2017 From: yorick на ya.ru (Yury Lyakh) Date: Thu, 11 May 2017 14:53:45 +0200 Subject: =?UTF-8?B?bmdpbnggY2FjaGUgbWFuYWdlciBwcm9jZXNzINC90LUg0YHQvtCx0LvRjtC00LA=?= =?UTF-8?B?0LXRgiBtYXhfc2l6ZSDRgNCw0LfQvNC10YDQsCDQutC10YjQsA==?= Message-ID: <0A7EC356-DD84-4E7C-8DCB-CCA6A12AC026@ya.ru> День добрый, Возможно кто-то сталкивался с подобной ситуацией и подскажет что я пропустил... Разбираясь с мониторингом вокруг nginx, столкнулись с тем что manager процесс, который должен вычищать кеши до размера max_size, не делает этого. Не соблюдает строго max_size размер. CentOS 7, ext4, ssd, nginx-1.11.7 (раннее 1.11.4). Система не нагружена никак, диск ssd отдыхает, CPU около 80% *IDLE*, идет поток мелких запросов суммарно до 300-400 мбайт/сек. Описание кеша следующее: proxy_cache_path /var/lib/nginx/cache/cdn-example-com levels=2:2 keys_zone=cdn-example-com:50m inactive=8h max_size=100g manager_files=10000; [root на dc227 ~]# du -sh -L /var/lib/nginx/cache/cdn-example-com/ 142G /var/lib/nginx/cache/cdn-example-com/ [root на dc227 ~]# find /var/lib/nginx/cache/cdn-example-com/*/ -type f | wc -l 145553 И размер кеша и кол-во файлов потихоньку растут или колеблются вокруг этих показаний, сложно сказать, очень медленная динамика. Одно ясно точно, фактический размер кеша превышает заданный max_size. Стрейсом по manager процессу, видно что он неторопливо делает unlink, очень неторопливо и от цифры в manager_files это никак не меняется. Изначально, пытаясь решить эту ситуацию, грешили на то что manager_files по умолчанию =100, но, и 1000, и 10000 никак не влияют на скорость. Что приходит в голову, видимо manager процесс вычищает ровно столько сколько необходимо и все прекрасно успевает при любых значениях manager_files. Просто остальные файлы, по каким-то причинам, он считает недостойными очистки во имя сохранение max_size кеша. Какие-то параметры в описании proxy_cache_path имеют приоритет на max_size при принятии решения чистить файл или нет? From slw на zxy.spb.ru Thu May 11 13:08:42 2017 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Thu, 11 May 2017 16:08:42 +0300 Subject: =?UTF-8?B?0L3QtdGB0LrQvtC70YzQutC+INGB0LXRgNGC0LjRhNC40LrQsNGC0L7QsiDQsiA=?= =?UTF-8?B?0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= Message-ID: <20170511130842.GH3165@zxy.spb.ru> А возможно ли как-то использовать несколько разных сертификатов (одинакового типа, но на разные домены) в одном блоке server? Не хочется дублировать конфигурацию (достаточно развесистую), отличающуюся только именем сертификата, ключа и прописыванием server_name. Т.е. что-то типа того, как умеет haproxy. From mdounin на mdounin.ru Thu May 11 13:12:57 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 11 May 2017 16:12:57 +0300 Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIg?= =?UTF-8?B?0LIg0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= In-Reply-To: <20170511130842.GH3165@zxy.spb.ru> References: <20170511130842.GH3165@zxy.spb.ru> Message-ID: <20170511131257.GQ55433@mdounin.ru> Hello! On Thu, May 11, 2017 at 04:08:42PM +0300, Slawa Olhovchenkov wrote: > А возможно ли как-то использовать несколько разных сертификатов > (одинакового типа, но на разные домены) в одном блоке server? > Не хочется дублировать конфигурацию (достаточно развесистую), > отличающуюся только именем сертификата, ключа и прописыванием > server_name. Нет, сертификаты задаются для блока server{}. Если нужно, чтобы для разных имён использовались разные сертификаты - нужно делать разные блоки server{}. -- Maxim Dounin http://nginx.org/ From chipitsine на gmail.com Thu May 11 13:14:51 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 11 May 2017 18:14:51 +0500 Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIg?= =?UTF-8?B?0LIg0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= In-Reply-To: <20170511130842.GH3165@zxy.spb.ru> References: <20170511130842.GH3165@zxy.spb.ru> Message-ID: Получите на lets encrypt сертификат на все домены сразу 11 мая 2017 г. 18:08 пользователь "Slawa Olhovchenkov" написал: > А возможно ли как-то использовать несколько разных сертификатов > (одинакового типа, но на разные домены) в одном блоке server? > Не хочется дублировать конфигурацию (достаточно развесистую), > отличающуюся только именем сертификата, ключа и прописыванием > server_name. > > Т.е. что-то типа того, как умеет haproxy. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From slw на zxy.spb.ru Thu May 11 13:24:25 2017 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Thu, 11 May 2017 16:24:25 +0300 Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIg?= =?UTF-8?B?0LIg0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= In-Reply-To: <20170511131257.GQ55433@mdounin.ru> References: <20170511130842.GH3165@zxy.spb.ru> <20170511131257.GQ55433@mdounin.ru> Message-ID: <20170511132425.GI3165@zxy.spb.ru> On Thu, May 11, 2017 at 04:12:57PM +0300, Maxim Dounin wrote: > > А возможно ли как-то использовать несколько разных сертификатов > > (одинакового типа, но на разные домены) в одном блоке server? > > Не хочется дублировать конфигурацию (достаточно развесистую), > > отличающуюся только именем сертификата, ключа и прописыванием > > server_name. > > Нет, сертификаты задаются для блока server{}. Если нужно, чтобы > для разных имён использовались разные сертификаты - нужно делать > разные блоки server{}. Очень не хочется дублировать конфигурацию, отличающуюся только стороками server_name и путем до сертификата. Это неудобно поддерживать, даже если основное тело включать через include. From basil на vpm.net.ua Thu May 11 13:53:07 2017 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Thu, 11 May 2017 16:53:07 +0300 Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIg?= =?UTF-8?B?0LIg0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= In-Reply-To: <20170511132425.GI3165@zxy.spb.ru> References: <20170511130842.GH3165@zxy.spb.ru> <20170511131257.GQ55433@mdounin.ru> <20170511132425.GI3165@zxy.spb.ru> Message-ID: ну так впишите все в основной конфиг, а уже отличающиеся - каждому свое http { *keepalive_timeout 70;* ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5; *ssl_session_cache shared:SSL:10m;* *ssl_session_timeout 10m;* server { listen 443 ssl; ssl_certificate /usr/local/nginx/conf/cert.pem; ssl_certificate_key /usr/local/nginx/conf/cert.key; ... } 11 мая 2017 г., 16:24 пользователь Slawa Olhovchenkov написал: > On Thu, May 11, 2017 at 04:12:57PM +0300, Maxim Dounin wrote: > > > > А возможно ли как-то использовать несколько разных сертификатов > > > (одинакового типа, но на разные домены) в одном блоке server? > > > Не хочется дублировать конфигурацию (достаточно развесистую), > > > отличающуюся только именем сертификата, ключа и прописыванием > > > server_name. > > > > Нет, сертификаты задаются для блока server{}. Если нужно, чтобы > > для разных имён использовались разные сертификаты - нужно делать > > разные блоки server{}. > > Очень не хочется дублировать конфигурацию, отличающуюся только > стороками server_name и путем до сертификата. > > Это неудобно поддерживать, даже если основное тело включать через > include. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From slw на zxy.spb.ru Thu May 11 13:58:46 2017 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Thu, 11 May 2017 16:58:46 +0300 Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIg?= =?UTF-8?B?0LIg0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= In-Reply-To: References: <20170511130842.GH3165@zxy.spb.ru> <20170511131257.GQ55433@mdounin.ru> <20170511132425.GI3165@zxy.spb.ru> Message-ID: <20170511135846.GJ3165@zxy.spb.ru> On Thu, May 11, 2017 at 04:53:07PM +0300, Vasiliy P. Melnik wrote: > ну так впишите все в основной конфиг, а уже отличающиеся - каждому свое > > http { > > > *keepalive_timeout 70;* > ssl_protocols TLSv1 TLSv1.1 TLSv1.2; > ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5; > *ssl_session_cache shared:SSL:10m;* > *ssl_session_timeout 10m;* > > server { listen 443 ssl; > > ssl_certificate /usr/local/nginx/conf/cert.pem; > ssl_certificate_key /usr/local/nginx/conf/cert.key; > > ... } > что в основной конфиг вписать? все вот эти вот location {} в количестве дцать штук? так нельзя же: "Context: server, location" и серверов вложенных не бывает: "Context: http" From basil на vpm.net.ua Thu May 11 14:05:14 2017 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Thu, 11 May 2017 17:05:14 +0300 Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIg?= =?UTF-8?B?0LIg0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= In-Reply-To: <20170511135846.GJ3165@zxy.spb.ru> References: <20170511130842.GH3165@zxy.spb.ru> <20170511131257.GQ55433@mdounin.ru> <20170511132425.GI3165@zxy.spb.ru> <20170511135846.GJ3165@zxy.spb.ru> Message-ID: > > что в основной конфиг вписать? > все вот эти вот > > location {} в количестве дцать штук? > > так нельзя же: "Context: server, location" > > и серверов вложенных не бывает: "Context: http" > Ну значит не понял я чего Вы хотите - что я поделать то могу ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From tolmachev.vlad на gmail.com Thu May 11 14:11:05 2017 From: tolmachev.vlad на gmail.com (=?UTF-8?B?0JLQu9Cw0LTQuNGB0LvQsNCyINCi0L7Qu9C80LDRh9C10LI=?=) Date: Thu, 11 May 2017 14:11:05 +0000 Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIg?= =?UTF-8?B?0LIg0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= In-Reply-To: References: <20170511130842.GH3165@zxy.spb.ru> <20170511131257.GQ55433@mdounin.ru> <20170511132425.GI3165@zxy.spb.ru> <20170511135846.GJ3165@zxy.spb.ru> Message-ID: А нельзя ли сделать разные server и инклудить из отдельного файла ваши location? чт, 11 мая 2017 г. в 17:05, Vasiliy P. Melnik : > что в основной конфиг вписать? >> все вот эти вот >> >> location {} в количестве дцать штук? >> >> так нельзя же: "Context: server, location" >> >> и серверов вложенных не бывает: "Context: http" >> > > Ну значит не понял я чего Вы хотите - что я поделать то могу > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением Толмачев Владислав. tolmachev.vlad на gmail.com skype: vladislaviki icq: 274888266 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From slw на zxy.spb.ru Thu May 11 14:15:19 2017 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Thu, 11 May 2017 17:15:19 +0300 Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIg?= =?UTF-8?B?0LIg0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= In-Reply-To: References: <20170511130842.GH3165@zxy.spb.ru> <20170511131257.GQ55433@mdounin.ru> <20170511132425.GI3165@zxy.spb.ru> <20170511135846.GJ3165@zxy.spb.ru> Message-ID: <20170511141519.GK3165@zxy.spb.ru> On Thu, May 11, 2017 at 02:11:05PM +0000, Владислав Толмачев wrote: > А нельзя ли сделать разные server и инклудить из отдельного файла ваши > location? можно. но я уже писал выше по треду -- это неудобно сопровождать. From chipitsine на gmail.com Thu May 11 14:22:34 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 11 May 2017 19:22:34 +0500 Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIg?= =?UTF-8?B?0LIg0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= In-Reply-To: <20170511141519.GK3165@zxy.spb.ru> References: <20170511130842.GH3165@zxy.spb.ru> <20170511131257.GQ55433@mdounin.ru> <20170511132425.GI3165@zxy.spb.ru> <20170511135846.GJ3165@zxy.spb.ru> <20170511141519.GK3165@zxy.spb.ru> Message-ID: так, стоп. вы говорите, что так умеет haproxy. способ, которым это можно сделать в nginx, для вас неудобен. может, вам правильнее на haproxy перейти 11 мая 2017 г., 19:15 пользователь Slawa Olhovchenkov написал: > On Thu, May 11, 2017 at 02:11:05PM +0000, Владислав Толмачев wrote: > > > А нельзя ли сделать разные server и инклудить из отдельного файла ваши > > location? > > можно. но я уже писал выше по треду -- это неудобно сопровождать. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Thu May 11 14:26:59 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 11 May 2017 17:26:59 +0300 Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIg?= =?UTF-8?B?0LIg0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= In-Reply-To: <20170511132425.GI3165@zxy.spb.ru> References: <20170511130842.GH3165@zxy.spb.ru> <20170511131257.GQ55433@mdounin.ru> <20170511132425.GI3165@zxy.spb.ru> Message-ID: <20112c65-4991-1f1f-4cbc-54edae0eccf8@csdoc.com> On 11.05.2017 16:24, Slawa Olhovchenkov wrote: > Очень не хочется дублировать конфигурацию, отличающуюся только > стороками server_name и путем до сертификата. > > Это неудобно поддерживать, даже если основное тело включать через > include. может быть поможет вариант написать свой генератор конфига? например, шаблон server.atpl: server { ### example.com /path/to/cert/ ### example.net /path/to/cert/ ### example.org /path/to/cert/ // ... } на выходе - конфиг server.conf в том же каталоге с тремя серверами. можно даже написать такой генератор конфига, когда он информацию берет не из входного файла, а из базы данных, например, которую сопровождать будет удобно, используя веб-интефейс, если доменов много. -- Best regards, Gena From slw на zxy.spb.ru Thu May 11 14:32:35 2017 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Thu, 11 May 2017 17:32:35 +0300 Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIg?= =?UTF-8?B?0LIg0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= In-Reply-To: References: <20170511130842.GH3165@zxy.spb.ru> <20170511131257.GQ55433@mdounin.ru> <20170511132425.GI3165@zxy.spb.ru> <20170511135846.GJ3165@zxy.spb.ru> <20170511141519.GK3165@zxy.spb.ru> Message-ID: <20170511143235.GA1188@zxy.spb.ru> On Thu, May 11, 2017 at 07:22:34PM +0500, Илья Шипицин wrote: > так, стоп. > > вы говорите, что так умеет haproxy. > способ, которым это можно сделать в nginx, для вас неудобен. > > может, вам правильнее на haproxy перейти haproxy удобен для проксирования, но не для [нужной мне] раздачи статики, для которой удобен nginx. haproxy у меня тоже используется, там где он более удобен. From slw на zxy.spb.ru Thu May 11 14:33:21 2017 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Thu, 11 May 2017 17:33:21 +0300 Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIg?= =?UTF-8?B?0LIg0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= In-Reply-To: <20112c65-4991-1f1f-4cbc-54edae0eccf8@csdoc.com> References: <20170511130842.GH3165@zxy.spb.ru> <20170511131257.GQ55433@mdounin.ru> <20170511132425.GI3165@zxy.spb.ru> <20112c65-4991-1f1f-4cbc-54edae0eccf8@csdoc.com> Message-ID: <20170511143321.GB1188@zxy.spb.ru> On Thu, May 11, 2017 at 05:26:59PM +0300, Gena Makhomed wrote: > On 11.05.2017 16:24, Slawa Olhovchenkov wrote: > > > Очень не хочется дублировать конфигурацию, отличающуюся только > > стороками server_name и путем до сертификата. > > > > Это неудобно поддерживать, даже если основное тело включать через > > include. > > может быть поможет вариант написать свой генератор конфига? те же яица, только в профиль. From alexander.moskalenko на gmail.com Fri May 12 10:37:36 2017 From: alexander.moskalenko на gmail.com (Alexander Moskalenko) Date: Fri, 12 May 2017 12:37:36 +0200 Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIg?= =?UTF-8?B?0LIg0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= In-Reply-To: <20170511143321.GB1188@zxy.spb.ru> References: <20170511130842.GH3165@zxy.spb.ru> <20170511131257.GQ55433@mdounin.ru> <20170511132425.GI3165@zxy.spb.ru> <20112c65-4991-1f1f-4cbc-54edae0eccf8@csdoc.com> <20170511143321.GB1188@zxy.spb.ru> Message-ID: как уже написали выше - letsencrypt позволяет получать сертификаты до 100 доменов 2017-05-11 16:33 GMT+02:00 Slawa Olhovchenkov : > On Thu, May 11, 2017 at 05:26:59PM +0300, Gena Makhomed wrote: > > > On 11.05.2017 16:24, Slawa Olhovchenkov wrote: > > > > > Очень не хочется дублировать конфигурацию, отличающуюся только > > > стороками server_name и путем до сертификата. > > > > > > Это неудобно поддерживать, даже если основное тело включать через > > > include. > > > > может быть поможет вариант написать свой генератор конфига? > > те же яица, только в профиль. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx на mva.name Fri May 12 13:42:05 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 12 May 2017 20:42:05 +0700 Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIg?= =?UTF-8?B?0LIg0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= In-Reply-To: References: <20170511130842.GH3165@zxy.spb.ru> <20170511143321.GB1188@zxy.spb.ru> Message-ID: <1764268.teAOebzlEB@note> В письме от пятница, 12 мая 2017 г. 17:37:36 +07 пользователь Alexander Moskalenko написал: > как уже написали выше - letsencrypt позволяет получать сертификаты до 100 > доменов А ещё ОП мог бы перестать быть привередой с субъективным "неудобно" и объяснить чуть более объективно :) Ну или использовать lua-модуль. Тот - умеет отдавать сертификаты по условиям. From slw на zxy.spb.ru Fri May 12 13:44:38 2017 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Fri, 12 May 2017 16:44:38 +0300 Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIg?= =?UTF-8?B?0LIg0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= In-Reply-To: <1764268.teAOebzlEB@note> References: <20170511130842.GH3165@zxy.spb.ru> <20170511143321.GB1188@zxy.spb.ru> <1764268.teAOebzlEB@note> Message-ID: <20170512134438.GF1188@zxy.spb.ru> On Fri, May 12, 2017 at 08:42:05PM +0700, Vadim A. Misbakh-Soloviov wrote: > В письме от пятница, 12 мая 2017 г. 17:37:36 +07 пользователь Alexander > Moskalenko написал: > > как уже написали выше - letsencrypt позволяет получать сертификаты до 100 > > доменов > > А ещё ОП мог бы перестать быть привередой с субъективным "неудобно" и > объяснить чуть более объективно :) > > Ну или использовать lua-модуль. Тот - умеет отдавать сертификаты по условиям. Да? Вот это интересно, с этого места подробнее, lua у меня уже используется. From annulen на yandex.ru Fri May 12 14:28:50 2017 From: annulen на yandex.ru (Konstantin Tokarev) Date: Fri, 12 May 2017 17:28:50 +0300 Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIg?= =?UTF-8?B?0LIg0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= In-Reply-To: <20170511143235.GA1188@zxy.spb.ru> References: <20170511130842.GH3165@zxy.spb.ru> <20170511131257.GQ55433@mdounin.ru> <20170511132425.GI3165@zxy.spb.ru> <20170511135846.GJ3165@zxy.spb.ru> <20170511141519.GK3165@zxy.spb.ru> <20170511143235.GA1188@zxy.spb.ru> Message-ID: <1340421494599330@web29o.yandex.ru> 11.05.2017, 17:32, "Slawa Olhovchenkov" : > On Thu, May 11, 2017 at 07:22:34PM +0500, Илья Шипицин wrote: > >>  так, стоп. >> >>  вы говорите, что так умеет haproxy. >>  способ, которым это можно сделать в nginx, для вас неудобен. >> >>  может, вам правильнее на haproxy перейти > > haproxy удобен для проксирования, но не для [нужной мне] раздачи > статики, для которой удобен nginx. Можно затерминировать на haproxy весь https и проксировать на nginx, где уже не морочиться с сертификатами > > haproxy у меня тоже используется, там где он более удобен. > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From slw на zxy.spb.ru Fri May 12 14:30:20 2017 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Fri, 12 May 2017 17:30:20 +0300 Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIg?= =?UTF-8?B?0LIg0L7QtNC90L7QvCDQsdC70L7QutC1IHNlcnZlcg==?= In-Reply-To: <1340421494599330@web29o.yandex.ru> References: <20170511131257.GQ55433@mdounin.ru> <20170511132425.GI3165@zxy.spb.ru> <20170511135846.GJ3165@zxy.spb.ru> <20170511141519.GK3165@zxy.spb.ru> <20170511143235.GA1188@zxy.spb.ru> <1340421494599330@web29o.yandex.ru> Message-ID: <20170512143020.GG1188@zxy.spb.ru> On Fri, May 12, 2017 at 05:28:50PM +0300, Konstantin Tokarev wrote: > > > 11.05.2017, 17:32, "Slawa Olhovchenkov" : > > On Thu, May 11, 2017 at 07:22:34PM +0500, Илья Шипицин wrote: > > > >>  так, стоп. > >> > >>  вы говорите, что так умеет haproxy. > >>  способ, которым это можно сделать в nginx, для вас неудобен. > >> > >>  может, вам правильнее на haproxy перейти > > > > haproxy удобен для проксирования, но не для [нужной мне] раздачи > > статики, для которой удобен nginx. > > Можно затерминировать на haproxy весь https и проксировать на nginx, > где уже не морочиться с сертификатами у меня нет столько лишнего CPU. From nginx-forum на forum.nginx.org Sat May 13 09:21:12 2017 From: nginx-forum на forum.nginx.org (Sfalimov) Date: Sat, 13 May 2017 05:21:12 -0400 Subject: nginx + goaccess Message-ID: <935fb8482136c0da5ab3cbf78a0aaa70.NginxMailingListRussian@forum.nginx.org> Добрый день. Дано: web server apache, reverse proxy nginx + парсер логов goaccess В последней версии goaccess утилиту можно запустить с ключом --real-time-html и получить красивую вэбморду с парсингом логов в реальном времени (пример: http://rt.goaccess.io/) Утилита goaccess по умолчанию слушает 7890 порт. данные с сервера: iptables -L -n -v | grep 7890 1 60 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:7890 запускается goaccess следующей командой goaccess /var/log/apache2/domains/123.com.log -o /home/admin/web/stat.123.com/public_html/index.html --real-time-html --ws-url=stat.123.com конфиг nginx server { listen 99.99.99.99:80; server_name stat.123.com s.123.com; error_log /var/log/apache2/domains/stat.123.com.error.log error; location / { proxy_pass http://99.99.99.99:8080; location ~* ^.+\.(jpeg|jpg|png|gif|bmp|ico|svg|tif|tiff|css|js|htm|html|ttf|otf|webp|woff|txt|csv|rtf|doc|docx|xls|xlsx|p$ root /home/admin/web/stat.alexeymirnoff.com/public_html; access_log /var/log/apache2/domains/stat.123.com.log combined; access_log /var/log/apache2/domains/stat.123.com.bytes bytes; expires max; try_files $uri @fallback; } } location /error/ { alias /home/admin/web/stat.123.com/document_errors/; } location @fallback { proxy_pass http://99.99.99.99:8080; } При текущей конфигурации goaccess генерит статический index.html, а хотелось бы чтобы это было Real Time. Вопрос: Какие настройки должны быть у nginx чтобы на сервере по адресу: http://stat.123.com/ показывалась статистика goaccess? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274196,274196#msg-274196 From alex.hha на gmail.com Sun May 14 18:15:39 2017 From: alex.hha на gmail.com (Alex Domoradov) Date: Sun, 14 May 2017 21:15:39 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiBwZXJsX3NldCDQv9GA0Lgg0LjRgdC/?= =?UTF-8?B?0L7Qu9GM0LfQvtCy0LDQvdC40LggcGVybCBtb2R1bGU=?= In-Reply-To: References: <20170510133309.GH55433@mdounin.ru> <20170510164833.GL55433@mdounin.ru> Message-ID: > Зайдём с другой стороны: зачем вам логгировать эту переменную? :) это было лишь для примера. Сама переменная окружения к ruby отношения не имеет. > бы начал с того, что задал бы значение непосредственно в конфиге nginx'а так работает > Таким образом вы задали переменную оболочки, а не переменную среды я может что то упускаю, но как мне тогда задавать переменные окружения, чтобы их видел nginx? 2017-05-11 6:03 GMT+03:00 Илья Шипицин : > Таким образом вы задали переменную оболочки, а не переменную среды > > 11 мая 2017 г. 2:28 пользователь "Alex Domoradov" > написал: > > Запустил уже из командной строки >> >> # RACK_ENV=PROD /opt/nginx/sbin/nginx -c /opt/nginx/conf/nginx.conf >> >> все равно не логирует ничего >> >> >> 2017-05-10 19:48 GMT+03:00 Maxim Dounin : >> >>> Hello! >>> >>> On Wed, May 10, 2017 at 07:19:39PM +0300, Alex Domoradov wrote: >>> >>> > Переменную задавал через /etc/profile.d >>> >>> Так не будет работать, если вы конечно не руками запускаете nginx >>> из интерактивного shell'а. Файл /etc/profile (и содержимое >>> /etc/profile.d соответственно) подгружаются шелом, и только в >>> случае "invoked as an interactive login shell, or as a >>> non-interactive shell with the --login option". >>> >>> -- >>> Maxim Dounin >>> http://nginx.org/ >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vladget на gmail.com Sun May 14 19:38:13 2017 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Sun, 14 May 2017 22:38:13 +0300 Subject: nginx-1.12.0 In-Reply-To: <20170412151937.GX13617@mdounin.ru> References: <20170412151937.GX13617@mdounin.ru> Message-ID: Добрый вечер! После обновления на 1.12 в конфиге: map $http_variable_name $variable_name { ... } ругается: nginx: [emerg] the duplicate "variable_name" variable debian jessie 2017-04-12 18:19 GMT+03:00 Maxim Dounin : > Изменения в nginx 1.12.0 > 12.04.2017 > > *) Стабильная ветка 1.12.x. > > > -- > Maxim Dounin > http://nginx.org/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon May 15 09:50:48 2017 From: nginx-forum на forum.nginx.org (ohmykot) Date: Mon, 15 May 2017 05:50:48 -0400 Subject: =?UTF-8?B?0JrQsNC6INC30LDQsdC70L7QutC40YDQvtCy0LDRgtGMINC00L7RgdGC0YPQvyA=?= =?UTF-8?B?0Log0KfQn9CjIFVSTD8=?= Message-ID: <2f594dd97a79ca8da45d662a8f259644.NginxMailingListRussian@forum.nginx.org> Привет! Есть сервер на nginx и сайт на Wordpress. Появилась задача - к определенному странице Wordpress дать доступ только с определенного IP, а к остальным - запретить (не директории, а именно к определенной странице, то есть это не php-файл) Привет: http://somesite.com/my-private-page/ До этого работал только с Apache + htaccess, поэтому решение на nginx вызвало затруднение. Пробовал гуглить этот вопрос и описать в конфиг файле моего сайта решение, через location, что-то вроде: location ~* ^/my-private-page/ { allow 1.1.1.1; deny all; } В таком случае пишет 404 ошибку с разрешенного IP (как будто ищет файл по такому location, а не пробует открыть ЧПУ URL). Видимо, мне не хватает понимания конфигурирования nginx, помогите, пожалуйста. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274211,274211#msg-274211 From mdounin на mdounin.ru Mon May 15 15:21:26 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 15 May 2017 18:21:26 +0300 Subject: nginx-1.12.0 In-Reply-To: References: <20170412151937.GX13617@mdounin.ru> Message-ID: <20170515152126.GD55433@mdounin.ru> Hello! On Sun, May 14, 2017 at 10:38:13PM +0300, Vladimir Getmanshchuk wrote: > Добрый вечер! > > После обновления на 1.12 в конфиге: > map $http_variable_name $variable_name { > ... > } > > ругается: > nginx: [emerg] the duplicate "variable_name" variable Судя по сообщению, вы пытаетесь переопределить встроенную переменную. В nginx'е нет переменной с именем $variable_name, так что если данное имя переменной настоящее - то посмотрите на список используемых сторонних модулей, возможно проблема там. Или же нужен полный (минимальный) конфиг, на котором воспроизводится проблема. -- Maxim Dounin http://nginx.org/ From a.vasilishin на kpi.ua Mon May 15 18:40:26 2017 From: a.vasilishin на kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Mon, 15 May 2017 21:40:26 +0300 Subject: mp4 + ssl Message-ID: <9986e8c8-8092-abf2-80e1-1f00ef0575b4@kpi.ua> Привет всем! В связи с поголовной sslзацией Интернета пришла очередь и до mp4-стримминга. И вот Вчерашний тест показал, при 15к коннектах уже начало потихоньку упираться в проц и в пике было 32 Гбит/с трафика. Сегодня без ssl при тех же 15к коннектах 40 Гбит/с трафика и проц гуляет. Может нчто-то где-то надо подтюнить в конфиге? Конфиг ssl ниже: listen 443 ssl; add_header Strict-Transport-Security "max-age=0;"; # add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; # ssl on; ssl_certificate /etc/nginx/ssl/site.com.crt; ssl_certificate_key /etc/nginx/ssl/privatekey.key; ssl_trusted_certificate /etc/nginx/ssl/site.com.crt; # должен содержать 80 или 48 48 or 80 bytes # openssl rand 48 > /etc/nginx/ssl/current.key ssl_session_ticket_key /etc/nginx/ssl/current.key; ssl_session_ticket_key /etc/nginx/ssl/prev.key; ssl_session_ticket_key /etc/nginx/ssl/prevprev.key; # Use 2048 bit Diffie-Hellman RSA key parameters # (otherwise Nginx defaults to 1024 bit, lowering the strength of encryption # when using PFS) # Generated by OpenSSL with the following command: # openssl dhparam -outform pem -out /etc/nginx/ssl/dhparam2048.pem 2048 ssl_dhparam /etc/nginx/ssl/dhparam2048.pem; # make the server choose the best cipher instead of the browser # Perfect Forward Secrecy(PFS) is frequently compromised without this ssl_prefer_server_ciphers on; # support only believed secure ciphersuites using the following priority: # 1.) prefer PFS enabled ciphers # 2.) prefer AES128 over AES256 for speed (AES128 has completely adequate security for now) # 3.) Support DES3 for IE8 support # disable the following ciphersuites completely # 1.) null ciphers # 2.) ciphers with low security # 3.) fixed ECDH cipher (does not allow for PFS) # 4.) known vulnerable cypers (MD5, RC4, etc) # 5.) little-used ciphers (Camellia, Seed) ssl_ciphers 'kEECDH+ECDSA+AES128 kEECDH+ECDSA+AES256 kEECDH+AES128 kEECDH+AES256 kEDH+AES128 kEDH+AES256 DES-CBC3-SHA +SHA !aNULL !eNULL !LOW !kECDH !DSS !MD5 !EXP !PSK !SRP !CAMELLIA !SEED'; ## OCSP Stapling ssl_stapling on; ssl_stapling_verify on; ssl_protocols TLSv1.2 TLSv1.1 TLSv1; # Cache SSL Sessions for up to 10 minutes # This improves performance by avoiding the costly session negotiation process where possible ssl_session_cache builtin:10000 shared:SSL:100m; # ssl_session_timeout 5m; # this is a default, but can be changed ssl_session_timeout 1h; From slw на zxy.spb.ru Mon May 15 18:52:55 2017 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Mon, 15 May 2017 21:52:55 +0300 Subject: mp4 + ssl In-Reply-To: <9986e8c8-8092-abf2-80e1-1f00ef0575b4@kpi.ua> References: <9986e8c8-8092-abf2-80e1-1f00ef0575b4@kpi.ua> Message-ID: <20170515185255.GP1188@zxy.spb.ru> On Mon, May 15, 2017 at 09:40:26PM +0300, Андрей Василишин wrote: > Привет всем! > В связи с поголовной sslзацией Интернета пришла очередь и до > mp4-стримминга. И вот Вчерашний тест показал, при 15к коннектах уже > начало потихоньку упираться в проц и в пике было 32 Гбит/с трафика. > Сегодня без ssl при тех же 15к коннектах 40 Гбит/с трафика и проц > гуляет. Может нчто-то где-то надо подтюнить в конфиге? Конфиг ssl ниже: по моим наблюдениям sslизация режет производительность эдак на треть/пополам (смотря от какого сценария мерять) и с этим ничего сделать нельзя, если только у тебя нет парочки ядерных программистов на год, что бы повторить работу scott и glebius (и тогда будет резать только процентов 20%, емнип). From annulen на yandex.ru Mon May 15 18:54:02 2017 From: annulen на yandex.ru (Konstantin Tokarev) Date: Mon, 15 May 2017 21:54:02 +0300 Subject: mp4 + ssl In-Reply-To: <9986e8c8-8092-abf2-80e1-1f00ef0575b4@kpi.ua> References: <9986e8c8-8092-abf2-80e1-1f00ef0575b4@kpi.ua> Message-ID: <10129351494874442@web44j.yandex.ru> 15.05.2017, 21:40, "Андрей Василишин" : > Привет всем! > В связи с поголовной sslзацией Интернета пришла очередь и до > mp4-стримминга. И вот Вчерашний тест показал, при 15к коннектах уже > начало потихоньку упираться в проц и в пике было 32 Гбит/с трафика. > Сегодня без ssl при тех же 15к коннектах 40 Гбит/с трафика и проц > гуляет. Может нчто-то где-то надо подтюнить в конфиге? Поставить в качестве предпочитаемых шифров null и rc4, все равно это шифрование для галочки > Конфиг ssl ниже: > >         listen 443 ssl; >         add_header Strict-Transport-Security "max-age=0;"; > # add_header Strict-Transport-Security "max-age=31536000; > includeSubDomains" always; > # ssl on; >         ssl_certificate /etc/nginx/ssl/site.com.crt; >         ssl_certificate_key /etc/nginx/ssl/privatekey.key; >         ssl_trusted_certificate /etc/nginx/ssl/site.com.crt; >         # должен содержать 80 или 48 48 or 80 bytes >         # openssl rand 48 > /etc/nginx/ssl/current.key >         ssl_session_ticket_key /etc/nginx/ssl/current.key; >         ssl_session_ticket_key /etc/nginx/ssl/prev.key; >         ssl_session_ticket_key /etc/nginx/ssl/prevprev.key; > >         # Use 2048 bit Diffie-Hellman RSA key parameters >         # (otherwise Nginx defaults to 1024 bit, lowering the strength > of encryption # when using PFS) >         # Generated by OpenSSL with the following command: >         # openssl dhparam -outform pem -out > /etc/nginx/ssl/dhparam2048.pem 2048 >         ssl_dhparam /etc/nginx/ssl/dhparam2048.pem; > >         # make the server choose the best cipher instead of the browser >         # Perfect Forward Secrecy(PFS) is frequently compromised without > this >         ssl_prefer_server_ciphers on; > >         # support only believed secure ciphersuites using the following > priority: >         # 1.) prefer PFS enabled ciphers >         # 2.) prefer AES128 over AES256 for speed (AES128 has completely > adequate security for now) >         # 3.) Support DES3 for IE8 support > >         # disable the following ciphersuites completely >         # 1.) null ciphers >         # 2.) ciphers with low security >         # 3.) fixed ECDH cipher (does not allow for PFS) >         # 4.) known vulnerable cypers (MD5, RC4, etc) >         # 5.) little-used ciphers (Camellia, Seed) >         ssl_ciphers 'kEECDH+ECDSA+AES128 kEECDH+ECDSA+AES256 > kEECDH+AES128 kEECDH+AES256 kEDH+AES128 kEDH+AES256 DES-CBC3-SHA +SHA > !aNULL !eNULL !LOW !kECDH !DSS !MD5 !EXP !PSK !SRP !CAMELLIA !SEED'; > >         ## OCSP Stapling >         ssl_stapling on; >         ssl_stapling_verify on; >         ssl_protocols TLSv1.2 TLSv1.1 TLSv1; > >         # Cache SSL Sessions for up to 10 minutes >         # This improves performance by avoiding the costly session > negotiation process where possible >         ssl_session_cache builtin:10000 shared:SSL:100m; >         # ssl_session_timeout 5m; # this is a default, but can be changed >         ssl_session_timeout 1h; > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From annulen на yandex.ru Mon May 15 18:55:55 2017 From: annulen на yandex.ru (Konstantin Tokarev) Date: Mon, 15 May 2017 21:55:55 +0300 Subject: mp4 + ssl In-Reply-To: <10129351494874442@web44j.yandex.ru> References: <9986e8c8-8092-abf2-80e1-1f00ef0575b4@kpi.ua> <10129351494874442@web44j.yandex.ru> Message-ID: <10132551494874555@web44j.yandex.ru> 15.05.2017, 21:54, "Konstantin Tokarev" : > 15.05.2017, 21:40, "Андрей Василишин" : >>  Привет всем! >>  В связи с поголовной sslзацией Интернета пришла очередь и до >>  mp4-стримминга. И вот Вчерашний тест показал, при 15к коннектах уже >>  начало потихоньку упираться в проц и в пике было 32 Гбит/с трафика. >>  Сегодня без ssl при тех же 15к коннектах 40 Гбит/с трафика и проц >>  гуляет. Может нчто-то где-то надо подтюнить в конфиге? > > Поставить в качестве предпочитаемых шифров null и rc4, все равно это шифрование для галочки Естественно только для раздачи mp4 и т.п. ассетов > >>  Конфиг ssl ниже: >> >>          listen 443 ssl; >>          add_header Strict-Transport-Security "max-age=0;"; >>  # add_header Strict-Transport-Security "max-age=31536000; >>  includeSubDomains" always; >>  # ssl on; >>          ssl_certificate /etc/nginx/ssl/site.com.crt; >>          ssl_certificate_key /etc/nginx/ssl/privatekey.key; >>          ssl_trusted_certificate /etc/nginx/ssl/site.com.crt; >>          # должен содержать 80 или 48 48 or 80 bytes >>          # openssl rand 48 > /etc/nginx/ssl/current.key >>          ssl_session_ticket_key /etc/nginx/ssl/current.key; >>          ssl_session_ticket_key /etc/nginx/ssl/prev.key; >>          ssl_session_ticket_key /etc/nginx/ssl/prevprev.key; >> >>          # Use 2048 bit Diffie-Hellman RSA key parameters >>          # (otherwise Nginx defaults to 1024 bit, lowering the strength >>  of encryption # when using PFS) >>          # Generated by OpenSSL with the following command: >>          # openssl dhparam -outform pem -out >>  /etc/nginx/ssl/dhparam2048.pem 2048 >>          ssl_dhparam /etc/nginx/ssl/dhparam2048.pem; >> >>          # make the server choose the best cipher instead of the browser >>          # Perfect Forward Secrecy(PFS) is frequently compromised without >>  this >>          ssl_prefer_server_ciphers on; >> >>          # support only believed secure ciphersuites using the following >>  priority: >>          # 1.) prefer PFS enabled ciphers >>          # 2.) prefer AES128 over AES256 for speed (AES128 has completely >>  adequate security for now) >>          # 3.) Support DES3 for IE8 support >> >>          # disable the following ciphersuites completely >>          # 1.) null ciphers >>          # 2.) ciphers with low security >>          # 3.) fixed ECDH cipher (does not allow for PFS) >>          # 4.) known vulnerable cypers (MD5, RC4, etc) >>          # 5.) little-used ciphers (Camellia, Seed) >>          ssl_ciphers 'kEECDH+ECDSA+AES128 kEECDH+ECDSA+AES256 >>  kEECDH+AES128 kEECDH+AES256 kEDH+AES128 kEDH+AES256 DES-CBC3-SHA +SHA >>  !aNULL !eNULL !LOW !kECDH !DSS !MD5 !EXP !PSK !SRP !CAMELLIA !SEED'; >> >>          ## OCSP Stapling >>          ssl_stapling on; >>          ssl_stapling_verify on; >>          ssl_protocols TLSv1.2 TLSv1.1 TLSv1; >> >>          # Cache SSL Sessions for up to 10 minutes >>          # This improves performance by avoiding the costly session >>  negotiation process where possible >>          ssl_session_cache builtin:10000 shared:SSL:100m; >>          # ssl_session_timeout 5m; # this is a default, but can be changed >>          ssl_session_timeout 1h; >>  _______________________________________________ >>  nginx-ru mailing list >>  nginx-ru на nginx.org >>  http://mailman.nginx.org/mailman/listinfo/nginx-ru > > -- > Regards, > Konstantin > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From basil на vpm.net.ua Mon May 15 19:22:30 2017 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Mon, 15 May 2017 22:22:30 +0300 Subject: mp4 + ssl In-Reply-To: <10132551494874555@web44j.yandex.ru> References: <9986e8c8-8092-abf2-80e1-1f00ef0575b4@kpi.ua> <10129351494874442@web44j.yandex.ru> <10132551494874555@web44j.yandex.ru> Message-ID: > > > Поставить в качестве предпочитаемых шифров null и rc4, все равно это > шифрование для галочки > > Естественно только для раздачи mp4 и т.п. ассетов > а тест www.ssllabs.com проходится в таком случае? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From maxim на nginx.com Mon May 15 20:04:29 2017 From: maxim на nginx.com (Maxim Konovalov) Date: Mon, 15 May 2017 13:04:29 -0700 Subject: mp4 + ssl In-Reply-To: <20170515185255.GP1188@zxy.spb.ru> References: <9986e8c8-8092-abf2-80e1-1f00ef0575b4@kpi.ua> <20170515185255.GP1188@zxy.spb.ru> Message-ID: On 15/05/2017 11:52, Slawa Olhovchenkov wrote: > On Mon, May 15, 2017 at 09:40:26PM +0300, Андрей Василишин wrote: > >> Привет всем! >> В связи с поголовной sslзацией Интернета пришла очередь и до >> mp4-стримминга. И вот Вчерашний тест показал, при 15к коннектах уже >> начало потихоньку упираться в проц и в пике было 32 Гбит/с трафика. >> Сегодня без ssl при тех же 15к коннектах 40 Гбит/с трафика и проц >> гуляет. Может нчто-то где-то надо подтюнить в конфиге? Конфиг ssl ниже: > > по моим наблюдениям sslизация режет производительность эдак на > треть/пополам (смотря от какого сценария мерять) и с этим ничего > сделать нельзя, если только у тебя нет парочки ядерных программистов > на год, что бы повторить работу scott и glebius (и тогда будет резать > только процентов 20%, емнип). > Скорее rss: https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf -- Maxim Konovalov From gmm на csdoc.com Mon May 15 20:06:50 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 15 May 2017 23:06:50 +0300 Subject: mp4 + ssl In-Reply-To: <9986e8c8-8092-abf2-80e1-1f00ef0575b4@kpi.ua> References: <9986e8c8-8092-abf2-80e1-1f00ef0575b4@kpi.ua> Message-ID: <42fbd281-763e-b035-518d-5ccfe15a307e@csdoc.com> On 15.05.2017 21:40, Андрей Василишин wrote: > Может что-то где-то надо подтюнить в конфиге? https://habrahabr.ru/post/325230/ OpenSSL, ssl_ciphers и nginx: прокачиваем на 100% [...] С таким конфигом мы получаем ровно такой результат как у Google на начало 2017 года. При этом мы точно знаем что у всех клиентов сайт открывается настолько быстро, насколько это возможно без использования слабых шифров: все современные браузеры используют ECDHE. -- Best regards, Gena From maxim на nginx.com Mon May 15 20:08:01 2017 From: maxim на nginx.com (Maxim Konovalov) Date: Mon, 15 May 2017 13:08:01 -0700 Subject: =?UTF-8?B?aGFwcm94eSAod2FzIFJlOiDQvdC10YHQutC+0LvRjNC60L4g0YHQtdGA0YLQuNGE?= =?UTF-8?B?0LjQutCw0YLQvtCyINCyINC+0LTQvdC+0Lwg0LHQu9C+0LrQtSBzZXJ2ZXIp?= In-Reply-To: <20170511143235.GA1188@zxy.spb.ru> References: <20170511130842.GH3165@zxy.spb.ru> <20170511131257.GQ55433@mdounin.ru> <20170511132425.GI3165@zxy.spb.ru> <20170511135846.GJ3165@zxy.spb.ru> <20170511141519.GK3165@zxy.spb.ru> <20170511143235.GA1188@zxy.spb.ru> Message-ID: On 11/05/2017 07:32, Slawa Olhovchenkov wrote: > On Thu, May 11, 2017 at 07:22:34PM +0500, Илья Шипицин wrote: > >> так, стоп. >> >> вы говорите, что так умеет haproxy. >> способ, которым это можно сделать в nginx, для вас неудобен. >> >> может, вам правильнее на haproxy перейти > > haproxy удобен для проксирования, но не для [нужной мне] раздачи > статики, для которой удобен nginx. > > haproxy у меня тоже используется, там где он более удобен. > Пардон, что угоняю тред, но всегда интересовало: но ведь haproxy не умеет нормально smp -- оно по сути однопроцессное (см. ворнинг для nbproc) и однотредовое. Как вы с этим справляетесь? Запускаете пачку haproxy, каждый со своим конфигом? -- Maxim Konovalov From slw на zxy.spb.ru Mon May 15 20:08:34 2017 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Mon, 15 May 2017 23:08:34 +0300 Subject: mp4 + ssl In-Reply-To: References: <9986e8c8-8092-abf2-80e1-1f00ef0575b4@kpi.ua> <20170515185255.GP1188@zxy.spb.ru> Message-ID: <20170515200834.GR1188@zxy.spb.ru> On Mon, May 15, 2017 at 01:04:29PM -0700, Maxim Konovalov wrote: > On 15/05/2017 11:52, Slawa Olhovchenkov wrote: > > On Mon, May 15, 2017 at 09:40:26PM +0300, Андрей Василишин wrote: > > > >> Привет всем! > >> В связи с поголовной sslзацией Интернета пришла очередь и до > >> mp4-стримминга. И вот Вчерашний тест показал, при 15к коннектах уже > >> начало потихоньку упираться в проц и в пике было 32 Гбит/с трафика. > >> Сегодня без ssl при тех же 15к коннектах 40 Гбит/с трафика и проц > >> гуляет. Может нчто-то где-то надо подтюнить в конфиге? Конфиг ssl ниже: > > > > по моим наблюдениям sslизация режет производительность эдак на > > треть/пополам (смотря от какого сценария мерять) и с этим ничего > > сделать нельзя, если только у тебя нет парочки ядерных программистов > > на год, что бы повторить работу scott и glebius (и тогда будет резать > > только процентов 20%, емнип). > > > Скорее rss: > > https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf ну может трое. а может первые два из статьи -- типа руководители. sendfile занимался glebius, а по поводу используемых библиотек я переписывался со scott. From maxim на nginx.com Mon May 15 20:11:27 2017 From: maxim на nginx.com (Maxim Konovalov) Date: Mon, 15 May 2017 13:11:27 -0700 Subject: mp4 + ssl In-Reply-To: <20170515200834.GR1188@zxy.spb.ru> References: <9986e8c8-8092-abf2-80e1-1f00ef0575b4@kpi.ua> <20170515185255.GP1188@zxy.spb.ru> <20170515200834.GR1188@zxy.spb.ru> Message-ID: <32698a7d-1a85-c50c-44be-e5a0e76bef41@nginx.com> On 15/05/2017 13:08, Slawa Olhovchenkov wrote: > On Mon, May 15, 2017 at 01:04:29PM -0700, Maxim Konovalov wrote: > >> On 15/05/2017 11:52, Slawa Olhovchenkov wrote: >>> On Mon, May 15, 2017 at 09:40:26PM +0300, Андрей Василишин wrote: >>> >>>> Привет всем! >>>> В связи с поголовной sslзацией Интернета пришла очередь и до >>>> mp4-стримминга. И вот Вчерашний тест показал, при 15к коннектах уже >>>> начало потихоньку упираться в проц и в пике было 32 Гбит/с трафика. >>>> Сегодня без ssl при тех же 15к коннектах 40 Гбит/с трафика и проц >>>> гуляет. Может нчто-то где-то надо подтюнить в конфиге? Конфиг ssl ниже: >>> >>> по моим наблюдениям sslизация режет производительность эдак на >>> треть/пополам (смотря от какого сценария мерять) и с этим ничего >>> сделать нельзя, если только у тебя нет парочки ядерных программистов >>> на год, что бы повторить работу scott и glebius (и тогда будет резать >>> только процентов 20%, емнип). >>> >> Скорее rss: >> >> https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf > > ну может трое. > а может первые два из статьи -- типа руководители. > sendfile занимался glebius, а по поводу используемых библиотек я > переписывался со scott. tls занимался rss. -- Maxim Konovalov From slw на zxy.spb.ru Mon May 15 20:20:21 2017 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Mon, 15 May 2017 23:20:21 +0300 Subject: =?UTF-8?B?UmU6IGhhcHJveHkgKHdhcyBSZTog0L3QtdGB0LrQvtC70YzQutC+INGB0LXRgNGC?= =?UTF-8?B?0LjRhNC40LrQsNGC0L7QsiDQsiDQvtC00L3QvtC8INCx0LvQvtC60LUgc2Vy?= =?UTF-8?B?dmVyKQ==?= In-Reply-To: References: <20170511131257.GQ55433@mdounin.ru> <20170511132425.GI3165@zxy.spb.ru> <20170511135846.GJ3165@zxy.spb.ru> <20170511141519.GK3165@zxy.spb.ru> <20170511143235.GA1188@zxy.spb.ru> Message-ID: <20170515202021.GT1188@zxy.spb.ru> On Mon, May 15, 2017 at 01:08:01PM -0700, Maxim Konovalov wrote: > On 11/05/2017 07:32, Slawa Olhovchenkov wrote: > > On Thu, May 11, 2017 at 07:22:34PM +0500, Илья Шипицин wrote: > > > >> так, стоп. > >> > >> вы говорите, что так умеет haproxy. > >> способ, которым это можно сделать в nginx, для вас неудобен. > >> > >> может, вам правильнее на haproxy перейти > > > > haproxy удобен для проксирования, но не для [нужной мне] раздачи > > статики, для которой удобен nginx. > > > > haproxy у меня тоже используется, там где он более удобен. > > > Пардон, что угоняю тред, но всегда интересовало: но ведь haproxy не > умеет нормально smp -- оно по сути однопроцессное (см. ворнинг для > nbproc) и однотредовое. ну там в общем-то только сказанно что отладка сложна и уныла. но это и с nginx так же (проходил, да). собственно запрета-то там не было, кажется просто переставали работать всякие агрегатные лимиты (могу путать, поскольку см.ниже). > Как вы с этим справляетесь? Запускаете пачку haproxy, каждый со > своим конфигом? ну пока там, где haproxy -- мне и одного треда хватает. ну а в версии 1.7 поддержка улучшилась (will make it easier to aggregate statistics over multiple processes). From maxim на nginx.com Mon May 15 20:31:01 2017 From: maxim на nginx.com (Maxim Konovalov) Date: Mon, 15 May 2017 13:31:01 -0700 Subject: =?UTF-8?B?UmU6IGhhcHJveHkgKHdhcyBSZTog0L3QtdGB0LrQvtC70YzQutC+INGB0LXRgNGC?= =?UTF-8?B?0LjRhNC40LrQsNGC0L7QsiDQsiDQvtC00L3QvtC8INCx0LvQvtC60LUgc2Vy?= =?UTF-8?B?dmVyKQ==?= In-Reply-To: <20170515202021.GT1188@zxy.spb.ru> References: <20170511131257.GQ55433@mdounin.ru> <20170511132425.GI3165@zxy.spb.ru> <20170511135846.GJ3165@zxy.spb.ru> <20170511141519.GK3165@zxy.spb.ru> <20170511143235.GA1188@zxy.spb.ru> <20170515202021.GT1188@zxy.spb.ru> Message-ID: [...] >> Пардон, что угоняю тред, но всегда интересовало: но ведь haproxy не >> умеет нормально smp -- оно по сути однопроцессное (см. ворнинг для >> nbproc) и однотредовое. > > ну там в общем-то только сказанно что отладка сложна и уныла. > но это и с nginx так же (проходил, да). > > собственно запрета-то там не было, кажется просто переставали работать > всякие агрегатные лимиты (могу путать, поскольку см.ниже). > Дело далеко не в отладке. Дело в том, что никакие стейты не шарятся между процессами. Из-за этого довольно много интересных нюансов появляется, начиная с балансировки. >> Как вы с этим справляетесь? Запускаете пачку haproxy, каждый со >> своим конфигом? > > ну пока там, где haproxy -- мне и одного треда хватает. Ясно, спасибо. > ну а в версии 1.7 поддержка улучшилась (will make it easier to > aggregate statistics over multiple processes). Не уверен, но похоже это про передачу статистики каждого куда-то наружу, во внешнюю систему. -- Maxim Konovalov From slw на zxy.spb.ru Mon May 15 20:53:33 2017 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Mon, 15 May 2017 23:53:33 +0300 Subject: =?UTF-8?B?UmU6IGhhcHJveHkgKHdhcyBSZTog0L3QtdGB0LrQvtC70YzQutC+INGB0LXRgNGC?= =?UTF-8?B?0LjRhNC40LrQsNGC0L7QsiDQsiDQvtC00L3QvtC8INCx0LvQvtC60LUgc2Vy?= =?UTF-8?B?dmVyKQ==?= In-Reply-To: References: <20170511135846.GJ3165@zxy.spb.ru> <20170511141519.GK3165@zxy.spb.ru> <20170511143235.GA1188@zxy.spb.ru> <20170515202021.GT1188@zxy.spb.ru> Message-ID: <20170515205333.GU1188@zxy.spb.ru> On Mon, May 15, 2017 at 01:31:01PM -0700, Maxim Konovalov wrote: > [...] > >> Пардон, что угоняю тред, но всегда интересовало: но ведь haproxy не > >> умеет нормально smp -- оно по сути однопроцессное (см. ворнинг для > >> nbproc) и однотредовое. > > > > ну там в общем-то только сказанно что отладка сложна и уныла. > > но это и с nginx так же (проходил, да). > > > > собственно запрета-то там не было, кажется просто переставали работать > > всякие агрегатные лимиты (могу путать, поскольку см.ниже). > > > Дело далеко не в отладке. Дело в том, что никакие стейты не шарятся > между процессами. Из-за этого довольно много интересных нюансов > появляется, начиная с балансировки. ну я как бы примерно это и написал. может путанно и криво. но [работая в другом проекта с шарингом стейтов между ядрами] не всегда можно сказать, что хуже (отсутсвие лимитов или lock contention) [это я для своей ситуации, когда у меня через haproxy идет много мелких сессий]. > >> Как вы с этим справляетесь? Запускаете пачку haproxy, каждый со > >> своим конфигом? > > > > ну пока там, где haproxy -- мне и одного треда хватает. > > Ясно, спасибо. > > > ну а в версии 1.7 поддержка улучшилась (will make it easier to > > aggregate statistics over multiple processes). > > Не уверен, но похоже это про передачу статистики каждого куда-то > наружу, во внешнюю систему. может быть, пока меня не клюнет -- я более глубоко не полезу, только поверхностно отслеживать буду. https://www.slideshare.net/MichaelCarney6/whats-new-in-haproxy на слайде 6 обещают попытаться multhreading сделать в версии 1.8 From vladget на gmail.com Tue May 16 11:57:33 2017 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Tue, 16 May 2017 14:57:33 +0300 Subject: nginx-1.12.0 In-Reply-To: <20170515152126.GD55433@mdounin.ru> References: <20170412151937.GX13617@mdounin.ru> <20170515152126.GD55433@mdounin.ru> Message-ID: Добрый день! $variable_name - выдуманная конечно, реально $http_request_id и $request_id 2017-05-15 18:21 GMT+03:00 Maxim Dounin : > Hello! > > On Sun, May 14, 2017 at 10:38:13PM +0300, Vladimir Getmanshchuk wrote: > > > Добрый вечер! > > > > После обновления на 1.12 в конфиге: > > map $http_variable_name $variable_name { > > ... > > } > > > > ругается: > > nginx: [emerg] the duplicate "variable_name" variable > > Судя по сообщению, вы пытаетесь переопределить встроенную > переменную. > > В nginx'е нет переменной с именем $variable_name, так что если > данное имя переменной настоящее - то посмотрите на список > используемых сторонних модулей, возможно проблема там. > > Или же нужен полный (минимальный) конфиг, на котором > воспроизводится проблема. > > -- > Maxim Dounin > http://nginx.org/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue May 16 13:06:16 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 16 May 2017 16:06:16 +0300 Subject: nginx-1.12.0 In-Reply-To: References: <20170412151937.GX13617@mdounin.ru> <20170515152126.GD55433@mdounin.ru> Message-ID: <20170516130616.GH55433@mdounin.ru> Hello! On Tue, May 16, 2017 at 02:57:33PM +0300, Vladimir Getmanshchuk wrote: > $variable_name - выдуманная конечно, реально $http_request_id и $request_id В nginx 1.11.0 была добавлена встроенная пременная $request_id, от этого и возникает кофликт. -- Maxim Dounin http://nginx.org/ From vl на nginx.com Thu May 18 09:29:12 2017 From: vl на nginx.com (Vladimir Homutov) Date: Thu, 18 May 2017 12:29:12 +0300 Subject: =?UTF-8?B?RFRMUyDQv9Cw0YLRh9C4?= Message-ID: <20170518092911.GC26916@vlpc.nginx.com> Привет, Для заинтересованных в тестировании поддержки DTLS, теперь доступен экспериментальный патч: http://nginx.org/patches/dtls/ Подробности в README.txt По результатам можно отписаться в этом треде (а лучше сразу в аналогичном в английской рассылке, чтобы не дублировать) From bazilek на gmail.com Thu May 18 21:32:33 2017 From: bazilek на gmail.com (Vasil Mikhalenya) Date: Fri, 19 May 2017 00:32:33 +0300 Subject: proxy_pass uri Message-ID: Всем привет, вопрос по proxy_pass в случае указания uri. В документации не нашел описания данного поведения, пытаюсь понять, что не так. map $scheme $o_upstream { "http" "http://o_up"; "https" "https://o_up_ssl"; } в случае location / { proxy_pass $o_upstream/pp/; на origin вижу неправильный uri ip_address o "http" [18/May/2017:21:32:08 +0000] r:0.000 up:- "GET /pp/ HTTP/1.0" 403 162 "-" "curl/7.42.1" "-" в случае location / { proxy_pass https://o_up_ssl/pp/; все работает хорошо ==> /var/log/nginx/o_access.log <== ip_address o "https" [18/May/2017:21:31:29 +0000] r:0.000 up:- "GET /pp/t.txt HTTP/1.0" 200 9 "-" "curl/7.42.1" "-" в чем же отличие с точки зрения nginx? где в документации это отражено? Спасибо -- Best regards, Vasil Mikhalenya From vbart на nginx.com Thu May 18 22:50:51 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 19 May 2017 01:50:51 +0300 Subject: proxy_pass uri In-Reply-To: References: Message-ID: <3024375.LDOXxt2IB1@vbart-laptop> On Friday 19 May 2017 00:32:33 Vasil Mikhalenya wrote: > Всем привет, > > вопрос по proxy_pass в случае указания uri. В документации не нашел > описания данного поведения, пытаюсь понять, что не так. > > map $scheme $o_upstream { > "http" "http://o_up"; > "https" "https://o_up_ssl"; > } > > в случае > location / { > proxy_pass $o_upstream/pp/; > > на origin вижу неправильный uri > > ip_address o "http" [18/May/2017:21:32:08 +0000] r:0.000 up:- "GET > /pp/ HTTP/1.0" 403 162 "-" "curl/7.42.1" "-" > > в случае > location / { > proxy_pass https://o_up_ssl/pp/; > > все работает хорошо > ==> /var/log/nginx/o_access.log <== > ip_address o "https" [18/May/2017:21:31:29 +0000] r:0.000 up:- "GET > /pp/t.txt HTTP/1.0" 200 9 "-" "curl/7.42.1" "-" > > в чем же отличие с точки зрения nginx? где в документации это отражено? > В описании директивы proxy_pass есть такая фраза: | Имя сервера, его порт и передаваемый URI можно также полностью задать с помощью переменных Ключевое слово тут "полностью". P.S. Я согласен, что в текущем описании данный момент отражен несколько завуалированно. -- Валентин Бартенев From bazilek на gmail.com Fri May 19 08:20:27 2017 From: bazilek на gmail.com (Vasil Mikhalenya) Date: Fri, 19 May 2017 11:20:27 +0300 Subject: proxy_pass uri In-Reply-To: <3024375.LDOXxt2IB1@vbart-laptop> References: <3024375.LDOXxt2IB1@vbart-laptop> Message-ID: не похоже, что этот момент разрешает противоречие, т.к. следующая конструкция, состоящая не только из переменных, работает proxy_pass $o_upstream/pp$uri; подскажите, какой вариант является правильным? 2017-05-19 1:50 GMT+03:00 Валентин Бартенев : > On Friday 19 May 2017 00:32:33 Vasil Mikhalenya wrote: >> Всем привет, >> >> вопрос по proxy_pass в случае указания uri. В документации не нашел >> описания данного поведения, пытаюсь понять, что не так. >> >> map $scheme $o_upstream { >> "http" "http://o_up"; >> "https" "https://o_up_ssl"; >> } >> >> в случае >> location / { >> proxy_pass $o_upstream/pp/; >> >> на origin вижу неправильный uri >> >> ip_address o "http" [18/May/2017:21:32:08 +0000] r:0.000 up:- "GET >> /pp/ HTTP/1.0" 403 162 "-" "curl/7.42.1" "-" >> >> в случае >> location / { >> proxy_pass https://o_up_ssl/pp/; >> >> все работает хорошо >> ==> /var/log/nginx/o_access.log <== >> ip_address o "https" [18/May/2017:21:31:29 +0000] r:0.000 up:- "GET >> /pp/t.txt HTTP/1.0" 200 9 "-" "curl/7.42.1" "-" >> >> в чем же отличие с точки зрения nginx? где в документации это отражено? >> > > В описании директивы proxy_pass есть такая фраза: > > | Имя сервера, его порт и передаваемый URI можно также полностью задать с помощью переменных > > Ключевое слово тут "полностью". > > P.S. Я согласен, что в текущем описании данный момент отражен несколько завуалированно. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Vasil Mikhalenya From wangsamp на gmail.com Fri May 19 12:40:46 2017 From: wangsamp на gmail.com (Oleksandr V. Typlyns'kyi) Date: Fri, 19 May 2017 15:40:46 +0300 (EEST) Subject: proxy_pass uri In-Reply-To: References: <3024375.LDOXxt2IB1@vbart-laptop> Message-ID: Today May 19, 2017 at 11:20 Vasil Mikhalenya wrote: > не похоже, что этот момент разрешает противоречие, т.к. следующая > конструкция, состоящая не только из переменных, работает > > proxy_pass $o_upstream/pp$uri; > > подскажите, какой вариант является правильным? Тут "полностью" - это полностью сформированный передаваемый URI - без расчета на замену префикса и подстановку окончания. В случае $o_upstream/pp/ - это просто /pp/ для любого запроса пользователя. -- WNGS-RIPE From vbart на nginx.com Fri May 19 13:25:28 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 19 May 2017 16:25:28 +0300 Subject: proxy_pass uri In-Reply-To: References: <3024375.LDOXxt2IB1@vbart-laptop> Message-ID: <24514817.c4lai4EInn@vbart-workstation> On Friday 19 May 2017 11:20:27 Vasil Mikhalenya wrote: > не похоже, что этот момент разрешает противоречие, т.к. следующая > конструкция, состоящая не только из переменных, работает > > proxy_pass $o_upstream/pp$uri; > > подскажите, какой вариант является правильным? > [..] Полностью задать - в данном случае имеется в виду не то, что он полностью должен состоять из переменных, а то, что если есть переменные, то URI задается полностью, без всяких подмен. -- Валентин Бартенев From nginx-forum на forum.nginx.org Fri May 19 15:58:14 2017 From: nginx-forum на forum.nginx.org (vermakov) Date: Fri, 19 May 2017 11:58:14 -0400 Subject: $sent_http_date Message-ID: Добрый день! Заметил, что переменная $sent_http_date всегда печатает в лог _. Не смотря на то, что в ответе я вижу заголовок Date Date: Fri, 19 May 2017 15:23:53 GMT В то же время с другими заголовками из ответа, таких проблем не возникает. Например заголовок Content-Length из ответа печатается в переменной $sent_http_content_length. Это какая-то особенность с заголовком Date? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274319,274319#msg-274319 From mdounin на mdounin.ru Fri May 19 16:44:27 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 19 May 2017 19:44:27 +0300 Subject: $sent_http_date In-Reply-To: References: Message-ID: <20170519164427.GZ55433@mdounin.ru> Hello! On Fri, May 19, 2017 at 11:58:14AM -0400, vermakov wrote: > Добрый день! > > Заметил, что переменная $sent_http_date всегда печатает в лог _. Не смотря > на то, что в ответе я вижу заголовок Date > > Date: Fri, 19 May 2017 15:23:53 GMT > > В то же время с другими заголовками из ответа, таких проблем не возникает. > Например заголовок Content-Length из ответа печатается в переменной > $sent_http_content_length. > > Это какая-то особенность с заголовком Date? Заголовок Date всегда содержит текущее время, так что nginx выводит его непосредственно в момент формирования текстового представления ответа, и нигде не хранит. В результате переменная $sent_http_date будет иметь осмысленное значение только если соответствующий заголовок получен от бекенда и специально пропущен клиенту с помощью "proxy_pass_header Date". Это можно исправить (cделать, чтобы выведенное время где-то дополнительно сохранялось, и его можно было вывести в переменную), но там возникнут очевидные накладные расходы на это сохранение, и не совсем понятно, зачем это вообще может быть нужно. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Sat May 20 18:48:11 2017 From: nginx-forum на forum.nginx.org (kycedbi) Date: Sat, 20 May 2017 14:48:11 -0400 Subject: =?UTF-8?B?0KHQu9C10LTQvtCy0LDQvdC40LUg0L/QviDRgNC10LTQuNGA0LXQutGC0LDQvCA=?= =?UTF-8?B?0LLQvNC10YHRgtC+INC+0YLQstC10YLQsCDQsdGA0LDRg9C30LXRgNGDLg==?= Message-ID: Здравствуйте. Использую nginx в качестве прокси с кэшем (сохраняет проксируемый файл в указанный каталог). Иногда файл, который проксируется, находится по другому адресу и целевой сервер указывает этот адрес с помощью 302 редиректа (иногда несколько 302 редиректов до достижения ответа 200/206/404). Но nginx при виде 302, сразу отдаёт 302 браузеру, а сам не переходит по этому редиректу для получения файла и последующего его проксирования. Примерный конфиг (internal location): https://gist.github.com/anonymous/35641c9c4d851e90e11417d17c17114b Тестовый скрипт: https://gist.github.com/006009edfe6be71daf5e028b10377f60 Подскажите, пожалуйста, как можно модифицировать конфиг, чтобы nginx сам ходил по редиректам, а не отправлял по ним браузер, и при этом сохранился функционал проксирования, т.е. чтобы nginx ещё и сохранял диск в указанное место проксируемый файл, если в результате перехода по редиректам таки был получен ответ 200 (при ответе 404, браузеру тоже нужно отдать ответ 404 и не кэшировать результат). http://stackoverflow.com/a/38592074 эту штуку не осилил. Возможна оплата за предоставленное рабочее решение. С уважением. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274346,274346#msg-274346 From chipitsine на gmail.com Sat May 20 18:55:28 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sat, 20 May 2017 23:55:28 +0500 Subject: =?UTF-8?B?UmU6INCh0LvQtdC00L7QstCw0L3QuNC1INC/0L4g0YDQtdC00LjRgNC10LrRgtCw?= =?UTF-8?B?0Lwg0LLQvNC10YHRgtC+INC+0YLQstC10YLQsCDQsdGA0LDRg9C30LXRgNGD?= =?UTF-8?B?Lg==?= In-Reply-To: References: Message-ID: привет! на каком движке сайт? код допускается менять? 20 мая 2017 г., 23:48 пользователь kycedbi написал: > Здравствуйте. > Использую nginx в качестве прокси с кэшем (сохраняет проксируемый файл в > указанный каталог). > Иногда файл, который проксируется, находится по другому адресу и целевой > сервер указывает этот адрес с помощью 302 редиректа (иногда несколько 302 > редиректов до достижения ответа 200/206/404). > Но nginx при виде 302, сразу отдаёт 302 браузеру, а сам не переходит по > этому редиректу для получения файла и последующего его проксирования. > > Примерный конфиг (internal location): > https://gist.github.com/anonymous/35641c9c4d851e90e11417d17c17114b > Тестовый скрипт: https://gist.github.com/006009edfe6be71daf5e028b10377f60 > > Подскажите, пожалуйста, как можно модифицировать конфиг, чтобы nginx сам > ходил по редиректам, а не отправлял по ним браузер, и при этом сохранился > функционал проксирования, т.е. чтобы nginx ещё и сохранял диск в указанное > место проксируемый файл, если в результате перехода по редиректам таки был > получен ответ 200 (при ответе 404, браузеру тоже нужно отдать ответ 404 и > не > кэшировать результат). > > http://stackoverflow.com/a/38592074 эту штуку не осилил. > > Возможна оплата за предоставленное рабочее решение. > С уважением. > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,274346,274346#msg-274346 > > _______________________________________________ > 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 May 20 20:17:44 2017 From: nginx-forum на forum.nginx.org (kycedbi) Date: Sat, 20 May 2017 16:17:44 -0400 Subject: =?UTF-8?B?UmU6INCh0LvQtdC00L7QstCw0L3QuNC1INC/0L4g0YDQtdC00LjRgNC10LrRgtCw?= =?UTF-8?B?0Lwg0LLQvNC10YHRgtC+INC+0YLQstC10YLQsCDQsdGA0LDRg9C30LXRgNGD?= =?UTF-8?B?Lg==?= In-Reply-To: References: Message-ID: Код написан на php. Модификация кода допускается. Речь о предварительной проверке наличия редиректов средствами языка программирования и последующее скармливание nginx-у конечного url? В идеале - хотелось бы решения чисто на nginx. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274346,274348#msg-274348 From nginx-forum на forum.nginx.org Sat May 20 21:00:26 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Sat, 20 May 2017 17:00:26 -0400 Subject: =?UTF-8?B?UmU6INCh0LvQtdC00L7QstCw0L3QuNC1INC/0L4g0YDQtdC00LjRgNC10LrRgtCw?= =?UTF-8?B?0Lwg0LLQvNC10YHRgtC+INC+0YLQstC10YLQsCDQsdGA0LDRg9C30LXRgNGD?= =?UTF-8?B?Lg==?= In-Reply-To: References: Message-ID: <037101be65fba36cc15c006e376002e1.NginxMailingListRussian@forum.nginx.org> > В идеале - хотелось бы решения чисто на nginx. x-accel-redirect https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/#x-accel-redirect Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274346,274349#msg-274349 From bazilek на gmail.com Sat May 20 21:00:47 2017 From: bazilek на gmail.com (Vasil Mikhalenya) Date: Sun, 21 May 2017 00:00:47 +0300 Subject: proxy_pass uri In-Reply-To: <24514817.c4lai4EInn@vbart-workstation> References: <3024375.LDOXxt2IB1@vbart-laptop> <24514817.c4lai4EInn@vbart-workstation> Message-ID: ок, спасибо. это действительно никак не описано в английской версии документации в таком случае, можно ли сказать, что для решения этой задачи правильнее иcпользовать rewrite? location /xx { proxy_pass $o_upstream; rewrite ^/xx/(.*) /pp/$1; } 2017-05-19 16:25 GMT+03:00 Валентин Бартенев : > On Friday 19 May 2017 11:20:27 Vasil Mikhalenya wrote: >> не похоже, что этот момент разрешает противоречие, т.к. следующая >> конструкция, состоящая не только из переменных, работает >> >> proxy_pass $o_upstream/pp$uri; >> >> подскажите, какой вариант является правильным? >> > [..] > > Полностью задать - в данном случае имеется в виду не то, что он > полностью должен состоять из переменных, а то, что если есть > переменные, то URI задается полностью, без всяких подмен. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Vasil Mikhalenya From nginx-forum на forum.nginx.org Sat May 20 21:19:51 2017 From: nginx-forum на forum.nginx.org (kycedbi) Date: Sat, 20 May 2017 17:19:51 -0400 Subject: =?UTF-8?B?UmU6INCh0LvQtdC00L7QstCw0L3QuNC1INC/0L4g0YDQtdC00LjRgNC10LrRgtCw?= =?UTF-8?B?0Lwg0LLQvNC10YHRgtC+INC+0YLQstC10YLQsCDQsdGA0LDRg9C30LXRgNGD?= =?UTF-8?B?Lg==?= In-Reply-To: <037101be65fba36cc15c006e376002e1.NginxMailingListRussian@forum.nginx.org> References: <037101be65fba36cc15c006e376002e1.NginxMailingListRussian@forum.nginx.org> Message-ID: В первом сообщении указана ссылка на php-скрипт, где и используется x-accel-redirect. Задача: сделать, чтобы nginx, приняв url, ещё и переходил по редиректам, а не завершал обработку при получении первого редиректа. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274346,274351#msg-274351 From nginx-forum на forum.nginx.org Sun May 21 08:18:19 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Sun, 21 May 2017 04:18:19 -0400 Subject: =?UTF-8?B?UmU6INCh0LvQtdC00L7QstCw0L3QuNC1INC/0L4g0YDQtdC00LjRgNC10LrRgtCw?= =?UTF-8?B?0Lwg0LLQvNC10YHRgtC+INC+0YLQstC10YLQsCDQsdGA0LDRg9C30LXRgNGD?= =?UTF-8?B?Lg==?= In-Reply-To: References: <037101be65fba36cc15c006e376002e1.NginxMailingListRussian@forum.nginx.org> Message-ID: <34b4b26ae1e113d7b83ff3149597a337.NginxMailingListRussian@forum.nginx.org> > В первом сообщении указана ссылка на php-скрипт, где и используется > x-accel-redirect. Задача: сделать, чтобы nginx, приняв url, ещё и > переходил по редиректам, а не завершал обработку при получении первого > редиректа. Nginx, браузеру заголовок X-Accel-Redirect никогда не отдает, т.е. браузер не может сам ходить по этим редиректам, по ним может ходить только Nginx, вы даже можете в именованые локейшины ходить. header('X-Accel-Redirect: @named_location'); Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274346,274356#msg-274356 From chipitsine на gmail.com Sun May 21 08:22:35 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 21 May 2017 13:22:35 +0500 Subject: =?UTF-8?B?UmU6INCh0LvQtdC00L7QstCw0L3QuNC1INC/0L4g0YDQtdC00LjRgNC10LrRgtCw?= =?UTF-8?B?0Lwg0LLQvNC10YHRgtC+INC+0YLQstC10YLQsCDQsdGA0LDRg9C30LXRgNGD?= =?UTF-8?B?Lg==?= In-Reply-To: References: <037101be65fba36cc15c006e376002e1.NginxMailingListRussian@forum.nginx.org> Message-ID: добрый день! кажется, вы несколько перемудрили с X-Accel-Redirect. посмотрел ваш скрипт, задумка понятна. у вас есть какой-нибудь тестовый стенд ? напишите мне в личку: chipitsine на gmail.com 21 мая 2017 г., 2:19 пользователь kycedbi написал: > В первом сообщении указана ссылка на php-скрипт, где и используется > x-accel-redirect. Задача: сделать, чтобы nginx, приняв url, ещё и переходил > по редиректам, а не завершал обработку при получении первого редиректа. > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,274346,274351#msg-274351 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From tolmachev.vlad на gmail.com Sun May 21 14:19:58 2017 From: tolmachev.vlad на gmail.com (=?UTF-8?B?0JLQu9Cw0LTQuNGB0LvQsNCyINCi0L7Qu9C80LDRh9C10LI=?=) Date: Sun, 21 May 2017 17:19:58 +0300 Subject: =?UTF-8?B?0LfQsNC80LXQvdCwINC30L3QsNGH0LXQvdC40Y8g0L/QtdGA0LXQvNC10L3QvdC+?= =?UTF-8?B?0Lkg0LIgbG9jYXRpb24=?= Message-ID: Добрый день. Есть переменная в location $name, полученная получена из адреса запроса, допустим она равна ".mp999" как изменить ее значение на ".mp3"? Понимаю что адрес запроса можно сделать rewrite и там уже изменить эту часть урл, но хотелось бы изменить ее значение в самой переменной. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vadim.lazovskiy на gmail.com Mon May 22 06:27:39 2017 From: vadim.lazovskiy на gmail.com (Vadim Lazovskiy) Date: Mon, 22 May 2017 09:27:39 +0300 Subject: =?UTF-8?B?UmU6INC30LDQvNC10L3QsCDQt9C90LDRh9C10L3QuNGPINC/0LXRgNC10LzQtdC9?= =?UTF-8?B?0L3QvtC5INCyIGxvY2F0aW9u?= In-Reply-To: References: Message-ID: Здравствуйте. В ту же самую переменную (зачем?), наверное, можно так (1.11.0+): map $name $new_name { ~"^(?.*)\.mp\d+$" "${basename}.mp3"; default ""; } location ~ /.../(?.*)/...$ { set $name $new_name; ... } 21 мая 2017 г., 17:19 пользователь Владислав Толмачев < tolmachev.vlad на gmail.com> написал: > Добрый день. Есть переменная в location $name, полученная получена из > адреса запроса, допустим она равна ".mp999" как изменить ее значение на > ".mp3"? > Понимаю что адрес запроса можно сделать rewrite и там уже изменить эту > часть урл, но хотелось бы изменить ее значение в самой переменной. > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- WBR, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.lazovskiy на gmail.com Mon May 22 06:38:18 2017 From: vadim.lazovskiy на gmail.com (Vadim Lazovskiy) Date: Mon, 22 May 2017 09:38:18 +0300 Subject: =?UTF-8?B?UmU6INCh0LvQtdC00L7QstCw0L3QuNC1INC/0L4g0YDQtdC00LjRgNC10LrRgtCw?= =?UTF-8?B?0Lwg0LLQvNC10YHRgtC+INC+0YLQstC10YLQsCDQsdGA0LDRg9C30LXRgNGD?= =?UTF-8?B?Lg==?= In-Reply-To: References: Message-ID: Здравствуйте. Например, как-то так: location ~ /proxy/(?[^/]+)/(?.+)$ { error_page 301 302 307 =200 @proxy_redirect; proxy_intercept_errors on; proxy_pass http://$proxy_host/$proxy_uri?$args; ... } location @proxy_redirect { set $redirect_url $upstream_http_location; proxy_pass $redirect_url; proxy_set_header Host $proxy_host; ... } Кеширование добавить в оба location. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.lazovskiy на gmail.com Mon May 22 06:45:09 2017 From: vadim.lazovskiy на gmail.com (Vadim Lazovskiy) Date: Mon, 22 May 2017 09:45:09 +0300 Subject: =?UTF-8?B?UmU6INC30LDQvNC10L3QsCDQt9C90LDRh9C10L3QuNGPINC/0LXRgNC10LzQtdC9?= =?UTF-8?B?0L3QvtC5INCyIGxvY2F0aW9u?= In-Reply-To: References: Message-ID: А вообще, не выделяейте из uri расширение и внутри location просто допишите: set $name "${name}.mp3" 22 мая 2017 г., 9:27 пользователь Vadim Lazovskiy написал: > Здравствуйте. > > В ту же самую переменную (зачем?), наверное, можно так (1.11.0+): > > map $name $new_name { > ~"^(?.*)\.mp\d+$" "${basename}.mp3"; > default ""; > } > > location ~ /.../(?.*)/...$ { > set $name $new_name; > ... > } > > > 21 мая 2017 г., 17:19 пользователь Владислав Толмачев < > tolmachev.vlad на gmail.com> написал: > >> Добрый день. Есть переменная в location $name, полученная получена из >> адреса запроса, допустим она равна ".mp999" как изменить ее значение на >> ".mp3"? >> Понимаю что адрес запроса можно сделать rewrite и там уже изменить эту >> часть урл, но хотелось бы изменить ее значение в самой переменной. >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > > -- > WBR, > Vadim Lazovskiy > -- WBR, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum на forum.nginx.org Mon May 22 11:38:04 2017 From: nginx-forum на forum.nginx.org (BorisK2) Date: Mon, 22 May 2017 07:38:04 -0400 Subject: =?UTF-8?B?0JrQsNC6INGB0LTQtdC70LDRgtGMIGF1dGggcmVxdWVzdCDQv9GA0LggU1NJPw==?= Message-ID: Есть html-страница статьи, доступная всем. Надо на ней показать ссылку "Редактировать", доступную только некоторым юзерам. Из статьи (test1.html) подключаю по SSI ссылку (test2.html), но почему то права на нее не проверяются. При прямом обращении из браузера - проверяются. Как заставить проверять при SSI? test1.html (статья) test1 (include virtual тоже пробовал) test2.html (ссылка) test2 Конфиг сайта: server { ssi on; location = /test1.html { } location = /test2.html { auth_request /test_auth; } location = /test_auth { return 403; } } Выводится при обращении к test1.html: test1 test2 Должно выводиться: test1 <403> Выводится при обращении к test2.html (так и должно): <403> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274370,274370#msg-274370 From nginx-forum на forum.nginx.org Mon May 22 12:06:00 2017 From: nginx-forum на forum.nginx.org (vermakov) Date: Mon, 22 May 2017 08:06:00 -0400 Subject: $sent_http_date In-Reply-To: <20170519164427.GZ55433@mdounin.ru> References: <20170519164427.GZ55433@mdounin.ru> Message-ID: <1d374189cf88c3e11faa039b8e20c59f.NginxMailingListRussian@forum.nginx.org> Спасибо! Все понятно. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274319,274371#msg-274371 From mdounin на mdounin.ru Mon May 22 12:50:56 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 22 May 2017 15:50:56 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC00LXQu9Cw0YLRjCBhdXRoIHJlcXVlc3Qg0L/RgNC4IFNT?= =?UTF-8?B?ST8=?= In-Reply-To: References: Message-ID: <20170522125056.GC55433@mdounin.ru> Hello! On Mon, May 22, 2017 at 07:38:04AM -0400, BorisK2 wrote: > Есть html-страница статьи, доступная всем. Надо на ней показать ссылку > "Редактировать", доступную только некоторым юзерам. > Из статьи (test1.html) подключаю по SSI ссылку (test2.html), но почему то > права на нее не проверяются. При прямом обращении из браузера - проверяются. > Как заставить проверять при SSI? > > test1.html (статья) > test1 > Модули контроля доступа (как то auth_basic, access и auth_request) не проверяют подзапросы. Предполагается, что все необходимые права были проверены на этапе обработки основного запроса. Если хочется какие-то ssi-фрагменты показывать в зависимости от результата auth_request, то следует использовать auth_request для основного запроса, и вернуть положительный результат, параллельно установив дополнительную переменную через auth_request_set. После чего проверять переменную с помощью, например, SSI-команды "if". Подробнее про auth_request_set в документации тут: http://nginx.org/ru/docs/http/ngx_http_auth_request_module.html -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Mon May 22 12:54:40 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 22 May 2017 15:54:40 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC00LXQu9Cw0YLRjCBhdXRoIHJlcXVlc3Qg0L/RgNC4IFNT?= =?UTF-8?B?ST8=?= In-Reply-To: <20170522125056.GC55433@mdounin.ru> References: <20170522125056.GC55433@mdounin.ru> Message-ID: <20170522125440.GD55433@mdounin.ru> Hello! On Mon, May 22, 2017 at 03:50:56PM +0300, Maxim Dounin wrote: > Hello! > > On Mon, May 22, 2017 at 07:38:04AM -0400, BorisK2 wrote: > > > Есть html-страница статьи, доступная всем. Надо на ней показать ссылку > > "Редактировать", доступную только некоторым юзерам. > > Из статьи (test1.html) подключаю по SSI ссылку (test2.html), но почему то > > права на нее не проверяются. При прямом обращении из браузера - проверяются. > > Как заставить проверять при SSI? > > > > test1.html (статья) > > test1 > > > > Модули контроля доступа (как то auth_basic, access и auth_request) > не проверяют подзапросы. Предполагается, что все необходимые > права были проверены на этапе обработки основного запроса. > > Если хочется какие-то ssi-фрагменты показывать в зависимости от > результата auth_request, то следует использовать auth_request для > основного запроса, и вернуть положительный результат, параллельно > установив дополнительную переменную через auth_request_set. После > чего проверять переменную с помощью, например, SSI-команды "if". > Подробнее про auth_request_set в документации тут: > > http://nginx.org/ru/docs/http/ngx_http_auth_request_module.html Ну и да, отмечу в скобках, что возможно вам auth_request тут вообще не надо, а вполне хватит обычного <--#include ... set="variable" -->, подробнее тут: http://nginx.org/ru/docs/http/ngx_http_ssi_module.html#commands -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Tue May 23 00:23:27 2017 From: nginx-forum на forum.nginx.org (BorisK2) Date: Mon, 22 May 2017 20:23:27 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC00LXQu9Cw0YLRjCBhdXRoIHJlcXVlc3Qg0L/RgNC4IFNT?= =?UTF-8?B?ST8=?= In-Reply-To: <20170522125056.GC55433@mdounin.ru> References: <20170522125056.GC55433@mdounin.ru> Message-ID: <4bfe9bee994df827ed17af9ca88b7e2f.NginxMailingListRussian@forum.nginx.org> Maxim Dounin Wrote: ------------------------------------------------------- > Если хочется какие-то ssi-фрагменты показывать в зависимости от > результата auth_request, то следует использовать auth_request для > основного запроса, и вернуть положительный результат, параллельно > установив дополнительную переменную через auth_request_set. После > чего проверять переменную с помощью, например, SSI-команды "if". Спасибо за совет! Не получается установить переменную: auth_request_set $x_allow_test2 $upstream_http_x_allow_test2; Она всегда пустая. auth_request_set $server $upstream_http_server; тоже пустая. Нашел аналогичный вопрос https://forum.nginx.org/read.php?2,233582,233586#msg-233586 , но так и не понял, как исправить Mistake #1. Конфиг: ssi on; location = /test1.html { auth_request /test_auth; auth_request_set $x_allow_test2 $upstream_http_x_allow_test2; } location = /test2.html { } location = /test_auth { add_header X-Allow-Test2 1; return 200; } test1.html: test1 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274370,274394#msg-274394 From nginx-forum на forum.nginx.org Tue May 23 00:35:49 2017 From: nginx-forum на forum.nginx.org (BorisK2) Date: Mon, 22 May 2017 20:35:49 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC00LXQu9Cw0YLRjCBhdXRoIHJlcXVlc3Qg0L/RgNC4IFNT?= =?UTF-8?B?ST8=?= In-Reply-To: <20170522125440.GD55433@mdounin.ru> References: <20170522125440.GD55433@mdounin.ru> Message-ID: > Ну и да, отмечу в скобках, что возможно вам auth_request тут > вообще не надо, а вполне хватит обычного <--#include ... > set="variable" -->, 1. По документации непонятно, что за "результат выполнения запроса" будет в переменной? body в переменной вместо вывода на экран? $upstream_http_*? 2. Это где именно использовать? В test1.html, где include file="test2.html"? 3. Наверное, вместо auth_request можно из test1 всегда подключать test2. А уже при обработке test проверять права и возвращать либо пустую строку, либо содержимое файла test2 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274370,274395#msg-274395 From mdounin на mdounin.ru Tue May 23 12:35:42 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 23 May 2017 15:35:42 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC00LXQu9Cw0YLRjCBhdXRoIHJlcXVlc3Qg0L/RgNC4IFNT?= =?UTF-8?B?ST8=?= In-Reply-To: References: <20170522125440.GD55433@mdounin.ru> Message-ID: <20170523123542.GH55433@mdounin.ru> Hello! On Mon, May 22, 2017 at 08:35:49PM -0400, BorisK2 wrote: > > Ну и да, отмечу в скобках, что возможно вам auth_request тут > > вообще не надо, а вполне хватит обычного <--#include ... > > set="variable" -->, > > 1. По документации непонятно, что за "результат выполнения запроса" будет в > переменной? body в переменной вместо вывода на экран? $upstream_http_*? Речь про тело ответа. > 2. Это где именно использовать? В test1.html, где include > file="test2.html"? Записать в переменную результат выполнения подзапроса, далее if'ом проверить нужное. Где это делать - не принципиально, вариантов масса. > 3. Наверное, вместо auth_request можно из test1 всегда подключать test2. А > уже при обработке test проверять права и возвращать либо пустую строку, либо > содержимое файла test2 Можно и так. Речь в первую очередь о том, что SSI сам умеет подзапросы, и прикручивать к нему дополнительно auth_request - особого смысла нет, всё можно сделать средствами SSI. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Tue May 23 12:58:26 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 23 May 2017 15:58:26 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC00LXQu9Cw0YLRjCBhdXRoIHJlcXVlc3Qg0L/RgNC4IFNT?= =?UTF-8?B?ST8=?= In-Reply-To: <4bfe9bee994df827ed17af9ca88b7e2f.NginxMailingListRussian@forum.nginx.org> References: <20170522125056.GC55433@mdounin.ru> <4bfe9bee994df827ed17af9ca88b7e2f.NginxMailingListRussian@forum.nginx.org> Message-ID: <20170523125826.GI55433@mdounin.ru> Hello! On Mon, May 22, 2017 at 08:23:27PM -0400, BorisK2 wrote: > Maxim Dounin Wrote: > ------------------------------------------------------- > > Если хочется какие-то ssi-фрагменты показывать в зависимости от > > результата auth_request, то следует использовать auth_request для > > основного запроса, и вернуть положительный результат, параллельно > > установив дополнительную переменную через auth_request_set. После > > чего проверять переменную с помощью, например, SSI-команды "if". > > Спасибо за совет! > Не получается установить переменную: auth_request_set $x_allow_test2 > $upstream_http_x_allow_test2; > Она всегда пустая. auth_request_set $server $upstream_http_server; тоже > пустая. > > Нашел аналогичный вопрос > https://forum.nginx.org/read.php?2,233582,233586#msg-233586 , но так и не > понял, как исправить Mistake #1. > > Конфиг: > ssi on; > > location = /test1.html { > auth_request /test_auth; > auth_request_set $x_allow_test2 $upstream_http_x_allow_test2; > } > > location = /test2.html { > } > > location = /test_auth { > add_header X-Allow-Test2 1; > return 200; > } > > > test1.html: > test1 > > > Вы пытаетесь использовать переменную $upstream_http_x_allow_test2. Однако переменные $upstream_http_* отражают заголовки, полученные от бекенда при проксировании (http://nginx.org/r/$upstream_http_/ru). У вас же проксирование не используется, и переменная ожидаемо пустая. Если речь идёт о том, чтобы поставить переменную в рамках подзапроса непосредственно из конфига nginx'а, то вместо auth_request_set просто сделайте set, как-то так: location = /test_auth { set $x_allow_test2 1; return 200; } Пространство переменных у запросов и подзапроса - общее, так что установленная в подзапросе переменная будет доступна в основном запросе. Директива auth_request_set нужна тогда, когда речь идёт про специальные переменные, такие как $upstream_http_*, которые могут иметь различные значения в зависимости от того, где именно к ним обращаются. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Tue May 23 22:10:32 2017 From: nginx-forum на forum.nginx.org (BorisK2) Date: Tue, 23 May 2017 18:10:32 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC00LXQu9Cw0YLRjCBhdXRoIHJlcXVlc3Qg0L/RgNC4IFNT?= =?UTF-8?B?ST8=?= In-Reply-To: <20170523125826.GI55433@mdounin.ru> References: <20170523125826.GI55433@mdounin.ru> Message-ID: <296f8cd645d842cb5263ed939259adaa.NginxMailingListRussian@forum.nginx.org> Спасибо! Свою задачу я решил следующим образом: test1.html test1 Конфиг: map $cookie_user_id:$request_uri $allow { default 0; 1234:/path/page1.html 1; 4567:/path/page1.html 1; } server { ssi on; location = /test1.html { } location = /test2.html { internal; } } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274370,274416#msg-274416 From nginx-forum на forum.nginx.org Tue May 23 22:44:18 2017 From: nginx-forum на forum.nginx.org (BorisK2) Date: Tue, 23 May 2017 18:44:18 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC00LXQu9Cw0YLRjCBhdXRoIHJlcXVlc3Qg0L/RgNC4IFNT?= =?UTF-8?B?ST8=?= In-Reply-To: <296f8cd645d842cb5263ed939259adaa.NginxMailingListRussian@forum.nginx.org> References: <20170523125826.GI55433@mdounin.ru> <296f8cd645d842cb5263ed939259adaa.NginxMailingListRussian@forum.nginx.org> Message-ID: Первый вариант решает задачу, но для многих статей/ссылок придется делать слишком много переменных. В реальности же редакторам можно редактировать любую статью. Поэтому сделал второй вариант. Логика не html, а в конфиге, где можно использовать rewrite и другое, чтобы множество прав и переменных свести к нескольким. test1.html: test1 конфиг: map $cookie_user_id:$request_uri $allow { default 0; 1234:/path/page1.html 1; 4567:/path/page1.html 1; } server { ssi on; location = /test1.html { } location = /test2.html { internal; if ($allow = 0) { return 403; } } } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274370,274417#msg-274417 From nginx-forum на forum.nginx.org Wed May 24 07:45:19 2017 From: nginx-forum на forum.nginx.org (Vladislavik) Date: Wed, 24 May 2017 03:45:19 -0400 Subject: =?UTF-8?B?UmU6IDUwMC3RjyDQvtGI0LjQsdC60LAg0L/RgNC4INC40YHQv9C+0LvRjNC30L4=?= =?UTF-8?B?0LLQsNC90LjQuCDQutC10YjQsA==?= In-Reply-To: <20160607193820.GF36620@mdounin.ru> References: <20160607193820.GF36620@mdounin.ru> Message-ID: <7eb99f538ddfbcf4f6a9b1af05aecdeb.NginxMailingListRussian@forum.nginx.org> Полностью согласен с топикстартером, вчера весь день нервы истрепал с поддержкой sucuri, они мне говорят ищи 500 ошибку у себя, я им говорю, что это у вас касячное ПО, пока они не нашли что переполнился keys_zone. И смысл отдавать 500, если кэш не получилось сохранить... только день убитый и куча нервов... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267328,274422#msg-274422 From nginx-forum на forum.nginx.org Wed May 24 07:49:40 2017 From: nginx-forum на forum.nginx.org (Vladislavik) Date: Wed, 24 May 2017 03:49:40 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IGNhY2hlIG1hbmFnZXIgcHJvY2VzcyDQvdC1INGB0L7QsdC70Y4=?= =?UTF-8?B?0LTQsNC10YIgbWF4IHNpemUg0YDQsNC30LzQtdGA0LAg0LrQtdGI0LA=?= In-Reply-To: <0A7EC356-DD84-4E7C-8DCB-CCA6A12AC026@ya.ru> References: <0A7EC356-DD84-4E7C-8DCB-CCA6A12AC026@ya.ru> Message-ID: Была проблема с включенным http2, после того как выключили, вроде стал держать размер строго. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274159,274423#msg-274423 From nginx-forum на forum.nginx.org Thu May 25 08:12:11 2017 From: nginx-forum на forum.nginx.org (Trurl) Date: Thu, 25 May 2017 04:12:11 -0400 Subject: =?UTF-8?B?0LDQvdCw0LvQvtCzIElmTW9kdWxl?= Message-ID: <8dee2ff7ddec32fdd96347ab9275eaf3.NginxMailingListRussian@forum.nginx.org> А есть/будет ли какой-то способ управления конфигами в зависимости от загруженных модулей? А то у меня уже достаточно много различных динамических модулей, и при этом достаточно сложная конфигурация. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274430,274430#msg-274430 From onokonem на gmail.com Thu May 25 09:23:08 2017 From: onokonem на gmail.com (Daniel Podolsky) Date: Thu, 25 May 2017 12:23:08 +0300 Subject: =?UTF-8?B?UmU6INCw0L3QsNC70L7QsyBJZk1vZHVsZQ==?= In-Reply-To: <8dee2ff7ddec32fdd96347ab9275eaf3.NginxMailingListRussian@forum.nginx.org> References: <8dee2ff7ddec32fdd96347ab9275eaf3.NginxMailingListRussian@forum.nginx.org> Message-ID: > А есть/будет ли какой-то способ управления конфигами в зависимости от > загруженных модулей? вот не хотел Игорь делать динамические модули, не хотел... From nginx-forum на forum.nginx.org Thu May 25 09:37:26 2017 From: nginx-forum на forum.nginx.org (Trurl) Date: Thu, 25 May 2017 05:37:26 -0400 Subject: =?UTF-8?B?UmU6INCw0L3QsNC70L7QsyBJZk1vZHVsZQ==?= In-Reply-To: References: Message-ID: <8ed27fdca72c2436bbde132f61b05866.NginxMailingListRussian@forum.nginx.org> Ну вот у меня есть 4 разных вида серверов, и вести поддержку билдов для каждого из них отдельно как-то напряжно. А так вынес часть в модули и всё красиво. В принципе у меня и конфигурация полностью генерируется, но, на случай ошибки хотелось бы сделать так, чтоб "лишняя" часть конфигов просто не работала, а не блокировала наглухо запуск ноды вообще. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274430,274433#msg-274433 From exelib на gmail.com Thu May 25 10:37:50 2017 From: exelib на gmail.com (Anton Bessonov) Date: Thu, 25 May 2017 12:37:50 +0200 Subject: =?UTF-8?B?0J/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUg0L3QsCBhd3MvYWxi?= In-Reply-To: References: Message-ID: <5926B3FE.1080406@gmail.com> Здравстуйте, есть такой сетап: интернет -> внешний alb -> энджин (ECS-Cluster) -> внутренний alb -> кучка сервисов (ECS-Cluster). alb меняет время от времени свой айпи адрес, а энджин новый адрес не резольвит. Нашол https://distinctplace.com/2017/04/19/nginx-resolver-explained/. Как узнать айпи адрес резольвера? ЛоадБалансер прикреплён к двум AZ: CIDR 10.180.24.0/21 и 10.180.32.0/21 . Правильно ли я понимаю, что конфигурация должна выглядить следующим образом (особенно айпи резольвера при ECS): server { listen 0.0.0.0:8000 ; location /service { resolver 10.180.24.2 10.180.32.2 valid=5s; set $upstream_endpoint http://${ALB_URL}; proxy_pass $upstream_endpoint; } location /otherservice { resolver 10.180.24.2 10.180.32.2 valid=5s; [...] Как я понимаю, то при смене айпи есть вероятность в течении 5ти секунд, что возникнет предыдущая ощибка: connect() failed (113: No route to host) while connecting to upstream Как можно избежать этого? Ну и вопрос удобства. Что можно куда вынести из локейшн? В данный момент конфиг выглядит следующим образом: upstream frontend { server ${ALB_URL}; } server { listen 0.0.0.0:8000 ; location /service { proxy_pass http://frontend; } location /otherservice { proxy_pass http://frontend; } [...] И так как блоков сервер и локейшн много, не хотелось бы копипейстить. Где и что можно применять стоит в документации, но вопрос в том, будет ли работать хак с обновлением айпи адреса в резольвере? С уважением, Антон -------------- next part -------------- An HTML attachment was scrubbed... URL: From server_inc на list.ru Fri May 26 00:17:22 2017 From: server_inc на list.ru (=?UTF-8?B?0KHRgtCw0L3QuNGB0LvQsNCy?=) Date: Thu, 25 May 2017 17:17:22 -0700 Subject: =?UTF-8?B?0J7Qs9GA0LDQvdC40YfQtdC90LjQtSDQtNC+0YHRgtGD0L/QsCDQv9C+INCw0YA=?= =?UTF-8?B?0LPRg9C80LXQvdGC0YMg0LIgcXVlcnkgc3RyaW5n?= Message-ID: <9105ad4b-1484-6829-c1d6-37395e498a70@list.ru> Привет, Появилась такая задача - если от клиента в query string присутствует аргумент "controller", nginx должен что-то делать (например разрывать соединение). Было сделано такое: if ($arg_controller) { return 444 ; } Работало, нашли как это можно обойти: curl -s -L -D - http://localhost/testme.php?controller=&controller=heresmysecretkeyword Nginx не будет делать "return 444" так как аргумент controller пустой (не определен), второй аргумент с таким же именем nginx игнорирует. Данные передаются бэкэнду таким способом: location = /testme.php { ..... fastcgi_param QUERY_STRING controller=$secret_var&$args; ..... } Где $args приобретает форму: controller=&controller=heresmysecretkeyword Бэкэнд перезаписывает аргумент последним аргументом в query string, и в код интерпретируемым бэкэндом передается heresmysecretkeyword . Сталкивался кто-то с такой ситуацией? Как можно это пофиксить если нет возможности трогать сам бэкэнд. Пока только в голову приходит проверять регулярным выражением $args на присутствие нежелаемого аргумента. Не очень хочу юзать тут regex :/ From mdounin на mdounin.ru Fri May 26 13:13:14 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 26 May 2017 16:13:14 +0300 Subject: =?UTF-8?B?UmU6INCe0LPRgNCw0L3QuNGH0LXQvdC40LUg0LTQvtGB0YLRg9C/0LAg0L/QviA=?= =?UTF-8?B?0LDRgNCz0YPQvNC10L3RgtGDINCyIHF1ZXJ5IHN0cmluZw==?= In-Reply-To: <9105ad4b-1484-6829-c1d6-37395e498a70@list.ru> References: <9105ad4b-1484-6829-c1d6-37395e498a70@list.ru> Message-ID: <20170526131314.GA55433@mdounin.ru> Hello! On Thu, May 25, 2017 at 05:17:22PM -0700, Станислав wrote: > Привет, > > Появилась такая задача - если от клиента в query string присутствует > аргумент "controller", nginx должен что-то делать (например разрывать > соединение). Было сделано такое: > > if ($arg_controller) { > return 444 ; > } > > Работало, нашли как это можно обойти: curl -s -L -D - > http://localhost/testme.php?controller=&controller=heresmysecretkeyword > > Nginx не будет делать "return 444" так как аргумент controller пустой > (не определен), второй аргумент с таким же именем nginx игнорирует. > Данные передаются бэкэнду таким способом: > > location = /testme.php { > ..... > fastcgi_param QUERY_STRING controller=$secret_var&$args; > ..... > } > > Где $args приобретает форму: controller=&controller=heresmysecretkeyword > > Бэкэнд перезаписывает аргумент последним аргументом в query string, и в > код интерпретируемым бэкэндом передается heresmysecretkeyword . > > Сталкивался кто-то с такой ситуацией? Как можно это пофиксить если нет > возможности трогать сам бэкэнд. Пока только в голову приходит проверять > регулярным выражением $args на присутствие нежелаемого аргумента. Не > очень хочу юзать тут regex :/ Лучше всего - на пытаться завязывать безопасность на аргументы запроса, тем более - на их разбор nginx'ом через переменные $arg_*. Разбор аргументов запроса не стандартизирован, и это может много где выйти боком: как в вашем случае по разному может обрабатываться случай нескольких аргументов, или же бекенд может понимать более одного разделителя (скажем, php обычно поддерживает не только "&", но и ";"), и так далее. Если очень надо - выясняйте подробности обработки аргументов бекендом и фильтруйте по $args. Но, как уже сказано выше, лучше всего вообще не пытаться этого делать. -- Maxim Dounin http://nginx.org/ From gmm на csdoc.com Fri May 26 16:26:14 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 26 May 2017 19:26:14 +0300 Subject: =?UTF-8?Q?Priority_of_X-Accel-Expires=2C_=D0=A1ache-=D0=A1ontrol=2C_Expire?= =?UTF-8?Q?s?= Message-ID: Здравствуйте! На странице http://mailman.nginx.org/pipermail/nginx/2011-December/030797.html Maxim Dounin написано: First of the Expires and/or Cache-Control is used. В то же самое время, на странице https://support.cloudflare.com/hc/en-us/articles/202775670-How-Do-I-Tell-Cloudflare-What-to-Cache- написано: Note: As per RFC rules, "Cache-Control: max-age" trumps "Expires" headers. If we see both and they do not agree, max-age wins. Из этого следует что nginx не совсем соответствует RFC, или в сообщении от 2011 года устаревшая информация? -- Best regards, Gena From mdounin на mdounin.ru Fri May 26 16:51:24 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 26 May 2017 19:51:24 +0300 Subject: =?UTF-8?Q?Re=3A_Priority_of_X-Accel-Expires=2C_=D0=A1ache-=D0=A1ontrol=2C_?= =?UTF-8?Q?Expires?= In-Reply-To: References: Message-ID: <20170526165124.GI55433@mdounin.ru> Hello! On Fri, May 26, 2017 at 07:26:14PM +0300, Gena Makhomed wrote: > Здравствуйте! > > На странице > http://mailman.nginx.org/pipermail/nginx/2011-December/030797.html > Maxim Dounin написано: > > First of the Expires and/or Cache-Control is used. > > В то же самое время, на странице > https://support.cloudflare.com/hc/en-us/articles/202775670-How-Do-I-Tell-Cloudflare-What-to-Cache- > написано: > > Note: As per RFC rules, "Cache-Control: max-age" trumps "Expires" > headers. If we see both and they do not agree, max-age wins. > > Из этого следует что nginx не совсем соответствует RFC, > или в сообщении от 2011 года устаревшая информация? Поведение было приведено в большее соответствие с RFC в 2014 году (nginx 1.5.9): http://hg.nginx.org/nginx/rev/6a3ab6fdd70f Однако там по прежнему не всё строго, в частности - если директива Expires идёт первой и совсем запрещает кеширование, то кеширование использоваться не будет. У нас даже есть тикет про это, https://trac.nginx.org/nginx/ticket/964. -- Maxim Dounin http://nginx.org/ From server_inc на list.ru Fri May 26 19:02:03 2017 From: server_inc на list.ru (=?UTF-8?B?0KHRgtCw0L3QuNGB0LvQsNCy?=) Date: Fri, 26 May 2017 12:02:03 -0700 Subject: =?UTF-8?B?UmU6INCe0LPRgNCw0L3QuNGH0LXQvdC40LUg0LTQvtGB0YLRg9C/0LAg0L/QviA=?= =?UTF-8?B?0LDRgNCz0YPQvNC10L3RgtGDINCyIHF1ZXJ5IHN0cmluZw==?= In-Reply-To: <20170526131314.GA55433@mdounin.ru> References: <9105ad4b-1484-6829-c1d6-37395e498a70@list.ru> <20170526131314.GA55433@mdounin.ru> Message-ID: <36dfd9df-5c8a-ca4d-047c-3c24ce2e6a66@list.ru> > Hello! > > On Thu, May 25, 2017 at 05:17:22PM -0700, Станислав wrote: > >> Привет, >> >> Появилась такая задача - если от клиента в query string присутствует >> аргумент "controller", nginx должен что-то делать (например разрывать >> соединение). Было сделано такое: >> >> if ($arg_controller) { >> return 444 ; >> } >> >> Работало, нашли как это можно обойти: curl -s -L -D - >> http://localhost/testme.php?controller=&controller=heresmysecretkeyword >> >> Nginx не будет делать "return 444" так как аргумент controller пустой >> (не определен), второй аргумент с таким же именем nginx игнорирует. >> Данные передаются бэкэнду таким способом: >> >> location = /testme.php { >> ..... >> fastcgi_param QUERY_STRING controller=$secret_var&$args; >> ..... >> } >> >> Где $args приобретает форму: controller=&controller=heresmysecretkeyword >> >> Бэкэнд перезаписывает аргумент последним аргументом в query string, и в >> код интерпретируемым бэкэндом передается heresmysecretkeyword . >> >> Сталкивался кто-то с такой ситуацией? Как можно это пофиксить если нет >> возможности трогать сам бэкэнд. Пока только в голову приходит проверять >> регулярным выражением $args на присутствие нежелаемого аргумента. Не >> очень хочу юзать тут regex :/ > Лучше всего - на пытаться завязывать безопасность на аргументы > запроса, тем более - на их разбор nginx'ом через переменные > $arg_*. Разбор аргументов запроса не стандартизирован, и это > может много где выйти боком: как в вашем случае по разному может > обрабатываться случай нескольких аргументов, или же бекенд может > понимать более одного разделителя (скажем, php обычно поддерживает > не только "&", но и ";"), и так далее. > > Если очень надо - выясняйте подробности обработки аргументов > бекендом и фильтруйте по $args. Но, как уже сказано выше, лучше > всего вообще не пытаться этого делать. > Спасибо за информацию Максим. Будем пробовать фиксить сторону бэкэнда. From nginx на mva.name Sat May 27 09:44:50 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Sat, 27 May 2017 16:44:50 +0700 Subject: =?UTF-8?B?W2ZlYXR1cmVdINC00LjRgNC10LrRgtC40LLQsCBzc2wg0LTQu9GPIGludGVybWVk?= =?UTF-8?B?aWF0ZSDRgdC10YDRgtC40YTQuNC60LDRgtC+0LIv0LHQsNC90LTQu9C+0LI=?= Message-ID: <7474878.XTvfhTvdsP@note> А что уважаемые разработчики думают об имплементации ssl_* директивы для указания в ней intermediate-сертификатов/бандлов (чтобы в certificate можно было указывать только сертификат самого сайта)? From nginx-forum на forum.nginx.org Sat May 27 15:26:21 2017 From: nginx-forum на forum.nginx.org (Schumi) Date: Sat, 27 May 2017 11:26:21 -0400 Subject: =?UTF-8?B?0J/QvtC70YPRh9C40YLRjCDRhNCw0LnQuyDQsiDQv9Cw0L/QutC1?= Message-ID: <6de40be5b914bdbf780026100263e855.NginxMailingListRussian@forum.nginx.org> ubuntu 16.04 x64. Установил nginx из репозитария, конфиг по умолчанию. Вижу в /var/www/html index-файлик, при открытии в браузере вижу его содержание. Теперь докидываю в эту же директорию новый файлик. Я знаю его имя, поэтому к урлу добавляю его имя и спокойно открываю второй файл в браузере. А может кто-либо подобрать это имя и также открыть его в браузере? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274475,274475#msg-274475 From vbart на nginx.com Sat May 27 15:36:44 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 27 May 2017 18:36:44 +0300 Subject: =?UTF-8?B?UmU6INCf0L7Qu9GD0YfQuNGC0Ywg0YTQsNC50Lsg0LIg0L/QsNC/0LrQtQ==?= In-Reply-To: <6de40be5b914bdbf780026100263e855.NginxMailingListRussian@forum.nginx.org> References: <6de40be5b914bdbf780026100263e855.NginxMailingListRussian@forum.nginx.org> Message-ID: <9321183.eMuvL3clsD@vbart-laptop> On Saturday 27 May 2017 11:26:21 Schumi wrote: > ubuntu 16.04 x64. Установил nginx из репозитария, конфиг по умолчанию. > Вижу в /var/www/html index-файлик, при открытии в браузере вижу его > содержание. > Теперь докидываю в эту же директорию новый файлик. Я знаю его имя, поэтому к > урлу добавляю его имя и спокойно открываю второй файл в браузере. > А может кто-либо подобрать это имя и также открыть его в браузере? > [..] Когда вы открываете его в браузере, то ваш браузер может об этом рассказать куда-то, например в Google. Так что и подбирать ничего не придется. -- Валентин Бартенев From nginx-forum на forum.nginx.org Sat May 27 15:47:57 2017 From: nginx-forum на forum.nginx.org (Schumi) Date: Sat, 27 May 2017 11:47:57 -0400 Subject: =?UTF-8?B?UmU6INCf0L7Qu9GD0YfQuNGC0Ywg0YTQsNC50Lsg0LIg0L/QsNC/0LrQtQ==?= In-Reply-To: <9321183.eMuvL3clsD@vbart-laptop> References: <9321183.eMuvL3clsD@vbart-laptop> Message-ID: <51390bab41493b8eb886d6bc8622ab0f.NginxMailingListRussian@forum.nginx.org> А если исходим из соображения, что не передаёт. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274475,274477#msg-274477 From nginx на mva.name Sat May 27 19:33:02 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Sun, 28 May 2017 02:33:02 +0700 Subject: =?UTF-8?B?UmU6INCf0L7Qu9GD0YfQuNGC0Ywg0YTQsNC50Lsg0LIg0L/QsNC/0LrQtQ==?= In-Reply-To: <51390bab41493b8eb886d6bc8622ab0f.NginxMailingListRussian@forum.nginx.org> References: <9321183.eMuvL3clsD@vbart-laptop> <51390bab41493b8eb886d6bc8622ab0f.NginxMailingListRussian@forum.nginx.org> Message-ID: <42467164.gfSdNDSy5U@note> > А если исходим из соображения, что не передаёт. Вы, конечно, простите, но... Вам просто поговорить захотелось? Ваш вопрос не имеет ровным счётом ничего общего с NginX и списком рассылки по нему. (Да, то, что вы поставили NginX и этот вопрос у вас возник при работе с ним - не играет никакой роли. Сам вопрос оффтопичен до последнего байта). Ваш вопрос - самый что ни на есть философский. И ответ на него прсто до БОЛИ очевиден: да, любой {человек, бот, инопланетянин} СМОЖЕТ подобрать URL, если ему будет нечем заняться и он начнёт перебирать брутфорсом. Вопрос лишь в количестве затраченного времени. Почему это не очевидно лично для вас? Почему вы думаете, что мы — телепаты-во-времени-и-параллельных-реальностях и *В ПРИНЦИПЕ* можем знать ответ на вопрос "сможет ли кто-нибудь" как таковой? Ну и чтобы второй раз не вставать, на будущее (информация для саморазвития): > x64 Нет такой буквы в этом слове! Это выдумка маркетологов из M$. Есть архитектура x86_64. Более известная как amd64 (в честь тех, кто первый выкатил на рынок. И это вовсе не означает amd- процессор) > из репозитария 1) репозитория 2) КАКОГО? Есть дистрибутивные, а есть с сайта nginx'а. Пакеты там СОВЕРШЕННО разные. Абсолютно. От слова "совсем". > конфиг по умолчанию Как правило, среднестатистический участник рассылки вообще не в курсе, какие там у вас в убунте умолчания. Куча людей здесь вообще использует FreeBSD. Некоторые - извращаются с Windows. У меня, вот, более 70 серверов на Hardened Gentoo (тут история умолчит, что у меня и на ubuntu порядка 30, но они не обязаны были быть, так что не считается). Ещё куча людей использует всякие красношапки и прочие производные типа "копеек" и федор. И никому, поверьте, не хочется просто так (если не сильно интересный вопрос прямо. Что, впрочем, явно противоречит наличию формулировки "дефолтный конфиг" внутри него) тратить время на поиск информации, какой же он там, "дефолтный" конфиг в Ubuntu-то... И самое главное... На ваш изначальный вопрос невозможно *однозначно* ответить ВПРИНЦИПЕ. Потому что в вопросе нет главной информации: ГДЕ ЖЕ ЭТО ВСЁ ПРОИСХОДИТ? Если вы это всё делаете на локалхосте, без перманентного доступа к сети, то шанс, что кто-то подберёт URL — стремится к нулю. Если на какой-то бездоменной VPS, которой пользуетесь только вы — шанс выше, но всё равно мизерный. Если там планирует быть какой-то сайт хотя бы средней посещаемости — шансы ещё выше, но (тут отсылка к началу письма). Только я очень надеюсь, что этот вариант — не тот, который планируется быть в реальности. В общем, вариантов ответа — куча. Поэтому, научитесь, пожалуйста, задавать вопросы МАКСИМАЛЬНО ПОДРОБНО. Если вам, конечно, нужен ответ, а не флейм... // спасибо за внимание From valery+nginx на grid.net.ru Sun May 28 07:34:42 2017 From: valery+nginx на grid.net.ru (Valery Kholodkov) Date: Sun, 28 May 2017 09:34:42 +0200 Subject: =?UTF-8?B?UmU6INCf0L7Qu9GD0YfQuNGC0Ywg0YTQsNC50Lsg0LIg0L/QsNC/0LrQtQ==?= In-Reply-To: <51390bab41493b8eb886d6bc8622ab0f.NginxMailingListRussian@forum.nginx.org> References: <9321183.eMuvL3clsD@vbart-laptop> <51390bab41493b8eb886d6bc8622ab0f.NginxMailingListRussian@forum.nginx.org> Message-ID: <8054f5a7-f809-1b9f-09ec-d20e2be7f8ca@grid.net.ru> Подобрать смогут, если захотят. Оценку вероятности можно получить исходя из энтропии Шеннона. Пример расчета оставлю Вам на домашнее задание. On 27-05-17 17:47, Schumi wrote: > А если исходим из соображения, что не передаёт. From mdounin на mdounin.ru Sun May 28 17:09:34 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sun, 28 May 2017 20:09:34 +0300 Subject: =?UTF-8?B?UmU6IFtmZWF0dXJlXSDQtNC40YDQtdC60YLQuNCy0LAgc3NsINC00LvRjyBpbnRl?= =?UTF-8?B?cm1lZGlhdGUg0YHQtdGA0YLQuNGE0LjQutCw0YLQvtCyL9Cx0LDQvdC00Ls=?= =?UTF-8?B?0L7Qsg==?= In-Reply-To: <7474878.XTvfhTvdsP@note> References: <7474878.XTvfhTvdsP@note> Message-ID: <20170528170934.GL55433@mdounin.ru> Hello! On Sat, May 27, 2017 at 04:44:50PM +0700, Vadim A. Misbakh-Soloviov wrote: > А что уважаемые разработчики думают об имплементации ssl_* директивы для > указания в ней intermediate-сертификатов/бандлов (чтобы в certificate можно > было указывать только сертификат самого сайта)? Плохое думают. Цепочка является, фактически, частью сертификата, и класть её отдельно - неинтуитивно, неудобно, и приведёт скорее к проблемам с перепутанными цепочками, чем к чему-то положительному. В своё время Игорь сделал одну директиву для сертификата и цепочки вместо принятых двух - отдельно для сертификата, отдельно для цепочки - и это, как мне кажется, было однозначным плюсом в части удобства конфигурирования. Причин вдруг всё менять - не прослеживается. Наоборот, я бы подумал о том, чтобы вместе с сертификатом научиться, скажем, класть ещё и OCSP-ответ для stapling'а, а то вот желающие использовать OCSP stapling и Must-Staple жалуются, что ssl_stapling_file нельзя использовать с несколькими сертификатми. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Mon May 29 06:26:36 2017 From: nginx-forum на forum.nginx.org (Schumi) Date: Mon, 29 May 2017 02:26:36 -0400 Subject: =?UTF-8?B?UmU6INCf0L7Qu9GD0YfQuNGC0Ywg0YTQsNC50Lsg0LIg0L/QsNC/0LrQtQ==?= In-Reply-To: <42467164.gfSdNDSy5U@note> References: <42467164.gfSdNDSy5U@note> Message-ID: <9c70348b16e0822ab643e4fdeaa3a635.NginxMailingListRussian@forum.nginx.org> Vadim A. Misbakh-Soloviov, а как тогда правильно писать архитектуру, i386 и x86_64? Не совсем понимаю насчёт пакетов. Что значит совершенно разные, если мы говорим условно об одной и тоже версии? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274475,274483#msg-274483 From nginx-forum на forum.nginx.org Mon May 29 14:43:46 2017 From: nginx-forum на forum.nginx.org (RomkaV) Date: Mon, 29 May 2017 10:43:46 -0400 Subject: =?UTF-8?B?0J/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgSFRUUFMgKyDQsNCy0YLQvtGA0Lg=?= =?UTF-8?B?0LfQsNGG0LjRjyDQvdCwINCx0Y3QutGN0LXQvdC00LUg0L/QviDQutC70Y4=?= =?UTF-8?B?0YfQsNC8?= Message-ID: <3dca82a8ac2f764093063a8c05af13a9.NginxMailingListRussian@forum.nginx.org> Доброго времени суток! На фронтэнде установление сертификат компании, на бэкэнде организована авторизация клиентов по ключам. Есть задача: надо сделать локейшн на фронтэнде, который проксируется на бэкэнд, опять же надо, чтоб клиентский сертификат попал на бэкенд. На текущий момент зашел в тупик - сертификат клиента не попадает на бэкэнд через фронтэнд. Возможно ли такое реализовать? # Frontend server { listen 127.0.0.1:443 ssl default_server; ssl on; ssl_certificate /etc/nginx/ssl/server.crt; ssl_certificate_key /etc/nginx/ssl/server.key; ssl_client_certificate /etc/nginx/ssl/ca.crt; ssl_crl /etc/nginx/ssl/revoked/crl.pem; ssl_verify_client on; root /var/www/; index index.html index.htm ; } #Backend server { listen 127.0.0.1:8443; ssl on; ssl_certificate /etc/nginx/company_ssl/ssl.company.com.crt; ssl_certificate_key /etc/nginx/company_ssl/ssl.company.com.key; root /var/www2/; location / { proxy_pass https://127.0.0.1:443; proxy_set_header X-SSL-CLIENT-CERT $ssl_client_cert; proxy_set_header X-SSL-ClIENT-S-DN $ssl_client_s_dn; proxy_set_header X-CLIENT-VERIFY $ssl_client_verify; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; proxy_redirect off; } } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274494,274494#msg-274494 From nginx-forum на forum.nginx.org Mon May 29 17:25:34 2017 From: nginx-forum на forum.nginx.org (recived) Date: Mon, 29 May 2017 13:25:34 -0400 Subject: =?UTF-8?B?0JrQsNC6INCy0YvRgNC10LfQsNGC0Ywg0YfQsNGB0YLRjCDRg9GA0LvQsCDQtNC+?= =?UTF-8?B?INC30L3QsNC60LAg0LLQvtC/0YDQvtGB0LAg0Lgg0YHQtNC10LvQsNGC0Ywg?= =?UTF-8?B?0YDQtdC00LjRgNC10LrRgj8=?= Message-ID: <3114547e406484791b46a24be8c0023a.NginxMailingListRussian@forum.nginx.org> Добрый день. Есть такой урл => example.com/compgraf/space/25623/3717/lesson.doc?width=1&height=y Необходимо вырезать /compgraf/space/25623/3717/lesson.doc и вставить вконец example.com/download.html?file= чтобы получился вот такой запрос: example.com/download.html?file=/compgraf/space/25623/3717/lesson.doc Подскажите, как средствами ngnix сделать перенаправление в секции location. Спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274495,274495#msg-274495 From vladget на gmail.com Mon May 29 19:20:56 2017 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Mon, 29 May 2017 19:20:56 +0000 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IEhUVFBTICsg0LDQstGC0L4=?= =?UTF-8?B?0YDQuNC30LDRhtC40Y8g0L3QsCDQsdGN0LrRjdC10L3QtNC1INC/0L4g0Lo=?= =?UTF-8?B?0LvRjtGH0LDQvA==?= In-Reply-To: <3dca82a8ac2f764093063a8c05af13a9.NginxMailingListRussian@forum.nginx.org> References: <3dca82a8ac2f764093063a8c05af13a9.NginxMailingListRussian@forum.nginx.org> Message-ID: Авторизируйте клиента на фронте и просто передавайте переменные удачной/не удачной авторизации на бэк, а там уже или 403 или "здрасьте заходите", опшинал только верификацию настройте.. пн, 29 трав. 2017 о 17:43 RomkaV пише: > Доброго времени суток! > На фронтэнде установление сертификат компании, на бэкэнде организована > авторизация клиентов по ключам. Есть задача: надо сделать локейшн на > фронтэнде, который проксируется на бэкэнд, опять же надо, чтоб клиентский > сертификат попал на бэкенд. На текущий момент зашел в тупик - сертификат > клиента не попадает на бэкэнд через фронтэнд. > Возможно ли такое реализовать? > > # Frontend > server { > listen 127.0.0.1:443 ssl default_server; > > ssl on; > ssl_certificate /etc/nginx/ssl/server.crt; > ssl_certificate_key /etc/nginx/ssl/server.key; > ssl_client_certificate /etc/nginx/ssl/ca.crt; > ssl_crl /etc/nginx/ssl/revoked/crl.pem; > ssl_verify_client on; > > root /var/www/; > index index.html index.htm ; > > } > > #Backend > server { > listen 127.0.0.1:8443; > > ssl on; > ssl_certificate /etc/nginx/company_ssl/ssl.company.com.crt; > ssl_certificate_key /etc/nginx/company_ssl/ssl.company.com.key; > > root /var/www2/; > > > location / { > proxy_pass https://127.0.0.1:443; > proxy_set_header X-SSL-CLIENT-CERT $ssl_client_cert; > proxy_set_header X-SSL-ClIENT-S-DN $ssl_client_s_dn; > proxy_set_header X-CLIENT-VERIFY $ssl_client_verify; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header X-Forwarded-Proto https; > proxy_redirect off; > } > } > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,274494,274494#msg-274494 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue May 30 07:58:00 2017 From: nginx-forum на forum.nginx.org (RomkaV) Date: Tue, 30 May 2017 03:58:00 -0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IEhUVFBTICsg0LDQstGC0L4=?= =?UTF-8?B?0YDQuNC30LDRhtC40Y8g0L3QsCDQsdGN0LrRjdC10L3QtNC1INC/0L4g0Lo=?= =?UTF-8?B?0LvRjtGH0LDQvA==?= In-Reply-To: References: Message-ID: <45f6d326b7d79fe7edb44da4a1e46192.NginxMailingListRussian@forum.nginx.org> В том вся и проблема, что FE один, и на нём висит еще несколько сайтов, а BE несколько. nginx(FE) может же вставить сертификат в header, но BE его не воспринимает. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274494,274502#msg-274502 From chipitsine на gmail.com Tue May 30 08:43:17 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 30 May 2017 13:43:17 +0500 Subject: =?UTF-8?B?0YTQuNGH0LAg0YDQtdC60LLQtdGB0YIg0L/QviDRhNC+0YDQvNCw0YLRgyDQu9C+?= =?UTF-8?B?0LPQvtCy?= Message-ID: Добрый день! смотрели в сторону формата W3C ? https://msdn.microsoft.com/en-us/library/windows/desktop/aa814385%28v=vs.85%29.aspx формат замечателен тем, что в начале каждого файла с логом есть мета-информация со списком полей (и под этот формат есть куча наработок типа Microsoft LogParser) Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From rogat1y на gmail.com Tue May 30 09:05:04 2017 From: rogat1y на gmail.com (Maxim Kozlov) Date: Tue, 30 May 2017 12:05:04 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQstGL0YDQtdC30LDRgtGMINGH0LDRgdGC0Ywg0YPRgNC70LAg?= =?UTF-8?B?0LTQviDQt9C90LDQutCwINCy0L7Qv9GA0L7RgdCwINC4INGB0LTQtdC70LA=?= =?UTF-8?B?0YLRjCDRgNC10LTQuNGA0LXQutGCPw==?= In-Reply-To: <3114547e406484791b46a24be8c0023a.NginxMailingListRussian@forum.nginx.org> References: <3114547e406484791b46a24be8c0023a.NginxMailingListRussian@forum.nginx.org> Message-ID: rewrite ^/(.*)$ /download.html?file=$1; 29 мая 2017 г., 20:25 пользователь recived написал: > Добрый день. Есть такой урл => > example.com/compgraf/space/25623/3717/lesson.doc?width=1&height=y > Необходимо вырезать /compgraf/space/25623/3717/lesson.doc и вставить > вконец > example.com/download.html?file= чтобы получился вот такой запрос: > example.com/download.html?file=/compgraf/space/25623/3717/lesson.doc > > Подскажите, как средствами ngnix сделать перенаправление в секции location. > Спасибо! > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,274495,274495#msg-274495 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue May 30 14:53:32 2017 From: nginx-forum на forum.nginx.org (Dee Dee) Date: Tue, 30 May 2017 10:53:32 -0400 Subject: =?UTF-8?B?0JzQsNGB0YHQuNGA0L7QstCw0L3QvdGL0LkgcmV3cml0ZSDQuNC70LggbWFwID8=?= Message-ID: <3c712a7ee752f1fad7f925f9a96b298a.NginxMailingListRussian@forum.nginx.org> Добрый день всем. У меня возникла проблема на, казалось бы, простой задаче. У меня есть порядка 300 штук редиректов в разделе блог вида: /blog?page=post&blog=blog_EN&id=298 /blog/topic1-theme-for-russian-speakers/ /blog?page=post&blog=blog_RU&id=300 /blog/webinar-new-staff/ Как я понимаю, тут location это "blog" а далее пошли уже $args. У меня получилось сделать это через map вида: map $args $link { "blog?page=post&blog=blog_EN&id=300" "/blog/webinar-new-staff/"; .... default "/blog/"; } и if ($args) { return 301 $scheme://$host$link; } Всё работает. Но map из трёхсот записей кажется мне громоздким. Есть ли какие-либо варианты решения задачи, которые более элегантны, чем мой ? Заранее большое спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274512,274512#msg-274512 From mdounin на mdounin.ru Tue May 30 15:12:11 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 30 May 2017 18:12:11 +0300 Subject: nginx-1.13.1 Message-ID: <20170530151211.GY55433@mdounin.ru> Изменения в nginx 1.13.1 30.05.2017 *) Добавление: теперь в качестве параметра директивы set_real_ip_from можно указывать имя хоста. *) Добавление: улучшения в скриптах подсветки синтаксиса для vim. *) Добавление: директива worker_cpu_affinity теперь работает на DragonFly BSD. Спасибо Sepherosa Ziehau. *) Исправление: SSL renegotiation в соединениях к бэкендам не работал при использовании OpenSSL до 1.1.0. *) Изменение: nginx не собирался с Oracle Developer Studio 12.5. *) Изменение: теперь cache manager пропускает заблокированные записи при очистке кэша по max_size. *) Исправление: клиентские SSL-соединения сразу закрывались, если использовался отложенный accept и параметр proxy_protocol директивы listen. *) Исправление: в директиве proxy_cache_background_update. *) Изменение: теперь директива tcp_nodelay устанавливает опцию TCP_NODELAY перед SSL handshake. -- Maxim Dounin http://nginx.org/ From annulen на yandex.ru Tue May 30 15:15:17 2017 From: annulen на yandex.ru (Konstantin Tokarev) Date: Tue, 30 May 2017 18:15:17 +0300 Subject: =?UTF-8?B?UmU6INCc0LDRgdGB0LjRgNC+0LLQsNC90L3Ri9C5IHJld3JpdGUg0LjQu9C4IG1h?= =?UTF-8?B?cCA/?= In-Reply-To: <3c712a7ee752f1fad7f925f9a96b298a.NginxMailingListRussian@forum.nginx.org> References: <3c712a7ee752f1fad7f925f9a96b298a.NginxMailingListRussian@forum.nginx.org> Message-ID: <1828881496157317@web6o.yandex.ru> 30.05.2017, 17:53, "Dee Dee" : > Добрый день всем. > > У меня возникла проблема на, казалось бы, простой задаче. У меня есть > порядка 300 штук редиректов в разделе блог вида: > > /blog?page=post&blog=blog_EN&id=298 > /blog/topic1-theme-for-russian-speakers/ > /blog?page=post&blog=blog_RU&id=300 /blog/webinar-new-staff/ > > Как я понимаю, тут location это "blog" а далее пошли уже $args. > У меня получилось сделать это через map вида: > > map $args $link { >         "blog?page=post&blog=blog_EN&id=300" "/blog/webinar-new-staff/"; >          .... >         default "/blog/"; > } > > и > > if ($args) { >                 return 301 $scheme://$host$link; > } > > Всё работает. Но map из трёхсот записей кажется мне громоздким. > Есть ли какие-либо варианты решения задачи, которые более элегантны, чем мой > ? В бэкэнде это делать > > Заранее большое спасибо! > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274512,274512#msg-274512 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From nginx-forum на forum.nginx.org Tue May 30 15:20:05 2017 From: nginx-forum на forum.nginx.org (Dee Dee) Date: Tue, 30 May 2017 11:20:05 -0400 Subject: =?UTF-8?B?UmU6INCc0LDRgdGB0LjRgNC+0LLQsNC90L3Ri9C5IHJld3JpdGUg0LjQu9C4IG1h?= =?UTF-8?B?cCA/?= In-Reply-To: <1828881496157317@web6o.yandex.ru> References: <1828881496157317@web6o.yandex.ru> Message-ID: <83aacff4344e782e9de22f1afc09e863.NginxMailingListRussian@forum.nginx.org> Спасибо за ответ. А если средствами Nginx ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274512,274522#msg-274522 From nginx-forum на forum.nginx.org Tue May 30 21:35:35 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 30 May 2017 17:35:35 -0400 Subject: client_body_temp_path - permissions In-Reply-To: References: Message-ID: <05065dac6ac84393441b953568b67578.NginxMailingListRussian@forum.nginx.org> Я конечно извиняюсь, за настойчивость, но неужели пермишен 0600, на файл который должен быть обработан в другом процессе, это нормально и это никак нельзя настроить в конфиге Nginx? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274059,274538#msg-274538 From arut на nginx.com Wed May 31 17:36:28 2017 From: arut на nginx.com (Roman Arutyunyan) Date: Wed, 31 May 2017 20:36:28 +0300 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgYmFja2dyb3VuZCB1cGRhdGUgc3NpINC/0L7QtNC3?= =?UTF-8?B?0LDQv9GA0L7RgdC+0LI=?= In-Reply-To: <07c422771a3503eaa3ee80cd75e924b7.NginxMailingListRussian@forum.nginx.org> References: <20170510171846.GG94542@Romans-MacBook-Air.local> <07c422771a3503eaa3ee80cd75e924b7.NginxMailingListRussian@forum.nginx.org> Message-ID: <20170531173628.GE77454@Romans-MacBook-Air.local> Патч был закоммичен: http://hg.nginx.org/nginx/rev/9552758a786e (1.13.1) On Thu, May 11, 2017 at 03:58:58AM -0400, metalfm1 wrote: > Роман, огромное вам спасибо! Приложенный патч полностью решает мои проблемы. > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274142,274154#msg-274154 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Roman Arutyunyan