Installation d’AlmaLinux 10 : Linux d’entreprise avec une voie de mise à niveau propre

Pourquoi AlmaLinux 10 (et ce que vous choisissez vraiment)

AlmaLinux est une distribution Enterprise Linux visant la compatibilité avec l’écosystème RHEL. En langage opérationnel : vous obtenez les conventions de packaging, les comportements systemd, les valeurs par défaut SELinux et la mémoire opérationnelle des administrateurs sur lesquelles les entreprises se standardisent. Cela compte plus que le logo.

La vraie valeur d’AlmaLinux 10 n’est pas « gratuit ». C’est la prévisibilité. Flux de démarrage prévisible (UEFI), posture de sécurité prévisible (SELinux activé), outils de mise à jour prévisibles (DNF), schémas de cycle de vie prévisibles (les mises à niveau majeures sont des événements, les mises à jour mineures sont de la maintenance).

Mais la compatibilité a deux faces. Si vous l’installez comme une distribution de loisir — système de fichiers géant unique, aucune réflexion sur /var, aucun plan pour l’UEFI, aucune configuration de base — alors chaque incident « mineur » devient un combat total.

Voici une position assumée : installez AlmaLinux 10 comme si vous prévoyiez de l’exploiter pendant 5–10 ans. Si vous ne pouvez pas vous engager là-dessus, mettez-le dans un conteneur ou choisissez quelque chose que vous êtes prêt à reconstruire fréquemment.

Faits intéressants et contexte historique (pour ne pas répéter l’histoire)

• Les clones Enterprise Linux étaient autrefois « installer et oublier ». Puis des changements de politique en amont ont fait de la « stratégie clone » une question au niveau du conseil d’administration, pas un hobby de nerd.
• UEFI est devenu l’histoire de démarrage par défaut parce que le démarrage BIOS est essentiellement une pièce de musée qui alimente encore votre système de paie.
• SELinux est passé de « désactivez-le » à « il nous a sauvés ». Les outils modernes de politique et de meilleurs réglages ont fait de l’état enforcing la base raisonnable à nouveau.
• DNF a remplacé YUM pour corriger la résolution des dépendances et les problèmes de performance ; la commande « yum » est aujourd’hui principalement une couche de compatibilité.
• systemd a gagné parce qu’une gestion de services cohérente vaut mieux qu’un millier de scripts init artisanaux, surtout lors des pannes.
• Les paramètres par défaut d’OpenSSH se sont durcis (algorithmes, attentes sur la connexion root). Les anciennes configurations « tout autoriser » deviennent des bloqueurs lors des mises à jour.
• XFS est devenu le système de fichiers d’entreprise par défaut pour les performances sur gros volumes et la cohérence ; ext4 reste correct, mais les valeurs par défaut comptent.
• Kickstart et les installations PXE sont devenues la manière adulte de construire des flottes parce que les « opérations par clic » ne montent ni en charge ni en audit.

Une idée paraphrasée du monde de la fiabilité qui mérite d’être collée à votre écran : idée paraphrasée — « L’espoir n’est pas une stratégie », attribuée au général Gordon R. Sullivan. En ops, « nous nous souviendrons des étapes d’installation » est de l’espoir avec des étapes en plus.

Blague n°1 : Si votre seule sauvegarde est « on peut réinstaller », félicitations — vous venez d’inventer la reprise après sinistre basée sur les intuitions.

Décisions importantes avant de cliquer sur « Begin Installation »

1) UEFI + Secure Boot : décidez délibérément

UEFI doit être votre choix par défaut sauf si vous êtes coincé sur du matériel ancien. Pour Secure Boot, soyez honnête : en avez-vous besoin pour conformité ou parce que vous gérez réellement l’intégrité de la chaîne de démarrage ? Si vous l’activez, vous devez garder votre histoire de noyau/modules simple — pas de pilotes signés n’importe comment plus tard.

Conseil opérationnel : choisissez Secure Boot si votre équipe plateforme peut le supporter de manière cohérente. Les flottes mixtes où certains nœuds ont Secure Boot et d’autres non tendent à produire des pannes « ça marche sur mon hôte ».

2) Agencement du stockage : vous concevez des domaines de panne

Vos choix de partitionnement au moment de l’installation déterminent ce qui se remplit en premier, ce qui peut être snapshoté, et ce qui bloque les mises à niveau. La panne de production classique est / ou /var atteignant 100 % à 3 h du matin parce que des logs, des couches de conteneurs ou un spool incontrôlé ont gonflé.

Opinion : séparez /var si le système héberge des bases de données, des conteneurs, des runners CI ou quoi que ce soit de bavard. Mettez /var/log sur une partition dédiée seulement si vous avez une vraie raison et une surveillance adaptée. Sinon, vous créez un second mode de panne : « /var/log est plein donc rien ne log ».

3) Choix du système de fichiers : choisissez le gagnant ennuyeux

