РЕД ОС 8.0: тестируем как замену CentOS 8 на серверах объекта КИИ

В начале сентября «РЕД СОФТ» анонсировал выпуск РЕД ОС 8.0 - дистрибутива, заявленного как бинарно совместимый с RHEL 8 и ориентированного в том числе на объекты КИИ. Учитывая, что у одного из наших клиентов несколько серверов до сих пор работают на CentOS 8 (которая формально EOL с конца 2021-го, но «работает же»), повод был конкретный: посмотреть, насколько реально использовать РЕД ОС 8.0 как замену без переписывания инфраструктуры.

Сервера у клиента - типичный набор для промышленного предприятия из реестра КИИ: несколько прикладных серверов под внутренние сервисы, пара серверов БД (PostgreSQL), мониторинг на Zabbix. Всё это изначально ставилось на CentOS 8 ещё когда планировалось долгосрочное использование. После EOL ехали на заморозке: обновления не прилетали, уязвимости закрывали вручную там, где удавалось.

Что заявлено в 8.0

РЕД ОС 8.0 строится поверх того же upstream, что и RHEL 8, - это dnf/RPM как пакетный менеджер, SELinux по умолчанию в enforcing, systemd, NetworkManager. Официально заявлена бинарная совместимость с RHEL 8 на уровне пакетов - то есть RPM-пакеты, собранные под RHEL 8, должны устанавливаться и работать. Дистрибутив включён в реестр Минцифры и имеет сертификат ФСТЭК, что для объектов КИИ закрывает вопрос с регуляторными требованиями к используемому ПО.

Тест первый: RPM-пакеты

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

Большинство стандартных пакетов встали без проблем. PostgreSQL 14 из официального репозитория PGDG для RHEL 8 - установился, инициализировался, запустился. Zabbix-агент из официального репозитория Zabbix для RHEL 8 - аналогично. Здесь бинарная совместимость работает как обещано.

Сложнее с вендорскими RPM. Один из пакетов, поставляемых производителем промышленного ПО, внутри зависит от конкретной версии библиотеки, которая в РЕД ОС 8.0 присутствует, но собрана с другим набором флагов. Пакет встал, но при запуске сервиса - segfault. Разобрались: проблема в том, что вендор собирал пакет под конкретную сборку RHEL 8.6, и runtime-поведение при линковке отличается. Это не уникальная проблема РЕД ОС - то же самое случалось бы на AlmaLinux или Rocky при несовпадении минорной версии RHEL. Но нужно понимать, что «совместимость с RHEL 8» - это не гарантия совместимости с каждым вендорским RPM, собранным когда-то под конкретный RHEL 8.x.

Тест второй: SELinux-политики

CentOS 8 - это тоже SELinux enforcing по умолчанию, так что политики у клиента уже были настроены, хотя и не без костылей: за годы работы накопился набор audit2allow-сгенерированных модулей, которые просто «глушат» аудит по конкретным паттернам. Классика.

При переносе кастомных SELinux-модулей из CentOS 8 на РЕД ОС 8.0 большинство импортировалось без изменений через semodule -i. Два модуля потребовали пересборки: политика изменилась в достаточной мере, что типы объявленные в модуле конфликтовали с базовой политикой РЕД ОС 8.0. Не трагедия - пересобрали через checkmodule и semodule_package, заняло полчаса. Но если у кого-то есть большой зоопарк кастомных SELinux-модулей, лучше закладывать время на ревизию.

Базовая политика по умолчанию в РЕД ОС 8.0 соответствует политике RHEL 8 с небольшими дополнениями вендора. На глаз - ничего неожиданного, привычные типы на месте, auditd пишет то что ожидается.

Тест третий: механизм подписки на обновления

Это то, о чём меньше всего говорят, но что на практике критически важно для КИИ: как получать патчи безопасности и как убедиться, что они действительно прилетают.

В RHEL 8 это subscription-manager со своей экосистемой. В РЕД ОС 8.0 - собственный механизм подписки через личный кабинет на портале «РЕД СОФТ». Репозитории подключаются через специальный пакет redos-release, который прописывает нужные .repo-файлы и сертификаты для аутентификации на зеркалах.

На практике: регистрация в личном кабинете, получение подписки, подключение сервера - сделали за 20 минут. dnf update отработал корректно, обновления прилетели. Один момент важен для изолированных контуров КИИ: если сеть закрытая - а у данного клиента это так - нужно либо организовывать репозиторий-зеркало внутри контура, либо использовать offline-обновления через rpm-пакеты. Документация на этот счёт у «РЕД СОФТ» есть, но немного лаконичная - пришлось уточнять у поддержки детали по настройке локального зеркала. Поддержка ответила оперативно, это честно надо отметить.

Итог по состоянию на сейчас

Тестовый стенд с РЕД ОС 8.0 поднят и работает. Стандартный стек (PostgreSQL, Zabbix, базовые сервисы) - всё встало нормально. Проблема с одним вендорским RPM остаётся открытой - ждём от производителя пересборки под актуальный upstream. SELinux-политики перенесены с минимальными правками.

Для принятия решения о переводе продуктивных серверов нам нужно ещё закрыть вопрос с тем самым вендорским пакетом и прогнать тест производительности PostgreSQL на реальных нагрузках - это следующий шаг. Пока картина такая: как замена CentOS 8 для типового серверного стека - вполне рабочий вариант, managed-сопровождение здесь помогает не потерять нить между тестовым стендом и продуктивом. Вендорские зависимости - проверять отдельно и заранее.