AlmaLinux и Rocky Linux: upgrade с EL8 на EL9 через Leapp на VDS

Привет, это Вася из Fastfox. Обновление AlmaLinux или Rocky Linux с 8 до 9 на живом VDS — задача из тех, где лучше один раз потратить вечер на подготовку, чем потом героически восстанавливать сервер из rescue-режима. В этой инструкции разберём практичный путь upgrade через Leapp с использованием данных ELevate: от аудита EL8 до проверки сервисов уже на EL9.

Сразу важная оговорка: in-place upgrade между major-версиями Enterprise Linux не равен обычному dnf update. Меняется базовая версия системы, ядро, Python, OpenSSL, системные библиотеки, набор модулей AppStream, политики SELinux и поведение некоторых сервисов. Поэтому подход должен быть как к небольшой миграции, а не как к рядовому обновлению пакетов.

Главное правило: перед leapp upgrade у вас должен быть рабочий rollback. Для VDS это обычно snapshot на стороне провайдера плюс независимая файловая и дамповая резервная копия критичных данных.

Что делает Leapp и когда его стоит использовать

Leapp — это фреймворк для major upgrade систем семейства Enterprise Linux. Он анализирует текущую систему, строит отчёт preupgrade, ищет блокирующие проблемы, готовит пакеты для новой major-версии и выполняет обновление в специальной загрузочной среде. Для AlmaLinux и Rocky Linux на практике часто используют проект ELevate, который предоставляет нужные пакеты и данные миграции для перехода с EL8 на EL9.

Такой сценарий удобен, если на VDS уже настроены десятки сервисов, пользователи, firewall, веб-сервер, PHP-FPM, базы данных, мониторинг, бэкапы, системные unit-файлы и cron/systemd timers. Если же сервер простой, а приложение хорошо автоматизировано Ansible, Terraform, cloud-init или CI/CD, иногда надёжнее поднять чистый EL9 рядом и переключить трафик через DNS или балансировщик.

Leapp особенно полезен для типовой связки VDS: Nginx или Apache, PHP-FPM, MariaDB или PostgreSQL, Redis, Postfix, Dovecot, системные таймеры и несколько пользовательских сервисов. Но чем больше нестандартных репозиториев, DKMS-модулей, вручную собранных пакетов и старых панелей управления, тем выше риск blockers на этапе preupgrade.

Перед стартом: проверяем, что сервер вообще готов к EL9

Начните не с установки Leapp, а с инвентаризации. Нужно понять текущую ОС, ядро, свободное место, активные репозитории, включённые модули, старые пакеты и состояние systemd. На production-VDS я запускаю такие проверки в tmux, чтобы не потерять сессию при обрыве SSH.

dnf install -y tmux
mkdir -p /root/upgrade-el9
script -a /root/upgrade-el9/session.log
tmux new -s leapp

Дальше собираем базовую информацию. Логи лучше сохранить в отдельную директорию: они пригодятся, если понадобится анализировать, почему preupgrade остановился или почему после reboot не поднялся сервис.

cat /etc/os-release
rpm -E %rhel
uname -r
df -h / /boot
df -ih / /boot
dnf repolist --enabled
dnf module list --enabled
systemctl --failed
systemctl is-active NetworkManager
nmcli con show
ip address
ip route

Для Leapp важны свободное место и чистое состояние пакетной базы. На небольших VDS часто забивается /boot: старые ядра занимают место, а обновление должно поставить новое ядро EL9 и initramfs. Если /boot меньше 1 ГБ и там уже почти нет места, сначала аккуратно удалите лишние старые ядра, оставив текущее рабочее и одно предыдущее.

dnf repoquery --installonly --latest-limit=-2 -q
rpm -qa | grep -E 'kernel|kmod|dkms|elrepo'