XFS est un excellent choix par défaut pour les volumes serveurs. Ext4 convient aussi, particulièrement pour les petites partitions boot/root. Si vous voulez ZFS, vous adoptez un modèle de cycle de vie et des outils différents ; ça peut être excellent, mais ne prétendez pas que c’est « juste comme XFS ».

4) Synchronisation temporelle et DNS : ne pas improviser

Le temps et le DNS sont les deux services que tout le monde suppose corrects — jusqu’à ce que Kerberos échoue, que les certificats TLS semblent « pas encore valides » ou que votre gestionnaire de paquets ne puisse pas résoudre les dépôts. Assurez-vous que NTP/chrony et les paramètres du résolveur font partie du socle post-installation.

5) Identité et accès : les utilisateurs locaux sont un signe

En entreprise, les utilisateurs admin locaux s’accumulent comme la poussière. Utilisez une authentification centralisée (SSSD/LDAP/Kerberos) quand c’est pertinent, et gardez un compte break-glass local avec accès contrôlé. Si vous êtes dans des environnements plus petits, restez simple : au minimum exigez des clés SSH, désactivez l’authentification par mot de passe et consignez tout.

6) Voie de mise à niveau : planifiez-la maintenant, pas plus tard

Une « voie de mise à niveau propre » est moitié politique, moitié architecture :

• Politique : déploiements en étapes, dépôts épinglés et fenêtres de changement qui incluent du temps pour un rollback.
• Architecture : gestion de configuration, scripts de bootstrap idempotents et séparation des données et du système quand c’est possible.

Si l’état de votre application vit à l’intérieur de /usr/local avec des fichiers édités à la main et des exécutables mystérieux, aucune distribution ne pourra vous sauver. AlmaLinux ne réparera pas votre relation avec l’entropie.

Chemins d’installation : ISO, Kickstart et images dorées

Installation ISO interactive (bonne pour le premier nœud, mauvaise pour les flottes)

Utilisez l’installateur interactif pour valider la compatibilité matérielle, les hypothèses de stockage et la dénomination des interfaces réseau. Puis stop. Ne construisez pas dix serveurs en cliquant dix fois les mêmes écrans et en faisant confiance à votre mémoire.

Kickstart (l’option adulte)

Kickstart vous donne des installations versionnables et révisables. Cela signifie :

• Partitionnement et sélection de paquets audités.
• Dénomination réseau et services de base prévisibles.
• Un chemin vers le provisionnement PXE et les reconstructions sans intervention.

Quand surgit l’inévitable « il faut reconstruire le nœud 14 maintenant », Kickstart transforme la panique en routine.

Images dorées (à utiliser avec précaution)

Les images dorées sont excellentes pour le cloud et les hyperviseurs, mais elles peuvent incorporer des problèmes : machine-id obsolète, clés SSH hôtes dupliquées et artefacts udev/réseau bizarres. Si vous choisissez cette voie, prévoyez une étape d’initialisation au premier démarrage qui réinitialise l’identité et resevre correctement les secrets.

Agencements de stockage qui résistent aux audits et aux pannes

Agencement de base pour serveurs polyvalents (recommandé)

Pour une VM typique ou un serveur bare-metal exécutant quelques services :

• /boot (ext4) : petit, stable.
• /boot/efi (vfat) : partition système UEFI.
• / (XFS) : OS et binaires.
• /var (XFS) : logs, caches, spools, conteneurs.
• /home optionnel (XFS) : si des humains se connectent réellement (essayez de ne pas le faire).

LVM au-dessus de RAID (matériel ou mdadm) vous donne de la flexibilité : étendre les systèmes de fichiers, ajouter un nouveau LV pour /var/lib/containers ou tailler de l’espace pour les données d’application sans réinstaller.

Hôtes de conteneurs (ne prétendez pas qu’ils sont « juste des serveurs »)

Si l’hôte exécute Podman/Docker ou des composants Kubernetes, planifiez l’amplification d’écriture du stockage. Donnez plus d’espace à /var ou séparez /var/lib/containers dans son propre LV. Sinon, le runtime de conteneur finira par manger votre OS.

Hôtes de base de données (séparer OS et données)

Pour les bases de données, séparez agressivement l’OS et les données. Mettez les données de la base sur leurs propres volumes avec des options de montage claires, des files d’attente I/O séparées si possible, et de la surveillance. Gardez / et /var propres pour que les mises à jour OS et les logs ne concurrencent pas votre charge principale.

Chiffrement : LUKS est une décision de politique

Le chiffrement disque est excellent — jusqu’au redémarrage d’un serveur non supervisé à 2 h du matin. Choisissez LUKS uniquement si vous avez un plan pour le déverrouillage à distance, l’accès console et des runbooks opérationnels. « On tapera la passphrase au redémarrage » n’est pas un plan si le serveur est à 1 200 km.

Tâches pratiques : commandes, sorties et décisions associées

Voici les vérifications que j’exécute après une installation d’AlmaLinux 10. Chacune répond à une question qui compte lors d’une mise à niveau ou d’une panne.

Task 1: Verify OS release and kernel line

cr0x@server:~$ cat /etc/os-release
NAME="AlmaLinux"
VERSION="10.0 (Purple Lion)"
ID="almalinux"
ID_LIKE="rhel fedora"
VERSION_ID="10.0"
PLATFORM_ID="platform:el10"
PRETTY_NAME="AlmaLinux 10.0 (Purple Lion)"

Ce que cela signifie : Confirme que vous êtes sur la version majeure et l’ID de plateforme attendus.

Décision : Si cela n’indique pas el10, arrêtez et corrigez votre image/dépôt. Ne « mettez pas à niveau plus tard ».

Task 2: Confirm boot mode is UEFI (or not)

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo BIOS
UEFI

Ce que cela signifie : UEFI est actif si ce répertoire existe.

Décision : Si vous attendiez UEFI et obtenez BIOS, corrigez cela maintenant. Les modes de démarrage mixtes compliquent la standardisation, Secure Boot et les workflows de récupération.

Task 3: Check Secure Boot state

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Ce que cela signifie : Secure Boot est activé.

Décision : Si activé, traitez les modules noyau tiers et les pilotes hors-arbre comme des changements contrôlés. Si désactivé mais requis par la politique, corrigez avant la mise en production.

Task 4: Inspect disk and filesystem layout

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sda       476G disk
├─sda1    600M part vfat   /boot/efi
├─sda2      1G part ext4   /boot
└─sda3  474.4G part LVM2_member
  ├─almalv-root  60G lvm   xfs    /
  ├─almalv-var  120G lvm   xfs    /var
  └─almalv-home  20G lvm   xfs    /home

Ce que cela signifie : Confirme partition UEFI, /boot séparé et agencement basé LVM.

Décision : Si /var est petit sur un hôte de service, corrigez maintenant (redimensionnez les LV) avant que logs/containeurs le remplissent et transforment votre prochaine mise à niveau en prise d’otage.

Task 5: Validate fstab is sane (no surprise network mounts at boot)

cr0x@server:~$ cat /etc/fstab
UUID=3E2A-1C0B  /boot/efi  vfat  umask=0077,shortname=winnt  0  2
UUID=7b3e6dd4-0f3e-4a4c-9b0d-5a5f0a8a5f17  /boot  ext4  defaults  1  2
/dev/mapper/almalv-root  /     xfs   defaults  0  0
/dev/mapper/almalv-var   /var  xfs   defaults  0  0

Ce que cela signifie : Les montages critiques au démarrage sont locaux et simples.

Décision : Si vous voyez des montages NFS/CIFS sans nofail et sans timeouts appropriés, vous invitez les blocages au démarrage après le premier incident réseau.

Task 6: Check NIC naming and link state (predictability matters)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
ens192           UP             00:50:56:aa:bb:cc

Ce que cela signifie : Nom et état de l’interface. UP signifie que le lien est actif.

Décision : Si les noms diffèrent sur du matériel/VM identique, corrigez votre provisionnement ou vos règles udev. « Quelle NIC est prod ? » n’est pas un jeu amusant pendant une panne.

Task 7: Confirm IP, route, and DNS with NetworkManager

cr0x@server:~$ nmcli -g GENERAL.DEVICE,GENERAL.STATE,IP4.ADDRESS,IP4.GATEWAY,IP4.DNS device show ens192
ens192:100 (connected)
10.20.30.40/24
10.20.30.1
10.20.30.10

Ce que cela signifie : Le périphérique est connecté, a une IP, une passerelle et un DNS.

Décision : Si le DNS est incorrect, corrigez-le avant de déboguer « dnf est cassé ». C’est généralement le DNS.

Task 8: Verify time sync (TLS and auth depend on it)

cr0x@server:~$ timedatectl
               Local time: Tue 2026-02-05 13:18:19 UTC
           Universal time: Tue 2026-02-05 13:18:19 UTC
                 RTC time: Tue 2026-02-05 13:18:19
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Ce que cela signifie : Horloge synchronisée et NTP actif.

Décision : Si System clock synchronized est no, corrigez chrony avant de toucher aux certificats, Kerberos ou aux systèmes distribués.

Task 9: Check SELinux mode and recent denials

cr0x@server:~$ getenforce
Enforcing

cr0x@server:~$ ausearch -m avc -ts recent | tail -n 5
----
time->Tue Feb  5 13:10:41 2026
type=AVC msg=audit(1738761041.223:412): avc:  denied  { name_connect } for  pid=1240 comm="nginx" dest=5432 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:postgresql_port_t:s0 tclass=tcp_socket permissive=0

Ce que cela signifie : SELinux est en enforcing ; une interdiction AVC montre que nginx a tenté de se connecter au port Postgres.

Décision : Ne désactivez pas SELinux. Décidez si le service doit parler à ce port, puis appliquez le bon boolean/étiquetage. Si la connexion est légitime, corrigez la politique ; sinon, corrigez l’architecture.

Task 10: Confirm firewall state and open services

cr0x@server:~$ systemctl is-active firewalld
active

cr0x@server:~$ firewall-cmd --list-all
public (active)
  target: default
  interfaces: ens192
  services: ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Ce que cela signifie : Le pare-feu est activé ; seul le service SSH est ouvert dans la zone public.

Décision : Si votre hôte expose des ports aléatoires, fermez-les maintenant. Si votre application a besoin de ports, ouvrez-les explicitement et documentez-le comme du code.

Task 11: Check repo configuration and update metadata

cr0x@server:~$ dnf repolist
repo id                              repo name
almalinux-baseos                     AlmaLinux 10 - BaseOS
almalinux-appstream                  AlmaLinux 10 - AppStream
almalinux-crb                        AlmaLinux 10 - CRB

cr0x@server:~$ dnf -q check-update || true
kernel.x86_64  6.11.0-12.el10  almalinux-baseos
openssl.x86_64 3.2.2-4.el10    almalinux-baseos

Ce que cela signifie : Les dépôts sont activés ; des mises à jour sont disponibles.

Décision : Si des dépôts manquent ou que des dépôts tiers inattendus apparaissent, arrêtez-vous. La sécurité des mises à niveau commence par l’hygiène des dépôts.

Task 12: Inspect enabled services (reduce surprise at boot)

cr0x@server:~$ systemctl list-unit-files --type=service --state=enabled | head -n 15
UNIT FILE                          STATE   PRESET
chronyd.service                     enabled enabled
firewalld.service                   enabled enabled
sshd.service                        enabled enabled
tuned.service                       enabled enabled
NetworkManager.service              enabled enabled

Ce que cela signifie : Services de base activés ; vous pouvez voir ce qui démarrera au boot.

Décision : Désactivez ce dont vous n’avez pas besoin. Chaque démon activé est à la fois une surface d’attaque et une interaction future de mise à jour.

Task 13: Validate SSH hardening posture

cr0x@server:~$ sshd -T | egrep 'passwordauthentication|permitrootlogin|pubkeyauthentication'
passwordauthentication no
permitrootlogin no
pubkeyauthentication yes

Ce que cela signifie : L’authentification par mot de passe et la connexion root sont désactivées ; les clés sont activées.

Décision : Si l’authentification par mot de passe est activée sur des hôtes accessibles par Internet, corrigez-le avant de devenir un nœud de botnet.

Task 14: Check disk health indicators (NVMe/SATA)

cr0x@server:~$ smartctl -H /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.11.0-12.el10] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Ce que cela signifie : Le périphérique rapporte un état PASSED (pas parfait, mais un début).

Décision : Si SMART échoue ou est indisponible, déterminez si vous avez besoin d’outils du fournisseur, de vérifications du contrôleur RAID ou d’un remplacement proactif. N’attendez pas le théâtre du « système de fichiers en lecture seule ».

Task 15: Confirm journald persistence and log volume expectations

cr0x@server:~$ grep -E '^(Storage|SystemMaxUse|RuntimeMaxUse)=' /etc/systemd/journald.conf
Storage=persistent
SystemMaxUse=1G
RuntimeMaxUse=200M

Ce que cela signifie : Les logs persistent après redémarrage, avec des limites.

Décision : Si journald n’est pas limité sur de petits disques, plafonnez-le. Si vous avez besoin d’une rétention longue, envoyez les logs hors hôte ; ne les accumulez pas localement comme des souvenirs.

Task 16: Measure boot performance and find slow units

cr0x@server:~$ systemd-analyze
Startup finished in 3.212s (kernel) + 9.844s (userspace) = 13.056s
graphical.target reached after 9.801s in userspace

cr0x@server:~$ systemd-analyze blame | head
4.812s NetworkManager-wait-online.service
1.905s firewalld.service
1.102s chronyd.service

Ce que cela signifie : Identifie les services qui ralentissent le démarrage, souvent « wait-online ».

Décision : Si NetworkManager-wait-online domine et n’est pas nécessaire, désactivez-le. Un démarrage plus rapide signifie une récupération et des mises à jour plus rapides.

Task 17: Check CPU/memory and pressure (baseline for later comparisons)

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\):|Thread|Core|Socket'
CPU(s):                               4
Model name:                           Intel(R) Xeon(R) CPU
Thread(s) per core:                   2
Core(s) per socket:                   2
Socket(s):                            1

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       0.9Gi       5.9Gi       0.0Gi       0.9Gi       6.6Gi
Swap:          4.0Gi         0B       4.0Gi

Ce que cela signifie : Établit ce que « normal » ressemble sur une installation fraîche.

