Debian 13 Trixie sur serveur : ce qui change, mesuré en VM

Debian 13 « Trixie » est publiée depuis le 9 août 2025. Pour un serveur, trois changements comptent vraiment : /tmp devient un disque en mémoire (tmpfs), /etc/sysctl.conf n'est plus lu au démarrage, et les commandes last, lastb et lastlog sont supprimées. La migration depuis Debian 12 se fait en deux temps (apt upgrade --without-new-pkgs puis apt full-upgrade), et elle peut vous couper SSH ou le réseau si vous ne préparez pas le terrain. Ce guide s'appuie sur un lab en machine virtuelle : une Debian 13.5 neuve, une Debian 12 témoin, et la même Debian 12 migrée en 13.6. Chaque affirmation qui suit est soit une sortie de commande réelle, soit une consigne officielle explicitement présentée comme telle.

Ce que vous allez apprendre

Situer Debian 13 : dates de publication, durée de support, versions réellement installées.
Reconnaître les changements de Trixie qui touchent un serveur, et les vérifier sur votre machine.
Comprendre le piège sysctl.conf, celui que votre test manuel ne détecte pas.
Savoir qui patche quoi dans l'archive Debian, et ce que la machine envoie sur le réseau.
Migrer une Debian 12 « Bookworm » vers Trixie dans le bon ordre, jusqu'au redémarrage.
Anticiper les pièges qui coupent la production : SSH, noms d'interfaces réseau, chiffrement, MariaDB.

Debian 13 en bref

Avant de toucher à un serveur en production, il faut savoir combien de temps la version tiendra et ce qu'elle apporte. Debian n'est pas une distribution à cycle court : une version majeure vous engage pour cinq ans, et ce calendrier détermine quand vous devrez rejouer l'exercice.

Dates et durée de support

Debian 13.0 est sortie le 9 août 2025. Le support complet dure trois ans, jusqu'au 9 août 2028 : c'est l'équipe de sécurité Debian qui publie les correctifs. Ensuite, le relais est pris par l'équipe LTS (Long Term Support) jusqu'au 30 juin 2030, soit cinq ans de couverture au total.

Un point de vocabulaire qui fait perdre du temps à beaucoup d'administrateurs : une version ponctuelle comme la 13.6 n'est pas une nouvelle version de Debian. C'est une republication des images avec les paquets mis à jour depuis. Le lab le montre de façon amusante : l'image cloud installe une 13.5, mais apt-cache policy annonce déjà l'archive en v=13.6, et base-files figure dans la liste des paquets à mettre à jour. Autrement dit, un simple apt upgrade vous amène en 13.6. Rien à voir avec le saut de Bookworm vers Trixie, qui, lui, est une montée de version majeure.

Les versions livrées par Trixie

Le tableau ci-dessous compare les briques que vous manipulez le plus sur un serveur, entre Debian 12 et Debian 13. Lisez-le comme une liste de choses à retester : chaque saut de version majeure est un risque de régression de configuration, surtout sur les serveurs web et les bases de données. Les valeurs en gras dans la colonne Debian 13 sont celles relevées dans la VM du lab, les autres viennent des notes de publication.

Composant	Debian 12 (Bookworm)	Debian 13 (Trixie)
Noyau Linux	6.1.0-50-amd64	6.12.95+deb13-amd64
systemd	252	257 (`257.13-1~deb13u1`)
OpenSSH	9.2p1	10.0p2 (paquet `1:10.0p1-7+deb13u4`)
APT	2.6	3.0.3
dpkg	1.21	1.22.22
coreutils	9.1	9.7 (GNU)
sudo	1.9.13	1.9.16p2
util-linux	2.38	2.41
AppArmor	3.0	4.1.0
nginx	1.22	1.26.3
PostgreSQL	15	17
MariaDB	10.11	11.8
Python	3.11	3.13
PHP	8.2	8.4
OpenSSL	3.0	3.5

Deux détails de lecture. Le noyau est de la série 6.12 LTS, mais le numéro exact (6.12.95) bouge à chaque version ponctuelle : ne le figez pas dans vos documents d'exploitation. Et OpenSSH déroute en audit : le paquet s'appelle 1:10.0p1-7+deb13u4 alors que ssh -V répond OpenSSH_10.0p2. Le saut PostgreSQL 15 vers 17 et MariaDB 10.11 vers 11.8 demandent le plus d'attention : une base de données ne se migre pas à l'aveugle.

Les architectures matérielles

Trixie ajoute riscv64 à la liste des architectures officiellement prises en charge, une première. À l'inverse, mipsel et mips64el sont retirées, et armel vit sa dernière version : Trixie est la dernière Debian à le prendre en charge.

Le cas i386 mérite une correction, car il circule beaucoup d'approximations. i386 n'est pas supprimé de Debian 13. Ce qui disparaît, c'est le noyau officiel et l'installateur i386. L'architecture reste disponible en multiarch, c'est-à-dire pour faire tourner des binaires 32 bits sur un système amd64, ou dans un chroot. C'est même devenu sa seule raison d'être. La consigne officielle est nette : les utilisateurs de systèmes i386 ne doivent pas mettre à niveau vers Trixie, Debian recommande de réinstaller en amd64.

Ce qui change pour un serveur

Voici le cœur du sujet. La plupart des articles sur Trixie listent les nouveautés du bureau. Sur un serveur, ce sont d'autres choses qui vous réveillent la nuit : un répertoire temporaire qui mange la RAM, un tuning noyau silencieusement ignoré, et des outils d'audit qui n'existent plus.

/tmp devient un disque en mémoire

C'est le changement le plus visible. Par défaut, /tmp est monté en tmpfs, un système de fichiers en mémoire vive. Sa taille est plafonnée à 50 % de la mémoire de la machine. Attention au sens du mot plafond : c'est un maximum, pas une réservation. La RAM n'est consommée qu'à mesure que des fichiers sont écrits. Sur la VM du lab, dotée de 2 Go de RAM, cela donne 987 Mo :

findmnt /tmp
df -h /tmp

TARGET SOURCE FSTYPE OPTIONS
/tmp   tmpfs  tmpfs  rw,nosuid,nodev,size=1010472k,nr_inodes=1048576,inode64

Filesystem      Size  Used Avail Use% Mounted on
tmpfs           987M     0  987M   0% /tmp

Ce chiffre dépend de votre RAM, ne le recopiez pas comme une constante. Ce qui compte, c'est d'où il vient : aucune ligne tmp n'existe dans /etc/fstab (le fichier des montages persistants au démarrage). C'est systemd qui décide, via l'unité tmp.mount, dont l'option de taille est écrite en dur :

Options=mode=1777,strictatime,nosuid,nodev,size=50%,nr_inodes=1m

L'impact serveur est réel. Un job qui déposait un dump SQL de 40 Go dans /tmp sur une machine à 32 Go de RAM fonctionnait très bien en Bookworm ; il échouera en Trixie. Et un redémarrage vide désormais /tmp intégralement. Le lab l'a vérifié en déposant un fichier témoin avant un vrai reboot :