Не копируйте команду удаления старых ядер вслепую. Сначала посмотрите список, убедитесь, что там нет текущего ядра из uname -r, и только потом удаляйте конкретные пакеты по именам. На VDS с нестандартным kernel-ml, kmod-драйверами или DKMS лучше заранее оценить, нужны ли они в EL9. Если параллельно планируете пересмотреть дисковую подсистему, пригодится материал про выбор и настройку ext4/XFS на VDS.

Бэкапы и rollback: что должно быть до preupgrade

Rollback — это не один пункт, а несколько уровней защиты. Snapshot VDS удобен тем, что возвращает диск целиком в состояние до upgrade. Но snapshot не заменяет бэкап: если вы случайно сделали снимок после повреждения данных или обнаружили проблему поздно, нужна независимая копия.

Минимальный набор перед AlmaLinux upgrade или Rocky Linux upgrade:

• снимок VDS в панели управления перед началом работ;
• дампы баз данных, если на сервере есть MySQL, MariaDB или PostgreSQL;
• архивы конфигураций из /etc, сайтов, unit-файлов и cron/systemd timers;
• проверка, что вы можете зайти в аварийную консоль VDS, а не только по SSH;
• план окна работ: кто проверяет приложение, кто принимает решение об откате.

Пример базовой локальной подготовки дампов и конфигов. Пути и имена баз адаптируйте под себя, а архив после создания лучше унести на внешний storage.

mkdir -p /root/upgrade-el9/backups
cp -a /etc /root/upgrade-el9/backups/etc-$(date +%F)
tar -C /var/www -czf /root/upgrade-el9/backups/www-$(date +%F).tar.gz .
mysqldump --all-databases --single-transaction --routines --events > /root/upgrade-el9/backups/mysql-all-$(date +%F).sql
sudo -u postgres pg_dumpall > /root/upgrade-el9/backups/postgresql-all-$(date +%F).sql

Если базы большие, не ограничивайтесь одной командой. Проверьте размер дампа, возможность чтения архива и наличие свободного места. Для PostgreSQL с крупными инсталляциями вместо pg_dumpall часто удобнее отдельные дампы баз и проверенный физический backup. Для MySQL и MariaDB на нагруженных серверах лучше использовать согласованный hot backup или делать дамп в окно низкой активности.

Отдельно сохраните список пакетов и сервисов. После перехода на EL9 это поможет найти забытые зависимости и понять, какие пакеты остались из EL8.

rpm -qa | sort > /root/upgrade-el9/rpm-before.txt
systemctl list-unit-files --state=enabled > /root/upgrade-el9/enabled-before.txt
ss -lntup > /root/upgrade-el9/listen-before.txt
crontab -l > /root/upgrade-el9/root-crontab-before.txt

Обновляем EL8 до актуального состояния

Leapp лучше запускать на полностью обновлённой EL8. Если система годами не обновлялась, сначала сделайте обычное обновление в рамках текущей major-версии, перезагрузитесь и проверьте сервисы. Не смешивайте обычный dnf update и major upgrade в один недокументированный прыжок.

dnf clean all
dnf makecache
dnf update -y
reboot

После перезагрузки снова проверьте состояние. Если уже на этом этапе появились failed units, ошибки репозиториев или проблемы с сетью, исправляйте их до Leapp. Major upgrade усиливает существующие проблемы, а не лечит их.

cat /etc/redhat-release
uname -r
systemctl --failed
dnf check
journalctl -p warning -b

Также временно отключите лишние сторонние репозитории. EPEL, Remi, ELRepo, репозитории панелей управления и vendor-репозитории приложений могут мешать расчёту зависимостей. Не обязательно удалять их навсегда, но на время preupgrade и upgrade лучше оставить только нужные базовые репозитории и репозиторий ELevate.

dnf install -y dnf-plugins-core
dnf repolist --enabled
dnf config-manager --set-disabled epel
dnf config-manager --set-disabled remi-safe
dnf config-manager --set-disabled elrepo

Названия репозиториев на вашем сервере могут отличаться. Сначала смотрите dnf repolist --enabled, потом отключайте конкретные id. Если сервер использует PHP из Remi или специализированные пакеты из EPEL, зафиксируйте это в плане: после EL9 их нужно будет подключить заново уже в версии для EL9.

Устанавливаем Leapp/ELevate для AlmaLinux и Rocky Linux

На этом шаге различаются пакеты данных миграции. Сам leapp-upgrade общий, а leapp-data-almalinux или leapp-data-rocky выбирается по целевой системе. Пакет elevate-release скачайте с официального зеркала проекта ELevate или из доверенного зеркала вашей инфраструктуры, затем установите локальный rpm-файл.

AlmaLinux 8 to AlmaLinux 9

dnf install -y ./elevate-release-latest-el8.noarch.rpm
dnf install -y leapp-upgrade leapp-data-almalinux

Rocky Linux 8 to Rocky Linux 9

dnf install -y ./elevate-release-latest-el8.noarch.rpm
dnf install -y leapp-upgrade leapp-data-rocky

Проверьте, что команда leapp доступна, а установленные пакеты соответствуют нужному дистрибутиву. Не смешивайте данные AlmaLinux и Rocky Linux: это частая причина странных зависимостей и неверной целевой системы.

leapp --version
rpm -qa | grep -E 'leapp|elevate'

Запускаем preupgrade и читаем отчёт

preupgrade — самый важный этап. Он не обновляет систему до EL9, а анализирует её и создаёт отчёт. Если здесь есть inhibitors, переход заблокирован. Если есть high risk, обновление может пройти, но с заметным риском для сервисов. Я советую не игнорировать даже medium-предупреждения, если они касаются сети, bootloader, SELinux, баз данных или веб-стека.

leapp preupgrade

После завершения смотрите отчёт и логи. В отчёте Leapp обычно пишет не только проблему, но и remediation hint — что именно нужно сделать. Иногда это одна команда, иногда ручная правка конфигурации.

less /var/log/leapp/leapp-report.txt
grep -i inhibitor /var/log/leapp/leapp-report.txt
grep -i 'high risk' /var/log/leapp/leapp-report.txt
less /var/log/leapp/leapp-preupgrade.log

Типовые причины, по которым preupgrade останавливает EL8 to EL9 upgrade:

• не заполнен answerfile для известных вопросов Leapp;
• мало места в /boot или корневом разделе;
• включены сторонние репозитории с конфликтующими пакетами;
• установлены неподдерживаемые kernel-модули, DKMS или нестандартное ядро;
• есть старые сетевые настройки, завязанные на deprecated network-scripts;
• используются пакеты, которых нет в EL9 или которые переехали в другие модули;
• есть проблемы с SELinux contexts, PAM, устаревшими crypto policies.

Один из распространённых вопросов касается старого PAM-модуля pam_pkcs11. Если Leapp требует явного подтверждения и вы действительно не используете этот модуль для входа по смарт-картам, ответ можно заполнить так:

leapp answer --section remove_pam_pkcs11_module_check.confirm=True
leapp preupgrade

Не превращайте это в универсальный рецепт для всех inhibitors. Если отчёт спрашивает про VDO, нестандартный драйвер, сетевые скрипты или критичный пакет, сначала разберитесь, используется ли это на вашем VDS. Leapp — хороший помощник, но он не знает бизнес-ценности конкретной службы.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Подготовка приложений: PHP, базы, веб-сервер, почта

Переход с EL8 на EL9 затрагивает не только ОС. На EL9 другие версии системных библиотек и AppStream-модулей. Если у вас PHP-приложение, заранее проверьте совместимость кода и расширений. Если PHP установлен из стороннего репозитория, решите, будете ли вы после upgrade подключать EL9-версию этого репозитория или переходить на пакетную базу дистрибутива.

