Fedora 45 est disponible : ce qui change pour un serveur Fedora sur VPS

Le projet Fedora a publié Fedora Linux 45 le 3 novembre 2026. L'annonce officielle met en avant les bureaux, mais la liste des changements acceptés pour cette version touche surtout la couche système : une nouvelle console virtuelle en espace utilisateur (kmscon), des signatures de paquets RPM exigées par défaut, une restriction de ptrace pour les processus non privilégiés, Stratis intégré à l'installateur Anaconda et à Kickstart, OpenSSL 4.0, Podman 6, Python 3.15 et Go 1.27. Pour quiconque administre un VPS Fedora ou un serveur dédié sous Fedora Server, chacun de ces points modifie une habitude : la console de secours, l'installation d'un paquet maison, le débogage d'un service, la mise à niveau elle-même. Cet article passe en revue ce qui change réellement pour un serveur, détaille la mise à niveau depuis Fedora 44 avec dnf system-upgrade sur une machine sans écran, liste les pièges relevés par les premiers utilisateurs et replace Fedora Server face à Debian et Rocky Linux.

Sources : Announcing Fedora Linux 45, Fedora Magazine, 3 novembre 2026 ; liste des changements acceptés sur le wiki du projet Fedora (Releases/45/ChangeSet) et pages de proposition associées ; versions des paquets relevées sur packages.fedoraproject.org.

Les changements de Fedora 45 qui comptent pour un serveur

Fedora publie une version tous les six mois environ et chaque version est maintenue à peu près treize mois, jusqu'à quelques semaines après la sortie de la version N+2. Fedora 45 marque donc la fin prochaine de Fedora 43 et ouvre la fenêtre de mise à niveau pour les serveurs restés en 44. Le tableau ci-dessous résume ce qui change entre les deux dernières versions, du point de vue d'un administrateur de serveur Linux.

Le noyau mérite une précision : Fedora suit les versions stables du noyau dans les mises à jour courantes, si bien qu'au 11 novembre 2026, packages.fedoraproject.org affiche le même noyau 7.3.3 pour Fedora 44 et Fedora 45. La mise à niveau ne change donc pas la branche du noyau, ce qui écarte un risque classique sur un VPS : pilote virtio, module tiers ou option de démarrage qui se comporte autrement après le redémarrage.

kmscon remplace la console du noyau, y compris sur Fedora Server

Jusqu'à Fedora 44, les consoles virtuelles tty1 à tty6 étaient dessinées par fbcon, le pilote de console intégré au noyau, et un processus agetty y affichait l'invite de connexion. Fedora 45 installe kmscon par défaut et fait pointer l'unité systemd autovt@.service vers kmsconvt@.service. kmscon est une console en espace utilisateur qui parle directement au pilote graphique via DRM et libdrm. La proposition de changement précise qu'elle doit devenir la console par défaut y compris sur les installations sans environnement graphique, donc sur Fedora Server. Le paquet a été découpé pour qu'un serveur n'ait pas à tirer de dépendance OpenGL : le rendu accéléré est dans un sous-paquet séparé, kmscon-gl, à côté de kmscon-freetype et kmscon-pango pour les polices. Si kmscon ne parvient pas à démarrer, le système retombe sur agetty et fbcon.

Sur un VPS, la console que vous ouvrez depuis le panneau de gestion de l'hébergeur (console VNC) affiche précisément tty1. Après la mise à niveau, c'est donc kmscon qui dessine ce que vous voyez, avec un meilleur support des polices et de l'Unicode. Trois conséquences pratiques :

• Les outils qui configurent la console du noyau, setfont et loadkeys, n'ont plus d'effet. La police et la disposition du clavier se règlent dans /etc/kmscon/kmscon.conf ; par défaut, kmscon reprend la disposition définie par localectl.
• La console série (ttyS0) n'est pas concernée : elle reste gérée par serial-getty@.service. Si votre hébergeur vous donne une console série plutôt qu'un affichage VNC, rien ne change.
• Pour revenir à l'ancien comportement, la proposition de changement indique qu'il suffit de ne pas avoir kmscon installé : getty sur fbcon redevient alors la console par défaut. fbcon reste compilé dans le noyau, si bien que les messages de démarrage et la saisie d'une phrase de passe LUKS ne changent pas.