Décision : Si la mémoire est déjà serrée sur un hôte neuf, ne déployez pas de charges gourmandes en mémoire puis ne soyez pas surpris.

Task 18: Check I/O scheduler and filesystem mount options (performance and latency)

cr0x@server:~$ cat /sys/block/sda/queue/scheduler
[mq-deadline] kyber bfq none

cr0x@server:~$ findmnt -no TARGET,FSTYPE,OPTIONS / /var
/ xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota
/var xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota

Ce que cela signifie : Montre le scheduler et les options de montage qui affectent la latence et le débit.

Décision : Ne « tunez » pas les options de montage au hasard. Capturez d’abord la base ; changez une chose ; mesurez ; revenez en arrière si c’est pire.

Playbook de diagnostic rapide (trouver le goulot en quelques minutes)

Voici la séquence « je suis de permanence et quelque chose semble lent ». L’objectif est d’identifier si vous êtes lié au CPU, à la mémoire, au disque, au réseau, ou bloqué par une dépendance (DNS, auth, backend de stockage).

First: confirm the symptom is real and local

• L’application est-elle lente pour tout le monde ou seulement depuis un segment réseau ?
• L’hôte est-il lent pour toutes les commandes ou seulement pour l’application ?
• Quelque chose a-t-il changé (déploiement, patch, config) dans la dernière heure ?

Second: check resource saturation in the simplest tools

cr0x@server:~$ uptime
 13:22:11 up 10 days,  3:41,  1 user,  load average: 6.12, 5.98, 5.44

Interprétation : Une charge moyenne supérieure au nombre de CPU suggère une contention CPU ou une file d’exécution croissante (cela peut aussi être un I/O bloqué contribuant à la charge).

Décision : Si la charge est élevée, vérifiez immédiatement l’usage CPU vs iowait et la file d’exécution.

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 5  1      0 412112  90124 982112    0    0   120   450  580  900 25 10 45 20  0
 6  2      0 401980  90124 982400    0    0   110   980  600  950 22 11 42 25  0

Interprétation : r est les processus exécutable, b est bloqué, wa est iowait. Ici, iowait est significatif et des processus sont bloqués.

Décision : Traitez comme un probable goulot de stockage. Passez aux vérifications de latence disque avant d’ajuster les threads applicatifs.

Third: differentiate disk latency vs filesystem full vs memory pressure

cr0x@server:~$ df -hT / /var
Filesystem            Type  Size  Used Avail Use% Mounted on
/dev/mapper/almalv-root xfs    60G   18G   42G  31% /
/dev/mapper/almalv-var  xfs   120G  118G  2.0G  99% /var

Interprétation : /var est effectivement plein. Cela peut causer des écritures lentes, des services en échec et un comportement étrange du gestionnaire de paquets.

Décision : Arrêtez l’hémorragie : faites tourner les logs, nettoyez les caches ou étendez le LV. Ne « redémarrez pas tout » en espérant.

cr0x@server:~$ dmesg -T | tail -n 8
[Tue Feb  5 13:18:02 2026] XFS (dm-1): log I/O error -5
[Tue Feb  5 13:18:02 2026] XFS (dm-1): Filesystem has been shut down due to log error (0x2).

Interprétation : Si vous voyez des arrêts de système de fichiers, le problème n’est pas votre application. C’est le stockage ou des erreurs de périphérique sous-jacent.

Décision : Escaladez immédiatement vers le stockage/matériel. Protégez les données. Remontez en lecture seule si nécessaire et planifiez une récupération contrôlée.

Fourth: validate network and DNS (because it’s always in the suspect list)

cr0x@server:~$ resolvectl status | sed -n '1,25p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.30.10
       DNS Servers: 10.20.30.10 10.20.30.11

Interprétation : Confirme la configuration du résolveur et le serveur DNS actif.

Décision : Si les serveurs DNS sont incorrects ou injoignables, corrigez le DNS avant de blâmer DNF, SSSD ou l’application.

Fifth: check service health and logs with intent

cr0x@server:~$ systemctl --failed
  UNIT          LOAD   ACTIVE SUB    DESCRIPTION
● app.service    loaded failed failed Example Application

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state.
SUB    = The low-level unit activation state.

Interprétation : Une unité en échec est explicite ; ne devinez pas.

Décision : Passez à journalctl -u app.service -b, corrigez la cause racine, puis redémarrez. Ne redémarrez pas comme outil de diagnostic sauf si vous aimez perdre des preuves.

Trois mini-histoires du monde de l’entreprise (quelqu’un a déjà fait votre erreur)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise du secteur financier a déplacé une flotte de services internes vers un « Linux compatible RHEL » pour standardiser les patchs. Une image basée sur AlmaLinux a été construite vite, approuvée vite et déployée vite. L’hypothèse critique : « le partitionnement par défaut de l’installateur est correct ; c’est une distro d’entreprise. »

