Installation Oracle Linux 9 : Ksplice, UEK et une base serveur propre

Le modèle mental : OL9, UEK, RHCK et Ksplice

Oracle Linux 9 est une distribution compatible RHEL avec deux pistes de noyau que vous pouvez exécuter :

• RHCK (Red Hat Compatible Kernel) : suit de près les attentes ABI du noyau RHEL en amont.
• UEK (Unbreakable Enterprise Kernel) : le noyau d’Oracle, généralement plus récent, avec des fonctionnalités et des optimisations de performance ciblées pour les charges d’entreprise.

Aucune n’est « toujours correcte ». UEK est souvent un bon choix par défaut pour les déploiements OL, en particulier là où Oracle l’attend (bases de données, I/O stockage/réseau intensifs, certains pilotes). RHCK peut être le choix conservateur lorsque vous avez besoin d’une compatibilité maximale avec des modules noyau tiers validés pour la ligne noyau RHEL, ou quand les outils de conformité de votre organisation supposent des versions de noyau RHEL.

Ksplice est du live patching : appliquer certains correctifs du noyau sans redémarrage. Dans la vraie vie, cela n’élimine pas le besoin de redémarrages pour toujours. Cela change le calendrier des redémarrages de « à chaque fois qu’il y a une CVE du noyau » à « quand vous le planifiez ». C’est une énorme différence si vous avez déjà essayé de coordonner des redémarrages sur des clusters étatful, des middlewares capricieux ou la patience des dirigeants.

Une citation à épingler au-dessus de votre baie : « L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan. Ce n’est pas une citation SRE, mais elle résume la planification des opérations.

Voici l’attitude de base : choisissez une piste de noyau intentionnellement, vérifiez que vous avez démarré ce que vous pensez avoir démarré, rendez les mises à jour prévisibles et limitez la dérive. Vos incidents futurs arriveront toujours, mais ils concerneront de vrais bugs — pas une ambiguïté auto-infligée.

Blague #1 : Si vous ne standardisez pas votre baseline, chaque serveur devient un flocon de neige unique. Et les flocons fondent sous la pression.

Faits et contexte intéressants (parce que l’histoire fuit dans vos incidents)

• Oracle Linux a commencé comme une reconstruction des sources RHEL ; l’ADN « compatible mais avec des options » explique pourquoi RHCK existe aux côtés d’UEK.
• Ksplice était à l’origine une startup (fin des années 2000) axée sur les mises à jour du noyau sans redémarrage ; Oracle l’a acquis et en a fait partie de son offre entreprise.
• UEK a souvent évolué plus rapidement que le flux de noyau RHEL, ce qui peut compter pour l’activation matérielle sur des plateformes plus récentes.
• La stabilité ABI de type RHEL est un objectif de conception ; les fournisseurs tiers testent fréquemment contre cette attente, d’où la pertinence de RHCK.
• Le live patching n’est pas « tous les patchs » : certains changements du noyau sont trop invasifs ; vous aurez toujours besoin de fenêtres de maintenance pour certaines classes de mises à jour.
• Réalités du Secure Boot : il peut être activé et ne pas vous protéger si votre processus opérationnel permet des modules non signés ou des contrôles faibles de la chaîne de démarrage.
• La modularité DNF et l’expansion des dépôts sont devenues un problème opérationnel pratique à l’ère RHEL 8+ ; l’hygiène des dépôts fait maintenant partie de « l’installation ».
• La domination de systemd (depuis le milieu des années 2010 sur les principales distributions) signifie que le comportement des services, les logs de démarrage et les échecs de dépendance sont essentiellement des problèmes systemd maintenant, pas des « scripts init ».

Une base serveur propre qui survit aux opérations réelles

Objectifs de la baseline (ceux qui comptent à 3 h du matin)

• État de démarrage déterministe : vous savez toujours quel noyau vous exécutez et pourquoi.
• Mises à jour prévisibles : les correctifs de sécurité circulent ; les changements cassants n’arrivent pas sans être vus.
• Faible dérive : les hôtes se ressemblent suffisamment pour qu’un seul runbook fonctionne.
• Observable : les logs, la synchronisation de l’heure et les signaux de ressources sont fiables.
• Récupérable : vous pouvez revenir en arrière ou au moins arrêter d’enfoncer la taupinière quand quelque chose sent mauvais.

Composants de la baseline

Pour la plupart des environnements, je veux que ceci soit mis en place tôt :

• UEK ou RHCK choisi intentionnellement, l’autre étant supprimé ou du moins non par défaut.
• Ksplice activé et surveillé si vous avez l’abonnement/l’entitlement et le besoin opérationnel.
• Politique de dépôts : seuls les dépôts requis sont activés ; pas de dépôts « testing » en production.
• Mises à jour de sécurité automatiques (ou au moins notifications automatiques), avec une fenêtre de maintenance prise en charge par une personne pour les redémarrages.
• Synchronisation de l’heure via chrony ; la dérive de l’heure ruine les timelines d’incident et l’authentification.
• Politique de pare-feu qui correspond à l’exposition réelle des services, pas « ouvert et prier ».
• SELinux en mode enforcing sauf si vous pouvez justifier l’exception par des preuves.
• Crash kernel (kdump) activé pour les systèmes où les pannes du noyau seraient coûteuses à diagnostiquer.
• Vérifications de sanity du stockage : ordonnanceur correct, options de montage correctes, pas de réglages « ça semblait plus rapide » sans mesure.

Opinion : si vous n’êtes pas prêt à exécuter SELinux en mode enforcing, vous n’êtes pas prêt à exposer des services sur Internet. « Interne seulement » n’est pas un champ de force ; c’est une rumeur.

Tâches pratiques : commandes, signaux attendus et décisions

Ce sont des vérifications réelles que vous pouvez coller dans un terminal. Chaque tâche inclut ce que la sortie signifie et la décision que vous devez prendre en fonction de celle-ci. Faites-les dans l’ordre sur une installation OL9 fraîche, puis intégrez les résultats dans l’automatisation.

Task 1: Confirm OS release and baseline identity

cr0x@server:~$ cat /etc/os-release
NAME="Oracle Linux Server"
VERSION="9.4"
ID="ol"
ID_LIKE="fedora"
VERSION_ID="9.4"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Oracle Linux Server 9.4"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:9:4:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://github.com/oracle/oracle-linux"
ORACLE_BUGZILLA_PRODUCT="Oracle Linux 9"
ORACLE_BUGZILLA_PRODUCT_VERSION=9.4

Sens : Confirme que vous êtes réellement sur Oracle Linux 9.x, pas sur un template ressemblant. Le PLATFORM_ID et le CPE_NAME montrent la famille EL9.

Décision : Enregistrez la version dans le CMDB/inventaire d’actifs ; alignez les cibles de dépôts et la politique de patch sur la même ligne mineure sur l’ensemble du parc quand c’est possible.

Task 2: Check what kernel you’re currently running

cr0x@server:~$ uname -r
5.15.0-201.135.6.el9uek.x86_64

Sens : el9uek dans la chaîne de version indique UEK. Si vous voyez .el9.x86_64 sans uek, c’est RHCK.

Décision : Si cela ne correspond pas à votre standard, arrêtez-vous et corrigez-le maintenant. Le plan « on nettoiera plus tard » est la façon dont les flottes dérivent.

Task 3: Confirm which kernel is set as default for next boot

cr0x@server:~$ sudo grubby --default-kernel
/boot/vmlinuz-5.15.0-201.135.6.el9uek.x86_64

Sens : C’est ce que GRUB démarrera par défaut, pas nécessairement ce que vous exécutez aujourd’hui.

Décision : Si le noyau par défaut diffère de uname -r, vous êtes à un redémarrage d’une surprise. Alignez-les.

Task 4: List installed kernels (spot dual-track installs)

cr0x@server:~$ rpm -qa | egrep '^kernel|^kernel-uek' | sort
kernel-5.14.0-427.13.1.el9_4.x86_64
kernel-core-5.14.0-427.13.1.el9_4.x86_64
kernel-modules-5.14.0-427.13.1.el9_4.x86_64
kernel-uek-5.15.0-201.135.6.el9uek.x86_64
kernel-uek-core-5.15.0-201.135.6.el9uek.x86_64
kernel-uek-modules-5.15.0-201.135.6.el9uek.x86_64

Sens : Vous avez à la fois RHCK et UEK installés. C’est courant après des migrations ou des installations « au cas où ».

Décision : Choisissez une piste comme standard. Si vous conservez les deux, documentez pourquoi et assurez-vous que le noyau par défaut est explicite. Sinon, supprimez la piste inutilisée pour réduire la confusion.

Task 5: Verify enabled repositories (repo hygiene)

cr0x@server:~$ sudo dnf repolist --enabled
repo id                                   repo name
ol9_baseos_latest                         Oracle Linux 9 BaseOS Latest (x86_64)
ol9_appstream                             Oracle Linux 9 Application Stream (x86_64)
ol9_uek_latest                            Latest Unbreakable Enterprise Kernel Release 7 for Oracle Linux 9 (x86_64)
ol9_ksplice                               Ksplice for Oracle Linux 9 (x86_64)

Sens : Ce sont les sources de vérité pour les paquets et les noyaux. Les dépôts supplémentaires sont la façon dont vous importez accidentellement des bizarreries.

Décision : Désactivez tout ce que vous ne pouvez pas expliquer. Si vous n’avez pas l’entitlement pour Ksplice, ne laissez pas le dépôt à moitié configuré.

Task 6: Check package update posture (what’s pending)

cr0x@server:~$ sudo dnf -q check-update
kernel-uek.x86_64                  5.15.0-201.138.1.el9uek        ol9_uek_latest
openssl-libs.x86_64                1:3.0.7-29.el9_4               ol9_baseos_latest

Sens : Les mises à jour en attente incluent un noyau et des bibliothèques userland. C’est normal.

Décision : Décidez si vous appliquez immédiatement (nouvelle build) ou si vous mettez en scène. Si Ksplice est activé, la mise à jour du noyau devient une décision « live patch d’abord, redémarrage plus tard ».

Task 7: Confirm Secure Boot state (don’t guess)

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

Sens : Secure Boot est activé au niveau du firmware. S’il est désactivé, vous pouvez quand même être correct — mais c’est une décision de politique, pas un haussement d’épaules par défaut.

Décision : Si votre posture de conformité exige Secure Boot, corrigez-le tôt. L’activer plus tard peut casser les flux de travail avec des pilotes non signés.

Task 8: Check SELinux mode (security baseline reality)

cr0x@server:~$ getenforce
Enforcing

Sens : SELinux est actif et applique la politique. Permissive est le « mode audit » ; disabled, c’est « je vis dangereusement ».

