Changements dans Fedora 40 pour les administrateurs système

Programme d’installation

Pour la liste des changements dans Anaconda, le programme d’installation de Fedora, et les composants connexes tels que Kickstart, consultez les notes de version upstream.

Conteneur amorçable Fedora IoT

Il existe désormais une image amorçable de Fedora IoT. Cette nouvelle manière d’utiliser Fedora IoT peut mieux correspondre aux environnements et aux écosystèmes des utilisateurs, permettant une adoption plus large.

Vous pouvez télécharger la nouvelle image sur la page officielle de Fedora IoT. Consultez également la documentation.

389 Directory Server 3.0.0

Fedora 40 provides a new major release of 389 Directory Server, a significant upgrade from version 2.4.4 available in previous releases.

Un des changements majeurs est que, à partir de cette version, les nouvelles instances sont créées en utilisant LMDB par défaut, au lieu de BerkeleyDB, utilisé précédemment par défaut. Voir ici pour plus d’informations.

pam_userdb passe à GDBM

pam_userdb a été construite en prenant en charge BerkeleyDB, mais ce projet n’est plus maintenu en open source. Il a donc été remplacé par GDBM dans Fedora 40. Consultez le guide de l’administrateur système Fedora pour savoir comment effectuer la conversion.

Fonctionnalité enumeration supprimée des backends AD et IPA

La fonctionnalité enumeration fournit la possibilité de lister les utilisateurs et les groupes en utilisant getent passwd et getent group sans argument. Cette fonctionnalité a été supprimée des fournisseurs AD et FreeIPA.

L’outil sss_ssh_knownhostsproxy sera remplacé dans les versions futures de Fedora

L’outil sss_ssh_knownhostsproxy est désormais obsolète et sera remplacé par une nouvel outil plus efficace. Consultez le ticket upstream pour connaître les détails.

Suppression de l’option files provider de SSSD

La fonctionnalité files provider de SSSD, rendue précédemment obsolète et qui permet de gérer les utilisateurs locaux, a été supprimée dans Fedora 40. Cela n’affecte pas la configuration par défaut lorsque les utilisateurs locaux sont gérés par le module glibc (libnss_files.so.2), ce qui est le cas la plupart du temps. Si vous avez une configuration spécifique qui nécessite la gestion des utilisateurs locaux par SSSD (comme l’authentification par smart card ou l’enregostrement des sessions des utilisateurs locaux), passez à proxy provider. Si vous êtes concerné·e, consultez la documentation upstream pour plus de détails.

Profil minimal de Authselect remplacé par le profil local

Le profil minimal de Authselect est désormais remplacé par le profil local. Ce nouveau profil est basé sur le précédent mais contient de nouvelles fonctionnalités optionnelles. Il est utilisé pour servir les groupes et les utilisateurs locaux sans SSSD. Cette migration du profil minimal à local est effectuée automatiquement en installant Fedora 40 ou en effectuant la mise à jour et les utilisateurs ne sont pas affectés. Toutefois, vous devez adapter vos scripts au nouveau profil local puisque le profil minimal n’est plus disponible.

bogofilter et SQLite

Bogofilter (paquet bogofilter) est un mécanisme de filtrage antispam rapide utilisant l’analyse statistique bayésienne pour classer les e-mails comme spam ou non-spam. Il utilise Berkeley DB (paquet libdb) comme moteur de base de données pour stocker les probabilités de mots et d’autres données pertinentes au processus de filtrage.

Avec cette version de Fedora, Bogofilter change de moteur de base de données, passant de Berkeley DB à SQLite, car libdb est désormais obsolète dans Fedora.

Bogofilter ne prend en charge qu’un seul backend de base de données à la fois, c’est pourquoi le paquet bogofilter mis à jour ne sera pas en capacité de traiter les données libdb. En réponse à cela, le nouveau paquet fournit un script de migration ; ou bien, si vous le préférez, vous pouvez migrer vos listes de mots manuellement avec la commande bogomigrate-berkeley ~/.bogofilter/wordlist.db.