APRES REBOOT :
ls: cannot access '/tmp/temoin-avant-reboot': No such file or directory
[/tmp rc=2]
-rw-r--r-- 1 root root 26 Jul 12 21:12 /var/tmp/temoin-avant-reboot
[/var/tmp rc=0]

/tmp est vidé, /var/tmp survit. Point capital pour les serveurs existants : la bascule s'applique aussi aux machines migrées, ce que beaucoup d'articles laissent croire réservé aux installations neuves. Sur la Debian 12 du lab, migrée en 13, le témoin déposé dans /tmp juste avant le reboot de migration avait lui aussi disparu, et findmnt /tmp répond tmpfs. Un serveur qui écrivait de gros fichiers temporaires dans /tmp se retrouve donc, après migration, à les écrire en RAM.

Sur une machine mise à niveau, les anciens fichiers de /tmp ne sont pas effacés : ils sont masqués par le nouveau montage. Le journal de démarrage le signale d'ailleurs par un message explicite, tmp.mount: Directory /tmp to mount over is not empty, mounting anyway. Pour les récupérer :

# Monter la racine réelle ailleurs pour voir sous le tmpfs
sudo mount --bind / /mnt
ls /mnt/tmp          # les anciens fichiers sont ici
sudo umount /mnt

Trois façons d'adapter ce comportement, selon ce que vous voulez. Pour agrandir le tmpfs, on édite l'unité systemd avec systemctl edit :

sudo systemctl edit tmp.mount

[Mount]
Options=mode=1777,nosuid,nodev,size=2G

Pour revenir à un /tmp sur disque, on masque l'unité, puis on redémarre. Le lab a validé ce retour en arrière, et c'est une bonne nouvelle : la manipulation est réversible et tient dans le temps.

sudo systemctl mask tmp.mount
sudo reboot

APRES REBOOT avec tmp.mount masque :
[findmnt rc=1]
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        16G  937M   14G   7% /
ext2/ext3

findmnt ne trouve plus de point de montage, stat -fc "%T" /tmp répond ext2/ext3 : /tmp est bien revenu sur le disque. Un fichier témoin déposé ensuite a survécu à deux redémarrages consécutifs. systemctl unmask tmp.mount remet l'unité en place. Enfin, si votre serveur a déjà une partition /tmp déclarée dans /etc/fstab, vous n'êtes pas concerné : votre partition l'emporte, le tmpfs ne s'active pas.

Le nettoyage automatique de /tmp : neuve contre migrée

Le sujet connexe est la purge automatique, et c'est là que se cache un écart que personne ne documente. Sur une installation neuve, systemd-tmpfiles est configuré pour purger /tmp au bout de 10 jours et /var/tmp au bout de 30 jours. Le fichier de règles, fourni par le paquet systemd, est sans ambiguïté :

cat /usr/lib/tmpfiles.d/tmp.conf

q /tmp 1777 root root 10d
q /var/tmp 1777 root root 30d

Sur une machine migrée, ces deux lignes ne s'appliquent plus. La migration dépose un fichier /etc/tmpfiles.d/tmp.conf d'une seule ligne, et comme il porte le même nom qu'un fichier de /usr/lib, il le remplace intégralement au lieu de le compléter. La commande qui donne la configuration effective ne renvoie plus que ceci :

systemd-analyze cat-config tmpfiles.d/tmp.conf

D /tmp 1777 root root -

Trois conséquences à comprendre. D'abord, l'absence de durée (-) désactive la purge par âge sur /tmp. Ensuite, la règle des 30 jours sur /var/tmp disparaît avec, puisque le fichier entier est masqué. Enfin, ce fichier n'appartient à aucun paquet (dpkg -S ne trouve rien) : il est écrit par les scripts de maintenance pendant la migration, exactement comme l'annoncent les notes de systemd affichées pendant le full-upgrade (« This override will be automatically provided for upgrades of existing systems »). C'est donc un choix délibéré de Debian, pas un bug. Supprimez ce fichier si vous voulez aligner votre serveur migré sur le comportement d'une installation neuve.

/etc/sysctl.conf n'est plus lu, et le piège est double

Celui-là est le plus dangereux de Trixie, parce qu'il échoue en silence et qu'il résiste à votre test de vérification. Premier fait : sur une Debian 13 neuve, /etc/sysctl.conf n'existe même pas, et aucun paquet ne le fournit.

ls -la /etc/sysctl.conf
dpkg -S /etc/sysctl.conf

ls: cannot access '/etc/sysctl.conf': No such file or directory
dpkg-query: no path found matching pattern /etc/sysctl.conf

Deuxième fait : si vous le créez à la main, il est ignoré au démarrage. Le lab a écrit net.ipv4.ip_forward=1 dans ce fichier, puis a réellement redémarré la VM :

APRES REBOOT, /etc/sysctl.conf contient :
net.ipv4.ip_forward=1
valeur reelle du noyau :
0

Le fichier est là, le réglage est dedans, et le noyau est resté à 0. Le service systemd-sysctl.service est pourtant active (exited) et se termine sans la moindre erreur : il n'a simplement jamais regardé ce fichier. Le même réglage placé dans /etc/sysctl.d/99-local.conf, après un redémarrage vérifié, donne bien 1. Et sur la Debian 12 témoin, le même /etc/sysctl.conf survit au reboot : la rupture est bien introduite par Trixie.

Troisième fait, et c'est la trouvaille qui rend ce piège vicieux : sysctl --system continue, lui, de lire /etc/sysctl.conf.

sudo sysctl --system

* Applying /usr/lib/sysctl.d/10-coredump-debian.conf ...
* Applying /usr/lib/sysctl.d/50-default.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /etc/sysctl.conf ...

Relisez la dernière ligne. Votre test manuel réussit, la valeur est appliquée, tout semble normal. Seul le redémarrage révèle que le réglage est perdu. C'est exactement ce qui fait qu'un tuning réseau survit à la recette et meurt au premier reboot de maintenance, six mois plus tard, quand plus personne ne fait le lien.

À la migration, le piège se double d'une disparition. Le paquet procps déclare /etc/sysctl.conf comme conffile obsolète et le renomme, en deux lignes noyées au milieu des 3 475 lignes de la sortie du full-upgrade :

Setting up procps (2:4.0.4-9) ...
Installing new version of config file /etc/sysctl.d/README.sysctl ...
Obsolete conffile /etc/sysctl.conf has been modified by you.
Saving as /etc/sysctl.conf.dpkg-bak ...

Après la migration, /etc/sysctl.conf n'existe plus, son contenu est dans /etc/sysctl.conf.dpkg-bak, et le noyau est revenu à la valeur par défaut. Votre tuning est donc perdu deux fois : il n'est plus lu, et il n'est plus là où vous le cherchez. La correction se fait avant de migrer, et elle prend trois commandes :

# 1. Voir ce que vous avez réellement à récupérer
grep -v -e '^#' -e '^$' /etc/sysctl.conf

# 2. Le déplacer dans le répertoire réellement lu par systemd
sudo cp /etc/sysctl.conf /etc/sysctl.d/99-local.conf

