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

Changements dans le programme d’installation Anaconda

Activation par défaut de Anaconda WebUI sur Workstation

À partir de Fedora 42, l’Édition Workstation contient une nouvelle interface d’installation basée sur Patternfly. L’ancien modèle « Hub & Spoke » est remplacé par une interface de type « Wizard » (assistant) avec une séquence d’étapes devant être effectuées dans un ordre précis. Cette interface intègre aussi dans un panneau latéral une aide simplifiée mais complète, remplaçant l’aide accessible précédemment dans une fenêtre séparée.

Sélection d’une langue dans la nouvelle interface Web.
Figure 1. Premier écran de la nouvelle interface

La nouvelle interface est simplifiée, mais les utilisateur·rices ayant besoin des options avancées de configuration du stockage peuvent toujours y accéder à partir de la seconde étape d’installation (Méthode d’installation) en appuyant sur le bouton Menu () dans le coin supérieur droit.

Nouvel éditeur de stockage.
Figure 2. Nouvel écran de partitionnement personnalisé

Dans un premier temps, la nouvelle interface sera disponible uniquement dans Fedora Workstation ; les autres Éditions suivront dans les versions futures de Fedora.

Pour plus d’informations à propos de la nouvelle interface et de son développement, lisez le billet sur le Fedora Community Blog et la la partie Detailed Description de la page Change sur Fedora Wiki.

Anaconda est maintenant une application Wayland native

Le programme d’installation Anaconda est maintenant une application Wayland native. Anaconda fonctionnait auparavant en tant qu’application Xorg ou reposait sur XWayland. En implémentant cette mise à jour, Anaconda peut se débarrasser des dépendances X11 et accueillir de nouvelles technologies plus sûres.

Notez qu’il n’est plus possible d’utiliser TigerVNC pour accéder à distance à l’interface pendant l’installation en raison de la dépendance de TigerVNC sur X11. Les installations à distance doivent désormais utiliser une application prenant en charge le protocole Bureau à distance (RDP) telle que GNOME Remote Desktop (grd). En accord avec ce changement, les options de démarrage suivantes ont été ajoutées : inst.rdp, inst.rdp.username, inst.rdp.password. Les options de démarrage suivantes ont été retirées : inst.vnc, inst.vncpassword, inst.vncconnect. La commande Kickstart vnc a aussi été retirée.

GPT est maintenant utilisé par défaut sur toutes les architectures

Anaconda utilise maintenant GUID Partition Table (GPT) à la place de Master Boot Record (MBR) comme table de partitionnement (disklabel) par défaut sur toutes les architectures. C’était déjà le cas sur les systèmes x86_64, et la nouvelle valeur par défaut est maintenant appliquée aux installations sur toutes les architectures.

Unification de /usr/bin et /usr/sbin

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.

Plymouth : utilisation par défaut de simpledrm

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 :

sudo grubby --update-kernel=ALL --args="plymouth.use-simpledrm=0"

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

sudo grubby --update-kernel=ALL --args="plymouth.force-scale=1"

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 :

  • UseSimpledrm=1 et/ou

  • DeviceScale=1 ou DeviceScale=2

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.

fips-mode-setup a été retiré de Fedora

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 :

  • Ajouter fips=1 à la ligne de commande du noyau du programme d’installation Fedora. Sur les systèmes basés sur UEFI, il s’agit généralement d’appuyer sur la touche e pendant que GRUB affiche le menu de démarrage. Après avoir ajouté fips=1, appuyez sur Ctrl+X pour continuer le démarrage.

  • Créer une image Fedora à l’aide du Image Builder avec la personnalisation suivante :

    [customizations]
    fips = true

    Voici un fichier blueprint d’exemple :

    name = "fedora42-fips"
    distro = "fedora-42"
    description = "Une image Fedora où FIPS est activé"
    version = "0.0.1"
    modules = []
    groups = []
    
    [customizations]
    fips = true
  • Créer une image disque avec bootc et activer le mode FIPS en utilisant les instructions suivantes dans le Containerfile :

    Containerfile
    FROM quay.io/fedora/fedora-bootc:42
    
    # Activer la crypto policy FIPS
    # crypto-policies-scripts n'est pas installé par défaut
    RUN dnf install -y crypto-policies-scripts && update-crypto-policies --no-reload --set FIPS
    
    # Activer l'argument de noyau fips=1 : https://bootc-dev.github.io/bootc/building/kernel-arguments.html
    # Ce fichier doit contenir 'kargs = ["fips=1"]'
    COPY 01-fips.toml /usr/lib/bootc/kargs.d/

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 :

