Mises à jour Linux : automatiser sans casser ses serveurs

Automatiser les mises à jour sans abandonner le contrôle

Automatiser les mises à jour Linux est une bonne pratique de sécurité, mais ce n’est pas une autorisation à déployer n’importe quel changement, à n’importe quel moment, sur tous les serveurs. Une mise à jour de sécurité corrige une vulnérabilité connue ; une mise à niveau de distribution, un changement majeur de noyau ou une mise à jour applicative peut modifier des dépendances, des fichiers de configuration ou le comportement d’un service critique.

Pour une PME ou une équipe d’exploitation, l’objectif raisonnable est donc simple : automatiser les correctifs prévisibles, conserver une visibilité sur les opérations et isoler les changements sensibles. Cette approche réduit la fenêtre d’exposition aux vulnérabilités sans transformer la production en environnement de test.

Un cadre fiable repose généralement sur quatre principes :

• ne mettre à jour automatiquement que les dépôts et paquets approuvés ;
• prévoir une sauvegarde vérifiée ou un mécanisme de restauration avant les changements ;
• journaliser chaque opération et surveiller les erreurs ;
• traiter les redémarrages comme une décision d’exploitation, et non comme un effet secondaire invisible.

Cette distinction est particulièrement importante sur un serveur qui héberge une base de données, un service web, un VPN ou un outil métier. Installer automatiquement un correctif de sécurité est souvent acceptable. Passer automatiquement d’une version majeure de PHP, PostgreSQL, MariaDB ou du noyau à une autre ne l’est pas nécessairement.

Définir ce qui peut être mis à jour automatiquement

Avant de configurer unattended-upgrades, DNF ou un timer systemd, commencez par classer vos machines. Un poste de travail, un serveur de préproduction et un serveur de production ne méritent pas toujours la même politique.

Les changements généralement adaptés à l’automatisation

Les dépôts de sécurité maintenus par la distribution sont le premier candidat. Sur Debian et Ubuntu, le mécanisme unattended-upgrades est conçu pour cette tâche. Sur les distributions utilisant DNF, le paquet dnf-automatic peut télécharger et appliquer des mises à jour selon une politique définie.

Dans tous les cas, vérifiez que vos dépôts sont officiels ou explicitement approuvés. Les dépôts tiers ajoutés pour installer un runtime, un agent de supervision ou un logiciel métier peuvent avoir leur propre cycle de publication. Les inclure sans examen dans une politique automatique augmente le risque de changement inattendu.

Les changements à séparer du flux automatique

Gardez hors du mécanisme automatique les opérations qui demandent une validation fonctionnelle ou une fenêtre de maintenance :

• mise à niveau vers une nouvelle version majeure de Debian, Ubuntu, Rocky Linux, AlmaLinux ou Fedora ;
• modification du fichier /etc/apt/sources.list ou des fichiers de dépôts dans /etc/apt/sources.list.d/ ;
• ajout, retrait ou remplacement d’un dépôt tiers ;
• mise à jour d’un composant applicatif critique ;
• migration de base de données ou changement de format de données ;
• redémarrage d’un serveur qui ne dispose pas de redondance.

La séparation est aussi organisationnelle. Un environnement de préproduction permet d’observer une mise à jour avant sa diffusion en production. Même quand ce n’est pas possible, quelques serveurs pilotes mis à jour en premier donnent un signal utile avant de toucher le reste du parc.

Une automatisation saine ne cherche pas à supprimer toute intervention humaine. Elle réserve l’intervention humaine aux changements dont l’impact ne peut pas être déduit du seul nom d’un paquet.

Préparer les serveurs avant d’activer les mises à jour automatiques

Un serveur sans sauvegarde vérifiée n’est pas prêt à recevoir des changements automatiques. Une sauvegarde doit être exploitable : le simple fait qu’un fichier d’archive existe ne garantit pas qu’il est complet ni qu’il peut être restauré. Pour les fichiers, une stratégie de sauvegarde avec rsync peut couvrir un besoin simple. Pour une base de données, prévoyez un export ou une sauvegarde cohérente avec le moteur utilisé.

Avant l’activation, relevez également les éléments suivants :

• la distribution et sa version, avec cat /etc/os-release ;
• les dépôts actifs ;
• les services exposés et leur méthode de redémarrage ;
• la présence d’une supervision capable de signaler une indisponibilité ;
• l’espace libre dans /var et sur la partition racine ;
• la procédure de connexion de secours, notamment via une console d’hébergeur ou une interface hors bande.

Sur Debian et Ubuntu, inspectez les sources APT avant toute chose :

grep -R --line-number --no-messages '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d/

Sur les systèmes utilisant DNF, la commande suivante aide à inventorier les dépôts activés :

dnf repolist --enabled

Documentez enfin une fenêtre de mise à jour. Même sans redémarrage automatique, l’installation de paquets peut relancer certains services. Un redémarrage de daemon web ou de processus de supervision est souvent bref, mais il doit rester visible et compatible avec vos engagements de disponibilité.

Configurer les correctifs de sécurité sur Debian et Ubuntu

Debian et Ubuntu proposent le paquet unattended-upgrades. Il s’appuie sur APT pour installer, selon la configuration, des mises à jour issues des origines autorisées. La documentation officielle d’Ubuntu décrit ce mécanisme dans sa page consacrée aux mises à jour de sécurité automatiques.

Installez d’abord le composant si nécessaire :

sudo apt update
sudo apt install unattended-upgrades

Le fichier /etc/apt/apt.conf.d/20auto-upgrades active les tâches périodiques APT. Une configuration courante pour télécharger et installer quotidiennement les mises à jour est la suivante :

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Le chiffre indique une périodicité en jours. Le fichier déterminant pour la sélection des origines est généralement /etc/apt/apt.conf.d/50unattended-upgrades. Sur un serveur, évitez de le modifier à la hâte : lisez les commentaires existants et assurez-vous que seules les origines prévues sont activées.

Le paramètre Unattended-Upgrade::Allowed-Origins peut limiter les mises à jour aux dépôts de sécurité de votre distribution. Les libellés exacts dépendent de la version et des fichiers de sources configurés. Il est donc préférable de partir de l’exemple généré localement plutôt que de recopier une liste trouvée pour une autre version d’Ubuntu ou Debian.

Tester avant de laisser le service agir seul

Avant de compter sur l’exécution planifiée, lancez une simulation. La commande suivante affiche ce que le programme envisagerait de faire :

sudo unattended-upgrade --dry-run --debug

Vérifiez que les paquets proposés correspondent bien à votre politique. Une simulation ne remplace pas un test en préproduction, mais elle permet de détecter rapidement une origine de paquet mal configurée ou un dépôt tiers inclus par erreur.

Vous pouvez aussi consulter les paquets pouvant être mis à jour :

apt list --upgradable

Sur les distributions Debian récentes, le déclenchement périodique APT est pris en charge par des unités systemd. Contrôlez leur état avec :

systemctl list-timers 'apt-*'
systemctl status apt-daily.timer apt-daily-upgrade.timer

Ne confondez pas le téléchargement des index de paquets avec leur installation. Les unités APT peuvent exécuter ces étapes séparément. C’est précisément ce qui rend la consultation des journaux indispensable.

Utiliser DNF Automatic sur les distributions Fedora, RHEL et compatibles

Les distributions qui utilisent DNF disposent du paquet dnf-automatic. Il propose plusieurs unités systemd, selon que vous souhaitez seulement télécharger les paquets, notifier leur disponibilité ou les installer automatiquement.

Installez le paquet avec :

sudo dnf install dnf-automatic

Sa configuration se trouve habituellement dans /etc/dnf/automatic.conf. Le fichier contient notamment le paramètre upgrade_type, qui permet de choisir entre l’ensemble des mises à jour disponibles et les mises à jour de sécurité lorsque les métadonnées du dépôt le permettent. Pour une politique prudente, examinez cette valeur ainsi que les options de téléchargement, d’application et de notification.

Les unités proposées peuvent varier selon la distribution et le paquet installé. Listez celles réellement disponibles sur votre machine :

systemctl list-unit-files 'dnf-automatic*'
systemctl list-timers 'dnf-automatic*'

Par exemple, une unité dédiée à l’installation automatique peut être activée uniquement après validation de votre configuration locale :

sudo systemctl enable --now dnf-automatic-install.timer

Ne supposez pas que ce timer applique uniquement les mises à jour de sécurité : le comportement dépend de /etc/dnf/automatic.conf. Contrôlez le fichier, puis effectuez un essai sur une machine non critique. La documentation de référence de DNF est disponible sur le site du projet DNF.

Planifier une tâche maîtrisée avec un timer systemd

Les timers systemd sont utiles lorsque vous devez encadrer une commande, lancer un contrôle préalable ou construire un flux propre à votre parc. Ils remplacent avantageusement un cron pour les systèmes déjà administrés avec systemd : ils s’intègrent à journalctl, peuvent rejouer une tâche manquée et permettent de déclarer les dépendances entre unités.

Un timer n’est cependant pas une raison de réécrire un gestionnaire de paquets. Sur Debian et Ubuntu, préférez unattended-upgrades pour les correctifs APT. Sur DNF, préférez dnf-automatic. Créez une unité personnalisée lorsque vous avez un besoin concret : exécuter une vérification, déclencher une notification ou lancer un script d’inventaire après mise à jour.

Exemple : rapport quotidien des paquets en attente

L’exemple suivant ne modifie rien. Il écrit un état des mises à jour disponibles dans le journal systemd. Créez /etc/systemd/system/updates-report.service :

[Unit]
Description=Rapport des mises à jour APT disponibles

[Service]
Type=oneshot
ExecStart=/usr/bin/apt-get --simulate upgrade

Créez ensuite /etc/systemd/system/updates-report.timer :

[Unit]
Description=Exécution quotidienne du rapport APT

[Timer]
OnCalendar=*-*-* 03:15:00
Persistent=true
RandomizedDelaySec=30m

[Install]
WantedBy=timers.target

Persistent=true demande à systemd d’exécuter la tâche au prochain démarrage lorsqu’une occurrence a été manquée alors que la machine était arrêtée. RandomizedDelaySec=30m répartit les exécutions dans une fenêtre de 30 minutes : c’est utile si plusieurs serveurs consultent le même miroir de paquets.

Chargez et activez le timer :

sudo systemctl daemon-reload
sudo systemctl enable --now updates-report.timer
systemctl list-timers updates-report.timer

Consultez son résultat avec :

journalctl -u updates-report.service

Pour une tâche qui installe réellement des paquets, ajoutez des protections explicites : vérification de l’espace disque, exclusion des périodes de maintenance, prévention des exécutions concurrentes avec flock, et remontée d’erreur vers votre outil de supervision. Les mécanismes natifs APT et DNF sont souvent plus robustes pour gérer leurs propres verrous ; ne les lancez pas simultanément avec une commande manuelle.

Surveiller les journaux et vérifier le résultat des mises à jour

Une automatisation sans suivi finit par produire des serveurs en retard, des erreurs de dépendances ou des espaces disques saturés sans que personne ne s’en aperçoive. La bonne question n’est pas seulement « le timer est-il activé ? », mais « quelle a été sa dernière exécution, et quel en a été le résultat ? »

Sur Debian et Ubuntu, commencez par les journaux propres à unattended-upgrades :

sudo less /var/log/unattended-upgrades/unattended-upgrades.log
sudo less /var/log/unattended-upgrades/unattended-upgrades-dpkg.log

L’historique APT et DPKG apporte un second niveau de lecture :

sudo less /var/log/apt/history.log
sudo less /var/log/dpkg.log

Les journaux systemd se consultent avec journalctl. Le filtre par unité est particulièrement pratique, comme expliqué dans notre guide pour lire et filtrer les logs Linux avec journalctl.

journalctl -u apt-daily-upgrade.service --since "7 days ago"
journalctl -u dnf-automatic-install.service --since "7 days ago"

Le nom exact de l’unité DNF dépend de celle que vous avez activée. Utilisez systemctl list-units et systemctl list-timers pour identifier la bonne unité sur votre système.

Intégrez au minimum ces contrôles à votre supervision :

• âge de la dernière exécution réussie ;
• échec d’une unité systemd liée aux mises à jour ;
• espace libre insuffisant sur les systèmes de fichiers concernés ;
• présence d’un redémarrage requis ;
• nombre de paquets en attente, selon votre politique interne.

Gérer les redémarrages sans provoquer d’indisponibilité

Certains correctifs ne prennent pleinement effet qu’après un redémarrage, notamment lorsqu’ils concernent le noyau. Sur Debian et Ubuntu, certains paquets créent le fichier /var/run/reboot-required lorsqu’un redémarrage est nécessaire. Vous pouvez le tester ainsi :

if [ -f /var/run/reboot-required ]; then
  cat /var/run/reboot-required
fi

La présence du fichier n’impose pas une action immédiate, mais elle doit déclencher une décision. Dans une architecture redondante, mettez à jour et redémarrez un nœud à la fois, vérifiez son retour en service, puis passez au suivant. Derrière un répartiteur de charge, retirez proprement le nœud du trafic avant son redémarrage.

Sur un serveur unique, planifiez une fenêtre de maintenance et vérifiez les services après le retour du système :

systemctl --failed
systemctl status nginx
systemctl status ssh

Adaptez évidemment ces noms de services à votre stack. Si votre serveur dépend de systemd, la commande systemctl --failed donne un premier aperçu après redémarrage. Pour les services importants, complétez par un test applicatif réel : requête HTTP, connexion à la base de données, tâche métier ou contrôle depuis votre supervision externe.

Évitez d’activer un redémarrage automatique généralisé sur des machines critiques sans procédure de continuité. Une automatisation complète est envisageable pour des nœuds jetables ou redondants ; elle est beaucoup plus risquée pour un serveur unique qui héberge plusieurs fonctions.

Prévoir le retour en arrière avant l’incident

Le gestionnaire de paquets conserve un historique, mais l’historique n’est pas une garantie de retour arrière sûr. Désinstaller ou rétrograder un paquet peut être difficile si le dépôt ne fournit plus la version précédente, si des dépendances ont évolué ou si une migration de données a déjà eu lieu.

La restauration la plus fiable dépend de votre architecture :

• restaurer une sauvegarde de fichiers et de données testée ;
• revenir à un snapshot de machine virtuelle ou de volume, après avoir vérifié sa cohérence ;
• recréer un serveur à partir d’une image ou d’une configuration versionnée ;
• basculer vers un nœud sain dans une architecture redondante.

Sur les systèmes utilisant APT, l’historique peut aider à identifier les paquets concernés :

apt history 2>/dev/null || true
grep -A 20 'Start-Date' /var/log/apt/history.log

La première commande n’est pas disponible partout dans la même forme ; le fichier /var/log/apt/history.log reste une source directe utile. Avec DNF, la commande suivante affiche les transactions connues :

dnf history

Avant toute tentative de restauration par le gestionnaire de paquets, lisez la transaction, vérifiez les dépendances proposées et assurez-vous d’avoir une sauvegarde. Une restauration de snapshot peut également annuler des écritures applicatives postérieures au snapshot : elle doit donc être coordonnée avec les équipes concernées.

Conclusion : une automatisation utile est une automatisation observable

Les mises à jour automatiques ne doivent pas être un mécanisme opaque. Sur Debian et Ubuntu, unattended-upgrades permet de cibler les correctifs appropriés. Sur les systèmes à base de DNF, dnf-automatic offre une approche comparable. Les timers systemd complètent ces outils pour les vérifications, rapports et tâches propres à votre environnement.

Commencez par un serveur non critique, limitez le périmètre aux mises à jour de sécurité, observez les journaux pendant plusieurs cycles et documentez la procédure de redémarrage comme celle de restauration. Cette progression apporte davantage de sécurité sans sacrifier la maîtrise opérationnelle de vos serveurs.