Pour les serveurs que vous administrez exclusivement en SSH, kmscon ne se voit jamais. Il compte le jour où SSH ne répond plus et où la console VNC devient votre seul accès, par exemple après une erreur de pare-feu ou de configuration SSH. Notre guide VPS inaccessible : diagnostic réseau en 30 secondes décrit ce scénario.

Signatures de paquets obligatoires avec RPM 6.1

Fedora 45 livre RPM 6.1 et active la vérification stricte des signatures : la macro %_pkgverify_level passe de digest (seules les empreintes sont contrôlées) à all (signature OpenPGP valide et empreintes). Concrètement, rpm -i ou rpm -U sur un fichier .rpm non signé, ou signé avec une clé non importée, échoue, sauf option --nosignature explicite. Ce réglage, qui est déjà le défaut de RPM 6.0 en amont, devait arriver avec cette version ; il a été repoussé à Fedora 45 faute de temps et de ressources, d'où un Fedora 44 en RPM 6.0 qui ne contrôlait encore que les empreintes.

Pour un serveur, les paquets des dépôts officiels et des dépôts tiers signés ne posent aucun problème. Les situations à vérifier sont celles où vous installez des paquets construits par vous-même ou fournis sans signature par un éditeur :

# Contourner la vérification pour une seule commande
sudo rpm -i --nosignature mon-paquet.rpm

# Revenir durablement à l'ancien niveau (empreintes seulement)
echo '%_pkgverify_level digest' | sudo tee /etc/rpm/macros.verify

Avec dnf5 (version 5.2.14 ou plus récente, donc depuis Fedora 42), un dépôt déclaré avec gpgcheck=0 reste utilisable : dnf désactive la vérification de signature paquet par paquet pour ce dépôt. Pour vos propres constructions, RPM 6 peut signer automatiquement avec une clé sans mot de passe : exécutez une fois /usr/lib/rpm/rpm-setup-autosign, puis importez la clé indiquée. COPR signe automatiquement ce qu'il construit, et Mock dispose d'un greffon de signature pour les paquets construits en local.

