Cours Ubuntu 26.04 / Gérer les mises à jour de sécurité et les redémarrages

Sur Ubuntu, une mise à jour de sécurité n’est pas terminée dès que le paquet a été installé : vérifiez les correctifs réellement appliqués, les services utilisant encore d’anciens fichiers et le besoin de redémarrage. Définissez aussi qui intervient, à quel moment et comment confirmer que le serveur répond de nouveau.

Lire la configuration et la planification effectives

unattended-upgrades est le mécanisme qui peut installer des mises à jour APT sans intervention. Sur votre serveur de laboratoire, commencez par consulter le paquet, les minuteries et les options lues par APT :

dpkg-query -W unattended-upgrades
systemctl list-timers --all apt-daily.timer apt-daily-upgrade.timer
apt-config dump | grep -E 'Periodic|Unattended-Upgrade'

Un paquet absent, une unité introuvable ou une erreur de lecture demande un diagnostic adapté à l’image utilisée. Un système minimal, un conteneur et une VM Server ne disposent pas forcément des mêmes outils. La présence du paquet ne prouve pas que l’exécution périodique est activée ou qu’un correctif a été appliqué.

Examinez les options APT::Periodic, les origines autorisées et les exclusions de paquets. Un dépôt connu d’APT n’est pas automatiquement autorisé dans unattended-upgrades. Ne recopiez pas les noms de code d’une autre version Ubuntu. Le guide Ubuntu des mises à jour automatiques décrit cette sélection.

Pour comprendre un horaire inattendu, lisez aussi les unités et leurs éventuelles surcharges :

systemctl cat apt-daily.timer apt-daily-upgrade.timer

Une minuterie systemd peut ajouter un délai aléatoire ou rattraper une échéance manquée lorsque Persistent est activé. La colonne NEXT est un repère de planification, pas une preuve du résultat d’une installation.

Préparer l’application des correctifs et son effet sur les services

Prévoyez une sauvegarde restaurable des données et configurations, une fenêtre d’intervention, l’accès à la console et des tests de service de référence. Un snapshot de VM peut compléter cette préparation, mais ne remplace pas une copie indépendante ni une restauration cohérente des bases de données.

sudo apt update
apt list --upgradable
apt-get -s upgrade

Après chaque commande, lisez les messages avant de poursuivre. Un téléchargement d’index partiellement échoué peut laisser des informations anciennes. Comparez paquets, espace disponible et changements proposés selon la procédure de première mise à jour du serveur. Une simulation décrit une proposition avec l’état actuel ; la transaction réelle peut évoluer si une autre tâche modifie les paquets.

Lorsque le plan est adapté et qu’aucune tâche concurrente ne travaille sur APT, appliquez les correctifs avec sudo apt upgrade et relisez la confirmation. Une mise à jour différée par le déploiement progressif n’est pas systématiquement une erreur ; ne forcez pas tous les paquets retenus sans identifier la cause.

Les scripts de paquets peuvent redémarrer des services. Ubuntu a aussi modifié le comportement de needrestart depuis Ubuntu 24.04 pour redémarrer automatiquement des services affectés dans le contexte APT. Interdire le redémarrage complet du système ne suffit donc pas à garantir l’absence d’interruption applicative.

Comparer la simulation aux journaux d’une vraie exécution

Attendez la fin d’une autre opération APT, puis examinez la sélection automatique sans demander l’installation des correctifs :

sudo unattended-upgrade --dry-run --debug
sudo journalctl -u apt-daily-upgrade.service --since today --no-pager
sudo ls /var/log/unattended-upgrades

Le manuel unattended-upgrade définit --dry-run comme une simulation et --debug comme une sortie de diagnostic supplémentaire. Cette opération peut écrire un journal ; elle ne constitue pas la preuve d’une installation réelle.

Dans le répertoire affiché, consultez les fichiers réellement présents, notamment unattended-upgrades.log pour la sélection et unattended-upgrades-dpkg.log pour le travail du gestionnaire de paquets. Par exemple, pour les noms courants :

sudo tail -n 80 /var/log/unattended-upgrades/unattended-upgrades.log
sudo tail -n 80 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log

