Cédrix
155 lines
8.9 KiB
Markdown
155 lines
8.9 KiB
Markdown
Maintenir un système Debian à jour, c'est un peu comme fermer ses fenêtres avant de partir en vacances : on sait qu'il faut le faire, on sait pourquoi, et pourtant ça finit régulièrement par passer à la trappe. Le problème, c'est qu'une CVE qui traîne plusieurs semaines sur un serveur exposé, ça ne pardonne pas toujours.
|
|
|
|
Heureusement, Debian fournit tout ce qu'il faut pour automatiser l'application des correctifs de sécurité, à travers un paquet qui s'appelle `unattended-upgrades`. L'idée est simple : on configure une fois, et la machine se débrouille pour appliquer les patches `-security` sans qu'on ait à y penser. Ce qui suit, c'est la marche à suivre, avec les pièges que j'ai croisés en route.
|
|
|
|
## Le principe
|
|
|
|
`unattended-upgrades` n'est pas un démon qui tourne en permanence. C'est un script qui est lancé une fois par jour par un timer systemd (`apt-daily-upgrade.timer`), et qui regarde dans sa configuration quelles « origines » de paquets il a le droit de mettre à jour. Par défaut, il est conservateur : il ne touche qu'aux paquets venant du dépôt de sécurité officiel. C'est exactement ce qu'on veut sur un serveur de production.
|
|
|
|
Deux fichiers entrent en jeu :
|
|
|
|
- `/etc/apt/apt.conf.d/20auto-upgrades` décide *si* et *à quelle fréquence* unattended-upgrades est exécuté
|
|
- `/etc/apt/apt.conf.d/50unattended-upgrades` décide *quoi* mettre à jour et *comment*
|
|
|
|
On va passer par les deux.
|
|
|
|
## Installation
|
|
|
|
Rien de très exotique :
|
|
|
|
```bash
|
|
sudo apt update
|
|
sudo apt install -y unattended-upgrades apt-listchanges
|
|
```
|
|
|
|
`apt-listchanges` n'est pas strictement nécessaire, mais il est utile : il permet de recevoir un résumé des changements appliqués (notamment les entrées de `NEWS.Debian` qui annoncent parfois des changements de comportement qu'il vaut mieux ne pas découvrir un lundi matin).
|
|
|
|
## Activer l'exécution automatique
|
|
|
|
La commande classique pour ça :
|
|
|
|
```bash
|
|
sudo dpkg-reconfigure --priority=low unattended-upgrades
|
|
```
|
|
|
|
L'interface te pose une question simple — « voulez-vous appliquer automatiquement les mises à jour de stabilité ? » — réponds oui. En coulisses, cette commande crée le fichier `/etc/apt/apt.conf.d/20auto-upgrades` avec ce contenu :
|
|
|
|
```
|
|
APT::Periodic::Update-Package-Lists "1";
|
|
APT::Periodic::Unattended-Upgrade "1";
|
|
```
|
|
|
|
Le `"1"` signifie « tous les jours ». Tu peux mettre `"7"` pour hebdomadaire, mais sur un serveur exposé je ne vois pas l'intérêt de retarder.
|
|
|
|
Pendant qu'on y est, deux options qu'on ajoute souvent à ce fichier :
|
|
|
|
```
|
|
APT::Periodic::Download-Upgradeable-Packages "1";
|
|
APT::Periodic::AutocleanInterval "7";
|
|
```
|
|
|
|
La première télécharge les paquets en amont, ce qui rend l'installation plus rapide le moment venu. La seconde nettoie le cache `/var/cache/apt/archives` une fois par semaine, ce qui évite que ce dossier ne grossisse indéfiniment.
|
|
|
|
## Configurer le périmètre des mises à jour
|
|
|
|
C'est dans `/etc/apt/apt.conf.d/50unattended-upgrades` que ça se joue. Le fichier est livré commenté et documenté, ce qui aide. La section la plus importante ressemble à ça :
|
|
|
|
```
|
|
Unattended-Upgrade::Origins-Pattern {
|
|
"origin=Debian,codename=${distro_codename}-updates";
|
|
"origin=Debian,codename=${distro_codename},label=Debian";
|
|
"origin=Debian,codename=${distro_codename},label=Debian-Security";
|
|
"origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
|
|
};
|
|
```
|
|
|
|
Sur une Debian récente (Bookworm et au-delà), ces lignes sont décommentées par défaut et couvrent les mises à jour de sécurité. Si tu veux être strictement sécurité-seulement, garde uniquement les deux lignes contenant `Debian-Security` et commente les autres. La règle est : `label=Debian-Security` correspond aux correctifs de l'équipe sécurité, le reste correspond aux mises à jour de point release (les `12.6 → 12.7` et compagnie).
|
|
|
|
Quelques options supplémentaires qui méritent qu'on s'y arrête :
|
|
|
|
### Le redémarrage automatique
|
|
|
|
```
|
|
Unattended-Upgrade::Automatic-Reboot "false";
|
|
Unattended-Upgrade::Automatic-Reboot-Time "02:00";
|
|
```
|
|
|
|
Question politique autant que technique. Certaines mises à jour — typiquement le noyau ou la glibc — ne prennent effet qu'après reboot. Tant que la machine n'a pas redémarré, le correctif n'est pas réellement appliqué, même si le paquet est installé. Tu as deux options : laisser à `"false"` et reboot manuellement quand tu veux (en surveillant `/var/run/reboot-required`), ou passer à `"true"` avec une heure creuse. Sur un serveur isolé, le reboot auto se défend. Sur une base de données critique, beaucoup moins.
|
|
|
|
### Les notifications
|
|
|
|
```
|
|
Unattended-Upgrade::Mail "admin@exemple.fr";
|
|
Unattended-Upgrade::MailReport "on-change";
|
|
```
|
|
|
|
Très utile. Tu reçois un mail uniquement quand quelque chose a été installé (ou a échoué), ce qui évite le bruit. Évidemment, il faut un MTA configuré — `msmtp` ou un postfix en relais SMTP font le boulot.
|
|
|
|
### Le nettoyage
|
|
|
|
```
|
|
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
|
|
Unattended-Upgrade::Remove-Unused-Dependencies "true";
|
|
```
|
|
|
|
Sans ça, les vieux noyaux s'accumulent dans `/boot`, qui finit par se remplir, ce qui finit par bloquer la prochaine mise à jour du noyau. Classique.
|
|
|
|
## Tester avant de laisser tourner
|
|
|
|
Avant de partir en weekend, vérifie que la configuration est bien comprise :
|
|
|
|
```bash
|
|
sudo unattended-upgrades --dry-run --debug
|
|
```
|
|
|
|
Le dry-run ne touche à rien, mais il liste les paquets qui seraient installés et — surtout — il indique pourquoi un paquet est ou n'est pas retenu. Si tu vois `Checking: <paquet>` suivi de `Allowed origins are:` et que ton dépôt de sécurité apparaît bien dans la liste, c'est bon signe.
|
|
|
|
Tu peux aussi vérifier que les timers systemd sont actifs :
|
|
|
|
```bash
|
|
systemctl list-timers apt-daily.timer apt-daily-upgrade.timer
|
|
```
|
|
|
|
Ces deux timers sont fournis par le paquet `apt` lui-même, indépendamment de unattended-upgrades. Le premier rafraîchit la liste des paquets, le second déclenche l'upgrade. S'ils sont marqués `inactive`, c'est qu'ils sont masqués quelque part — un `systemctl unmask` règle généralement le problème.
|
|
|
|
## Vérifier après coup
|
|
|
|
Les logs vivent ici :
|
|
|
|
```bash
|
|
sudo less /var/log/unattended-upgrades/unattended-upgrades.log
|
|
sudo less /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
|
|
```
|
|
|
|
Le premier est un résumé lisible, le second contient la sortie brute de `dpkg`. Quand quelque chose se passe mal, c'est généralement dans le second qu'on trouve l'explication (un fichier de configuration modifié, un service qui refuse de redémarrer, ce genre de choses).
|
|
|
|
Pour savoir si la machine attend un reboot après une mise à jour de noyau :
|
|
|
|
```bash
|
|
ls /var/run/reboot-required 2>/dev/null && cat /var/run/reboot-required.pkgs
|
|
```
|
|
|
|
Si le fichier existe, c'est qu'au moins un paquet installé recommande un redémarrage. Le second fichier liste lesquels.
|
|
|
|
## Quelques pièges
|
|
|
|
**Les fichiers de configuration modifiés.** Si tu as personnalisé un `/etc/...` dont le paquet propose une nouvelle version, unattended-upgrades va voir un conflit et laisser tomber l'installation par défaut (option `--force-confdef`). C'est généralement le bon comportement, mais ça veut dire que certaines mises à jour resteront en attente jusqu'à une intervention manuelle. Les logs te le diront.
|
|
|
|
**Les paquets blacklistés.** Tu peux exclure des paquets précis de la mise à jour automatique :
|
|
|
|
```
|
|
Unattended-Upgrade::Package-Blacklist {
|
|
"libc6";
|
|
"linux-image-.*";
|
|
};
|
|
```
|
|
|
|
À utiliser avec discernement — exclure libc6 ou le noyau, c'est précisément exclure les correctifs qui comptent le plus. Mais sur une machine où un reboot coûte cher, ça permet de garder le contrôle sur les paquets sensibles tout en automatisant le reste.
|
|
|
|
**Les dépôts tiers.** Par défaut, seuls les dépôts Debian officiels sont concernés. Si tu utilises un PPA ou un dépôt comme celui de Docker ou de PostgreSQL, il faut explicitement l'ajouter dans `Origins-Pattern`. Sinon, ces paquets ne sont jamais mis à jour automatiquement — ce qui peut être un piège silencieux.
|
|
|
|
## Pour conclure
|
|
|
|
L'automatisation des mises à jour de sécurité sur Debian, ce n'est pas une boîte noire : c'est un script qui tourne une fois par jour, qui lit deux fichiers texte, et qui appelle `apt` avec des règles bien définies. Une fois qu'on a compris ça, le configurer revient à éditer ces deux fichiers selon ses contraintes — niveau de risque, fenêtre de reboot acceptable, notifications souhaitées.
|
|
|
|
Le minimum vital sur un serveur exposé tient en quatre points : `unattended-upgrades` installé, le périmètre limité aux dépôts `-security`, les notifications mail activées, et un coup d'œil régulier à `/var/run/reboot-required` pour ne pas oublier les redémarrages. Le reste, c'est de l'ajustement selon le contexte. |