Changements dans Fedora 42 pour les administrateur·rices système

Vous trouverez des notes supplémentaires en accédant à la documentation upstream.

Des images pour l’architecture alternative RISC-V sont maintenant disponibles pour Fedora 42, sans prise en charge officielle, pour les variantes de serveur, de cloud et de conteneurs. Pour plus d’informations, consultez le message d’annonce sur Fedora Discussion.

Dans Fedora 42, le répertoire /usr/sbin devient un lien symbolique vers bin, ce qui signifie que les chemins d’accès comme /usr/bin/foo et /usr/sbin/foo pointent maintenant vers le même endroit. /bin et /sbin sont déjà des liens symboliques vers /usr/bin et /usr/sbin, donc /bin/foo et /sbin/foo pointent également vers le même endroit. /usr/sbin sera retiré du $PATH par défaut. Le même changement s’applique également à /usr/local/sbin qui pointe vers /bin : /usr/local/bin/foo et /usr/local/sbin/foo pointent donc vers le même endroit.

La définition de %_sbindir a été modifiée en %_bindir, les paquets utiliseront donc le nouveau répertoire après un nouveau build sans autre action nécessaire.

Les mainteneur·ses peuvent arrêter d’utiliser %_sbindir, sans en être obligé·es.

Dans Fedora 42, le boot-splash (plymouth) utilise maintenant par défaut le framebuffer du micrologiciel EFI pour afficher le boot-splash plus tôt pendant le démarrage.

Puisque le framebuffer EFI ne fournit pas le DPI de l’écran, plymouth essaie désormais de deviner si une mise à l’échelle HiDPI 2x doit être appliquée en se basant sur la résolution d’écran. Fedora 42 est donc susceptible d’utiliser un facteur de mise à l’échelle du bootsplash différent que par le passé.

L’ancien comportement consistant à attendre que le pilote GPU soit chargé avant d’afficher le splash peut être rétabli en exécutant :

Le facteur de mise à l’échelle peut également être défini manuellement en exécutant :

Modifiez =1 en =2 pour forcer la mise à l’échelle 2x. Notez que si ce paramètre est utilisé, le facteur spécifié s’appliquera à tous les écrans.

Sinon, au lieu d’utiliser la ligne de commande du noyau, ces paramètres peuvent être configurés en modifiant /etc/plymouth/plymouthd.conf. Décommentez la ligne [Daemon] et ajoutez :

Après avoir modifié /etc/plymouth/plymouthd.conf, l’initrd doit être régénéré de manière à contenir la nouvelle version du fichier en exécutant sudo dracut -f.

L’utilitaire fips-mode-setup a été retiré de Fedora. Pour mettre en place le mode FIPS sur un système, les options suivantes s’offrent à vous :

Passer un système en mode FIPS après l’installation n’est plus recommandé. Par exemple, le chiffrement des disques avec LUKS, ou la génération de clés OpenSSH effectuent des choix algorithmiques pendant l’installation ou le premier démarrage qui ne sont pas conformes FIPS si le mode FIPS n’est pas activé pendant l’installation ou le premier démarrage.

Si vous devez quand même passer un système en mode FIPS après l’installation et êtes conscient·e des risques, vous pouvez ajouter l’argument fips=1 à la ligne de commande du noyau. Notez que si /boot est sur une partition séparée, vous devrez aussi ajouter l’UUID de la partition à la ligne de commande pour que le module dracut d’initramfs dédié aux FIPS puisse trouver le noyau et son fichier checksum, ou le démarrage échouera. La commande suivante effectue ceci en une seule étape :

Pour désactiver le mode FIPS, vous devriez réinstaller le système. Si vous avez besoin de le désactiver sur un système existant – ce qui est déconseillé – vous pouvez utiliser grubby à nouveau pour supprimer l’argument de ligne de commande fips=1.

Le mécanisme intégré à RPM de création d’utilisateurs système à partir des métadonnées sysusers.d distribuées par les paquets peut maintenant être utilisé pour créer des utilisateurs système, évitant le besoin d’utiliser des scriptlets RPM personnalisés pour chaque paquet.

Pour plus d’informations à propos de la création d’utilisateurs à l’aide de sysusers.d, consultez la documentation RPM upstream.

Sur les systèmes Fedora à Bureau atomique, la racine du système (/) est maintenant montée à l’aide de composefs, la rendant réellement en lecture seule. Cela améliore l’intégrité du système et sa robustesse, et constitue une première étape en direction d’une vérification en runtime complète de l’intégrité du système de fichiers.

Ce changement fait suite à un changement similaire dans Fedora 41 qui activait ComposeFS par défaut dans les Éditions Fedora CoreOS et IoT.