Ça allait pour une VM tranquille. Ce n’était pas adéquat pour un nœud API chargé qui écrit des logs, conserve un cache de paquets et exécute un runtime de conteneurs. En quelques semaines, /var s’est rempli lors d’une journée de pointe. L’application a commencé à renvoyer des timeouts et l’équipe support a poursuivi des problèmes réseau fantômes parce que le CPU et le réseau semblaient normaux. Pendant ce temps, journald a commencé à laisser tomber des messages car l’espace disque était rare, et les logs les plus utiles ont disparu justement quand tout le monde en avait besoin.

Le postmortem a été embarrassant car personne n’avait fait quelque chose de « mal » au sens habituel. L’OS était installé. Le service avait démarré. La surveillance existait. La vraie défaillance était d’avoir supposé que le layout par défaut correspondait à la charge.

La correction n’a pas été héroïque : reconstruire les nœuds avec un /var séparé et plus grand, appliquer des limites à journald et expédier les logs hors hôte. Ils ont aussi ajouté un test de pré-production qui générait volontairement du volume de logs et la churn des couches de conteneurs. Une fois que /var est resté sain pendant une semaine d’abus synthétique, ils ont de nouveau fait confiance à l’image.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation avait un service sensible à la latence et un ingénieur prudent vis-à-vis des changements de contexte. Ils ont « optimisé » en désactivant quelques services par défaut et en ajustant des kernel/sysctl suivant un article de blog. Ils ont aussi désactivé tuned parce que « ça change des choses » et figé le gouverneur CPU via un snippet de configuration.

En test synthétique, c’était plus rapide. Puis est venue une vraie fenêtre de maintenance. Après une mise à jour et un reboot, le temps de démarrage a explosé et le service est revenu de façon incohérente selon les nœuds. Certains nœuds attendaient indéfiniment le réseau ; d’autres démarraient tôt, subissaient des timeouts DNS et échouaient. Un nœud était OK. La flotte ne l’était pas. Le tuning avait dérivé parce que l’image dorée avait été mise à jour sur place et différentes équipes « corrigeaient » des nœuds à la main.

Le plus effrayant : le gain de performance n’était pas le problème. Le problème était la non-reproductibilité. Pendant la récupération, ils ne pouvaient pas dire quels changements étaient présents sur quels nœuds. La réponse à l’incident est devenue de l’archéologie.

La correction a été ennuyeuse : revenir sur des sysctl inconnus, réactiver les services de base et mettre en place le tuning via des profils versionnés avec des critères de mesure explicites. Ils ont encore optimisé, mais seulement avec un plan de roll-forward/roll-back et la gestion de configuration pour imposer la similitude.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise de retail exploitait AlmaLinux sur des systèmes périphériques qui perdaient parfois la connectivité réseau. Rien de sophistiqué : quelques services locaux, une file et une synchronisation périodique. Leur équipe plateforme insistait sur deux choses que personne n’aimait : une checklist de base stricte et des exercices de reconstruction réguliers via Kickstart.

Un jour, un souci de firmware du contrôleur de stockage a commencé à provoquer des erreurs I/O intermittentes. Quelques nœuds sont passés en lecture seule. L’équipe applicative voulait, compréhensiblement, « juste redémarrer » et continuer la vente. Mais l’équipe plateforme avait une routine pratiquée : capturer les logs, marquer le nœud hors rotation, reconstruire sur du matériel sain et restaurer le service depuis la file.

Parce que l’installation OS était reproductible, ils n’ont pas perdu de temps à se demander dans quel état était la machine. Parce que les partitions étaient cohérentes, leurs scripts de collecte de logs ont fonctionné. Parce que SELinux était appliqué partout, ils n’ont pas eu de dérive « ça marche sur le nœud A mais pas sur le B ». La panne a été contenue, pas célébrée.

Ce jour-là, personne n’a été reconnu pour son ingéniosité. L’entreprise a été reconnue pour être restée ouverte. C’est tout le travail.

Blague n°2 : La seule chose plus permanente qu’une solution temporaire est le ticket qui dit « supprimer plus tard ».

Erreurs courantes : symptôme → cause racine → correction

1) DNF est lent ou échoue avec des timeouts

Symptôme : dnf makecache bloque ou le téléchargement des métadonnées du repo timeoute.

Cause racine : Mauvaise configuration DNS, problèmes de proxy ou MTU/chemin. Moins souvent : sélection de miroir cassée.

Correction : Confirmez le résolveur et le routage (nmcli, resolvectl), testez la résolution de noms, validez les paramètres proxy dans /etc/dnf/dnf.conf et l’environnement. Si vous êtes sur un VLAN avec un MTU étrange, testez avec ping -M do et ajustez.

2) Le système ne démarre plus après activation de Secure Boot

Symptôme : Démarrage échoue après installation de pilotes tiers ou modules noyau personnalisés.