Rapprochez les heures, la version installée et les messages : exclusion, maintien, problème de dépôt, manque d’espace ou échec de configuration ne demandent pas le même traitement. Le message de réussite figurant dans une simulation ne prouve pas une modification réelle. Un journal absent peut venir d’une absence d’exécution ou d’une rotation ; ne supprimez pas les anciens journaux pour faire disparaître une anomalie.

Définir une politique explicite de redémarrage automatique

Si votre laboratoire doit attendre une intervention manuelle pour redémarrer, inspectez d’abord les valeurs actuelles. Sauvegardez la configuration avant de la modifier, avec un nouveau répertoire de sauvegarde :

reboot_policy_backup=$(sudo mktemp -d /root/apt-reboot-policy.XXXXXX) &&
sudo cp -a /etc/apt/apt.conf.d "$reboot_policy_backup/" &&
printf 'Sauvegarde : %s\n' "$reboot_policy_backup"

Ne poursuivez pas si une étape échoue. Notez le chemin affiché et l’ancienne valeur effective. Avec sudoedit, ouvrez /etc/apt/apt.conf.d/52unattended-upgrades-local. Si ce fichier existe, examinez son contenu et modifiez uniquement la directive concernée ; ne l’écrasez pas. Sinon, créez ce fichier avec cette ligne :

Unattended-Upgrade::Automatic-Reboot "false";

Les guillemets et le point-virgule sont nécessaires. Le format apt.conf suit un ordre de lecture : un fichier commençant par 52 peut encore être surchargé plus tard ou par le fichier principal. Vérifiez donc la valeur finale au lieu de supposer que le nom choisi l’impose :

apt-config dump | grep 'Unattended-Upgrade::Automatic-Reboot'

Automatic-Reboot false interdit le redémarrage déclenché par cette fonction ; il ne bloque ni un autre outil d’administration ni les redémarrages de services. L’opérateur reste responsable des correctifs nécessitant un redémarrage. Une politique qui autorise ce dernier doit aussi définir heure locale, utilisateurs connectés, interruption acceptable, contrôle du retour et alerte d’échec.

Après l’exercice, comparez uniquement votre modification avec la sauvegarde : rétablissez la valeur antérieure ou retirez la directive ajoutée. Si le fichier était nouveau, ne retirez tout le fichier que s’il contient toujours uniquement votre ajout. Ne recopiez pas tout le répertoire sauvegardé sur une configuration qui a évolué entre-temps. Relisez ensuite apt-config dump et conservez le suivi des redémarrages à réaliser.

Vérifier le besoin de redémarrage et le fonctionnement après retour

if [ -f /run/reboot-required ]; then
    cat /run/reboot-required
    if [ -f /run/reboot-required.pkgs ]; then
        cat /run/reboot-required.pkgs
    fi
else
    printf 'Aucun indicateur reboot-required présent.\n'
fi
uname -r
systemctl --failed

L’indicateur annonce une demande de redémarrage lorsqu’il est créé par les paquets concernés. Son absence ne garantit pas que tous les processus utilisent des bibliothèques corrigées. uname -r décrit le noyau en cours, pas simplement le dernier paquet noyau installé.

Si needrestart est installé, le mode de consultation de needrestart permet un diagnostic complémentaire sans lui demander de relancer les services :

sudo needrestart -r l

Examinez les processus ou services signalés et planifiez leur traitement. Un contrôle sans anomalie détectée ne remplace pas les tests de l’application. Vérifiez aussi séparément les conteneurs et les autres environnements dont elle dépend.

Au moment convenu, enregistrez les travaux et redémarrez le serveur depuis la console ou avec la commande d’administration prévue. Avant une programmation horaire, consultez les règles de shutdown et de l’annulation d’un redémarrage en attente ; ne lancez pas une action immédiate pour simplement tester la syntaxe.

Après le retour, contrôlez le noyau actif, l’heure, les adresses réseau, les unités en échec et une nouvelle connexion SSH. Répétez depuis le client les requêtes de référence : une réponse HTTP attendue, une authentification ou une lecture de données, selon le service. Un processus actif ne suffit pas si le client ne peut pas obtenir la réponse utile.

Si le démarrage ou l’accès réseau échoue, utilisez la console préparée et les journaux de l’intervention. Selon la cause, le noyau précédent, une configuration connue ou une restauration cohérente peuvent être nécessaires ; ne réinstallez pas le serveur avant d’avoir identifié le problème et préservé les données.