J’ai récemment fleurté avec AlmaLinux pour quelques uns de mes conteneurs LXC. C’est que j’étais tombé sur un bug plutôt tannant avec Oracle Linux 8 (OL8), soit que la commande « dnf updateinfo list » me retournait des erratas erronés pour des paquetages provenant de appstream lorsque la version installée ne correspondait pas à la dernière version majeure disponible dans appstream. Par exemple, utilisant php 7.4 et étant bien à jour à « l’intérieur » de cette version, on m’indiquait des erratas pour la version 8.0, nouvellement disponible dans appstream… Plutôt gênant comme situation surtout que j’ai lu quelque part qu’Oracle ne peut rien faire pour corriger ce pépin à l’intérieur de la version 8 de OL. C’est pour cette raison, donc, avec aussi comme but secondaire d’améliorer mon karma car on sait tous qu’Oracle est « evil » 😉 , que j’ai décidé d’essayer AlmaLinux. La conversion de mon conteneur LXC Oracle vers Alma s’est bien passée mais, malheureusement, mon expérience a été de courte durée car je me suis vite rendu compte que les erratas retournés par « dnf updateinfo list » étaient très incomplets et parfois en double par rapport à ceux fournis par Oracle et Red Hat. Autrement dit, plusieurs paquetages pouvaient être disponibles pour mise à jour sans avoir de errata associé. Déçu, j’ai donc décidé de bifurquer vers Rocky Linux (toujours via l’outil de conversion officielle de la distribution de destination) pour vérifier si la situation est la même et il semblerait que ça soit le cas. Il ne me restait donc qu’un choix… L’original: Red Hat Enterprise Linux (RHEL).
Depuis un peu moins de deux ans, Red Hat a bonifié l’offre gratuite aux individus pour son système d’exploitation. Il est maintenant possible pour n’importe quel particulier de rouler, sans frais, jusqu’à 16 systèmes Red Hat Enterprise Linux (RHEL), incluant les mises à jour, pour n’importe quel usage. La raison pour laquelle RHEL était mon dernier recours est l’enregistrement annuel qu’il faut renouveler une fois celui-ci expiré. L’an dernier, j’ai dû attendre au moins 3 ou 4 jours après son expiration pour que le renouvellement fonctionne et ça m’a un peu échaudé. En plus, le OS utilise la commande subscription-manager pour gérer les abonnements et dépôts de paquetages et ça ajoute une petite couche de complexité déplaisante pour moi qui préfère les dépôts yum/dnf accessibles publiquement et configurables directement dans /etc/yum.repos.d ou via un rpm « release » qui le fait pour nous comme dans Oracle Linux, AlmaLinux ou Rocky Linux. Quoi qu’il en soit, au moins avec RHEL, chaque paquetage disponible pour mise à jour a un errata d’assigné et il n’y a aucun bug avec les erratas de appstream comme avec Oracle Linux (mentionné précédemment).
Maintenant, un problème demeure pour moi, oh grand fan par excellence de LXC et dénigreur de Docker: Red Hat ne supporte pas du tout LXC. Oui, il est possible de rouler des conteneurs LXC sur un hôte physique ou une vm RHEL via les paquetages LXC fournis par EPEL mais pour ce qui est de rouler un conteneur LXC RHEL, que ce soit sur RHEL ou une autre distribution, ça c’est en théorie proscrit puisqu’aucune image RHEL n’est disponible lors de la création d’un conteneur avec lxc-create ou même provenant de Red Hat. Par contre, un script est fourni par Red Hat pour convertir à partir d’un clone de RHEL. Jusqu’à récemment, seulement Oracle Linux et (feu) CentOS étaient compatibles, mais, depuis peu, AlmaLinux et Rocky Linux le sont également. Il est donc possible d’installer un conteneur LXC d’à peu près n’importe quel clone de RHEL puis de le convertir *facilement* en RHEL… Du moins, c’est ce que je pensais il y a quelques temps puisque je l’avais déjà fait sans tracas à partir d’Oracle Linux il y a quelques années. Malheureusement, les dernières versions du script vérifient maintenant plusieurs points, entre autres en lien avec le kernel installé et ses modules. Pour le kernel, il y a toujours moyen de l’installer sur le conteneur LXC même si ça ne sert à rien mais le problème majeur auquel je me suis buté est que le script, qui s’exécute dans le conteneur, détecte la présence du module ZFS, qui n’est pas sous licence GPL, sur mon hôte physique et refuse de poursuivre à cause de ça. Comme à peu près tout ce qui est sur mon serveur repose sur ZFS, je suis mal pris. Par chance, c’est très facile de désactiver certaines vérifications faites par le script convert2rhel. En effet, une fois le script installé, il s’agit simplement d’éditer le fichier /usr/lib/python3.6/site-packages/convert2rhel/checks.py et de commenter comme suit:
... def perform_pre_checks(): """Early checks after system facts should be added here.""" check_custom_repos_are_valid() check_convert2rhel_latest() ##check_efi() ##check_tainted_kmods() check_readonly_mounts() ##check_rhel_compatible_kernel_is_used() check_package_updates() ##is_loaded_kernel_latest() check_dbus_is_running() ... def perform_pre_ponr_checks(): """Late checks before ponr should be added here.""" ##ensure_compatibility_of_kmods() ...
Enfin, il ne reste juste qu’à exécuter le script de conversion avec les crédentiels de l’abonnement Red Hat et le tour est joué:
[root@conteneur ~]# convert2rhel -u usager -p motdepasse --no-rpm-va
Pour l’exemple, j’y suis allé avec le plus simple mais il est aussi possible d’utiliser d’autres arguments pour ne pas avoir à passer un mot de passe en clair. Sinon, il vaut mieux éditer le fichier .bash_history de l’usager utilisé après coup et enlever la ligne de commande qui mentionne le mot de passe.
Donc, voilà, il suffit de redémarrer le conteneur après coup et on a maintenant un conteneur RHEL:
[root@conteneur ~]# hostnamectl Static hostname: n/a Transient hostname: conteneur Icon name: computer-container Chassis: container Machine ID: 123abc... Boot ID: zyx456... Virtualization: lxc Operating System: Red Hat Enterprise Linux 8.7 (Ootpa) CPE OS Name: cpe:/o:redhat:enterprise_linux:8::baseos Kernel: Linux 5.15.0-5.76.5.1.el8uek.x86_64 Architecture: x86-64
Les gens cultivés pourront remarquer que mon conteneur est hébergé sur un hôte Oracle Linux puisque le champ « Kernel » indique le Unbreakable Enterprise Kernel Release 7 (UEK R7) plutôt que le kernel Red Hat officiel plus « vieillot ». Il est également à noter que le script de conversion ne marche que pour l’architecture x86_64. J’ai essayé de convertir un conteneur LXC Oracle Linux 8 aarch64 (ARM64), mais en vain. Pourtant, RHEL 8 est sensé être disponible pour aarch64 et les dépôts de paquetages auxquels j’ai tenté d’accéder existent bel et bien selon mes recherches mais il semblerait que subscription-manager ne les trouve pas. C’est peut-être une limitation de la licence développeur gratuite que j’utilise… Même en « bypassant » subscription-manager et en « hardcodant » des fichiers de dépôts yum/dnf à la main que j’utilise ensuite avec convert2rhel, j’obtiens un code d’erreur web 403 lorsque je tente d’accéder à ces dépôts. Pour ceux qui se le demandent: Non, mon conteneur Oracle Linux 8 aarch64 ne repose pas sur un « Raspberry Pi ». Il se trouve plutôt sur une vm KVM hébergée dans Oracle Cloud. On parle de 4 vcpu aarch64 et 24 Go de RAM offerts par Oracle totalement gratuitement. Ça semble trop beau pour être vrai mais, pourtant, ça fait presqu’un an que je roule ça sans problème et Oracle parle bien de « always free ».
Même si je n’ai pas eu une très longue et concluante expérience avec AlmaLinux et Rocky Linux, je vais continuer de suivre l’évolution de ces distributions qui s’affrontent pour succéder à CentOS. Néanmoins, pour l’instant, je vais m’en tenir à RHEL et Oracle Linux pour mes systèmes personnels… En plus de Debian et FreeBSD, évidemment!!