Installation de Rocky Linux 10 : compatible RHEL sans les contraintes d’abonnement

Ce que vous construisez réellement (et ce que vous ne construisez pas)

Rocky Linux 10 est le choix « je veux le comportement RHEL sans la paperasserie RHEL ». Si vous avez de l’expérience avec le Linux d’entreprise,
vous savez déjà pourquoi c’est important : vos fournisseurs certifient sur une plateforme, vos auditeurs attendent certains réglages,
et vos runbooks opérationnels supposent systemd, SELinux, des noms de paquets prévisibles et une fenêtre de support longue.

Mais clarifions l’accord :

• Vous obtenez un userland et un comportement du noyau compatibles RHEL, une pile de paquets familière (dnf/rpm) et des paramètres par défaut orientés entreprise.
• Vous n’obtenez pas par défaut des contrats de support fournisseur, des intégrations propriétaires de gestion ou des dépôts verrouillés par abonnement.
• Vous devez absolument effectuer votre propre validation de base : mode de démarrage, schéma de disque, mises à jour, synchronisation du temps, journaux et posture de sécurité.

Si votre environnement nécessite un support officiel du fournisseur pour des raisons réglementaires ou contractuelles, payez là où ça compte.
Si votre besoin est « fonctionne pareil, se met à jour pareil et ne nous surprend pas », Rocky est un choix solide.

Une vérité opérationnelle : la plupart des pannes ne viennent pas de bugs noyau exotiques. Elles viennent d’hypothèses — sur le stockage,
l’ordre de démarrage, l’état des dépôts, le « on durcira plus tard ». Rocky Linux n’empêche pas ces hypothèses. Vous le faites.

Faits intéressants et contexte historique

Ce ne sont pas des bulletins pour un quiz. Ils expliquent pourquoi Rocky existe et pourquoi il se comporte comme il le fait.

1. Les clones RHEL sont récurrents. L’écosystème a longtemps eu des rebuilds du Linux d’entreprise pour capturer la compatibilité RHEL sans friction de licence directe.
2. CentOS était autrefois le choix « gratuit et RHEL-like ». Pendant des années, beaucoup d’organisations standardisaient sur CentOS pour leurs flottes de serveurs parce qu’il suivait étroitement RHEL.
3. CentOS Stream a changé les attentes. Quand Stream est devenu le centre d’attention, il est passé d’un « rebuild downstream » à un aperçu continu de ce qui pourrait arriver dans RHEL.
4. Rocky Linux a été créé en réponse à ce changement. Une large partie de l’industrie avait besoin d’une plateforme stable et downstream-compatible à nouveau.
5. Le « contrat Linux d’entreprise » est autant social que technique. La stabilité signifie peu de surprises : attentes ABI, cadence du noyau et paramètres conservateurs.
6. dnf a remplacé yum pour une raison. La résolution de dépendances, la modularité et les améliorations de performance n’étaient pas cosmétiques ; elles répondaient à des années de douleur dans le patching de flottes.
7. SELinux n’est pas optionnel dans les environnements sérieux. C’est une des grandes raisons pour lesquelles les systèmes « RHEL-like » sont déployables à grande échelle sans transformer chaque service en une exception sur mesure.
8. systemd a standardisé le comportement des services entre distributions. Qu’on l’aime ou non, il a rendu la supervision de service, la journalisation et la gestion des dépendances plus cohérentes.
9. UEFI + GPT est désormais la réalité par défaut. Si vous concevez encore comme si tout était BIOS+MBR, vous construisez des bombes à retardement pour les plateformes serveur modernes.

Décisions préalables qui évitent les interruptions

1) Décidez : UEFI ou BIOS hérité (et ne mélangez pas les modes)

Si le matériel est à peu près moderne, utilisez UEFI. Ce n’est pas une question de mode ; c’est une question de gestion de démarrage cohérente,
meilleur support GPT et moins de mystères du type « pourquoi le chargeur de démarrage a disparu après une mise à jour du firmware ».

Mélanger les modes de démarrage du média d’installation (installer en BIOS hérité sur une machine, en UEFI sur une autre) crée une dérive opérationnelle.
La dérive devient de la confusion, et la confusion devient des tickets à 03:00.

2) Décidez : schéma de stockage par domaine de panne, pas par habitude

Votre plan de stockage doit répondre à deux questions :

• Qu’est-ce qui peut tomber en panne ? Disque, contrôleur, nœud, rack, volume cloud, humain.
• Qu’est-ce qui casse quand ça tombe ? Démarrage, système racine, journaux, base de données, images de conteneur.

Conseils simples qui tiennent en production :

• Fiabilité du démarrage : Gardez /boot simple. Si vous faites du RAID, assurez-vous que votre chargeur de démarrage le prend en charge proprement.
• Contrôle opérationnel : Mettez /var sur son propre volume logique si la machine journalise beaucoup ou exécute des conteneurs. Les tempêtes de logs ne doivent pas remplir la racine.
• Filets de sécurité : Si vous ne pouvez pas vous permettre une indisponibilité, utilisez la redondance (RAID matériel ou mdraid) pour les disques système ; ne considérez pas les snapshots cloud comme du RAID.
• Performance : Séparez les chemins d’écriture chauds (bases de données, applications à journal intensif) du reste. Si ce n’est pas possible, au moins surveillez les E/S et planifiez la capacité.