Для Nginx и Apache обычно достаточно проверить конфиги и модули, но есть нюансы: старые директивы могут быть deprecated, сторонние модули Nginx могут не иметь сборки под EL9, а Apache-модули из EPEL потребуют повторной установки. Для PHP-FPM проверьте pool-конфиги, пути к сокетам, владельцев, лимиты и systemd override-файлы. Если после переезда планируете ограничивать прожорливые сервисы, посмотрите отдельную инструкцию про лимиты памяти и CPU в systemd.

nginx -t
httpd -t
php -v
php -m
systemctl status php-fpm
systemctl cat php-fpm

С базами данных осторожнее. Major upgrade ОС может привести к обновлению серверного пакета MariaDB или PostgreSQL в рамках доступных модулей. Само обновление ОС не заменяет полноценный major upgrade PostgreSQL-кластера по правилам PostgreSQL. Если у вас PostgreSQL из отдельного репозитория, проверьте его поддержку EL9 до старта. Если MariaDB системная, обязательно имейте дамп и план запуска mysql_upgrade или его современного аналога, если он требуется вашей версии.

mysql --version
mariadb --version
psql --version
systemctl status mariadb
systemctl status postgresql

Почтовые серверы требуют отдельной проверки TLS и путей к сертификатам. OpenSSL в EL9 новее, и старые протоколы или слабые шифры могут перестать работать. Это хорошо для безопасности, но может неожиданно выявить древние клиенты. Перед upgrade сохраните вывод текущих портов и проверьте, какие сервисы слушают сеть.

ss -lntup
postconf -n
doveconf -n

Запускаем leapp upgrade

Когда leapp preupgrade проходит без inhibitors, есть свежий snapshot, бэкапы вынесены с сервера, а окно работ согласовано, можно запускать обновление. На этом этапе Leapp подготовит новую загрузочную запись и пакеты для перехода.

leapp upgrade

Если команда завершилась успешно, перезагружаем сервер. После reboot система загрузится в специальный upgrade-режим, выполнит замену пакетов и ещё раз перезагрузится уже в EL9. В этот момент SSH может быть недоступен довольно долго, особенно на небольшом VDS с медленным диском или множеством пакетов.

reboot

Не паникуйте после первой минуты недоступности. Лучше наблюдать через консоль VDS. Если есть возможность открыть serial/VNC-консоль, держите её под рукой заранее. Типичная ошибка — запускать upgrade по SSH без доступа к консоли, а затем не понимать, система обновляется, ждёт ввода в initramfs или упала в emergency mode. Для тестовой репетиции или миграции на чистую систему можно заранее подготовить отдельный VDS и прогнать на нём тот же сценарий.

Первые проверки после загрузки EL9

После возвращения SSH сначала убедитесь, что вы действительно на EL9, а не откатились в старую запись загрузчика. Затем проверьте ядро, failed units, сетевые порты и пакетную базу.

cat /etc/redhat-release
rpm -E %rhel
uname -r
systemctl --failed
journalctl -p warning -b
ss -lntup
dnf check
dnf repolist --enabled

Сравните список listening-портов с тем, что сохранили до upgrade. Если до перехода слушали 80, 443, 22, 25, 587, 993, 3306 на localhost и Redis на unix-сокете, после upgrade картина должна быть ожидаемой. Не полагайтесь только на статус systemd: сервис может быть active, но слушать не тот адрес или упасть на первом пользовательском запросе.

ss -lntup > /root/upgrade-el9/listen-after.txt
diff -u /root/upgrade-el9/listen-before.txt /root/upgrade-el9/listen-after.txt

После major upgrade полезно выполнить синхронизацию пакетов с текущими репозиториями EL9. Но перед этим убедитесь, что подключены именно репозитории EL9, а не оставшиеся EL8-источники.

dnf repolist --enabled
dnf distro-sync -y

