Fedora Server sur VPS : une mise à niveau par an

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, avec un ensemble de paquets qui n’est plus mis à jour.

Les dates permettent de mieux comprendre. En août 2026, les versions prises en charge sont Fedora 43 et Fedora 44. Fedora 44 a été publiée le 28 avril 2026 et sa fin de vie est prévue pour juin 2027. Fedora 42 a été publiée en avril 2025 et est arrivée en fin de vie en mai 2026, quatre semaines après l’arrivée 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 face à une version 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 de support par version. Une version Ubuntu LTS en offre 60, et une reconstruction destinée aux entreprises comme AlmaLinux en offre 120. Lisez la deuxième colonne comme la charge de maintenance. Sur dix ans, Fedora vous demande environ 10 mises à niveau complètes du système d’exploitation, contre 2 pour Ubuntu LTS. La valeur de 36 mois 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, vérifiées en août 2026, et non d’une mesure de disponibilité. La raison des différences de cadence est expliquée dans la différence entre Ubuntu LTS et les versions intermédiaires sur un serveur. Ce qui compte ici, c’est la charge de travail que chacune crée pour vous.

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. Si vous venez d’un serveur Debian ou Ubuntu, la plupart des commandes que vous utilisez au quotidien ont un équivalent direct d’apt vers dnf, et la mise à niveau de version ci-dessous fait partie des rares opérations sans véritable équivalent. Partez de la version actuelle, avec toutes les mises à jour installées :

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 du noyau ou de glibc appliquée partiellement 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 toute la transaction et télécharge chaque paquet, sans rien modifier sur le système en cours d’exécution. Sur un petit serveur, prévoyez quelques milliers de paquets et un à trois gigaoctets. Si dnf ne parvient pas à résoudre la transaction, il s’arrête à ce stade et indique le paquet bloquant. C’est le meilleur scénario : l’échec se produit alors que la machine est encore disponible et que vous avez toujours un shell.

Exécutez ensuite la mise à niveau :

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 exécuter la transaction hors ligne : il s’agit d’un démarrage minimal pendant lequel la transaction RPM s’exécute seule. Cette méthode est nécessaire, car remplacer glibc et systemd sous des services en cours d’exécution peut laisser le système dans un état d’installation partielle. Votre serveur est inaccessible pendant toute la transaction, généralement plusieurs minutes sur un petit VPS, puis il redémarre à nouveau avec la nouvelle version. Prévoyez deux redémarrages et une période pendant laquelle SSH ne répond 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 du démarrage hors ligne. C’est le seul relevé de ce qui s’est produit pendant que vous n’aviez aucun shell. distro-sync installe les éventuels paquets restants dans les versions de la nouvelle version. repoquery --extras liste 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 version pour la nouvelle release.

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 disposez d’une console ou d’un snapshot avant de commencer, et non après.

Voici une dernière vérification souvent oubliée :

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 dans l’ancienne version, tandis que les nouveaux paramètres par défaut restent inutilisés sur le disque. Lisez ces fichiers après chaque mise à niveau. L’installation de rpmconf, suivie de l’exécution de sudo rpmconf -a, les parcourt un par un et affiche les différences.

Les dépôts tiers sont ceux qui bloquent la mise à niveau

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

Listez les dépôts présents sur votre système :

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, testez sa compatibilité avec la version cible avant de confirmer quoi que ce soit :

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

Si l’éditeur a publié le dépôt pour cette version, dnf télécharge les métadonnées et se termine sans message. Dans le cas contraire, vous obtenez une erreur 404 pour un chemin comme https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml, et la même erreur interrompra la mise à niveau system-upgrade download plus tard. Durant les premières semaines qui suivent la sortie d’une version de Fedora, c’est la raison la plus fréquente pour laquelle une mise à niveau ne démarre pas.

Vous avez deux possibilités. Attendre quelques semaines que l’éditeur publie le dépôt, ce qui est généralement la bonne décision. Ou 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. Ils restent installés et ne sont plus gérés par ce dépôt. S’ils bloquent la transaction, dnf vous l’indique. L’ajout de --allowerasing permet à dnf de supprimer des paquets installés pour résoudre le conflit. Consultez donc la liste des suppressions avant de l’accepter. C’est ainsi que l’on perd un serveur de base de données que l’on voulait conserver.

