From a.kunich на webguard.pro Mon Oct 3 07:30:17 2022 From: a.kunich на webguard.pro (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCa0YPQvdC40Yc=?=) Date: Mon, 3 Oct 2022 10:30:17 +0300 Subject: =?UTF-8?B?0J3QtSDQv9C+0L3Rj9GC0L3QsCDQu9C+0LPQuNC60LAg0YDQsNCx0L4=?= =?UTF-8?Q?=d1=82=d1=8b_hash_consistent?= Message-ID: <0a9b94e4-0e6c-805f-09e4-090cc8fffd86@webguard.pro> Здравствуйте. Подскажите пожалуйста, это у меня не работает консистентное хеширование или я не верно понимаю алгоритм его работы. У меня в системе апстримы в конфигурации ниже являются кеширующими прокси. Недавно понадобилось перераспределить часть нагрузки между ними и понял, что веса работают не так, как я ожидал. Опишу по порядку. С пол года конфигурация была такой. Кеш на прокси апстримах прогрелся до 95% попаданий. upstream upstream_meed {     server  192.168.1.1:8080 max_fails=3 fail_timeout=30s;     server  192.168.1.2:8080 backup max_fails=3 fail_timeout=30s;     server  192.168.1.3:8080 max_fails=3 fail_timeout=30s;     hash $request_uri consistent;     keepalive 128; } Затем понадобилось часть нагрузки перенести на 192.168.1.2. Снял метку backup  с 192.168.1.2 , готовился к тому, что попадания в кеш на 192.168.1.1 и 192.168.1.3 снизятся, но этого не произошло. Просто нагрузка на 192.168.1.2 существенно выросла. Тут первый вопрос - почему? Т.е. как ketama должен обрабатывать метку backup? Далее потребовалось перераспределить ещё немного нагрузку и вот тут выявилось самое интересное. upstream upstream_meed {     server  192.168.1.1:8080 weight=13 max_fails=3 fail_timeout=30s;     server  192.168.1.2:8080 weight=7 max_fails=3 fail_timeout=30s;     server  192.168.1.3:8080 weight=10 max_fails=3 fail_timeout=30s;     hash $request_uri consistent;     keepalive 128; } В этой конфигурации ожидалось, что 192.168.1.3 останется на прежнем месте круга хеширования кетама и промахов кеша у него не добавится. Но оказалось вовсе не так. Промахи добавились везде и существенно. Далее я попробовал у всех серверов выставить последовательно одинаковые веса. Сначала всем weight=1 - попадания в кеш восстановились, затем всем выставил weight=10 - попадания с 95% упали почти до 50%. До этого я полагал, что в алгоритме хеширования кетама играет роль пропорциональность весов и порядковое место сервера в списке. Согласно этого понимания, две приведённые ниже конфигурации должны быть равнозначны в плане попаданий кеш. upstream upstream_meed {     server  192.168.1.1:8080 weight=1 max_fails=3 fail_timeout=30s;     server  192.168.1.2:8080 weight=1 max_fails=3 fail_timeout=30s;     server  192.168.1.3:8080 weight=1 max_fails=3 fail_timeout=30s;     hash $request_uri consistent;     keepalive 128; } upstream upstream_meed {     server  192.168.1.1:8080 weight=10 max_fails=3 fail_timeout=30s;     server  192.168.1.2:8080 weight=10 max_fails=3 fail_timeout=30s;     server  192.168.1.3:8080 weight=10 max_fails=3 fail_timeout=30s;     hash $request_uri consistent;     keepalive 128; } На практике у меня это не работает. С весом 10 попадания сильно уменьшаются. Это я что-то не так понимаю или у меня не работает ketama ? Заранее, большое спасибо за помощь. С уважением, Александр Кунич. From mdounin на mdounin.ru Mon Oct 3 14:06:50 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 3 Oct 2022 17:06:50 +0300 Subject: =?koi8-r?B?7sUg0M/O0dTOwSDMz8fJy8Eg?= =?koi8-r?B?0sHCz9TZ?= hash consistent In-Reply-To: <0a9b94e4-0e6c-805f-09e4-090cc8fffd86@webguard.pro> References: <0a9b94e4-0e6c-805f-09e4-090cc8fffd86@webguard.pro> Message-ID: Hello! On Mon, Oct 03, 2022 at 10:30:17AM +0300, Александр Кунич via nginx-ru wrote: > Здравствуйте. > > Подскажите пожалуйста, это у меня не работает консистентное хеширование > или я не верно понимаю алгоритм его работы. > > У меня в системе апстримы в конфигурации ниже являются кеширующими > прокси. Недавно понадобилось перераспределить часть нагрузки между ними > и понял, что веса работают не так, как я ожидал. > > Опишу по порядку. С пол года конфигурация была такой. Кеш на прокси > апстримах прогрелся до 95% попаданий. > > upstream upstream_meed { >     server  192.168.1.1:8080 max_fails=3 fail_timeout=30s; >     server  192.168.1.2:8080 backup max_fails=3 fail_timeout=30s; >     server  192.168.1.3:8080 max_fails=3 fail_timeout=30s; >     hash $request_uri consistent; >     keepalive 128; > } > > Затем понадобилось часть нагрузки перенести на 192.168.1.2. Снял метку > backup  с 192.168.1.2 , готовился к тому, что попадания в кеш на > 192.168.1.1 и 192.168.1.3 снизятся, но этого не произошло. Просто > нагрузка на 192.168.1.2 существенно выросла. Тут первый вопрос - почему? > Т.е. как ketama должен обрабатывать метку backup? При consistent-хэшировании, как и при прочей балансировке, backup-сервера используются только в случае, если от основных серверов ответа получить не удалось из-за ошибок. Соответственно в вашем случае в конфигурацию, фактически, был добавлен сервер 192.168.1.2. Для consistent-хэширования добавление нового сервера означает, что часть нагрузки с существующих серверов будет перенесена на добавленный. Больше никаких изменений не будет. Соответственно то, что процент попаданий в кэш на ранее использовавшихся серверах не поменялся - это вполне нормально, так как исключены ситуации, когда запрос ранее попадал на 192.168.1.1, а теперь стал попадать на 192.168.1.3 (или наоборот). При этом часть кэша на 192.168.1.1 и 192.168.1.3 стала не нужна (так как соответствующие запросы уехали на 192.168.1.2), но на процент попаданий в кэш оставшихся запросов это влиять никак не должно. > Далее потребовалось перераспределить ещё немного нагрузку и вот тут > выявилось самое интересное. > > upstream upstream_meed { >     server  192.168.1.1:8080 weight=13 max_fails=3 fail_timeout=30s; >     server  192.168.1.2:8080 weight=7 max_fails=3 fail_timeout=30s; >     server  192.168.1.3:8080 weight=10 max_fails=3 fail_timeout=30s; >     hash $request_uri consistent; >     keepalive 128; > } > > В этой конфигурации ожидалось, что 192.168.1.3 останется на прежнем > месте круга хеширования кетама и промахов кеша у него не добавится. Но > оказалось вовсе не так. Промахи добавились везде и существенно. Далее я > попробовал у всех серверов выставить последовательно одинаковые веса. > Сначала всем weight=1 - попадания в кеш восстановились, затем всем > выставил weight=10 - попадания с 95% упали почти до 50%. > > До этого я полагал, что в алгоритме хеширования кетама играет роль > пропорциональность весов и порядковое место сервера в списке. Согласно > этого понимания, две приведённые ниже конфигурации должны быть > равнозначны в плане попаданий кеш. > > upstream upstream_meed { >     server  192.168.1.1:8080 weight=1 max_fails=3 fail_timeout=30s; >     server  192.168.1.2:8080 weight=1 max_fails=3 fail_timeout=30s; >     server  192.168.1.3:8080 weight=1 max_fails=3 fail_timeout=30s; >     hash $request_uri consistent; >     keepalive 128; > } > > upstream upstream_meed { >     server  192.168.1.1:8080 weight=10 max_fails=3 fail_timeout=30s; >     server  192.168.1.2:8080 weight=10 max_fails=3 fail_timeout=30s; >     server  192.168.1.3:8080 weight=10 max_fails=3 fail_timeout=30s; >     hash $request_uri consistent; >     keepalive 128; > } > > На практике у меня это не работает. С весом 10 попадания сильно > уменьшаются. Это я что-то не так понимаю или у меня не работает ketama ? При consistent-хэшировании вес реализован с помощью добавления дополнительных точек для данного сервера. То есть, фактически, увеличение веса сервера с 1 до 2 эквивалентно добавлению ещё одного сервера. Соответственно изменение весов трёх серверов с 1 на 10 эквивалентно добавлению 27 новых серверов, и ожидаемо приводит к сильной ребалансировке существующих запросов между серверами. Ну и да, при consistent-хэшировании, конечно, порядок серверов не имеет значения, и так как добавляемые на круг хэширования точки зависят только от имени сервера, но не от его места в списке. Как раз отсутствие зависимости от порядка - одно из важных отличий от обычного хэширования. -- Maxim Dounin http://mdounin.ru/ From Vladimir.Korobov на infotecs.ru Tue Oct 4 12:00:57 2022 From: Vladimir.Korobov на infotecs.ru (Korobov Vladimir) Date: Tue, 4 Oct 2022 12:00:57 +0000 Subject: =?koi8-r?B?6dPQ0sHXzMXOydEg09LBwsHU2dfBzsnKINPUwdTJ3sXTy8/HzyDBzsHMydrB?= =?koi8-r?B?1M/SwS4=?= Message-ID: Добрый день После проверки исходного кода статическим анализатором (Svace https://www.ispras.ru/technologies/svace/) выделено несколько потенциально опасных мест, закрывающихся приложенным патчем. Прошу рассмотреть возможность включения указанных изменений в исходный код проекта. С уважением, Владимир Коробов ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: ----------- следующая часть ----------- Вложение не в текстовом формате было извлечено… Имя: fix_critical_errors.patch Тип: application/octet-stream Размер: 3646 байтов Описание: fix_critical_errors.patch URL: From slw на zxy.spb.ru Tue Oct 4 13:04:55 2022 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Tue, 4 Oct 2022 16:04:55 +0300 Subject: =?utf-8?B?0JjRgdC/0YDQsNCy0LvQtdC90Lg=?= =?utf-8?B?0Y8g0YHRgNCw0LHQsNGC0YvQstCw0L3QuNC5INGB0YLQsNGC0LjRh9C10YE=?= =?utf-8?B?0LrQvtCz0L4g0LDQvdCw0LvQuNC30LDRgtC+0YDQsC4=?= In-Reply-To: References: Message-ID: <20221004130455.GI14170@zxy.spb.ru> On Tue, Oct 04, 2022 at 12:00:57PM +0000, Korobov Vladimir via nginx-ru wrote: > Добрый день > > После проверки исходного кода статическим анализатором (Svace https://www.ispras.ru/technologies/svace/) выделено несколько потенциально опасных мест, закрывающихся приложенным патчем. > > Прошу рассмотреть возможность включения указанных изменений в исходный код проекта. а эти исправления на самом деле что делают? Успокаивают статистический анализатор или исправляют ошибки? From bgx на protva.ru Tue Oct 4 13:11:41 2022 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Tue, 4 Oct 2022 16:11:41 +0300 Subject: =?koi8-r?B?6dPQ0sHXzMXOydEg09LBwsHU?= =?koi8-r?B?2dfBzsnKINPUwdTJ3sXTy8/HzyDBzsHMydrB1M/SwS4=?= In-Reply-To: References: Message-ID: On Tue, Oct 04, 2022 at 12:00:57PM +0000, Korobov Vladimir via nginx-ru wrote: > После проверки исходного кода статическим анализатором (Svace > https://www.ispras.ru/technologies/svace/) выделено несколько потенциально > опасных мест, закрывающихся приложенным патчем. Тупое выбрасывание кусков кода при проверке указателя на NULL не только не решает проблему, но создаёт более опасную ситуацию, когда код приложения может работать неверно, но ничего об этом не сообщать, так что поймать баг станет очень трудно. Лучше сегфолт в в точно локализованном месте, чем глюки непонятно где и непонятно отчего. При потенциальной возможности зануления указателя следует ловить и обрабатывать такое исключение. В противном случае нет смысла в проверке. Задача же не в ублажении тупых анализаторов, а в правильной работе кода. -- Eugene Berdnikov From eugen на grosbein.net Tue Oct 4 16:33:14 2022 From: eugen на grosbein.net (Eugene Grosbein) Date: Tue, 4 Oct 2022 23:33:14 +0700 Subject: =?UTF-8?B?UmU6INCY0YHQv9GA0LDQstC70LXQvdC40Y8g0YHRgNCw0LHQsNGC0Ys=?= =?UTF-8?B?0LLQsNC90LjQuSDRgdGC0LDRgtC40YfQtdGB0LrQvtCz0L4g0LDQvdCw0LvQuNC3?= =?UTF-8?B?0LDRgtC+0YDQsC4=?= In-Reply-To: References: Message-ID: <3eaaf6f8-0cde-54aa-f2b7-7226d894ae4f@grosbein.net> 04.10.2022 20:11, Evgeniy Berdnikov пишет: > On Tue, Oct 04, 2022 at 12:00:57PM +0000, Korobov Vladimir via nginx-ru wrote: >> После проверки исходного кода статическим анализатором (Svace >> https://www.ispras.ru/technologies/svace/) выделено несколько потенциально >> опасных мест, закрывающихся приложенным патчем. > > Тупое выбрасывание кусков кода при проверке указателя на NULL не только > не решает проблему, но создаёт более опасную ситуацию, когда код приложения > может работать неверно, но ничего об этом не сообщать, так что поймать баг > станет очень трудно. Лучше сегфолт в в точно локализованном месте, чем > глюки непонятно где и непонятно отчего. > > При потенциальной возможности зануления указателя следует ловить и > обрабатывать такое исключение. В противном случае нет смысла в проверке. > Задача же не в ублажении тупых анализаторов, а в правильной работе кода. Как пользователь разнообразного софта, могу доложить, что сегфолт очень фиговая обработка исключений. Проверка указателя на NULL перед разадресацией в том случае, когда нельзя гарантировать что он не NULL, практически всегда благо. Другой вопрос, что потом делать, если вдруг: молча восстановиться и ехать дальше, или не молча, а с сообщением в лог, или выдать даже stack trace и выйти. Но что угодно лучше сырого сегфолта. From bgx на protva.ru Tue Oct 4 17:53:15 2022 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Tue, 4 Oct 2022 20:53:15 +0300 Subject: =?utf-8?B?0JjRgdC/0YDQsNCy0LvQtdC90Lg=?= =?utf-8?B?0Y8g0YHRgNCw0LHQsNGC0YvQstCw0L3QuNC5INGB0YLQsNGC0LjRh9C10YE=?= =?utf-8?B?0LrQvtCz0L4g0LDQvdCw0LvQuNC30LDRgtC+0YDQsC4=?= In-Reply-To: <3eaaf6f8-0cde-54aa-f2b7-7226d894ae4f@grosbein.net> References: <3eaaf6f8-0cde-54aa-f2b7-7226d894ae4f@grosbein.net> Message-ID: On Tue, Oct 04, 2022 at 11:33:14PM +0700, Eugene Grosbein wrote: > 04.10.2022 20:11, Evgeniy Berdnikov пишет: > > При потенциальной возможности зануления указателя следует ловить и > > обрабатывать такое исключение. В противном случае нет смысла в проверке. > > Задача же не в ублажении тупых анализаторов, а в правильной работе кода. > > Как пользователь разнообразного софта, могу доложить, что сегфолт очень фиговая обработка исключений. > Проверка указателя на NULL перед разадресацией в том случае, когда нельзя гарантировать что он не NULL, > практически всегда благо. Ну, я написал что такую ситуацию нужно ловить всегда, т.е. MUST а не SHOULD. > Другой вопрос, что потом делать, если вдруг: молча восстановиться и ехать дальше, > или не молча, а с сообщением в лог, или выдать даже stack trace и выйти. Но что угодно лучше сырого сегфолта. Был бы я пользователем, я бы тоже так считал, наверное... Но поскольку я сисадмин с некоторым запилом в разработку, то думаю иначе: вставить в свою софтину полноценный обработчик сегфолта, с анализатором стека и печатью регистров, чтобы по функционалу всё было не хуже gdb -- это очень непросто. Корпорации размера Оракл могут себе такое позволить, и нанять кучу фултайм-саппортеров на разборку трейсов, а для широкой публики нет ничего эффективней сборки без стрипа -> coredump -> gdb -> "bt full" и анализа содержимого регистров, памяти, etc. Конечно, если софтина mission critical, и останавливаться ей никак нельзя, то нужно думать об обработке сбоев. Но в большинстве случаев это можно решить дизайном: например, при сегфолте в рабочем процессе автоматически запускать новый, отмечать сбой в логе / e-mail, а корку оставлять админу на изучение. -- Eugene Berdnikov From mdounin на mdounin.ru Tue Oct 4 18:11:47 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 4 Oct 2022 21:11:47 +0300 Subject: =?koi8-r?B?6dPQ0sHXzMXOydEg09LBwsHU?= =?koi8-r?B?2dfBzsnKINPUwdTJ3sXTy8/HzyDBzsHMydrB1M/SwS4=?= In-Reply-To: <3eaaf6f8-0cde-54aa-f2b7-7226d894ae4f@grosbein.net> References: <3eaaf6f8-0cde-54aa-f2b7-7226d894ae4f@grosbein.net> Message-ID: Hello! On Tue, Oct 04, 2022 at 11:33:14PM +0700, Eugene Grosbein wrote: > 04.10.2022 20:11, Evgeniy Berdnikov пишет: > > On Tue, Oct 04, 2022 at 12:00:57PM +0000, Korobov Vladimir via nginx-ru wrote: > >> После проверки исходного кода статическим анализатором (Svace > >> https://www.ispras.ru/technologies/svace/) выделено несколько потенциально > >> опасных мест, закрывающихся приложенным патчем. > > > > Тупое выбрасывание кусков кода при проверке указателя на NULL не только > > не решает проблему, но создаёт более опасную ситуацию, когда код приложения > > может работать неверно, но ничего об этом не сообщать, так что поймать баг > > станет очень трудно. Лучше сегфолт в в точно локализованном месте, чем > > глюки непонятно где и непонятно отчего. > > > > При потенциальной возможности зануления указателя следует ловить и > > обрабатывать такое исключение. В противном случае нет смысла в проверке. > > Задача же не в ублажении тупых анализаторов, а в правильной работе кода. > > Как пользователь разнообразного софта, могу доложить, что сегфолт очень фиговая обработка исключений. > Проверка указателя на NULL перед разадресацией в том случае, когда нельзя гарантировать что он не NULL, > практически всегда благо. Другой вопрос, что потом делать, если вдруг: молча восстановиться и ехать дальше, > или не молча, а с сообщением в лог, или выдать даже stack trace и выйти. Но что угодно лучше сырого сегфолта. Так о том и речь, что в данном случае есть, потенциально, два варианта: - Статический анализатор прав, и в рассматриваемых местах возможно появление нулевых указателей. Тогда ситуацию надо обрабатывать, а не тупо игнорировать кусок кода. То есть патч плохой. - Статический анализатор не прав, и в рассматриваемых местах появление нулевых указателей невозможно (ну, кроме случая memory corruption). Тогда добавлять проверки с игнорированием кода опять же неправильно: они ничего не будут делать в штатном режиме, а в случае memory corruption - ещё и увеличивают шанс получить code execution вместо segmentation fault. То есть патч опять же плохой. Ситуаций, когда предлагаемый патч может быть хорошим - не прослеживается. Вообще, по моему опыту - в большинстве случаев статические анализаторы, даже лучшие, приносят мусор. Но иногда случается и что-нибудь полезное, поэтому жалобы какого-нибудь Coverity - регулярно отсматриваются. Но надо понимать, что анализ жалоб какого-либо статического анализатора - это кропотливый труда, а не взять и заткнуть тупыми проверками всё, на что оно вдруг решило пожаловаться по каким-то своим внутренним причинам. -- Maxim Dounin http://mdounin.ru/ From eugen на grosbein.net Tue Oct 4 19:34:33 2022 From: eugen на grosbein.net (Eugene Grosbein) Date: Wed, 5 Oct 2022 02:34:33 +0700 Subject: =?UTF-8?B?UmU6INCY0YHQv9GA0LDQstC70LXQvdC40Y8g0YHRgNCw0LHQsNGC0Ys=?= =?UTF-8?B?0LLQsNC90LjQuSDRgdGC0LDRgtC40YfQtdGB0LrQvtCz0L4g0LDQvdCw0LvQuNC3?= =?UTF-8?B?0LDRgtC+0YDQsC4=?= In-Reply-To: References: <3eaaf6f8-0cde-54aa-f2b7-7226d894ae4f@grosbein.net> Message-ID: <1605bc8c-70a7-cc24-6418-e858a1fb1625@grosbein.net> 05.10.2022 0:53, Evgeniy Berdnikov пишет: >> Другой вопрос, что потом делать, если вдруг: молча восстановиться и ехать дальше, >> или не молча, а с сообщением в лог, или выдать даже stack trace и выйти. Но что угодно лучше сырого сегфолта. > > Был бы я пользователем, я бы тоже так считал, наверное... Но поскольку я > сисадмин с некоторым запилом в разработку, то думаю иначе: вставить в свою > софтину полноценный обработчик сегфолта, с анализатором стека и печатью > регистров, чтобы по функционалу всё было не хуже gdb -- это очень непросто. Не нужно делать "по функционалу не хуже gdb", на это есть gdb. Нужно просто использовать libexecinfo или аналоги и backtrace(3) сотоварищи. From bgx на protva.ru Tue Oct 4 19:54:54 2022 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Tue, 4 Oct 2022 22:54:54 +0300 Subject: =?utf-8?B?0JjRgdC/0YDQsNCy0LvQtdC90Lg=?= =?utf-8?B?0Y8g0YHRgNCw0LHQsNGC0YvQstCw0L3QuNC5INGB0YLQsNGC0LjRh9C10YE=?= =?utf-8?B?0LrQvtCz0L4g0LDQvdCw0LvQuNC30LDRgtC+0YDQsC4=?= In-Reply-To: <1605bc8c-70a7-cc24-6418-e858a1fb1625@grosbein.net> References: <3eaaf6f8-0cde-54aa-f2b7-7226d894ae4f@grosbein.net> <1605bc8c-70a7-cc24-6418-e858a1fb1625@grosbein.net> Message-ID: On Wed, Oct 05, 2022 at 02:34:33AM +0700, Eugene Grosbein wrote: > 05.10.2022 0:53, Evgeniy Berdnikov пишет: > > Был бы я пользователем, я бы тоже так считал, наверное... Но поскольку я > > сисадмин с некоторым запилом в разработку, то думаю иначе: вставить в свою > > софтину полноценный обработчик сегфолта, с анализатором стека и печатью > > регистров, чтобы по функционалу всё было не хуже gdb -- это очень непросто. > > Не нужно делать "по функционалу не хуже gdb", на это есть gdb. > Нужно просто использовать libexecinfo или аналоги и backtrace(3) сотоварищи. Я пытался пользоваться backtrace(3) и сделал для себя вывод, что ценность распечатки стэка без возможности детального анализа памяти довольно низкая. Реально полезна корка или остановленный процесс, ждущий подключения gdb. У кого-то может быть другое мнение, конечно. -- Eugene Berdnikov From eugen на grosbein.net Tue Oct 4 20:10:54 2022 From: eugen на grosbein.net (Eugene Grosbein) Date: Wed, 5 Oct 2022 03:10:54 +0700 Subject: =?UTF-8?B?UmU6INCY0YHQv9GA0LDQstC70LXQvdC40Y8g0YHRgNCw0LHQsNGC0Ys=?= =?UTF-8?B?0LLQsNC90LjQuSDRgdGC0LDRgtC40YfQtdGB0LrQvtCz0L4g0LDQvdCw0LvQuNC3?= =?UTF-8?B?0LDRgtC+0YDQsC4=?= In-Reply-To: References: <3eaaf6f8-0cde-54aa-f2b7-7226d894ae4f@grosbein.net> <1605bc8c-70a7-cc24-6418-e858a1fb1625@grosbein.net> Message-ID: 05.10.2022 2:54, Evgeniy Berdnikov пишет: > On Wed, Oct 05, 2022 at 02:34:33AM +0700, Eugene Grosbein wrote: >> 05.10.2022 0:53, Evgeniy Berdnikov пишет: >>> Был бы я пользователем, я бы тоже так считал, наверное... Но поскольку я >>> сисадмин с некоторым запилом в разработку, то думаю иначе: вставить в свою >>> софтину полноценный обработчик сегфолта, с анализатором стека и печатью >>> регистров, чтобы по функционалу всё было не хуже gdb -- это очень непросто. >> >> Не нужно делать "по функционалу не хуже gdb", на это есть gdb. >> Нужно просто использовать libexecinfo или аналоги и backtrace(3) сотоварищи. > > Я пытался пользоваться backtrace(3) и сделал для себя вывод, что ценность > распечатки стэка без возможности детального анализа памяти довольно низкая. > Реально полезна корка или остановленный процесс, ждущий подключения gdb. backtrace не противоречит отбрасыванию корки. From Vladimir.Korobov на infotecs.ru Wed Oct 5 05:22:10 2022 From: Vladimir.Korobov на infotecs.ru (Korobov Vladimir) Date: Wed, 5 Oct 2022 05:22:10 +0000 Subject: =?utf-8?B?UkU6INCY0YHQv9GA0LDQstC70LXQvdC40Y8g0YHRgNCw0LHQsNGC0YvQstCw?= =?utf-8?B?0L3QuNC5INGB0YLQsNGC0LjRh9C10YHQutC+0LPQviDQsNC90LDQu9C40Lc=?= =?utf-8?B?0LDRgtC+0YDQsC4=?= In-Reply-To: <20221004130455.GI14170@zxy.spb.ru> References: <20221004130455.GI14170@zxy.spb.ru> Message-ID: <5bd84475451c4ba8ba968918f856c787@infotecs.ru> Кажется, что да, что-то делают. Цели успокоить анализатора нет, тем более анализатор генерирует несколько сотен предупреждений, а исправляются патчем только несколько. С уважением, Владимир Коробов -----Original Message----- From: Slawa Olhovchenkov Sent: Tuesday, October 4, 2022 4:05 PM To: Korobov Vladimir via nginx-ru Subject: Re: Исправления срабатываний статического анализатора. On Tue, Oct 04, 2022 at 12:00:57PM +0000, Korobov Vladimir via nginx-ru wrote: > Добрый день > > После проверки исходного кода статическим анализатором (Svace https://www.ispras.ru/technologies/svace/) выделено несколько потенциально опасных мест, закрывающихся приложенным патчем. > > Прошу рассмотреть возможность включения указанных изменений в исходный код проекта. а эти исправления на самом деле что делают? Успокаивают статистический анализатор или исправляют ошибки? _______________________________________________ nginx-ru mailing list -- nginx-ru на nginx.org To unsubscribe send an email to nginx-ru-leave на nginx.org From Vladimir.Korobov на infotecs.ru Wed Oct 5 05:35:38 2022 From: Vladimir.Korobov на infotecs.ru (Korobov Vladimir) Date: Wed, 5 Oct 2022 05:35:38 +0000 Subject: =?utf-8?B?UkU6INCY0YHQv9GA0LDQstC70LXQvdC40Y8g0YHRgNCw0LHQsNGC0YvQstCw?= =?utf-8?B?0L3QuNC5INGB0YLQsNGC0LjRh9C10YHQutC+0LPQviDQsNC90LDQu9C40Lc=?= =?utf-8?B?0LDRgtC+0YDQsC4=?= In-Reply-To: References: Message-ID: <595c5405e1ac4360835eb1959f89aae2@infotecs.ru> Проверять на NULL, конечно, надо. Тем более во всех файлах, в которых я внёс изменения, такие проверки есть. И выглядит так, что в указанных местах такие проверки добавить забыли. На счёт "тупого выбрасывания кусков кода" согласен, добавлю логирование. С уважением, Владимир Коробов From chipitsine на gmail.com Wed Oct 5 08:29:31 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 5 Oct 2022 13:29:31 +0500 Subject: =?UTF-8?B?UmU6INCY0YHQv9GA0LDQstC70LXQvdC40Y8g0YHRgNCw0LHQsNGC0YvQstCw0L3QuNC5IA==?= =?UTF-8?B?0YHRgtCw0YLQuNGH0LXRgdC60L7Qs9C+INCw0L3QsNC70LjQt9Cw0YLQvtGA0LAu?= In-Reply-To: <595c5405e1ac4360835eb1959f89aae2@infotecs.ru> References: <595c5405e1ac4360835eb1959f89aae2@infotecs.ru> Message-ID: вопросов на самом деле два (из опыта работы с статическими анализаторами) 1) анализаторы могут неправильно определять, что в конкретном месте может быть NULL. поэтому хочется действительно убедиться, что он там может быть 2) если туда таки попал NULL, то поведение функции может потребовать более существенной модификации, чем игнор конструкции, использующей эту переменную. ср, 5 окт. 2022 г. в 10:35, Korobov Vladimir via nginx-ru < nginx-ru на nginx.org>: > Проверять на NULL, конечно, надо. Тем более во всех файлах, в которых я > внёс изменения, такие проверки есть. И выглядит так, что в указанных местах > такие проверки добавить забыли. > > На счёт "тупого выбрасывания кусков кода" согласен, добавлю логирование. > > С уважением, > Владимир Коробов > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From slw на zxy.spb.ru Wed Oct 5 09:13:09 2022 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Wed, 5 Oct 2022 12:13:09 +0300 Subject: =?utf-8?B?0JjRgdC/0YDQsNCy0LvQtdC90Lg=?= =?utf-8?B?0Y8g0YHRgNCw0LHQsNGC0YvQstCw0L3QuNC5INGB0YLQsNGC0LjRh9C10YE=?= =?utf-8?B?0LrQvtCz0L4g0LDQvdCw0LvQuNC30LDRgtC+0YDQsC4=?= In-Reply-To: <5bd84475451c4ba8ba968918f856c787@infotecs.ru> References: <20221004130455.GI14170@zxy.spb.ru> <5bd84475451c4ba8ba968918f856c787@infotecs.ru> Message-ID: <20221005091309.GJ14170@zxy.spb.ru> On Wed, Oct 05, 2022 at 05:22:10AM +0000, Korobov Vladimir via nginx-ru wrote: > Кажется, что да, что-то делают. Цели успокоить анализатора нет, тем более анализатор генерирует несколько сотен предупреждений, а исправляются патчем только несколько. погоди-погоди, как так "кажется"? ны написал какой-то код, но сам не понимаешь что он делает? а не делает ли он хуже? > С уважением, > Владимир Коробов > > > -----Original Message----- > From: Slawa Olhovchenkov > Sent: Tuesday, October 4, 2022 4:05 PM > To: Korobov Vladimir via nginx-ru > Subject: Re: Исправления срабатываний статического анализатора. > > On Tue, Oct 04, 2022 at 12:00:57PM +0000, Korobov Vladimir via nginx-ru wrote: > > > Добрый день > > > > После проверки исходного кода статическим анализатором (Svace https://www.ispras.ru/technologies/svace/) выделено несколько потенциально опасных мест, закрывающихся приложенным патчем. > > > > Прошу рассмотреть возможность включения указанных изменений в исходный код проекта. > > а эти исправления на самом деле что делают? > Успокаивают статистический анализатор или исправляют ошибки? > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org To unsubscribe send an email to nginx-ru-leave на nginx.org > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org From Vladimir.Korobov на infotecs.ru Wed Oct 5 09:24:19 2022 From: Vladimir.Korobov на infotecs.ru (Korobov Vladimir) Date: Wed, 5 Oct 2022 09:24:19 +0000 Subject: =?utf-8?B?UkU6INCY0YHQv9GA0LDQstC70LXQvdC40Y8g0YHRgNCw0LHQsNGC0YvQstCw?= =?utf-8?B?0L3QuNC5INGB0YLQsNGC0LjRh9C10YHQutC+0LPQviDQsNC90LDQu9C40Lc=?= =?utf-8?B?0LDRgtC+0YDQsC4=?= In-Reply-To: <20221005091309.GJ14170@zxy.spb.ru> References: <20221004130455.GI14170@zxy.spb.ru> <5bd84475451c4ba8ba968918f856c787@infotecs.ru> <20221005091309.GJ14170@zxy.spb.ru> Message-ID: <3b632aef36da4ec6a5a4bc28e0de083c@infotecs.ru> Окей, неправально выразился. Я понимаю, что делает этот патч и он не делает хуже. С уважением, Владимир Коробов -----Original Message----- From: Slawa Olhovchenkov Sent: Wednesday, October 5, 2022 12:13 PM To: Korobov Vladimir via nginx-ru Subject: Re: Исправления срабатываний статического анализатора. On Wed, Oct 05, 2022 at 05:22:10AM +0000, Korobov Vladimir via nginx-ru wrote: > Кажется, что да, что-то делают. Цели успокоить анализатора нет, тем более анализатор генерирует несколько сотен предупреждений, а исправляются патчем только несколько. погоди-погоди, как так "кажется"? ны написал какой-то код, но сам не понимаешь что он делает? а не делает ли он хуже? > С уважением, > Владимир Коробов > > > -----Original Message----- > From: Slawa Olhovchenkov > Sent: Tuesday, October 4, 2022 4:05 PM > To: Korobov Vladimir via nginx-ru > Subject: Re: Исправления срабатываний статического анализатора. > > On Tue, Oct 04, 2022 at 12:00:57PM +0000, Korobov Vladimir via nginx-ru wrote: > > > Добрый день > > > > После проверки исходного кода статическим анализатором (Svace https://www.ispras.ru/technologies/svace/) выделено несколько потенциально опасных мест, закрывающихся приложенным патчем. > > > > Прошу рассмотреть возможность включения указанных изменений в исходный код проекта. > > а эти исправления на самом деле что делают? > Успокаивают статистический анализатор или исправляют ошибки? > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org To unsubscribe send an > email to nginx-ru-leave на nginx.org > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org To unsubscribe send an > email to nginx-ru-leave на nginx.org _______________________________________________ nginx-ru mailing list -- nginx-ru на nginx.org To unsubscribe send an email to nginx-ru-leave на nginx.org From bgx на protva.ru Wed Oct 5 09:32:40 2022 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 5 Oct 2022 12:32:40 +0300 Subject: =?utf-8?B?0JjRgdC/0YDQsNCy0LvQtdC90Lg=?= =?utf-8?B?0Y8g0YHRgNCw0LHQsNGC0YvQstCw0L3QuNC5INGB0YLQsNGC0LjRh9C10YE=?= =?utf-8?B?0LrQvtCz0L4g0LDQvdCw0LvQuNC30LDRgtC+0YDQsC4=?= In-Reply-To: <3b632aef36da4ec6a5a4bc28e0de083c@infotecs.ru> References: <20221004130455.GI14170@zxy.spb.ru> <5bd84475451c4ba8ba968918f856c787@infotecs.ru> <20221005091309.GJ14170@zxy.spb.ru> <3b632aef36da4ec6a5a4bc28e0de083c@infotecs.ru> Message-ID: On Wed, Oct 05, 2022 at 09:24:19AM +0000, Korobov Vladimir via nginx-ru wrote: > Окей, неправально выразился. > Я понимаю, что делает этот патч и он не делает хуже. Я написал, почему этот патч делает хуже, причём СИЛЬНО хуже чем было. И Максим Дунин высказался. Вы можете что-то возразить предметно? -- Eugene Berdnikov From slw на zxy.spb.ru Wed Oct 5 10:10:22 2022 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Wed, 5 Oct 2022 13:10:22 +0300 Subject: =?utf-8?B?0JjRgdC/0YDQsNCy0LvQtdC90Lg=?= =?utf-8?B?0Y8g0YHRgNCw0LHQsNGC0YvQstCw0L3QuNC5INGB0YLQsNGC0LjRh9C10YE=?= =?utf-8?B?0LrQvtCz0L4g0LDQvdCw0LvQuNC30LDRgtC+0YDQsC4=?= In-Reply-To: <3b632aef36da4ec6a5a4bc28e0de083c@infotecs.ru> References: <20221004130455.GI14170@zxy.spb.ru> <5bd84475451c4ba8ba968918f856c787@infotecs.ru> <20221005091309.GJ14170@zxy.spb.ru> <3b632aef36da4ec6a5a4bc28e0de083c@infotecs.ru> Message-ID: <20221005101022.GK14170@zxy.spb.ru> On Wed, Oct 05, 2022 at 09:24:19AM +0000, Korobov Vladimir via nginx-ru wrote: > Окей, неправально выразился. > Я понимаю, что делает этот патч и он не делает хуже. окей, возьмем скажем второй кусок патча. diff -r ba5cf8f73a2d -r ee42d7efc9a6 src/http/modules/ngx_http_proxy_module.c --- a/src/http/modules/ngx_http_proxy_module.c Thu Sep 08 13:53:49 2022 +0400 +++ b/src/http/modules/ngx_http_proxy_module.c Fri Sep 23 03:52:37 2022 -0700 @@ -1485,9 +1485,11 @@ continue; } - - code = *(ngx_http_script_code_pt *) e.ip; - code((ngx_http_script_engine_t *) &e); + + if (*(uintptr_t *) e.ip) { + code = *(ngx_http_script_code_pt *) e.ip; + code((ngx_http_script_engine_t *) &e); + } *e.pos++ = ':'; *e.pos++ = ' '; взяли и просто выкинули исполнение кода (вопрос о том, может ли в e.ip вообще чисто теоретически быть NULL -- пока опустим) раскрытия макросов. но сдвиг по строке оставили. это точно то, что надо делать и это не сделает хуже? при этом, если посмотреть внимательно, то ниже, после цикла while у нас написанно e.ip += sizeof(uintptr_t); т.е. если предположить, что по какой-то причине у нас структрура headers->values->elts (по которой и бежит e.ip) побилась, и там вдруг возник NULL где не надо, то мы его пропустим и дальше будем уже выполнять мусор. ну или еще NULL пропустим, пока мусор не попадется. после этого его выполним. точно-точно не хуже? > С уважением, > Владимир Коробов > > > -----Original Message----- > From: Slawa Olhovchenkov > Sent: Wednesday, October 5, 2022 12:13 PM > To: Korobov Vladimir via nginx-ru > Subject: Re: Исправления срабатываний статического анализатора. > > On Wed, Oct 05, 2022 at 05:22:10AM +0000, Korobov Vladimir via nginx-ru wrote: > > > Кажется, что да, что-то делают. Цели успокоить анализатора нет, тем более анализатор генерирует несколько сотен предупреждений, а исправляются патчем только несколько. > > погоди-погоди, как так "кажется"? > ны написал какой-то код, но сам не понимаешь что он делает? > а не делает ли он хуже? > > > С уважением, > > Владимир Коробов > > > > > > -----Original Message----- > > From: Slawa Olhovchenkov > > Sent: Tuesday, October 4, 2022 4:05 PM > > To: Korobov Vladimir via nginx-ru > > Subject: Re: Исправления срабатываний статического анализатора. > > > > On Tue, Oct 04, 2022 at 12:00:57PM +0000, Korobov Vladimir via nginx-ru wrote: > > > > > Добрый день > > > > > > После проверки исходного кода статическим анализатором (Svace https://www.ispras.ru/technologies/svace/) выделено несколько потенциально опасных мест, закрывающихся приложенным патчем. > > > > > > Прошу рассмотреть возможность включения указанных изменений в исходный код проекта. > > > > а эти исправления на самом деле что делают? > > Успокаивают статистический анализатор или исправляют ошибки? > > _______________________________________________ > > nginx-ru mailing list -- nginx-ru на nginx.org To unsubscribe send an > > email to nginx-ru-leave на nginx.org > > _______________________________________________ > > nginx-ru mailing list -- nginx-ru на nginx.org To unsubscribe send an > > email to nginx-ru-leave на nginx.org > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org To unsubscribe send an email to nginx-ru-leave на nginx.org > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org From Vladimir.Korobov на infotecs.ru Wed Oct 5 10:18:19 2022 From: Vladimir.Korobov на infotecs.ru (Korobov Vladimir) Date: Wed, 5 Oct 2022 10:18:19 +0000 Subject: =?utf-8?B?UkU6INCY0YHQv9GA0LDQstC70LXQvdC40Y8g0YHRgNCw0LHQsNGC0YvQstCw?= =?utf-8?B?0L3QuNC5INGB0YLQsNGC0LjRh9C10YHQutC+0LPQviDQsNC90LDQu9C40Lc=?= =?utf-8?B?0LDRgtC+0YDQsC4=?= In-Reply-To: References: <20221004130455.GI14170@zxy.spb.ru> <5bd84475451c4ba8ba968918f856c787@infotecs.ru> <20221005091309.GJ14170@zxy.spb.ru> <3b632aef36da4ec6a5a4bc28e0de083c@infotecs.ru> Message-ID: <49914e4247594db5b0f5de1d00d558cf@infotecs.ru> Да, патч нужно дорабатывать. Согласен. С уважением, Владимир Коробов -----Original Message----- From: Evgeniy Berdnikov Sent: Wednesday, October 5, 2022 12:33 PM To: nginx-ru на nginx.org Subject: Re: Исправления срабатываний статического анализатора. On Wed, Oct 05, 2022 at 09:24:19AM +0000, Korobov Vladimir via nginx-ru wrote: > Окей, неправально выразился. > Я понимаю, что делает этот патч и он не делает хуже. Я написал, почему этот патч делает хуже, причём СИЛЬНО хуже чем было. И Максим Дунин высказался. Вы можете что-то возразить предметно? -- Eugene Berdnikov _______________________________________________ nginx-ru mailing list -- nginx-ru на nginx.org To unsubscribe send an email to nginx-ru-leave на nginx.org From Vladimir.Korobov на infotecs.ru Wed Oct 5 10:18:41 2022 From: Vladimir.Korobov на infotecs.ru (Korobov Vladimir) Date: Wed, 5 Oct 2022 10:18:41 +0000 Subject: =?utf-8?B?UkU6INCY0YHQv9GA0LDQstC70LXQvdC40Y8g0YHRgNCw0LHQsNGC0YvQstCw?= =?utf-8?B?0L3QuNC5INGB0YLQsNGC0LjRh9C10YHQutC+0LPQviDQsNC90LDQu9C40Lc=?= =?utf-8?B?0LDRgtC+0YDQsC4=?= In-Reply-To: <20221005101022.GK14170@zxy.spb.ru> References: <20221004130455.GI14170@zxy.spb.ru> <5bd84475451c4ba8ba968918f856c787@infotecs.ru> <20221005091309.GJ14170@zxy.spb.ru> <3b632aef36da4ec6a5a4bc28e0de083c@infotecs.ru> <20221005101022.GK14170@zxy.spb.ru> Message-ID: <55785e3e1aba47569b04bc592f6ba5ef@infotecs.ru> Да, нужно доработать патч. Согласен. С уважением, Владимир Коробов -----Original Message----- From: Slawa Olhovchenkov Sent: Wednesday, October 5, 2022 1:10 PM To: Korobov Vladimir via nginx-ru Subject: Re: Исправления срабатываний статического анализатора. On Wed, Oct 05, 2022 at 09:24:19AM +0000, Korobov Vladimir via nginx-ru wrote: > Окей, неправально выразился. > Я понимаю, что делает этот патч и он не делает хуже. окей, возьмем скажем второй кусок патча. diff -r ba5cf8f73a2d -r ee42d7efc9a6 src/http/modules/ngx_http_proxy_module.c --- a/src/http/modules/ngx_http_proxy_module.c Thu Sep 08 13:53:49 2022 +0400 +++ b/src/http/modules/ngx_http_proxy_module.c Fri Sep 23 03:52:37 2022 -0700 @@ -1485,9 +1485,11 @@ continue; } - - code = *(ngx_http_script_code_pt *) e.ip; - code((ngx_http_script_engine_t *) &e); + + if (*(uintptr_t *) e.ip) { + code = *(ngx_http_script_code_pt *) e.ip; + code((ngx_http_script_engine_t *) &e); + } *e.pos++ = ':'; *e.pos++ = ' '; взяли и просто выкинули исполнение кода (вопрос о том, может ли в e.ip вообще чисто теоретически быть NULL -- пока опустим) раскрытия макросов. но сдвиг по строке оставили. это точно то, что надо делать и это не сделает хуже? при этом, если посмотреть внимательно, то ниже, после цикла while у нас написанно e.ip += sizeof(uintptr_t); т.е. если предположить, что по какой-то причине у нас структрура headers->values->elts (по которой и бежит e.ip) побилась, и там вдруг возник NULL где не надо, то мы его пропустим и дальше будем уже выполнять мусор. ну или еще NULL пропустим, пока мусор не попадется. после этого его выполним. точно-точно не хуже? > С уважением, > Владимир Коробов > > > -----Original Message----- > From: Slawa Olhovchenkov > Sent: Wednesday, October 5, 2022 12:13 PM > To: Korobov Vladimir via nginx-ru > Subject: Re: Исправления срабатываний статического анализатора. > > On Wed, Oct 05, 2022 at 05:22:10AM +0000, Korobov Vladimir via nginx-ru wrote: > > > Кажется, что да, что-то делают. Цели успокоить анализатора нет, тем более анализатор генерирует несколько сотен предупреждений, а исправляются патчем только несколько. > > погоди-погоди, как так "кажется"? > ны написал какой-то код, но сам не понимаешь что он делает? > а не делает ли он хуже? > > > С уважением, > > Владимир Коробов > > > > > > -----Original Message----- > > From: Slawa Olhovchenkov > > Sent: Tuesday, October 4, 2022 4:05 PM > > To: Korobov Vladimir via nginx-ru > > Subject: Re: Исправления срабатываний статического анализатора. > > > > On Tue, Oct 04, 2022 at 12:00:57PM +0000, Korobov Vladimir via nginx-ru wrote: > > > > > Добрый день > > > > > > После проверки исходного кода статическим анализатором (Svace https://www.ispras.ru/technologies/svace/) выделено несколько потенциально опасных мест, закрывающихся приложенным патчем. > > > > > > Прошу рассмотреть возможность включения указанных изменений в исходный код проекта. > > > > а эти исправления на самом деле что делают? > > Успокаивают статистический анализатор или исправляют ошибки? > > _______________________________________________ > > nginx-ru mailing list -- nginx-ru на nginx.org To unsubscribe send an > > email to nginx-ru-leave на nginx.org > > _______________________________________________ > > nginx-ru mailing list -- nginx-ru на nginx.org To unsubscribe send an > > email to nginx-ru-leave на nginx.org > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org To unsubscribe send an > email to nginx-ru-leave на nginx.org > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org To unsubscribe send an > email to nginx-ru-leave на nginx.org _______________________________________________ nginx-ru mailing list -- nginx-ru на nginx.org To unsubscribe send an email to nginx-ru-leave на nginx.org From a.kunich на webguard.pro Thu Oct 13 08:52:42 2022 From: a.kunich на webguard.pro (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCa0YPQvdC40Yc=?=) Date: Thu, 13 Oct 2022 11:52:42 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90Y/RgtC90LAg0LvQvtCz0LjQutCwINGA0LA=?= =?UTF-8?B?0LHQvtGC0YsgaGFzaCBjb25zaXN0ZW50?= In-Reply-To: References: <0a9b94e4-0e6c-805f-09e4-090cc8fffd86@webguard.pro> Message-ID: <219f33fe-7998-0b9e-8c3d-9bc29cff4485@webguard.pro> 03.10.2022 17:06, Maxim Dounin пишет: > Hello! > > On Mon, Oct 03, 2022 at 10:30:17AM +0300, Александр Кунич via nginx-ru > wrote: > >> Здравствуйте. >> >> Подскажите пожалуйста, это у меня не работает консистентное хеширование >> или я не верно понимаю алгоритм его работы. >> >> У меня в системе апстримы в конфигурации ниже являются кеширующими >> прокси. Недавно понадобилось перераспределить часть нагрузки между ними >> и понял, что веса работают не так, как я ожидал. >> >> Опишу по порядку. С пол года конфигурация была такой. Кеш на прокси >> апстримах прогрелся до 95% попаданий. >> >> upstream upstream_meed { >>     server  192.168.1.1:8080 max_fails=3 fail_timeout=30s; >>     server  192.168.1.2:8080 backup max_fails=3 fail_timeout=30s; >>     server  192.168.1.3:8080 max_fails=3 fail_timeout=30s; >>     hash $request_uri consistent; >>     keepalive 128; >> } >> >> Затем понадобилось часть нагрузки перенести на 192.168.1.2. Снял метку >> backup  с 192.168.1.2 , готовился к тому, что попадания в кеш на >> 192.168.1.1 и 192.168.1.3 снизятся, но этого не произошло. Просто >> нагрузка на 192.168.1.2 существенно выросла. Тут первый вопрос - почему? >> Т.е. как ketama должен обрабатывать метку backup? > При consistent-хэшировании, как и при прочей балансировке, > backup-сервера используются только в случае, если от основных > серверов ответа получить не удалось из-за ошибок. Соответственно > в вашем случае в конфигурацию, фактически, был добавлен сервер > 192.168.1.2. > > Для consistent-хэширования добавление нового сервера означает, что > часть нагрузки с существующих серверов будет перенесена на > добавленный. Больше никаких изменений не будет. Соответственно > то, что процент попаданий в кэш на ранее использовавшихся серверах > не поменялся - это вполне нормально, так как исключены ситуации, > когда запрос ранее попадал на 192.168.1.1, а теперь стал попадать > на 192.168.1.3 (или наоборот). > > При этом часть кэша на 192.168.1.1 и 192.168.1.3 стала не нужна > (так как соответствующие запросы уехали на 192.168.1.2), но на > процент попаданий в кэш оставшихся запросов это влиять никак не > должно. > >> Далее потребовалось перераспределить ещё немного нагрузку и вот тут >> выявилось самое интересное. >> >> upstream upstream_meed { >>     server  192.168.1.1:8080 weight=13 max_fails=3 fail_timeout=30s; >>     server  192.168.1.2:8080 weight=7 max_fails=3 fail_timeout=30s; >>     server  192.168.1.3:8080 weight=10 max_fails=3 fail_timeout=30s; >>     hash $request_uri consistent; >>     keepalive 128; >> } >> >> В этой конфигурации ожидалось, что 192.168.1.3 останется на прежнем >> месте круга хеширования кетама и промахов кеша у него не добавится. Но >> оказалось вовсе не так. Промахи добавились везде и существенно. Далее я >> попробовал у всех серверов выставить последовательно одинаковые веса. >> Сначала всем weight=1 - попадания в кеш восстановились, затем всем >> выставил weight=10 - попадания с 95% упали почти до 50%. >> >> До этого я полагал, что в алгоритме хеширования кетама играет роль >> пропорциональность весов и порядковое место сервера в списке. Согласно >> этого понимания, две приведённые ниже конфигурации должны быть >> равнозначны в плане попаданий кеш. >> >> upstream upstream_meed { >>     server  192.168.1.1:8080 weight=1 max_fails=3 fail_timeout=30s; >>     server  192.168.1.2:8080 weight=1 max_fails=3 fail_timeout=30s; >>     server  192.168.1.3:8080 weight=1 max_fails=3 fail_timeout=30s; >>     hash $request_uri consistent; >>     keepalive 128; >> } >> >> upstream upstream_meed { >>     server  192.168.1.1:8080 weight=10 max_fails=3 fail_timeout=30s; >>     server  192.168.1.2:8080 weight=10 max_fails=3 fail_timeout=30s; >>     server  192.168.1.3:8080 weight=10 max_fails=3 fail_timeout=30s; >>     hash $request_uri consistent; >>     keepalive 128; >> } >> >> На практике у меня это не работает. С весом 10 попадания сильно >> уменьшаются. Это я что-то не так понимаю или у меня не работает ketama ? > При consistent-хэшировании вес реализован с помощью добавления > дополнительных точек для данного сервера. То есть, фактически, > увеличение веса сервера с 1 до 2 эквивалентно добавлению ещё > одного сервера. Соответственно изменение весов трёх серверов с 1 > на 10 эквивалентно добавлению 27 новых серверов, и ожидаемо > приводит к сильной ребалансировке существующих запросов между > серверами. > > Ну и да, при consistent-хэшировании, конечно, порядок серверов не > имеет значения, и так как добавляемые на круг хэширования точки > зависят только от имени сервера, но не от его места в списке. Как > раз отсутствие зависимости от порядка - одно из важных отличий от > обычного хэширования. > Здравствуйте, Максим. Большое спасибо Вам за быстрый и развёрнутый ответ. Теперь всё стало ясно. Я действительно не верно представлял себе принцип работы консистентного хеширования. Особенно про независимость от места в списке без Вашего ответа, маловероятно, что сам дошёл бы. А подскажите ещё пожалуйста, строится ли отдельный круг ketama для серверов с меткой backup? Т.е. если в конфигурации будет указано несколько серверов с меткой backup, то запросы, приходящие на эти сервера будут тоже консистентными? Ещё раз спасибо и успехов Вам в работе. С уважением и благодарностью, Александр Кунич. From mdounin на mdounin.ru Thu Oct 13 13:15:16 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 13 Oct 2022 16:15:16 +0300 Subject: =?koi8-r?B?7sUg0M/O0dTOwSDMz8fJy8Eg?= =?koi8-r?B?0sHCz9TZ?= hash consistent In-Reply-To: <219f33fe-7998-0b9e-8c3d-9bc29cff4485@webguard.pro> References: <0a9b94e4-0e6c-805f-09e4-090cc8fffd86@webguard.pro> <219f33fe-7998-0b9e-8c3d-9bc29cff4485@webguard.pro> Message-ID: Hello! On Thu, Oct 13, 2022 at 11:52:42AM +0300, Александр Кунич via nginx-ru wrote: [...] > А подскажите ещё пожалуйста, строится ли отдельный круг ketama для > серверов с меткой backup? Т.е. если в конфигурации будет указано > несколько серверов с меткой backup, то запросы, приходящие на эти > сервера будут тоже консистентными? Формально backup-сервера вообще не поддерживаются при использовании методов балансировки hash, ip_hash и random, см. тут: http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#backup И если сначала задать метод балансировки, а потом уже описывать сервера, то использовать флаг "backup" nginx не разрешит. Если же сервера уже описаны к тому моменту, как задан метод балансировки, и соответственно известно, что backup-сервера не поддерживаются, в текущей реализации nginx такое пропускает. При этом, опять же в текущей реализации, при hash-балансировке nginx пытается делать до 20 попыток перехэширования для выбора сервера, и если за эти 20 попыток он не смог найти работающий сервер - то nginx переключается в режим round-robin-балансировки для выбора хоть какого-то сервера из оставшихся (если хотя бы что-то осталось). И уже в этом режиме срабатывают backup-сервера, если они вдруг были заданы. Соответственно, если вы задали backup-сервера при hash-балансировке, то они будут использоваться только в рамках перехода к round-robin-балансировке при невозможности выбрать сервер с помощью hash-балансировки, и для выбора из backup-серверов будет использоваться round-robin-балансировка. Но по хорошему так делать не надо, это особенность реализации, а не гарантированное поведение. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Wed Oct 19 12:10:29 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 19 Oct 2022 15:10:29 +0300 Subject: nginx-1.23.2 Message-ID: Изменения в nginx 1.23.2 19.10.2022 *) Безопасность: обработка специально созданного mp4-файла модулем ngx_http_mp4_module могла приводить к падению рабочего процесса, отправке клиенту части содержимого памяти рабочего процесса, а также потенциально могла иметь другие последствия (CVE-2022-41741, CVE-2022-41742). *) Добавление: переменные "$proxy_protocol_tlv_...". *) Добавление: ключи шифрования TLS session tickets теперь автоматически меняются при использовании разделяемой памяти в ssl_session_cache. *) Изменение: уровень логгирования ошибок SSL "bad record type" понижен с уровня crit до info. Спасибо Murilo Andrade. *) Изменение: теперь при использовании разделяемой памяти в ssl_session_cache сообщения "could not allocate new session" логгируются на уровне warn вместо alert и не чаще одного раза в секунду. *) Исправление: nginx/Windows не собирался с OpenSSL 3.0.x. *) Исправление: в логгировании ошибок протокола PROXY. Спасибо Сергею Брестеру. *) Изменение: при использовании TLSv1.3 с OpenSSL разделяемая память из ssl_session_cache расходовалась в том числе на сессии, использующие TLS session tickets. *) Изменение: таймаут, заданный с помощью директивы ssl_session_timeout, не работал при использовании TLSv1.3 с OpenSSL или BoringSSL. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Wed Oct 19 12:10:57 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 19 Oct 2022 15:10:57 +0300 Subject: nginx-1.22.1 Message-ID: Изменения в nginx 1.22.1 19.10.2022 *) Безопасность: обработка специально созданного mp4-файла модулем ngx_http_mp4_module могла приводить к падению рабочего процесса, отправке клиенту части содержимого памяти рабочего процесса, а также потенциально могла иметь другие последствия (CVE-2022-41741, CVE-2022-41742). -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Wed Oct 19 12:11:35 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 19 Oct 2022 15:11:35 +0300 Subject: nginx security advisory (CVE-2022-41741, CVE-2022-41742) Message-ID: Hello! В модуле ngx_http_mp4_module были обнаружены две проблемы, которые позволяют с помощью специально созданного mp4-файла вызвать падение рабочего процесса, отправку клиенту части содержимого памяти рабочего процесса, а также потенциально могут иметь другие последствия (CVE-2022-41741, CVE-2022-41742). Проблемам подвержен nginx, если он собран с модулем ngx_http_mp4_module (по умолчанию не собирается) и директива mp4 используется в конфигурационном файле. При этом атака возможна только в случае, если атакующий имеет возможность обеспечить обработку специально созданного mp4-файла с помощью модуля ngx_http_mp4_module. Проблемам подвержен nginx 1.1.3+, 1.0.7+. Проблемы исправлены в 1.23.2, 1.22.1. Патч, исправляющий проблемы, доступен тут: http://nginx.org/download/patch.2022.mp4.txt -- Maxim Dounin http://nginx.org/ From agent00990 на mail.ru Thu Oct 20 06:43:14 2022 From: agent00990 на mail.ru (=?UTF-8?B?0KLQsNGC0YzRj9C90LAg0J7RgNC70L7QstCw?=) Date: Thu, 20 Oct 2022 09:43:14 +0300 Subject: =?UTF-8?B?0JTQuNGA0LXQutGC0L7RgNC40Lgg0YEg0YDQsNC30L3Ri9C80Lgg0LzQtdGC?= =?UTF-8?B?0L7QtNCw0LzQuCDQsiDQvtC00L3QviDQstC40YDRgiDRhdC+0YHRgtC1?= Message-ID: <1666248194.889023105@f509.i.mail.ru>   Приветствую! Помогите пожалуйста разобраться в написании конфига виртуального хоста. Есть текущий конфиг         location / {                 root /mnt/project;                 open_file_cache off;                 client_max_body_size 1000m;                 dav_methods PUT;                 dav_access user:rw group:r all:r;                 create_full_put_path on;         }           error_page 597 = @not_modif;         if (-e /mnt/project/$uri) {             return 597;         }           location @not_modif {                 internal;                 root /mnt/project;                 dav_methods off;                 } Конфиг разрешает запись методом PUT в корневую директорию, в которой имеется много субдиректорий. И проверяет наличие файлов, не разрешая применять к ним методы, отличные от GET(PUT, MOVE, DELETE, etc)   Необходимо решить задачу добавления в корневую директорию папку еще одной, которая будет называться  tmp и разрешить в рамках этой папки  методы PUT, MOVE, DELETE, но при этом сохранив текущий функционал директорий, которые не tmp. Как это можно сделать?   -- Tatiana   ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Oct 20 08:15:23 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 20 Oct 2022 13:15:23 +0500 Subject: =?UTF-8?B?UmU6INCU0LjRgNC10LrRgtC+0YDQuNC4INGBINGA0LDQt9C90YvQvNC4INC80LXRgtC+?= =?UTF-8?B?0LTQsNC80Lgg0LIg0L7QtNC90L4g0LLQuNGA0YIg0YXQvtGB0YLQtQ==?= In-Reply-To: <1666248194.889023105@f509.i.mail.ru> References: <1666248194.889023105@f509.i.mail.ru> Message-ID: более детально могу позже посмотреть. из того, что бросилось при беглом просмотре if (-e /mnt/project/$uri) { return 597; } попробуйте переделать на try_files ? работает точно так же, но более изящное описание чт, 20 окт. 2022 г. в 11:44, Татьяна Орлова via nginx-ru : > > Приветствую! > Помогите пожалуйста разобраться в написании конфига виртуального хоста. > Есть текущий конфиг > location / { > root /mnt/project; > open_file_cache off; > client_max_body_size 1000m; > dav_methods PUT; > dav_access user:rw group:r all:r; > create_full_put_path on; > } > > error_page 597 = @not_modif; > if (-e /mnt/project/$uri) { > return 597; > } > > location @not_modif { > internal; > root /mnt/project; > dav_methods off; > } > Конфиг разрешает запись методом PUT в корневую директорию, в которой > имеется много субдиректорий. > И проверяет наличие файлов, не разрешая применять к ним методы, отличные > от GET(PUT, MOVE, DELETE, etc) > > Необходимо решить задачу добавления в корневую директорию папку еще одной, > которая будет называться tmp и разрешить в рамках этой папки методы PUT, > MOVE, DELETE, но при этом сохранив текущий функционал директорий, которые > не tmp. > Как это можно сделать? > > -- > Tatiana > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From izorkin на gmail.com Sun Oct 23 17:19:58 2022 From: izorkin на gmail.com (izorkin на gmail.com) Date: Sun, 23 Oct 2022 20:19:58 +0300 Subject: =?windows-1251?B?0ODh7vLgIGxvY2F0aW9uIPEg4Ovo4PHu7A==?= Message-ID: <1116728916.20221023201958@gmail.com> Здравствуйте. Сейчас столкнулся с непонятной ошибкой. Тестовый пример: ``` root /var/www; location / { try_files $uri =404; } location /test/ { try_files $uri =404; alias /var/test/; } ``` Проверяю доступность тестового файла через curl: ``` curl --head -k https://example.com/test/example.txt HTTP/2 200 ... ``` Файл доступен. Лог отладки: ``` ... *302 test location: "/" *302 test location: "test/" *302 using configuration "/test/" ... *302 http script var: "/test/example.txt" *302 trying to use file: "example.txt" "/var/test/example.txt" *302 try file uri: "/test/example.txt" ... *302 http filename: "/var/test/example.txt" ... *302 http2 output header: ":status: 200" ... ``` Меняю location `test` на такой вариант: ``` location ~ ^/(test|custom)/ { try_files $uri =404; alias /var/test/; } ``` Теперь файл не доступен. По идее должно работать... Лог отладки: ``` ... *303 test location: "/" *303 test location: ~ "^/(test|custom)/" *303 using configuration "^/(test|custom)/" ... *303 http script copy: "/var/test/" *303 http script var: "/test/example.txt" *303 trying to use file: "/test/example.txt" "/var/test//test/example.txt" *303 trying to use file: "=404" "/var/test/=404" *303 http finalize request: 404, "/test/example.txt?" a:1, c:1 *303 http special response: 404, "/test/example.txt?" ... *303 http2 output header: ":status: 404" ... ``` Так и должно работать? Только вот если убрать параметр `alias /var/test/;`, то `location /test/` и `location ~ ^/(test|custom)/` работают одинаково. -- С уважением, Izorkin mailto:izorkin на gmail.com From mdounin на mdounin.ru Sun Oct 23 20:36:37 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sun, 23 Oct 2022 23:36:37 +0300 Subject: =?koi8-r?B?8sHCz9TBIGxvY2F0aW9uINMg?= =?koi8-r?B?wczJwdPPzQ==?= In-Reply-To: <1116728916.20221023201958@gmail.com> References: <1116728916.20221023201958@gmail.com> Message-ID: Hello! On Sun, Oct 23, 2022 at 08:19:58PM +0300, izorkin на gmail.com wrote: > Здравствуйте. > > Сейчас столкнулся с непонятной ошибкой. > > Тестовый пример: > ``` > root /var/www; > > location / { > try_files $uri =404; > } > > location /test/ { > try_files $uri =404; > alias /var/test/; > } > ``` > > Проверяю доступность тестового файла через curl: > ``` > curl --head -k https://example.com/test/example.txt > HTTP/2 200 > ... > ``` > > Файл доступен. Лог отладки: > ``` > ... > *302 test location: "/" > *302 test location: "test/" > *302 using configuration "/test/" > ... > *302 http script var: "/test/example.txt" > *302 trying to use file: "example.txt" "/var/test/example.txt" > *302 try file uri: "/test/example.txt" > ... > *302 http filename: "/var/test/example.txt" > ... > *302 http2 output header: ":status: 200" > ... > ``` > > Меняю location `test` на такой вариант: > ``` > location ~ ^/(test|custom)/ { > try_files $uri =404; > alias /var/test/; > } > ``` > > Теперь файл не доступен. По идее должно работать... Лог отладки: > ``` > ... > *303 test location: "/" > *303 test location: ~ "^/(test|custom)/" > *303 using configuration "^/(test|custom)/" > ... > *303 http script copy: "/var/test/" > *303 http script var: "/test/example.txt" > *303 trying to use file: "/test/example.txt" "/var/test//test/example.txt" > *303 trying to use file: "=404" "/var/test/=404" > *303 http finalize request: 404, "/test/example.txt?" a:1, c:1 > *303 http special response: 404, "/test/example.txt?" > ... > *303 http2 output header: ":status: 404" > ... > ``` > > Так и должно работать? > Только вот если убрать параметр `alias /var/test/;`, то `location /test/` и `location ~ ^/(test|custom)/` работают одинаково. Директива "alias" заменяет совпавшую часть location'а на заданный путь. Если же location задан регулярным выражением, то "совпавшей части" как таковой нет, и это работает так (цитата по http://nginx.org/r/alias/ru): : Если alias используется внутри location’а, заданного регулярным : выражением, то регулярное выражение должно содержать выделения, а : сам alias — ссылки на эти выделения (0.7.40), например: : : location ~ ^/users/(.+\.(?:gif|jpe?g|png))$ { : alias /data/w3/images/$1; : } То есть всё работает ровно так, как должно/документировано. Безусловно, в конкретном примере оно работает не очень ожидаемо для пользователя. Но, скажем так, это не единственный пример, когда location'ы, заданные регулярными выражениями, работают не очень ожидаемо для пользователя. Лучше использовать location'ы, заданные префиксной строкой, Игорь даже как-то доклад об этом делал. -- Maxim Dounin http://mdounin.ru/ From agent00990 на mail.ru Sun Oct 23 20:49:58 2022 From: agent00990 на mail.ru (=?UTF-8?B?0KLQsNGC0YzRj9C90LAg0J7RgNC70L7QstCw?=) Date: Sun, 23 Oct 2022 23:49:58 +0300 Subject: =?UTF-8?B?UmVbMl06INCg0LDQsdC+0YLQsCBsb2NhdGlvbiDRgSDQsNC70LjQsNGB0L4=?= =?UTF-8?B?0Lw=?= In-Reply-To: References: <1116728916.20221023201958@gmail.com> Message-ID: <1666558198.549926086@f426.i.mail.ru> Добрый вечер! Попробую на практике этот вариант с такой конструкцией. Sunday, 23 October 2022, 11:37PM +03:00 from Maxim Dounin mdounin на mdounin.ru : >Hello! > >On Sun, Oct 23, 2022 at 08:19:58PM +0300, izorkin на gmail.com wrote: > > Здравствуйте. > > Сейчас столкнулся с непонятной ошибкой. > > Тестовый пример: > ``` > root /var/www; > > location / { > try_files $uri =404; > } > > location /test/ { > try_files $uri =404; > alias /var/test/; > } > ``` > > Проверяю доступность тестового файла через curl: > ``` > curl --head -k https://example.com/test/example.txt > HTTP/2 200 > ... > ``` > > Файл доступен. Лог отладки: > ``` > ... > *302 test location: "/" > *302 test location: "test/" > *302 using configuration "/test/" > ... > *302 http script var: "/test/example.txt" > *302 trying to use file: "example.txt" "/var/test/example.txt" > *302 try file uri: "/test/example.txt" > ... > *302 http filename: "/var/test/example.txt" > ... > *302 http2 output header: ":status: 200" > ... > ``` > > Меняю location `test` на такой вариант: > ``` > location ~ ^/(test|custom)/ { > try_files $uri =404; > alias /var/test/; > } > ``` > > Теперь файл не доступен. По идее должно работать... Лог отладки: > ``` > ... > *303 test location: "/" > *303 test location: ~ "^/(test|custom)/" > *303 using configuration "^/(test|custom)/" > ... > *303 http script copy: "/var/test/" > *303 http script var: "/test/example.txt" > *303 trying to use file: "/test/example.txt" "/var/test//test/example.txt" > *303 trying to use file: "=404" "/var/test/=404" > *303 http finalize request: 404, "/test/example.txt?" a:1, c:1 > *303 http special response: 404, "/test/example.txt?" > ... > *303 http2 output header: ":status: 404" > ... > ``` > > Так и должно работать? > Только вот если убрать параметр `alias /var/test/;`, то `location /test/` и `location ~ ^/(test|custom)/` работают одинаково. > >Директива "alias" заменяет совпавшую часть location'а на заданный >путь. Если же location задан регулярным выражением, то "совпавшей >части" как таковой нет, и это работает так (цитата по >http://nginx.org/r/alias/ru ): > >: Если alias используется внутри location’а, заданного регулярным >: выражением, то регулярное выражение должно содержать выделения, а >: сам alias — ссылки на эти выделения (0.7.40), например: >: >: location ~ ^/users/(.+\.(?:gif|jpe?g|png))$ { >: alias /data/w3/images/$1; >: } > >То есть всё работает ровно так, как должно/документировано. > >Безусловно, в конкретном примере оно работает не очень ожидаемо >для пользователя. Но, скажем так, это не единственный пример, >когда location'ы, заданные регулярными выражениями, работают не >очень ожидаемо для пользователя. Лучше использовать location'ы, >заданные префиксной строкой, Игорь даже как-то доклад об этом >делал. > >-- >Maxim Dounin >http://mdounin.ru/ >_______________________________________________ >nginx-ru mailing list -- nginx-ru на nginx.org >To unsubscribe send an email to nginx-ru-leave на nginx.org ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From izorkin на gmail.com Mon Oct 24 06:46:51 2022 From: izorkin на gmail.com (izorkin на gmail.com) Date: Mon, 24 Oct 2022 09:46:51 +0300 Subject: =?utf-8?B?UmU6INCg0LDQsdC+0YLQsCBsb2NhdGlvbiDRgSDQsNC70LjQsNGB0L7QvA==?= In-Reply-To: References: <1116728916.20221023201958@gmail.com> Message-ID: <1973845214.20221024094651@gmail.com> Здравствуйте, Максим. Спасибо за пояснение. Вариант с использованием префиксной строки будет быстрее обрабатываться nginx-ом, по сравнение с использованием регулярных выражений? Не смотря на увеличение итогового объёма конфигурационного файла? ``` root /var/www; location / { try_files $uri =404; } location /test/ { try_files $uri =404; alias /var/test/; } location /custom/ { try_files $uri =404; alias /var/test/; } ``` Вы писали 23 октября 2022 г., 23:36:37: > Hello! > On Sun, Oct 23, 2022 at 08:19:58PM +0300, izorkin на gmail.com wrote: > Директива "alias" заменяет совпавшую часть location'а на заданный > путь. Если же location задан регулярным выражением, то "совпавшей > части" как таковой нет, и это работает так (цитата по > http://nginx.org/r/alias/ru): > : Если alias используется внутри location’а, заданного регулярным > : выражением, то регулярное выражение должно содержать выделения, а > : сам alias — ссылки на эти выделения (0.7.40), например: > : > : location ~ ^/users/(.+\.(?:gif|jpe?g|png))$ { > : alias /data/w3/images/$1; > : } > То есть всё работает ровно так, как должно/документировано. > Безусловно, в конкретном примере оно работает не очень ожидаемо > для пользователя. Но, скажем так, это не единственный пример, > когда location'ы, заданные регулярными выражениями, работают не > очень ожидаемо для пользователя. Лучше использовать location'ы, > заданные префиксной строкой, Игорь даже как-то доклад об этом > делал. -- С уважением, Izorkin mailto:izorkin на gmail.com From mdounin на mdounin.ru Mon Oct 24 15:48:01 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 24 Oct 2022 18:48:01 +0300 Subject: =?koi8-r?B?8sHCz9TBIGxvY2F0aW9uINMg?= =?koi8-r?B?wczJwdPPzQ==?= In-Reply-To: <1973845214.20221024094651@gmail.com> References: <1116728916.20221023201958@gmail.com> <1973845214.20221024094651@gmail.com> Message-ID: Hello! On Mon, Oct 24, 2022 at 09:46:51AM +0300, izorkin на gmail.com wrote: > Вариант с использованием префиксной строки будет быстрее обрабатываться > nginx-ом, по сравнение с использованием регулярных выражений? Не смотря > на увеличение итогового объёма конфигурационного файла? > ``` > root /var/www; > > location / { > try_files $uri =404; > } > > location /test/ { > try_files $uri =404; > alias /var/test/; > } > > location /custom/ { > try_files $uri =404; > alias /var/test/; > } > ``` Основное тут не скорость, а простота поддержки. Скажем, если вы в данный конфиг добавите что-нибудь вроде location /test/images/ { alias /var/test/images/ expires max; } то в случае префиксных строк всё будет работать так, как должно, то есть для файлов в /test/images/ будут возвращаться соответствующие заголовки Expires и Cache-Control. А в случае регулярных выражений просто ничего не произойдёт, и запросы продолжат обрабатываться в location'е, заданном регулярным выражением. И чтобы это понять, придётся внимательно прочитать весь конфиг. Подробнее об этом и других случаях у Игоря в докладе, "Масштабируемая конфигурация nginx": https://youtu.be/jf3wIN-FwW4 https://highload.guide/blog/scalable-configuration-nginx.html Скорость, впрочем, тут тоже будет больше. Кроме разве что совсем вырожденных случаев, когда одним регулярным выражением заменяются тысячи префиксных location'ов, и начинает сильно влиять объём конфигурации в памяти. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Tue Oct 25 03:41:56 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 25 Oct 2022 06:41:56 +0300 Subject: ssl_protocols / ssl_conf_command - nginx bug or nginx documentation bug ? Message-ID: Здравствуйте, All! У некоторых пользователей nginx возникли затруднения: https://github.com/mozilla/ssl-config-generator/issues/124#issuecomment-1288224600 Только не понятно, это ошибка в самом nginx или ошибка в документации к nginx. Максим, можете ответить этому пользователю на github, в чем там дело? У меня английский такой, что пишу с ошибками, кроме того, я не уверен, что сам правильно понимаю, в чем именно состоит проблема этого пользователя. Ложные сообщения про ошибки в nginx, которые остаются без ответа - это наверное не очень хорошо, поэтому прошу Вас помочь. И если там нет проблемы в коде nginx - может быть все-таки есть проблема в документации к nginx, поскольку если прочитав документацию пользователи не могут правильно сконфигурировать nginx - значит это проблема в документации. В таком случае - можно ли поправить документацию, чтобы в этом месте все было более понятно и чтобы не приходилось в будущем каждому пользователю отвечать по отдельности? -- Best regards, Gena From mdounin на mdounin.ru Tue Oct 25 04:28:40 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 25 Oct 2022 07:28:40 +0300 Subject: ssl_protocols / ssl_conf_command - nginx bug or nginx documentation bug ? In-Reply-To: References: Message-ID: Hello! On Tue, Oct 25, 2022 at 06:41:56AM +0300, Gena Makhomed wrote: > У некоторых пользователей nginx возникли затруднения: > > https://github.com/mozilla/ssl-config-generator/issues/124#issuecomment-1288224600 > > Только не понятно, это ошибка в самом nginx или ошибка в документации к > nginx. > > Максим, можете ответить этому пользователю на github, в чем там дело? > У меня английский такой, что пишу с ошибками, кроме того, я не уверен, > что сам правильно понимаю, в чем именно состоит проблема этого пользователя. Полной конфигурации там не приведено, так что остаётся только гадать, но судя по всему это очередной пользователь, который пытается задавать разные ssl_protocols в name-based виртуальных серверах. Так работать не будет, потому что OpenSSL фиксирует протокол раньше, чем становится известно имя. При этом в разных IP-based (или port-based) виртуальных серверах вполне можно использовать различные ssl_protocols. Подробнее об этом есть тут: https://trac.nginx.org/nginx/ticket/676 https://mailman.nginx.org/pipermail/nginx/2014-November/045738.html Этот и другие нюансы применения конфигурации для name-based виртуальных серверов документированы тут: http://nginx.org/en/docs/http/server_names.html#virtual_server_selection Что до TLSv1.3 Ciphersuites, то их OpenSSL, судя по всему, тоже выбирает сразу при установлении соединения, и соответственно задавать их в name-based виртуальных серверах бессмысленно, надо задавать в сервере по умолчанию. Это, впрочем, уже вообще не про nginx, если человек лезет в настройки OpenSSL напрямую, минуя nginx, он сам кузнец своего счастья. Писать всего этого на гитхабе я, конечно, не буду, но приведённой выше ссылки на документацию должно хватить даже без каких-либо пояснений. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Tue Oct 25 04:47:15 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 25 Oct 2022 07:47:15 +0300 Subject: ssl_protocols / ssl_conf_command - nginx bug or nginx documentation bug ? In-Reply-To: References: Message-ID: <7f9a7ae3-cda6-a6ec-5e00-9bc8b8aa3318@csdoc.com> On 25.10.2022 7:28, Maxim Dounin wrote: >> https://github.com/mozilla/ssl-config-generator/issues/124#issuecomment-1288224600 > Полной конфигурации там не приведено, так что остаётся только > гадать, но судя по всему это очередной пользователь, который > пытается задавать разные ssl_protocols в name-based виртуальных > серверах. Так работать не будет, потому что OpenSSL фиксирует > протокол раньше, чем становится известно имя. При этом в разных > IP-based (или port-based) виртуальных серверах вполне можно > использовать различные ssl_protocols. Понятно, спасибо. Может быть имеет смысл научить nginx, чтобы он выдавал варнинг в момент чтения конфигурации, если пользователь будет пытаться задавать разные ssl_protocols в name-based виртуальных серверах? Или вообще, просто если встречается директива "ssl_protocols" и "ssl_conf_command" in non-default server{} blocks, even if SNI is used. Это же достаточно просто запрограммировать ведь. Это снимет большое количество глупых вопросов от пользователей. > Писать всего этого на гитхабе я, конечно, не буду, но приведённой > выше ссылки на документацию должно хватить даже без каких-либо > пояснений. Ясно, спасибо, что ответили в список рассылки. С помощью google translate я перевел часть Вашего ответа и опубликовал его на гитхабе: https://github.com/mozilla/ssl-config-generator/issues/124#issuecomment-1289968597 -- Best regards, Gena From chipitsine на gmail.com Tue Oct 25 05:14:54 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 25 Oct 2022 10:14:54 +0500 Subject: ssl_protocols / ssl_conf_command - nginx bug or nginx documentation bug ? In-Reply-To: <7f9a7ae3-cda6-a6ec-5e00-9bc8b8aa3318@csdoc.com> References: <7f9a7ae3-cda6-a6ec-5e00-9bc8b8aa3318@csdoc.com> Message-ID: вт, 25 окт. 2022 г. в 09:47, Gena Makhomed : > On 25.10.2022 7:28, Maxim Dounin wrote: > > >> > https://github.com/mozilla/ssl-config-generator/issues/124#issuecomment-1288224600 > > > Полной конфигурации там не приведено, так что остаётся только > > гадать, но судя по всему это очередной пользователь, который > > пытается задавать разные ssl_protocols в name-based виртуальных > > серверах. Так работать не будет, потому что OpenSSL фиксирует > > протокол раньше, чем становится известно имя. При этом в разных > > IP-based (или port-based) виртуальных серверах вполне можно > > использовать различные ssl_protocols. > > Понятно, спасибо. > > Может быть имеет смысл научить nginx, чтобы он выдавал варнинг > в момент чтения конфигурации, если пользователь будет пытаться > задавать разные ssl_protocols в name-based виртуальных серверах? > это наверное критикал. т.е. человек делает конфиг, который в силу свойств openssl работать будет не так, как описано пользователем, а наоборот про подобное поведение знаем, сталкивались. больно в теории, я конечно, понимаю, что клиент может пихнуть днс в SNI. и уже в ответ на SNI сервер может предложить те или иные протоколы, вопрос к OpenSSL > > Или вообще, просто если встречается директива "ssl_protocols" > и "ssl_conf_command" in non-default server{} blocks, > even if SNI is used. > > Это же достаточно просто запрограммировать ведь. > Это снимет большое количество глупых вопросов от пользователей. > > > Писать всего этого на гитхабе я, конечно, не буду, но приведённой > > выше ссылки на документацию должно хватить даже без каких-либо > > пояснений. > > Ясно, спасибо, что ответили в список рассылки. С помощью > google translate я перевел часть Вашего ответа > и опубликовал его на гитхабе: > > > https://github.com/mozilla/ssl-config-generator/issues/124#issuecomment-1289968597 > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Tue Oct 25 06:20:57 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 25 Oct 2022 09:20:57 +0300 Subject: ssl_protocols / ssl_conf_command - nginx bug or nginx documentation bug ? In-Reply-To: References: <7f9a7ae3-cda6-a6ec-5e00-9bc8b8aa3318@csdoc.com> Message-ID: <346fca7b-adf5-6fb8-cfe7-3a3e93645ac2@csdoc.com> On 25.10.2022 8:14, Илья Шипицин wrote: >> Может быть имеет смысл научить nginx, чтобы он выдавал варнинг >> в момент чтения конфигурации, если пользователь будет пытаться >> задавать разные ssl_protocols в name-based виртуальных серверах? > это наверное критикал. т.е. человек делает конфиг, который в силу свойств > openssl работать будет не так, как описано пользователем, а наоборот Или так. Главное, чтобы nginx не молчал, когда ему подсовывают кривой конфиг. > в теории, я конечно, понимаю, что клиент может пихнуть днс в SNI. и уже > в ответ на SNI сервер может предложить те или иные протоколы, вопрос к > OpenSSL разве в OpenSSL открыт тикет на эту тему? это никому не надо, похоже на то. -- Best regards, Gena From chipitsine на gmail.com Tue Oct 25 07:09:39 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 25 Oct 2022 12:09:39 +0500 Subject: ssl_protocols / ssl_conf_command - nginx bug or nginx documentation bug ? In-Reply-To: <346fca7b-adf5-6fb8-cfe7-3a3e93645ac2@csdoc.com> References: <7f9a7ae3-cda6-a6ec-5e00-9bc8b8aa3318@csdoc.com> <346fca7b-adf5-6fb8-cfe7-3a3e93645ac2@csdoc.com> Message-ID: вт, 25 окт. 2022 г. в 11:21, Gena Makhomed : > On 25.10.2022 8:14, Илья Шипицин wrote: > > >> Может быть имеет смысл научить nginx, чтобы он выдавал варнинг > >> в момент чтения конфигурации, если пользователь будет пытаться > >> задавать разные ssl_protocols в name-based виртуальных серверах? > > > это наверное критикал. т.е. человек делает конфиг, который в силу свойств > > openssl работать будет не так, как описано пользователем, а наоборот > > Или так. > > Главное, чтобы nginx не молчал, когда ему подсовывают кривой конфиг. > > > > в теории, я конечно, понимаю, что клиент может пихнуть днс в SNI. и уже > > в ответ на SNI сервер может предложить те или иные протоколы, вопрос к > > OpenSSL > > разве в OpenSSL открыт тикет на эту тему? > > это никому не надо, похоже на то. > не смотрел. не искал. по опыту взаимодействия с OpenSSL - да, дело небыстрое и не всегда простое. > > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Oct 25 15:12:36 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 25 Oct 2022 18:12:36 +0300 Subject: ssl_protocols / ssl_conf_command - nginx bug or nginx documentation bug ? In-Reply-To: <7f9a7ae3-cda6-a6ec-5e00-9bc8b8aa3318@csdoc.com> References: <7f9a7ae3-cda6-a6ec-5e00-9bc8b8aa3318@csdoc.com> Message-ID: Hello! On Tue, Oct 25, 2022 at 07:47:15AM +0300, Gena Makhomed wrote: > On 25.10.2022 7:28, Maxim Dounin wrote: > > >> https://github.com/mozilla/ssl-config-generator/issues/124#issuecomment-1288224600 > > > Полной конфигурации там не приведено, так что остаётся только > > гадать, но судя по всему это очередной пользователь, который > > пытается задавать разные ssl_protocols в name-based виртуальных > > серверах. Так работать не будет, потому что OpenSSL фиксирует > > протокол раньше, чем становится известно имя. При этом в разных > > IP-based (или port-based) виртуальных серверах вполне можно > > использовать различные ssl_protocols. > > Понятно, спасибо. > > Может быть имеет смысл научить nginx, чтобы он выдавал варнинг > в момент чтения конфигурации, если пользователь будет пытаться > задавать разные ssl_protocols в name-based виртуальных серверах? В общем случае неизвестно, является ли виртуальный сервер name-based или IP/port-based. Не говоря уже о случаях, когда сервер и такой, и такой одновременно. И не говоря уже о том, что всё это вообще говоря особенность реализации OpenSSL, а как оно работает в той SSL-библиотеке, что у пользователя - мы не знаем. > Или вообще, просто если встречается директива "ssl_protocols" > и "ssl_conf_command" in non-default server{} blocks, > even if SNI is used. А ssl_conf_command вообще тут ни коим боком: мы не знаем, что именно с помощью неё пытаются сделать, и не знаем, как оно будет (или не будет) работать в каких случаях. В документации явно сделано предупреждение о возможных непредсказуемых последствиях, остальное - зона ответственности того, кто писал конфигурацию. -- Maxim Dounin http://mdounin.ru/