Installation RHEL 10 : la checklist d’entreprise que vous auriez voulu avoir plus tôt

Faits rapides et contexte (pourquoi les installations RHEL ressemblent à ça)

• Anaconda est l’installateur RHEL, et il existe depuis la fin des années 1990. Son rôle est ennuyeux : être prévisible sur du matériel médiocre.
• Kickstart n’est pas un luxe ; c’est la façon dont les entreprises ont transformé des « serveurs flocons de neige » en bétail bien avant que le cloud ne rende cela à la mode.
• systemd est devenu le défaut dans RHEL 7. C’est pourquoi services, journaux et diagnostics de démarrage vivent maintenant dans un seul univers scriptable.
• XFS est devenu le système de fichiers par défaut pour RHEL 7 pour de bonnes raisons : montée en charge, maturité et performance raisonnable avec de grands arbres de répertoires.
• SELinux est présent dans RHEL depuis des décennies. Beaucoup d’intrusions n’arrivent pas parce que SELinux est magique, mais parce qu’il est pénible à contourner discrètement.
• UEFI a remplacé le BIOS comme standard de démarrage moderne ; vos échecs de boot ressemblent de plus en plus à des « variables EFI » et à l’état Secure Boot, pas à de la magie MBR.
• chrony a remplacé les anciens daemons NTP parce que les réseaux modernes ont besoin d’une convergence plus rapide et d’une meilleure gestion des machines qui se suspendent ou dérivent.
• LUKS2 est le format moderne de chiffrement de disque Linux. Ce n’est pas que pour les laptops ; c’est pour les datacenters où les disques perdus deviennent des cauchemars de conformité.
• cgroups v2 (le modèle moderne de contrôle de ressources Linux) change le comportement des limites CPU/mémoire ; cela compte si vous exécutez des piles de conteneurs ou des quotas stricts.

Aucun de ces faits n’est une anecdote. Ils expliquent pourquoi « juste cliquer dans l’installateur » est un piège. RHEL est conçu pour des opérations répétables à grande échelle.
Si vous n’installez pas comme si vous alliez opérer, vous vous portez volontaire pour un futur rapport d’incident.

Décisions à prendre avant de démarrer l’installateur

1) Qu’est-ce que vous construisez : serveur « pet », nœud de flotte, ou système réglementé ?

Si c’est un nœud de flotte, vous avez besoin d’automatisation (Kickstart), d’un stockage standardisé et d’un réseau prévisible. Si c’est réglementé, vous avez besoin de chiffrement, de réglages d’audit,
et d’une traçabilité papier. Si c’est une « boîte utilitaire » unique, ok — mais n’affirmez pas ensuite qu’elle ne deviendra pas de la production.

2) Firmware et mode de démarrage : UEFI ou legacy ?

Choisissez UEFI sauf si vous avez une raison de compatibilité solide de ne pas le faire. Les installations Legacy BIOS restent possibles, mais votre support fournisseur et les mises à niveau futures
supposeront de plus en plus UEFI. De plus : la politique Secure Boot doit être une décision consciente, pas une surprise.

3) Agencement des disques : LVM, partitions classiques, ou quelque chose de personnalisé ?

Pour des installations RHEL en entreprise, le choix par défaut raisonnable est GPT + UEFI + LVM sur XFS, avec optionnellement LUKS.
LVM vous donne de la flexibilité opérationnelle : redimensionner, ajouter des volumes, séparer des chemins à forte écriture.

Évitez les schémas de partitionnement héroïques qui « optimisent les performances » à la main sauf si vous pouvez les défendre pendant une panne.
Votre futur-vous ne se souviendra pas pourquoi /var a reçu 12.7 GiB.

4) Chiffrement : en avez-vous besoin, et pouvez-vous déverrouiller à l’échelle ?

Le chiffrement des disques est simple. Le chiffrement des disques avec démarrage non supervisé, mains à distance et coffre de clés cassé ne l’est pas.
Si vous activez LUKS, décidez du mécanisme de déverrouillage : phrase locale (manuelle), chiffrement lié au réseau (là où approprié), ou méthode compatible avec l’orchestration.

5) Identité réseau : noms d’hôtes, DNS, NTP et plan d’adressage IP

Choisissez des noms d’hôtes reflétant la fonction et l’environnement. Décidez si vous utiliserez DHCP, IP statiques ou réservations DHCP. Définissez les résolveurs DNS et domaines de recherche.
Décidez des sources NTP et si vous avez besoin de serveurs temporels internes.

6) Stratégie de mises à jour : « latest », figé, ou staged ?

Dans les vraies entreprises vous échelonnez les mises à jour. Vous ne laissez pas une nouvelle installation tirer tout ce qui est plus récent au moment de l’installation et appeler cela reproductible.
Décidez : version de l’image de base, stratégie de snapshot des dépôts, et comment vous déployez les errata de sécurité.

