Почему мы не строим RISH на Ubuntu

Серверу часто нужны несколько версий PHP одновременно: один сайт живет на старой ветке, другой уже требует новую, третий нужно временно перенести без немедленной модернизации.

В RHEL-family эта задача решается через Remi repository. Для RISH это удобная и понятная модель: PHP устанавливается из RPM-репозитория, разные версии живут рядом, а PHP-FPM pools каждого пользователя находятся в предсказуемых местах вроде /etc/opt/remi/phpXX/php-fpm.d/<user>.conf.

В Ubuntu штатные репозитории привязаны к версии дистрибутива и не закрывают нормальный hosting-сценарий с несколькими актуальными PHP-ветками. На практике такой сервер почти неизбежно упирается в ppa:ondrej/php.

В июле 2024 года Ondřej Surý, мейнтейнер ppa:ondrej/php и packages.sury.org, публично объявил, что блокирует российские IP-адреса на своей пакетной инфраструктуре packages.sury.org.

В issue Geoblocking Russia он прямо написал, что начал блокировать загрузку пакетов с packages.sury.org из России. Отдельно он указал, что технически не может сделать то же самое для Launchpad PPA, но сделал бы, если бы мог.

Та же позиция была опубликована в Mastodon-посте DEB.SURY.ORG от 3 июля 2024 года: геоблокировка российских IP для packages.sury.org, невозможность применить ее к Launchpad PPA и прямое заявление, что для Launchpad он сделал бы то же самое при наличии такой возможности.

Для RISH это красная линия. Мы не можем строить установщик веб-сервера поверх PHP-экосистемы, где доступ для российских пользователей уже становился политическим решением одного человека. Даже если сам ppa:ondrej/php на Launchpad технически остается доступен, мейнтейнер публично заявил свое намерение: если бы он мог заблокировать PPA для российских IP, он бы это сделал.

Это превращает Ubuntu-сценарий PHP из технической зависимости в политический риск. А политический риск в установщике сервера означает простую вещь: сегодня установка работает, завтра не работает, и пользователь RISH ничего не может с этим сделать.

В RHEL-family RISH использует Remi repository. Это тоже внешний репозиторий. Оба источника внешние по отношению к базовому дистрибутиву.

Разница в риске. Remi давно стал привычной частью RPM-экосистемы для PHP и хорошо ложится на архитектуру RISH. Мы не видим публичной истории, где Remi объявлял бы политическую блокировку российских IP-адресов. Вокруг Ondřej Surý такая история есть, и она напрямую касается доступности PHP-пакетов.

Ubuntu Server давно перестал быть просто «Debian, но удобнее». Canonical активно продвигает Snap, и на сервере это часто вызывает раздражение у администраторов.

Snap приносит отдельный snapd, свою модель обновлений, свои mount namespaces, свою инфраструктуру Snap Store и свои правила изоляции. Для десктопа или IoT это может быть полезно. Для управляемого веб-сервера это лишний слой, который нужно понимать, учитывать, отключать или обходить.

RISH нужен сервер, где пакет — это системный пакет, сервис — это systemd unit, конфиг лежит там, где его ожидает администратор, а обновления идут через понятный пакетный менеджер. Snap делает эту картину более мутной.

В Ubuntu есть несколько фоновых механизмов, которые управляют обновлениями без прямого участия администратора.

unattended-upgrades может автоматически устанавливать обновления безопасности. Это полезно, когда сервер никто не сопровождает вручную, но для управляемого веб-сервера означает, что пакеты могут измениться без явного действия администратора. Причем некоторые пакеты могут восстанавливать настройки по умолчанию.

apt-daily регулярно запускает служебные операции для apt: обновляет данные пакетного менеджера и проверяет доступные пакеты. Из-за этого администратор может столкнуться с lock на apt, хотя сам ничего не запускал.

apt-daily-upgrade отвечает за автоматическое применение обновлений, в том числе через unattended-upgrades. Это еще один фоновый процесс, который может конкурировать с ручной установкой или обновлением пакетов.

Phased updates — это поэтапная раскатка обновлений. Canonical может отдавать новую версию пакета не всем серверам сразу, а постепенно. С точки зрения дистрибутива это снижает риск массовых поломок, но для администратора означает, что две одинаковые машины могут видеть разные версии пакетов или разное поведение apt upgrade.

Все эти механизмы имеют разумные цели: безопасность, снижение риска массовых поломок, более аккуратная доставка обновлений. Но для администраторов, которые бы поставили RISH на Ubuntu они создают состояние неопределенности. Нам важно, чтобы администратор понимал, когда обновляется пакетная база, кто держит lock на пакетный менеджер и почему конкретный пакет доступен или недоступен именно сейчас.

Netplan и cloud-init сами по себе не являются злом. В облаках и автоматической первичной настройке они бывают полезны. Проблема в другом: Ubuntu добавляет все больше промежуточных механизмов между администратором и реальным состоянием системы.

Сеть описывается YAML-конфигурацией Netplan, которая дальше генерирует настройки для NetworkManager или systemd-networkd. Первичная настройка может проходить через cloud-init, который умеет менять hostname, сеть, пользователей, SSH-ключи и выполнять скрипты при загрузке.

Для RISH это означает больше потенциальных источников неожиданного поведения. Сервер может выглядеть настроенным, но часть состояния была создана или изменена не тем инструментом, с которым сейчас работает администратор.

У Ubuntu есть коммерческая экосистема Canonical: Ubuntu Pro, ESM, Livepatch, Landscape, Snap Store. В этом нет ничего удивительного: у любой большой серверной платформы есть коммерческая сторона.

Проблема в том, что Ubuntu все чаще ощущается не как обычная базовая ОС, а как вход в продуктовый контур Canonical. Система предлагает, напоминает, подключает дополнительные уровни поддержки и сервисов. Это лишнее для обычного управления сервером.

RISH не нужен сервер, который постоянно тянет за собой продуктовую повестку поставщика дистрибутива. RISH нужен предсказуемый Linux, на котором можно строить свою серверную модель.

Ubuntu Server не является плохой системой. Его широко используют, он хорошо документирован и часто быстро дает рабочий результат. Но у многих системных администраторов к нему накопилось раздражение.

Причина простая: Ubuntu слишком часто делает по-своему. Snap вместо обычных пакетов. Netplan поверх привычной сетевой настройки. cloud-init, который может менять состояние системы при загрузке. Автоматические обновления и phased updates. Ubuntu Pro и ESM вокруг обычного apt. А для нормального PHP stack — фактическая зависимость от экосистемы Ondřej Surý.

Каждая из этих технологий может быть оправдана отдельно. Вместе они создают серверную среду, которая слишком часто ведет себя не так, как ожидает администратор. Для RISH это плохая основа.

Мы не выбираем RHEL-family потому, что Ubuntu нельзя использовать на сервере. Можно. Многие используют. Но RISH — это не абстрактный набор shell-скриптов, а управляемая серверная модель.

Для этой модели Ubuntu приносит слишком много лишнего: Snap, Canonical-специфику, Netplan, cloud-init, phased updates, автоматические пакетные процессы, Ubuntu Pro/ESM и критическую зависимость от PHP-экосистемы Ondřej Surý для актуального PHP.

История с геоблокировкой российских IP на packages.sury.org окончательно показывает, почему такая зависимость неприемлема. Если ключевой PHP-источник может стать политическим фильтром, RISH не должен строиться на этой базе.

RISH нужен скучный, предсказуемый, управляемый Linux. Поэтому мы выбираем RHEL-family.