РЕД ОС на сервере: чем она отличается от AlmaLinux на практике

MAATRIX

Если вам поручили развернуть сервер на РЕД ОС, а весь предыдущий опыт — это CentOS, AlmaLinux или Rocky Linux, первая реакция обычно спокойная: «rpm-based, дистрибутив семейства RHEL, разберусь по накатанной». И это по большей части правда — команды знакомые, файловая структура та же, systemd тот же. Но именно на стыке «почти то же самое» и «на самом деле другое» уходит время в первую неделю: не найденный в репозитории пакет, непонятная логика обновлений, вопрос «а кому вообще звонить, если что-то сломалось». Разберём по пунктам, на что реально обращать внимание при переходе, без домыслов о номерах версий и датах — только то, что можно проверить на живой системе.

Родословная: что общего с AlmaLinux, а что нет

РЕД ОС — российский дистрибутив, построенный на RHEL-совместимой основе: тот же формат пакетов rpm, тот же принцип мажорных релизов, что и у всей семьи CentOS/AlmaLinux/Rocky Linux, тот же набор системных инструментов — systemd, SELinux, firewalld, NetworkManager. Для админа, который годами работал с этим стеком, окружение выглядит узнаваемым буквально с первой команды.

Но родство на уровне пакетного формата — это не то же самое, что родство на уровне модели дистрибутива. AlmaLinux — это community-проект (поддерживается независимым фондом), цель которого — бесплатная и максимально точная пересборка исходников RHEL, «один в один» по духу с тем, чем раньше был классический CentOS. Подробнее о том, как устроена эта ниша и чем CentOS Stream отличается от полноценного клона RHEL, можно почитать в статье CentOS или AlmaLinux: что выбрать для сервера.

РЕД ОС — коммерческий продукт российского вендора (компания «РЕД СОФТ»), ориентированный в первую очередь на российский рынок, со своей политикой релизов, собственной сборкой пакетов и отдельной сертификацией. Это не «ещё один бесплатный клон RHEL» — это дистрибутив с лицензионной и вендорской моделью, где за системой стоит конкретная компания с контрактными обязательствами, а не открытое комьюнити. Переключаясь с AlmaLinux на РЕД ОС, вы меняете не только пакетную базу, но и саму модель отношений с поставщиком системы — это стоит держать в голове с первого дня, а не узнавать постфактум при инциденте.

Пакетный менеджер: rpm/yum/dnf — что совместимо

Хорошая новость: базовый инструментарий работает так, как вы привыкли. dnf install, dnf update, dnf repolist, rpm -qa, rpm -qi имя-пакета, systemctl — всё это ведёт себя предсказуемо, потому что формат пакетов и логика пакетного менеджера унаследованы от той же RHEL-совместимой базы. Скрипты и плейбуки, которые дергают dnf/rpm как таковые (а не конкретные имена пакетов или репозиториев), в большинстве случаев переносятся без переделки.

Первое, что стоит сделать на новом сервере — не поверить на слово, а проверить, с чем вы имеете дело:

cat /etc/os-release
cat /etc/redhat-release 2>/dev/null
rpm -q --whatprovides /etc/redhat-release
uname -r
dnf --version

Дальше — обязательно посмотреть, что реально подключено как источники пакетов, и не полагаться на память о том, «как это было на AlmaLinux»:

dnf repolist -v
dnf repolist --all
rpm -qa gpg-pubkey --qf '%{name}-%{version}-%{release} %{summary}\n'

Последняя команда покажет, какие GPG-ключи репозиториев уже импортированы в систему — это полезно сверить с тем, что вы ожидаете увидеть, особенно если сервер настраивался не вами. Ключевой практический момент: сам факт, что команда одинаковая, не гарантирует одинакового результата — набор подключённых репозиториев и то, что в них лежит, будет другим, и это следующий пункт.

Репозитории: чем реально отличается от AlmaLinux/EPEL

На AlmaLinux (и вообще во всей экосистеме RHEL-клонов) вы привыкли к паре: базовые репозитории, максимально близкие к структуре самого RHEL, плюс EPEL — огромный community-репозиторий дополнительных пакетов, который де-факто стал стандартом для установки всего, чего нет «из коробки» — от htop и certbot до нишевых библиотек.

На РЕД ОС репозитории — собственные, поддерживаемые вендором. Набор пакетов в них формируется не как зеркало апстрима, а по логике вендора: что протестировано, сертифицировано и признано нужным для целевой аудитории продукта (в основном — государственные и регулируемые организации). Это не значит, что репозиториев «мало» в абсолютном смысле — но набор точно не идентичен тому, что вы найдёте в base+EPEL на AlmaLinux, и рассчитывать на автоматическое наличие привычного пакета не стоит.

Практический вывод простой: прежде чем переносить стек приложений, пройдитесь по каждому пакету, который ставит ваш Ansible-плейбук или Dockerfile, командой dnf search / dnf list <пакет> на самой РЕД ОС, а не полагайтесь на то, что «на AlmaLinux же было». Для пакетов, которых нет в штатных репозиториях, часто остаётся рабочий путь — подключение стороннего репозитория конкретного вендора приложения (например, официальный repo Docker CE или PostgreSQL PGDG) тем же способом, что и на любом RHEL-совместимом дистрибутиве: файл .repo в /etc/yum.repos.d/ и импорт GPG-ключа. Технически это работает так же, как на AlmaLinux — но проверяйте совместимость версии пакета с конкретной версией системы отдельно, не по умолчанию.

Скорость обновлений и жизненный цикл версий