3) Décidez : LVM ou « partitions classiques »

Utilisez LVM pour presque tous les serveurs. Ça rend le redimensionnement raisonnable, supporte les snapshots (avec réserves) et vous donne une frontière d’abstraction contrôlée.
Les partitions classiques conviennent pour des appliances immuables, mais la plupart des serveurs « temporaires » vivent des années.

4) Décidez : choix de système de fichiers (XFS vs ext4) avec une intention

XFS est un choix courant en entreprise pour de bonnes raisons : scalable, robuste et bien supporté. ext4 convient très bien aussi.
Choisissez-en un et standardisez, sauf si un workload spécifique justifie de diverger.

5) Décidez : plan réseau (statique, réservations DHCP ou dynamique)

Les serveurs qui exécutent des services de production doivent avoir un adressage prévisible. Cela peut être une configuration statique ou des réservations DHCP,
mais « il prendra une IP quelconque » n’est pas un plan.

6) Décidez : comment vous patcherez (et comment vous reviendrez en arrière)

Le patching n’est pas un événement ; c’est une pipeline. Décidez maintenant :

• Mettrez-vous à jour automatiquement (dnf-automatic) ou batcherez-vous et validerez-vous les mises à jour ?
• Quelle est votre politique pour les mises à jour du noyau ?
• Faites-vous des snapshots des disques VM avant patch ? Avez-vous une méthode de rollback testée ?

Blague #1 (court, pertinent) : Traitez le patching comme le fil dentaire — tout le monde reconnaît que c’est bien, et la plupart des pannes arrivent parce que quelqu’un « commencera demain ».

Guide d’installation : UEFI, stockage et paramètres raisonnables

Étape 0 : vérifier le média d’installation et le mode de démarrage

Avant de cliquer sur « Installer », confirmez que vous avez démarré de la façon prévue (UEFI vs hérité). Sur beaucoup de serveurs, le menu de démarrage
affiche deux entrées pour la même ISO USB — choisissez celle en UEFI sauf raison contraire.

Étape 1 : choisir un ensemble de paquets minimal sauf si vous avez besoin d’une GUI

Pour les serveurs, choisissez une installation minimale. Chaque paquet en plus, c’est :
une mise à jour de plus,
une vulnérabilité potentielle de plus,
un autre « pourquoi ce service écoute sur un port qu’on ne connaissait pas ».

Étape 2 : heure, locale et clavier (les pièges silencieux)

Réglez correctement le fuseau horaire et activez la synchronisation du temps ensuite. Certificats, Kerberos, corrélation des logs et chronologie des incidents dépendent tous d’horloges qui ne mentent pas.

Étape 3 : partitionnement disque qui ne vous hantera pas

Si vous installez sur une VM à disque unique, le schéma sécuritaire le plus simple est :

• Partition système UEFI (ESP), petite
• /boot, petite
• PV LVM pour le reste
• Volumes logiques pour /, /var et swap (la taille du swap dépend du workload ; ne suivez pas les recettes toutes faites)

Si vous installez sur des serveurs physiques avec deux disques système, vous avez deux approches courantes :

• RAID1 matériel pour les disques système : le plus simple opérationnellement ; le contrôleur devient une dépendance.
• RAID1 logiciel (mdraid) : transparent et portable entre contrôleurs ; il faut faire attention à l’emplacement du chargeur de démarrage/UEFI.

Étape 4 : réseau et nom d’hôte

Donnez un vrai nom d’hôte. Si votre convention de nommage est un désordre, corrigez la convention, pas les noms d’hôtes après le déploiement.
Les noms d’hôte apparaissent dans les logs, la supervision, les certificats et dans la tête des gens.

Étape 5 : création d’utilisateurs et SSH

Créez un utilisateur administrateur non-root. Autorisez SSH par clés. Gardez SSH par mot de passe désactivé sauf besoin spécifique, et dans ce cas,
contraignez-le par la politique réseau et MFA si possible.

Étape 6 : SELinux doit être Enforcing

Laissez SELinux en Enforcing. Si vous le désactivez « juste pour l’instant », vous oublierez, et la machine deviendra un cas spécial.
Les cas spéciaux sont l’endroit où vont éclore les pagers.

Étape 7 : validation au premier démarrage

Après le premier démarrage, n’installez pas immédiatement votre pile applicative. Validez le système de base : mode de démarrage, santé des disques,
configuration des dépôts, mises à jour, synchronisation du temps et journalisation.

Post-installation : mises à jour, dépôts, base de sécurité et hygiène des services

Dépôts : restez ennuyeux et intentionnels

Le Linux d’entreprise vit et meurt par la discipline des dépôts. Vous voulez :
un ensemble connu de dépôts,
des paquets cohérents entre hôtes,
et un comportement de mise à jour prévisible.