Cause racine : Modules non signés bloqués par la politique Secure Boot.

Correction : Utilisez des pilotes signés et supportés par le fournisseur ; enregistrez des clés si vous gérez vraiment votre propre signature ; sinon désactivez Secure Boot uniquement si la politique le permet. Ne mélangez pas « chaîne de démarrage stricte » avec « modules DKMS aléatoires ».

3) Les services échouent mystérieusement après l’installation

Symptôme : Un service démarre bien sur un nœud, échoue sur un autre avec « permission denied » même en tant que root.

Cause racine : Deniés SELinux, fichiers mal étiquetés ou contextes incorrects après copie manuelle.

Correction : Inspectez les AVC, restaurez les contextes (restorecon), appliquez les bons labels et utilisez des booleans appropriés. Désactiver SELinux n’est pas une correction ; c’est une reddition.

4) Le démarrage prend une éternité, surtout sur les hôtes réseau

Symptôme : Temps de démarrage long ; systemd-analyze blame montre wait-online.

Cause racine : NetworkManager-wait-online attend la connectivité dans des environnements où ce n’est pas nécessaire (ou où le DHCP est instable).

Correction : Désactivez wait-online lorsque la charge n’en a pas besoin au boot, ou corrigez la dépendance réseau. Ne maquillez pas les problèmes réseau avec des attentes infinies.

5) Le disque se remplit pendant l’opération normale

Symptôme : /var atteint 100 %, les services plantent, les logs s’arrêtent, DNF échoue.

Cause racine : /var sous-dimensionné, logs sans limites, croissance des couches de conteneurs, spools incontrôlés.

Correction : Redimensionnez les LV, plafonnez journald, configurez logrotate, séparez le stockage des conteneurs et mettez des alertes de surveillance sur l’utilisation d’inodes et d’espace.

6) Après une mise à jour, l’app ne peut pas binder un port ou se connecter en sortie

Symptôme : Permission denied sur bind/connect malgré une config applicative correcte.

Cause racine : Étiquetage de port SELinux ou règles de pare-feu non alignées avec l’app.

Correction : Vérifiez la zone/ports/services firewalld, confirmez les types de port SELinux et appliquez des corrections ciblées. Évitez les règles « ouvrir tout » qui deviennent des passifs permanents.

7) Clés hôtes ou identité machine dupliquées sur des VM clonées

Symptôme : Avertissements SSH sur changements de clé hôte ; la surveillance montre plusieurs nœuds avec le même ID.

Cause racine : Image dorée clonée sans régénérer machine-id et clés hôtes SSH.

Correction : Utilisez cloud-init ou des scripts de premier démarrage pour réinitialiser l’identité, régénérer les clés et assurer des hostnames uniques et des réservations DHCP si nécessaire.

Listes de contrôle / plan étape par étape

Étape par étape : installation AlmaLinux 10 de niveau entreprise (serveur unique)

1. Décidez du mode de démarrage : Utilisez UEFI sauf raison documentée contraire. Décidez d’une politique Secure Boot dès le départ.
2. Décidez de l’agencement du stockage : Planifiez un /var séparé pour les hôtes de service. Utilisez LVM pour la flexibilité. Choisissez XFS pour la plupart des charges.
3. Configurez hostname et réseau : Configurez une IP statique si approprié ; assurez-vous que DNS et NTP sont corrects.
4. Paquets minimaux : Installez uniquement ce dont vous avez besoin. Moins de paquets signifie moins de CVE et moins de conflits de mise à jour.
5. Créez l’accès admin : Utilisez des clés SSH. Désactivez la connexion root par SSH. Créez un chemin break-glass auditable.
6. Laissez SELinux en enforcing : Corrigez correctement les problèmes de politique plutôt que de l’éteindre.
7. Activez le pare-feu : Ouvrez seulement les ports requis, explicitement.
8. Mettez à jour immédiatement : Appliquez les correctifs pour atteindre l’état mineur courant avant d’intégrer en production.
9. Capturez la baseline : Sauvegardez les sorties des commandes clés (repolist, layout de montage, services activés, sync temporel).
10. Enregistrez la surveillance : Espace disque/inodes, CPU, mémoire, charge et état des services au minimum.
11. Documentez le plan de mise à niveau : Quel est votre rollback ? Snapshot ? Rebuild ? Où sont stockées les données ?
12. Testez un reboot : Vérifiez le démarrage, le réseau, les services et l’état applicatif après redémarrage.

Checklist : ce que signifie « voie de mise à niveau propre » en pratique

