Содержание
В декабре 2021 года Red Hat официально прекратил поддержку CentOS 8, а в июне 2024-го — и CentOS 7. Это решение вызвало волну паники среди владельцев серверов по всему миру: тысячи production-систем остались без обновлений безопасности, патчей и технической поддержки. Для многих это стало сигналом к немедленной миграции. Один из самых логичных путей — переход на Rocky Linux, созданный бывшим соучредителем CentOS Грегом Курцером как прямой, 1:1-совместимый заменитель RHEL.
Однако миграция — не просто «переустановка ОС». Это сложный процесс, требующий планирования, тестирования и глубокого понимания инфраструктуры. В этой статье подробно разбирается **пошаговая стратегия перехода с CentOS на Rocky Linux**, основанная на реальных кейсах системных администраторов, с акцентом на **типичные ошибки**, **методы восстановления** и **практические решения** для безопасного обновления без потери данных и простоя.
Почему CentOS больше нельзя использовать в продакшене после EOL
End-of-Life (EOL) означает, что разработчик больше не выпускает:
- Обновления безопасности — уязвимости остаются открытыми;
- Исправления багов — критические ошибки не чинятся;
- Поддержку пакетов — репозитории становятся read-only или удаляются.
Например, в 2024 году была обнаружена уязвимость в OpenSSH (CVE-2024-6387), затрагивающая миллионы серверов. Пользователи CentOS 7 не получили патча — их системы остались уязвимыми. Это делает эксплуатацию таких серверов в production юридически и технически рискованной.
Кроме того, многие современные приложения (например, новые версии PHP, Node.js, Docker) перестают поддерживать старые ядра и библиотеки, используемые в CentOS 7.
Подготовка к миграции: резервное копирование, тестовый стенд и инвентаризация сервисов
Любая миграция начинается не с команды в терминале, а с подготовки. Пропуск этого этапа — главная причина катастроф.
1. Полное резервное копирование
Используйте комбинацию методов:
- Образ диска через
ddилиClonezilla— для полного восстановления; - Резервные копии конфигураций — каталоги
/etc,/var/www,/home; - Дампы баз данных — например, для MySQL/MariaDB:
mysqldump -u root -p --all-databases > /backup/all_dbs_$(date +%F).sql
2. Создание тестового стенда
Разверните идентичную копию production-сервера на отдельной машине или виртуальной среде (VirtualBox, Proxmox, VMware). Это позволит протестировать миграцию без риска для основного проекта.
3. Инвентаризация сервисов
Составьте список всего, что работает на сервере:
- Веб-сервер (Apache/Nginx);
- Базы данных (MySQL, PostgreSQL);
- Почтовые сервисы (Postfix, Dovecot);
- Крон-задачи;
- Проприетарные приложения (1С, Bitrix, CRM);
- SELinux-политики и custom systemd-юниты.
Для автоматизации можно использовать:
systemctl list-unit-files --type=service | grep enabled
Попытка автоматической миграции через Leapp: почему она часто завершается ошибкой
Проект Leapp (Leveraging Existing Automation for Project) — официальный инструмент Red Hat для миграции между мажорными версиями RHEL. Сообщество адаптировало его и для CentOS → Rocky Linux.
Команда выглядит просто:
leapp upgrade --target rocky8
Но на практике даже на «чистом» CentOS 7 возникают десятки ошибок:
Типичные ошибки Leapp:
- «Unsupported third-party packages» — наличие пакетов из EPEL, Remi, RPM Fusion;
- «Inhibitor: Custom kernel modules detected» — драйверы NVIDIA, ZFS, VirtualBox;
- «SELinux policy incompatibility» — кастомные политики не переносятся;
- «Python 2 dependency» — многие скрипты всё ещё используют Python 2, которого нет в Rocky 8/9.
В одном из реальных кейсов Leapp завершился с ошибкой на этапе «Initramfs generation», оставив систему в состоянии «полумёртвой» — загрузка останавливалась на initramfs shell.
Вывод: Leapp подходит только для очень простых, стандартных установок. Для большинства production-серверов требуется ручной подход.
Ручная миграция: пошаговая перенастройка репозиториев, SELinux и systemd-юнитов
Более надёжный путь — полная переустановка ОС с последующим восстановлением данных. Но если переустановка невозможна (например, физический сервер без KVM), можно выполнить in-place миграцию вручную.
Шаг 1: Отключение сторонних репозиториев
sudo yum-config-manager --disable epel remi-safe rpmfusion*Шаг 2: Удаление CentOS-специфичных пакетов
sudo yum remove centos-logos centos-releaseШаг 3: Установка репозитория Rocky Linux
Скачайте и запустите официальный скрипт:
curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh sudo chmod +x migrate2rocky.sh sudo ./migrate2rocky.sh -r
Этот скрипт заменяет все CentOS-пакеты на эквиваленты Rocky Linux, сохраняя версионность (CentOS 7 → Rocky 7, CentOS 8 → Rocky 8).
Шаг 4: Обновление системы
sudo dnf clean all sudo dnf update -y
Проблемы с проприетарными драйверами и их решение
Одна из самых частых проблем — отсутствие драйверов для специфического оборудования: RAID-контроллеров, GPU, сетевых карт.
Пример: драйвер NVIDIA
После миграции модуль ядра nvidia.ko перестаёт загружаться, так как версия ядра изменилась.
Решение:
# Установка EPEL и development tools sudo dnf install epel-release sudo dnf groupinstall "Development Tools" sudo dnf install kernel-devel-$(uname -r) # Скачивание и установка драйвера с сайта NVIDIA wget https://us.download.nvidia.com/XFree86/Linux-x86_64/535.183.01/NVIDIA-Linux-x86_64-535.183.01.run sudo sh NVIDIA-Linux-x86_64-535.183.01.run
RAID-контроллеры (например, MegaRAID)
Драйверы часто поставляются в виде RPM-пакетов от производителя. Их нужно пересобрать под новое ядро:
rpmbuild --rebuild MegaCli-8.07.14-1.x86_64.rpm
SELinux и systemd: как восстановить кастомные настройки
SELinux часто «ломается» после миграции, блокируя доступ веб-сервера к файлам.
Диагностика:
sudo ausearch -m avc -ts recent
Покажет, какие именно политики нарушаются.
Восстановление контекста:
sudo restorecon -R /var/www/html
Если у вас были кастомные политики (например, myweb.te), их нужно перекомпилировать:
checkmodule -M -m -o myweb.mod myweb.te semodule_package -o myweb.pp -m myweb.mod sudo semodule -i myweb.pp
Systemd-юниты
Проверьте, что все кастомные сервисы работают:
sudo systemctl daemon-reload sudo systemctl enable myapp.service sudo systemctl start myapp.service
Финальный этап: проверка, мониторинг и документирование изменений
После успешной миграции необходимо:
- Проверить все сервисы — веб, почта, БД, cron;
- Запустить нагрузочное тестирование (например, через
abилиhey); - Настроить мониторинг (Zabbix, Netdata, Prometheus);
- Обновить документацию — зафиксируйте версии ОС, ПО, особенности конфигурации.
Также рекомендуется настроить автоматические обновления безопасности:
sudo dnf install dnf-automatic sudo systemctl enable --now dnf-automatic.timer
Итог: 8 часов работы, но система снова поддерживается до 2029 года
Хотя миграция с CentOS на Rocky Linux требует времени и внимания, результат оправдывает усилия. Rocky Linux гарантирует:
- 100% совместимость с RHEL — все enterprise-приложения работают без изменений;
- Поддержка до 2029 года (для Rocky 8) и до 2032 (для Rocky 9);
- Активное сообщество и регулярные обновления;
- Бесплатность и открытость — без скрытых условий, как у Oracle Linux.
Для компаний, которые не готовы тратить ресурсы на самостоятельную миграцию, отличным решением станет переход на управляемый хостинг с поддержкой современных ОС. Например, сервис хостинг-беларусь.рф предоставляет серверы на Rocky Linux с предустановленной защитой от DDoS, резервным копированием и технической поддержкой 24/7.
Заключение: миграция — не катастрофа, а возможность модернизации
Конец поддержки CentOS — не конец света, а повод привести инфраструктуру в порядок. Миграция на Rocky Linux — это шанс избавиться от «технического долга», обновить стек и обеспечить безопасность на годы вперёд. Главное — действовать методично, с резервной копией и планом отката. Тогда даже самый сложный переход пройдёт гладко.