N’activez pas de dépôts tiers aléatoires sur des serveurs de production parce qu’un blog l’a conseillé. Si vous avez besoin de paquets supplémentaires, prenez une décision consciente :
mirror-les, verouillez-les et testez les mises à jour dans un staging qui ressemble à la production.

Mises à jour : patcher tôt, puis régulièrement

Votre première vraie action après l’installation devrait être de mettre à jour, puis redémarrer si le noyau ou des bibliothèques critiques ont changé.
Cela établit la base et évite le mythe « ça tourne depuis le jour de l’installation ».

Base de sécurité : SSH, firewalld et politique SELinux

Réglez SSH sur clés, bloquez la connexion root, gardez firewalld activé et utilisez SELinux comme prévu :
comme couche de sécurité qui limite le rayon d’impact.

Journalisation : conservez les logs sans vous noyer

Configurez la persistance de journald si nécessaire, transférez les logs vers un stockage central et limitez la rétention locale pour éviter que l’hôte ne s’auto-DoS par remplissage disque.

Citation (idée paraphrasée)

Idée paraphrasée : tout échoue un jour ; la résilience vient de la conception pour la panne, pas de l’espoir qu’elle n’arrive pas.
— Werner Vogels (leadership orienté fiabilité, paraphrasé)

Tâches pratiques : commandes, sens des sorties et décisions (12+)

Voici les vérifications que je lance après avoir installé un système compatible RHEL. Chacune se termine par une décision,
car des commandes sans décisions ne sont que de l’art vivant.

Task 1: Confirm OS version and platform identity

cr0x@server:~$ cat /etc/os-release
NAME="Rocky Linux"
VERSION="10.0 (Green Obsidian)"
ID="rocky"
ID_LIKE="rhel fedora"
VERSION_ID="10.0"
PLATFORM_ID="platform:el10"
PRETTY_NAME="Rocky Linux 10.0 (Green Obsidian)"
ANSI_COLOR="0;32"
LOGO="rocky"

Ce que cela signifie : Vous êtes sur Rocky 10, et il annonce une compatibilité avec la famille RHEL.

Décision : Si PLATFORM_ID n’est pas EL10, arrêtez-vous et confirmez que vous n’avez pas installé la mauvaise ISO ou un dérivé non voulu.

Task 2: Verify boot mode (UEFI vs legacy)

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

Ce que cela signifie : La présence du répertoire EFI indique un démarrage UEFI.

Décision : Si vous attendiez UEFI et que vous avez BIOS, réinstallez correctement maintenant. Ne « corrigez pas plus tard ». Plus tard coûte cher.

Task 3: Inspect block devices and partition map

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sda        200G disk
├─sda1     600M part vfat   /boot/efi
├─sda2       1G part xfs    /boot
└─sda3   198.4G part LVM2_member
  ├─rl-root   40G lvm  xfs  /
  ├─rl-var    80G lvm  xfs  /var
  └─rl-swap    8G lvm  swap [SWAP]

Ce que cela signifie : Vous avez une mise en place propre UEFI + /boot + LVM, et /var est isolé.

Décision : Si /var n’est pas séparé sur une machine à logs intenses (conteneurs, bases de données, runners CI), envisagez de reconstruire avant de stocker des données.

Task 4: Check filesystem usage and the “/var filled root” trap

cr0x@server:~$ df -hT
Filesystem           Type   Size  Used Avail Use% Mounted on
/dev/mapper/rl-root  xfs     40G  2.3G   38G   6% /
/dev/mapper/rl-var   xfs     80G  5.1G   75G   7% /var
/dev/sda2            xfs    960M  220M  740M  23% /boot
/dev/sda1            vfat   599M  6.2M  593M   2% /boot/efi

Ce que cela signifie : Espace libre sain sur les points de montage importants.

Décision : Si la racine est petite et que /var n’est pas séparé, vous êtes à un pic de logs d’un système de fichiers racine en lecture seule.

Task 5: Confirm fstab correctness (boots matter more than beauty)

cr0x@server:~$ cat /etc/fstab
UUID=2f6c4d9b-4c1e-4ed6-a57b-3e1e6e2a9b0a /                       xfs     defaults        0 0
UUID=fa1b70d8-5b0c-4b98-8e12-7c0d8f8195a2 /var                    xfs     defaults        0 0
UUID=8d8a7d9f-9b02-4d5e-9f21-3d65d7f6e4bc /boot                   xfs     defaults        0 0
UUID=0A1B-2C3D                            /boot/efi               vfat    umask=0077,shortname=winnt 0 2
/dev/mapper/rl-swap                       none                    swap    defaults        0 0

Ce que cela signifie : Les montages basés sur UUID réduisent les surprises si les noms de périphériques changent.

Décision : Si vous voyez des chemins de périphérique comme /dev/sda3 pour des montages critiques sur des serveurs physiques, passez aux UUID maintenant.

Task 6: Verify repo status and avoid “mystery packages”

cr0x@server:~$ dnf repolist
repo id                         repo name
appstream                       Rocky Linux 10 - AppStream
baseos                          Rocky Linux 10 - BaseOS
extras                          Rocky Linux 10 - Extras

