Migrer de CentOS vers Rocky Linux 9 en 2026

Migrer de CentOS vers Rocky Linux 9 est en retard chez beaucoup de boîtes, parce que CentOS 7 a atteint sa fin de vie le 30 juin 2024 et CentOS 8 est mort encore plus tôt, le 31 décembre 2021. Et pourtant nous voilà en 2026 et plein de machines font encore tourner ces systèmes en production. Les correctifs se sont arrêtés, l'archive officielle des paquets a disparu, et une seule CVE glibc non corrigée suffit à faire de cette machine stable une cible facile. Ce guide couvre le passage à Rocky Linux 9, ou AlmaLinux 9 si tu penches de ce côté. Deux voies : la voie in-place ELevate, et la réinstallation propre, plus lente mais à laquelle je fais plus confiance. Plus l'inventaire préalable qu'on ne peut pas zapper et les casses qui échouent en silence.

CentOS 7 a atteint sa fin de vie le 30 juin 2024. Ça fait deux ans et demi maintenant. CentOS 8 est mort encore plus tôt, brutalement, le 31 décembre 2021. Et pourtant nous voilà en 2026 et plein de boîtes font encore tourner ces machines en production. Je comprends pourquoi. Un système métier s'est soudé à l'OS il y a des années, refaire la certification avec l'éditeur coûte de l'argent bien réel, les fenêtres de maintenance sont serrées, et il y a cette petite voix qui dit que ça marche toujours alors pourquoi y toucher. Mais voilà ce que personne de ce côté n'aime entendre. Les correctifs se sont arrêtés. L'archive officielle des paquets a disparu. Une seule CVE glibc non corrigée et cette machine "stable" devient la cible facile par laquelle quelqu'un passe sans effort. Ce guide couvre le passage à Rocky Linux 9, ou AlmaLinux 9 si tu penches de ce côté, et je vais parler des deux. Deux voies : la migration in-place avec ELevate, et la réinstallation propre, plus lente, à laquelle je fais honnêtement plus confiance. Plus l'inventaire préalable qu'on ne peut pas zapper et les casses qui échouent en silence.

Pourquoi migrer encore en 2026

Les maths se fichent de tes sentiments ici. La dernière mise à jour de sécurité de CentOS 7 est sortie fin juin 2024. Chaque CVE depuis reste non corrigée sur la machine que tu n'as pas touchée. Les miroirs qui répondent encore le font par bonté de la communauté, et l'archive officielle de Red Hat a disparu des URL canoniques il y a des mois. Tu gères des paiements, des données personnelles, quoi que ce soit qui tombe sous SOC2, ISO 27001 ou PCI-DSS ? Un OS en EOL, c'est un point écrit noir sur blanc à chaque audit. Certains assureurs excluent maintenant la couverture cyber dès l'instant où l'OS sous-jacent dépasse sa fin de vie. Alors le "si ça marche, on n'y touche pas", que j'ai moi-même servi un paquet de fois, ça ne tient tout simplement plus une fois assis en face d'un auditeur.

CentOS 8 est le cas le plus délicat. La coupure est arrivée vite, et le virage vers Stream a discrètement réécrit le contrat. Stream est en amont de RHEL. Ce n'est pas le truc tranquille en aval qu'on appelait tous "CentOS". Donc si tu faisais tourner CentOS 8 en production parce que tu voulais du chiant et du prévisible, Stream est la mauvaise réponse. Tu veux Rocky, ou Alma, ou RHEL.

Choisir la cible : Rocky vs Alma vs RHEL

Tu as en gros trois équivalents stables de RHEL 9 au choix en 2026.

Rocky et Alma sont binaires-compatibles entre eux et avec RHEL. Un paquet construit pour RHEL 9 se pose sur Rocky 9 ou Alma 9 sans rebuild. Donc au niveau technique le choix relève surtout de la gouvernance. Rocky rend des comptes à une fondation communautaire. Alma est sous la fondation CloudLinux. Les deux sont d'une solidité à toute épreuve depuis 2022. Mon avis, et je peux me tromper là-dessus, c'est que si tu remplaces CentOS par défaut, tu devrais simplement partir sur Rocky. Même fondateur que le CentOS d'origine, et la plus grosse communauté, ce qui en pratique veut dire plus de résultats de recherche quand un truc casse à 2h du mat. Alma est un choix vraiment excellent aussi, et ses correctifs de sécurité ont tendance à arriver un peu plus tôt. Honnêtement la capacité est identique, alors suis la foule sur laquelle ton équipe pourra vraiment s'appuyer.