В экосистеме CentOS/AlmaLinux/Rocky вы привыкли к достаточно понятному ритму: апстрим (RHEL) выпускает патч безопасности — с некоторой задержкой на пересборку он появляется и в клоне. Задержка при этом обычно небольшая и, что важно, публично отслеживаемая — можно свериться с апстрим-адвайзери и понять, догнал ли клон конкретную уязвимость.

На РЕД ОС такой прямой параллели нет: обновления идут по циклу самого вендора, а не синхронизируются в реальном времени с чьим-то ещё апстримом. Это не «хуже» и не «лучше» само по себе — это просто другой процесс, со своим SLA и расписанием, который стоит уточнять по актуальной документации и changelog вендора, а не проецировать на него привычки из мира community-клонов. Практический вывод для админа: не считайте день выхода патча в RHEL/AlmaLinux ориентиром для даты появления того же исправления на РЕД ОС — это разные производственные процессы с разными сроками, и для каждой конкретной уязвимости стоит проверять статус именно по документации/бюллетеням вендора, а не предполагать.

То же касается жизненного цикла мажорных версий: сроки поддержки, окна перехода между версиями, порядок мажорных апгрейдов — у РЕД ОС это отдельная политика вендора, которую нужно смотреть в его собственной документации на момент планирования, а не выводить из публичного расписания жизненного цикла RHEL или AlmaLinux. Если для инфраструктуры важны точные даты EOL — закладывайте время на то, чтобы свериться с актуальным документом вендора перед принятием решения, а не полагаться на память о том, «как обычно бывает у RHEL-клонов».

Поддержка, сертификация и реестр — зачем вообще выбирают РЕД ОС

Здесь, пожалуй, главное концептуальное отличие. AlmaLinux выбирают в первую очередь по инженерным причинам: бесплатная, предсказуемая, совместимая с RHEL система. РЕД ОС в подавляющем большинстве случаев выбирают не вместо AlmaLinux по вкусу, а потому что этого требует внешний контур: включение в реестр отечественного программного обеспечения и наличие сертификатов соответствия требованиям безопасности (в частности, требованиям ФСТЭК России) — это то, что имеет значение для госзаказчиков, регулируемых отраслей и организаций, для которых действуют требования импортозамещения на инфраструктурном уровне.

Это смежная, но отдельная тема от требований 152-ФЗ о локализации персональных данных — 152-ФЗ регулирует, где физически должна лежать база с персональными данными, а требования к самому ПО (реестр, сертификация) — про происхождение и проверенность программного обеспечения. Если для вашего проекта актуальна именно локализация данных, а не выбор ОС, подробный разбор — в статье 152-ФЗ: где законно держать сервер с персональными данными. Если же вопрос шире — насколько сам хостинг-провайдер учитывает такие требования — стоит посмотреть на статью о том, что означает нахождение хостинг-провайдера в реестре.

Из выбора «по требованию, а не по вкусу» вытекает и другая модель поддержки. Вместо community-форумов, Stack Overflow и багтрекеров с обсуждением на английском — вендорский саппорт: контракт, тикеты, SLA, документация на русском языке. Это ощутимо иначе, чем привычная модель «погуглил ошибку на английском — нашёл похожий issue на GitHub». Плюс — есть с кого спросить формально и предъявить претензию по контракту. Минус — объём открытой community-базы знаний вокруг РЕД ОС кардинально меньше, чем вокруг RHEL/CentOS/AlmaLinux, поэтому многие мелкие вопросы, которые в мире Alma решаются за пять минут поиском, здесь быстрее решить через документацию вендора или обращение в поддержку, чем перебором форумов.

Первое знакомство: чек-лист для админа с опытом CentOS/AlmaLinux/Rocky

Если сервер на РЕД ОС достался вам впервые, прежде чем разворачивать на нём привычный стек, пройдитесь по короткому списку — он экономит именно тот день, который обычно уходит на «а почему не работает то, что всегда работало»:

• Зафиксируйте точную идентичность системы. cat /etc/os-release и cat /etc/redhat-release — не пропускайте этот шаг, даже если сервер выдали «уже настроенным».
• Сверьте репозитории и ключи, а не предполагайте их. dnf repolist -v и список импортированных GPG-ключей — прежде чем что-то ставить.
• Проверьте статус SELinux и его политику. getenforce и sestatus — режим по умолчанию и набор политик может отличаться от того, к чему вы привыкли на AlmaLinux, а тихо выключать SELinux «чтобы не мешал» — плохая практика в среде, где систему как раз выбирали ради безопасности и сертификации.
• Посмотрите на firewalld по умолчанию. firewall-cmd --state и firewall-cmd --list-all — какие зоны и правила активны из коробки.
• Проверьте, что реально включено и слушает порты. systemctl list-unit-files --state=enabled и ss -tulpn — на новом для себя дистрибутиве не доверяйте списку сервисов «на глаз».
• Не переносите Ansible/Puppet-роли вслепую. Роли, написанные под AlmaLinux, часто жёстко зашивают имена пакетов и репозиториев — прогоните их сначала на тестовом сервере и явно сверьте, что каждая задача действительно находит нужный пакет.
• Уточните условия лицензии и поддержки до продакшена, а не после инцидента. Модель подписки, что входит в SLA, какие каналы эскалации — это стоит понять на берегу, а не в момент, когда сервер уже лёг.
• Держите отдельный тестовый стенд под первые недели знакомства. Дешевле сломать тестовый сервер, разбираясь с отличиями в репозиториях, чем чинить прод в 9 вечера.

Частые вопросы