Décision : Gardez en enforcing sauf si vous avez une incompatibilité connue. Si quelque chose casse, écrivez une politique locale ou ajustez les contextes ; ne le désactivez pas simplement.

Task 9: Validate time sync (incident timelines depend on it)

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

Sens : L’horloge est synchronisée, le service NTP est actif et vous utilisez UTC (bon). Si synchronized: no, vos logs vous feront douter de la réalité.

Décision : Si non synchronisé, corrigez chrony avant toute autre action. Déboguer avec une heure incorrecte est de l’automutilation.

Task 10: Confirm network identity and DNS (basic, but breaks everything)

cr0x@server:~$ hostnamectl
 Static hostname: ol9-db-01
       Icon name: computer-server
         Chassis: server
      Machine ID: 2f9b2c9d0d6a4d4a8c1d3b0d3b2c4a11
         Boot ID: 8a42f5d7e7f747a0a5f01d72bbf05d61
Operating System: Oracle Linux Server 9.4
          Kernel: Linux 5.15.0-201.135.6.el9uek.x86_64
    Architecture: x86-64

Sens : Le nom d’hôte est défini ; le noyau affiché correspond à ce que vous attendiez. Des noms d’hôte incohérents provoquent des collisions de supervision et des problèmes de certificats.

Décision : Standardisez les modèles de nommage d’hôtes ; assurez-vous que le DNS forward/reverse est correct pour tout ce qui utilisera TLS ou des systèmes du type Kerberos.

Task 11: See what’s listening (catch accidental exposure)

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

Sens : Seul SSH est ouvert sur le monde ; chrony est local. Si vous voyez des services aléatoires sur 0.0.0.0, votre « installation minimale » ne l’était pas.

Décision : Si un service écoute et que vous ne l’avez pas demandé, désactivez-le. Les services ouverts par défaut sont une erreur de carrière.

Task 12: Firewall status and actual rules

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

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

Sens : Le pare-feu fonctionne et seul SSH est autorisé dans la zone publique.

Décision : Gardez ceci serré. Ouvrez des ports dans le cadre du déploiement applicatif, pas lors de l’installation du serveur.

Task 13: Check storage layout and mount options (avoid accidental foot-guns)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
NAME        TYPE   SIZE FSTYPE MOUNTPOINTS
sda         disk   200G
├─sda1      part   600M vfat   /boot/efi
├─sda2      part     1G xfs    /boot
└─sda3      part 198.4G LVM2_member
  ├─ol-root lvm     80G xfs    /
  ├─ol-var  lvm     60G xfs    /var
  └─ol-home lvm   58.4G xfs    /home

Sens : Un /var séparé est généralement une bonne idée pour les logs, caches de paquets et bases de données qui débordent. LVM vous donne des options de redimensionnement quand la réalité arrive.

Décision : Pour les serveurs hébergeant des services étatful, séparez volontairement /var (et souvent /var/log). Si vous gardez tout sur /, documentez votre plan de croissance.

Task 14: Check I/O scheduler and queue settings (don’t tune blind)

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

Sens : L’ordonnanceur courant est mq-deadline. Sur des disques SSD modernes en virtualisation, c’est souvent bien ; sur certains arrays, none peut aussi être approprié.

Décision : Ne changez pas d’ordonnanceur parce qu’un blog vous l’a dit. Changez-le seulement après un test de charge mesuré et avec un plan de rollback.

Task 15: Confirm swap and memory pressure posture

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi       2.1Gi        26Gi       128Mi       3.0Gi        28Gi
Swap:          4.0Gi          0B       4.0Gi

Sens : Un espace d’échange existe et n’est pas utilisé ; bien. Ne pas avoir de swap n’est pas un « tuning de performance », c’est jouer au poker avec l’OOM killer.

Décision : Gardez le swap pour la plupart des serveurs généralistes ; dimensionnez-le sensiblement. Pour des systèmes de base de données spécialisés, décidez délibérément et testez les modes d’échec.

Task 16: Audit boot errors quickly (don’t wait for the ticket)

cr0x@server:~$ sudo journalctl -b -p warning --no-pager | tail -n 20
Feb 05 10:01:18 ol9-db-01 kernel: ACPI: \_SB_.PLTF.C000: Failed to evaluate _DSM (0x1001)
Feb 05 10:01:20 ol9-db-01 systemd[1]: Failed to start Crash recovery kernel arming.
Feb 05 10:01:20 ol9-db-01 systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE

Sens : Le démarrage a des avertissements ; kdump a échoué. Ce n’est pas nécessairement fatal, mais c’est une déviation de la baseline.

Décision : Corrigez kdump si vous avez besoin des dumps de crash ; sinon désactivez-le intentionnellement pour qu’il ne devienne pas du bruit qui masque de vraies erreurs de démarrage.

Ksplice sur OL9 : ce dont vous avez réellement besoin

Ksplice est un levier opérationnel. Mais seulement si vous le traitez comme un système, pas comme une case à cocher.

Ce pour quoi Ksplice est utile

• Réduire le nombre de redémarrages d’urgence pour les CVE du noyau.
• Acheter du temps pour coordonner des fenêtres de maintenance.
• Maintenir des services sensibles à l’uptime stables tout en patchant.

Ce que Ksplice n’est pas

• Une garantie que vous ne redémarrerez jamais.
• Un remplacement pour la mise à niveau des bibliothèques userland (OpenSSL, glibc, etc.).
• Une baguette magique pour les noyaux cassés, les mauvais pilotes ou les problèmes de firmware.