À éviter : faire passer CentOS 7 ou 8 sur CentOS Stream et appeler ça "stable". Stream se situe en amont de RHEL. Il reçoit les changements avant que RHEL les ait stabilisés. Génial pour le dev et pour renvoyer des correctifs vers RHEL. Le mauvais outil pour les machines de production de la longue traîne que tu essaies enfin de poser.

Deux voies : ELevate in-place vs réinstallation propre

Deux stratégies réalistes. C'est tout.

ELevate in-place

L'équipe AlmaLinux maintient ELevate (github.com/AlmaLinux/leapp-data), un portage du Leapp de Red Hat qui met à niveau une machine CentOS 7/8 en fonctionnement, in-place, directement vers Rocky 9, Alma 9, RHEL 9, ou une autre cible de la famille RHEL. Il lit le système, signale ce qui bloque, puis fait la mise à niveau en trois redémarrages. Sur des installs vanilla propres, ça marche bien. Sur des machines bourrées de paquets tiers et d'années de dérive de config éditée à la main, avec parfois un kernel custom par-dessus ? Ça marche mal, et tu vas le sentir passer.

Réinstallation propre + restauration

Tu montes une nouvelle machine Rocky 9 ou Alma 9, tu installes les applis à partir de zéro (idéalement via ta gestion de configuration), puis tu restaures les données. C'est plus lent par machine. C'est aussi nettement plus prévisible, et ça te force discrètement à avoir vraiment une gestion de configuration documentée, ce qui, soyons honnêtes, est l'endroit où tu voulais être de toute façon.

Ma règle approximative, et elle a tenu sur un paquet de machines : ELevate pour les machines que tu as documentées et testées, réinstallation propre pour celles qui ont poussé toutes seules dans leur coin. La plupart des parcs CentOS sont un mélange bordélique des deux. L'étape d'audit juste en dessous te les trie.

Inventaire préalable et sauvegarde

Inventorier les paquets installés

Récupère la liste complète de chaque paquet installé, ventilée selon le repo d'où il vient. C'est ça qui te dit lesquels ont un équivalent RHEL 9 propre et lesquels tu vas devoir te coltiner à la main.

rpm -qa --qf "%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n" | sort > /tmp/packages.txt
yum repolist                                # CentOS 7
dnf repolist                                # CentOS 8
yum list installed | grep -v "@base\|@updates" > /tmp/third-party.txt

Ce fichier /tmp/third-party.txt contient tout ce qui vient d'en dehors des défauts de la distro. Ce sont les paquets qui mordent pendant une migration. Les suspects habituels : EPEL, Remi, ELRepo, et les repos d'éditeurs comme PostgreSQL officiel, MariaDB officiel, MongoDB.

Inventorier la dérive de configuration

Laisse rpm te dire chaque fichier de config qui ne correspond plus à son défaut de paquet. Ce sont ceux que tu dois vérifier sur la cible, parce que la moitié d'entre eux ont déménagé vers un nouvel emplacement dans RHEL 9.

sudo rpm -Va --nofiles --nomd5 --noscripts 2>/dev/null | sort > /tmp/drift.txt
sudo find /etc -type f -newer /tmp/install-marker 2>/dev/null > /tmp/changed-config.txt

Pour les fichiers que tu ne peux vraiment pas te permettre de rater, sshd_config et sudoers et nginx.conf et my.cnf et postfix main.cf, fais un diff de chacun contre une install standard de la même version. Comme ça la migration se contente de rejouer les deltas au lieu de te faire deviner.

Tout sauvegarder