Дальше ищем хвосты EL8. Не всё, что содержит el8 в имени, обязательно надо немедленно удалять, но список нужно просмотреть. Особенно внимательно смотрите библиотеки, пакеты из сторонних репозиториев и старые kernels.

rpm -qa | grep -E 'el8|elevate|leapp'
dnf repoquery --unsatisfied
dnf autoremove

dnf autoremove сначала покажет кандидатов на удаление и попросит подтверждение. На production не соглашайтесь автоматически, пока не просмотрели список. Иногда в autoremove попадают пакеты, которые приложение использует напрямую, но которые были установлены как зависимости.

Проверка сервисов и прикладной smoke test

Технически успешная загрузка EL9 ещё не означает, что upgrade завершён. Нужно проверить приложение снаружи и изнутри. Я обычно делю smoke test на три уровня: системный, сервисный и пользовательский.

• Системный уровень: CPU, RAM, диск, swap, сеть, failed units, firewall, SELinux.
• Сервисный уровень: Nginx/Apache, PHP-FPM, база, Redis, очереди, cron/systemd timers, почта.
• Пользовательский уровень: главная страница, логин, загрузка файла, отправка письма, фоновые задачи, API-методы.

free -h
df -h
df -ih
getenforce
firewall-cmd --state
firewall-cmd --list-all
systemctl status nginx
systemctl status httpd
systemctl status php-fpm
systemctl status mariadb
systemctl status postgresql
systemctl list-timers

Если SELinux включён, не отключайте его первым движением при любой ошибке 403 или 502. Сначала посмотрите audit-логи. После major upgrade могли измениться контексты файлов, особенно если сайты лежат в нестандартных каталогах.

ausearch -m AVC -ts recent
restorecon -Rv /var/www

Для веб-сервера обязательно проверьте конфигурацию и сделайте graceful reload. Если reload не проходит, не перезапускайте всё подряд: сначала исправьте конфиг, иначе можно погасить работающий процесс.

nginx -t
systemctl reload nginx
httpd -t
systemctl reload httpd
php-fpm -t
systemctl reload php-fpm

Если что-то пошло не так: стратегия rollback

Откат после неудачного Leapp upgrade зависит от момента, на котором вы остановились. Если проблема обнаружена до команды leapp upgrade, всё просто: исправляете inhibitors, возвращаете репозитории в нормальное состояние или отказываетесь от in-place сценария. Если проблема возникла после leapp upgrade, но до reboot, можно изучить логи и часто безопасно не продолжать, пока не понятно состояние системы.

Если сервер уже перезагрузился и EL9 не поднялся, главный путь rollback на VDS — восстановление snapshot. Поэтому снимок должен быть сделан прямо перед работами, а не неделю назад. Восстановление snapshot обычно быстрее и чище, чем попытки вручную откатить сотни rpm-пакетов между major-версиями.

Если EL9 загрузился, но не работает приложение, не спешите откатывать весь сервер. Сначала оцените масштаб:

• не поднялся один сервис из-за конфигурации или прав;
• сломалась зависимость PHP или Python;
• база требует post-upgrade действий;
• неверно включены репозитории EL9;
• сеть или firewall изменили поведение доступа.

Для одиночного сервиса часто быстрее исправить проблему на EL9. Для системной поломки сети, пакетной базы, bootloader или несовместимости критичного приложения лучше откатываться на snapshot и готовить миграцию на чистый сервер.

Хороший rollback-план содержит не только кнопку восстановления snapshot, но и критерии: сколько минут мы диагностируем, какие сервисы считаем критичными и при каком результате прекращаем эксперименты.

Типовые проблемы после EL8 to EL9 upgrade

Остались EL8-репозитории

Это одна из самых неприятных проблем. Система вроде бы EL9, но dnf тянет пакеты из старого репозитория или ругается на зависимости. Проверьте все файлы репозиториев и отключите устаревшие источники.

grep -R 'el8' /etc/yum.repos.d
dnf repolist --enabled