7) Authentification : utilisateurs locaux, LDAP/IdM, ou SSO ?

Si vous allez utiliser une identité centralisée (fréquent), planifiez-le maintenant. Cela change la politique sudo, l’accès SSH, les attentes d’audit et le workflow de réponse aux incidents.

Blague #1 : Installer RHEL sans décider du stockage et de l’identité revient à acheter un coffre-fort et laisser la clé sous le paillasson.

Checklists / plan étape par étape (pré, install, post)

Checklist pré-install (faire avant de toucher Anaconda)

• Confirmer les spécifications matériel/VM : CPU, RAM, modèle de disque, type de contrôleur et NICs. Obtenez les noms de périphériques réels que vous verrez sous Linux.
• Confirmer les réglages du firmware : UEFI activé, mode RAID vs HBA/JBOD, politique Secure Boot, extensions de virtualisation si pertinent.
• Choisir l’agencement du stockage : partitions, LVM, points de montage, types de systèmes de fichiers et plan de chiffrement.
• Définir la config réseau : VLANs, MTU, bonding/teaming, routes statiques, DNS et sources temporelles.
• Décider des dépôts post-install et de la méthode de mise à jour (et si la machine peut les atteindre pendant l’installation).
• Préparer l’automatisation : fichier Kickstart, ou au moins une fiche de construction écrite à suivre à la lettre.
• Enregistrer la base : nom d’hôte prévu, IP, numéro de série/tag d’actif, propriétaire, environnement et objectif.

Checklist installateur (choix qui mordent plus tard)

• Vérifier que vous installez dans le mode de démarrage prévu (UEFI vs legacy) avant de partitionner.
• Définir le fuseau horaire correct et activer la synchronisation temporelle (ou au moins la planifier après l’installation).
• Choisir des ensembles de paquets minimaux ; ajoutez ce dont vous avez besoin intentionnellement.
• Ne pas désactiver SELinux pour « faire marcher ». Corrigez la politique ou les labels.
• Définir la politique de mot de passe root et créer un utilisateur admin avec sudo. Préférez SSH par clé.
• Vérifier que les bons disques cibles sont sélectionnés. Triple-vérifiez sur les serveurs multi-disques.

Checklist post-install (le vrai travail commence au premier démarrage)

• Mettre à jour vers votre niveau de patch de base (échelonné, contrôlé).
• Verrouiller SSH : clés, utilisateurs/groupes autorisés, désactiver auth par mot de passe si possible.
• Confirmer que SELinux est en enforcing ; corriger les éventuels mauvais labels issus d’images/scripts personnalisés.
• Configurer les zones du pare-feu et les ouvertures de services explicites.
• Mettre en place la journalisation persistante et l’envoi de logs à distance si nécessaire.
• Valider le stockage : options de système de fichiers, exactitude de fstab, santé LVM et attentes du scheduler IO.
• Valider la synchronisation temporelle et la résolution de noms. Un DNS cassé se déguise en « lenteur aléatoire ».
• Mesure de base des performances : CPU steal (VMs), latence IO et débit réseau. Capturer des métriques initiales.
• Enregistrer dans votre plan de gestion (Satellite, dépôts internes, gestion de config) et marquer la build comme immuable.

Tâches pratiques (commandes, sorties, signification, décisions)

Voici les vérifications « parcourir la machine » que j’attends sur un nouveau système RHEL 10 avant de lui confier quoi que ce soit qui déclenche un pager.
Chaque tâche inclut : commande, sortie exemple, ce que ça signifie, et la décision à prendre.

Tâche 1 : Confirmer la version de l’OS et la provenance de l’installation

cr0x@server:~$ cat /etc/redhat-release
Red Hat Enterprise Linux release 10.0 (Plow)

Ce que ça signifie : Vous êtes sur la release majeure/minor attendue (et pas sur une image ancienne qu’on a « recyclée »).

Décision : Si la release n’est pas celle prévue, arrêtez. Ne dites pas « on mettra à jour plus tard » comme plan de récupération d’une base mal installée.

Tâche 2 : Confirmer le mode de démarrage (UEFI vs legacy)

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

Ce que ça signifie : Le système a démarré en mode UEFI. Cela affecte le partitionnement, la config GRUB et certains workflows de récupération.

Décision : Si vous attendiez UEFI mais avez Legacy, réinstallez maintenant. Les flottes mixtes rendent les opérations fragiles.

Tâche 3 : Inspecter les périphériques blocs et identifier le vrai disque de démarrage

cr0x@server:~$ lsblk -o NAME,MODEL,SIZE,TYPE,FSTYPE,MOUNTPOINTS
NAME        MODEL          SIZE TYPE FSTYPE      MOUNTPOINTS
sda         PERC H755      1.8T  disk
├─sda1                    600M  part vfat        /boot/efi
├─sda2                      1G  part xfs         /boot
└─sda3                    1.8T  part LVM2_member
  ├─rhel-root               80G lvm  xfs         /
  ├─rhel-var                50G lvm  xfs         /var
  ├─rhel-tmp                 8G lvm  xfs         /tmp
  └─rhel-home               10G lvm  xfs         /home