Vérifications de base pour la préparation Ksplice

Task 17: Verify ksplice tooling installed

cr0x@server:~$ rpm -q ksplice-uptrack
ksplice-uptrack-1.0.2-14.el9.x86_64

Sens : Le paquet existe. S’il n’est pas installé, vous ne faites pas de live patching.

Décision : Si vous avez l’intention d’utiliser Ksplice, installez l’outillage comme partie de l’image de base ; ne comptez pas sur des étapes post-install manuelles.

Task 18: Check ksplice service status

cr0x@server:~$ sudo systemctl status uptrack.service --no-pager
● uptrack.service - Ksplice Uptrack service
     Loaded: loaded (/usr/lib/systemd/system/uptrack.service; enabled; preset: disabled)
     Active: active (running) since Tue 2026-02-05 10:05:12 UTC; 6min ago
   Main PID: 1523 (uptrack)
     Tasks: 3
     Memory: 12.4M
        CPU: 0.220s
     CGroup: /system.slice/uptrack.service
             └─1523 /usr/sbin/uptrack -d

Sens : Le service est en cours d’exécution. Notez l’état « enabled » ; vous voulez qu’il soit persistant après redémarrage.

Décision : S’il est inactif, vérifiez les entitlements et la configuration. Si vous ne voulez pas Ksplice, désactivez-le et supprimez-le — des agents à moitié configurés créent une fausse confiance.

Task 19: List applied and available Ksplice updates

cr0x@server:~$ sudo uptrack-show --available
Effective kernel version is 5.15.0-201.135.6.el9uek.x86_64
Updates available:
[0t9s] CVE-2025-12345: Fix for kernel issue in netfilter
[1a2b] CVE-2025-23456: Fix for kernel issue in io_uring

Sens : Ksplice voit votre noyau effectif et a des correctifs live disponibles.

Décision : Si rien n’est disponible, cela peut être normal. Si des mises à jour existent et que vous êtes dans une fenêtre de patch, appliquez-les. Si Ksplice ne peut pas déterminer le noyau effectif, vous avez probablement un mismatch de noyau ou un état non supporté.

Task 20: Apply Ksplice updates (when policy allows)

cr0x@server:~$ sudo uptrack-upgrade -y
Installing [0t9s]... ok
Installing [1a2b]... ok
Your kernel is fully up to date.

Sens : Les live patches ont été appliqués avec succès.

Décision : Enregistrez l’événement de patching (ticket/CMDB). Si les patches échouent, n’essayez pas de relancer aveuglément — capturez les logs et envisagez une mise à jour normale du noyau + redémarrage.

Task 21: Confirm reboot requirement state (Ksplice doesn’t cancel physics)

cr0x@server:~$ sudo dnf -q needs-restarting -r || true
No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

Sens : Du point de vue du gestionnaire de paquets, vous n’avez pas besoin de redémarrage pour des changements userland. Cela ne signifie pas que vous ne devez jamais redémarrer, mais cela réduit l’urgence.

Décision : Utilisez ceci pour justifier le report des redémarrages aux fenêtres planifiées, pas pour les éviter indéfiniment. Vous voulez toujours des redémarrages périodiques pour le firmware/les pilotes, les upgrades de noyau au-delà des live patches et l’hygiène générale.

Sélection de l’UEK et hygiène de démarrage

Les erreurs de piste de noyau sont coûteuses parce qu’elles apparaissent tard : un pilote se comporte différemment, la performance change, ou un module tiers refuse de se charger après un redémarrage.

Choisissez un standard : UEK par défaut, sauf raison de compatibilité

Mon choix par défaut dans les environnements Oracle Linux est UEK pour les charges serveur typiques sauf si :

• Vous dépendez d’un module noyau tiers certifié uniquement contre la ligne noyau RHEL.
• Vous avez une exigence réglementaire ou fournisseur qui référence explicitement le flux noyau compatible.
• Vous essayez de minimiser les différences entre des flottes OL et RHEL.

Task 22: Install UEK kernel packages (if not already present)

cr0x@server:~$ sudo dnf install -y kernel-uek
Last metadata expiration check: 0:18:10 ago on Tue 05 Feb 2026 09:54:21 AM UTC.
Dependencies resolved.
====================================================================
 Package                Arch       Version                         Repo            Size
====================================================================
Installing:
 kernel-uek              x86_64     5.15.0-201.138.1.el9uek         ol9_uek_latest  17 M

Transaction Summary
====================================================================
Install  1 Package

Complete!

Sens : Le noyau UEK est installé. Vous devez toujours vous assurer qu’il est l’entrée de démarrage par défaut.

Décision : Si c’est un système de production, planifiez un redémarrage pour valider que le nouveau noyau démarre correctement avant de qualifier la build de « gold ».

Task 23: Set the default kernel explicitly

cr0x@server:~$ sudo grubby --set-default /boot/vmlinuz-5.15.0-201.138.1.el9uek.x86_64

cr0x@server:~$ sudo grubby --default-kernel
/boot/vmlinuz-5.15.0-201.138.1.el9uek.x86_64

Sens : Le prochain démarrage utilisera l’image UEK prévue.

Décision : Épinglez-le. Ne comptez pas sur le comportement « latest wins » de GRUB quand plusieurs familles de noyau sont installées.

Task 24: Remove the unused kernel family (optional, but reduces confusion)

cr0x@server:~$ sudo dnf remove -y 'kernel*5.14.0*' 'kernel-core*5.14.0*' 'kernel-modules*5.14.0*'
Dependencies resolved.
====================================================================
 Package                Arch   Version                    Repository    Size