Ce qui arrive à un serveur Fedora qui dépasse l’échéance

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 vers 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 traiter le 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 de paquets. Le jour où un avis de sécurité concerne OpenSSH ou nginx, vous ne disposez donc d’aucun moyen pris en charge pour appliquer le correctif.

Il est possible de sortir de cette situation, 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. Une machine qui a quatre versions de retard nécessite donc plusieurs sauts successifs. Chacun peut échouer et doit être exécuté sans visibilité lors d’un démarrage hors ligne. Sur un VPS, reconstruire la machine à partir d’une image actuelle, puis 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 des correctifs à une release. Elles ne la mettent jamais à niveau.

Fedora peut installer ses mises à jour selon un timer :

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. Tel quel, le timer télécharge donc 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.

Cela vous permet de rester à jour au sein d’une release. Fedora 43 ne passera jamais à Fedora 44, car une mise à niveau de version est une opération distincte et volontaire qui redémarre le système pour exécuter une transaction hors ligne. C’est la différence pratique par rapport à une LTS. Sur Ubuntu, les mises à niveau de sécurité automatiques permettent à une machine de rester couverte pendant toute la période de cinq ans, sans aucun changement de version. Le changement de version lui-même est une opération planifiée, comme la mise à niveau de 24.04 vers 26.04, effectuée 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 celui fourni par une distribution LTS : matériel récent, ou stack de conteneurs et systemd qui ne sera pas disponible dans une release enterprise avant encore un an. Fedora passe également aux nouveaux kernels upstream pendant le cycle d’une release. Ce n’est donc pas seulement un avantage ponctuel au moment de l’installation.
• Vous voulez valider ce qui va entrer dans RHEL (Red Hat Enterprise Linux). Fedora alimente CentOS Stream, qui alimente RHEL. Les logiciels qui se compilent et s’exécutent 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. La même logique s’applique aux VM jetables que vous attribuez aux agents de programmation, lorsque la machine est reconstruite beaucoup 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 est inscrite au calendrier. C’est un mauvais choix pour une machine que tout le monde a oubliée.

Le compromis : 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 à jour. Ces deux besoins peuvent être séparés. Utilisez une distribution LTS ou une reconstruction d’une distribution entreprise comme base, puis installez les logiciels récents uniquement là où vous en avez besoin. Une image de conteneur vous fournit la nouvelle version de l’application sur un hôte que vous n’avez jamais 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 composant sans modifier la base.

Le compromis fonctionne dans les deux sens. Un conteneur fournit un nouvel espace utilisateur sur l’ancien kernel de l’hôte. Il ne vous aide donc pas lorsque c’est le kernel qui doit être mis à jour. Un dépôt de fournisseur vous fournit un paquet plus 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. C’est ce calendrier qui vous impose chaque année une fenêtre de maintenance avec Fedora.

Si vous choisissez Fedora pour un serveur, inscrivez le cycle sur un calendrier. Lorsqu’une release est publiée, attendez quelques semaines que les dépôts des fournisseurs se mettent à jour, créez un snapshot, effectuez la mise à niveau, puis vérifiez que les services ont redémarré. Ce rythme demande environ une heure par an et fonctionne. La seule mise à niveau qui échoue est celle dont on se souvient uniquement parce qu’un problème s’était déjà produit.

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 en charge chaque version jusqu’à environ quatre semaines après la publication de la version sortie deux versions plus tard. Fedora 44 est sortie le 28 avril 2026 et sa fin de vie est prévue pour juin 2027. À cette date, la version ne reçoit plus de mises à jour de sécurité et ses paquets sont retirés des miroirs pour être placés dans 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 comme cible une version située une ou deux versions plus loin. Passer directement deux versions correspond exactement à un rythme de mise à niveau annuel. Aller au-delà n’est pas une procédure prise en charge. 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 que sa version est arrivée en fin de vie, réinstaller le serveur depuis une image actuelle est généralement 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 à dl.fedoraproject.org. Vous pouvez modifier les fichiers des dépôts pour pointer vers cette archive, puis effectuer la mise à niveau par étapes. Vous pouvez aussi réinstaller 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 lorsqu’il répond à un besoin précis. Le coût est une mise à niveau complète du système d’exploitation chaque année, indéfiniment, sur une machine que vous préféreriez peut-être ne pas modifier. 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 fonctionner pendant une courte période. Choisissez une version LTS ou une rebuild enterprise si vous voulez appliquer des correctifs à un serveur pendant plusieurs années sans modifier sa version.