À partir de Fedora 42, les Bureaux atomiques Fedora ne sont plus disponibles pour l’architecture PPC64LE (POWER 64 bits petit-boutiste) en raison d’un manque d’intérêt. Les personnes souhaitant utiliser un Bureau atomique sur un tel système doivent donc se rabattre sur une installation classique de Fedora, ou construire leurs propres images à partir des conteneurs bootables disponibles pour PPC64LE.

Les versions précédentes de Fedora IoT utilisaient le serveur d’approvisionnement Zezere pour la configuration initiale. Cette approche causait des problèmes pour certain·es utilisateur·rices, notamment celleux utilisant IPv6. À partir de Fedora 42, Zezere est remplacé par systemd-firstboot. Les utilisateur·rices qui ne pouvaient pas utiliser Zezere peuvent désormais configurer leur système plus facilement, engendrant moins de frustration lors de l’expérience cruciale de premier démarrage.

La section Bien démarrer de la documentation Fedora IoT a été mise à jour en accord avec ce changement.

Fedora CoreOS reçoit désormais ses mises à jour à partir de link:https://quay.io/fedora/fedora-coreos, remplaçant le dépôt OSTree Fedora. L’ancien dépôt OSTree continuera à être actif jusqu’à la sortie de Fedora 43. Les images disque seront mises à jour en premier : les nouvelles installations de Fedora CoreOS basées sur Fedora 42 utiliseront donc directement les images OCI. Les nœuds existants seront migrés à l’avenir.

Ce changement aide à mettre en phase Fedora CoreOS avec l’initiative actuelle des conteneurs bootables.

Fedora est mis à disposition sous la forme d’un conteneur bootable grâce au registre OCI. L’installation s’effectue typiquement en convertissant le conteneur en une image de VM ou un ISO d’installation à l’aide d’osbuild (Image Builder). Il peut toutefois être intéressant de démarrer à partir du réseau pour effectuer des déploiements bare-metal sur une flotte. Les fichiers nécessaires pour ces déploiements n’étaient jusqu’ici pas disponibles dans le dépôt OCI et ne pouvaient donc pas être récupérés à l’aide du registre ; cela évolue à partir de Fedora 42.

Jusqu’ici, les fichiers Kickstart étaient disponibles uniquement dans le dépôt RPM Fedora. La récupération des assets nécessaires était laborieuse : il fallait trouver la version correcte du dépôt RPM puis extraire les fichiers nécessaires. À partir de Fedora 42, un dépôt OCI contenant ces fichiers est disponible et ils peuvent maintenant être récupérés simplement à partir du registre.

Les fichiers Kickstart continueront aussi à être distribués dans les dépôts RPM.

Consultez la page Change sur le wiki Fedora pour plus d’informations.

Fedora fournit maintenant des images WSL (Windows Subsystem for Linux). Elles sont disponibles au téléchargement sur la page de téléchargement de Fedora Cloud.

WSL est un sous-système Windows permettant aux utilisateur·rices de Windows d’utiliser facilement plusieurs distributions Linux sous la forme de conteneurs exécutés au sein d’une même machine virtuelle gérée par un hôte Windows.

Le conteneur Fedora de base peut déjà être utilisé avec WSL, mais il n’est pas idéal puisqu’il exclut intentionnellement la documentation et les outils non essentiels, que cette image Fedora Cloud fournit.

Pour apprendre à utiliser ces images, consultez la documentation Fedora Cloud.

Dans cette version de Fedora, le paquet ansible a été mis à jour vers la version 11. Les changements sont nombreux ; pour consulter la liste complète, consultez la documentation upstream.

Le paquet ansible-core a également été mis à jour vers la version 2.18. Quelques changements à noter :

Pour plus de détails, consultez la documentation upstream.

Intel Software Guard Extensions (SGX) est une technologie permettant la création d’enclaves d’exécution. Leur mémoire est chiffrée et donc protégée du reste du code s’exécutant sur le CPU, dont System Management Mode (SMM), le micrologiciel, le noyau et le user space.

Cette mise à jour de Fedora fournit la pile logicielle d’hôte SGX, les enclaves d’architecture et les paquets de développement. Ce changement se concentre sur l’activation générale de l’infrastructure logicielle. Le but futur est d’introduire les applications et les fonctionnalités dépendant de SGX.

Fedora 42 introduit une nouvelle manière de gérer l’installation de paquets RPM à partir des dépôts alors que des clés PGP expirées sont encore présentes sur le système. Ces clés devaient jusqu’ici être supprimées manuellement en exécutant rpmkeys --delete. À partir de cette version, les clés expirées seront détectées automatiquement avant toute transaction DNF et gérées de manière appropriée grâce à un nouveau plugin libdnf5 activé par défaut.