# 3. Recharger, puis vérifier un paramètre précis
sudo sysctl --system
sysctl net.ipv4.ip_forward

La vraie validation, elle, se fait après le prochain redémarrage : rejouez sysctl net.ipv4.ip_forward (ou le paramètre qui compte pour vous) et comparez. Tant que vous n'avez pas rebooté, vous n'avez rien prouvé.

last, lastb et lastlog sont supprimées, et les remplaçants ne sont pas là

Trixie supprime last, lastb et lastlog. Ce n'est pas un caprice : les formats de fichiers wtmp, btmp et lastlog stockent les dates sur 32 bits et ne survivent pas à l'an 2038. Debian a préféré les retirer plutôt que de les laisser mentir. La racine du choix est visible dans la build de systemd livrée par Trixie, marquée -UTMP : le support du format historique n'y est plus compilé.

Sur l'image cloud du lab, les trois commandes répondent la même chose, avec le code de retour 127 :

$ last
bash: line 1: last: command not found      [rc=127]
$ lastb
bash: line 1: lastb: command not found     [rc=127]
$ lastlog
bash: line 1: lastlog: command not found   [rc=127]

Le point que la documentation officielle escamote, et que le lab établit : wtmpdb et lastlog2 ne sont pas installés. Ils existent bien dans trixie/main, mais apt-cache policy répond Installed: (none) et les commandes sont introuvables elles aussi. Sur une machine neuve, il n'y a donc aucun remplaçant en place. Seul lslogins (fourni par util-linux) est présent.

Le fait qui compte vraiment, c'est ce que devient une tentative de connexion en échec. Le lab a provoqué un vrai échec d'authentification SSH dans la VM. Le journal systemd le voit :

sshd-session[2654]: Failed password for root from 127.0.0.1 port 55252 ssh2

Et juste après cet échec, /var/log/btmp fait toujours 0 octet, daté du jour de construction de l'image, tandis que lslogins --failed affiche la colonne FAILED-LOGIN vide pour tous les comptes. Conclusion sans détour : l'échec de connexion n'est enregistré nulle part, sauf dans le journal systemd. Un serveur dont la détection de force brute reposait sur la lecture de btmp ou sur lastb a perdu sa source de données en silence. Si c'est votre cas, votre détection passe désormais par les journaux systemd et par un outil comme fail2ban, qui lit le journal.

Curiosité mesurée au passage : /var/log/wtmp continue d'être écrit (il grossit à chaque connexion) alors qu'aucune commande du système de base ne sait plus le lire. Et /var/lib/wtmpdb/wtmp.db est déjà présent, sous forme de lien symbolique vers une cible qui n'existe pas tant que wtmpdb n'est pas installé.

Si vos scripts d'audit s'appuient sur les anciennes commandes, installez explicitement les remplaçants :

sudo apt install wtmpdb libpam-wtmpdb lastlog2 libpam-lastlog2

Les modules PAM ne sont pas facultatifs, et c'est le détail qui fait perdre une soirée : sans libpam-wtmpdb et libpam-lastlog2, les commandes s'installent mais plus rien n'alimente leur base. Vous obtenez un outil qui fonctionne et qui n'affiche rien. Les notes de publication le précisent pour chacun des deux paquets.

Commande retirée	Remplacement	Paquets à installer	Usage
`last`	`wtmpdb last`	`wtmpdb` et `libpam-wtmpdb`	Historique des connexions
`lastb`	`lslogins --failed`	déjà présent (`util-linux`)	Tentatives de connexion échouées
`lastlog`	`lastlog2` ou `lslogins`	`lastlog2` et `libpam-lastlog2`	Dernière connexion par compte

La transition 64-bit time_t

C'est le chantier de fond derrière la suppression ci-dessus. Toutes les architectures sauf i386 utilisent désormais une ABI time_t sur 64 bits, ce qui règle le problème de l'an 2038 (date au-delà de laquelle un compteur de secondes 32 bits déborde).

Ce que ça implique pour vous, très concrètement : sur amd64 et arm64, il n'y a rien à faire, tous les paquets Debian ont été recompilés. Le risque réel se situe sur armhf et armel, avec des binaires tiers non recompilés : ils peuvent provoquer des pertes de données silencieuses. Si vous faites tourner du logiciel propriétaire ou compilé maison sur du matériel ARM 32 bits, c'est le point à traiter en priorité avec l'éditeur.

Le format deb822, et la disparition d'apt-key

Debian recommande désormais le format deb822 pour les dépôts APT : un fichier /etc/apt/sources.list.d/debian.sources avec des champs explicites (Types, URIs, Suites, Components, Signed-By), plutôt que le format une-ligne historique de sources.list.

Soyons précis, parce que beaucoup d'articles exagèrent : le format une-ligne est déprécié mais pas supprimé. La page de manuel de Trixie dit qu'il pourrait être retiré à terme, mais pas avant 2029. Vous n'êtes donc pas obligé de migrer vos sources aujourd'hui. C'est une bonne pratique, pas une urgence. Le détail du format et de la gestion des clés est traité dans le guide administrer les paquets avec APT.

En revanche, une commande a bel et bien disparu : apt-key. Le lab est catégorique, elle n'existe plus et aucun paquet ne la fournit :

$ command -v apt-key                       [rc=1]
$ apt-key --version
bash: line 1: apt-key: command not found   [rc=127]
$ dpkg -S /usr/bin/apt-key
dpkg-query: no path found matching pattern /usr/bin/apt-key

