From vladget на gmail.com Fri Jan 4 15:12:11 2019 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Fri, 4 Jan 2019 17:12:11 +0200 Subject: GeoIP Message-ID: Добрый день! Вчера maxmind таки дропнул GeoIP Country файл со своих серверов, в связи с чем хотелось бы разобраться, что вообще происходить с GeoIP и nginx. Разъясните пожалуйста ситуацию. Как я все это вижу: У maxmind была коммерческая GeoIP библиотека данных и программная библиотека для работы с ней, так же была бесплатная, но не очень точная библиотека данных под названием GeoLite. Nginx работал с обоими этими либами через ngx_http_geoip_module... Спустя какое то время maxmind выпустил вторую версию коммерческой либы, а так-же бесплатной либы под названием GeoLite2 и отказался от поддержки первой версии, а вчера вообще дропнул файлы со своих серверов. Все ли так? Поддерживает ли ngx_http_geoip_module GeoLite2? Если нет, то планируется ли разработка поддержки? Какие есть альтернативы maxmind и/или этому модулю? -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From oleg на mamontov.net Fri Jan 4 15:39:14 2019 From: oleg на mamontov.net (Oleg A. Mamontov) Date: Fri, 4 Jan 2019 18:39:14 +0300 Subject: GeoIP In-Reply-To: References: Message-ID: <20190104153914.ohbj67rsjoea7ly7@xenon.mamontov.net> On Fri, Jan 04, 2019 at 05:12:11PM +0200, Vladimir Getmanshchuk wrote: >Добрый день! > >Вчера maxmind таки дропнул GeoIP Country файл со своих серверов, >в связи с чем хотелось бы разобраться, что вообще происходить с GeoIP и >nginx. >Разъясните пожалуйста ситуацию. > >Как я все это вижу: >У maxmind была коммерческая GeoIP библиотека данных и программная >библиотека для работы с ней, >так же была бесплатная, но не очень точная библиотека данных под названием >GeoLite. >Nginx работал с обоими этими либами через ngx_http_geoip_module... >Спустя какое то время maxmind выпустил вторую версию коммерческой либы, а >так-же бесплатной либы под названием GeoLite2 и отказался от поддержки >первой версии, >а вчера вообще дропнул файлы со своих серверов. > >Все ли так? >Поддерживает ли ngx_http_geoip_module GeoLite2? >Если нет, то планируется ли разработка поддержки? >Какие есть альтернативы maxmind и/или этому модулю? Все так, для GeoIP2 есть вполне работоспособный модуль: https://github.com/leev/ngx_http_geoip2_module >-- >Yours sincerely, >Vladimir Getmanshchuk -- Cheers, Oleg A. Mamontov mailto: oleg на mamontov.net skype: lonerr11 cell: +7 (903) 798-1352 From gmm на csdoc.com Fri Jan 4 15:58:03 2019 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 4 Jan 2019 17:58:03 +0200 Subject: GeoIP In-Reply-To: References: Message-ID: On 04.01.2019 17:12, Vladimir Getmanshchuk wrote: > Вчера maxmind таки дропнул GeoIP Country файл со своих серверов, > в связи с чем хотелось бы разобраться, что вообще происходить с GeoIP и > nginx. > Разъясните пожалуйста ситуацию. > > Как я все это вижу: > У maxmind была коммерческая GeoIP библиотека данных и программная > библиотека для работы с ней, > так же была бесплатная, но не очень точная библиотека данных под названием > GeoLite. > Nginx работал с обоими этими либами через ngx_http_geoip_module... > Спустя какое то время maxmind выпустил вторую версию коммерческой либы, а > так-же бесплатной либы под названием GeoLite2 и отказался от поддержки > первой версии, > а вчера вообще дропнул файлы со своих серверов. > > Все ли так? > Поддерживает ли ngx_http_geoip_module GeoLite2? > Если нет, то планируется ли разработка поддержки? > Какие есть альтернативы maxmind и/или этому модулю? Есть альтернативы модулю ngx_http_geoip_module. Я просто конвертирую GeoLite2 в формат, который понимает nginx с помощью своего скрипта https://github.com/makhomed/nginx-geo запускаемого через крон раз в сутки, так что таким образом у меня в nginx используется всегда самая свежая база GeoLite2 через модуль http://nginx.org/en/docs/http/ngx_http_geo_module.html Встроенный в nginx модуль ngx_http_geo_module не использует никаких сторонних библиотек, так что он работает максимально стабильно и надежно, при этом использует минимальное количество памяти. -- Best regards, Gena From vladget на gmail.com Sat Jan 5 10:18:20 2019 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Sat, 5 Jan 2019 12:18:20 +0200 Subject: GeoIP In-Reply-To: References: Message-ID: Всем спасибо за ответы. Гена, с City скрипт тоже корректно работает? On Fri, Jan 4, 2019 at 5:58 PM Gena Makhomed wrote: > On 04.01.2019 17:12, Vladimir Getmanshchuk wrote: > > > Вчера maxmind таки дропнул GeoIP Country файл со своих серверов, > > в связи с чем хотелось бы разобраться, что вообще происходить с GeoIP и > > nginx. > > Разъясните пожалуйста ситуацию. > > > > Как я все это вижу: > > У maxmind была коммерческая GeoIP библиотека данных и программная > > библиотека для работы с ней, > > так же была бесплатная, но не очень точная библиотека данных под > названием > > GeoLite. > > Nginx работал с обоими этими либами через ngx_http_geoip_module... > > Спустя какое то время maxmind выпустил вторую версию коммерческой либы, а > > так-же бесплатной либы под названием GeoLite2 и отказался от поддержки > > первой версии, > > а вчера вообще дропнул файлы со своих серверов. > > > > Все ли так? > > Поддерживает ли ngx_http_geoip_module GeoLite2? > > Если нет, то планируется ли разработка поддержки? > > Какие есть альтернативы maxmind и/или этому модулю? > > Есть альтернативы модулю ngx_http_geoip_module. > > Я просто конвертирую GeoLite2 в формат, который понимает nginx > с помощью своего скрипта https://github.com/makhomed/nginx-geo > запускаемого через крон раз в сутки, так что таким образом > у меня в nginx используется всегда самая свежая база GeoLite2 > через модуль http://nginx.org/en/docs/http/ngx_http_geo_module.html > > Встроенный в nginx модуль ngx_http_geo_module не использует никаких > сторонних библиотек, так что он работает максимально стабильно > и надежно, при этом использует минимальное количество памяти. > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Sat Jan 5 10:57:57 2019 From: gmm на csdoc.com (Gena Makhomed) Date: Sat, 5 Jan 2019 12:57:57 +0200 Subject: GeoIP In-Reply-To: References: Message-ID: <6a7ae8a0-12dc-1ab1-b2dc-00c27a2fb646@csdoc.com> On 05.01.2019 12:18, Vladimir Getmanshchuk wrote: > Гена, с City скрипт тоже корректно работает? В файле http://geolite.maxmind.com/download/geoip/database/GeoLite2-Country-CSV.zip нет городов, там есть только код континента, название континента, код страны и название страны. Поле is_in_european_union у них выставляется очень странным образом. Например, страна 3579143,en,NA,"North America",GP,Guadeloupe,1 которая находится в Америке считается входящей в Евросоюз. Или вот эти африканские страны 935317,en,AF,Africa,RE,Réunion,1 1024031,en,AF,Africa,YT,Mayotte,1 у них тоже являются членами Евросоюза. P.S. Лицензия на код BSD 2-Clause License, так что Вы легко можете сделать форк и подправить этот скрипт под свои потребности, например, добавив туда поддержку City для платных баз maxmind. > On Fri, Jan 4, 2019 at 5:58 PM Gena Makhomed wrote: >>> Какие есть альтернативы maxmind и/или этому модулю? >> Есть альтернативы модулю ngx_http_geoip_module. >> >> Я просто конвертирую GeoLite2 в формат, который понимает nginx >> с помощью своего скрипта https://github.com/makhomed/nginx-geo >> запускаемого через крон раз в сутки, так что таким образом >> у меня в nginx используется всегда самая свежая база GeoLite2 >> через модуль http://nginx.org/en/docs/http/ngx_http_geo_module.html >> >> Встроенный в nginx модуль ngx_http_geo_module не использует никаких >> сторонних библиотек, так что он работает максимально стабильно >> и надежно, при этом использует минимальное количество памяти. -- Best regards, Gena From chipitsine на gmail.com Sat Jan 5 11:12:21 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sat, 5 Jan 2019 16:12:21 +0500 Subject: GeoIP In-Reply-To: References: Message-ID: Города есть тут https://github.com/m-messiah/ip2geo On Sat, Jan 5, 2019, 3:18 PM Vladimir Getmanshchuk Всем спасибо за ответы. > > Гена, с City скрипт тоже корректно работает? > > On Fri, Jan 4, 2019 at 5:58 PM Gena Makhomed wrote: > >> On 04.01.2019 17:12, Vladimir Getmanshchuk wrote: >> >> > Вчера maxmind таки дропнул GeoIP Country файл со своих серверов, >> > в связи с чем хотелось бы разобраться, что вообще происходить с GeoIP и >> > nginx. >> > Разъясните пожалуйста ситуацию. >> > >> > Как я все это вижу: >> > У maxmind была коммерческая GeoIP библиотека данных и программная >> > библиотека для работы с ней, >> > так же была бесплатная, но не очень точная библиотека данных под >> названием >> > GeoLite. >> > Nginx работал с обоими этими либами через ngx_http_geoip_module... >> > Спустя какое то время maxmind выпустил вторую версию коммерческой либы, >> а >> > так-же бесплатной либы под названием GeoLite2 и отказался от поддержки >> > первой версии, >> > а вчера вообще дропнул файлы со своих серверов. >> > >> > Все ли так? >> > Поддерживает ли ngx_http_geoip_module GeoLite2? >> > Если нет, то планируется ли разработка поддержки? >> > Какие есть альтернативы maxmind и/или этому модулю? >> >> Есть альтернативы модулю ngx_http_geoip_module. >> >> Я просто конвертирую GeoLite2 в формат, который понимает nginx >> с помощью своего скрипта https://github.com/makhomed/nginx-geo >> запускаемого через крон раз в сутки, так что таким образом >> у меня в nginx используется всегда самая свежая база GeoLite2 >> через модуль http://nginx.org/en/docs/http/ngx_http_geo_module.html >> >> Встроенный в nginx модуль ngx_http_geo_module не использует никаких >> сторонних библиотек, так что он работает максимально стабильно >> и надежно, при этом использует минимальное количество памяти. >> >> -- >> Best regards, >> Gena >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > Yours sincerely, > Vladimir Getmanshchuk > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From fe на hamilton.rinet.ru Sat Jan 5 12:49:51 2019 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Sat, 5 Jan 2019 15:49:51 +0300 Subject: GeoIP In-Reply-To: <6a7ae8a0-12dc-1ab1-b2dc-00c27a2fb646@csdoc.com> References: <6a7ae8a0-12dc-1ab1-b2dc-00c27a2fb646@csdoc.com> Message-ID: <99471555-8e70-56d9-0629-4c8440eea3dc@hamilton.rinet.ru> 05.01.19 13:57, Gena Makhomed пишет: > On 05.01.2019 12:18, Vladimir Getmanshchuk wrote: > >> Гена, с City скрипт тоже корректно работает? > > В файле > http://geolite.maxmind.com/download/geoip/database/GeoLite2-Country-CSV.zip > нет городов, там есть только код континента, название континента, код > страны и название страны. > > Поле is_in_european_union у них выставляется очень странным образом. > Например, страна 3579143,en,NA,"North America",GP,Guadeloupe,1 > которая находится в Америке считается входящей в Евросоюз. > Или вот эти африканские страны > 935317,en,AF,Africa,RE,Réunion,1 > 1024031,en,AF,Africa,YT,Mayotte,1 > у них тоже являются членами Евросоюза. И это правильно: Гваделупа – французская заморская территория, расположенная на островах в южной части Карибского моря. Реюньон – французский заморский департамент на одноименном острове в Индийском океане Майотта – заморский регион и департамент Франции, а также архипелаг, который относится к Коморским островам и находится между северным Мадагаскаром и северным Мозамбиком. и эти территории соответственно принадлежат к Евросоюзу. И там, например, надо соблюдать законы и требования EU. > > P.S. > > Лицензия на код BSD 2-Clause License, так что Вы легко можете > сделать форк и подправить этот скрипт под свои потребности, > например, добавив туда поддержку City для платных баз maxmind. > >> On Fri, Jan 4, 2019 at 5:58 PM Gena Makhomed wrote: > >>>> Какие есть альтернативы maxmind и/или этому модулю? > >>> Есть альтернативы модулю ngx_http_geoip_module. >>> >>> Я просто конвертирую GeoLite2 в формат, который понимает nginx >>> с помощью своего скрипта https://github.com/makhomed/nginx-geo >>> запускаемого через крон раз в сутки, так что таким образом >>> у меня в nginx используется всегда самая свежая база GeoLite2 >>> через модуль http://nginx.org/en/docs/http/ngx_http_geo_module.html >>> >>> Встроенный в nginx модуль ngx_http_geo_module не использует никаких >>> сторонних библиотек, так что он работает максимально стабильно >>> и надежно, при этом использует минимальное количество памяти. > -- Fedor Dikarev From nginx-forum на forum.nginx.org Sun Jan 6 17:32:43 2019 From: nginx-forum на forum.nginx.org (kycedbi) Date: Sun, 06 Jan 2019 12:32:43 -0500 Subject: GeoIP In-Reply-To: <20190104153914.ohbj67rsjoea7ly7@xenon.mamontov.net> References: <20190104153914.ohbj67rsjoea7ly7@xenon.mamontov.net> Message-ID: <21711a4c3ec06d7e17b4a55dc1c0fcdd.NginxMailingListRussian@forum.nginx.org> Здравствуйте. А планируется добавление в официальный репозиторий nginx пакета с модулем https://github.com/leev/ngx_http_geoip2_module (как это сейчас есть для модуля GeoIP v1)? Чтобы можно было спокойно обновлять nginx через менеджер пакетов linux (apt/yum), не пересобирая каждый раз из исходников сторонний модуль? Или с этим есть какие-то сложности (внутренняя конкуренция с nginx-plus, неподходящая лицензия ngx_http_geoip2_module, etc)? Благодарю за информацию. С уважением. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282545,282558#msg-282558 From nginx-forum на forum.nginx.org Tue Jan 8 00:23:04 2019 From: nginx-forum на forum.nginx.org (valet) Date: Mon, 07 Jan 2019 19:23:04 -0500 Subject: =?UTF-8?B?R0VULdC/0LDRgNCw0LzQtdGC0YDRiyDQutCw0Log0YHRgtCw0YLQuNGH0LXRgdC6?= =?UTF-8?B?0LDRjyDRgdGC0YDQsNC90LjRhtCw?= Message-ID: <27ecca1686cf85ebc2b92fb2a63f0ccf.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Вопрос такой: на сервере лежат статические html-файлы с именами типа index.html?id=1 index.html?id=2 и т.д. - то есть это их имена именно в таком виде. Как заставить nginx отдавать собственно именно эти файлы? стандартный кусок конфига location / { root /data/www/site.ru/; index index.html; } на запросы типа http://site.ru/index.html?id=1 отдает просто http://site.ru/index.html, то есть параметры отбрасываются. Я так подозреваю нужен какой-то правиьлный rewite, но гугление пока не помогает, знаний тоже не хватает, помогите разобраться. С уважением, Леонид. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282565,282565#msg-282565 From bgx на protva.ru Tue Jan 8 09:21:07 2019 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Tue, 8 Jan 2019 12:21:07 +0300 Subject: =?UTF-8?B?UmU6IEdFVC3Qv9Cw0YDQsNC80LXRgtGA0Ysg0LrQsNC6INGB0YLQsNGC0LjRh9C1?= =?UTF-8?B?0YHQutCw0Y8g0YHRgtGA0LDQvdC40YbQsA==?= In-Reply-To: <27ecca1686cf85ebc2b92fb2a63f0ccf.NginxMailingListRussian@forum.nginx.org> References: <27ecca1686cf85ebc2b92fb2a63f0ccf.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190108092107.GH3081@protva.ru> On Mon, Jan 07, 2019 at 07:23:04PM -0500, valet wrote: > Вопрос такой: на сервере лежат статические html-файлы с именами типа > index.html?id=1 index.html?id=2 и т.д. - то есть это их имена именно в таком > виде. ... > на запросы типа http://site.ru/index.html?id=1 отдает просто > http://site.ru/index.html, то есть параметры отбрасываются. Правильно, символ "?" являeтся специальным и потому не может быть частью имени файла в url. Если же приспичило указать имя файла со спецсимволами, то в url они должны быть заэскейплены: http://site.ru/index.html%3Fid%3D1 Хотя для "=" это необязательно. > Я так подозреваю нужен какой-то правиьлный rewite, Нет, проблема здесь в формировании правильного url на стороне клиента, никакие rewite правила кодировки url отменить не могут. -- Eugene Berdnikov From eugene.toropov на gmail.com Tue Jan 8 11:34:47 2019 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Tue, 8 Jan 2019 14:34:47 +0300 Subject: no live upstreams while connecting to upstream Message-ID: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> Добрый день, Всех с праздниками! Может кто знает - валятся ошибки "no live upstreams while connecting to upstream”. Если слать запрос не через nginx, а напрямую на апстрим в тестовом скрипте - все работает. Как только меняешь endpoint на nginx - 502 Bad Gateway с такой ошибкой. # nginx -V nginx version: nginx/1.14.0 (Ubuntu) built with OpenSSL 1.1.0g 2 Nov 2017 TLS SNI support enabled configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-FIJPpj/nginx-1.14.0=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-mail=dynamic --with-mail_ssl_module Евгений eugene.toropov на gmail.com From pnz.stalker на mail.ru Tue Jan 8 13:00:24 2019 From: pnz.stalker на mail.ru (pnz.stalker на mail.ru) Date: Tue, 8 Jan 2019 16:00:24 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> Message-ID: <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> И Вас с прошедшими... Проверьте, что по пути от nginx до апстримов нет блокировок файрволлами или ещё чем либо. То есть что апстримы доступны для nginx 08.01.2019 14:34, Eugene Toropov пишет: > Добрый день, > Всех с праздниками! > Может кто знает - валятся ошибки "no live upstreams while connecting to upstream”. Если слать запрос не через nginx, а напрямую на апстрим в тестовом скрипте - все работает. Как только меняешь endpoint на nginx - 502 Bad Gateway с такой ошибкой. From fe на hamilton.rinet.ru Tue Jan 8 16:45:22 2019 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Tue, 8 Jan 2019 19:45:22 +0300 Subject: =?UTF-8?B?UmU6IEdFVC3Qv9Cw0YDQsNC80LXRgtGA0Ysg0LrQsNC6INGB0YLQsNGC0LjRh9C1?= =?UTF-8?B?0YHQutCw0Y8g0YHRgtGA0LDQvdC40YbQsA==?= In-Reply-To: <27ecca1686cf85ebc2b92fb2a63f0ccf.NginxMailingListRussian@forum.nginx.org> References: <27ecca1686cf85ebc2b92fb2a63f0ccf.NginxMailingListRussian@forum.nginx.org> Message-ID: 08.01.2019 3:23, valet пишет: > Здравствуйте. > > Вопрос такой: на сервере лежат статические html-файлы с именами типа > index.html?id=1 index.html?id=2 и т.д. - то есть это их имена именно в таком > виде. > Как заставить nginx отдавать собственно именно эти файлы? > > стандартный кусок конфига > location / { > root /data/www/site.ru/; > index index.html; > } > на запросы типа http://site.ru/index.html?id=1 отдает просто > http://site.ru/index.html, то есть параметры отбрасываются. > > Я так подозреваю нужен какой-то правиьлный rewite, но гугление пока не > помогает, знаний тоже не хватает, помогите разобраться. можно попробовать try_files, например так: > location /args_test/ { try_files $uri$is_args$args =404; } или так: > location /args_test/ { try_files $uri$is_args$args $uri; } И тогда: > root на hamilton:/st/hosting/hamilton/htdocs/args_test # ls > index.html index.html?id=1 > root на hamilton:/st/hosting/hamilton/htdocs/args_test # cat * > none > one > curl 'http://hamilton.rinet.ru/args_test/index.html?id=1' > one возможно это решит конкретно эту задачу. Но надо помнить, что добавление любого другого параметра в запрос все сломает, и если их будет несколько, то важен будет и порядок в котором они передаются в запросе. Если надо будет и такие случаи разобрать, то уже надо будет правильный map строить от аргументов map-ить в имя файла на диске. > > С уважением, Леонид. > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282565,282565#msg-282565 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From eugene.toropov на gmail.com Tue Jan 8 18:01:27 2019 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Tue, 8 Jan 2019 21:01:27 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> Message-ID: Добрый вечер, Тогда получается ситуация, при которой часть запросов файрвол пропускает, а часть режет. При чем ночью до 9 утра не режет ничего, а вечером почти все. Как nginx определяет, что апстрим живой? Любой статус, отличный от 200? Евгений > On 8 Jan 2019, at 16:00, pnz.stalker--- via nginx-ru wrote: > > > И Вас с прошедшими... > > Проверьте, что по пути от nginx до апстримов нет блокировок файрволлами или ещё чем либо. > > То есть что апстримы доступны для nginx > > 08.01.2019 14:34, Eugene Toropov пишет: >> Добрый день, >> Всех с праздниками! >> Может кто знает - валятся ошибки "no live upstreams while connecting to upstream”. Если слать запрос не через nginx, а напрямую на апстрим в тестовом скрипте - все работает. Как только меняешь endpoint на nginx - 502 Bad Gateway с такой ошибкой. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From pnz.stalker на mail.ru Tue Jan 8 18:15:18 2019 From: pnz.stalker на mail.ru (pnz.stalker на mail.ru) Date: Tue, 8 Jan 2019 21:15:18 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> Message-ID: <7eae549a-1e04-366a-817a-1fdf8bb6ac31@mail.ru> 08.01.2019 21:01, Eugene Toropov пишет: > Тогда получается ситуация, при которой часть запросов файрвол пропускает, а часть режет. При чем ночью до 9 утра не режет ничего, а вечером почти все. Как nginx определяет, что апстрим живой? Любой статус, отличный от 200? Ну как вариант сеть перегружена или ещё какие сетевые проблемы по пути от нигкса до апстримов. В общем в момент проблемы смотреть логи, проверять связность между nginx и апстримами. Смотреть логи апстримов. Попробовать тестовым скриптом цепануться с nginx к апстриму From eugene.toropov на gmail.com Tue Jan 8 18:29:43 2019 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Tue, 8 Jan 2019 21:29:43 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: <7eae549a-1e04-366a-817a-1fdf8bb6ac31@mail.ru> References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> <7eae549a-1e04-366a-817a-1fdf8bb6ac31@mail.ru> Message-ID: После nginx reload первые несколько запросов проходят с тестового скрипта через nginx к апстриму, дальше стабильно 502 вот с таким дебаг логом: 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 posix_memalign: 0000560601D430F0:4096 @16 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 http cleanup add: 0000560601758258 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 get rr peer, try: 8 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 http upstream connect: -3 2019/01/08 18:21:59 [error] 23082#23082: *1842235429 no live upstreams while connecting to upstream, client: 192.168.42.25, server: xxx, request: "POST /xxxxx HTTP/1.1", upstream: “xxxxx", host: “xxxxx" 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 http next upstream, 40000000 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 finalize http upstream request: 502 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 finalize http proxy request Вопрос по “http upstream connect: -3” - это стандартная ошибка коннекта? Евгений > On 8 Jan 2019, at 21:15, pnz.stalker--- via nginx-ru wrote: > > 08.01.2019 21:01, Eugene Toropov пишет: > >> Тогда получается ситуация, при которой часть запросов файрвол пропускает, а часть режет. При чем ночью до 9 утра не режет ничего, а вечером почти все. Как nginx определяет, что апстрим живой? Любой статус, отличный от 200? > > Ну как вариант сеть перегружена или ещё какие сетевые проблемы по пути от нигкса до апстримов. > > В общем в момент проблемы смотреть логи, проверять связность между nginx и апстримами. Смотреть логи апстримов. Попробовать тестовым скриптом цепануться с nginx к апстриму > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From pnz.stalker на mail.ru Tue Jan 8 18:41:30 2019 From: pnz.stalker на mail.ru (pnz.stalker на mail.ru) Date: Tue, 8 Jan 2019 21:41:30 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> <7eae549a-1e04-366a-817a-1fdf8bb6ac31@mail.ru> Message-ID: <3dcd8706-ee5a-2a50-d118-380be0671610@mail.ru> 08.01.2019 21:29, Eugene Toropov пишет: Что значит -3 на вскидку не помню.. Над исходники смотреть. Есть мнение, что со стороны апстрима стоят лимиты на количество подключений с 1 IP адреса/keep-alive соединений. Когда перезапускаете nginx "старые" соединения сбрасываются и пока лимит не достигнут всё работает. Смотрите логи апстримов. > После nginx reload первые несколько запросов проходят с тестового скрипта через nginx к апстриму, дальше стабильно 502 вот с таким дебаг логом: > > 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 posix_memalign: 0000560601D430F0:4096 @16 > 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 http cleanup add: 0000560601758258 > 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 get rr peer, try: 8 > 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 http upstream connect: -3 > 2019/01/08 18:21:59 [error] 23082#23082: *1842235429 no live upstreams while connecting to upstream, client: 192.168.42.25, server: xxx, request: "POST /xxxxx HTTP/1.1", upstream: “xxxxx", host: “xxxxx" > 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 http next upstream, 40000000 > 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 finalize http upstream request: 502 > 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 finalize http proxy request > > Вопрос по “http upstream connect: -3” - это стандартная ошибка коннекта? From eugene.toropov на gmail.com Tue Jan 8 19:00:07 2019 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Tue, 8 Jan 2019 22:00:07 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: <3dcd8706-ee5a-2a50-d118-380be0671610@mail.ru> References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> <7eae549a-1e04-366a-817a-1fdf8bb6ac31@mail.ru> <3dcd8706-ee5a-2a50-d118-380be0671610@mail.ru> Message-ID: Я тестовый скрипт запускаю с того же сервера, где nginx крутится, и он всегда работает, если запрос идет напрямую на апстрим. Так что больше похоже на то, что проблема где-то в конфигурации nginx :( Евгений > On 8 Jan 2019, at 21:41, pnz.stalker--- via nginx-ru wrote: > > 08.01.2019 21:29, Eugene Toropov пишет: > > Что значит -3 на вскидку не помню.. Над исходники смотреть. > Есть мнение, что со стороны апстрима стоят лимиты на количество подключений с 1 IP адреса/keep-alive соединений. > Когда перезапускаете nginx "старые" соединения сбрасываются и пока лимит не достигнут всё работает. Смотрите логи апстримов. > >> После nginx reload первые несколько запросов проходят с тестового скрипта через nginx к апстриму, дальше стабильно 502 вот с таким дебаг логом: >> 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 posix_memalign: 0000560601D430F0:4096 @16 >> 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 http cleanup add: 0000560601758258 >> 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 get rr peer, try: 8 >> 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 http upstream connect: -3 >> 2019/01/08 18:21:59 [error] 23082#23082: *1842235429 no live upstreams while connecting to upstream, client: 192.168.42.25, server: xxx, request: "POST /xxxxx HTTP/1.1", upstream: “xxxxx", host: “xxxxx" >> 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 http next upstream, 40000000 >> 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 finalize http upstream request: 502 >> 2019/01/08 18:21:59 [debug] 23082#23082: *1842235429 finalize http proxy request >> Вопрос по “http upstream connect: -3” - это стандартная ошибка коннекта? > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From ngnx8810773a83 на avksrv.org Tue Jan 8 20:10:15 2019 From: ngnx8810773a83 на avksrv.org (Alexey) Date: Tue, 8 Jan 2019 23:10:15 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> Message-ID: <5f58f93c-1dca-e655-95be-407b642426bf@avksrv.org> 08.01.2019 21:01, Eugene Toropov пишет: > Добрый вечер, > > Тогда получается ситуация, при которой часть запросов файрвол пропускает, а часть режет. При чем ночью до 9 утра не режет ничего, а вечером почти все. Как nginx определяет, что апстрим живой? Любой статус, отличный от 200? посмотрите описание proxy_next_upstream Директива также определяет, что считается неудачной попыткой работы с сервером. Случаи error, timeout и invalid_header всегда считаются неудачными попытками, даже если они не указаны в директиве. Случаи http_500, http_502, http_503, http_504 и http_429 считаются неудачными попытками, только если они указаны в директиве. Случаи http_403 и http_404 никогда не считаются неудачными попытками. и директиву server из секции описания upstream max_fails=число     задаёт число неудачных попыток работы с сервером, которые должны произойти в течение времени, заданного параметром fail_timeout, чтобы сервер считался недоступным на период времени, также заданный параметром fail_timeout. По умолчанию число попыток устанавливается равным 1. Нулевое значение отключает учёт попыток. Что считается неудачной попыткой, определяется  директивами proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream,scgi_next_upstream, memcached_next_upstream и grpc_next_upstream. если апстрим реально один, то укажите ему max_fails=0 А вообще смотрите запросы рядом с первым 502. там скорее всего гдето случились таймауты, единственный апстрим отметился как фейл и на время fail_timeout(10с по умолчанию) выпадает из работы. /Алексей From eugene.toropov на gmail.com Tue Jan 8 20:40:15 2019 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Tue, 8 Jan 2019 23:40:15 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: <5f58f93c-1dca-e655-95be-407b642426bf@avksrv.org> References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> <5f58f93c-1dca-e655-95be-407b642426bf@avksrv.org> Message-ID: <7E73A574-A0D8-4019-9572-CE42D647E9AA@gmail.com> Я не совсем понял, при чем здесь параметр max_fails - его на странице proxy модуля нет нигде - http://nginx.org/en/docs/http/ngx_http_proxy_module.html - я что-то пропустил? Евгений > On 8 Jan 2019, at 23:10, Alexey via nginx-ru wrote: > > 08.01.2019 21:01, Eugene Toropov пишет: >> Добрый вечер, >> >> Тогда получается ситуация, при которой часть запросов файрвол пропускает, а часть режет. При чем ночью до 9 утра не режет ничего, а вечером почти все. Как nginx определяет, что апстрим живой? Любой статус, отличный от 200? > > > > посмотрите описание proxy_next_upstream > > > Директива также определяет, что считается неудачной попыткой работы с сервером. Случаи error, timeout и invalid_header всегда считаются неудачными попытками, даже если они не указаны в директиве. Случаи http_500, http_502, http_503, http_504 и http_429 считаются неудачными попытками, только если они указаны в директиве. Случаи http_403 и http_404 никогда не считаются неудачными попытками. > > и директиву server из секции описания upstream > > max_fails=число > задаёт число неудачных попыток работы с сервером, которые должны произойти в течение времени, заданного параметром fail_timeout, чтобы сервер считался недоступным на период времени, также заданный параметром fail_timeout. По умолчанию число попыток устанавливается равным 1. Нулевое значение отключает учёт попыток. Что считается неудачной попыткой, определяется директивами proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream,scgi_next_upstream, memcached_next_upstream и grpc_next_upstream. > > > если апстрим реально один, то укажите ему max_fails=0 > > А вообще смотрите запросы рядом с первым 502. там скорее всего гдето случились таймауты, единственный апстрим отметился как фейл и на время fail_timeout(10с по умолчанию) выпадает из работы. > > /Алексей > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From ngnx8810773a83 на avksrv.org Tue Jan 8 20:48:56 2019 From: ngnx8810773a83 на avksrv.org (Alexey) Date: Tue, 8 Jan 2019 23:48:56 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: <7E73A574-A0D8-4019-9572-CE42D647E9AA@gmail.com> References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> <5f58f93c-1dca-e655-95be-407b642426bf@avksrv.org> <7E73A574-A0D8-4019-9572-CE42D647E9AA@gmail.com> Message-ID: <7a52c47a-72d6-46ff-b0e2-701984489943@avksrv.org> 08.01.2019 23:40, Eugene Toropov пишет: > Я не совсем понял, при чем здесь параметр max_fails - его на странице proxy модуля нет нигде - http://nginx.org/en/docs/http/ngx_http_proxy_module.html - я что-то пропустил? > ustream tratata { server tratutu:80 .... max_fails=XXX; } server {  location / {   upstream http://tratata; ... } } если Вы явно не указали upstream, то это не значит что там нет никаких умолчаний... укажите явно, впишите туда max_fails=0 From eugene.toropov на gmail.com Tue Jan 8 20:50:45 2019 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Tue, 8 Jan 2019 23:50:45 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: <7a52c47a-72d6-46ff-b0e2-701984489943@avksrv.org> References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> <5f58f93c-1dca-e655-95be-407b642426bf@avksrv.org> <7E73A574-A0D8-4019-9572-CE42D647E9AA@gmail.com> <7a52c47a-72d6-46ff-b0e2-701984489943@avksrv.org> Message-ID: <0A2F155E-71B5-4D5F-B72D-7D73B6B69B6F@gmail.com> Зачем мне upstream, если я использую proxy_pass: location / { proxy_pass xxxxxx; } ? > On 8 Jan 2019, at 23:48, Alexey via nginx-ru wrote: > > 08.01.2019 23:40, Eugene Toropov пишет: >> Я не совсем понял, при чем здесь параметр max_fails - его на странице proxy модуля нет нигде - http://nginx.org/en/docs/http/ngx_http_proxy_module.html - я что-то пропустил? >> > > ustream tratata { > > server tratutu:80 .... max_fails=XXX; > > } > > > server { > > location / { > > upstream http://tratata; > > ... > > } > > } > > > если Вы явно не указали upstream, то это не значит что там нет никаких умолчаний... укажите явно, впишите туда max_fails=0 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From ngnx8810773a83 на avksrv.org Tue Jan 8 20:54:43 2019 From: ngnx8810773a83 на avksrv.org (Alexey) Date: Tue, 8 Jan 2019 23:54:43 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: <0A2F155E-71B5-4D5F-B72D-7D73B6B69B6F@gmail.com> References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> <5f58f93c-1dca-e655-95be-407b642426bf@avksrv.org> <7E73A574-A0D8-4019-9572-CE42D647E9AA@gmail.com> <7a52c47a-72d6-46ff-b0e2-701984489943@avksrv.org> <0A2F155E-71B5-4D5F-B72D-7D73B6B69B6F@gmail.com> Message-ID: <660804d4-36a1-ec7c-a11a-7474f1c3536c@avksrv.org> 08.01.2019 23:50, Eugene Toropov пишет: > Зачем мне upstream, если я использую proxy_pass: > > location / { > proxy_pass xxxxxx; > } > ? да, сорри, во второй случае должно было быть proxy_pass Еще раз, если Вы не описали апстрим для проксипаса, то это не значит что его нет и в нем нет умолчаний. Если умолчания не подходят, то значит надо описать таки апстрим самостоятельно с нужными параметрами. >> On 8 Jan 2019, at 23:48, Alexey via nginx-ru wrote: >> >> 08.01.2019 23:40, Eugene Toropov пишет: >>> Я не совсем понял, при чем здесь параметр max_fails - его на странице proxy модуля нет нигде - http://nginx.org/en/docs/http/ngx_http_proxy_module.html - я что-то пропустил? >>> >> ustream tratata { >> >> server tratutu:80 .... max_fails=XXX; >> >> } >> >> >> server { >> >> location / { >> >> proxy_pass http://tratata; >> >> ... >> >> } >> >> } >> >> >> если Вы явно не указали upstream, то это не значит что там нет никаких умолчаний... укажите явно, впишите туда max_fails=0 >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru From eugene.toropov на gmail.com Tue Jan 8 21:08:22 2019 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Wed, 9 Jan 2019 00:08:22 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: <660804d4-36a1-ec7c-a11a-7474f1c3536c@avksrv.org> References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> <5f58f93c-1dca-e655-95be-407b642426bf@avksrv.org> <7E73A574-A0D8-4019-9572-CE42D647E9AA@gmail.com> <7a52c47a-72d6-46ff-b0e2-701984489943@avksrv.org> <0A2F155E-71B5-4D5F-B72D-7D73B6B69B6F@gmail.com> <660804d4-36a1-ec7c-a11a-7474f1c3536c@avksrv.org> Message-ID: <9F4FE080-5371-4448-BE81-1F3153A905CA@gmail.com> С max_fails=0 получил ошибку "SSL_do_handshake() failed (SSL: error:1408F10B:SSL routines:ssl3_get_record:wrong version number) while SSL handshaking to upstream” (апстрим на httpS) - буду разбираться с SSL. Всем спасибо и спокойной ночи! Евгений > On 8 Jan 2019, at 23:54, Alexey via nginx-ru wrote: > > 08.01.2019 23:50, Eugene Toropov пишет: >> Зачем мне upstream, если я использую proxy_pass: >> >> location / { >> proxy_pass xxxxxx; >> } >> ? > > да, сорри, во второй случае должно было быть proxy_pass > > Еще раз, если Вы не описали апстрим для проксипаса, то это не значит что его нет и в нем нет умолчаний. Если умолчания не подходят, то значит надо описать таки апстрим самостоятельно с нужными параметрами. > >>> On 8 Jan 2019, at 23:48, Alexey via nginx-ru wrote: >>> >>> 08.01.2019 23:40, Eugene Toropov пишет: >>>> Я не совсем понял, при чем здесь параметр max_fails - его на странице proxy модуля нет нигде - http://nginx.org/en/docs/http/ngx_http_proxy_module.html - я что-то пропустил? >>>> >>> ustream tratata { >>> >>> server tratutu:80 .... max_fails=XXX; >>> >>> } >>> >>> >>> server { >>> >>> location / { >>> >>> proxy_pass http://tratata ; >>> >>> ... >>> >>> } >>> >>> } >>> >>> >>> если Вы явно не указали upstream, то это не значит что там нет никаких умолчаний... укажите явно, впишите туда max_fails=0 >>> >>> _______________________________________________ >>> 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 ngnx8810773a83 на avksrv.org Tue Jan 8 21:29:11 2019 From: ngnx8810773a83 на avksrv.org (Alexey) Date: Wed, 9 Jan 2019 00:29:11 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: <9F4FE080-5371-4448-BE81-1F3153A905CA@gmail.com> References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> <5f58f93c-1dca-e655-95be-407b642426bf@avksrv.org> <7E73A574-A0D8-4019-9572-CE42D647E9AA@gmail.com> <7a52c47a-72d6-46ff-b0e2-701984489943@avksrv.org> <0A2F155E-71B5-4D5F-B72D-7D73B6B69B6F@gmail.com> <660804d4-36a1-ec7c-a11a-7474f1c3536c@avksrv.org> <9F4FE080-5371-4448-BE81-1F3153A905CA@gmail.com> Message-ID: <6af24580-e5b1-1414-3d45-29cbd727a514@avksrv.org> 09.01.2019 0:08, Eugene Toropov пишет: > С max_fails=0 получил ошибку "SSL_do_handshake() failed (SSL: > error:1408F10B:SSL routines:ssl3_get_record:wrong version number) > while SSL handshaking to upstream” (апстрим на httpS) - буду > разбираться с SSL. Это ошибка сразу же ? порт надо явно указать в upstream tra { server x.x.x.x:443 ...} и в проксипас уже proxy_pass https://tra ; секция upstream не в курсе откуда её будут звать и по умолчанию там :80, если её позвать потом https то будет как Вы написали. апстрим умеет http/1.1 и он включен со стороны нгинкса (со сбросом proxy_set_header Connection '') ? если нет, то новое ssl соединение устанавливается на каждое соединение с апстримом. Это дорого. если апстрим умеет http/1.1 и кипалайв, то ОЧЕНЬ рекомендуется их включить. (если конечно есть достаточно веские аргументы для вообще использования https для связи между nginx и апстримом. SSL дорог и хандшейк медленен, на новых процах и правильно собранном openssl несколько быстрее, но всеравно чертовски медленнен..., но кипалайв всеравно снизит нагрузку, даже без ssl, опять же количество соединений с 1 портом ограничено, и учитывая что по умолчапнию реюз запрещен, то порт остается занятым много дольше, чем он используется) Да и всякие лимиты nfile. /Алексей From eugene.toropov на gmail.com Tue Jan 8 21:30:46 2019 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Wed, 9 Jan 2019 00:30:46 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: <9F4FE080-5371-4448-BE81-1F3153A905CA@gmail.com> References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> <5f58f93c-1dca-e655-95be-407b642426bf@avksrv.org> <7E73A574-A0D8-4019-9572-CE42D647E9AA@gmail.com> <7a52c47a-72d6-46ff-b0e2-701984489943@avksrv.org> <0A2F155E-71B5-4D5F-B72D-7D73B6B69B6F@gmail.com> <660804d4-36a1-ec7c-a11a-7474f1c3536c@avksrv.org> <9F4FE080-5371-4448-BE81-1F3153A905CA@gmail.com> Message-ID: Я, кстати, не указал :443 порт у server в upstream-е - поэтому и такую ошибку получил. Более подробно здесь - https://stackoverflow.com/questions/53245818/nginx-upstream-to-https-host-ssl3-get-recordwrong-version-number Евгений > On 9 Jan 2019, at 00:08, Eugene Toropov wrote: > > С max_fails=0 получил ошибку "SSL_do_handshake() failed (SSL: error:1408F10B:SSL routines:ssl3_get_record:wrong version number) while SSL handshaking to upstream” (апстрим на httpS) - буду разбираться с SSL. > > Всем спасибо и спокойной ночи! > > Евгений > >> On 8 Jan 2019, at 23:54, Alexey via nginx-ru > wrote: >> >> 08.01.2019 23:50, Eugene Toropov пишет: >>> Зачем мне upstream, если я использую proxy_pass: >>> >>> location / { >>> proxy_pass xxxxxx; >>> } >>> ? >> >> да, сорри, во второй случае должно было быть proxy_pass >> >> Еще раз, если Вы не описали апстрим для проксипаса, то это не значит что его нет и в нем нет умолчаний. Если умолчания не подходят, то значит надо описать таки апстрим самостоятельно с нужными параметрами. >> >>>> On 8 Jan 2019, at 23:48, Alexey via nginx-ru > wrote: >>>> >>>> 08.01.2019 23:40, Eugene Toropov пишет: >>>>> Я не совсем понял, при чем здесь параметр max_fails - его на странице proxy модуля нет нигде - http://nginx.org/en/docs/http/ngx_http_proxy_module.html - я что-то пропустил? >>>>> >>>> ustream tratata { >>>> >>>> server tratutu:80 .... max_fails=XXX; >>>> >>>> } >>>> >>>> >>>> server { >>>> >>>> location / { >>>> >>>> proxy_pass http://tratata ; >>>> >>>> ... >>>> >>>> } >>>> >>>> } >>>> >>>> >>>> если Вы явно не указали upstream, то это не значит что там нет никаких умолчаний... укажите явно, впишите туда max_fails=0 >>>> >>>> _______________________________________________ >>>> 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 eugene.toropov на gmail.com Tue Jan 8 21:33:10 2019 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Wed, 9 Jan 2019 00:33:10 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: <6af24580-e5b1-1414-3d45-29cbd727a514@avksrv.org> References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> <5f58f93c-1dca-e655-95be-407b642426bf@avksrv.org> <7E73A574-A0D8-4019-9572-CE42D647E9AA@gmail.com> <7a52c47a-72d6-46ff-b0e2-701984489943@avksrv.org> <0A2F155E-71B5-4D5F-B72D-7D73B6B69B6F@gmail.com> <660804d4-36a1-ec7c-a11a-7474f1c3536c@avksrv.org> <9F4FE080-5371-4448-BE81-1F3153A905CA@gmail.com> <6af24580-e5b1-1414-3d45-29cbd727a514@avksrv.org> Message-ID: <1369380A-7170-4E3C-8A9A-8CE3DECF8531@gmail.com> Спасибо :) Опередили меня :) Пробую proxy_http_version 1.1; > On 9 Jan 2019, at 00:29, Alexey via nginx-ru wrote: > > > 09.01.2019 0:08, Eugene Toropov пишет: >> С max_fails=0 получил ошибку "SSL_do_handshake() failed (SSL: error:1408F10B:SSL routines:ssl3_get_record:wrong version number) while SSL handshaking to upstream” (апстрим на httpS) - буду разбираться с SSL. > > > Это ошибка сразу же ? порт надо явно указать в upstream tra { server x.x.x.x:443 ...} и в проксипас уже proxy_pass https://tra ; секция upstream не в курсе откуда её будут звать и по умолчанию там :80, если её позвать потом https то будет как Вы написали. > > > апстрим умеет http/1.1 и он включен со стороны нгинкса (со сбросом proxy_set_header Connection '') ? > если нет, то новое ssl соединение устанавливается на каждое соединение с апстримом. Это дорого. если апстрим умеет http/1.1 и кипалайв, то ОЧЕНЬ рекомендуется их включить. (если конечно есть достаточно веские аргументы для вообще использования https для связи между nginx и апстримом. SSL дорог и хандшейк медленен, на новых процах и правильно собранном openssl несколько быстрее, но всеравно чертовски медленнен..., но кипалайв всеравно снизит нагрузку, даже без ssl, опять же количество соединений с 1 портом ограничено, и учитывая что по умолчапнию реюз запрещен, то порт остается занятым много дольше, чем он используется) Да и всякие лимиты nfile. > > /Алексей > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From eugene.toropov на gmail.com Tue Jan 8 21:47:26 2019 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Wed, 9 Jan 2019 00:47:26 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: <1369380A-7170-4E3C-8A9A-8CE3DECF8531@gmail.com> References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> <5f58f93c-1dca-e655-95be-407b642426bf@avksrv.org> <7E73A574-A0D8-4019-9572-CE42D647E9AA@gmail.com> <7a52c47a-72d6-46ff-b0e2-701984489943@avksrv.org> <0A2F155E-71B5-4D5F-B72D-7D73B6B69B6F@gmail.com> <660804d4-36a1-ec7c-a11a-7474f1c3536c@avksrv.org> <9F4FE080-5371-4448-BE81-1F3153A905CA@gmail.com> <6af24580-e5b1-1414-3d45-29cbd727a514@avksrv.org> <1369380A-7170-4E3C-8A9A-8CE3DECF8531@gmail.com> Message-ID: <3E12976E-07A7-4A9C-AD71-9591D5E4ECFD@gmail.com> proxy_http_version 1.1; и proxy_set_header Connection '' помогли, по крайней мере 502 больше не вижу. Уточните, пожалуйста, можно ли еще как-то не прописывать явно “proxy_set_header Host tratutu” в конфиге, чтоб он правильный хост передавал на апстрим вместо tratata? Евгений > On 9 Jan 2019, at 00:33, Eugene Toropov wrote: > > Спасибо :) Опередили меня :) Пробую proxy_http_version 1.1; > >> On 9 Jan 2019, at 00:29, Alexey via nginx-ru wrote: >> >> >> 09.01.2019 0:08, Eugene Toropov пишет: >>> С max_fails=0 получил ошибку "SSL_do_handshake() failed (SSL: error:1408F10B:SSL routines:ssl3_get_record:wrong version number) while SSL handshaking to upstream” (апстрим на httpS) - буду разбираться с SSL. >> >> >> Это ошибка сразу же ? порт надо явно указать в upstream tra { server x.x.x.x:443 ...} и в проксипас уже proxy_pass https://tra ; секция upstream не в курсе откуда её будут звать и по умолчанию там :80, если её позвать потом https то будет как Вы написали. >> >> >> апстрим умеет http/1.1 и он включен со стороны нгинкса (со сбросом proxy_set_header Connection '') ? >> если нет, то новое ssl соединение устанавливается на каждое соединение с апстримом. Это дорого. если апстрим умеет http/1.1 и кипалайв, то ОЧЕНЬ рекомендуется их включить. (если конечно есть достаточно веские аргументы для вообще использования https для связи между nginx и апстримом. SSL дорог и хандшейк медленен, на новых процах и правильно собранном openssl несколько быстрее, но всеравно чертовски медленнен..., но кипалайв всеравно снизит нагрузку, даже без ssl, опять же количество соединений с 1 портом ограничено, и учитывая что по умолчапнию реюз запрещен, то порт остается занятым много дольше, чем он используется) Да и всякие лимиты nfile. >> >> /Алексей >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > From ngnx8810773a83 на avksrv.org Wed Jan 9 18:43:19 2019 From: ngnx8810773a83 на avksrv.org (Alexey) Date: Wed, 9 Jan 2019 21:43:19 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: <3E12976E-07A7-4A9C-AD71-9591D5E4ECFD@gmail.com> References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> <5f58f93c-1dca-e655-95be-407b642426bf@avksrv.org> <7E73A574-A0D8-4019-9572-CE42D647E9AA@gmail.com> <7a52c47a-72d6-46ff-b0e2-701984489943@avksrv.org> <0A2F155E-71B5-4D5F-B72D-7D73B6B69B6F@gmail.com> <660804d4-36a1-ec7c-a11a-7474f1c3536c@avksrv.org> <9F4FE080-5371-4448-BE81-1F3153A905CA@gmail.com> <6af24580-e5b1-1414-3d45-29cbd727a514@avksrv.org> <1369380A-7170-4E3C-8A9A-8CE3DECF8531@gmail.com> <3E12976E-07A7-4A9C-AD71-9591D5E4ECFD@gmail.com> Message-ID: 09.01.2019 0:47, Eugene Toropov пишет: > proxy_http_version 1.1; и proxy_set_header Connection '' помогли, по крайней мере 502 больше не вижу. Уточните, пожалуйста, можно ли еще как-то не прописывать явно “proxy_set_header Host tratutu” в конфиге, чтоб он правильный хост передавал на апстрим вместо tratata? Ну можно, например, proxy_set_header Host $host; тогда дальше поедет тоже имя, что передано клиентом. Вообще никто не мешает вместо proxy_pass https://www.domain.ru; написать upstream www.domain.ru { server www.domain.ru:443 ...; } и строку proxy_pass вообще не менять, тогда ничего в плане переданных имен не поменяется. From eugene.toropov на gmail.com Wed Jan 9 19:27:35 2019 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Wed, 9 Jan 2019 22:27:35 +0300 Subject: no live upstreams while connecting to upstream In-Reply-To: References: <14F52F38-03E6-44F3-B081-459F4C8CF9C3@gmail.com> <33c46cdf-d2cc-2362-fe50-0ce9af0453bb@mail.ru> <5f58f93c-1dca-e655-95be-407b642426bf@avksrv.org> <7E73A574-A0D8-4019-9572-CE42D647E9AA@gmail.com> <7a52c47a-72d6-46ff-b0e2-701984489943@avksrv.org> <0A2F155E-71B5-4D5F-B72D-7D73B6B69B6F@gmail.com> <660804d4-36a1-ec7c-a11a-7474f1c3536c@avksrv.org> <9F4FE080-5371-4448-BE81-1F3153A905CA@gmail.com> <6af24580-e5b1-1414-3d45-29cbd727a514@avksrv.org> <1369380A-7170-4E3C-8A9A-8CE3DECF8531@gmail.com> <3E12976E-07A7-4A9C-AD71-9591D5E4ECFD@gmail.com> Message-ID: <7A83D60F-FED9-4B43-A295-0C7604CE8B4B@gmail.com> Понятно, спасибо. > On 9 Jan 2019, at 21:43, Alexey via nginx-ru wrote: > > 09.01.2019 0:47, Eugene Toropov пишет: >> proxy_http_version 1.1; и proxy_set_header Connection '' помогли, по крайней мере 502 больше не вижу. Уточните, пожалуйста, можно ли еще как-то не прописывать явно “proxy_set_header Host tratutu” в конфиге, чтоб он правильный хост передавал на апстрим вместо tratata? > > Ну можно, например, > proxy_set_header Host $host; > тогда дальше поедет тоже имя, что передано клиентом. > > Вообще никто не мешает вместо > > proxy_pass https://www.domain.ru; > > написать > > upstream www.domain.ru { > server www.domain.ru:443 ...; > > } > и строку proxy_pass вообще не менять, тогда ничего в плане переданных имен не поменяется. > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From oleg на mamontov.net Thu Jan 10 13:11:59 2019 From: oleg на mamontov.net (Oleg A. Mamontov) Date: Thu, 10 Jan 2019 16:11:59 +0300 Subject: GeoIP In-Reply-To: <21711a4c3ec06d7e17b4a55dc1c0fcdd.NginxMailingListRussian@forum.nginx.org> References: <20190104153914.ohbj67rsjoea7ly7@xenon.mamontov.net> <21711a4c3ec06d7e17b4a55dc1c0fcdd.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190110131159.ono5wbhostpsb56i@xenon.mamontov.net> On Sun, Jan 06, 2019 at 12:32:43PM -0500, kycedbi wrote: >Здравствуйте. >А планируется добавление в официальный репозиторий nginx пакета с модулем >https://github.com/leev/ngx_http_geoip2_module (как это сейчас есть для >модуля GeoIP v1)? >Чтобы можно было спокойно обновлять nginx через менеджер пакетов linux >(apt/yum), не пересобирая каждый раз из исходников сторонний модуль? >Или с этим есть какие-то сложности (внутренняя конкуренция с nginx-plus, >неподходящая лицензия ngx_http_geoip2_module, etc)? Исходный код модуля ngx_http_geoip_module входит в поставку nginx, поэтому наличие для него пакета в официальном репозитории выглядит вполне естественным. А ngx_http_geoip2_module это совершенно сторонний (по отношению к разработчикам nginx) код, обладающий внешними зависимостями (libmaxminddb). Никакой внутренней конкуренции с NGINX Plus тут нет, проблем с лицензией тоже не просматривается. Возможный путь решения - создание пакета с динамическим модулем в репозитории целевой операционной системы. В данный момент рассматривается вопрос доработки ngx_http_geoip_module для поддержки MaxMind GeoIP2, но пока это из области возможных планов с неопределенными сроками. >Благодарю за информацию. >С уважением. -- Cheers, Oleg A. Mamontov From nginx-forum на forum.nginx.org Thu Jan 10 13:53:12 2019 From: nginx-forum на forum.nginx.org (kycedbi) Date: Thu, 10 Jan 2019 08:53:12 -0500 Subject: GeoIP In-Reply-To: <20190110131159.ono5wbhostpsb56i@xenon.mamontov.net> References: <20190110131159.ono5wbhostpsb56i@xenon.mamontov.net> Message-ID: <517dcc55057328297dce64a8af898968.NginxMailingListRussian@forum.nginx.org> > В данный момент рассматривается вопрос доработки ngx_http_geoip_module > для поддержки MaxMind GeoIP2, но пока это из области возможных планов > с неопределенными сроками. Благодарю за информацию. А в nginx, случаем, нету программы, с помощью которой можно было бы ускорить реализацию некоторого функционала за донаты? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282545,282626#msg-282626 From oleg на mamontov.net Thu Jan 10 14:46:51 2019 From: oleg на mamontov.net (Oleg A. Mamontov) Date: Thu, 10 Jan 2019 17:46:51 +0300 Subject: GeoIP In-Reply-To: <517dcc55057328297dce64a8af898968.NginxMailingListRussian@forum.nginx.org> References: <20190110131159.ono5wbhostpsb56i@xenon.mamontov.net> <517dcc55057328297dce64a8af898968.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190110144651.6rlawr4f34ps4rbe@xenon.mamontov.net> On Thu, Jan 10, 2019 at 08:53:12AM -0500, kycedbi wrote: >> В данный момент рассматривается вопрос доработки ngx_http_geoip_module >> для поддержки MaxMind GeoIP2, но пока это из области возможных планов >> с неопределенными сроками. >Благодарю за информацию. >А в nginx, случаем, нету программы, с помощью которой можно было бы ускорить >реализацию некоторого функционала за донаты? Нет, программы такого формата у нас не существует, но качественные предложения по дополнению функциональности от сообщества охотно принимаются, подробнее можно прочитать тут: http://nginx.org/ru/docs/contributing_changes.html -- Cheers, Oleg A. Mamontov mailto: oleg на mamontov.net skype: lonerr11 cell: +7 (903) 798-1352 From endo.mulo на gmail.com Mon Jan 14 16:02:46 2019 From: endo.mulo на gmail.com (Dmitriy M.) Date: Mon, 14 Jan 2019 18:02:46 +0200 Subject: =?UTF-8?B?0JLQvtC30LzQvtC20L3QvtGB0YLRjCDRgdC00LXQu9Cw0YLRjCBiaW5kKCkg0LQ=?= =?UTF-8?B?0LvRjyDQuNGB0YXQvtC00Y/RidC40YUg0LfQsNC/0YDQvtGB0L7QsiDQvNC+?= =?UTF-8?B?0LTRg9C70Y8gbWFpbA==?= Message-ID: Добрый день, Возможно, не нашел в документации, но есть ли возможность указать от какого исходящего (локального) IP будет сделать запрос, если это запрос от mail модуля? Речь идет об аналоге proxy_bind из модулей http_proxy/stream_proxy http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_bind . С их помощью мы успешно решаем проблему нехватки локальных портов при большом кол-ве исходящих соединений работая с HTTP. Хотелось бы найти аналог и в mail модуле, т.к. похоже начинает проявляться та же проблема нехватки локальных портов на почтовом прокси-сервере с установленным тут nginx и модулем mail, но как обойти её без создания дополнительных контейнеров (что бы исходящие IP были разные), пока не придумал (тюнинги системы выполнены, расширен диапазон разрешенных портов и пр.). Спасибо! ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Jan 14 19:50:56 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 14 Jan 2019 22:50:56 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L7RgdGC0Ywg0YHQtNC10LvQsNGC0YwgYmluZCgp?= =?UTF-8?B?INC00LvRjyDQuNGB0YXQvtC00Y/RidC40YUg0LfQsNC/0YDQvtGB0L7QsiA=?= =?UTF-8?B?0LzQvtC00YPQu9GPIG1haWw=?= In-Reply-To: References: Message-ID: <20190114195056.GF99070@mdounin.ru> Hello! On Mon, Jan 14, 2019 at 06:02:46PM +0200, Dmitriy M. wrote: > Возможно, не нашел в документации, но есть ли возможность указать от какого > исходящего (локального) IP будет сделать запрос, если это запрос от mail > модуля? Нет, сейчас mail-модуль bind не умеет. > Речь идет об аналоге proxy_bind из модулей http_proxy/stream_proxy > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_bind . С их > помощью мы успешно решаем проблему нехватки локальных портов при большом > кол-ве исходящих соединений работая с HTTP. > Хотелось бы найти аналог и в mail модуле, т.к. похоже начинает проявляться > та же проблема нехватки локальных портов на почтовом прокси-сервере с > установленным тут nginx и модулем mail, но как обойти её без создания > дополнительных контейнеров (что бы исходящие IP были разные), пока не > придумал (тюнинги системы выполнены, расширен диапазон разрешенных портов и > пр.). Кажется, в случае mail могут иметь смысл два возможных подхода: явная директива proxy_bind (со статически заданным значением, ибо переменных в mail нет), либо же заголовок ответа от auth-скрипта Auth-Bind (аналогично Auth-Server/Auth-Port, задающих собственно адрес проксирования). Патч, добавляющий директиву proxy_bind: # HG changeset patch # User Maxim Dounin # Date 1547495341 -10800 # Mon Jan 14 22:49:01 2019 +0300 # Node ID 271bd1fa164251de128cdc35dc1295ceaaa06a30 # Parent 6d15e452fa2eaf19408e24a0d0fcc3a31344a289 Mail: proxy_bind. diff --git a/src/mail/ngx_mail_proxy_module.c b/src/mail/ngx_mail_proxy_module.c --- a/src/mail/ngx_mail_proxy_module.c +++ b/src/mail/ngx_mail_proxy_module.c @@ -13,11 +13,12 @@ typedef struct { - ngx_flag_t enable; - ngx_flag_t pass_error_message; - ngx_flag_t xclient; - size_t buffer_size; - ngx_msec_t timeout; + ngx_flag_t enable; + ngx_flag_t pass_error_message; + ngx_flag_t xclient; + size_t buffer_size; + ngx_msec_t timeout; + ngx_addr_t *local; } ngx_mail_proxy_conf_t; @@ -35,6 +36,8 @@ static void ngx_mail_proxy_close_session static void *ngx_mail_proxy_create_conf(ngx_conf_t *cf); static char *ngx_mail_proxy_merge_conf(ngx_conf_t *cf, void *parent, void *child); +static char *ngx_mail_proxy_bind(ngx_conf_t *cf, ngx_command_t *cmd, + void *conf); static ngx_command_t ngx_mail_proxy_commands[] = { @@ -60,6 +63,13 @@ static ngx_command_t ngx_mail_proxy_com offsetof(ngx_mail_proxy_conf_t, timeout), NULL }, + { ngx_string("proxy_bind"), + NGX_MAIL_MAIN_CONF|NGX_MAIL_SRV_CONF|NGX_CONF_TAKE1, + ngx_mail_proxy_bind, + NGX_MAIL_SRV_CONF_OFFSET, + 0, + NULL }, + { ngx_string("proxy_pass_error_message"), NGX_MAIL_MAIN_CONF|NGX_MAIL_SRV_CONF|NGX_CONF_FLAG, ngx_conf_set_flag_slot, @@ -118,6 +128,7 @@ ngx_mail_proxy_init(ngx_mail_session_t * s->connection->log->action = "connecting to upstream"; + pcf = ngx_mail_get_module_srv_conf(s, ngx_mail_proxy_module); cscf = ngx_mail_get_module_srv_conf(s, ngx_mail_core_module); p = ngx_pcalloc(s->connection->pool, sizeof(ngx_mail_proxy_ctx_t)); @@ -134,6 +145,7 @@ ngx_mail_proxy_init(ngx_mail_session_t * p->upstream.get = ngx_event_get_peer; p->upstream.log = s->connection->log; p->upstream.log_error = NGX_ERROR_ERR; + p->upstream.local = pcf->local; rc = ngx_event_connect_peer(&p->upstream); @@ -150,8 +162,6 @@ ngx_mail_proxy_init(ngx_mail_session_t * s->connection->read->handler = ngx_mail_proxy_block_read; p->upstream.connection->write->handler = ngx_mail_proxy_dummy_handler; - pcf = ngx_mail_get_module_srv_conf(s, ngx_mail_proxy_module); - s->proxy->buffer = ngx_create_temp_buf(s->connection->pool, pcf->buffer_size); if (s->proxy->buffer == NULL) { @@ -1104,6 +1114,7 @@ ngx_mail_proxy_create_conf(ngx_conf_t *c pcf->xclient = NGX_CONF_UNSET; pcf->buffer_size = NGX_CONF_UNSET_SIZE; pcf->timeout = NGX_CONF_UNSET_MSEC; + pcf->local = NGX_CONF_UNSET_PTR; return pcf; } @@ -1121,6 +1132,52 @@ ngx_mail_proxy_merge_conf(ngx_conf_t *cf ngx_conf_merge_size_value(conf->buffer_size, prev->buffer_size, (size_t) ngx_pagesize); ngx_conf_merge_msec_value(conf->timeout, prev->timeout, 24 * 60 * 60000); + ngx_conf_merge_ptr_value(conf->local, prev->local, NULL); return NGX_CONF_OK; } + + +static char * +ngx_mail_proxy_bind(ngx_conf_t *cf, ngx_command_t *cmd, void *conf) +{ + ngx_mail_proxy_conf_t *pcf = conf; + + ngx_int_t rc; + ngx_str_t *value; + + if (pcf->local != NGX_CONF_UNSET_PTR) { + return "is duplicate"; + } + + value = cf->args->elts; + + if (cf->args->nelts == 2 && ngx_strcmp(value[1].data, "off") == 0) { + pcf->local = NULL; + return NGX_CONF_OK; + } + + pcf->local = ngx_palloc(cf->pool, sizeof(ngx_addr_t)); + if (pcf->local == NULL) { + return NGX_CONF_ERROR; + } + + rc = ngx_parse_addr_port(cf->pool, pcf->local, value[1].data, + value[1].len); + + switch (rc) { + case NGX_OK: + pcf->local->name = value[1]; + break; + + case NGX_DECLINED: + ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, + "invalid address \"%V\"", &value[1]); + /* fall through */ + + default: + return NGX_CONF_ERROR; + } + + return NGX_CONF_OK; +} -- Maxim Dounin http://mdounin.ru/ From endo.mulo на gmail.com Tue Jan 15 11:28:52 2019 From: endo.mulo на gmail.com (Dmitriy M.) Date: Tue, 15 Jan 2019 13:28:52 +0200 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L7RgdGC0Ywg0YHQtNC10LvQsNGC0YwgYmluZCgp?= =?UTF-8?B?INC00LvRjyDQuNGB0YXQvtC00Y/RidC40YUg0LfQsNC/0YDQvtGB0L7QsiA=?= =?UTF-8?B?0LzQvtC00YPQu9GPIG1haWw=?= In-Reply-To: <20190114195056.GF99070@mdounin.ru> References: <20190114195056.GF99070@mdounin.ru> Message-ID: Спасибо за развернутый ответ и патч. Мы модифицировали патч, добавив логику перебора IP исходящих соединений. В нашем случае нам достаточно 4х IP, т.е.: proxy_bind 10.10.0.1 10.10.0.2 10.10.0.3 10.10.0.4; Вроде работает пока, балансируя соединения с 4 IP поровну. Патч с модификацией: diff --git a/src/mail/ngx_mail_proxy_module.c b/src/mail/ngx_mail_proxy_module.c index 1c86e54..da55a11 100644 --- a/src/mail/ngx_mail_proxy_module.c +++ b/src/mail/ngx_mail_proxy_module.c @@ -13,11 +13,14 @@ typedef struct { - ngx_flag_t enable; - ngx_flag_t pass_error_message; - ngx_flag_t xclient; - size_t buffer_size; - ngx_msec_t timeout; + ngx_flag_t enable; + ngx_flag_t pass_error_message; + ngx_flag_t xclient; + size_t buffer_size; + ngx_msec_t timeout; + ngx_addr_t *local; + size_t local_size; + size_t local_index; } ngx_mail_proxy_conf_t; @@ -35,6 +38,8 @@ static void ngx_mail_proxy_close_session(ngx_mail_session_t *s); static void *ngx_mail_proxy_create_conf(ngx_conf_t *cf); static char *ngx_mail_proxy_merge_conf(ngx_conf_t *cf, void *parent, void *child); +static char *ngx_mail_proxy_bind(ngx_conf_t *cf, ngx_command_t *cmd, + void *conf); static ngx_command_t ngx_mail_proxy_commands[] = { @@ -60,6 +65,13 @@ static ngx_command_t ngx_mail_proxy_commands[] = { offsetof(ngx_mail_proxy_conf_t, timeout), NULL }, + { ngx_string("proxy_bind"), + NGX_MAIL_MAIN_CONF|NGX_MAIL_SRV_CONF|NGX_CONF_TAKE1234|NGX_CONF_TAKE5|NGX_CONF_TAKE6|NGX_CONF_TAKE7, + ngx_mail_proxy_bind, + NGX_MAIL_SRV_CONF_OFFSET, + 0, + NULL }, + { ngx_string("proxy_pass_error_message"), NGX_MAIL_MAIN_CONF|NGX_MAIL_SRV_CONF|NGX_CONF_FLAG, ngx_conf_set_flag_slot, @@ -118,6 +130,7 @@ ngx_mail_proxy_init(ngx_mail_session_t *s, ngx_addr_t *peer) s->connection->log->action = "connecting to upstream"; + pcf = ngx_mail_get_module_srv_conf(s, ngx_mail_proxy_module); cscf = ngx_mail_get_module_srv_conf(s, ngx_mail_core_module); p = ngx_pcalloc(s->connection->pool, sizeof(ngx_mail_proxy_ctx_t)); @@ -135,6 +148,16 @@ ngx_mail_proxy_init(ngx_mail_session_t *s, ngx_addr_t *peer) p->upstream.log = s->connection->log; p->upstream.log_error = NGX_ERROR_ERR; + if (pcf->local) { + p->upstream.local = pcf->local + pcf->local_index; + + if (pcf->local_size > 1 + && ++pcf->local_index >= pcf->local_size) { + /* wrap around */ + pcf->local_index = 0; + } + } + rc = ngx_event_connect_peer(&p->upstream); if (rc == NGX_ERROR || rc == NGX_BUSY || rc == NGX_DECLINED) { @@ -150,8 +173,6 @@ ngx_mail_proxy_init(ngx_mail_session_t *s, ngx_addr_t *peer) s->connection->read->handler = ngx_mail_proxy_block_read; p->upstream.connection->write->handler = ngx_mail_proxy_dummy_handler; - pcf = ngx_mail_get_module_srv_conf(s, ngx_mail_proxy_module); - s->proxy->buffer = ngx_create_temp_buf(s->connection->pool, pcf->buffer_size); if (s->proxy->buffer == NULL) { @@ -1104,6 +1125,9 @@ ngx_mail_proxy_create_conf(ngx_conf_t *cf) pcf->xclient = NGX_CONF_UNSET; pcf->buffer_size = NGX_CONF_UNSET_SIZE; pcf->timeout = NGX_CONF_UNSET_MSEC; + pcf->local = NGX_CONF_UNSET_PTR; + pcf->local_size = NGX_CONF_UNSET_SIZE; + pcf->local_index = NGX_CONF_UNSET_SIZE; return pcf; } @@ -1121,6 +1145,57 @@ ngx_mail_proxy_merge_conf(ngx_conf_t *cf, void *parent, void *child) ngx_conf_merge_size_value(conf->buffer_size, prev->buffer_size, (size_t) ngx_pagesize); ngx_conf_merge_msec_value(conf->timeout, prev->timeout, 24 * 60 * 60000); + ngx_conf_merge_ptr_value(conf->local, prev->local, NULL); + ngx_conf_merge_size_value(conf->local_size, prev->local_size, 0); + ngx_conf_merge_size_value(conf->local_index, prev->local_index, 0); + + return NGX_CONF_OK; +} + +static char * +ngx_mail_proxy_bind(ngx_conf_t *cf, ngx_command_t *cmd, void *conf) +{ + ngx_mail_proxy_conf_t *pcf = conf; + size_t i; + + ngx_int_t rc; + ngx_str_t *value; + + if (pcf->local != NGX_CONF_UNSET_PTR) { + return "is duplicate"; + } + + value = cf->args->elts; + + if (cf->args->nelts == 2 && ngx_strcmp(value[1].data, "off") == 0) { + pcf->local = NULL; + return NGX_CONF_OK; + } + + pcf->local = ngx_palloc(cf->pool, (cf->args->nelts - 1) * sizeof(ngx_addr_t)); + if (pcf->local == NULL) { + return NGX_CONF_ERROR; + } + + for (i = 0; i < (cf->args->nelts - 1); ++i) { + rc = ngx_parse_addr_port(cf->pool, pcf->local + i, value[i + 1].data, + value[i + 1].len); + + switch (rc) { + case NGX_OK: + pcf->local[i].name = value[i + 1]; + break; + + case NGX_DECLINED: + ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, + "invalid address \"%V\"", &value[1 + 1]); + /* fall through */ + + default: + return NGX_CONF_ERROR; + } + } + pcf->local_size = (cf->args->nelts - 1); return NGX_CONF_OK; } пн, 14 янв. 2019 г. в 21:51, Maxim Dounin : > Hello! > > On Mon, Jan 14, 2019 at 06:02:46PM +0200, Dmitriy M. wrote: > > > Возможно, не нашел в документации, но есть ли возможность указать от > какого > > исходящего (локального) IP будет сделать запрос, если это запрос от mail > > модуля? > > Нет, сейчас mail-модуль bind не умеет. > > > Речь идет об аналоге proxy_bind из модулей http_proxy/stream_proxy > > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_bind . С > их > > помощью мы успешно решаем проблему нехватки локальных портов при большом > > кол-ве исходящих соединений работая с HTTP. > > Хотелось бы найти аналог и в mail модуле, т.к. похоже начинает > проявляться > > та же проблема нехватки локальных портов на почтовом прокси-сервере с > > установленным тут nginx и модулем mail, но как обойти её без создания > > дополнительных контейнеров (что бы исходящие IP были разные), пока не > > придумал (тюнинги системы выполнены, расширен диапазон разрешенных > портов и > > пр.). > > Кажется, в случае mail могут иметь смысл два возможных подхода: > явная директива proxy_bind (со статически заданным значением, ибо > переменных в mail нет), либо же заголовок ответа от auth-скрипта > Auth-Bind (аналогично Auth-Server/Auth-Port, задающих собственно > адрес проксирования). > > Патч, добавляющий директиву proxy_bind: > > # HG changeset patch > # User Maxim Dounin > # Date 1547495341 -10800 > # Mon Jan 14 22:49:01 2019 +0300 > # Node ID 271bd1fa164251de128cdc35dc1295ceaaa06a30 > # Parent 6d15e452fa2eaf19408e24a0d0fcc3a31344a289 > Mail: proxy_bind. > > diff --git a/src/mail/ngx_mail_proxy_module.c > b/src/mail/ngx_mail_proxy_module.c > --- a/src/mail/ngx_mail_proxy_module.c > +++ b/src/mail/ngx_mail_proxy_module.c > @@ -13,11 +13,12 @@ > > > typedef struct { > - ngx_flag_t enable; > - ngx_flag_t pass_error_message; > - ngx_flag_t xclient; > - size_t buffer_size; > - ngx_msec_t timeout; > + ngx_flag_t enable; > + ngx_flag_t pass_error_message; > + ngx_flag_t xclient; > + size_t buffer_size; > + ngx_msec_t timeout; > + ngx_addr_t *local; > } ngx_mail_proxy_conf_t; > > > @@ -35,6 +36,8 @@ static void ngx_mail_proxy_close_session > static void *ngx_mail_proxy_create_conf(ngx_conf_t *cf); > static char *ngx_mail_proxy_merge_conf(ngx_conf_t *cf, void *parent, > void *child); > +static char *ngx_mail_proxy_bind(ngx_conf_t *cf, ngx_command_t *cmd, > + void *conf); > > > static ngx_command_t ngx_mail_proxy_commands[] = { > @@ -60,6 +63,13 @@ static ngx_command_t ngx_mail_proxy_com > offsetof(ngx_mail_proxy_conf_t, timeout), > NULL }, > > + { ngx_string("proxy_bind"), > + NGX_MAIL_MAIN_CONF|NGX_MAIL_SRV_CONF|NGX_CONF_TAKE1, > + ngx_mail_proxy_bind, > + NGX_MAIL_SRV_CONF_OFFSET, > + 0, > + NULL }, > + > { ngx_string("proxy_pass_error_message"), > NGX_MAIL_MAIN_CONF|NGX_MAIL_SRV_CONF|NGX_CONF_FLAG, > ngx_conf_set_flag_slot, > @@ -118,6 +128,7 @@ ngx_mail_proxy_init(ngx_mail_session_t * > > s->connection->log->action = "connecting to upstream"; > > + pcf = ngx_mail_get_module_srv_conf(s, ngx_mail_proxy_module); > cscf = ngx_mail_get_module_srv_conf(s, ngx_mail_core_module); > > p = ngx_pcalloc(s->connection->pool, sizeof(ngx_mail_proxy_ctx_t)); > @@ -134,6 +145,7 @@ ngx_mail_proxy_init(ngx_mail_session_t * > p->upstream.get = ngx_event_get_peer; > p->upstream.log = s->connection->log; > p->upstream.log_error = NGX_ERROR_ERR; > + p->upstream.local = pcf->local; > > rc = ngx_event_connect_peer(&p->upstream); > > @@ -150,8 +162,6 @@ ngx_mail_proxy_init(ngx_mail_session_t * > s->connection->read->handler = ngx_mail_proxy_block_read; > p->upstream.connection->write->handler = ngx_mail_proxy_dummy_handler; > > - pcf = ngx_mail_get_module_srv_conf(s, ngx_mail_proxy_module); > - > s->proxy->buffer = ngx_create_temp_buf(s->connection->pool, > pcf->buffer_size); > if (s->proxy->buffer == NULL) { > @@ -1104,6 +1114,7 @@ ngx_mail_proxy_create_conf(ngx_conf_t *c > pcf->xclient = NGX_CONF_UNSET; > pcf->buffer_size = NGX_CONF_UNSET_SIZE; > pcf->timeout = NGX_CONF_UNSET_MSEC; > + pcf->local = NGX_CONF_UNSET_PTR; > > return pcf; > } > @@ -1121,6 +1132,52 @@ ngx_mail_proxy_merge_conf(ngx_conf_t *cf > ngx_conf_merge_size_value(conf->buffer_size, prev->buffer_size, > (size_t) ngx_pagesize); > ngx_conf_merge_msec_value(conf->timeout, prev->timeout, 24 * 60 * > 60000); > + ngx_conf_merge_ptr_value(conf->local, prev->local, NULL); > > return NGX_CONF_OK; > } > + > + > +static char * > +ngx_mail_proxy_bind(ngx_conf_t *cf, ngx_command_t *cmd, void *conf) > +{ > + ngx_mail_proxy_conf_t *pcf = conf; > + > + ngx_int_t rc; > + ngx_str_t *value; > + > + if (pcf->local != NGX_CONF_UNSET_PTR) { > + return "is duplicate"; > + } > + > + value = cf->args->elts; > + > + if (cf->args->nelts == 2 && ngx_strcmp(value[1].data, "off") == 0) { > + pcf->local = NULL; > + return NGX_CONF_OK; > + } > + > + pcf->local = ngx_palloc(cf->pool, sizeof(ngx_addr_t)); > + if (pcf->local == NULL) { > + return NGX_CONF_ERROR; > + } > + > + rc = ngx_parse_addr_port(cf->pool, pcf->local, value[1].data, > + value[1].len); > + > + switch (rc) { > + case NGX_OK: > + pcf->local->name = value[1]; > + break; > + > + case NGX_DECLINED: > + ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, > + "invalid address \"%V\"", &value[1]); > + /* fall through */ > + > + default: > + return NGX_CONF_ERROR; > + } > + > + return NGX_CONF_OK; > +} > > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Jan 15 13:43:51 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 15 Jan 2019 16:43:51 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L7RgdGC0Ywg0YHQtNC10LvQsNGC0YwgYmluZCgp?= =?UTF-8?B?INC00LvRjyDQuNGB0YXQvtC00Y/RidC40YUg0LfQsNC/0YDQvtGB0L7QsiA=?= =?UTF-8?B?0LzQvtC00YPQu9GPIG1haWw=?= In-Reply-To: References: <20190114195056.GF99070@mdounin.ru> Message-ID: <20190115134351.GG99070@mdounin.ru> Hello! On Tue, Jan 15, 2019 at 01:28:52PM +0200, Dmitriy M. wrote: > Спасибо за развернутый ответ и патч. > > Мы модифицировали патч, добавив логику перебора IP исходящих соединений. В > нашем случае нам достаточно 4х IP, т.е.: > > proxy_bind 10.10.0.1 10.10.0.2 10.10.0.3 10.10.0.4; > > Вроде работает пока, балансируя соединения с 4 IP поровну. Нет, так мы точно делать не будем. Если хочется вращать много локальных адресов в рамках одного сервера - то вот патч, который позволяет задать локальный адрес из auth-скрипта с помощью заголовка Auth-Bind: # HG changeset patch # User Maxim Dounin # Date 1547559561 -10800 # Tue Jan 15 16:39:21 2019 +0300 # Node ID 7d052f39bf8c8fb028569e290f67edf4bacb3252 # Parent 6d15e452fa2eaf19408e24a0d0fcc3a31344a289 Mail: Auth-Bind header. diff --git a/src/mail/ngx_mail.h b/src/mail/ngx_mail.h --- a/src/mail/ngx_mail.h +++ b/src/mail/ngx_mail.h @@ -400,7 +400,8 @@ char *ngx_mail_capabilities(ngx_conf_t * /* STUB */ -void ngx_mail_proxy_init(ngx_mail_session_t *s, ngx_addr_t *peer); +void ngx_mail_proxy_init(ngx_mail_session_t *s, ngx_addr_t *peer, + ngx_addr_t *local); void ngx_mail_auth_http_init(ngx_mail_session_t *s); /**/ diff --git a/src/mail/ngx_mail_auth_http_module.c b/src/mail/ngx_mail_auth_http_module.c --- a/src/mail/ngx_mail_auth_http_module.c +++ b/src/mail/ngx_mail_auth_http_module.c @@ -53,6 +53,7 @@ struct ngx_mail_auth_http_ctx_s { ngx_str_t err; ngx_str_t errmsg; ngx_str_t errcode; + ngx_str_t bind; time_t sleep; @@ -467,7 +468,7 @@ ngx_mail_auth_http_process_headers(ngx_m time_t timer; size_t len, size; ngx_int_t rc, port, n; - ngx_addr_t *peer; + ngx_addr_t *peer, *local; ngx_log_debug0(NGX_LOG_DEBUG_MAIL, s->connection->log, 0, "mail auth http process headers"); @@ -677,6 +678,18 @@ ngx_mail_auth_http_process_headers(ngx_m continue; } + if (len == sizeof("Auth-Bind") - 1 + && ngx_strncasecmp(ctx->header_name_start, + (u_char *) "Auth-Bind", + sizeof("Auth-Bind") - 1) + == 0) + { + ctx->bind.len = ctx->header_end - ctx->header_start; + ctx->bind.data = ctx->header_start; + + continue; + } + /* ignore other headers */ continue; @@ -772,6 +785,52 @@ ngx_mail_auth_http_process_headers(ngx_m return; } + if (ctx->bind.len) { + + local = ngx_palloc(s->connection->pool, sizeof(ngx_addr_t)); + if (local == NULL) { + ngx_close_connection(ctx->peer.connection); + ngx_destroy_pool(ctx->pool); + ngx_mail_session_internal_server_error(s); + return; + } + + rc = ngx_parse_addr_port(s->connection->pool, local, + ctx->bind.data, ctx->bind.len); + + switch (rc) { + case NGX_OK: + break; + + case NGX_DECLINED: + ngx_log_error(NGX_LOG_ERR, s->connection->log, 0, + "auth http server %V sent invalid bind " + "address:\"%V\"", + ctx->peer.name, &ctx->bind); + /* fall through */ + + default: + ngx_destroy_pool(ctx->pool); + ngx_mail_session_internal_server_error(s); + return; + } + + local->name.len = ctx->bind.len; + + local->name.data = ngx_pnalloc(s->connection->pool, + local->name.len); + if (local->name.data == NULL) { + ngx_destroy_pool(ctx->pool); + ngx_mail_session_internal_server_error(s); + return; + } + + ngx_memcpy(local->name.data, ctx->bind.data, ctx->bind.len); + + } else { + local = NULL; + } + peer = ngx_pcalloc(s->connection->pool, sizeof(ngx_addr_t)); if (peer == NULL) { ngx_destroy_pool(ctx->pool); @@ -832,7 +891,7 @@ ngx_mail_auth_http_process_headers(ngx_m ngx_memcpy(peer->name.data + len, ctx->port.data, ctx->port.len); ngx_destroy_pool(ctx->pool); - ngx_mail_proxy_init(s, peer); + ngx_mail_proxy_init(s, peer, local); return; } diff --git a/src/mail/ngx_mail_proxy_module.c b/src/mail/ngx_mail_proxy_module.c --- a/src/mail/ngx_mail_proxy_module.c +++ b/src/mail/ngx_mail_proxy_module.c @@ -109,7 +109,7 @@ static u_char smtp_auth_ok[] = "235 2.0 void -ngx_mail_proxy_init(ngx_mail_session_t *s, ngx_addr_t *peer) +ngx_mail_proxy_init(ngx_mail_session_t *s, ngx_addr_t *peer, ngx_addr_t *local) { ngx_int_t rc; ngx_mail_proxy_ctx_t *p; @@ -134,6 +134,7 @@ ngx_mail_proxy_init(ngx_mail_session_t * p->upstream.get = ngx_event_get_peer; p->upstream.log = s->connection->log; p->upstream.log_error = NGX_ERROR_ERR; + p->upstream.local = local; rc = ngx_event_connect_peer(&p->upstream); -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue Jan 15 15:49:36 2019 From: nginx-forum на forum.nginx.org (dmprog08) Date: Tue, 15 Jan 2019 10:49:36 -0500 Subject: nginx rewrite rule Message-ID: <6a4e84938e48efb0653cbf9c4bce9c27.NginxMailingListRussian@forum.nginx.org> Как настроить рулзы чтобы когда я вводил такой урл http://admin.1851.local/assets/814baced/css/style_v1.css перенаправляло на http://admin.1851.local/assets/814baced/css/style.css http://admin.1851.local/assets/814baced/css/style_v2.css перенаправляло на http://admin.1851.local/assets/814baced/css/style.css то есть просто style_v1.css => style.css style_v2.css => style.css Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282704,282704#msg-282704 From andrey на kopeyko.ru Tue Jan 15 22:10:45 2019 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Wed, 16 Jan 2019 01:10:45 +0300 (MSK) Subject: nginx rewrite rule In-Reply-To: <6a4e84938e48efb0653cbf9c4bce9c27.NginxMailingListRussian@forum.nginx.org> References: <6a4e84938e48efb0653cbf9c4bce9c27.NginxMailingListRussian@forum.nginx.org> Message-ID: On Tue, 15 Jan 2019, dmprog08 wrote: > Как настроить рулзы чтобы когда я вводил такой урл > http://admin.1851.local/assets/814baced/css/style_v1.css перенаправляло на > http://admin.1851.local/assets/814baced/css/style.css > http://admin.1851.local/assets/814baced/css/style_v2.css перенаправляло на > http://admin.1851.local/assets/814baced/css/style.css > то есть просто > style_v1.css => style.css > style_v2.css => style.css > Зачем вам "рулзы"? сделайте надёжно location ^~ ^/(assets/814baced/css/style)_v(1|2).css { return 301 http://$host/$1.css; } -- Best regards, Andrey Kopeyko From nginx-forum на forum.nginx.org Wed Jan 16 04:28:34 2019 From: nginx-forum на forum.nginx.org (inkognito0609) Date: Tue, 15 Jan 2019 23:28:34 -0500 Subject: error log format Message-ID: Доброго времени суток. Кейс такой: Настроено логирование: на хост в файл + отправка в graylog При недоступности graylog, nginx не может отправить отправить и соответственно получаем в error.log massage "...send() failed (111: Connection refused)" что намного увеличивает объем error лога, а соответственно и проблемы с местом. Возможно ли явно указать не писать error log для определенного случая? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282708,282708#msg-282708 From nginx на mva.name Wed Jan 16 14:26:45 2019 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Wed, 16 Jan 2019 21:26:45 +0700 Subject: =?UTF-8?Q?=5BUnit=5D_Per-appication_acces=5Flog=27=D0=B8?= Message-ID: <1706343.6ukY5vAJJj@tp> А планируется ли в Unit завезти возможность назначать отдельные access-логи для каждого приложения вместо одного общего?.. И, что-то, я в документации не нахожу информации по поводу error_log'ов :'( Подскажите, пожалуйста, куда тогда смотреть на предмет ошибок (в т.ч. тех, что отдаёт приложение)?.. P.S. error_log'и на уровне приложения тоже хотелось бы мочь задавать :) From vbart на nginx.com Wed Jan 16 16:23:37 2019 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 16 Jan 2019 19:23:37 +0300 Subject: =?UTF-8?Q?Re=3A_=5BUnit=5D_Per-appication_acces=5Flog=27=D0=B8?= In-Reply-To: <1706343.6ukY5vAJJj@tp> References: <1706343.6ukY5vAJJj@tp> Message-ID: <1651599.mtSk9uYGdT@vbart-workstation> On Wednesday 16 January 2019 21:26:45 Vadim A. Misbakh-Soloviov wrote: > А планируется ли в Unit завезти возможность назначать отдельные access-логи > для каждого приложения вместо одного общего?.. > Да, различные настройки лога в планах есть. > И, что-то, я в документации не нахожу информации по поводу error_log'ов :'( > Подскажите, пожалуйста, куда тогда смотреть на предмет ошибок (в т.ч. тех, что > отдаёт приложение)?.. У юнита есть основной лог, который указывается при сборке или на этапе запуска: http://unit.nginx.org/troubleshooting/#logging > > P.S. error_log'и на уровне приложения тоже хотелось бы мочь задавать :) > Имеет смысл написать сюда: https://github.com/nginx/unit/issues/197 -- Валентин Бартенев From nginx-forum на forum.nginx.org Fri Jan 18 18:12:08 2019 From: nginx-forum на forum.nginx.org (Vladislavik) Date: Fri, 18 Jan 2019 13:12:08 -0500 Subject: =?UTF-8?Q?Re=3A_fastcgi_keep_conn_on_=D0=B8_fastcgi_finish_request=28=29_?= =?UTF-8?Q?=D0=B2_PHP?= In-Reply-To: References: <20140218123241.GG33573@mdounin.ru> Message-ID: <710cce766dbb8e72643a52f53c6f4a1b.NginxMailingListRussian@forum.nginx.org> Подтверждаю проблему в последних версиях 2019 года присутствует. При включенных fastcgi_keep_conn и keepalive, если скрипт завершился через fastcgi_finish_request() и продолжает выполнять работу в фоне, то следующий запрос другого клиента к php-fpm может получить 502 ошибку, придя по тому же коннекту, уже судя по всему не сможет подключиться к php-fpm, тк тот все еще выполняет прошлую задачу. Вопрос, почему запрос пихается на не завершенный процесс. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,247596,282747#msg-282747 From mdounin на mdounin.ru Fri Jan 18 22:29:28 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sat, 19 Jan 2019 01:29:28 +0300 Subject: =?UTF-8?Q?Re=3A_fastcgi_keep_conn_on_=D0=B8_fastcgi_finish_request=28=29_?= =?UTF-8?Q?=D0=B2_PHP?= In-Reply-To: <710cce766dbb8e72643a52f53c6f4a1b.NginxMailingListRussian@forum.nginx.org> References: <20140218123241.GG33573@mdounin.ru> <710cce766dbb8e72643a52f53c6f4a1b.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190118222928.GN99070@mdounin.ru> Hello! On Fri, Jan 18, 2019 at 01:12:08PM -0500, Vladislavik wrote: > Подтверждаю проблему в последних версиях 2019 года присутствует. > При включенных fastcgi_keep_conn и keepalive, если скрипт завершился через > fastcgi_finish_request() и продолжает выполнять работу в фоне, то следующий > запрос другого клиента к php-fpm может получить 502 ошибку, придя по тому же > коннекту, уже судя по всему не сможет подключиться к php-fpm, тк тот все еще > выполняет прошлую задачу. Вопрос, почему запрос пихается на не завершенный > процесс. Когда я на это смотрел в последний раз, php не умел корректно работать с keepalive-соединениями при использовании fastcgi_finish_request(), и посылал FCGI_END_REQUEST два раза - один раз после вызова fastcgi_finish_request(), второй раз после завершения работы в фоне. Вторая отправка FCGI_END_REQUEST ожидаемо приводила к 502, если к тому моменту nginx успевал отправить в соединение очередной запрос. Подробнее тут: http://mailman.nginx.org/pipermail/nginx-devel/2014-July/005539.html Я не слежу за разработкой PHP, но если вы по прежнему наблюдаете проблему - можно предположить, что баг в PHP так и не поправили, и fastcgi_finish_request() пользоваться не стоит. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Sat Jan 19 13:04:50 2019 From: nginx-forum на forum.nginx.org (Ilya Evseev) Date: Sat, 19 Jan 2019 08:04:50 -0500 Subject: Nginx + SSL async + Intel QAT Message-ID: <11060fd38c7a8611269f3d77790db1fe.NginxMailingListRussian@forum.nginx.org> Intel и Alibaba создали свои ветки Nginx'a, которые используют для SSL асинхронный режим и аппаратную акселерацию QAT. Было ли обсуждение презентации Интела на NginxConf? Планируется принимать их наработки в Nginx? Или асинхронный режим не имеет смысла без аппаратной акселерации, а аппаратная акселерация слишком редка? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,282750,282750#msg-282750 From nginx-forum на forum.nginx.org Sat Jan 19 14:37:04 2019 From: nginx-forum на forum.nginx.org (S.A.N) Date: Sat, 19 Jan 2019 09:37:04 -0500 Subject: =?UTF-8?Q?Re=3A_fastcgi_keep_conn_on_=D0=B8_fastcgi_finish_request=28=29_?= =?UTF-8?Q?=D0=B2_PHP?= In-Reply-To: <20190118222928.GN99070@mdounin.ru> References: <20190118222928.GN99070@mdounin.ru> Message-ID: <82c023ade02391d97c43a5a372128396.NginxMailingListRussian@forum.nginx.org> > Я не слежу за разработкой PHP, но если вы по прежнему наблюдаете > проблему - можно предположить, что баг в PHP так и не поправили, и > fastcgi_finish_request() пользоваться не стоит. Да, у нас это была одна из причин, уйти от FPM, и перейти на Swoole https://www.swoole.co.uk/docs/ Потом на самописный наш app server В FPM более 100 багов которым 2-5 лет, FPM не развивается и там уже ищут нового мейтейнера https://externals.io/message/101893 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,247596,282751#msg-282751 From maxim на nginx.com Sat Jan 19 18:19:29 2019 From: maxim на nginx.com (Maxim Konovalov) Date: Sat, 19 Jan 2019 21:19:29 +0300 Subject: Nginx + SSL async + Intel QAT In-Reply-To: <11060fd38c7a8611269f3d77790db1fe.NginxMailingListRussian@forum.nginx.org> References: <11060fd38c7a8611269f3d77790db1fe.NginxMailingListRussian@forum.nginx.org> Message-ID: <47434bc5-58da-9479-ba3f-05a4e523c73b@nginx.com> Добрый день. On 19/01/2019 16:04, Ilya Evseev wrote: > Intel и Alibaba создали свои ветки Nginx'a, которые используют для SSL > асинхронный режим и аппаратную акселерацию QAT. > > Было ли обсуждение презентации Интела на NginxConf? > Планируется принимать их наработки в Nginx? > Или асинхронный режим не имеет смысла без аппаратной акселерации, а > аппаратная акселерация слишком редка? > Да, мы на это смотрели несколько лет назад. Насколько я помню, работа этого кода зависела от openssl-1.1.0+. Тогда с этой версией в дистрибутивах большинства ОС было совсем плохо, сейчас ситуация несколько лучше. На данный момент мы этой темой не занимаемся, но с удовольствием послушает про опыт реального использования этого кода. И железа, конечно. Не исключено, что будем делать второй подход. Тут надо понимать, что Интел выкладывает эти (и другие похожие) патчи исключительно с одной целью: продвигать свои технологии. Само по себе это не плохо. Но есть одно следствие -- допиливать до рабочего состояния код они не горят. На момент наших исследований вся эта связка из патча к nginx, QAT engine и драйвера карты, не отличалась стабильностью. Как с этим дело обстоит сейчас не в курсе. Китайские же товарищи, кажется, затягивают вообще любой код. -- Maxim Konovalov From coddoc на mail.ru Tue Jan 22 06:54:12 2019 From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=) Date: Tue, 22 Jan 2019 09:54:12 +0300 Subject: =?UTF-8?B?VXBzdHJlYW0g0Lgg0LfQsNCz0L7Qu9C+0LLQvtC6IEhvc3Q=?= Message-ID: <1548140052.359264467@f416.i.mail.ru> Доброе время суток! Тестовый сервер: test.local. В нем тестовый кластер: upstream cdn {     server :;     server :;     .... } или: upstream cdn {     server cdn001.test.local:;     server cdn002.test.local:;     .... } Не принципиально, ибо "cdn001.test.local" резолвится в и т.д. Само собой, "proxy_http_version 1.1;" и из какого-то локейшена "proxy_pass http://cdn;" Теперь смотрю, что приходит, например, на выбранный бэкенд. Ожидаю там увидеть в заголовке Host значение или 'cdn###.test.local'. Вижу: http header: "Host: cdn". Что не так? Входящий контроль проверяет правильность заголовка Host. Все, что не соответствуют разрешенным, посылаются на 400. Можно, конечно, добавить фильтрацию по белому списку, что-то типа "такой-то IP должен прислать такой-то заголовок". Но (ИМХО) костыль. proxy_set_header 'Host' $upstream_addr; - бесполезно. $upstream_addr получает значение ПОСЛЕ proxy_pass. Попутно вопрос о $upstream_addr. Ее можно еще как-то использовать, кроме как в логах? Например, отправить в php, но без костылей? Спасибо. -- ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From dmitriy на lyalyuev.info Tue Jan 22 07:29:42 2019 From: dmitriy на lyalyuev.info (Dmitriy Lyalyuev) Date: Tue, 22 Jan 2019 09:29:42 +0200 Subject: =?UTF-8?B?UmU6IFVwc3RyZWFtINC4INC30LDQs9C+0LvQvtCy0L7QuiBIb3N0?= In-Reply-To: <1548140052.359264467@f416.i.mail.ru> References: <1548140052.359264467@f416.i.mail.ru> Message-ID: <0C357EE1-2FF8-487D-A33B-1EACB383F4F0@lyalyuev.info> Если коротко, то - https://serverfault.com/questions/598202/make-nginx-to-pass-hostname-of-the-upstream-when-reverseproxying Второй ответ в треде. Но сама схема, как по мне, выглядит костылем. Костылем и лечить. -- With best regards, Dmitriy Lyalyuev dmitriy на lyalyuev.info > On Jan 22, 2019, at 08:54, CoDDoC via nginx-ru wrote: > > Доброе время суток! > > Тестовый сервер: test.local. В нем тестовый кластер: > upstream cdn { > server :; > server :; > .... > } > > или: > upstream cdn { > server cdn001.test.local:; > server cdn002.test.local:; > .... > } > > Не принципиально, ибо "cdn001.test.local" резолвится в и т.д. > > Само собой, "proxy_http_version 1.1;" и из какого-то локейшена "proxy_pass http://cdn;" > Теперь смотрю, что приходит, например, на выбранный бэкенд. > Ожидаю там увидеть в заголовке Host значение или 'cdn###.test.local'. > Вижу: http header: "Host: cdn". Что не так? > > Входящий контроль проверяет правильность заголовка Host. > Все, что не соответствуют разрешенным, посылаются на 400. Можно, конечно, добавить фильтрацию по белому списку, что-то типа "такой-то IP должен прислать такой-то заголовок". Но (ИМХО) костыль. > > proxy_set_header 'Host' $upstream_addr; - бесполезно. > $upstream_addr получает значение ПОСЛЕ proxy_pass. > > Попутно вопрос о $upstream_addr. > Ее можно еще как-то использовать, кроме как в логах? Например, отправить в php, но без костылей? > > Спасибо. > -- > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: ----------- следущая часть ----------- Вложение не в текстовом формате было извлечено… Имя: smime.p7s Тип: application/pkcs7-signature Размер: 3884 байтов Описание: отсутствует URL: From alex на tkachuk.pp.ua Tue Jan 22 12:28:50 2019 From: alex на tkachuk.pp.ua (Alex Tkachuk) Date: Tue, 22 Jan 2019 14:28:50 +0200 Subject: =?UTF-8?B?UmU6IFVwc3RyZWFtINC4INC30LDQs9C+0LvQvtCy0L7QuiBIb3N0?= In-Reply-To: <0C357EE1-2FF8-487D-A33B-1EACB383F4F0@lyalyuev.info> References: <1548140052.359264467@f416.i.mail.ru> <0C357EE1-2FF8-487D-A33B-1EACB383F4F0@lyalyuev.info> Message-ID: <658EEFD4-2B2F-45A5-B460-6CA5CBC6C4D9@tkachuk.pp.ua> В линуксе есть какой-то прикол с резолвом .local доменов. Гляньте на /etc/nsswitch.conf. Там определяется очередность служб для резолва адресов. Для .local оно как-то отдельно идет. Отправлено с iPhone > 22 янв. 2019 г., в 09:29, Dmitriy Lyalyuev написал(а): > > Если коротко, то - https://serverfault.com/questions/598202/make-nginx-to-pass-hostname-of-the-upstream-when-reverseproxying > > Второй ответ в треде. > Но сама схема, как по мне, выглядит костылем. Костылем и лечить. > > -- > With best regards, > Dmitriy Lyalyuev > dmitriy на lyalyuev.info > > > >> On Jan 22, 2019, at 08:54, CoDDoC via nginx-ru wrote: >> >> Доброе время суток! >> >> Тестовый сервер: test.local. В нем тестовый кластер: >> upstream cdn { >> server :; >> server :; >> .... >> } >> >> или: >> upstream cdn { >> server cdn001.test.local:; >> server cdn002.test.local:; >> .... >> } >> >> Не принципиально, ибо "cdn001.test.local" резолвится в и т.д. >> >> Само собой, "proxy_http_version 1.1;" и из какого-то локейшена "proxy_pass http://cdn;" >> Теперь смотрю, что приходит, например, на выбранный бэкенд. >> Ожидаю там увидеть в заголовке Host значение или 'cdn###.test.local'. >> Вижу: http header: "Host: cdn". Что не так? >> >> Входящий контроль проверяет правильность заголовка Host. >> Все, что не соответствуют разрешенным, посылаются на 400. Можно, конечно, добавить фильтрацию по белому списку, что-то типа "такой-то IP должен прислать такой-то заголовок". Но (ИМХО) костыль. >> >> proxy_set_header 'Host' $upstream_addr; - бесполезно. >> $upstream_addr получает значение ПОСЛЕ proxy_pass. >> >> Попутно вопрос о $upstream_addr. >> Ее можно еще как-то использовать, кроме как в логах? Например, отправить в php, но без костылей? >> >> Спасибо. >> -- >> _______________________________________________ >> 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 Tue Jan 22 14:31:37 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 22 Jan 2019 17:31:37 +0300 Subject: =?UTF-8?B?UmU6IFVwc3RyZWFtINC4INC30LDQs9C+0LvQvtCy0L7QuiBIb3N0?= In-Reply-To: <1548140052.359264467@f416.i.mail.ru> References: <1548140052.359264467@f416.i.mail.ru> Message-ID: <20190122143136.GD1877@mdounin.ru> Hello! On Tue, Jan 22, 2019 at 09:54:12AM +0300, CoDDoC via nginx-ru wrote: > Доброе время суток! > > Тестовый сервер: test.local. В нем тестовый кластер: > upstream cdn { >     server :; >     server :; >     .... > } > > или: > upstream cdn { >     server cdn001.test.local:; >     server cdn002.test.local:; >     .... > } > > Не принципиально, ибо "cdn001.test.local" резолвится в и т.д. > > Само собой, "proxy_http_version 1.1;" и из какого-то локейшена "proxy_pass http://cdn;" > Теперь смотрю, что приходит, например, на выбранный бэкенд. > Ожидаю там увидеть в заголовке Host значение или 'cdn###.test.local'. > Вижу: http header: "Host: cdn". Что не так? А можно вопрос - почему вы ожидаете увидеть в заголовке Host " или 'cdn###.test.local'"? Документация по данному вопросу однозначна, да и, скажем, прописывая в DNS соответствующие A или CNAME-записи никто не ожидает, что в запросах будет заголовок Host, соответствующий содержимому записи. Почему от блоков upstream вдруг ожидается какое-то другое поведение? На всякий случай уточню - вопрос вполне серьёзный, хочется понять, на какие аналогии опираются люди, считающие, что заголовок Host должен зависеть от того, на какой IP-адрес из списка был отправлен запрос. Вроде бы аналогия с DNS очевидна, и она подразумевает именно именно то поведение, которое есть сейчас, но почему-то людей, предполагающих другое поведение, много. [...] > Попутно вопрос о $upstream_addr. > Ее можно еще как-то использовать, кроме как в логах? Например, отправить в php, но без костылей? Нет. Запрос формируется до выбора бэкенда, на который этот запрос будет отправлен (а в рамках proxy_next_upstream - один и тот же запрос может быть отправлен на несколько бэкендов). Соотвественно переменную $upstream_addr можно использовать в логах (а равно при обработке ответа бэкенда - скажем, в add_header), но бессмысленно использовать в запросе на бэкенд - на момент формирования запроса она всегда будет пустой. -- Maxim Dounin http://mdounin.ru/ From vas на mpeks.tomsk.su Tue Jan 22 17:23:57 2019 From: vas на mpeks.tomsk.su (Victor Sudakov) Date: Wed, 23 Jan 2019 00:23:57 +0700 Subject: =?UTF-8?B?ZmNnaXdyYXAg0L3QtSDQvNC+0LPRgyDQt9Cw0L/Rg9GB0YLQuNGC0Yw=?= Message-ID: <20190122172357.GA85220@admin.sibptus.ru> Коллеги, снимите с ручника пожалуйста, что не так? nginx (FreeBSD 11.2, nginx-1.14.1_1,2) при обращении к /cgi-bin/test возвращает "403 Forbidden". Самое странное, что в error.log по этому поводу ничего не пишется. В access.log есть совершенно неинформативное 2001:470:35:7af::2 - - [22/Jan/2019:23:37:46 +0700] "GET /cgi-bin/test HTTP/1.1" 403 25 "-" "Mozilla/5.0 (X11; FreeBSD amd64; rv:64.0) Gecko/20100101 Firefox/64.0" Чего ему не хватает? И как хотя бы включить ошибки в error.log? nginx.conf: location /cgi-bin/ { root /usr/local/www/cgi-bin; include /usr/local/etc/nginx/fastcgi_params; fastcgi_pass unix:/tmp/fcgiwrap.socket; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } # ls -al /tmp/fcgiwrap.socket srw------- 1 www wheel 0 22 янв. 23:33 /tmp/fcgiwrap.socket rc.conf.local: fcgiwrap_enable="YES" fcgiwrap_socket_owner="www" fcgiwrap_user="www" fcgiwrap_socket="unix:/tmp/fcgiwrap.socket" fcgiwrap_socket_mode="0600" # ls -al /usr/local/www/cgi-bin total 12 drwxr-xr-x 2 root wheel 512 22 янв. 22:58 . drwxr-xr-x 4 root wheel 512 22 янв. 22:56 .. -rwxr-xr-x 1 root wheel 103 22 янв. 22:58 test # ps axwwu | grep cgi www 85035 0,0 0,1 6388 1808 - Is 00:11 0:00,00 daemon: /usr/local/sbin/fcgiwrap[85037] (daemon) www 85037 0,0 0,1 6356 1832 - I 00:11 0:00,00 /usr/local/sbin/fcgiwrap -s unix:/tmp/fcgiwrap.socket Если сказать su -m www -c 'telnet /tmp/fcgiwrap.socket' то соединяется с fastcgi-сервером (я правда не знаю, какую команду там сказать можно, но права доступа к сокету у www явно есть). -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49 на fidonet http://vas.tomsk.ru/ From vas на mpeks.tomsk.su Tue Jan 22 18:02:01 2019 From: vas на mpeks.tomsk.su (Victor Sudakov) Date: Wed, 23 Jan 2019 01:02:01 +0700 Subject: =?UTF-8?B?UmU6IGZjZ2l3cmFwINC90LUg0LzQvtCz0YMg0LfQsNC/0YPRgdGC0LjRgtGM?= In-Reply-To: <20190122172357.GA85220@admin.sibptus.ru> References: <20190122172357.GA85220@admin.sibptus.ru> Message-ID: <20190122180201.GA85748@admin.sibptus.ru> Victor Sudakov wrote: > > > Если сказать > su -m www -c 'telnet /tmp/fcgiwrap.socket' > то соединяется с fastcgi-сервером (я правда не знаю, какую команду там > сказать можно, но права доступа к сокету у www явно есть). FastCGI server сам по себе однако работает: # ~/bin/debug_cgi.sh + SCRIPT_FILENAME=/usr/local/www/cgi-bin/test + export SCRIPT_FILENAME + REQUEST_URI=/test + export REQUEST_URI + REQUEST_METHOD=GET + export REQUEST_METHOD + su -m www -c '/usr/local/bin/cgi-fcgi -bind -connect /tmp/fcgiwrap.socket' Content-type: text/plain This is a test script This is a test script This is a test script This is a test script This is a test script This is a test script This is a test script -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49 на fidonet http://vas.tomsk.ru/ From vas на mpeks.tomsk.su Wed Jan 23 08:36:23 2019 From: vas на mpeks.tomsk.su (Victor Sudakov) Date: Wed, 23 Jan 2019 15:36:23 +0700 Subject: =?UTF-8?B?UmU6IGZjZ2l3cmFwINC90LUg0LzQvtCz0YMg0LfQsNC/0YPRgdGC0LjRgtGM?= In-Reply-To: <20190122180201.GA85748@admin.sibptus.ru> References: <20190122172357.GA85220@admin.sibptus.ru> <20190122180201.GA85748@admin.sibptus.ru> Message-ID: <20190123083623.GA93836@admin.sibptus.ru> fcgiwrap с ключом -f маленько прояснил ситуацию, имею теперь сообщение об ошибке в логе nginx: 2019/01/23 15:29:36 [error] 93721#100134: *5 FastCGI sent in stderr: "Cannot get script name, are DOCUMENT_ROOT and SCRIPT_NAME (or SCRIPT_FILENAME) set and is the script executable?" while reading response header from upstream, client: 10.10.10.3, server: , request: "GET /cgi-bin/test HTTP/1.1", upstream: "fastcgi://unix:/tmp/fcgiwrap.socket:", host: "admin.sibptus.ru" С учетом нижепоказанного, чего ещё недостаёт? location /cgi-bin/ { root /usr/local/www/cgi-bin; include /usr/local/etc/nginx/fastcgi_params; fastcgi_pass unix:/tmp/fcgiwrap.socket; } $ egrep 'DOCUMENT_ROOT|SCRIPT_NAME' /usr/local/etc/nginx/fastcgi_params fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_param DOCUMENT_ROOT $document_root; $ ls -al /usr/local/www/cgi-bin total 12 drwxr-xr-x 2 root wheel 512 23 янв. 00:58 . drwxr-xr-x 4 root wheel 512 22 янв. 22:56 .. -rwxr-xr-x 1 root wheel 313 23 янв. 00:58 test -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49 на fidonet http://vas.tomsk.ru/ From constantine на mellodesign.ru Wed Jan 23 09:19:16 2019 From: constantine на mellodesign.ru (=?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=) Date: Wed, 23 Jan 2019 13:19:16 +0400 Subject: =?UTF-8?B?UmU6IGZjZ2l3cmFwINC90LUg0LzQvtCz0YMg0LfQsNC/0YPRgdGC0LjRgtGM?= In-Reply-To: <20190123083623.GA93836@admin.sibptus.ru> References: <20190122172357.GA85220@admin.sibptus.ru> <20190122180201.GA85748@admin.sibptus.ru> <20190123083623.GA93836@admin.sibptus.ru> Message-ID: Здравствуйте! Владельца для /usr/local/www/cgi-bin/test пробовали ставить в www? Понятно, что есть чтение, но меня смущает эта директива fcgiwrap_user="www" ср, 23 янв. 2019 г. в 12:36, Victor Sudakov : > fcgiwrap с ключом -f маленько прояснил ситуацию, имею теперь сообщение > об ошибке в логе nginx: > > 2019/01/23 15:29:36 [error] 93721#100134: *5 FastCGI sent in stderr: > "Cannot get script name, are DOCUMENT_ROOT and SCRIPT_NAME (or > SCRIPT_FILENAME) set and is the script executable?" while reading response > header from upstream, client: 10.10.10.3, server: , request: "GET > /cgi-bin/test HTTP/1.1", upstream: "fastcgi://unix:/tmp/fcgiwrap.socket:", > host: "admin.sibptus.ru" > > С учетом нижепоказанного, чего ещё недостаёт? > > location /cgi-bin/ { > root /usr/local/www/cgi-bin; > include /usr/local/etc/nginx/fastcgi_params; > fastcgi_pass unix:/tmp/fcgiwrap.socket; > } > > > $ egrep 'DOCUMENT_ROOT|SCRIPT_NAME' /usr/local/etc/nginx/fastcgi_params > fastcgi_param SCRIPT_NAME $fastcgi_script_name; > fastcgi_param DOCUMENT_ROOT $document_root; > > $ ls -al /usr/local/www/cgi-bin > total 12 > drwxr-xr-x 2 root wheel 512 23 янв. 00:58 . > drwxr-xr-x 4 root wheel 512 22 янв. 22:56 .. > -rwxr-xr-x 1 root wheel 313 23 янв. 00:58 test > > > > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > 2:5005/49 на fidonet http://vas.tomsk.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Константин! ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bmp.line на gmail.com Wed Jan 23 09:44:08 2019 From: bmp.line на gmail.com (MazalTov Tov) Date: Wed, 23 Jan 2019 11:44:08 +0200 Subject: =?UTF-8?B?UmU6INCU0LDQudC00LbQtdGB0YIg0YHQv9C40YHQutCwINGA0LDRgdGB0YvQu9C6?= =?UTF-8?B?0LggbmdpbngtcnU7INGC0L7QvCAxMTEsINCy0YvQv9GD0YHQuiAxOQ==?= In-Reply-To: References: Message-ID: Отписаться ср, 23 янв. 2019 г. в 11:15, : > Сообщения, предназначенные для списка > рассылки nginx-ru, отправляйте по адресу > nginx-ru на nginx.org > > Для изменения параметров подписки или > отписки используйте веб-страницу > http://mailman.nginx.org/mailman/listinfo/nginx-ru > или отправьте письмо, в теле или теме > которого будет слово 'help', по адресу > nginx-ru-request на nginx.org > > Адрес администратора этого списка > рассылки: > nginx-ru-owner на nginx.org > > При ответе, пожалуйста, измените тему > письма на более содержательную чем "Re: > Содержание дайджеста списка рассылки > nginx-ru..." > В этом номере: > > 1. Re: Upstream и заголовок Host (Alex Tkachuk) > 2. Re: Upstream и заголовок Host (Maxim Dounin) > 3. fcgiwrap не могу запустить (Victor Sudakov) > 4. Re: fcgiwrap не могу запустить (Victor Sudakov) > 5. Re: fcgiwrap не могу запустить (Victor Sudakov) > > > > ---------- Forwarded message ---------- > From: Alex Tkachuk > To: nginx-ru на nginx.org > Cc: > Bcc: > Date: Tue, 22 Jan 2019 14:28:50 +0200 > Subject: Re: Upstream и заголовок Host > В линуксе есть какой-то прикол с резолвом .local доменов. Гляньте на > /etc/nsswitch.conf. Там определяется очередность служб для резолва адресов. > Для .local оно как-то отдельно идет. > > Отправлено с iPhone > > 22 янв. 2019 г., в 09:29, Dmitriy Lyalyuev > написал(а): > > Если коротко, то - > https://serverfault.com/questions/598202/make-nginx-to-pass-hostname-of-the-upstream-when-reverseproxying > > Второй ответ в треде. > Но сама схема, как по мне, выглядит костылем. Костылем и лечить. > > -- > With best regards, > Dmitriy Lyalyuev > dmitriy на lyalyuev.info > > > > On Jan 22, 2019, at 08:54, CoDDoC via nginx-ru wrote: > > Доброе время суток! > > Тестовый сервер: test.local. В нем тестовый кластер: > upstream cdn { > server :; > server :; > .... > } > > или: > upstream cdn { > server cdn001.test.local:; > server cdn002.test.local:; > .... > } > > Не принципиально, ибо "cdn001.test.local" резолвится в и т.д. > > Само собой, "proxy_http_version 1.1;" и из какого-то локейшена "proxy_pass > http://cdn;" > Теперь смотрю, что приходит, например, на выбранный бэкенд. > Ожидаю там увидеть в заголовке Host значение или 'cdn###.test.local'. > Вижу: http header: "Host: cdn". Что не так? > > Входящий контроль проверяет правильность заголовка Host. > Все, что не соответствуют разрешенным, посылаются на 400. Можно, конечно, > добавить фильтрацию по белому списку, что-то типа "такой-то IP должен > прислать такой-то заголовок". Но (ИМХО) костыль. > > proxy_set_header 'Host' $upstream_addr; - бесполезно. > $upstream_addr получает значение ПОСЛЕ proxy_pass. > > Попутно вопрос о $upstream_addr. > Ее можно еще как-то использовать, кроме как в логах? Например, отправить в > php, но без костылей? > > Спасибо. > -- > _______________________________________________ > 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 > > > > > ---------- Forwarded message ---------- > From: Maxim Dounin > To: CoDDoC via nginx-ru > Cc: > Bcc: > Date: Tue, 22 Jan 2019 17:31:37 +0300 > Subject: Re: Upstream и заголовок Host > Hello! > > On Tue, Jan 22, 2019 at 09:54:12AM +0300, CoDDoC via nginx-ru wrote: > > > Доброе время суток! > > > > Тестовый сервер: test.local. В нем тестовый кластер: > > upstream cdn { > > server :; > > server :; > > .... > > } > > > > или: > > upstream cdn { > > server cdn001.test.local:; > > server cdn002.test.local:; > > .... > > } > > > > Не принципиально, ибо "cdn001.test.local" резолвится в и т.д. > > > > Само собой, "proxy_http_version 1.1;" и из какого-то локейшена > "proxy_pass http://cdn;" > > Теперь смотрю, что приходит, например, на выбранный бэкенд. > > Ожидаю там увидеть в заголовке Host значение или > 'cdn###.test.local'. > > Вижу: http header: "Host: cdn". Что не так? > > А можно вопрос - почему вы ожидаете увидеть в заголовке Host > " или 'cdn###.test.local'"? > > Документация по данному вопросу однозначна, да и, скажем, > прописывая в DNS соответствующие A или CNAME-записи никто не > ожидает, что в запросах будет заголовок Host, соответствующий > содержимому записи. > > Почему от блоков upstream вдруг ожидается какое-то другое > поведение? > > На всякий случай уточню - вопрос вполне серьёзный, хочется > понять, на какие аналогии опираются люди, считающие, что заголовок > Host должен зависеть от того, на какой IP-адрес из списка был > отправлен запрос. Вроде бы аналогия с DNS очевидна, и она > подразумевает именно именно то поведение, которое есть сейчас, но > почему-то людей, предполагающих другое поведение, много. > > [...] > > > Попутно вопрос о $upstream_addr. > > Ее можно еще как-то использовать, кроме как в логах? Например, отправить > в php, но без костылей? > > Нет. Запрос формируется до выбора бэкенда, на который этот запрос > будет отправлен (а в рамках proxy_next_upstream - один и тот же > запрос может быть отправлен на несколько бэкендов). Соотвественно > переменную $upstream_addr можно использовать в логах (а равно при > обработке ответа бэкенда - скажем, в add_header), но бессмысленно > использовать в запросе на бэкенд - на момент формирования запроса > она всегда будет пустой. > > -- > Maxim Dounin > http://mdounin.ru/ > > > > > ---------- Forwarded message ---------- > From: Victor Sudakov > To: nginx-ru на nginx.org > Cc: > Bcc: > Date: Wed, 23 Jan 2019 00:23:57 +0700 > Subject: fcgiwrap не могу запустить > Коллеги, снимите с ручника пожалуйста, что не так? > > nginx (FreeBSD 11.2, nginx-1.14.1_1,2) при обращении к /cgi-bin/test > возвращает "403 Forbidden". Самое странное, что в error.log по этому > поводу ничего не пишется. В access.log есть совершенно неинформативное > > 2001:470:35:7af::2 - - [22/Jan/2019:23:37:46 +0700] "GET /cgi-bin/test > HTTP/1.1" 403 25 "-" "Mozilla/5.0 (X11; FreeBSD amd64; rv:64.0) > Gecko/20100101 Firefox/64.0" > > Чего ему не хватает? И как хотя бы включить ошибки в error.log? > > nginx.conf: > > location /cgi-bin/ { > root /usr/local/www/cgi-bin; > include /usr/local/etc/nginx/fastcgi_params; > fastcgi_pass unix:/tmp/fcgiwrap.socket; > fastcgi_param SCRIPT_FILENAME > $document_root$fastcgi_script_name; > } > > > # ls -al /tmp/fcgiwrap.socket > srw------- 1 www wheel 0 22 янв. 23:33 /tmp/fcgiwrap.socket > > > rc.conf.local: > > fcgiwrap_enable="YES" > fcgiwrap_socket_owner="www" > fcgiwrap_user="www" > fcgiwrap_socket="unix:/tmp/fcgiwrap.socket" > fcgiwrap_socket_mode="0600" > > > # ls -al /usr/local/www/cgi-bin > total 12 > drwxr-xr-x 2 root wheel 512 22 янв. 22:58 . > drwxr-xr-x 4 root wheel 512 22 янв. 22:56 .. > -rwxr-xr-x 1 root wheel 103 22 янв. 22:58 test > > # ps axwwu | grep cgi > www 85035 0,0 0,1 6388 1808 - Is 00:11 0:00,00 > daemon: /usr/local/sbin/fcgiwrap[85037] (daemon) > www 85037 0,0 0,1 6356 1832 - I 00:11 0:00,00 > /usr/local/sbin/fcgiwrap -s unix:/tmp/fcgiwrap.socket > > > Если сказать > su -m www -c 'telnet /tmp/fcgiwrap.socket' > то соединяется с fastcgi-сервером (я правда не знаю, какую команду там > сказать можно, но права доступа к сокету у www явно есть). > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > 2:5005/49 на fidonet http://vas.tomsk.ru/ > > > > > ---------- Forwarded message ---------- > From: Victor Sudakov > To: nginx-ru на nginx.org > Cc: > Bcc: > Date: Wed, 23 Jan 2019 01:02:01 +0700 > Subject: Re: fcgiwrap не могу запустить > Victor Sudakov wrote: > > > > > > Если сказать > > su -m www -c 'telnet /tmp/fcgiwrap.socket' > > то соединяется с fastcgi-сервером (я правда не знаю, какую команду там > > сказать можно, но права доступа к сокету у www явно есть). > > FastCGI server сам по себе однако работает: > > # ~/bin/debug_cgi.sh > + SCRIPT_FILENAME=/usr/local/www/cgi-bin/test > + export SCRIPT_FILENAME > + REQUEST_URI=/test > + export REQUEST_URI > + REQUEST_METHOD=GET > + export REQUEST_METHOD > + su -m www -c '/usr/local/bin/cgi-fcgi -bind -connect > /tmp/fcgiwrap.socket' > Content-type: text/plain > > This is a test script > This is a test script > This is a test script > This is a test script > This is a test script > This is a test script > This is a test script > > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > 2:5005/49 на fidonet http://vas.tomsk.ru/ > > > > > ---------- Forwarded message ---------- > From: Victor Sudakov > To: nginx-ru на nginx.org > Cc: > Bcc: > Date: Wed, 23 Jan 2019 15:36:23 +0700 > Subject: Re: fcgiwrap не могу запустить > fcgiwrap с ключом -f маленько прояснил ситуацию, имею теперь сообщение > об ошибке в логе nginx: > > 2019/01/23 15:29:36 [error] 93721#100134: *5 FastCGI sent in stderr: > "Cannot get script name, are DOCUMENT_ROOT and SCRIPT_NAME (or > SCRIPT_FILENAME) set and is the script executable?" while reading response > header from upstream, client: 10.10.10.3, server: , request: "GET > /cgi-bin/test HTTP/1.1", upstream: "fastcgi://unix:/tmp/fcgiwrap.socket:", > host: "admin.sibptus.ru" > > С учетом нижепоказанного, чего ещё недостаёт? > > location /cgi-bin/ { > root /usr/local/www/cgi-bin; > include /usr/local/etc/nginx/fastcgi_params; > fastcgi_pass unix:/tmp/fcgiwrap.socket; > } > > > $ egrep 'DOCUMENT_ROOT|SCRIPT_NAME' /usr/local/etc/nginx/fastcgi_params > fastcgi_param SCRIPT_NAME $fastcgi_script_name; > fastcgi_param DOCUMENT_ROOT $document_root; > > $ ls -al /usr/local/www/cgi-bin > total 12 > drwxr-xr-x 2 root wheel 512 23 янв. 00:58 . > drwxr-xr-x 4 root wheel 512 22 янв. 22:56 .. > -rwxr-xr-x 1 root wheel 313 23 янв. 00:58 test > > > > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > 2:5005/49 на fidonet http://vas.tomsk.ru/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vas на mpeks.tomsk.su Wed Jan 23 13:42:09 2019 From: vas на mpeks.tomsk.su (Victor Sudakov) Date: Wed, 23 Jan 2019 20:42:09 +0700 Subject: =?UTF-8?B?UmU6IGZjZ2l3cmFwINC90LUg0LzQvtCz0YMg0LfQsNC/0YPRgdGC0LjRgtGM?= In-Reply-To: References: <20190122172357.GA85220@admin.sibptus.ru> <20190122180201.GA85748@admin.sibptus.ru> <20190123083623.GA93836@admin.sibptus.ru> Message-ID: <20190123134209.GA96343@admin.sibptus.ru> Константин Ткаченко wrote: > > 2019/01/23 15:29:36 [error] 93721#100134: *5 FastCGI sent in stderr: "Cannot get script name, are DOCUMENT_ROOT and SCRIPT_NAME (or SCRIPT_FILENAME) set and is the script executable?" while reading response header from upstream, client: 10.10.10.3, server: , request: "GET /cgi-bin/test HTTP/1.1", upstream: "fastcgi://unix:/tmp/fcgiwrap.socket:", host: "admin.sibptus.ru" > Владельца для /usr/local/www/cgi-bin/test пробовали ставить в www? > Понятно, что есть чтение, но меня смущает эта директива fcgiwrap_user="www" Нет, права и владельцы тут ни при чём, дело в другом. Путь к скрипту задаётся (передаётся в fcgiwrap) склеиванием двух переменных: SCRIPT_NAME и DOCUMENT_ROOT, которые получаются из $fastcgi_script_name и $document_root соответственно. По умолчанию $fastcgi_script_name=$request_uri, то есть при моей конфигурации > > location /cgi-bin/ { > > root /usr/local/www/cgi-bin; > > include /usr/local/etc/nginx/fastcgi_params; > > fastcgi_pass unix:/tmp/fcgiwrap.socket; > > } путь к cgi-скрипту получался "/usr/local/www/cgi-bin/cgi-bin/test", понятно что такого пути нет. Поэтому надо было или урезать root до "/usr/local/www", или задать свой $fastcgi_split_path_info, который бы переопределил $fastcgi_script_name, отрезав от "/cgi-bin/test" только последнюю компоненту. Спасибо Иван за верную наводку. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49 на fidonet http://vas.tomsk.ru/ From vas на mpeks.tomsk.su Thu Jan 24 15:31:35 2019 From: vas на mpeks.tomsk.su (Victor Sudakov) Date: Thu, 24 Jan 2019 22:31:35 +0700 Subject: =?UTF-8?B?UmU6IGZjZ2l3cmFwINC90LUg0LzQvtCz0YMg0LfQsNC/0YPRgdGC0LjRgtGM?= In-Reply-To: <20190123134209.GA96343@admin.sibptus.ru> References: <20190122172357.GA85220@admin.sibptus.ru> <20190122180201.GA85748@admin.sibptus.ru> <20190123083623.GA93836@admin.sibptus.ru> <20190123134209.GA96343@admin.sibptus.ru> Message-ID: <20190124153135.GA10022@admin.sibptus.ru> Victor Sudakov wrote: > > > 2019/01/23 15:29:36 [error] 93721#100134: *5 FastCGI sent in stderr: "Cannot get script name, are DOCUMENT_ROOT and SCRIPT_NAME (or SCRIPT_FILENAME) set and is the script executable?" while reading response header from upstream, client: 10.10.10.3, server: , request: "GET /cgi-bin/test HTTP/1.1", upstream: "fastcgi://unix:/tmp/fcgiwrap.socket:", host: "admin.sibptus.ru" Не поленился изложить для памяти и Гугла: https://victor-sudakov.dreamwidth.org/463780.html -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49 на fidonet http://vas.tomsk.ru/ From nginx на kinetiksoft.com Thu Jan 24 15:52:08 2019 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Thu, 24 Jan 2019 18:52:08 +0300 Subject: =?UTF-8?B?UmU6IGZjZ2l3cmFwINC90LUg0LzQvtCz0YMg0LfQsNC/0YPRgdGC0LjRgtGM?= In-Reply-To: <20190124153135.GA10022@admin.sibptus.ru> References: <20190122172357.GA85220@admin.sibptus.ru> <20190122180201.GA85748@admin.sibptus.ru> <20190123083623.GA93836@admin.sibptus.ru> <20190123134209.GA96343@admin.sibptus.ru> <20190124153135.GA10022@admin.sibptus.ru> Message-ID: <25ea9528-ecae-0665-b7ab-d9ee09bebf03@kinetiksoft.com> Ну вообще я же не телепатически эту инфу получил. Всё достаточно понятно написано в https://nginx.org/ru/docs/http/ngx_http_core_module.html#root : "Путь к файлу формируется путём простого добавления URI к значению директивы |root|." 24.01.2019 18:31, Victor Sudakov пишет: > Victor Sudakov wrote: >>>> 2019/01/23 15:29:36 [error] 93721#100134: *5 FastCGI sent in stderr: "Cannot get script name, are DOCUMENT_ROOT and SCRIPT_NAME (or SCRIPT_FILENAME) set and is the script executable?" while reading response header from upstream, client: 10.10.10.3, server: , request: "GET /cgi-bin/test HTTP/1.1", upstream: "fastcgi://unix:/tmp/fcgiwrap.socket:", host: "admin.sibptus.ru" > Не поленился изложить для памяти и Гугла: https://victor-sudakov.dreamwidth.org/463780.html > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vas на mpeks.tomsk.su Fri Jan 25 09:13:13 2019 From: vas на mpeks.tomsk.su (Victor Sudakov) Date: Fri, 25 Jan 2019 16:13:13 +0700 Subject: =?UTF-8?B?UmU6IGZjZ2l3cmFwINC90LUg0LzQvtCz0YMg0LfQsNC/0YPRgdGC0LjRgtGM?= In-Reply-To: <25ea9528-ecae-0665-b7ab-d9ee09bebf03@kinetiksoft.com> References: <20190122172357.GA85220@admin.sibptus.ru> <20190122180201.GA85748@admin.sibptus.ru> <20190123083623.GA93836@admin.sibptus.ru> <20190123134209.GA96343@admin.sibptus.ru> <20190124153135.GA10022@admin.sibptus.ru> <25ea9528-ecae-0665-b7ab-d9ee09bebf03@kinetiksoft.com> Message-ID: <20190125091313.GA21257@admin.sibptus.ru> Иван wrote: > Ну вообще я же не телепатически эту инфу получил. Всё достаточно понятно > написано в https://nginx.org/ru/docs/http/ngx_http_core_module.html#root : > > "Путь к файлу формируется путём простого добавления URI к значению > директивы |root|." Что касается отдачи статики, то понятно что понятно. А в fastcgi передаются две переменные, DOCUMENT_ROOT и SCRIPT_NAME, и пока я не осознал, что SCRIPT_NAME равен REQUEST_URI целиком (а не только его последней компоненте, как я ошибочно полагал), ничего и не работало. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49 на fidonet http://vas.tomsk.ru/ From nginx на kinetiksoft.com Fri Jan 25 09:22:45 2019 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Fri, 25 Jan 2019 12:22:45 +0300 Subject: =?UTF-8?B?UmU6IGZjZ2l3cmFwINC90LUg0LzQvtCz0YMg0LfQsNC/0YPRgdGC0LjRgtGM?= In-Reply-To: <20190125091313.GA21257@admin.sibptus.ru> References: <20190122172357.GA85220@admin.sibptus.ru> <20190122180201.GA85748@admin.sibptus.ru> <20190123083623.GA93836@admin.sibptus.ru> <20190123134209.GA96343@admin.sibptus.ru> <20190124153135.GA10022@admin.sibptus.ru> <25ea9528-ecae-0665-b7ab-d9ee09bebf03@kinetiksoft.com> <20190125091313.GA21257@admin.sibptus.ru> Message-ID: SCRIPT_NAME равен тому, чему его вы приравняете (по умолчанию) fastcgi_params:fastcgi_param SCRIPT_NAME $fastcgi_script_name; которая в свою очередь описана https://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#var_fastcgi_script_name 25.01.2019 12:13, Victor Sudakov пишет: > Иван wrote: >> Ну вообще я же не телепатически эту инфу получил. Всё достаточно понятно >> написано в https://nginx.org/ru/docs/http/ngx_http_core_module.html#root : >> >> "Путь к файлу формируется путём простого добавления URI к значению >> директивы |root|." > Что касается отдачи статики, то понятно что понятно. А в fastcgi > передаются две переменные, DOCUMENT_ROOT и SCRIPT_NAME, и пока я не > осознал, что SCRIPT_NAME равен REQUEST_URI целиком (а не только его > последней компоненте, как я ошибочно полагал), ничего и не работало. > From thresh на nginx.com Wed Jan 30 10:19:22 2019 From: thresh на nginx.com (Konstantin Pavlov) Date: Wed, 30 Jan 2019 13:19:22 +0300 Subject: =?UTF-8?B?0J/QsNC60LXRgtGLINC00LvRjyBMaW51eDog0LTQvtCx0LDQstC70LXQvSBBbHBp?= =?UTF-8?B?bmUgTGludXg=?= Message-ID: Привет, В рамках наших постоянных усилий по внедрению поддержки новых платформ и операционных систем для nginx, бинарные пакеты от nginx.org теперь доступны и для Alpine Linux. Прочитать о том, как настраивать репозиторий и устанавливать пакеты можно на https://nginx.org/ru/linux_packages.html#Alpine. Исходные коды средств пакетирования доступны на http://hg.nginx.org/pkg-oss/file/default/alpine. Хорошего дня, -- Konstantin Pavlov https://www.nginx.com/