====================================================================
Removing:
 kernel                  x86_64 5.14.0-427.13.1.el9_4      @System      0
 kernel-core             x86_64 5.14.0-427.13.1.el9_4      @System     25 M
 kernel-modules          x86_64 5.14.0-427.13.1.el9_4      @System     34 M

Transaction Summary
====================================================================
Remove  3 Packages

Complete!

Sens : Les paquets RHCK ont été supprimés (dans cet exemple). Vous avez toujours UEK installé.

Décision : Si cet hôte doit supporter les deux (rare), conservez-les mais documentez la raison et assurez-vous que le noyau par défaut est géré via la gestion de configuration.

Stratégie de mises à jour : sécurité, stabilité et contrôle des changements

Mettre à jour n’est pas une simple commande. C’est une politique avec des outils associés.

Mises à jour de sécurité : rendez-les routinières

Si vous ne pouvez pas automatiser les mises à jour de sécurité, au moins automatisez la visibilité. Les humains sont des planificateurs peu fiables.

Task 25: See security advisories for pending updates

cr0x@server:~$ sudo dnf updateinfo list --security
OLSA-2026-0001 Important/Sec.  openssl-libs-1:3.0.7-29.el9_4.x86_64
OLSA-2026-0002 Moderate/Sec.   curl-7.76.1-29.el9_4.x86_64

Sens : Des avis de sécurité existent pour des paquets spécifiques.

Décision : Si ces paquets font partie de votre chemin d’exécution (ce qui est généralement le cas), planifiez le patch. Pour les systèmes exposés à Internet, « Important » n’est pas optionnel.

Task 26: Apply updates with a conservative posture

cr0x@server:~$ sudo dnf upgrade -y
Dependencies resolved.
====================================================================
 Package             Arch   Version                      Repo               Size
====================================================================
Upgrading:
 openssl-libs         x86_64 1:3.0.7-29.el9_4             ol9_baseos_latest  1.5 M

Transaction Summary
====================================================================
Upgrade  1 Package

Complete!

Sens : Un paquet userland a été mis à niveau. Le noyau peut rester en attente selon votre approche.

Décision : Après les mises à jour, lancez needs-restarting pour décider si des services doivent être redémarrés ou si un reboot est nécessaire.

Task 27: Identify services needing restart due to updated libraries

cr0x@server:~$ sudo dnf needs-restarting || true
sshd : 1032
chronyd : 980

Sens : Ces processus fonctionnent avec d’anciennes bibliothèques mappées ; ils devraient être redémarrés pour appliquer complètement les mises à jour.

Décision : Redémarrez les services dans un ordre contrôlé. Pour SSH, soyez prudent : gardez une session active ouverte lors du redémarrage pour éviter de vous verrouiller.

Task 28: Lock down package sources and prevent accidental repo enablement

cr0x@server:~$ sudo dnf config-manager --set-disabled ol9_developer_EPEL
Error: No matching repo to modify: ol9_developer_EPEL.

Sens : Le dépôt n’est pas présent ; bien. S’il était présent et activé, vous voudriez le désactiver en production.

Décision : Gérez explicitement les dépôts activés dans l’automatisation. « Il n’était pas activé sur ma machine » n’est pas un contrôle.

Trois mini-récits d’entreprise issus du terrain

Incident causé par une mauvaise hypothèse : « UEK est installé, donc nous devons l’exécuter »

Dans une entreprise de taille moyenne, une équipe a standardisé sur Oracle Linux pour une flotte de serveurs applicatifs. Le doc baseline disait « installer UEK » et la pipeline de build l’a fait exactement. Quelque part dans la chaîne de redémarrage, cependant, le noyau par défaut est resté RHCK parce que l’image venait initialement d’un template qui avait RHCK en premier dans l’ordre GRUB.

Pendant des mois, rien ne semblait cassé. La supervision était verte. Les performances étaient correctes. Puis un redémarrage de maintenance a touché un sous-ensemble de nœuds et soudain une fonctionnalité NIC tiers s’est comportée différemment. Le symptôme était vilain : pertes sporadiques de paquets sous charge et retransmissions qui semblaient « réseau » mais sentaient « noyau ». L’équipe a traqué des ports de switch, accusé le câblage et ouvert des tickets fournisseur. Le temps a disparu.

La correction était embarrassante de simplicité : confirmer le noyau en cours d’exécution, confirmer le noyau par défaut, puis les aligner. La leçon n’était pas « UEK mauvais » ou « RHCK mauvais ». C’était que l’installation d’un paquet n’est pas la même chose que son démarrage. Toute baseline qui ne vérifie pas l’état de démarrage est une histoire du soir.

Par la suite, ils ont ajouté deux vérifications à l’acceptation de build : uname -r doit correspondre à la piste prévue, et grubby --default-kernel doit correspondre à uname -r. Ça a pris des minutes. Ça a sauvé des jours plus tard.

Optimisation qui s’est retournée contre eux : « Désactivons le swap pour réduire la latence »

Une autre organisation exécutait des services à faible latence et a décidé que le swap était l’ennemi. Quelqu’un avait lu un fil de discussion sur les performances et a pris la conclusion personnellement. Le swap a été retiré de la baseline. Les serveurs semblaient « plus réactifs » dans un benchmark étroit, donc le changement paraissait justifié.

Puis est venue la fuite lente : un service Java avec un bug de croissance mémoire qui poussait normalement quelques pages froides vers le swap sous pression. Sans swap, la pression mémoire est passée de « légèrement dégradée » à « OOM instantané ». Le noyau a commencé à tuer des processus. Pas toujours le gros évident — parfois il tuait d’abord le sidecar ou un agent de logging, ce qui a rendu l’incident plus difficile à interpréter.

Le pire était le mode d’échec. Ce n’était pas une dégradation élégante. C’était une boucle de plantage chaotique qui ressemblait à un bug applicatif (ce qu’il était) mais qui se comportait comme une instabilité d’infrastructure (ça le devenait). Ils ont réintroduit le swap avec un dimensionnement sensé, ajusté les limites mémoire correctement et utilisé des cgroups pour contraindre les plus mauvais coupables. L’« optimisation » avait réduit un type de latence et augmenté le temps moyen pour revenir à la raison de beaucoup.

Blague #2 : Désactiver le swap pour « améliorer les performances » revient à enlever la roue de secours pour « réduire le poids ». Techniquement vrai jusqu’à ce que la route devienne intéressante.

Pratique ennuyeuse mais correcte qui a sauvé la mise : « Séparer /var et le surveiller »

Dans un environnement réglementé, l’équipe sécurité exigeait une journalisation verbeuse. L’équipe ops a fait quelque chose de profondément peu sexy : ils ont séparé /var en volume logique dédié, ajouté des alertes sur l’espace libre et maintenu une rotation des logs stricte. Personne n’a applaudi. Personne n’a écrit d’article de blog à ce sujet.

Un matin, un fournisseur d’authentification en amont a eu des échecs intermittents. Les applications ont commencé à réessayer, et les tempêtes de retry ont amplifié le volume de logs. Sur beaucoup de systèmes, ce type d’événement remplit le système de fichiers racine et vous obtenez des défaillances en cascade : le gestionnaire de paquets casse, les services ne peuvent plus écrire d’état, les connexions SSH échouent, et la récupération devient une aventure hands-on à distance.

Ici, root est resté sain. Seul /var a été touché, les alertes se sont déclenchées tôt et l’équipe a eu de la marge de manœuvre : ils ont limité les retries, augmenté temporairement la rotation et nettoyé la croissance. L’incident a quand même fait mal, mais il ne s’est pas transformé en panne système totale. Le meilleur travail ops ressemble à rien ne s’est passé.

Playbook de diagnostic rapide

Voici la séquence « entrer dans la pièce en feu ». Elle suppose OL9, mais la plupart des étapes sont universelles. L’objectif est de trouver rapidement le goulot : CPU, mémoire, disque, réseau, ou « le noyau n’est pas ce que vous croyez ».

Première étape : confirmez que vous êtes sur le noyau que vous pensez

cr0x@server:~$ uname -r
5.15.0-201.135.6.el9uek.x86_64

cr0x@server:~$ sudo grubby --default-kernel
/boot/vmlinuz-5.15.0-201.135.6.el9uek.x86_64

Signal : Une discordance signifie que vous êtes à un redémarrage d’un nouveau mode de défaillance. Aussi, certaines anomalies de performance se corrèlent avec des différences de piste de noyau.

Décision : Si mismatch, traitez cela comme une dérive de configuration et corrigez avant d’aller plus loin dans le tuning.

Deuxième étape : identifiez la pression de ressource en 60 secondes

cr0x@server:~$ uptime
 10:19:52 up  2:31,  2 users,  load average: 7.22, 6.91, 6.80

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
 3  0      0 26800000 120000 2100000  0    0     2     7  120  240  3  1 95  1  0
 8  2      0  900000 110000 2200000  0    0  8000 12000 1400 2200  5  3 55 37  0

Signal : Un wa élevé (iowait) suggère une latence ou saturation du stockage. Un r élevé avec peu d’idle suggère une contention CPU. Les swap-in/out suggèrent une pression mémoire.

Décision : Choisissez la classe de goulot la plus probable et creusez là-bas, pas partout à la fois.

Troisième étape : si l’iowait est élevé, prouvez-le avec les stats par périphérique

cr0x@server:~$ iostat -xz 1 3
Linux 5.15.0-201.135.6.el9uek.x86_64 (ol9-db-01)  02/05/2026  _x86_64_  (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.20    0.00    3.10   34.50    0.00   56.20

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
sda              65.0   5200.0     0.0    0.0   18.5     80.0    110.0  14500.0     2.0    1.8   35.2    131.8    5.3   92.0

Signal : Un await élevé, un %util élevé et une aqu-sz croissante = le stockage est le goulot.

Décision : Vérifiez le backend de stockage, la profondeur de la file d’attente, les voisins bruyants, le système de fichiers et les patterns d’I/O applicatifs avant de toucher au tuning CPU.

Quatrième étape : si le CPU est élevé, trouvez les principaux coupables et leurs appels système

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
  PID COMMAND         %CPU %MEM
 2412 java            380  22.1
 1530 node             95   3.2
  980 chronyd           2   0.1

Signal : Un processus unique dominant signifie que vous pouvez vous concentrer. Beaucoup de processus utilisant chacun un peu suggère une contention ou un thundering herd.

Décision : Pour les coupables uniques, vérifiez le profiling applicatif et les limites. Pour les foules, examinez les tempêtes de connexions, les boucles de retry et la contention de verrous.

Cinquième étape : si ça « ressemble au réseau », validez pertes et erreurs

cr0x@server:~$ ip -s link show dev ens192
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:50:56:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
      987654321  1234567      0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
      876543210  1122334      0       0       0       0

Signal : Des drops ou des erreurs existent ; ce n’est pas une preuve de cause racine, mais un indice. En environnements virtualisés, les drops peuvent être dus à une congestion côté hôte.

Décision : Si les drops sont non nuls et en augmentation, corrélez avec la charge et vérifiez les métriques vSwitch/hôte ; n’allez pas réécrire immédiatement les réglages TCP.

Erreurs courantes : symptômes → cause racine → correction

1) « Ksplice est installé mais rien ne se patch »