Podman 5

Le moteur de conteneur podman a été mis à jour vers la version 5, qui contient de nombreuses corrections de bugs et améliorations. Les changements à noter comprennent :

  • abandon des cgroups version 1 (les environnements doivent passer aux cgroups version 2) ;

  • les plugins Container Networking Interface (CNI) sont désormais obsolètes (les environnements doivent passer à la pile réseau netavark) ;

  • BoltDB est désormais obsolète ;

  • passt a été défini comme service réseau sans root par défaut, remplaçant slirp4netns ;

  • amélioration de la gestion du fichier containers.conf ;

  • les bindings podman sont maintenant isolés pour améliorer leur utilisation.

Pour tout savoir sur ces mises à jour, consultez les notes de version upstream.

ROCm 6

ROCm, la pile de calcul d’unité de traitement graphique (GPU), a été mise à jour vers la version 6, qui contient de nombreuses corrections de bugs et améliorations. Les changements à noter comprennent :

  • meilleures performances dans certaines opérations, telles que les opérations mathématiques de plus faible précision et les Attention Layers ;

  • nouvelle bibliothèque hipSPARSELt, accélérant les charges de travail d’IA en utilisant la technique de matrice creuse d’AMD ;

  • prise en charge des nouvelles versions des frameworks d’IA tels que PyTorch, TensorFlow et JAX ;

  • ajout de la prise en charge de bibliothèques telles que DeepSpeed, ONNX-RT et CuPy ;

Pour tout savoir sur ces mises à jour, consultez les notes de version upstream.

Stratis 3.6

Cette mise à jour de Fedora inclut les nouvelles versions de stratisd (3.6.7) et stratis-cli (3.6.0).

Ces nouvelles versions contiennent un certain nombre d’améliorations, de corrections de bugs et de nettoyages de code. Voici un bref résumé des changements.

stratisd 3.6.7 inclut la correction d’un bug introduit avec stratisd 3.6.6 qui causait l’échec de l’exécution de la commande stratis-min pool start, quand le pool était chiffré et que le mot de passe pour déverrouiller le pool était spécifié sur la ligne de commande. Il inclut aussi la correction d’un bug introduit avec stratisd 3.6.4 qui empêchait de déverrouiller automatiquement un pool lors du montage d’un système de fichiers spécifié dans /etc/fstab.

stratisd 3.6.6 corrige un bug où le PID d’une instance de stratisd s’exécutant déjà pouvait être mal recopié en essayant de démarrer une nouvelle instance. La nouvelle version inclut également des limites sur la taille des valeurs string dans les métadonnées Stratis au niveau du pool.

stratisd 3.6.5 inclut une modification à son mécanisme de verrouillage interne qui permet à un verrou n’entrant pas en conflit avec un verrou actif de précéder un verrou ayant des conflits. Ce changement rend plus souple une restriction qui assignait une priorité aux verrous en se basant uniquement sur leur ordre en file d’attente.

stratisd 3.6.4 inclut la correction d’un bug lors de l’envoi par stratisd-min de la commande start de stratis-min aux pools non chiffrés. Il capture et journalise également les messages d’erreur émis par les exécutables thin_check et mkfs.xfs.

stratisd 3.6.3 définit explicitement l’option nrext64 à 0 lors de l’invocation de mkfs.xfs. Une version récente de XFS a changé la valeur par défaut à 1. Définir explicitement cette valeur à 0 empêche stratisd de créer des systèmes de fichiers XFS impossibles à monter sur les versions plus anciennes du noyau.

stratisd 3.6.2 corrige la manière dont les Thin Devices sont alloués pour éviter les problèmes d’alignement des sections distinctes du Thin Data Device. Ces problèmes d’alignement peuvent dégrader les performances.

stratisd 3.6.1 inclut la correction d’un problème où stratisd n’arrivait pas à déverrouiller un pool si le pool était chiffré en utilisant à la fois Clevis et le trousseau du noyau, mais que la clé dans le trousseau du noyau était indisponible.