Tout tutoriel qui commence par curl ... | sudo apt-key add - est donc mort sur Debian 13. Les clés vivent maintenant dans /etc/apt/trusted.gpg.d/*.asc et /usr/share/keyrings/. Détail de trousseau utile en dépannage : les fichiers en .gpg de /usr/share/keyrings/ sont désormais des liens symboliques vers les nouveaux fichiers .pgp canoniques. Vos anciens Signed-By continuent donc de fonctionner sans modification.

Qui patche quoi : tout ce qui compte est dans main

L'archive Debian est découpée en composants : main, contrib, non-free et non-free-firmware. Seul le contenu de la distribution officielle est suivi par l'équipe de sécurité Debian, et cette frontière a des conséquences très concrètes. La question à se poser est simple : les paquets que vous installez vraiment sur un serveur sont-ils couverts ? Elle mérite des mesures, pas une opinion.

Les dépôts de l'image cloud

Sur l'image cloud Debian 13, les sources tiennent en deux strophes deb822, et la ligne à lire est Components: :

Types: deb deb-src
URIs: mirror+file:///etc/apt/mirrors/debian.list
Suites: trixie trixie-updates trixie-backports
Components: main

Types: deb deb-src
URIs: mirror+file:///etc/apt/mirrors/debian-security.list
Suites: trixie-security
Components: main

Trois informations utiles ici. Le composant main est le seul déclaré : ni contrib, ni non-free-firmware. Le dépôt de sécurité trixie-security est configuré par défaut, vous n'avez rien à ajouter. Et trixie-backports est activé par défaut sur cette image, ce que personne n'annonce : les paquets de backports y sont visibles avec une priorité de 100, donc jamais installés sans demande explicite, mais ils apparaissent dans apt-cache policy et peuvent surprendre. La forme mirror+file: des URIs est une indirection propre aux images cloud : APT lit la liste des miroirs dans un fichier local plutôt que de coder une URL en dur.

Le test sur cinq paquets serveur

Pour passer de la théorie à la mesure, le lab a interrogé apt-cache policy sur cinq paquets qu'on retrouve sur la plupart des serveurs : un moteur de conteneurs, un cache mémoire, un anti force-brute, un client de certificats et un serveur web. Le résultat est net :

Paquet	Version dans Trixie	Dépôt qui le sert
`docker.io`	26.1.5+dfsg1-9+b13	`trixie/main`
`redis`	5:8.0.2-3+deb13u2	`trixie/main` et `trixie-security/main`
`fail2ban`	1.1.0-8	`trixie/main`
`certbot`	4.0.0-2+deb13u1	`trixie/main`
`nginx`	1.26.3-3+deb13u7	`trixie/main` et `trixie-security/main`

Les cinq paquets sont dans main, donc tous couverts par l'équipe de sécurité Debian, sans dépôt à ajouter ni composant à activer. Et ce n'est pas théorique : redis et nginx sont effectivement servis par trixie-security, la preuve qu'un correctif de sécurité y est réellement publié pour eux. Concrètement, une stack Docker plus Redis plus fail2ban installée depuis l'archive est couverte d'office, pendant toute la durée de support de la version.

La nuance d'honnêteté à ne pas escamoter

Une affirmation circule beaucoup : « l'équipe de sécurité Debian couvre toute l'archive ». Elle est fausse, et la FAQ sécurité officielle de Debian le dit noir sur blanc : contrib, non-free et non-free-firmware ne font pas partie de la distribution publiée et ne sont pas couverts par l'équipe de sécurité.

Ce qui est vrai, et qui suffit largement, tient en une phrase : tout ce qui compte pour un serveur est dans main. Le raccourci « Debian couvre tout » est une facilité de langage qui vous exposera le jour où vous activerez contrib pour un pilote ou un firmware propriétaire. Attention d'ailleurs à la portée de la mesure : l'image cloud n'active que main, mais l'installateur Debian, lui, active non-free-firmware par défaut. Vérifiez vos propres sources plutôt que de généraliser.

Rien à activer, un seul outil d'audit à connaître

La couverture de main est acquise d'office : Debian ne propose aucune souscription, aucun enregistrement de machine, aucune commande d'activation pour débloquer des correctifs. Le dépôt trixie-security est déjà déclaré dans les sources, et il sert l'intégralité de main.

L'outil à connaître pour auditer cette couverture est debian-security-support, et il est absent par défaut. Une fois installé, check-support-status sort vide avec un code 0 sur l'image minimale du lab, autrement dit : aucun paquet à support limité ou terminé. Sur un serveur chargé de paquets, la sortie sera plus intéressante, et c'est une commande à ajouter à votre routine d'audit.

sudo apt install debian-security-support
sudo check-support-status

Ce que la machine envoie sur le réseau

Sur une infrastructure cloisonnée ou soumise à une revue de conformité, tout flux sortant non déclaré est un point d'audit. La question mérite donc une mesure, pas une opinion. Le lab a lancé tcpdump dans la VM, en excluant sa propre session SSH de pilotage, sur deux fenêtres de 30 secondes.

Fenêtre de capture	Paquets capturés (hors SSH)
Contrôle, machine au repos	0
Pendant 3 connexions SSH avec session complète	2

Les deux seuls paquets de la seconde fenêtre, sortie brute intégrale :

21:11:18.634727 enp0s2 Out IP 10.0.2.15.37877 > 82.64.55.167.123: NTPv4, Client, length 48
21:11:18.651608 enp0s2 In  IP 82.64.55.167.123 > 10.0.2.15.37877: NTPv4, Server, length 48

Du NTP, et rien d'autre. Zéro requête DNS, zéro poignée de main TLS, zéro paquet vers un domaine nommé. À la connexion, Debian n'appelle personne. Le paquet popularity-contest, qui remonte des statistiques d'usage, n'est pas installé sur l'image cloud.

Deux choses à dire quand même, par honnêteté. D'abord, unattended-upgrades 2.12 est installé et actif : la machine contacte donc deb.debian.org quotidiennement via apt-daily.timer. Ce n'est pas de la télémétrie (aucune donnée sur votre machine n'est transmise), mais c'est bien du trafic sortant, autant le savoir. Ensuite, /etc/update-motd.d/ existe et contient deux scripts, 10-uname et 92-unattended-upgrades : leurs noms disent leur périmètre, et la capture réseau confirme qu'ils ne parlent à personne.

Si vous devez justifier vos flux sortants devant un auditeur, la liste est donc courte : du NTP, et le passage quotidien d'APT sur deb.debian.org. Et elle se vérifie en une commande tcpdump sur votre propre machine.

Du GNU partout, et pas de pare-feu

Deux traits de caractère de Trixie méritent d'être connus avant d'écrire vos scripts de déploiement : ce que la distribution n'a pas changé, et ce qu'elle n'active pas.

sudo et coreutils restent du GNU

Debian 13 livre sudo en C (1.9.16p2), le binaire setuid historique, et GNU coreutils 9.7 sur les dix binaires testés (ls, cp, mv, rm, cat, sort, wc, df, true, false). Aucune asymétrie, aucune surprise.

Le fait notable est ailleurs : sudo-rs et rust-coreutils, les réécritures en Rust de ces outils, existent bien dans main, mais ils répondent Installed: (none). Debian les package sans les installer : le userland par défaut reste GNU, et vos scripts, vos invites sudo et vos automatisations se comportent exactement comme en Bookworm. Sur ce terrain, il n'y a rien de nouveau à retester.

Aucun pare-feu, pas même installé

C'est un point à traiter dès la première heure d'un serveur. Sur l'image cloud Debian 13, il n'y a aucun pare-feu, et pas seulement au sens « désactivé » : nftables, ufw et firewalld ne sont jamais installés, et nft répond command not found. iptables est présent, avec zéro règle et des politiques en ACCEPT :

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

La réserve vaut d'être posée : ce constat porte sur l'image cloud, celle qu'on déploie en pratique chez un hébergeur, et non sur l'installateur ISO. La conclusion opérationnelle, elle, ne change pas : le filtrage est à votre charge, et c'est la première chose à poser sur un serveur exposé. La marche à suivre est dans le guide nftables.

Le contrôle d'accès obligatoire (MAC) est en revanche bien présent : AppArmor 4.1.0 est actif, avec 106 profils chargés et 7 en mode enforce sur l'image neuve. AppArmor confine les programmes par chemin de fichier, à partir de profils texte lisibles ; c'est le modèle historique de Debian, et il n'y a pas de SELinux sur cette image (getenforce et sestatus sont absents). Le guide AppArmor détaille son fonctionnement. Dernier point de contexte, utile pour les conteneurs : Trixie est en cgroup v2 exclusivement (stat -fc %T /sys/fs/cgroup répond cgroup2fs), même si le noyau expose toujours l'ancienne interface dans /proc/filesystems.

Migrer depuis Debian 12

La montée de version Debian est réputée fiable, et elle l'est, à condition de suivre l'ordre officiel. La plupart des migrations qui tournent mal viennent d'une étape sautée en amont, pas d'un bug de Debian. La séquence complète a été rejouée en VM dans le lab, jusqu'au redémarrage et au retour du réseau.

Préparer la migration

Ces vérifications ne sont pas décoratives : chacune correspond à un mode d'échec constaté. Consacrez-y le temps nécessaire, c'est là que se joue le succès de l'opération.

Partir d'une Debian 12 complètement à jour. Les sauts de version (12 vers 14, par exemple) ne sont pas pris en charge.
Fenêtre de terminal
```
cat /etc/debian_version     # doit afficher 12.x
sudo apt update && sudo apt upgrade
```
Sauvegarder ce qui compte. En plus de votre sauvegarde système habituelle, Debian demande explicitement /etc, /var/lib/dpkg, /var/lib/apt/extended_states et la liste des paquets sélectionnés.
Fenêtre de terminal
```
dpkg --get-selections '*' > /root/paquets-avant-migration.txt
sudo tar czf /root/etc-avant-migration.tar.gz /etc /var/lib/dpkg /var/lib/apt/extended_states
```
Mettre le tuning noyau à l'abri. C'est le piège documenté plus haut : recopiez /etc/sysctl.conf dans /etc/sysctl.d/99-local.conf maintenant, pendant qu'il existe encore.
Fenêtre de terminal
```
grep -v -e '^#' -e '^$' /etc/sysctl.conf
sudo cp /etc/sysctl.conf /etc/sysctl.d/99-local.conf
```
Retirer les backports et l'épinglage. Les dépôts bookworm-backports et proposed-updates doivent sortir des sources, et l'épinglage (pinning) de /etc/apt/preferences* doit être désactivé. Ils fausseraient le calcul de dépendances.
Inventorier ce qui ne vient pas de Debian. Les paquets tiers sont la première cause de migration bloquée, et les paquets obsolètes la première cause de surprise ensuite.
Fenêtre de terminal
```
apt list '?narrow(?installed, ?not(?origin(Debian)))'
apt list '?obsolete'
```
Lever les blocages et vérifier l'état de dpkg. Un paquet en hold ou une installation à moitié terminée fait échouer la montée de version. Estimez aussi l'espace disque : Debian ne donne aucun chiffre absolu, sauf pour /boot, qui doit compter au moins 768 Mo, dont 300 Mo libres.
Fenêtre de terminal
```
sudo dpkg --audit
apt-mark showhold
df -h /boot /var /
```
Travailler sous screen ou tmux. Une coupure SSH pendant un full-upgrade laisse le système dans un état intermédiaire. Un multiplexeur de terminal permet à la migration de continuer sans vous. Arrêtez aussi les superviseurs qui relancent les services tout seuls : monit est nommément cité par Debian.
Fenêtre de terminal
```
sudo systemctl stop monit    # si présent
tmux new -s migration
```

Trouver vos sources APT : les deux cas

C'est ici que la plupart des tutoriels vous mènent dans le mur. Ils vous disent d'éditer /etc/apt/sources.list et d'y remplacer bookworm par trixie. Sur une Debian 12 récente, ce fichier n'existe pas, ou bien il existe mais ne contient qu'un commentaire qui renvoie ailleurs (c'est le cas sur les images cloud : # See /etc/apt/sources.list.d/debian.sources). Les vraies sources sont en deb822 dans /etc/apt/sources.list.d/debian.sources. Un sed lancé sur le mauvais fichier échoue en silence, et vous croyez avoir basculé vos sources alors que rien n'a changé.

Commencez donc toujours par regarder ce que vous avez réellement :

ls -l /etc/apt/sources.list 2>&1
ls -l /etc/apt/sources.list.d/
cat /etc/apt/sources.list.d/*.sources 2>/dev/null

Sources deb822
Serveur hérité

Sortie observée sur la Debian 12 du lab :

ls: cannot access '/etc/apt/sources.list': No such file or directory
---
total 4
-rw-r--r-- 1 root root 443 Jun 23 00:00 debian.sources

Le fichier debian.sources contient des strophes de ce type :

Types: deb
URIs: http://deb.debian.org/debian
Suites: bookworm bookworm-updates
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

La bascule consiste à changer les Suites:, pas le nom du fichier :

sudo cp /etc/apt/sources.list.d/debian.sources /root/debian.sources.bak
sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/debian.sources
grep -E 'Suites|URIs' /etc/apt/sources.list.d/debian.sources

Résultat attendu :

URIs: http://deb.debian.org/debian
Suites: trixie trixie-updates
URIs: http://deb.debian.org/debian-security
Suites: trixie-security

Si /etc/apt/sources.list existe et contient des lignes deb, vous êtes sur un serveur au format une-ligne historique :

deb http://deb.debian.org/debian bookworm main
deb http://deb.debian.org/debian bookworm-updates main
deb http://deb.debian.org/debian-security bookworm-security main

La bascule s'y fait de la même manière, sur le bon fichier :

sudo cp /etc/apt/sources.list /root/sources.list.bak
sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
grep -v '^#' /etc/apt/sources.list

Attention à un détail de nommage : le dépôt de sécurité de Bookworm s'appelait bookworm-security, celui de Trixie s'appelle trixie-security. Un sed global sur bookworm traite les deux d'un coup.

Une fois les sources basculées, rafraîchissez l'index. La sortie doit mentionner trixie, c'est votre confirmation que la bascule a bien été prise en compte :

sudo apt update

Get:4 http://deb.debian.org/debian trixie/main amd64 Packages [9673 kB]
Get:5 http://deb.debian.org/debian trixie-updates/main amd64 Packages [5412 B]
Get:6 http://deb.debian.org/debian-security trixie-security/main amd64 Packages [225 kB]
Fetched 10.1 MB in 2s (5165 kB/s)

Étape 1 : la mise à niveau minimale

Debian impose deux temps, et le premier n'est pas un apt upgrade nu. Le drapeau --without-new-pkgs est explicite dans les notes de publication : il met à jour les paquets déjà installés sans en installer de nouveaux ni en retirer. Cette étape prudente réduit la taille de la transaction et limite les risques d'un système à moitié migré.

sudo apt upgrade --without-new-pkgs

Étape 2 : full-upgrade

Le second temps est apt full-upgrade (et non dist-upgrade, l'ancien nom encore présent partout sur le web). Cette commande autorise les installations et les retraits de paquets, ce qui est indispensable pour faire aboutir le changement de version.

sudo apt full-upgrade

C'est l'étape longue, et bavarde : dans le lab, elle produit 3 475 lignes de sortie. Elle pose des questions sur les fichiers de configuration modifiés (dpkg vous demande de garder votre version ou de prendre celle du mainteneur) : dans le doute, gardez votre version et comparez ensuite avec le fichier .dpkg-dist déposé à côté. Surtout, relisez cette sortie ou conservez-la dans un fichier : c'est là, et nulle part ailleurs, que dpkg vous annonce le déplacement de /etc/sysctl.conf. Si la transaction bute sur un conflit, le guide réparer des dépendances cassées donne la marche à suivre.

À l'issue de l'opération, mais avant le redémarrage, le système annonce déjà Trixie tout en faisant encore tourner l'ancien noyau :

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
VERSION_ID="13"
systemd 257 (257.13-1~deb13u1)

uname -r

6.1.0-50-amd64

Cette dissonance est normale : le nouveau noyau est installé mais pas encore chargé. C'est précisément ce que le redémarrage va corriger.

Le redémarrage, validé de bout en bout

Le redémarrage n'est pas une formalité : c'est lui qui active le nouveau noyau, le tmpfs sur /tmp, et les éventuels nouveaux noms d'interfaces réseau. C'est le moment où les problèmes non anticipés se manifestent, et où l'accès distant peut être perdu. C'est aussi ce que le lab en conteneur ne pouvait pas tester, et que la VM a permis de valider.

Juste avant le reboot, les deux noyaux cohabitent, tirés par le métapaquet linux-image-amd64 :

ii  linux-image-6.1.0-50-amd64        6.1.176-1    amd64
ii  linux-image-6.12.95+deb13-amd64   6.12.95-1    amd64
ii  linux-image-amd64                 6.12.95-1    amd64

L'initramfs du nouveau noyau a bien été régénéré (/boot/initrd.img-6.12.95+deb13-amd64, 37 174 750 octets), et GRUB a été réinstallé pendant la migration, avec un nouveau /etc/default/grub :

Setting up linux-image-6.12.95+deb13-amd64 (6.12.95-1) ...
update-initramfs: Generating /boot/initrd.img-6.12.95+deb13-amd64
Generating grub configuration file ...
Installing for i386-pc platform.
Installation finished. No error reported.

Avant de taper reboot, assurez-vous d'avoir un accès console (KVM, IPMI, console du fournisseur cloud) : c'est votre seul filet si le réseau ne remonte pas. Puis validez au retour :

sudo reboot

# Après redémarrage, les quatre vérifications qui comptent
cat /etc/debian_version      # 13.x
uname -r                     # nouveau noyau de la série 6.12
findmnt /tmp                 # doit montrer tmpfs
systemctl --failed           # aucun service en échec attendu

Dans le lab, la machine est revenue proprement : uname -r affiche 6.12.95+deb13-amd64, /etc/debian_version passe à 13.6, l'interface enp0s2 reprend son adresse, la résolution DNS fonctionne, apt update repasse en Hit: sur trixie-security, et systemctl --failed liste 0 unité. Les deux seules erreurs du journal de démarrage concernent systemd-ssh-generator, qui cherche un canal de communication de machine virtuelle absent : c'est bénin et propre à l'environnement de test.

Après la migration : nettoyer et moderniser

Une migration laisse des traces. Les paquets obsolètes sont des bibliothèques de Debian 12 qui n'existent plus dans Trixie mais restent installées, faute de quelqu'un pour les retirer. La VM du lab en comptait 15, dont l'ancien noyau. En voici cinq :

apt list '?obsolete'

libapt-pkg6.0/now 2.6.1 amd64 [installed,local]
libicu72/now 72.1-3+deb12u1 amd64 [installed,local]
libnetplan0/now 0.106-2+deb12u1 amd64 [installed,local]
linux-image-6.1.0-50-amd64/now 6.1.176-1 amd64 [installed,local]
python3.11/now 3.11.2-6+deb12u8 amd64 [installed,local]

Ce motif de recherche '?obsolete' fait partie des patterns APT, peu connus et très utiles. Complétez avec apt autoremove, qui proposera de retirer les dépendances devenues inutiles (32 paquets dans le lab, dont tout l'ancien python3.11). Relisez la liste avant de valider : autoremove est une commande qui mérite qu'on lui prête attention, surtout juste après une montée de version.

C'est aussi le moment de moderniser vos sources, si vous le souhaitez. APT 3.0 apporte apt modernize-sources, qui convertit le format une-ligne en deb822. Elle n'existe pas en Debian 12 (E: Invalid operation), elle n'est donc utilisable qu'après la migration.

sudo apt modernize-sources

La commande est interactive et demande confirmation. Répondre N donne une simulation, ce qui est le bon réflexe pour un premier passage :

This command supports the 'signed-by' and 'trusted' options. If you
have specified other options inside [] brackets, please transfer them
manually to the output files; see sources.list(5) for a mapping.

For a simulation, respond N in the following prompt.
Rewrite 1 sources? [Y/n] Y
Modernizing /etc/apt/sources.list...
- Writing /etc/apt/sources.list.d/debian.sources

Trois comportements à connaître, observés en lab. Elle écrit une strophe par ligne d'origine (elle ne fusionne pas les suites), elle sauvegarde l'original en .list.bak, et elle déduit Signed-By toute seule. Surtout, elle avertit que les options entre crochets autres que signed-by et trusted ne sont pas transférées : si vos dépôts tiers portent des options comme arch=, reportez-les à la main. Sur des sources déjà en deb822, elle répond simplement All sources are modern.

Les pièges qui coupent la production

Voici les scénarios qui transforment une migration de routine en incident. Ils ont un point commun : ils se préparent avant le redémarrage, et se réparent très difficilement après, parfois seulement depuis la console physique.

Le nom des interfaces réseau peut changer

C'est le piège le plus brutal : la machine redémarre, tout va bien, mais elle n'a plus de réseau. La cause est un changement de nom d'interface : votre configuration cible enp3s0 alors que le système présente désormais un autre nom, donc l'interface ne se configure pas.

Deux cas sont documentés par Debian. Le pilote de carte réseau i40e (cartes Intel, très fréquent en serveur), et les firmwares qui exposent l'objet ACPI _SUN : cet objet était ignoré par systemd 252 et il est pris en compte par systemd 257, ce qui suffit à changer le nom calculé.

Soyons honnête sur ce point précis : le lab n'a pas pu reproduire ce renommage. QEMU n'expose pas d'objet _SUN, il n'y a donc rien à ignorer en 252 ni à prendre en compte en 257, et l'interface s'est appelée enp0s2 avant comme après la migration. Ce qui suit est donc la procédure officielle, pas du vécu. Elle reste la seule parade connue, et elle ne coûte rien.

La vérification se fait avant le redémarrage, en demandant à udev de simuler le nommage. Comparez la valeur ID_NET_NAME retournée avec le nom actuel de l'interface :

# Remplacez eth0 par le nom actuel de votre interface (ip -br link)
udevadm test-builtin net_setup_link /sys/class/net/eth0 2>/dev/null | grep ID_NET_NAME

Si les noms divergent, la parade est d'épingler les noms actuels avec des fichiers systemd.link, avant de migrer. Détail rassurant relevé dans le lab : sur une image cloud, le nom est déjà épinglé par un fichier .link généré par netplan, ce qui protège de facto du renommage. Sur une machine migrée depuis un système historique, en revanche, aucun fichier .link n'existe dans /etc/systemd/network/. Le principe et la configuration des interfaces sont détaillés dans la section réseau et le guide NetworkManager.

Le chiffrement de disque

Si votre serveur utilise des systèmes de fichiers chiffrés, le montage automatique au démarrage est désormais assuré par un paquet séparé, systemd-cryptsetup. Il est recommandé par systemd, donc normalement tiré tout seul, sauf si vous avez désactivé les paquets recommandés. S'il manque, la machine redémarre et ne monte plus les volumes chiffrés, ce qui bloque le démarrage ou fait échouer les services qui en dépendent. Debian demande explicitement de le vérifier avant le redémarrage.

sudo apt install systemd-cryptsetup

Faites-le avant le redémarrage. C'est une ligne de commande qui vous épargne un déplacement en salle machine.

MariaDB : l'arrêt propre est obligatoire

Le saut MariaDB 10.11 vers 11.8 est un changement de version majeure, et la récupération après crash entre versions majeures ne fonctionne pas. Autrement dit : si le serveur MariaDB n'a pas été arrêté proprement avant la migration, il ne redémarrera pas, et vous devrez restaurer depuis une sauvegarde.

La procédure est donc stricte : arrêter le service, puis vérifier dans les journaux que l'arrêt s'est bien terminé avant de lancer le full-upgrade.

sudo service mariadb stop
sudo journalctl -u mariadb -n 20 | grep -i "Shutdown complete"

Ne migrez pas tant que la mention Shutdown complete n'apparaît pas. La lecture des journaux systemd est ici votre garde-fou, pas une option.

OpenSSH n'accepte plus les clés DSA

Trixie livre OpenSSH 10, qui n'accepte plus les clés DSA. Le retrait est en réalité effectif depuis OpenSSH 9.8, et définitif en 10.0. Un compte de service ou un automate qui s'authentifie encore avec une clé DSA sera refusé après la migration, sans préavis. Ces clés sont anciennes et faibles, leur retrait est une bonne nouvelle, mais il faut avoir fait le tour de son parc avant.

ssh-keygen -t ed25519 -C "compte-sauvegarde@srv-prod-01"

Générez et déployez les clés Ed25519 de remplacement avant de migrer, pendant que l'ancienne authentification fonctionne encore. La méthode complète est dans le guide créer et déployer une clé SSH.

ping échoue pour les utilisateurs normaux

Symptôme déroutant : après migration, ping fonctionne en root mais échoue pour un utilisateur normal. La cause est le paramètre net.ipv4.ping_group_range, désormais fourni par le paquet linux-sysctl-defaults, qui livre /usr/lib/sysctl.d/50-default.conf. Ce paquet est recommandé par systemd, pas exigé : sur une machine où les paquets recommandés sont désactivés, la migration ne l'installe pas. Le premier réflexe est donc de vérifier sa présence avant d'écrire quoi que ce soit à la main.

sudo apt install linux-sysctl-defaults

Si vous préférez régler le paramètre vous-même, c'est un cas particulier du problème sysctl.conf évoqué plus haut, et il se traite de la même manière, dans /etc/sysctl.d/.

RabbitMQ n'a pas de chemin de migration direct

Si vous exploitez RabbitMQ, arrêtez-vous ici : il n'existe pas de chemin de migration direct depuis Bookworm. Par ailleurs, les files HA (mirrored queues) ne sont plus prises en charge, il faut passer aux quorum queues. Cette migration se planifie comme un chantier applicatif à part entière, indépendamment de la montée de version de l'OS.

Le message « System is tainted: unmerged-bin »

Au démarrage, votre serveur migré peut afficher System is tainted: unmerged-bin. La consigne officielle de Debian est claire : ignorez ce message. Ne cédez pas à la tentation de fusionner manuellement /usr/bin et /usr/sbin, cela casserait les mises à niveau suivantes. C'est un avertissement cosmétique, pas un défaut à corriger.

Dépannage

Ce tableau regroupe les symptômes les plus fréquents après une migration vers Trixie. Cherchez-y d'abord avant de partir en investigation : dans la grande majorité des cas, le coupable est un des changements de comportement documentés plus haut, pas un bug.

Symptôme	Cause probable	Solution
`sed: can't read /etc/apt/sources.list`	Sources déjà en deb822	Éditer `/etc/apt/sources.list.d/debian.sources` (champs `Suites:`)
Tuning noyau sans effet après reboot	`/etc/sysctl.conf` n'est plus lu au démarrage	Déplacer les réglages dans `/etc/sysctl.d/99-local.conf`, puis valider après un reboot
`/etc/sysctl.conf` a disparu après migration	dpkg l'a renommé en `.dpkg-bak` (conffile obsolète)	Récupérer le contenu dans `/etc/sysctl.conf.dpkg-bak` et le poser dans `/etc/sysctl.d/`
Le réglage marche en manuel mais pas au boot	`sysctl --system` lit encore `/etc/sysctl.conf`, pas `systemd-sysctl`	Ne jamais valider un sysctl sans redémarrer
Pas de réseau après reboot	Nom d'interface changé (`i40e`, ACPI `_SUN`)	Accès console, `ip -br link` pour le nouveau nom, puis épingler avec un fichier `systemd.link`
`/tmp` plein alors que le disque est libre	`/tmp` en tmpfs, plafonné à 50 % de la RAM	`systemctl edit tmp.mount` pour agrandir, ou `systemctl mask tmp.mount` pour revenir au disque
Fichiers disparus de `/tmp` après reboot	tmpfs monté par-dessus l'ancien répertoire	`sudo mount --bind / /mnt`, récupérer dans `/mnt/tmp`, puis `sudo umount /mnt`
`/tmp` n'est plus purgé sur une machine migrée	`/etc/tmpfiles.d/tmp.conf` masque le fichier de `/usr/lib`	Supprimer ce fichier pour retrouver le comportement d'une installation neuve
`last: command not found`	Commande supprimée (incompatible 2038)	`apt install wtmpdb lastlog2`, puis `wtmpdb last` ; `lslogins --failed`
`btmp` vide malgré des échecs SSH	Plus aucun outil n'écrit btmp (systemd est compilé `-UTMP`)	Lire le journal systemd ; brancher fail2ban dessus
`apt-key: command not found`	`apt-key` supprimé, aucun paquet ne le fournit	Poser la clé dans `/usr/share/keyrings/` et la déclarer en `Signed-By:`
`ping` refusé pour un utilisateur normal	`net.ipv4.ping_group_range` (paquet `linux-sysctl-defaults`)	Régler le paramètre dans `/etc/sysctl.d/`
MariaDB ne redémarre pas	Arrêt non propre avant un saut de version majeure	Restaurer depuis la sauvegarde ; prévenir avec `service mariadb stop` + `Shutdown complete` vérifié
Connexion SSH par clé refusée	Clé DSA, refusée par OpenSSH 10	Générer une clé `ed25519` et la déployer
Volume chiffré non monté	Paquet `systemd-cryptsetup` absent	`apt install systemd-cryptsetup` puis redémarrer
`System is tainted: unmerged-bin`	Répertoires `/usr/bin` et `/usr/sbin` non fusionnés	Ignorer, ne surtout pas fusionner à la main
`apt modernize-sources` : `E: Invalid operation`	Commande d'APT 3.0, absente de Debian 12	L'exécuter seulement après la migration

Anticiper Debian 14 « Forky »

Debian publie ses avertissements de dépréciation une version à l'avance. Traiter ces points dès maintenant, pendant que Trixie les prend encore en charge, vous évitera de les découvrir dans l'urgence lors du prochain saut.

Quatre points concernent directement les serveurs :

sudo-ldap sera retiré. Si votre élévation de privilèges passe par LDAP, migrez vers libsss-sudo, le greffon sudo de SSSD. Ne pas le faire, c'est perdre sudo sur toute la flotte au prochain redémarrage.
lxd n'est plus mis à jour. Le successeur soutenu par Debian est incus, un fork de LXD. Planifiez la bascule de vos conteneurs système.
isc-dhcp est obsolète. Le remplaçant est Kea, du même éditeur (ISC). Si vous exploitez un serveur DHCP, c'est le moment de préparer la conversion de configuration.
GSS-API d'OpenSSH sort des paquets principaux. Si vous vous authentifiez en Kerberos via SSH, installez openssh-server-gssapi dès Trixie.

À retenir

Debian 13 « Trixie » est publiée depuis le 9 août 2025, supportée jusqu'au 9 août 2028, puis en LTS jusqu'au 30 juin 2030. Une version ponctuelle (13.6) n'est pas une nouvelle version : vos mises à jour quotidiennes vous y amènent déjà.
/etc/sysctl.conf n'est plus lu au démarrage, et le piège est double : sysctl --system continue de le lire, donc votre test manuel réussit et seul le reboot révèle la perte. À la migration, dpkg le renomme en .dpkg-bak.
/tmp passe en tmpfs (50 % de la RAM), y compris sur une machine migrée. La purge automatique, en revanche, ne s'applique qu'aux installations neuves : la migration dépose un /etc/tmpfiles.d/tmp.conf qui masque le fichier par défaut.
last, lastb et lastlog sont supprimées, et wtmpdb/lastlog2 ne sont pas installés. Leurs modules PAM (libpam-wtmpdb, libpam-lastlog2) sont indispensables, sinon rien n'alimente la base. Après un échec SSH réel, btmp reste à 0 octet : l'échec n'existe que dans le journal systemd.
apt-key n'existe plus : aucun paquet ne le fournit. Les clés vont dans /usr/share/keyrings/, déclarées en Signed-By:.
Tout ce qui compte pour un serveur est dans main : docker.io, redis, fail2ban, certbot et nginx y sont tous, couverts par l'équipe de sécurité sans rien activer ni payer. Nuance à assumer : contrib et non-free ne sont pas couverts par l'équipe de sécurité.
Debian n'appelle personne : 0 paquet réseau au repos, 2 paquets NTP pendant trois connexions SSH, aucun domaine contacté. Le seul flux sortant régulier est le passage quotidien d'APT sur deb.debian.org, dû à unattended-upgrades.
La migration se fait en deux temps : apt upgrade --without-new-pkgs puis apt full-upgrade. Vérifiez où sont vos sources APT avant tout : sur une Debian 12 récente, tout est en deb822.
Trois précautions avant de redémarrer : OpenSSH à jour, noms d'interfaces vérifiés avec udevadm, systemd-cryptsetup installé si vous chiffrez. Et aucun pare-feu n'est installé par défaut : c'est à vous de le poser.

Sources et références

Ce guide croise un lab en machine virtuelle et les publications officielles de Debian. Les liens ci-dessous permettent de vérifier chaque affirmation à la source, ce qui est particulièrement utile avant d'engager la migration d'un parc.

Les notes de publication, qui sont la source de presque tout ce qui précède :

Points à surveiller pour Trixie : le chapitre le plus important pour un serveur. On y trouve /tmp en tmpfs, l'abandon de /etc/sysctl.conf, la suppression de last, le renommage des interfaces réseau, MariaDB, RabbitMQ et les dépréciations annoncées pour Forky.
Mise à niveau depuis Debian 12 : la procédure officielle en deux temps, les sauvegardes exigées, et le bug OpenSSH de Bookworm qui peut rendre une machine inaccessible.
Quoi de neuf dans Trixie : les architectures prises en charge, les versions livrées et la transition time_t 64 bits.
Annonce de publication de Debian 13 : la date du 9 août 2025, les cinq ans de support et l'arrivée de riscv64.

Le cycle de vie et la couverture de sécurité :

Page de la version Trixie : le cycle chiffré, trois ans de support complet puis LTS jusqu'au 30 juin 2030, et l'historique des versions ponctuelles.
Calendrier LTS : les fenêtres exactes de prise en charge longue durée, version par version.
FAQ sécurité de Debian : la source qui dit noir sur blanc que contrib, non-free et non-free-firmware ne sont pas couverts par l'équipe de sécurité. C'est la nuance que le raccourci « Debian couvre tout » escamote.

Les pages qui documentent le piège sysctl, à lire ensemble car chacune ne donne que la moitié du problème :

Page de manuel sysctl.conf(5) : « This file is not used by systemd-sysctl ».
Page de manuel sysctl(8) : --system lit pourtant /etc/sysctl.conf, en dernier. D'où un test manuel qui réussit et un réglage perdu au redémarrage.
Bug Debian #1077184 : le rapport « /etc/sysctl.conf is no longer read », fermé en wontfix, avec le témoignage d'un routeur qui perd son ip_forward au reboot. C'est un choix, pas un oubli.

Pour vérifier par vous-même :

Page de manuel sources.list(5) : le format une-ligne est déprécié mais ne sera pas retiré avant 2029. Rien ne presse.
Le paquet systemd dans Trixie : le point d'entrée pour contrôler chaque version du tableau, en changeant simplement le nom du paquet dans l'URL.
Notes de version d'OpenSSH 10.0 : le retrait définitif des clés DSA.
Communiqué de Proxmox VE 9.0 : la confirmation que Proxmox VE 9 est bâti sur Debian 13, ce qui rend ce guide directement utile aux hyperviseurs.

Prochaines étapes

Ubuntu Server 26.04 LTS Le guide frère : ce que la LTS d'Ubuntu change pour un serveur, mesurée selon le même protocole de lab.

Administrer les paquets avec APT Dépôts deb822, clés GPG, patterns de recherche et dépannage APT en profondeur.

Filtrer avec nftables Debian n'installe aucun pare-feu : poser le filtrage sur un serveur exposé.

Réparer des dépendances cassées Quand un full-upgrade laisse dpkg dans un état incohérent, la marche à suivre.

Gérer les services systemd systemctl edit, mask, et le fonctionnement des unités sous systemd 257.

Mises à jour de sécurité La routine du quotidien, à distinguer d'une montée de version majeure.