Symptômes : uptrack-show affiche des erreurs, le service n’est pas en cours d’exécution, ou aucune mise à jour n’apparaît jamais.

Cause racine : Entitlement de dépôt manquant, agent non activé, ou exécution d’une piste/version de noyau non supportée pour le canal Ksplice configuré.

Correction : Vérifiez que dnf repolist --enabled inclut le dépôt Ksplice, assurez-vous de systemctl enable --now uptrack.service, et confirmez que uname -r correspond au flux UEK/RHCK attendu pour le support Ksplice.

2) « Après le reboot, le noyau a changé de manière inattendue »

Symptômes : Le système redémarre et maintenant les pilotes/performances diffèrent ; uname -r montre une famille différente.

Cause racine : L’entrée GRUB par défaut n’est pas définie ; les deux familles de noyau sont installées ; des mises à jour ont installé un noyau plus récent de l’autre famille.

Correction : Utilisez grubby --default-kernel et grubby --set-default pour épingler ; supprimez les paquets noyau inutilisés ou gérez explicitement GRUB via la gestion de configuration.

3) « DNF apporte des versions inattendues »

Symptômes : Une mise à niveau routine apporte des paquets inattendus ; les chaînes de dépendance semblent étranges.

Cause racine : Dépôts supplémentaires activés (souvent developer/testing), ou flux modulaires discordants entre hôtes.

Correction : Appliquez des listes blanches de dépôts, auditez avec dnf repolist --enabled, et standardisez les streams modulaires si vous les utilisez.

4) « Le redémarrage de ssh m’a verrouillé hors du système »

Symptômes : Redémarrage d’sshd pendant le patch, perte de connectivité.

Cause racine : Config firewall erronée, erreur de configuration sshd, ou vous étiez connecté via un bastion fragile sans solution de repli.

Correction : Validez la config avec sshd -t avant de redémarrer, gardez une seconde session ouverte et utilisez l’accès console pour les changements critiques.

5) « Iowait élevé après un ‘tuning stockage’ »

Symptômes : Pics de latence ; applications lentes ; iostat montre un await élevé.

Cause racine : Changement de l’ordonnanceur I/O ou des paramètres de file sans tenir compte du backend ou de la virtualisation ; options de système de fichiers/montage mal alignées.

Correction : Revenez au tuning précédent ; basez-vous sur l’ordonnanceur par défaut ; mesurez avec une charge représentative ; coordonnez-vous avec l’équipe stockage sur la profondeur de file et le comportement de l’array.

6) « Les logs ont disparu ou le système a gelé à cause d’un disque plein »

Symptômes : Services en échec, erreurs du gestionnaire de paquets, le noyau rapporte des échecs d’écriture.

Cause racine : Système de fichiers racine rempli par des logs ou des données applicatives ; absence d’alertes sur la croissance.

Correction : Séparez /var (et parfois /var/log), activez une rotation agressive des logs, alertez sur l’utilisation des systèmes de fichiers et limitez les logs applicatifs hors contrôle.

7) « Secure Boot activé, mais les modules noyau ne se chargent pas »

Symptômes : Les pilotes/modules n’arrivent pas à se charger après activation de Secure Boot ; dmesg montre des problèmes de signature.

Cause racine : Modules tiers non signés et un processus opérationnel qui n’a jamais géré la signature/l’enrôlement des clés MOK.

Correction : Soit signez correctement les modules et gérez les clés MOK, soit gardez Secure Boot désactivé par politique — ne restez pas dans un état intermédiaire indéfini.

Checklists / plan étape par étape

Image gold baseline (faites-le une fois, automatisez pour toujours)

1. Installez OL9 minimal là où c’est approprié ; évitez les groupes de paquets supplémentaires sauf besoin.
2. Définissez hostname, DNS et fuseau horaire (utilisez UTC sauf raison légale contraire).
3. Choisissez la piste noyau :
   • UEK pour les flottes Oracle Linux typiques.
   • RHCK si un fournisseur l’exige ou si vous avez besoin d’un alignement étroit avec RHEL.
4. Épinglez le noyau par défaut avec grubby ; supprimez l’autre famille de noyau si vous n’en avez pas besoin.
5. Activez uniquement les dépôts requis ; vérifiez avec dnf repolist --enabled.
6. Activez SELinux en mode enforcing ; corrigez les problèmes de politique au lieu de désactiver.
7. Configurez chrony et vérifiez la synchronisation de l’heure.
8. Configurez le pare-feu : n’autorisez que ce qui est requis ; validez avec ss et firewall-cmd.
9. Partitionnez sensiblement : séparez /var pour la plupart des rôles serveur ; assurez-vous d’un plan de croissance.
10. Décidez pour Ksplice :
    • Si vous l’utilisez, installez l’agent, activez le service, validez l’application des patches.
    • Si vous ne l’utilisez pas, ne faites pas semblant — supprimez les paquets et désactivez les dépôts.
