From b1os на bk.ru Wed Mar 1 11:33:09 2017 From: b1os на bk.ru (=?UTF-8?B?QW5kcmV5IEVuc2hpbg==?=) Date: Wed, 01 Mar 2017 14:33:09 +0300 Subject: =?UTF-8?B?0KPRgdGC0LDQvdC+0LLQutCwINC/0YDQvtC40LfQstC+0LvRjNC90YvRhSDQt9Cw?= =?UTF-8?B?0LPQvtC70L7QstC60L7QsiDQv9GA0LggWC1BY2NlbC1SZWRpcmVjdA==?= Message-ID: <1488367988.309459534@f123.i.mail.ru> Привет! Приходит пользователь с запросом в nginx, который upstream'ит это в мой скрипт. Я отдаю ответ и выставлю заголовки, среди которых есть: X-Accel-Redirect и Foo-Bar . Nginx при ответе реагирует на X-Accel-Redirect и proxy_pass'ит в другой скрипт, откуда выкачивается файл и отдаётся пользователю. Я хочу, чтобы пользователь получать Foo-Bar. По ссылке конфиг(часть я выпилил, но необходимое для понимания оставил). Там видны мои попытки отловить Foo-Bar http://paste.org.ru/?it7v8z   Хотелось бы понять возможно ли это и если да, то как? -- Андрей Еньшин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Mar 1 11:48:32 2017 From: nginx-forum на forum.nginx.org (Dothris) Date: Wed, 01 Mar 2017 06:48:32 -0500 Subject: =?UTF-8?Q?basic-auth_=D0=B8_Geo?= Message-ID: <138a7038f80a4487c073d8b206160f11.NginxMailingListRussian@forum.nginx.org> Привет всем! Скажите пожалуйста, можно ли сделать такую конструкцию? Если нет, то как сделать так чтобы для клиентов с сети 10.0.0.0/8 basic-auth не запрашивалась, а для всех остальных запрашивалась? Заранее спасибо geo $developers_ip { default 1; 10.0.0.0/8 0; } server { listen 80; server_name xxxxxxxxxxx; if ($developers_ip) { auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.pass; } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272677,272677#msg-272677 From mdounin на mdounin.ru Wed Mar 1 11:54:14 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 1 Mar 2017 14:54:14 +0300 Subject: =?UTF-8?Q?Re=3A_basic-auth_=D0=B8_Geo?= In-Reply-To: <138a7038f80a4487c073d8b206160f11.NginxMailingListRussian@forum.nginx.org> References: <138a7038f80a4487c073d8b206160f11.NginxMailingListRussian@forum.nginx.org> Message-ID: <20170301115414.GP34777@mdounin.ru> Hello! On Wed, Mar 01, 2017 at 06:48:32AM -0500, Dothris wrote: > Привет всем! > Скажите пожалуйста, можно ли сделать такую конструкцию? > Если нет, то как сделать так чтобы для клиентов с сети 10.0.0.0/8 basic-auth > не запрашивалась, а для всех остальных запрашивалась? > Заранее спасибо > > geo $developers_ip { > default 1; > 10.0.0.0/8 0; > } > > server { > listen 80; > server_name xxxxxxxxxxx; > > if ($developers_ip) { > auth_basic "Restricted"; > auth_basic_user_file /etc/nginx/.pass; > } Правильно так: satisfy any; allow 10.0.0.0/8; deny all; auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.pass; Подробнее в описании директивы satisfy, http://nginx.org/r/satisfy/ru. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Wed Mar 1 13:02:04 2017 From: nginx-forum на forum.nginx.org (Dothris) Date: Wed, 01 Mar 2017 08:02:04 -0500 Subject: =?UTF-8?Q?Re=3A_basic-auth_=D0=B8_Geo?= In-Reply-To: <138a7038f80a4487c073d8b206160f11.NginxMailingListRussian@forum.nginx.org> References: <138a7038f80a4487c073d8b206160f11.NginxMailingListRussian@forum.nginx.org> Message-ID: <02821962309ecb5df292c285e677c651.NginxMailingListRussian@forum.nginx.org> Ответ satisfy any; allow 10.0.0.0/8; deny all; auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.pass; Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272677,272682#msg-272682 From nginx-forum на forum.nginx.org Wed Mar 1 13:02:27 2017 From: nginx-forum на forum.nginx.org (Dothris) Date: Wed, 01 Mar 2017 08:02:27 -0500 Subject: =?UTF-8?Q?Re=3A_basic-auth_=D0=B8_Geo?= In-Reply-To: <02821962309ecb5df292c285e677c651.NginxMailingListRussian@forum.nginx.org> References: <138a7038f80a4487c073d8b206160f11.NginxMailingListRussian@forum.nginx.org> <02821962309ecb5df292c285e677c651.NginxMailingListRussian@forum.nginx.org> Message-ID: <9e69f8c380cccbf2b24ab8a610da1f61.NginxMailingListRussian@forum.nginx.org> Спасибо. я понял Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272677,272683#msg-272683 From nginx-forum на forum.nginx.org Wed Mar 1 16:06:20 2017 From: nginx-forum на forum.nginx.org (syswipe) Date: Wed, 01 Mar 2017 11:06:20 -0500 Subject: =?UTF-8?B?0L/QvtC00YHRgtCw0L3QvtCy0LrQsCDQv9C10YDQtdC80LXQvdC90YvRhSDQsiA=?= =?UTF-8?B?0LjQvNGPINCw0L/RgdGC0YDQuNC80LAu?= Message-ID: <2f4e131e205ead04371192406dc0d463.NginxMailingListRussian@forum.nginx.org> Добрый день! хочется странного, пока не понимаю, как бы это реализовать красивей.есть пачка конфигов, для различных виртуальных хостов. так же есть один общий набор локейшенов, который они все инклюдят. локейшенов очень много, они одинаковые но ведут на разные апстримы в каждом виртхосте. Упрощенно это выглядит следующим образом: VHOST1.conf: upstream upstream_vhost1_backend { server host1; server host2; } server { server vhost1; ... set $upstream_backend upstream_vhost1_backend; include common_config; } VHOST2.conf: upstream upstream_vhost2_backend { server host3; server host4; } server { server vhost2; ... set $upstream_backend upstream_vhost2_backend; include common_config; } в common_config задается соответствующий локейшн: ... location /somelocation { proxy_pass http://$upstream_backend; } тут все хорошо. проблема начинается, когда в common_config нужно задать локейшены следующего вида: location /somelocation/module1/ { proxy_pass http://$upstream_module1; } location /somelocation/module2/ { proxy_pass http://$upstream_module2; } location /somelocation/moduleN/ { proxy_pass http://$upstream_moduleN; } проблема в том, что количество таких схожих локейшенов может расти и хотелось бы конфиг свернуть. хочется получить что-то вроде location ~ ^/somelocation/module(\d+)/ { proxy_pass http://$upstream_module$1; } как это сделать по уму? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272691,272691#msg-272691 From andrey на kopeyko.ru Wed Mar 1 16:17:28 2017 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Wed, 1 Mar 2017 19:17:28 +0300 (MSK) Subject: =?UTF-8?B?UmU6INC/0L7QtNGB0YLQsNC90L7QstC60LAg0L/QtdGA0LXQvNC10L3QvdGL0YUg?= =?UTF-8?B?0LIg0LjQvNGPINCw0L/RgdGC0YDQuNC80LAu?= In-Reply-To: <2f4e131e205ead04371192406dc0d463.NginxMailingListRussian@forum.nginx.org> References: <2f4e131e205ead04371192406dc0d463.NginxMailingListRussian@forum.nginx.org> Message-ID: On Wed, 1 Mar 2017, syswipe wrote: > Добрый день! Добрый день! > хочется странного, пока не понимаю, как бы это реализовать красивей.есть > пачка конфигов, для различных виртуальных хостов. так же есть один общий > набор локейшенов, который они все инклюдят. локейшенов очень много, они > одинаковые но ведут на разные апстримы в каждом виртхосте. ... > проблема в том, что количество таких схожих локейшенов может расти и > хотелось бы конфиг свернуть. ... > как это сделать по уму? Генерите ваш конфиг. ansible и его шаблоны - годный инструмент для этого. -- Best regards, Andrey Kopeyko From nginx-forum на forum.nginx.org Wed Mar 1 16:35:34 2017 From: nginx-forum на forum.nginx.org (syswipe) Date: Wed, 01 Mar 2017 11:35:34 -0500 Subject: =?UTF-8?B?UmU6INC/0L7QtNGB0YLQsNC90L7QstC60LAg0L/QtdGA0LXQvNC10L3QvdGL0YUg?= =?UTF-8?B?0LIg0LjQvNGPINCw0L/RgdGC0YDQuNC80LAu?= In-Reply-To: References: Message-ID: вариант. но в этом случае, если двести виртхостов будут иметь по два локейшена /moduleN, а один - сотню, то в common придется засунуть 100 сгенерированных локейшенов. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272691,272694#msg-272694 From andrey на kopeyko.ru Wed Mar 1 23:13:59 2017 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Thu, 2 Mar 2017 02:13:59 +0300 (MSK) Subject: =?UTF-8?B?UmU6INC/0L7QtNGB0YLQsNC90L7QstC60LAg0L/QtdGA0LXQvNC10L3QvdGL0YUg?= =?UTF-8?B?0LIg0LjQvNGPINCw0L/RgdGC0YDQuNC80LAu?= In-Reply-To: References: Message-ID: On Wed, 1 Mar 2017, syswipe wrote: > вариант. но в этом случае, если двести виртхостов будут иметь по два > локейшена /moduleN, а один - сотню, то в common придется засунуть 100 > сгенерированных локейшенов. нет в этом проблемы, никакой. -- Best regards, Andrey Kopeyko From ru на nginx.com Thu Mar 2 12:17:56 2017 From: ru на nginx.com (Ruslan Ermilov) Date: Thu, 2 Mar 2017 15:17:56 +0300 Subject: =?UTF-8?B?UmU6INC/0L7QtNGB0YLQsNC90L7QstC60LAg0L/QtdGA0LXQvNC10L3QvdGL0YUg?= =?UTF-8?B?0LIg0LjQvNGPINCw0L/RgdGC0YDQuNC80LAu?= In-Reply-To: <2f4e131e205ead04371192406dc0d463.NginxMailingListRussian@forum.nginx.org> References: <2f4e131e205ead04371192406dc0d463.NginxMailingListRussian@forum.nginx.org> Message-ID: <20170302121756.GB64206@lo0.su> On Wed, Mar 01, 2017 at 11:06:20AM -0500, syswipe wrote: > Добрый день! > > хочется странного, пока не понимаю, как бы это реализовать красивей.есть > пачка конфигов, для различных виртуальных хостов. так же есть один общий > набор локейшенов, который они все инклюдят. локейшенов очень много, они > одинаковые но ведут на разные апстримы в каждом виртхосте. Упрощенно это > выглядит следующим образом: > > VHOST1.conf: > > upstream upstream_vhost1_backend { > server host1; > server host2; > } > > server { > server vhost1; > ... > set $upstream_backend upstream_vhost1_backend; > include common_config; > } > > VHOST2.conf: > > upstream upstream_vhost2_backend { > server host3; > server host4; > } > > server { > server vhost2; > ... > set $upstream_backend upstream_vhost2_backend; > include common_config; > } > > в common_config задается соответствующий локейшн: > ... > location /somelocation { > proxy_pass http://$upstream_backend; > } > > тут все хорошо. проблема начинается, когда в common_config нужно задать > локейшены следующего вида: > location /somelocation/module1/ { > proxy_pass http://$upstream_module1; > } > > location /somelocation/module2/ { > proxy_pass http://$upstream_module2; > } > > location /somelocation/moduleN/ { > proxy_pass http://$upstream_moduleN; > } > > проблема в том, что количество таких схожих локейшенов может расти и > хотелось бы конфиг свернуть. > хочется получить что-то вроде > > location ~ ^/somelocation/module(\d+)/ { > proxy_pass http://$upstream_module$1; > } > > как это сделать по уму? При использовании переменных в proxy_pass nginx после раскрытия переменных будет сначала искать среди явно описанных апстримов, и если у вас будет блок upstream{} с таким именем, он и будет использоваться. Никакого DNS resolving'а. Т.е. вот прямо как вы и написали, примерно. Вопрос исключительно в том, как из переменных получить имя апстрима. Либо явно, либо через map. Пример: http { upstream u1 { server 127.0.0.1:10001; } upstream u2 { server 127.0.0.1:10002; } server { listen 10001; listen 10002; return 200 "$server_port\n"; } server { listen 8000; server_name ~^s(\d)$; location / { proxy_pass http://u$1; } } } $ curl -H 'Host: s1' http://127.1:8000 10001 $ curl -H 'Host: s2' http://127.1:8000 10002 From nginx-forum на forum.nginx.org Tue Mar 7 09:50:08 2017 From: nginx-forum на forum.nginx.org (itcod) Date: Tue, 07 Mar 2017 04:50:08 -0500 Subject: =?UTF-8?B?0LLQvtC/0YDQvtGBINC+IG1pbWUtdHlwZQ==?= Message-ID: Добрый день уважаемые! Имеем два файла: 1.js и .js По моей логике у этих файлов расширение "js", а имена разные, у одного есть, а у другого пустое. Но nginx мне в заголовках выдает: 1.js - Content-type: application/javascript .js - Content-type: application/octet-stream Подскажите пожалуйста! Это только у меня так, или это логика nginx файлам без имени ставить default_type, несмотря на наличие у файла расширения. И подскажите пожалуйста, как возможно отдельному файлу (по полному имени с расширением) установить принудительно персональный mime-type. Спасибо!!! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272787,272787#msg-272787 From annulen на yandex.ru Tue Mar 7 09:56:44 2017 From: annulen на yandex.ru (Konstantin Tokarev) Date: Tue, 07 Mar 2017 12:56:44 +0300 Subject: =?UTF-8?B?UmU6INCy0L7Qv9GA0L7RgSDQviBtaW1lLXR5cGU=?= In-Reply-To: References: Message-ID: <3906881488880604@web1o.yandex.ru> 07.03.2017, 12:50, "itcod" : > Добрый день уважаемые! > > Имеем два файла: 1.js и .js > По моей логике у этих файлов расширение "js", а имена разные, у одного есть, > а у другого пустое. > Но nginx мне в заголовках выдает: > 1.js - Content-type: application/javascript > .js - Content-type: application/octet-stream > > Подскажите пожалуйста! > Это только у меня так, или это логика nginx файлам без имени ставить > default_type, несмотря на наличие у файла расширения. Вообще "1.js" - это файл с именем "1" и расширением "js", а ".js" - скрытый файл с именем "js" и без расширения > > И подскажите пожалуйста, как возможно отдельному файлу (по полному имени с > расширением) установить принудительно персональный mime-type. > > Спасибо!!! > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272787,272787#msg-272787 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From nginx-forum на forum.nginx.org Tue Mar 7 10:38:12 2017 From: nginx-forum на forum.nginx.org (itcod) Date: Tue, 07 Mar 2017 05:38:12 -0500 Subject: =?UTF-8?B?UmU6INCy0L7Qv9GA0L7RgSDQviBtaW1lLXR5cGU=?= In-Reply-To: <3906881488880604@web1o.yandex.ru> References: <3906881488880604@web1o.yandex.ru> Message-ID: <95a4814455964cd2d7c3e33000e3b915.NginxMailingListRussian@forum.nginx.org> Константин добрый день! > > Имеем два файла: 1.js и .js > > По моей логике у этих файлов расширение "js", а имена разные, у > одного есть, а у другого пустое. > Вообще "1.js" - это файл с именем "1" и расширением "js", а ".js" - > скрытый файл с именем "js" и без расширения > Да конечно лидирующая точка - это общепринятый идентификатор скрытости. Только imho утверждение "пустое имя является идентификатором скрытости" так же является логичным :) И в таком контексте - файл не имеет имени, но имеет расширение/я. (например файл: ".tar.bz2" = это скрытый архив с двойной упаковкой и не имеющий имени:) ) Cобственно вопросы логики не особенно важны - так как мой второй вопрос снимает их: Как в конфигах location, файлу с определённым полным именем(включая расширения) назначить нужный мне хидер Content-Type. чтобы стало .js = Content-Type: application/javascript Спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272787,272789#msg-272789 From nefer05 на gmail.com Tue Mar 7 10:45:26 2017 From: nefer05 на gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQnNC+0YHQutCy0LjRgtC40L0=?=) Date: Tue, 7 Mar 2017 13:45:26 +0300 Subject: =?UTF-8?B?UmU6INCy0L7Qv9GA0L7RgSDQviBtaW1lLXR5cGU=?= In-Reply-To: <95a4814455964cd2d7c3e33000e3b915.NginxMailingListRussian@forum.nginx.org> References: <3906881488880604@web1o.yandex.ru> <95a4814455964cd2d7c3e33000e3b915.NginxMailingListRussian@forum.nginx.org> Message-ID: Ну нету в никсах расширений, нету! 2017-03-07 13:38 GMT+03:00 itcod : > Константин добрый день! > > > Имеем два файла: 1.js и .js > > > По моей логике у этих файлов расширение "js", а имена разные, у > > одного есть, а у другого пустое. > > > Вообще "1.js" - это файл с именем "1" и расширением "js", а ".js" - > > скрытый файл с именем "js" и без расширения > > > Да конечно лидирующая точка - это общепринятый идентификатор скрытости. > Только imho утверждение "пустое имя является идентификатором скрытости" так > же является логичным :) > И в таком контексте - файл не имеет имени, но имеет расширение/я. (например > файл: ".tar.bz2" = это скрытый архив с двойной упаковкой и не имеющий > имени:) ) > > Cобственно вопросы логики не особенно важны - так как мой второй вопрос > снимает их: > Как в конфигах location, файлу с определённым полным именем(включая > расширения) назначить нужный мне хидер Content-Type. > > чтобы стало > .js = Content-Type: application/javascript > > Спасибо! > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,272787,272789#msg-272789 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Mar 7 10:50:24 2017 From: nginx-forum на forum.nginx.org (itcod) Date: Tue, 07 Mar 2017 05:50:24 -0500 Subject: =?UTF-8?B?UmU6INCy0L7Qv9GA0L7RgSDQviBtaW1lLXR5cGU=?= In-Reply-To: References: Message-ID: Добрый день Роман! > Ну нету в никсах расширений, нету! В никсах нету, а в nginx есть - в файле mime-types :) Вопрос как файлу назначить Content-Type всё ещё висит.... Надеюсь есть решение:) Спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272787,272791#msg-272791 From chipitsine на gmail.com Tue Mar 7 11:15:29 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 7 Mar 2017 16:15:29 +0500 Subject: =?UTF-8?B?UmU6INCy0L7Qv9GA0L7RgSDQviBtaW1lLXR5cGU=?= In-Reply-To: References: Message-ID: 7 марта 2017 г., 14:50 пользователь itcod написал: > Добрый день уважаемые! > > Имеем два файла: 1.js и .js > По моей логике у этих файлов расширение "js", а имена разные, у одного > есть, > а у другого пустое. > Но nginx мне в заголовках выдает: > 1.js - Content-type: application/javascript > .js - Content-type: application/octet-stream > мы сталкивались с тем, что сторонние модули влияют на эту логику. попробуйте nginx без модулей ? > > Подскажите пожалуйста! > Это только у меня так, или это логика nginx файлам без имени ставить > default_type, несмотря на наличие у файла расширения. > > И подскажите пожалуйста, как возможно отдельному файлу (по полному имени с > расширением) установить принудительно персональный mime-type. > > Спасибо!!! > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,272787,272787#msg-272787 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From ru на nginx.com Tue Mar 7 12:07:28 2017 From: ru на nginx.com (Ruslan Ermilov) Date: Tue, 7 Mar 2017 15:07:28 +0300 Subject: =?UTF-8?B?UmU6INCy0L7Qv9GA0L7RgSDQviBtaW1lLXR5cGU=?= In-Reply-To: References: Message-ID: <20170307120728.GJ909@lo0.su> On Tue, Mar 07, 2017 at 05:50:24AM -0500, itcod wrote: > Добрый день Роман! > > Ну нету в никсах расширений, нету! > В никсах нету, а в nginx есть - в файле mime-types :) > > Вопрос как файлу назначить Content-Type всё ещё висит.... > Надеюсь есть решение:) > > Спасибо! Ответ на этот вопрос есть в документации. http://nginx.org/r/types/ru Для того чтобы для определённого location’а для всех ответов выдавался MIME-тип “application/octet-stream”, можно использовать следующее: location /download/ { types { } default_type application/octet-stream; } From nginx-forum на forum.nginx.org Tue Mar 7 12:25:45 2017 From: nginx-forum на forum.nginx.org (itcod) Date: Tue, 07 Mar 2017 07:25:45 -0500 Subject: =?UTF-8?B?UmU6INCy0L7Qv9GA0L7RgSDQviBtaW1lLXR5cGU=?= In-Reply-To: References: Message-ID: <77a0b39aa696b65b93225b66ebefe639.NginxMailingListRussian@forum.nginx.org> Илья! Добрый день. > > Но nginx мне в заголовках выдает: > > 1.js - Content-type: application/javascript > > .js - Content-type: application/octet-stream > > > мы сталкивались с тем, что сторонние модули влияют на эту логику. > попробуйте nginx без модулей ? Проверил без модулей lua - результат не изменился Нарыл и проверил на стареньком сервочке с nginx 0.8 и базовым комплектом модулей по default - результат тот-же. Файлы вот с такими названиями ".js" ".html" и подобными, идентифицируются как тип указанный в default_type У меня это application/octet-stream Получается и старые версии и посвежее nginx'ы, и с модулями, и без - одинаковая логика... И для nginx - видимо файлы с такими именами это файлы без расширения, и потому он ставит значение из переменной default_type. Как же мне всё-таки изменить Content-Type для нужных файлов? Спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272787,272794#msg-272794 From nginx-forum на forum.nginx.org Tue Mar 7 12:31:58 2017 From: nginx-forum на forum.nginx.org (itcod) Date: Tue, 07 Mar 2017 07:31:58 -0500 Subject: =?UTF-8?B?UmU6INCy0L7Qv9GA0L7RgSDQviBtaW1lLXR5cGU=?= In-Reply-To: <20170307120728.GJ909@lo0.su> References: <20170307120728.GJ909@lo0.su> Message-ID: <9fc2007c2336d90eb23fcb226309f817.NginxMailingListRussian@forum.nginx.org> Добрый день! ru на nginx.com > > Вопрос как файлу назначить Content-Type всё ещё висит.... > Для того чтобы для определённого location’а для всех ответов Мне НЕ нужно глобально менять Сontent-Type в location для всех ответов!!!! Только для файлов с определёнными названиями. Спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272787,272795#msg-272795 From ru на nginx.com Tue Mar 7 12:39:43 2017 From: ru на nginx.com (Ruslan Ermilov) Date: Tue, 7 Mar 2017 15:39:43 +0300 Subject: =?UTF-8?B?UmU6INCy0L7Qv9GA0L7RgSDQviBtaW1lLXR5cGU=?= In-Reply-To: <9fc2007c2336d90eb23fcb226309f817.NginxMailingListRussian@forum.nginx.org> References: <20170307120728.GJ909@lo0.su> <9fc2007c2336d90eb23fcb226309f817.NginxMailingListRussian@forum.nginx.org> Message-ID: <20170307123943.GK909@lo0.su> On Tue, Mar 07, 2017 at 07:31:58AM -0500, itcod wrote: > Добрый день! ru на nginx.com > > > > Вопрос как файлу назначить Content-Type всё ещё висит.... > > Для того чтобы для определённого location’а для всех ответов > > Мне НЕ нужно глобально менять Сontent-Type в location для всех ответов!!!! > Только для файлов с определёнными названиями. Задайте "файлы с определёнными названиями" при помощи location'а, внутри которого задайте нужный mime-тип. From nginx-forum на forum.nginx.org Tue Mar 7 16:11:56 2017 From: nginx-forum на forum.nginx.org (itcod) Date: Tue, 07 Mar 2017 11:11:56 -0500 Subject: =?UTF-8?B?UmU6INCy0L7Qv9GA0L7RgSDQviBtaW1lLXR5cGU=?= In-Reply-To: <20170307123943.GK909@lo0.su> References: <20170307123943.GK909@lo0.su> Message-ID: ru на nginx.com Wrote: > > Мне НЕ нужно глобально менять Сontent-Type в location для всех > ответов!!!! > > Только для файлов с определёнными названиями. > > Задайте "файлы с определёнными названиями" при помощи location'а, > внутри которого задайте нужный mime-тип. Да! Такая конструкция работает. Большое Спасибо! location / { ..... location ~* \.(js|ijs)$ { default_type application/javascript; } ..... } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272787,272802#msg-272802 From nginx-forum на forum.nginx.org Thu Mar 9 09:01:57 2017 From: nginx-forum на forum.nginx.org (ingtar) Date: Thu, 09 Mar 2017 04:01:57 -0500 Subject: upstream and hash Message-ID: Доброго дня! Эксперементирую с опцией hash для секции upstream. В ней можно указывать переменные и произвольный текст. С переменными понятно - посчитается хэш от например $host и запрос пойдет к апстриму. Как в этом случае сработает например такая конструкция: upstream groups { hash blablabla consistent; server test01:80; server test02:80; } Как будут распределяться запросы от пользователей? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272838,272838#msg-272838 From arut на nginx.com Thu Mar 9 09:07:19 2017 From: arut на nginx.com (Roman Arutyunyan) Date: Thu, 9 Mar 2017 12:07:19 +0300 Subject: upstream and hash In-Reply-To: References: Message-ID: <20170309090719.GA7909@Romans-MacBook-Air.local> Добрый день, On Thu, Mar 09, 2017 at 04:01:57AM -0500, ingtar wrote: > Доброго дня! > Эксперементирую с опцией hash для секции upstream. > В ней можно указывать переменные и произвольный текст. > С переменными понятно - посчитается хэш от например $host и запрос пойдет к > апстриму. > Как в этом случае сработает например такая конструкция: > > upstream groups { > hash blablabla consistent; > server test01:80; > server test02:80; > } > > Как будут распределяться запросы от пользователей? Точно так же. Только хеш будет всегда считаться от одной и той же строки. Впрочем большого смысла в такой конструкции нет. -- Roman Arutyunyan From nginx-forum на forum.nginx.org Thu Mar 9 09:45:41 2017 From: nginx-forum на forum.nginx.org (ingtar) Date: Thu, 09 Mar 2017 04:45:41 -0500 Subject: upstream and hash In-Reply-To: <20170309090719.GA7909@Romans-MacBook-Air.local> References: <20170309090719.GA7909@Romans-MacBook-Air.local> Message-ID: Получается это RR балансировка с хэшом? Как если бы hash не указывался вовсе Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272838,272841#msg-272841 From arut на nginx.com Thu Mar 9 10:24:32 2017 From: arut на nginx.com (Roman Arutyunyan) Date: Thu, 9 Mar 2017 13:24:32 +0300 Subject: upstream and hash In-Reply-To: References: <20170309090719.GA7909@Romans-MacBook-Air.local> Message-ID: <20170309102432.GB7909@Romans-MacBook-Air.local> On Thu, Mar 09, 2017 at 04:45:41AM -0500, ingtar wrote: > Получается это RR балансировка с хэшом? > Как если бы hash не указывался вовсе Нет. У вас каждый раз будет выбираться один и тот же сервер. -- Roman Arutyunyan From nginx-forum на forum.nginx.org Fri Mar 10 10:35:19 2017 From: nginx-forum на forum.nginx.org (ingtar) Date: Fri, 10 Mar 2017 05:35:19 -0500 Subject: =?UTF-8?B?UmU6INCx0LDQsyA/?= In-Reply-To: References: Message-ID: <7875282925cf102c2d0dd00de2d40faa.NginxMailingListRussian@forum.nginx.org> Выглядит все логично - у него два конфига слушают один и тот же адрес:порт. Сработает первая секция Есть еще интересные моменты, когда указание конкретного интерфейса меняет порядок прохождение конфигов Т.е. listen IP:PORT имеет приоритет над listen PORT Я прав? Столкнулся с таким на работе и был несколько удивлен о_О Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272442,272872#msg-272872 From chipitsine на gmail.com Fri Mar 10 10:53:32 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 10 Mar 2017 15:53:32 +0500 Subject: =?UTF-8?B?UmU6INCx0LDQsyA/?= In-Reply-To: <7875282925cf102c2d0dd00de2d40faa.NginxMailingListRussian@forum.nginx.org> References: <7875282925cf102c2d0dd00de2d40faa.NginxMailingListRussian@forum.nginx.org> Message-ID: 10 марта 2017 г., 15:35 пользователь ingtar написал: > Выглядит все логично - у него два конфига слушают один и тот же адрес:порт. > Сработает первая секция > ... и, поскольку вторая не сможет забиндиться (именно это происходит при применении конфига), то хочется, чтобы в момент "nginx -t" я об этом узнал > > Есть еще интересные моменты, когда указание конкретного интерфейса меняет > порядок прохождение конфигов > Т.е. listen IP:PORT имеет приоритет над listen PORT > > Я прав? Столкнулся с таким на работе и был несколько удивлен о_О > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,272442,272872#msg-272872 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Mar 14 08:49:23 2017 From: nginx-forum на forum.nginx.org (valmon) Date: Tue, 14 Mar 2017 04:49:23 -0400 Subject: =?UTF-8?B?0J3QtdGB0LrQvtC70YzQutC+IENNUyDQtNC70Y8g0YDQsNC30L3Ri9GFIFVSTA==?= Message-ID: Коллеги, подскажите направление. Необходимо совместить работу двух cms на одном домене, первая cms самописный биллинг, урлы у которого начинаются с буквы в верхнем регистре, например /Invoce, /Clause, /Bonuses, /API/*, обработчик для которых является /Core/Load.php, вторая cms, modx, корень вообще хочу сделать статичным. Собственно, какие варианты? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272923,272923#msg-272923 From chipitsine на gmail.com Tue Mar 14 10:13:38 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 14 Mar 2017 15:13:38 +0500 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: References: Message-ID: Префиксные локейшены и try_files 14 марта 2017 г. 13:49 пользователь "valmon" написал: > Коллеги, подскажите направление. > Необходимо совместить работу двух cms на одном домене, первая cms > самописный > биллинг, урлы у которого начинаются с буквы в верхнем регистре, например > /Invoce, /Clause, /Bonuses, /API/*, обработчик для которых является > /Core/Load.php, вторая cms, modx, корень вообще хочу сделать статичным. > Собственно, какие варианты? > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,272923,272923#msg-272923 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Mar 14 11:54:06 2017 From: nginx-forum на forum.nginx.org (valmon) Date: Tue, 14 Mar 2017 07:54:06 -0400 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: References: Message-ID: <731ac84696a89a5c61dc0899d175f9f7.NginxMailingListRussian@forum.nginx.org> Насколько я понял, он просто добавить к /Invoce /Invoce/index А есть какие либо регулярные выражения чтобы отфильтровать по первому символу в верхнем регистре? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272923,272926#msg-272926 From chipitsine на gmail.com Tue Mar 14 12:15:06 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 14 Mar 2017 17:15:06 +0500 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: <731ac84696a89a5c61dc0899d175f9f7.NginxMailingListRussian@forum.nginx.org> References: <731ac84696a89a5c61dc0899d175f9f7.NginxMailingListRussian@forum.nginx.org> Message-ID: нет, не надо ничего добавлять. да, конечно, вместо префиксных локейшенов можно использовать регулярные выражения. 14 марта 2017 г., 16:54 пользователь valmon написал: > Насколько я понял, он просто добавить к /Invoce /Invoce/index > А есть какие либо регулярные выражения чтобы отфильтровать по первому > символу в верхнем регистре? > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,272923,272926#msg-272926 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Mar 14 13:07:42 2017 From: nginx-forum на forum.nginx.org (valmon) Date: Tue, 14 Mar 2017 09:07:42 -0400 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: References: Message-ID: <94014c41d485fc31d103682e9c5788a2.NginxMailingListRussian@forum.nginx.org> Это замечательно, вот только пример не могу найти, чтобы регулярные выражение действовали по условию первая в верхнем регистре, далее в нижнем любой длины. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272923,272928#msg-272928 From chipitsine на gmail.com Tue Mar 14 13:43:48 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 14 Mar 2017 18:43:48 +0500 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: <94014c41d485fc31d103682e9c5788a2.NginxMailingListRussian@forum.nginx.org> References: <94014c41d485fc31d103682e9c5788a2.NginxMailingListRussian@forum.nginx.org> Message-ID: location ~ ^/[A-Z][a-z]*./ { ... } 14 марта 2017 г., 18:07 пользователь valmon написал: > Это замечательно, вот только пример не могу найти, чтобы регулярные > выражение действовали по условию первая в верхнем регистре, далее в нижнем > любой длины. > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,272923,272928#msg-272928 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Mar 14 14:42:29 2017 From: nginx-forum на forum.nginx.org (valmon) Date: Tue, 14 Mar 2017 10:42:29 -0400 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: References: Message-ID: Я так понимаю, работает только на /Invoce/, а если это конечный /Invoce, плюс передаем args? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272923,272931#msg-272931 From chipitsine на gmail.com Tue Mar 14 15:06:39 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 14 Mar 2017 20:06:39 +0500 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: References: Message-ID: args не затрагиваются. Со слешем или без - на ваше усмотрение 14 марта 2017 г. 19:42 пользователь "valmon" написал: > Я так понимаю, работает только на /Invoce/, а если это конечный /Invoce, > плюс передаем args? > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,272923,272931#msg-272931 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Mar 14 17:38:19 2017 From: nginx-forum на forum.nginx.org (valmon) Date: Tue, 14 Mar 2017 13:38:19 -0400 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: References: Message-ID: Чтото не получается сделать рабочую регулярку /Invoce, /Invoce/* и /API/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272923,272933#msg-272933 From nginx-forum на forum.nginx.org Tue Mar 14 20:49:05 2017 From: nginx-forum на forum.nginx.org (valmon) Date: Tue, 14 Mar 2017 16:49:05 -0400 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: References: Message-ID: <4ac6f65faf14923d653a50a2c35fd92b.NginxMailingListRussian@forum.nginx.org> В общем, получилась вот такая конструкция location / { root /home/admin/web/site.com/public_html; location ~ ^/[A-Z][A-Za-z]*. { if (!-e $request_filename) { rewrite ^/(.*)$ /core/Load.php?q=$1 last; } } location ~* ^.+\.(jpeg|jpg|png|gif|bmp|ico|svg|css|js)$ { expires max; } location ~ [^/]\.php(/|$) { fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; if (!-f $document_root$fastcgi_script_name) { return 404; } fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include /etc/nginx/fastcgi_params; } } Но получается, что можно слить файлы конфигурации, так как if (!-e $request_filename) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272923,272934#msg-272934 From vlad.shabanov на gmail.com Tue Mar 14 20:54:25 2017 From: vlad.shabanov на gmail.com (Vladislav Shabanov) Date: Tue, 14 Mar 2017 23:54:25 +0300 Subject: =?UTF-8?B?0KHQvdCw0YfQsNC70LAg0L7RgtC00LDRgtGMINCx0YDQsNGD0LfQtdGA0YMg0L4=?= =?UTF-8?B?0LTQvdC+0L/QuNC60YHQtdC70YzQvdGL0Lkg0LPQuNGELCDQsCDQv9C+0YI=?= =?UTF-8?B?0L7QvCDQv9C+0LTRg9C80LDRgtGM?= Message-ID: <32DB4417-17CC-4B1C-ABA3-0736C0737B03@gmail.com> Добрый день. Есть location, на котором сейчас отдаётся empty_gif. Мне нужно вызвать в этом месте демона через uwsgi, чтобы демон обработал событие и что-то записал в БД. Не хочется заставлять браузер ждать окончания всей этой обработки. Как настроить nginx чтобы uwsgi вызывался после того, как браузеру будет отправлен однопиксельный гиф? Ответ от uwsgi нужно ждать N миллисекунд и выбрасывать, нам всё равно, он успешно будет обработан или сломается. Можно ли такое сделать штатными средствами? С уважением, Влад From andrey на kopeyko.ru Tue Mar 14 22:34:44 2017 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Wed, 15 Mar 2017 01:34:44 +0300 Subject: =?UTF-8?B?UmU6INCh0L3QsNGH0LDQu9CwINC+0YLQtNCw0YLRjCDQsdGA0LDRg9C30LXRgNGD?= =?UTF-8?B?INC+0LTQvdC+0L/QuNC60YHQtdC70YzQvdGL0Lkg0LPQuNGELCDQsCDQv9C+?= =?UTF-8?B?0YLQvtC8INC/0L7QtNGD0LzQsNGC0Yw=?= In-Reply-To: <32DB4417-17CC-4B1C-ABA3-0736C0737B03@gmail.com> References: <32DB4417-17CC-4B1C-ABA3-0736C0737B03@gmail.com> Message-ID: <639990DD-E0BA-418C-87C3-52129C363FB8@kopeyko.ru> Привет, Влад! Возможно, тебе поможет post_action в этом location. 14 марта 2017 г. 23:54:25 GMT+03:00, Vladislav Shabanov пишет: >Добрый день. > >Есть location, на котором сейчас отдаётся empty_gif. > >Мне нужно вызвать в этом месте демона через uwsgi, чтобы демон >обработал событие и что-то записал в БД. Не хочется заставлять браузер >ждать окончания всей этой обработки. Как настроить nginx чтобы uwsgi >вызывался после того, как браузеру будет отправлен однопиксельный гиф? >Ответ от uwsgi нужно ждать N миллисекунд и выбрасывать, нам всё равно, >он успешно будет обработан или сломается. > >Можно ли такое сделать штатными средствами? > >С уважением, > Влад > > >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Простите за краткость, создано в K-9 Mail. From vadim.lazovskiy на gmail.com Wed Mar 15 05:58:34 2017 From: vadim.lazovskiy на gmail.com (Vadim Lazovskiy) Date: Wed, 15 Mar 2017 08:58:34 +0300 Subject: =?UTF-8?B?UmU6INCh0L3QsNGH0LDQu9CwINC+0YLQtNCw0YLRjCDQsdGA0LDRg9C30LXRgNGD?= =?UTF-8?B?INC+0LTQvdC+0L/QuNC60YHQtdC70YzQvdGL0Lkg0LPQuNGELCDQsCDQv9C+?= =?UTF-8?B?0YLQvtC8INC/0L7QtNGD0LzQsNGC0Yw=?= In-Reply-To: <32DB4417-17CC-4B1C-ABA3-0736C0737B03@gmail.com> References: <32DB4417-17CC-4B1C-ABA3-0736C0737B03@gmail.com> Message-ID: Здравствуйте. Я за скрипт в режиме "tail -f" на лог. 14 марта 2017 г., 23:54 пользователь Vladislav Shabanov < vlad.shabanov на gmail.com> написал: > Добрый день. > > Есть location, на котором сейчас отдаётся empty_gif. > > Мне нужно вызвать в этом месте демона через uwsgi, чтобы демон обработал > событие и что-то записал в БД. Не хочется заставлять браузер ждать > окончания всей этой обработки. Как настроить nginx чтобы uwsgi вызывался > после того, как браузеру будет отправлен однопиксельный гиф? Ответ от uwsgi > нужно ждать N миллисекунд и выбрасывать, нам всё равно, он успешно будет > обработан или сломается. > > Можно ли такое сделать штатными средствами? > > С уважением, > Влад > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- WBR, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine на gmail.com Wed Mar 15 06:17:13 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 15 Mar 2017 11:17:13 +0500 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: <4ac6f65faf14923d653a50a2c35fd92b.NginxMailingListRussian@forum.nginx.org> References: <4ac6f65faf14923d653a50a2c35fd92b.NginxMailingListRussian@forum.nginx.org> Message-ID: для настройки роутинга CMS общепринятая практика делать try_files, например, так https://book.cakephp.org/2.0/en/installation/url-rewriting.html логика тут примерно, как вы написали "если файл существует, то отдать его, если файла нет, или он с расширением php, то отправить на fastcgi" что делать с "можно слить файлы конфигурации" - в принципе, странно, что вы об этом думаете заранее. обычно, проблемы решаются по мере поступления )) а) необязательно файлы конфигурации хранить внутри сайта б) можно сделать вот так location /config/ { return 404; } в) можно хранить конфигурацию в виде php (а не ini, yml), это, кстати, самое выгодное в плане производительности. и такой файл (внутри которого определены только переменные) слить не получится. 2017-03-15 1:49 GMT+05:00 valmon : > В общем, получилась вот такая конструкция > location / { > root /home/admin/web/site.com/public_html; > location ~ ^/[A-Z][A-Za-z]*. { > if (!-e $request_filename) { > rewrite ^/(.*)$ /core/Load.php?q=$1 last; > } > } > > location ~* ^.+\.(jpeg|jpg|png|gif|bmp|ico|svg|css|js)$ { > expires max; > } > location ~ [^/]\.php(/|$) { > fastcgi_param SCRIPT_FILENAME > $document_root$fastcgi_script_name; > if (!-f $document_root$fastcgi_script_name) { > return 404; > } > > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > include /etc/nginx/fastcgi_params; > } > } > > Но получается, что можно слить файлы конфигурации, так как if (!-e > $request_filename) > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,272923,272934#msg-272934 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Wed Mar 15 08:02:28 2017 From: onokonem на gmail.com (Daniel Podolsky) Date: Wed, 15 Mar 2017 11:02:28 +0300 Subject: =?UTF-8?B?UmU6INCh0L3QsNGH0LDQu9CwINC+0YLQtNCw0YLRjCDQsdGA0LDRg9C30LXRgNGD?= =?UTF-8?B?INC+0LTQvdC+0L/QuNC60YHQtdC70YzQvdGL0Lkg0LPQuNGELCDQsCDQv9C+?= =?UTF-8?B?0YLQvtC8INC/0L7QtNGD0LzQsNGC0Yw=?= In-Reply-To: References: <32DB4417-17CC-4B1C-ABA3-0736C0737B03@gmail.com> Message-ID: > Я за скрипт в режиме "tail -f" на лог. tail -F From chipitsine на gmail.com Wed Mar 15 08:18:25 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 15 Mar 2017 13:18:25 +0500 Subject: =?UTF-8?B?UmU6INCh0L3QsNGH0LDQu9CwINC+0YLQtNCw0YLRjCDQsdGA0LDRg9C30LXRgNGD?= =?UTF-8?B?INC+0LTQvdC+0L/QuNC60YHQtdC70YzQvdGL0Lkg0LPQuNGELCDQsCDQv9C+?= =?UTF-8?B?0YLQvtC8INC/0L7QtNGD0LzQsNGC0Yw=?= In-Reply-To: <32DB4417-17CC-4B1C-ABA3-0736C0737B03@gmail.com> References: <32DB4417-17CC-4B1C-ABA3-0736C0737B03@gmail.com> Message-ID: если речь идет об аналитике (и небольшая задержка данных допустима), то можно access.log сделать доступным по http, откуда аналитика его будет вычитывать с нужной периодичностью и обрабатывать решение с претензией на универсальность 15 марта 2017 г., 1:54 пользователь Vladislav Shabanov < vlad.shabanov на gmail.com> написал: > Добрый день. > > Есть location, на котором сейчас отдаётся empty_gif. > > Мне нужно вызвать в этом месте демона через uwsgi, чтобы демон обработал > событие и что-то записал в БД. Не хочется заставлять браузер ждать > окончания всей этой обработки. Как настроить nginx чтобы uwsgi вызывался > после того, как браузеру будет отправлен однопиксельный гиф? Ответ от uwsgi > нужно ждать N миллисекунд и выбрасывать, нам всё равно, он успешно будет > обработан или сломается. > > Можно ли такое сделать штатными средствами? > > С уважением, > Влад > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Mar 15 09:55:55 2017 From: nginx-forum на forum.nginx.org (valmon) Date: Wed, 15 Mar 2017 05:55:55 -0400 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: References: Message-ID: что делать с "можно слить файлы конфигурации" - в принципе, странно, что вы об этом думаете заранее. А не зря, реврайт из модуля для апача отправляет все кроме style|public на index.php, тут же, все что не попадает под маску [A-Z][A-Za-z], отрабатывается как статика и отображается. Добавил location ~* "/\.(htaccess|htpasswd|xml|ini)$" { deny all; return 403; , но не работает. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272923,272943#msg-272943 From chipitsine на gmail.com Wed Mar 15 10:22:42 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 15 Mar 2017 15:22:42 +0500 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: References: Message-ID: "deny" и "return 403" взаимоисключающие, хватило бы любого из. насчет того, какой локейшен срабатывает, алгоритм описан, например, вот тут http://nginx.org/ru/docs/http/request_processing.html "nginx вначале ищет среди всех префиксных location’ов, заданных строками, максимально совпадающий. В вышеприведённой конфигурации указан только один префиксный location “/”, и поскольку он подходит под любой запрос, он и будет использован, если других совпадений не будет найдено. Затем nginx проверяет location’ы, заданные регулярными выражениями, в порядке их следования в конфигурационном файле. При первом же совпадении поиск прекращается и nginx использует совпавший location. Если запросу не соответствует ни одно из регулярных выражений, nginx использует максимально совпавший префиксный location, найденный ранее. " возможно, у вас порядок локейшенов задан такой, что срабатывает другая регулярка (я так понял, у вас запрос попадает под обе регулярки) 15 марта 2017 г., 14:55 пользователь valmon написал: > что делать с "можно слить файлы конфигурации" - в принципе, странно, что вы > > об этом думаете заранее. > > А не зря, реврайт из модуля для апача отправляет все кроме style|public на > index.php, тут же, все что не попадает под маску [A-Z][A-Za-z], > отрабатывается как статика и отображается. > Добавил > location ~* "/\.(htaccess|htpasswd|xml|ini)$" { > deny all; > return 403; > , но не работает. > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,272923,272943#msg-272943 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Mar 15 11:17:57 2017 From: nginx-forum на forum.nginx.org (valmon) Date: Wed, 15 Mar 2017 07:17:57 -0400 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: References: Message-ID: Да, вы правы, локация не в том порядке, вот что получилось, но как выяснилось, по частям не вариант, получилось уже приличное количество исключений, для отдачи 403 location ~* ^.+\.(xml|ini|bin|sql|log)$ { deny all; return 403; } server { listen 192.168.0.147:443; server_name site.com; root /home/admin/web/site.com/public_html; index index.php index.html index.htm; access_log /var/log/nginx/domains/site.com.log combined; access_log /var/log/nginx/domains/site.com.bytes bytes; error_log /var/log/nginx/domains/site.com.error.log error; ssl on; ssl_certificate /home/admin/conf/web/ssl.site.com.pem; ssl_certificate_key /home/admin/conf/web/ssl.site.com.key; location / { root /home/admin/web/site.com/public_html; location ~ ^/[A-Z][A-Za-z]*. { if (!-e $request_filename) { #rewrite ^/(.*)$ /core/Load.php?q=$1 last; Не работает Inclede с относительным путем rewrite ^/(.*)$ /index2.php?q=$1 last; } } location ~* ^.+\.(jpeg|jpg|png|gif|bmp|ico|svg|css|js)$ { expires max; } location ~ [^/]\.php(/|$) { fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; if (!-f $document_root$fastcgi_script_name) { return 404; } fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include /etc/nginx/fastcgi_params; } location ~* ^.+\.(xml|ini|bin|sql|log)$ { deny all; return 403; } } #error_page 403 /error/404.html; #error_page 404 /error/404.html; error_page 500 502 503 504 /error/50x.html; location /error/ { alias /home/admin/web/site.com/document_errors/; } location ~* "/\.(htaccess|htpasswd)$" { deny all; return 404; } include /etc/nginx/conf.d/phpmyadmin.inc*; include /etc/nginx/conf.d/phppgadmin.inc*; include /etc/nginx/conf.d/webmail.inc*; include /home/admin/conf/web/snginx.site.com.conf*; } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272923,272951#msg-272951 From chipitsine на gmail.com Wed Mar 15 11:21:15 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 15 Mar 2017 16:21:15 +0500 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: References: Message-ID: аккуратнее с конфигами, чтобы демонов не вызвать :) 2017-03-15 16:17 GMT+05:00 valmon : > Да, вы правы, локация не в том порядке, вот что получилось, но как > выяснилось, по частям не вариант, получилось уже приличное количество > исключений, для отдачи 403 > location ~* ^.+\.(xml|ini|bin|sql|log)$ { > deny all; > return 403; > } > server { > listen 192.168.0.147:443; > server_name site.com; > root /home/admin/web/site.com/public_html; > index index.php index.html index.htm; > access_log /var/log/nginx/domains/site.com.log combined; > access_log /var/log/nginx/domains/site.com.bytes bytes; > error_log /var/log/nginx/domains/site.com.error.log error; > > ssl on; > ssl_certificate /home/admin/conf/web/ssl.site.com.pem; > ssl_certificate_key /home/admin/conf/web/ssl.site.com.key; > > location / { > root /home/admin/web/site.com/public_html; > location ~ ^/[A-Z][A-Za-z]*. { > if (!-e $request_filename) { > #rewrite ^/(.*)$ /core/Load.php?q=$1 last; Не работает > Inclede с относительным путем > rewrite ^/(.*)$ /index2.php?q=$1 last; > } > } > location ~* ^.+\.(jpeg|jpg|png|gif|bmp|ico|svg|css|js)$ { > expires max; > } > location ~ [^/]\.php(/|$) { > fastcgi_param SCRIPT_FILENAME > $document_root$fastcgi_script_name; > if (!-f $document_root$fastcgi_script_name) { > return 404; > } > > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > include /etc/nginx/fastcgi_params; > } > location ~* ^.+\.(xml|ini|bin|sql|log)$ { > deny all; > return 403; > } > } > > #error_page 403 /error/404.html; > #error_page 404 /error/404.html; > error_page 500 502 503 504 /error/50x.html; > > location /error/ { > alias /home/admin/web/site.com/document_errors/; > } > > location ~* "/\.(htaccess|htpasswd)$" { > deny all; > return 404; > } > > include /etc/nginx/conf.d/phpmyadmin.inc*; > include /etc/nginx/conf.d/phppgadmin.inc*; > include /etc/nginx/conf.d/webmail.inc*; > > include /home/admin/conf/web/snginx.site.com.conf*; > } > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,272923,272951#msg-272951 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Mar 15 12:00:35 2017 From: nginx-forum на forum.nginx.org (valmon) Date: Wed, 15 Mar 2017 08:00:35 -0400 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: References: Message-ID: <2678ad40623e6173f5a09f8063f04210.NginxMailingListRussian@forum.nginx.org> И не говорите) Собственно вопрос, как к регулярным выражением для location ~* ^.+\.(xml|ini|bin|sql|log)$ добавить директории типа style|public? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272923,272957#msg-272957 From chipitsine на gmail.com Wed Mar 15 12:44:47 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 15 Mar 2017 17:44:47 +0500 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: <2678ad40623e6173f5a09f8063f04210.NginxMailingListRussian@forum.nginx.org> References: <2678ad40623e6173f5a09f8063f04210.NginxMailingListRussian@forum.nginx.org> Message-ID: если имеется в виду, что файлы с таким расширением только в таких папка, то через вложенные локейшены 15 марта 2017 г., 17:00 пользователь valmon написал: > И не говорите) > > Собственно вопрос, как к регулярным выражением для location ~* > ^.+\.(xml|ini|bin|sql|log)$ добавить директории типа style|public? > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,272923,272957#msg-272957 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Mar 15 13:01:34 2017 From: nginx-forum на forum.nginx.org (valmon) Date: Wed, 15 Mar 2017 09:01:34 -0400 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: References: Message-ID: <6cd9ae19c61901d0722225393dbf6025.NginxMailingListRussian@forum.nginx.org> Нет, чтобы не делать два location location ~* ^.+\.(xml|ini|bin|sql|log)$ { deny all; return 403; } location ~* ^/(hosts|core|patches|db|others)/ { deny all; return 403; } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272923,272960#msg-272960 From chipitsine на gmail.com Wed Mar 15 13:06:44 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 15 Mar 2017 18:06:44 +0500 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: <6cd9ae19c61901d0722225393dbf6025.NginxMailingListRussian@forum.nginx.org> References: <6cd9ae19c61901d0722225393dbf6025.NginxMailingListRussian@forum.nginx.org> Message-ID: чем плохо два локейшена ? 2017-03-15 18:01 GMT+05:00 valmon : > Нет, чтобы не делать два location > location ~* ^.+\.(xml|ini|bin|sql|log)$ { > deny all; > return 403; > } > location ~* ^/(hosts|core|patches|db|others)/ { > deny all; > return 403; > } > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,272923,272960#msg-272960 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Mar 15 14:50:55 2017 From: nginx-forum на forum.nginx.org (valmon) Date: Wed, 15 Mar 2017 10:50:55 -0400 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: References: Message-ID: <99989cd6099261b1a14b36441aef72c5.NginxMailingListRussian@forum.nginx.org> В общем, нарисовался вот такой конфиг, есть замечание, даже со статичным index.html все получается, есть замечание? location / { root /home/admin/web/site.com/public_html; location ~ ^/[A-Z][A-Za-z]*. { rewrite ^/(.*)$ /index2.php?q=$1 last; } if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?q=$1 last; } location ~* ^.+\.(jpeg|jpg|png|gif|bmp|ico|svg|css|js)$ { expires max; } location ~ [^/]\.php(/|$) { fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; if (!-f $document_root$fastcgi_script_name) { return 404; } fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include /etc/nginx/fastcgi_params; } location ~* ^.+\.(xml|ini|bin|sql|log)$ { deny all; return 403; } location ~* ^/(hosts|core|patches|db|others|tmp)/ { deny all; return 403; } } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272923,272965#msg-272965 From chipitsine на gmail.com Wed Mar 15 15:19:37 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 15 Mar 2017 20:19:37 +0500 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: <99989cd6099261b1a14b36441aef72c5.NginxMailingListRussian@forum.nginx.org> References: <99989cd6099261b1a14b36441aef72c5.NginxMailingListRussian@forum.nginx.org> Message-ID: если для вас это является понятным, и работает так, как вы ожидаете, почему бы и нет. я бы на try_files сделал. и от "expires max" обычно больше вреда, чем пользы (если содержимое файла поменяется, а имя останется прежним). 2017-03-15 19:50 GMT+05:00 valmon : > В общем, нарисовался вот такой конфиг, есть замечание, даже со статичным > index.html все получается, есть замечание? > > > location / { > root /home/admin/web/site.com/public_html; > location ~ ^/[A-Z][A-Za-z]*. { > rewrite ^/(.*)$ /index2.php?q=$1 last; > } > if (!-e $request_filename) { > rewrite ^/(.*)$ /index.php?q=$1 last; > } > location ~* ^.+\.(jpeg|jpg|png|gif|bmp|ico|svg|css|js)$ { > expires max; > } > location ~ [^/]\.php(/|$) { > fastcgi_param SCRIPT_FILENAME > $document_root$fastcgi_script_name; > if (!-f $document_root$fastcgi_script_name) { > return 404; > } > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > include /etc/nginx/fastcgi_params; > } > location ~* ^.+\.(xml|ini|bin|sql|log)$ { > deny all; > return 403; > } > location ~* ^/(hosts|core|patches|db|others|tmp)/ { > deny all; > return 403; > } > } > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,272923,272965#msg-272965 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Mar 15 17:23:27 2017 From: nginx-forum на forum.nginx.org (valmon) Date: Wed, 15 Mar 2017 13:23:27 -0400 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviBDTVMg0LTQu9GPINGA0LDQt9C90YvRhSBV?= =?UTF-8?B?Ukw=?= In-Reply-To: References: Message-ID: <466740aeb90664f11413020a02c04619.NginxMailingListRussian@forum.nginx.org> Я не совсем понимаю как работает try_files, если не затруднит, могли бы привести пример на моем случае? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272923,272970#msg-272970 From nginx-forum на forum.nginx.org Thu Mar 16 13:56:33 2017 From: nginx-forum на forum.nginx.org (obolobova) Date: Thu, 16 Mar 2017 09:56:33 -0400 Subject: =?UTF-8?B?aG9zdCBub3QgZm91bmQgaW4gdXBzdHJlYW06INC90LUg0L/QvtGP0LLQuNC70LA=?= =?UTF-8?B?0YHRjCDQstC+0LfQvNC+0LbQvdC+0YHRgtGMINC40LPQvdC+0YDQuNGA0L4=?= =?UTF-8?B?0LLQsNGC0Yw/?= Message-ID: <7c851a4cc60b7bb4dc8bfdaf22de1afd.NginxMailingListRussian@forum.nginx.org> Здравствуйте. У нас крутится nginx в докере, и проксирует запросы на большое количество сервисов, тоже в контейнерах. Все это хозяйство объединено в Docker overlay network, и адресация идет не по реальным хостнеймам, а по именам/алиасам докер-контейнеров (DNS-резолвинг обеспечивает сетевая инфраструктура докера). Конфиг примерно такой: upstream my_upstream1 { server DOCKER_CONTAINER1:8080 max_fails=0; server DOCKER_CONTAINER2:8080; keepalive 32; } # еще куча апстримов upstream my_upstream2... upstream my_upstream3... server { server_name myurl.com; listen 80 ; access_log /var/log/nginx/access.log vhost; location / { proxy_pass http://my_upstream1; #также пробовали вариант с переменной set $my_var my_upstream1; proxy_pass http://$my_var; } } Проблема, наверное, уже понятна: если хоть один контейнер исчезает (упал, удалили, машина провалилась под землю, whatever), то соответствующее имя не резолвится и NGINX крэшится при старте. Подчеркну, что проблема не в резолвере - он работает совершенно верно, исчезнувший контейнер и не должен резолвиться - всё, его нет, и докер убирает соответствующую запись из своего DNS. Описанный выше вариант - штатная ситуация, в системе будут сотни апстримов и тысячи контейнеров, какие-то из них будут падать обязательно. Можно ли что-то сделать - на уровне штатного конфига - чтобы NGINX всё же стартовал? В гугле пишут, что либо ничего не сделать, либо использовать переменную в proxy_pass - но нам не помогло. Если хоть одно имя хоть в одном upstream не резолвится, NGINX не стартует. Может быть, появился какой-то новый workaround? Если нет, то, насколько я понимаю, остается вариант цеплять к NGINXу дополнительный DNS, который все эти апстримы будет резолвить хоть бы на 127.0.0.1? Большое спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272978,272978#msg-272978 From nginx-forum на forum.nginx.org Thu Mar 16 14:08:33 2017 From: nginx-forum на forum.nginx.org (jtiq) Date: Thu, 16 Mar 2017 10:08:33 -0400 Subject: =?UTF-8?B?0J/QvtC70YPRh9C40YLRjCDQstGA0LXQvNGPINC40YHRgtC10LrQsNC90LjRjyA=?= =?UTF-8?B?0LrRjdGI0LAg0YTQsNC50LvQsA==?= Message-ID: Можно ли получить время истекания кэша файла jsonp запросом? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272979,272979#msg-272979 From valery+nginx на grid.net.ru Thu Mar 16 14:25:39 2017 From: valery+nginx на grid.net.ru (Valery Kholodkov) Date: Thu, 16 Mar 2017 15:25:39 +0100 Subject: =?UTF-8?B?UmU6IGhvc3Qgbm90IGZvdW5kIGluIHVwc3RyZWFtOiDQvdC1INC/0L7Rj9Cy0Lg=?= =?UTF-8?B?0LvQsNGB0Ywg0LLQvtC30LzQvtC20L3QvtGB0YLRjCDQuNCz0L3QvtGA0Lg=?= =?UTF-8?B?0YDQvtCy0LDRgtGMPw==?= In-Reply-To: <7c851a4cc60b7bb4dc8bfdaf22de1afd.NginxMailingListRussian@forum.nginx.org> References: <7c851a4cc60b7bb4dc8bfdaf22de1afd.NginxMailingListRussian@forum.nginx.org> Message-ID: <6ca68ae8-e65f-3dd0-9931-1063e787fac9@grid.net.ru> Для решения этой проблемы достаточно всем контейнерам одного сервиса в оверлей-сети прописать один и тот же алиас. Тогда докер в своем внутреннем DNS-е пропишет запись с множеством адресов и nginx сможет резолвить набор адресов контейнеров соответствующих сервису. Пример на docker-compose: version: '2' services: myapp: [ ... пропущено ... ] networks: ovr0: aliases: - myapp networks: ovr0: external: name: ovr0 Конфиг nginx: server { server_name myurl.com; listen 80 ; access_log /var/log/nginx/access.log vhost; location / { proxy_pass http://myapp; } } Замечания: 1. nginx должен быть докеризирован. Я пока не нашел способов роутинга трафика с хоста в оверлей-сеть; 2. Контейнеры должны использовать внутренный DNS докера; 3. Оверлей-сеть не всегда стабильна, особенно в глобальном масштабе. Полагаю максимальная стабильность может быть гарантирована, только если все хосты находятся в локальной сети. On 16-03-17 14:56, obolobova wrote: > Здравствуйте. > > У нас крутится nginx в докере, и проксирует запросы на большое количество > сервисов, тоже в контейнерах. > Все это хозяйство объединено в Docker overlay network, и адресация идет не > по реальным хостнеймам, а по именам/алиасам докер-контейнеров (DNS-резолвинг > обеспечивает сетевая инфраструктура докера). > > Конфиг примерно такой: > > upstream my_upstream1 { > server DOCKER_CONTAINER1:8080 max_fails=0; > server DOCKER_CONTAINER2:8080; > keepalive 32; > } > > # еще куча апстримов > upstream my_upstream2... > upstream my_upstream3... > > server { > server_name myurl.com; > listen 80 ; > access_log /var/log/nginx/access.log vhost; > location / { > proxy_pass http://my_upstream1; > > #также пробовали вариант с переменной > set $my_var my_upstream1; > proxy_pass http://$my_var; > } > } > > Проблема, наверное, уже понятна: если хоть один контейнер исчезает (упал, > удалили, машина провалилась под землю, whatever), то соответствующее имя не > резолвится и NGINX крэшится при старте. > Подчеркну, что проблема не в резолвере - он работает совершенно верно, > исчезнувший контейнер и не должен резолвиться - всё, его нет, и докер > убирает соответствующую запись из своего DNS. > > Описанный выше вариант - штатная ситуация, в системе будут сотни апстримов и > тысячи контейнеров, какие-то из них будут падать обязательно. > > Можно ли что-то сделать - на уровне штатного конфига - чтобы NGINX всё же > стартовал? > В гугле пишут, что либо ничего не сделать, либо использовать переменную в > proxy_pass - но нам не помогло. Если хоть одно имя хоть в одном upstream не > резолвится, NGINX не стартует. > Может быть, появился какой-то новый workaround? > > Если нет, то, насколько я понимаю, остается вариант цеплять к NGINXу > дополнительный DNS, который все эти апстримы будет резолвить хоть бы на > 127.0.0.1? > > Большое спасибо. > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272978,272978#msg-272978 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From undying-m на yandex.ru Thu Mar 16 16:36:53 2017 From: undying-m на yandex.ru (Den Bozhok) Date: Thu, 16 Mar 2017 19:36:53 +0300 Subject: proxy_cache_path max_size mismatch Message-ID: <464371489682213@web15m.yandex.ru> Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Mar 16 16:56:08 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 16 Mar 2017 19:56:08 +0300 Subject: proxy_cache_path max_size mismatch In-Reply-To: <464371489682213@web15m.yandex.ru> References: <464371489682213@web15m.yandex.ru> Message-ID: <20170316165608.GR13617@mdounin.ru> Hello! On Thu, Mar 16, 2017 at 07:36:53PM +0300, Den Bozhok wrote: > Есть странная ситуация с кэшированием. > > nginx используется как кэш статических файлов с max_size=800GB. Кэш > длительное время заполняется, но внезапно на ~500GB включается кэш > менеджер и начитает чистить кэш освобождая место. В дальнейшем кэш > менеджер держит использование пространства около 500 Гигабайт вместо > 800. Если поднять max_size до 850ГБ, то кэш снова начинает наполнятся > примерно до 600ГБ, а потом снова кэш менеджер включает чистку. Какая файловая система используется? Ранее подобное поведение отмечалось на XFS, где размер занимаемого дискового пространства сообщается "с запасом", пока не закроешь файл. Подробности в https://trac.nginx.org/nginx/ticket/157. -- Maxim Dounin http://nginx.org/ From undying-m на yandex.ru Thu Mar 16 17:10:51 2017 From: undying-m на yandex.ru (Den Bozhok) Date: Thu, 16 Mar 2017 20:10:51 +0300 Subject: proxy_cache_path max_size mismatch In-Reply-To: <20170316165608.GR13617@mdounin.ru> References: <464371489682213@web15m.yandex.ru> <20170316165608.GR13617@mdounin.ru> Message-ID: <595591489684251@web12j.yandex.ru> Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Mar 16 17:31:17 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 16 Mar 2017 20:31:17 +0300 Subject: proxy_cache_path max_size mismatch In-Reply-To: <595591489684251@web12j.yandex.ru> References: <464371489682213@web15m.yandex.ru> <20170316165608.GR13617@mdounin.ru> <595591489684251@web12j.yandex.ru> Message-ID: <20170316173116.GS13617@mdounin.ru> Hello! On Thu, Mar 16, 2017 at 08:10:51PM +0300, Den Bozhok wrote: > У нас как раз используется XFS. > > Вижу, что задаче уже 5 лет, есть ли перспективы в ее решении? Со стороны nginx'а - вряд ли, разумных способов что-то сделать с подобным поведением файловой системы не просматривается. Да и проблема не выглядит серьёзной. Со стороны XFS - вопрос, насколько я понимаю, закрывается установкой allocsize по умолчанию. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Thu Mar 16 19:19:38 2017 From: nginx-forum на forum.nginx.org (obolobova) Date: Thu, 16 Mar 2017 15:19:38 -0400 Subject: =?UTF-8?B?UmU6IGhvc3Qgbm90IGZvdW5kIGluIHVwc3RyZWFtOiDQvdC1INC/0L7Rj9Cy0Lg=?= =?UTF-8?B?0LvQsNGB0Ywg0LLQvtC30LzQvtC20L3QvtGB0YLRjCDQuNCz0L3QvtGA0Lg=?= =?UTF-8?B?0YDQvtCy0LDRgtGMPw==?= In-Reply-To: <6ca68ae8-e65f-3dd0-9931-1063e787fac9@grid.net.ru> References: <6ca68ae8-e65f-3dd0-9931-1063e787fac9@grid.net.ru> Message-ID: У нас так не получается, увы - мы используем оверлей с внешним хранилищем (Консулом), а эта разновидность сети требует уникальных имен всех нод в кластере. Да и не хочется ставить старт NGINXа, который служит entrypoint'ом для всех сервисов, в зависимость от одного или нескольких сервисов или событий. Хотелось бы сделать его максимально независимым. Вы правильно сказали, что оверлей-нетворк бывают нестабильны, а у нас это всё распределенное, крутится в Амазоне, поэтому события в стиле "сетевой администратор ошибся цифрой - два континента отвалились" тоже случаются. Получается, NGINX out-of-box не очень приспособлен к работе в быстро меняющемся окружении, где, в общем, нормой является, что где-то что-то падает, исчезает, появляется, меняются имена и адреса и т. п. По крайней мере, жалоб именно на эту проблему с апстримом в сети очень много :) Valery Kholodkov Wrote: ------------------------------------------------------- > Для решения этой проблемы достаточно всем контейнерам одного сервиса в > > оверлей-сети прописать один и тот же алиас. Тогда докер в своем > внутреннем DNS-е пропишет запись с множеством адресов и nginx сможет > резолвить набор адресов контейнеров соответствующих сервису. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272978,272991#msg-272991 From vl на nginx.com Thu Mar 16 19:27:58 2017 From: vl на nginx.com (Vladimir Homutov) Date: Thu, 16 Mar 2017 22:27:58 +0300 Subject: =?UTF-8?B?UmU6IGhvc3Qgbm90IGZvdW5kIGluIHVwc3RyZWFtOiDQvdC1INC/0L7Rj9Cy0Lg=?= =?UTF-8?B?0LvQsNGB0Ywg0LLQvtC30LzQvtC20L3QvtGB0YLRjCDQuNCz0L3QvtGA0Lg=?= =?UTF-8?B?0YDQvtCy0LDRgtGMPw==?= In-Reply-To: References: <6ca68ae8-e65f-3dd0-9931-1063e787fac9@grid.net.ru> Message-ID: <11e64fcb-0584-f307-769a-e64ca9b5fa5c@nginx.com> On 16.03.2017 22:19, obolobova wrote: > У нас так не получается, увы - мы используем оверлей с внешним хранилищем > (Консулом), а эта разновидность сети требует уникальных имен всех нод в > кластере. > > Да и не хочется ставить старт NGINXа, который служит entrypoint'ом для всех > сервисов, в зависимость от одного или нескольких сервисов или событий. > Хотелось бы сделать его максимально независимым. Вы правильно сказали, что > оверлей-нетворк бывают нестабильны, а у нас это всё распределенное, крутится > в Амазоне, поэтому события в стиле "сетевой администратор ошибся цифрой - > два континента отвалились" тоже случаются. > > Получается, NGINX out-of-box не очень приспособлен к работе в быстро > меняющемся окружении, где, в общем, нормой является, что где-то что-то > падает, исчезает, появляется, меняются имена и адреса и т. п. > По крайней мере, жалоб именно на эту проблему с апстримом в сети очень много > :) > Возможно, вам будут интересны опции "resolve" и "service" директивы server[1], доступные в коммерческой версии. http://nginx.org/en/docs/http/ngx_http_upstream_module.html#server From valery+nginx на grid.net.ru Thu Mar 16 20:43:43 2017 From: valery+nginx на grid.net.ru (Valery Kholodkov) Date: Thu, 16 Mar 2017 21:43:43 +0100 Subject: =?UTF-8?B?UmU6IGhvc3Qgbm90IGZvdW5kIGluIHVwc3RyZWFtOiDQvdC1INC/0L7Rj9Cy0Lg=?= =?UTF-8?B?0LvQsNGB0Ywg0LLQvtC30LzQvtC20L3QvtGB0YLRjCDQuNCz0L3QvtGA0Lg=?= =?UTF-8?B?0YDQvtCy0LDRgtGMPw==?= In-Reply-To: References: <6ca68ae8-e65f-3dd0-9931-1063e787fac9@grid.net.ru> Message-ID: <6bdb6bbd-685d-6eaf-3f92-563f326b6080@grid.net.ru> Добавлю, что контейнер в сети может иметь несколько разных алиасов. Поэтому необходимость иметь уникальные имена не противоречит с возможностью иметь неуникальный алиас. On 16-03-17 20:19, obolobova wrote: > У нас так не получается, увы - мы используем оверлей с внешним хранилищем > (Консулом), а эта разновидность сети требует уникальных имен всех нод в > кластере. > > Да и не хочется ставить старт NGINXа, который служит entrypoint'ом для всех > сервисов, в зависимость от одного или нескольких сервисов или событий. > Хотелось бы сделать его максимально независимым. Вы правильно сказали, что > оверлей-нетворк бывают нестабильны, а у нас это всё распределенное, крутится > в Амазоне, поэтому события в стиле "сетевой администратор ошибся цифрой - > два континента отвалились" тоже случаются. > > Получается, NGINX out-of-box не очень приспособлен к работе в быстро > меняющемся окружении, где, в общем, нормой является, что где-то что-то > падает, исчезает, появляется, меняются имена и адреса и т. п. > По крайней мере, жалоб именно на эту проблему с апстримом в сети очень много > :) > > Valery Kholodkov Wrote: > ------------------------------------------------------- >> Для решения этой проблемы достаточно всем контейнерам одного сервиса в >> >> оверлей-сети прописать один и тот же алиас. Тогда докер в своем >> внутреннем DNS-е пропишет запись с множеством адресов и nginx сможет >> резолвить набор адресов контейнеров соответствующих сервису. > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272978,272991#msg-272991 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From undying-m на yandex.ru Thu Mar 16 22:58:21 2017 From: undying-m на yandex.ru (Den Bozhok) Date: Fri, 17 Mar 2017 01:58:21 +0300 Subject: proxy_cache_path max_size mismatch In-Reply-To: <20170316173116.GS13617@mdounin.ru> References: <464371489682213@web15m.yandex.ru> <20170316165608.GR13617@mdounin.ru> <595591489684251@web12j.yandex.ru> <20170316173116.GS13617@mdounin.ru> Message-ID: <991601489705101@web21m.yandex.ru> Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Mar 17 17:35:17 2017 From: nginx-forum на forum.nginx.org (Archy) Date: Fri, 17 Mar 2017 13:35:17 -0400 Subject: =?UTF-8?B?0KfRgtC10L3QuNC1INC80LXRgtC60LggRG9EIFNlY3VyaXR5IE9wdGlvbiAoUkZD?= =?UTF-8?B?MTEwOCk=?= Message-ID: Здравствуйте! Стоит задача передачи в приложение меток, передаваемых с клиента в поле опций IPv4 пакета. Метки добавляются по RFC1108 типа IPOPT_SEC,5,0xAB,03,12 Подскажите, куда копать, можно ли сделать на основе существующих модулей разбор пакета или можно/нужно писать свой модуль? Или может быть даже такая возможность есть в ядре, а я банально не вижу? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273014,273014#msg-273014 From simpot на simpot.com Sun Mar 19 19:44:10 2017 From: simpot на simpot.com (Dmitry Saratsky) Date: Sun, 19 Mar 2017 19:44:10 +0000 Subject: =?UTF-8?B?0JHRg9C00LXRgiDQu9C4IExVQSBtb2R1bGUg0LTQvtCx0LDQstC70LXQvSDQsiB5?= =?UTF-8?B?dW0g0YDQtdC/0L7Qt9C40YLQvtGA0LjQuT8=?= Message-ID: Доброго времени суток! А не подскажет ли мне уважаемое сообщество, есть ли планы добавить модуль ЛУА в репозитории? Или ждать не стоит?))) Спасибо! ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx на mva.name Sun Mar 19 19:46:52 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Mon, 20 Mar 2017 02:46:52 +0700 Subject: =?UTF-8?B?UmU6INCR0YPQtNC10YIg0LvQuCBMVUEgbW9kdWxlINC00L7QsdCw0LLQu9C10L0g?= =?UTF-8?B?0LIgeXVtINGA0LXQv9C+0LfQuNGC0L7RgNC40Lk/?= In-Reply-To: References: Message-ID: <7918077.QEGnISXHgm@note> 1) https://www.lua.org/about.html#name > Please do not write it as "LUA", which is both ugly and confusing, because then it becomes an acronym with different meanings for different people. So, please, write "Lua" right! !!! 2) скорее всего нет, т.к. сообщество разработчиков настроено решительно против него в связи с качеством кода From simpot на simpot.com Sun Mar 19 19:50:15 2017 From: simpot на simpot.com (Dmitry Saratsky) Date: Sun, 19 Mar 2017 19:50:15 +0000 Subject: =?UTF-8?B?UkU6INCR0YPQtNC10YIg0LvQuCBMVUEgbW9kdWxlINC00L7QsdCw0LLQu9C10L0g?= =?UTF-8?B?0LIgeXVtINGA0LXQv9C+0LfQuNGC0L7RgNC40Lk/?= In-Reply-To: <7918077.QEGnISXHgm@note> References: <7918077.QEGnISXHgm@note> Message-ID: 1. Ок, спасибо) 2. жаль( -----Original Message----- From: nginx-ru [mailto:nginx-ru-bounces на nginx.org] On Behalf Of Vadim A. Misbakh-Soloviov Sent: 19-Mar-2017 21:47 To: nginx-ru на nginx.org Subject: Re: Будет ли LUA module добавлен в yum репозиторий? 1) https://www.lua.org/about.html#name > Please do not write it as "LUA", which is both ugly and confusing, > because then it becomes an acronym with different meanings for different people. So, please, write "Lua" right! !!! 2) скорее всего нет, т.к. сообщество разработчиков настроено решительно против него в связи с качеством кода _______________________________________________ nginx-ru mailing list nginx-ru на nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum на forum.nginx.org Mon Mar 20 08:18:59 2017 From: nginx-forum на forum.nginx.org (Archy) Date: Mon, 20 Mar 2017 04:18:59 -0400 Subject: =?UTF-8?B?UmU6INCn0YLQtdC90LjQtSDQvNC10YLQutC4IERvRCBTZWN1cml0eSBPcHRpb24g?= =?UTF-8?B?KFJGQzExMDgp?= In-Reply-To: References: Message-ID: <45bfd19d1d62ded5aa2eac3ee8f8065d.NginxMailingListRussian@forum.nginx.org> Может быть есть возможность просто чтения сырых tcp-пакетов запроса? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273014,273033#msg-273033 From nginx на mva.name Mon Mar 20 08:35:54 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Mon, 20 Mar 2017 15:35:54 +0700 Subject: =?UTF-8?B?UmU6INCn0YLQtdC90LjQtSDQvNC10YLQutC4IERvRCBTZWN1cml0eSBPcHRpb24g?= =?UTF-8?B?KFJGQzExMDgp?= In-Reply-To: <45bfd19d1d62ded5aa2eac3ee8f8065d.NginxMailingListRussian@forum.nginx.org> References: <45bfd19d1d62ded5aa2eac3ee8f8065d.NginxMailingListRussian@forum.nginx.org> Message-ID: <1704686.U2HM0o3nQN@note> Почему вы вообще решили это делать на NginX, а не на... Да на чём угодно, что более узкоспецифично, чем веб-сервер :) From maxim на nginx.com Mon Mar 20 08:45:18 2017 From: maxim на nginx.com (Maxim Konovalov) Date: Mon, 20 Mar 2017 11:45:18 +0300 Subject: =?UTF-8?B?UmU6INCn0YLQtdC90LjQtSDQvNC10YLQutC4IERvRCBTZWN1cml0eSBPcHRpb24g?= =?UTF-8?B?KFJGQzExMDgp?= In-Reply-To: References: Message-ID: <4d8f2127-334c-47f5-5fb5-d384c8d04336@nginx.com> On 3/17/17 8:35 PM, Archy wrote: > Здравствуйте! > > Стоит задача передачи в приложение меток, передаваемых с клиента в поле > опций IPv4 пакета. Метки добавляются по RFC1108 типа > IPOPT_SEC,5,0xAB,03,12 > > Подскажите, куда копать, можно ли сделать на основе существующих модулей > разбор пакета или можно/нужно писать свой модуль? Или может быть даже такая > возможность есть в ядре, а я банально не вижу? > Модуль в ядро + getsockopt в nginx. Ну, если вам в самом деле это надо делать в веб-сервере. -- Maxim Konovalov From nginx-forum на forum.nginx.org Mon Mar 20 08:58:40 2017 From: nginx-forum на forum.nginx.org (Archy) Date: Mon, 20 Mar 2017 04:58:40 -0400 Subject: =?UTF-8?B?UmU6INCn0YLQtdC90LjQtSDQvNC10YLQutC4IERvRCBTZWN1cml0eSBPcHRpb24g?= =?UTF-8?B?KFJGQzExMDgp?= In-Reply-To: <1704686.U2HM0o3nQN@note> References: <1704686.U2HM0o3nQN@note> Message-ID: <770b773873a4a06537d0165887fa32ac.NginxMailingListRussian@forum.nginx.org> Метка приходит с запросом браузера с клиента, при этом на сервере приложение на php. Между php и клиентом стоит NginX потому на него основной взгляд. Имеет смысл какую-то прослойку на 80й порт делать, типа haproxy, а NginX ставить неё? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273014,273036#msg-273036 From nginx-forum на forum.nginx.org Mon Mar 20 09:01:42 2017 From: nginx-forum на forum.nginx.org (Archy) Date: Mon, 20 Mar 2017 05:01:42 -0400 Subject: =?UTF-8?B?UmU6INCn0YLQtdC90LjQtSDQvNC10YLQutC4IERvRCBTZWN1cml0eSBPcHRpb24g?= =?UTF-8?B?KFJGQzExMDgp?= In-Reply-To: <4d8f2127-334c-47f5-5fb5-d384c8d04336@nginx.com> References: <4d8f2127-334c-47f5-5fb5-d384c8d04336@nginx.com> Message-ID: <46ae3d7ef89e22b7650252dddba7c84d.NginxMailingListRussian@forum.nginx.org> Спасибо, ответил вышел по поводу необходимости реализации в nginx, в принципе можно перед ним поставить сервис, но не хотелось велосипедить, вдруг что-то подобное уже есть в коробке. Maxim Konovalov Wrote: ------------------------------------------------------- > On 3/17/17 8:35 PM, Archy wrote: > > Здравствуйте! > > > > Стоит задача передачи в приложение меток, передаваемых с клиента в > поле > > опций IPv4 пакета. Метки добавляются по RFC1108 типа > > IPOPT_SEC,5,0xAB,03,12 > > > > Подскажите, куда копать, можно ли сделать на основе существующих > модулей > > разбор пакета или можно/нужно писать свой модуль? Или может быть > даже такая > > возможность есть в ядре, а я банально не вижу? > > > Модуль в ядро + getsockopt в nginx. Ну, если вам в самом деле это > надо делать в веб-сервере. > > -- > Maxim Konovalov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273014,273037#msg-273037 From bgx на protva.ru Mon Mar 20 09:07:58 2017 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Mon, 20 Mar 2017 12:07:58 +0300 Subject: =?UTF-8?B?UmU6INCn0YLQtdC90LjQtSDQvNC10YLQutC4IERvRCBTZWN1cml0eSBPcHRpb24g?= =?UTF-8?B?KFJGQzExMDgp?= In-Reply-To: <45bfd19d1d62ded5aa2eac3ee8f8065d.NginxMailingListRussian@forum.nginx.org> References: <45bfd19d1d62ded5aa2eac3ee8f8065d.NginxMailingListRussian@forum.nginx.org> Message-ID: <20170320090758.GE6700@protva.ru> On Mon, Mar 20, 2017 at 04:18:59AM -0400, Archy wrote: > Может быть есть возможность просто чтения сырых tcp-пакетов запроса? В nginx? Конечно же нет. Вообще, tcp это абстракция потока данных (stream), приложение tcp не видит никаких пакетов. Передавать на этот уровень информацию по отдельным пакетам было бы довольно странно. Если возникло такое желание, самое время попробовать переосмыслить задачу. Добавить заголовок в http запрос (сквидом, например) мне лично кажется намного проще и легче, нежели добавлять метки к исходящим ip-пакетам. -- Eugene Berdnikov From nginx-forum на forum.nginx.org Mon Mar 20 09:29:58 2017 From: nginx-forum на forum.nginx.org (Archy) Date: Mon, 20 Mar 2017 05:29:58 -0400 Subject: =?UTF-8?B?UmU6INCn0YLQtdC90LjQtSDQvNC10YLQutC4IERvRCBTZWN1cml0eSBPcHRpb24g?= =?UTF-8?B?KFJGQzExMDgp?= In-Reply-To: <20170320090758.GE6700@protva.ru> References: <20170320090758.GE6700@protva.ru> Message-ID: <5643dd5d933af17db048a04eb2152b90.NginxMailingListRussian@forum.nginx.org> Исходящие запросы помечаются не нами, это мандатные метки, добавляемые ОС AstraLinux SE, совместимости с которой мы добиваемся. Так что этот механизм мы поменять к сожалению не можем, только на сервере каким-то образом до nginx или в самом nginx эти метки перевести в http-заголовки или переменные окружения. Evgeniy Berdnikov Wrote: ------------------------------------------------------- > On Mon, Mar 20, 2017 at 04:18:59AM -0400, Archy wrote: > > Может быть есть возможность просто чтения сырых tcp-пакетов запроса? > > В nginx? Конечно же нет. Вообще, tcp это абстракция потока данных > (stream), приложение tcp не видит никаких пакетов. Передавать на этот > уровень информацию по отдельным пакетам было бы довольно странно. > Если > возникло такое желание, самое время попробовать переосмыслить задачу. > Добавить заголовок в http запрос (сквидом, например) мне лично > кажется > намного проще и легче, нежели добавлять метки к исходящим ip-пакетам. > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273014,273039#msg-273039 From nginx-forum на forum.nginx.org Mon Mar 20 12:35:36 2017 From: nginx-forum на forum.nginx.org (malaf) Date: Mon, 20 Mar 2017 08:35:36 -0400 Subject: request reference counter overflow while processing Message-ID: <60ab73af705cb5b2a3cc15761e389d0c.NginxMailingListRussian@forum.nginx.org> Здравствуйте. В error.log наблюдали такие ошибки: [crit] request reference counter overflow while processing "next_subrequest_uri", client: , server: , request: "GET HTTP/1.1", subrequest: "subrequest_uri", host: "", referrer: Подскажите, какое максимальное значение имеет счетчик ссылок? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273042,273042#msg-273042 From mdounin на mdounin.ru Mon Mar 20 13:47:01 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 20 Mar 2017 16:47:01 +0300 Subject: request reference counter overflow while processing In-Reply-To: <60ab73af705cb5b2a3cc15761e389d0c.NginxMailingListRussian@forum.nginx.org> References: <60ab73af705cb5b2a3cc15761e389d0c.NginxMailingListRussian@forum.nginx.org> Message-ID: <20170320134700.GB13617@mdounin.ru> Hello! On Mon, Mar 20, 2017 at 08:35:36AM -0400, malaf wrote: > Здравствуйте. > > В error.log наблюдали такие ошибки: > > [crit] request reference counter overflow while processing > "next_subrequest_uri", client: , server: , request: "GET > HTTP/1.1", subrequest: "subrequest_uri", host: "", referrer: > > > Подскажите, какое максимальное значение имеет счетчик ссылок? Такое сообщение выдаётся, если используется больше 64 тысяч ссылок на запрос. Если вы его видите - вряд ли проблема в максимальном значении, скорее что-то пошло не так. -- Maxim Dounin http://nginx.org/ From gmm на csdoc.com Mon Mar 20 14:41:04 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 20 Mar 2017 16:41:04 +0200 Subject: merge_slashes Message-ID: <9642400a-3809-74bf-ece0-e20439c7f321@csdoc.com> Здравствуйте! Можно ли сделать в директиве merge_slashes параметр redirect, чтобы из урла с несколькими слешами в канонический урл преобразование происходило путем 301 редиректа? SEO-шники пристали, говорят так как сейчас - получается дубль страниц и чтобы дубля не было надо делать редирект вместо простого склеивания. -- Best regards, Gena From pavel2000 на ngs.ru Mon Mar 20 15:02:40 2017 From: pavel2000 на ngs.ru (Pavel V.) Date: Mon, 20 Mar 2017 22:02:40 +0700 Subject: merge_slashes In-Reply-To: <9642400a-3809-74bf-ece0-e20439c7f321@csdoc.com> References: <9642400a-3809-74bf-ece0-e20439c7f321@csdoc.com> Message-ID: <4810636269.20170320220240@ngs.ru> Здравствуйте. Вы писали 20 марта 2017 г., 21:41:04: > Можно ли сделать в директиве merge_slashes параметр redirect, > чтобы из урла с несколькими слешами в канонический урл > преобразование происходило путем 301 редиректа? Локейшном с регуляркой ситуация не разыгрывается? -- С уважением, Pavel mailto:pavel2000 на ngs.ru From nginx-forum на forum.nginx.org Mon Mar 20 15:40:57 2017 From: nginx-forum на forum.nginx.org (BieZax) Date: Mon, 20 Mar 2017 11:40:57 -0400 Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCAg0YEgINC+0LHRgNCw0LHQvtGC0LrQvtC5ICA1MDIg?= =?UTF-8?B?ICDQutC+0LTQsCAg0LIgIHVwc3RyZWFtL2lwIGhhc2g=?= Message-ID: <3c89f9f25a71339f5725ae711d4d8f96.NginxMailingListRussian@forum.nginx.org> Добрый день. Имеется следующий конфиг: location = /abc/auth { internal; proxy_set_header X-CAuth-Realm "Registration"; proxy_set_header X-CAuth-Base "access"; proxy_set_header X-CAuth-Table "users"; proxy_set_header X-CAuth-GField "_S_abc"; proxy_set_header X-CAuth-PassF "password"; client_max_body_size 0; proxy_pass_request_body off; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header Content-Length ""; proxy_set_header X-Original-URI $request_uri; proxy_pass http://127.0.0.1:8079; # тут висит perl демон и авторизует } location /abc/ { auth_request /abc/auth; proxy_set_header Host abc-i1.balhblah.ru; proxy_pass http://abc; proxy_redirect http://abc-i1.blahblah.ru/ /; proxy_redirect http://abc-i2.blahblah.ru/ /; proxy_next_upstream error timeout invalid_header http_500 http_503 http_502 http_504; } ... upstream abc { ip_hash; server abc-i1.blahblah.ru; server abc-i2.blahblah.ru; } Все работает нормально, пока один из бэкендов не начинает отдавать 502 Вот пример лога: logformat '$remote_addr - $remote_user [$time_local] "$request" ' '$status $bytes_sent "$http_referer" ' '"$http_user_agent" "$cookie_CID" "$request_time" "$upstream_response_time" "$upstream_addr" "$upstream_status" "$upstream_http_server"' 2 строчки из лога, идущие подряд: 10.105.5.152 - vasya [20/Mar/2017:17:03:15 +0300] "GET /abc/Account/Login?ReturnUrl=%2Fabc%2F HTTP/1.0" 200 3295 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36" "wmmDEljC0bF6XGXtCV9/Ag==" "10.105.5.152" "0.136" "0.003, 0.113" "10.10.11.72:80, 10.10.11.71:80" "502, 200" "Microsoft-IIS/8.5" 10.105.5.152 - vasya [20/Mar/2017:17:03:16 +0300] "POST /abc/ru-RU/Account/Login?ReturnUrl=%2Fabc%2F HTTP/1.0" 502 713 "https://blahblah.ru/abc/Account/Login?ReturnUrl=%2Fabc%2F" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36" "wmmDEljC0bF6XGXtCV9/Ag==" "0.024" "0.004" "10.10.11.72:80" "502" "Microsoft-IIS/8.5" В error логе при этом пусто. Разве при такой конфигурации фронтенд не должен всегда спрашивать второй сервер, если один из них не отвечает? Почему при одной и тоже конфигурации получается 2 разных реакции? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273046,273046#msg-273046 From medvedev.yp на gmail.com Mon Mar 20 15:44:07 2017 From: medvedev.yp на gmail.com (Yuriy Medvedev) Date: Mon, 20 Mar 2017 18:44:07 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L7QsdGA0LDQsdC+0YLQutC+0LkgNTAy?= =?UTF-8?B?INC60L7QtNCwINCyIHVwc3RyZWFtL2lwIGhhc2g=?= In-Reply-To: <3c89f9f25a71339f5725ae711d4d8f96.NginxMailingListRussian@forum.nginx.org> References: <3c89f9f25a71339f5725ae711d4d8f96.NginxMailingListRussian@forum.nginx.org> Message-ID: Nginx, это пассивные проверки. 20 марта 2017 г., 18:40 пользователь BieZax написал: > Добрый день. > Имеется следующий конфиг: > > location = /abc/auth { > internal; > proxy_set_header X-CAuth-Realm "Registration"; > proxy_set_header X-CAuth-Base "access"; > proxy_set_header X-CAuth-Table "users"; > proxy_set_header X-CAuth-GField "_S_abc"; > proxy_set_header X-CAuth-PassF "password"; > client_max_body_size 0; > proxy_pass_request_body off; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header Host $host; > proxy_set_header Content-Length ""; > proxy_set_header X-Original-URI $request_uri; > proxy_pass http://127.0.0.1:8079; # тут висит perl > демон и > авторизует > } > > location /abc/ { > auth_request /abc/auth; > proxy_set_header Host abc-i1.balhblah.ru; > proxy_pass http://abc; > proxy_redirect http://abc-i1.blahblah.ru/ /; > proxy_redirect http://abc-i2.blahblah.ru/ /; > proxy_next_upstream error timeout invalid_header http_500 > http_503 http_502 http_504; > } > > ... > upstream abc { > ip_hash; > server abc-i1.blahblah.ru; > server abc-i2.blahblah.ru; > } > > Все работает нормально, пока один из бэкендов не начинает > отдавать 502 > > Вот пример лога: > > logformat '$remote_addr - $remote_user [$time_local] "$request" ' '$status > $bytes_sent "$http_referer" ' '"$http_user_agent" "$cookie_CID" > "$request_time" "$upstream_response_time" "$upstream_addr" > "$upstream_status" "$upstream_http_server"' > > 2 строчки из лога, идущие подряд: > 10.105.5.152 - vasya [20/Mar/2017:17:03:15 +0300] "GET > /abc/Account/Login?ReturnUrl=%2Fabc%2F HTTP/1.0" 200 3295 "-" "Mozilla/5.0 > (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 > Safari/537.36" "wmmDEljC0bF6XGXtCV9/Ag==" "10.105.5.152" "0.136" "0.003, > 0.113" "10.10.11.72:80, 10.10.11.71:80" "502, 200" "Microsoft-IIS/8.5" > 10.105.5.152 - vasya [20/Mar/2017:17:03:16 +0300] "POST > /abc/ru-RU/Account/Login?ReturnUrl=%2Fabc%2F HTTP/1.0" 502 713 > "https://blahblah.ru/abc/Account/Login?ReturnUrl=%2Fabc%2F" "Mozilla/5.0 > (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 > Safari/537.36" "wmmDEljC0bF6XGXtCV9/Ag==" "0.024" "0.004" "10.10.11.72:80" > "502" "Microsoft-IIS/8.5" > В error логе при этом пусто. > > Разве при такой конфигурации фронтенд не должен всегда спрашивать > второй сервер, если один из них не отвечает? Почему при одной и тоже > конфигурации получается 2 разных реакции? > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,273046,273046#msg-273046 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon Mar 20 15:53:50 2017 From: nginx-forum на forum.nginx.org (BieZax) Date: Mon, 20 Mar 2017 11:53:50 -0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L7QsdGA0LDQsdC+0YLQutC+0LkgNTAy?= =?UTF-8?B?INC60L7QtNCwINCyIHVwc3RyZWFtL2lwIGhhc2g=?= In-Reply-To: References: Message-ID: <607fecb214e7fe4194f13a0ef94c6b53.NginxMailingListRussian@forum.nginx.org> Не совсем понятно. Т.е. это нормально, что при одной и той же ситуации с разницей в 2 секунды я получаю разное поведение? Yuriy Medvedev Wrote: ------------------------------------------------------- > Nginx, это пассивные проверки. > > 20 марта 2017 г., 18:40 пользователь BieZax > > написал: > > > Добрый день. > > Имеется следующий конфиг: > > > > location = /abc/auth { > > internal; > > proxy_set_header X-CAuth-Realm "Registration"; > > proxy_set_header X-CAuth-Base "access"; > > proxy_set_header X-CAuth-Table "users"; > > proxy_set_header X-CAuth-GField "_S_abc"; > > proxy_set_header X-CAuth-PassF "password"; > > client_max_body_size 0; > > proxy_pass_request_body off; > > proxy_set_header X-Real-IP $remote_addr; > > proxy_set_header Host $host; > > proxy_set_header Content-Length ""; > > proxy_set_header X-Original-URI $request_uri; > > proxy_pass http://127.0.0.1:8079; # тут висит > perl > > демон и > > авторизует > > } > > > > location /abc/ { > > auth_request /abc/auth; > > proxy_set_header Host abc-i1.balhblah.ru; > > proxy_pass http://abc; > > proxy_redirect http://abc-i1.blahblah.ru/ /; > > proxy_redirect http://abc-i2.blahblah.ru/ /; > > proxy_next_upstream error timeout invalid_header > http_500 > > http_503 http_502 http_504; > > } > > > > ... > > upstream abc { > > ip_hash; > > server abc-i1.blahblah.ru; > > server abc-i2.blahblah.ru; > > } > > > > Все работает нормально, пока один из бэкендов не > начинает > > отдавать 502 > > > > Вот пример лога: > > > > logformat '$remote_addr - $remote_user [$time_local] "$request" ' > '$status > > $bytes_sent "$http_referer" ' '"$http_user_agent" "$cookie_CID" > > "$request_time" "$upstream_response_time" "$upstream_addr" > > "$upstream_status" "$upstream_http_server"' > > > > 2 строчки из лога, идущие подряд: > > 10.105.5.152 - vasya [20/Mar/2017:17:03:15 +0300] "GET > > /abc/Account/Login?ReturnUrl=%2Fabc%2F HTTP/1.0" 200 3295 "-" > "Mozilla/5.0 > > (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) > Chrome/56.0.2924.87 > > Safari/537.36" "wmmDEljC0bF6XGXtCV9/Ag==" "10.105.5.152" "0.136" > "0.003, > > 0.113" "10.10.11.72:80, 10.10.11.71:80" "502, 200" > "Microsoft-IIS/8.5" > > 10.105.5.152 - vasya [20/Mar/2017:17:03:16 +0300] "POST > > /abc/ru-RU/Account/Login?ReturnUrl=%2Fabc%2F HTTP/1.0" 502 713 > > "https://blahblah.ru/abc/Account/Login?ReturnUrl=%2Fabc%2F" > "Mozilla/5.0 > > (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) > Chrome/56.0.2924.87 > > Safari/537.36" "wmmDEljC0bF6XGXtCV9/Ag==" "0.024" "0.004" > "10.10.11.72:80" > > "502" "Microsoft-IIS/8.5" > > В error логе при этом пусто. > > > > Разве при такой конфигурации фронтенд не должен всегда > спрашивать > > второй сервер, если один из них не отвечает? Почему при одной > и тоже > > конфигурации получается 2 разных реакции? > > > > Posted at Nginx Forum: https://forum.nginx.org/read. > > php?21,273046,273046#msg-273046 > > > > _______________________________________________ > > 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 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273047,273048#msg-273048 From mdounin на mdounin.ru Mon Mar 20 16:13:30 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 20 Mar 2017 19:13:30 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAgINGBICDQvtCx0YDQsNCx0L7RgtC60L7QuSAg?= =?UTF-8?B?NTAyICAg0LrQvtC00LAgINCyICB1cHN0cmVhbS9pcCBoYXNo?= In-Reply-To: <3c89f9f25a71339f5725ae711d4d8f96.NginxMailingListRussian@forum.nginx.org> References: <3c89f9f25a71339f5725ae711d4d8f96.NginxMailingListRussian@forum.nginx.org> Message-ID: <20170320161330.GC13617@mdounin.ru> Hello! On Mon, Mar 20, 2017 at 11:40:57AM -0400, BieZax wrote: [...] > proxy_next_upstream error timeout invalid_header http_500 > http_503 http_502 http_504; [...] > 2 строчки из лога, идущие подряд: > 10.105.5.152 - vasya [20/Mar/2017:17:03:15 +0300] "GET > /abc/Account/Login?ReturnUrl=%2Fabc%2F HTTP/1.0" 200 3295 "-" "Mozilla/5.0 > (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 > Safari/537.36" "wmmDEljC0bF6XGXtCV9/Ag==" "10.105.5.152" "0.136" "0.003, > 0.113" "10.10.11.72:80, 10.10.11.71:80" "502, 200" "Microsoft-IIS/8.5" > 10.105.5.152 - vasya [20/Mar/2017:17:03:16 +0300] "POST > /abc/ru-RU/Account/Login?ReturnUrl=%2Fabc%2F HTTP/1.0" 502 713 > "https://blahblah.ru/abc/Account/Login?ReturnUrl=%2Fabc%2F" "Mozilla/5.0 > (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 > Safari/537.36" "wmmDEljC0bF6XGXtCV9/Ag==" "0.024" "0.004" "10.10.11.72:80" > "502" "Microsoft-IIS/8.5" > В error логе при этом пусто. > > Разве при такой конфигурации фронтенд не должен всегда спрашивать > второй сервер, если один из них не отвечает? Почему при одной и тоже > конфигурации получается 2 разных реакции? Проблема в том, что второй запрос - это POST. POST - неидемпотентный метод, и по умолчанию POST-запросы nginx не повторяет, если запрос уже был отправлен на бекенд. Если хочется, чтобы повторял, надо использовать "proxy_next_upstream ... non_idempotent". Ну и помнить при этом, что некоторые бекенды могут оказаться к такому не готовы. Подробнее тут: http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#non_idempotent -- Maxim Dounin http://nginx.org/ From skobolo на gmail.com Mon Mar 20 16:15:13 2017 From: skobolo на gmail.com (SK) Date: Mon, 20 Mar 2017 19:15:13 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L7QsdGA0LDQsdC+0YLQutC+0LkgNTAy?= =?UTF-8?B?INC60L7QtNCwINCyIHVwc3RyZWFtL2lwIGhhc2g=?= In-Reply-To: <607fecb214e7fe4194f13a0ef94c6b53.NginxMailingListRussian@forum.nginx.org> References: <607fecb214e7fe4194f13a0ef94c6b53.NginxMailingListRussian@forum.nginx.org> Message-ID: На втором запросе — POST. См non_idempotent директиву, чтобы отправлять post-запросы кросс-апстрим SK > 20 марта 2017 г., в 18:53, BieZax написал(а): > > Не совсем понятно. Т.е. это нормально, что при одной и той же > ситуации с разницей в 2 секунды я получаю разное поведение? > Yuriy Medvedev Wrote: > ------------------------------------------------------- >> Nginx, это пассивные проверки. >> >> 20 марта 2017 г., 18:40 пользователь BieZax >> >> написал: >> >>> Добрый день. >>> Имеется следующий конфиг: >>> >>> location = /abc/auth { >>> internal; >>> proxy_set_header X-CAuth-Realm "Registration"; >>> proxy_set_header X-CAuth-Base "access"; >>> proxy_set_header X-CAuth-Table "users"; >>> proxy_set_header X-CAuth-GField "_S_abc"; >>> proxy_set_header X-CAuth-PassF "password"; >>> client_max_body_size 0; >>> proxy_pass_request_body off; >>> proxy_set_header X-Real-IP $remote_addr; >>> proxy_set_header Host $host; >>> proxy_set_header Content-Length ""; >>> proxy_set_header X-Original-URI $request_uri; >>> proxy_pass http://127.0.0.1:8079; # тут висит >> perl >>> демон и >>> авторизует >>> } >>> >>> location /abc/ { >>> auth_request /abc/auth; >>> proxy_set_header Host abc-i1.balhblah.ru; >>> proxy_pass http://abc; >>> proxy_redirect http://abc-i1.blahblah.ru/ /; >>> proxy_redirect http://abc-i2.blahblah.ru/ /; >>> proxy_next_upstream error timeout invalid_header >> http_500 >>> http_503 http_502 http_504; >>> } >>> >>> ... >>> upstream abc { >>> ip_hash; >>> server abc-i1.blahblah.ru; >>> server abc-i2.blahblah.ru; >>> } >>> >>> Все работает нормально, пока один из бэкендов не >> начинает >>> отдавать 502 >>> >>> Вот пример лога: >>> >>> logformat '$remote_addr - $remote_user [$time_local] "$request" ' >> '$status >>> $bytes_sent "$http_referer" ' '"$http_user_agent" "$cookie_CID" >>> "$request_time" "$upstream_response_time" "$upstream_addr" >>> "$upstream_status" "$upstream_http_server"' >>> >>> 2 строчки из лога, идущие подряд: >>> 10.105.5.152 - vasya [20/Mar/2017:17:03:15 +0300] "GET >>> /abc/Account/Login?ReturnUrl=%2Fabc%2F HTTP/1.0" 200 3295 "-" >> "Mozilla/5.0 >>> (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) >> Chrome/56.0.2924.87 >>> Safari/537.36" "wmmDEljC0bF6XGXtCV9/Ag==" "10.105.5.152" "0.136" >> "0.003, >>> 0.113" "10.10.11.72:80, 10.10.11.71:80" "502, 200" >> "Microsoft-IIS/8.5" >>> 10.105.5.152 - vasya [20/Mar/2017:17:03:16 +0300] "POST >>> /abc/ru-RU/Account/Login?ReturnUrl=%2Fabc%2F HTTP/1.0" 502 713 >>> "https://blahblah.ru/abc/Account/Login?ReturnUrl=%2Fabc%2F" >> "Mozilla/5.0 >>> (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) >> Chrome/56.0.2924.87 >>> Safari/537.36" "wmmDEljC0bF6XGXtCV9/Ag==" "0.024" "0.004" >> "10.10.11.72:80" >>> "502" "Microsoft-IIS/8.5" >>> В error логе при этом пусто. >>> >>> Разве при такой конфигурации фронтенд не должен всегда >> спрашивать >>> второй сервер, если один из них не отвечает? Почему при одной >> и тоже >>> конфигурации получается 2 разных реакции? >>> >>> Posted at Nginx Forum: https://forum.nginx.org/read. >>> php?21,273046,273046#msg-273046 >>> >>> _______________________________________________ >>> 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 > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273047,273048#msg-273048 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From chipitsine на gmail.com Mon Mar 20 16:21:08 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 20 Mar 2017 21:21:08 +0500 Subject: merge_slashes In-Reply-To: <9642400a-3809-74bf-ece0-e20439c7f321@csdoc.com> References: <9642400a-3809-74bf-ece0-e20439c7f321@csdoc.com> Message-ID: проще отключить merge и разруливать уже в приложении 20 марта 2017 г., 19:41 пользователь Gena Makhomed написал: > Здравствуйте! > > Можно ли сделать в директиве merge_slashes параметр redirect, > чтобы из урла с несколькими слешами в канонический урл > преобразование происходило путем 301 редиректа? > > SEO-шники пристали, говорят так как сейчас - получается дубль страниц > и чтобы дубля не было надо делать редирект вместо простого склеивания. > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Mon Mar 20 16:51:00 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 20 Mar 2017 18:51:00 +0200 Subject: merge_slashes In-Reply-To: References: <9642400a-3809-74bf-ece0-e20439c7f321@csdoc.com> Message-ID: <012c4737-9635-8a0d-9c91-fdd065bb33cd@csdoc.com> On 20.03.2017 18:21, Илья Шипицин wrote: > проще отключить merge и разруливать уже в приложении отключать merge_slashes нельзя, тогда сломается вся логика работы: http://nginx.org/ru/docs/http/ngx_http_core_module.html#merge_slashes On 20.03.2017 17:02, Pavel V. wrote: > Локейшном с регуляркой ситуация не разыгрывается? теоретически да, но получается достаточно криво в результате: http://stackoverflow.com/questions/14832780/nginx-merge-slashes-redirect P.S. тема с merge_slashes redirect достаточно популярная, странно что это до сих пор еще никто не реализовал в nginx. -- Best regards, Gena From chipitsine на gmail.com Mon Mar 20 16:57:14 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 20 Mar 2017 21:57:14 +0500 Subject: merge_slashes In-Reply-To: <012c4737-9635-8a0d-9c91-fdd065bb33cd@csdoc.com> References: <9642400a-3809-74bf-ece0-e20439c7f321@csdoc.com> <012c4737-9635-8a0d-9c91-fdd065bb33cd@csdoc.com> Message-ID: 20 марта 2017 г., 21:51 пользователь Gena Makhomed написал: > > On 20.03.2017 18:21, Илья Шипицин wrote: > > проще отключить merge и разруливать уже в приложении >> > > отключать merge_slashes нельзя, тогда сломается вся логика работы: > http://nginx.org/ru/docs/http/ngx_http_core_module.html#merge_slashes сломается только, если у вас используются префиксные локейшены. если, например, один локейшен "/", то нет > > > On 20.03.2017 17:02, Pavel V. wrote: > > > Локейшном с регуляркой ситуация не разыгрывается? > > теоретически да, но получается достаточно криво в результате: > http://stackoverflow.com/questions/14832780/nginx-merge-slashes-redirect > > P.S. > > тема с merge_slashes redirect достаточно популярная, > странно что это до сих пор еще никто не реализовал в nginx. какой-нибудь rewrite_by_lua ? или аналог на nginScript > > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx на mva.name Mon Mar 20 16:57:46 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Mon, 20 Mar 2017 23:57:46 +0700 Subject: merge_slashes In-Reply-To: <012c4737-9635-8a0d-9c91-fdd065bb33cd@csdoc.com> References: <9642400a-3809-74bf-ece0-e20439c7f321@csdoc.com> <012c4737-9635-8a0d-9c91-fdd065bb33cd@csdoc.com> Message-ID: <11154211.gE8FHxvta6@note> > тема с merge_slashes redirect достаточно популярная, > странно что это до сих пор еще никто не реализовал в nginx. На самом деле это попахивает недопониманием некоторыми "SEO'шниками" реальных алгоритмов работы поисковиков (собственно, а откуда бы им их понимать, если не они их разрабатывали). На сколько я могу судить (может я что-то делал не так), но гугл и яндекс не настолько тупые, чтобы не смочь смерджить слеши при обработке и понять что это одна страница. Ну и отдельный вопрос как вообще ссылки с кучей слешей становятся известны поисковикам. From chipitsine на gmail.com Mon Mar 20 17:01:26 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 20 Mar 2017 22:01:26 +0500 Subject: merge_slashes In-Reply-To: <11154211.gE8FHxvta6@note> References: <9642400a-3809-74bf-ece0-e20439c7f321@csdoc.com> <012c4737-9635-8a0d-9c91-fdd065bb33cd@csdoc.com> <11154211.gE8FHxvta6@note> Message-ID: 20 марта 2017 г., 21:57 пользователь Vadim A. Misbakh-Soloviov < nginx на mva.name> написал: > > тема с merge_slashes redirect достаточно популярная, > > странно что это до сих пор еще никто не реализовал в nginx. > > На самом деле это попахивает недопониманием некоторыми "SEO'шниками" > реальных > алгоритмов работы поисковиков (собственно, а откуда бы им их понимать, > если не > они их разрабатывали). > SEO-шники вообще на своей волне. из опыта - не самым плохим решением является поставить apache (за nginx), и дать SEO-шникам возможность на .htaccess пилить правила mod_rewrite > > На сколько я могу судить (может я что-то делал не так), но гугл и яндекс не > настолько тупые, чтобы не смочь смерджить слеши при обработке и понять что > это > одна страница. > > > Ну и отдельный вопрос как вообще ссылки с кучей слешей становятся известны > поисковикам. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Mon Mar 20 17:06:10 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 20 Mar 2017 19:06:10 +0200 Subject: merge_slashes In-Reply-To: References: <9642400a-3809-74bf-ece0-e20439c7f321@csdoc.com> <012c4737-9635-8a0d-9c91-fdd065bb33cd@csdoc.com> Message-ID: On 20.03.2017 18:57, Илья Шипицин wrote: >>> проще отключить merge и разруливать уже в приложении >> отключать merge_slashes нельзя, тогда сломается вся логика работы: >> http://nginx.org/ru/docs/http/ngx_http_core_module.html#merge_slashes > сломается только, если у вас используются префиксные локейшены. префиксные локейшены используются, поэтому merge_slashes off не подходит >>> Локейшном с регуляркой ситуация не разыгрывается? >> тема с merge_slashes redirect достаточно популярная, >> странно что это до сих пор еще никто не реализовал в nginx. > какой-нибудь rewrite_by_lua ? или аналог на nginScript как оказалось, можно и просто "программированием на конфигах nginx": # remove multiple sequences of forward slashes # The $uri variable with have duplicate slashes removed by default via [merge_slashes on] - just need to rewrite back to $uri # note: use of the "^[^?]*?" pattern avoids any matches in the querystring section of URI - which would cause an infinite redirect loop if ($request_uri ~ "^[^?]*?//") { rewrite "^" $scheme://$host$uri permanent; } но добавлять этот фрагмент кода в каждый сайт... нет ли проще варианта? например, сделать merge_slashes redirect значением по умолчанию? -- Best regards, Gena From chipitsine на gmail.com Mon Mar 20 17:09:41 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 20 Mar 2017 22:09:41 +0500 Subject: merge_slashes In-Reply-To: References: <9642400a-3809-74bf-ece0-e20439c7f321@csdoc.com> <012c4737-9635-8a0d-9c91-fdd065bb33cd@csdoc.com> Message-ID: 20 марта 2017 г., 22:06 пользователь Gena Makhomed написал: > On 20.03.2017 18:57, Илья Шипицин wrote: > > проще отключить merge и разруливать уже в приложении >>>> >>> > отключать merge_slashes нельзя, тогда сломается вся логика работы: >>> http://nginx.org/ru/docs/http/ngx_http_core_module.html#merge_slashes >>> >> > сломается только, если у вас используются префиксные локейшены. >> > > префиксные локейшены используются, поэтому merge_slashes off не подходит > > Локейшном с регуляркой ситуация не разыгрывается? >>>> >>> > тема с merge_slashes redirect достаточно популярная, >>> странно что это до сих пор еще никто не реализовал в nginx. >>> >> > какой-нибудь rewrite_by_lua ? или аналог на nginScript >> > > как оказалось, можно и просто "программированием на конфигах nginx": > > # remove multiple sequences of forward slashes > # The $uri variable with have duplicate slashes removed by default via > [merge_slashes on] - just need to rewrite back to $uri > # note: use of the "^[^?]*?" pattern avoids any matches in the querystring > section of URI - which would cause an infinite redirect loop > if ($request_uri ~ "^[^?]*?//") { > rewrite "^" $scheme://$host$uri permanent; > } > > но добавлять этот фрагмент кода в каждый сайт... нет ли проще варианта? > > например, сделать merge_slashes redirect значением по умолчанию? это очень печальная тема - менять поведение по умолчанию. имхо, хорошим дизайном является оставить как есть + сделать крутилку, для тех, кто хочет по-другому > > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From me на kemko.ru Mon Mar 20 17:37:03 2017 From: me на kemko.ru (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JDQvdC00YDQtdC10LI=?=) Date: Mon, 20 Mar 2017 17:37:03 +0000 Subject: merge_slashes In-Reply-To: References: <9642400a-3809-74bf-ece0-e20439c7f321@csdoc.com> <012c4737-9635-8a0d-9c91-fdd065bb33cd@csdoc.com> Message-ID: А что мешает сеошникам воспользоваться сеошными методами и прописать в robots.txt что-то вроде Disallow: *//* ? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Mar 21 08:17:42 2017 From: nginx-forum на forum.nginx.org (BieZax) Date: Tue, 21 Mar 2017 04:17:42 -0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAgINGBICDQvtCx0YDQsNCx0L7RgtC60L7QuSAg?= =?UTF-8?B?NTAyICAg0LrQvtC00LAgINCyICB1cHN0cmVhbS9pcCBoYXNo?= In-Reply-To: <20170320161330.GC13617@mdounin.ru> References: <20170320161330.GC13617@mdounin.ru> Message-ID: <429bcca86654d8e7b4cf303a58e56680.NginxMailingListRussian@forum.nginx.org> Спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273049,273069#msg-273069 From mdounin на mdounin.ru Tue Mar 21 15:19:04 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 21 Mar 2017 18:19:04 +0300 Subject: nginx-1.11.11 Message-ID: <20170321151904.GJ13617@mdounin.ru> Изменения в nginx 1.11.11 21.03.2017 *) Добавление: директива worker_shutdown_timeout. *) Добавление: улучшения в скриптах подсветки синтаксиса для vim. Спасибо Wei-Ko Kao. *) Исправление: при попытке установить переменную $limit_rate в пустую строку в рабочем процессе мог произойти segmentation fault. *) Исправление: директивы proxy_cache_background_update, fastcgi_cache_background_update, scgi_cache_background_update и uwsgi_cache_background_update могли работать некорректно, если использовалась директива if. *) Исправление: в рабочем процессе мог произойти segmentation fault, если количество large_client_header_buffers в виртуальном сервере отличалось от такового в сервере по умолчанию. *) Исправление: в почтовом прокси-сервере. -- Maxim Dounin http://nginx.org/ From nginx на mva.name Tue Mar 21 17:50:44 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Wed, 22 Mar 2017 00:50:44 +0700 Subject: nginx-1.11.11 In-Reply-To: <20170321151904.GJ13617@mdounin.ru> References: <20170321151904.GJ13617@mdounin.ru> Message-ID: <4989493.S9Kr5P0XXh@note> В письме от вторник, 21 марта 2017 г. 22:19:04 +07 пользователь Maxim Dounin написал: > *) Добавление: улучшения в скриптах подсветки синтаксиса для vim. > Спасибо Wei-Ko Kao. А можно вот про это поподробнее? А то я как раз хотел пожаловаться, что какая-то релиска там придумала делать `iskeyword+=/`, из-за чего пути в соответствующих директивах редактировать не очень удобно :) Если исправили именно это, то это очень даже замечательно :) From mdounin на mdounin.ru Tue Mar 21 18:20:40 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 21 Mar 2017 21:20:40 +0300 Subject: nginx-1.11.11 In-Reply-To: <4989493.S9Kr5P0XXh@note> References: <20170321151904.GJ13617@mdounin.ru> <4989493.S9Kr5P0XXh@note> Message-ID: <20170321182040.GM13617@mdounin.ru> Hello! On Wed, Mar 22, 2017 at 12:50:44AM +0700, Vadim A. Misbakh-Soloviov wrote: > В письме от вторник, 21 марта 2017 г. 22:19:04 +07 пользователь Maxim Dounin > написал: > > *) Добавление: улучшения в скриптах подсветки синтаксиса для vim. > > Спасибо Wei-Ko Kao. > > А можно вот про это поподробнее? > А то я как раз хотел пожаловаться, что какая-то релиска там придумала делать > `iskeyword+=/`, из-за чего пути в соответствующих директивах редактировать не > очень удобно :) > > Если исправили именно это, то это очень даже замечательно :) Эту часть он ещё не донёс, но собирался. -- Maxim Dounin http://nginx.org/ From allogany на mail.ru Wed Mar 22 12:05:33 2017 From: allogany на mail.ru (=?UTF-8?B?TUM=?=) Date: Wed, 22 Mar 2017 15:05:33 +0300 Subject: =?UTF-8?B?UmU6INCU0LDQudC00LbQtdGB0YIg0YHQv9C40YHQutCwINGA0LDRgdGB0YvQu9C6?= =?UTF-8?B?0LggbmdpbngtcnU7INGC0L7QvCA4OSwg0LLRi9C/0YPRgdC6IDI0?= In-Reply-To: References: Message-ID: <1490184333.299973588@f363.i.mail.ru> help отписаться >Среда, 22 марта 2017, 15:00 +03:00 от nginx-ru-request на nginx.org: > >Сообщения, предназначенные для списка >рассылки 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. nginx-1.11.11 (Maxim Dounin) >   2. Re: nginx-1.11.11 (Vadim A. Misbakh-Soloviov) >   3. Re: nginx-1.11.11 (Maxim Dounin) >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru  ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vladget на gmail.com Thu Mar 23 16:18:21 2017 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Thu, 23 Mar 2017 18:18:21 +0200 Subject: =?UTF-8?B?cHJveHlfc2V0X2hlYWRlciDQuCDQvdCw0YHQu9C10LTQuNC1?= Message-ID: Доброе время суток! С этим proxy_set_header какой-то АД: 1) Почему proxy_set_header дикректива уровнем ниже перетирает ВСЕ proxy_set_header уровнем выше, а не только тот хедер который ресетишь? 2) Если делаешь proxy_set_header дважды (иногда пересекается из-за include), то получаешь два хедера в HTTP запросе(от чего некоторые backends сходят с ума, когда видят два хедера Host(например). Почему не брать значение из последнего proxy_set_header? Поймите правильно, не хочется писать proxy_set_header в каждом (вложенном тоже?) локейшене, а использовать наследие. Спасибо за внимание, извините за непонимание :) -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Mar 23 16:41:18 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 23 Mar 2017 21:41:18 +0500 Subject: =?UTF-8?B?UmU6IHByb3h5X3NldF9oZWFkZXIg0Lgg0L3QsNGB0LvQtdC00LjQtQ==?= In-Reply-To: References: Message-ID: 23 марта 2017 г., 21:18 пользователь Vladimir Getmanshchuk < vladget на gmail.com> написал: > Доброе время суток! > > С этим proxy_set_header какой-то АД: > > 1) Почему proxy_set_header дикректива уровнем ниже перетирает ВСЕ > proxy_set_header уровнем выше, а не только тот хедер который ресетишь? > а для вложенных локейшенов ? > > 2) Если делаешь proxy_set_header дважды (иногда пересекается из-за > include), то получаешь два хедера в HTTP запросе(от чего некоторые backends > сходят с ума, когда видят два хедера Host(например). > Почему не брать значение из последнего proxy_set_header? > > Поймите правильно, не хочется писать proxy_set_header в каждом (вложенном > тоже?) локейшене, а использовать наследие. > > Спасибо за внимание, извините за непонимание :) > > -- > Yours sincerely, > Vladimir Getmanshchuk > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Mar 23 17:00:28 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 23 Mar 2017 20:00:28 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5X3NldF9oZWFkZXIg0Lgg0L3QsNGB0LvQtdC00LjQtQ==?= In-Reply-To: References: Message-ID: <20170323170028.GZ13617@mdounin.ru> Hello! On Thu, Mar 23, 2017 at 06:18:21PM +0200, Vladimir Getmanshchuk wrote: > Доброе время суток! > > С этим proxy_set_header какой-то АД: > > 1) Почему proxy_set_header дикректива уровнем ниже перетирает ВСЕ > proxy_set_header уровнем выше, а не только тот хедер который ресетишь? Так работает всё наследование всех директив в nginx'е. Если вы задаёте что-то на каком-то уровне конфигурации, то наследования с предыдущих уровней - не будет. Так сделано по ряду причин. И не в последнюю очередь потому, что такие конфигурации читать проще - если вы видите, что что-то явно написано, не надо думать, какие ещё чудеса прилетят с других уровней и что будет в итоге. Документация о таком поведение - явно говорит, http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_set_header: : Директивы наследуются с предыдущего уровня при условии, что на : данном уровне не описаны свои директивы proxy_set_header. Не стоит удивляться такому поведению. Вместо этого - стоит его понять и пользоваться преимуществами. > 2) Если делаешь proxy_set_header дважды (иногда пересекается из-за > include), то получаешь два хедера в HTTP запросе(от чего некоторые backends > сходят с ума, когда видят два хедера Host(например). > Почему не брать значение из последнего proxy_set_header? В HTTP вполне допустимо использование нескольких одинаковых заголовков, более того - явно специфицировано, когда можно, а когда - нельзя, и как трактовать. И во многих случаях это используется. Было бы странно ограничивать людей в том, что они могут написать в конфиге, причём совсем не так, как специфицирует используемый протокол. > Поймите правильно, не хочется писать proxy_set_header в каждом (вложенном > тоже?) локейшене, а использовать наследие. Не пишите, кто же вас заставляет. В случае правильно и грамотно написанной конфигурации - обычно хватает одного набора директив proxy_set_header на уровне http, возможно - с отдельными вкраплениями "специальных" наборов. Если очень нужно вносить локальные изменения в конкретных location'ах - можно использовать директиву include с неким базовым набором, дополняя его по необходимости. Но если вы регулярно сталкиваетесь с подобной проблемой - скорее всего вы что-то делаете не так. -- Maxim Dounin http://nginx.org/ From public-mail на alekciy.ru Thu Mar 23 19:51:44 2017 From: public-mail на alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Thu, 23 Mar 2017 23:51:44 +0400 Subject: nginx-1.11.11 In-Reply-To: <20170321151904.GJ13617@mdounin.ru> References: <20170321151904.GJ13617@mdounin.ru> Message-ID: > *) Добавление: улучшения в скриптах подсветки синтаксиса для vim. А речь про этот файл: https://trac.nginx.org/nginx/browser/nginx/contrib/vim/syntax/nginx.vim ? Я правильно понимаю, что это эволюция вот этого http://www.vim.org/scripts/script.php?script_id=1886 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum на forum.nginx.org Fri Mar 24 09:38:21 2017 From: nginx-forum на forum.nginx.org (IvanMiller) Date: Fri, 24 Mar 2017 05:38:21 -0400 Subject: access log to syslog Message-ID: <81fcff159a8620677b3d5659139d5db5.NginxMailingListRussian@forum.nginx.org> Добрый день. nginx1.11 Вот хочу access log писать на syslog сервер и оставлять локально. Делаю так access_log /var/log/nginx/access_conf.log main if=$confirm; access_log syslog:server=192.168.201.12,facility=local7,tag=nginx,severity=info; или так. access_log /var/log/nginx/access_conf.log main if=$confirm; access_log syslog:server=192.168.201.12,facility=local7,tag=nginx,severity=info main if=$confirm; до сервака не долетает ничего. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273150,273150#msg-273150 From mail на void.so Fri Mar 24 09:44:10 2017 From: mail на void.so (Pavel Balaev) Date: Fri, 24 Mar 2017 12:44:10 +0300 Subject: =?UTF-8?B?0KPQutCw0LfQsNGC0LXQu9GMINC90LAg0L/RgNC+0LjQt9Cy0L7Qu9GM0L3Ri9C1?= =?UTF-8?B?INC00LDQvdC90YvQtSDQsiDRgdGC0YDRg9C60YLRg9GA0LUgbmd4X2Nvbm5l?= =?UTF-8?B?Y3Rpb25fcw==?= Message-ID: <20170324094410.GB7140@rnd.localhost> Добрый день. Я пытаюсь написать модуль, который должен хранить некоторые произвольные данные на протяжении времени жизни сессии (keep-alive). В структуре ngx_connection_s есть пул памяти, при первом реквесте я аллоцирую память для ctx = ngx_pcalloc(r->connection->pool,..., но проблема в том, что полученный адрес негде прикрепить. Локально я пропатчил структуру ngx_connection_s и сохраняю указатель в r->connection->ctx. У меня есть подозрения, что я делаю что-то не так. From nginx-forum на forum.nginx.org Fri Mar 24 10:55:41 2017 From: nginx-forum на forum.nginx.org (Kacblm) Date: Fri, 24 Mar 2017 06:55:41 -0400 Subject: =?UTF-8?B?bmdpbngtbGRhcC1hdXRoINC/0L7QvNC+0LPQuNGC0LUg0YEg0L3QsNGB0YLRgNC+?= =?UTF-8?B?0LnQutC+0Lkg0L/QvtC20LDQu9GD0LnRgdGC0LA=?= Message-ID: <542a249c5d4e499dac5fea8d19046795.NginxMailingListRussian@forum.nginx.org> Добрый день. Подскажите пожалуйста как правильно настроить авторизацию через LDAP Делаю по инструкции : https://www.nginx.com/blog/nginx-plus-authenticate-users/ Подключаюсь к AD на Windows Server 2008 R2. При правильно логине и пароле получаю следующую ошибку: localhost - testnginx [24/Mar/2017 10:06:32] "GET /auth-proxy HTTP/1.0" 401 - localhost - - [24/Mar/2017 10:06:32] using username/password from cookie nginxauth localhost - testnginx [24/Mar/2017 10:06:32] Error while binding as search user: {'info': '80090308: LdapErr: DSID-0C0903A8, comment: AcceptSecurityContext error, data 52e, v1db1', 'desc': 'Invalid credentials'}, server="ldap://172.16.1.9:389", login="testnginx" localhost - testnginx [24/Mar/2017 10:06:32] "GET /auth-proxy HTTP/1.0" 401 - Если закомментирую строчки proxy_set_header X-Ldap-BindDN и proxy_set_header X-Ldap-BindPass получаю: localhost - testnginx [24/Mar/2017 10:04:54] "GET /auth-proxy HTTP/1.0" 401 - localhost - - [24/Mar/2017 10:04:54] using username/password from cookie nginxauth localhost - testnginx [24/Mar/2017 10:04:54] searching on server "ldap://172.16.1.9:389" with base dn "DC=cstest,DC=local" with filter "(SAMAccountName=testnginx )" localhost - testnginx [24/Mar/2017 10:04:54] Error while running search query: {'info': '000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1', 'desc': 'Operations error'}, server="ldap://172.16.1.9:389", login="testnginx " localhost - testnginx [24/Mar/2017 10:04:54] "GET /auth-proxy HTTP/1.0" 401 - Логины правильные, смущает может я не правильно указал X-Ldap-BaseDN и X-Ldap-BindDN И ещё, а какой метонд аутентификации использует модуль? Не Simple Authentication and Security Layer? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273152,273152#msg-273152 From mdounin на mdounin.ru Fri Mar 24 12:01:32 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 24 Mar 2017 15:01:32 +0300 Subject: nginx-1.11.11 In-Reply-To: References: <20170321151904.GJ13617@mdounin.ru> Message-ID: <20170324120132.GC13617@mdounin.ru> Hello! On Thu, Mar 23, 2017 at 11:51:44PM +0400, Алексей Сундуков wrote: > > *) Добавление: улучшения в скриптах подсветки синтаксиса для vim. > А речь про этот файл: > https://trac.nginx.org/nginx/browser/nginx/contrib/vim/syntax/nginx.vim ? > Я правильно понимаю, что это эволюция вот этого > http://www.vim.org/scripts/script.php?script_id=1886 ? Да, nginx 1.5.8: *) Feature: vim syntax highlighting scripts were added to contrib. Thanks to Evan Miller. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Fri Mar 24 12:20:45 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 24 Mar 2017 15:20:45 +0300 Subject: =?UTF-8?B?UmU6INCj0LrQsNC30LDRgtC10LvRjCDQvdCwINC/0YDQvtC40LfQstC+0LvRjNC9?= =?UTF-8?B?0YvQtSDQtNCw0L3QvdGL0LUg0LIg0YHRgtGA0YPQutGC0YPRgNC1IG5neF9j?= =?UTF-8?B?b25uZWN0aW9uX3M=?= In-Reply-To: <20170324094410.GB7140@rnd.localhost> References: <20170324094410.GB7140@rnd.localhost> Message-ID: <20170324122045.GD13617@mdounin.ru> Hello! On Fri, Mar 24, 2017 at 12:44:10PM +0300, Pavel Balaev wrote: > Добрый день. > > Я пытаюсь написать модуль, который должен хранить некоторые произвольные > данные на протяжении времени жизни сессии (keep-alive). В структуре ngx_connection_s есть > пул памяти, при первом реквесте я аллоцирую память для ctx = > ngx_pcalloc(r->connection->pool,..., но проблема в том, что полученный > адрес негде прикрепить. Локально я пропатчил структуру ngx_connection_s и сохраняю > указатель в r->connection->ctx. У меня есть подозрения, что я делаю > что-то не так. Лучше всего - не пытаться ничего хранить "на протяжении времени жизни сессии", вас ждут сюрпризы с тем, когда именно и по каким причинам соеденение может закрываться, а равно с тем, какие именно запросы могут присутствовать в одном соединении. Протокол HTTP не предусматривает какой-либо зависимости от соединения, и не надо её вводить - а то получится, как у MS NTLM-авторизацией для HTTP: вроде и есть, но противоречит протоколу, и в любых конфигурациях, отличных от тривиальных, скорее не работает, чем работает. Если изложенное выше вас не переубедило, и вы хорошо понимаете, зачем вам хранить данные именно в соединении - то это можно сделать в форме pool cleanup handler'а: добавить свой cleanup handler с помощью ngx_pool_cleanup_add(), а при необходимости получить данные обратно - найти его в списке c->pool->cleanup. Пример подобного хранения данных (правда, в пуле запроса, а не соединения) можно посмотреть, например, в модуле realip. -- Maxim Dounin http://nginx.org/ From vladget на gmail.com Fri Mar 24 13:32:41 2017 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Fri, 24 Mar 2017 15:32:41 +0200 Subject: =?UTF-8?B?UmU6IHByb3h5X3NldF9oZWFkZXIg0Lgg0L3QsNGB0LvQtdC00LjQtQ==?= In-Reply-To: <20170323170028.GZ13617@mdounin.ru> References: <20170323170028.GZ13617@mdounin.ru> Message-ID: Hi! 2017-03-23 19:00 GMT+02:00 Maxim Dounin : > Hello! > Спасибо за скорый и развернутый ответ. > Документация о таком поведение - явно говорит, > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_set_header: > > : Директивы наследуются с предыдущего уровня при условии, что на > : данном уровне не описаны свои директивы proxy_set_header. > > Не стоит удивляться такому поведению. Вместо этого - стоит его > понять и пользоваться преимуществами. > Читал. > > > 2) Если делаешь proxy_set_header дважды (иногда пересекается из-за > > include), то получаешь два хедера в HTTP запросе(от чего некоторые > backends > > сходят с ума, когда видят два хедера Host(например). > > Почему не брать значение из последнего proxy_set_header? > > В HTTP вполне допустимо использование нескольких одинаковых > заголовков, более того - явно специфицировано, когда можно, а > когда - нельзя, и как трактовать. И во многих случаях это > используется. > > Было бы странно ограничивать людей в том, что они могут написать в > конфиге, причём совсем не так, как специфицирует используемый > протокол. > А какое из значений двух хедеров "Host" будет использовать NGINX для определения server_name? > > > Поймите правильно, не хочется писать proxy_set_header в каждом (вложенном > > тоже?) локейшене, а использовать наследие. > > Не пишите, кто же вас заставляет. > > В случае правильно и грамотно написанной конфигурации - обычно > хватает одного набора директив proxy_set_header на уровне http, > возможно - с отдельными вкраплениями "специальных" наборов. > Так и есть, но у меня меняется хедер Host на некоторых locations, что-бы отправить "сквозной" запрос на нужный мне микросервис внутри бэкэнда, без использования "прослойки".. > Если очень нужно вносить локальные изменения в конкретных > location'ах - можно использовать директиву include с неким базовым > набором, дополняя его по необходимости. Но если вы регулярно > сталкиваетесь с подобной проблемой - скорее всего вы что-то > делаете не так. > Так и решил, но выглядет не очень кошерно... -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Fri Mar 24 14:11:50 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 24 Mar 2017 17:11:50 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5X3NldF9oZWFkZXIg0Lgg0L3QsNGB0LvQtdC00LjQtQ==?= In-Reply-To: References: <20170323170028.GZ13617@mdounin.ru> Message-ID: <20170324141149.GF13617@mdounin.ru> Hello! On Fri, Mar 24, 2017 at 03:32:41PM +0200, Vladimir Getmanshchuk wrote: > > > 2) Если делаешь proxy_set_header дважды (иногда пересекается из-за > > > include), то получаешь два хедера в HTTP запросе(от чего некоторые > > backends > > > сходят с ума, когда видят два хедера Host(например). > > > Почему не брать значение из последнего proxy_set_header? > > > > В HTTP вполне допустимо использование нескольких одинаковых > > заголовков, более того - явно специфицировано, когда можно, а > > когда - нельзя, и как трактовать. И во многих случаях это > > используется. > > > > Было бы странно ограничивать людей в том, что они могут написать в > > конфиге, причём совсем не так, как специфицирует используемый > > протокол. > > > > А какое из значений двух хедеров "Host" будет использовать NGINX для > определения server_name? В случае конкретно заголовка Host - nginx испольузет первое из полученных значений. Это поведение, впрочем, историческое, и стоит подумать о том, чтобы возвращать в подобных случаях 400, т.к. синтаксис заголовка Host нескольких значений не допускает, и свежий RFC 7230 явно требует именно 400 в случае нескольких заголовков Host. А вот, скажем, в случае заголовка X-Forwarded-For - nginx честно использует все полученные заголовки, интерпретируя их в соответствии со стандартом, т.е. два заголовка равносильны одному со значениями этих заголовков через запятую. -- Maxim Dounin http://nginx.org/ From vladget на gmail.com Fri Mar 24 14:16:47 2017 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Fri, 24 Mar 2017 16:16:47 +0200 Subject: =?UTF-8?B?UmU6IHByb3h5X3NldF9oZWFkZXIg0Lgg0L3QsNGB0LvQtdC00LjQtQ==?= In-Reply-To: <20170324141149.GF13617@mdounin.ru> References: <20170323170028.GZ13617@mdounin.ru> <20170324141149.GF13617@mdounin.ru> Message-ID: Hi В случае конкретно заголовка Host - nginx испольузет первое из > полученных значений. Это поведение, впрочем, историческое, и > стоит подумать о том, чтобы возвращать в подобных случаях 400, т.к. > синтаксис заголовка Host нескольких значений не допускает, и > свежий RFC 7230 явно требует именно 400 в случае нескольких > заголовков Host. > > Может следует делать ресет в proxy_set_header для хедера Host, что бы избежать 400, когда несколько NGINX в каскаде? :) -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Fri Mar 24 14:32:00 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 24 Mar 2017 17:32:00 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5X3NldF9oZWFkZXIg0Lgg0L3QsNGB0LvQtdC00LjQtQ==?= In-Reply-To: References: <20170323170028.GZ13617@mdounin.ru> <20170324141149.GF13617@mdounin.ru> Message-ID: <20170324143200.GH13617@mdounin.ru> Hello! On Fri, Mar 24, 2017 at 04:16:47PM +0200, Vladimir Getmanshchuk wrote: > Hi > > В случае конкретно заголовка Host - nginx испольузет первое из > > полученных значений. Это поведение, впрочем, историческое, и > > стоит подумать о том, чтобы возвращать в подобных случаях 400, т.к. > > синтаксис заголовка Host нескольких значений не допускает, и > > свежий RFC 7230 явно требует именно 400 в случае нескольких > > заголовков Host. > > > > > Может следует делать ресет в proxy_set_header для хедера Host, > что бы избежать 400, когда несколько NGINX в каскаде? :) Скорее, в подобных случаях следует ругаться на duplicate header при парсинге конфигурации, аналогично тому, как nginx ругается на все дублирующиеся директивы. Но, скажем так, маловероятно, что подобная функциональность будет реализована, различать заголовки в директиве, предназначенной для добавления произвольных заголовков к запросу - то ещё развлечение. Я бы тут скорее подумал о том, чтобы сделать отдельную директиву для задания имени хоста в запросе на бекенд. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Fri Mar 24 15:19:10 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 24 Mar 2017 18:19:10 +0300 Subject: nginx-1.11.12 Message-ID: <20170324151910.GK13617@mdounin.ru> Изменения в nginx 1.11.12 24.03.2017 *) Исправление: nginx мог нагружать процессор; ошибка появилась в 1.11.11. -- Maxim Dounin http://nginx.org/ From nginx на mva.name Fri Mar 24 15:36:08 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 24 Mar 2017 22:36:08 +0700 Subject: nginx-1.11.12 In-Reply-To: <20170324151910.GK13617@mdounin.ru> References: <20170324151910.GK13617@mdounin.ru> Message-ID: <1809839.8k7NIdh1D3@note> В письме от пятница, 24 марта 2017 г. 22:19:10 +07 пользователь Maxim Dounin написал: > Изменения в nginx 1.11.12 24.03.2017 > > *) Исправление: nginx мог нагружать процессор; ошибка появилась в > 1.11.11. Ну вот. А я так ждал релиза 1.11.11 из-за такой красивой версии, а он всего три дня прожил :'( From bgx на protva.ru Fri Mar 24 16:24:38 2017 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 24 Mar 2017 19:24:38 +0300 Subject: nginx-1.11.12 In-Reply-To: <1809839.8k7NIdh1D3@note> References: <20170324151910.GK13617@mdounin.ru> <1809839.8k7NIdh1D3@note> Message-ID: <20170324162438.mq5lbnhkp7vdzdfc@protva.ru> On Fri, Mar 24, 2017 at 10:36:08PM +0700, Vadim A. Misbakh-Soloviov wrote: > В письме от пятница, 24 марта 2017 г. 22:19:10 +07 пользователь Maxim Dounin > написал: > > Изменения в nginx 1.11.12 24.03.2017 > > > > *) Исправление: nginx мог нагружать процессор; ошибка появилась в > > 1.11.11. > > Ну вот. А я так ждал релиза 1.11.11 из-за такой красивой версии, а он всего > три дня прожил :'( Эх, теперь будем ждать 1.11.111 и надеяться. ;) -- Eugene Berdnikov From nginx на mva.name Sat Mar 25 18:34:17 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Sun, 26 Mar 2017 01:34:17 +0700 Subject: =?UTF-8?B?0J/Rg9GC0Ywg0L/QvtC40YHQutCwINC00LjQvdCw0LzQuNGH0LXRgdC60LjRhSA=?= =?UTF-8?B?0LzQvtC00YPQu9C10Lkg0L/QviDRg9C80L7Qu9GH0LDQvdC40Y4=?= Message-ID: <8571219.XkNELoDLQA@note> Данный пост, скорее, обращение к Максиму, т.к. именно он закрыл связанный с тем, о чём пойдёт речь, баг: ( https://trac.nginx.org/nginx/ticket/961 ), но я так же приглашаю остальных участников рассылки высказать свои мысли по этому поводу. Суть же моего обращения в том, что в данном вопросе я, всё же, больше солидарен с ожиданиями автора бага, нежели с решением команды разработки, и думаю, что фича в виде установки c `--modules-path` не только пути установки модулей, но и пути, по которому NginX будет их искать - довольно логична. Стандартно, многие linux-системы собирают софт с `--prefix=/usr` и т.п. (в общем, разбивкой служебных путей по разным частям фс). Порой на это даже трудно повлиять, не переделывая билдскрипты. В общем, "среднестатистическая" линуксовая сборка NginX выглядит так: ``` --prefix=/usr --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/ nginx/error.log --pid-path=/run/nginx.pid --lock-path=/run/lock/nginx.lock -- with-cc-opt=-I/usr/include --with-ld-opt=-L/usr/lib64 --http-log-path=/var/ log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client -- http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/ lib/nginx/tmp/fastcgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --http- uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi ``` При этом подразумевается, что свои модули и прочие "свои" файлы софт будет хранить не в системных директориях, а в своих поддиректориях. В случае же NginX, при обычной сборке, modules_path получается /usr/modules (я так догадываюсь, из-за того, что по умолчанию оно имеет значение $prefix/ modules). В итоге получается крайне не логичный путь, как по мне. Что ещё за /usr/ modules? Тут на помощь приходит `--modules_path`. Но, к сожалению, после установки NginX всё равно будет пытаться искать файлы относительно префикса. И класть там симлинк - тот ещё костыль и равноценен тому, чтобы поставить их туда напрямую (см. довод про нелогичность пути). В случае инклуда конфигов, к слову, nginx вполне логично ищет их в /etc/nginx, а не в prefix (хотя надо уточнить, не дистрибутивный ли патч фиксит это поведение). Так почему бы не сделать такое же по смыслу и для модулей? Чтобы не провоцировать кучу лишней писанины на пустом месте :) ==== Так же, можно было бы на этапе сборки хардкодить расширение динамических библиотек (so, dll, dylib), и так же не заставлять конфигописателя указывать этот суффикс в конфиге, а просто конкатенировать параметр load_module (если он в виде относительного, а не абсолютного пути) с "modules_path" спереди и shared_suffix на конце. Что думаете? // особенно Максим From nginx-forum на forum.nginx.org Sat Mar 25 20:01:59 2017 From: nginx-forum на forum.nginx.org (Siava) Date: Sat, 25 Mar 2017 16:01:59 -0400 Subject: =?UTF-8?B?UkVNT1RFIEFERFIg0LfQsCDRgNC+0YPRgtC10YDQvtC8INC90LAg0LHQtdC60LU=?= =?UTF-8?B?0L3QtNC1?= Message-ID: <20e8f5e3ae92a44f9ae2b0aabe5533f4.NginxMailingListRussian@forum.nginx.org> Добрый вечер. Имеется роутер, за ним несколько http-серверов. Один из серверов за роутером проксирующий. То есть схема доступа такая: роутер (192.168.0.1) -> проксирующий_сервер (192.168.0.11) -> [остальные бекенды (192.168.0.2x)] Проблема в том, что на бекендах теряется реальный IP. Он равен IP-адресу проксирующего сервера 192.168.0.11 Пример конфигурации одного из сайтов на проксирующем сервере: server { listen 80; server_name 21.domain.ru; location / { proxy_pass http://192.168.0.21:80/; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } На проксирующем сервере реальные IP корректные, но получается он их дальше не пробрасывает. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273186,273186#msg-273186 From nginx-forum на forum.nginx.org Sat Mar 25 20:43:22 2017 From: nginx-forum на forum.nginx.org (Vasiliy P. Melnik) Date: Sat, 25 Mar 2017 16:43:22 -0400 Subject: =?UTF-8?B?UmU6IFJFTU9URSBBRERSINC30LAg0YDQvtGD0YLQtdGA0L7QvCDQvdCwINCx0LU=?= =?UTF-8?B?0LrQtdC90LTQtQ==?= In-Reply-To: <20e8f5e3ae92a44f9ae2b0aabe5533f4.NginxMailingListRussian@forum.nginx.org> References: <20e8f5e3ae92a44f9ae2b0aabe5533f4.NginxMailingListRussian@forum.nginx.org> Message-ID: чудес же не бывает, бекэнды тоже нгинкс? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273186,273187#msg-273187 From nginx-forum на forum.nginx.org Sat Mar 25 20:45:38 2017 From: nginx-forum на forum.nginx.org (Siava) Date: Sat, 25 Mar 2017 16:45:38 -0400 Subject: =?UTF-8?B?UmU6IFJFTU9URSBBRERSINC30LAg0YDQvtGD0YLQtdGA0L7QvCDQvdCwINCx0LU=?= =?UTF-8?B?0LrQtdC90LTQtQ==?= In-Reply-To: References: <20e8f5e3ae92a44f9ae2b0aabe5533f4.NginxMailingListRussian@forum.nginx.org> Message-ID: <11adc7f9bbf4a0edd465427836e457e7.NginxMailingListRussian@forum.nginx.org> Да, бэкенды тоже nginx. Но конфиги там обычные. Как заставить их принимать реальный IP? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273186,273188#msg-273188 From gmm на csdoc.com Sat Mar 25 20:54:11 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Sat, 25 Mar 2017 22:54:11 +0200 Subject: =?UTF-8?B?UmU6IFJFTU9URSBBRERSINC30LAg0YDQvtGD0YLQtdGA0L7QvCDQvdCwINCx0LU=?= =?UTF-8?B?0LrQtdC90LTQtQ==?= In-Reply-To: <11adc7f9bbf4a0edd465427836e457e7.NginxMailingListRussian@forum.nginx.org> References: <20e8f5e3ae92a44f9ae2b0aabe5533f4.NginxMailingListRussian@forum.nginx.org> <11adc7f9bbf4a0edd465427836e457e7.NginxMailingListRussian@forum.nginx.org> Message-ID: <94bcbf9c-20c5-7106-1c8d-29b4e5f229a5@csdoc.com> On 25.03.2017 22:45, Siava wrote: > Да, бэкенды тоже nginx. Но конфиги там обычные. > Как заставить их принимать реальный IP? на них надо настроить set_real_ip_from, тогда будет работать. -- Best regards, Gena From bgx на protva.ru Sat Mar 25 20:55:19 2017 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Sat, 25 Mar 2017 23:55:19 +0300 Subject: =?UTF-8?B?UmU6IFJFTU9URSBBRERSINC30LAg0YDQvtGD0YLQtdGA0L7QvCDQvdCwINCx0LU=?= =?UTF-8?B?0LrQtdC90LTQtQ==?= In-Reply-To: <20e8f5e3ae92a44f9ae2b0aabe5533f4.NginxMailingListRussian@forum.nginx.org> References: <20e8f5e3ae92a44f9ae2b0aabe5533f4.NginxMailingListRussian@forum.nginx.org> Message-ID: <20170325205518.oz4c2cdixwmqdelw@protva.ru> On Sat, Mar 25, 2017 at 04:01:59PM -0400, Siava wrote: > Добрый вечер. > > Имеется роутер, за ним несколько http-серверов. Один из серверов за роутером > проксирующий. > > То есть схема доступа такая: > роутер (192.168.0.1) -> проксирующий_сервер (192.168.0.11) -> [остальные > бекенды (192.168.0.2x)] > > Проблема в том, что на бекендах теряется реальный IP. Он равен IP-адресу > проксирующего сервера 192.168.0.11 Как бэкенды вычисляют реальный ip? Они обрабатывают заголовок X-Real-IP, который устанавливается в цитируемом ниже конфиге? Если да, то что прилетает в этом заголовке? Если нет, то это ожидаемое поведение. > Пример конфигурации одного из сайтов на проксирующем сервере: > > server { > listen 80; > server_name 21.domain.ru; > > location / { > proxy_pass http://192.168.0.21:80/; > proxy_redirect off; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > } > } > > На проксирующем сервере реальные IP корректные, но получается он их дальше > не пробрасывает. -- Eugene Berdnikov From nginx-forum на forum.nginx.org Sat Mar 25 21:14:59 2017 From: nginx-forum на forum.nginx.org (Siava) Date: Sat, 25 Mar 2017 17:14:59 -0400 Subject: =?UTF-8?B?UmU6IFJFTU9URSBBRERSINC30LAg0YDQvtGD0YLQtdGA0L7QvCDQvdCwINCx0LU=?= =?UTF-8?B?0LrQtdC90LTQtQ==?= In-Reply-To: <94bcbf9c-20c5-7106-1c8d-29b4e5f229a5@csdoc.com> References: <94bcbf9c-20c5-7106-1c8d-29b4e5f229a5@csdoc.com> Message-ID: Добавляю на бекенд в секцию server set_real_ip_from 192.168.0.11; real_ip_header X-Real-IP; real_ip_recursive on; и "реальный" IP адрес становится равным 192.168.0.1 (адресу роутера). P.S. nginx 1.10.3 из репозитория nginx.org для Debian с --with-http_realip_module Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273189,273192#msg-273192 From nginx-forum на forum.nginx.org Sat Mar 25 21:15:52 2017 From: nginx-forum на forum.nginx.org (Siava) Date: Sat, 25 Mar 2017 17:15:52 -0400 Subject: =?UTF-8?B?UmU6IFJFTU9URSBBRERSINC30LAg0YDQvtGD0YLQtdGA0L7QvCDQvdCwINCx0LU=?= =?UTF-8?B?0LrQtdC90LTQtQ==?= In-Reply-To: <20170325205518.oz4c2cdixwmqdelw@protva.ru> References: <20170325205518.oz4c2cdixwmqdelw@protva.ru> Message-ID: <23b5dc469cc309eca5ac20fb2af61a68.NginxMailingListRussian@forum.nginx.org> Странно, тема разделилась. Я тут ответил: https://forum.nginx.org/read.php?21,273189,273192#msg-273192 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273190,273193#msg-273193 From nginx-forum на forum.nginx.org Sat Mar 25 21:16:57 2017 From: nginx-forum на forum.nginx.org (Siava) Date: Sat, 25 Mar 2017 17:16:57 -0400 Subject: =?UTF-8?B?UmU6IFJFTU9URSBBRERSINC30LAg0YDQvtGD0YLQtdGA0L7QvCDQvdCwINCx0LU=?= =?UTF-8?B?0LrQtdC90LTQtQ==?= In-Reply-To: <23b5dc469cc309eca5ac20fb2af61a68.NginxMailingListRussian@forum.nginx.org> References: <20170325205518.oz4c2cdixwmqdelw@protva.ru> <23b5dc469cc309eca5ac20fb2af61a68.NginxMailingListRussian@forum.nginx.org> Message-ID: <53264caeae8d55571b016cd6a3929ab3.NginxMailingListRussian@forum.nginx.org> Добавляю на бекенд в секцию server set_real_ip_from 192.168.0.11; real_ip_header X-Real-IP; real_ip_recursive on; и "реальный" IP адрес становится равным 192.168.0.1 (адресу роутера). P.S. nginx 1.10.3 из репозитория nginx.org для Debian с --with-http_realip_module Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273190,273194#msg-273194 From nginx-forum на forum.nginx.org Sat Mar 25 21:33:32 2017 From: nginx-forum на forum.nginx.org (Siava) Date: Sat, 25 Mar 2017 17:33:32 -0400 Subject: =?UTF-8?B?UmU6IFJFTU9URSBBRERSINC30LAg0YDQvtGD0YLQtdGA0L7QvCDQvdCwINCx0LU=?= =?UTF-8?B?0LrQtdC90LTQtQ==?= In-Reply-To: <53264caeae8d55571b016cd6a3929ab3.NginxMailingListRussian@forum.nginx.org> References: <20170325205518.oz4c2cdixwmqdelw@protva.ru> <23b5dc469cc309eca5ac20fb2af61a68.NginxMailingListRussian@forum.nginx.org> <53264caeae8d55571b016cd6a3929ab3.NginxMailingListRussian@forum.nginx.org> Message-ID: Разобрался. Компьютер, с которого запросы отправляю, сам находится за роутером, поэтому и IP его такой. Проверил запросами снаружи, всё в порядке. IP реальный! Спасибо за наводку. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273190,273195#msg-273195 From mdounin на mdounin.ru Sun Mar 26 02:49:29 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sun, 26 Mar 2017 05:49:29 +0300 Subject: =?UTF-8?B?UmU6INCf0YPRgtGMINC/0L7QuNGB0LrQsCDQtNC40L3QsNC80LjRh9C10YHQutC4?= =?UTF-8?B?0YUg0LzQvtC00YPQu9C10Lkg0L/QviDRg9C80L7Qu9GH0LDQvdC40Y4=?= In-Reply-To: <8571219.XkNELoDLQA@note> References: <8571219.XkNELoDLQA@note> Message-ID: <20170326024928.GO13617@mdounin.ru> Hello! On Sun, Mar 26, 2017 at 01:34:17AM +0700, Vadim A. Misbakh-Soloviov wrote: > Данный пост, скорее, обращение к Максиму, т.к. именно он закрыл связанный с > тем, о чём пойдёт речь, баг: ( https://trac.nginx.org/nginx/ticket/961 ), но я > так же приглашаю остальных участников рассылки высказать свои мысли по этому > поводу. > > Суть же моего обращения в том, что в данном вопросе я, всё же, больше > солидарен с ожиданиями автора бага, нежели с решением команды разработки, и > думаю, что фича в виде установки c `--modules-path` не только пути установки > модулей, но и пути, по которому NginX будет их искать - довольно логична. В конфигурации nginx'а уже существует два типа путей, которые используют в качестве базы разные префиксы - просто префикс и "конфигурационный". Добавлять к этому ещё дополнительный префикс для модулей - нет никакого желания, префиксов и так на один больше, чем должно быть. [...] > В итоге получается крайне не логичный путь, как по мне. Что ещё за /usr/ > modules? > > Тут на помощь приходит `--modules_path`. Но, к сожалению, после установки > NginX всё равно будет пытаться искать файлы относительно префикса. И класть > там симлинк - тот ещё костыль и равноценен тому, чтобы поставить их туда > напрямую (см. довод про нелогичность пути). Рекомендую посмотреть на пакеты с nginx.org, там --prefix ставится в /etc/nginx и проблема исчезает. -- Maxim Dounin http://nginx.org/ From nginx на mva.name Sun Mar 26 07:22:02 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Sun, 26 Mar 2017 14:22:02 +0700 Subject: =?UTF-8?B?UmU6INCf0YPRgtGMINC/0L7QuNGB0LrQsCDQtNC40L3QsNC80LjRh9C10YHQutC4?= =?UTF-8?B?0YUg0LzQvtC00YPQu9C10Lkg0L/QviDRg9C80L7Qu9GH0LDQvdC40Y4=?= In-Reply-To: <20170326024928.GO13617@mdounin.ru> References: <8571219.XkNELoDLQA@note> <20170326024928.GO13617@mdounin.ru> Message-ID: <3521265.s6OhU7fFM2@note> > В конфигурации nginx'а уже существует два типа путей, которые > используют в качестве базы разные префиксы - просто префикс и > "конфигурационный". Добавлять к этому ещё дополнительный префикс > для модулей - нет никакого желания, префиксов и так на один > больше, чем должно быть. Ну, вот "префиксный", в отличие от "конфигурационного", как раз-таки и не то, чтобы особо был нужен, если задуматься :) А вот конфигурационный и модульный - довольно удобны. > Рекомендую посмотреть на пакеты с nginx.org, там --prefix ставится > в /etc/nginx и проблема исчезает. 1) хранить бинарные модули в /etc — нарушение FHS. Да и противоречит дистрибутивной политике многих дистрибутивов. По возможности в гайдлайнах просят такого избегать. 2) ну, да, получается "не как у всех" :) 3) я бы, вообще, раз у вас WONTFIX, поставил бы prefix в что-то типа /var/lib/ nginx, но не уверен, что NginX потом из-за этого не выстрелит по ногам где- нибудь в другом месте :( From nginx на mva.name Sun Mar 26 09:34:57 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Sun, 26 Mar 2017 16:34:57 +0700 Subject: =?UTF-8?B?UmU6INCf0YPRgtGMINC/0L7QuNGB0LrQsCDQtNC40L3QsNC80LjRh9C10YHQutC4?= =?UTF-8?B?0YUg0LzQvtC00YPQu9C10Lkg0L/QviDRg9C80L7Qu9GH0LDQvdC40Y4=?= In-Reply-To: <3521265.s6OhU7fFM2@note> References: <8571219.XkNELoDLQA@note> <20170326024928.GO13617@mdounin.ru> <3521265.s6OhU7fFM2@note> Message-ID: <3371344.X9tt12rPsV@note> > 3) я бы, вообще, раз у вас WONTFIX, поставил бы prefix в что-то типа > /var/lib/ nginx, но не уверен, что NginX потом из-за этого не выстрелит по > ногам где- нибудь в другом месте :( К слову, по этому поводу, если я сделаю `--prefix=/var/lib/nginx`, а так же укажу вот так: ``` --http-client-body-temp-path="tmp/client" \ --http-proxy-temp-path="tmp/proxy" \ --http-fastcgi-temp-path="tmp/fastcgi" \ --http-scgi-temp-path="tmp/scgi" \ --http-uwsgi-temp-path="tmp/uwsgi" \ --modules-path="modules" \ ``` Он же в рантайме поймёт, что пути тут относительно префикса? или лучше везде указать полные? From nginx-forum на forum.nginx.org Sun Mar 26 12:25:52 2017 From: nginx-forum на forum.nginx.org (vitcool) Date: Sun, 26 Mar 2017 08:25:52 -0400 Subject: =?UTF-8?B?0JLQtdGB0LXQvdC90LjQuSDQsNCy0LjRgtCw0LzQuNC90L7QtyDRgSDQu9C+0Lo=?= =?UTF-8?B?0LXQudGI0LXQvdCw0LzQuA==?= Message-ID: <7826c2aa6696e0d408a959f064ba65a3.NginxMailingListRussian@forum.nginx.org> Добрый день! Подскажите как мне организовать локейшены для реализации следующей логики ключевой паттерн на который сейчас используется location ~* \.(png|gif|jpg|jpeg)$ { # запрос проксируется на бекенд где происходит разбор ситуации и принимается # решение куда проксировать дальше и что делать. # хочется сделать чтобы основная # логика отрабатывалась сразу на фронте nginx } логика которая требуется (вариант 1) запрос /yyy/xxx/ggg/a1b2c3%20d4.jpg - надо проксировать на бекенд№1 as is + использовать кэш nginx http://backend1:port/yyy/xxx/ggg/a1b2c3%20d4.jpg (вариант 2) запрос /yyy/xxx/ggg/a1b2c3%20d4.jpg?param1=value1 - надо проксировать на бекенд№1 + использовать кэш nginx http://backend1:port/yyy/xxx/ggg/a1b2c3%20d4.jpg (т.е. игнорируем все параметры отличные от param2, param3, param4 - см ниже) (вариант 3) запрос /yyy/xxx/ggg/a1b2c3%20d4.jpg?param2=value2 - надо проксировать на бекенд№2 + использовать кэш nginx http://backend2:port/blabla/?source=http://static_server/yyy/xxx/ggg/a1b2c3%20d4.jpg¶m2=value2 (вариант 4) запрос /yyy/xxx/ggg/a1b2c3%20d4.jpg?param3=value3 - надо проксировать на бекенд№2 + использовать кэш nginx http://backend2:port/blabla/?source=http://static_server/yyy/xxx/ggg/a1b2c3%20d4.jpg¶m3=value3 (вариант 5) запрос /yyy/xxx/ggg/a1b2c3%20d4.jpg?param4=value4 - надо проксировать на бекенд№3 + использовать кэш nginx http://backend3:port/blabla/?source=http://static_server/yyy/xxx/ggg/a1b2c3%20d4.jpg¶m4=value4 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273212,273212#msg-273212 From mdounin на mdounin.ru Mon Mar 27 12:38:37 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 27 Mar 2017 15:38:37 +0300 Subject: =?UTF-8?B?UmU6INCf0YPRgtGMINC/0L7QuNGB0LrQsCDQtNC40L3QsNC80LjRh9C10YHQutC4?= =?UTF-8?B?0YUg0LzQvtC00YPQu9C10Lkg0L/QviDRg9C80L7Qu9GH0LDQvdC40Y4=?= In-Reply-To: <3371344.X9tt12rPsV@note> References: <8571219.XkNELoDLQA@note> <20170326024928.GO13617@mdounin.ru> <3521265.s6OhU7fFM2@note> <3371344.X9tt12rPsV@note> Message-ID: <20170327123837.GP13617@mdounin.ru> Hello! On Sun, Mar 26, 2017 at 04:34:57PM +0700, Vadim A. Misbakh-Soloviov wrote: > > 3) я бы, вообще, раз у вас WONTFIX, поставил бы prefix в что-то типа > > /var/lib/ nginx, но не уверен, что NginX потом из-за этого не выстрелит по > > ногам где- нибудь в другом месте :( > > К слову, по этому поводу, если я сделаю `--prefix=/var/lib/nginx`, а так же > укажу вот так: > ``` > --http-client-body-temp-path="tmp/client" \ > --http-proxy-temp-path="tmp/proxy" \ > --http-fastcgi-temp-path="tmp/fastcgi" \ > --http-scgi-temp-path="tmp/scgi" \ > --http-uwsgi-temp-path="tmp/uwsgi" \ > --modules-path="modules" \ > ``` > Он же в рантайме поймёт, что пути тут относительно префикса? или лучше везде > указать полные? Все пути в configure, если они относительные, задаются относительно префикса. Собственно, для установки nginx'а в произвольный каталог достаточно задать только --prefix. Все остальные пути по умолчанию - относительные, и, соответственно, относительно префикса. -- Maxim Dounin http://nginx.org/ From chipitsine на gmail.com Mon Mar 27 13:18:25 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 27 Mar 2017 18:18:25 +0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0YwgTmdpbngg0LIg0Lo=?= =?UTF-8?B?0LDRh9C10YHRgtCy0LUg0L/RgNC+0LrRgdC4INC00LvRjyBTMyDRgdC+0LI=?= =?UTF-8?B?0LzQtdGB0YLQuNC80L7Qs9C+INGF0YDQsNC90LjQu9C40YnQsD8=?= In-Reply-To: References: Message-ID: недавно траблшутили аналогичную проблему. AWS4 работает на механизме подписи хедеров запроса. клиент перечисляет хедеры в SignedHeaders=content-type;date;expect;host;x-amz-content-sha256;x-amz-date а сервер проверяет подпись соответственно, если клиент добавляет "expect" (у нас - добавляет), то подпись бьется. нет планов реализовать поддержку Expect ? 14 декабря 2016 г., 18:28 пользователь Alexandr Porunov < alexandr.porunov на gmail.com> написал: > Я же написал что клиент поддерживает только 4 версию. Я не использую > клиент на c#. > Если написать развёрнуто, то вот что я использую: > Я использую SaltStack. > SaltStack нуждается в хранилище (он поддерживает разные хранилища: > локальная папка, git, s3, azure...). > Лично мне удобно использовать s3 (локальная папка в моём случае не > приемлема). > Так вот, для того чтобы работать с s3 у них есть специальный модуль s3fs > который умеет использовать s3 обьектное хранилище. Этот модуль написан на > Python и этот модуль умеет работать только с 4 версией подписи. Там просто > не написана логика работы для 2 версии. > Я не могу перевести клиента на вторую версию по двум причинам: > 1. Нужно переписывать чужой модуль > 2. Я никогда не работал с Python > > Нужно понимать что я не использую s3.amazon.com. У меня своё приватное > хранилище которые никоем образом не относиться к амазону. Просто что у > этого хранилища точно такое-же API как и у Амазона. > > Единственное решение это настроить Nginx чтобы он правильно проксировал > запросы к моему хранилищу. > > 2016-12-14 14:53 GMT+02:00 Илья Шипицин : > >> >> >> 14 декабря 2016 г., 17:41 пользователь Alexandr Porunov < >> alexandr.porunov на gmail.com> написал: >> >>> Всем привет, >>> >>> Я хочу использовать Nginx в качестве прокси для S3 совместимого >>> хранилища с 4 версией подписи (Amazon s3 signature version 4). >>> >>> Я новичёк в Nginx, но попробую обьяснить что я хочу сделать. >>> >>> У меня есть 3 сервера: >>> >>> mydomain.com - публичный сервер с запущенным Nginx >>> s3storage - приватный сервер с хранилищем с S3 API >>> client - клиент который хочет использовать S3 хранилище через Nginx >>> (т.е. через домен mydomain.com). Этот клиент умеет работать только с 4 >>> версией S3 подписи. >>> >>> Таким образом клиент отправляет примерно такие запросы к Nginx: >>> https://.mydomain.com/ >>> >>> где - имя бакета и - имя файла (если есть). >>> >>> Я должен иметь возможность как-то правильно проксировать эти запросы с >>> mydomain.com к s3storage (у s3storage IP 192.168.0.45). >>> >>> Проблема в том что имя бакета находиться в URL, а не в пути. Не понятно >>> как правильно проксировать такие запросы чтобы подпись оставалась целой и >>> чтобы можно было получать файлы с s3storage. >>> >> >> каким образом использовать бакет, в днс или в пути - это на усмотрение >> клиента, допустимы оба варианта >> >> http://stackoverflow.com/questions/16938683/ >> >> >> (пример для клиента на c#) >> >> AmazonS3Config S3Config = new AmazonS3Config() >> { >> ServiceURL = "s3.amazonaws.com", >> ForcePathStyle = true, >> RegionEndpoint = region >> }; >> >> более предсказуемая схема - перевести клиента и сервер на единообразный механизм. иначе подпись будет биться >> (и не совсем понятно, почему это надо чинить на nginx в транзите) >> >> >> >> >> >>> >>> Если кто-то знает как правильно настроить Nginx, то подскажите, >>> пожалуйста >>> >>> С уважением, >>> Александр >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Thu Mar 30 06:33:43 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 30 Mar 2017 09:33:43 +0300 Subject: =?UTF-8?B?0L/QvtGB0LvQtSB5dW0gdXBkYXRlINC+0YHRgtCw0LvQuNGB0Ywg0LDQutGC0Lg=?= =?UTF-8?B?0LLQvdGLINC00LLQsCDQvNCw0YHRgtC10YAt0L/RgNC+0YbQtdGB0YHQsCBu?= =?UTF-8?B?Z2lueA==?= Message-ID: Здравствуйте! в файле /var/run/nginx.pid записано 26112 в файле /var/run/nginx.pid.oldbin записано 603 при обновлении nginx с версии 1.11.10 на версию 1.11.12 через yum update он ругнулся, что во время обновления произошла ошибка и остались висеть оба мастер-процесса со своими воркерами. официальная сборка из репозитория nginx.org mainline для centos 7. в sysctl.conf сервера прописано net.ipv4.ip_nonlocal_bind=1 и эта CentOS 7 - контейнер на OpenVZ 2.6.32-042stab120.18 если это может быть важно. ожидалось что после yum update останется только один мастер nginx. и только его воркер-процессы. в конфиге nginx прописано worker_processes 8; у старого мастера их почему-то было в два раза больше запущено. # pstree -cp systemd(1)─┬─nginx(603)─┬─nginx(26112)─┬─nginx(26826) │ │ ├─nginx(26827) │ │ ├─nginx(26828) │ │ ├─nginx(26829) │ │ ├─nginx(26830) │ │ ├─nginx(26831) │ │ ├─nginx(26832) │ │ └─nginx(26833) │ ├─nginx(25993) │ ├─nginx(25994) │ ├─nginx(25995) │ ├─nginx(25996) │ ├─nginx(25997) │ ├─nginx(25998) │ ├─nginx(25999) │ ├─nginx(26000) │ ├─nginx(26160) │ ├─nginx(26161) │ ├─nginx(26162) │ ├─nginx(26163) │ ├─nginx(26164) │ ├─nginx(26165) │ ├─nginx(26166) │ └─nginx(26167) # ps aux | grep nginx USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 603 0.0 3.5 143696 73680 ? Ss Mar05 0:10 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 25993 0.0 3.9 152352 82552 ? S< Mar29 0:02 nginx: worker process nginx 25994 0.0 3.9 152352 82580 ? S< Mar29 0:02 nginx: worker process nginx 25995 0.0 3.9 152352 82556 ? S< Mar29 0:02 nginx: worker process nginx 25996 0.0 3.9 152352 82580 ? S< Mar29 0:02 nginx: worker process nginx 25997 0.0 3.9 152352 82604 ? S< Mar29 0:03 nginx: worker process nginx 25998 0.0 3.9 152352 82588 ? S< Mar29 0:04 nginx: worker process nginx 25999 0.0 3.9 152352 82588 ? S< Mar29 0:04 nginx: worker process nginx 26000 0.0 3.9 152352 82640 ? S< Mar29 0:05 nginx: worker process root 26112 0.0 3.7 145824 77672 ? S Mar29 0:01 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 26160 0.0 3.9 152352 82632 ? S< Mar29 0:05 nginx: worker process nginx 26161 0.0 3.9 152352 82620 ? S< Mar29 0:06 nginx: worker process nginx 26162 0.0 3.9 152352 82632 ? S< Mar29 0:08 nginx: worker process nginx 26163 0.0 3.9 152352 82652 ? S< Mar29 0:09 nginx: worker process nginx 26164 0.0 3.9 152352 82652 ? S< Mar29 0:10 nginx: worker process nginx 26165 0.0 3.9 152352 82660 ? S< Mar29 0:12 nginx: worker process nginx 26166 0.0 3.9 152352 82648 ? S< Mar29 0:14 nginx: worker process nginx 26167 0.0 3.9 152352 82672 ? S< Mar29 0:16 nginx: worker process nginx 26826 0.0 3.6 145828 76444 ? S< 05:00 0:05 nginx: worker process nginx 26827 0.0 3.6 145828 76456 ? S< 05:00 0:06 nginx: worker process nginx 26828 0.0 3.6 145828 76456 ? S< 05:00 0:07 nginx: worker process nginx 26829 0.0 3.6 145828 76488 ? S< 05:00 0:12 nginx: worker process nginx 26830 0.0 3.6 145828 76464 ? S< 05:00 0:09 nginx: worker process nginx 26831 0.1 3.6 145828 76468 ? S< 05:00 0:17 nginx: worker process nginx 26832 0.1 3.6 145828 76488 ? S< 05:00 0:26 nginx: worker process nginx 26833 0.1 3.6 145828 76488 ? S< 05:00 0:21 nginx: worker process -- Best regards, Gena From nginx-forum на forum.nginx.org Thu Mar 30 14:16:56 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Thu, 30 Mar 2017 10:16:56 -0400 Subject: Cache TTL = 0 Message-ID: <824d8dc6451150631caeb3ca08e4c6cb.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Я уже когда-то писал, что некоторые запросы бекенды должны всегда ревалидировать, в спецификации это документировано в трех параметрах заголовка Cache-Control. max-age=0 - кешировать если есть валидатор (ETag или Last-Modified) no-cache - не использовать кеш без ревалидации must-revalidate - нужна ревалидация Есть тикеты в багтрекере https://trac.nginx.org/nginx/ticket/1182 Amazon CloudFront, уже это потдерживает в своих патчах Nginx http://stackoverflow.com/questions/10621099/what-is-a-ttl-0-in-cloudfront-useful-for Я провел маленькое исследования, многие веб фреймворки используют параметр no-cache чтобы отключить кеширование, реже для этого используют max-age=0, но никто не использует для отключения кеширования параметр must-revalidate. Чтобы не нарушить обратную совместимость со многими фрейворками, безопасней всего научить Nginx понимать параметр must-revalidate. Если не указаны no-store, no-cache, max-age=0 но указан must-revalidate и бекенд отдал валидаторы ETag или Last-Modified, тогда Nginx сохраняет ответ в свой кеш и при запросах всегда проводит ревалидацию. Это потребность из реальных кейсов, спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273298,273298#msg-273298 From thresh на nginx.com Thu Mar 30 14:26:11 2017 From: thresh на nginx.com (Konstantin Pavlov) Date: Thu, 30 Mar 2017 17:26:11 +0300 Subject: =?UTF-8?B?UmU6INC/0L7RgdC70LUgeXVtIHVwZGF0ZSDQvtGB0YLQsNC70LjRgdGMINCw0Lo=?= =?UTF-8?B?0YLQuNCy0L3RiyDQtNCy0LAg0LzQsNGB0YLQtdGALdC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0LAgbmdpbng=?= In-Reply-To: References: Message-ID: <9151cf72-e1f9-a7bc-9d18-7c247d377adb@nginx.com> On 30/03/2017 09:33, Gena Makhomed wrote: > Здравствуйте! > > в файле /var/run/nginx.pid записано 26112 > в файле /var/run/nginx.pid.oldbin записано 603 > > при обновлении nginx с версии 1.11.10 на версию 1.11.12 > через yum update он ругнулся, что во время обновления произошла > ошибка и остались висеть оба мастер-процесса со своими воркерами. > > официальная сборка из репозитория nginx.org mainline для centos 7. > > в sysctl.conf сервера прописано net.ipv4.ip_nonlocal_bind=1 > и эта CentOS 7 - контейнер на OpenVZ 2.6.32-042stab120.18 > если это может быть важно. Сообщения какие-нибудь остались в терминале? Что либо есть в error log'ах в эпсилон-окрестности времени обновления? Сколько по времени занимает проверка конфигурационного файла (nginx -t)? Была ли высокая нагрузка на диски в момент обновления? > ожидалось что после yum update останется только один мастер nginx. > и только его воркер-процессы. > > в конфиге nginx прописано worker_processes 8; > у старого мастера их почему-то было в два раза больше запущено. У старого мастера могли быть reload'ы и долгоиграющие соединения, что может обьяснять количество воркеров. > # pstree -cp > systemd(1)─┬─nginx(603)─┬─nginx(26112)─┬─nginx(26826) > │ │ ├─nginx(26827) > │ │ ├─nginx(26828) > │ │ ├─nginx(26829) > │ │ ├─nginx(26830) > │ │ ├─nginx(26831) > │ │ ├─nginx(26832) > │ │ └─nginx(26833) > │ ├─nginx(25993) > │ ├─nginx(25994) > │ ├─nginx(25995) > │ ├─nginx(25996) > │ ├─nginx(25997) > │ ├─nginx(25998) > │ ├─nginx(25999) > │ ├─nginx(26000) > │ ├─nginx(26160) > │ ├─nginx(26161) > │ ├─nginx(26162) > │ ├─nginx(26163) > │ ├─nginx(26164) > │ ├─nginx(26165) > │ ├─nginx(26166) > │ └─nginx(26167) > > > # ps aux | grep nginx > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > root 603 0.0 3.5 143696 73680 ? Ss Mar05 0:10 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > nginx 25993 0.0 3.9 152352 82552 ? S< Mar29 0:02 nginx: worker process > nginx 25994 0.0 3.9 152352 82580 ? S< Mar29 0:02 nginx: worker process > nginx 25995 0.0 3.9 152352 82556 ? S< Mar29 0:02 nginx: worker process > nginx 25996 0.0 3.9 152352 82580 ? S< Mar29 0:02 nginx: worker process > nginx 25997 0.0 3.9 152352 82604 ? S< Mar29 0:03 nginx: worker process > nginx 25998 0.0 3.9 152352 82588 ? S< Mar29 0:04 nginx: worker process > nginx 25999 0.0 3.9 152352 82588 ? S< Mar29 0:04 nginx: worker process > nginx 26000 0.0 3.9 152352 82640 ? S< Mar29 0:05 nginx: worker process > root 26112 0.0 3.7 145824 77672 ? S Mar29 0:01 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > nginx 26160 0.0 3.9 152352 82632 ? S< Mar29 0:05 nginx: worker process > nginx 26161 0.0 3.9 152352 82620 ? S< Mar29 0:06 nginx: worker process > nginx 26162 0.0 3.9 152352 82632 ? S< Mar29 0:08 nginx: worker process > nginx 26163 0.0 3.9 152352 82652 ? S< Mar29 0:09 nginx: worker process > nginx 26164 0.0 3.9 152352 82652 ? S< Mar29 0:10 nginx: worker process > nginx 26165 0.0 3.9 152352 82660 ? S< Mar29 0:12 nginx: worker process > nginx 26166 0.0 3.9 152352 82648 ? S< Mar29 0:14 nginx: worker process > nginx 26167 0.0 3.9 152352 82672 ? S< Mar29 0:16 nginx: worker process > nginx 26826 0.0 3.6 145828 76444 ? S< 05:00 0:05 nginx: worker process > nginx 26827 0.0 3.6 145828 76456 ? S< 05:00 0:06 nginx: worker process > nginx 26828 0.0 3.6 145828 76456 ? S< 05:00 0:07 nginx: worker process > nginx 26829 0.0 3.6 145828 76488 ? S< 05:00 0:12 nginx: worker process > nginx 26830 0.0 3.6 145828 76464 ? S< 05:00 0:09 nginx: worker process > nginx 26831 0.1 3.6 145828 76468 ? S< 05:00 0:17 nginx: worker process > nginx 26832 0.1 3.6 145828 76488 ? S< 05:00 0:26 nginx: worker process > nginx 26833 0.1 3.6 145828 76488 ? S< 05:00 0:21 nginx: worker process > -- Konstantin Pavlov From nginx-forum на forum.nginx.org Thu Mar 30 14:40:36 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Thu, 30 Mar 2017 10:40:36 -0400 Subject: Cache TTL = 0 In-Reply-To: <824d8dc6451150631caeb3ca08e4c6cb.NginxMailingListRussian@forum.nginx.org> References: <824d8dc6451150631caeb3ca08e4c6cb.NginxMailingListRussian@forum.nginx.org> Message-ID: <20312c4c3a1ad9045fff74c0c480d4b9.NginxMailingListRussian@forum.nginx.org> Проще всего сделать как в Amazon CloudFront, если бекенд отдал Cache-Control: max-age=0, кешировать эти ответы, если в заголовках ответа есть валидаторы ETag или Last-Modified. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,273298,273299#msg-273299 From mdounin на mdounin.ru Thu Mar 30 14:55:40 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 30 Mar 2017 17:55:40 +0300 Subject: =?UTF-8?B?UmU6INC/0L7RgdC70LUgeXVtIHVwZGF0ZSDQvtGB0YLQsNC70LjRgdGMINCw0Lo=?= =?UTF-8?B?0YLQuNCy0L3RiyDQtNCy0LAg0LzQsNGB0YLQtdGALdC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0LAgbmdpbng=?= In-Reply-To: <9151cf72-e1f9-a7bc-9d18-7c247d377adb@nginx.com> References: <9151cf72-e1f9-a7bc-9d18-7c247d377adb@nginx.com> Message-ID: <20170330145540.GH13617@mdounin.ru> Hello! On Thu, Mar 30, 2017 at 05:26:11PM +0300, Konstantin Pavlov wrote: [...] > > в конфиге nginx прописано worker_processes 8; > > у старого мастера их почему-то было в два раза больше запущено. > > У старого мастера могли быть reload'ы и долгоиграющие > соединения, что может обьяснять количество воркеров. При релоаде заголовок процесса меняется на "worker process is shutting down", тут же у всех "worker process". -- Maxim Dounin http://nginx.org/ From gmm на csdoc.com Thu Mar 30 16:59:23 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 30 Mar 2017 19:59:23 +0300 Subject: =?UTF-8?B?UmU6INC/0L7RgdC70LUgeXVtIHVwZGF0ZSDQvtGB0YLQsNC70LjRgdGMINCw0Lo=?= =?UTF-8?B?0YLQuNCy0L3RiyDQtNCy0LAg0LzQsNGB0YLQtdGALdC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0LAgbmdpbng=?= In-Reply-To: <9151cf72-e1f9-a7bc-9d18-7c247d377adb@nginx.com> References: <9151cf72-e1f9-a7bc-9d18-7c247d377adb@nginx.com> Message-ID: <31da807d-6ad7-c108-0fca-7f3743e70324@csdoc.com> On 30.03.2017 17:26, Konstantin Pavlov wrote: >> в файле /var/run/nginx.pid записано 26112 >> в файле /var/run/nginx.pid.oldbin записано 603 >> >> при обновлении nginx с версии 1.11.10 на версию 1.11.12 >> через yum update он ругнулся, что во время обновления произошла >> ошибка и остались висеть оба мастер-процесса со своими воркерами. > Сообщения какие-нибудь остались в терминале? Только это: "Binary upgrade failed, please check nginx's error.log" Но судя по pid-файлам, "Starting new master nginx" получилось сделать, а операция "Graceful shutdown of old nginx" вообще не была выполнена. > Что либо есть в error log'ах в эпсилон-окрестности времени обновления? В /var/log/nginx/error.log пусто, проверка nginx -t проходит без ошибок. > Сколько по времени занимает проверка конфигурационного файла (nginx -t)? Около секунды, но иногда - проверка конфига занимает 6 или 11 секунд. Наверное сказывается нагрузка на диски другими контейнерами сервера. А насколько я понял исходники nginx - он создает pid-файл только после успешного чтения конфигурационного файла. (!) Причина глюка видимо в том, что за секунду ни разу не выполнилось условие if [ -f ${oldbinpidfile} -a -f ${pidfile} ], потому что нового ${pidfile} просто еще не было на тот момент на диске. Может быть имеет смысл сделать UPGRADEWAITLOOPS побольше, так чтобы максимальное время ожидания было не 1 секунда, а 30 секунд например? Это будет очень актуально для конфигураций с большим количеством включаемых файлов на серверах с нагруженной дисковой подсистемой. А так как сейчас есть - получается race condition. Собственно именно это и наблюдалось в моем случае. -- Best regards, Gena From thresh на nginx.com Thu Mar 30 19:07:57 2017 From: thresh на nginx.com (Konstantin Pavlov) Date: Thu, 30 Mar 2017 22:07:57 +0300 Subject: =?UTF-8?B?UmU6INC/0L7RgdC70LUgeXVtIHVwZGF0ZSDQvtGB0YLQsNC70LjRgdGMINCw0Lo=?= =?UTF-8?B?0YLQuNCy0L3RiyDQtNCy0LAg0LzQsNGB0YLQtdGALdC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0LAgbmdpbng=?= In-Reply-To: <31da807d-6ad7-c108-0fca-7f3743e70324@csdoc.com> References: <9151cf72-e1f9-a7bc-9d18-7c247d377adb@nginx.com> <31da807d-6ad7-c108-0fca-7f3743e70324@csdoc.com> Message-ID: On 30/03/2017 19:59, Gena Makhomed wrote: > On 30.03.2017 17:26, Konstantin Pavlov wrote: > >>> в файле /var/run/nginx.pid записано 26112 >>> в файле /var/run/nginx.pid.oldbin записано 603 >>> >>> при обновлении nginx с версии 1.11.10 на версию 1.11.12 >>> через yum update он ругнулся, что во время обновления произошла >>> ошибка и остались висеть оба мастер-процесса со своими воркерами. > >> Сообщения какие-нибудь остались в терминале? > > Только это: "Binary upgrade failed, please check nginx's error.log" > > Но судя по pid-файлам, "Starting new master nginx" получилось сделать, > а операция "Graceful shutdown of old nginx" вообще не была выполнена. > >> Что либо есть в error log'ах в эпсилон-окрестности времени обновления? > > В /var/log/nginx/error.log пусто, проверка nginx -t проходит без ошибок. > >> Сколько по времени занимает проверка конфигурационного файла (nginx -t)? > > Около секунды, но иногда - проверка конфига занимает 6 или 11 секунд. > Наверное сказывается нагрузка на диски другими контейнерами сервера. > > А насколько я понял исходники nginx - он создает pid-файл > только после успешного чтения конфигурационного файла. (!) > > Причина глюка видимо в том, что за секунду ни разу не выполнилось > условие if [ -f ${oldbinpidfile} -a -f ${pidfile} ], потому что > нового ${pidfile} просто еще не было на тот момент на диске. Да, именно поэтому я и спросил про время. > Может быть имеет смысл сделать UPGRADEWAITLOOPS побольше, так чтобы > максимальное время ожидания было не 1 секунда, а 30 секунд например? > > Это будет очень актуально для конфигураций с большим количеством > включаемых файлов на серверах с нагруженной дисковой подсистемой. > > А так как сейчас есть - получается race condition. > Собственно именно это и наблюдалось в моем случае. Мы посчитали, что секунды по-умолчанию должно быть достаточно для всех =) В инит-скрипте для centos/rhel 5-6 используется вот такое для переопределения администраторами: 30 sysconfig=`/bin/basename $initscript` 31 32 if [ -f /etc/sysconfig/$sysconfig ]; then 33 . /etc/sysconfig/$sysconfig 34 fi ... 42 UPGRADEWAITLOOPS=${UPGRADEWAITLOOPS-5} 43 CHECKSLEEP=${CHECKSLEEP-3} Соответственно администратор может переназначить значения переменных так, как подходит для его системы. Для systemd-based исправим, чтобы тоже можно было переопределить аналогичным образом. Спасибо! -- Konstantin Pavlov From gmm на csdoc.com Thu Mar 30 20:35:26 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 30 Mar 2017 23:35:26 +0300 Subject: =?UTF-8?B?UmU6INC/0L7RgdC70LUgeXVtIHVwZGF0ZSDQvtGB0YLQsNC70LjRgdGMINCw0Lo=?= =?UTF-8?B?0YLQuNCy0L3RiyDQtNCy0LAg0LzQsNGB0YLQtdGALdC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0LAgbmdpbng=?= In-Reply-To: References: <9151cf72-e1f9-a7bc-9d18-7c247d377adb@nginx.com> <31da807d-6ad7-c108-0fca-7f3743e70324@csdoc.com> Message-ID: On 30.03.2017 22:07, Konstantin Pavlov wrote: >>> Сколько по времени занимает проверка конфигурационного файла (nginx -t)? >> >> Около секунды, но иногда - проверка конфига занимает 6 или 11 секунд. >> Наверное сказывается нагрузка на диски другими контейнерами сервера. >> >> А насколько я понял исходники nginx - он создает pid-файл >> только после успешного чтения конфигурационного файла. (!) >> >> Причина глюка видимо в том, что за секунду ни разу не выполнилось >> условие if [ -f ${oldbinpidfile} -a -f ${pidfile} ], потому что >> нового ${pidfile} просто еще не было на тот момент на диске. > > Да, именно поэтому я и спросил про время. > >> Может быть имеет смысл сделать UPGRADEWAITLOOPS побольше, так чтобы >> максимальное время ожидания было не 1 секунда, а 30 секунд например? >> >> Это будет очень актуально для конфигураций с большим количеством >> включаемых файлов на серверах с нагруженной дисковой подсистемой. >> >> А так как сейчас есть - получается race condition. >> Собственно именно это и наблюдалось в моем случае. > > Мы посчитали, что секунды по-умолчанию должно быть достаточно для всех =) > Как мне кажется, задержка в 1 секунду пошла из Makefile, который генерируется командой ./configure из состава nginx: upgrade: /usr/local/nginx/sbin/nginx -t kill -USR2 `cat /usr/local/nginx/logs/nginx.pid` sleep 1 test -f /usr/local/nginx/logs/nginx.pid.oldbin kill -QUIT `cat /usr/local/nginx/logs/nginx.pid.oldbin` Но тут никто не ждет появления pid-файла от нового мастера, одна секунда дается старому мастеру на то чтобы получить сигнал, переименовать nginx.pid в nginx.pid.oldbin и запустить новый мастер (без лимита времени на старт) В скрипте /usr/libexec/initscripts/legacy-actions/nginx/upgrade логика теперь уже совсем другая, там ожидается что за 1 секунду новый мастер успеет прочитать конфиг и записать свой pid-файл. Когда включается много мелких конфигурационных файлов в основной конфиг и когда дисковая подсистема сервера загружена - легко может получиться и 11 секунд и даже больше. Можно ли увеличить значение по-умолчанию переменной UPGRADEWAITLOOPS до UPGRADEWAITLOOPS=450 ? Это вполне безопасно и не будет приводить к каким-либо проблемам. В том же systemd значением по-умолчанию для TimeoutStartSec= и TimeoutStopSec= является 90 секунд и это не вызывает никаких проблем. Тут у нас, по сути, счетчик UPGRADEWAITLOOPS играет роль TimeoutStartSec > В инит-скрипте для centos/rhel 5-6 используется вот такое для переопределения администраторами: > > 30 sysconfig=`/bin/basename $initscript` > 31 > 32 if [ -f /etc/sysconfig/$sysconfig ]; then > 33 . /etc/sysconfig/$sysconfig > 34 fi > > ... > > 42 UPGRADEWAITLOOPS=${UPGRADEWAITLOOPS-5} > 43 CHECKSLEEP=${CHECKSLEEP-3} > > Соответственно администратор может переназначить значения переменных так, как подходит для его системы. > > Для systemd-based исправим, чтобы тоже можно было переопределить аналогичным образом. Только сделайте, пожалуйста, значение по-умолчанию UPGRADEWAITLOOPS=450 И тогда очень мало кому понадобится менять новое дефолтовое значение UPGRADEWAITLOOPS=450 на какое-то другое, 99.999999% пользователей вполне устроит то, как будет работать новый service nginx upgrade -- Best regards, Gena From nginx на mva.name Fri Mar 31 03:00:03 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 31 Mar 2017 10:00:03 +0700 Subject: =?UTF-8?B?UmU6INC/0L7RgdC70LUgeXVtIHVwZGF0ZSDQvtGB0YLQsNC70LjRgdGMINCw0Lo=?= =?UTF-8?B?0YLQuNCy0L3RiyDQtNCy0LAg0LzQsNGB0YLQtdGALdC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0LAgbmdpbng=?= In-Reply-To: References: <31da807d-6ad7-c108-0fca-7f3743e70324@csdoc.com> Message-ID: <3096491.AOrNFe5d22@note> > Для systemd-based исправим, чтобы тоже можно было переопределить аналогичным > образом. В systemd же вполне работает systemctl edit svcname. И так администратор может добавить Environment=VAR=VALUE... > Спасибо! From thresh на nginx.com Fri Mar 31 06:04:07 2017 From: thresh на nginx.com (Konstantin Pavlov) Date: Fri, 31 Mar 2017 09:04:07 +0300 Subject: =?UTF-8?B?UmU6INC/0L7RgdC70LUgeXVtIHVwZGF0ZSDQvtGB0YLQsNC70LjRgdGMINCw0Lo=?= =?UTF-8?B?0YLQuNCy0L3RiyDQtNCy0LAg0LzQsNGB0YLQtdGALdC/0YDQvtGG0LXRgdGB?= =?UTF-8?B?0LAgbmdpbng=?= In-Reply-To: <3096491.AOrNFe5d22@note> References: <31da807d-6ad7-c108-0fca-7f3743e70324@csdoc.com> <3096491.AOrNFe5d22@note> Message-ID: <15084819-b4b7-5346-e38f-a9a828fd41fe@nginx.com> On 31/03/2017 06:00, Vadim A. Misbakh-Soloviov wrote: >> Для systemd-based исправим, чтобы тоже можно было переопределить аналогичным >> образом. > > В systemd же вполне работает systemctl edit svcname. И так администратор может > добавить Environment=VAR=VALUE... Да, вот только legacy action scripts, к сожалению, запускаются не через systemctl - и поэтому drop-in units и описания в .service-файлах не используются. Соответственно возможности прокинуть Environment в них таким образом нет. -- Konstantin Pavlov