Fedora sur un VPS : combien de temps est-il supporté ?

Combien de temps une version de Fedora reçoit-elle des mises à jour de sécurité ?

Un serveur Fedora doit être mis à niveau environ une fois par an, pendant toute la durée de vie de la machine. Fedora publie une nouvelle version environ tous les six mois. Chaque version est prise en charge jusqu’à environ quatre semaines après la publication de la version sortie deux versions plus tard, soit environ 13 mois de mises à jour. Après cette date, la version ne reçoit plus aucun correctif de sécurité. Le serveur continue de fonctionner, mais plus personne ne corrige son ensemble de paquets.

Les dates permettent de mieux comprendre. En août 2026, les versions prises en charge sont Fedora 43 et Fedora 44. Fedora 44 est sortie le 28 avril 2026 et sa fin de vie est prévue pour juin 2027. Fedora 42 est sortie en avril 2025 et est arrivée en fin de vie en mai 2026, quatre semaines après la sortie de Fedora 44. Un serveur créé à partir d’une image Fedora 42 n’était donc plus pris en charge treize mois plus tard, sans qu’aucune erreur n’ait été commise.

Fedora par rapport à une LTS, en mois

LTS signifie « support à long terme » : il s’agit d’une version que l’éditeur continue de corriger pendant des années, et non pendant quelques mois. EOL signifie « fin de vie » : c’est la date à laquelle les correctifs cessent. Voici ce que chaque projet publie pour la version que vous installeriez aujourd’hui.

[
  {
    "distro": "Fedora 44",
    "support_window": 13,
    "upgrades_per_decade": 10
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "support_window": 60,
    "upgrades_per_decade": 2
  },
  {
    "distro": "Debian 13 stable",
    "support_window": 36,
    "upgrades_per_decade": 3
  },
  {
    "distro": "AlmaLinux 10",
    "support_window": 120,
    "upgrades_per_decade": 1
  }
]

Fedora vous offre 13 mois par version. Une Ubuntu LTS en offre 60, et une rebuild d’entreprise comme AlmaLinux en offre 120. Considérez la deuxième colonne comme la facture. Sur dix ans, Fedora vous impose environ 10 mises à niveau de l’ensemble du système d’exploitation, contre 2 pour Ubuntu LTS. La durée de 36 mois indiquée pour Debian correspond à son support de sécurité standard ; une équipe LTS distincte prolonge ensuite la prise en charge de la plupart des versions jusqu’à environ cinq ans.

Il s’agit de périodes de support publiées et vérifiées en août 2026, et non d’une mesure de disponibilité. La raison de ces cadences différentes est expliquée dans la différence entre Ubuntu LTS et les versions intermédiaires sur un serveur. Ce qui compte ici, c’est le travail que chacune vous impose.

Ce qu’implique réellement une mise à niveau de Fedora

DNF 5 est le gestionnaire de paquets par défaut depuis Fedora 41, et dnf l’exécute. La commande system-upgrade fait partie de dnf5 lui-même : aucun plugin n’est donc à installer au préalable. Commencez par la version actuelle, avec tous les correctifs appliqués :

sudo dnf upgrade --refresh
sudo reboot

Le redémarrage est important, car la mise à niveau s’appuie sur les paquets installés et le système en cours d’exécution. Une mise à jour partiellement appliquée du noyau ou de glibc rend donc l’étape suivante plus difficile à diagnostiquer. Préparez maintenant la nouvelle version. Remplacez 44 par la version vers laquelle vous migrez :

sudo dnf system-upgrade download --releasever=44

Cette commande résout l’intégralité de la transaction et télécharge tous les paquets, sans rien modifier sur le système en cours d’exécution. Prévoyez quelques milliers de paquets et un à trois gigaoctets sur un petit serveur. Si dnf ne peut pas résoudre la transaction, il s’arrête à cette étape et indique le paquet qui bloque l’opération. C’est le cas le plus favorable, car l’échec se produit alors que la machine est encore disponible et que vous avez toujours un shell.