Вывод dnf repolist --enabled нужно читать глазами. Автоматически править repo-файлы после major upgrade опасно: можно удалить нужный внутренний репозиторий или оставить систему без security updates.

Не стартует PHP-FPM

После EL9 могли измениться версии PHP, расширения и пути. Проверьте syntax, pool-файлы, сокеты, владельцев и логи. Частая ситуация: Nginx проксирует в старый socket, а новый PHP-FPM слушает другой путь.

php -v
php-fpm -t
systemctl status php-fpm
journalctl -u php-fpm -b
find /run -name '*php*fpm*' -o -name 'php-fpm.sock'

Nginx или Apache отвечает 502/503

Смотрите не только веб-сервер, но и upstream: PHP-FPM, Gunicorn, Node.js, uWSGI, backend API. После upgrade могли измениться systemd overrides, лимиты, environment-файлы или права на runtime-каталоги.

systemctl status nginx
systemctl status httpd
journalctl -u nginx -b
journalctl -u httpd -b
systemctl --failed
ss -lntup

Проблемы с NetworkManager

EL9 ожидает нормальную работу NetworkManager. Если на EL8 сеть была настроена старыми network-scripts или вручную, проверьте connection profiles, адреса, маршруты и DNS. На VDS особенно важно не потерять основной маршрут и доступ по SSH.

systemctl status NetworkManager
nmcli con show
nmcli dev status
ip address
ip route
cat /etc/resolv.conf

Финальная уборка и фиксация результата

Когда приложение проверено, не оставляйте сервер в промежуточном состоянии. Сохраните новый список пакетов и сервисов, включите обратно только нужные EL9-репозитории, обновите документацию и проверьте расписание бэкапов. Если на сервере есть мониторинг, убедитесь, что agents совместимы с EL9 и продолжают отправлять метрики.

rpm -qa | sort > /root/upgrade-el9/rpm-after.txt
systemctl list-unit-files --state=enabled > /root/upgrade-el9/enabled-after.txt
ss -lntup > /root/upgrade-el9/listen-after.txt
dnf update -y
systemctl --failed

После успешного окна работ я обычно оставляю snapshot на короткий срок, например на несколько дней, если это позволяет политика хранения. Но не стоит хранить временные snapshot бесконечно: они могут занимать место и усложнять управление дисками. Когда вы уверены, что EL9 стабилен, сделайте уже новый плановый backup и удалите временные артефакты по внутреннему регламенту.

Также стоит пересмотреть автоматические обновления. На EL9 могут отличаться пакеты, политики dnf-automatic, excludes и правила needrestart-подобных инструментов. Если у вас есть Ansible-роль для EL8, заведите отдельные переменные для EL9, а не пытайтесь бесконечно обрастать условиями в старой роли.

Короткий чек-лист для рабочего окна

1. Проверить ОС, ядро, место на / и /boot, состояние systemd.
2. Сделать snapshot VDS и независимые бэкапы данных.
3. Обновить EL8 до актуального состояния и перезагрузиться.
4. Отключить конфликтующие сторонние репозитории.
5. Установить leapp-upgrade и правильный leapp-data для AlmaLinux или Rocky Linux.
6. Запустить leapp preupgrade, устранить inhibitors и повторить проверку.
7. Запустить leapp upgrade и перезагрузить сервер через консоль VDS.
8. Проверить EL9, сервисы, сеть, firewall, SELinux, приложение и фоновые задачи.
9. Выполнить финальный dnf distro-sync, убрать хвосты и зафиксировать результат.

Итог: Leapp даёт вполне рабочий путь EL8 to EL9 upgrade для AlmaLinux и Rocky Linux на VDS, но успех зависит не от одной команды, а от дисциплины вокруг неё. Хороший preupgrade, понятный rollback, чистые репозитории и прикладной smoke test превращают рискованный major upgrade в управляемую админскую процедуру.