From vlad.shabanov на gmail.com Fri Jan 1 17:46:58 2021 From: vlad.shabanov на gmail.com (Vladislav Shabanov) Date: Fri, 1 Jan 2021 20:46:58 +0300 Subject: =?UTF-8?B?0JrQu9C40LXQvdGC0YHQutC40LUgU1NMLdGB0LXRgNGC0LjRhNC40LrQsNGC0Ysg?= =?UTF-8?B?KyBuZ3hfaHR0cF9hdXRoX2Jhc2ljX21vZHVsZQ==?= Message-ID: <8237F139-4E29-4070-B048-D97D48A877FC@gmail.com> Добрый день! Хочу посоветоваться. Есть сервер, где зона «для сотрудников» закрыта двумя слоями авторизации: auth_basic + проверка на уровне приложения, с куками, сессиями и прочим. Отказываться от auth_basic не хочется: В коде приложения запросто могут быть ошибки. Забыли, например, завернуть какую-нибудь функцию приложения в декоратор и получили дырку в защите. Сессионную куку могут угнать. XSS, «мутные» плагины для браузеров и т. д. Есть «интимная» статика, которую проверять через auth_request не хочется, т.к. замедляет. Проблема в том, что большинство браузеров неудобно работают с basic_auth: Сафари под iPhone спрашивает пароль каждые несколько часов и даже не заморачивается, чтобы его запомнить. FireFox после рестарта показывает модальный диалог со вводом пароля в одном из окон и блокирует все остальные окна с тем же сайтом. Неудобно, короче. Настроил клиентские сертификаты. Есть сотни мануалов, ничего интересного. Но вот раздача сертификатов сотрудникам и установка их в браузеры – дело муторное. У каждого браузера свои тараканы, сложно объяснить сотруднику по телефону, как поставить сертификат в его браузер и т. д. А если сертификат устареет или придётся его отозвать, совсем беда. Поэтому решил сделать вот какую логику: Если браузер предъявил сертификат, то auth_basic не требуем. Если не предъявил, то пусть вводит логин+пароль через auth_basic. Проверка доступа на уровне приложения никуда не девается, работаем по старому. Я не нашёл способа, как настроить конфиг nginx, чтобы эту логику реализовать. Конструкции с if $ssl_client_verify == "SUCCESS" {} несовместимы с auth_basic. Пока придумал только одно: отпатчил ngx_http_auth_basic_module.c, сделал в нём директиву auth_basic_skip_if_client_cert on/off по которой проверка пароля выключается, если предъявлен валидный клиентский сертификат. Вопросы: Может быть, кто-то решал аналогичную задачу? Чтоб и два слоя защиты для страховки и удобство в повседневной работе? Существует ли решение без патча ngx_http_auth_basic_module.c? Интересен ли кому-нибудь этот патч? Может, на моём велосипеде ещё кто-нибудь хочет покататься? :) С уважением, Владислав ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From inkvizitor68sl на gmail.com Sat Jan 2 05:16:45 2021 From: inkvizitor68sl на gmail.com (Vladislav Zhivotnev) Date: Sat, 02 Jan 2021 08:16:45 +0300 Subject: =?UTF-8?B?UmU6INCa0LvQuNC10L3RgtGB0LrQuNC1IFNTTC3RgdC10YDRgtC40YTQuNC60LA=?= =?UTF-8?B?0YLRiyArIG5neF9odHRwX2F1dGhfYmFzaWNfbW9kdWxl?= In-Reply-To: <8237F139-4E29-4070-B048-D97D48A877FC@gmail.com> Message-ID: Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Sat Jan 2 08:47:57 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sat, 2 Jan 2021 13:47:57 +0500 Subject: =?UTF-8?B?UmU6INCa0LvQuNC10L3RgtGB0LrQuNC1IFNTTC3RgdC10YDRgtC40YTQuNC60LA=?= =?UTF-8?B?0YLRiyArIG5neF9odHRwX2F1dGhfYmFzaWNfbW9kdWxl?= In-Reply-To: <8237F139-4E29-4070-B048-D97D48A877FC@gmail.com> References: <8237F139-4E29-4070-B048-D97D48A877FC@gmail.com> Message-ID: пт, 1 янв. 2021 г. в 22:47, Vladislav Shabanov : > Добрый день! > > Хочу посоветоваться. > Есть сервер, где зона «для сотрудников» закрыта двумя слоями авторизации: > auth_basic > + проверка на уровне приложения, с куками, сессиями и прочим. > > Отказываться от auth_basic не хочется: > > - В коде приложения запросто могут быть ошибки. Забыли, например, > завернуть какую-нибудь функцию приложения в декоратор и получили дырку в > защите. > - Сессионную куку могут угнать. XSS, «мутные» плагины для браузеров и > т. д. > - Есть «интимная» статика, которую проверять через auth_request не > хочется, т.к. замедляет. > > Проблема в том, что большинство браузеров неудобно работают с basic_auth: > Сафари под iPhone спрашивает пароль каждые несколько часов и даже не > заморачивается, чтобы его запомнить. FireFox после рестарта показывает > модальный диалог со вводом пароля в одном из окон и блокирует все остальные > окна с тем же сайтом. Неудобно, короче. > > Настроил клиентские сертификаты. Есть сотни мануалов, ничего интересного. > Но вот раздача сертификатов сотрудникам и установка их в браузеры – дело > муторное. У каждого браузера свои тараканы, сложно объяснить сотруднику по > телефону, как поставить сертификат в его браузер и т. д. А если сертификат > устареет или придётся его отозвать, совсем беда. > > Поэтому решил сделать вот какую логику: > > - Если браузер предъявил сертификат, то *auth_basic* не требуем. > - Если не предъявил, то пусть вводит логин+пароль через *auth_basic*. > - Проверка доступа на уровне приложения никуда не девается, работаем > по старому. > > тут есть подводные камни как минимум с сафари. браузер предъявил или браузер не предъявил на транспортном уровне работает таким образом 1) в серверном SSL Hello выставляется флаг "хочу сертификат" (вы можете намекнуть клиенту, на каких именно УЦ вы хотели бы видеть сертификат, либо "*ssl_verify_client* optional_no_ca;", если вы готовы принимать сертификат любого УЦ) 2) нормальный браузер реагирует так, если он видит, что у него нет клиентских сертификатов на требуемом УЦ, он не пытается спросить у пользователя, и отправляет запрос без сертификата 3) сафари будет требовать пользователя сертификат в любом случае далее на стороне nginx можно настроить обработчик 496 ошибки, мы с таким игрались, туда попадет трафик без клиентских сертов (и там вы сможете реализовать нужную вам логику) > Я не нашёл способа, как настроить конфиг nginx, чтобы эту логику > реализовать. Конструкции с > > if $ssl_client_verify == "SUCCESS" {} > > несовместимы с auth_basic. > error_page 496 ..... > > Пока придумал только одно: отпатчил *ngx_http_auth_basic_module.c*, > сделал в нём директиву > > *auth_basic_skip_if_client_cert* *on/off* > > по которой проверка пароля выключается, если предъявлен валидный > клиентский сертификат. > > Вопросы: > > 1. Может быть, кто-то решал аналогичную задачу? Чтоб и два слоя защиты > для страховки и удобство в повседневной работе? > > кроме описанной вами трудностей с доставкой и установкой клиентских сертов еще есть неприятное поведение сафари > > 1. Существует ли решение без патча ngx_http_auth_basic_module.c? > 2. Интересен ли кому-нибудь этот патч? Может, на моём велосипеде ещё > кто-нибудь хочет покататься? :) > > как-то сейчас oauth более в тренде > > С уважением, > Владислав > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Mon Jan 4 14:59:53 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 4 Jan 2021 16:59:53 +0200 Subject: worker_connections Message-ID: <10e117d5-3cbe-82ab-ccc1-38e27be38554@csdoc.com> Здравствуйте, All! В документации написано, что значение по-умолчанию для директивы worker_connections равно 512. Значение директивы worker_connections равное 512 дает всего лишь 256 одновременных подключений к бекенду. И там же в документации нарисован пример, увеличивающий worker_connections до 2048. Не совсем понятно, чем вызвано такое маленькое значение для директивы worker_connections указано по-умолчанию. worker_connections 512 - это явно не оптимальное значение. Ведь даже в дефолтовом конфиге nginx.conf, который поставляется с nginx указано в два раза большее значение: worker_connections 1024; Каким способом можно подобрать наиболее оптимальное значение для директивы worker_connections - так чтобы nginx не упирался в этот лимит даже в случае DDoS-атак на сервер и в то же время, чтобы память зря не расходовалась? -- Best regards, Gena From gmm на csdoc.com Mon Jan 4 16:03:44 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 4 Jan 2021 18:03:44 +0200 Subject: ssl_protocols In-Reply-To: <20200706191725.GF12747@mdounin.ru> References: <20200625192707.GT12747@mdounin.ru> <20200629140756.GZ12747@mdounin.ru> <78b46597-2110-2cad-6252-8cb2c3d8ac60@csdoc.com> <20200706191725.GF12747@mdounin.ru> Message-ID: On 06.07.2020 22:17, Maxim Dounin wrote: >> On 29.06.2020 17:07, Maxim Dounin wrote: >> >>> Соответственно для включения TLSv1.3 по умолчанию надо решить две >>> проблемы: >>> >>> 1. Сделать решение, которое бы позволило реализовать ту же >>> семантику "отазаться общаться, не предъявляя сертификата" в >>> условиях наличия TLSv1.3. >>> >>> 2. Придумать решение для существующих конфигураций с "ssl_ciphers >>> aNULL; return 444;". >> >> Эти две проблемы выглядят как в принципе не решаемые >> в условиях наличия включенного протокола TLSv1.3. > > Как минимум первая из этих проблем легко решается возвратом ошибки > из ngx_http_ssl_servername(). Основной вопрос - что делать со > второй. И вот тут не совсем понятно, существует ли хорошее > решение, внешнее по отношению к SSL-библиотеке. Первая проблема теперь уже полностью решена, с появлением директивы ssl_reject_handshake http://hg.nginx.org/nginx/rev/59e1c73fe02b Для существующих конфигураций с "ssl_ciphers aNULL;" можно выдавать deprecation warning во время проверки конфига и предлагать поменять этот хак с "ssl_ciphers aNULL;" на директиву ssl_reject_handshake. >>>>> в TLSv1.3 не настраиваются шифры Кстати, да. Что-то директива ssl_conf_command http://hg.nginx.org/nginx/rev/3bff3f397c05 не работает таким образом, как ожидалось. В файле nginx.conf прописано: ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384; При этом сайт ssllabs.com показывает, что включенным остается также и шифр TLS_AES_128_CCM_SHA256 Операционная система CentOS 8, в файле /etc/crypto-policies/back-ends/opensslcnf.config есть такая строчка: Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256 То есть, получается, что не смотря на то, что указано в директиве ssl_conf_command - настройки из файла /etc/crypto-policies/back-ends/opensslcnf.config имеют более высокий приоритет и перекрывают настройки из директивы ssl_conf_command - это так и должно быть? Или можно каким-то образом настройки из файла /etc/crypto-policies/back-ends/opensslcnf.config обойти и сделать так, чтобы nginx мог выключить шифр TLS_AES_128_CCM_SHA256 не редактируя opensslcnf.config? -- Best regards, Gena From gmm на csdoc.com Mon Jan 4 16:37:19 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 4 Jan 2021 18:37:19 +0200 Subject: ssl_protocols In-Reply-To: References: <20200625192707.GT12747@mdounin.ru> <20200629140756.GZ12747@mdounin.ru> <78b46597-2110-2cad-6252-8cb2c3d8ac60@csdoc.com> <20200706191725.GF12747@mdounin.ru> Message-ID: On 04.01.2021 18:03, Gena Makhomed wrote: >>>>>> в TLSv1.3 не настраиваются шифры > Кстати, да. Что-то директива ssl_conf_command > http://hg.nginx.org/nginx/rev/3bff3f397c05 > не работает таким образом, как ожидалось. Sorry, уже все нормально работает. В логах была строчка [emerg] 118#118: unknown directive "ssl_conf_command" in /etc/nginx/nginx.conf:49 - по всей видимости после yum update nginx не обновился и в памяти работала старая версия nginx, хотя на диске лежал бинарник 1.19.6. После перезапуска nginx по команде systemctl restart nginx - теперь уже все работает нормально, так, как и ожидалось. -- Best regards, Gena From mdounin на mdounin.ru Mon Jan 4 17:57:55 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 4 Jan 2021 20:57:55 +0300 Subject: worker_connections In-Reply-To: <10e117d5-3cbe-82ab-ccc1-38e27be38554@csdoc.com> References: <10e117d5-3cbe-82ab-ccc1-38e27be38554@csdoc.com> Message-ID: <20210104175755.GR1147@mdounin.ru> Hello! On Mon, Jan 04, 2021 at 04:59:53PM +0200, Gena Makhomed wrote: > В документации написано, что значение по-умолчанию > для директивы worker_connections равно 512. > > Значение директивы worker_connections равное 512 > дает всего лишь 256 одновременных подключений к бекенду. > > И там же в документации нарисован пример, > увеличивающий worker_connections до 2048. > > Не совсем понятно, чем вызвано такое маленькое значение > для директивы worker_connections указано по-умолчанию. > > worker_connections 512 - это явно не оптимальное значение. > > Ведь даже в дефолтовом конфиге nginx.conf, который поставляется > с nginx указано в два раза большее значение: worker_connections 1024; На некоторых операционных системах 1024 уже упирается в ограничение ОС, поэтому по умолчанию используется 512. При этом даже минимальное значение по умолчанию - в разы больше, чем MaxClients (MaxRequestWorkers) в каком-нибудь Apache, так что нет повода считать, что оно слишком маленькое. Скорее, тут вопрос в том, что сам nginx позволяет существенно больше. Но это уже отдельный вопрос, который в первую очередь упирается в грамотную настройку операционной системы. > Каким способом можно подобрать наиболее оптимальное значение > для директивы worker_connections - так чтобы nginx не упирался > в этот лимит даже в случае DDoS-атак на сервер и в то же время, > чтобы память зря не расходовалась? В первую очередь стоит отталкиваться от того, какое максимальное количество соединений может держать операционная система с конкретными настройками. И настраивать nginx так, чтобы он таки _упирался_ в worker_connections чуть раньше, чем операционная система упрётся в свои ограничения (или nginx упрётся в ограничения операционной системы). Потому что: 1. Если первой упрётся операционная система - то может статься, что операционную систему мы потеряем. 2. А если nginx упрётся в какой-нибудь лимит по max files - то он не сможет принимать входящие соединения вообще, и даже их сразу закрывать после этого, и в то же время accept() будет всегда сообщать о новых соединениях. Как-то игнорировать такое, периодически ругаясь в логи, nginx с некоторых пор умеет, но это категорически неправильный режим работы. 3. При приближении к исчерпанию worker_connections nginx умеет закрывать keepalive-соединения, которые дольше всего не использовались, тем самым снижая нагрузку. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Mon Jan 4 21:36:32 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 5 Jan 2021 00:36:32 +0300 Subject: ssl_protocols In-Reply-To: References: <20200625192707.GT12747@mdounin.ru> <20200629140756.GZ12747@mdounin.ru> <78b46597-2110-2cad-6252-8cb2c3d8ac60@csdoc.com> <20200706191725.GF12747@mdounin.ru> Message-ID: <20210104213632.GS1147@mdounin.ru> Hello! On Mon, Jan 04, 2021 at 06:03:44PM +0200, Gena Makhomed wrote: > On 06.07.2020 22:17, Maxim Dounin wrote: > > >> On 29.06.2020 17:07, Maxim Dounin wrote: > >> > >>> Соответственно для включения TLSv1.3 по умолчанию надо решить две > >>> проблемы: > >>> > >>> 1. Сделать решение, которое бы позволило реализовать ту же > >>> семантику "отазаться общаться, не предъявляя сертификата" в > >>> условиях наличия TLSv1.3. > >>> > >>> 2. Придумать решение для существующих конфигураций с "ssl_ciphers > >>> aNULL; return 444;". > >> > >> Эти две проблемы выглядят как в принципе не решаемые > >> в условиях наличия включенного протокола TLSv1.3. > > > > Как минимум первая из этих проблем легко решается возвратом ошибки > > из ngx_http_ssl_servername(). Основной вопрос - что делать со > > второй. И вот тут не совсем понятно, существует ли хорошее > > решение, внешнее по отношению к SSL-библиотеке. > > Первая проблема теперь уже полностью решена, > с появлением директивы ssl_reject_handshake > http://hg.nginx.org/nginx/rev/59e1c73fe02b > > Для существующих конфигураций с "ssl_ciphers aNULL;" можно выдавать > deprecation warning во время проверки конфига и предлагать поменять > этот хак с "ssl_ciphers aNULL;" на директиву ssl_reject_handshake. Выдавать deprecation warning на какие-то сочетания шифров - это выглядит как плохой путь. Кому что надо - тот то и конфигурит. Что до ssl_reject_handshake, то отстоится - и начнём считать, что оно есть, и кому надо - конфиги поменяли. Тогда и задумаемся о включении TLSv1.3 по умолчанию. Логичным выглядит что-нибудь из первых версий 1.21.x. -- Maxim Dounin http://mdounin.ru/ From igor.bliss на gmail.com Sat Jan 16 17:08:05 2021 From: igor.bliss на gmail.com (Igor Savenko) Date: Sat, 16 Jan 2021 19:08:05 +0200 Subject: =?UTF-8?B?0J7QsdGJ0LjQuSDQutC+0L3RgtC10LrRgdGCINGB0LXRgNCy0LXRgNCw?= Message-ID: Добрый день! Есть задача в одном STREAM модуле создавать и писать в shared memory (mmap, созданной с помощью 'ngx_shm_alloc', а в другом, HTTP модуле, читать из этой shared memory. Есть ли способ положить адрес этой созданной shared memory в какой-то общесерверный контекст, так, чтобы он был доступен на протяжении всей жизни сервера, для всех его воркеров? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Sat Jan 23 17:25:07 2021 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sat, 23 Jan 2021 22:25:07 +0500 Subject: =?UTF-8?B?0YHQtdGA0YLQuNGE0LjQutCw0YIg0L3QsCBmb3J1bS5uZ2lueC5vcmc=?= Message-ID: привет, https://www.ssllabs.com/ssltest/analyze.html?d=forum.nginx.org&s=69.46.5.194&latest недействительный. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From maxim на nginx.com Tue Jan 26 10:16:47 2021 From: maxim на nginx.com (Maxim Konovalov) Date: Tue, 26 Jan 2021 13:16:47 +0300 Subject: =?UTF-8?B?UmU6INGB0LXRgNGC0LjRhNC40LrQsNGCINC90LAgZm9ydW0ubmdpbngub3Jn?= In-Reply-To: References: Message-ID: Приветствую. On 23.01.2021 20:25, Илья Шипицин wrote: > привет, > > https://www.ssllabs.com/ssltest/analyze.html?d=forum.nginx.org&s=69.46.5.194&latest > > > недействительный. forum.nginx.org -- это ресурс не под нашим контролем. Он поддерживается внешним активистом. Сейчас пытаемся с ним связаться. -- Maxim Konovalov From slw на zxy.spb.ru Wed Jan 27 14:08:45 2021 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Wed, 27 Jan 2021 17:08:45 +0300 Subject: =?UTF-8?B?bG9jYXRpb24gLyDQstC90YPRgtGA0LggbG9jYXRpb24gLw==?= Message-ID: <20210127140845.GA1073@zxy.spb.ru> А возможна ли конструкция типа такой: location / { rewrite ....; rewrite ....; location ~ /../(..)... { try_files /$2/$3/$2$3$4_$1.bin @proxy; } location / { try_files /notexist @proxy; } } location @proxy { } Ну т.е. смысл в том, что не попадает под маску -- сразу брать с апстрима, а что под маску попадает -- проверять на диске и если нет -- брать с апстрима. From mdounin на mdounin.ru Wed Jan 27 15:34:15 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 27 Jan 2021 18:34:15 +0300 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIC8g0LLQvdGD0YLRgNC4IGxvY2F0aW9uIC8=?= In-Reply-To: <20210127140845.GA1073@zxy.spb.ru> References: <20210127140845.GA1073@zxy.spb.ru> Message-ID: <20210127153415.GB1121@mdounin.ru> Hello! On Wed, Jan 27, 2021 at 05:08:45PM +0300, Slawa Olhovchenkov wrote: > А возможна ли конструкция типа такой: > > location / { > rewrite ....; > rewrite ....; > location ~ /../(..)... { > try_files /$2/$3/$2$3$4_$1.bin @proxy; > } > location / { > try_files /notexist @proxy; > } > } > location @proxy { > } > > Ну т.е. смысл в том, что не попадает под маску -- сразу брать с > апстрима, а что под маску попадает -- проверять на диске и если нет -- > брать с апстрима. Возможна. Впрочем, в предложенной конструкции вложенный "location /" избыточен, его содержимое можно написать непосредственно во внешнем "location /". Заодно и написанные во внешнем "location /" директивы rewrite обретут какой-то смысл (впрочем, скорее всего по прежнему неверный, так как эти директивы не применяются к запросам, попавшим в любой из вложенных location'ов). -- Maxim Dounin http://mdounin.ru/ From slw на zxy.spb.ru Wed Jan 27 15:43:10 2021 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Wed, 27 Jan 2021 18:43:10 +0300 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIC8g0LLQvdGD0YLRgNC4IGxvY2F0aW9uIC8=?= In-Reply-To: <20210127153415.GB1121@mdounin.ru> References: <20210127140845.GA1073@zxy.spb.ru> <20210127153415.GB1121@mdounin.ru> Message-ID: <20210127154310.GB1073@zxy.spb.ru> On Wed, Jan 27, 2021 at 06:34:15PM +0300, Maxim Dounin wrote: > Hello! > > On Wed, Jan 27, 2021 at 05:08:45PM +0300, Slawa Olhovchenkov wrote: > > > А возможна ли конструкция типа такой: > > > > location / { > > rewrite ....; > > rewrite ....; > > location ~ /../(..)... { > > try_files /$2/$3/$2$3$4_$1.bin @proxy; > > } > > location / { > > try_files /notexist @proxy; > > } > > } > > location @proxy { > > } > > > > Ну т.е. смысл в том, что не попадает под маску -- сразу брать с > > апстрима, а что под маску попадает -- проверять на диске и если нет -- > > брать с апстрима. > > Возможна. Впрочем, в предложенной конструкции вложенный "location /" > избыточен, его содержимое можно написать непосредственно во > внешнем "location /". а кстати, есть ли какой-то более изящный способ сделать внутрений редирект на @proxy в данном случае? > Заодно и написанные во внешнем "location /" директивы rewrite > обретут какой-то смысл (впрочем, скорее всего по прежнему > неверный, так как эти директивы не применяются к запросам, > попавшим в любой из вложенных location'ов). разве rewrite применяется не до разбора вложенных локейшинов? а они не наследуся ли, кстати? да, я забыл в примере укзать, там рядом с rewrite у меня еще и auth_request есть, это тоже добавит сложностей? From mdounin на mdounin.ru Wed Jan 27 16:07:35 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 27 Jan 2021 19:07:35 +0300 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIC8g0LLQvdGD0YLRgNC4IGxvY2F0aW9uIC8=?= In-Reply-To: <20210127154310.GB1073@zxy.spb.ru> References: <20210127140845.GA1073@zxy.spb.ru> <20210127153415.GB1121@mdounin.ru> <20210127154310.GB1073@zxy.spb.ru> Message-ID: <20210127160735.GC1121@mdounin.ru> Hello! On Wed, Jan 27, 2021 at 06:43:10PM +0300, Slawa Olhovchenkov wrote: > On Wed, Jan 27, 2021 at 06:34:15PM +0300, Maxim Dounin wrote: > > > Hello! > > > > On Wed, Jan 27, 2021 at 05:08:45PM +0300, Slawa Olhovchenkov wrote: > > > > > А возможна ли конструкция типа такой: > > > > > > location / { > > > rewrite ....; > > > rewrite ....; > > > location ~ /../(..)... { > > > try_files /$2/$3/$2$3$4_$1.bin @proxy; > > > } > > > location / { > > > try_files /notexist @proxy; > > > } > > > } > > > location @proxy { > > > } > > > > > > Ну т.е. смысл в том, что не попадает под маску -- сразу брать с > > > апстрима, а что под маску попадает -- проверять на диске и если нет -- > > > брать с апстрима. > > > > Возможна. Впрочем, в предложенной конструкции вложенный "location /" > > избыточен, его содержимое можно написать непосредственно во > > внешнем "location /". > > а кстати, есть ли какой-то более изящный способ сделать внутрений > редирект на @proxy в данном случае? Можно сделать error_page 418 @proxy; return 418; "Более изящный" ли это способ - затрудняюсь сказать, но более смешной. Более правильным в данном случае будет просто прописать проксирование явно. > > Заодно и написанные во внешнем "location /" директивы rewrite > > обретут какой-то смысл (впрочем, скорее всего по прежнему > > неверный, так как эти директивы не применяются к запросам, > > попавшим в любой из вложенных location'ов). > > разве rewrite применяется не до разбора вложенных локейшинов? Нет. Дерево location'ов - общее, поиск подходящего location'а по URI - это единая операция. Директивы rewrite применяются из найденного подходящего к запросу location'а. Подробности применения директив rewrite расписаны в описании модуля rewrite, тут: http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html > а они не наследуся ли, кстати? Нет. > да, я забыл в примере укзать, там рядом с rewrite у меня еще и > auth_request есть, это тоже добавит сложностей? Нет, auth_request это простая декларативная директива конфигурации, наследуемая по общим правилам, и каких-либо сложностей с вложенными location'ами от неё не будет. Собственно, с rewrite тоже сложностей нет - просто работают они не так, как предполагает конфигурация в исходном письме. -- Maxim Dounin http://mdounin.ru/ From slw на zxy.spb.ru Wed Jan 27 16:14:27 2021 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Wed, 27 Jan 2021 19:14:27 +0300 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIC8g0LLQvdGD0YLRgNC4IGxvY2F0aW9uIC8=?= In-Reply-To: <20210127160735.GC1121@mdounin.ru> References: <20210127140845.GA1073@zxy.spb.ru> <20210127153415.GB1121@mdounin.ru> <20210127154310.GB1073@zxy.spb.ru> <20210127160735.GC1121@mdounin.ru> Message-ID: <20210127161427.GC1073@zxy.spb.ru> On Wed, Jan 27, 2021 at 07:07:35PM +0300, Maxim Dounin wrote: > Hello! > > On Wed, Jan 27, 2021 at 06:43:10PM +0300, Slawa Olhovchenkov wrote: > > > On Wed, Jan 27, 2021 at 06:34:15PM +0300, Maxim Dounin wrote: > > > > > Hello! > > > > > > On Wed, Jan 27, 2021 at 05:08:45PM +0300, Slawa Olhovchenkov wrote: > > > > > > > А возможна ли конструкция типа такой: > > > > > > > > location / { > > > > rewrite ....; > > > > rewrite ....; > > > > location ~ /../(..)... { > > > > try_files /$2/$3/$2$3$4_$1.bin @proxy; > > > > } > > > > location / { > > > > try_files /notexist @proxy; > > > > } > > > > } > > > > location @proxy { > > > > } > > > > > > > > Ну т.е. смысл в том, что не попадает под маску -- сразу брать с > > > > апстрима, а что под маску попадает -- проверять на диске и если нет -- > > > > брать с апстрима. > > > > > > Возможна. Впрочем, в предложенной конструкции вложенный "location /" > > > избыточен, его содержимое можно написать непосредственно во > > > внешнем "location /". > > > > а кстати, есть ли какой-то более изящный способ сделать внутрений > > редирект на @proxy в данном случае? > > Можно сделать > > error_page 418 @proxy; > return 418; > > "Более изящный" ли это способ - затрудняюсь сказать, но более > смешной. > > Более правильным в данном случае будет просто прописать > проксирование явно. в смысле два раза копировать конфигурацию прокси? она сильно развесистая, не хотелось бы дублирования. > > > Заодно и написанные во внешнем "location /" директивы rewrite > > > обретут какой-то смысл (впрочем, скорее всего по прежнему > > > неверный, так как эти директивы не применяются к запросам, > > > попавшим в любой из вложенных location'ов). > > > > разве rewrite применяется не до разбора вложенных локейшинов? > > Нет. Дерево location'ов - общее, поиск подходящего location'а по > URI - это единая операция. Директивы rewrite применяются из > найденного подходящего к запросу location'а. Подробности > применения директив rewrite расписаны в описании модуля rewrite, > тут: > > http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html читал, но понял видимо неправильно, в том куске который "Если директива указана внутри location, дальнейшая обработка запроса продолжается в этом location.". я это понял так, что при наличии там вложенных локейшинов подбор будет продолжен с них. а почему, кстати, может игнориоваться директива set? я по дебаг логу смотрю, попадаю во вложенный локейшен, там у меня есть set но он даже выполняться не собирался. да, сейчас туда скопированы rewrite. From nginx-forum на forum.nginx.org Wed Jan 27 16:58:42 2021 From: nginx-forum на forum.nginx.org (denltsb) Date: Wed, 27 Jan 2021 11:58:42 -0500 Subject: nginx/ Rest API Message-ID: Доброе время суток. не знаю куда уже обратиться может тут подскажите. есть связка centos7/ nginx 1.18/ php7.3/ на нем вертится GLPI 9.5.3. проблема в том что хочу подключиться к нему с приложения для андроид Gapp версии 1.2 настроил все по инструкции от разработчиков ,и в итоге при подключении в андроид и (вожу логин и пароль ) вижу как приложение открывает веб страницу где опять спрашивается логин и пароль как в браузере , но туда вести я их не могу, любой нажатие на экран и он начинает автоматически бесконечно подключаться на сервер. в логах сервера пусто, как закроеш приложение сервер пишет неудачна попытка входа. я Выяснил , что входим в Gapp в своей среде GLPI, Gapp ожидает json с токеном, предоставленным сервером. Если вместо этого сервер дает взамен html-веб-страницу, Gapp показывает ее . Обычно такого рода проблемы относятся к брандмауэру, прокси-серверам и всевозможным блокировщикам. В сервере нет файла json (до этого настраивал OTRS там был json файл и удалось настроить для доступа с приложения), как мне сконфигурировать свой nginx что бы он принимал запросы от приложения gapp. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,290584,290584#msg-290584 From mdounin на mdounin.ru Wed Jan 27 17:35:41 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 27 Jan 2021 20:35:41 +0300 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIC8g0LLQvdGD0YLRgNC4IGxvY2F0aW9uIC8=?= In-Reply-To: <20210127161427.GC1073@zxy.spb.ru> References: <20210127140845.GA1073@zxy.spb.ru> <20210127153415.GB1121@mdounin.ru> <20210127154310.GB1073@zxy.spb.ru> <20210127160735.GC1121@mdounin.ru> <20210127161427.GC1073@zxy.spb.ru> Message-ID: <20210127173541.GD1121@mdounin.ru> Hello! On Wed, Jan 27, 2021 at 07:14:27PM +0300, Slawa Olhovchenkov wrote: > On Wed, Jan 27, 2021 at 07:07:35PM +0300, Maxim Dounin wrote: > > > Hello! > > > > On Wed, Jan 27, 2021 at 06:43:10PM +0300, Slawa Olhovchenkov wrote: > > > > > On Wed, Jan 27, 2021 at 06:34:15PM +0300, Maxim Dounin wrote: > > > > > > > Hello! > > > > > > > > On Wed, Jan 27, 2021 at 05:08:45PM +0300, Slawa Olhovchenkov wrote: > > > > > > > > > А возможна ли конструкция типа такой: > > > > > > > > > > location / { > > > > > rewrite ....; > > > > > rewrite ....; > > > > > location ~ /../(..)... { > > > > > try_files /$2/$3/$2$3$4_$1.bin @proxy; > > > > > } > > > > > location / { > > > > > try_files /notexist @proxy; > > > > > } > > > > > } > > > > > location @proxy { > > > > > } > > > > > > > > > > Ну т.е. смысл в том, что не попадает под маску -- сразу брать с > > > > > апстрима, а что под маску попадает -- проверять на диске и если нет -- > > > > > брать с апстрима. > > > > > > > > Возможна. Впрочем, в предложенной конструкции вложенный "location /" > > > > избыточен, его содержимое можно написать непосредственно во > > > > внешнем "location /". > > > > > > а кстати, есть ли какой-то более изящный способ сделать внутрений > > > редирект на @proxy в данном случае? > > > > Можно сделать > > > > error_page 418 @proxy; > > return 418; > > > > "Более изящный" ли это способ - затрудняюсь сказать, но более > > смешной. > > > > Более правильным в данном случае будет просто прописать > > проксирование явно. > > в смысле два раза копировать конфигурацию прокси? > она сильно развесистая, не хотелось бы дублирования. Конфигурацию прокси можно задать на уровне http или server, а в соответствующих location'ах писать исключительно proxy_pass. Если конфигурацию зачем-то требуется задавать непосредственно в location - то это можно сделать с помощью директивы include. > > > > Заодно и написанные во внешнем "location /" директивы rewrite > > > > обретут какой-то смысл (впрочем, скорее всего по прежнему > > > > неверный, так как эти директивы не применяются к запросам, > > > > попавшим в любой из вложенных location'ов). > > > > > > разве rewrite применяется не до разбора вложенных локейшинов? > > > > Нет. Дерево location'ов - общее, поиск подходящего location'а по > > URI - это единая операция. Директивы rewrite применяются из > > найденного подходящего к запросу location'а. Подробности > > применения директив rewrite расписаны в описании модуля rewrite, > > тут: > > > > http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html > > читал, но понял видимо неправильно, в том куске который "Если > директива указана внутри location, дальнейшая обработка запроса > продолжается в этом location.". я это понял так, что при наличии там > вложенных локейшинов подбор будет продолжен с них. Это часть описания директивы break, и она верна в том смысле, что если директива break будет выполнена - то дальнейшкая обработка продолжится в том location, в котором указана директива break, то есть даже если URI запроса изменился, nginx не будет снова искать location, соответствующий новому URI запроса. Читать в первую очередь следует основную схему работы, которая расписана непосредственно в описании модуля: : Директивы break, if, return, rewrite и set обрабатываются в : следующем порядке: : : - последовательно выполняются директивы этого модуля, описанные на : уровне server; : - в цикле: : - ищется location по URI запроса; : - последовательно выполняются директивы этого модуля, описанные в : найденном location; : - цикл повторяется, если URI запроса изменялся, но не более 10 раз. Соответственно директива break позволяет изменить URI и выйти из цикла несмотря на это, но никак не влияет на то, что поиск location по URI запроса - единая операция. > а почему, кстати, может игнориоваться директива set? > я по дебаг логу смотрю, попадаю во вложенный локейшен, там у меня есть > set но он даже выполняться не собирался. Простейшая причина - обработка директив модуля rewrite остановлена с помощью директивы break или "rewrite ... break". -- Maxim Dounin http://mdounin.ru/ From slw на zxy.spb.ru Wed Jan 27 17:52:48 2021 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Wed, 27 Jan 2021 20:52:48 +0300 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIC8g0LLQvdGD0YLRgNC4IGxvY2F0aW9uIC8=?= In-Reply-To: <20210127173541.GD1121@mdounin.ru> References: <20210127140845.GA1073@zxy.spb.ru> <20210127153415.GB1121@mdounin.ru> <20210127154310.GB1073@zxy.spb.ru> <20210127160735.GC1121@mdounin.ru> <20210127161427.GC1073@zxy.spb.ru> <20210127173541.GD1121@mdounin.ru> Message-ID: <20210127175248.GD1073@zxy.spb.ru> On Wed, Jan 27, 2021 at 08:35:41PM +0300, Maxim Dounin wrote: > > > > а кстати, есть ли какой-то более изящный способ сделать внутрений > > > > редирект на @proxy в данном случае? > > > > > > Можно сделать > > > > > > error_page 418 @proxy; > > > return 418; > > > > > > "Более изящный" ли это способ - затрудняюсь сказать, но более > > > смешной. > > > > > > Более правильным в данном случае будет просто прописать > > > проксирование явно. > > > > в смысле два раза копировать конфигурацию прокси? > > она сильно развесистая, не хотелось бы дублирования. > > Конфигурацию прокси можно задать на уровне http или server, а в > соответствующих location'ах писать исключительно proxy_pass. Если в том числе и proxy_cache proxy_hide_header aws_sign ? > конфигурацию зачем-то требуется задавать непосредственно в > location - то это можно сделать с помощью директивы include. From mdounin на mdounin.ru Wed Jan 27 18:08:47 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 27 Jan 2021 21:08:47 +0300 Subject: =?UTF-8?B?UmU6IGxvY2F0aW9uIC8g0LLQvdGD0YLRgNC4IGxvY2F0aW9uIC8=?= In-Reply-To: <20210127175248.GD1073@zxy.spb.ru> References: <20210127140845.GA1073@zxy.spb.ru> <20210127153415.GB1121@mdounin.ru> <20210127154310.GB1073@zxy.spb.ru> <20210127160735.GC1121@mdounin.ru> <20210127161427.GC1073@zxy.spb.ru> <20210127173541.GD1121@mdounin.ru> <20210127175248.GD1073@zxy.spb.ru> Message-ID: <20210127180847.GF1121@mdounin.ru> Hello! On Wed, Jan 27, 2021 at 08:52:48PM +0300, Slawa Olhovchenkov wrote: > On Wed, Jan 27, 2021 at 08:35:41PM +0300, Maxim Dounin wrote: > > > > > > а кстати, есть ли какой-то более изящный способ сделать внутрений > > > > > редирект на @proxy в данном случае? > > > > > > > > Можно сделать > > > > > > > > error_page 418 @proxy; > > > > return 418; > > > > > > > > "Более изящный" ли это способ - затрудняюсь сказать, но более > > > > смешной. > > > > > > > > Более правильным в данном случае будет просто прописать > > > > проксирование явно. > > > > > > в смысле два раза копировать конфигурацию прокси? > > > она сильно развесистая, не хотелось бы дублирования. > > > > Конфигурацию прокси можно задать на уровне http или server, а в > > соответствующих location'ах писать исключительно proxy_pass. Если > > в том числе и proxy_cache proxy_hide_header aws_sign ? Все настройки проксирования, включая proxy_cache и proxy_hide_header, можно задавать на любом уровне, они наследуются (как, собственно, и большинство стандартных директив). Явно нужно задавать только собственно proxy_pass - эта директива задаёт обработку location'а, и такие директивы не наследуются, соответственно их надо задавать явно. Хотя конкретно proxy_cache я бы тоже рекомендовал задавать явно по месту, вместе с proxy_pass, просто для улучшения читаемости конфигурации. Что до aws_sign, то в прошлый раз, если мне не изменяет память, мы выяснили, что оно просто не работает, как ни задавай. -- Maxim Dounin http://mdounin.ru/ From igor.bliss на gmail.com Wed Jan 27 18:49:30 2021 From: igor.bliss на gmail.com (Igor Savenko) Date: Wed, 27 Jan 2021 20:49:30 +0200 Subject: =?UTF-8?B?0J7QsdGJ0LXRgdC10YDQstC10YDQvdGL0Lkg0LrQvtC90YLQtdC60YHRgg==?= Message-ID: Добрый день! Подскажите, пожалуйста, можно ли указатель на созданную в одном STREAM модуле (слушает на UNIX сокете) shared memory (mmap, созданной с помощью 'ngx_shm_alloc') передать через какой-либо общесерверный контекст в другой, HTTP, модуль, чтобы эта shared memory была доступна для всех воркеров на протяжении всей жизни сервера. Есть ли вообще такой контекст? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Thu Jan 28 01:00:11 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 28 Jan 2021 03:00:11 +0200 Subject: =?UTF-8?B?0J/RgNC+0YLQvtC60L7QuyBUTFN2MS4zINC4INC00LjRgNC10LrRgtC40LLQsCBz?= =?UTF-8?B?c2xfcmVqZWN0X2hhbmRzaGFrZSDQsiDRgdC10YDQstC10YDQtSDQv9C+LdGD?= =?UTF-8?B?0LzQvtC70YfQsNC90LjRjg==?= Message-ID: Здравствуйте, All! nginx/1.19.6 из официального репозитория nginx.org openssl-1.1.1g-12.el8_3.x86_64 из репозитория CentOS 8.3 Протокол TLSv1.3 включен, но если в сервере по умолчанию прописать директиву "ssl_reject_handshake on;" тогда протокол TLSv1.3 перестает работать для всех серверов. Фрагмент конфигурации nginx на уровне http: http { # ... ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers off; ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384; ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384; # ... } Комментирование директивы "ssl_conf_command Ciphersuites ... ;" не помогает решить проблему - протокол TLSv1.3 по прежнему не работает. Конфигурация сервера по-умолчанию: # cat /etc/nginx/conf.d/default.conf server { listen 111.111.111.111:443 bind default_server ssl http2; ssl_reject_handshake on; server_name default-server; location / { return 444; } } Конфигурация обычного сервера: # cat /etc/nginx/conf.d/example.com.conf server { listen 111.111.111.111:443 ssl http2; server_name example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; add_header Strict-Transport-Security max-age=31536000 always; location / { return 200 "OK"; } } Попытка подключения к серверу example.com по протоколу TLSv1.3 завершается ошибкой: # openssl s_client -tls1_3 -connect example.com:443 -servername example.com CONNECTED(00000003) 140542584969024:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:1543:SSL alert number 70 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 235 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- Это ошибка в nginx или я что-то делаю не так? Если в сервере по-умолчанию закомментировать директиву "ssl_reject_handshake on;" и прописать какой-нибудь сертификат, #ssl_reject_handshake on; ssl_certificate /etc/letsencrypt/live/example.net/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.net/privkey.pem; Тогда попытка подключения к серверу example.com по протоколу TLSv1.3 завершается успешно: # openssl s_client -tls1_3 -connect example.com:443 -servername example.com CONNECTED(00000003) --- Certificate chain 0 s:CN = example.com i:C = US, O = Let's Encrypt, CN = R3 1 s:C = US, O = Let's Encrypt, CN = R3 i:O = Digital Signature Trust Co., CN = DST Root CA X3 --- Server certificate -----BEGIN CERTIFICATE----- [...] -- Best regards, Gena From boco на ufanet.ru Thu Jan 28 04:08:43 2021 From: boco на ufanet.ru (damir bikmuhametov) Date: Thu, 28 Jan 2021 09:08:43 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtGC0L7QutC+0LsgVExTdjEuMyDQuCDQtNC40YDQtdC60YLQuNCy?= =?UTF-8?B?0LAgc3NsX3JlamVjdF9oYW5kc2hha2Ug0LIg0YHQtdGA0LLQtdGA0LUg0L8=?= =?UTF-8?B?0L4t0YPQvNC+0LvRh9Cw0L3QuNGO?= In-Reply-To: References: Message-ID: <20210128040842.GB66656@ufanet.ru> On Thu, Jan 28, 2021 at 03:00:11AM +0200, Gena Makhomed wrote: > Протокол TLSv1.3 включен, но если в сервере по умолчанию прописать > директиву "ssl_reject_handshake on;" тогда протокол TLSv1.3 перестает > работать для всех серверов. https://forum.nginx.org/read.php?2,290250 оно? -- boco From gmm на csdoc.com Thu Jan 28 09:56:05 2021 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 28 Jan 2021 11:56:05 +0200 Subject: =?UTF-8?B?UmU6INCf0YDQvtGC0L7QutC+0LsgVExTdjEuMyDQuCDQtNC40YDQtdC60YLQuNCy?= =?UTF-8?B?0LAgc3NsX3JlamVjdF9oYW5kc2hha2Ug0LIg0YHQtdGA0LLQtdGA0LUg0L8=?= =?UTF-8?B?0L4t0YPQvNC+0LvRh9Cw0L3QuNGO?= In-Reply-To: <20210128040842.GB66656@ufanet.ru> References: <20210128040842.GB66656@ufanet.ru> Message-ID: <0195d7a6-782d-56c3-ebb0-7604fcc782f9@csdoc.com> On 28.01.2021 6:08, damir bikmuhametov wrote: >> Протокол TLSv1.3 включен, но если в сервере по умолчанию прописать >> директиву "ssl_reject_handshake on;" тогда протокол TLSv1.3 перестает >> работать для всех серверов. > https://forum.nginx.org/read.php?2,290250 оно? да. Вот ссылка на архив списка рассылки, которая работает без ошибок: http://mailman.nginx.org/pipermail/nginx/2020-December/060251.html ================================================================== P.S. Кстати, certbot начиная с версии 1.10 научился генерировать ECDSA сертификаты: https://certbot.eff.org/docs/using.html#using-ecdsa-keys И как оказалось он поддерживает файл конфигурации /etc/letsencrypt/cli.ini в котором можно прописать значение по-умолчанию для многих параметров командной строки. Например: # cat /etc/letsencrypt/cli.ini key-type = ecdsa elliptic-curve = secp256r1 authenticator = webroot webroot-path = /opt/letsencrypt agree-tos = True reuse-key = False no-eff-email = True ======================================== тогда новый ecdsa сертификат можно выпустить с помощью команды certbot certonly -d example.com -d www.example.com а существующий RSA - переделать на ECDSA с помощью команды certbot certonly --cert-name example.com -d example.com -d www.example.com -- Best regards, Gena From nginx на kinetiksoft.com Thu Jan 28 16:37:17 2021 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Thu, 28 Jan 2021 19:37:17 +0300 Subject: Is if evil with rewrite ... redirect? Message-ID: <0b7d8c1b-d85d-9261-8879-bc92e1ab5dcb@kinetiksoft.com> Здравствуйте! Вопрос коротко: является ли rewrite ... redirect на 100% безопасным при использовании if внутри location. Подробнее: В https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/ > The only 100% safe things which may be done inside if in a location > context are: > > * return > > ...; > * rewrite > > ... last; > то есть единственным вариантов rewrite на 100% безопасным с if в location написан rewrite с last. Учитывая написанное в статье далее и моё понимание nginx предполагаю, что rewrite можно не только с last, но так же с redirect и permanent, так как исключают выполнение других директив в рамках этого локейшена. "Возможно опасными" тут могут быть только break и, вероятно, отсуствие флагов rewrite так как оставляют возможность выполнения других директив не из модуля rewrite. Я прав? С уважением, Иван. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Jan 28 18:06:33 2021 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 28 Jan 2021 21:06:33 +0300 Subject: Is if evil with rewrite ... redirect? In-Reply-To: <0b7d8c1b-d85d-9261-8879-bc92e1ab5dcb@kinetiksoft.com> References: <0b7d8c1b-d85d-9261-8879-bc92e1ab5dcb@kinetiksoft.com> Message-ID: <20210128180633.GH1121@mdounin.ru> Hello! On Thu, Jan 28, 2021 at 07:37:17PM +0300, Иван wrote: > Здравствуйте! > > Вопрос коротко: является ли > > rewrite ... redirect на 100% безопасным при использовании if внутри > location. > > > Подробнее: > > В https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/ > > > The only 100% safe things which may be done inside if in a location > > context are: > > > > * return > > > > ...; > > * rewrite > > > > ... last; > > > то есть единственным вариантов rewrite на 100% безопасным с if в > location написан rewrite с last. Учитывая написанное в статье далее и > моё понимание nginx предполагаю, что rewrite можно не только с last, но > так же с redirect и permanent, так как исключают выполнение других > директив в рамках этого локейшена. > > "Возможно опасными" тут могут быть только break и, вероятно, отсуствие > флагов rewrite так как оставляют возможность выполнения других директив > не из модуля rewrite. > > Я прав? Не совсем. Там, собственно, кто-то бред написал про "100% safe", да останется это на совести того, кто полез править написанную мной статью, не понимая её. Не бывает "100% безопасного" использования if'а внутри location'а, в лучшем случае бывает просто безопасное использование. Возвращаясь к исходному вопросу про безопасность "rewrite ... last", то ответ тут длинный. В случае if'а безопасность достигается ровно одним способом: обработка запроса не должна происходить внутри неявного location'а, созданного if'ом. Это бывает в случае "rewrite ... last", а также почти бывает в случае "return", если по этому return'у nginx куда-то уходит в рамках error_page. Если же речь идёт о том, что клиенту возвращается ответ - как в случае "return" без соответствующего error_page или "rewrite ... redirect" - то мы уже попадаем на отдельную конфигурацию, в рамках которой этот ответ возвращается. Каких-либо известных проблем в подобных ситуациях - нет, по крайней мере со стандартными модулями. Да и со сторонними скорее всего тоже - там будет простое наследование конфигурации, накосячить сложно. Но таки никто не гарантирует, что прооблем нет совсем. -- Maxim Dounin http://mdounin.ru/ From patriotlv на rambler.ru Thu Jan 28 19:08:34 2021 From: patriotlv на rambler.ru (resident) Date: Thu, 28 Jan 2021 22:08:34 +0300 Subject: =?UTF-8?B?cmF0ZV9saW1pdF90b3RhbCDQtNC70Y8g0LLRgdC10LPQviDRgdC10YDQstC10YA=?= =?UTF-8?B?0LA=?= Message-ID: <1611860914.582568.31861.16749@mail.rambler.ru> Добрый день. Прошу помощь зала. Есть задача ограничить каждый виртуальный сервер по скорости. Скажем есть сайт site1.com с заданной скоростью в 4096КиБ/с и site2.com с 2048КиБ/с. Как сделать что бы одно соединение обрабатывалось на максимальной скорости а остальные на пониженной в зависимости от количества соединений. То бишь что бы $limit_rate выставлялся автоматически в зависимости от уже имеющихся соединений при заданной общей скорости.Можно было бы решить это с $connections_active но она для всего сервера. Или новой директивой $limit_rate_total. На сколько сложно это реализовать или может есть какие то варианты используя текущую реализацию? server { listen 80; server_name site1.com; access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log info;if ($connections_active = 1) { set $limit_rate 4096k; } if ($connections_active = 2) { set $limit_rate 2048k; } if ($connections_active = 3) { set $limit_rate 1365k; } .. if ($connections_active = 100) { set $limit_rate 40k; }#$limit_rate_total 4096k;root /home/user/sites/site.com/www; } server { listen 80; server_name site2.com; access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log info;if ($connections_active = 1) { set $limit_rate 2048k; } if ($connections_active = 2) { set $limit_rate 1024k; } if ($connections_active = 3) { set $limit_rate 682k; } ...... if ($connections_active = 100) { set $limit_rate 20k; }#$limit_rate_total 2048k;root /home/user/sites/site.com/www; } ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From slw на zxy.spb.ru Fri Jan 29 14:28:32 2021 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Fri, 29 Jan 2021 17:28:32 +0300 Subject: =?UTF-8?B?JHVyaSDQtNC70Y8gdHJ5X2ZpbGVz?= Message-ID: <20210129142832.GE1073@zxy.spb.ru> А есть какой-то способ в случае try_files логировать не имя файла, которе совпало, а собственно текущий uri? $request_uri не подходит т.к. во-первых с аргументами, во-вторых потом его через rewrite прогнали. Т.е. я хочу в лог записать без аргументов, после rewrite, но не результат try_files.