Ce que cela signifie : Vous avez les dépôts de base activés. C’est généralement ce que vous voulez dès le premier jour.

Décision : Si vous voyez des dépôts supplémentaires que vous n’avez pas approuvés, désactivez-les avant d’installer quoi que ce soit. La reproductibilité bat la nouveauté.

Task 7: Check for updates and understand the blast radius

cr0x@server:~$ dnf check-update
Last metadata expiration check: 0:12:31 ago on Tue 06 Feb 2026 10:14:20 AM UTC.
kernel.x86_64                     6.12.0-1.el10_0                 baseos
openssl-libs.x86_64               3.2.2-4.el10_0                  baseos
systemd.x86_64                    256.7-2.el10_0                  baseos

Ce que cela signifie : Des mises à jour du kernel, d’OpenSSL et de systemd sont en attente — ce n’est pas une catégorie « peut attendre ».

Décision : Patchez maintenant dans une fenêtre de maintenance ; prévoyez un redémarrage si kernel/systemd sont mis à jour. Si cet hôte fait partie d’un cluster, faites un roulé.

Task 8: Apply updates and capture what changed

cr0x@server:~$ sudo dnf -y update
Dependencies resolved.
================================================================================
 Package           Arch   Version                 Repository               Size
================================================================================
Upgrading:
 kernel            x86_64 6.12.0-1.el10_0         baseos                  12 M
 openssl-libs      x86_64 3.2.2-4.el10_0          baseos                 2.4 M
 systemd           x86_64 256.7-2.el10_0          baseos                 4.1 M

Transaction Summary
================================================================================
Upgrade  3 Packages

Complete!

Ce que cela signifie : Vous avez mis à jour des composants centraux.

Décision : Redémarrez bientôt. Ne laissez pas un nouveau noyau installé sans l’exécuter ; cela crée l’illusion « c’est patché ».

Task 9: Validate SELinux state (and don’t negotiate with it)

cr0x@server:~$ getenforce
Enforcing

Ce que cela signifie : SELinux fait son travail.

Décision : S’il est Permissive ou Disabled, corrigez-le maintenant sauf si vous avez une exception documentée avec contrôles compensatoires.

Task 10: Confirm firewall status and open ports intentionally

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

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

Ce que cela signifie : firewalld tourne et seul SSH est autorisé par la définition de services.

Décision : Si vous voyez des services trop ouverts que vous ne reconnaissez pas, retirez-les. « On restreindra plus tard » est la façon dont des ports de test deviennent des fonctionnalités de production.

Task 11: Check time sync status (because logs must agree)

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

Ce que cela signifie : L’horloge système est synchronisée, le service NTP est actif.

Décision : Si la synchronisation est « non », corrigez-le avant de rejoindre des domaines, d’émettre des certificats ou de déboguer des systèmes distribués.

Task 12: Verify network configuration and DNS resolution

cr0x@server:~$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens192           UP             10.40.12.34/24 fe80::250:56ff:feaa:bbcc/64

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

Ce que cela signifie : Vous avez une adresse, et le DNS pointe vers des serveurs voulus.

Décision : Si le DNS pointe vers un résolveur aléatoire ou ne résout pas les zones internes, corrigez-le maintenant — les installations de paquets et la découverte de services échoueront de façon créative.

Task 13: Confirm system services and catch accidental listeners

cr0x@server:~$ systemctl --failed
0 loaded units listed.

cr0x@server:~$ ss -lntp
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      128    0.0.0.0:22          0.0.0.0:*     users:(("sshd",pid=991,fd=3))
LISTEN 0      4096   127.0.0.1:323       0.0.0.0:*     users:(("chronyd",pid=812,fd=5))

Ce que cela signifie : Rien n’a échoué ; seuls les ports attendus sont ouverts.

Décision : Si vous voyez des écouteurs inattendus, identifiez le paquet et désactivez le service avant qu’il ne devienne un titre d’incident.

Task 14: Validate storage health (hardware exposure varies)

cr0x@server:~$ sudo dmesg -T | grep -E "I/O error|blk_update_request|reset|nvme|ata" | tail -n 8
[Tue Feb  6 10:21:22 2026] nvme nvme0: pci function 0000:5e:00.0
[Tue Feb  6 10:21:22 2026] nvme nvme0: 4/0/0 default/read/poll queues
[Tue Feb  6 10:21:22 2026] nvme0n1: p1 p2 p3

Ce que cela signifie : Pas d’erreurs de stockage évidentes ; le périphérique a été énuméré proprement.

Décision : Si vous voyez des resets ou des erreurs I/O ici pendant le jour d’installation, remplacez le matériel ou corrigez le firmware avant de confier cette machine à quelque chose d’important.

Task 15: Kernel and reboot hygiene (avoid “patched but not rebooted”)

cr0x@server:~$ uname -r
6.12.0-1.el10_0.x86_64

cr0x@server:~$ sudo dnf -q repoquery --installed --latest-limit=1 kernel
kernel-6.12.0-1.el10_0.x86_64

Ce que cela signifie : Le noyau en cours d’exécution correspond au dernier noyau installé.

Décision : Si ces valeurs ne correspondent pas après une mise à jour, planifiez un redémarrage et consignez-le. « On a patché » ne compte pas tant que vous ne l’exécutez pas.

Trois mini-histoires d’entreprise depuis le terrain

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

Une entreprise de taille moyenne a migré une flotte de services internes depuis un ancien setup CentOS vers un rebuild compatible RHEL.
Ils ont traité l’installation de l’OS comme une formalité et se sont concentrés sur le déploiement applicatif.
L’hypothèse était simple : « l’espace disque est de l’espace disque. Les défauts sont corrects. »

La pile applicative était centrée sur les conteneurs. Les logs étaient bruyants mais gérables — jusqu’à ce qu’un drapeau de débogage soit laissé activé dans un service.
En quelques heures, /var a gonflé. Sur leur installation « les défauts sont corrects », /var vivait sur le système racine.
La racine a atteint 100%, et le système a commencé à échouer de façons qui semblaient sans rapport : connexions SSH bloquées, unités systemd qui dépassaient les délais,
et le nœud a cessé d’accepter de nouvelles pulls de conteneurs.

L’équipe d’astreinte a d’abord chassé un CPU ou un réseau. Les graphiques hurlaient ; le disque criait en silence.
Finalement quelqu’un a lancé df, vu la racine pleine et supprimé des logs. L’hôte a récupéré — en quelque sorte.
Ils ont ensuite eu la suite : téléchargements partiels corrompus et un runtime conteneur nécessitant un reset.

La correction n’a pas été « dire aux développeurs de loguer moins » (bien sûr aussi). La vraie correction a été un schéma de stockage qui partait de l’hypothèse de panne :
séparateur /var, limiter la rétention de journald et expédier les logs hors hôte. L’incident s’est avéré être une leçon d’installation,
pas une leçon applicative, ce qui est un genre d’ennui particulier.

Mini-histoire 2 : L’optimisation qui a mal tourné

Une autre organisation avait un mandat de performance : builds CI plus rapides, téléchargements d’artefacts plus rapides, tout plus rapide.
Quelqu’un a proposé une « optimisation » : monter l’espace de travail de build sur un seul grand filesystem, pas de volumes séparés,
et tuner pour le débit. Ils ont aussi désactivé SELinux parce que « ça ralentit les opérations de fichiers ».

Le CI a effectivement été un peu plus rapide. Puis c’est devenu étrange. Des anomalies de permissions apparaissaient, mais seulement sous charge.
Quelques builds échouaient avec des erreurs de système de fichiers ; les retries réussissaient. Les équipes ont blâmé l’outil CI, le réseau,
et une fois, brièvement, la lune.

La cause racine était un cocktail : tuning agressif plus un workspace générant un énorme churn de métadonnées,
combiné à un pipeline de logs qui provoquait parfois des pics d’écriture disque. Sans isolation entre /, /var
et l’espace de build, la pire journée d’une charge est devenue la pire journée pour tout le monde.
Désactiver SELinux n’a pas « amélioré les performances » ; cela a juste retiré une barrière, et la revue de sécurité qui a suivi les a forcés
à le réactiver sous pression — pendant une fenêtre de sortie trimestrielle. C’était… un choix.

Ils ont annulé l’« optimisation » : volumes logiques séparés, paramètres I/O raisonnables, SELinux Enforcing,
et une approche mesurée du tuning avec des benchmarks représentatifs.
Les temps de build étaient un peu plus lents que la configuration « la plus rapide », mais le taux d’échec a fortement chuté.
En exploitation, le plus rapide n’est que rarement le meilleur.

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

Une équipe proche de la finance exploitait des systèmes de type Rocky pour des services internes.
Leur pratique était douloureusement banale : chaque installation suivait une checklist, chaque hôte avait le même partitionnement,
les dépôts étaient verrouillés, et les mises à jour passaient par un anneau canari.
Ce n’était pas glamour. C’était efficace.

Un matin, un lot d’hôtes a commencé à échouer au démarrage après une mise à jour de firmware réalisée par une autre équipe.
Le mode d’échec variait selon le modèle matériel. Certains systèmes tombaient dans un prompt boot ; d’autres ne trouvaient plus l’entrée EFI.
Là où vous voyez d’habitude la panique et des gens « corriger » manuellement sur la console.

Ils ont récupéré rapidement parce que leur discipline d’installation leur donnait un état prévisible :
UEFI partout, tailles ESP cohérentes, configuration du chargeur standardisée et une méthode standard pour vérifier et reconstruire les entrées EFI.
Ils ont pu comparer un hôte cassé à un hôte connu sain et appliquer les mêmes étapes de récupération sans tâtonnements.

Le résultat n’a pas été une nuit blanche héroïque. Ce fut un incident calme avec un postmortem propre.
Le meilleur compliment que l’exploitation puisse recevoir est : « c’était ennuyeux ». Blague #2 (court, pertinent) : L’infrastructure ennuyeuse est comme une ceinture de sécurité — on ne la remarque que quand elle manque.

Mode d’emploi pour un diagnostic rapide

