Debian 12 « Bookworm » : mettre à jour ou migrer un serveur de production ?

Debian 12, nom de code « Bookworm », est sortie le 10 juin. Pour un serveur web, elle apporte notamment PHP 8.2, MariaDB 10.11 et nginx 1.22. Debian 11 reste maintenue encore un an, puis passe en support long terme : il n’y a pas d’urgence, mais il y a un calendrier.

Deux méthodes, un choix au cas par cas

Il y a deux façons de passer un serveur en Debian 12 : le mettre à jour sur place, ou monter un serveur neuf et y déplacer les sites. Je ne fais pas toujours l’une ni toujours l’autre. Debian est l’une des rares distributions dont la mise à jour d’une version à la suivante est réellement fiable, et ce serait dommage de s’en priver par principe.

Quand la mise à jour en place est la bonne réponse

Sur un serveur installé proprement, dont la configuration est connue et documentée, qui n’a pas accumulé des années de bricolages, la mise à jour en place est souvent le plus simple et le moins risqué. Elle garde la même machine, la même adresse IP (précieuse pour la réputation d’un serveur de messagerie), et ne demande aucune bascule DNS. Ce qui fait la différence, ce n’est pas la méthode, c’est la préparation.

Les précautions d’usage

1. Lire les notes de publication de Debian 12. Elles listent les changements qui cassent, comme le nouveau composant non-free-firmware à ajouter aux sources des paquets.
2. Sauvegarder, et vérifier la sauvegarde : fichiers, bases de données et configuration, copiés hors du serveur. Sur une machine virtuelle, un instantané juste avant l’opération en plus.
3. Mettre Debian 11 parfaitement à jour avant de changer de version, puis faire l’inventaire des dépôts tiers (PHP, MariaDB, supervision). On les désactive le temps de la mise à jour.
4. S’assurer d’un accès de secours : console distante ou mode de secours de l’hébergeur. Si le serveur ne redémarre pas, SSH ne servira à rien.
5. Choisir un créneau et prévenir les personnes concernées. Un soir de semaine calme vaut mieux qu’un vendredi soir.
6. Procéder en deux temps, comme le recommande Debian : une mise à jour minimale d’abord, puis la mise à jour complète. À chaque fichier de configuration modifié, comparer plutôt que d’écraser.
7. Redémarrer, vérifier chaque service (web, bases, messagerie, tâches planifiées), parcourir les sites hébergés et surveiller les journaux pendant les jours qui suivent.

Quand je préfère un serveur neuf

Quand le serveur a déjà traversé plusieurs versions et accumulé des configurations dont plus personne ne connaît l’origine, quand le matériel arrive en bout de course, ou quand certains sites hébergés sont trop fragiles pour supporter une coupure. Dans ce cas, je monte une machine neuve, je la durcis, j’y copie chaque site pour le tester via une adresse temporaire, puis je bascule le DNS, préalablement réglé avec un TTL court. L’ancien serveur reste en l’état quelques jours, au cas où.

Le vrai sujet : PHP 8.2

La partie système est la plus prévisible. Le point d’attention, ce sont les sites eux-mêmes : PHP 8.2 déprécie encore quelques usages, et un site ancien peut remplir ses journaux d’avertissements, ou pire. Pouvoir faire tourner plusieurs versions de PHP côte à côte permet de migrer le serveur sans imposer la même échéance à tous les sites.