stratisd 3.6.0 étend ses fonctionnalités en permettant à un utilisateur de définir la limite de taille d’un système de fichiers et contient un certain nombre d’améliorations supplémentaires.

L’interface en ligne de commande stratis-cli a été étendue avec la version 3.6.0, avec l’ajout d’une option supplémentaire permettant de définir la limite de taille d’un système de fichiers au moment de sa création, et deux nouvelles commandes filesystem, set-size-limit et unset-size-limit, pour définir ou annuler la limite de taille d’un système de fichiers après qu’il ait été créé.

Toutes les mises à jour comprennent des améliorations internes et des corrections de bugs mineurs.

Veuillez consulter le journal des modifications de stratisd et celui de stratis-cli pour plus de détails.

Abandon des RPM au format delta

Delta RPM (DRPM) est une fonctionnalité qui réduit le temps et les données nécessaires à la mise à jour des paquets en ne téléchargeant que les différences (deltas) entre l’ancienne et la nouvelle version d’un paquet RPM. Ensuite, en utilisant votre version du paquet et la différence, votre système réassemble le paquet RPM complet contenant la nouvelle version du logiciel.

À partir de cette version de Fedora, les DRPM ne seront plus générés lors du processus de composition. De plus, la prise en charge des DRPM dans dnf et dnf5 sera désactivée par défaut. Les raisons principales expliquant ce changement sont les suivantes :

  • Il est impossible de produire des DRPM pour tous les paquets, en raison de la façon dont les DRPM sont générés pendant le processus de composition. Par conséquent, une mise à jour composée de centaines de paquets peut ne contenir qu’une faible portion de paquets avec les DRPM appropriés disponibles dans le dépôt.

  • La reconstruction de la nouvelle version d’un RPM peut échouer. Cela entraîne alors un téléchargement supplémentaire : celui du RPM complet de la nouvelle version.

  • La présence des DRPM dans les dépôts augmente significativement la taille des métadonnées. Ces métadonnées sont nécessaires au téléchargement des mises à jour, que les DRPM soient activés ou non.

Améliorations venant avec ce changement :

  • Simplification du processus de composition pour les dépôts "updates" et "updates-testing", puisque la génération des DRPM est ignorée.

  • Réduction de la bande passante utilisée pour les mises à jour des métadonnées des dépôts.

  • Réduction de l’espace disque nécessaire dans l’infrastructure de Fedora et dans les serveurs miroirs grâce aux métadonnées plus légères et à l’abandon des DRPM.

  • Mises à jour plus fiables pour les utilisateurs.

Arrêt du téléchargement par défaut des listes de fichiers

Les listes de fichiers sont des fichiers XML qui contiennent des métadonnées importantes et des informations facilitant l’installation, la gestion et la maintenance des paquets RPM.

À partir de cette version de Fedora, le comportement de DNF est modifié de façon à ne plus télécharger les listes de fichiers par défaut. La raison est que les métadonnées fournies par les listes de fichiers ne sont pas nécessaires à la majorité des usages et qu’elles sont grandes en taille. Cela rendait l’expérience utilisateur significativement plus lente.

Améliorations notables venant avec ce changement :

  • réduction significative du temps de traitement et des ressources utilisées pour la compilation et l’installation de paquets RPM, la création d’environnements de test, etc. ;

  • baisse des coûts d’opération d’un serveur miroir Fedora ;

  • réduction de la RAM nécessaire au fonctionnement de DNF, ce qui règle certains problèmes se présentant lorsque Fedora est utilisé sur des machines avec peu de mémoire, comme les Raspberry Pi ;

Notez que vous pouvez toujours utiliser DNF sans les métadonnées de listes de fichiers pour trouver les fichiers situés dans les répertoires /usr/bin, /usr/sbin et`/etc`.

wget2 remplace wget

La commande wget dans Fedora 40 utilise Wget2.

GNU Wget2 est le successeur à GNU Wget fournissant une implémentation moderne de wget, épaulée par une nouvelle bibliothèque : libwget2. La raison du passage de wget 1.x à wget2 est de passer à une implémentation avec un développement plus actif et qui fournit une interface plus riche pour exploiter les fonctionnalités de wget.

