Les paquets et les mises à jour

Pourquoi

Mardi matin, l'équipe sécurité de Lyneko fait circuler une alerte : une faille critique a été publiée dans OpenSSH, le serveur SSH présent sur tous les serveurs. Questions immédiates pour sig-app-1 : quelle version est installée ? Le correctif est-il déjà disponible pour Ubuntu 24.04 ? A-t-il déjà été appliqué automatiquement cette nuit ? Faut-il redémarrer quelque chose pour qu'il prenne effet ?

Sur une distribution Linux, presque tout ce qui est installé, du noyau à la bibliothèque TLS en passant par Python, vient de paquets, fournis par la distribution et mis à jour par elle. Savoir les manipuler, c'est savoir répondre à ces questions en une minute. Ne pas le savoir conduit aux deux erreurs classiques : laisser un serveur sans mises à jour pendant des mois, parce qu'on a peur de le casser ; ou installer n'importe quoi depuis n'importe où, en copiant une commande curl ... | sudo bash trouvée sur un forum, et confier ainsi les clés du serveur à un inconnu.

Les concepts

Ce qu'est un paquet

Un paquet est une archive qui contient un logiciel prêt à installer, plus des métadonnées : son nom, sa version, une description, l'architecture visée (amd64, arm64), la liste des autres paquets dont il a besoin (ses dépendances), ceux avec lesquels il est incompatible, et des scripts à exécuter avant et après l'installation ou la suppression (créer un utilisateur système, activer un service). Sur Debian et Ubuntu, le format est le .deb ; sur Red Hat, Fedora et leurs dérivés, le .rpm ; sur Alpine, le .apk.

Le paquet apporte trois garanties qu'une installation à la main n'a pas : on sait quels fichiers il a déposés (et donc les retirer), on sait d'où il vient (un dépôt signé), et il sera mis à jour avec le reste du système.

Le numéro de version Debian

Une version de paquet Debian suit la forme [époque:]version_amont[-révision], décrite dans deb-version(7) :

• l'époque (facultative, 1: par exemple) sert à corriger une numérotation qui a mal tourné : une époque plus grande l'emporte toujours ;
• la version amont est celle du logiciel d'origine ;
• la révision compte les versions du paquet lui-même pour une même version amont. Ubuntu y ajoute ses propres suffixes.

Ainsi, 1:9.6p1-3ubuntu13.19 se lit : époque 1, OpenSSH 9.6p1, troisième révision Debian, treizième révision Ubuntu, dix-neuvième mise à jour publiée pour Ubuntu 24.04. Point capital : les distributions stables ne changent pas de version amont pour corriger une faille. Elles reportent le correctif (backport) dans la version qu'elles ont figée, et incrémentent la révision. Un scanner de vulnérabilités qui ne lit que « OpenSSH 9.6p1 » et conclut que la faille est présente se trompe souvent : c'est la révision qu'il faut comparer à l'avis de sécurité de la distribution.

dpkg et APT

Deux étages d'outils, à ne pas confondre :

• dpkg est le bas niveau : il installe un fichier .deb qu'on lui donne, en dépose les fichiers, exécute ses scripts, et tient la base des paquets installés (/var/lib/dpkg/status). Il vérifie les dépendances mais ne sait pas les résoudre : si une dépendance manque, il s'arrête.
• APT (Advanced Package Tool) est le haut niveau : il connaît les dépôts, télécharge les listes de paquets disponibles, calcule l'ensemble des paquets à installer ou à mettre à jour pour satisfaire toutes les dépendances, vérifie les signatures, télécharge, puis appelle dpkg. La commande apt est l'interface pour les humains ; apt-get et apt-cache, plus anciennes, ont une sortie stable et conviennent mieux aux scripts.

Un gestionnaire de paquets désigne l'ensemble : APT et dpkg sur Debian et Ubuntu, DNF et RPM sur Red Hat, apk sur Alpine.

Les dépôts

