Changements dans Fedora 41 pour les administrateurs système

Le gestionnaire de paquets par défaut dans Fedora 41 est DNF 5. Il s’agit d’une mise à jour importante venant avec son lot d’améliorations :

Pour obtenir des informations à propos de cette version, consultez la documentation DNF5 upstream, en particulier la liste des différences entre DNF et DNF5. Nous recommandons également aux développeur·euses de consulter les bindings API DBus pour dnfdaemon.

RPM a été mis à jour vers la version 4.20 dans Fedora 41, qui contient un certain nombre d’améliorations, telles que :

Consultez les notes de version upstream pour connaître les détails.

À partir de Fedora 41, les Bureaux atomiques Fedora, Fedora CoreOS et Fedora IoT seront fournis avec bootc et DNF5 dans leur image. Vous pouvez maintenant utiliser les commandes dnf dans le processus de compilation des conteneurs utilisant ces variantes de Fedora en tant qu’image de base. Bien que rpm-ostree reste disponible, vous pouvez désormais utiliser bootc pour gérer les déploiements et les mises à jour en mode Image.

Lorsque vous essayez d’utiliser DNF sur un système démarré en mode Image, un message d’erreur plus clair est désormais affiché, indiquant les outils disponibles sur votre système qui vous permettront d’accomplir votre tâche. Il s’agit de la première étape d’un processus visant à mettre à disposition les fonctionnalités de rpm-ostree dans DNF et à recentrer la gestion des déploiements en mode Image sur bootc.

Les identifiants SPDX sont utilisés comme standard de référence pour la spécification des licences des paquets RPM. 90 % des paquets ont été migrés vers les identifiants SPDX. La migration des paquets restants devrait être achevée pour la sortie de Fedora 42. Une liste de l’ensemble des licences autorisées (et utilisées) dans Fedora Linux est consultable sur la page des mentions légales de Fedora. Dans les 90 % de paquets migrés, 9 % comportent une licence LicenseRef-Callaway-* temporaire et conforme au standard SPDX, mais qui doit être remplacée par l’identifiant de licence correct provenant de l’organisation SPDX.

La prise en charge dans NetworkManager des profils de connexion stockés au format ifcfg a été supprimée. Ce format est considéré comme obsolète en upstream et le format natif Keyfile prend sa succession. Les paquets suivants sont donc abandonnés : NetworkManager-initscripts-ifcfg-rh, NetworkManager-dispatcher-routing-rules et NetworkManager-initscripts-updown.

Afin de prendre en charge le renforcement général de la sécurité des systèmes, les logiciels doivent pouvoir s’exécuter avec le moins de privilèges possible : c’est pourquoi le service SSSD est désormais configuré de manière à pouvoir être exécuté par l’utilisateur sssd, en plus de l’utilisateur root. Cela signifie que l’utilisateur des services systemd SSSD est maintenant défini par défaut sur sssd. Quel que soit l’utilisateur choisi, toutes les capacités root sont abandonnées, à l’exception de certains processus privilégiés auxiliaires.

L’outil sss_ssh_knownhostsproxy est obsolète depuis la dernière version de Fedora et a désormais été retiré des dépôts. L’outil sss_ssh_knownhosts le remplace. Utilisez man sss_ssh_knownhosts(1) pour apprendre à l’utiliser.

Précédemment, l’Édition Fedora Cloud définissait le paramètre de la ligne de commande du noyau net.ifnames=0 pendant le processus Kickstart. Cela avait pour effet de désactiver le nommage stable des périphériques réseau et de s’assurer que les périphériques Ethernet conservaient leurs noms traditionnels tels que eth0, eth1, etc. Avec cette mise à jour, net.ifnames=0 a été supprimé du fichier Kickstart de Fedora Cloud afin d’assurer la stabilité du nommage des périphériques réseau et être en cohérence avec les autres Éditions Fedora.

Avec cette mise à jour, le paquet network-scripts, obsolète depuis longtemps, sera retiré des dépôts. Le paquet fournissait les utilitaires ifup et ifdown, maintenant dépréciés, ainsi que network.service. Ces scripts dépendaient fortement du client DHCP dhclient et, sans développement actif, il n’y a aucune chance de les voir être mis à jour et utiliser un client alternatif.

Paquets dépendant directement ou non de network-scripts :

Notez que ce changement affecte également toutes les personnes utilisant des scripts réseau personnalisés dépendant des fonctionnalités fournies par le paquet network-scripts.

À partir de Fedora 41, toutes les versions prises en charge de Kubernetes, CRI-O et CRI-Tools seront disponibles simultanément. À titre d’exemple, Fedora 41 met à disposition les RPM suivants dès sa sortie :

Il s’agit d’un changement significatif car, dans les versions précédentes de Fedora, seule une version de Kubernetes était disponible dans les dépôts officiels. Les RPM de CRI-O et de CRI-Tools sont également concernés par ce changement : de nouvelles versions de ces outils vont être mises à disposition pour complémenter les nouvelles versions de Kubernetes.

TuneD a remplacé power-profiles-daemon en tant que démon par défaut de gestion des profils d’alimentation dans les variantes de Fedora Workstation suivantes :

Les utilisateur·rices de serveurs peuvent personnaliser les profils d’alimentation exposés à l’environnement de bureau en modifiant le fichier /etc/tuned/ppd.conf. Les utilisateur·rices Workstation peuvent définir le profil d’alimentation par le centre de contrôle graphique.

Le paquet tuned-ppd fournit un remplacement drop-in pour power-profiles-daemon, le permettant d’être utilisé avec les bureaux actuels.

Les applications utilisant déjà power-profiles-daemon peuvent accéder à TuneD sans modifier leur code.

Netavark est un outil de gestion des réseaux de conteneurs utilisé par Podman. Netavark effectue la gestion des interfaces et des règles de pare-feu et, à partir de cette version de Fedora, il utilise nftables par défaut pour la création des règles de pare-feu des conteneurs.

Sur les Bureaux atomiques, la politique contrôlant l’accès au démon rpm-ostree a été mise à jour afin de :

Sur les systèmes Fedora CoreOS et Fedora IoT, le point de montage racine du système (/) est maintenant monté à l’aide de composefs. Dorénavant, ce système de fichiers est réellement en lecture seule, améliorant l’intégrité et la robustesse du système. Il s’agit d’un premier pas en direction d’une vérification complète en runtime de l’intégrité du système de fichiers.

Sur les Bureaux atomiques, le bootloader est maintenant mis à jour automatiquement à l’aide de bootupd. Les nouveaux systèmes sont désormais installés avec une configuration statique de GRUB reposant uniquement sur les fichiers de configuration Boot Loader Specification et n’est plus régénérée à chaque mise à jour.

Le projet upstream Kubernetes maintient 3 versions à la fois, avec une nouvelle version tous les 4 mois. Précédemment, dans Fedora, seule une de ces versions était toujours fournie et correspondait toujours à une version spécifique. À partir de Fedora 41, toutes les versions de Kubernetes actuellement prises en charge sont fournies, avec des paquets séparés portant le nom de chacune des versions majeures. Par exemple, pour le RPM kubernetes-client, au lieu de fournir le paquet kubernetes-client-1.29.2-1.fc41, Fedora fournit désormais kubernetes1.29-client-1.29.2-1.fc41, kubernetes1.28-client-1.28.5-1.fc41 et kubernetes1.27-client-1.27.8-1.fc41.

La mise à jour vers Fedora 41 d’une machine avec Fedora 40 ou Fedora 39 nécessite que l’utilisateur·ice sélectionne manuellement le paquet Kubernetes désiré.

Pour plus d’informations, consultez la Documentation rapide Fedora.

Fedora 41 est la première version de Fedora fournissant la cible device mapper dm-vdo (optimiseur de données virtuelles, virtual data optimizer) et le paquet vdo contenant les outils associés.

La cible dm-vdo fournit la déduplication inline, la compression, et l’allocation fine et dynamique. Ces fonctionnalités peuvent être ajoutées à la pile de stockage, compatible avec n’importe quel système de fichiers. Une cible dm-vdo peut être alimentée par un maximum de 256 To de stockage et afficher une taille logique maximale de 4 Po. Le développement de cette cible a débuté en 2009. La première sortie publique remonte à 2013, et elle a été utilisée dans des environnements en production depuis lors. Elle a été rendue open-source en 2017, et a été intégrée au noyau Linux upstream en 2024.

Pour prendre en charge les cibles dm-vdo, le paquet vdo fournit les outils suivants :

Des outils de diagnostic supplémentaires sont également inclus dans le paquet vdo. Ils sont néanmoins rarement nécessaires pour une utilisation normale.

Bien que ce ne soit pas obligatoire, il est fortement recommandé d’utiliser lvm2 pour gérer les volumes vdo. Consultez la documentation lvm2 pour plus d’informations.

Si l’un de vos volumes vdo a été créé avec le module kvdo, avant de tenter la mise à niveau vers une cible dm-vdo, assurez-vous de bien avoir lu la documentation kvdo. Elle contient des informations importantes à connaître avant de tenter l’opération.

Consultez la documentation upstream dm-vdo et vdo pour plus de détails.

Cette mise à jour contient stratisd 3.7.3 et stratis-cli 3.7.0, amenant 1 amélioration significative, plusieurs améliorations mineures et un certain nombre de petites améliorations.

Le changement le plus important est que Stratis 3.7.3 permet à un·e utilisateur·ice de rétablir un instantané, c’est-à-dire d’écraser un système de fichiers Stratis avec un instantané. Le processus comprend deux étapes. La première consiste à planifier le rétablissement d’un instantané. Ce rétablissement ne peut avoir lieu qu’au démarrage d’un pool, c’est-à-dire pendant que stratisd s’exécute , ou en arrêtant et en redémarrant le pool. Un rétablissement peut également être provoqué par le redémarrage d’un système où stratisd s’exécute. Le redémarrage de stratisd engendrera le démarrage des rétablissements planifiés, si tenté que le pool contenant le système de fichiers à rétablir ait été arrêté au préalable. Pour prendre en charge cette fonctionnalité, stratis-cli propose deux nouvelles sous-commandes filesystem : schedule-revert et cancel-revert.

Des fonctionnalités supplémentaires ont été ajoutées pour accompagner l’ajout du rétablissement d’instantané. Tout d’abord, le champ origin d’un système de fichiers est désormais inclut dans ses propriétés D-Bus et mis à jour automatiquement. stratis-cli affiche une valeur origin dans la vue détaillée des systèmes de fichiers. stratisd prend également un charge une nouvelle méthode D-Bus filesystem retournant les métadonnées d’un système de fichiers. Les commandes filesystem de débogage dans stratis-cli incluent une option get-metadata qui affiche les métadonnées d’un système de fichiers ou d’un pool donné. Des fonctionnalités équivalentes pour les métadonnées des pools ont également été ajoutées.

stratisd inclut également un nombre considérable de mises à jour de dépendances, de corrections mineures et de nouveaux tests, tandis que stratis-cli inclut des améliorations à l’implémentation de son analyseur de ligne de commande.

Consultez l’historique des modifications de stratisd et stratis-cli pour plus d’informations à propos de ces nouvelles versions.

Fedora 41 fournit un nouvel outil pour interroger les dépôts, fedora-repoquery, un petit outil en ligne de commande servant à effectuer des repoqueries vers les dépôts Fedora, EPEL, eln et CentOS Stream. Il appelle dnf repoquery en séparant les données des dépôts mises en cache pour accélérer les interrogations.

Consultez le readme upstream pour connaître des exemples d’utilisation, ou utilisez fedora-repoquery --help une fois l’installation terminée.

OpenSSL dans Fedora 41 ne fait plus confiance par défaut aux signatures SHA-1 et empêche également leur création. Ce changement fait suite à la découverte d’un nombre grandissant d’attaques de collision avec préfixe choisi. Cela améliore les paramètres de sécurité par défaut de Fedora et les rapproche de ce qui est considéré comme sécurisé dans le paysage de la cryptographie moderne.

Vous pouvez rétablir le comportement par défaut précédent au niveau du système en utilisant update-crypto-policies --set FEDORA40, ou par processus avec runcp FEDORA40 command args (outil crypto-policies-extra disponible sur Copr). Ces anciennes politiques seront conservées dans Fedora pendant quelques versions majeures. Notez néanmoins que leur utilisation est généralement déconseillée.

Les créations de paquet Fedora sont désormais plus déterministes qu’avant, faisant avancer l’objectif de la distribution d’avoir l’ensemble de ses paquets pouvant être créés de manière reproductible.

Pour plus d’informations, consultez la documentation Reproducible Builds de Fedora.

Le réseau virtuel libvirt a été modifié de manière à privilégier l’utilisation du backend de pare-feu nftables à la place de iptables.

Ce changement pourrait impacter la compatibilité, consultez la page Change pour connaître les détails et les solutions de contournement.

Redis a été remplacé par Valkey dans Fedora 41 en raison du changement de licence de Redis. En effet, la licence RASLv2/SSPL est incompatible avec les principes du logiciel libre et open-source. Valkey est un remplacement complet de Redis qui préserve la licence BSD originale.

En passant à Fedora Linux 41 sur les systèmes avec redis, ce dernier sera remplacé par valkey grâce au paquet valkey-compat. Ce changement devrait être globalement invisible aux yeux des utilisateur·rices car le paquet valkey-compat propose la migration de la configuration et des données dans les cas les plus courants. Les unités systemd valkey auront des alias pour redis, vous facilitant la migration.

Les moteurs OpenSSL sont considérés comme obsolètes à partir de Fedora 41. Ces moteurs ne sont pas FIPS-compatibles et l’API associée est considérée comme obsolète à partir de OpenSSL 3.0. Nous recommandons aux personnes utilisant les moteurs OpenSSL de passer aux fournisseurs (providers).