Pour les personnes utilisant le mode interactif, une invite apparaîtra pour les informer à chaque clé expirée sur le système et demander une confirmation avant de les supprimer. Pour celleux utilisant le mode non interactif, le workflow reste le même.

Cette mise à jour améliore le téléchargement et l’installation des mises à jour dans Fedora. Ce changement fournit une meilleure expérience utilisateur en réduisant la quantité de ressources I/O requises et retarde le coût CPU de la décompression de paquets. Par conséquent, l’OS installe et met à jour les paquets plus rapidement.

Notez que ce comportement n’est pas activé par défaut et que, pour le moment, il doit être activé explicitement.

Stratis 3.8.0, comprenant stratisd 3.8.0 et stratis-cli 3.8.0, contient deux améliorations significatives ainsi qu’un certain nombre d’améliorations mineures.

L’amélioration la plus importante est l’arrivée d’une pile stockage améliorée. La motivation derrière ce changement et la structure globale de la pile stockage est décrite [dans une publication séparée].

Stratis 3.8.0 introduit également la prise en charge de plusieurs bindings pour les chiffrements utilisant le même mécanisme. Jusqu’ici, Stratis n’autorisait qu’un seul binding qui utilisait une clé dans le trousseau du noyau. Maintenant, plusieurs bindings avec différentes clés peuvent être utilisées dans le même pool. De manière analogue, plusieurs bindings utilisant un mécanisme de chiffrement Clevis peuvent être utilisés dans le même pool. Le nombre total de bindings est limité à 15.

Ce changement rend possible de nombreux nouveaux cas d’utilisation. Par exemple, un pool peut être configuré de manière à pouvoir être déverrouillé avec une clé appartenant à un·e administrateur·rice de stockage, pour la maintenance obligatoire occasionnelle, et une autre clé appartenant à la personne désignée comme utilisateur·rice du pool.

Jusqu’ici, en démarrant un pool chiffré, l’utilisateur·rice était obligé·e de désigner une méthode de déverrouillage : clevis ou keyring. Puisque cette nouvelle version permet l’utilisation de plusieurs bindings par méthode de déverrouillage, elle introduit aussi une méthode plus générale pour spécifier un mécanisme de déverrouillage au démarrage du pool. L’utilisateur·rice peut spécifier --unlock-method=any et toutes les méthodes disponibles seront testées. L’utilisateur·rice peut aussi spécifier que le pool doit être ouvert avec un binding particulier, à l’aide de l’option --token-slot. Ou bien l’utilisateur·rice peut choisir de saisir une phrase secrète pour déverrouiller le pool, soit en spécifiant l’option --capture-key, soit en utilisant un keyfile avec l’option --keyfile-path. De même, l’option unbind requiert désormais que l’utilisateur·rice spécifie un emplacement de jeton particulier à l’aide de l’option --token-slot si le pool a plus d’un binding avec la même méthode.

Cette version contient également un certain nombre d’améliorations internes, de corrections de bugs mineurs et des mises à jour de dépendances.

Consultez le journal des modifications de stratisd et de stratis-cli pour en savoir plus sur cette nouvelle version.

La bibliothèque de compression zlib-ng a été mise à jour dans Fedora 42 vers la version 2.2.4. Cette nouvelle version fournit de nouvelles optimisations, la réécriture de l’allocation de mémoire pour la fonction deflate, et améliore les systèmes de construction et les tests.

Vous trouverez les notes de version pour la version 2.2 aux liens suivants :

Apache Traffic Server a été mis à jour vers la version 10.x. Le fichier /etc/trafficserver/records.config sera automatiquement mis à jour vers le nouveau format records.yaml. Des étapes de mise à jour supplémentaires peuvent être nécessaires si vous utilisez des fonctionnalités ou des API qui ne sont plus disponibles : passez en revue la documentation upstream pour savoir si vous êtes concerné·e.

Fedora 42 fournit le paquet bpfman.

Bpfman est une pile logicielle simplifiant la gestion des programmes eBPF dans les clusters Kubernetes ou sur les hôtes indépendants. Il est composé d’un démon système (bpfman), de définitions de ressources personnalisées (CRD), d’un agent (bpfman-agent) et d’un opérateur (bpfman-operator). Développé en Rust et reposant sur la bibliothèque Aya, bpfman offre une meilleure sécurité, visibilité et prise en charge multiprogrammes, ainsi qu’une meilleure productivité pour les développeur·ses.

Pour Fedora, intégrer bpfman représente une clarification du chargement de programmes eBPF. Il améliore la sécurité en restreignant les privilèges au démon bpfman contrôlé, simplifie le déploiement dans les clusters Kubernetes et offre une visibilité améliorée dans les programmes eBPF en cours d’exécution. Cette intégration est dans la droite ligne de l’engagement de Fedora en faveur de solutions efficaces et sécurisées, et permet aux utilisateur·rices de tirer partie plus facilement des avantages émanant de l’utilisation d’eBPF dans leurs systèmes.

