From mif на me.com Sun Sep 1 15:50:32 2024 From: mif на me.com (Alexey Galygin) Date: Sun, 1 Sep 2024 18:50:32 +0300 Subject: =?utf-8?B?0LrQvtC90YHRgtCw0L3RgtGLINC90LAgaHR0cC3Rg9GA0L7QstC9?= =?utf-8?B?0LUg0LrQvtC90YTQuNCz0LA=?= In-Reply-To: <1723648197.543555186@f750.i.mail.ru> References: <1723648197.543555186@f750.i.mail.ru> Message-ID: <61FEDB73-5C34-4095-A716-40A957D9EF3E@me.com> добрых суток I. ситуация переменные завести на уровне конфига в секции http нельзя с другой стороны, определение upstream возможно только в http предлагаемые текущие костыли через envsubst не очень удобны (ничего в этом красивого нет, перерыл весь S/O): условно, у нас от хоста к хосту на docker разные сетки, меняются IP адреса и надо их динамически (а лучше без скриптов) менять, чтобы подготовить описания upstream’s II. вопрос про возможное решение почему бы не добавить не переменные, а константы — разрешить их на уровне http? также, для docker/k8s было бы идеально, чтобы можно было им давать значение сразу из окружения ( .env )… но, можно стартовать и с чистыми значениями, обычно мы конфигурацию монтируем папкой — есть ли планы по такому развитию конфига или envsubst наше всё и точка? ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From arut на nginx.com Fri Sep 6 15:12:44 2024 From: arut на nginx.com (Roman Arutyunyan) Date: Fri, 6 Sep 2024 19:12:44 +0400 Subject: =?utf-8?B?TkdJTlgg0L/QtdGA0LXQtdGF0LDQuyDQvdCwIEdpdEh1YiE=?= Message-ID: <5C10C1AF-C556-4DEB-AB92-1CC53278CFEF@nginx.com> Привет от команды NGINX! Мы рады сообщить, что официальный репозиторий разработки NGINX Open Source был перенесен с Mercurial на GitHub [1][2][3], где с сегодняшнего дня мы начинаем принимать патчи в форме Pull Request. Отчеты об ошибках, запросы на новую функциональность и улучшения теперь принимаются в разделе «Issues» на GitHub. Форумы сообщества интегрированы в раздел GitHub “Discussions”, где вы можете участвовать в дискуссиях, задавать вопросы и отвечать на них. Важно: чтобы сообщить о проблемах, связанной с безопасностью, просим вас следовать нашей политике безопасности [4]. Мы понимаем, что эти изменения могут потребовать времени на адаптацию. В связи с этим до 31 декабря 2024 года мы продолжим принимать патчи и оказывать поддержку сообществу через списки рассылок. Мы уверены, что данные изменения будут способствовать централизации и упрощению доступа к разработке и взаимодействию с сообществом NGINX. Они отражают наше неизменное стремление к открытому исходному коду, о чем упоминается в блог-посте [5]. Ждем ваших патчей, обсуждений и отзывов на новой платформе. [1] https://github.com/nginx/nginx [2] https://github.com/nginx/nginx-tests [3] https://github.com/nginx/nginx.org [4] https://github.com/nginx/nginx/blob/master/SECURITY.md [5] https://www.f5.com/company/blog/nginx/meetup-recap-nginxs-commitments-to-the-open-source-community От лица команды NGINX, Роман Арутюнян arut на nginx.com From d.isaev на f5.com Fri Sep 6 15:41:37 2024 From: d.isaev на f5.com (Dan Isaev) Date: Fri, 6 Sep 2024 15:41:37 +0000 Subject: =?windows-1251?B?UkU6IE5HSU5YIO/l8OXl9eDrIO3gIEdpdEh1YiE=?= In-Reply-To: <5C10C1AF-C556-4DEB-AB92-1CC53278CFEF@nginx.com> References: <5C10C1AF-C556-4DEB-AB92-1CC53278CFEF@nginx.com> Message-ID: [heart] Dan Isaev reacted to your message: ________________________________ From: nginx-ru on behalf of Roman Arutyunyan Sent: Friday, September 6, 2024 3:12:44 PM To: nginx-ru на nginx.org Subject: NGINX переехал на GitHub! CAUTION: This email has been sent from an external source. Do not click links, open attachments, or provide sensitive business information unless you can verify the sender’s legitimacy. Привет от команды NGINX! Мы рады сообщить, что официальный репозиторий разработки NGINX Open Source был перенесен с Mercurial на GitHub [1][2][3], где с сегодняшнего дня мы начинаем принимать патчи в форме Pull Request. Отчеты об ошибках, запросы на новую функциональность и улучшения теперь принимаются в разделе «Issues» на GitHub. Форумы сообщества интегрированы в раздел GitHub “Discussions”, где вы можете участвовать в дискуссиях, задавать вопросы и отвечать на них. Важно: чтобы сообщить о проблемах, связанной с безопасностью, просим вас следовать нашей политике безопасности [4]. Мы понимаем, что эти изменения могут потребовать времени на адаптацию. В связи с этим до 31 декабря 2024 года мы продолжим принимать патчи и оказывать поддержку сообществу через списки рассылок. Мы уверены, что данные изменения будут способствовать централизации и упрощению доступа к разработке и взаимодействию с сообществом NGINX. Они отражают наше неизменное стремление к открытому исходному коду, о чем упоминается в блог-посте [5]. Ждем ваших патчей, обсуждений и отзывов на новой платформе. [1] https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnginx%2Fnginx&data=05%7C02%7Cd.isaev%40f5.com%7C10bae834187548c297e708dcce8665c3%7Cdd3dfd2f6a3b40d19be0bf8327d81c50%7C0%7C0%7C638612323835526643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=o%2BtKOpxmhLO%2BBabklrXGaN4W5WRqUZec7bBWNOAEL4M%3D&reserved=0 [2] https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnginx%2Fnginx-tests&data=05%7C02%7Cd.isaev%40f5.com%7C10bae834187548c297e708dcce8665c3%7Cdd3dfd2f6a3b40d19be0bf8327d81c50%7C0%7C0%7C638612323835538361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=S0K8CszUMLcb7dJzHI6VWhnNNGn%2BAkHnhsiDiZSHqFM%3D&reserved=0 [3] https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnginx%2Fnginx.org&data=05%7C02%7Cd.isaev%40f5.com%7C10bae834187548c297e708dcce8665c3%7Cdd3dfd2f6a3b40d19be0bf8327d81c50%7C0%7C0%7C638612323835553284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=c34LQw5wdvPyHACsR0P9HOSZXvk4vmJTbdPa5JmZLdI%3D&reserved=0 [4] https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnginx%2Fnginx%2Fblob%2Fmaster%2FSECURITY.md&data=05%7C02%7Cd.isaev%40f5.com%7C10bae834187548c297e708dcce8665c3%7Cdd3dfd2f6a3b40d19be0bf8327d81c50%7C0%7C0%7C638612323835560787%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=WjiT7RBU1AyenfVz0xvYFqY1sp54XrX7giCwJ4ibkDc%3D&reserved=0 [5] https://www.f5.com/company/blog/nginx/meetup-recap-nginxs-commitments-to-the-open-source-community От лица команды NGINX, Роман Арутюнян arut на nginx.com _______________________________________________ nginx-ru mailing list nginx-ru на nginx.org https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.nginx.org%2Fmailman%2Flistinfo%2Fnginx-ru&data=05%7C02%7Cd.isaev%40f5.com%7C10bae834187548c297e708dcce8665c3%7Cdd3dfd2f6a3b40d19be0bf8327d81c50%7C0%7C0%7C638612323835566650%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=6KEd%2FOXpTVXw0q2ebakk7G0ANVarkvac4fD8KbIGxBc%3D&reserved=0 ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From o.deeva на wbsrv.ru Wed Sep 11 13:08:57 2024 From: o.deeva на wbsrv.ru (=?utf-8?B?0J7QutGB0LDQvdCwINCU0LXQtdCy0LA=?=) Date: Wed, 11 Sep 2024 16:08:57 +0300 Subject: =?utf-8?B?0KLQtdGB0YLRizog0L/RgNC+0LLQtdGA0LrQsCBleHBlY3RlZF90ZXN0cyDQsiDQtNC10YHRgtGA0YM=?= =?utf-8?B?0LrRgtC+0YDQtQ==?= Message-ID: <158431726059269@mail.yandex.ru> Вложение в формате HTML было извлечено… URL: From thresh на nginx.com Thu Sep 12 17:14:06 2024 From: thresh на nginx.com (Konstantin Pavlov) Date: Thu, 12 Sep 2024 10:14:06 -0700 Subject: =?UTF-8?B?UmU6INCi0LXRgdGC0Ys6INC/0YDQvtCy0LXRgNC60LAgZXhwZWN0ZWRf?= =?UTF-8?B?dGVzdHMg0LIg0LTQtdGB0YLRgNGD0LrRgtC+0YDQtQ==?= In-Reply-To: <158431726059269@mail.yandex.ru> References: <158431726059269@mail.yandex.ru> Message-ID: <23295fba-25f5-4164-be63-65ca4ab4ef01@nginx.com> Добрый день, On 11/09/2024 6:08 AM, Оксана Деева wrote: > > P.s. я хотела задать вопрос через github, но для репозитория > nginx-tests такой возможности нет. > Не по делу, но: теперь issues там включены, спасибо за замечание. From slw на zxy.spb.ru Sat Sep 14 20:09:52 2024 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Sat, 14 Sep 2024 23:09:52 +0300 Subject: limit_except =?utf-8?B?0Lg=?= proxy_pass Message-ID: <20240914200952.GB60179@zxy.spb.ru> А как лучше всео скрещивать limit_except и proxy_pass? Ну вот то есть надо запетить, например, POST на /. И как, если у нас дальше надо куда-то через proxy_pass прокинуть? nginx: [emerg] "proxy_pass" cannot have URI part in location given by regular expression, or inside named location, or inside "if" statement, or inside "limit_except" block try_files /dev/null @proxy; -- получается нельзя внутри limit_except -- тоже нельзя From gmm на csdoc.com Sat Sep 14 21:50:27 2024 From: gmm на csdoc.com (Hennadii Makhomed) Date: Sat, 14 Sep 2024 23:50:27 +0200 Subject: =?UTF-8?Q?Re=3A_limit=5Fexcept_=D0=B8_proxy=5Fpass?= In-Reply-To: <20240914200952.GB60179@zxy.spb.ru> References: <20240914200952.GB60179@zxy.spb.ru> Message-ID: On 14.09.2024 22:09, Slawa Olhovchenkov wrote: > А как лучше всео скрещивать limit_except и proxy_pass? > Ну вот то есть надо запетить, например, POST на /. > И как, если у нас дальше надо куда-то через proxy_pass прокинуть? location = / { limit_except GET { deny all; } proxy_pass http://backend; } В документации https://nginx.org/r/limit_except/ru явно указано, директивы только из каких именно трех модулей nginx разрешено использовать внутри блока директивы limit_except. -- Best regards, Gena From slw на zxy.spb.ru Sun Sep 15 10:25:13 2024 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Sun, 15 Sep 2024 13:25:13 +0300 Subject: limit_except =?utf-8?B?0Lg=?= proxy_pass In-Reply-To: References: <20240914200952.GB60179@zxy.spb.ru> Message-ID: <20240915102513.GC60179@zxy.spb.ru> On Sat, Sep 14, 2024 at 11:50:27PM +0200, Hennadii Makhomed wrote: > On 14.09.2024 22:09, Slawa Olhovchenkov wrote: > > > А как лучше всео скрещивать limit_except и proxy_pass? > > Ну вот то есть надо запетить, например, POST на /. > > И как, если у нас дальше надо куда-то через proxy_pass прокинуть? > > location = / { > limit_except GET { deny all; } > proxy_pass http://backend; > } > > > В документации https://nginx.org/r/limit_except/ru явно указано, > директивы только из каких именно трех модулей nginx разрешено > использовать внутри блока директивы limit_except. для GET / вообще-то гораздо больше директив и их не хочется дублировать тут, как и в блоке location / From gmm на csdoc.com Sun Sep 15 14:12:40 2024 From: gmm на csdoc.com (Hennadii Makhomed) Date: Sun, 15 Sep 2024 16:12:40 +0200 Subject: =?UTF-8?Q?Re=3A_limit=5Fexcept_=D0=B8_proxy=5Fpass?= In-Reply-To: <20240915102513.GC60179@zxy.spb.ru> References: <20240914200952.GB60179@zxy.spb.ru> <20240915102513.GC60179@zxy.spb.ru> Message-ID: <35180196-0146-4cef-a048-0bb07032b48e@csdoc.com> On 15.09.2024 12:25, Slawa Olhovchenkov wrote: >>> А как лучше всео скрещивать limit_except и proxy_pass? >>> Ну вот то есть надо запетить, например, POST на /. >>> И как, если у нас дальше надо куда-то через proxy_pass прокинуть? >> >> location = / { >> limit_except GET { deny all; } >> proxy_pass http://backend; >> } >> >> >> В документации https://nginx.org/r/limit_except/ru явно указано, >> директивы только из каких именно трех модулей nginx разрешено >> использовать внутри блока директивы limit_except. > > для GET / вообще-то гораздо больше директив и их не хочется > дублировать тут, как и в блоке location / тогда или использовать директиву include и общие части конфига выносить в отдельные файлы, или написать свой генератор конфига, который будет на основании своего "высокоуровневого" описания конфига в виде своего DSL (domain-specific language) генерировать конфиг nginx в котором дублирование кода не будет проблемой, потому что этот конфиг уже никто не будет потом править вручную. хороший вариант для создания своих генераторов конфига - это язык программирования Python плюс библиотека Jinja2 - для удобных шаблонов плюс библиотека Invoke - для того, чтобы выполнить команду run('systemctl reload nginx') после обновления конфга nginx. Обновлять конфиг необходимо/очень желательно с помощью атомарной операции обновления файла, когда в файловой системе будет по имени файла доступно или старое содержимое файла или новое содержимое файла, но никогда не будет доступно промежуточное состояние из частично сохраненного содержимого файла. это касается вообще всего - и модификации конфигов nginx, и модификации sitemap.xml и вообще любых файлов, если не хочется создавать себе приключений и чтобы все работало максимально надежно. например: def atomic_write_text(content, filename): assert isinstance(content, str) assert isinstance(filename, Path) tmp_filename = filename.with_name(filename.name + '.tmp.' + secrets.token_hex() + '.tmp') tmp_filename.write_text(content) tmp_filename.rename(filename) как я это делал в скрипте https://github.com/makhomed/nginx-cloudflare или если совсем не интересно автоматизировать и программировать - тогда можно сделать такой запрет с использованием директивы map: map $request_method$uri $post_to_root { default 0; "POST/" 1; } location / { if ( $post_to_root ) { return 403; } proxy_pass http://backend; } здесь неудобство в том, что директиву map необходимо выносить за пределы блока server { ... } в контекст http, поэтому - необходимо будет следить самостоятельно за тем, чтобы в разных директивах map были разные имена паеременных, потому что nginx самостоятельно эту ошибку не отслеживает и такой конфиг считает полностью валидным: map $request_method$uri $post_to_root { default 0; "POST/" 1; } map $request_method$request_uri $post_to_root { default 0; "POST/" 1; } # nginx -v ; nginx -t nginx version: nginx/1.27.1 nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful поэтому - могут быть очень интересные глюки, если внутри каталога /etc/nginx/conf.d будут файлы *.conf в которых за пределами блоков server { ... } будут находиться директивы map с одинаковыми именами переменных - для читателя конфига это может выглядеть так, словно бы каждая директива map локальна для своего конфигурационного файла, но в действительности - все директивы map задаются только в глобальном контексте http { ... } и если имена переменных одинаковы - они будут просто перезатирать друг друга, вызывая неочевидные глюки в работе. идеальным решением этой проблемы с директивой map (с моей точки зрения) было бы разрешить задавать директиву map не только в контекстах http и stream, но и в контексте server. тогда - каждый блок server { ... } был бы полностью независимым от других блоков server { ... } и не надо было бы читать весь конфиг nginx, пытаясь понять, почему что-то не работает. Именно такая проблема была у httpd Apache, и именно эту проблему когда-то и хотел избежать Игорь Сысоев, создавая nginx, чтобы конфигурация nginx была бы легко масштабируемой: Масштабируемая конфигурация nginx / Игорь Сысоев https://www.youtube.com/watch?v=jf3wIN-FwW4 003. Масштабируемая конфигурация nginx - Игорь Сысоев https://www.youtube.com/watch?v=fcG-7k20oG8 не идеальным решением проблемы было бы выдача ошибок в процессе тестирования конфигурации, если разные блоки map имеют в качестве второго параметра одну и ту же переменную. но пока эта проблема с директивой map никак не решена - то надо быть очень аккуратным при ее использовании, и надо самостоятельно следить за тем, чтобы имя переменной из второго параметра директивы map было бы уникальным в пределах всего конфига nginx. или - просто стараться не использовать директиву map без крайней на то необходимости, как и директиву if, потому что, map - это по своей сути, почти то же самое, что и директива if - только без известных глюков в стиле "if is evil" - https://habr.com/ru/articles/74135/ https://mailman.nginx.org/pipermail/nginx-ru/2013-September/051898.html нельзя сказать, что "map is evil", потому что директива map работает именно так, как написано в документации на сайте, и такм нет никаких "сорпризов" в этом плане. просто map - это просто уже неудобно, когда на сервере есть больше одного блока server { ... } и тогда, например, надо придумывать различные "костыли", чтоыб не было проблем, например, включать "имя" сервера в переменную второго аргумента: map $request_method$uri $example_com_post_to_root { default 0; "POST/" 1; } map $request_method$request_uri $example_net_post_to_root { default 0; "POST/" 1; } директива map хороша еще и тем, что можно вообще любую условную логику с ее помощью закодировать - and, or, not и любые их комбинации, в том числе и включая скобки любой вложенности. Но то, что это можно сделать не означает, что это надо делать, потому что разбирать такие цепочки из map потом неудобно и это может отрицательно сказываться на производительности. Но такая возможность есть, и на самом деле, директива map - очень мощная. например: geo $remote_addr_block { default 1; 10.0.0.0/8 0; 172.16.0.0/12 0; 2001:DB8:11:22::/64 0; 2001:DB8:99:77::/64 0; } map $http_cf_ipcountry $country_block { default 1; RU 0; BY 0; } map $remote_addr_block$country_block $block { 11 1; 10 0; 01 0; 00 0; } и потом уже, где нужна блокировка: if ( $block ) { return 403; } -- Best regards, Gena From gmm на csdoc.com Sun Sep 15 14:32:56 2024 From: gmm на csdoc.com (Hennadii Makhomed) Date: Sun, 15 Sep 2024 16:32:56 +0200 Subject: /usr/sbin/nginx alternatives Message-ID: Здравствуйте, All! nginx развивается в разных направлениях, freenginx Angie OpenResty Tengine nginx-plus nginx https://freenginx.org/ развивается достаточно динамично, много исправлений ошибок, часто выходят новые mainline версии. Но на странице https://freenginx.org/en/download.html не понятная ситуация - есть .tar.gz архивы с исходными текстами, есть .zip архивы с бинарными версиями nginx для операционных систем семейства Windows, но нет rpm-пакетов и yum-репозиториев для Rocky Linux 9 / RHEL 9. То есть, ситуация выглядит так, что поддержка операционных систем семейства Windows даже на более высоком уровне, чем поддержка операционных сисем семейства Enterprise Linux, у которых 10 лет срок жизни дистрибутива и наивысший уровень надежности и стабильности среди вообще всех дистрибутивов Linux. Особенно - после того, как Solar Designer присоединился к проекту Rocky Linux - https://x.com/solardiz/status/1709574519688487374 А вот с freenginx ситуация не понятная совершенно - его же сейчас можно нормально использовать только в FreeBSD, потому что там есть соответствующий порт. А для для Rocky Linux 9 / RHEL 9 - бинарников на сайте https://freenginx.org/ нет, так что использовать его легко и просто не получится - надо каждому пользователю freenginx самому делать rpm пакеты, самому делать yum-репозитории, и потом - это все еще и надо поддерживать в актулаьном состоянии, оперативно выпуская новые версии с каждым выходом freenginx. То есть, пока что он не для production? Или только для early adopters, у которых есть время и возможность и желание, чтобы самим у себя поддерживать эту инфранструктуру для сборки новых версий freenginx? Просто не понимаю, как использовать freenginx в production. Кто-либо это делает на Rocky Linux 9 / RHEL 9 ? Каким образом? Или все пользователи freenginx - это только пользователи FreeBSD? Там то все просто, потому что есть соответствующий порт в системе. Так не хочется самому этим всем заморачиваться, потому что я ведь внутрь одного rpm-пакета могу захотеть поместить все четыре бинарника, биранринки nginx и nginx-debug, собранные из https://freenginx.org/download/freenginx-1.27.4.tar.gz и бинарники nginx и nginx-debug, собарнные из https://nginx.org/download/nginx-1.27.1.tar.gz To Konstantin Pavlov: возможно ли будет внутрь https://nginx.org/en/linux_packages.html хотя бы для Rocky Linux 9 / RHEL 9 включить не два бинарника, как сейчас - nginx и nginx-debug, собранных на основании исходников с сайта https://nginx.org/ но и еще два бинарника nginx и nginx-debug собранных на основании исходников с сайта https://freenginx.org/ ? тогда можно будет иметь всего один юнит-файл nginx.service а переключение между различными реализациями бинарника nginx можно будет делать через alternatives, как это уже сделано для других программ в операционной системе Rocky Linux 9 / RHEL 9 # alternatives --list # alternatives --display ld # man alternatives это было бы очень удобно и для /usr/sbin/nginx, потому что сейчас, когда не используется alternatives - то приходится сооружать костыли из двух unit-файлов /usr/lib/systemd/system/nginx-debug.service /usr/lib/systemd/system/nginx.service которые отличаются между собой только именем бинарника: -ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf +ExecStart=/usr/sbin/nginx-debug -c /etc/nginx/nginx.conf а во всем остальном - полностью идентичны между собой. когда делать переключение между различными вариантами nginx средствами операционной системы - то это будет гораздо удобнее. потому что все юнит-файлы и все скрипты не будут требовать изменений. пока что - четыре варианта бинарников, но в будущем можно добавить и другие форки и другие варианты бинарного файла /usr/sbin/nginx To Konstantin Pavlov: можно так сделать? хотя бы только для Rocky Linux 9 / RHEL 9 но вообще, сам механизм alternatives есть во многих дистрибутивах. В Rocky Linux 9 / RHEL 9 бинарник alternatives - это разработка Red Hat. В Debian / Ubuntu аналогичная бинарная программа - update-alternatives. Это было бы удобно, чтобы для отладки временно можно было бы переключить /usr/sbin/nginx с версии без debug на версию бинарника с debug, или, чтобы можно было бы для эксперимента переключить /usr/sbin/nginx с варианта nginx.org на вариант freenginx.org - для тестирования. И если окажется, что в варианте бинарника от freenginx.org ошибки нет, а в варианте бинарника от nginx.org ошибка есть, то тогда можно будет значительно легче и проще устранить проблему и в основной версии nginx и в закрытом форке nginx-plus. можно так сделать? если по каким-то причинам нельзя включать бинарники собранные с исходников из сайта freenginx.org - то хотя бы можно сделать переключение между версиями /usr/sbin/nginx с отладкой и без отладки через механизм alternatives, а не через отдельные unit-файлы systemd. а по два комплекта бинарников - с сайта freenginx.org и nginx.org можно уже делать внутри rpm-пакетов с сайта freenginx.org - основной будет версия с сайта freenginx.org, альтернативной --версия с сайта nginx.org, чтобы можно было бы быстро находить ошибки, которые присутствуют в исходниках с сайта freenginx.org но которых нет в исходниках с сайта nginx.org это было бы очень удобно и таким образом - у пользователей была бы возможность быстро переключаться между различными вариантами nginx / freenginx в случае каких-то проблем. -- Best regards, Gena From chipitsine на gmail.com Sun Sep 15 18:04:15 2024 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 15 Sep 2024 20:04:15 +0200 Subject: /usr/sbin/nginx alternatives In-Reply-To: References: Message-ID: а к чему вы предлагаете привязать график релизов ? если выйдет новая версия angie или freenginx, пересобирать пакет с nginx ? а какая версия будет у пакета ? вс, 15 сент. 2024 г. в 16:33, Hennadii Makhomed : > Здравствуйте, All! > > nginx развивается в разных направлениях, > > freenginx > Angie > OpenResty > Tengine > nginx-plus > nginx > > https://freenginx.org/ развивается достаточно динамично, > много исправлений ошибок, часто выходят новые mainline версии. > > Но на странице https://freenginx.org/en/download.html не понятная > ситуация - есть .tar.gz архивы с исходными текстами, есть .zip архивы > с бинарными версиями nginx для операционных систем семейства Windows, > но нет rpm-пакетов и yum-репозиториев для Rocky Linux 9 / RHEL 9. > > То есть, ситуация выглядит так, что поддержка операционных систем > семейства Windows даже на более высоком уровне, чем поддержка > операционных сисем семейства Enterprise Linux, у которых 10 лет > срок жизни дистрибутива и наивысший уровень надежности > и стабильности среди вообще всех дистрибутивов Linux. > > Особенно - после того, как Solar Designer присоединился к проекту > Rocky Linux - https://x.com/solardiz/status/1709574519688487374 > > А вот с freenginx ситуация не понятная совершенно - его же сейчас > можно нормально использовать только в FreeBSD, потому что там есть > соответствующий порт. А для для Rocky Linux 9 / RHEL 9 - бинарников > на сайте https://freenginx.org/ нет, так что использовать его легко > и просто не получится - надо каждому пользователю freenginx самому > делать rpm пакеты, самому делать yum-репозитории, и потом - это все > еще и надо поддерживать в актулаьном состоянии, оперативно выпуская > новые версии с каждым выходом freenginx. То есть, пока что он не для > production? Или только для early adopters, у которых есть время > и возможность и желание, чтобы самим у себя поддерживать эту > инфранструктуру для сборки новых версий freenginx? > > Просто не понимаю, как использовать freenginx в production. > Кто-либо это делает на Rocky Linux 9 / RHEL 9 ? Каким образом? > > Или все пользователи freenginx - это только пользователи FreeBSD? > Там то все просто, потому что есть соответствующий порт в системе. > > Так не хочется самому этим всем заморачиваться, потому что я ведь > внутрь одного rpm-пакета могу захотеть поместить все четыре бинарника, > биранринки nginx и nginx-debug, собранные из > https://freenginx.org/download/freenginx-1.27.4.tar.gz > и бинарники nginx и nginx-debug, собарнные из > https://nginx.org/download/nginx-1.27.1.tar.gz > > To Konstantin Pavlov: > > возможно ли будет внутрь https://nginx.org/en/linux_packages.html > хотя бы для Rocky Linux 9 / RHEL 9 включить не два бинарника, > как сейчас - nginx и nginx-debug, собранных на основании исходников > с сайта https://nginx.org/ но и еще два бинарника nginx и nginx-debug > собранных на основании исходников с сайта https://freenginx.org/ ? > > тогда можно будет иметь всего один юнит-файл nginx.service > а переключение между различными реализациями бинарника nginx > можно будет делать через alternatives, как это уже сделано > для других программ в операционной системе Rocky Linux 9 / RHEL 9 > > # alternatives --list > # alternatives --display ld > # man alternatives > > это было бы очень удобно и для /usr/sbin/nginx, потому что сейчас, > когда не используется alternatives - то приходится сооружать костыли > из двух unit-файлов > > /usr/lib/systemd/system/nginx-debug.service > /usr/lib/systemd/system/nginx.service > > которые отличаются между собой только именем бинарника: > > -ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf > +ExecStart=/usr/sbin/nginx-debug -c /etc/nginx/nginx.conf > > а во всем остальном - полностью идентичны между собой. > > когда делать переключение между различными вариантами nginx > средствами операционной системы - то это будет гораздо удобнее. > потому что все юнит-файлы и все скрипты не будут требовать изменений. > > пока что - четыре варианта бинарников, но в будущем можно добавить > и другие форки и другие варианты бинарного файла /usr/sbin/nginx > > To Konstantin Pavlov: > > можно так сделать? хотя бы только для Rocky Linux 9 / RHEL 9 > > но вообще, сам механизм alternatives есть во многих дистрибутивах. > В Rocky Linux 9 / RHEL 9 бинарник alternatives - это разработка Red Hat. > В Debian / Ubuntu аналогичная бинарная программа - update-alternatives. > > Это было бы удобно, чтобы для отладки временно можно было бы переключить > /usr/sbin/nginx с версии без debug на версию бинарника с debug, > или, чтобы можно было бы для эксперимента переключить /usr/sbin/nginx > с варианта nginx.org на вариант freenginx.org - для тестирования. > > И если окажется, что в варианте бинарника от freenginx.org > ошибки нет, а в варианте бинарника от nginx.org ошибка есть, > то тогда можно будет значительно легче и проще устранить > проблему и в основной версии nginx и в закрытом форке nginx-plus. > > можно так сделать? > > если по каким-то причинам нельзя включать бинарники собранные > с исходников из сайта freenginx.org - то хотя бы можно сделать > переключение между версиями /usr/sbin/nginx с отладкой > и без отладки через механизм alternatives, а не через отдельные > unit-файлы systemd. > > а по два комплекта бинарников - с сайта freenginx.org и nginx.org > можно уже делать внутри rpm-пакетов с сайта freenginx.org - основной > будет версия с сайта freenginx.org, альтернативной --версия с сайта > nginx.org, чтобы можно было бы быстро находить ошибки, > которые присутствуют в исходниках с сайта freenginx.org > но которых нет в исходниках с сайта nginx.org > > это было бы очень удобно и таким образом - у пользователей > была бы возможность быстро переключаться между различными > вариантами nginx / freenginx в случае каких-то проблем. > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Sun Sep 15 21:16:00 2024 From: gmm на csdoc.com (Hennadii Makhomed) Date: Sun, 15 Sep 2024 23:16:00 +0200 Subject: /usr/sbin/nginx alternatives In-Reply-To: References: Message-ID: On 15.09.2024 20:04, Илья Шипицин wrote: > а к чему вы предлагаете привязать график релизов ? если выйдет новая версия > angie или freenginx, пересобирать пакет с nginx ? а какая версия будет у > пакета ? если основным пакетом будет freenginx, то там вообще не проблема, потому что новые версии freenginx выходят чаще, чем новые версии nginx, если посмотреть по содержимому этих двух файлов: https://freenginx.org/en/CHANGES https://nginx.org/en/CHANGES в freenginx больше новых возможностей и больше исправлено ошибок. и тогда версию пакета делать по версии freenginx, и его делать версией по умолчанию, но включить внутрь все четыре варианты исполняемого файла, freenginx и nginx, обычную и отладочную версию бинарника. Но я не знаю, захотят ли сотрудники компании F5, Inc. на своем сайте nginx.org выкладывать бинарники для форка freenginx - им это зачем ? поэтому я и просил сделать хотя бы переключение только между обычной и отладочной версиями nginx через alternatives - дальше уже доработать spec и добавить туда еще и поддержку двух бинарников для freenginx - это будет не сложно и расхождений между rpm-пакетами для freenginx и nginx будет мнимальное количество - тогда получится легко сделать пакет для freenginx, у которого будет запасной вариант, "план Б", чтобы можно было бы в случае обнаружения какого-то бага в поведении freenginx 1.27.4 проверить, воспроизводится ли эта ошибка и при использовании бинарника оригинального nginx, собранного из исходников взятых с сайта nginx.org/en/download.html или нет. Тогда проще будет найти и устранить ошибку - она является общей дле обеих форков, или эта ошибка является уникальной только для nginx, или эта ошибка является уникальной только для freenginx. в пакете freenginx дополнительно еще два бинарника из другой кодовой базы смотрелись бы вполне естественно и это было бы удобно в работе. в rpm-пакете для nginx скорее всего, что не захотят делать через alternatives еще и бинарники для варианта freenginx. потому что там ведь еще и все модули для nginx тоже придется менять, через follower links, во всех дополнительных внешних пакетах, чтобы это была одна link group, которая вся вместе переключается, за один шаг. но это было бы удобно в использовании - при обнаружении какой-то ошибки в работе nginx - переключиться через alternatives на отладочную версию и попробовать найти причину и посмотреть есть ли эта ошибка в альтернативной версии nginx. я бы даже и mainline и stable версии включил бы в один пакет, чтобы можно было бы "на лету" переключаться между: - release или debug - stable или mainline - nginx или freenginx всего 2**8 == 8 различных вариантов бинарников nginx. включать туда еще и Angie - не получится наверное, потому что у Angie все переименовано - и каталоги с конфигами и бинарник переименован, да и модулей у них внешних гораздо больше - скорее всего, что не получится совместить с nginx так, чтобы можно было бы переключать на Angie без каких-либо проблем. Например, Angie умеет отдавать метрики в формате Prometheus, а freenginx и nginx этого не умеют, так что nginx и freenginx будут выдавать ошибку на директивы prometheus и prometheus_template. разве что - портировать эту функциональность из Angie обратно в freenginx и nginx, но ведь nginx не free from arbitrary corporate actions. было бы хорошо сделать для начала хотя бы возможность переключения через alternatives между release и debug версиями nginx, потом - в состав mainline rpm-пакета можно будет добавить и stable-варианты бинарников и потом - уже будет проще по аналогии добавить и возможность переключения между freenginx и nginx зачем могут быть нужны stable бинарники внутри mainline версии? для того, чтобы можно было бы очень быстро определить, присутствует какой-то баг только в mainline версии nginx или же он есть и в stable? без переустановки пакета, просто переключив бинарники через alternatives в общем, пока что есть такие варианты реализации: 1. в виде готовых rpm-пакетов с сайта freenginx.org 2. в виде готовых rpm-пакетов с сайта nginx.org 3. делать это все самому, собирая такие пакеты для себя 4. попробовать поговорить с разрабочиками Rocky Linux, может быть им это тоже будет интересно и в дополнение к существующим Rocky Linux Special Interest Groups https://wiki.rockylinux.org/special_interest_groups/current/ можно будет создать еще одну Special Interest Group, например, Web Server SIG (не путать с Web Server LLC). Ведь судя по статистике August 2024 Web Server Survey https://www.netcraft.com/blog/august-2024-web-server-survey/ в мире примерно на 30% всех сайтов. На самом деле - еще больше, потому что на многих сайтах, которые отжаются через Cloudflare - тоже стоит nginx, просто Cloudflare заменяет заголовок Server: своим. А если смотреть market share по компьютерам (виртуальным или выделенным серверам), то там вообще на почти что 40% всех серверов установлен nginx. по market share of all domains nginx + OpenResty - примерно 37%, но на самом деле больше, потому что там где написано Cloudflare - это тоже во многих случаях nginx. так что возможно получилось бы сделать такую Web Server SIG, но это уже на самый крайний случай, если только по варианту №1 и №2 не получится ничего сделать и есмли это надо будет не только мне одному (вариант №3) и тогда только можно будет пробовать создавать такую SIG в рамках дистрибутива Rocky Linux, чтобы можно было бы собрать наиболее униерсальный и наиболее удобный пакет с nginx для Rocky Linux, включающий в себя все 8 вариантов: - freenginx или nginx - mainline или stable - release или debug какую именно версию дистрибутива активировать по умолчанию через alternatives - в процессе установки пакета можно будет задавать через переменную окружения, yапример, так: export NGINX_VERSION="freenginx-mainline-release" export NGINX_VERSION="freenginx-mainline-debug" export NGINX_VERSION="freenginx-stable-release" export NGINX_VERSION="freenginx-stable-debug" export NGINX_VERSION="nginx-mainline-release" export NGINX_VERSION="nginx-mainline-debug" export NGINX_VERSION="nginx-stable-release" export NGINX_VERSION="nginx-stable-debug" и потом - просто выполнить команду dnf install nginx и необходимая для работы версия nginx будет автоматически активирована в процессе установки rpm-пакета через систему alternatives. но пользователи других дистрибутивов тогда будут ограничены в своих возможностях, потому что такое пакеты, включающие в себя несколько вариантов бинарников nginx тогда будут доступны только для Rocky Linux и пользователи других дистрибутивов Linux тогда будут чувствовать себя не очень уютно и не очень комфортно. вот это ощущение, что был выбран не тот дистрибутив Linux, который было бы целесообразно использовать для production use - оно не из приятных. им же и так хватает проблем с Debian, которых нет в Rocky Linux, например: https://www.opennet.ru/opennews/art.shtml?num=60877 В библиотеке xz/liblzma выявлен бэкдор, организующий вход через sshd https://legalhackers.com/advisories/Nginx-Exploit-Deb-Root-PrivEsc-CVE-2016-1247.html Nginx (Debian-based + Gentoo distros) - Root Privilege Escalation https://bdu.fstec.ru/vul/2015-04116 BDU:2015-04116: Уязвимости операционной системы Debian GNU/Linux, позволяющие удаленному злоумышленнику нарушить конфиденциальность защищаемой информации https://www.linux.org.ru/news/security/2739951 Предсказуемый генератор случайных чисел в Debian/Ubuntu https://www.opennet.ru/opennews/art.shtml?num=15862 Разбор причин появления уязвимости в openssl пакете или о вреде valgrind https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0166 OpenSSL 0.9.8c-1 up to versions before 0.9.8g-9 on Debian-based operating systems uses a random number generator that generates predictable numbers, which makes it easier for remote attackers to conduct brute force guessing attacks against cryptographic keys. Я это не ради флейма пишу, объективно, у Rocky Linux качетсво кода выше, чем у Debian - вот в исторической перскпективе, три серьезные проблемы, которых не было в Enterprise Linux, но которые были добавлены в Debian. получить 10 лет жизни для какой-то ветки Debian можно только за деньги, https://endoflife.date/debian - а для Rocky Linux срок жизни 10 лет - это вообще бесплатно, https://endoflife.date/rocky-linux - потому что Rocky Linux - это клон RHEL + дополнительные возможности, которых нет в RHEL + возможность купить коммерческу поддержку у CIQ https://ciq.com/products/rocky-linux/ в случае необходимости. Потому что Gregory Kurtzer, основатель преокта Rocky Linux является также CEO и основателем CIQ https://ciq.com/company/founding-story/ А то, что Debian stable branch is the most popular edition for personal computers and network servers - этого не понятно. Ведь объективно, по качеству кода - дистрибутив Rocky Linux лучше. Впрочем, сравнивать здесь дистрибутивы Linux - это наверное оффтопик. P.S. это как в том старом анекдоте, Человек останавливает машину. Водитель: Вам куда? - Мне туда-то, а вы такси? - Садитесь. - А вы такси? Так где же ваши шашечки? - Вам шашечки, или ехать? ===================================== так и тут - если на самом деле нужно "ехать", в не "шашечки" то объективно - Rocky Linux - это лучший выбор для сервера, если выбирать из числа всех Linux-дистрибутивов всего мира. -- Best regards, Gena From chipitsine на gmail.com Sun Sep 15 22:30:34 2024 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 16 Sep 2024 00:30:34 +0200 Subject: /usr/sbin/nginx alternatives In-Reply-To: References: Message-ID: вс, 15 сент. 2024 г. в 23:16, Hennadii Makhomed : > On 15.09.2024 20:04, Илья Шипицин wrote: > > > а к чему вы предлагаете привязать график релизов ? если выйдет новая > версия > > angie или freenginx, пересобирать пакет с nginx ? а какая версия будет у > > пакета ? > > если основным пакетом будет freenginx, то там вообще не проблема, > потому что новые версии freenginx выходят чаще, чем новые версии nginx, > если посмотреть по содержимому этих двух файлов: > > https://freenginx.org/en/CHANGES > https://nginx.org/en/CHANGES > > в freenginx больше новых возможностей и больше исправлено ошибок. > > и тогда версию пакета делать по версии freenginx, и его делать версией > по умолчанию, но включить внутрь все четыре варианты исполняемого файла, > freenginx и nginx, обычную и отладочную версию бинарника. > > Но я не знаю, захотят ли сотрудники компании F5, Inc. на своем сайте > nginx.org выкладывать бинарники для форка freenginx - им это зачем ? > > поэтому я и просил сделать хотя бы переключение только между обычной > и отладочной версиями nginx через alternatives - дальше уже доработать > spec и добавить туда еще и поддержку двух бинарников для freenginx - > это будет не сложно и расхождений между rpm-пакетами для freenginx > и nginx будет мнимальное количество - тогда получится легко сделать > пакет для freenginx, у которого будет запасной вариант, "план Б", > чтобы можно было бы в случае обнаружения какого-то бага > в поведении freenginx 1.27.4 проверить, воспроизводится ли > эта ошибка и при использовании бинарника оригинального nginx, > собранного из исходников взятых с сайта nginx.org/en/download.html > или нет. Тогда проще будет найти и устранить ошибку - она является > общей дле обеих форков, или эта ошибка является уникальной только > для nginx, или эта ошибка является уникальной только для freenginx. > > в пакете freenginx дополнительно еще два бинарника из другой кодовой > базы смотрелись бы вполне естественно и это было бы удобно в работе. > > в rpm-пакете для nginx скорее всего, что не захотят делать > через alternatives еще и бинарники для варианта freenginx. > > потому что там ведь еще и все модули для nginx тоже придется менять, > через follower links, во всех дополнительных внешних пакетах, чтобы > это была одна link group, которая вся вместе переключается, за один шаг. > > но это было бы удобно в использовании - при обнаружении какой-то ошибки > в работе nginx - переключиться через alternatives на отладочную версию > и попробовать найти причину и посмотреть есть ли эта ошибка > в альтернативной версии nginx. > > я бы даже и mainline и stable версии включил бы в один пакет, > чтобы можно было бы "на лету" переключаться между: > > - release или debug > - stable или mainline > - nginx или freenginx > > всего 2**8 == 8 различных вариантов бинарников nginx. > > включать туда еще и Angie - не получится наверное, > потому что у Angie все переименовано - и каталоги > с конфигами и бинарник переименован, да и модулей > у них внешних гораздо больше - скорее всего, что > не получится совместить с nginx так, чтобы можно > было бы переключать на Angie без каких-либо проблем. > > Например, Angie умеет отдавать метрики в формате > Prometheus, а freenginx и nginx этого не умеют, > так что nginx и freenginx будут выдавать ошибку > на директивы prometheus и prometheus_template. > > разве что - портировать эту функциональность > из Angie обратно в freenginx и nginx, но ведь > nginx не free from arbitrary corporate actions. > > было бы хорошо сделать для начала хотя бы возможность > переключения через alternatives между release и debug > версиями nginx, потом - в состав mainline rpm-пакета > можно будет добавить и stable-варианты бинарников > и потом - уже будет проще по аналогии добавить > и возможность переключения между freenginx и nginx > > зачем могут быть нужны stable бинарники внутри mainline версии? > > для того, чтобы можно было бы очень быстро определить, присутствует > какой-то баг только в mainline версии nginx или же он есть и в stable? > без переустановки пакета, просто переключив бинарники через alternatives > > в общем, пока что есть такие варианты реализации: > > 1. в виде готовых rpm-пакетов с сайта freenginx.org > > 2. в виде готовых rpm-пакетов с сайта nginx.org > > 3. делать это все самому, собирая такие пакеты для себя > > 4. попробовать поговорить с разрабочиками Rocky Linux, > может быть им это тоже будет интересно и в дополнение > к существующим Rocky Linux Special Interest Groups > https://wiki.rockylinux.org/special_interest_groups/current/ > можно будет создать еще одну Special Interest Group, > например, Web Server SIG (не путать с Web Server LLC). > > Ведь судя по статистике August 2024 Web Server Survey > https://www.netcraft.com/blog/august-2024-web-server-survey/ > в мире примерно на 30% всех сайтов. На самом деле - еще больше, > потому что на многих сайтах, которые отжаются через Cloudflare > - тоже стоит nginx, просто Cloudflare заменяет заголовок Server: своим. > > А если смотреть market share по компьютерам > (виртуальным или выделенным серверам), то там вообще > на почти что 40% всех серверов установлен nginx. > это огромное число серверов. наталкивает на мысль, что каким-то образом задача с пакетами решена, не могут же столько народа мучиться, чтобы об этом ничего не было известно. > > по market share of all domains nginx + OpenResty - примерно 37%, > но на самом деле больше, потому что там где написано Cloudflare > - это тоже во многих случаях nginx. > > так что возможно получилось бы сделать такую Web Server SIG, > но это уже на самый крайний случай, если только по варианту > №1 и №2 не получится ничего сделать и есмли это надо будет > не только мне одному (вариант №3) и тогда только можно будет > пробовать создавать такую SIG в рамках дистрибутива Rocky Linux, > чтобы можно было бы собрать наиболее униерсальный и наиболее удобный > пакет с nginx для Rocky Linux, включающий в себя все 8 вариантов: > > - freenginx или nginx > - mainline или stable > - release или debug > > какую именно версию дистрибутива активировать по умолчанию через > alternatives - в процессе установки пакета можно будет задавать > через переменную окружения, yапример, так: > > export NGINX_VERSION="freenginx-mainline-release" > export NGINX_VERSION="freenginx-mainline-debug" > > export NGINX_VERSION="freenginx-stable-release" > export NGINX_VERSION="freenginx-stable-debug" > > export NGINX_VERSION="nginx-mainline-release" > export NGINX_VERSION="nginx-mainline-debug" > > export NGINX_VERSION="nginx-stable-release" > export NGINX_VERSION="nginx-stable-debug" > > и потом - просто выполнить команду > > dnf install nginx > > и необходимая для работы версия nginx > будет автоматически активирована в процессе > установки rpm-пакета через систему alternatives. > > но пользователи других дистрибутивов тогда будут ограничены > в своих возможностях, потому что такое пакеты, включающие > в себя несколько вариантов бинарников nginx тогда будут доступны > только для Rocky Linux и пользователи других дистрибутивов Linux > тогда будут чувствовать себя не очень уютно и не очень комфортно. > > вот это ощущение, что был выбран не тот дистрибутив Linux, который было > бы целесообразно использовать для production use - оно не из приятных. > > им же и так хватает проблем с Debian, > которых нет в Rocky Linux, например: > > https://www.opennet.ru/opennews/art.shtml?num=60877 > В библиотеке xz/liblzma выявлен бэкдор, организующий вход через sshd > > > https://legalhackers.com/advisories/Nginx-Exploit-Deb-Root-PrivEsc-CVE-2016-1247.html > Nginx (Debian-based + Gentoo distros) - Root Privilege Escalation > > https://bdu.fstec.ru/vul/2015-04116 > BDU:2015-04116: Уязвимости операционной системы Debian GNU/Linux, > позволяющие удаленному злоумышленнику нарушить конфиденциальность > защищаемой информации > https://www.linux.org.ru/news/security/2739951 > Предсказуемый генератор случайных чисел в Debian/Ubuntu > https://www.opennet.ru/opennews/art.shtml?num=15862 > Разбор причин появления уязвимости в openssl пакете или о вреде valgrind > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0166 > OpenSSL 0.9.8c-1 up to versions before 0.9.8g-9 on Debian-based > operating systems uses a random number generator that generates > predictable numbers, which makes it easier for remote attackers > to conduct brute force guessing attacks against cryptographic keys. > > Я это не ради флейма пишу, объективно, у Rocky Linux качетсво кода выше, > чем у Debian - вот в исторической перскпективе, три серьезные проблемы, > которых не было в Enterprise Linux, но которые были добавлены в Debian. > > получить 10 лет жизни для какой-то ветки Debian можно только за деньги, > https://endoflife.date/debian - а для Rocky Linux срок жизни 10 лет - > это вообще бесплатно, https://endoflife.date/rocky-linux - потому > что Rocky Linux - это клон RHEL + дополнительные возможности, > которых нет в RHEL + возможность купить коммерческу поддержку > у CIQ https://ciq.com/products/rocky-linux/ в случае необходимости. > > Потому что Gregory Kurtzer, основатель преокта Rocky Linux является > также CEO и основателем CIQ https://ciq.com/company/founding-story/ > > А то, что Debian stable branch is the most popular edition > for personal computers and network servers - этого не понятно. > > Ведь объективно, по качеству кода - дистрибутив Rocky Linux лучше. > Впрочем, сравнивать здесь дистрибутивы Linux - это наверное оффтопик. > > P.S. > > это как в том старом анекдоте, > > Человек останавливает машину. > Водитель: Вам куда? > - Мне туда-то, а вы такси? > - Садитесь. > - А вы такси? Так где же ваши шашечки? > - Вам шашечки, или ехать? > > ===================================== > > так и тут - если на самом деле нужно "ехать", в не "шашечки" > то объективно - Rocky Linux - это лучший выбор для сервера, > если выбирать из числа всех Linux-дистрибутивов всего мира. > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From raven_kg на megaline.kg Mon Sep 16 03:13:02 2024 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Mon, 16 Sep 2024 09:13:02 +0600 Subject: /usr/sbin/nginx alternatives In-Reply-To: References: Message-ID: Предположим, опакетить freenginx для семейства RHEL 8-9 совершенно не проблема, хотя и есть отдельные вопросы (именование юнита, разрешение конфликтов и т.д.). Но вот эта вот часть про alternatives вызывает некоторые вопросы к автору и его дилеру. Во-первых, вы предлагаете объединить в один пакет кучу ОТДЕЛЬНЫХ проектов, сама по себе суть возникновения которых была в том, чтобы существовать ОТДЕЛЬНО. Во-вторых, само по себе использование alternatives - весьма спорное предложение. Как мы помним, alternatives формирует цепочку симлинков: /usr/sbin/ -> /etc/alternatives/ -> /usr/sbin/. В моей практике несколько раз случались ситуации, когда после обновления пакетов симлинк /etc/alternatives/ начинал указывать в пустоту. Да, это вероятно была какая-то ошибка сборщика пакетов, но тем не менее, это достаточно неприятный инцидент. В случае с (free)nginx такое проишествие способно повлечь за собой достаточно неприятные последствия и лично мне очень бы не хотелось иметь на серверах мины замедленного действия. 15.09.2024 20:32, Hennadii Makhomed пишет: > Здравствуйте, All! > > nginx развивается в разных направлениях, > > freenginx > Angie > OpenResty > Tengine > nginx-plus > nginx > > https://freenginx.org/ развивается достаточно динамично, > много исправлений ошибок, часто выходят новые mainline версии. > > Но на странице https://freenginx.org/en/download.html не понятная > ситуация - есть .tar.gz архивы с исходными текстами, есть .zip архивы > с бинарными версиями nginx для операционных систем семейства Windows, > но нет rpm-пакетов и yum-репозиториев для Rocky Linux 9 / RHEL 9. > > То есть, ситуация выглядит так, что поддержка операционных систем > семейства Windows даже на более высоком уровне, чем поддержка > операционных сисем семейства Enterprise Linux, у которых 10 лет > срок жизни дистрибутива и наивысший уровень надежности > и стабильности среди вообще всех дистрибутивов Linux. > > Особенно - после того, как Solar Designer присоединился к проекту > Rocky Linux - https://x.com/solardiz/status/1709574519688487374 > > А вот с freenginx ситуация не понятная совершенно - его же сейчас > можно нормально использовать только в FreeBSD, потому что там есть > соответствующий порт. А для для Rocky Linux 9 / RHEL 9 - бинарников > на сайте https://freenginx.org/ нет, так что использовать его легко > и просто не получится - надо каждому пользователю freenginx самому > делать rpm пакеты, самому делать yum-репозитории, и потом - это все > еще и надо поддерживать в актулаьном состоянии, оперативно выпуская > новые версии с каждым выходом freenginx. То есть, пока что он не для > production? Или только для early adopters, у которых есть время > и возможность и желание, чтобы самим у себя поддерживать эту > инфранструктуру для сборки новых версий freenginx? > > Просто не понимаю, как использовать freenginx в production. > Кто-либо это делает на Rocky Linux 9 / RHEL 9 ? Каким образом? > > Или все пользователи freenginx - это только пользователи FreeBSD? > Там то все просто, потому что есть соответствующий порт в системе. > > Так не хочется самому этим всем заморачиваться, потому что я ведь > внутрь одного rpm-пакета могу захотеть поместить все четыре бинарника, > биранринки nginx и nginx-debug, собранные из > https://freenginx.org/download/freenginx-1.27.4.tar.gz > и бинарники nginx и nginx-debug, собарнные из > https://nginx.org/download/nginx-1.27.1.tar.gz > > To Konstantin Pavlov: > > возможно ли будет внутрь https://nginx.org/en/linux_packages.html > хотя бы для Rocky Linux 9 / RHEL 9 включить не два бинарника, > как сейчас - nginx и nginx-debug, собранных на основании исходников > с сайта https://nginx.org/ но и еще два бинарника nginx и nginx-debug > собранных на основании исходников с сайта https://freenginx.org/ ? > > тогда можно будет иметь всего один юнит-файл nginx.service > а переключение между различными реализациями бинарника nginx > можно будет делать через alternatives, как это уже сделано > для других программ в операционной системе Rocky Linux 9 / RHEL 9 > > # alternatives --list > # alternatives --display ld > # man alternatives > > это было бы очень удобно и для /usr/sbin/nginx, потому что сейчас, > когда не используется alternatives - то приходится сооружать костыли > из двух unit-файлов > > /usr/lib/systemd/system/nginx-debug.service > /usr/lib/systemd/system/nginx.service > > которые отличаются между собой только именем бинарника: > > -ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf > +ExecStart=/usr/sbin/nginx-debug -c /etc/nginx/nginx.conf > > а во всем остальном - полностью идентичны между собой. > > когда делать переключение между различными вариантами nginx > средствами операционной системы - то это будет гораздо удобнее. > потому что все юнит-файлы и все скрипты не будут требовать изменений. > > пока что - четыре варианта бинарников, но в будущем можно добавить > и другие форки и другие варианты бинарного файла /usr/sbin/nginx > > To Konstantin Pavlov: > > можно так сделать? хотя бы только для Rocky Linux 9 / RHEL 9 > > но вообще, сам механизм alternatives есть во многих дистрибутивах. > В Rocky Linux 9 / RHEL 9 бинарник alternatives - это разработка Red Hat. > В Debian / Ubuntu аналогичная бинарная программа - update-alternatives. > > Это было бы удобно, чтобы для отладки временно можно было бы переключить > /usr/sbin/nginx с версии без debug на версию бинарника с debug, > или, чтобы можно было бы для эксперимента переключить /usr/sbin/nginx > с варианта nginx.org на вариант freenginx.org - для тестирования. > > И если окажется, что в варианте бинарника от freenginx.org > ошибки нет, а в варианте бинарника от nginx.org ошибка есть, > то тогда можно будет значительно легче и проще устранить > проблему и в основной версии nginx и в закрытом форке nginx-plus. > > можно так сделать? > > если по каким-то причинам нельзя включать бинарники собранные > с исходников из сайта freenginx.org - то хотя бы можно сделать > переключение между версиями /usr/sbin/nginx с отладкой > и без отладки через механизм alternatives, а не через отдельные > unit-файлы systemd. > > а по два комплекта бинарников - с сайта freenginx.org и nginx.org > можно уже делать внутри rpm-пакетов с сайта freenginx.org - основной > будет версия с сайта freenginx.org, альтернативной --версия с сайта > nginx.org, чтобы можно было бы быстро находить ошибки, > которые присутствуют в исходниках с сайта freenginx.org > но которых нет в исходниках с сайта nginx.org > > это было бы очень удобно и таким образом - у пользователей > была бы возможность быстро переключаться между различными > вариантами nginx / freenginx в случае каких-то проблем. > From thresh на nginx.com Mon Sep 16 16:10:27 2024 From: thresh на nginx.com (Konstantin Pavlov) Date: Mon, 16 Sep 2024 09:10:27 -0700 Subject: /usr/sbin/nginx alternatives In-Reply-To: References: Message-ID: Здравствуйте, On 15/09/2024 7:32 AM, Hennadii Makhomed wrote: > To Konstantin Pavlov: > > возможно ли будет внутрь https://nginx.org/en/linux_packages.html > хотя бы для Rocky Linux 9 / RHEL 9 включить не два бинарника, > как сейчас - nginx и nginx-debug, собранных на основании исходников > с сайта https://nginx.org/ но и еще два бинарника nginx и nginx-debug > собранных на основании исходников с сайта https://freenginx.org/ ? Нет, паковать и поддерживать не наш код мы не будем. From gmm на csdoc.com Mon Sep 16 16:52:09 2024 From: gmm на csdoc.com (Hennadii Makhomed) Date: Mon, 16 Sep 2024 18:52:09 +0200 Subject: /usr/sbin/nginx alternatives In-Reply-To: References: Message-ID: On 16.09.2024 18:10, Konstantin Pavlov wrote: >> возможно ли будет внутрь https://nginx.org/en/linux_packages.html >> хотя бы для Rocky Linux 9 / RHEL 9 включить не два бинарника, >> как сейчас - nginx и nginx-debug, собранных на основании исходников >> с сайта https://nginx.org/ но и еще два бинарника nginx и nginx-debug >> собранных на основании исходников с сайта https://freenginx.org/ ? > Нет, паковать и поддерживать не наш код мы не будем. Ok. а как Вам идея вместо двух unit-файлов nginx.service и nginx-debug.service использовать только один unit-файл nginx.service и использовать alternatives для переключения бинарника /usr/sbin/nginx между release и debug версиями ? можно ли при сборке пакета с nginx поменять каталог /var/run/nginx.pid на /run/nginx.pid ? в логах сообщения есть на эту тему: Sep 15 22:06:25 dc21-srv123-vm121 systemd: /usr/lib/systemd/system/nginx.service:9: PIDFile= references a path below legacy directory /var/run/, updating /var/run/nginx.pid → /run/nginx.pid; please update the unit file accordingly. -- Best regards, Gena From thresh на nginx.com Mon Sep 16 17:25:33 2024 From: thresh на nginx.com (Konstantin Pavlov) Date: Mon, 16 Sep 2024 10:25:33 -0700 Subject: /usr/sbin/nginx alternatives In-Reply-To: References: Message-ID: Здравствуйте, On 16/09/2024 9:52 AM, Hennadii Makhomed wrote: > On 16.09.2024 18:10, Konstantin Pavlov wrote: > >>> возможно ли будет внутрь https://nginx.org/en/linux_packages.html >>> хотя бы для Rocky Linux 9 / RHEL 9 включить не два бинарника, >>> как сейчас - nginx и nginx-debug, собранных на основании исходников >>> с сайта https://nginx.org/ но и еще два бинарника nginx и nginx-debug >>> собранных на основании исходников с сайта https://freenginx.org/ ? > >> Нет, паковать и поддерживать не наш код мы не будем. > > Ok. а как Вам идея вместо двух unit-файлов nginx.service > и nginx-debug.service использовать только один unit-файл > nginx.service и использовать alternatives для переключения > бинарника /usr/sbin/nginx между release и debug версиями ? Мы поддерживаем несколько разных ОС в наших пакетах на nginx.org (и еще больше - для коммерческой версии), и не во всех них есть поддержка alternatives.  По этой причине не хотелось бы это реализовывать для какой-то одной конкретной ОС если нельзя сделать везде одинаково. > можно ли при сборке пакета с nginx поменять > каталог /var/run/nginx.pid на /run/nginx.pid ? > > в логах сообщения есть на эту тему: > > Sep 15 22:06:25 dc21-srv123-vm121 systemd: > /usr/lib/systemd/system/nginx.service:9: PIDFile= references a path > below legacy directory /var/run/, updating /var/run/nginx.pid → > /run/nginx.pid; please update the unit file accordingly. Да, это есть в планах, давно пора поменять. From gmm на csdoc.com Mon Sep 16 18:34:31 2024 From: gmm на csdoc.com (Hennadii Makhomed) Date: Mon, 16 Sep 2024 20:34:31 +0200 Subject: /usr/sbin/nginx alternatives In-Reply-To: References: Message-ID: <16ead54d-9392-4ac4-8a2a-5b4f5396739e@csdoc.com> On 16.09.2024 19:25, Konstantin Pavlov wrote: >> а как Вам идея вместо двух unit-файлов nginx.service >> и nginx-debug.service использовать только один unit-файл >> nginx.service и использовать alternatives для переключения >> бинарника /usr/sbin/nginx между release и debug версиями ? > > Мы поддерживаем несколько разных ОС в наших пакетах на nginx.org (и еще > больше - для коммерческой версии), и не во всех них есть поддержка > alternatives.  По этой причине не хотелось бы это реализовывать для > какой-то одной конкретной ОС если нельзя сделать везде одинаково. это можно сделать везде одинаково, на всех Linux/UNIX системах. в пакет положить два бинарника: /usr/sbin/nginx-release /usr/sbin/nginx-debug а потом симлинк /usr/sbin/nginx устанавливать на один из этих бинарников внешним скриптом, если такого симлинка нет - установить его тогда на /usr/sbin/nginx-release например, так: NGINX_VERSION=debug /sbin/service nginx upgrade NGINX_VERSION=release /sbin/service nginx upgrade просто добавив скрипт /usr/libexec/initscripts/legacy-actions/nginx/upgrade такую логику: если переменная NGINX_VERSION равна debug то установить симлинк /usr/sbin/nginx чтобы он указывал на на бинарник /usr/sbin/nginx-debug если переменная NGINX_VERSION равна release то установить симлинк /usr/sbin/nginx чтобы он указывал на на бинарник /usr/sbin/nginx-release если переменная NGINX_VERSION не определена - не трогать симлинк. если переменная NGINX_VERSION определена, но не равна release или debug то в таком случае выдать сообщение про ошибку и аварийно завершить работу скрипта с ненулевым кодом ошибки переменную NGINX нельзя использовать, потому что # man nginx ENVIRONMENT The NGINX environment variable is used internally by nginx and should not be set directly by the user. =============================================================== или так: nginx upgrade to debug nginx upgrade to release nginx upgrade причем, одинарные или двойные минусы перед словом "upgrade" тут и не нужны, потому что это же и есть именно что команда в таком стиле работает и zfs и systemctl и многие другие команды современного Linux/UNIX например, тот же kubectl если же переключение между release / debug версями происходит с помощью двух отдельных сервисов nginx.service и nginx-debug.service, то в таком случае переключение между ними происходит с потерей соединений клиентов -- Best regards, Gena From thresh на nginx.com Mon Sep 16 19:06:34 2024 From: thresh на nginx.com (Konstantin Pavlov) Date: Mon, 16 Sep 2024 12:06:34 -0700 Subject: /usr/sbin/nginx alternatives In-Reply-To: <16ead54d-9392-4ac4-8a2a-5b4f5396739e@csdoc.com> References: <16ead54d-9392-4ac4-8a2a-5b4f5396739e@csdoc.com> Message-ID: <1818b389-1ac8-4e1a-94f6-443aefda3dcd@nginx.com> Здравствуйте, On 16/09/2024 11:34 AM, Hennadii Makhomed wrote: > On 16.09.2024 19:25, Konstantin Pavlov wrote: > >>> а как Вам идея вместо двух unit-файлов nginx.service >>> и nginx-debug.service использовать только один unit-файл >>> nginx.service и использовать alternatives для переключения >>> бинарника /usr/sbin/nginx между release и debug версиями ? >> >> Мы поддерживаем несколько разных ОС в наших пакетах на nginx.org (и >> еще больше - для коммерческой версии), и не во всех них есть >> поддержка alternatives.  По этой причине не хотелось бы это >> реализовывать для какой-то одной конкретной ОС если нельзя сделать >> везде одинаково. > > это можно сделать везде одинаково, на всех Linux/UNIX системах. > > если же переключение между release / debug версями происходит с помощью > двух отдельных сервисов nginx.service и nginx-debug.service, то в таком > случае переключение между ними происходит с потерей соединений клиентов Делать столько уникальной логики, опять же уходя от привычной многим и документированной системы alternatives, для очень редкой ситуации когда нужно запустить дебаг-версию? Кажется, гораздо проще, если уж нельзя воспроизвести проблему на стенде, сделать временно: mv /usr/sbin/nginx /usr/sbin/nginx.bak mv /usr/sbin/nginx-debug /usr/sbin/nginx service nginx upgrade From gmm на csdoc.com Mon Sep 16 19:59:00 2024 From: gmm на csdoc.com (Hennadii Makhomed) Date: Mon, 16 Sep 2024 21:59:00 +0200 Subject: /usr/sbin/nginx alternatives In-Reply-To: <1818b389-1ac8-4e1a-94f6-443aefda3dcd@nginx.com> References: <16ead54d-9392-4ac4-8a2a-5b4f5396739e@csdoc.com> <1818b389-1ac8-4e1a-94f6-443aefda3dcd@nginx.com> Message-ID: On 16.09.2024 21:06, Konstantin Pavlov wrote: >>> Мы поддерживаем несколько разных ОС в наших пакетах на nginx.org (и >>> еще больше - для коммерческой версии), и не во всех них есть >>> поддержка alternatives.  По этой причине не хотелось бы это >>> реализовывать для какой-то одной конкретной ОС если нельзя сделать >>> везде одинаково. >> >> это можно сделать везде одинаково, на всех Linux/UNIX системах. >> >> если же переключение между release / debug версями происходит с помощью >> двух отдельных сервисов nginx.service и nginx-debug.service, то в таком >> случае переключение между ними происходит с потерей соединений клиентов > > Делать столько уникальной логики, опять же уходя от привычной многим и > документированной системы alternatives, для очень редкой ситуации когда > нужно запустить дебаг-версию? > > Кажется, гораздо проще, если уж нельзя воспроизвести проблему на стенде, > сделать временно: > > mv /usr/sbin/nginx /usr/sbin/nginx.bak > > mv /usr/sbin/nginx-debug /usr/sbin/nginx > > service nginx upgrade > гораздо проще для пользователя как open source версии nginx, так и коммерческой версии nginx-plus было бы просто выполнить одну команду для переключения между release и debug версиями: nginx upgrade to debug nginx upgrade to release nginx upgrade привычная многим система alternatives есть не во всех ОС, и везде одинаково сделать можно только в том случае, если эту логику реализовать прямо внутри nginx. команды service вскоре не будет, ее планируют выбросить из systemd: https://github.com/systemd/systemd/blob/main/NEWS * Support for System V service scripts is deprecated and will be removed in a future release. Please make sure to update your software *now* to include a native systemd unit file instead of a legacy System V script to retain compatibility with future systemd releases. -- Best regards, Gena From chipitsine на gmail.com Mon Sep 16 20:53:37 2024 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 16 Sep 2024 22:53:37 +0200 Subject: /usr/sbin/nginx alternatives In-Reply-To: References: <16ead54d-9392-4ac4-8a2a-5b4f5396739e@csdoc.com> <1818b389-1ac8-4e1a-94f6-443aefda3dcd@nginx.com> Message-ID: пн, 16 сент. 2024 г. в 21:59, Hennadii Makhomed : > On 16.09.2024 21:06, Konstantin Pavlov wrote: > > >>> Мы поддерживаем несколько разных ОС в наших пакетах на nginx.org (и > >>> еще больше - для коммерческой версии), и не во всех них есть > >>> поддержка alternatives. По этой причине не хотелось бы это > >>> реализовывать для какой-то одной конкретной ОС если нельзя сделать > >>> везде одинаково. > >> > >> это можно сделать везде одинаково, на всех Linux/UNIX системах. > >> > >> если же переключение между release / debug версями происходит с помощью > >> двух отдельных сервисов nginx.service и nginx-debug.service, то в таком > >> случае переключение между ними происходит с потерей соединений клиентов > > > > Делать столько уникальной логики, опять же уходя от привычной многим и > > документированной системы alternatives, для очень редкой ситуации когда > > нужно запустить дебаг-версию? > > > > Кажется, гораздо проще, если уж нельзя воспроизвести проблему на стенде, > > сделать временно: > > > > mv /usr/sbin/nginx /usr/sbin/nginx.bak > > > > mv /usr/sbin/nginx-debug /usr/sbin/nginx > > > > service nginx upgrade > > > > гораздо проще для пользователя как open source версии nginx, > так и коммерческой версии nginx-plus было бы просто выполнить > одну команду для переключения между release и debug версиями: > > nginx upgrade to debug > > nginx upgrade to release > > nginx upgrade > > привычная многим система alternatives есть не во всех ОС, > и везде одинаково сделать можно только в том случае, > если эту логику реализовать прямо внутри nginx. > > команды service вскоре не будет, ее планируют выбросить из systemd: > > https://github.com/systemd/systemd/blob/main/NEWS > > * Support for System V service scripts is deprecated and will be > removed in a future release. Please make sure to update your software > *now* to include a native systemd unit file instead of a legacy > System V script to retain compatibility with future systemd releases. > это касается лишь систем, работающих на systemd, причем на последней версии. переносить в nginx логику "вы вызываете nginx upgrade и в соответствии с принятой в данном дистрибутиве системой инициализации все будет по феншую" - не слишком ли много оверинжиниринга. есть всякие чудеса на дебиан без systemd. есть, прости господи, NixOS > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From thresh на nginx.com Mon Sep 16 20:55:17 2024 From: thresh на nginx.com (Konstantin Pavlov) Date: Mon, 16 Sep 2024 13:55:17 -0700 Subject: /usr/sbin/nginx alternatives In-Reply-To: References: <16ead54d-9392-4ac4-8a2a-5b4f5396739e@csdoc.com> <1818b389-1ac8-4e1a-94f6-443aefda3dcd@nginx.com> Message-ID: <9e0176cc-7dda-4801-a2b0-c1c138be1aca@nginx.com> Здравствуйте, On 16/09/2024 12:59 PM, Hennadii Makhomed wrote: > привычная многим система alternatives есть не во всех ОС, > и везде одинаково сделать можно только в том случае, > если эту логику реализовать прямо внутри nginx. Да, именно поэтому и не хочется делать что-то уникальное только для nginx. > команды service вскоре не будет, ее планируют выбросить из systemd: > > https://github.com/systemd/systemd/blob/main/NEWS > > * Support for System V service scripts is deprecated and will be >   removed in a future release. Please make sure to update your software >   *now* to include a native systemd unit file instead of a legacy >   System V script to retain compatibility with future systemd releases. Команда service не была в systemd никогда, это часть дистрибутивных обвязок вокруг sysvinit. То, что вы цитируете - поддержка генерации unit-файлов на базе init-скриптов, если этих unit-файлов нет изначально.  Это не наш случай. From russjura на gmail.com Mon Sep 16 21:07:30 2024 From: russjura на gmail.com (=?UTF-8?B?0K7RgNC40Lk=?=) Date: Mon, 16 Sep 2024 23:07:30 +0200 Subject: /usr/sbin/nginx alternatives In-Reply-To: <9e0176cc-7dda-4801-a2b0-c1c138be1aca@nginx.com> References: <16ead54d-9392-4ac4-8a2a-5b4f5396739e@csdoc.com> <1818b389-1ac8-4e1a-94f6-443aefda3dcd@nginx.com> <9e0176cc-7dda-4801-a2b0-c1c138be1aca@nginx.com> Message-ID: Предлагаю к году-месяцу + индекс от продукта который обновился: n - nginx a - angie f - freenginx и другие.. пн, 16 сент. 2024 г., 22:55 Konstantin Pavlov : > Здравствуйте, > > On 16/09/2024 12:59 PM, Hennadii Makhomed wrote: > > привычная многим система alternatives есть не во всех ОС, > > и везде одинаково сделать можно только в том случае, > > если эту логику реализовать прямо внутри nginx. > > Да, именно поэтому и не хочется делать что-то уникальное только для nginx. > > > > команды service вскоре не будет, ее планируют выбросить из systemd: > > > > https://github.com/systemd/systemd/blob/main/NEWS > > > > * Support for System V service scripts is deprecated and will be > > removed in a future release. Please make sure to update your software > > *now* to include a native systemd unit file instead of a legacy > > System V script to retain compatibility with future systemd releases. > > Команда service не была в systemd никогда, это часть дистрибутивных > обвязок вокруг sysvinit. > > То, что вы цитируете - поддержка генерации unit-файлов на базе > init-скриптов, если этих unit-файлов нет изначально. Это не наш случай. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Mon Sep 16 21:12:46 2024 From: gmm на csdoc.com (Hennadii Makhomed) Date: Mon, 16 Sep 2024 23:12:46 +0200 Subject: /usr/sbin/nginx alternatives In-Reply-To: References: <16ead54d-9392-4ac4-8a2a-5b4f5396739e@csdoc.com> <1818b389-1ac8-4e1a-94f6-443aefda3dcd@nginx.com> Message-ID: On 16.09.2024 22:53, Илья Шипицин wrote: >> привычная многим система alternatives есть не во всех ОС, >> и везде одинаково сделать можно только в том случае, >> если эту логику реализовать прямо внутри nginx. > это касается лишь систем, работающих на systemd, причем на последней версии. > переносить в nginx логику "вы вызываете nginx upgrade и в соответствии с > принятой в данном дистрибутиве > системой инициализации все будет по феншую" - не слишком ли много > оверинжиниринга. > > есть всякие чудеса на дебиан без systemd. есть, прости господи, NixOS если этот метод логики обновления бинарника на лету: https://nginx.org/en/docs/control.html#upgrade Upgrading Executable on the Fly реализовать внутри nginx в виде кода на C, как nginx upgrade то это тогда будет работать на любой системе Linux / UNIX. сейчас эта логика обновления реализована в виде shell-скрипта /usr/libexec/initscripts/legacy-actions/nginx/upgrade который запускается на выполнение командой service nginx upgrade -- Best regards, Gena From gmm на csdoc.com Mon Sep 16 22:02:07 2024 From: gmm на csdoc.com (Hennadii Makhomed) Date: Tue, 17 Sep 2024 00:02:07 +0200 Subject: /usr/sbin/nginx alternatives In-Reply-To: <1818b389-1ac8-4e1a-94f6-443aefda3dcd@nginx.com> References: <16ead54d-9392-4ac4-8a2a-5b4f5396739e@csdoc.com> <1818b389-1ac8-4e1a-94f6-443aefda3dcd@nginx.com> Message-ID: On 16.09.2024 21:06, Konstantin Pavlov wrote: > Делать столько уникальной логики, опять же уходя от привычной многим и > документированной системы alternatives, для очень редкой ситуации когда > нужно запустить дебаг-версию? > > Кажется, гораздо проще, если уж нельзя воспроизвести проблему на стенде, > сделать временно: > > mv /usr/sbin/nginx /usr/sbin/nginx.bak > > mv /usr/sbin/nginx-debug /usr/sbin/nginx > > service nginx upgrade > Вообще-то да, Вы правы, переключение на nginx-debug необходимо достаточно редко, и не стоит ради этого сильно усложнять систему и делать ее более хрупкой из-за симлинков или хардлинков на бинарники. А если не приемлемо делать переключение версий через остановку сервиса nginx.service и запуск сервиса nginx-debug.service - то можно будет переключить через service nginx upgrade без потери соединений, перед тем просто вручную переименовав бинарник. -- Best regards, Gena From gmm на csdoc.com Tue Sep 17 08:10:25 2024 From: gmm на csdoc.com (Hennadii Makhomed) Date: Tue, 17 Sep 2024 10:10:25 +0200 Subject: /usr/sbin/nginx alternatives In-Reply-To: <1818b389-1ac8-4e1a-94f6-443aefda3dcd@nginx.com> References: <16ead54d-9392-4ac4-8a2a-5b4f5396739e@csdoc.com> <1818b389-1ac8-4e1a-94f6-443aefda3dcd@nginx.com> Message-ID: On 16.09.2024 21:06, Konstantin Pavlov wrote: >>>> а как Вам идея вместо двух unit-файлов nginx.service >>>> и nginx-debug.service использовать только один unit-файл >>>> nginx.service и использовать alternatives для переключения >>>> бинарника /usr/sbin/nginx между release и debug версиями ? >>> >>> Мы поддерживаем несколько разных ОС в наших пакетах на nginx.org (и >>> еще больше - для коммерческой версии), и не во всех них есть >>> поддержка alternatives.  По этой причине не хотелось бы это >>> реализовывать для какой-то одной конкретной ОС если нельзя сделать >>> везде одинаково. >> >> это можно сделать везде одинаково, на всех Linux/UNIX системах. >> >> если же переключение между release / debug версями происходит с помощью >> двух отдельных сервисов nginx.service и nginx-debug.service, то в таком >> случае переключение между ними происходит с потерей соединений клиентов > > Делать столько уникальной логики, опять же уходя от привычной многим и > документированной системы alternatives, для очень редкой ситуации когда > нужно запустить дебаг-версию? Моя идея с симлинком /usr/sbin/nginx который указывает на release или debug версию бинарника nginx - это плохая идея еще и потому, что по стандарту FHS - "/usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere". alternatives использовать также нельзя, потому что не во всех ОС есть поддержка alternatives и потому что использование системы alternatives увеличивает хрупкость. > Кажется, гораздо проще, если уж нельзя воспроизвести проблему на стенде, > сделать временно: > > mv /usr/sbin/nginx /usr/sbin/nginx.bak > > mv /usr/sbin/nginx-debug /usr/sbin/nginx > > service nginx upgrade > А что делать в том случае, когда файловая система /usr смонтирована в режиме read-only и не удается воспроизвести проблему на стенде? Да и в том случае, когда файловая система /usr доступна на запись - переименование исполняемых файлов - это неудобно как для самих пользователей, так и для инженеров технической поддержки, которые будут общаться с пользователями и помогать им. Какое решение этой задачи будет более оптимальным? service nginx upgrade service nginx upgrade-to-debug service nginx upgrade-to-release Как технически это реализовать? Upgrading Executable on the Fly https://nginx.org/en/docs/control.html#upgrade Когда старый master-процесс nginx делает этот шаг: "then starts a new executable file that in turn starts new worker processes" необходимо, он мог понимать, какой именно бинарник ему следует запустить на выполнение - release или debug вариант бинарника. Для этого - надо передать работающему master-процессу nginx в процессе online upgrade дополнительно один бит информации. когда передается 0 бит - тогда запускается /usr/sbin/nginx когда передается 1 бит - тогда запускается /usr/sbin/nginx-debug Каким образом это можно сделать? С помощью pid-файла. В нормальном режиме работы pid-файл имеет владельца root:root и права доступа 0644 (-rw-r--r--) - в таком случае master-процесс nginx делает online upgrade на обычную, release-версию бинарника /usr/sbin/nginx Если же в момент получения master-процессом nginx сигнала USR2 на его pid-файл установлены права доступа 0664 (-rw-rw-r--) - в таком случае master-процесс nginx делает online upgrade на отладочную, debug-версию бинарника /usr/sbin/nginx-debug В configure arguments при сборке задается --sbin-path=/usr/sbin/nginx было бы хорошо добавить еще один аргумент, --sbin-debug-path=/usr/sbin/nginx-debug по умолчанию, если явно не задано - добавляется подстрока "-debug" к значению аргумента --sbin-path в таком случае изменение логики работы nginx будет минимальным в процессе online upgrade: если pid-файл nginx имеет 1 бит в поле права на запись для группы, тогда запустить бинарный файл, который задан в --sbin-debug-path если 0 бит - запустить бинарный файл, который задан в --sbin-path скрипт для выполнения команды service nginx upgrade-to-debug файла /usr/libexec/initscripts/legacy-actions/nginx/upgrade-to-debug =================================== #!/usr/bin/sh # # Legacy action script for "service nginx upgrade-to-debug" pidfile=`/usr/bin/systemctl show -p PIDFile nginx.service | sed 's/^PIDFile=//' | tr ' ' '\n'` chmod --quiet g+w ${pidfile} exec service nginx upgrade =================================== скрипт для выполнения команды service nginx upgrade-to-release файла /usr/libexec/initscripts/legacy-actions/nginx/upgrade-to-release =================================== #!/usr/bin/sh # # Legacy action script for "service nginx upgrade-to-release" pidfile=`/usr/bin/systemctl show -p PIDFile nginx.service | sed 's/^PIDFile=//' | tr ' ' '\n'` chmod --quiet g-w ${pidfile} exec service nginx upgrade =================================== существующий скрипт для выполнения команды service nginx upgrade файл /usr/libexec/initscripts/legacy-actions/nginx/upgrade - остается без изменений. и тогда - в любой момент времени можно будет сделать on the fly переключение между release и debug версиями nginx без потери клиентских соединений, всего одной командой. причем, этот метод будет работать на любой версии Linux и тогда можно будет обойтись всего одним unit-файлом nginx.service и можно будет полностью отказаться от unit-файла nginx-debug.service такой вариант решения будет иметь максимальную надежность, потому что не будут использоваться симлинки и alternatives будет требовать минимальное количество изменений в коде nginx и при этом - будет максимально удобным для пользователей nginx, потому что позволит переключаться между release и debug версями nginx без потери соединений выполнив всего лишь одну команду. -- Best regards, Gena From chipitsine на gmail.com Tue Sep 17 08:20:32 2024 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 17 Sep 2024 10:20:32 +0200 Subject: /usr/sbin/nginx alternatives In-Reply-To: References: <16ead54d-9392-4ac4-8a2a-5b4f5396739e@csdoc.com> <1818b389-1ac8-4e1a-94f6-443aefda3dcd@nginx.com> Message-ID: вт, 17 сент. 2024 г. в 10:10, Hennadii Makhomed : > On 16.09.2024 21:06, Konstantin Pavlov wrote: > > >>>> а как Вам идея вместо двух unit-файлов nginx.service > >>>> и nginx-debug.service использовать только один unit-файл > >>>> nginx.service и использовать alternatives для переключения > >>>> бинарника /usr/sbin/nginx между release и debug версиями ? > >>> > >>> Мы поддерживаем несколько разных ОС в наших пакетах на nginx.org (и > >>> еще больше - для коммерческой версии), и не во всех них есть > >>> поддержка alternatives. По этой причине не хотелось бы это > >>> реализовывать для какой-то одной конкретной ОС если нельзя сделать > >>> везде одинаково. > >> > >> это можно сделать везде одинаково, на всех Linux/UNIX системах. > >> > >> если же переключение между release / debug версями происходит с помощью > >> двух отдельных сервисов nginx.service и nginx-debug.service, то в таком > >> случае переключение между ними происходит с потерей соединений клиентов > > > > Делать столько уникальной логики, опять же уходя от привычной многим и > > документированной системы alternatives, для очень редкой ситуации когда > > нужно запустить дебаг-версию? > > Моя идея с симлинком /usr/sbin/nginx который указывает на release > или debug версию бинарника nginx - это плохая идея еще и потому, > что по стандарту FHS - "/usr should be shareable between various > FHS-compliant hosts and must not be written to. Any information > that is host-specific or varies with time is stored elsewhere". > > alternatives использовать также нельзя, потому что > не во всех ОС есть поддержка alternatives и потому что > использование системы alternatives увеличивает хрупкость. > > > Кажется, гораздо проще, если уж нельзя воспроизвести проблему на стенде, > > сделать временно: > > > > mv /usr/sbin/nginx /usr/sbin/nginx.bak > > > > mv /usr/sbin/nginx-debug /usr/sbin/nginx > > > > service nginx upgrade > > > > А что делать в том случае, когда файловая система /usr смонтирована > в режиме read-only и не удается воспроизвести проблему на стенде? > если вы попали в такую ситуацию - стоит задуматься, зачем вы в нее попали. желание переименовывать файлы и файловая система, смонтированная в режиме ead-only - как бы немного друг другу противоречат for the sake of simplicity - не надо пытаться решать задачу переименования файла на read-only системе, пожалуйста > > Да и в том случае, когда файловая система /usr доступна на запись - > переименование исполняемых файлов - это неудобно как для самих > пользователей, так и для инженеров технической поддержки, > которые будут общаться с пользователями и помогать им. > > Какое решение этой задачи будет более оптимальным? > > service nginx upgrade > > service nginx upgrade-to-debug > > service nginx upgrade-to-release > > Как технически это реализовать? > > Upgrading Executable on the Fly > https://nginx.org/en/docs/control.html#upgrade > > Когда старый master-процесс nginx делает этот шаг: "then starts > a new executable file that in turn starts new worker processes" > необходимо, он мог понимать, какой именно бинарник ему следует > запустить на выполнение - release или debug вариант бинарника. > > Для этого - надо передать работающему master-процессу nginx > в процессе online upgrade дополнительно один бит информации. > > когда передается 0 бит - тогда запускается /usr/sbin/nginx > когда передается 1 бит - тогда запускается /usr/sbin/nginx-debug > > Каким образом это можно сделать? С помощью pid-файла. > > В нормальном режиме работы pid-файл > имеет владельца root:root и права доступа 0644 (-rw-r--r--) > - в таком случае master-процесс nginx делает online upgrade > на обычную, release-версию бинарника /usr/sbin/nginx > > Если же в момент получения master-процессом nginx сигнала USR2 > на его pid-файл установлены права доступа 0664 (-rw-rw-r--) > - в таком случае master-процесс nginx делает online upgrade > на отладочную, debug-версию бинарника /usr/sbin/nginx-debug > > В configure arguments при сборке задается > > --sbin-path=/usr/sbin/nginx > > было бы хорошо добавить еще один аргумент, > > --sbin-debug-path=/usr/sbin/nginx-debug > > по умолчанию, если явно не задано - добавляется > подстрока "-debug" к значению аргумента --sbin-path > > в таком случае изменение логики работы nginx > будет минимальным в процессе online upgrade: > > если pid-файл nginx имеет 1 бит в поле права на запись для группы, > тогда запустить бинарный файл, который задан в --sbin-debug-path > если 0 бит - запустить бинарный файл, который задан в --sbin-path > > скрипт для выполнения команды service nginx upgrade-to-debug > > файла /usr/libexec/initscripts/legacy-actions/nginx/upgrade-to-debug > > =================================== > > #!/usr/bin/sh > # > # Legacy action script for "service nginx upgrade-to-debug" > > pidfile=`/usr/bin/systemctl show -p PIDFile nginx.service | sed > 's/^PIDFile=//' | tr ' ' '\n'` > > chmod --quiet g+w ${pidfile} > > exec service nginx upgrade > > =================================== > > скрипт для выполнения команды service nginx upgrade-to-release > > файла /usr/libexec/initscripts/legacy-actions/nginx/upgrade-to-release > > =================================== > > #!/usr/bin/sh > # > # Legacy action script for "service nginx upgrade-to-release" > > pidfile=`/usr/bin/systemctl show -p PIDFile nginx.service | sed > 's/^PIDFile=//' | tr ' ' '\n'` > > chmod --quiet g-w ${pidfile} > > exec service nginx upgrade > > =================================== > > существующий скрипт для выполнения команды service nginx upgrade > файл /usr/libexec/initscripts/legacy-actions/nginx/upgrade > - остается без изменений. > > и тогда - в любой момент времени можно будет сделать > on the fly переключение между release и debug версиями > nginx без потери клиентских соединений, всего одной командой. > > причем, этот метод будет работать на любой версии Linux > > и тогда можно будет обойтись всего одним unit-файлом nginx.service > и можно будет полностью отказаться от unit-файла nginx-debug.service > > такой вариант решения будет иметь максимальную надежность, > потому что не будут использоваться симлинки и alternatives > > будет требовать минимальное количество изменений в коде nginx > > и при этом - будет максимально удобным для пользователей nginx, > потому что позволит переключаться между release и debug версями > nginx без потери соединений выполнив всего лишь одну команду. > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Tue Sep 17 08:45:13 2024 From: gmm на csdoc.com (Hennadii Makhomed) Date: Tue, 17 Sep 2024 10:45:13 +0200 Subject: /usr/sbin/nginx alternatives In-Reply-To: References: <16ead54d-9392-4ac4-8a2a-5b4f5396739e@csdoc.com> <1818b389-1ac8-4e1a-94f6-443aefda3dcd@nginx.com> Message-ID: <0aa6f41d-a267-48bf-aa66-502aa41472bb@csdoc.com> On 17.09.2024 10:20, Илья Шипицин wrote: >>> Кажется, гораздо проще, если уж нельзя воспроизвести проблему на стенде, >>> сделать временно: >>> >>> mv /usr/sbin/nginx /usr/sbin/nginx.bak >>> >>> mv /usr/sbin/nginx-debug /usr/sbin/nginx >>> >>> service nginx upgrade >> >> А что делать в том случае, когда файловая система /usr смонтирована >> в режиме read-only и не удается воспроизвести проблему на стенде? > > если вы попали в такую ситуацию - стоит задуматься, зачем вы в нее попали. > желание переименовывать файлы и файловая система, смонтированная в режиме > read-only - как бы немного друг другу противоречат > > for the sake of simplicity - не надо пытаться решать задачу переименования > файла на read-only системе, пожалуйста задача, которую я решаю, формулируется таким образом: сделать переключение между release и debug версиями nginx в режиме on the fly и без потери клиентских соединений, способом, который будет работать всегда и который будет максимально удобным для пользоватлей nginx и инженеров технической поддержки, которые общаются с пользователями коммерческих версий nginx-plus (США) и Angie PRO (Россия). У меня нет задачи переименовывать файлы на read-only системе см. также Феномен XY: как избежать «неправильных» проблем https://habr.com/ru/companies/dododev/articles/467047/ не надо пытаться разговаривать со мной менторским тоном и хамить мне, иначе у меня не будет желания вам отвечать. кроме того, было бы очень желательно не увлекаться overquoting`ом, потому что подобным образом - вы демонстрируете свое презрение и свое высокомерие не только по отношению ко мне, но и по отношению ко всем остальным участникам и читателям этого списка рассылки. >> Какое решение этой задачи будет более оптимальным? >> >> service nginx upgrade >> >> service nginx upgrade-to-debug >> >> service nginx upgrade-to-release -- Best regards, Gena From chipitsine на gmail.com Tue Sep 17 08:54:57 2024 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 17 Sep 2024 10:54:57 +0200 Subject: /usr/sbin/nginx alternatives In-Reply-To: <0aa6f41d-a267-48bf-aa66-502aa41472bb@csdoc.com> References: <16ead54d-9392-4ac4-8a2a-5b4f5396739e@csdoc.com> <1818b389-1ac8-4e1a-94f6-443aefda3dcd@nginx.com> <0aa6f41d-a267-48bf-aa66-502aa41472bb@csdoc.com> Message-ID: вт, 17 сент. 2024 г. в 10:45, Hennadii Makhomed : > On 17.09.2024 10:20, Илья Шипицин wrote: > > >>> Кажется, гораздо проще, если уж нельзя воспроизвести проблему на > стенде, > >>> сделать временно: > >>> > >>> mv /usr/sbin/nginx /usr/sbin/nginx.bak > >>> > >>> mv /usr/sbin/nginx-debug /usr/sbin/nginx > >>> > >>> service nginx upgrade > >> > >> А что делать в том случае, когда файловая система /usr смонтирована > >> в режиме read-only и не удается воспроизвести проблему на стенде? > > > > если вы попали в такую ситуацию - стоит задуматься, зачем вы в нее > попали. > > желание переименовывать файлы и файловая система, смонтированная в режиме > > read-only - как бы немного друг другу противоречат > > > > for the sake of simplicity - не надо пытаться решать задачу > переименования > > файла на read-only системе, пожалуйста > > задача, которую я решаю, формулируется таким образом: > > сделать переключение между release и debug версиями nginx > в режиме on the fly и без потери клиентских соединений, > способом, который будет работать всегда и который будет > максимально удобным для пользоватлей nginx и инженеров > технической поддержки, которые общаются с пользователями > коммерческих версий nginx-plus (США) и Angie PRO (Россия). > отлично. наверное, в рамках платной поддержки есть какая-то выгода вышеупомянутых компаний. предлагаю сделать эту задачу их головной болью > > У меня нет задачи переименовывать файлы на read-only системе > см. также Феномен XY: как избежать «неправильных» проблем > https://habr.com/ru/companies/dododev/articles/467047/ > > не надо пытаться разговаривать со мной менторским тоном > и хамить мне, иначе у меня не будет желания вам отвечать. > да, в общем, нестрашно. ваше желаниие или нежелание отвечать - ваше добровольное дело. переживу. > > кроме того, было бы очень желательно не увлекаться overquoting`ом, > потому что подобным образом - вы демонстрируете свое презрение и > свое высокомерие не только по отношению ко мне, но и по отношению > ко всем остальным участникам и читателям этого списка рассылки. > я просто в гмейле отвечаю. если он как-то не так форматирует, тут не мое презрение, а разработки гмейла. > > >> Какое решение этой задачи будет более оптимальным? > >> > >> service nginx upgrade > >> > >> service nginx upgrade-to-debug > >> > >> service nginx upgrade-to-release > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Tue Sep 17 11:30:27 2024 From: gmm на csdoc.com (Hennadii Makhomed) Date: Tue, 17 Sep 2024 13:30:27 +0200 Subject: /usr/sbin/nginx alternatives In-Reply-To: References: <16ead54d-9392-4ac4-8a2a-5b4f5396739e@csdoc.com> <1818b389-1ac8-4e1a-94f6-443aefda3dcd@nginx.com> <0aa6f41d-a267-48bf-aa66-502aa41472bb@csdoc.com> Message-ID: On 17.09.2024 10:54, Илья Шипицин wrote: >>> если вы попали в такую ситуацию - стоит задуматься, >>> зачем вы в нее попали.желание переименовывать файлы и файловая система, >>> смонтированная в режиме read-only - как бы немного друг другу противоречат >>> >>> for the sake of simplicity - не надо пытаться решать задачу >>> переименования файла на read-only системе, пожалуйста >> >> задача, которую я решаю, формулируется таким образом: >> >> сделать переключение между release и debug версиями nginx >> в режиме on the fly и без потери клиентских соединений, >> способом, который будет работать всегда и который будет >> максимально удобным для пользоватлей nginx и инженеров >> технической поддержки, которые общаются с пользователями >> коммерческих версий nginx-plus (США) и Angie PRO (Россия). > > отлично. наверное, в рамках платной поддержки есть какая-то выгода > вышеупомянутых компаний. предлагаю сделать эту задачу их головной болью это очень глупое предложение, потому что если эта функциональность будет добавлена только в коммерческие версии nginx-plus и Angie PRO - тогда у вас и у меня, как у пользователей open source версии nginx не будет такой возможности - удобно переключаться on the fly без потери соединений между release и debug версиями nginx. вам это не нужно - не пользуйтесь, вас же к этому никто не принуждает. если ничем не можете или не хотите мне помочь - то хотя бы не мешайте. ведь и для них же тоже лучше будет сначала "потренироваться на кошках", то есть на пользователях open source версии nginx, прежде чем добавлять эту новую функциональность в коммерческие версии nginx-plus и Angie PRO >> не надо пытаться разговаривать со мной менторским тоном >> и хамить мне, иначе у меня не будет желания вам отвечать. > > да, в общем, нестрашно. ваше желаниие или нежелание отвечать > - ваше добровольное дело. переживу. вам и не должно быть страшно, потому что я же вас не пытаюсь напугать. просто попросил не хамить и не разговаривать со мной менторским тоном. предполагалось, что если вы мне пишете какое-то сообщение - то вы это же делаете с целью поулучить от меня какой-то ответ, а не с целью самоутвердиться на мой счет с помощью флуда и флейма, как это было недавно, в вашем сообщении 22:30:34 от 15 Sep 2024 UTC >> кроме того, было бы очень желательно не увлекаться overquoting`ом, >> потому что подобным образом - вы демонстрируете свое презрение и >> свое высокомерие не только по отношению ко мне, но и по отношению >> ко всем остальным участникам и читателям этого списка рассылки. > > я просто в гмейле отвечаю. если он как-то не так форматирует, > тут не мое презрение, а разработки гмейла. я говорил не про форматирование сообщений, а про избыточное цитирование. вы сейчас хотите сказать, что смысл слова overquoting вам не понятен? в таком случае - поясню вам более подробно причину этой моей просьбы. https://ru.wikipedia.org/wiki/Оверквотинг Оверкво́тинг (англ. overquoting) — одна из проблем при написании текста в телекоммуникационных сетях, при которой происходит избыточное цитирование источника поста. Под оверкво́тинг понимается неумеренное, избыточное цитирование постов на сетевых форумах, e-mail, новостной группе или эхоконференции когда текст автора намного меньше, чем объем цитат, что доставляет неудобство для читателя и заставляет пролистывать цитаты. В сети уже сложилась определённая культура цитирования. Умелое цитирование позволяет удерживать нить беседы и всегда легко продолжить её, даже если прошло длительное время. На форумах оверквотинг вынуждает читателей использовать скролл, что вызывает раздражение, считается признаком невоспитанности. -- Best regards, Gena From pluknet на nginx.com Tue Sep 17 13:52:56 2024 From: pluknet на nginx.com (Sergey Kandaurov) Date: Tue, 17 Sep 2024 17:52:56 +0400 Subject: =?utf-8?B?UmU6INCi0LXRgdGC0Ys6INC/0YDQvtCy0LXRgNC60LAgZXhwZWN0?= =?utf-8?B?ZWRfdGVzdHMg0LIg0LTQtdGB0YLRgNGD0LrRgtC+0YDQtQ==?= In-Reply-To: <158431726059269@mail.yandex.ru> References: <158431726059269@mail.yandex.ru> Message-ID: <612F1496-54B1-4DB7-8109-EB70E1C527A2@nginx.com> > On 11 Sep 2024, at 17:08, Оксана Деева wrote: > > Здравствуйте, > Столкнулась с такой проблемой: если в тесте plan() стоит после run() и nginx по какой-то причине не может стартовать, то деструктор нормально не отрабатывает - он запускается, но expected_tests везде по нулям и из-за этого мы не проверяем логи на ошибки/алерты (https://github.com/nginx/nginx-tests/blob/master/lib/Test/Nginx.pm#L67 и https://github.com/nginx/nginx-tests/blob/master/lib/Test/Nginx.pm#L85). > При этом, если просто в тесте переместить вызов plan() в начало, то все нормально отрабатывает, до всех проверок мы доходим - expected_tests не равен нулю, даже если nginx не смог стартануть (и это ожидаемое поведение). > Вопрос: зачем нужна проверка на expected_tests? Если был skip_all, то до деструктора и этой проверки мы вообще не доходим, если все тесты заскипались, то expected_tests не будет нулем. Больше никаких сценариев придумать не могу, и хотела бы убрать эту проверку, но интересно было бы услышать мнение автора. IIRC, исходно проверка была добавлена для skip_all, который стоит после run(), как, например, в upstream_ip_hash.t: $t->run(); plan(skip_all => ..); $t->plan(N); Иначе, при безусловном запуске, тест выполнится с нулевым планом и математика не сойдётся. -- Sergey Kandaurov From o.deeva на wbsrv.ru Tue Sep 17 15:50:23 2024 From: o.deeva на wbsrv.ru (=?utf-8?B?0J7QutGB0LDQvdCwINCU0LXQtdCy0LA=?=) Date: Tue, 17 Sep 2024 18:50:23 +0300 Subject: =?utf-8?B?UmU6INCi0LXRgdGC0Ys6INC/0YDQvtCy0LXRgNC60LAgZXhwZWN0ZWRfdGVzdHMg0LIg0LTQtdGB0YI=?= =?utf-8?B?0YDRg9C60YLQvtGA0LU=?= In-Reply-To: <612F1496-54B1-4DB7-8109-EB70E1C527A2@nginx.com> References: <158431726059269@mail.yandex.ru> <612F1496-54B1-4DB7-8109-EB70E1C527A2@nginx.com> Message-ID: <109561726584602@mail.yandex.ru> Вложение в формате HTML было извлечено… URL: From 440hz на mail.ru Wed Sep 18 12:03:19 2024 From: 440hz на mail.ru (=?UTF-8?B?0JDQvdC00YDQtdC5INCT0L7Qu9GD0LHQtdCy?=) Date: Wed, 18 Sep 2024 15:03:19 +0300 Subject: =?UTF-8?B?0JLQvdC10LTRgNC10L3QuNC1IEVhcmx5IEhpbnRz?= Message-ID: <1726660999.588314434@f320.i.mail.ru> Планируется ли внедрение фичи Early Hints в nginx и если нет, то очень хочется узнать почему.   есть модуль 8-ми летней давности и все...   интересует в первую очередь проксирование proxy_pass, http/2, http/3     С уважением, Андрей Голубев 440hz на mail.ru ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: