Linux, le noyau et les distributions

Pourquoi

Premier jour dans l'équipe qui exploite Signalements, l'API de signalement d'incidents de voirie que plusieurs communes utilisent. On vous donne un accès au serveur sig-app-1 avec une phrase : « c'est un Linux ». Une heure plus tard, trois questions arrivent, et la phrase ne suffit à répondre à aucune :

• Un bulletin de sécurité annonce une faille dans le noyau Linux, corrigée dans certaines versions. Le serveur est-il concerné ? Il faut connaître la version du noyau, mais aussi savoir qui fournit ce noyau et ses correctifs.
• Une documentation en ligne explique comment installer un outil « sous Linux » avec dnf. Sur le serveur, la commande n'existe pas. Pourquoi deux Linux n'ont-ils pas les mêmes commandes ?
• Le responsable demande s'il faut prévoir une migration l'an prochain. Jusqu'à quand cette version reçoit-elle des correctifs ?

Ces trois questions ont la même racine : « Linux » désigne, selon le contexte, un noyau, un système complet, ou une distribution maintenue par une organisation. Cette leçon démêle les trois, montre comment les identifier sur une machine en trois commandes, et explique pourquoi la date de fin de support d'une distribution est l'une des premières choses à regarder sur un serveur.

Les concepts

Le noyau et l'espace utilisateur

Un ordinateur exécute des programmes qui veulent tous la même chose : du temps de processeur, de la mémoire, l'accès aux disques et au réseau. Si chaque programme parlait directement au matériel, le premier programme défectueux pourrait écrire dans la mémoire des autres ou effacer le disque. Le noyau (kernel) est le programme qui s'interpose : il démarre en premier, garde seul l'accès direct au matériel, et partage les ressources entre les autres programmes en les isolant les uns des autres.

Le processeur lui-même fait respecter ce partage. Il fonctionne en deux modes au moins : un mode privilégié, où toutes les instructions sont permises, réservé au noyau, et un mode restreint, où s'exécutent tous les autres programmes. On parle donc de l'espace noyau et de l'espace utilisateur (user space). Le shell, ls, Python, PostgreSQL, gunicorn qui sert Signalements : tout cela vit en espace utilisateur, y compris quand le programme tourne sous le compte root. Être root donne beaucoup de droits auprès du noyau ; cela ne fait pas passer le programme en mode privilégié.

Le noyau Linux a quatre grandes responsabilités :

Les appels système

Puisqu'un programme ne peut pas toucher le matériel, comment lit-il un fichier ? Il le demande au noyau, par un appel système (system call, abrégé syscall). La page de manuel syscalls(2) le définit comme « l'interface fondamentale entre une application et le noyau Linux ». Ouvrir un fichier (openat), y lire (read), écrire à l'écran (write), créer un processus (clone), lancer un programme (execve) : chacune de ces opérations est un appel système. Linux en compte plus de quatre cents.

Les programmes n'appellent presque jamais ces fonctions directement. Ils passent par la bibliothèque C (sur Ubuntu et Debian, la glibc du projet GNU), qui fournit des fonctions d'emballage : elles placent les arguments là où le noyau les attend, déclenchent le passage en mode noyau, et traduisent le code de retour en valeur d'erreur exploitable. C'est pour cela que le choix de la bibliothèque C (glibc ou musl, voir plus bas) a des conséquences pratiques : un programme compilé contre l'une ne tourne pas forcément avec l'autre.

Retenez l'image : le noyau ne fait rien de lui-même pour l'utilisateur. Il ne connaît ni les commandes, ni les menus, ni les fichiers de configuration de vos applications. Il répond aux appels système que les programmes de l'espace utilisateur lui adressent. Tout ce que vous taperez dans ce cours finira, quelques couches plus bas, en appels système.

Linux, GNU, et la question du nom

Unix est né en 1969 aux laboratoires Bell d'AT&T. Il s'est répandu dans les universités et les entreprises sous des variantes concurrentes, la plupart sous licence propriétaire. En 1983, Richard Stallman annonce le projet GNU (« GNU's Not Unix »), qui démarre en 1984 avec un objectif : un système complet de type Unix, entièrement libre. Au début des années 1990, GNU a un compilateur (GCC), une bibliothèque C, un shell (Bash), les utilitaires de base (les coreutils : ls, cp, cat...), un éditeur (Emacs). Il lui manque le noyau.

En août 1991, Linus Torvalds, étudiant à Helsinki, annonce sur un forum Usenet qu'il écrit un noyau « juste pour le plaisir ». Le README du noyau le décrit toujours comme un clone d'Unix « écrit à partir de zéro par Linus Torvalds avec l'aide d'une équipe de hackers éparpillés sur le Net ». En 1992, Torvalds le place sous la licence publique générale GNU (GPL), dans sa version 2, qui est toujours la sienne : quiconque distribue le noyau, modifié ou non, doit en fournir le code source sous la même licence. Le noyau de Torvalds et les outils de GNU s'assemblent : on obtient un système libre complet.

D'où une querelle de vocabulaire qui dure encore. Le projet GNU défend le nom GNU/Linux, en faisant valoir que le système, pris dans son ensemble, est pour l'essentiel le système GNU auquel on a ajouté Linux. L'usage courant dit simplement « Linux ». Dans ce cours, « Linux » désigne le système d'exploitation complet quand il n'y a pas d'ambiguïté, et l'on dit « le noyau Linux » quand on parle du noyau. Ce qui compte n'est pas le nom, mais la distinction : le noyau et les outils viennent de projets différents, avec des versions différentes. La commande uname vous donne la version du noyau ; ls --version vous donne celle des coreutils de GNU ; ni l'une ni l'autre ne vous dit quelle distribution vous utilisez.

Une remarque qui servira : tout ce qui tourne sur Linux n'est pas GNU. Les images de conteneur Alpine utilisent BusyBox au lieu des coreutils et musl au lieu de la glibc ; Android utilise le noyau Linux sans presque rien de GNU.

Les distributions

Un noyau et quelques milliers de programmes libres, chacun avec son propre site, ses versions, ses dépendances : personne ne veut assembler cela à la main sur chaque serveur. Une distribution est le travail qui transforme ce matériau en un système installable et maintenu. Elle :

1. choisit des versions précises du noyau, de la bibliothèque C, des outils et de milliers de logiciels, qui fonctionnent ensemble ;
2. les compile et les empaquette dans un format de paquet (.deb chez Debian et Ubuntu, .rpm chez Red Hat), avec un gestionnaire de paquets qui gère les dépendances (apt, dnf, apk, leçon 12) ;
3. fournit un installeur, des réglages par défaut, une documentation ;
4. surtout, maintient ces paquets pendant une durée annoncée : elle suit les failles de sécurité, rétroporte les correctifs dans les versions qu'elle a figées, et publie des mises à jour.

Ce quatrième point est la vraie valeur d'une distribution pour un serveur. Quand une faille est publiée dans OpenSSL, vous ne recompilez pas OpenSSL : vous installez la mise à jour que votre distribution a préparée, testée et signée. C'est aussi pour cela que le numéro de version d'un paquet de distribution peut sembler « ancien » tout en étant corrigé : la distribution a appliqué le correctif à la version qu'elle avait figée, plutôt que de passer à une version plus récente qui pourrait changer de comportement.

Les familles que vous rencontrerez :

Le passage d'une famille à l'autre change surtout trois choses : le gestionnaire de paquets (la commande dnf absente de sig-app-1, qui est une Ubuntu), quelques emplacements de fichiers de configuration, et les noms de paquets. Le noyau, le shell, les commandes de base et la logique d'ensemble restent les mêmes. Ce cours vise Ubuntu et Debian ; ce que vous y apprenez vaut aux trois quarts pour une Rocky Linux.

Alpine mérite une mention à part parce que vous la croiserez dans les images de conteneur : elle utilise la bibliothèque C musl au lieu de la glibc. La plupart des programmes fonctionnent, mais un binaire compilé pour la glibc échoue souvent sur Alpine avec un message déroutant (« not found » pour un fichier qui existe). Le glossaire détaille cette différence à l'entrée glibc et musl, et le cours Construire des images de conteneurs en tire les conséquences.

Cycles de vie et versions LTS

Chaque version d'une distribution a une date de fin de support. Après elle, plus aucun correctif de sécurité n'est publié : le système continue de fonctionner, mais chaque faille découverte ensuite reste ouverte pour toujours. Sur un serveur exposé à Internet, c'est une question de mois avant qu'une faille exploitable apparaisse.

Les distributions destinées aux serveurs proposent donc des versions à support long (Long Term Support, LTS) : figées pour plusieurs années, elles ne reçoivent que des correctifs de sécurité et de bogues. Voici les cycles des versions courantes, vérifiés sur les pages officielles en octobre 2026 :

Quelques lectures de ce tableau :

• Ubuntu publie une version tous les six mois, mais seules celles d'avril des années paires sont LTS. Une version intermédiaire (24.10, 25.04...) n'a que neuf mois de mises à jour : elle n'a pas sa place sur un serveur. Une LTS a cinq ans de maintenance standard, que l'abonnement Ubuntu Pro prolonge par l'Expanded Security Maintenance (ESM). L'ESM couvre aussi les paquets du dépôt universe, maintenu par la communauté, qui ne reçoit sinon que des correctifs au mieux. Ubuntu Pro est gratuit pour un usage personnel sur quelques machines, payant au-delà.
• Debian publie une version stable environ tous les deux ans, maintenue trois ans par son équipe de sécurité, puis deux ans de plus par l'équipe Debian LTS, sur un périmètre de paquets et d'architectures plus restreint.
• RHEL annonce un cycle de dix ans par version majeure. Les dates futures sont, dit Red Hat, des approximations.

Les versions d'Ubuntu ont aussi des versions ponctuelles (point releases) : 24.04.1, 24.04.2... jusqu'à 24.04.5. Ce ne sont pas de nouvelles versions, mais des images d'installation regroupant les mises à jour publiées depuis. Une machine installée en 24.04.0 et tenue à jour est, au paquet près, une 24.04.5.

Le noyau d'une distribution

La distribution choisit et maintient aussi son noyau. Ubuntu en propose deux lignées pour une même LTS : le noyau GA (General Availability), celui de la sortie (6.8 pour la 24.04), maintenu toute la vie de la version, et la pile HWE (Hardware Enablement), qui apporte un noyau plus récent à chaque version ponctuelle (6.17 avec la 24.04.4, 7.0 avec la 24.04.5) pour prendre en charge le matériel récent. Les installations de bureau suivent HWE par défaut ; les serveurs restent sur le noyau GA sauf choix contraire. Deux machines « en 24.04 » peuvent donc avoir des noyaux de versions très différentes, toutes deux maintenues.

Où l'on rencontre Linux

Linux fait tourner la très grande majorité des serveurs, des instances de cloud, des téléphones Android, des routeurs, et l'ensemble des 500 supercalculateurs les plus puissants du monde depuis 2017. Pour une équipe comme celle de Signalements, trois contextes comptent :

• le serveur ou la machine virtuelle : une distribution complète, son noyau, ses services. C'est le cas de sig-app-1 ;
• l'instance de cloud, qui est une machine virtuelle dont l'image a été préparée par la distribution et le fournisseur (cours Le cloud : les fondamentaux) ;
• le conteneur, qui n'a pas de noyau à lui. Un conteneur Debian qui tourne sur une machine Ubuntu contient l'espace utilisateur de Debian (ses bibliothèques, ses commandes, son gestionnaire de paquets) et utilise le noyau de la machine hôte. C'est le point de départ du cours Docker : les fondamentaux : un conteneur se distingue d'une machine virtuelle précisément par ce noyau partagé.

En pratique

Connectez-vous à votre machine d'entraînement (le cours suppose sig-app-1, une Ubuntu 24.04) et ouvrez un terminal. La leçon 2 détaille ce qu'est ce terminal ; pour l'instant, tapez les commandes et validez avec Entrée. Les sorties ci-dessous ont été produites sur une Ubuntu 24.04.5 ; le nom de la machine a été remplacé par sig-app-1, et la langue forcée en anglais (LC_ALL=C.UTF-8) pour correspondre à ce que vous verrez sur la plupart des serveurs.

Quelle distribution ?

Le fichier /etc/os-release est la source normalisée de cette information. Il est défini par la page os-release(5) et présent sur toutes les distributions qui utilisent systemd, et sur la plupart des autres :

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.5 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.5 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo

cat affiche le contenu d'un fichier (leçon 5). Les champs à connaître :

• ID : l'identifiant de la distribution, en minuscules (ubuntu, debian, rocky, alpine). C'est lui qu'un script doit tester.
• ID_LIKE : la ou les familles dont elle dérive. Ubuntu déclare debian ; Rocky Linux déclare rhel centos fedora. Un script qui sait traiter Debian sait souvent traiter tout ce qui déclare ID_LIKE=debian.
• VERSION_ID : la version, sous une forme courte destinée aux programmes (24.04), et VERSION_CODENAME, le nom de code (noble) qui apparaît dans les adresses des dépôts de paquets (leçon 12).
• PRETTY_NAME : le libellé destiné aux humains, avec la version ponctuelle.

Le format est fait d'affectations de variables compatibles avec le shell, sans aucune autre fonction du shell : la page de manuel précise qu'un script peut le « sourcer », mais que les lecteurs n'ont pas à implémenter de shell pour le lire. Un script pourra donc écrire :

$ . /etc/os-release && echo "$ID $VERSION_ID"
ubuntu 24.04

Le point (.) lit le fichier dans le shell courant, qui définit ainsi les variables ID, VERSION_ID... ; && n'exécute la commande suivante que si la première a réussi (leçon 6) ; echo affiche ses arguments.

Remarquez enfin que /etc/os-release est un lien symbolique :

$ ls -l /etc/os-release
lrwxrwxrwx 1 root root 21 Sep  6 16:29 /etc/os-release -> ../usr/lib/os-release

Le vrai fichier est dans /usr/lib, qui appartient à la distribution, et /etc n'en garde qu'un renvoi, pour les programmes qui ne regardent que là. La leçon 3 explique la répartition des rôles entre /usr et /etc, et la leçon 4 ce qu'est un lien symbolique.

Deux autres commandes donnent la même information. lsb_release -a vient d'une ancienne norme (la Linux Standard Base) et n'est pas installée partout, notamment pas dans les images de conteneur ; hostnamectl l'affiche avec d'autres informations sur les machines qui utilisent systemd :

$ lsb_release -a
Distributor ID:	Ubuntu
Description:	Ubuntu 24.04.5 LTS
Release:	24.04
Codename:	noble

Préférez /etc/os-release dans un script : c'est un simple fichier, présent même dans les conteneurs les plus dépouillés.

Quel noyau ?

uname (pour Unix name) interroge le noyau sur lui-même :

$ uname -r
7.0.0-34-generic
$ uname -m
x86_64
$ uname -a
Linux sig-app-1 7.0.0-34-generic #34~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Sep  4 15:38:29 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

• -r (release) donne la version du noyau. 7.0.0 est la version du projet Linux ; -34 est la révision du paquet de noyau par Ubuntu, qui augmente à chaque mise à jour de sécurité ; generic est la variante (il existe des variantes pour les machines virtuelles, le temps réel, certains fournisseurs de cloud). La machine de test suit la pile HWE de la 24.04.5, d'où un noyau 7.0 ; un serveur installé sur le noyau GA afficherait une version en 6.8.0-.
• -m (machine) donne l'architecture matérielle : x86_64 pour les processeurs Intel et AMD 64 bits, aarch64 pour ARM 64 bits (instances Ampere chez les fournisseurs de cloud, Raspberry Pi 4 et 5).
• -a (all) affiche tout : le nom du système (Linux), le nom de la machine, la version, la date de construction du noyau (#34~24.04.1-Ubuntu ... Fri Sep 4), l'architecture, et le système d'exploitation (GNU/Linux : uname vient des coreutils de GNU, qui ont choisi ce libellé).

Le fichier /proc/version donne une information voisine, avec le compilateur qui a servi à construire le noyau :

$ cat /proc/version
Linux version 7.0.0-34-generic (buildd@lcy02-amd64-117) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #34~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Sep  4 15:38:29 UTC 2

Ce fichier n'existe sur aucun disque. /proc est un système de fichiers virtuel : quand vous lisez /proc/version, le noyau fabrique le contenu à la volée. C'est un premier exemple d'une idée qui reviendra souvent, « tout est fichier » (leçon 3).

Le noyau d'un conteneur

Si Docker est installé sur votre machine d'entraînement, comparez :

$ docker run --rm debian:13 sh -c 'grep PRETTY /etc/os-release; uname -r'

La première ligne annonce Debian 13 : c'est l'espace utilisateur du conteneur. La seconde affiche la même version de noyau que uname -r sur la machine hôte : le conteneur n'a pas de noyau propre. Un bulletin de sécurité sur le noyau concerne donc l'hôte, quelle que soit la distribution des conteneurs qui y tournent.

Voir les appels système

strace (installé par défaut sur Ubuntu, sinon sudo apt install strace) lance un programme et affiche chaque appel système qu'il fait. Créez un petit fichier et faites-le afficher par cat, en résumant les appels :

$ echo "bonjour" > note.txt
$ strace -c cat note.txt
bonjour
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 29.86    0.000229           7        31        12 openat
 21.12    0.000162           7        23           mmap
 12.91    0.000099           4        21           close
 12.26    0.000094           4        20           fstat
  5.87    0.000045           9         5           read
...
  1.56    0.000012          12         1           write
...
  0.00    0.000000           0         1           execve
------ ----------- ----------- --------- --------- ----------------
100.00    0.000767           6       121        13 total

L'option -c (count) compte les appels au lieu de les afficher un par un. Pour afficher le mot bonjour, cat a fait 121 appels système. L'essentiel n'est pas de lire le fichier : c'est de démarrer. execve charge le programme, puis openat et mmap chargent la bibliothèque C et les fichiers de langue (d'où les 12 « erreurs » : des fichiers cherchés à plusieurs endroits et absents de certains). Regardez maintenant les seuls appels qui touchent au fichier et à l'écran :

$ strace -e trace=openat,read,write,close cat note.txt 2>&1 | tail -8
read(3, "bonjour\n", 131072)            = 8
write(1, "bonjour\n", 8bonjour
)                = 8
read(3, "", 131072)                     = 0
close(3)                                = 0
close(1)                                = 0
close(2)                                = 0
+++ exited with 0 +++

-e trace= restreint l'affichage à certains appels ; 2>&1 | tail -8 garde les huit dernières lignes (strace écrit sur la sortie d'erreur, leçon 6 ; vous comprendrez cette syntaxe à ce moment-là). Plus haut dans la sortie complète, une ligne openat(AT_FDCWD, "note.txt", O_RDONLY) = 3 montre l'ouverture du fichier : le noyau a répondu par le numéro 3, un descripteur de fichier. Puis cat lit sur le descripteur 3 (read(3, ...) renvoie les 8 octets de bonjour\n), écrit sur le descripteur 1, la sortie standard, c'est-à-dire votre terminal (write(1, ...), dont la sortie se mêle à l'affichage de strace), relit et obtient 0 octet, ce qui signifie « fin du fichier », puis ferme tout. exited with 0 : le programme s'est terminé avec le code 0, qui signifie le succès (leçon 6).

Vous venez de voir la frontière entre l'espace utilisateur et le noyau. cat ne sait pas où est le disque, ni comment il est organisé : il demande au noyau d'ouvrir un nom, de lire, d'écrire, de fermer.

Sous le capot

Le démarrage. À la mise sous tension, le micrologiciel de la machine (UEFI, ou l'hyperviseur pour une machine virtuelle) charge un chargeur d'amorçage (GRUB sur Ubuntu), qui charge le noyau depuis /boot avec un système de fichiers initial en mémoire. Le noyau détecte le matériel, monte le système de fichiers racine, puis lance un seul programme de l'espace utilisateur, avec le numéro de processus 1. Sur Ubuntu, Debian et RHEL, ce programme est systemd, qui démarre ensuite tous les services (leçon 11). Tous les autres processus de la machine descendent de lui. Dans un conteneur, il n'y a pas de démarrage du noyau : le processus 1 est directement l'application (voir l'entrée PID 1 du glossaire).

Ce que contient une version de noyau. Le projet Linux publie une nouvelle version environ toutes les neuf à dix semaines, et désigne chaque année une version maintenue à long terme. Les distributions ne suivent pas ce rythme : elles figent une version et y rétroportent les correctifs. C'est pourquoi un noyau 6.8.0-xx d'Ubuntu, publié en 2026, contient des correctifs de sécurité découverts bien après la sortie de Linux 6.8. Pour savoir si une faille est corrigée sur votre serveur, ne comparez pas les numéros du projet Linux : consultez l'avis de sécurité de votre distribution (Ubuntu Security Notices, Debian Security Advisories), qui indique la révision corrigée du paquet.

Pourquoi « GNU/Linux » dans uname -a. Le dernier champ, le système d'exploitation, n'est pas fourni par le noyau : c'est une valeur fixée à la compilation des coreutils. Le noyau, interrogé par l'appel système uname, ne renvoie que son nom (Linux), le nom de la machine, sa version, sa date de construction et l'architecture.

Pièges courants

Confondre la version du noyau et celle de la distribution. « On est en 7.0 » ne dit rien de la distribution, et « on est en 24.04 » ne dit pas quel noyau tourne. Les deux se lisent séparément : /etc/os-release et uname -r.

Croire que le noyau installé est le noyau qui tourne. Une mise à jour du noyau installe un nouveau paquet, mais la machine continue d'exécuter l'ancien noyau jusqu'au redémarrage. Après une mise à jour de sécurité du noyau, uname -r affiche encore l'ancienne version, et la faille reste ouverte. Sur Ubuntu, le fichier /var/run/reboot-required apparaît quand un redémarrage est nécessaire (leçon 12).

Suivre une documentation écrite pour une autre famille. Une procédure qui commence par dnf install ou yum install vient du monde Red Hat. Les noms de paquets diffèrent souvent (httpd chez Red Hat, apache2 chez Debian), comme les emplacements de configuration. Vérifiez ID et ID_LIKE avant de copier.

Installer une version intermédiaire d'Ubuntu sur un serveur. Une 25.10 est séduisante parce qu'elle est plus récente ; elle sera sans correctifs neuf mois plus tard. Sur un serveur : LTS uniquement.

Lancer un binaire glibc sur Alpine. Le message sh: ./programme: not found pour un fichier qui existe bel et bien vient le plus souvent de là : le chargeur de la glibc indiqué dans le binaire n'existe pas sous musl.

Sécurité

La fin de support est une faille programmée. Le jour où une version sort du support, toutes les failles découvertes ensuite restent ouvertes sur toutes les machines qui l'utilisent. Les attaquants le savent, et les outils d'analyse de vulnérabilités le signalent. Inscrivez la date de fin de support de chaque serveur dans votre inventaire, et planifiez la migration un an avant, pas un mois.

Ubuntu Pro et Debian LTS sont des prolongations, pas des solutions. Ils donnent du temps pour migrer. Notez deux limites : l'ESM d'Ubuntu demande un abonnement et l'enregistrement de la machine (pro attach), et Debian LTS ne couvre qu'une partie des paquets et des architectures.

Le dépôt d'origine compte. Les mises à jour de sécurité de main sont garanties par Canonical pendant cinq ans ; celles de universe (des dizaines de milliers de paquets maintenus par la communauté) ne le sont qu'avec Ubuntu Pro. Un serveur qui dépend d'un paquet de universe (par exemple certains outils de supervision) n'a pas les mêmes garanties que le reste du système.

Le noyau est partagé par les conteneurs. Une faille du noyau qui permet d'élever ses privilèges concerne tous les conteneurs d'un hôte, quelle que soit leur image. Mettre à jour les images ne suffit pas : il faut mettre à jour, et redémarrer, les hôtes.

En production

• Un inventaire avec trois colonnes : distribution et version, noyau en cours d'exécution, date de fin de support. Les outils de gestion de configuration (cours Ansible : les fondamentaux) collectent ces informations automatiquement, à partir des mêmes sources que cette leçon.
• Homogénéiser. Une équipe qui exploite à la fois des Debian 11, des Ubuntu 20.04, 22.04 et 24.04 et deux CentOS oubliées entretient cinq jeux de réflexes et de correctifs. Choisir une distribution et une version de référence, et migrer par lots, réduit le coût d'exploitation et le risque.
• Le choix de la distribution d'un serveur se fait sur des critères d'exploitation, pas de goût : durée du support, rythme des versions, disponibilité des images chez votre fournisseur de cloud, compétences de l'équipe, exigences des éditeurs de logiciels (certains ne supportent que RHEL), contrats de support si le client en exige un. Chez les clients de Lyneko, Ubuntu LTS et Debian dominent, avec quelques RHEL imposées par un éditeur.
• Les montées de version majeures se répètent. Passer de 22.04 à 24.04 sur place (do-release-upgrade) fonctionne, mais un serveur que l'on sait recréer depuis une description (image et configuration, cours Le cloud : les fondamentaux) se migre en créant un nouveau serveur sur la nouvelle version, sans risque pour l'ancien.

Exercices

1. Identifier une machine (niveau 100). Sur votre machine d'entraînement, et si possible sur une seconde (un conteneur debian:13 ou rockylinux:9 si Docker est disponible), relevez : l'ID, l'ID_LIKE, la version, le nom de code, la version du noyau et l'architecture. Pour chaque machine, dites quel gestionnaire de paquets vous vous attendez à trouver.

2. Lire un tableau de cycle de vie (niveau 100). Un client possède, en octobre 2026, cinq serveurs : deux Ubuntu 20.04 sans abonnement, un Ubuntu 22.04, un Debian 12 et un Debian 13. Classez-les du plus urgent au moins urgent à migrer, en justifiant avec les dates officielles (consultez les pages citées en sources pour les versions que la leçon ne détaille pas).

3. Compter des appels système (niveau 100). Avec strace -c, comparez le nombre d'appels système de cat note.txt et de ls. Puis lancez strace -e trace=openat ls 2>&1 | head : quels fichiers ls ouvre-t-il avant même de lire le répertoire ? Pourquoi un programme aussi simple fait-il autant d'appels ?

4. Préparer un choix (niveau 100). Une collectivité demande à Lyneko d'héberger une application pour au moins six ans sur des serveurs Linux, avec un contrat de support éditeur si possible. Comparez en cinq lignes Ubuntu 24.04 LTS, Ubuntu 26.04 LTS, Debian 13 et RHEL 10 au regard de cette durée.

Récapitulatif

• Le noyau partage le matériel entre les programmes et les isole ; tout le reste vit en espace utilisateur, y compris ce qui tourne sous root.
• Les programmes demandent tout au noyau par des appels système, en général à travers la bibliothèque C (glibc, ou musl sur Alpine). strace les montre.
• « Linux » désigne selon le contexte le noyau ou le système complet ; le projet GNU défend « GNU/Linux ». Noyau et outils ont des versions indépendantes.
• Une distribution choisit, empaquette et surtout maintient les logiciels ; ses familles (Debian et Ubuntu, Red Hat et ses dérivées, Alpine) diffèrent surtout par les paquets et quelques emplacements.
• Sur un serveur : une version LTS, et une date de fin de support suivie de près. Ubuntu 24.04 : mai 2029, 2034 avec Ubuntu Pro ; Debian 13 : août 2028, juin 2030 avec LTS.
• /etc/os-release (champs ID, ID_LIKE, VERSION_ID, VERSION_CODENAME) identifie la distribution ; uname -r et /proc/version identifient le noyau en cours d'exécution.
• Un conteneur n'a pas de noyau : il utilise celui de l'hôte.

Pour aller plus loin

• La page de manuel syscalls(2), pour parcourir la liste des appels système, et strace(1) pour les options de filtrage.
• Le texte Linux and the GNU System de Richard Stallman, pour l'argument du projet GNU sur le nom, à lire avec le README du noyau.
• Les pages de cycle de vie d'Ubuntu, de Debian et de Red Hat citées en sources : ce sont elles, et non un article de blog, qui font foi.
• The Linux Command Line de William Shotts, disponible librement en ligne, pour une seconde présentation progressive du système.
• La leçon suivante, qui ouvre le terminal et explique ce qui se passe entre le moment où vous tapez une commande et celui où le noyau l'exécute.