Les variantes de Fedora Workstation utilisent par défaut des vérifications de connectivité. Ces vérifications peuvent échouer pour les hôtes à plusieurs réseaux (par ex. LAN + Wi-Fi) où firewalld utilise IPv6_rpfilter=strict. C’est pourquoi, à partir de Fedora 42, Fedora Workstation définit IPv6_rpfilter=loose par défaut pour permettre aux vérifications de connectivité de fonctionner comme prévu.

Pour les systèmes mis à jour vers Fedora 42, IPv6_rpfilter est défini en fonction de l’état du fichier /etc/firewalld/firewalld.conf. S’il est intact, le processus de mise à jour RPM modifiera la configuration et définira IPv6_rpfilter=loose. S’il a été modifié, alors la configuration existante ne sera pas modifiée.

Notez que cette modification est purement downstream : l’upstream continue d’utiliser par défaut IPv6_rpfilter=strict.

Fedora 42 remplace le plugin Cockpit Navigator par Cockpit Files. L’année dernière, le projet Cockpit a sorti le nouveau plugin Cockpit Files, un plugin officiellement pris en charge destiné à fournir une alternative moderne au plugin Cockpit de navigateur existant. La dernière version (14) prend en charge tout ce que Cockpit Navigator prenait en charge, à l’exception des liens symboliques, dont l’implémentation est planifiée.

Le remplacement de cockpit-navigator par cockpit-files entraîne une modification visuelle dans Cockpit : l’entrée de menu Navigateur sera remplacée par une nouvelle entrée de menu Explorateur de fichiers, accessible sous Outils.

L’interface de cockpit-files est différente de celle de cockpit-navigator mais offre les mêmes fonctionnalités, à l’exception de la création de liens symboliques. cockpit-files utilise le kit d’outils PatternFly pour son interface, améliorant la cohérence de l’interface de Cockpit.

Fedora 42 permet aux hôtes de virtualisation de lancer des machines virtuelles confidentielles grâce à la technologie SEV-SNP d’AMD. La virtualisation confidentielle empêche l’accès à la mémoire de tout invité en cours d’exécution par les administrateur·rices avec un accès root, ou par une pile logicielle qui aurait été compromise. SEV-SNP est une évolution des technologies SEV et SEV-ES fournies précédemment, et fournit une protection plus forte et de nouvelles fonctionnalités telles que l’utilisation d’un TPM virtuel sécurisé.

Fedora fournit maintenant un mécanisme permettant le chargement automatique de binaires optimisés pour les versions récentes de l’architecture x86_64 grâce à glibc-hwcaps. Les utilisateur·rices sont susceptibles de remarquer une exécution plus rapide des binaires contenus dans un paquet où lae mainteneur·se a activé manuellement ce mécanisme. Pour une explication complète du mécanisme, consultez la page Change sur le wiki Fedora.

PostgreSQL en version 15 sera retiré de Fedora 42 en raison de l’existence de versions plus récentes (16 et 17). La version 16 est déjà la version par défaut (annoncé lors du passage à PostgreSQL 16) et la version 17 constitue une alternative.

Si vous n’avez toujours pas mis à jour vers la version 16, vous devriez suivre la stratégie de mise à jour standard :

Le paquet opendmarc contenait jusqu’ici un ensemble de binaires facultatifs secondaires qui ne sont pas requis pour la configuration du service et qui engendraient la récupération d’un grand nombre de paquets supplémentaires (plus de 80) considérés comme dépendances. À partir de Fedora 42, le paquet opendmarc ne contient plus que les utilitaires essentiels, et les outils supplémentaires peuvent être installés séparément si besoin, économisant potentiellement de l’espace pour celles·eux ne les utilisant pas. Les nouveaux paquets séparés sont :

Jusqu’ici, le paquet git était complexe, divisé en de nombreux sous-paquets, et fournissait le binaire git. Si vous vouliez satisfaire les paquets exigeant le binaire git, vous deviez subir un processus d’installation long et intensif en terme de calcul. Avec cette mise à jour, le binaire git est maintenant fourni par le paquet git-core, ce qui devrait réduire le nombre de paquets installés en tant que dépendances transitoires du paquet principal.

Les environnements Fedora Linux live utilisent désormais Enhanced Read-Only FileSystem (EROFS), un système de fichiers moderne et riche en fonctionnalités.

Le paquet pam_ssh_agent_auth n’est plus disponible dans Fedora 42 en raison de son obsolescence et de sa faible utilisation.