Montée de version 8 à 9 d'une distribution RedHat et apparentés avec Leapp

Mettre à jour sa version majeure de Linux, c'est possible

Il est possible de procéder à la mise à jour de son système RedHat Enterprise Linux et apparentés (Almalinux, Rocky, Oracle Linux...) grâce à l'outil LEAPP. leapp.

Celui-ci vous permet de faire la mise à jour d'une version 7 vers une version 8 et d'une version 8 vers une version 9 (le passage direct d'une 7 vers une 9 n'est pas possible en une seule mise à jour).

Cet article reprend les commandes utilisées ainsi que quelques captures d'écran de la vidéo disponible sur notre chaîne Youtube @LHQG-fr

Cette vidéo montre la montée de version d’une machine sous Rocky Linux 8 pour passer en version 9.

Préparation

Je me suis connecté à une machine Rocky 8 (installation de base) avec mon compte personnel. Et je deviens root pour la suite des opérations car les privilèges systèmes et le domaine SELinux non confiné (unconfined_t) seront nécessaires pour leapp. 

La première chose à faire avant de commencer, est de vérifier que vous possédez bien la dernière version de votre système.

dnf upgrade

Parfait ! notre système est à jour. Si ce n’est pas le cas, faite le !!!! et redémarrez votre machine

Espace disque

Afin de vous faire gagner du temps, nous allons voir dès maintenant un problème que vous pourriez rencontrer et qui est lié à un manque d'espace disque disponible pour faire la mise à jour :

RedHat® publie un article très intéressant sur le sujet. Vous y retrouverez un script qui vous donnera approximativement la volumétrie à prévoir.

Leapp peut nécessiter beaucoup d’espace disque selon la taille de votre machine chaque cas étant particulier.

Pour éviter les problèmes futurs, nous allons lui allouer de l’espace disque. 

Ici, je vais utiliser un volume logique dédié afin de pouvoir récupérer cet espace par la suite. Mais ce n'est qu'une possibilité parmi tant d'autres. A vous de choisir la solution qui vous convient.

Je dispose d'un peu d'espace dans mon volume groupe principal, je vais donc m'en servir.

Voici la liste des commandes utilisées ensuite :

lvcreate -n /dev/VG_SYS/var_lib_leapp -L5G VG_SYS
mkfs.xfs /dev/VG_SYS/var_lib_leapp
udevadm settle
echo "/dev/VG_SYS/var_lib_leapp /var/lib/leapp xfs defaults 0 0" >> /etc/fstab
systemctl daemon-reload
mount /var/lib/leapp

Référentiels utilisés

Dans la plus par des cas, leapp s'occupera de configurer les référentiels de paquets (repos yum) à utiliser pour la version cible.

Nous ne rentrerons pas ici dans le détail, mais si vous utilisez RedHat® Enterprise Linux et RedHat® Satellite, il y aura des étapes préparatoires obligatoires à faire sur les content views. 

Installation de leapp

L’étape suivante est spécifique pour les OS non RedHat® mais apparentés (Rocky Linux, AlmaLinux), elle permet d’obtenir des fichiers de migration spécifiques à la distribution utilisée :

dnf install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm

Installez ensuite leapp et le paquet spécifique à votre distribution (ce dernier n'étant pas nécessaire sur les RedHat® Enterprise Linux) :  

dnf install -y leapp-upgrade leapp-data-rocky

Le(s) pré-upgrade(s)

Pré-upgrade(s) de test

L'étape suivant consiste à lancer une première vérification grâce: à la commande :

leapp preupgrade

Une fois le preupgrade terminé, un rapport est généré. Dans le résumé, on peut voir qu’il remonte 2 inhibiteurs nous empêchant de faire la mise à jour.

Le mieux est de commencer par consulter le contenu du fichier de rapport qui a été généré dans « /var/log/leapp/leapp-report.txt ». Celui-ci fournit des informations complémentaires et remonte aussi d’autres points qui peuvent être intéressants à connaître ou à corriger (matériel non supporté par la version cible...). 

Résolution des inhibiteurs

Il va donc falloir faire les corrections nécessaires.  

Dans l'image ci-dessus, le premier inhibiteur concerne un paramètre devenu obsolète dans la configuration de firewalld et le second, l'accès distant en ssh pour "root" qui est autorisé (c'est maaaaal !!!!).

Voici une proposition de résolution de ces inhibiteurs.

Pour "firewalld", passer la valeur du paramètre "AllowZoneDrifting" à "no" soit en éditant le ficher soit grâce à la commande suivante :

sed -i "s/^AllowZoneDrifting=.*/AllowZoneDrifting=no/" /etc/firewalld/firewalld.conf

Comme je dispose d'un compte personnel pour me connecter à la machine et que je n'ai pas besoin de la connexion "root" en ssh, je modifie le fichier sshd_config en passant la valeur de "PermitRootLogin" à "no" ou ensinon commande :

sed -i "s/^PermitRootLogin yes.*/PermitRootLogin no/" /etc/ssh/sshd_config

Si vous souhaitez impérativement conserver la connexion en ssh via "root", il est indiqué d'ajouter un commentaire supplémentaire au niveau de la ligne pour que cela reste en place :

PermitRootLogin yes    #rootlogin is required        <<<<====== add a comment in same line then it gets allowed

D'autres points étaient remontés dans le rapport. Un problème avec un driver du noyau pour ip_set qui n'est plus supporté, de même pour un type de processeur... Dans mon cas, ces points ne sont pas pertinents, je les ignore donc.

Renouvelez l'opération pour vérifier que vos modifications ont résolu les inhibiteurs et les erreurs. Procédez par itération si nécessaire.

Pré-upgrade de contrôle

Une fois les modifications faites, relancez un dernier pré-upgrade :

leapp preupgrade

Vous ne devez plus avoir d'inhibiteurs ni d'erreurs.

Dans la capture ci-dessous, on constate qu'il n'y a plus de problèmes majeurs. Les autres points remontés (high, medium, low et info) correspondent à ceux que j'ai délibérément ignorés (mais par sécurité, vérifiez de votre côté). A nouveau, chaque cas est unique.

L'upgrade

Maintenant que le pré-upgrade est correct et que vous disposez d'une sauvegarde fiable de votre système, lancez la mise à jour à proprement parler : 

leapp upgrade

Cas particulier Rocky Linux

Sur une Rocky Linux, pendant l'upgrade, on peut rencontrer un conflit avec le paquet rocky-logos :

Si vous rencontrez le même problème, vous pouvez supprimer le paquet rocky-logos car il n'est pas critique. Dans tous les cas, vous pourrez le réinstaller manuellement après l'upgrade :

dnf remove -y rocky-logos

Relancez l'upgrade.

Déroulement de l'upgrade

L'upgrade devrait se terminer sans erreur et fournir un résultat comme celui ci-dessous (si ce n'est pas le cas, corrigez à nouveau les erreurs rencontrées et recommencez) :  

La première partie de l'upgrade est terminée et Leapp demande de redémarrer la machine comme indiqué.

reboot

La machine redémarre et procède à la mise à jour de la distribution, ici Rocky 9. 

Après le redémarrage, vous pouvez vérifier que votre machine a bien été mise à jour, comme indiqué ci-dessous :

Nettoyage après l'upgrade

Afin d'avoir un système le plus propre possible, nous allons procéder au nettoyage de la machine. 

Nettoyage des paquets

Lors de la mise à jour, Leapp ajoute des exclusions dans la configuration de dnf au moment de l'upgrade. Les commandes ci-dessous vous indiquent comment les visualiser et les supprimer (vous pourriez aussi éditer le fichier) :

cat /etc/dnf/dnf.conf
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False
exclude=leapp,leap-upgrade-el8toel9,python3-leapp,snactor

dnf config-manager --save --setopt exclude=''

L'étape suivante consiste si des paquets d'une ancienne version (7 ou 8) sont encore présents sur votre système. La seconde commande vous permet de les supprimer : 

rpm -qa | grep -e '\.el[78]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort
dnf remove $(rpm -qa | grep \.el[78] | grep -vE 'gpg-pubkey|libmodulemd|katello-ca-consumer')

Le travail étant terminé avec Leapp, nous pouvons donc supprimer les paquets qui lui sont liés :

dnf remove leapp-deps-el9 leapp-repository-deps-el9

Espace disque

Commencez par supprimer les répertoires utilisés par leapp :

rm -rf /var/log/leapp /root/tmp_leapp_py3 /var/lib/leap/*

J'avais précédemment créé un volume logique pour héberger le /var/lib/leapp. L'upgrade étant terminé, je n'en ai plus besoin ; je vais donc le supprimer pour pouvoir réutiliser cet espace plus tard :  

umount /var/lib/leapp/
lvremove /dev/VG_SYS/var_lib_leapp
rm -rf /var/lib/leapp

Éditer ensuite le fichier /etc/fstab pour supprimer la ligne correspondante :

et je n'oublie pas la commande :

systemctl daemon-reload

Mise à jour du chargeur de noyau

Mettez à jour les arguments de de la ligne de commande du noyau utilisé afin de ne pas rencontrer de souci lors d'une prochaine mise à jour de celui-ci :

BOOT_OPTIONS="$(tr -s "$IFS" '\n' </proc/cmdline | grep -ve '^BOOT_IMAGE=' -e '^initrd=' | tr '\n' ' ')"
echo $BOOT_OPTIONS > /etc/kernel/cmdline

Supprimez ensuite le noyau de secours existant ainsi que l'initramfs :

rm /boot/vmlinuz-*rescue* /boot/initramfs-*rescue*

Puis réinstallez le noyau de secours et l'initramfs pour disposer des bonnes versions :

/usr/lib/kernel/install.d/51-dracut-rescue.install add "$(uname -r)" /boot "/boot/vmlinuz-$(uname -r)"

Pour confirmer que ces deux étapes se sont bien déroulées, lancez les commandes suivantes  :

ls /boot/vmlinuz-*rescue* /boot/initramfs-*rescue*
lsinitrd /boot/initramfs-*rescue*.img | grep -qm1 "$(uname -r)/kernel/" && echo "OK" || echo "FAIL"

Et pour terminer cette étape, vérifier que l'entrée dans le menu grub pour le noyau de secours est correcte :

grubby --info $(ls /boot/vmlinuz-*rescue*)

Réactivation de SELinux

N'oubliez pas que Leapp a mis SELinux en mode permissif et qu'il faut donc le remettre en mode enforcing.

En première lieu, vérifiez qu'il n'y a pas d'erreurs SELinux de remontées en utilisant la commande ausearch :

ausearch -m AVC,USER_AVC -ts boot

Sinon, faites le nécessaire pour qu'elles ne soient plus présentes (les erreurs liées à leapp peuvent-être ignorées).

Modifiez ensuite le fichier de configuration /etc/selinux/config pour remplacer la valeur permissive de la clé SELINUX= par enforcing.

Redémarrez alors votre système et lancer ensuite la commande getenforce qui doit vous renvoyer la valeur Enforcing : 

getenforce
    
Enforcing

Conclusion

Vous venez de réussir la mise à jour d'une version RedHat® 8 (et apparentées) vers 9 (ici une Rocky Linux). Félicitations !!!

Chaque cas reste spécifique ; cette procédure n'a pas vocation à être exhaustive mais à vous donner les clés et étapes nécessaires pour faire la mise à jour.