Une précision, car plusieurs résumés de la sortie mélangent deux propositions : le verrouillage du changement de fournisseur de paquets par dnf5 (allow_vendor_change=False, qui empêchera dnf de remplacer silencieusement un paquet Fedora par celui d'un dépôt tiers) a d'abord été proposé pour Fedora 45, puis reporté : il figure parmi les changements acceptés pour Fedora 46. Sur Fedora 45, dnf5 se comporte comme avant sur ce point. Si vous mélangez dépôts officiels et dépôts tiers (COPR, dépôt d'éditeur), notez dès maintenant les paquets concernés : avec la 46, il faudra autoriser explicitement ces changements de fournisseur, par exemple avec l'option --from-vendor prévue par la proposition.

ptrace restreint pour les processus non privilégiés

Le module de sécurité Yama du noyau permet de limiter l'appel système ptrace, celui qu'utilisent les débogueurs et traceurs pour s'attacher à un processus. Jusqu'à Fedora 44, le paquet elfutils-default-yama-scope, tiré par elfutils-libs et donc présent sur toutes les machines, livrait un fichier sysctl qui remettait kernel.yama.ptrace_scope à 0 : n'importe quel processus d'un utilisateur pouvait inspecter n'importe quel autre processus du même utilisateur. Fedora 45 applique la valeur 1 par défaut : un processus ne peut tracer que ses descendants. L'objectif est d'empêcher un logiciel malveillant exécuté sous un compte ordinaire de lire la mémoire des autres processus de ce compte, par exemple un agent SSH ou un navigateur.

Pour un administrateur, cela se voit dès qu'on cherche à s'attacher à un processus existant avec le même compte non privilégié :

sysctl kernel.yama.ptrace_scope
# kernel.yama.ptrace_scope = 1

strace -p $(pgrep -f mon-serveur)
# strace: attach: ptrace(PTRACE_SEIZE, ...): Operation not permitted

Lancer un programme sous strace ou gdb continue de fonctionner, et root n'est pas concerné. Le paquet yama-ptrace-enable (nouveau nom de elfutils-default-yama-scope) restaure l'ancien comportement ; il est recommandé par gdb, strace, ltrace, lldb, delve et systemtap, mais pas par gdb-headless ni gdb-minimal. Lors d'une mise à niveau, le fichier sysctl d'elfutils est retiré si aucun outil de débogage n'est installé, et conservé sinon. Sur un serveur de production, la bonne pratique est de laisser la restriction active et de n'installer yama-ptrace-enable que le temps d'un diagnostic.

Stratis dans Anaconda et Kickstart

Stratis est la couche de gestion du stockage développée par Red Hat au-dessus de device-mapper et du système de fichiers XFS : pools de disques, allocation fine (thin provisioning), instantanés, niveaux de cache et chiffrement, le tout piloté par un démon et la commande stratis. Jusqu'ici, on ne pouvait pas installer Fedora directement dessus. Fedora 45 ajoute Stratis à l'installateur Anaconda de deux manières. Dans l'interface web, le partitionnement manuel ouvre le module de stockage de Cockpit, qui sait créer un pool et des systèmes de fichiers Stratis, puis l'installateur utilise la configuration ainsi préparée. Dans un fichier Kickstart, le partitionnement automatique accepte --type=stratis et deux nouvelles commandes, stratispool et stratisfs, décrivent un pool et ses systèmes de fichiers, sur le modèle de volgroup et logvol pour LVM :

# Partitionnement automatique sur Stratis
autopart --type=stratis

# Ou pool explicite sur deux disques (syntaxe donnée par la proposition de changement)
part bd.01 --size=18000 --ondisk=vda
part bd.02 --size=18000 --ondisk=vdb
stratispool mypool bd.01 bd.02
stratisfs / --size=10000 --name=root --pool=mypool
stratisfs /home --size=1 --grow --name=home --pool=mypool

Les partitions de démarrage (/boot, /boot/efi ou biosboot) restent des partitions classiques créées avant le pool. L'ancienne interface GTK d'Anaconda ne reçoit pas ce support, et la proposition prévient que la syntaxe Kickstart pourrait encore évoluer : vérifiez la documentation de pykickstart avant d'industrialiser. Ce changement ne concerne que les nouvelles installations. Sur un VPS livré avec une image Fedora déjà partitionnée, rien ne change ; il prend son sens pour l'installation automatisée d'un serveur dédié depuis une ISO Fedora Server et un fichier Kickstart, là où l'on choisissait jusqu'ici entre LVM et Btrfs. Pour l'extension de volumes sur une installation existante, notre guide étendre un volume LVM sur un serveur dédié reste la référence.

Podman 6, Python 3.15 et Go 1.27 : ce qui casse, ce qui ne casse pas

Podman 6.1.3 est la version livrée avec Fedora 45, contre 5.8.9 sur Fedora 44. C'est une version majeure, avec des retraits annoncés : le réseau rootless slirp4netns disparaît au profit de pasta, déjà par défaut depuis Podman 5.0 ; cgroups v1 n'est plus pris en charge ; le backend de base de données BoltDB est retiré au profit de SQLite, par défaut depuis Podman 4.8 ; l'option --network-cmd-path disparaît avec slirp4netns ; Netavark ne gère plus qu'nftables ; et containers.conf est réorganisé entre client et serveur. Le point critique est la base de données : une installation restée sur BoltDB voit son état de conteneurs inutilisable après le passage à Podman 6. La proposition de changement demande de passer par Podman 5.8 et de redémarrer avant la mise à niveau, ce qui revient à mettre Fedora 44 entièrement à jour d'abord. Vérifiez le backend en place :

podman --version
podman info --format '{{.Host.DatabaseBackend}}'
# attendu : sqlite

Si vous hésitez entre Podman et Docker pour vos conteneurs sur Fedora, notre comparatif Podman ou Docker sur un VPS Linux détaille les différences, et le guide installer Docker sur un VPS couvre le dépôt Docker CE.

Python 3.15 remplace 3.14 comme interpréteur système ; la proposition de changement estimait à environ 3 900 le nombre de paquets à reconstruire. Fedora prévient qu'un utilisateur ne doit remarquer aucun changement de comportement du système, hormis la version de l'interpréteur, mais vos propres scripts et surtout vos environnements virtuels sont liés à la version de l'interpréteur : un venv créé sous 3.14 doit être recréé, et les dépendances réinstallées, après la mise à niveau. Go 1.27 arrive sans impact de compatibilité annoncé ; les binaires compilés avec 1.26 continuent de tourner, et une recompilation suffit pour profiter de la nouvelle version.

OpenSSL 4.0, MySQL 9.7 et MariaDB 12.3 : trois versions majeures sous vos services

Fedora 45 passe à OpenSSL 4.0 : 4.0.3 au 11 novembre 2026, contre 3.5.9 sur Fedora 44. C'est la bibliothèque TLS et cryptographique de tout le système (OpenSSH, serveurs web, clients de base de données, curl). La proposition de changement annonce un changement de soname, donc la reconstruction de tous les paquets qui la lient, et le retrait du support des ENGINE, l'ancien mécanisme de modules cryptographiques remplacé par les providers. Les paquets Fedora ont été reconstruits ; le risque se situe ailleurs, sur les binaires que vous avez installés hors dépôt et qui sont liés à libssl.so.3 ou libcrypto.so.3, et sur les configurations qui chargent un engine (module PKCS#11 pour une clé matérielle, par exemple). Fedora fournit pour eux un paquet de compatibilité, openssl3-libs, en version 3.5.9 :

# Un binaire installé à la main dépend-il encore d'OpenSSL 3 ?
ldd /opt/mon-service/bin/mon-service | grep -E 'libssl|libcrypto'

# Si oui, installer la bibliothèque de compatibilité
sudo dnf install openssl3-libs

# Version d'OpenSSL du système après la mise à niveau
openssl version

Pour contrôler qu'un service TLS répond toujours correctement après le passage à OpenSSL 4.0, notre guide vérifier un certificat TLS avec openssl donne les commandes openssl s_client utiles.

Côté bases de données, les paquets non versionnés mysql-server et mariadb-server pointent désormais vers MySQL 9.7 (au lieu de 8.4) et MariaDB 12.3 (au lieu de 11.8). Un serveur SQL installé sous ces noms change donc de version majeure pendant la mise à niveau du système. Les deux propositions de changement listent ce qui peut casser :

• MySQL 9.7 exécute la mise à niveau des tables seul au premier démarrage. En revanche, une application qui s'authentifie encore avec le greffon mysql_native_password échoue tant que le compte n'est pas passé à caching_sha2_password, et la variable replica_parallel_type a disparu : une réplication qui l'utilise doit être corrigée avant la mise à niveau.
• MariaDB 12.3 demande de lancer mariadb-upgrade après le premier démarrage. Trois changements de comportement sont à vérifier : innodb_snapshot_isolation activé par défaut (effet sur les transactions REPEATABLE READ), CONVERSION, ST_COLLECT et TO_DATE devenus des mots réservés, et master_use_gtid remis à sa valeur par défaut sur les réplicas, à reconfigurer.

Pour rester sur l'ancienne branche, Fedora 45 conserve les paquets versionnés mysql8.4-server et mariadb11.8-server. La procédure donnée par Fedora consiste à arrêter et désactiver le service avant la mise à jour, puis à échanger le paquet :

# Avant tout : sauvegarde complète
sudo mariadb-dump --all-databases --single-transaction > /root/avant-fedora-45.sql

# Avant la mise à niveau : arrêter et désactiver le service
sudo systemctl disable --now mariadb

# Une fois en Fedora 45 : revenir à la branche 11.8 et relancer
sudo dnf swap mariadb-server mariadb11.8-server --allowerasing
sudo systemctl enable --now mariadb

Pour MySQL, le principe est le même avec mysqldump, le service mysqld et dnf swap mysql-server mysql8.4-server --allowerasing. Les paquets 8.4 et 9.7 ne peuvent pas être installés ensemble. Si vos sauvegardes SQL ne sont pas encore automatisées, notre guide sauvegardes MySQL avec mysqldump et cron règle la question avant le saut, et installer MariaDB sur un VPS Linux rappelle la configuration de base du serveur.

Mettre à niveau un VPS Fedora 44 vers 45 sans console graphique

Depuis que dnf5 est le gestionnaire de paquets par défaut, la commande system-upgrade fait partie de dnf lui-même : il n'y a plus de plugin dnf-plugin-system-upgrade à installer, contrairement aux anciens guides écrits pour DNF 4. Le principe n'a pas changé : dnf télécharge tous les paquets de la nouvelle version pendant que le serveur tourne normalement, puis redémarre dans un environnement minimal hors ligne pour les installer, et redémarre une seconde fois dans Fedora 45. Pendant la phase hors ligne, SSH ne répond pas. Sur un VPS sans écran, préparez donc votre accès à la console VNC du panneau de gestion avant de commencer, et créez un snapshot du VPS si votre hébergeur le propose. Les VPS Fedora ElypseCloud se déploient avec une image Fedora 42 Server Edition et un snapshot se crée depuis le Manager. Or Fedora 42 ne reçoit plus de mises à jour depuis fin mai 2026 : un serveur resté sur cette image doit être mis à niveau sans attendre. Fedora ne prenant en charge qu'un saut de deux versions à la fois, passez d'abord de la 42 à la 44, vérifiez, puis de la 44 à la 45 avec la même procédure.

1. Sauvegarder et mettre Fedora 44 entièrement à jour. Le snapshot protège le système, une sauvegarde rsync vers un serveur distant protège les données. La mise à jour complète garantit que Podman est bien en 5.8.9 avant le saut vers la 6 :

sudo dnf --refresh upgrade
sudo systemctl reboot

2. Contrôler les dépôts tiers. Un dépôt qui ne publie pas encore d'arbre pour Fedora 45 fera échouer le téléchargement. Listez-les et désactivez temporairement ceux qui ne suivent pas :

dnf repolist
# si nécessaire, pour la seule étape de téléchargement :
# --disablerepo=nom-du-depot

3. Télécharger les paquets de Fedora 45. Lancez cette étape dans tmux ou screen : une coupure SSH en plein téléchargement ne casse rien, mais vous perdriez la sortie. Ajoutez --allowerasing uniquement si dnf signale des conflits de dépendances, et lisez alors la liste des paquets qu'il propose de retirer :

sudo dnf system-upgrade download --releasever=45

4. Redémarrer dans l'environnement de mise à niveau. La commande suivante prépare la transaction hors ligne et redémarre. N'intervenez pas pendant l'installation ; suivez l'avancement dans la console VNC, où kmscon ne joue pas encore puisque c'est l'ancien système qui exécute cette phase :

sudo dnf system-upgrade reboot

5. Vérifier après le second redémarrage. Reconnectez-vous en SSH et contrôlez la version, les services et le journal de la mise à niveau :

cat /etc/fedora-release
systemctl --failed
sudo dnf system-upgrade log --number=-1
sudo dnf system-upgrade clean

Terminez par le ménage habituel : rpmconf -a (paquet rpmconf) pour arbitrer les fichiers de configuration modifiés, et remove-retired-packages pour retirer les paquets abandonnés par Fedora entre les deux versions. Si vos services sont déclarés en unités systemd, ils reviennent seuls au démarrage ; vérifiez-le avec systemctl status plutôt que de le supposer. Pour une lecture plus fine des journaux, voir analyser les journaux avec journalctl.

Les pièges relevés après les premières mises à niveau

Les fichiers .repo de Fedora ont déménagé. Les définitions de dépôts fournies par les paquets Fedora quittent /etc/yum.repos.d pour /usr/share/dnf5/repos.d, et les clés de signature du paquet fedora-gpg-keys passent dans /usr/share/pki/rpm-gpg. Un fichier Fedora resté intact est déplacé proprement. Un fichier Fedora que vous aviez modifié à la main dans /etc/yum.repos.d (par exemple pour activer updates-testing ou fixer un miroir) reste en place et remplace entièrement la version livrée dans /usr. Votre réglage survit, mais c'est désormais votre copie figée qui fait foi : les évolutions que Fedora apportera au fichier livré ne s'appliqueront pas chez vous. La méthode propre consiste à supprimer cette copie, pour que la version de /usr reprenne la main, puis à passer par dnf config-manager setopt, qui n'écrit que l'option modifiée dans /etc/dnf/repos.override.d/99-config_manager.repo. Les fichiers .repo que vous avez ajoutés vous-même (Docker CE, dépôt d'éditeur, COPR) restent dans /etc/yum.repos.d, que dnf5 continue de lire.

# Après la mise à niveau : un fichier Fedora présent dans les deux dossiers
# est une copie modifiée qui masque la version livrée
ls /usr/share/dnf5/repos.d/ /etc/yum.repos.d/

# Régler un dépôt proprement (surcharge dans /etc/dnf/repos.override.d)
sudo dnf config-manager setopt updates-testing.enabled=0

La même proposition précise que les anciens gestionnaires de paquets, DNF4 et YUM, ne fonctionneront plus comme gestionnaires de paquets du système. Sur Fedora, la commande dnf est déjà dnf5 depuis plusieurs versions ; vérifiez seulement qu'aucun script d'administration n'appelle encore dnf4 explicitement.

Deux plugins VPN de NetworkManager sont retirés. NetworkManager-vpnc (IPsec/IKEv1 de type Cisco) et NetworkManager-fortisslvpn (Fortinet SSL VPN) n'étaient plus maintenus et sont désinstallés automatiquement lors du passage à Fedora 45 : le paquet NetworkManager les déclare obsolètes. Sur Fedora 43 et 44, ils restent installés mais ne reçoivent plus aucune mise à jour. Un serveur qui montait un tunnel vers un site distant avec l'un d'eux perd sa connexion. Fedora Magazine indique les remplaçants : NetworkManager-libreswan pour IPsec et NetworkManager-openconnect pour Fortinet, avec une reprise des paramètres IKE et ESP à la main. Si le tunnel sert à joindre votre infrastructure, une alternative plus simple sur un VPS est un maillage WireGuard : voir Tailscale sur VPS Linux.

Les autres surprises sont celles décrites plus haut. Un strace -p qui échoue (ptrace), un rpm -i refusé (signature), un conteneur Podman dont l'état a disparu (BoltDB), un service Python qui ne démarre plus (environnement virtuel lié à 3.14), un binaire maison qui ne trouve plus libssl.so.3 (OpenSSL 4.0), une base MariaDB ou MySQL qui change de version majeure, et une console VNC rendue par kmscon dont la disposition clavier se règle désormais dans /etc/kmscon/kmscon.conf. Aucune n'est bloquante, toutes se diagnostiquent en quelques minutes si vous savez qu'elles existent.

Fedora Server, Debian ou Rocky Linux : quelle distribution pour quel serveur

Fedora Server n'est pas la distribution par défaut d'un hébergeur, et ce n'est pas un hasard : son cycle court impose une mise à niveau majeure tous les six à treize mois. En échange, elle livre les versions les plus récentes du noyau, de Podman, de Python et de Go, et elle préfigure ce qui arrivera dans Red Hat Enterprise Linux et donc dans Rocky Linux. Le tableau compare les trois options proposées sur un VPS Linux, avec les versions au jour de la sortie de Fedora 45.

En pratique, trois profils se dégagent. Un serveur de jeu FiveM, Minecraft ou Rust, ou un hébergement web que vous voulez oublier pendant des années, se trouve mieux sur Debian ou Ubuntu LTS : peu de changements, beaucoup de documentation, et une migration de version tous les deux ou trois ans, comme décrit dans notre guide migrer un VPS de Debian 12 vers Debian 13. Une application qui doit tourner sur une base compatible RHEL, parce qu'un éditeur la certifie ou parce que votre équipe vient du monde Red Hat, va sur Rocky Linux, avec dix ans de correctifs. Un environnement de développement, une plateforme de conteneurs ou un service écrit en Python ou Go qui a besoin des dernières versions, ou une équipe qui veut tester aujourd'hui ce que RHEL livrera dans deux ans, est à sa place sur Fedora Server, à condition d'accepter la discipline de la mise à niveau semestrielle et de disposer d'un snapshot avant chaque saut. Le comparatif complet quelle distribution Linux pour un VPS détaille ces arbitrages, et le guide gérer plusieurs serveurs Linux avec Cockpit montre l'interface d'administration livrée en standard avec Fedora Server.

Conclusion

Fedora 45 ne change pas le noyau d'un serveur Fedora 44, mais elle change beaucoup de choses autour : la console que vous verrez le jour où SSH tombe, les paquets que RPM accepte d'installer, les processus qu'un compte ordinaire peut inspecter, la version d'OpenSSL, de Podman, de Python et du serveur SQL qui fait tourner vos services. Rien de tout cela n'est un obstacle à la mise à niveau, qui se fait en quatre commandes avec dnf system-upgrade, à condition de respecter l'ordre : sauvegarde et snapshot, Fedora 44 entièrement à jour, dépôts tiers vérifiés, puis téléchargement et redémarrage. Les administrateurs de Fedora 43 n'ont plus que quelques semaines de correctifs devant eux et doivent planifier le saut dès maintenant. Ceux de Fedora 44 ont le temps de lire les notes de version et d'attendre les premières corrections, pas celui d'oublier : la 44 s'arrêtera à son tour peu après la sortie de Fedora 46, au printemps 2027. Pour tester Fedora 45 sans toucher à la production, un VPS Fedora avec snapshot et SSH durci reste le moyen le plus rapide de voir ce que ces changements donnent sur vos propres services.