Activation par défaut de la détection de conflit d’adresse IPv4 dans NetworkManager

La détection de conflit d’adresse IPv4 est désormais activée par défaut dans NetworkManager. En d’autres termes, la RFC 5527 est maintenant activée par défaut avec un intervalle de 200 ms.

Assignation d’adresses MAC uniques et stables pour les connexions Wi-Fi

Fedora 40 adopte stable-ssid comme mode par défaut pour l’assignation d’adresses MAC uniques et stables aux connexions Wi-Fi dans NetworkManager, améliorant la confidentialité sans compromettre la stabilité de la connexion réseau.

Pour mettre en place ce changement, un nouveau fichier a été ajouté, /usr/lib/NetworkManager/conf.d/22-wifi-mac-addr.conf, qui définit wifi.cloned-mac-address=stable-ssid en tant que mode par défaut pour la sélection d’adresse MAC pour les connexions Wi-Fi dans NetworkManager. Le mode stable-ssid génère une adresse MAC différente pour chacun des SSID des réseaux auxquels vous vous connectez, ce qui améliore la confidentialité en rendant plus difficile votre suivi en pistant l’adresse MAC de votre matériel de réseau en réseau.

Cette nouvelle valeur par défaut remplace la valeur par défaut preserve de NetworkManager et s’applique dans Fedora 40 à tous les profils Wi-Fi, existant ou nouveau, tant que la valeur par défaut n’est pas remplacée dans le profil (par exemple en clonant une adresse MAC spécifique dans l’interface graphique de NetworkManager, ou en définissant manuellement le paramètre wifi.clones-mac-address).

Avec l’adoption de stable-ssid en tant que valeur par défaut dans Fedora 40, passer à Fedora 40 entraînera l’application par défaut de cette nouvelle méthode de génération d’adresse MAC, ce qui inclut les profils Wi-Fi existants. Cela pourrait entraîner des changements pouvant potentiellement couper la connexion Wi-Fi, en particulier si vous utilisez certains réseaux avec des fonctionnalités ou des restrictions basées sur l’adresse MAC de l’appareil.

Les utilisateurs devant maintenir une adresse MAC constante pour certains réseaux peuvent le faire en définissant manuellement wifi.cloned-mac-address sur permanent pour certains profils :

nmcli connection modify [$PROFIL] wifi.cloned-mac-address permanent

Remplacez [$PROFIL] par le nom du profil NetworkManager, qui est généralement le SSID. Pour lister les profils par nom, exécutez nmcli connection.

Pour rétablir le comportement précédent, remplacez la nouvelle valeur par défaut en suivant l’une de ces étapes :

  • Créez le fichier de configuration personnalisé /etc/NetworkManager/conf.d/22-wifi-mac-addr.conf, qui peut être vide ou contenir des configurations spécifiques. Cela empêche Fedora de charger le fichier par défaut dans /usr/lib.

  • Créez un fichier .conf avec une priorité plus élevée, tel que`/etc/NetworkManager/conf.d/90-wifi-mac-addr.conf`, définissant wifi.cloned-mac-address :

    [connection-90-wifi-mac-addr-conf]
    wifi.cloned-mac-address=permanent

Pour plus de détails sur l’ordre de chargement des fichiers de configuration et leur priorité, référez-vous à man NetworkManager.conf. Pour connaître les autres options wifi.cloned-mac-address, consultez la [documentation de NetworkManager](https://networkmanager.dev/docs/api/1.46/settings-802-11-wireless.html).

PostgreSQL 16

Fedora 40 fournit la version 16 de PostgreSQL. Pour plus d’informations, consultez les notes de version upstream.

Migration vers SPDX

Les paquets RPM utilisent les identifiants SPDX comme standard pour les licences. 63 % des paquets et presque l’ensemble des paquets provenant de ELN ont été migrés vers les identifiants SPDX. Les paquets restants devraient être migrés vers SPDX dans Fedora 41.