Prends une image disque complète si ton hyperviseur ou ton fournisseur cloud te le permet (snapshot Hetzner, AMI AWS, snapshot OVH, un snapshot ESXi avant toute conversion d'hôte VMware). Puis une sauvegarde logique des bases de données et des données applicatives par-dessus. Et teste vraiment que tu peux la restaurer. Une sauvegarde que tu n'as jamais restaurée n'est qu'un espoir.

sudo tar -czf /backup/etc-pre-migration.tar.gz /etc /var/spool/cron /root /home
sudo mysqldump --all-databases | gzip > /backup/mysql-$(date +%F).sql.gz
sudo -u postgres pg_dumpall | gzip > /backup/pg-$(date +%F).sql.gz
sudo tar -czf /backup/var-www-$(date +%F).tar.gz /var/www

Documenter les services en cours

Tu vas y jeter un oeil tout au long de la validation.

sudo systemctl list-units --type=service --state=running > /tmp/services-running.txt
sudo ss -tlnp > /tmp/listening-ports.txt
sudo crontab -l > /tmp/root-crontab.txt
ls /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.weekly/ /etc/cron.monthly/ > /tmp/cron-jobs.txt

La migration in-place avec ELevate

ELevate est un outil Python qui fait passer la machine par trois phases : une analyse de pré-migration, le redémarrage de la mise à niveau lui-même, puis le nettoyage ensuite. Voici la procédure CentOS 7 vers Rocky 9 (ou Alma 9) telle qu'elle est en 2026.

Installer ELevate

sudo yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm
sudo yum install -y leapp-upgrade leapp-data-rocky    # pour une cible Rocky
# Ou : sudo yum install -y leapp-upgrade leapp-data-almalinux  # pour une cible Alma

Analyse de pré-migration

sudo leapp preupgrade

Ça écrit /var/log/leapp/leapp-report.txt, trié par niveaux de sévérité. inhibitor veut dire que ça bloque la mise à niveau. high veut dire qu'il faut le passer en revue avant de bouger. medium/low, c'est juste pour ton information. Élimine chaque inhibitor avant d'aller plus loin, sans exception. Généralement ce sont des paquets épinglés d'un repo tiers ou des modules kernel custom. Parfois un système de fichiers chiffré monté d'une façon non standard.

Lancer la mise à niveau

sudo leapp upgrade
sudo reboot

Le vrai travail se passe dans un initramfs spécial après le redémarrage, pas pendant que tu regardes le terminal. Compte 15 à 45 minutes, selon la vitesse du disque et le nombre de paquets que tu as. Quand c'est fini la machine redémarre toute seule une deuxième fois. Ne panique pas quand ça arrive.

Réconciliation post-migration

cat /etc/os-release          # confirmer Rocky 9 / Alma 9
uname -r                     # nouveau kernel
sudo dnf check-update        # des mises à jour de paquets de routine ?
sudo dnf upgrade -y          # les appliquer
sudo systemctl --failed      # un service a échoué au démarrage ?

Mise en garde sur ELevate : il ne gère pas chaque paquet avec élégance. Les trucs EPEL et les RPM custom peuvent nécessiter un nettoyage manuel ensuite, pareil pour tout ce qui a des scripts post-install velus. Lance-le sur un snapshot d'abord, à chaque fois. Et attends-toi à ce qu'environ une migration sur quatre demande des retouches à la main.

La voie de la réinstallation propre

Tu montes une machine Rocky 9 ou Alma 9 fraîche, tu installes les applis, tu restaures les données, puis tu bascules le DNS ou l'IP flottante. Voilà comment ça se passe.

1. Provisionne la nouvelle machine aux mêmes specs que la source, ou plus grosse. Pose un durcissement de base par la même occasion. Notre checklist de durcissement Ubuntu couvre le raisonnement, et il se reporte bien sur la famille RHEL une fois les commandes échangées.
2. Installe les applis depuis la gestion de configuration (Ansible, Salt, Puppet, Chef). Pas encore de gestion de configuration ? C'est le moment de t'y mettre. Même un petit playbook Ansible bricolé qui se contente de noter ce qui s'installe vaut mieux que rien.
3. Restaure les données depuis la sauvegarde. La base d'abord, puis les fichiers applicatifs, la configuration en dernier.
4. Valide avec la section suivante.
5. Bascule le trafic avec un changement DNS ou un déplacement d'IP flottante (ou rééquilibre le load balancer si tu en as un). Laisse l'ancienne machine tourner 24 à 72 heures comme filet de sécurité.
6. Décommissionne l'ancienne machine une fois que tu es sûr que la nouvelle tient.

Validation post-migration

Peu importe la voie que tu as prise. Valide par rapport aux notes que tu as faites en préalable. C'est tout l'intérêt de les avoir faites.

• Chaque service en cours de /tmp/services-running.txt tourne toujours. Recoupe avec systemctl --failed.
• Chaque port de /tmp/listening-ports.txt écoute toujours. Recoupe avec ss -tlnp.
• Chaque tâche cron se déclenche au moins une fois. Suis /var/log/cron (CentOS 7) ou journalctl (Rocky 9).
• Les smoke tests applicatifs passent. Le même flux de bout en bout que tu lancerais après n'importe quel déploiement.
• Le monitoring externe voit vraiment la machine. Uptime, le certif TLS, les en-têtes de sécurité, tout ça. Notre Cyber Audit Suite vérifie tout ça en une vingtaine de secondes.
• Sauvegarde la nouvelle machine. Les migrations adorent casser discrètement les anciens hooks de sauvegarde (chemins déplacés, permissions modifiées), alors surveille le prochain passage planifié de tes propres yeux et assure-toi qu'il se déclenche vraiment.

Casses fréquentes et corrections

network-scripts supprimé

RHEL 9 a abandonné /etc/sysconfig/network-scripts/ifcfg-* comme source de vérité. Ta config réseau vit maintenant dans des keyfiles NetworkManager sous /etc/NetworkManager/system-connections/. Convertis-la avec nmcli, ou, si tu as besoin de t'accrocher aux anciens fichiers un moment, installe la couche de compat NetworkManager-initscripts-ifcfg-rh. Notre article sur la configuration réseau détaille les schémas de traduction.

Python 2 disparu

RHEL 9 livre Python 3.9 par défaut avec 3.11 en alternatif. Python 2 a tout simplement disparu. Tout script maison encore coincé sur 2 doit être porté. Commence avec 2to3, bien sûr, mais ne te fais pas d'illusions, il y aura du nettoyage manuel ensuite. Le guide officiel de portage Python gère les cas courants.

iptables remplacé par nftables (en grande partie)

iptables est toujours là sur Rocky 9, mais c'est la couche nft maintenant, pas la vraie chose. Tes anciens fichiers de règles se chargent et se comportent pareil, même si le profil de performance change une fois passé à l'échelle. Notre comparatif de pare-feu détaille le passage d'iptables au nftables natif.

Podman remplace Docker (presque)

RHEL 9 livre Podman 4.x par défaut. Docker reste installable depuis le repo Docker, ce n'est juste plus le runtime par défaut. La plupart de tes réflexes docker survivent via l'alias podman (alias docker=podman), et les fichiers compose tournent via podman-compose. Ce qui change : Podman est sans démon et joue plus joliment en rootless. La sémantique réseau dérive un peu, alors teste cette partie plutôt que de la supposer.

SELinux aux défauts plus stricts

La politique SELinux sur RHEL 9 est plus serrée qu'elle ne l'était sur RHEL 7. Une appli custom qui tournait tranquillement sur CentOS 7 peut soudain heurter des refus AVC sur Rocky 9. Trouve-les avec ausearch -m AVC -ts recent, puis construis un module de politique local avec audit2allow. S'il te plaît, ne désactive pas SELinux juste pour faire disparaître l'erreur. J'ai vu des gens faire exactement ça, et tout ce que ça fait c'est offrir une machine plus molle à un attaquant.

Anciens symboles glibc abandonnés

Quelques bibliothèques C de CentOS 7 ne se lieront pas proprement sur Rocky 9 à cause du versionnage des symboles glibc. Recompile depuis les sources, ou tourne-toi vers les paquets compat-glibc s'ils sont disponibles pour ton cas. Tout ce qui est lié statiquement continue simplement de fonctionner, sans y toucher.

Décalage de version majeure de base de données

CentOS 7 venait avec MariaDB 5.5 et PostgreSQL 9.2. Rocky 9 te fait sauter à MariaDB 10.5 et PostgreSQL 13. Une sauvegarde logique (mysqldump, pg_dumpall) franchit ce gouffre. Une copie brute du système de fichiers, non, et essayer c'est comme ça qu'on corrompt une base à 3h du mat. Pars sur la voie logique sauf si tu as une raison vraiment solide de ne pas le faire.

Sources et lectures complémentaires

• Rocky Linux : documentation
• AlmaLinux ELevate (leapp-data)

Questions fréquentes