Exécutez ensuite la transaction :

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status confirme qu’une transaction est préparée et en attente. dnf system-upgrade reboot redémarre la machine pour lancer une transaction hors ligne : un démarrage minimal pendant lequel la transaction RPM s’exécute seule. Ce fonctionnement est nécessaire, car remplacer glibc et systemd sous des services en cours d’exécution peut laisser le système dans un état partiellement installé. Votre serveur est inaccessible pendant toute la transaction, généralement plusieurs minutes sur un petit VPS, puis il redémarre de nouveau avec la nouvelle version. Préparez deux redémarrages et une période pendant laquelle SSH ne répondra pas.

À son retour :

cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras

/etc/fedora-release doit afficher une ligne semblable à Fedora release 44 (Forty Four). La sous-commande log affiche le journal de la transaction de ce démarrage hors ligne. C’est le seul enregistrement de ce qui s’est produit pendant que vous n’aviez pas de shell. distro-sync applique aux paquets restants les versions de la nouvelle version. repoquery --extras répertorie les paquets installés qui ne figurent plus dans aucun dépôt activé. C’est là que vous trouverez les restes d’un dépôt qui n’a jamais publié de paquets pour la nouvelle version.

Créez un snapshot du disque avant l’étape de téléchargement. La transaction s’exécute alors que vous ne pouvez pas voir l’écran. Si elle échoue pendant le démarrage hors ligne, SSH ne reviendra pas et votre seul moyen d’accès sera la console fournie par l’hébergeur, via VNC ou une liaison série. Vérifiez que vous avez accès à une console ou à un snapshot avant de commencer, et non après.

Voici un autre contrôle souvent oublié :

sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

Lorsqu’un paquet fournit un nouveau fichier de configuration par défaut et que vous avez modifié l’ancien, RPM n’écrase pas votre fichier. Il écrit la version fournie par le paquet à côté, sous le nom .rpmnew. Votre sshd ou nginx continue donc de fonctionner exactement comme sur l’ancienne version, tandis que les nouveaux paramètres par défaut restent inutilisés sur le disque. Consultez ces fichiers après chaque mise à niveau. Installez rpmconf, puis exécutez sudo rpmconf -a pour les parcourir un par un et afficher les différences.

Les dépôts tiers sont la cause des échecs de mise à niveau

Les paquets Fedora officiels évoluent tous ensemble le jour de la sortie. Les paquets provenant de sources externes suivent le calendrier de leurs éditeurs. La plupart des dépôts de fournisseurs intègrent $releasever dans leur URL. Dès que vous effectuez la mise à niveau, dnf demande donc un chemin qui n’existe peut-être pas encore.

Affichez les dépôts configurés :

sudo dnf repo list --enabled
grep -R -e baseurl -e metalink /etc/yum.repos.d/

Pour chaque dépôt qui n’appartient pas à Fedora, vérifiez sa compatibilité avec la version cible avant de lancer la mise à niveau :

sudo dnf --releasever=44 --repo=docker-ce-stable makecache

Si le fournisseur a publié les paquets pour cette version, dnf télécharge les métadonnées, puis se termine sans afficher d’erreur. Sinon, vous obtenez une erreur 404 pour un chemin tel que https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml, et le même échec interrompra ensuite system-upgrade download. Dans les premières semaines qui suivent la sortie d’une version de Fedora, c’est la cause la plus fréquente d’une mise à niveau qui ne démarre pas.

Deux solutions sont possibles. Attendez quelques semaines que le fournisseur publie les paquets. C’est généralement le meilleur choix. Vous pouvez aussi effectuer la mise à niveau sans ce dépôt :

sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stable

Désactiver un dépôt ne supprime pas ses paquets. Ceux-ci restent installés et ne sont plus gérés. S’ils bloquent la transaction, dnf vous l’indique. L’ajout de --allowerasing autorise dnf à supprimer les paquets installés pour résoudre le conflit. Consultez donc la liste des suppressions avant de confirmer. C’est dans cette liste que vous risquez de supprimer un serveur de base de données que vous vouliez conserver.

Que devient un serveur Fedora qui ne respecte pas le délai

Rien ne se passe le jour même. L’échec survient la prochaine fois que vous utilisez le gestionnaire de paquets. Les versions en fin de vie sont retirées du réseau de miroirs et déplacées dans l’archive. dnf upgrade échoue donc lors de la récupération des métadonnées, avec une erreur 404 sur l’URL metalink de votre version :

Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64

La machine continue de servir du trafic réseau, ce qui rend la situation discrète et dangereuse. Elle ne reçoit plus de mises à jour de sécurité. Elle ne peut pas non plus installer quoi que ce soit. Le jour où un avis de sécurité concerne OpenSSH ou nginx, vous ne disposez donc d’aucune méthode prise en charge pour la corriger.

Il est possible de s’en sortir, mais la procédure est lente. Vous pouvez rediriger les dépôts vers l’archive Fedora à l’adresse https://dl.fedoraproject.org/pub/archive/fedora/linux/, puis effectuer la mise à niveau depuis cette archive. Fedora prévoit un saut d’une ou deux versions à la fois. Un serveur qui a quatre versions de retard nécessite donc plusieurs sauts successifs. Chacun peut échouer et chacun s’exécute sans visibilité lors d’un démarrage hors ligne. Sur un VPS, reconstruire le serveur avec une image actuelle et transférer les données est généralement plus rapide et plus sûr. C’est le même travail que les dix premières minutes sur un nouveau VPS.

Les mises à jour automatiques appliquent les correctifs d’une release. Elles ne la mettent jamais à niveau.

Fedora peut installer ses mises à jour selon une planification :

sudo dnf install -y dnf5-plugin-automatic
sudo systemctl enable --now dnf5-automatic.timer

Les paramètres se trouvent dans /etc/dnf/automatic.conf, qui remplace les valeurs par défaut fournies dans /usr/share/dnf5/dnf5-plugins/automatic.conf. apply_updates est désactivé par défaut. Par conséquent, avec la configuration d’origine, le timer télécharge les mises à jour, mais n’en installe aucune. upgrade_type permet de choisir entre default et security. reboot accepte never, when-changed ou when-needed.

Le système reste ainsi à jour au sein d’une release. Il ne fera jamais passer Fedora 43 à Fedora 44, car une mise à niveau de version est une opération distincte et volontaire, qui redémarre le système pour effectuer une transaction hors ligne. C’est la différence pratique par rapport à une LTS. Sur Ubuntu, les mises à niveau de sécurité sans intervention maintiennent une machine à jour pendant toute la période de cinq ans, sans aucun changement de version, et le changement de version lui-même est une opération planifiée, comme la mise à niveau de 24.04 vers 26.04, une fois tous les quelques années.

Quand Fedora est le bon choix pour un serveur

Fedora est un bon choix lorsque la nouveauté est l’objectif.

• Vous avez besoin d’un kernel ou d’un userspace plus récent que ce que propose toute distribution LTS : matériel récent, ou stack de conteneurs et systemd qui ne sera pris en charge par une distribution enterprise que dans un an. Fedora adopte également de nouveaux kernels upstream pendant le cycle d’une release. Ce n’est donc pas seulement un avantage ponctuel au moment de l’installation.
• Vous vérifiez les composants destinés à entrer dans RHEL (Red Hat Enterprise Linux). Fedora alimente CentOS Stream, qui alimente RHEL. Les logiciels qui se construisent et fonctionnent aujourd’hui sur Fedora sont donc testés avec la plateforme enterprise de dans quelques années.
• La machine est conçue pour une durée de vie courte. Un build runner ou une machine de test détruite au bout de deux mois n’atteint jamais sa date de fin de vie. Le même raisonnement s’applique aux VM éphémères que vous attribuez à des agents de programmation, lorsque la machine est reconstruite bien plus souvent que Fedora ne publie de releases.
• Quelqu’un est responsable de la mise à niveau. Fedora convient à un serveur dont le responsable est identifié et dont la mise à niveau figure au calendrier. C’est un mauvais choix pour une machine que tout le monde a oubliée.

La voie intermédiaire : des paquets récents sur une base stable

La plupart des personnes qui veulent Fedora sur un serveur veulent deux ou trois paquets récents, pas un système d’exploitation récent. Ces deux choix peuvent être séparés. Utilisez une distribution LTS ou une reconstruction d’une distribution d’entreprise comme base, puis installez les logiciels récents uniquement là où vous en avez besoin. Une image de conteneur vous fournit une nouvelle version de l’application sur un hôte que vous n’avez pas besoin de mettre à niveau pour cela (exécuter Docker sur un VPS). Le dépôt du fournisseur pour le seul paquet qui vous intéresse, PostgreSQL ou nginx par exemple, fait évoluer ce paquet sans modifier la base.

Le compromis est clair dans les deux cas. Un conteneur fournit un nouvel espace utilisateur sur l’ancien noyau de l’hôte. Il ne vous aide donc pas lorsque le noyau est précisément l’élément dont vous avez besoin. Un dépôt du fournisseur fournit un paquet récent sur une base que le fournisseur a moins testée. Dans les deux cas, les mises à jour de sécurité du système de base suivent le calendrier LTS. Avec Fedora, ce calendrier vous impose chaque année une fenêtre de maintenance.

Si vous choisissez Fedora pour un serveur, inscrivez le cycle dans un calendrier. Lorsqu’une version sort, attendez quelques semaines que les dépôts des fournisseurs soient à jour, créez un snapshot, effectuez la mise à niveau, puis vérifiez que les services ont redémarré. Ce rythme prend environ une heure par an et fonctionne. Le scénario qui échoue est celui où vous ne vous souvenez de la mise à niveau qu’après une panne.

FAQ

Combien de temps une version de Fedora est-elle prise en charge ?

Environ 13 mois. Fedora publie une version environ tous les six mois et prend chacune en charge jusqu’à environ quatre semaines après la publication de la version sortie deux versions plus tard. Fedora 44 est sortie le 28 avril 2026, avec une fin de vie prévue en juin 2027. Après cette date, la version ne reçoit plus de mises à jour de sécurité et ses paquets sont retirés des mirrors pour être déplacés vers l’archive Fedora.

Puis-je ignorer une version de Fedora et effectuer une mise à niveau de deux versions à la fois ?

Oui, dans certaines limites. dnf system-upgrade download --releasever= accepte une cible située une ou deux versions plus loin, et passer deux versions à la fois correspond exactement à un rythme de mise à niveau annuel. Aller au-delà n’est pas une procédure prise en charge, et chaque version supplémentaire augmente le risque qu’un renommage de paquet ou qu’une modification du format de configuration interrompe la transaction. Si une machine a déjà plusieurs versions de retard et a dépassé sa fin de vie, reconstruire le serveur à partir d’une image actuelle est normalement plus rapide qu’enchaîner les mises à niveau.

Que se passe-t-il si mon serveur Fedora arrive en fin de vie ?

Il continue de fonctionner, mais ne reçoit plus de correctifs. Le prochain dnf upgrade échoue avec une erreur 404 sur l’URL metalink de votre version, car les versions arrivées en fin de vie sont déplacées vers l’archive à l’adresse dl.fedoraproject.org. Vous pouvez modifier les fichiers de dépôt pour pointer vers cette archive, puis effectuer la mise à niveau par étapes, ou reconstruire le serveur avec une version prise en charge. Tant que vous n’avez pas choisi l’une de ces deux solutions, aucune mise à jour de sécurité ne peut atteindre la machine et aucun paquet ne peut être installé.

Fedora est-elle un mauvais choix pour un serveur de production ?

C’est un mauvais choix par défaut, mais un choix raisonnable si vous avez une raison précise. Le coût est d’effectuer chaque année, indéfiniment, une mise à niveau complète du système d’exploitation sur une machine à laquelle vous préféreriez peut-être ne pas toucher. Choisissez Fedora si vous avez besoin d’un kernel ou d’un userspace plus récent que celui fourni par une version LTS, ou si le serveur est conçu pour une durée de vie courte. Choisissez une version LTS ou une distribution enterprise rebuild si vous voulez corriger un serveur pendant plusieurs années sans modifier sa version.