Ce que ça signifie : Vous voyez la partition EFI, /boot séparé, et un PV LVM hébergeant des volumes logiques.

Décision : Validez que les points de montage correspondent à l’intention. Si /var n’est pas séparé sur des systèmes générant beaucoup de logs, envisagez de corriger tôt (la migration ultérieure est douloureuse).

Tâche 4 : Vérifier les types de systèmes de fichiers et options (roues de performance et sécurité)

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS / /var /tmp /home
/ /dev/mapper/rhel-root xfs rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k
/var /dev/mapper/rhel-var xfs rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k
/tmp /dev/mapper/rhel-tmp xfs rw,nosuid,nodev,noexec,relatime,seclabel
/home /dev/mapper/rhel-home xfs rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k

Ce que ça signifie : /tmp est durci (nosuid,nodev,noexec). XFS est en place. Les labels SELinux sont activés.

Décision : Gardez /tmp durci sauf si vous avez une chaîne d’outils de build qui nécessite vraiment l’exécution dans /tmp—corrigez plutôt cet outil que d’affaiblir l’OS.

Tâche 5 : Valider la santé LVM et l’espace libre pour la croissance

cr0x@server:~$ vgs
  VG   #PV #LV #SN Attr   VSize  VFree
  rhel   1   4   0 wz--n-  1.79t  1.64t

Ce que ça signifie : Beaucoup d’espace libre dans le VG. Bon signe : vous pouvez étendre /var ou ajouter des volumes spécifiques sans passer par la « Storage Team Theater ».

Décision : Si VFree est minuscule, vous avez soit surdimensionné des volumes, soit oublié la croissance future. Corrigez maintenant, avant que des données n’existent.

Tâche 6 : Confirmer l’état du chiffrement (LUKS) là où requis

cr0x@server:~$ lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINTS
sda      disk
├─sda1   part vfat        /boot/efi
├─sda2   part xfs         /boot
└─sda3   part crypto_LUKS
  └─luks-2b3c...  crypt LVM2_member
    └─rhel-root   lvm   xfs         /

Ce que ça signifie : Le PV root est à l’intérieur d’un conteneur LUKS. C’est du vrai chiffrement au repos, pas « on a fermé la porte du datacenter ».

Décision : Validez que vous avez un processus de déverrouillage viable (console locale, KVM distant, ou méthode approuvée par l’entreprise). Sinon, vous venez de construire une panne future.

Tâche 7 : Vérifier le kernel, les paramètres de boot et l’état du microcode

cr0x@server:~$ uname -r
6.12.0-xx.el10.x86_64

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.12.0-xx.el10.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto rhgb quiet

Ce que ça signifie : Vous êtes sur une ligne de noyau connue ; cmdline montre que crashkernel est activé (utile pour kdump).

Décision : Si vous exécutez des charges sensibles à la latence, considérez si « quiet/rhgb » a sa place en production (je les retire généralement sur les serveurs pour rendre les logs de démarrage visibles).

Tâche 8 : Confirmer l’application de SELinux

cr0x@server:~$ getenforce
Enforcing

Ce que ça signifie : SELinux fait son travail : Enforcing, pas seulement en log.

Décision : Si c’est Permissive/Disabled, corrigez avant d’y déployer des applis. Sinon votre « baseline de sécurité » n’est qu’un mémo, pas un contrôle.

Tâche 9 : Confirmer l’état du pare-feu et ce qui est réellement exposé

cr0x@server:~$ sudo firewall-cmd --state
running

cr0x@server:~$ sudo firewall-cmd --get-active-zones
public
  interfaces: ens192

cr0x@server:~$ sudo firewall-cmd --zone=public --list-services
ssh

Ce que ça signifie : Firewalld est actif ; seul le service SSH est autorisé dans la zone public.

Décision : N’ouvrez pas de ports « temporairement » et oubliez-les. Si un service est nécessaire, définissez-le explicitement par zone et capturez cela dans l’automatisation.

Tâche 10 : Valider le DNS et le comportement du résolveur (les échecs rapides valent mieux que des mystères lents)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 resolv.conf mode: stub
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53 10.20.0.54
        DNS Domain: corp.example

Ce que ça signifie : systemd-resolved gère le DNS ; vous avez deux résolveurs ; un domaine de recherche est défini.

Décision : Si DNSSEC ou split DNS est requis, planifiez-le maintenant. Si les résolveurs sont injoignables, corrigez avant d’accuser « le réseau ».

Tâche 11 : Valider la synchronisation temporelle (authentification et systèmes distribués en dépendent)

cr0x@server:~$ chronyc tracking
Reference ID    : 0A140035 (10.20.0.53)
Stratum         : 3
Ref time (UTC)  : Mon Feb 05 12:10:28 2026
System time     : 0.000123456 seconds fast of NTP time
Last offset     : -0.000045678 seconds
RMS offset      : 0.000210000 seconds
Frequency       : 12.345 ppm fast
Leap status     : Normal

Ce que ça signifie : Chrony est synchronisé, faible offset, stratum stable. Cela évite des échecs TLS, des bizarreries Kerberos et des misères de corrélation de logs.

Décision : Si Leap status n’est pas Normal ou si les offsets sont importants, corrigez la reachabilité NTP ou les règles du pare-feu. N’ignorez pas la dérive temporelle.

Tâche 12 : Confirmer la persistance de journald (logs qui survivent aux redémarrages)

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

cr0x@server:~$ journalctl --disk-usage
Archived and active journals take up 312.0M in the file system.

Ce que ça signifie : Les logs persistent après redémarrage et ont un plafond. Vous avez choisi de garder des preuves sans laisser les logs manger le filesystem root.

Décision : Si Storage est volatile, changez-le. Si SystemMaxUse est illimité, fixez un plafond et expédiez les logs hors hôte si vous avez besoin de rétention.

Tâche 13 : Vérifier les ressources système de base (pression mémoire, sanity du swap)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi       1.2Gi        28Gi       120Mi       1.8Gi        29Gi
Swap:          8.0Gi          0B       8.0Gi

Ce que ça signifie : Beaucoup de marge ; le swap existe et n’est pas utilisé.

Décision : Pour de nombreuses charges serveurs, un peu de swap reste utile comme filet de sécurité. Évitez les politiques « swapoff partout » sauf si vous comprenez le mode de défaillance.

Tâche 14 : Valider la pile IO et détecter une latence évidente avant l’arrivée des applis

cr0x@server:~$ iostat -xz 1 3
Linux 6.12.0-xx.el10.x86_64 (server)  02/05/2026  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          1.20    0.00    0.55    0.10    0.00   98.15

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
dm-0             0.20    1.50     8.0    64.0      64.0     0.01    2.10    1.90    2.13   0.25   0.04

Ce que ça signifie : Faible await et faible utilisation ; le disque n’est pas actuellement le goulot.

Décision : Si await grimpe dans les dizaines/centaines de ms sous charge légère, arrêtez et investiguez le contrôleur de stockage, multipath, ou les performances du SAN sous-jacent.

Tâche 15 : Confirmer les canaux de mise à jour et ce qui sera réellement patché

cr0x@server:~$ sudo dnf repolist
repo id                              repo name
rhel-10-baseos                       RHEL 10 BaseOS (Staged)
rhel-10-appstream                    RHEL 10 AppStream (Staged)
rhel-10-extras                       RHEL 10 Extras (Staged)

Ce que ça signifie : Les dépôts sont configurés et pointent probablement vers votre miroir/snapshot échelonné.

Décision : Si les dépôts pointent vers des sources aléatoires ou manquent, corrigez maintenant. Le comportement de mise à jour fait partie de votre posture de sécurité.

Tâche 16 : Confirmer que kdump est configuré (vous ne vous en soucierez que quand vous en aurez vraiment besoin)

cr0x@server:~$ systemctl is-enabled kdump
enabled

cr0x@server:~$ sudo kdumpctl status
Kdump is operational

Ce que ça signifie : Si le noyau plante, vous pouvez capturer un dump de crash pour un vrai diagnostic.

Décision : Sur les systèmes critiques, gardez kdump. Sur les petites VMs, vous pouvez choisir de le désactiver pour récupérer de la RAM—documentez ce choix.

Stockage et systèmes de fichiers : configurations qui survivent à la vie réelle

Le layout par défaut en lequel j’ai confiance (et pourquoi)

Sur les serveurs d’entreprise à usage général, j’aime :
/ (root) dimensionné pour l’OS et les outils, /var séparé pour les logs et l’état mutable,
/tmp séparé et durci, et des volumes dédiés optionnels pour bases de données ou systèmes de queues.
Utilisez XFS sauf si vous avez une raison validée précise de faire autrement.

L’objectif opérationnel n’est pas l’élégance. C’est le contrôle du rayon d’impact. Quand une appli devient incontrôlable et écrit des logs infinis, /var se remplit—pas /.
Quand un processus de build abîme /tmp, il ne peut pas monter par accident une zone de staging exécutable.

Partitionnement et LVM : privilégiez la flexibilité plutôt que la prophétie

Les gens sur-partitionnent parce qu’ils veulent prévenir les incidents de disque plein. C’est noble, et cela cause généralement des incidents de disque plein.
L’approche correcte est séparer les points de montage à haut risque plus de l’espace libre LVM pour une croissance contrôlée.

Pour être clair : vous ne pouvez pas prédire quel répertoire va croître. Vous pouvez prédire lesquels font mal quand ils le font.

Partitions de boot UEFI : gardez-les basiques

Pour UEFI : vous avez besoin d’une EFI System Partition (vfat) montée sur /boot/efi. Gardez-la de taille standard (quelques centaines de Mo).
Gardez /boot séparé (XFS est correct) si vous utilisez LUKS pour root—parce que le bootstrap d’un root chiffré a besoin de clarté.

Chiffrement : rendez-le réel, rendez-le opérable

Le chiffrement des données au repos est souvent une exigence de politique. Le piège est de construire un système qui ne peut pas redémarrer sans intervention après une maintenance électrique,
parce que quelqu’un a mis la passphrase d’unlock dans un tableur puis l’a fait tourner.

Si vous faites LUKS, décidez :

• Où vivent les clés et qui peut les récupérer lors d’un incident.
• Que se passe-t-il quand l’hôte est déplacé, remplacé ou restauré depuis une sauvegarde.
• Si l’accès console distant existe pendant le boot (pour déverrouillage manuel).

Swap : ennuyeux, démodé, toujours utile

Le swap n’est pas une fonctionnalité de performance. C’est un façonneur de mode de défaillance. Une petite quantité de swap peut garder un système vivant assez longtemps pour vous alerter,
expédier des logs et récupérer proprement au lieu de tuer des processus au hasard.

Options de montage : sécurité et comportement, pas folklore

Utilisez nodev,nosuid,noexec là où c’est pertinent (par ex. /tmp). Utilisez noatime seulement si vous comprenez les effets secondaires ;
relatime est généralement bien et par défaut. Évitez de tuner sur la base d’un cargo cult internet.

Base de sécurité : SELinux, pare-feu, crypto et réalité SSH

SELinux : enforcing est la baseline, pas une aspiration

SELinux est souvent blâmé pour des échecs qu’il se contente d’exposer. Quand une appli essaie d’écrire dans le mauvais répertoire ou de binder un mauvais port,
SELinux dit « non » et vous le découvrez tôt. C’est une fonctionnalité.

Si vous devez dépanner, utilisez des outils ciblés : vérifiez les logs d’audit, confirmez les contextes, et appliquez des changements minimaux de politique.
« Désactiver SELinux » est la version sysadmin de « enlever le détecteur de fumée parce qu’il est bruyant ».

Pare-feu : refus par défaut avec intention explicite

Sur les serveurs, je veux firewalld en marche avec un minimum de services exposés. Si vous devez ouvrir des ports, faites-le délibérément et capturez-le dans l’automatisation.
Ce n’est pas de la paranoïa ; c’est réduire votre surface de scan.

SSH : clés, accès restreint et pas d’utilisateurs mystères

Utilisez l’authentification par clé pour l’accès admin quand c’est possible. Désactivez la connexion root via SSH. Limitez qui peut SSHer (AllowUsers ou AllowGroups).
Pour le « break-glass », utilisez un chemin audité et documentez-le.

Politiques crypto : ne luttez pas contre la plateforme

RHEL dispose d’une gestion de politique crypto système. C’est bien : cela maintient les réglages TLS cohérents entre les consommateurs OpenSSL.
Ne laissez pas des scripts d’installation d’applis affaiblir les politiques crypto pour « permettre à un ancien client de se connecter ».
Corrigez le client, ou isolez ce système legacy jusqu’à sa remplaҫon.

Citation (idée paraphrasée) de Werner Vogels : « You build it, you run it » — la fiabilité s’améliore quand les constructeurs assument les conséquences opérationnelles.

Journalisation et observabilité : conservez les preuves

journald persistant est non négociable pour le debugging en production

Si journald est volatile, les logs disparaissent au redémarrage — le moment exact après des mises à jour du noyau, des coupures de courant, ou « on a changé une petite chose ».
Persistez le journal, plafonnez son usage disque, et expédiez les logs importants hors hôte si la conformité ou la réponse aux incidents l’exige.

Isolation du volume de logs : /var comme barrière de sécurité

Séparer /var est une pratique classique ennuyeuse parce que ça marche. Cela contient le bazar : caches de paquets, logs, spools et état.
Quand /var se remplit, l’OS peut souvent rester en marche assez longtemps pour réparer. Quand / se remplit, tout devient excitant.

Base métrique : prenez un cliché quand tout va bien

Le meilleur moment pour capturer des métriques de base de performance est juste après l’installation, avant que la charge ne change.
Capturez : idle/steal CPU, latence IO, débit réseau et pression mémoire. Plus tard, quand quelqu’un dira « c’est plus lent », vous aurez une référence.

Blague #2 : Les logs sont comme les backups — tout le monde les aime après avoir réalisé qu’ils ne les ont pas.

Réseau : DNS, temps, MTU, bonding et « pourquoi c’est lent »

