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: