Debian on slash-root.fr

Aptly : mirroiter Debian proprement

Fri, 13 Mar 2026 19:05:06 +0100

Quand on gère une flotte de serveurs Debian, on finit toujours par se poser la même question : comment maîtriser ce que mes machines vont installer ? Comment être sûr qu'un apt update ne va pas me ramener une version de paquet qui casse tout ? Et surtout, comment faire pour que mes serveurs de prod ne dépendent pas d'un miroir externe qui peut tomber au pire moment ?

La réponse classique, c'est de monter un miroir local. Sauf que mirrorer Debian avec les outils standards (debmirror, apt-mirror...), c'est lourd, c'est rigide, et ça ne répond qu'à la moitié du problème. On a une copie locale, d'accord, mais on n'a toujours aucun contrôle sur ce qui change d'un jour à l'autre.

C'est là qu'aptly entre en jeu.

Ce qu’aptly fait vraiment

aptly, c'est un gestionnaire de dépôts Debian écrit en Go. Il sait faire trois choses fondamentales :

mirrorer un dépôt distant -- comme apt-mirror, mais en mieux
Figer l'état d'un miroir dans un snapshot immuable -- ça, c'est la vraie valeur ajoutée
Publier ce snapshot pour que vos machines puissent l'utiliser

Le workflow de base, c'est ça :

mirror create → mirror update → snapshot create → publish snapshot

Et quand il faut mettre à jour :

mirror update → snapshot create → publish switch

Le publish switch bascule la publication d'un snapshot à un autre. Vos machines continuent de pointer sur la même URL, mais le contenu change de manière contrôlée. Si ça foire, vous rebasculez sur l'ancien snapshot. Pas de panique, pas de retélécharger quoi que ce soit.

Installation

Via les paquets Debian

C'est la méthode standard, celle qu'on va utiliser ici :

sudo apt update
sudo apt install aptly

Sur Debian Trixie, ça installe la version 1.5.0. C'est pas la toute dernière (la 1.6.2 existe), mais c'est largement suffisant pour ce qu'on va faire.

Vérification :

$ aptly version
aptly version: 1.5.0

L’upstream (optionnel)

Si vous voulez absolument la dernière version upstream, vous pouvez ajouter le dépôt officiel d'aptly. Mais franchement, pour un usage classique, la version Debian fait le job. Je mentionne juste l'option pour ceux qui en ont besoin :

sudo mkdir -p /etc/apt/keyrings
wget -O /etc/apt/keyrings/aptly.asc https://www.aptly.info/pubkey.txt

echo "deb [signed-by=/etc/apt/keyrings/aptly.asc] http://repo.aptly.info/release trixie main" \
 | sudo tee /etc/apt/sources.list.d/aptly.list

sudo apt update
sudo apt install aptly

Mais encore une fois, c'est optionnel. On va continuer avec la version des dépôts Debian.

Configuration de base

aptly stocke tout dans ~/.aptly par défaut. En prod, on va plutôt utiliser /var/aptly. On crée le répertoire et on configure aptly pour l'utiliser :

sudo mkdir -p /var/aptly
sudo chown $USER:$USER /var/aptly

Le fichier de config, c'est ~/.aptly.conf (ou /etc/aptly.conf pour une config globale). On va en créer un minimal :

cat > ~/.aptly.conf << 'EOF'
{
 "rootDir": "/var/aptly",
 "architectures": ["amd64"]
}
EOF

On restreint à amd64 parce que c'est ce qu'on utilise. Pas la peine de télécharger du i386, du arm64 ou du armhf si on n'en a pas besoin.

Le rootDir, c'est la racine de tout. Dedans, aptly va créer :

db/ -- sa base de données interne
pool/ -- les fichiers .deb téléchargés
public/ -- les dépôts publiés, ceux qu'on va exposer

Importer les clés GPG

Avant de créer un miroir, aptly a besoin des clés GPG pour vérifier les signatures des dépôts distants. Sur Debian, les clés d'archive sont déjà présentes dans /usr/share/keyrings/. Il suffit de les importer dans le trousseau d'aptly :

gpg --no-default-keyring \
 --keyring /usr/share/keyrings/debian-archive-keyring.gpg \
 --export | \
 gpg --no-default-keyring \
 --keyring trustedkeys.gpg \
 --import

Ça importe les clés dans ~/.gnupg/trustedkeys.gpg, le trousseau qu'aptly utilise par défaut.

Créer un miroir de Debian Trixie

On va mirrorer le dépôt officiel français (ftp.fr.debian.org), avec les sections main et non-free-firmware. Pourquoi non-free-firmware ? Parce que depuis Debian 12, les firmwares non-libres (wifi, GPU...) sont dans cette section, et on en a souvent besoin.

aptly mirror create \
 -architectures=amd64 \
 debian-trixie \
 http://ftp.fr.debian.org/debian/ \
 trixie main non-free-firmware

Quelques remarques :

Le flag -architectures=amd64 se place avant la sous-commande mirror. C'est un flag global. Si vous le mettez après, aptly va râler.
Le nom du miroir (debian-trixie), c'est vous qui le choisissez. Prenez un nom explicite.
L'URL doit finir par un /.
On spécifie la distribution (trixie) et les composants (main non-free-firmware).

La commande crée la définition du miroir, mais ne télécharge rien encore. Pour ça, il faut lancer un mirror update.

Remplir le miroir

aptly mirror update debian-trixie

Là, ça télécharge. Et ça prend du temps. Un miroir complet de Debian main + non-free-firmware en amd64, c'est plusieurs dizaines de Go. Prévoyez du café.

Vous pouvez suivre la progression dans le terminal. aptly affiche les paquets au fur et à mesure qu'il les télécharge.

Une fois terminé, vous pouvez voir ce que contient le miroir :

aptly mirror show debian-trixie

Ça vous donne le nombre de paquets, la taille totale, la date de dernière mise à jour, etc.

Créer un snapshot

Le miroir est à jour. Maintenant, on va en faire un snapshot. Un snapshot, c'est une copie figée et immuable de l'état du miroir à un instant T. Une fois créé, il ne bouge plus, quoi qu'il arrive au miroir source.

aptly snapshot create trixie-$(date +%Y%m%d) from mirror debian-trixie

J'utilise la date dans le nom du snapshot. C'est une bonne pratique : ça permet de savoir immédiatement à quoi correspond chaque snapshot.

Vous pouvez lister vos snapshots :

aptly snapshot list

Et voir le détail d'un snapshot :

aptly snapshot show trixie-20260313

Publier le snapshot

Un snapshot qui n'est pas publié, ça ne sert à rien. La publication génère l'arborescence standard Debian (dists/, pool/, fichiers Release signés...) dans /var/aptly/public/.

aptly publish snapshot -distribution=trixie trixie-20260313

Le flag -distribution=trixie indique quelle distribution utiliser dans les métadonnées du dépôt publié. C'est ce que vos machines verront dans leur sources.list.

aptly va vous demander la passphrase de votre clé GPG pour signer le fichier Release. Si vous n'avez pas encore de clé GPG, créez-en une :

gpg --full-generate-key

Choisissez RSA 4096 bits, et renseignez un nom et un email.

Une fois la publication terminée, vous avez un dépôt Debian complet dans /var/aptly/public/. Il ne reste plus qu'à l'exposer via un serveur web.

L’impact des hard links

Un détail important : quand aptly publie un snapshot, il ne copie pas les fichiers .deb. Il crée des hard links depuis le pool vers le répertoire public/.

Ça veut dire quoi concrètement ?

Pas de duplication -- un paquet présent dans plusieurs snapshots n'occupe qu'une seule fois la place sur le disque
Publication instantanée -- créer un hard link, c'est quasi gratuit en temps et en espace
Plusieurs snapshots publiés en même temps -- vous pouvez avoir trixie-20260313 et trixie-20260310 publiés simultanément, ils partagent les fichiers communs

C'est pour ça que le publish switch est si rapide. aptly ne déplace rien, il change juste les liens.

Par contre, attention : si vous supprimez un snapshot publié avec snapshot drop, aptly refuse tant que la publication existe. Il faut d'abord dépublier (publish drop) ou basculer vers un autre snapshot (publish switch).

Mettre à jour le miroir et basculer

Quelques jours passent. Le miroir Debian a évolué. Vous voulez mettre à jour votre dépôt local. Voilà le workflow complet :

# 1. Mettre à jour le miroir
aptly mirror update debian-trixie

# 2. Créer un nouveau snapshot
aptly snapshot create trixie-$(date +%Y%m%d) from mirror debian-trixie

# 3. Basculer la publication vers le nouveau snapshot
aptly publish switch trixie trixie-20260315

Le publish switch fait tout le boulot :

Il met à jour les métadonnées (Release, Packages, Contents...)
Il ajuste les hard links dans public/
Il signe le nouveau Release avec GPG
Il nettoie les anciens liens qui ne servent plus

Vos machines qui pointent sur ce dépôt voient le changement au prochain apt update. Pas de coupure, pas de temps d'arrêt.

Si le nouveau snapshot pose problème, vous rebasculez sur l'ancien :

aptly publish switch trixie trixie-20260313

C'est aussi rapide dans un sens que dans l'autre.

Les dépôts locaux (mention rapide)

aptly sait aussi gérer des dépôts locaux, où vous poussez vos propres paquets .deb. Le workflow est similaire :

# Créer un dépôt local
aptly repo create mon-depot

# Ajouter des paquets
aptly repo add mon-depot /chemin/vers/*.deb

# Snapshot
aptly snapshot create mon-depot-v1 from repo mon-depot

# Publier
aptly publish snapshot mon-depot-v1

Je ne développe pas plus ici, parce que le cas d'usage principal d'aptly, c'est quand même le mirroring. Mais sachez que c'est possible.

Exposer le dépôt

Le serveur embarqué (test uniquement)

aptly a un petit serveur HTTP intégré. C'est pratique pour tester, mais la doc officielle est claire : not suitable for real production usage.

aptly serve -listen=:8080

Vous pouvez alors ajouter le dépôt sur une machine de test :

echo "deb http://votre-serveur:8080/ trixie main non-free-firmware" \
 | sudo tee /etc/apt/sources.list.d/aptly-test.list

nginx (production)

En prod, on utilise nginx. Je ne vais pas détailler ici parce que ça fera l'objet d'un second article si besoin, mais l'idée générale :

server {
 listen 80;
 server_name repo.example.com;
 root /var/aptly/public;
 location / {
 autoindex on;
 }
}

Vous activez le vhost, vous rechargez nginx, et c'est bon. Pour HTTPS, ajoutez Let's Encrypt avec certbot.

Côté client, vous ajoutez le dépôt :

echo "deb http://repo.example.com/ trixie main non-free-firmware" \
 | sudo tee /etc/apt/sources.list.d/mon-miroir.list

sudo apt update

Si le dépôt est signé (et il devrait l'être), distribuez votre clé GPG publique aux clients :

gpg --armor --export VOTRE_KEY_ID > /var/aptly/public/repo-key.asc

Sur les clients :

wget -O /etc/apt/keyrings/mon-repo.asc http://repo.example.com/repo-key.asc

echo "deb [signed-by=/etc/apt/keyrings/mon-repo.asc] http://repo.example.com/ trixie main non-free-firmware" \
 | sudo tee /etc/apt/sources.list.d/mon-miroir.list

Automatiser avec cron

Un miroir, ça se met à jour régulièrement. Voici un script cron qui fait le job :

#!/bin/bash
# /etc/cron.daily/aptly-update

set -euo pipefail

MIRROR="debian-trixie"
DATE=$(date +%Y%m%d)

# Mise à jour du miroir
aptly mirror update "$MIRROR"

# Nouveau snapshot
aptly snapshot create "trixie-${DATE}" from mirror "$MIRROR"

# Basculer la publication
aptly publish switch -batch -gpg-key="VOTRE_KEY_ID" trixie "trixie-${DATE}"

# Nettoyer les vieux snapshots (garder les 7 derniers)
aptly snapshot list -raw | grep "^trixie-" | sort | head -n -7 | while read snap; do
 aptly snapshot drop "$snap" 2>/dev/null || true
done

# Nettoyer la base
aptly db cleanup

Le flag -batch est crucial : il permet à GPG de fonctionner sans terminal interactif. Sans ça, le script va bloquer en attendant que vous tapiez la passphrase.

Pour éviter ça, vous pouvez aussi utiliser gpg-agent avec un cache de passphrase, ou stocker la passphrase dans un fichier sécurisé et utiliser -passphrase-file.

Nettoyage et maintenance

aptly conserve tous les paquets téléchargés dans son pool, même ceux qui ne sont plus référencés par aucun snapshot. Pour faire le ménage :

aptly db cleanup

Ça supprime les paquets orphelins. Si vous voulez voir ce qui va être supprimé avant de le faire :

aptly db cleanup -verbose -dry-run

Pour sauvegarder votre installation aptly, c'est simple : sauvegardez /var/aptly en entier. Tout est dedans.

tar -czf aptly-backup-$(date +%Y%m%d).tar.gz /var/aptly

Quelques astuces

Filtrer les paquets lors du mirroring. Si vous ne voulez mirrorer que certains paquets (par exemple, uniquement nginx et ses dépendances), vous pouvez utiliser des filtres :

aptly mirror create -filter='nginx' -filter-with-deps \
 nginx-only \
 http://ftp.fr.debian.org/debian/ \
 trixie main

Le flag -filter-with-deps est important : sans lui, vous récupérez nginx mais pas ses dépendances, et ça ne servira à rien.

Comparer deux snapshots. Pour voir ce qui a changé entre deux snapshots :

aptly snapshot diff trixie-20260313 trixie-20260315

Fusionner des snapshots. Vous pouvez combiner plusieurs snapshots en un seul. Utile si vous avez un miroir Debian et un dépôt local, et que vous voulez les publier ensemble :

aptly snapshot merge trixie-complet trixie-20260315 mon-depot-v1

Conclusion

aptly résout un vrai problème : comment garder le contrôle sur ce que vos machines Debian vont installer. Les miroirs classiques vous donnent une copie locale, d'accord, mais ils ne vous donnent pas la maîtrise des changements. Avec aptly et ses snapshots, vous décidez quand et comment vos serveurs voient les mises à jour.

Le workflow mirror create → mirror update → snapshot create → publish snapshot → publish switch devient vite un réflexe. Et le jour où une mise à jour casse quelque chose, vous serez bien content de pouvoir rebascule sur le snapshot d'hier en une commande.

Les hard links font que tout ça reste léger en espace disque et rapide en exécution. Vous pouvez avoir plusieurs snapshots publiés en parallèle, pour des environnements de test et de prod différents, sans exploser votre stockage.

Bref, si vous gérez des serveurs Debian sérieusement, aptly mérite sa place dans votre boîte à outils.

Debian : Configuration complète d’unattended-upgrades pour une sécurité sans effort

Thu, 08 May 2025 14:03:19 +0200

1. Introduction, ou pourquoi il est temps d’arrêter de faire semblant

Laissez-moi deviner : vous êtes du genre à vous vanter d'être un administrateur système compétent, mais vous ne vous souvenez pas de la dernière fois que vous avez tapé apt update && apt upgrade sur vos serveurs en production ? Pas étonnant que vos systèmes ressemblent à un gruyère numérique avec plus de trous que de fromage. Un bon sysadmin met à jour ses systèmes - un vrai sysadmin automatise ça et passe à autre chose.

Heureusement, les créateurs de Debian n'ont pas supposé que vous étiez tous des héros de la ligne de commande avec une mémoire infaillible et un agenda aussi vide que /dev/null. Ils nous ont gratifiés d'unattended-upgrades, ce petit bijou d'automatisation que seuls les vrais barbus savent configurer correctement. Bien sûr, vous pourriez continuer à mettre à jour manuellement, de la même manière que vous pourriez continuer à croire que vi est plus difficile qu'Emacs.

2. Unattended-upgrades : le sysadmin silencieux qui ne prend jamais de pause café

Contrairement à votre stagiaire qui croit que "mise à jour de sécurité" signifie "changer son mot de passe de 'password123' à 'password1234'", unattended-upgrades est un service qui prend son travail au sérieux. Cette petite merveille d'ingénierie fonctionne pendant que vous dormez profondément, rêvant probablement de clusters Kubernetes parfaitement orchestrés (on sait tous que ça n'arrive que dans les rêves).

Techniquement parlant (et les vrais barbus aiment parler techniquement), c'est un démon qui s'exécute via systemd timers pour :

Chercher les mises à jour que vous auriez dû installer il y a des semaines
Filtrer celles qui empêcheront votre système de se faire pwner par un script kiddie
Les installer sans vous demander votre avis (parce qu'on sait tous que vous diriez "plus tard")
Redémarrer votre serveur au milieu de la nuit quand personne ne regardera vos graphs de monitoring chuter momentanément

Ce paquet fonctionne sur n'importe quelle version de Debian (de l'antique Buster à la fraichement sortie Bookworm) et même sur ces ersatz de Debian comme Ubuntu, si vous vous abaissez à utiliser de telles distributions.

3. Installation pour ceux qui savent encore taper sur un clavier

3.1 Les bases (même votre stagiaire pourrait le faire)

Ouvrez votre terminal noir (parce que bien sûr, vous utilisez un fond noir avec des polices vertes, comme tout vrai barbu qui se respecte) et tapez ces incantations magiques :

sudo apt update
sudo apt install unattended-upgrades apt-listchanges

Ce que vous venez de conjurer :

unattended-upgrades : le véritable héros silencieux qui fera le travail que vous procrastinez habituellement
apt-listchanges : pour recevoir des emails détaillés que vous prétendrez lire avant de les archiver automatiquement

3.2 Activation pour les admins qui ont peur de modifier les fichiers de configuration à la main

Si vous préférez l'approche "clique-bouton" (aucun jugement, enfin peut-être un peu), Debian vous offre un assistant :

sudo dpkg-reconfigure --priority=low unattended-upgrades

💡 Astuce de vrai barbu : L'argument --priority=low force l'affichage de toutes les options possibles, parce que les vrais barbus veulent tout contrôler. Les autres priorités sont pour ceux qui pensent qu'utiliser une souris sous Linux est une bonne idée.

Un menu pseudo-graphique va apparaître dans votre terminal. Sélectionnez "Oui" (comme si vous aviez réellement le choix). Cette étape crée le fichier /etc/apt/apt.conf.d/20auto-upgrades avec une configuration basique pour les âmes simples.

4. Configuration pour les vrais barbus (ceux qui n’utilisent pas de GUI)

La configuration d'unattended-upgrades se fait dans deux fichiers de configuration. Si vous ne savez pas ce qu'est un fichier de configuration, fermez cet article et retournez installer Windows :

/etc/apt/apt.conf.d/50unattended-upgrades - Où la vraie magie se passe
/etc/apt/apt.conf.d/20auto-upgrades - Pour dire à votre système à quelle fréquence il doit se sauver lui-même

4.1 Sélection des dépôts (ou comment distinguer les mises à jour importantes des futilités)

Éditez /etc/apt/apt.conf.d/50unattended-upgrades (avec vi, bien sûr, pas avec cette abomination qu'est nano). La section Origins-Pattern est comme le filtre de Tinder de votre système - elle décide quelles mises à jour méritent son attention :

Unattended-Upgrade::Origins-Pattern {
 "origin=Debian,codename=${distro_codename}-security";

 // "origin=Debian,codename=${distro_codename}-updates";

 // "origin=Debian,codename=${distro_codename}-proposed-updates";

 // "origin=Debian,codename=${distro_codename}-backports";
};

Guide de traduction du jargon Debian pour mortels :

Type de dépôt	Ce que Debian dit	Ce que ça signifie vraiment	À activer si...
-security	"Correctifs de sécurité critiques"	"Colmate les trous que les script kiddies utilisent déjà"	Vous avez un minimum d'instinct de survie
-updates	"Corrections importantes non sécuritaires"	"Bugs suffisamment gênants pour qu'on daigne les corriger"	Vous en avez assez que vos services plantent mystérieusement
-proposed-updates	"Candidats en attente de validation"	"Quelqu'un a bricolé ça, ça semble marcher, mais on n'est pas sûr"	Vous aimez vivre dangereusement (ou avez un environnement de test)
-backports	"Nouvelles versions portées vers stable"	"Du code récent greffé sur un OS dinosaure"	Un fonctionnalité VRAIMENT nécessaire vous manque

🐑 Conseil de troupeau : La plupart des moutons n'activent que -security. Les vrais barbus activent tout puis blâment systemd quand ça casse.

4.2 Planification des mises à jour (ou quand laisser votre système jouer au docteur)

Modifiez /etc/apt/apt.conf.d/20auto-upgrades pour définir quand votre système se soignera tout seul :

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Unattended-Upgrade-Time "3";
APT::Periodic::RandomSleep "60";

Explication pour ceux qui n'ont jamais lu le man :

Update-Package-Lists : À quelle fréquence votre système recherche de nouvelles mises à jour.
- "1" = tous les jours (pour les paranoïaques)
- "7" = une fois par semaine (pour les décontractés)
- "0" = jamais (pour ceux qui aiment jouer à la roulette russe avec les exploits)
Unattended-Upgrade : Quand appliquer réellement ces mises à jour.
- "1" = quotidiennement (recommandé par tous ceux qui ont déjà dû nettoyer un serveur compromis)
- "7" = hebdomadaire (un compromis pour les téméraires)
- "0" = jamais (alors pourquoi lire cet article ?)
Unattended-Upgrade-Time : L'heure à laquelle lancer le processus.
- "3" = 3h du matin, quand même les administrateurs système devraient dormir
RandomSleep : Le délai aléatoire pour éviter d'être comme tout le monde.
- "60" = entre 0 et 60 minutes de décalage (pour ne pas faire tomber les miroirs Debian quand tout le monde se rue dessus à 3h00 pile)

🐔 Pour les insomniaques : Sur Debian 11+, RandomSleep est en minutes. Sur Debian 10 et avant, c'est en secondes. Pourquoi ? Parce que la cohérence, c'est surfait quand on peut introduire des bugs subtils dans votre configuration.

4.3 Gestion du reboot automatique (ou comment faire pleurer vos utilisateurs)

Les mises à jour du noyau sont comme les légumes - elles ne font effet que si vous redémarrez. Configurez le comportement dans /etc/apt/apt.conf.d/50unattended-upgrades :

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:30";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";

Ce que ces options signifient vraiment :

Automatic-Reboot : Le grand interrupteur de la terreur nocturne.
- "true" = "J'aime vivre dangereusement et mes backups sont à jour"
- "false" = "Je préfère avoir un noyau vulnérable mais au moins je sais quand mon serveur redémarre"
Automatic-Reboot-Time : L'heure du crime parfait.
- Format : "HH:MM" (choisir une heure où personne ne remarquera que tout est tombé)
- Conseil de barbu : planifiez-le toujours APRÈS les mises à jour, pas pendant
Automatic-Reboot-WithUsers : Le dilemme éthique.
- "true" = "Les sessions des utilisateurs importent moins que la sécurité" (approche soviétique)
- "false" = "Les humains d'abord" (approche diplomatique)

🔥 Histoire vraie : J'ai vu un administrateur configurer un redémarrage automatique à 14h sur un serveur de production. Il a ensuite passé trois semaines à se demander pourquoi les utilisateurs lui envoyaient des messages haineux tous les jours.

4.4 Notifications pour prétendre que vous surveillez vos serveurs

Les emails de notification sont là pour vous donner l'illusion que vous savez ce qui se passe sur vos serveurs. Configurez-les dans /etc/apt/apt.conf.d/50unattended-upgrades :

Unattended-Upgrade::Mail "admin@domaine.fr";
Unattended-Upgrade::MailReport "on-change";

//Unattended-Upgrade::Mail-Server "smtp.example.com";
//Unattended-Upgrade::Mail-Server-Port "587";
//Unattended-Upgrade::Mail-Server-Login "votre_login";
//Unattended-Upgrade::Mail-Server-Password "votre_motdepasse";

Options pour votre spam personnel :

Mail : Qui recevra les rapports que personne ne lit.
- Mettez votre email perso si vous aimez être réveillé à 3h du matin par des notifications
- Ou créez un filtre qui les envoie directement dans un dossier que vous n'ouvrirez jamais
MailReport : La fréquence de spam.
- "always" = pour ceux qui aiment leur boîte mail bien remplie
- "on-change" = le choix des gens raisonnables
- "only-on-error" = pour ceux qui adhèrent à la philosophie "pas de nouvelles, bonnes nouvelles"

📣 Rappel essentiel : Ces mails ne serviront à rien si vous n'avez pas un MTA fonctionnel. Installez-en un ou tous ces paramètres ne seront que des vœux pieux :
sudo apt install postfix
# OU
sudo apt install msmtp msmtp-mta

5. Dompter les mises à jour majeures (ou l’art d’éviter la crise cardiaque à 3h du matin)

Les mises à jour de sécurité, c'est bien, mais les mises à jour majeures, c'est comme laisser un enfant de 5 ans conduire votre voiture - ça peut aller très mal, très vite. Particulièrement avec ces paquets qui utilisent le système d'alternatives de Debian, cette brillante invention qui garantit votre future migraine.

5.1 Le piège des alternatives (ou comment se tirer une balle dans le pied automatiquement)

Les langages comme PHP, Python ou Java utilisent ce merveilleux système d'alternatives, qui permet à plusieurs versions de coexister (comme vos ex, mais en plus utile). Malheureusement, ce système a été conçu par quelqu'un qui n'a manifestement jamais entendu parler de l'automatisation.

Le drame en 4 actes :

Acte	Tragédie	Résultat
1	Votre système découvre PHP 8.3 et pense "oh, quelle belle mise à jour !"	Installation lancée à 3h17 du matin
2	Le script demande poliment : "Voulez-vous faire de cette nouvelle version la version par défaut ?"	Votre serveur fige, attendant une réponse qui ne viendra jamais
3	Vous dormez paisiblement pendant que votre installation reste suspendue	Configuration en état zombie (`sudo dpkg --configure -a` sera votre mantra du matin)
4	Votre système de mise à jour automatique est lui-même bloqué	Félicitations, vous venez de désactiver votre sécurité automatique

5.2 Solutions pour barbus confirmés (et amateurs de nuits tranquilles)

5.2.1 Entraîner debconf à ne pas vous demander votre avis

Ce code est l'équivalent de mettre un bâillon sur debconf pour qu'il arrête de poser des questions stupides :

sudo echo "php8.3 php8.3/common/default_for_install boolean false" | sudo debconf-set-selections
sudo echo "php8.2 php8.2/common/default_for_install boolean true" | sudo debconf-set-selections

Quand l'utiliser : Lorsque vous êtes un admin responsable qui teste d'abord les nouvelles versions avant de les infliger à votre production. Concept alien pour certains, je sais.

5.2.2 Expliquer à Debian ce qu’est une priorité (comme à votre chef de projet)

Le système de priorité d'alternatives est l'équivalent technique d'une hiérarchie féodale - celui avec le plus grand nombre gagne :

sudo update-alternatives --install /usr/bin/php php /usr/bin/php8.2 82 \
 --slave /usr/bin/phar phar /usr/bin/phar8.2 \
 --slave /usr/bin/phpdbg phpdbg /usr/bin/phpdbg8.2

sudo update-alternatives --install /usr/bin/php php /usr/bin/php8.3 80 \
 --slave /usr/bin/phar phar /usr/bin/phar8.3 \
 --slave /usr/bin/phpdbg phpdbg /usr/bin/phpdbg8.3

💡 Astuce de vrai barbu : La valeur numérique est juste une préférence, pas une garantie. Utilisez des nombres significativement différents si vous ne voulez pas être surpris. J'ai déjà vu des administrateurs utiliser 10 et 11, puis se plaindre que leur choix n'était pas respecté - niveau amateur.

5.2.3 Le coup du hook post-installation (ou comment avoir le dernier mot)

Quand vous en avez assez que Debian ignore vos préférences, créez un hook qui aura le dernier mot après chaque mise à jour :

sudo vi /etc/apt/apt.conf.d/99post-upgrade-hook

Ajoutez ce code vindicatif dans le fichier :

DPkg::Post-Invoke {
 "if [ -f /usr/bin/php8.2 ] && [ -f /usr/bin/php8.3 ]; then update-alternatives --set php /usr/bin/php8.2; fi";
};

Pourquoi c'est brillant : Cette approche passive-agressive rétablit votre version préférée après CHAQUE opération APT, même si un paquet tente sournoisement de changer la version par défaut. C'est l'équivalent de dire "Merci pour ton opinion, maintenant on va faire à ma façon quand même".

5.2.4 Mettre un gilet pare-balles contre les versions majeures

Ajoutez à /etc/apt/apt.conf.d/50unattended-upgrades ce code défensif :

Unattended-Upgrade::MinimalSteps "true";
Unattended-Upgrade::Allow-downgrade "false";
Unattended-Upgrade::Allow-APT-Mark-Fallback "false";

Décryptage des incantations de protection :

Option	Ce qu'elle fait vraiment	Traduction en langage barbu
MinimalSteps	Change en mode "un paquet à la fois"	"Je préfère que mon système plante sur UN paquet plutôt que sur TOUS"
Allow-downgrade	Empêche les retours en arrière	"Non, on ne revient pas à PHP 5 juste parce que tu as peur du changement"
Allow-APT-Mark-Fallback	Désactive l'auto-sélection de nouvelles versions	"Touche pas à mes versions majeures, animal ! "

5.2.5 La liste noire de la honte (ou comment bannir les paquets problématiques)

Placez vos paquets critiques sur la liste des indésirables avec cette configuration :

Unattended-Upgrade::Blacklist {
 "php*";
 "mariadb-server";
 "postgresql*";
 "nginx";
 "apache2";
};

5.3 Le plan de bataille pour les vrais professionnels

📌 Stratégie de survie en environnement de production :

Bloquez les versions majeures avec la configuration 5.2.4, à moins que vous n'aimiez les appels nocturnes
Blacklistez impitoyablement tout ce qui fait tourner votre business avec l'option 5.2.5
Construisez un environnement de test identique - les vrais barbus testent AVANT, pas en production
Planifiez vos mises à jour majeures comme des opérations militaires, avec des plans de repli
Faites des backups complets avant toute mise à jour majeure, ou préparez votre CV

⚠️ Alerte rouge : Les mises à jour majeures automatiques sur des composants critiques, c'est comme jouer à la roulette russe avec le serveur de production - vous pourriez vous en sortir, mais est-ce vraiment un risque que vous voulez prendre ? Pour tout ce qui fait tourner votre business (PHP, bases de données, serveurs web), planifiez, testez, puis priez avant de mettre à jour.

6. Entrer dans la matrice : surveillance et déblocage des catastrophes nocturnes

6.1 Les logs que personne ne lit jamais (jusqu’à ce que tout explose)

Même avec l'automatisation, il faut surveiller ce que fait cette bête sauvage qu'est unattended-upgrades. Sinon, c'est comme laisser votre adolescent seul à la maison pendant le week-end - tôt ou tard, vous le regretterez. Voici les fichiers que vous prétendrez consulter régulièrement :

Fichier log	Ce qu'il contient réellement	Quand le lire (soyons honnêtes)
`/var/log/unattended-upgrades/unattended-upgrades.log`	Le journal de bord du capitaine automatique	Quand votre patron demande "que s'est-il passé ?"
`/var/log/unattended-upgrades/unattended-upgrades-dpkg.log`	Ce que dpkg marmonne dans sa barbe	Quand le premier log ne vous dit pas pourquoi tout a explosé
`/var/log/apt/history.log`	La preuve que quelqu'un a fait quelque chose	Pour savoir QUI blâmer (spoiler : c'est toujours systemd)
`/var/log/apt/term.log`	Les mêmes informations qu'avant, mais en plus verbeux	Pour les masochistes qui aiment lire 5000 lignes de texte
`/var/log/dpkg.log`	Chaque respiration de dpkg	Pour les vrais barbus qui lisent les logs comme d'autres lisent Game of Thrones

Les logs sont automagiquement comprimés et rotatés (.1, .2.gz, etc.). Voici comment faire semblant de les surveiller régulièrement :

sudo tail -n 20 /var/log/unattended-upgrades/unattended-upgrades.log

sudo grep -i "error\|fail\|warning" /var/log/unattended-upgrades/unattended-upgrades.log

6.2 Déclencher manuellement les mises à jour (pour le plaisir de voir quelque chose se casser en temps réel)

Pour voir unattended-upgrades en action, comme si vous regardiez un documentaire animalier sur un prédateur dans son habitat naturel :

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

🧪 Preuve d'expertise technique : Utilisez --dry-run lors des démos pour vos collègues. Si ça fonctionne, prenez un air suffisant. Si ça plante, dites nonchalamment : "C'est exactement pourquoi j'utilise dry-run, voyez-vous".

6.3 Techniques de réanimation pour système bloqué (ou comment sauver votre journée)

Quand votre système de mise à jour automatique s'arrête en position fœtale, voici la trousse d'urgence du barbu :

sudo dpkg --audit
sudo dpkg --configure --pending
sudo apt-get -f install
sudo apt-mark showhold

Si votre système est bloqué par une question existentielle comme "Voulez-vous que PHP 8.3 devienne le nouveau PHP par défaut ?", il est temps d'intervenir manuellement (comme arracher la manette des mains d'un enfant) :

sudo dpkg --configure -a
sudo dpkg-reconfigure php8.3-common