DNS : la cause racine de la moitié de vos incidents intermittents

Des résolveurs mal configurés provoquent des démarrages d’application lents, des timeouts d’API aléatoires et des bascules confuses.
Validez la résolution directe et inverse si nécessaire. Sachez si systemd-resolved est utilisé et comment il s’intègre à vos outils.

Synchronisation temporelle : la dépendance silencieuse

La dérive temporelle casse TLS, l’authentification, le tracing distribué, et votre capacité à corréler des logs entre systèmes.
Chrony doit être configuré et vérifié. N’acceptez pas un « ça doit être probablement OK ».

MTU et VLANs : un classique piège de performance

Les jumbo frames peuvent aider dans certains environnements, et elles peuvent aussi créer une perte de paquets en trou noir si le chemin ne les supporte pas end-to-end.
Si vous mettez MTU 9000, validez-le sur switches, hyperviseurs et NICs. Sinon vous aurez des pannes partielles bizarres.

Bonding/teaming : la redondance nécessite des tests

Ne vous déclarez pas victorieux parce que les deux liens montrent « UP ». Testez la bascule. Débranchez un câble (ou désactivez une vNIC) et vérifiez que l’hôte garde la connectivité.
Vérifiez aussi que la configuration côté switch correspond au mode de bonding.

Playbook de diagnostic rapide (trouver le goulot vite)

Quand un hôte RHEL 10 fraîchement installé est « lent », ne commencez pas par réinstaller. Commencez par isoler le domaine du goulot :
CPU, mémoire, disque, réseau, ou configuration/identité. Cette séquence trouve 80 % des problèmes rapidement.

Première étape : le système est-il fondamentalement sain ?

• Vérifier les erreurs de boot : journalctl -b -p err
• Vérifier la charge basique : uptime, top ou htop
• Vérifier disque plein : df -h, df -i

Deuxième étape : est-ce la CPU / l’ordonnancement VM ?

• Regardez le CPU steal (VMs) : mpstat -P ALL 1 5 (steal %)
• Vérifiez le throttling : systemd-cgtop pour la pression des cgroups

Troisième étape : est-ce la latence IO ?

• Mesurez : iostat -xz 1 5 (await, %util)
• Trouvez les coupables : pidstat -d 1, iotop si disponible
• Validez multipath/SAN : multipath -ll (si utilisé)

Quatrième étape : est-ce le réseau (ou le DNS qui se fait passer pour réseau) ?

• Latence DNS : resolvectl query your-service et vérifier le timing
• Perte de paquets : ping -c 20 gateway
• Débit : ss -s (santé des sockets), ip -s link (drops/errors)

Cinquième étape : friction de politique/configuration ?

• Refus SELinux : ausearch -m avc -ts recent
• Blocages pare-feu : firewall-cmd --list-all plus logs de services
• Dérive temporelle/TLS : chronyc tracking, erreurs de certificats dans les logs applicatifs

L’astuce est la discipline. Ne poursuivez pas cinq hypothèses à la fois. Choisissez un domaine, prouvez-le coupable ou innocent, puis passez au suivant.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : Timeouts aléatoires vers des services internes

Cause racine : Résolveur DNS mal configuré, domaine de recherche manquant, ou confusion avec systemd-resolved stub.

Correction : Validez resolvectl status, assurez-vous que les résolveurs sont joignables, définissez correctement domaine/recherche, et testez les requêtes explicitement.

2) Symptom : Reboot après mises à jour et maintenant le système ne boot plus

Cause racine : Mauvais mode de boot (installé Legacy, attendu UEFI), ou partition EFI mal créée/montée.

Correction : Confirmez UEFI avec /sys/firmware/efi. Si c’est erroné, réinstallez en mode correct. Si la partition EFI manque, réparez le bootloader depuis un média rescue.

3) Symptom : Les logs disparaissent après redémarrage

Cause racine : journald configuré en stockage volatile (par défaut dans certaines images minimales), ou /var/log non persistant dans une pipeline d’image.

Correction : Mettez Storage=persistent dans journald.conf, créez /var/log/journal, et plafonnez l’usage avec SystemMaxUse.

4) Symptom : « Disque plein » fait tomber tout l’hôte

Cause racine : Filesystem root unique ; /var et / sont identiques ; tempêtes de logs remplissent /. Parfois exhaustion d’inodes.

Correction : Séparez /var ; surveillez df -i ; logrotate ; expédiez les logs hors hôte.

5) Symptom : L’application ne peut pas binder un port ou écrire dans un répertoire

Cause racine : SELinux refuse à cause d’un mauvais contexte ou d’un boolean manquant ; ou le pare-feu bloque les connexions entrantes.

Correction : Vérifiez les dénis AVC via ausearch, corrigez les contextes avec restorecon, réglez les booleans nécessaires, et ouvrez les ports du pare-feu de façon intentionnelle.

6) Symptom : Réseau « up » mais gros transferts stagnent ou sont instables

Cause racine : Incompatibilité MTU (jumbo frames non supportées end-to-end) ou mauvaise configuration de bonding.

Correction : Validez le MTU sur tout le chemin ; testez avec des pings en jouant sur le DF bit ; confirmez que la config switch correspond au mode de bonding ; testez la bascule.

7) Symptom : Performance terrible uniquement sur VMs

Cause racine : CPU steal dû à l’overcommit, contention stockage sur datastores partagés, ou optimisations virtio manquantes.

Correction : Mesurez le steal avec mpstat, vérifiez la latence IO avec iostat, coordonnez-vous avec l’équipe virtualisation pour le placement des ressources et le tiering stockage.

8) Symptom : L’hôte ne peut pas s’authentifier aux services corporate

Cause racine : Dérive temporelle, mauvais nom d’hôte, ou attentes de reverse DNS manquantes dans des environnements type Kerberos.

Correction : Corrigez d’abord la synchronisation temporelle ; assurez-vous que le nom d’hôte/FQDN est correct ; validez résolution avant/arrière ; puis retentez l’enrôlement.

Trois mini-histoires d’entreprise (ce qui tourne vraiment mal)

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

Une équipe a déployé une nouvelle flotte de jump hosts basés sur RHEL 10 pour l’accès en production. Ils avaient fait « les choses normales » : patchs appliqués, SSH durci, firewalld activé.
L’accès semblait correct lors des tests légers. Puis la rotation on-call a commencé à utiliser les hosts pendant un incident réel.

Les sessions se figeaient pendant 20–40 secondes quand les ingénieurs lançaient des commandes touchant des hostnames internes. Ensuite tout revenait à la normale.
La première hypothèse fut congestion réseau. La deuxième, un outil bastion cassé. La troisième, « le DNS RHEL 10 est bizarre ».

La cause racine était douloureusement simple : l’installation supposait que le domaine de recherche corporate serait fourni par DHCP partout. Dans cet environnement, ce n’était pas le cas.
La plupart des hostnames étaient non qualifiés dans des scripts et habitudes shell. Donc chaque lookup essayait des mauvais suffixes, atteignait des timeouts, puis finissait par résoudre.

La correction fut tout aussi simple : configurer explicitement le domaine de recherche et la liste de résolveurs, valider avec resolvectl, et ajouter un check basique de latence DNS dans la pipeline de build.
La leçon n’était pas « DHCP est mauvais ». La leçon était « les hypothèses sont une configuration que vous avez oublié d’écrire ».

Mini-histoire 2 : L’optimisation qui a échoué

Un groupe infra voulait accélérer les builds pour des runners CI sur RHEL 10. Quelqu’un a proposé de désactiver journald persistant parce que « les écritures disque sont lentes » et
« on n’a pas besoin de logs sur des runners éphémères ». C’était vendu comme optimisation perf et économie de stockage. Ça a été mergé.

Deux semaines plus tard, un sous-ensemble de runners a commencé à échouer des builds de manière intermittente. Les échecs n’étaient pas consistants—parfois installs de paquets foiraient,
parfois fetchs réseau mourraient, parfois des tests timeoutaient. La seule chose constante était que redémarrer un runner « le réparait » pendant un moment.

Il s’est avéré qu’il y avait un vrai problème sous-jacent : une interaction driver/firmware NIC sur un lot matériel particulier causait des liaisons qui tombaient ponctuellement.
Journald aurait montré une timeline propre des événements link down/up, des renewals DHCP et des restarts de services. Mais journald était volatile et les machines se redémarraient
pendant la remédiation automatique. Les preuves ont donc disparu.

Ils ont réactivé journald persistant avec un plafond disque serré, ajouté l’envoi distant de logs pour les événements critiques, et le temps de debugging est passé de jours à heures.
L’« optimisation » n’a pas économisé d’IO significatif. Elle a sauvé l’illusion d’IO tout en coûtant l’observabilité, qui est généralement la chose la plus chère à perdre.

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

Un cluster applicatif en lien avec la finance tournait sur RHEL avec de strictes exigences d’audit. Le standard de build paraissait presque comiquement conservateur :
/var séparé, swap présent, kdump activé, SELinux enforcing, pare-feu minimal, journald persistant avec plafonds, et un layout LVM standardisé avec beaucoup d’espace VG libre.
Personne ne l’aimait. Tout le monde le tolèrait.

Pendant un trimestre chargé, un composant tiers est devenu incontrôlable et a commencé à logger en debug verbeux dans /var/log à haut débit après un petit changement de config.
En quelques heures, /var a atteint 100 % d’utilisation. Sur beaucoup de systèmes, c’est là que vous obtenez une panne hôte complète et une longue nuit.