Quand une installation fraîche de Rocky Linux 10 « semble lente », « ne se met pas à jour » ou « n’atteint pas des choses », n’errer pas.
La priorisation est une séquence. Votre objectif est d’identifier la classe de goulot d’étranglement en quelques minutes.

Première étape : identifier le domaine de panne (démarrage, réseau, stockage, CPU/mémoire, dépôts)

• Problèmes de démarrage : bloqué au chargeur, mode d’urgence, racine manquante, échecs de vérification système de fichiers.
• Problèmes réseau : échecs DNS, impossibilité d’atteindre les dépôts, absence de route par défaut, perte de paquets intermittente.
• Problèmes de stockage : iowait élevé, erreurs de journal, systèmes de fichiers pleins, resets de périphériques.
• Problèmes CPU : charge moyenne élevée, OOM kills, processus en boucle.
• Problèmes dépôts/paquets : conflits de dépendances, timeouts metadata, erreurs GPG.

Deuxième étape : lancez les trois discriminants les plus rapides

1) Espace disque et sanity des inodes

cr0x@server:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/mapper/rl-root   40G  2.3G   38G   6% /
/dev/mapper/rl-var    80G  5.1G   75G   7% /var

Interprétation : Si un système de fichiers critique dépasse ~90%, considérez-le comme cause d’incident jusqu’à preuve du contraire.

Décision : Libérez de l’espace, agrandissez le LV ou réduisez les logs avant toute autre action.

2) DNS et route par défaut

cr0x@server:~$ ip route
default via 10.40.12.1 dev ens192 proto static metric 100
10.40.12.0/24 dev ens192 proto kernel scope link src 10.40.12.34 metric 100

cr0x@server:~$ getent hosts mirrors.rockylinux.org
203.0.113.20   mirrors.rockylinux.org

Interprétation : Si la résolution DNS échoue, les opérations de dépôt et beaucoup d’autres choses échouent.

Décision : Corrigez DNS/routage avant de blâmer dnf ou l’OS.

3) iowait et principaux coupables

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
 1  0      0 312544  42152 812344    0    0   120   220  310  640  6  3 89  2  0
 0  1      0 309812  42152 812512    0    0   320  5400  290  610  4  2 65 29  0
 0  1      0 310120  42160 812600    0    0   280  5100  300  620  5  2 63 30  0
 0  0      0 311004  42160 812900    0    0   140   260  305  635  5  2 90  3  0
 1  0      0 310888  42168 812930    0    0   150   240  320  650  6  3 88  3  0

Interprétation : Des pics sur wa (iowait) suggèrent une contention de stockage ou des problèmes de périphérique.

Décision : Si l’iowait est élevé, arrêtez de tuner le CPU. Investigatez les disques, l’ordonnancement et les services producteurs d’écritures.

Troisième étape : creusez d’un niveau selon ce que vous avez trouvé

• Si le démarrage échoue : vérifiez le journal du démarrage précédent, contrôlez /etc/fstab, vérifiez les entrées EFI.
• Si dnf échoue : vérifiez les dépôts, DNS, horloge et clés GPG ; lisez les messages d’erreur de dnf comme un adulte.
• Si la performance est mauvaise : identifiez si c’est CPU, pression mémoire ou latence de stockage ; ne devinez pas.

Erreurs courantes : symptômes → cause racine → correction

1) « dnf update dépasse le délai »

Symptômes : Cannot download repomd.xml, metadata lente, échecs intermittents.

Cause racine : Mauvaise configuration DNS, problèmes de proxy ou route par défaut cassée.

Correction : Validez le routage et le DNS ; confirmez la synchronisation horaire ; puis retentez.

cr0x@server:~$ curl -I -m 5 https://mirrors.rockylinux.org
HTTP/2 200
date: Tue, 06 Feb 2026 10:45:12 GMT
content-type: text/html

Décision : Si curl n’y accède pas, dnf n’y accédera pas non plus. Corrigez le chemin réseau d’abord.

2) « Après redémarrage, il tombe en mode emergency »

Symptômes : shell d’urgence systemd, message sur un montage qui échoue.

Cause racine : Entrée /etc/fstab incorrecte, UUID erroné, disque manquant ou course avec des montages réseau.

Correction : Utilisez systemctl status et les messages du journal pour identifier l’unité de montage, puis corrigez fstab.

cr0x@server:~$ systemctl --failed
  UNIT           LOAD   ACTIVE SUB    DESCRIPTION
  var.mount      loaded failed failed /var

Décision : Si c’est un montage local, corrigez les UUID. Si c’est un montage réseau, ajoutez des dépendances appropriées ou nofail avec des timeouts raisonnables.

3) « SSH marche, mais tout le reste ne peut pas se connecter »

Symptômes : Vous pouvez vous connecter en SSH, mais HTTPS sortant échoue ou les services internes sont inaccessibles.

Cause racine : Route par défaut manquante, masque de sous-réseau erroné ou firewall bloquant les sorties (moins courant).

Correction : Inspectez les routes et la config des interfaces, confirmez l’atteignabilité de la passerelle.