• Build reproductible : Kickstart ou pipeline d’images. Pas de snowflakes bricolés à la main.
• Gestion de configuration : Ansible/Salt/Puppet/etc. Même à petite échelle, ayez quelque chose.
• Contrôle des dépôts : Dépôts connus seulement ; dépôts tiers revus et épinglés.
• Séparation des données : Les données applicatives ne sont pas mélangées aux fichiers OS. Sauvegardes et restaurations testées.
• Répétitions de mise à niveau : Test sur un nœud de staging représentatif avec des patrons de trafic réels quand possible.
• Stratégie de rollback : Snapshot VM, snapshot LVM (avec précaution) ou rebuild + restore. Choisissez-en une et pratiquez-la.
• Observabilité : Logs envoyés hors hôte, métriques conservées et dashboards connus des humains qui seront alertés.

Checklist : durcissement post-installation qui ne brise pas votre futur moi

• Désactiver l’authentification SSH par mot de passe ; exiger des clés.
• Désactiver la connexion root directe par SSH ; utiliser sudo.
• Définir des limites journald ; vérifier logrotate quand applicable.
• Activer et configurer correctement les zones firewalld.
• Confirmer chrony/NTP ; utiliser UTC sauf raison forte contraire.
• Garder SELinux en enforcing ; considérer les dénis comme des signaux, pas des nuisances.
• Supprimer les paquets/services inutilisés ; moins c’est mieux.

FAQ

1) Dois-je choisir AlmaLinux 10 pour de nouveaux systèmes de production ?

Si vous voulez les conventions Enterprise Linux et un écosystème stable, oui. Le gain opérationnel vient de la compatibilité et de la prévisibilité, pas de la nouveauté.

2) Une « installation minimale » est-elle vraiment meilleure ?

Généralement. Moins de paquets réduit l’exposition sécurité et les interactions de mise à jour. Installez ce dont vous avez besoin, puis laissez la gestion de configuration ajouter le reste.

3) Quel est le meilleur système de fichiers pour les serveurs AlmaLinux 10 ?

XFS est le choix sûr par défaut pour la plupart des systèmes serveurs. Ext4 convient pour /boot et les racines petites. Choisissez ZFS seulement si vous adoptez aussi son modèle opérationnel.

4) Ai-je besoin de LVM ?

Si vous exploitez de vrais systèmes : oui, la plupart du temps. LVM permet de redimensionner et corriger la disposition sans réinstaller. Sans lui, vous pariez sur le fait de ne jamais vous tromper sur l’utilisation disque.

5) Dois-je séparer /var ?

Pour les hôtes de service, oui. Surtout avec des conteneurs, CI, logs intensifs ou cache de paquets. Isoler /var empêche qu’une charge bruyante ne saborde l’OS.

6) Secure Boot en vaut-il la peine ?

Utile quand vous pouvez le supporter de manière cohérente et que votre environnement tient à l’intégrité de la chaîne de démarrage. Si vous utilisez régulièrement des modules hors-arbre, Secure Boot peut devenir une taxe de maintenance récurrente.

7) Comment garantir une voie de mise à niveau majeure propre ?

Facilitez les reconstructions. Gardez les dépôts sous contrôle. Maintenez la configuration déclarative. Séparez les données. Alors les mises à niveau deviendront des événements planifiés plutôt que des rituels désespérés.

8) SELinux bloque mon appli. Quelle est la bonne correction ?

Trouvez le déni, décidez si l’accès est légitime, puis appliquez des changements ciblés (booleans, contextes appropriés, ports autorisés). Désactiver SELinux corrige le symptôme en supprimant la garde-fou.

9) Quelle est la première chose à vérifier quand « le serveur est lent » ?

uptime et vmstat. Vous devez savoir si vous êtes lié CPU, I/O ou mémoire avant de toucher à l’application.

10) Puis-je me fier aux images dorées plutôt qu’à Kickstart ?

Vous le pouvez, mais seulement si vous avez un processus de premier démarrage qui réinitialise l’identité et si vous maintenez la pipeline d’images disciplinée. Sinon, vous clonerez à grande échelle les erreurs d’hier.

Conclusion : prochaines étapes pratiques

Si vous voulez qu’AlmaLinux 10 ait un air « d’entreprise », installez-le comme si vous comptiez vivre avec. La plupart des douleurs viennent de la croissance non planifiée : logs, conteneurs, caches et changements humains qui ne reviennent jamais dans l’automatisation.

Faites ceci ensuite :

1. Choisissez un agencement de stockage avec une vraie stratégie pour /var et consignez-la.
2. Décidez d’une politique UEFI + Secure Boot pour toute la flotte, pas hôte par hôte.
3. Transformez votre meilleure installation interactive en Kickstart et reconstruisez un nœud depuis zéro pour prouver que ça marche.
4. Capturez une baseline avec l’ensemble de commandes ci-dessus et stockez-la avec la config du système.
5. Exécutez une simulation de panne : remplissez /var en staging, regardez ce qui casse, puis corrigez-le avant que la production ne le fasse pour vous.

Quand les mises à niveau arriveront, vous aurez toujours du travail. Mais ce sera le genre de travail qui se termine à l’heure, pas celui qui finit par un postmortem et un nouveau respect pour l’espace disque.