Ici, l’hôte est resté en marche. Le filesystem root avait de l’espace. SSH fonctionnait toujours. systemd fonctionnait toujours. Le monitoring aussi.
L’ingénieur on-call s’est connecté, a confirmé que /var était plein, a pivoté et tronqué les logs fautifs, et a redémarré le composant sous une config corrigée.

Le postmortem n’était pas glamour. Le standard de build n’a reçu aucun applaudissement. Mais il a évité une outage qui aurait cascade en jobs batch manqués et rapports retardés.
La pratique ennuyeuse—séparer /var et plafonner les logs—a fait exactement ce que les pratiques ennuyeuses sont censées faire : réduire la taille des catastrophes.

FAQ

1) Dois-je utiliser une installation GUI ou minimal pour des serveurs RHEL 10 ?

Minimal, sauf si vous avez une raison solide. Moins de paquets signifie moins de CVE, moins de churn de patchs, et moins de dépendances étranges.
Vous pouvez toujours ajouter des outils plus tard ; retirer une stack GUI plus tard vaut rarement la peine du nettoyage.

2) XFS est-il toujours le bon système de fichiers ?

Pour la plupart des cas d’usage serveurs en entreprise, oui. XFS scale bien et se comporte de façon prévisible sous charge. Si vous avez besoin d’une fonctionnalité spécifique (comme certains patrons de petits fichiers ou des snapshots),
justifiez-le par des tests et un plan de support opérationnel, pas par des opinions.

3) Ai-je vraiment besoin d’un /var séparé ?

Si le système exécute quoi que ce soit qui logge, spool, met en cache ou stocke un état mutable (donc : presque tout), oui.
Séparer /var est une assurance peu coûteuse contre les tempêtes de logs et caches incontrôlés qui prennent l’OS.

4) Dois-je chiffrer les disques root sur les serveurs ?

Si vous avez des exigences réglementaires ou de risque, oui. Sinon, cela vaut la peine d’envisager pour les systèmes contenant des données sensibles.
Mais faites-le seulement si vous pouvez l’opérer : déverrouillage, rotation des clés et récupération doivent être conçus, pas improvisés.

5) Puis-je désactiver SELinux pour accélérer le déploiement ?

Vous pouvez, mais vous ne devriez pas. Désactiver SELinux tend à cacher des mauvaises configurations jusqu’à plus tard, quand le rayon d’impact est plus grand.
Utilisez le mode permissive brièvement pour le diagnostic si nécessaire, puis revenez à enforcing avec des labels/politiques corrects.

6) Quelle est la base pour durcir SSH sans casser l’automatisation ?

Utilisez l’authentification par clé, désactivez la connexion root, et restreignez les utilisateurs/groupes autorisés. Gardez un chemin break-glass, mais rendez-le audité.
Si l’automatisation a besoin d’accès, utilisez des comptes de service dédiés avec des règles sudo limitées—pas des clés partagées.

7) Comment gérer les mises à jour sur des systèmes fraîchement installés ?

Alignez-les sur vos dépôts échelonnés et fenêtres de patch. Ne laissez pas des installations fraîches tirer des paquets latest arbitraires depuis n’importe où.
Standardisez sur une baseline connue, puis progressez en vagues contrôlées.

8) Quelle est la première chose à vérifier quand « le réseau est lent » ?

DNS et MTU. Validez la latence et la configuration des résolveurs, puis vérifiez les drops/errors sur les interfaces.
Ensuite, examinez le path MTU si les gros transferts échouent. Beaucoup de plaintes « réseau lent » sont des délais de résolution de noms.

9) Ai-je besoin de kdump sur tous les serveurs ?

Sur les systèmes critiques, oui. Sur les petites VMs avec budget RAM serré, peut-être pas.
Faites-en une décision délibérée : soit vous le gardez pour la diagnostiquabilité, soit vous le désactivez et acceptez une visibilité réduite sur les crashes.

Prochaines étapes que vous pouvez faire aujourd’hui

Si vous voulez que vos installations RHEL 10 cessent d’être des artefacts « ça marche chez moi » et deviennent des actifs de production, faites trois choses :
standardisez les décisions, automatisez la construction, et validez avec un contrôle de santé reproductible.

1. Écrivez votre baseline : mode de boot, agencement stockage, position sur le chiffrement, DNS/NTP, posture SELinux/pare-feu, et stratégie de mises à jour.
2. Transformez-le en automatisation : Kickstart plus config management post-install. Si vous ne pouvez pas le reconstruire, vous ne le possédez pas.
3. Exécutez la section tâches comme checklist de gate : traitez les échecs comme des tests qui ont échoué, pas comme « on corrigera après la mise en production ».
4. Ajoutez le playbook de diagnostic rapide aux docs on-call : le meilleur moment pour apprendre à déboguer est avant l’incident, pas pendant.

La production n’est pas l’endroit où vous prouvez que vos clics dans l’installateur fonctionnent. C’est l’endroit où vous prouvez vos choix par défaut. Faites-les bons.