Migration · fin de support
Migrer un serveur en fin de support : Debian 11, Ubuntu 20.04, CentOS 7
Depuis le 1er septembre 2026, Debian 11 ne reçoit plus aucun correctif de sécurité. Ubuntu 20.04 et CentOS 7 sont dans le même cas depuis plus longtemps. Si l'un de vos serveurs tourne encore dessus, chaque faille découverte à partir de maintenant restera ouverte. Je le migre vers une version maintenue, sans coupure.
Où en sont les versions courantes
- Debian 11 « Bullseye » : support terminé le 31 août 2026. Il ne reste qu'un support étendu payant, proposé par une société tierce pour une sélection de paquets.
- Ubuntu 20.04 LTS : support standard terminé en mai 2025. Les correctifs ne sont plus disponibles qu'avec l'abonnement Ubuntu Pro.
- CentOS 7 : fin de vie le 30 juin 2024, sans successeur direct.
- Debian 12 : maintenue jusqu'au 30 juin 2028. Debian 13 : jusqu'au 30 juin 2030.
- Ubuntu 22.04 LTS : fin du support standard en 2027. Mieux vaut l'anticiper maintenant que dans l'urgence.
Ce que risque un serveur non maintenu
Le serveur ne s'arrête pas le jour de la fin du support. Il continue de tourner, et c'est bien le problème : rien ne signale que chaque nouvelle faille publiée le concerne désormais sans correctif possible.
Or les attaques sont automatiques et permanentes. Sur une quarantaine de sites que j'administre, fail2ban a compté plus de 4 000 tentatives de connexion par jour entre fin juillet et fin septembre 2026. Des robots testent chaque serveur exposé, sans se soucier de sa taille ni de son intérêt.
S'y ajoutent des effets plus lents : les logiciels récents refusent de s'installer, les hébergeurs cessent de proposer la version, et chaque mois passé rend la migration plus longue.
Mise à niveau sur place ou reconstruction
Deux chemins existent. La mise à niveau sur place fait passer le système d'une version à la suivante sur la même machine. Debian ne permet pas de sauter une version : de la 11, il faut passer par la 12 avant la 13. C'est rapide quand le serveur est propre, risqué quand il a été bricolé pendant des années.
La reconstruction installe une version récente sur une nouvelle machine, à côté de l'ancienne. On y remonte les services un par un, on teste, puis on bascule. C'est plus long à préparer, mais la production n'est jamais touchée et le retour arrière reste possible jusqu'au bout. C'est le chemin que je privilégie, et celui qui permet de corriger au passage tout ce qui avait dérivé.
Quand la mise à jour est impossible dans les délais
Parfois, l'application elle-même ne supporte pas une version récente, et la réécrire prendrait des mois. En 2021, après l'incendie du datacenter de Strasbourg, j'ai dû sortir en deux semaines un serveur Ubuntu 12.04 qui faisait tourner une quarantaine de sites. J'ai reconstruit la machine à l'identique chez un autre hébergeur pour mettre les sites à l'abri, avant de moderniser ensuite.
Mettre à l'abri d'abord, moderniser ensuite : c'est souvent la bonne séquence quand le temps manque.