Conteneur LXC AlmaLinux 10 x86-64-v2

Note: Cet article s’adresse à ceux ayant de l’expérience avec l’administration de système et particulièrement avec Linux et les conteneurs LXC

Utilisant un dérivé de Red Hat Enterprise Linux (RHEL) depuis longtemps sur mon serveur physique principal, j’étais enthousiaste de voir si la mise à jour à la version 10, sortie en mai 2025, allait bien se passer. Malheureusement, ma fébrilité ne fut que de courte durée puisque je pris connaissance de l’impossibilité de rouler RHEL 10 sur du vieux matériel incompatible avec x86-64-v3 comme le mien et, ce, aussi bien avec RHEL 10 qu’avec Rocky Linux 10 ou Oracle Linux 10. Par contre, l’équipe d’AlmaLinux ont décidé de produire une version de leur dernier système d’exploitation compatible avec x86-64-v2. Hourra!! Cette possibilité allait peut-être sauver la présence d’une distribution basée sur RHEL sur mon serveur Linux principal, puisqu’il aurait été hors de question que je me magasine du nouveau matériel uniquement que pour rouler la dernière version de RHEL. Sans ça donc, j’imagine que j’aurais opté pour Debian ou Ubuntu. Tout en sachant qu’aucune image de conteneur LXC AlmaLinux 10.x x86-64-v2 n’était disponible sur https://images.linuxcontainers.org, je décidai quand même de procéder avec l’installation « from scratch » (la seule option possible avec la version x86-64-v2) sur mon serveur physique principal d’AlmaLinux 10, distribution à laquelle je m’étais brièvement intéressé dans le passé, mais à partir de laquelle je revenais toujours à mon dérivé de RHEL préféré, soit Oracle Linux.

L’installation et la configuration initiale (aidée par mes playbooks Ansible) allèrent de bon train et je fus rapidement fonctionnel avec cette toute dernière version. Par contre, j’allais être destiné à ne rouler que des conteneurs LXC Debian à long terme si je ne pouvais pas aider à faire en sorte que les images LXC officielles incluent une version x86-64-v2. Quelqu’un eu la même idée que moi semble-t-il puisque je finis par tomber sur ce rapport de bug , auquel je pris pars, tout comme un responsable des images LXC et qui fit de son mieux pour créer une image x86-64-v2 proprement. Malheureusement, il ne réussi pas à procéder avec cette tâche mais m’envoya un lien vers le log du logiciel Jenkins, utilisé pour la fabrication d’images semble-t-il. J’ai pu consulter ce log brièvement sans réaliser que j’allais rapidement trouver la recette toute simple pour créer, enfin, une image de la toute dernière version d’AlmaLinux en mode « vintage ».

Le log mentionnait une ligne ressemblant à ceci:

dnf --nogpgcheck --installroot=/rootfs --releasever=10 --skip-broken install basesystem almalinux-release yum NetworkManager

… et, un peu plus loin, précisait qu’il fallait créer le fichier /rootfs/etc/NetworkManager/conf.d/dhcp-client.conf suivant avec ce contenu:

[main]
dhcp=internal

Étant donné que j’avais déjà un serveur physique AlmaLinux à la « bonne » version, ça avait du sens de rouler la commande « dnf » indiquée sur celui-ci. J’avais juste à monter un dataset ZFS sur /rootfs et procéder avec les deux manipulations en question pour obtenir une image « faite maison » du système désiré. Évidemment, jai dû me baser sur la configuration LXC d’un autre de mes conteneurs, en gardant la plupart des éléments, sauf pour l’adresse MAC évidemment ainsi que les deux occurrences du paramètre liés à la configuration d’un conteneur non-privilégié (« lxc.idmap »). Ma surprise fut gigantesque quand je tentai pour la première fois de démarrer ce conteneur et que je réalise que ça marche!! La seule affaire qui manquait était l’aspect de non-privilégié du conteneur. Pour l’instant donc, j’avais un conteneur privilégié, soit que le UID 0 dans le conteneur est vu comme le UID 0 sur l’hôte physique… J’étais hautement satisfait de ma découverte mais, pour être complètement satisfait, j’allais devoir palier à ce dernier problème…

Pour résoudre le problème, je décidai donc de créer moi-même un petit script. En théorie, ça n’allait pas être si compliqué que ça, mais il y eu néanmoins quelques embuches. La première fut la nécessité d’inclure le flag « -h » au « chown » utilisé pour faire le changement de propriétaire et de groupe. Sans ce flag et lorsqu’un lien symbolique est visé par le « chown », c’est la destination du lien symbolique qui change plutôt que le lien symbolique lui-même. Si cette destination est un emplacement absolu (commençant par un « / »), l’action modifie donc le système où la commande est lancée plutôt que celui visé initialement, ce qui n’est absolument pas ce qu’on veut. Inclure le « -h » fait travailler le « chown » sur le dit lien symbolique lui-même contenu dans le dossier où repose le système cible. La deuxième embuche à laquelle je me suis buté consiste à la préservation des setuid/setgid. En effet, ces deux attributs disparaissent d’un fichier lorsque celui-ci change de propriétaire et/ou de groupe. Il faut donc penser à les ré-appliquer selon trois méthodes, soit lorsqu’il y a un setuid, lorsqu’il y a plutôt un setgid et lorsque ces deux attributs sont là en même temps.

Voici donc le script en question (renommez l’extension de .txt à .sh).

L’équipe d’AlmaLinux ont frappé dans le mille avec cette décision d’inclure x86-64-v2 comme architecture compatible avec leur système d’exploitation le plus récent. Premièrement, parce qu’ils ont été les seuls responsables d’une distribution Linux basée sur RHEL à le faire donc ça leur donne de la visibilité pour tous ces gens qui, comme moi, sont très heureux de garder leur vieux matériel longtemps et qui sont des fidèles de RHEL et/ou de ses clones. Mais, et ce deuxième point est beaucoup plus important, cette décision de leur part contribue à préserver l’environnement et ses ressources finies en diminuant les changements de matériel informatique dûs à une obsolescence artificielle et imposée par Red Hat. Personnellement, je leur lève mon chapeau (rouge) et je dis au monde que j’ai enfin trouvé un clone de RHEL qui me parle pour vrai et qui est moins « evil » que Oracle.