cr0x@server:~$ ping -c 2 10.40.12.1
PING 10.40.12.1 (10.40.12.1) 56(84) bytes of data.
64 bytes from 10.40.12.1: icmp_seq=1 ttl=64 time=0.388 ms
64 bytes from 10.40.12.1: icmp_seq=2 ttl=64 time=0.402 ms

--- 10.40.12.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss

Décision : Si vous n’atteignez pas la passerelle, arrêtez de blâmer le DNS et corrigez L2/L3 d’abord.

4) « SELinux bloque mon service ; je l’ai désactivé »

Symptômes : Service qui ne démarre pas, refus AVC dans les logs, quelqu’un passe SELinux en permissive/disabled.

Cause racine : Fichiers mal étiquetés, ports non standards ou service configuré en dehors des chemins attendus.

Correction : Lisez le déni, étiquetez correctement, autorisez le type de port si approprié, et maintenez SELinux en enforcing.

cr0x@server:~$ sudo ausearch -m avc -ts recent | tail -n 3
----
type=AVC msg=audit(1738839012.412:911): avc:  denied  { name_connect } for  pid=1420 comm="nginx" dest=8080 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket

Décision : Si c’est une connexion légitime, configurez les ports/étiquettes ; si le comportement est inattendu, considérez-le comme un constat de sécurité.

5) « Le système est lent sous charge ; le CPU semble correct »

Symptômes : Pics de latence, load average élevé, CPU souvent inactif, plaintes des utilisateurs.

Cause racine : Latence de stockage et iowait, souvent due à des rafales de logs, thrash de swap ou disques surchargés.

Correction : Identifiez les processus qui font le plus d’I/O, vérifiez la santé des périphériques, séparez les workloads et ajustez la journalisation.

cr0x@server:~$ iostat -x 1 3
Device            r/s   w/s  rkB/s  wkB/s  await  svctm  %util
sda              5.0  90.0   80.0  7200.0  28.50   1.10  99.0

Décision : Si %util est proche de 100% et que await augmente, vous êtes lié au stockage. Ajoutez des IOPS, réduisez les écritures ou repensez le layout.

6) « On a manqué d’espace mais df indique de l’espace libre »

Symptômes : Écritures échouent, mais df -h montre de l’espace libre.

Cause racine : Épuisement d’inodes (rare sur XFS, plus plausible sur ext4) ou fichiers supprimés mais toujours ouverts.

Correction : Vérifiez l’utilisation des inodes et les fichiers supprimés encore ouverts ; redémarrez les services incriminés si nécessaire.

cr0x@server:~$ df -i
Filesystem            Inodes  IUsed   IFree IUse% Mounted on
/dev/mapper/rl-var    524288  81234  443054   16% /var

cr0x@server:~$ sudo lsof +L1 | head
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NLINK NODE NAME
rsyslogd 901 root    5w   REG  253,1  1048576     0  123 /var/log/messages (deleted)

Décision : Si vous trouvez de gros fichiers supprimés mais encore ouverts, redémarrez le service dans une fenêtre contrôlée pour libérer l’espace.

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

Checklist A: “J’ai besoin d’une installation Rocky Linux 10 fiable”

1. Confirmez les réglages firmware du matériel : UEFI activé, politique secure boot cohérente avec votre organisation.
2. Démarrez l’installateur dans le mode prévu (entrée UEFI, pas legacy).
3. Choisissez un ensemble de paquets minimal sauf si une GUI est requise.
4. Définissez le nom d’hôte, le fuseau horaire et le plan d’adressage réseau.
5. Schéma de stockage :
   • ESP + /boot + LVM
   • Séparer /var pour les systèmes à logs/conteneurs intensifs
   • Redondance pour disques système (RAID1 matériel ou mdraid) si la disponibilité importe
6. Créez un utilisateur administrateur non-root ; configurez les clés SSH.
7. Laissez SELinux Enforcing.
8. Premier démarrage : vérifiez la release OS, le mode de démarrage, le layout disque et les montages de fichiers.
9. Activez et validez la synchronisation du temps.
10. Validez les dépôts ; désactivez tout ce qui n’est pas approuvé.
11. Patchez complètement ; redémarrez ; confirmez que le noyau en cours d’exécution correspond au noyau installé.
12. Confirmez que le firewall tourne ; n’ouvrez que les services/ports nécessaires.

Checklist B: “Standardiser les installations dans une flotte”

1. Rédigez un layout de stockage gold (noms LVM, points de montage, tailles, types de filesystem).
2. Définissez la politique des dépôts : quels dépôts, mirroring, et comment les mises à jour circulent (dev → staging → prod).
3. Décidez des services de base : chronyd activé, firewalld activé, sshd durci, démons inutiles désactivés.
4. Codifiez la configuration avec de l’automatisation (Kickstart + gestion de configuration). Les installations manuelles ne montent pas ; elles se multiplient.
5. Créez des contrôles de validation : mode de boot, SELinux, synchronisation du temps, ports ouverts, seuils d’utilisation disque.
6. Définissez le break-glass : accès console, procédure de secours, et comment récupérer les entrées EFI.

Checklist C: “Avant de déployer une application dessus”