grubby \
  --update-kernel=ALL \
  --args="fips=1 boot=UUID=$(blkid --output value --match-tag UUID "$(findmnt --first --noheadings -o SOURCE /boot)")"

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.

Intégration de systemd-sysusers à RPM

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.

ComposeFS activé par défaut pour les Bureaux atomiques Fedora

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.

Les Bureaux atomiques ne sont plus compilés pour PPC64LE

À 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.

Retrait du serveur d’approvisionnement Zezere (IoT)

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.

Mises à jour de Fedora CoreOS déplacées d’OSTree à OCI

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.

Distribution de fichiers Kickstart sous la forme d’artéfacts OCI

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.

Images WSL de Fedora

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.

Ansible 11

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 :

  • Abandon de Python 3.10 et ajout de Python 3.13 pour le code des contrôleurs.

  • Abandon de Python 3.7 et ajout de Python 3.13 pour le code cible.

  • Ajout de la fonctionnalité break pour les boucles de tâches.

  • Ajout de nouveaux mount facts non locaux.

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

Activation générale d’Intel SGX

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.

Gestion des clés PGP expirées dans DNF5

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.

Fedora prend en charge le Copy on Write

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.

Nouveau processus d’installation de paquets
  1. Résoudre la requête de packaging en créant une liste de paquets et d’opérations.

  2. Télécharger et décompresser les paquets pour créer un fichier rpm optimisé localement.

  3. Installer et/ou mettre à jour les paquets de manière séquentielle à l’aide des fichiers rpm. Le processus utilise le lien de références (reflinking) pour réutiliser les données déjà présentes sur le disque.

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

Stratis 3.8 : stratisd 3.8.0 et stratis-cli 3.8.0

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.

ZlibNG 2.2

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 :

Trafficserver 10.0

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.

Bpfman ajouté à Fedora

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.

Définition de IPv6_rpfilter (Firewalld) sur loose sur les stations de travail

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 (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.

cockpit-navigator remplacé par cockpit-files

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.

Hôte de virtualisation confidentielle avec AMD SEV-SNP

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é.

Binaires optimisés pour l’architecture x86_64

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.

Retrait de PostgreSQL 15

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 :

Mise à jour « dump and restore »
  1. Arrêtez le service postgresql

  2. Créez un dump des bases de données en exécutant su - postgres -c pg_dumpall  /CHEMIN/VERS/fichier_dump_pg.sql

  3. Sauvegardez toutes les données dans /var/lib/pgsql/data/

  4. Enumérez tous les paquets basés sur postgresql en exécutant rpm -qa | grep postgresql

  5. Mettez à jour tous les paquets PostgreSQL (énumérés à l’étape précédente) en utilisant (ex. pour mettre à jour vers PG-16) dnf install NOM_DES_PAQUETS --allowerasing

  6. Copiez les anciens fichiers de configuration vers /var/lib/pgsql/data/

  7. Démarrez le service postgresql

  8. Importez les données du fichier de dump en exécutant su - postgres -c 'psql -f /CHEMIN/VERS/fichier_dump_pg.sql postgres'

Mise à jour rapide à l’aide de pg_upgrade
  1. Arrêtez le service postgresql

  2. Sauvegardez toutes les données dans /var/lib/pgsql/data/

  3. Enumérez tous les paquets basés sur postgresql en exécutant rpm -qa | grep postgresql

  4. Mettez à jour tous les paquets PostgreSQL (énumérés à l’étape précédente) en utilisant (ex. pour mettre à jour vers PG-16) dnf install NOM_DES_PAQUETS --allowerasing

  5. Installez le paquet de mise à jour dnf install postgresql-upgrade

  6. Exécutez postgresql-setup --upgrade

  7. Copiez les anciens fichiers de configuration vers /var/lib/pgsql/data/

  8. Démarrez le service postgresql

Séparation de OpenDMARC en plusieurs paquets

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 :

  • opendmarc-check

  • opendmarc-expire

  • opendmarc-import

  • opendmarc-importstats

  • opendmarc-params

  • opendmarc-reports

Les paquets nécessitant le binaire git dépendent maintenant du paquet git-core.

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.

Le support live utilise désormais le système de fichiers EROFS à la place de SquashFS

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

pam_ssh_agent_auth retiré de Fedora

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