Un dépôt (repository) est un serveur web qui publie des paquets et un index signé de ce qu'il contient. Sur Ubuntu 24.04, la liste des dépôts est dans /etc/apt/sources.list.d/ubuntu.sources, au format dit deb822 (des blocs de champs Nom: valeur, comme les fichiers de contrôle des paquets), qui remplace l'ancien /etc/apt/sources.list d'une ligne par source. Sur la machine de test :

Types: deb
URIs: http://fr.archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://security.ubuntu.com/ubuntu/
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Trois notions s'y croisent :

• La version de la distribution, par son nom de code : noble pour Ubuntu 24.04, trixie pour Debian 13.
• Les poches (pockets), suffixes du nom de code : noble (les paquets tels qu'à la sortie, figés), noble-security (les correctifs de sécurité), noble-updates (les corrections qui ne relèvent pas de la sécurité ; les correctifs de sécurité y sont aussi recopiés, comme le montre apt-cache policy plus bas), noble-backports (des versions plus récentes de certains logiciels, rarement utiles sur un serveur), et noble-proposed (les mises à jour en test, à ne jamais activer en production). Debian a l'équivalent : trixie, trixie-security, trixie-updates, trixie-backports.
• Les composants : main (logiciels libres maintenus par Canonical, correctifs de sécurité garantis pendant la durée de support), restricted (pilotes propriétaires nécessaires au matériel), universe (logiciels libres maintenus par la communauté, sans garantie de correctifs de sécurité de la part de Canonical), multiverse (logiciels non libres, sans support). Debian découpe en main, contrib, non-free et non-free-firmware.

La distinction entre main et universe a des conséquences concrètes : un paquet de universe peut rester des mois avec une faille connue. Ubuntu Pro, gratuit pour un usage personnel jusqu'à cinq machines et payant au-delà, étend les correctifs à universe (offre ESM Apps) et prolonge le support de chaque version LTS jusqu'à dix ans (ESM Infra). La configuration par défaut des mises à jour automatiques, plus bas, mentionne d'ailleurs ces origines ESM.

Les signatures

Comment APT sait-il qu'un paquet vient bien d'Ubuntu, et pas d'un miroir compromis ou d'un attaquant placé sur le réseau ? Par une chaîne de signatures :

    flowchart LR
  K["Clé publique<br/>ubuntu-archive-keyring.gpg"] -->|"vérifie la signature de"| R["InRelease<br/>(index du dépôt)"]
  R -->|"contient l'empreinte SHA-256 de"| P["Packages<br/>(liste des paquets)"]
  P -->|"contient l'empreinte SHA-256 de"| D[".deb téléchargé"]
  

Le fichier InRelease de chaque poche est signé par la clé de l'archive ; il contient les empreintes des listes de paquets, qui contiennent elles-mêmes les empreintes de chaque .deb. APT vérifie chaque maillon. Le transport peut donc rester en HTTP sans compromettre l'intégrité : un fichier modifié en route ne correspond plus à son empreinte signée. (Il compromet en revanche la confidentialité de la liste de ce que vous installez, d'où l'usage croissant de miroirs HTTPS.)

Le champ Signed-By: indique quelle clé a le droit de signer ce dépôt. C'est le point le plus important pour les dépôts tiers.

Mises à jour de sécurité automatiques

Sur Ubuntu Server, la documentation officielle l'indique : les mises à jour de sécurité s'appliquent automatiquement, par le paquet unattended-upgrades, installé par défaut. Deux minuteurs systemd (leçon 11) s'en chargent : apt-daily.timer télécharge les listes et les paquets, apt-daily-upgrade.timer installe, avec un délai aléatoire pour ne pas faire tomber tous les serveurs du monde sur les miroirs à la même minute. Par défaut, seules les origines de sécurité (et la poche de sortie, qui ne change plus) sont autorisées : noble-updates n'est pas installé automatiquement.

Une mise à jour installée n'est pas toujours en service. Un processus qui a chargé une bibliothèque avant sa mise à jour continue d'utiliser l'ancienne version, en mémoire, jusqu'à son redémarrage. Deux mécanismes s'en occupent sur Ubuntu Server 24.04 :

• needrestart, exécuté à la fin de chaque opération APT, détecte les services qui utilisent une bibliothèque remplacée. Depuis Ubuntu 24.04, d'après l'annonce de l'équipe Ubuntu, il redémarre directement ces services, en mode interactif comme non interactif, y compris après unattended-upgrades. Signalements, s'il utilisait une bibliothèque Python système mise à jour, serait donc redémarré automatiquement.
• Le noyau ne se remplace pas à chaud : un nouveau noyau installé ne sert qu'au prochain démarrage. Le fichier /var/run/reboot-required signale qu'un redémarrage est nécessaire, et /var/run/reboot-required.pkgs dit à cause de quels paquets. Par défaut, unattended-upgrades ne redémarre pas la machine (Automatic-Reboot vaut false).

snap

Ubuntu propose un second système de paquets, snap : des applications empaquetées avec leurs dépendances, isolées, mises à jour automatiquement par le démon snapd depuis le magasin de Canonical. Sur un serveur, on le rencontre quand l'installateur d'Ubuntu Server propose des logiciels à cocher, ou quand une documentation d'éditeur le recommande. Les différences importantes pour l'exploitation : les snaps se mettent à jour d'eux-mêmes, selon leur propre calendrier (réglable par snap refresh --hold et les fenêtres de rafraîchissement), ne passent pas par les dépôts APT signés de la distribution, et ne figurent pas dans dpkg -l. Sur un serveur de production, on préfère en général les paquets de la distribution ou des conteneurs ; si un snap est utilisé, il faut le savoir et le surveiller (snap list, snap changes).

Les autres familles

Les concepts sont les mêmes partout ; seuls les noms changent. Alpine est surtout rencontrée comme image de base de conteneurs (voir glibc et musl).

En pratique

Les sorties de cette section ont été produites sur une machine Ubuntu 24.04 avec LC_ALL=C.UTF-8. Les commandes qui modifient le système (sudo) concernent sig-app-1 et sont décrites sans sortie ; pour voir ce qu'elles feraient, APT sait simuler avec -s, sans privilège.

Interroger : que sais-je d'un paquet ?

D'où vient le programme cron ?

$ dpkg -S /usr/sbin/cron
cron: /usr/sbin/cron
$ dpkg -l cron
...
+++-==============-=================-============-=================================
ii  cron           3.0pl1-184ubuntu2 amd64        process scheduling daemon
$ dpkg -L cron | grep -E "bin|service"
/usr/bin
/usr/bin/crontab
/usr/lib/systemd/system/cron.service
/usr/sbin
/usr/sbin/cron

dpkg -S cherche quel paquet installé possède un fichier ; dpkg -l affiche son état (les deux lettres ii : souhaité « installé », état réel « installé » ; rc signalerait un paquet supprimé dont la configuration reste) ; dpkg -L liste ses fichiers, y compris son unité systemd.

Et pour un paquet que l'on n'a pas encore ? apt show décrit un paquet du dépôt :

$ apt show cron
Package: cron
Version: 3.0pl1-184ubuntu2
Priority: standard
Section: admin
Origin: Ubuntu
...
Depends: libc6 (>= 2.34), libpam0g (>= 0.99.7.1), libselinux1 (>= 3.1~), sensible-utils, libpam-runtime
Suggests: anacron, logrotate, checksecurity, supercat, default-mta | mail-transport-agent
Conflicts: bcron, cronie, systemd-cron

Les dépendances (Depends) sont obligatoires ; les suggestions (Suggests) ne sont jamais installées automatiquement, les recommandations (Recommends) le sont par défaut. apt search mot cherche dans les noms et descriptions.

Quelle version, depuis quel dépôt ?

C'est la commande qui répond à l'alerte OpenSSH :

$ apt-cache policy openssh-server
openssh-server:
  Installed: (none)
  Candidate: 1:9.6p1-3ubuntu13.19
  Version table:
     1:9.6p1-3ubuntu13.19 500
        500 http://fr.archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages
     1:9.6p1-3ubuntu13 500
        500 http://fr.archive.ubuntu.com/ubuntu noble/main amd64 Packages

Sur la machine de test, le serveur SSH n'est pas installé (Installed: (none)) ; sur sig-app-1, cette ligne donnerait la version en place. Candidate est la version qu'APT installerait. La table liste chaque version connue et les dépôts qui la proposent : la version 13 est celle de la sortie d'Ubuntu 24.04 (poche noble), la version 13.19 est arrivée depuis par noble-security, et figure aussi dans noble-updates. Le nombre 500 est la priorité d'APT pour ce dépôt (500 par défaut, 100 pour la version installée) ; elle intervient quand plusieurs dépôts proposent le même paquet.

Pour savoir si l'avis de sécurité est corrigé, comparez la version installée à celle qu'indique l'avis Ubuntu (USN) pour 24.04. Le journal des modifications du paquet en dit plus : apt changelog openssh-server télécharge et affiche les entrées, avec les identifiants CVE corrigés.

Mettre à jour

$ sudo apt update
$ apt list --upgradable
$ sudo apt upgrade

• apt update ne met rien à jour : il télécharge les index des dépôts, et vérifie leurs signatures. C'est la commande qui échoue bruyamment si une clé manque ou a expiré.
• apt list --upgradable affiche ce qui pourrait l'être.
• apt upgrade installe les nouvelles versions des paquets installés. D'après apt(8), il peut installer de nouveaux paquets si une dépendance l'exige, mais ne supprime jamais de paquet : une mise à jour qui exigerait une suppression est mise de côté (« kept back »).
• apt full-upgrade fait la même chose, en acceptant de supprimer des paquets si nécessaire. Relisez sa liste avant de confirmer.

Avant une mise à jour sur un serveur, simulez :

$ apt-get -s install tree
...
The following NEW packages will be installed:
  tree
0 upgraded, 1 newly installed, 0 to remove and 10 not upgraded.
Inst tree (2.1.1-2ubuntu3.24.04.2 Ubuntu:24.04/noble-updates [amd64])
Conf tree (2.1.1-2ubuntu3.24.04.2 Ubuntu:24.04/noble-updates [amd64])

Les lignes Inst et Conf décrivent ce qui serait installé et configuré, sans rien toucher. Le résumé (0 to remove) est la ligne à lire en premier : une suppression inattendue est un signal d'arrêt.

Installer, retirer, nettoyer

$ sudo apt install htop
$ sudo apt remove htop          # retire le programme, garde sa configuration dans /etc
$ sudo apt purge htop           # retire aussi la configuration
$ sudo apt autoremove           # retire les dépendances devenues inutiles

APT retient quels paquets vous avez demandés explicitement et lesquels sont venus en dépendance. autoremove retire les seconds quand plus rien ne les demande. La page apt(8) conseille de relire sa liste : un outil que vous utilisez peut y figurer parce qu'il était arrivé comme dépendance ; sudo apt-mark manual <paquet> le protège.

Retenir une version

Pour empêcher la mise à jour d'un paquet (un PostgreSQL que l'on veut migrer à une date choisie, par exemple) :