11. Appliquez les mises à jour, puis décidez : redémarrer des services vs redémarrage complet. Utilisez needs-restarting.
12. Redémarrez une fois pendant la validation de la build pour assurer qu’elle revient proprement sur le noyau prévu.
13. Capturez l’état « connu bon » : noyau, dépôts activés, modules chargés, ports à l’écoute, disposition des systèmes de fichiers.

Opérations récurrentes (rythme hebdomadaire)

• Exécutez la visibilité des mises à jour de sécurité (dnf updateinfo list --security).
• Appliquez régulièrement les mises à jour userland ; redémarrez les services concernés délibérément.
• Appliquez les mises à jour Ksplice quand elles sont disponibles (si la politique le permet).
• Planifiez des redémarrages périodiques (mensuel/trimestriel) même avec le live patching.
• Auditez la dérive : famille de noyau, liste de dépôts, services du pare-feu, mode SELinux.

Vérifications pré-fenêtre de maintenance (par hôte)

• uname -r et grubby --default-kernel correspondent.
• dnf check-update revu ; noyau et bibliothèques critiques notés.
• dnf needs-restarting revu après mises à jour.
• Accès console vérifié pour les sites distants.
• Sauvegardes/snapshots validés pour les systèmes étatful.

FAQ

1) Dois-je utiliser UEK ou RHCK sur Oracle Linux 9 ?

Par défaut, choisissez UEK pour la plupart des flottes Oracle Linux, surtout si vous exécutez des charges Oracle ou que vous voulez des fonctionnalités noyau plus récentes. Utilisez RHCK lorsque un fournisseur tiers ne certifie que la ligne noyau compatible RHEL ou que votre organisation exige un alignement strict sur le noyau RHEL.

2) Puis-je installer à la fois UEK et RHCK « au cas où » ?

Vous pouvez, mais vous achetez de la confusion. Si vous conservez les deux, vous devez épingler le noyau par défaut et le vérifier en continu. Sinon vous redémarrerez dans une famille de noyau différente et appellerez cela « aléatoire ».

3) Ksplice élimine-t-il tous les redémarrages ?

Non. Il réduit la pression des redémarrages urgents pour de nombreuses corrections de type CVE du noyau, mais vous aurez toujours besoin de redémarrages pour certains changements de noyau, mises à jour de firmware, changements de pilotes et hygiène du cycle de vie.

4) Pourquoi grubby --default-kernel importe-t-il si uname -r semble correct ?

Parce que uname -r est « ce que vous avez démarré », tandis que grubby est « ce que vous démarrerez ». Les pannes adorent l’écart entre ces deux phrases.

5) Dois-je activer les mises à jour automatiques sur les serveurs OL9 ?

Activez uniquement les mises à jour de sécurité automatiques si vous avez une procédure de rollback testée et que vous comprenez vos exigences de contrôle des changements. Au minimum, automatisez le reporting des avis de sécurité et gardez des fenêtres de maintenance fréquentes.

6) Quel est l’ensemble minimal de dépôts à garder activés ?

Typiquement BaseOS et AppStream, plus UEK si vous l’exécutez, plus Ksplice si vous y avez droit et l’utilisez. Tout le reste doit être justifié par un besoin de paquet spécifique et revu périodiquement.

7) SELinux en enforcing est-il réaliste en production ?

Oui. La plupart des services standards fonctionnent correctement dès l’installation. Quand vous rencontrez des problèmes, corrigez les contextes ou écrivez une politique ciblée. Désactiver SELinux parce qu’un démon personnalisé s’est plaint est la façon la plus rapide d’obtenir des incidents « mystérieux » plus tard.

8) Quelle disposition de système de fichiers recommandez-vous pour un serveur polyvalent ?

UEFI + /boot séparé, LVM pour la flexibilité, /var séparé pour la croissance et le confinement des logs. Pour un logging intensif ou des bases de données, envisagez de séparer /var/log ou de placer les données sur des volumes dédiés.

9) Comment savoir si je dois m’inquiéter de Secure Boot ?

Si vous êtes en environnement réglementé ou que vous vous souciez de l’intégrité de la chaîne de démarrage, c’est un contrôle solide. Si vous exigez des modules noyau tiers, planifiez la signature des modules et l’enrôlement MOK d’abord, sinon Secure Boot deviendra une panne surprise.

Prochaines étapes à réaliser cette semaine

1. Choisissez votre standard de noyau (UEK ou RHCK) et consignez-le dans un endroit qui compte : pipeline de build + politique.
2. Ajoutez deux vérifications d’acceptation à chaque build d’hôte : uname -r correspond au standard, et grubby --default-kernel correspond à uname -r.
3. Décidez de Ksplice intentionnellement. Si vous l’utilisez, surveillez-le et prouvez qu’il patch. Si vous ne l’utilisez pas, retirez-le et cessez de faire semblant.
4. Rendez les mises à jour prévisibles : contraignez les dépôts, standardisez le rythme de patch, et utilisez needs-restarting pour éviter des redémarrages aléatoires.
5. Exécutez le playbook de diagnostic rapide sur un hôte sain et capturez le « normal ». Cette baseline rendra les anomalies futures évidentes.

Si vous ne faites rien d’autre : appliquez l’hygiène du démarrage du noyau et l’hygiène des dépôts. La plupart des problèmes de production « mystérieux » ne sont que des choix non documentés qui accumulent finalement des intérêts.