1. Espace : vérifiez les marges de / et /var ; définissez des politiques de rétention.
2. Identité : vérifiez le nom d’hôte, le DNS et la synchronisation du temps.
3. Sécurité : SELinux enforcing ; clés SSH ; politique firewall en place.
4. Mises à jour : patché, redémarré et stable.
5. Observabilité : confirmez la persistance du journal si nécessaire et le transfert des logs opérationnel.

FAQ

1) Rocky Linux 10 est-il « la même chose que RHEL » ?

C’est compatible RHEL dans les aspects qui comptent pour la plupart des workloads : écosystème de paquets, comportement, paramètres par défaut orientés entreprise.
Ce n’est pas le même produit, et il n’inclut pas par défaut le même contrat de support fournisseur.

2) Dois-je installer une interface graphique sur les serveurs ?

Non, sauf si vous avez une bonne raison opérationnelle. Les serveurs sans interface sont plus faciles à patcher, ont une surface d’attaque plus petite,
moins de dépendances, moins de surprises. Utilisez des outils de gestion à distance et des interfaces web quand c’est approprié.

3) XFS ou ext4 pour Rocky Linux 10 ?

XFS est un bon choix par défaut pour l’usage serveur général et scale bien. ext4 est également fiable. Standardisez sur l’un des deux sauf si un workload
exige autre chose. Le gain le plus important vient de la discipline de partitionnement, pas de la religion du filesystem.

4) Ai-je besoin de swap ?

Généralement oui, mais dimensionnez-le selon le workload. Le swap n’est pas une fonctionnalité de performance ; c’est un filet de sécurité. Sur des machines à mémoire limitée,
il peut empêcher un crash immédiat pendant le diagnostic. Sur des workloads sensibles à la latence, vous pouvez le contraindre et vous appuyer sur un bon dimensionnement mémoire.
Ne réalisez pas aveuglément le « 2x RAM » en 2026.

5) Dois-je désactiver SELinux s’il cause des problèmes ?

Non. Corrigez la politique ou l’étiquetage. Désactiver SELinux échange une commodité à court terme contre une fragilité et un risque à long terme.
Si vous devez temporairement passer en permissive pour déboguer, documentez-le et créez un ticket de suivi effectif.

6) Comment garder les installations cohérentes entre environnements ?

Utilisez Kickstart pour l’installation OS et la gestion de configuration pour l’état (utilisateurs, SSH, sysctl, services, config app).
Puis validez avec des contrôles automatisés. Les humains excellent dans le jugement et sont mauvais en précision répétitive.

7) Quel est le bon schéma disque pour les hôtes de conteneurs ?

Séparez /var (et parfois /var/lib selon le runtime) pour que images, layers et logs n’emplissent pas la racine.
Anticipez l’amplification d’écriture. Surveillez les IOPS, pas seulement la capacité. Si vous pouvez placer le stockage conteneur sur des disques séparés, faites-le.

8) Comment savoir si je suis CPU-bound ou storage-bound ?

Vérifiez vmstat pour l’iowait et la file d’attente, puis regardez iostat -x pour la saturation des périphériques.
Une forte utilisation CPU avec peu d’iowait suggère CPU-bound ; un iowait élevé et un %util disque élevé suggèrent storage-bound.

9) Puis-je joindre Rocky Linux 10 à un annuaire d’entreprise ?

Oui. Les prérequis usuels s’appliquent : DNS correct, synchronisation du temps correcte et nom d’hôte cohérent.
Les échecs de jointure à un annuaire sont plus souvent dus à l’horloge et au DNS qu’à l’OS.

10) Quelle est la première chose à automatiser après l’installation ?

La validation de base et le workflow de patching. Si vous n’automatisez qu’une chose, automatisez la partie qui empêche la dérive de configuration :
dépôts, mises à jour, état SELinux, règles firewall, synchronisation du temps et politique de logs.

Conclusion : étapes pratiques suivantes

Rocky Linux 10 vous offre la forme opérationnelle compatible RHEL sur laquelle de nombreuses organisations comptent, sans lier votre capacité basique
à patcher une flotte à un workflow d’abonnement. Voilà la valeur. Le risque est de croire que l’installation est « terminée » quand l’installateur l’a dit.

Étapes suivantes qui rapportent immédiatement :

1. Standardisez le mode de boot et le layout des disques (UEFI + GPT, séparer /var pour les hôtes bruyants, LVM partout où possible).
2. Verrouillez les dépôts et faites des mises à jour une pipeline prévisible (canari → rollout gradué).
3. Gardez SELinux Enforcing et apprenez à lire les dénis plutôt que d’abandonner.
4. Validez après chaque installation en utilisant les tâches pratiques ci-dessus ; transformez-les en contrôles automatisés.
5. Adoptez le playbook de diagnostic rapide pour que votre équipe cesse de deviner et commence à isoler rapidement les goulots.

Si vous faites ces cinq choses, Rocky Linux 10 devient exactement ce que vous vouliez : un OS stable et orienté entreprise qui s’efface en arrière-plan
et vous laisse vous concentrer sur les parties de la production qui sont réellement intéressantes. Comme les utilisateurs.