$ sudo apt-mark hold postgresql-16
$ apt-mark showhold
$ sudo apt-mark unhold postgresql-16

Un paquet retenu ne reçoit plus aucune mise à jour, sécurité comprise. Notez chaque hold dans la documentation de l'équipe, avec sa raison et sa date de fin.

Ajouter un dépôt tiers proprement

Certains logiciels ne sont pas dans la distribution, ou pas dans la version voulue : Docker Engine, PostgreSQL de la communauté (dépôt PGDG), Grafana... La procédure officielle de Docker pour Ubuntu illustre la bonne méthode :

$ sudo install -m 0755 -d /etc/apt/keyrings
$ sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
$ sudo chmod a+r /etc/apt/keyrings/docker.asc
$ sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
$ sudo apt update

• La clé est déposée dans /etc/apt/keyrings/, répertoire prévu pour les clés gérées localement, et non dans le trousseau global.
• Signed-By: restreint cette clé à ce dépôt seulement. Le wiki de Debian (page UseThirdParty) explique pourquoi c'est essentiel : une clé placée dans le trousseau de confiance global, /etc/apt/trusted.gpg.d/, serait acceptée pour signer n'importe quel dépôt, y compris des paquets qui se feraient passer pour ceux de Debian ou d'Ubuntu.
• Suites: lit le nom de code dans /etc/os-release : le dépôt suit la version d'Ubuntu.

