Mon choix post-CentOS : Alma Linux
Bonjour à tous,
Dans cet article, je vous explique la suite de ma réflexion sur l'abandon de CentOS 8, et de la stratégie adoptée d'un point de vue professionnel et personnel.
Contexte :
Rappel sur la décision de RH sur l'abandon de CentOS et choix de CentOS Stream : https://blog.centos.org/2020/12/future-is-centos-stream/
Le fonctionnement du développement de RHEL est présenté ainsi : https://blog.centos.org/2020/12/centos-stream-is-continuous-delivery/
Le plus problématique dans l'histoire, c'est que CentOS 8 qui devait être supportée jusqu'en 2029 (comme RHEL 8) a vu son support réduit à fin 2021. Et ça c'est pas cool car bon ... Quand on comptait sur CentOS 8 en Septembre/Octobre 2020, on comptait sur un support de 10 ans, pas 1 !
Voici donc en résumé imagé la stratégie de Red Hat :
Alors, il faut remplacer CentOS 8 avant fin 2021, sinon, plus de support !
Ma situation :
Pour rappel, j'avais expliqué ma situation ici : https://www.linuxtricks.fr/news/10-logiciels-libres/486-reflexion-sur-centos-8-que-vais-je-faire-en-entreprise-e/
J'avais dit que je prendrais ma décision courant été 2021, mais la situation professionnelle fait que nous allons avoir à partir de l'été beaucoup de travail. Il faut anticiper donc la migration des CentOS 8.
Cahier des charges :
Voici les éléments principaux de mon cahier des charges pour les serveurs du travail et perso :
- Système Linux
- Pas de coût de licence pour les serveurs où il n'est pas nécessaire d'avoir de support
- Fonctionnel et optimisé en VM
- Contient les services serveur ssh, web, ftp, etc... qui bénéficient de correctifs rapidement en cas de vulnérabilité
- Un support long pour économiser du temps administrateur (pas trop de mises à niveau)
- Sérieux sur la sécurité
- Robuste
- Fiable
- Facilement administrable par mon équipe
- De préférence une flexibilité sur les versions des logiciels
Les systèmes connus et candidats pour répondre au cahier des charges :
- Windows Server 2019 - WS
- Debian 10 - DEB
- Fedora 33 - FED
- Ubuntu 20.04 - UBU
- RHEL 8 Developer - RHEL
- CentOS 8 Stream - COS
- Alma Linux 8 - ALMA
- Rocky Linux ? - RL
- Oracle Linux - OL
- Gentoo - GEN
- Calculate Linux - CL
- Open Suse Leap - OSL
Dans la liste, j'ai inclus WS, car c'est une alternative et nous avons une licence globale permettant d'installer autant de WS en édition Datacenter qu'on veut pour le même prix sur nos VXRail. Cependant, lorsqu'il n'y a pas de besoin impératif de faire fonctionner un service Windows, je pars sur du Linux. Pour la fiabilité, la sécurité, et l'économie de ressources sur un système nu.
Réflexion sur la sélection du système :
Bien que je sois plus à l'aise avec les bases RedHat et Gentoo, ce critère n'est pas éliminatoire concernant les alternatives mentionnées. Les bases Debian et Suse font donc aussi partie du cahier des charges. Je ne veux pas choisir un système parce que MOI je l’apprécie, mais bien parce qu'il respecte le cahier des charges !
Nous partons d'une liste contenant : DEB - FED - UBU - RHEL - COS - ALMA - RL - OL - GEN - CL - OSL.
De cette liste, j'élimine dans un premier temps Fedora. Le cycle de vie est trop court pour l'utilisation que j'en ai. La montée trop rapide en version des composants de base (PHP, PERL, Python, par exemple) nécessite une adaptation trop rapide des applications, ce qui est compliqué dans le monde professionnel.
Petit aparté, on a toujours des applis tournant sous XP ou 7, car non compatible avec d'autres systèmes Windows plus récents. Evidemment, ils sont isolés du réseau ou isolés dans un VLAN avec les seuls flux strictement nécessaires autorisés.
La liste se réduit donc à : DEB - UBU - RHEL - COS - ALMA - RL - OL - GEN - CL - OSL.
Debian, possède un support de 5 ans, trop court à mon gout. Il n'y a pas de flexibilité sur la gestion des version des logiciels.
Si nous prenons par exemple Debian 10, PHP est fourni en 7.3 et l'installation d'une autre version nécessite un dépôt additionnel non supporté officiellement.
Ubuntu rentre dans les mêmes critères de sélection. Il existe bien la possibilité d'avoir un support à 10 ans avec Ubuntu mais il est soumis à licence (et c'est pas donné).
La liste se réduit donc à : RHEL - COS - ALMA - RL - OL - GEN - CL - OSL.
Concernant Gentoo, bien que j'apprécie ce système et qu'il soit utilisé sur mon serveur à la maison, c'est non car trop consommateur de ressources sur une virtualisation. Le cas Calculate Linux est intéressant car on n'a pas cette notion de durée de cycle de vie. Cependant, le système étant peu connu et complexe à administrer car le monde Gentoo n'est pas enseigné, donc c'est non (vis à vis de mon équipe qui n'est pas experte Linux). Le deuxième problème est le même que Fedora : la monté des versions des composants de base qui peuvent poser problème. Le monde Gentoo supprime vite ce qui n'est plus supporté ! (Qt4 a été dégagé très vite, python2 aussi là où certaines distribution l'utilisent encore). Certes d'un point de vue sécurité c'est bien mais si on casse la moitié des applications : non. Cependant, mon serveur Dell (physique) de tests au boulot est sous Gentoo et ma propre VM d'administration sous Calculate. Seul moi utilise ces 2 systèmes.
La liste se réduit donc à : RHEL - COS - ALMA - RL - OL - OSL.
OpenSuse est intéressante, car derrière, on a Suse, mais c'est la version communautaire, donc le cout de licence est nul, mais on a une stabilité derrière. Le cycle de vie est court. Même si la mise à niveau (exemple 15.1 vers 15.2) n'est pas aussi transparente que dans le monde Red Hat (tous les paquets sont réinstallés) ça semble plutôt stable. Yast est un couteau suisse pour paramétrer le système. Cependant, je suis toujours hésitant quand on doit faire une mises à niveau, surtout quand elle réinstalle beaucoup de choses. D'autant plus que même sur une évolution mineure, certains composants évoluent et on ne sait pas comment ça peut se comporter (nouvelle version de noyau par exemple). Sans oublier que l'emplacement de certains fichiers de configuration n'est pas là où on les trouve chez d'autres distributions (non standard). Ca me rend hésitant et me fait écarter cette distribution.
La liste se réduit donc à : RHEL - COS - ALMA - RL - OL
Finalement, il ne reste que Red Hat Enterprise Linux et ses dérivées. Alors comment choisir ?
La version gratuite de RHEL ne permet que 16 licences. C'est suffisant pour mon utilisation. Cependant, renouveler celles-ci tous les ans, ça va être pénible. Le portail RedHat est séduisant et la possibilité de l'utiliser avec la version développeur c'est cool. Mais c'est une version "développeur" !! Cette licence permet uniquement d'utiliser RHEL sur la durée de vie "Full support" donc 5 ans ! On reviens à la case dép...Debian !
Pour CentOS Stream, elle est en amont du projet RHEL, je la considère un peu comme une sorte de Béta de la RHEL donc potentiellement moins stable, et surtout on a aussi une durée de vie du produit d'environ 5 ans. Le projet est flou encore aujourd'hui. On ne sait pas si on passera de Stream 8 à 9 par un simple dnf upgrade, et l'incertitude ne me plait pas.
La liste se réduit donc à : ALMA - RL - OL
Sur ces 3 dernières, Alma Linux, Rocky Linux et Oracle Linux, on a beaucoup de points communs. Elles sont basées sur RHEL, et donc ont tous les avantages de cette dernière.
Rocky Linux n'est pas encore sortie (note avant publication, la RC est sortie le 1er Mai). Et même si elle était sortie début Avril, je ne l'aurais pas choisie. Le projet semble bon, mais il est trop jeune. Il est donc difficile d'utiliser un tel projet en production sans le recul nécessaire. Même si l'équipe était déjà impliquée dans CentOS, je suis toujours très prudent.
Il ne reste donc plus qu'Oracle Linux et Alma Linux.
Toutes les 2 sorties au moment où je vous écrit. Et mon choix s'est porté sur Alma Linux, mais j'ai longuement hésité entre les 2 pour ne pas vous le cacher. Les 2 distributions remplissent tous les critères.
Oracle existe depuis très longtemps, et je fais abstraction de la société qui est derrière. En effet le produit existe quand même depuis ... 2007, la première version était basée sur RHEL4. Elle dispose d'un kernel "UEK" spécial, dit incassable. Il est plus récent que celui de RHEL (5.4 contre 4.18 pour EL8). Elle m'a donné pleine satisfaction sur mon serveur de supervision Zabbix au travail, avec une bonne charge et grande fiabilité. Cependant, en étudiant de manière plus poussée Oracle Linux, elle dispose de son propre dépôt EPEL, et cela cause des petits dysfonctionnements, ne la rendant pas compatible à 100% comme l'était CentOS.
Alma Linux existe certes que depuis 2021, mais derrière se cache l'équipe de Cloud Linux. Et Cloud Linux OS, c'est une distribution qui existe depuis 2010 et basée sur CentOS. Elle est utilisée dans le monde professionnel et de l'hébergement. Cette équipe a donc totalement connaissance du monde professionnel et de la haute disponibilité, cochant ainsi toutes les cases de mon cahier des charges.
C'est donc ainsi que j'ai sélectionné Alma Linux !
Alma Linux : Détail
Voici le descriptif de la distribution sur le site d'Alma Linux : AlmaLinux is a Linux distribution based on Red Hat Enterprise Linux and maintained by CloudLinux, a company that provides server hosting and Linux software.
La première version est sortie le 30 Mars 2021; mais j'ai testé ce système en détails dès la publication de la Beta (Distribution, Migration depuis CentOS 8 et Oracle Linux 8). Comme dit précédemment, derrière se cache l'équipe de Cloud Linux. Donc c'est un projet jeune, mais avec une équipe qui a de la bouteille.
Vu que Cloud Linux OS se base sur CentOS, il faut donc une nouvelle base pour eux, et ils ont donc créé Alma Linux. Elle est 100% compatible CentOS ! Et ça c'est très intéressant. Pour installer le dépôt EPEL, sur CentOS, on faisait :
C'est un paquet rajouté sur CentOS, qu'on n'a pas sur Red Hat Enterprise Linux. Et bien chez Alma, c'est pareil. Donc 100% des tutos CentOS s'appliquent sur Alma Linux sans aucune modification.
Il reste cependant une interrogation sur le dépôt EPEL, quelle sera sa durée de vie, 5 ans (CentOS Stream) ou 10 ans (RHEL) ? Je pense que ça sera maintenu sur la durée de vie de RHEL, soit 10 ans.
Dans tous les cas, ce que j'installe depuis EPEL, ce ne sont jamais des éléments critiques ! Ce sont des outils tels que nmon, screen, htop, qui ne sont donc pas sujets à de graves dysfonctionnements ou vulnérabilités (comme un kernel, openssi par exemple).
L'équipe travaille déjà sur la Béta 8.4, RHEL est sur la voie 8.4 aussi. On a une équipe plutôt réactive !
Le processus de migration est entamé :
D'un point de vue professionnel :
Il s'avère que tout s'est bien passé dans mes tests. Dans les scénario, j'ai utilisé plusieurs CentOS 8 avec divers éléments installés dessus, tels que des serveurs web (Apache + PHP), bases de données (MariaDB), serveurs de fichiers (Samba), serveurs applicatifs (Zabbix, GLPI, OCS). Ce sont des copies de machines de production où j'ai fait mes tests.
J'ai rencontré 2 anomalies sur le processus de migration, que j'ai remontées à l'équipe Alma Linux pour correction du script.
Quand j'ai pu réinstaller proprement, je l'ai fait évidemment !!
Dans la boite où je suis DSI, je m'occupe de l'administration des serveurs Linux. Actuellement, au moment où je rédige cet article, le 1er Mai 2021, voici l'état des distributions utilisées :
Dans les serveurs Linux :
- AlmaLinux : 6
- CentOS : 3
- Red Hat Enterprise Linux : 2 (Version 5.X, idem que 2008R2, sur VLAN isolé)
- Oracle Linux 8 : 0
- Debian 10 : 3 (+ 1 Debian 7)
- Fedora Server : 2 (Applications serveur métier fournies par les prestataires)
- Ubuntu : 1 (Application pilotant un automate)
Les AlmaLinux sont des versions 8.3. Les services tournant sur les AlmaLinux en production sont Apache/PHP/MariaDB, Zabbix, GLPI, OCS. Zabbix est migré d'Oracle Linux à Alma Linux.
La répartition des CentOS c'est :
- CentOS 7 : 2 (1 samba chaud à migrer et 1 LAMP qui fait tourner des applis non compatible PHP 7.x).
- CentOS 8 : 1 (le DHCP/DNS qui concerne les machines non connectées à l'AD, trop sensible pour migrer pour le moment)
D'un point de vue personnel :
Pour Linuxtricks, le serveur est hébergé chez IONOS : J'ai opté pour une nouvelle machine Alma Linux le Mercredi 28 Avril et migré le site dans la soirée.
Interruption de service de 5 minutes le temps de couper httpd sur l'ancienne machine, backupper, transférer sur le nouveau serveur site et base de données, et de rallumer le tout. Ayant auparavant préparé tout le terrain sur la machine Alma Linux (Apache, MariaDB, Vhosts, Pare-Feu, Scripts, ...) avant de couper le site, finalement l'interruption fût courte.
J'aurais pu backupper à chaud, importer et basculer le DNS pour que ce soit transparent, mais non. Mon CMS PHPBoost met dans sa base des infos sur les connexions, écrit des données dans /cache du CMS, je voulais donc un état cohérent de l'ensemble.
Et pour l'hébergé à la maison : Gentoo ça ne change pas, la machine n'est pas virtualisée, elle a le transmetteur FM pour diffuser mes playlists dans la maison sur les différentes chaines Hi-Fi, radio réveil, donc je peux laisser ma distribution préférée dessus.
Quelques ressources :
Alma Linux : https://almalinux.org
Distrowatch Alma : https://distrowatch.com/table.php?distribution=alma
GitHub : https://github.com/AlmaLinux
Migration d'Alma : https://github.com/AlmaLinux/almalinux-deploy
Pour les ISOS, il en existe 3, comme RHEL :
AlmaLinux-8.3-x86_64-boot.iso => Pour une installation par le réseau
AlmaLinux-8.3-x86_64-dvd.iso => Le DVD complet
AlmaLinux-8.3-x86_64-minimal.iso => Pour une installation minimale d'Alma Linux
Il a été annoncé ce 1er Mai la disponibilité d'Alma Linux 8.4 Béta. l'équipe est réactive et suit de très près le fil de ce que fait RHEL.
J'espère que cet article vous a plu sur mon expérience, le cheminement de ma réflexion sur la suite apportée à CentOS 8 !
Dans cet article, je vous explique la suite de ma réflexion sur l'abandon de CentOS 8, et de la stratégie adoptée d'un point de vue professionnel et personnel.
Contexte :
Rappel sur la décision de RH sur l'abandon de CentOS et choix de CentOS Stream : https://blog.centos.org/2020/12/future-is-centos-stream/
Le fonctionnement du développement de RHEL est présenté ainsi : https://blog.centos.org/2020/12/centos-stream-is-continuous-delivery/
Le plus problématique dans l'histoire, c'est que CentOS 8 qui devait être supportée jusqu'en 2029 (comme RHEL 8) a vu son support réduit à fin 2021. Et ça c'est pas cool car bon ... Quand on comptait sur CentOS 8 en Septembre/Octobre 2020, on comptait sur un support de 10 ans, pas 1 !
Voici donc en résumé imagé la stratégie de Red Hat :
Alors, il faut remplacer CentOS 8 avant fin 2021, sinon, plus de support !
Ma situation :
Pour rappel, j'avais expliqué ma situation ici : https://www.linuxtricks.fr/news/10-logiciels-libres/486-reflexion-sur-centos-8-que-vais-je-faire-en-entreprise-e/
J'avais dit que je prendrais ma décision courant été 2021, mais la situation professionnelle fait que nous allons avoir à partir de l'été beaucoup de travail. Il faut anticiper donc la migration des CentOS 8.
Cahier des charges :
Voici les éléments principaux de mon cahier des charges pour les serveurs du travail et perso :
- Système Linux
- Pas de coût de licence pour les serveurs où il n'est pas nécessaire d'avoir de support
- Fonctionnel et optimisé en VM
- Contient les services serveur ssh, web, ftp, etc... qui bénéficient de correctifs rapidement en cas de vulnérabilité
- Un support long pour économiser du temps administrateur (pas trop de mises à niveau)
- Sérieux sur la sécurité
- Robuste
- Fiable
- Facilement administrable par mon équipe
- De préférence une flexibilité sur les versions des logiciels
Les systèmes connus et candidats pour répondre au cahier des charges :
- Windows Server 2019 - WS
- Debian 10 - DEB
- Fedora 33 - FED
- Ubuntu 20.04 - UBU
- RHEL 8 Developer - RHEL
- CentOS 8 Stream - COS
- Alma Linux 8 - ALMA
- Rocky Linux ? - RL
- Oracle Linux - OL
- Gentoo - GEN
- Calculate Linux - CL
- Open Suse Leap - OSL
Dans la liste, j'ai inclus WS, car c'est une alternative et nous avons une licence globale permettant d'installer autant de WS en édition Datacenter qu'on veut pour le même prix sur nos VXRail. Cependant, lorsqu'il n'y a pas de besoin impératif de faire fonctionner un service Windows, je pars sur du Linux. Pour la fiabilité, la sécurité, et l'économie de ressources sur un système nu.
Réflexion sur la sélection du système :
Bien que je sois plus à l'aise avec les bases RedHat et Gentoo, ce critère n'est pas éliminatoire concernant les alternatives mentionnées. Les bases Debian et Suse font donc aussi partie du cahier des charges. Je ne veux pas choisir un système parce que MOI je l’apprécie, mais bien parce qu'il respecte le cahier des charges !
Nous partons d'une liste contenant : DEB - FED - UBU - RHEL - COS - ALMA - RL - OL - GEN - CL - OSL.
De cette liste, j'élimine dans un premier temps Fedora. Le cycle de vie est trop court pour l'utilisation que j'en ai. La montée trop rapide en version des composants de base (PHP, PERL, Python, par exemple) nécessite une adaptation trop rapide des applications, ce qui est compliqué dans le monde professionnel.
Petit aparté, on a toujours des applis tournant sous XP ou 7, car non compatible avec d'autres systèmes Windows plus récents. Evidemment, ils sont isolés du réseau ou isolés dans un VLAN avec les seuls flux strictement nécessaires autorisés.
La liste se réduit donc à : DEB - UBU - RHEL - COS - ALMA - RL - OL - GEN - CL - OSL.
Debian, possède un support de 5 ans, trop court à mon gout. Il n'y a pas de flexibilité sur la gestion des version des logiciels.
Si nous prenons par exemple Debian 10, PHP est fourni en 7.3 et l'installation d'une autre version nécessite un dépôt additionnel non supporté officiellement.
Ubuntu rentre dans les mêmes critères de sélection. Il existe bien la possibilité d'avoir un support à 10 ans avec Ubuntu mais il est soumis à licence (et c'est pas donné).
La liste se réduit donc à : RHEL - COS - ALMA - RL - OL - GEN - CL - OSL.
Concernant Gentoo, bien que j'apprécie ce système et qu'il soit utilisé sur mon serveur à la maison, c'est non car trop consommateur de ressources sur une virtualisation. Le cas Calculate Linux est intéressant car on n'a pas cette notion de durée de cycle de vie. Cependant, le système étant peu connu et complexe à administrer car le monde Gentoo n'est pas enseigné, donc c'est non (vis à vis de mon équipe qui n'est pas experte Linux). Le deuxième problème est le même que Fedora : la monté des versions des composants de base qui peuvent poser problème. Le monde Gentoo supprime vite ce qui n'est plus supporté ! (Qt4 a été dégagé très vite, python2 aussi là où certaines distribution l'utilisent encore). Certes d'un point de vue sécurité c'est bien mais si on casse la moitié des applications : non. Cependant, mon serveur Dell (physique) de tests au boulot est sous Gentoo et ma propre VM d'administration sous Calculate. Seul moi utilise ces 2 systèmes.
La liste se réduit donc à : RHEL - COS - ALMA - RL - OL - OSL.
OpenSuse est intéressante, car derrière, on a Suse, mais c'est la version communautaire, donc le cout de licence est nul, mais on a une stabilité derrière. Le cycle de vie est court. Même si la mise à niveau (exemple 15.1 vers 15.2) n'est pas aussi transparente que dans le monde Red Hat (tous les paquets sont réinstallés) ça semble plutôt stable. Yast est un couteau suisse pour paramétrer le système. Cependant, je suis toujours hésitant quand on doit faire une mises à niveau, surtout quand elle réinstalle beaucoup de choses. D'autant plus que même sur une évolution mineure, certains composants évoluent et on ne sait pas comment ça peut se comporter (nouvelle version de noyau par exemple). Sans oublier que l'emplacement de certains fichiers de configuration n'est pas là où on les trouve chez d'autres distributions (non standard). Ca me rend hésitant et me fait écarter cette distribution.
La liste se réduit donc à : RHEL - COS - ALMA - RL - OL
Finalement, il ne reste que Red Hat Enterprise Linux et ses dérivées. Alors comment choisir ?
La version gratuite de RHEL ne permet que 16 licences. C'est suffisant pour mon utilisation. Cependant, renouveler celles-ci tous les ans, ça va être pénible. Le portail RedHat est séduisant et la possibilité de l'utiliser avec la version développeur c'est cool. Mais c'est une version "développeur" !! Cette licence permet uniquement d'utiliser RHEL sur la durée de vie "Full support" donc 5 ans ! On reviens à la case dép...Debian !
Pour CentOS Stream, elle est en amont du projet RHEL, je la considère un peu comme une sorte de Béta de la RHEL donc potentiellement moins stable, et surtout on a aussi une durée de vie du produit d'environ 5 ans. Le projet est flou encore aujourd'hui. On ne sait pas si on passera de Stream 8 à 9 par un simple dnf upgrade, et l'incertitude ne me plait pas.
La liste se réduit donc à : ALMA - RL - OL
Sur ces 3 dernières, Alma Linux, Rocky Linux et Oracle Linux, on a beaucoup de points communs. Elles sont basées sur RHEL, et donc ont tous les avantages de cette dernière.
Rocky Linux n'est pas encore sortie (note avant publication, la RC est sortie le 1er Mai). Et même si elle était sortie début Avril, je ne l'aurais pas choisie. Le projet semble bon, mais il est trop jeune. Il est donc difficile d'utiliser un tel projet en production sans le recul nécessaire. Même si l'équipe était déjà impliquée dans CentOS, je suis toujours très prudent.
Il ne reste donc plus qu'Oracle Linux et Alma Linux.
Toutes les 2 sorties au moment où je vous écrit. Et mon choix s'est porté sur Alma Linux, mais j'ai longuement hésité entre les 2 pour ne pas vous le cacher. Les 2 distributions remplissent tous les critères.
Oracle existe depuis très longtemps, et je fais abstraction de la société qui est derrière. En effet le produit existe quand même depuis ... 2007, la première version était basée sur RHEL4. Elle dispose d'un kernel "UEK" spécial, dit incassable. Il est plus récent que celui de RHEL (5.4 contre 4.18 pour EL8). Elle m'a donné pleine satisfaction sur mon serveur de supervision Zabbix au travail, avec une bonne charge et grande fiabilité. Cependant, en étudiant de manière plus poussée Oracle Linux, elle dispose de son propre dépôt EPEL, et cela cause des petits dysfonctionnements, ne la rendant pas compatible à 100% comme l'était CentOS.
Alma Linux existe certes que depuis 2021, mais derrière se cache l'équipe de Cloud Linux. Et Cloud Linux OS, c'est une distribution qui existe depuis 2010 et basée sur CentOS. Elle est utilisée dans le monde professionnel et de l'hébergement. Cette équipe a donc totalement connaissance du monde professionnel et de la haute disponibilité, cochant ainsi toutes les cases de mon cahier des charges.
C'est donc ainsi que j'ai sélectionné Alma Linux !
Alma Linux : Détail
Voici le descriptif de la distribution sur le site d'Alma Linux : AlmaLinux is a Linux distribution based on Red Hat Enterprise Linux and maintained by CloudLinux, a company that provides server hosting and Linux software.
La première version est sortie le 30 Mars 2021; mais j'ai testé ce système en détails dès la publication de la Beta (Distribution, Migration depuis CentOS 8 et Oracle Linux 8). Comme dit précédemment, derrière se cache l'équipe de Cloud Linux. Donc c'est un projet jeune, mais avec une équipe qui a de la bouteille.
Vu que Cloud Linux OS se base sur CentOS, il faut donc une nouvelle base pour eux, et ils ont donc créé Alma Linux. Elle est 100% compatible CentOS ! Et ça c'est très intéressant. Pour installer le dépôt EPEL, sur CentOS, on faisait :
Code BASH :
dnf install epel-releaseC'est un paquet rajouté sur CentOS, qu'on n'a pas sur Red Hat Enterprise Linux. Et bien chez Alma, c'est pareil. Donc 100% des tutos CentOS s'appliquent sur Alma Linux sans aucune modification.
Il reste cependant une interrogation sur le dépôt EPEL, quelle sera sa durée de vie, 5 ans (CentOS Stream) ou 10 ans (RHEL) ? Je pense que ça sera maintenu sur la durée de vie de RHEL, soit 10 ans.
Dans tous les cas, ce que j'installe depuis EPEL, ce ne sont jamais des éléments critiques ! Ce sont des outils tels que nmon, screen, htop, qui ne sont donc pas sujets à de graves dysfonctionnements ou vulnérabilités (comme un kernel, openssi par exemple).
L'équipe travaille déjà sur la Béta 8.4, RHEL est sur la voie 8.4 aussi. On a une équipe plutôt réactive !
Le processus de migration est entamé :
D'un point de vue professionnel :
Il s'avère que tout s'est bien passé dans mes tests. Dans les scénario, j'ai utilisé plusieurs CentOS 8 avec divers éléments installés dessus, tels que des serveurs web (Apache + PHP), bases de données (MariaDB), serveurs de fichiers (Samba), serveurs applicatifs (Zabbix, GLPI, OCS). Ce sont des copies de machines de production où j'ai fait mes tests.
J'ai rencontré 2 anomalies sur le processus de migration, que j'ai remontées à l'équipe Alma Linux pour correction du script.
Quand j'ai pu réinstaller proprement, je l'ai fait évidemment !!
Dans la boite où je suis DSI, je m'occupe de l'administration des serveurs Linux. Actuellement, au moment où je rédige cet article, le 1er Mai 2021, voici l'état des distributions utilisées :
Dans les serveurs Linux :
- AlmaLinux : 6
- CentOS : 3
- Red Hat Enterprise Linux : 2 (Version 5.X, idem que 2008R2, sur VLAN isolé)
- Oracle Linux 8 : 0
- Debian 10 : 3 (+ 1 Debian 7)
- Fedora Server : 2 (Applications serveur métier fournies par les prestataires)
- Ubuntu : 1 (Application pilotant un automate)
Les AlmaLinux sont des versions 8.3. Les services tournant sur les AlmaLinux en production sont Apache/PHP/MariaDB, Zabbix, GLPI, OCS. Zabbix est migré d'Oracle Linux à Alma Linux.
La répartition des CentOS c'est :
- CentOS 7 : 2 (1 samba chaud à migrer et 1 LAMP qui fait tourner des applis non compatible PHP 7.x).
- CentOS 8 : 1 (le DHCP/DNS qui concerne les machines non connectées à l'AD, trop sensible pour migrer pour le moment)
D'un point de vue personnel :
Pour Linuxtricks, le serveur est hébergé chez IONOS : J'ai opté pour une nouvelle machine Alma Linux le Mercredi 28 Avril et migré le site dans la soirée.
Interruption de service de 5 minutes le temps de couper httpd sur l'ancienne machine, backupper, transférer sur le nouveau serveur site et base de données, et de rallumer le tout. Ayant auparavant préparé tout le terrain sur la machine Alma Linux (Apache, MariaDB, Vhosts, Pare-Feu, Scripts, ...) avant de couper le site, finalement l'interruption fût courte.
J'aurais pu backupper à chaud, importer et basculer le DNS pour que ce soit transparent, mais non. Mon CMS PHPBoost met dans sa base des infos sur les connexions, écrit des données dans /cache du CMS, je voulais donc un état cohérent de l'ensemble.
Et pour l'hébergé à la maison : Gentoo ça ne change pas, la machine n'est pas virtualisée, elle a le transmetteur FM pour diffuser mes playlists dans la maison sur les différentes chaines Hi-Fi, radio réveil, donc je peux laisser ma distribution préférée dessus.
Quelques ressources :
Alma Linux : https://almalinux.org
Distrowatch Alma : https://distrowatch.com/table.php?distribution=alma
GitHub : https://github.com/AlmaLinux
Migration d'Alma : https://github.com/AlmaLinux/almalinux-deploy
Pour les ISOS, il en existe 3, comme RHEL :
AlmaLinux-8.3-x86_64-boot.iso => Pour une installation par le réseau
AlmaLinux-8.3-x86_64-dvd.iso => Le DVD complet
AlmaLinux-8.3-x86_64-minimal.iso => Pour une installation minimale d'Alma Linux
Il a été annoncé ce 1er Mai la disponibilité d'Alma Linux 8.4 Béta. l'équipe est réactive et suit de très près le fil de ce que fait RHEL.
J'espère que cet article vous a plu sur mon expérience, le cheminement de ma réflexion sur la suite apportée à CentOS 8 !