/usr/sbin/nginx alternatives

Вс Сен 15 21:16:00 UTC 2024

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