Avant de faire confiance à une clé téléchargée, vérifiez son empreinte avec celle publiée par l'éditeur sur une autre page :

$ gpg --show-keys /etc/apt/keyrings/docker.asc

Pour la clé de Docker, l'empreinte attendue se termine par 0EBF CD88. Et rappelez-vous ce qu'implique un dépôt tiers : ses paquets s'installent avec les droits de root, scripts compris. Le wiki de Debian le dit sans détour : si vous ne faites pas confiance aux mainteneurs d'un dépôt, ne l'activez pas.

Vérifier les mises à jour automatiques

$ cat /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Les deux valeurs à 1 : rafraîchir les listes et installer les mises à jour chaque jour. Les origines autorisées sont dans /etc/apt/apt.conf.d/50unattended-upgrades ; une fois les commentaires retirés, la machine de test contient :

Unattended-Upgrade::Allowed-Origins {
	"${distro_id}:${distro_codename}";
	"${distro_id}:${distro_codename}-security";
	"${distro_id}ESMApps:${distro_codename}-apps-security";
	"${distro_id}ESM:${distro_codename}-infra-security";
};

Seulement la sécurité, et les origines ESM si Ubuntu Pro est activé. Pour vérifier le comportement sans rien installer, et lire ce qui s'est passé :

$ sudo unattended-upgrade --dry-run -v
$ ls /var/log/unattended-upgrades/
$ less /var/log/apt/history.log
$ systemctl list-timers apt-daily.timer apt-daily-upgrade.timer

/var/log/apt/history.log garde la trace de toutes les opérations APT, manuelles ou automatiques : date, commande, paquets et versions. C'est le premier fichier à ouvrir quand un service s'est mis à se comporter différemment « sans que personne ne touche à rien ».

Enfin, après une série de mises à jour :

$ cat /var/run/reboot-required 2>/dev/null && cat /var/run/reboot-required.pkgs

Si le fichier existe, un redémarrage est nécessaire pour que la mise à jour (souvent le noyau) prenne effet. Sur sig-app-1, on le planifie dans la fenêtre de maintenance, après avoir vérifié que signalements.service est bien activé (leçon 11).

Sous le capot

Ce que fait apt install. APT lit les index téléchargés par apt update (sous /var/lib/apt/lists/), construit le graphe des dépendances, choisit pour chaque paquet la version candidate (la plus haute version de priorité maximale), et calcule une solution qui satisfait toutes les contraintes : c'est un vrai problème de résolution, d'où les messages parfois cryptiques en cas de conflit. Il télécharge les .deb dans /var/cache/apt/archives/, vérifie leurs empreintes contre les index signés, puis appelle dpkg dans le bon ordre. dpkg décompresse chaque paquet, exécute le script preinst, dépose les fichiers, exécute postinst (qui, pour un service, appelle souvent systemctl enable --now), et met à jour /var/lib/dpkg/status.

L'index signé. Sur la machine de test, l'en-tête du fichier InRelease de la poche de sécurité commence ainsi (le fichier se poursuit par la liste des empreintes et la signature) :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Origin: Ubuntu
Label: Ubuntu
Suite: noble-security
Version: 24.04
Codename: noble
Date: Fri, 02 Oct 2026  3:27:10 UTC

Le champ Date est signé avec le reste. Il ne suffit pas, à lui seul, contre une attaque discrète : vous servir un index parfaitement signé, mais vieux d'un an, vous priverait des correctifs sans rien casser. Les dépôts qui veulent s'en protéger ajoutent un champ Valid-Until, au-delà duquel APT refuse l'index ; celui-ci n'en déclare pas. Surveiller la date de la dernière mise à jour réussie de chaque serveur reste donc utile.

Les fichiers de configuration. Quand un paquet mis à jour apporte une nouvelle version d'un fichier de /etc que vous avez modifié, dpkg ne l'écrase pas : il vous pose la question en mode interactif, et garde votre version en mode non interactif (selon les options passées), en déposant la nouvelle à côté avec le suffixe .dpkg-dist. Cherchez ces fichiers après une mise à jour majeure : find /etc -name '*.dpkg-*'.

Pièges courants

Lancer apt upgrade sans apt update. APT travaille avec les index d'hier, ou du mois dernier : il annonce « rien à mettre à jour » alors que des correctifs existent.

Could not get lock /var/lib/dpkg/lock-frontend. Une autre opération APT est en cours, très souvent unattended-upgrades lancé par son minuteur, juste après le démarrage. Attendez qu'elle se termine (ps -ef | grep -E 'apt|dpkg'). Ne supprimez jamais le fichier de verrou : deux dpkg simultanés peuvent laisser la base des paquets incohérente.

dpkg was interrupted, you must manually run 'sudo dpkg --configure -a'. Une installation a été coupée (connexion SSH perdue, machine redémarrée). Faites ce que dit le message, puis sudo apt -f install pour terminer les dépendances. Pour les longues opérations à distance, travaillez dans tmux (leçon 10).

Une erreur de signature à apt update (NO_PUBKEY, EXPKEYSIG). La clé d'un dépôt manque ou a expiré. Récupérez la nouvelle clé depuis la source officielle de l'éditeur et mettez à jour le fichier désigné par Signed-By. Ne désactivez jamais la vérification (trusted=yes) pour « débloquer » la situation.

Des paquets « kept back ». apt upgrade refuse une mise à jour qui exigerait d'installer ou de supprimer d'autres paquets de façon qu'il juge risquée, ou qui est déployée progressivement par Ubuntu (phased updates). Regardez lequel avec apt list --upgradable, puis apt-cache policy ; ne lancez pas full-upgrade les yeux fermés.

Mélanger les versions. Ajouter le dépôt d'une autre version de la distribution (Debian testing sur une stable, ou les paquets d'une Ubuntu plus récente) pour obtenir un logiciel plus récent finit en dépendances impossibles à satisfaire. Utilisez le dépôt de l'éditeur prévu pour votre version, les backports, ou un conteneur.

Croire qu'un service mis à jour est corrigé. Tant qu'il n'a pas redémarré, il exécute l'ancien code. needrestart le fait pour la plupart des services sur Ubuntu 24.04 ; vérifiez le cas de vos applications, et le noyau, qui exige un redémarrage de la machine.

Sécurité

• N'installez que depuis des sources signées, et limitez chaque clé à son dépôt (Signed-By). Un dépôt tiers est un accès root permanent que vous accordez à son éditeur : chaque mise à jour exécute ses scripts.
• curl ... | sudo bash exécute sans le lire un script venu du réseau, avec tous les droits. Si l'éditeur ne propose que cela, téléchargez le script, lisez-le, vérifiez son empreinte, puis exécutez-le, ou cherchez un paquet.
• Les mises à jour de sécurité ne sont pas facultatives. La majorité des intrusions exploitent des failles connues et corrigées depuis longtemps. Gardez unattended-upgrades actif, surveillez /var/run/reboot-required, et redémarrez régulièrement.
• Surveillez universe et les paquets abandonnés. Un paquet de universe sans mainteneur actif peut garder une faille des mois. Faites l'inventaire (dpkg -l), retirez ce qui ne sert plus (moins de paquets, moins de failles), et envisagez Ubuntu Pro pour les serveurs qui dépendent de universe. Le cours Gestion des vulnérabilités outille cet inventaire.
• Les outils de mise à jour sont eux-mêmes du code privilégié. Fin 2024, des chercheurs de Qualys ont publié plusieurs failles d'élévation de privilèges dans needrestart (dont CVE-2024-48990), qui s'exécute en root après chaque opération APT : un utilisateur local pouvait en abuser pour devenir root. Elles ont été corrigées par des mises à jour... appliquées automatiquement aux serveurs à jour. C'est l'argument le plus simple en faveur des mises à jour automatiques.

En production

• Les mises à jour se planifient. Les correctifs de sécurité s'appliquent automatiquement chaque nuit ; les redémarrages et les mises à jour non urgentes se font dans une fenêtre de maintenance connue des utilisateurs, une machine à la fois quand le service est réparti sur plusieurs (cours Le cloud : les fondamentaux, leçon 3).
• On reconstruit plutôt que de mettre à jour en place. Dans une infrastructure immuable, on ne lance pas apt upgrade sur le serveur : on fabrique une nouvelle image à jour, on la déploie, et on supprime l'ancienne machine. Les conteneurs appliquent le même principe : reconstruire l'image régulièrement pour récupérer les correctifs de l'image de base (cours Construire des images de conteneurs).
• Des miroirs et un dépôt interne. À partir de quelques dizaines de machines, un miroir local (ou un cache comme apt-cacher-ng) accélère les mises à jour et permet de geler un état testé du dépôt, puis de le promouvoir d'un environnement à l'autre, comme un artefact.
• L'inventaire des versions de chaque serveur alimente la gestion des vulnérabilités : on ne corrige que ce que l'on sait installé.
• Chez Lyneko, les nœuds du cluster Kubernetes sont gérés par Scaleway (Kapsule) et les applications tournent dans des conteneurs dont les images sont reconstruites et analysées par la CI : les commandes de cette leçon servent surtout sur les machines virtuelles des clients et les postes d'administration.

Exercices

1. Lire une version (niveau 100). Décomposez la version 2:8.2.3995-1ubuntu2.24. Laquelle est la plus récente : 2:8.2.3995-1ubuntu2.24 ou 9.0.0-1 ?

2. Répondre à l'alerte (niveau 200). Un avis de sécurité Ubuntu indique que la faille d'OpenSSH est corrigée dans 1:9.6p1-3ubuntu13.19 pour Ubuntu 24.04. Écrivez les commandes qui disent si sig-app-1 est corrigé, et sinon, comment le corriger et vérifier que le correctif est en service.

3. Le dépôt trop généreux (niveau 200). Vous trouvez sur un serveur un fichier /etc/apt/trusted.gpg.d/editeur.gpg et une ligne deb https://paquets.editeur.example/ubuntu noble main dans /etc/apt/sources.list.d/editeur.list. Quel est le risque, et comment corrigez-vous ?

4. Le matin après (niveau 200). Lundi, Signalements répond des erreurs depuis 6 h 30, alors que personne n'est intervenu depuis vendredi. Décrivez votre enquête, fichier par fichier.

Récapitulatif

• Un paquet contient des fichiers, des métadonnées (version, dépendances) et des scripts ; dpkg l'installe, APT résout les dépendances, télécharge depuis les dépôts et vérifie les signatures.
• Les dépôts Ubuntu 24.04 sont décrits au format deb822 dans /etc/apt/sources.list.d/ubuntu.sources : nom de code, poches (-security, -updates) et composants (main supporté, universe communautaire).
• Les distributions stables reportent les correctifs sans changer de version amont : comparez la révision à l'avis de sécurité.
• apt update rafraîchit les index ; upgrade met à jour sans supprimer ; full-upgrade peut supprimer ; -s simule ; apt-cache policy dit quelle version vient d'où ; dpkg -S et dpkg -L relient fichiers et paquets.
• Un dépôt tiers : clé dans /etc/apt/keyrings/, limitée par Signed-By, empreinte vérifiée. Plus jamais apt-key.
• Sur Ubuntu Server, unattended-upgrades applique la sécurité chaque jour, needrestart redémarre les services concernés, et /var/run/reboot-required signale qu'il faut redémarrer la machine.
• /var/log/apt/history.log garde la trace de tout ce qu'APT a fait.

Pour aller plus loin

• Le chapitre 2 du Debian Reference, qui décrit la gestion des paquets en profondeur, avec ses pièges.
• La page DebianRepository/UseThirdParty du wiki de Debian, à relire avant chaque ajout de dépôt.
• La documentation Automatic updates d'Ubuntu Server, pour régler finement unattended-upgrades (listes noires, redémarrage automatique, notifications).
• Le cours Linux : administration système, qui prolonge ce cours (stockage, réseau, tâches planifiées), et le cours Gestion des vulnérabilités.