Anaconda prend en charge rhsm pour le provisionnement des machines par le biais d'installations Kickstart pour Satellite

Auparavant, le provisionnement des machines dépendait d'un script personnalisé %post pour l'installation de Kickstart sur Red Hat Satellite. Ce script %post importait le certificat auto-signé personnalisé de Satellite, enregistrait la machine, attachait un abonnement et installait les paquets résidant dans les dépôts.

RHEL prend en charge localhost en tant que nom d'hôte statique

À partir de RHEL 9, la définition de localhost comme nom d'hôte statique dans /etc/hostname est valide. Dans ce cas, NetworkManager n'essaie pas d'obtenir un nom d'hôte transitoire par DHCP ou par une recherche DNS inversée.

Les écrans de configuration des licences, du système et des paramètres utilisateur ont été désactivés après l'installation standard

Auparavant, les utilisateurs de RHEL configuraient les paramètres de licence, de système (gestionnaire d'abonnement) et d'utilisateur avant les écrans gnome-initial-setup et de connexion. Avec cette mise à jour, les écrans de configuration initiale ont été désactivés par défaut afin d'améliorer l'expérience des utilisateurs.

Anaconda active automatiquement le réseau pour les installations interactives

Auparavant, lors d'une installation interactive sans que le réseau soit activé par Kickstart ou les options de démarrage, les utilisateurs devaient activer le réseau manuellement dans le réseau. Avec cette mise à jour, Anaconda active le réseau automatiquement, sans que les utilisateurs aient à visiter le réseau et à l'activer manuellement.

Image Builder prend désormais en charge la configuration du système de fichiers

Grâce à cette amélioration, vous pouvez spécifier une configuration personnalisée du système de fichiers dans vos plans et créer des images avec la disposition de disque souhaitée. Par conséquent, en ayant des dispositions différentes de celles par défaut, vous pouvez bénéficier de références de sécurité, d'une cohérence avec les configurations existantes, de performances et d'une protection contre les erreurs hors disque.

Nouvelles options pour Lock root account et Allow root SSH login with password

Les nouvelles options suivantes ont été ajoutées à l'écran de configuration du mot de passe root dans l'installation graphique de RHEL :

Image Builder permet désormais de créer des images d'installation amorçables

Grâce à cette amélioration, vous pouvez utiliser Image Builder pour créer des images ISO amorçables composées d'un fichier tarball, qui contient un système de fichiers racine. Par conséquent, vous pouvez utiliser l'image ISO amorçable pour installer le système de fichiers tarball sur un système métallique nu.

RHEL for Edge prend désormais en charge par défaut les contrôles de santé intégrés de Greenboot

Avec cette mise à jour, RHEL for Edge Greenboot inclut désormais des contrôles de santé intégrés avec la fonctionnalité watchdog pour s'assurer que le matériel ne se bloque pas ou ne se fige pas lors du redémarrage. Vous pouvez ainsi bénéficier des fonctionnalités suivantes :

RHEL 9 fournit rpm-ostree v2022.2

RHEL 9 est distribué avec la version rpm-ostree v2022.2, qui apporte de nombreuses corrections de bogues et améliorations. Les changements notables sont les suivants :

RHEL 9 fournit OSTree v2021.2

RHEL 9 est distribué avec la version v2021.2 du paquet OSTree, qui apporte de nombreuses corrections de bogues et améliorations. Les changements notables sont les suivants :

L'outil rpm-ostree rebase prend en charge la mise à niveau de RHEL 8 vers RHEL 9

Grâce à cette amélioration, vous pouvez mettre à niveau votre système RHEL 8 vers RHEL 9 à l'aide de l'outil rpm-ostree rebase. Il prend entièrement en charge l'ensemble de paquets par défaut de RHEL pour les mises à niveau Edge entre les mises à jour les plus récentes de RHEL 8 et les mises à jour les plus récentes de RHEL 9.

Fusion des commandes d'objectifs du système sous subscription-manager syspurpose

Auparavant, il existait deux commandes différentes pour définir les attributs de l'objectif du système : syspurpose et subscription-manager. Afin d'unifier tous les attributs d'objectif du système dans un seul module, toutes les commandes addons, role, service-level, et usage du gestionnaire d'abonnements ont été déplacées dans le nouveau sous-module, subscription-manager syspurpose.

RHEL 9 fournit RPM 4.16

RHEL 9 est distribué avec la version 4.16 du RPM. Les corrections de bogues et améliorations notables par rapport à la version 4.14 sont les suivantes :

Le nouveau plugin RPM notifie à fapolicyd les changements survenus lors des transactions RPM

Cette mise à jour des paquets rpm introduit un nouveau plugin RPM qui intègre le cadre fapolicyd avec la base de données RPM. Le plugin notifie à fapolicyd les fichiers installés et modifiés au cours d'une transaction RPM. Par conséquent, fapolicyd prend désormais en charge la vérification de l'intégrité.

RPM prend désormais en charge l'algorithme de clé publique EdDSA

Avec cette amélioration, la commande rpm prend en charge les clés de signature utilisant l'algorithme de clé publique EdDSA. Par conséquent, les clés de signature générées à l'aide de l'algorithme EdDSA peuvent désormais être utilisées pour signer et vérifier les paquets.

RPM supporte maintenant l'algorithme de compression Zstandard (zstd)

Avec cette amélioration, l'algorithme de compression par défaut des RPM est passé à Zstandard (zstd). Les utilisateurs peuvent ainsi bénéficier d'une installation plus rapide des paquets, ce qui peut être particulièrement appréciable lors de transactions importantes.

Nouvelles options DNF exclude_from_weak_autodetect et exclude_from_weak

Avec cette amélioration, le comportement par défaut de la DNF n'installe pas de dépendances faibles indésirables. Pour modifier ce comportement, utilisez les nouvelles options suivantes :

RHEL 9 fournit libmodulemd 2.13.0

RHEL 9 est distribué avec le paquet libmodulemd version 2.13.0. Les corrections de bogues et améliorations notables par rapport à la version 2.9.4 sont les suivantes :

Le collage entre crochets est désormais activé par défaut dans bash

La version 8.1 de la bibliothèque bash readline est désormais disponible et active par défaut le mode de collage entre crochets. Lorsque vous collez du texte dans votre terminal, bash met le texte en surbrillance et vous devez appuyer sur enter pour exécuter la commande collée. Le mode de collage entre crochets est le paramètre par défaut pour éviter d'exécuter accidentellement des commandes malveillantes.

RHEL 9 comprend powerpc-utils 1.3.9

RHEL 9 fournit la version 1.3.9 du paquet powerpc-utils. Les corrections de bogues et améliorations notables par rapport à la version 1.3.8 sont les suivantes :

RHEL 9 est distribué avec opal-prd 6.7.1

La version 6.7.1 du paquet opal-prd apporte les corrections de bogues et améliorations suivantes par rapport à la version 6.6.3 précédemment disponible :

RHEL 9 fournit lsvpd 1.7.12

RHEL 9 est distribué avec le paquet lsvpd version 1.7.12. Les corrections de bogues et améliorations notables par rapport à la version 1.7.11 sont les suivantes :

ppc64-diag version 2.7.7 disponible

La version 2.7.7 du paquet ppc64-diag est fournie dans RHEL 9. Les corrections de bogues et améliorations notables par rapport à la version 2.7.6 sont les suivantes :

RHEL 9 comprend Fetchmail 6.4.24

RHEL 9 est distribué avec le paquet fetchmail version 6.4.24. Fetchmail est un utilitaire de récupération et de transfert de courrier à distance.

RHEL 9 comprend Eigen 3.4

RHEL 9 est distribué avec le paquetage eigen3 version 3.4. Eigen 3.4 est une bibliothèque de modèles C pour l'algèbre linéaire, qui prend désormais en charge les instructions d'assistance à la multiplication de matrices POWER10.

RHEL 9 introduit le paquetage cdrskin

RHEL 9 introduit le paquetage cdrskin pour la gravure de données sur CD, DVD ou BD. Le paquet cdrskin remplace l'exécutable cdrecord du paquet wodim, qui n'est pas disponible dans RHEL 9.

La collection Ansible redhat.rhel_mgmt est prise en charge dans la version RHEL 9

Cette mise à jour assure la prise en charge des modules Ansible Intelligent Platform Management Interface (IPMI). IPMI est une spécification pour un ensemble d'interfaces de gestion permettant de communiquer avec les dispositifs BMC (Baseboard Management Controller). Les modules IPMI - ipmi_power et ipmi_boot - sont disponibles dans la collection redhat.rhel_mgmt, à laquelle vous pouvez accéder en installant le paquetage ansible-collection-redhat-rhel_mgmt.

RHEL 9 introduit le paquetage util-linux-core

Outre le paquet util-linux, RHEL 9 fournit le sous-paquet util-linux-core pour les scénarios dans lesquels la taille des paquets installés est une caractéristique critique, par exemple les buildroots, certains conteneurs et les images de démarrage.

s-nail remplace mailx

Le système de traitement du courrier s-nail a remplacé l'utilitaire mailx. L'utilitaire s-nail est compatible avec mailx et ajoute de nombreuses fonctionnalités. Le paquet mailx n'est plus maintenu en amont.

TuneD 2.18 est disponible

RHEL 9 est distribué avec la version 2.18 de TuneD. Les changements notables par rapport à la version 2.16 sont les suivants :

RHEL 9 fournit mod_security_crs 3.3

RHEL 9 est distribué avec le paquet mod_security_crs version 3.3. Les corrections de bogues et améliorations notables sont les suivantes :

RHEL 9 fournit chrony 4.1

RHEL 9 est distribué avec chrony version 4.1. Les corrections de bogues et améliorations notables par rapport à la version 3.5 sont les suivantes :

Le système crypto-policies est désormais plus sûr

Avec cette mise à jour, les politiques cryptographiques du système ont été ajustées pour fournir des valeurs par défaut sécurisées et actualisées :

RHEL 9 fournit OpenSSL 3.0.1

RHEL 9 fournit les paquets openssl dans la version amont 3.0.1, qui comprend de nombreuses améliorations et corrections de bogues par rapport à la version précédente. Les changements les plus notables sont les suivants :

OpenSSL inclut désormais les fournisseurs

La boîte à outils OpenSSL dans sa version 3.0.1, qui est incluse dans RHEL 9, a ajouté le concept de fournisseurs. Les fournisseurs sont des collections d'algorithmes, et vous pouvez choisir différents fournisseurs pour différentes applications. OpenSSL inclut actuellement les fournisseurs suivants : base, default, fips, legacy, et null.

Le générateur de bits aléatoires OpenSSL prend désormais en charge CPACF

Cette version des paquets openssl introduit la prise en charge du CP Assist for Cryptographic Functions (CPACF) dans le générateur de bits aléatoires déterministes (DRBG) OpenSSL conforme à la norme NIST SP800-90A.

openssl-spkac peut désormais créer des fichiers SPKAC signés avec SHA-1 et SHA-256

L'utilitaire openssl-spkac peut désormais créer des fichiers de clés publiques et de défis signés Netscape (SPKAC) signés avec des hachages différents de MD5. Vous pouvez également créer et vérifier des fichiers SPKAC signés avec des hachages SHA-1 et SHA-256.

RHEL 9 fournit openCryptoki 3.17.0

RHEL 9 est distribué avec openCryptoki version 3.17.0. Les corrections de bogues et améliorations notables par rapport à la version 3.16.0 sont les suivantes :

GnuTLS fourni dans la version 3.7.3

Dans RHEL 9, les paquets gnutls sont fournis dans la version amont 3.7.3. Cette version apporte de nombreuses améliorations et corrections de bogues par rapport aux versions précédentes, notamment :

RHEL 9 fournit NSS 3.71

RHEL 9 est distribué avec la version 3.71 des bibliothèques NSS (Network Security Services). Les changements notables sont les suivants :

Les NSS ne prennent plus en charge les clés RSA de moins de 1023 bits

La mise à jour des bibliothèques Network Security Services (NSS) modifie la taille minimale des clés pour toutes les opérations RSA de 128 à 1023 bits. Cela signifie que les NSS n'exécutent plus les fonctions suivantes :

Option de longueur minimale des bits de la clé RSA dans OpenSSH

L'utilisation accidentelle de clés RSA courtes peut rendre le système plus vulnérable aux attaques. Avec cette mise à jour, vous pouvez définir la longueur minimale des bits de la clé RSA pour les serveurs et les clients OpenSSH. Pour définir la longueur minimale de la clé RSA, utilisez la nouvelle option RSAMinSize dans le fichier /etc/ssh/sshd_config pour les serveurs OpenSSH et dans le fichier /etc/ssh/ssh_config pour les clients OpenSSH.

OpenSSH distribué dans la version 8.7p1

RHEL 9 inclut OpenSSH dans la version 8.7p1. Cette version apporte de nombreuses améliorations et corrections de bogues par rapport à la version 8.0p1 de OpenSSH, qui est distribuée dans RHEL 8.5, notamment :

La redirection des langues est désactivée par défaut dans OpenSSH

L'utilisation des paramètres régionaux C.UTF-8 dans les petites images, telles que les conteneurs et les machines virtuelles, réduit la taille et améliore les performances par rapport à l'utilisation des paramètres régionaux traditionnels en_US.UTF-8.

OpenSSH prend en charge les clés de sécurité U2F/FIDO

Auparavant, les clés OpenSSH stockées dans le matériel n'étaient prises en charge que par la norme PKCS #11, ce qui limitait l'utilisation d'autres clés de sécurité dans SSH. La prise en charge des clés de sécurité U2F/FIDO a été développée en amont et est désormais implémentée dans RHEL 9, ce qui améliore l'utilisation des clés de sécurité dans SSH indépendamment de l'interface PKCS #11.

Libreswan fourni dans la version 4.6

Dans RHEL 9, Libreswan est fourni dans la version amont 4.6. Cette version apporte de nombreuses corrections de bogues et améliorations, notamment sur l'IPsec labellisé utilisé avec l'Internet Key Exchange version 2 (IKEv2).

Libreswan n'accepte pas les paquets IKEv1 par défaut

Le protocole IKEv2 (Internet Key Exchange v2) étant désormais largement déployé, Libreswan ne prend plus en charge les paquets IKEv1 par défaut. IKEv2 offre un environnement plus sûr et une meilleure résistance aux attaques. Si votre scénario nécessite l'utilisation d'IKEv1, vous pouvez l'activer en ajoutant l'option ikev1-policy=accept au fichier de configuration /etc/ipsec.conf.

RHEL 9 fournit stunnel 5.62

RHEL 9 est distribué avec le paquet stunnel version 5.62. Les corrections de bogues et améliorations notables sont les suivantes :

RHEL 9 fournit nettle 3.7.3

RHEL 9 fournit la version 3.7.3 du paquet nettle avec de nombreuses corrections de bogues et améliorations. Les changements notables sont les suivants :

RHEL 9 fournit p11-kit 0.24

RHEL 9 fournit le paquet p11-kit avec la version 0.24. Cette version apporte de nombreuses corrections de bogues et améliorations. Notamment, le sous-répertoire de stockage des autorités de certification de confiance a été renommé blocklist.

cyrus-sasl utilise désormais GDBM au lieu de Berkeley DB

Le paquetage cyrus-sasl est maintenant construit sans la dépendance libdb, et le plugin sasldb utilise le format de base de données GDBM au lieu de Berkeley DB. Pour migrer vos bases de données SASL (Simple Authentication and Security Layer) existantes stockées dans l'ancien format Berkeley DB, utilisez l'outil cyrusbdb2current avec la syntaxe suivante :

La politique SELinux de RHEL 9 est à jour avec le noyau actuel

La politique SELinux inclut de nouvelles permissions, classes et capacités qui font également partie du noyau. Par conséquent, SELinux peut utiliser tout le potentiel fourni par le noyau. En particulier, SELinux dispose d'une meilleure granularité pour l'octroi des permissions, ce qui présente des avantages ultérieurs en termes de sécurité. Cela permet également de faire fonctionner les systèmes avec la politique SELinux MLS, car la politique MLS empêcherait certains systèmes de démarrer s'ils contenaient des permissions inconnues de la politique.

La politique SELinux par défaut interdit les commandes contenant des bibliothèques de relocalisation de texte

Le booléen selinuxuser_execmod est désormais désactivé par défaut afin d'améliorer l'empreinte de sécurité des systèmes installés. En conséquence, les utilisateurs de SELinux ne peuvent pas entrer de commandes utilisant des bibliothèques qui nécessitent une relocalisation de texte, à moins que les fichiers de la bibliothèque ne portent l'étiquette textrel_shlib_t.

OpenSCAP est fourni dans la version 1.3.6

RHEL 9 inclut OpenSCAP dans la version 1.3.6, qui apporte des corrections de bogues et des améliorations, notamment :

OSCAP Anaconda Add-on supporte désormais un nouveau nom d'add-on

Grâce à cette amélioration, vous pouvez utiliser le nouveau nom du module com_redhat_oscap plutôt que l'ancien nom du module org_fedora_oscap dans le fichier Kickstart du module OSCAP Anaconda Add-on. Par exemple, la section Kickstart peut être structurée comme suit :

Les flux CVE OVAL sont désormais compressés

Avec cette mise à jour, Red Hat fournit les flux CVE OVAL sous une forme compressée. Ils ne sont plus disponibles sous forme de fichiers XML, mais au format bzip2. L'emplacement des flux pour RHEL9 a également été mis à jour pour refléter ce changement. Notez que les scanners SCAP tiers peuvent avoir des problèmes avec les règles d'analyse qui utilisent un flux compressé parce que le référencement du contenu compressé n'est pas standardisé.

Guide de sécurité SCAP fourni dans la version 0.1.60

RHEL 9 inclut les paquets scap-security-guide dans la version 0.1.60. Cette version apporte des corrections de bogues et des améliorations, notamment :

Profils du guide de sécurité SCAP pris en charge dans RHEL 9.0

Grâce aux profils de conformité du guide de sécurité SCAP inclus dans RHEL 9.0, vous pouvez renforcer le système conformément aux recommandations des organisations émettrices. Par conséquent, vous pouvez configurer et automatiser la conformité de vos systèmes RHEL 9 selon le niveau de renforcement requis en utilisant les remédiations et les profils SCAP associés.

RHEL 9 fournit fapolicyd 1.1

RHEL 9 est distribué avec le paquet fapolicyd version 1.1. Les améliorations les plus notables sont les suivantes :

Rsyslog inclut le module mmfields pour des opérations plus performantes et CEF

Rsyslog comprend désormais le sous-paquetage rsyslog-mmfields qui fournit le module mmfields. Il s'agit d'une alternative à l'utilisation de l'extraction de champs du substitut de propriété, mais contrairement à ce dernier, tous les champs sont extraits en une seule fois et stockés dans la partie des données structurées. Par conséquent, vous pouvez utiliser mmfields en particulier pour traiter des formats d'enregistrement basés sur des champs, par exemple Common Event Format (CEF), et si vous avez besoin d'un grand nombre de champs ou si vous réutilisez des champs spécifiques. Dans ces cas, mmfields est plus performant que les fonctions Rsyslog existantes.

logrotate inclus dans un paquet séparé rsyslog-logrotate

La configuration logrotate a été séparée du paquet principal rsyslog dans le nouveau paquet rsyslog-logrotate. Ceci est utile dans certains environnements minimaux, par exemple lorsque la rotation des journaux n'est pas nécessaire, pour éviter d'installer des dépendances inutiles.

sudo supporte les plugins Python

Avec le programme sudo version 1.9, qui est inclus dans RHEL 9, vous pouvez écrire des plugins sudo en Python. Il est ainsi plus facile d'améliorer sudo pour l'adapter plus précisément à des scénarios spécifiques.

libseccomp fourni dans la version 2.5.2

RHEL 9.0 fournit les paquets libseccomp dans la version amont 2.5.2. Cette version apporte de nombreuses corrections de bogues et améliorations par rapport aux versions précédentes, notamment :

Clevis prend désormais en charge SHA-256

Grâce à cette amélioration, le cadre Clevis prend en charge l'algorithme SHA-256 en tant que hachage par défaut pour les empreintes de clés Web JSON (JWK), conformément aux recommandations de RFC 7638. Comme les anciennes empreintes (SHA-1) sont toujours prises en charge, vous pouvez toujours décrypter les données précédemment cryptées.

Les modules diag sont désormais disponibles dans le noyau

Les modules diag sont désormais inclus dans l'image du noyau. Avec cette mise à jour, les modules diag n'ont plus besoin d'être chargés dynamiquement lorsque la commande ss est utilisée. Cela permet un meilleur débogage des problèmes de réseau, quelle que soit la politique du client concernant les modules du noyau. Modules inclus dans le noyau :

Nouveaux paramètres du noyau et des réseaux liés à IPv4 sysctl

Par rapport aux versions précédentes de RHEL, le noyau RHEL 9.0 fournit les nouveaux paramètres de base et de réseau IPv4 suivants : sysctl:

Modification du comportement de firewalld lors de la transmission de paquets entre zones

Dans les pare-feu basés sur des zones, les paquets n'entrent que dans une seule zone. La transmission implicite de paquets est une violation du concept et peut autoriser le trafic ou les services de manière inattendue. Dans Red Hat Enterprise Linux 9, le service firewalld ne permet plus la transmission implicite de paquets entre deux zones différentes.

Le transfert intra-zone a été activé par défaut

La fonctionnalité firewalld intra-zone forwarding permet de transférer le trafic entre des interfaces ou des sources au sein d'une zone firewalld. Depuis RHEL 9.0, cette fonctionnalité est activée par défaut. Utilisez l'option --add-forward de l'utilitaire firewall-cmd pour activer le transfert intra-zone pour une zone particulière. La commande firewall-cmd --list-all indique si le transfert intrazone est activé ou désactivé pour une zone :

Rendre Nmstate plus inclusif

Red Hat s'engage à utiliser un langage conscient. Pour plus de détails sur cette initiative, consultez le site Rendre l'open source plus inclusif. Par conséquent, le terme slave dans l'API nmstate a été remplacé par le terme port.

NetworkManager supporte les noms d'interface définis dans l'option du noyau rd.znet_ifname sur IBM Z

Avec cette amélioration, sur la plateforme IBM Z, NetworkManager interprète maintenant les options de ligne de commande rd.znet et rd.znet_ifname du noyau lors de l'installation ou du démarrage de Red Hat Enterprise Linux à partir du réseau. Par conséquent, il est possible de spécifier le nom d'une interface réseau identifiée par les sous-canaux au lieu du nom par défaut.

Le paquetage hostapd a été ajouté à RHEL 9.0

Avec cette version, RHEL fournit le paquetage hostapd. Cependant, Red Hat prend en charge hostapd uniquement pour configurer un hôte RHEL en tant qu'authentificateur 802.1X dans les réseaux Ethernet. D'autres scénarios, tels que les points d'accès Wi-Fi ou les authentificateurs dans les réseaux Wi-Fi, ne sont pas pris en charge.

ModemManager fourni dans la version 1.18.2

RHEL 9.0 fournit les paquets ModemManager dans la version amont 1.18.2. Cette version comprend des corrections de bogues et des améliorations par rapport à la version précédente, notamment :

NetworkManager permet de modifier queue_id du port de liaison

Les ports NetworkManager dans un lien supportent maintenant le paramètre queue_id. En supposant que eth1 est un port de l'interface de liaison, vous pouvez activer queue_id pour un port de liaison avec :

Support de la configuration des types de routes blackhole, prohibit et unreachable avec la dernière version de NetworkManager

Le noyau prend en charge plusieurs types d'itinéraires en plus des types d'itinéraires communs unicast, broadcast et local. En outre, les utilisateurs peuvent désormais configurer les types de routes statiques blackhole, prohibit et unreachable dans le profil de connexion du NetworkManager. Le NetworkManager ajoutera un profil lorsque celui-ci sera activé.

Les adaptateurs RoCE Express utilisent désormais un schéma de dénomination des interfaces amélioré

Avec cette amélioration, les adaptateurs RDMA over Converged Ethernet (RoCE) Express utilisent le schéma de dénomination prévisible de l'interface et le connecteur Peripheral Communication Interface on z-system (zPCI). Dans ce schéma de dénomination, RHEL utilise l'identifiant de l'utilisateur (UID) ou l'identifiant de la fonction (FID) pour générer des noms uniques. Si aucun UID unique n'est disponible, RHEL utilise le FID pour définir le schéma de dénomination.

Version du noyau dans RHEL 9.0

Red Hat Enterprise Linux 9.0 est distribué avec la version 5.14.0-70 du noyau.

Red Hat, par défaut, active eBPF dans toutes les versions de RHEL pour les utilisateurs privilégiés uniquement

Extended Berkeley Packet Filter (eBPF) est une technologie complexe qui permet aux utilisateurs d'exécuter un code personnalisé à l'intérieur du noyau Linux. En raison de sa nature, le code eBPF doit passer par le vérificateur et d'autres mécanismes de sécurité. Il y a eu des cas de vulnérabilités et d'expositions communes (CVE), où des bogues dans ce code pouvaient être utilisés pour des opérations non autorisées. Pour atténuer ce risque, Red Hat a activé par défaut eBPF dans toutes les versions de RHEL pour les utilisateurs privilégiés uniquement. Il est possible d'activer eBPF pour les utilisateurs non privilégiés en utilisant le paramètre de ligne de commande kernel. unprivileged_bpf_disabled=0.

Red Hat ne protège les symboles du noyau que pour les versions mineures

Red Hat garantit qu'un module du noyau continuera à se charger dans toutes les mises à jour futures au sein d'une version Extended Update Support (EUS), uniquement si vous compilez le module du noyau à l'aide de symboles protégés du noyau. Il n'y a pas de garantie d'ABI (Application Binary Interface) du noyau entre les versions mineures de RHEL 9.

Noyaux RHEL 9 Beta signés avec des certificats SecureBoot de confiance

Auparavant, les versions bêta de RHEL exigeaient des utilisateurs qu'ils inscrivent une clé publique bêta distincte à l'aide de la fonction MOK (Machine Owner Key). À partir de RHEL 9 Beta, les noyaux sont signés avec des certificats SecureBoot approuvés, et les utilisateurs n'ont donc plus besoin d'enregistrer une clé publique Beta distincte pour utiliser les versions Beta sur des systèmes dont l'UEFI Secure Boot est activé.

cgroup-v2 activé par défaut dans RHEL 9

La fonctionnalité des groupes de contrôle version 2 (cgroup-v2) met en œuvre un modèle hiérarchique unique qui simplifie la gestion des groupes de contrôle. Elle garantit également qu'un processus ne peut être membre que d'un seul groupe de contrôle à la fois. L'intégration approfondie avec systemd améliore l'expérience de l'utilisateur final lors de la configuration du contrôle des ressources sur un système RHEL.

Modifications du noyau susceptibles d'affecter les modules tiers du noyau

Les distributions Linux dont la version du noyau est antérieure à la version 5.9 prenaient en charge l'exportation des fonctions GPL en tant que fonctions non GPL. Par conséquent, les utilisateurs pouvaient lier des fonctions propriétaires à des fonctions GPL du noyau par le biais du mécanisme shim. Avec cette version, le noyau RHEL incorpore des changements en amont qui améliorent la capacité de RHEL à appliquer la GPL en repoussant shim.

L'architecture ARM 64 bits a une taille de page de 4 Ko dans RHEL 9

Red Hat a sélectionné une taille de page de mémoire physique de 4 Ko pour l'architecture ARM 64 bits dans Red Hat Enterprise Linux 9. Cette taille correspond bien aux charges de travail et aux quantités de mémoire présentes sur la majorité des systèmes basés sur ARM. Pour utiliser efficacement des tailles de page importantes, utilisez l'option "huge pages" pour traiter une plus grande quantité de mémoire ou des charges de travail avec de grands ensembles de données.

L'utilitaire strace affiche désormais correctement les incompatibilités de contexte SELinux

L'option --secontext de strace a été complétée par le paramètre mismatch. Ce paramètre permet d'imprimer le contexte attendu en même temps que le contexte réel en cas de non-concordance uniquement. La sortie est séparée par un double point d'exclamation (!!), d'abord le contexte réel, puis le contexte attendu. Dans les exemples ci-dessous, les paramètres full,mismatch affichent le contexte complet attendu en même temps que le contexte réel parce que la partie utilisateur des contextes ne correspond pas. Cependant, lors de l'utilisation d'un mismatch solitaire, il ne vérifie que la partie type du contexte. Le contexte attendu n'est pas imprimé car la partie type des contextes correspond.

perf-top peut maintenant être trié par une certaine colonne

Avec cette mise à jour de l'outil de profilage du système perf-top, vous pouvez trier les échantillons en fonction d'une colonne d'événements arbitraire. Auparavant, les événements étaient triés par la première colonne dans le cas où plusieurs événements d'un groupe étaient échantillonnés. Pour trier les échantillons, utilisez l'option de ligne de commande --group-sort-idx et appuyez sur une touche numérique pour trier le tableau par la colonne de données correspondante. Notez que la numérotation des colonnes commence à 0.

Nouveau paquet : jigawatts

Checkpoint/Restore In Userspace (CRIU) est un utilitaire Linux qui permet de vérifier et de restaurer des processus. Le paquetage jigawatts contient une bibliothèque Java qui vise à améliorer l'utilisation des mécanismes CRIU à partir d'applications Java.

La commande trace-cmd reset a un nouveau comportement

Auparavant, la commande trace-cmd reset réinitialisait la configuration de tracing_on à 0. Le nouveau comportement de trace-cmd reset est de réinitialiser tracing_on à sa valeur par défaut 1.

Le filtre de paquets Berkeley étendu est pris en charge dans RHEL 9

Le site Extended Berkeley Packet Filter (eBPF) est une machine virtuelle intégrée au noyau qui permet l'exécution de code dans l'espace du noyau, dans l'environnement restreint du bac à sable, avec un accès à un ensemble limité de fonctions. La machine virtuelle exécute un code spécial de type assemblage.

RHEL 9 fournit l'utilitaire crash version 8.0.0

RHEL 9 est distribué avec l'utilitaire crash version 8.0.0. Les corrections de bogues et les améliorations notables sont les suivantes :

makedumpfile prend désormais en charge une capacité de compression améliorée de zstd

Avec cette amélioration, le site makedumpfile inclut désormais la capacité de compression Zstandard (zstd), qui offre des taux de compression élevés. Cette amélioration est particulièrement utile pour les systèmes à grande mémoire.

numatop activé sur les processeurs de serveurs évolutifs Intel Xeon

numatop est un outil qui suit et analyse le comportement des processus et des threads s'exécutant sur des systèmes NUMA et affiche des mesures permettant d'identifier les goulets d'étranglement liés aux performances des NUMA.

kexec_file_load a été ajouté comme option par défaut pour RHEL 9

Cette mise à jour ajoute l'appel système kexec_file_load pour l'architecture ARM 64 bits. Elle fournit un chargeur in-kernel kexec pour kdump. Auparavant, le noyau empêchait le chargement d'images de noyau non signées lorsque l'option de démarrage sécurisé était activée. Le mécanisme kdump essayait d'abord de détecter si l'amorçage sécurisé était activé et choisissait ensuite l'interface d'amorçage à exécuter. Par conséquent, un noyau non signé ne parvenait pas à se charger lorsque l'amorçage sécurisé était activé et que kexec_file_load() était spécifié.

makedumpfile inclut désormais des options améliorées pour obtenir une estimation de la taille de vmcore

Avec cette implémentation, l'utilitaire makedumpfile inclut maintenant les options suivantes qui aident à imprimer une estimation de la taille du dump pour le noyau en cours d'exécution :

Le paquet kexec-tools prend désormais en charge les valeurs de réservation de mémoire par défaut de crashkernel pour RHEL 9

Le paquetage kexec-tools conserve désormais les valeurs par défaut de réservation de la mémoire crashkernel. Le service kdump utilise la valeur par défaut pour réserver la mémoire crashkernel pour chaque noyau. Cette implémentation améliore également l'allocation de la mémoire pour kdump lorsqu'un système dispose de moins de 4 Go de mémoire disponible.

L'ordonnancement des noyaux est pris en charge dans RHEL 9

Grâce à la fonctionnalité de planification de base, les utilisateurs peuvent empêcher les tâches qui ne devraient pas se faire confiance de partager le même cœur d'unité centrale. De même, les utilisateurs peuvent définir des groupes de tâches qui peuvent partager un cœur d'unité centrale.

Amélioration des performances sur l'architecture ARM 64 bits en utilisant par défaut le mode iommu non strict

Avec cette mise à jour, l'architecture ARM 64 bits utilise par défaut le domaine d'accès direct à la mémoire (DMA) paresseux pour l'unité de gestion de la mémoire système (SMMU). Tout en apportant un gain de performance significatif, cela peut introduire une fenêtre entre un désappairage d'adresse et un vidage du Translation Lookaside Buffer (TLB) sur l'unité de gestion de la mémoire du système. Dans les versions précédentes, l'architecture ARM 64 bits configurait par défaut les domaines DMA stricts, ce qui entraînait une baisse des performances en raison de la taille de page de 4 Ko.

L'arborescence des sources de kernel-rt a été mise à jour vers l'arborescence RHEL 9.0

Les sources de kernel-rt ont été mises à jour pour utiliser la dernière arborescence des sources du noyau Red Hat Enterprise Linux. Le jeu de correctifs en temps réel a également été mis à jour vers la dernière version en amont, v5.15-rt19. Ces mises à jour apportent un certain nombre de corrections de bogues et d'améliorations.

Prise en charge du hotplug de l'unité centrale dans les PMU hv_24x7 et hv_gpci

Avec cette mise à jour, les compteurs PMU réagissent correctement au branchement à chaud d'une unité centrale. Par conséquent, si un compteur d'événements hv_gpci fonctionne sur une unité centrale qui est désactivée, le comptage est redirigé vers une autre unité centrale.

Les mesures pour les événements de nidification du POWERPC hv_24x7 sont maintenant disponibles

Des mesures pour les événements de nidification POWERPC hv_24x7 sont maintenant disponibles pour perf. En agrégeant plusieurs événements, ces mesures permettent de mieux comprendre les valeurs obtenues à partir des compteurs perf et l'efficacité avec laquelle l'unité centrale est capable de traiter la charge de travail.

Le pilote IRDMA a été introduit dans RHEL 9

Le pilote IRDMA active la fonctionnalité RDMA sur les périphériques réseau Intel® compatibles RDMA. Les périphériques pris en charge par ce pilote sont les suivants :

Un nouveau paramètre pour le module kernel bonding: lacp_active

RHEL 9 introduit le paramètre lacp_active pour le module du noyau bonding. Ce paramètre indique s'il faut envoyer des trames LACPDU (Link Aggregation Control Protocol Data Unit) à des intervalles spécifiés. Les options sont les suivantes :

Les fichiers de configuration du chargeur d'amorçage sont unifiés pour toutes les architectures de processeurs

Les fichiers de configuration du chargeur de démarrage GRUB sont désormais stockés dans le répertoire /boot/grub2/ sur toutes les architectures de processeurs prises en charge. Le fichier /boot/efi/EFI/redhat/grub.cfg, que GRUB utilisait auparavant comme fichier de configuration principal sur les systèmes UEFI, charge désormais simplement le fichier /boot/grub2/grub.cfg.

Les options des utilitaires Samba ont été renommées et supprimées pour une expérience utilisateur cohérente

Les utilitaires Samba ont été améliorés afin de fournir une interface de ligne de commande cohérente. Ces améliorations comprennent des options renommées ou supprimées. Par conséquent, pour éviter tout problème après la mise à jour, passez en revue vos scripts qui utilisent les utilitaires Samba et mettez-les à jour si nécessaire.

Les systèmes de fichiers GFS2 sont désormais créés avec le format version 1802

Les systèmes de fichiers GFS2 dans RHEL 9 sont créés avec le format version 1802. Cela permet les fonctionnalités suivantes :

RHEL 9 fournit la version 1.10.1 du paquet nvml

RHEL 9.0 met à jour le paquetage nvml vers la version 1.10.1. Cette mise à jour ajoute des fonctionnalités et corrige un bogue potentiel de corruption de données en cas de perte d'alimentation.

La prise en charge du système de fichiers exFAT a été ajoutée

RHEL 9.0 prend en charge le système de fichiers Extensible File Allocation Table (exFAT). Vous pouvez désormais monter, formater et utiliser de manière générale ce système de fichiers, qui est généralement utilisé par défaut sur la mémoire flash.

rpcctl la commande affiche désormais les informations de connexion SunRPC

Avec cette mise à jour, vous pouvez utiliser la commande rpcctl pour afficher les informations collectées dans les fichiers SunRPC sysfs sur les objets SunRPC du système. Vous pouvez afficher, supprimer et définir des objets dans la couche réseau SunRPC via le système de fichiers sysfs.

Limiter l'ensemble des périphériques pour LVM

Par défaut, LVM dans RHEL 9 n'utilise que les périphériques que vous sélectionnez explicitement. Utilisez les nouvelles commandes lvmdevices et vgimportdevices pour sélectionner des périphériques spécifiques. L'utilisation des commandes pvcreate, vgcreate et vgextend sélectionne indirectement de nouveaux périphériques pour lvm, s'ils n'ont pas déjà été sélectionnés. LVM ignore les périphériques attachés au système jusqu'à ce que vous les sélectionniez à l'aide de l'une de ces commandes. La commande lvm enregistre la liste des périphériques sélectionnés dans le fichier de périphériques /etc/lvm/devices/system.devices. Le filtre lvm.conf ou tout autre filtre de configuration en ligne de commande ne fonctionne pas lorsque vous activez la fonctionnalité du nouveau fichier de périphériques. Si vous supprimez ou désactivez le fichier de périphériques, LVM applique le filtre à tous les périphériques connectés. Pour obtenir des informations détaillées sur cette fonctionnalité, consultez la page de manuel lvmdevices(8).

L'hôte NVMe/TCP avec nvme_tcp.ko est désormais entièrement pris en charge

Le stockage Nonvolatile Memory Express (NVMe) sur les réseaux TCP/IP (NVMe/TCP) avec le module du noyau nvme_tcp.ko est désormais entièrement pris en charge. La cible NVMe/TCP avec le module nvmet_tcp.ko est disponible avec un statut Unmaintained dans RHEL 9.0.

multipathd permet désormais de détecter les événements FPIN-Li

Lorsque vous ajoutez une nouvelle valeur fpin à l'option de configuration marginal_pathgroups, vous permettez à multipathd de surveiller les événements PFIN-Li (Link Integrity Fabric Performance Impact Notification) et de déplacer les chemins présentant des problèmes d'intégrité de lien vers un groupe de chemins marginaux. Avec la valeur fpin, multipathd remplace les méthodes de détection des chemins marginaux existantes et s'appuie sur la structure Fibre Channel pour identifier les problèmes d'intégrité des liens.

Le méta-attribut de ressource resource-stickiness est désormais fixé par défaut à 1 au lieu de 0 pour les grappes nouvellement créées

Auparavant, la valeur par défaut du méta-attribut resource-stickiness resource était de 0 pour les clusters nouvellement créés. La valeur par défaut de ce méta-attribut est désormais de 1.

Nouvel indicateur de groupe de volume LVM pour contrôler l'auto-activation

Les groupes de volumes LVM prennent désormais en charge l'indicateur setautoactivation qui détermine si les volumes logiques que vous créez à partir d'un groupe de volumes seront automatiquement activés au démarrage. Lors de la création d'un groupe de volumes qui sera géré par Pacemaker dans un cluster, définissez cet indicateur sur n avec la commande vgcreate --setautoactivation n pour le groupe de volumes afin d'éviter une éventuelle corruption des données. Si vous disposez d'un groupe de volumes existant utilisé dans un cluster Pacemaker, définissez l'indicateur avec vgchange --setautoactivation n.

Nouvelles commandes d'affichage de l'état des ressources pcs

Les commandes pcs resource status et pcs stonith status prennent désormais en charge les options suivantes :

Nouvelle option d'affichage réduit pour la commande pcs resource safe-disable

Les commandes pcs resource safe-disable et pcs resource disable --safe impriment un long résultat de simulation après un rapport d'erreur. Vous pouvez désormais spécifier l'option --brief pour ces commandes afin de n'imprimer que les erreurs. Le rapport d'erreur contient toujours les identifiants des ressources affectées.

Nouvelle commande pcs pour mettre à jour le dispositif de clôture SCSI sans provoquer le redémarrage de toutes les autres ressources

La mise à jour d'un dispositif de clôture SCSI à l'aide de la commande pcs stonith update entraîne le redémarrage de toutes les ressources s'exécutant sur le même nœud que celui où s'exécutait la ressource stonith. La nouvelle commande pcs stonith update-scsi-devices vous permet de mettre à jour les périphériques SCSI sans provoquer le redémarrage des autres ressources du cluster.

Possibilité de configurer un SBD avec chien de garde uniquement pour la clôture d'un sous-ensemble de nœuds de la grappe

Auparavant, pour utiliser une configuration SBD avec chien de garde uniquement, tous les nœuds de la grappe devaient utiliser le SBD. Cela empêchait d'utiliser le SMD dans un cluster où certains nœuds le supportent mais où d'autres nœuds (souvent des nœuds distants) ont besoin d'une autre forme de clôture. Les utilisateurs peuvent désormais configurer une configuration SBD avec chien de garde uniquement à l'aide du nouvel agent fence_watchdog, qui permet de configurer des clusters dans lesquels seuls certains nœuds utilisent le SBD avec chien de garde uniquement pour le clôturage et d'autres nœuds utilisent d'autres types de clôturage. Un cluster ne peut avoir qu'un seul dispositif de ce type, et il doit être nommé watchdog.

Affichage détaillé de l'état du stimulateur cardiaque pour les erreurs internes

Si Pacemaker ne peut pas exécuter une ressource ou un agent de clôture pour une raison quelconque, par exemple si l'agent n'est pas installé ou s'il y a eu un dépassement de délai interne, les écrans d'état de Pacemaker affichent désormais un motif de sortie détaillé pour l'erreur interne.

Le paramètre pcmk_delay_base peut désormais prendre des valeurs différentes selon les nœuds

Lors de la configuration d'un dispositif de clôture, vous pouvez désormais spécifier des valeurs différentes pour différents nœuds à l'aide de l'adresse pcmk_delay_base parameter. Cela permet d'utiliser un seul dispositif de clôture dans un cluster à deux nœuds, avec un délai différent pour chaque nœud. Cela permet d'éviter que chaque nœud tente de clôturer l'autre nœud en même temps. Pour spécifier des valeurs différentes pour les différents nœuds, vous mappez les noms d'hôte à la valeur de délai pour ce nœud en utilisant une syntaxe similaire à celle de pcmk_host_map. Par exemple, node1:0;node2:10s n'utilise pas de délai pour clôturer le nœud 1 et un délai de 10 secondes pour clôturer le nœud 2.

Prise en charge des caractères spéciaux dans les valeurs pcmk_host_map

La propriété pcmk_host_map prend désormais en charge les caractères spéciaux dans les valeurs pcmk_host_map en utilisant une barre oblique inverse (\N) devant la valeur. Par exemple, vous pouvez spécifier pcmk_host_map="node3:plug\ 1" pour inclure un espace dans l'alias de l'hôte.

Nouvel agent de clôture pour OpenShift

L'agent de clôture fence_kubevirt est désormais disponible pour une utilisation avec RHEL High Availability sur Red Hat OpenShift Virtualization. Pour plus d'informations sur l'agent fence_kubevirt, consultez la page de manuel fence_kubevirt(8).

La version en mode local de la commande pcs cluster setup est désormais entièrement prise en charge

Par défaut, la commande pcs cluster setup synchronise automatiquement tous les fichiers de configuration sur les nœuds du cluster. La commande pcs cluster setup prend désormais en charge l'option --corosync-conf. En spécifiant cette option, la commande passe en mode local. Dans ce mode, l'interface de ligne de commande pcs crée un fichier corosync.conf et l'enregistre dans un fichier spécifié sur le nœud local uniquement, sans communiquer avec aucun autre nœud. Cela vous permet de créer un fichier corosync.conf dans un script et de gérer ce fichier au moyen du script.

Suppression automatique des contraintes de localisation à la suite d'un déplacement de ressources

Lorsque vous exécutez la commande pcs resource move, vous ajoutez une contrainte à la ressource pour l'empêcher de s'exécuter sur le nœud sur lequel elle s'exécute actuellement. Par défaut, la contrainte d'emplacement créée par la commande est automatiquement supprimée une fois que la ressource a été déplacée. Cela ne ramène pas nécessairement les ressources sur le nœud d'origine ; l'endroit où les ressources peuvent s'exécuter à ce moment-là dépend de la manière dont vous avez configuré vos ressources au départ. Si vous souhaitez déplacer une ressource et laisser en place la contrainte qui en résulte, utilisez la commande pcs resource move-with-contraint.

pcs support pour la norme OCF Resource Agent API 1.1

L'interface en ligne de commande pcs prend désormais en charge les agents OCF 1.1 resource et STONITH. Dans le cadre de la mise en œuvre de ce support, les métadonnées de tout agent doivent être conformes au schéma OCF, que l'agent soit un agent OCF 1.0 ou OCF 1.1. Si les métadonnées d'un agent ne sont pas conformes au schéma OCF, pcs considère que l'agent n'est pas valide et ne créera pas ou ne mettra pas à jour une ressource de l'agent, sauf si l'option --force est spécifiée. L'interface Web pcsd et les commandes pcs pour lister les agents omettent désormais les agents dont les métadonnées ne sont pas valides.

pcs accepte désormais Promoted et Unpromoted comme noms de rôle

L'interface de ligne de commande pcs accepte désormais Promoted et Unpromoted partout où des rôles sont spécifiés dans la configuration de Pacemaker. Ces noms de rôles sont l'équivalent fonctionnel des rôles Master et Slave de Pacemaker dans les versions précédentes de RHEL, et ce sont les noms de rôles qui sont visibles dans les affichages de configuration et les pages d'aide.

Version actualisée de l'interface web pcsd

L'interface Web pcsd, l'interface utilisateur graphique permettant de créer et de configurer les clusters Pacemaker/Corosync, a été mise à jour. L'interface Web mise à jour offre une expérience utilisateur améliorée et une interface standardisée qui est construite avec le cadre PatternFly utilisé dans d'autres applications Web de Red Hat.

Python dans RHEL 9

Python 3.9 est l'implémentation par défaut de Python dans RHEL 9. Python 3.9 est distribué dans un paquet RPM python3 non modulaire dans le dépôt BaseOS et est généralement installé par défaut. Python 3.9 sera pris en charge pendant toute la durée de vie de RHEL 9.

Node.js 16 disponible dans RHEL 9

RHEL 9 fournit la version 16 du support à long terme (LTS) de Node.js, une plate-forme de développement logiciel pour la création d'applications réseau rapides et évolutives dans le langage de programmation JavaScript.

RHEL 9 fournit Ruby 3.0

RHEL 9 est distribué avec Ruby 3.0.3, qui apporte un certain nombre d'améliorations de performance, de corrections de bogues et de sécurité, ainsi que de nouvelles fonctionnalités par rapport à Ruby 2.7.

RHEL 9 présente Perl 5.32

RHEL 9 inclut Perl 5.32, qui apporte un certain nombre de corrections de bogues et d'améliorations par rapport à la version 5.30.

RHEL 9 comprend PHP 8.0

RHEL 9 est distribué avec PHP 8.0, qui apporte un certain nombre de corrections de bogues et d'améliorations par rapport à la version 7.4.

RHEL 9 fournit Git 2.31 et Git LFS 2.13

RHEL 9 est distribué avec Git 2.31 qui fournit un certain nombre d'améliorations et de performances par rapport à la version 2.27 disponible dans RHEL 8. Les changements les plus importants sont les suivants :

Subversion 1.14 dans RHEL 9

RHEL 9 est distribué avec Subversion 1.14. Subversion 1.14 est la version initiale de ce flux d'applications, que vous pouvez installer facilement sous la forme d'un paquetage RPM. D'autres versions de Subversion seront fournies sous forme de modules avec un cycle de vie plus court dans les prochaines versions mineures de RHEL 9.

Changements notables dans le serveur HTTP Apache

RHEL 9.0 fournit la version 2.4.51 du serveur HTTP Apache. Les changements notables par rapport à la version 2.4.37 sont les suivants :

nginx 1.20 disponible dans RHEL 9

RHEL 9 inclut le serveur web et proxy nginx 1.20. Cette version apporte un certain nombre de corrections de bogues, de correctifs de sécurité, de nouvelles fonctionnalités et d'améliorations par rapport à la version 1.18.

Varnish Cache 6.6 dans RHEL 9

RHEL 9 comprend Varnish Cache 6.6, un proxy inverse HTTP très performant.

RHEL 9 présente Squid 5

RHEL 9 est distribué avec Squid 5.2, un serveur proxy de mise en cache haute performance pour les clients web, prenant en charge les objets de données FTP, Gopher et HTTP. Cette version propose un certain nombre de corrections de bogues, de correctifs de sécurité, de nouvelles fonctionnalités et d'améliorations par rapport à la version 4.

MariaDB 10.5 dans RHEL 9

RHEL 9 fournit MariaDB 10.5. MariaDB 10.5 est la version initiale de ce flux d'applications, que vous pouvez installer facilement sous la forme d'un paquetage RPM. D'autres versions de MariaDB seront fournies sous forme de modules ayant un cycle de vie plus court dans les prochaines versions mineures de RHEL 9.

RHEL 9 comprend MySQL 8.0

RHEL 9 est distribué avec MySQL 8.0. MySQL 8.0 est la version initiale de ce flux d'applications, que vous pouvez installer facilement en tant que paquetage RPM. MySQL 8.0 a un cycle de vie plus court que RHEL 9. Pour plus de détails, consultez le document Red Hat Enterprise Linux Application Streams Life Cycle (cycle de vie des flux d'applications ).

RHEL 9 fournit PostgreSQL 13

PostgreSQL 13 est disponible avec RHEL 9. PostgreSQL 13 est la version initiale de ce flux d'applications, que vous pouvez installer facilement sous la forme d'un paquetage RPM. D'autres versions de PostgreSQL seront fournies sous forme de modules avec un cycle de vie plus court dans les prochaines versions mineures de RHEL 9.

Redis 6.2 dans RHEL 9

RHEL 9 est distribué avec Redis 6.2, qui apporte un certain nombre de corrections de bogues et de sécurité, ainsi que des améliorations par rapport à la version 6.0 disponible dans RHEL 8.

Nouveau paquet : perl-Module-Signature

RHEL 9 introduit le module Perl perl-Module-Signature. Avec ce nouveau module, vous pouvez activer la vérification des signatures pour cpan afin d'atténuer la CVE-2020-16156. Pour plus d'informations, voir Comment atténuer CVE-2020-16154 dans perl-App-cpanminus et CVE-2020-16156 dans perl-CPAN.

RHEL 9 prend en charge les processeurs IBM POWER10

Du noyau Linux à la chaîne d'outils système (GCC, binutils, glibc), Red Hat Enterprise Linux 9 a été mis à jour pour inclure la prise en charge du dernier processeur POWER d'IBM, le POWER10. RHEL 9 est prêt pour la production de charges de travail sur POWER10, avec des améliorations à venir dans les prochaines versions.

GCC 11.2.1 est disponible

RHEL 9 est distribué avec la version 11.2.1 de GCC. Les corrections de bogues et améliorations notables incluent :

Nouvelle commande pour capturer les données d'optimisation de glibc

La nouvelle commande ld.so --list-diagnostics capture les données qui influencent les décisions d'optimisation glibc, telles que la sélection IFUNC et la configuration glibc-hwcaps, dans un seul fichier lisible par une machine.

Changements notables binutils

RHEL 9 apporte les modifications suivantes à binutils:

sched_getcpu peut désormais, en option, utiliser rseq (séquences redémarrables) pour améliorer les performances sur les architectures ARM 64 bits et d'autres architectures

La précédente implémentation de sched_getcpu sur les architectures ARM 64 bits utilise l'appel système getcpu, qui est trop lent pour une utilisation efficace dans la plupart des algorithmes parallèles. D'autres architectures utilisent l'accélération vDSO (virtual dynamic shared object) pour contourner ce problème. L'implémentation de sched_getcpu à l'aide de rseq améliore considérablement les performances sur les architectures ARM 64 bits. Les autres architectures n'enregistrent qu'une légère amélioration.

Mise à jour des outils de performance et des débogueurs

Les outils de performance et les débogueurs suivants sont disponibles avec RHEL 9.0 :

Amélioration de la fonctionnalité DAWR dans GDB sur IBM POWER10

RHEL 9 est distribué avec GDB 10.2 qui fournit une fonctionnalité DAWR améliorée. De nouvelles capacités de surveillance matérielle sont activées pour GDB sur les processeurs IBM POWER10. Par exemple, un nouvel ensemble de registres DAWR/DAWRX a été ajouté.

GDB supporte les nouvelles instructions préfixées sur IBM POWER10

GDB 10.2 prend entièrement en charge les instructions préfixées Power ISA 3.1 sur POWER10, qui comprennent des instructions préfixées de huit octets. Dans RHEL 8.4, GDB ne prenait en charge que les instructions de quatre octets.

RHEL 9 fournit boost 1.75.0

RHEL 9 est distribué avec le paquet boost version 1.75.0. Les corrections de bogues et améliorations notables par rapport à la version 1.67.0 sont les suivantes :

RHEL 9 fournit le jeu d'outils LLVM 13.0.1

RHEL 9 est distribué avec la version 13.0.1 du jeu d'outils LLVM. Les corrections de bogues et améliorations notables par rapport à la version 12.0.1 sont les suivantes :

Changements notables dans CMake 3.20.2

RHEL 9 est distribué avec CMake 3.20.2. Pour utiliser CMake sur un projet qui nécessite la version 3.20.2 ou moins, utilisez la commande cmake_minimum_required(version 3.20.2).

RHEL 9 fournit Go 1.17.7

RHEL 9 est distribué avec la version 1.17.7 de Go Toolset. Les corrections de bogues et améliorations notables par rapport à la version 1.16.7 sont les suivantes :

Le mode Go FIPS est pris en charge par OpenSSL 3

Vous pouvez désormais utiliser la bibliothèque OpenSSL 3 en mode Go FIPS.

RHEL 9 fournit Rust Toolset 1.58.1

RHEL 9 est distribué avec la version 1.58.1 de Rust Toolset. Les corrections de bogues et améliorations notables par rapport à la version 1.54.0 sont les suivantes :

RHEL 9 fournit le paquet pcp version 5.3.5

RHEL 9 est distribué avec le paquet Performance Co-Pilot (pcp) version 5.3.5. Depuis la version 5.3.1, un nouveau sous-paquet pcp-pmda-bpf a été ajouté. Il fournit des données sur les performances des programmes eBPF utilisant BPF CO-RE (libbpf et BTF).

Authentification Active Directory pour l'accès aux métriques du serveur SQL dans PCP

Grâce à cette mise à jour, un administrateur système peut configurer pmdamssql(1) pour qu'il se connecte en toute sécurité aux métriques du serveur SQL à l'aide de l'authentification Active Directory (AD).

Le nouvel utilitaire pcp-ss PCP est maintenant disponible

L'utilitaire pcp-ss PCP fournit des statistiques sur les sockets collectées par pmdasockets(1) PMDA. La commande est compatible avec la plupart des options de ligne de commande et des formats de rapport de ss. Il offre également les avantages d'une surveillance locale ou à distance en mode direct et d'une relecture historique à partir d'une archive PCP précédemment enregistrée.

RHEL 9 fournit grafana 7.5.11

RHEL 9 est distribué avec le paquet grafana version 7.5.11. Les changements notables par rapport à la version 7.5.9 sont les suivants :

RHEL 9 fournit grafana-pcp 3.2.0

RHEL 9 est distribué avec la version 3.2.0 du paquet grafana-pcp. Les corrections de bogues et améliorations notables par rapport à la version 3.1.0 sont les suivantes :

L'accès aux hôtes distants par l'intermédiaire d'un site central pmproxy pour la source de données Vector dans grafana-pcp

Dans certains environnements, la politique de réseau n'autorise pas les connexions du navigateur de l'observateur du tableau de bord aux hôtes surveillés directement. Cette mise à jour permet de personnaliser le site hostspec afin de se connecter à un site central pmproxy, qui transmet les demandes aux différents hôtes.

Un nouveau paquet : ansible-pcp

Le package ansible-pcp contient des rôles pour Performance Co-Pilot (PCP) et des logiciels connexes, tels que Redis et Grafana, utilisés pour mettre en œuvre le rôle de système RHEL metrics.

RHEL 9 fournit python-jsonpointer 2.0

RHEL 9 est distribué avec le paquet python-jsonpointer version 2.0.

.NET 6.0 est disponible

RHEL 9 est distribué avec .NET version 6.0. Les améliorations notables sont les suivantes :

Implémentations Java dans RHEL 9

Le référentiel RHEL 9 AppStream comprend :

Outils Java dans RHEL 9

Le référentiel RHEL 9 AppStream comprend les outils Java suivants :

SWIG 4.0 disponible dans le répertoire du CRB

La version 4.0 du SWIG (Simplified Wrapper and Interface Generator) est disponible dans le dépôt CodeReady Linux Builder (CRB). Cette version ajoute la prise en charge de PHP 8.

Directory Server n'utilise plus de journal des modifications global

Avec cette amélioration, le journal des modifications de Directory Server a été intégré dans la base de données principale. Auparavant, Directory Server utilisait un journal des modifications global. Cependant, cela pouvait poser des problèmes si l'annuaire utilisait plusieurs bases de données. Par conséquent, chaque suffixe a maintenant son propre journal des modifications dans le même répertoire que les fichiers de la base de données principale.

ansible-freeipa est maintenant disponible dans le dépôt AppStream avec toutes les dépendances

Auparavant, dans RHEL 8, avant d'installer le paquet ansible-freeipa, vous deviez d'abord activer le référentiel Ansible et installer le paquet ansible. Dans RHEL 8.6 et RHEL 9, vous pouvez installer ansible-freeipa sans aucune étape préalable. L'installation de ansible-freeipa installe automatiquement le paquetage ansible-core, une version plus basique de ansible, en tant que dépendance. Les paquets ansible-freeipa et ansible-core sont disponibles dans le dépôt rhel-9-for-x86_64-appstream-rpms.

IdM supporte désormais les modules Ansible automountlocation, automountmap, et automountkey

Avec cette mise à jour, le paquet ansible-freeipa contient les modules ipaautomountlocation, ipaautomountmap, et ipaautomountkey. Vous pouvez utiliser ces modules pour configurer les répertoires à monter automatiquement pour les utilisateurs IdM connectés aux clients IdM dans un emplacement IdM. Notez qu'actuellement, seules les cartes directes sont prises en charge.

La prise en charge de la gestion des plages de sous-identifiants est disponible dans le module shadow-utils

Auparavant, shadow-utils configurait automatiquement les plages de sous-identifiants à partir des fichiers /etc/subuid et /etc/subgid. Avec cette mise à jour, la configuration des plages de sous-identifiants est disponible dans le fichier /etc/nsswitch.conf en définissant une valeur dans le champ subid. Pour plus d'informations, voir man subuid et man subgid. De plus, avec cette mise à jour, une implémentation SSSD du plugin shadow-utils est disponible, qui fournit les plages de sous-identifiants à partir du serveur IPA. Pour utiliser cette fonctionnalité, ajoutez la valeur subid: sss au fichier /etc/nsswitch.conf. Cette solution pourrait être utile dans l'environnement conteneurisé pour faciliter les conteneurs sans racine.

La gestion des plages de sous-identifiants est prise en charge par IdM

Avec cette mise à jour, vous pouvez gérer les sous-gammes d'ID pour les utilisateurs dans la gestion des identités. Vous pouvez utiliser l'outil CLI ipa ou l'interface WebUI IdM pour attribuer à un utilisateur des plages de sous-ID configurées automatiquement, ce qui peut s'avérer utile dans un environnement conteneurisé.

Les paquets d'installation de la gestion des identités ont été démodularisés

Auparavant, dans RHEL 8, les paquets IdM étaient distribués sous forme de modules, ce qui nécessitait d'activer un flux et d'installer le profil correspondant à l'installation souhaitée. Les paquets d'installation IdM ont été démodularisés dans RHEL 9, de sorte que vous pouvez utiliser les commandes dnf suivantes pour installer les paquets de serveur IdM :

Une alternative au dépôt traditionnel RHEL ansible-freeipa : Hub d'automatisation Ansible

Avec cette mise à jour, vous pouvez télécharger les modules ansible-freeipa depuis Ansible Automation Hub (AAH) au lieu de les télécharger depuis le dépôt RHEL standard. En utilisant AAH, vous pouvez bénéficier des mises à jour plus rapides des modules ansible-freeipa disponibles dans ce dépôt.

les modules ansible-freeipa peuvent désormais être exécutés à distance sur les clients IdM

Auparavant, les modules ansible-freeipa ne pouvaient être exécutés que sur les serveurs IdM. Cela nécessitait que votre administrateur Ansible ait un accès SSH à votre serveur IdM, ce qui constituait une menace potentielle pour la sécurité. Avec cette mise à jour, vous pouvez exécuter les modules ansible-freeipa à distance sur des systèmes qui sont des clients IdM. Par conséquent, vous pouvez gérer la configuration et les entités IdM de manière plus sécurisée.

Le module ipadnsconfig exige désormais que action: member exclue un transitaire global

Avec cette mise à jour, l'exclusion des expéditeurs globaux dans la gestion de l'identité (IdM) en utilisant le module ansible-freeipa ipadnsconfig nécessite l'utilisation de l'option action: member en plus de l'option state: absent. Si vous n'utilisez que state: absent dans votre manuel de jeu sans utiliser également action: member, le manuel de jeu échoue. Par conséquent, pour supprimer tous les transitaires globaux, vous devez tous les spécifier individuellement dans le cahier d'exécution. En revanche, l'option state: present ne nécessite pas action: member.

Les groupes privés automatiques pour les utilisateurs AD permettent une configuration centralisée

Vous pouvez désormais définir de manière centralisée la façon dont les versions compatibles de SSSD sur les clients IdM gèrent les groupes privés pour les utilisateurs des domaines Active Directory de confiance. Grâce à cette amélioration, vous pouvez désormais définir explicitement la valeur de l'option auto_private_groups de SSSD pour une plage d'identifiants qui gère les utilisateurs AD.

Paramètres de journalisation personnalisables pour BIND

Avec cette amélioration, vous pouvez maintenant configurer les paramètres de journalisation pour le composant serveur DNS BIND d'un serveur de gestion d'identité dans le fichier de configuration /etc/named/ipa-logging-ext.conf.

Découverte automatique des serveurs IdM lors de la récupération d'un keytab IdM

Grâce à cette amélioration, il n'est plus nécessaire de spécifier le nom d'hôte d'un serveur IdM lors de la récupération d'un keytab Kerberos à l'aide de la commande ipa-getkeytab. Si vous ne spécifiez pas de nom d'hôte de serveur, la recherche DNS est utilisée pour trouver un serveur IdM. Si aucun serveur n'est trouvé, la commande revient à la valeur host spécifiée dans le fichier de configuration /etc/ipa/default.conf.

RHEL 9 fournit Samba 4.15.5

RHEL 9 est distribué avec Samba 4.15.5, qui apporte des corrections de bogues et des améliorations par rapport à la version 4.14 :

Suivi des demandes des clients à l'aide de l'outil d'analyse des logs

Le démon des services de sécurité du système (SSSD) comprend désormais un outil d'analyse des journaux qui suit les demandes du début à la fin dans les fichiers journaux de plusieurs composants SSSD.

SSSD enregistre désormais les backtraces par défaut

Avec cette amélioration, SSSD stocke désormais des journaux de débogage détaillés dans une mémoire tampon et les ajoute aux fichiers journaux lorsqu'une erreur se produit. Par défaut, les niveaux d'erreur suivants déclenchent une trace arrière :

La valeur de hachage SSH par défaut de SSSD est désormais cohérente avec les paramètres d'OpenSSH

La valeur par défaut de ssh_hash_known_hosts a été changée en false. Elle est maintenant cohérente avec la configuration d'OpenSSH, qui ne hache pas les noms d'hôtes par défaut.

Directory Server 12.0 est basé sur la version amont 2.0.14

Directory Server 12.0 est basé sur la version amont 2.0.14 qui apporte un certain nombre de corrections de bogues et d'améliorations par rapport à la version précédente. Pour une liste complète des changements notables, lisez les notes de mise à jour de la version amont avant de procéder à la mise à jour :

Directory Server stocke désormais les fichiers de bases de données mappés en mémoire sur un système de fichiers tmpfs

Dans Directory Server, le paramètre nsslapd-db-home-directory définit l'emplacement des fichiers en mémoire des bases de données. Cette amélioration modifie la valeur par défaut du paramètre, qui passe de /var/lib/dirsrv/slapd-instance_name/db/ à /dev/shm/. Par conséquent, lorsque les bases de données internes sont stockées sur un système de fichiers tmpfs, les performances de Directory Server augmentent.

GNOME mis à jour à la version 40

L'environnement GNOME a été mis à jour de GNOME 3.28 à GNOME 40 avec de nombreuses nouvelles fonctionnalités.

PipeWire est désormais le service audio par défaut

Le service Pipewire gère désormais toutes les sorties et entrées audio. Pipewire remplace le service PulseAudio dans les cas d'utilisation générale et le service JACK dans les cas d'utilisation professionnelle. Le système redirige désormais l'audio des applications qui utilisent PulseAudio, JACK ou le cadre ALSA vers Pipewire.

Les profils d'alimentation sont disponibles dans GNOME

Vous pouvez désormais basculer entre plusieurs profils d'alimentation dans le panneau Power de Settings dans l'environnement GNOME. Les profils d'alimentation optimisent différents paramètres du système en fonction de l'objectif sélectionné.

Le soutien linguistique est désormais assuré par langpacks

La prise en charge de plusieurs langues est désormais disponible à partir des paquets langpacks. Vous pouvez personnaliser le niveau de prise en charge des langues que vous souhaitez installer en utilisant les noms de paquets suivants, où code est le code ISO abrégé de la langue, par exemple es pour l'espagnol :

Environnement léger à application unique

Pour les cas d'utilisation graphique qui ne présentent qu'une seule application, une interface utilisateur légère est désormais disponible.

Bannières de classification de sécurité à l'ouverture de session et dans la session de bureau

Vous pouvez désormais configurer des bannières de classification indiquant le niveau global de classification de sécurité du système. Cette fonction est utile pour les déploiements dans lesquels l'utilisateur doit connaître le niveau de classification de sécurité du système sur lequel il est connecté.

Le fond d'écran par défaut ajoute un logo Red Hat

Le fond d'écran par défaut de RHEL affiche désormais un logo Red Hat. Le logo est situé dans le coin supérieur gauche de l'écran.

Firefox utilise désormais un cryptage plus fort dans les fichiers PKCS#12

Le navigateur web Firefox utilise des fichiers PKCS#12 pour établir des certificats d'authentification client. Auparavant, Firefox chiffrait ces fichiers à l'aide d'algorithmes anciens :

La session Wayland est désormais la session par défaut avec les pilotes NVIDIA

Lors de l'utilisation des pilotes NVIDIA, la session de bureau sélectionne désormais le protocole d'affichage Wayland par défaut, si la configuration du pilote prend en charge Wayland. Dans les versions précédentes de RHEL, les pilotes NVIDIA désactivaient toujours Wayland.

Authentification par carte à puce pour sudo et SSH depuis la console web

Auparavant, il n'était pas possible d'utiliser l'authentification par carte à puce pour obtenir les privilèges sudo ou utiliser SSH dans la console web. Avec cette mise à jour, les utilisateurs de la gestion des identités peuvent utiliser une carte à puce pour obtenir les privilèges sudo ou pour se connecter à un hôte différent avec SSH.

Corrections de sécurité du noyau sans redémarrage dans la console web

Cette mise à jour de la console web permet aux utilisateurs d'appliquer les correctifs de sécurité du noyau sans forcer les redémarrages en utilisant le cadre kpatch. Les administrateurs peuvent également abonner automatiquement tout futur noyau au flux de correctifs en direct.

La console web RHEL fournit l'enregistrement Insights par défaut

Avec cette mise à jour, lorsque vous utilisez la console Web de Red Hat Enterprise Linux pour enregistrer un système RHEL, la case Connect this system to Red Hat Insights. est cochée par défaut. Si vous ne souhaitez pas vous connecter au service Insights, décochez la case.

Cockpit supporte désormais l'utilisation d'un certificat TLS existant

Grâce à cette amélioration, le certificat n'est plus soumis à des exigences strictes en matière d'autorisation de fichiers (comme root:cockpit-ws 0640) et peut donc être partagé avec d'autres services.

Le rôle de système de mise en réseau prend désormais en charge le SAE

Dans les réseaux Wi-Fi protected access version 3 (WPA3), la méthode d'authentification simultanée des égaux (SAE) garantit que la clé de chiffrement n'est pas transmise. Avec cette amélioration, le rôle de système RHEL de mise en réseau prend en charge la méthode SAE. Par conséquent, les administrateurs peuvent désormais utiliser le rôle de système de mise en réseau pour configurer les connexions aux réseaux Wi-Fi qui utilisent WPA-SAE.

Le rôle de système de mise en réseau prend désormais en charge owe

Le rôle de système RHEL de mise en réseau prend désormais en charge le chiffrement sans fil opportuniste (owe). owe est un type de gestion de clé d'authentification sans fil qui utilise le chiffrement entre les clients Wi-Fi et les points d'accès, et protège les clients Wi-Fi contre les attaques de reniflage. Pour utiliser owe, définissez le champ Type de gestion de clé d'authentification sans fil,key_mgmt, sur owe.

Le rôle de système de pare-feu permet désormais de définir la zone par défaut du pare-feu

Les zones représentent un concept permettant de gérer le trafic entrant de manière plus transparente. Les zones sont connectées à des interfaces de réseau ou se voient attribuer une série d'adresses sources. Les règles de pare-feu pour chaque zone sont gérées indépendamment, ce qui permet à l'administrateur de définir des paramètres de pare-feu complexes et de les appliquer au trafic. Cette fonctionnalité permet de définir la zone par défaut utilisée comme zone par défaut pour l'attribution des interfaces, comme sur firewall-cmd --set-default-zone zone-name.

Le rôle de système RHEL de stockage prend désormais en charge les volumes LVM VDO

Avec cette amélioration, vous pouvez utiliser le rôle de système de stockage pour gérer les volumes LVM (Logical Manager Volumes) Virtual Data Optimizer (VDO). Le système de fichiers LVM gère les volumes VDO et, grâce à cette fonctionnalité, il est désormais possible de compresser et de dédupliquer sur les volumes LVM. Ainsi, VDO permet d'optimiser l'utilisation des volumes de stockage.

La prise en charge des tailles de volume exprimées en pourcentage est disponible dans le rôle de système de stockage

Cette amélioration ajoute au rôle de système RHEL de stockage la prise en charge de l'expression de la taille des volumes LVM en tant que pourcentage de la taille totale du pool. Vous pouvez spécifier la taille des volumes LVM en pourcentage de la taille du pool/VG, par exemple : 50 % en plus de la taille lisible par l'homme du système de fichiers, par exemple, 10g, 50 GiB.

La prise en charge des volumes mis en cache est disponible dans le rôle de système de stockage

Cette amélioration ajoute la prise en charge du rôle de système RHEL de stockage pour créer et gérer des volumes logiques LVM mis en cache. Le cache LVM peut être utilisé pour améliorer les performances des volumes logiques plus lents, en stockant temporairement des sous-ensembles de données d'un LV sur un périphérique plus petit et plus rapide, par exemple un SSD.

Possibilité d'ajouter ou de supprimer des sources au rôle de pare-feu

Cette mise à jour permet d'ajouter ou de supprimer des sources dans la configuration des paramètres du pare-feu à l'aide du paramètre source.

Nouveau rôle Ansible pour la gestion de Microsoft SQL Server

Le nouveau rôle microsoft.sql.server est conçu pour aider les administrateurs informatiques et de bases de données à automatiser les processus d'installation, de configuration et d'optimisation des performances de SQL Server sur Red Hat Enterprise Linux.

Microsoft SQL System Role prend désormais en charge le dépôt personnalisé pour les abonnements déconnectés ou satellites

Auparavant, les utilisateurs d'environnements déconnectés qui devaient télécharger des paquets à partir d'un serveur personnalisé ou les utilisateurs de Satellite qui devaient pointer vers Satellite ou Capsule n'étaient pas pris en charge par le rôle microsoft.sql.server. Cette mise à jour corrige ce problème en fournissant les variables mssql_rpm_key, mssql_server_repository, et mssql_client_repository que vous pouvez utiliser pour personnaliser les référentiels à partir desquels télécharger les paquets. Si aucune URL n'est fournie, le rôle mssql utilise les serveurs officiels de Microsoft pour télécharger les RPM.

Le rôle MSSQL utilise systématiquement le commentaire "Ansible_managed" dans ses fichiers de configuration gérés

Le rôle MSSQL génère le fichier de configuration /var/opt/mssql/mssql.conf. Avec cette mise à jour, le rôle MSSQL insère le commentaire "Ansible managed" dans les fichiers de configuration, en utilisant la variable standard Ansible ansible_managed. Le commentaire indique que les fichiers de configuration ne doivent pas être modifiés directement car le rôle MSSQL peut écraser le fichier. Par conséquent, les fichiers de configuration contiennent une déclaration indiquant que les fichiers de configuration sont gérés par Ansible.

Prise en charge par Ansible Core des rôles système RHEL

À partir de la version RHEL 9 GA, Ansible Core est fourni, avec une portée de support limitée, pour permettre les cas d'utilisation d'automatisation pris en charge par RHEL. Ansible Core remplace Ansible Engine qui était fourni sur les versions précédentes de RHEL dans un dépôt séparé. Ansible Core est disponible dans le dépôt AppStream pour RHEL. Pour plus de détails sur les cas d'utilisation pris en charge, voir Scope of support for the Ansible Core package included in the RHEL 9 AppStream.

Prise en charge de la configuration de plusieurs hôtes elasticsearch dans un dictionnaire de sortie elasticsearch

Auparavant, le paramètre server_host prenait une valeur de chaîne pour un seul hôte. Cette amélioration l'adapte à la spécification sous-jacente rsyslog omelasticsearch’s, de sorte qu'il accepte désormais également une liste de chaînes de caractères pour prendre en charge plusieurs hôtes. Par conséquent, il est adapté aux hôtes, conformément à la spécification sous-jacente rsyslog omelasticsearch’s. Par conséquent, les utilisateurs peuvent configurer plusieurs hôtes elasticsearch dans un seul dictionnaire de sortie elasticsearch.

Les rôles système RHEL prennent désormais en charge la gestion des VPN

Auparavant, il était difficile de mettre en place des solutions sécurisées et correctement configurées de tunneling IPsec et de réseau privé virtuel (VPN) sur Linux. Grâce à cette amélioration, vous pouvez utiliser le rôle système VPN RHEL pour mettre en place et configurer plus facilement des tunnels VPN pour les connexions d'hôte à hôte et les connexions maillées sur un grand nombre d'hôtes. Vous disposez ainsi d'une interface de configuration cohérente et stable pour la configuration des tunnels VPN et IPsec dans le cadre du projet RHEL System Roles.

Le rôle de système SSHD RHEL prend désormais en charge les extraits de configuration non exclusifs

Grâce à cette fonctionnalité, vous pouvez configurer SSHD à travers différents rôles et playbooks sans réécrire les configurations précédentes en utilisant des espaces de noms. Les espaces de noms sont similaires à un répertoire de dépôt et définissent des extraits de configuration non exclusifs pour SSHD. Par conséquent, vous pouvez utiliser le rôle de système SSHD RHEL à partir d'un rôle différent, si vous avez besoin de configurer seulement une petite partie de la configuration et non pas le fichier de configuration entier.

Ajout de l'option Network Time Security (NTS) au rôle de système timesync RHEL

L'option NTS a été ajoutée au rôle système de Timesync RHEL pour activer NTS sur les serveurs clients. NTS est un nouveau mécanisme de sécurité spécifié pour le protocole NTP (Network Time Protocol). NTS peut sécuriser la synchronisation des clients NTP sans configuration spécifique au client et peut s'adapter à un grand nombre de clients. L'option NTS n'est prise en charge qu'avec le fournisseur NTP chrony à partir de la version 4.0.

Prise en charge du rôle de système RHEL pour les clusters HA

Le rôle de cluster de haute disponibilité (HA Cluster) est désormais entièrement pris en charge. Les configurations suivantes sont disponibles :

Prise en charge de l'authentification par nom d'utilisateur et mot de passe Rsyslog pour Elasticsearch

Cette mise à jour ajoute les paramètres de nom d'utilisateur et de mot de passe Elasticsearch au rôle de système de journalisation. Par conséquent, vous pouvez permettre à Rsyslog de s'authentifier auprès d'Elasticsearch à l'aide d'un nom d'utilisateur et d'un mot de passe.

Le rôle du système client de l'EDNB prend en charge les adresses IP statiques

Dans les versions précédentes de RHEL, le redémarrage d'un système doté d'une adresse IP statique et configuré avec le rôle de système client NBDE (Network Bound Disk Encryption) modifiait l'adresse IP du système. Avec cette modification, les systèmes avec des adresses IP statiques sont pris en charge par le rôle de système client NBDE et leurs adresses IP ne changent pas après un redémarrage.

La prise en charge de la spécification de raid_level pour LVM a été ajoutée

RHEL 9.0 prend en charge le regroupement des volumes LVM (Logical Volume Management) en RAID à l'aide de la fonctionnalité lvmraid.

Le rôle Certificat utilise systématiquement le commentaire "Ansible_managed" dans ses scripts d'accroche

Avec cette amélioration, le rôle de certificat génère des pré-scripts et des post-scripts pour soutenir les fournisseurs, auxquels le rôle insère le commentaire "Ansible managed" à l'aide de la variable standard Ansible "ansible_managed" :

Une nouvelle option auto_gateway permet de contrôler le comportement de l'itinéraire par défaut

Auparavant, le paramètre DEFROUTE n'était pas configurable à l'aide de fichiers de configuration, mais uniquement manuellement en nommant chaque itinéraire. Cette mise à jour ajoute une nouvelle option auto_gateway dans la section de configuration ip pour les connexions, avec laquelle vous pouvez contrôler le comportement de l'itinéraire par défaut. Vous pouvez configurer auto_gateway de la manière suivante :

Prise en charge de toutes les options de collage ajoutées au rôle du système network

Cette mise à jour prend en charge toutes les options de liaison pour le rôle de système RHEL network. Par conséquent, elle vous permet de contrôler de manière flexible la transmission du réseau sur l'interface liée. Par conséquent, vous pouvez contrôler la transmission du réseau sur l'interface liée en spécifiant plusieurs options pour cette interface.

NetworkManager permet de spécifier une carte réseau à l'aide de son adresse PCI

Auparavant, lors de l'établissement d'un profil de connexion, NetworkManager ne pouvait spécifier une carte réseau qu'en utilisant son nom ou son adresse MAC. Dans ce cas, le nom de l'appareil n'est pas stable et l'adresse MAC nécessite un inventaire pour maintenir l'enregistrement des adresses MAC utilisées. Désormais, vous pouvez spécifier une carte réseau en fonction de son adresse PCI dans un profil de connexion.

Le rôle Network System gère désormais directement les fichiers de configuration d'Ansible

Avec cette amélioration, le rôle network génère des fichiers ifcfg dans /etc/sysconfig/network-scripts. Il insère ensuite le commentaire "Ansible managed", en utilisant la variable standard ansible_managed. Ce commentaire indique que les fichiers ifcfg ne sont pas directement modifiables car le rôle network peut les écraser. La différence importante dans le traitement du fichier ifcfg pour ajouter le commentaire "Ansible managed" est que le rôle network utilise le paquetage initscripts alors que le NetworkManager utilise le paquetage nm.

Prise en charge par Ansible Core des rôles système RHEL

Dans RHEL 9.0, Ansible Core est fourni, avec une portée de support limitée, pour permettre les cas d'utilisation d'automatisation pris en charge par RHEL. Ansible Core remplace Ansible Engine qui était précédemment fourni dans un dépôt séparé. Ansible Core est disponible dans le dépôt AppStream pour RHEL. Pour plus de détails sur les cas d'utilisation pris en charge, voir Scope of support for the Ansible Core package included in the RHEL 9 and RHEL 8.6 and later AppStream repositories. Les utilisateurs doivent migrer manuellement leurs systèmes d'Ansible Engine vers Ansible Core.

Le rôle de système de cockpit est désormais pris en charge

Grâce à cette amélioration, vous pouvez installer et configurer la console web dans votre système. Par conséquent, vous pouvez gérer la console web de manière automatisée.

Le rôle de système d'enregistrement de la session Terminal utilise le commentaire "Ansible managed" dans ses fichiers de configuration gérés

Le rôle d'enregistrement de session terminal génère 2 fichiers de configuration :

Le rôle VPN utilise systématiquement le commentaire "Ansible_managed" dans ses fichiers de configuration gérés

Le rôle VPN génère le fichier de configuration suivant :

Le rôle Postfix utilise systématiquement le commentaire "Ansible_managed" dans ses fichiers de configuration gérés

Le rôle Postfix génère le fichier de configuration /etc/postfix/main.cf. Avec cette mise à jour, le rôle Postfix insère le commentaire "Ansible managed" dans les fichiers de configuration, en utilisant la variable standard Ansible ansible_managed. Le commentaire indique que les fichiers de configuration ne doivent pas être modifiés directement car le rôle Postfix peut écraser le fichier. En conséquence, les fichiers de configuration contiennent une déclaration indiquant que les fichiers de configuration sont gérés par Ansible.

Le rôle de système RHEL de pare-feu a été ajouté dans RHEL 9

Avec cette amélioration, le rôle de système RHEL rhel-system-roles.firewall a été ajouté au paquetage rhel-system-roles. Les administrateurs peuvent ainsi automatiser leurs paramètres de pare-feu pour les nœuds gérés.

Le client SSH RHEL System Role prend désormais en charge les nouvelles options de configuration d'OpenSSH 8.7

Avec cette amélioration, OpenSSH a été mis à jour vers la dernière version, qui fournit de nouvelles options de configuration disponibles dans le rôle de client SSH pour configurer de nouveaux hôtes.

Nouvelles fonctionnalités de virtualisation de la console web RHEL

Avec cette mise à jour, la console web RHEL inclut de nouvelles fonctionnalités dans la page Machines virtuelles. Vous pouvez désormais :

QEMU utilise Clang

L'émulateur QEMU est désormais construit à l'aide du compilateur Clang. Cela permet à l'hyperviseur KVM de RHEL 9 d'utiliser un certain nombre de fonctions de sécurité et de débogage avancées, et rend le développement de futures fonctions plus efficace.

SafeStack pour les machines virtuelles

Dans RHEL 9 sur du matériel AMD64 et Intel 64 (x86_64), l'émulateur QEMU peut utiliser SafeStack, une fonction améliorée de protection de la pile basée sur le compilateur. SafeStack réduit la capacité d'un attaquant à exploiter un débordement de mémoire tampon basé sur la pile pour modifier les pointeurs de retour dans la pile et créer des attaques de programmation orientée retour (Return-Oriented Programming, ROP). Par conséquent, les machines virtuelles hébergées sur RHEL 9 sont nettement plus sûres contre les vulnérabilités basées sur la programmation orientée retour.

prise en charge complète des virus sur Intel 64, AMD64 et IBM Z

Le système de fichiers virtio (virtiofs) est désormais entièrement pris en charge sur les architectures Intel 64, AMD64 et IBM Z. En utilisant virtiofs, vous pouvez partager efficacement des fichiers entre votre système hôte et ses machines virtuelles.

Processeurs AMD EPYC 7003 pris en charge par les invités KVM

La prise en charge des processeurs AMD EPYC de la série 7003 (également connus sous le nom de AMD Milan) a été ajoutée au code de l'hyperviseur et du noyau KVM, ainsi qu'à l'API libvirt. Cela permet aux machines virtuelles KVM d'utiliser les processeurs AMD EPYC de la série 7003.

qemu-kvm prend désormais en charge d'autres types de machines

Un ensemble de nouveaux types de machines, basés sur RHEL 9, a été ajouté pour être utilisé par les machines virtuelles (VM). Pour obtenir tous les types de machines actuellement pris en charge sur votre hôte, utilisez la commande /usr/libexec/qemu-kvm -M help.

Les périphériques médiatisés sont désormais pris en charge par les CLI de virtualisation sur IBM Z

En utilisant virt-install ou virt-xml, vous pouvez désormais attacher des périphériques à médiation à vos machines virtuelles, tels que vfio-ap et vfio-ccw. Cela permet par exemple une gestion plus souple des périphériques de stockage DASD et des coprocesseurs cryptographiques sur les hôtes IBM Z. En outre, à l'aide de virt-install, vous pouvez créer une VM qui utilise un périphérique DASD existant comme disque principal. Pour obtenir des instructions à ce sujet, consultez le guide Configurer et gérer la virtualisation dans RHEL 9.

Démons modulaires libvirt

Dans RHEL 9, la bibliothèque libvirt utilise des démons modulaires qui gèrent des ensembles de pilotes de virtualisation individuels sur votre hôte. Par exemple, le démon virtqemud gère les pilotes QEMU. Il est ainsi possible d'affiner une série de tâches impliquant des pilotes de virtualisation, telles que l'optimisation de la charge des ressources et la surveillance.

Les invités Windows 11 et Windows Server 2022 sont pris en charge

RHEL 9 prend en charge l'utilisation de Windows 11 et Windows Server 2022 en tant que systèmes d'exploitation invités sur les machines virtuelles KVM.

ksmtuned est désormais distribué séparément de qemu-kvm

Afin de réduire l'empreinte de l'hyperviseur KVM, l'utilitaire ksmtuned ne dépend plus de qemu-kvm. Par conséquent, si vous souhaitez configurer la fusion des pages identiques du noyau (KSM), vous devez installer manuellement le paquetage ksmtuned.

Nouvelle fonctionnalité : vTPM

Le module de plateforme virtuelle de confiance (vTPM) est entièrement pris en charge dans RHEL 9. vTPM permet d'ajouter un crypto-processeur virtuel TPM à une machine virtuelle (VM) exécutée dans l'hyperviseur KVM de RHEL 9. Il est ainsi possible d'utiliser la VM pour générer, stocker et gérer des clés cryptographiques.

Prise en charge de la virtualisation pour les processeurs Intel Atom de la série P59

Avec cette mise à jour, la virtualisation sur RHEL 9 ajoute la prise en charge des processeurs Intel Atom de la série P59, anciennement connus sous le nom de Snow Ridge. Par conséquent, les machines virtuelles hébergées sur RHEL 9 peuvent désormais utiliser le modèle de CPU Snowridge et profiter des nouvelles fonctionnalités offertes par ces processeurs.

RHEL 9 fournit WALinuxAgent 2.3.0.2

RHEL 9 est distribué avec le paquetage Windows Azure Linux Agent (WALinuxAgent) version 2.3.0.2. Les corrections de bogues et améliorations notables par rapport à la version 2.2.49 sont les suivantes :

RHEL on Azure prend désormais en charge MANA

Les machines virtuelles RHEL 9 fonctionnant sur Microsoft Azure peuvent désormais utiliser l'adaptateur réseau Microsoft Azure (MANA).

cloud-init prend en charge la source de données VMware GuestInfo

Avec cette mise à jour, l'utilitaire cloud-init est en mesure de lire la source de données pour les données VMware guestinfo. Par conséquent, l'utilisation de cloud-init pour configurer des machines virtuelles RHEL 9 sur VMware vSphere est désormais plus efficace et plus fiable.

Les machines virtuelles RHEL 9 sont désormais prises en charge sur certains hôtes ARM64 sur Azure

Les machines virtuelles utilisant RHEL 9 comme système d'exploitation invité sont désormais prises en charge sur les hyperviseurs Microsoft Azure fonctionnant sur des processeurs Ampere Altra ARM.

cloud-init prend en charge les données des utilisateurs sur Microsoft Azure

L'option --user-data a été introduite pour l'utilitaire cloud-init. Cette option permet de transmettre des scripts et des métadonnées du service de métadonnées d'instance Azure (IMDS) lors de la configuration d'une machine virtuelle RHEL 9 sur Azure.

Nouveau module SSH pour cloud-init

Avec cette mise à jour, un module SSH a été ajouté à l'utilitaire cloud-init, qui génère automatiquement des clés d'hôte lors de la création d'une instance.

sos report propose désormais un mode d'estimation

Cette mise à jour de sos report ajoute l'option --estimate-only qui permet d'évaluer l'espace disque nécessaire à la collecte d'un rapport sos à partir d'un serveur RHEL. Exécution de la commande sos report --estimate-only:

Podman prend désormais en charge les noms courts sécurisés

Les alias de noms courts pour les images peuvent désormais être configurés dans le fichier registries.conf, dans la table [aliases]. Les modes de noms courts sont les suivants :

Changements dans le module container-tools

Le module container-tools contient les outils Podman, Buildah, Skopeo et runc. Le flux roulant, représenté par le flux container-tools:rhel8 dans RHEL 8, est nommé container-tools:latest dans RHEL 9. Comme dans RHEL 8, les versions stables des outils de conteneur seront disponibles dans des flux numérotés (par exemple, 3.0).

Le paquet containers-common est maintenant disponible

Le paquet containers-common a été ajouté au module container-tools:latest. Le paquet containers-common contient des fichiers de configuration communs et de la documentation pour l'écosystème des outils de conteneurs, tels que Podman, Buildah et Skopeo.

Mise à jour des images de conteneurs avec de nouveaux paquets

Par exemple, pour mettre à jour l'image du conteneur registry.access.redhat.com/rhel9 avec les derniers paquets, utilisez les commandes suivantes :

Le méta-paquet container-tools a été mis à jour

Le méta-paquet RPM container-tools, qui contient les outils Podman, Buildah, Skopeo et runc, est désormais disponible. Cette mise à jour fournit une liste de corrections de bogues et d'améliorations par rapport à la version précédente.

Le paquet podman-py est maintenant disponible

Le paquet podman-py a été ajouté au flux de modules stables container-tools:3.0 et au module container-tools:latest. Le paquet podman-py est une bibliothèque de liens permettant d'utiliser l'API RESTful de Podman.

La version 2 des groupes de contrôle est maintenant disponible

La version précédente des groupes de contrôle, cgroups version 1 (cgroups v1), entraînait des problèmes de performance avec diverses applications. La dernière version des groupes de contrôle, cgroups version 2 (cgroups v2), permet aux administrateurs système de limiter les ressources pour n'importe quelle application sans causer de problèmes de performance.

Le méta-paquet container-tools est maintenant disponible

Le méta-paquet RPM container-tools, qui comprend Podman, Buildah, Skopeo, CRIU, Udica et toutes les bibliothèques requises, est disponible dans RHEL 9. Les flux stables ne sont pas disponibles sur RHEL 9. Pour bénéficier d'un accès stable à Podman, Buildah, Skopeo et autres, utilisez l'abonnement RHEL EUS.

La prise en charge native des systèmes de fichiers superposés dans le noyau est désormais disponible

La prise en charge des systèmes de fichiers superposés est désormais disponible à partir du noyau 5.11. Les utilisateurs non rootés bénéficieront des performances natives du système de fichiers overlayfs même lorsqu'ils fonctionnent sans root (en tant qu'utilisateur). Ainsi, cette amélioration fournit de meilleures performances aux utilisateurs non root qui souhaitent utiliser overlayfs sans avoir besoin de bind mounting.

Le stockage NFS est maintenant disponible

Vous pouvez désormais utiliser le système de fichiers NFS comme support de stockage pour les conteneurs et les images si votre système de fichiers prend en charge les xattr.

Le méta-paquet container-tools a été mis à jour

Le méta-paquet container-tools comprend Podman, Buildah, Skopeo, CRIU, Udica et toutes les bibliothèques nécessaires. Cette mise à jour fournit une liste de corrections de bogues et d'améliorations par rapport à la version précédente.

Le conteneur d'exécution crun est maintenant utilisé par défaut

L'exécution du conteneur crun est désormais l'exécution par défaut. L'exécution du conteneur crun prend en charge une annotation qui permet au conteneur d'accéder aux groupes supplémentaires de l'utilisateur sans racine. Ceci est utile pour le montage de volumes dans un répertoire où setgid est défini, ou lorsque l'utilisateur n'a qu'un accès de groupe. Les moteurs d'exécution crun et runc supportent entièrement cgroup v2.

La version 2 du groupe de contrôle est maintenant disponible

La version précédente des groupes de contrôle, cgroup version 1 (cgroup v1), entraînait des problèmes de performance avec diverses applications. La dernière version des groupes de contrôle, cgroup version 2 (cgroup v2), permet aux administrateurs système de limiter les ressources pour n'importe quelle application sans causer de problèmes de performance.

Les images de base universelles sont désormais disponibles sur Docker Hub

Auparavant, les images de base universelles n'étaient disponibles qu'à partir du catalogue de conteneurs Red Hat. Avec cette amélioration, les images de base universelles sont également disponibles à partir de Docker Hub en tant qu'image Verified Publisher.

L'image du conteneur openssl est maintenant disponible

L'image openssl fournit un outil de ligne de commande openssl permettant d'utiliser les différentes fonctions de la bibliothèque cryptographique OpenSSL. La bibliothèque OpenSSL permet de générer des clés privées, de créer des demandes de signature de certificat (CSR) et d'afficher des informations sur les certificats.

La pile réseau Netavark est désormais disponible

La pile Netavark est un outil de configuration réseau pour les conteneurs. Dans RHEL 9, la pile Netavark est entièrement prise en charge et activée par défaut.

Podman supporte maintenant l'auto-construction et l'auto-exécution de pods à l'aide d'un fichier YAML

La commande podman play kube construit et exécute automatiquement plusieurs pods avec plusieurs conteneurs dans les pods à l'aide d'un fichier YAML.

Podman a désormais la possibilité de trouver des plages de subUID et de subGID à partir d'IdM

Les plages de sous-UID et de sous-GID peuvent désormais être gérées par IdM. Au lieu de déployer les mêmes fichiers /etc/subuid et /etc/subgid sur chaque hôte, vous pouvez maintenant définir les plages dans un seul stockage central. Vous devez modifier le fichier /etc/nsswitch.conf et ajouter sss à la ligne services map : services: files sss.

--leavebootorder ne modifie plus l'ordre de démarrage

Auparavant, l'utilisation de --leavebootorder pour la commande bootloader kickstart ne fonctionnait pas correctement sur les systèmes UEFI et modifiait l'ordre de démarrage. Le programme d'installation ajoutait alors RHEL en tête de la liste des systèmes installés dans le menu de démarrage UEFI.

Anaconda définit un nom d'hôte statique avant d'exécuter les scripts %post

Auparavant, lorsqu'Anaconda définissait le nom d'hôte de l'environnement d'installation à la valeur de la configuration de démarrage (network --hostname), il définissait un nom d'hôte transitoire. Certaines des actions effectuées pendant l'exécution du script %post, par exemple l'activation de périphériques réseau, entraînaient la réinitialisation du nom d'hôte à une valeur obtenue par l'opération inverse dns.

Les utilisateurs peuvent désormais spécifier des comptes d'utilisateurs dans le plan d'installation de RHEL for Edge

Auparavant, l'exécution d'une mise à jour sur votre blueprint sans compte utilisateur défini dans l'edge commit pour la mise à niveau, comme l'ajout d'un package rpm, entraînait le verrouillage des utilisateurs d'un système, après l'application d'une mise à niveau. Ce problème a été résolu pour permettre aux utilisateurs de spécifier des comptes d'utilisateur dans le Blueprint RHEL for Edge Installer, qui crée un utilisateur sur le système au moment de l'installation, plutôt que d'avoir l'utilisateur dans le cadre du commit ostree.

Le mode basic graphics a été supprimé du menu de démarrage

Auparavant, le mode basic graphics était utilisé pour installer RHEL sur du matériel doté d'une carte graphique non prise en charge ou pour contourner des problèmes liés aux pilotes graphiques qui empêchaient le démarrage de l'interface graphique. Avec cette mise à jour, l'option d'installation en mode basic graphics a été supprimée du menu de démarrage du programme d'installation. Utilisez les options d'installation VNC pour les installations graphiques sur du matériel non pris en charge ou pour contourner les bogues des pilotes.

virt-who fonctionne désormais correctement avec les hôtes Hyper-V

Auparavant, lors de l'utilisation de virt-who pour configurer des machines virtuelles (VM) RHEL 9 sur un hyperviseur Hyper-V, virt-who ne communiquait pas correctement avec l'hyperviseur et la configuration échouait. Cela était dû à une méthode de cryptage obsolète dans le paquet openssl.

L'exécution de createrepo_c --update sur un référentiel modulaire préserve désormais les métadonnées modulaires qui s'y trouvent

Auparavant, lors de l'exécution de la commande createrepo_c --update sur un référentiel modulaire existant sans la source originale des métadonnées modulaires, la politique par défaut était de supprimer toutes les métadonnées supplémentaires, y compris les métadonnées modulaires, de ce référentiel, ce qui, par conséquent, le cassait. Pour préserver les métadonnées, il fallait exécuter la commande createrepo_c --update avec l'option supplémentaire --keep-all-metadata.

RHEL 9 fournit libservicelog 1.1.19

RHEL 9 est distribué avec libservicelog version 1.1.19. Les corrections de bogues notables incluent :

Optimisation matérielle activée sur libgcrypt en mode FIPS

Auparavant, la norme FIPS 140-2 (Federal Information Processing Standard) n'autorisait pas l'utilisation de l'optimisation matérielle. Par conséquent, dans les versions précédentes de RHEL, l'opération était désactivée dans le paquet libgcrypt en mode FIPS. RHEL 9 permet l'optimisation matérielle en mode FIPS et, par conséquent, toutes les opérations cryptographiques sont exécutées plus rapidement.

crypto-policies il est désormais possible de désactiver l'utilisation du cryptogramme ChaCha20

Auparavant, le paquet crypto-policies utilisait un mot-clé erroné pour désactiver le chiffrement ChaCha20 dans OpenSSL. Par conséquent, vous ne pouviez pas désactiver ChaCha20 pour le protocole TLS 1.2 dans OpenSSL via crypto-policies. Avec cette mise à jour, le mot-clé -CHACHA20 est utilisé à la place de -CHACHA20-POLY1305. Par conséquent, vous pouvez maintenant utiliser les politiques cryptographiques pour désactiver l'utilisation du chiffrement ChaCha20 dans OpenSSL pour TLS 1.2 et TLS 1.3.

les systèmes IBM Z 64 bits ne deviennent plus non amorçables lors de l'installation en mode FIPS

Auparavant, la commande fips-mode-setup avec l'option --no-bootcfg n'exécutait pas l'outil zipl. Comme fips-mode-setup régénère le disque RAM initial (initrd) et que le système résultant a besoin d'une mise à jour de l'état interne de zipl pour démarrer, les systèmes IBM Z 64 bits se retrouvaient dans un état non amorçable après une installation en mode FIPS. Avec cette mise à jour, fips-mode-setup exécute désormais zipl sur les systèmes IBM Z 64 bits, même s'il est invoqué avec --no-bootcfg, ce qui permet au système nouvellement installé de démarrer avec succès.

GNUTLS_NO_EXPLICIT_INIT ne désactive plus l'initialisation implicite de la bibliothèque

Auparavant, la variable d'environnement GNUTLS_NO_EXPLICIT_INIT désactivait l'initialisation implicite de la bibliothèque. Dans RHEL 9, la variable GNUTLS_NO_IMPLICIT_INIT désactive l'initialisation implicite des bibliothèques.

Les applications basées sur OpenSSL fonctionnent désormais correctement avec les paramètres linguistiques turcs

La bibliothèque OpenSSL utilisant des fonctions de comparaison de chaînes insensibles à la casse, les applications basées sur OpenSSL ne fonctionnaient pas correctement avec les paramètres linguistiques turcs, et les vérifications omises provoquaient le plantage des applications utilisant ces paramètres. Cette mise à jour fournit un correctif permettant d'utiliser les paramètres régionaux POSIX (Portable Operating System Interface) pour la comparaison de chaînes insensibles à la casse. Par conséquent, les applications basées sur OpenSSL telles que curl fonctionnent correctement avec les paramètres linguistiques turcs.

kdump ne plante plus à cause des permissions SELinux

Le service de récupération en cas de panne kdump nécessite des autorisations SELinux supplémentaires pour démarrer correctement. Par conséquent, dans les versions précédentes, SELinux empêchait kdump de fonctionner, kdump signalait qu'il n'était pas opérationnel et des refus d'accès au cache vectoriel (AVC) étaient audités. Dans cette version, les autorisations requises ont été ajoutées à selinux-policy et, par conséquent, kdump fonctionne correctement et aucun déni d'AVC n'est audité.

Le paquet usbguard-selinux ne dépend plus de usbguard

Auparavant, le paquet usbguard-selinux dépendait du paquet usbguard. Cette dépendance, combinée à d'autres dépendances de ces paquets, entraînait des conflits de fichiers lors de l'installation de usbguard. Par conséquent, cela empêchait l'installation de usbguard sur certains systèmes. Avec cette version, usbguard-selinux ne dépend plus de usbguard, et par conséquent, dnf peut installer usbguard correctement.

dnf install et dnf update fonctionnent désormais avec fapolicyd dans SELinux

Le paquet fapolicyd-selinux, qui contient les règles SELinux pour fapolicyd, ne contenait pas les autorisations nécessaires pour surveiller tous les fichiers et répertoires. Par conséquent, le paquet fapolicyd-dnf-plugin ne fonctionnait pas correctement, ce qui faisait que les commandes dnf install et dnf update empêchaient le système de répondre indéfiniment. Dans cette version, les autorisations de surveiller tout type de fichier ont été ajoutées à fapolicyd-selinux. En conséquence, fapolicyd-dnf-plugin fonctionne correctement et les commandes dnf install et dnf update sont opérationnelles.

Les capacités ambiantes sont désormais appliquées correctement aux utilisateurs non root

Par mesure de sécurité, le passage d'un UID (User Identifier) de root à non-root annule les ensembles de capacités autorisées, efficaces et ambiantes.

usbguard-notifier n'enregistre plus trop de messages d'erreur dans le journal

Auparavant, le service usbguard-notifier ne disposait pas des autorisations de communication interprocessus (IPC) pour se connecter à l'interface IPC usbguard-daemon. Par conséquent, usbguard-notifier n'a pas réussi à se connecter à l'interface et a écrit un message d'erreur correspondant dans le Journal. Comme usbguard-notifier a démarré avec l'option --wait, qui garantit que usbguard-notifier tente de se connecter à l'interface IPC chaque seconde après un échec de connexion, par défaut, le journal contient bientôt un nombre excessif de ces messages.

Les profils de connexion Wifi et Ethernet 802.1x se connectent désormais correctement

Auparavant, de nombreux profils de connexions Wifi et Ethernet 802.1x ne pouvaient pas se connecter. Ce bogue est maintenant corrigé. Tous les profils se connectent désormais correctement. Les profils qui utilisent des algorithmes cryptographiques anciens fonctionnent toujours, mais vous devez activer manuellement le fournisseur OpenSSL ancien. Cela est nécessaire, par exemple, lorsque vous utilisez DES avec MS-CHAPv2 et RC4 avec TKIP.

Afterburn ne met plus en place un nom d'hôte trop long en /etc/hostname

La longueur maximale d'un nom d'hôte RHEL est de 64 caractères. Cependant, certains fournisseurs de services en nuage utilisent le nom de domaine entièrement qualifié (FQDN) comme nom d'hôte, qui peut comporter jusqu'à 255 caractères. Auparavant, le service afterburn-hostname écrivait un tel nom d'hôte trop long directement dans le fichier /etc/hostname. Le service systemd tronquait le nom d'hôte à 64 caractères, et NetworkManager dérivait un domaine de recherche DNS incorrect à partir de la valeur tronquée. Avec cette correction, afterburn-hostname tronque les noms d'hôtes au premier point ou à 64 caractères, selon ce qui vient en premier. Par conséquent, NetworkManager ne définit plus de domaines de recherche DNS invalides dans /etc/resolv.conf.

modprobe charge les modules du noyau hors de l'arborescence comme prévu

Le fichier de configuration /etc/depmod.d/dist.conf fournit un ordre de recherche pour l'utilitaire depmod. En fonction de l'ordre de recherche, depmod crée le fichier modules.dep.bin. Ce fichier répertorie les dépendances des modules, que l'utilitaire modprobe utilise pour charger et décharger les modules du noyau et résoudre les dépendances des modules en même temps. Auparavant, le fichier /etc/depmod.d/dist.conf était manquant. Par conséquent, modprobe ne pouvait pas charger certains modules du noyau hors-arbre. Cette mise à jour inclut le fichier de configuration /etc/depmod.d/dist.conf, qui corrige l'ordre de recherche. Par conséquent, modprobe charge les modules de noyau hors-arbre comme prévu.

alsa-lib gère désormais correctement les périphériques audio qui utilisent UCM

Un bogue dans le paquetage alsa-lib a provoqué une analyse incorrecte de l'identifiant interne du Use Case Manager (UCM). Par conséquent, certains périphériques audio utilisant la configuration UCM n'ont pas été détectés ou n'ont pas fonctionné correctement. Le problème se produisait plus souvent lorsque le système utilisait le service audio pipewire. Avec la nouvelle version de RHEL 9, le problème a été corrigé en mettant à jour la bibliothèque alsa-lib.

Les événements de protection n'entraînent plus l'échec du rechargement des dispositifs à chemins multiples

Auparavant, lorsqu'un périphérique de chemin d'accès read-only était réanalysé, le noyau envoyait deux uevents de protection en écriture - l'un avec le périphérique défini sur read/write, et le suivant avec le périphérique défini sur read-only. Par conséquent, lors de la détection de l'événement read/write sur un périphérique de chemin d'accès, multipathd a essayé de recharger le périphérique à chemins multiples, ce qui a provoqué un message d'erreur de rechargement. Avec cette mise à jour, multipathd vérifie désormais que tous les chemins d'accès sont définis sur read/write avant de recharger un périphérique en lecture/écriture. Par conséquent, multipathd n'essaie plus de recharger read/write chaque fois qu'un périphérique read-only est analysé à nouveau.

device-mapper-multipath repassé à la version 0.8.7

Le paquet device-mapper-multipath a été mis à jour vers la version 0.8.7, qui apporte de nombreuses corrections de bogues et améliorations. Les changements notables sont les suivants :

Le gestionnaire d'attributs de Pacemaker détermine correctement les attributs des nœuds distants, ce qui permet d'éviter les boucles de désencombrement

Auparavant, le contrôleur de Pacemaker sur un nœud pouvait être élu contrôleur désigné (DC) avant que son gestionnaire d'attributs n'apprenne qu'un nœud distant déjà actif était distant. Dans ce cas, le planificateur du nœud ne voyait aucun des attributs du nœud distant. Si le cluster utilisait l'unfencing, cela pouvait entraîner une boucle d'unfencing. Avec la correction, le gestionnaire d'attributs peut maintenant apprendre qu'un nœud distant est distant au moyen d'événements supplémentaires, y compris la synchronisation initiale des attributs au démarrage. Par conséquent, aucune boucle d'inféodation ne se produit, quel que soit le nœud élu DC.

-Wsequence-point correction du comportement de l'avertissement

Auparavant, lors de la compilation de programmes C avec GCC, l'option d'avertissement -Wsequence-point essayait d'avertir des expressions très longues, ce qui pouvait entraîner un comportement quadratique et donc un temps de compilation significativement plus long. Avec cette mise à jour, -Wsequence-point n'essaie pas d'avertir des expressions extrêmement longues et, par conséquent, n'augmente pas le temps de compilation.

Authentification MS-CHAP avec le fournisseur historique OpenSSL

Auparavant, les mécanismes d'authentification FreeRADIUS qui utilisaient MS-CHAP échouaient car ils dépendaient des fonctions de hachage MD4, et MD4 a été déprécié dans RHEL 9. Avec cette mise à jour, vous pouvez authentifier les utilisateurs FreeRADIUS avec MS-CHAP ou MS-CHAPv2 si vous activez le fournisseur OpenSSL hérité.

L'exécution de commandes sudo n'exporte plus la variable d'environnement KRB5CCNAME

Auparavant, après l'exécution des commandes sudo, la variable d'environnement KRB5CCNAME pointait vers le cache d'informations d'identification Kerberos de l'utilisateur d'origine, qui pouvait ne pas être accessible à l'utilisateur cible. Par conséquent, les opérations liées à Kerberos pouvaient échouer car ce cache n'était pas accessible. Avec cette mise à jour, l'exécution des commandes sudo ne définit plus la variable d'environnement KRB5CCNAME et l'utilisateur cible peut utiliser son cache d'informations d'identification Kerberos par défaut.

SSSD évalue correctement le paramètre par défaut pour le nom du keytab Kerberos dans le fichier /etc/krb5.conf

Auparavant, si vous définissiez un emplacement non standard pour votre fichier krb5.keytab, SSSD n'utilisait pas cet emplacement et utilisait à la place l'emplacement par défaut /etc/krb5.keytab. Par conséquent, lorsque vous essayiez de vous connecter au système, la connexion échouait car le fichier /etc/krb5.keytab ne contenait aucune entrée.

L'authentification au serveur d'annuaire en mode FIPS avec des mots de passe hachés avec l'algorithme PBKDF2 fonctionne désormais comme prévu

Lorsque Directory Server fonctionne en mode FIPS (Federal Information Processing Standard), la fonction PK11_ExtractKeyValue() n'est pas disponible. Par conséquent, avant cette mise à jour, les utilisateurs dont le mot de passe était haché à l'aide de l'algorithme PBKDF2 (password-based key derivation function 2) ne pouvaient pas s'authentifier auprès du serveur lorsque le mode FIPS était activé. Avec cette mise à jour, Directory Server utilise désormais la fonction PK11_Decrypt() pour obtenir les données de hachage du mot de passe. Par conséquent, l'authentification avec des mots de passe hachés avec l'algorithme PBKDF2 fonctionne maintenant comme prévu.

Le rôle de système de mise en réseau n'échoue plus à définir un domaine de recherche DNS si IPv6 est désactivé

Auparavant, la fonction nm_connection_verify() de la bibliothèque libnm n'ignorait pas le domaine de recherche DNS si le protocole IPv6 était désactivé. Par conséquent, lorsque vous utilisiez le rôle de système RHEL de mise en réseau et que vous définissiez dns_search avec ipv6_disabled: true, le rôle de système échouait avec l'erreur suivante :

Postfix role README n'utilise plus de nom de rôle simple

Auparavant, les exemples fournis dans le site /usr/share/ansible/roles/rhel-system-roles.postfix/README.md utilisaient la version simple du nom de rôle, postfix, au lieu de rhel-system-roles.postfix. Par conséquent, les utilisateurs consultaient la documentation et utilisaient à tort le nom de rôle ordinaire au lieu du nom de rôle qualifié complet (FQRN). Cette mise à jour corrige le problème et la documentation contient des exemples avec le FQRN, rhel-system-roles.postfix, ce qui permet aux utilisateurs d'écrire correctement les playbooks.

Le fichier README.md de Postfix RHEL System Role ne manque plus de variables dans la section "Role Variables"

Auparavant, les variables de rôle du système Postfix RHEL, telles que postfix_check, postfix_backup, postfix_backup_multiple, n'étaient pas disponibles dans la section "Variables de rôle". Par conséquent, les utilisateurs ne pouvaient pas consulter la documentation sur les rôles de Postfix. Cette mise à jour ajoute la documentation des variables de rôle à la section README de Postfix. Les variables de rôle sont documentées et disponibles pour les utilisateurs dans la documentation doc/usr/share/doc/rhel-system-roles/postfix/README.md fournie par rhel-system-roles.

Les tâches de rôle ne changent plus lors de l'exécution de la même sortie

Auparavant, plusieurs tâches du rôle étaient signalées comme étant CHANGED lorsque la même entrée était exécutée une nouvelle fois, même s'il n'y avait pas de changement. Par conséquent, le rôle n'agissait pas de manière idempotente. Pour résoudre ce problème, effectuez les actions suivantes :

L'option logging_purge_confs supprime correctement les fichiers de configuration inutiles

Lorsque l'option logging_purge_confs est définie sur true, elle devrait supprimer les fichiers de configuration de journalisation inutiles. Auparavant, cependant, les fichiers de configuration inutiles n'étaient pas supprimés du répertoire de configuration, même si logging_purge_confs était défini sur true. Ce problème est désormais résolu et l'option a été redéfinie comme suit : si logging_purge_confs est défini sur true, Rsyslog supprime les fichiers du répertoire rsyslog.d qui n'appartiennent à aucun paquetage rpm. Cela inclut les fichiers de configuration générés par les exécutions précédentes du rôle Logging. La valeur par défaut de logging_purge_confs est false.

Un playbook utilisant le rôle Metrics se termine avec succès sur plusieurs exécutions même si le mot de passe de Grafana admin est changé

Auparavant, les modifications apportées au mot de passe de l'utilisateur Grafana admin après l'exécution du rôle Metrics avec le booléen metrics_graph_service: yes entraînaient l'échec des exécutions ultérieures du rôle Metrics. Cela entraînait l'échec des playbooks utilisant le rôle Metrics, et les systèmes concernés n'étaient que partiellement configurés pour l'analyse des performances. Désormais, le rôle Metrics utilise l'API Grafana deployment lorsqu'elle est disponible et ne nécessite plus la connaissance du nom d'utilisateur ou du mot de passe pour effectuer les actions de configuration nécessaires. Par conséquent, un playbook utilisant le rôle Metrics se termine avec succès lors de plusieurs exécutions, même si l'administrateur modifie le mot de passe Grafana admin.

La configuration par le rôle Metrics suit désormais correctement les liens symboliques

Lorsque le paquet mssql pcp est installé, le fichier mssql.conf est situé dans /etc/pcp/mssql/ et est ciblé par le lien symbolique /var/lib/pcp/pmdas/mssql/mssql.conf. Auparavant, cependant, le rôle Metrics écrasait le lien symbolique au lieu de le suivre et de configurer mssql.conf. Par conséquent, l'exécution du rôle Metrics a transformé le lien symbolique en un fichier normal et la configuration n'a donc affecté que le fichier /var/lib/pcp/pmdas/mssql/mssql.conf. Le lien symbolique a donc échoué et le fichier de configuration principal /etc/pcp/mssql/mssql.conf n'a pas été affecté par la configuration. Le problème est maintenant résolu et l'option follow: yes pour suivre le lien symbolique a été ajoutée au rôle Metrics. Par conséquent, le rôle Metrics préserve les liens symboliques et configure correctement le fichier de configuration principal.

Le rôle timesync n'échoue plus à trouver le service demandé ptp4l

Auparavant, sur certaines versions de RHEL, le module Ansible service_facts signalait les faits de service de manière incorrecte. Par conséquent, le rôle timesync signalait une erreur lors de la tentative d'arrêt du service ptp4l. Avec cette correction, le module Ansible service_facts vérifie la valeur de retour des tâches pour arrêter les services timesync. Si la valeur renvoyée est failed, mais que le message d'erreur est Could not find the requested service NAME:, le module suppose que l'opération a réussi. Par conséquent, le rôle timesync s'exécute maintenant sans erreurs comme Could not find the requested service ptp4l.

Le site kernel_settings configobj est disponible sur les hôtes gérés

Auparavant, le rôle kernel_settings n'installait pas le paquetage python3-configobj sur les hôtes gérés. Par conséquent, le rôle renvoyait une erreur indiquant que le module Python configobj était introuvable. Avec cette correction, le rôle s'assure que le paquetage python3-configobj est présent sur les hôtes gérés et le rôle kernel_settings fonctionne comme prévu.

Le rôle d'enregistrement de session de terminal tlog-rec-session est désormais correctement superposé à SSSD

Auparavant, le rôle de système RHEL d'enregistrement de session de terminal s'appuyait sur le fournisseur de fichiers SSSD (System Security Services Daemon) et sur l'option authselect with-files-domain activée pour configurer les entrées passwd correctes dans le fichier nsswitch.conf. Dans RHEL 9.0, SSSD n'activait pas implicitement le fournisseur de fichiers par défaut et, par conséquent, la superposition du shell tlog-rec-session par SSSD ne fonctionnait pas. Avec cette correction, le rôle d'enregistrement de session de terminal met désormais à jour le fichier nsswitch.conf pour s'assurer que tlog-rec-session est correctement superposé par SSSD.

Le rôle de système SSHD peut gérer des systèmes en mode FIPS

Auparavant, le rôle de système SSHD ne pouvait pas créer le type de clé d'hôte not allowed lorsqu'il était appelé. Par conséquent, le rôle de système SSHD ne pouvait pas gérer les systèmes RHEL 8 et antérieurs en mode FIPS (Federal Information Processing Standard). Avec cette mise à jour, le rôle système SSHD détecte le mode FIPS et ajuste correctement la liste des clés d'hôte par défaut. Par conséquent, le rôle système peut gérer les systèmes RHEL en mode FIPS avec la configuration HostKey par défaut.

Le rôle de système SSHD utilise le bon fichier de modèle

Auparavant, le rôle de système SSHD utilisait un mauvais fichier modèle. Par conséquent, le fichier sshd_config généré ne contenait pas le commentaire ansible_managed. Avec cette mise à jour, le rôle système utilise le bon fichier modèle et sshd_config contient le bon commentaire ansible_managed.

Le rôle de système Kdump RHEL est capable de redémarrer ou d'indiquer qu'un redémarrage est nécessaire

Auparavant, le rôle de système Kdump RHEL ignorait les nœuds gérés sans mémoire réservée pour le noyau de crash. Par conséquent, le rôle se terminait avec l'état "Success", même s'il ne configurait pas le système correctement. Avec cette mise à jour de RHEL 9, le problème a été corrigé. Dans les cas où les nœuds gérés n'ont pas de mémoire réservée pour le noyau de crash, le rôle Kdump RHEL System échoue et suggère aux utilisateurs de définir la variable kdump_reboot_ok sur true pour configurer correctement le service kdump sur les nœuds gérés.

Le fournisseur nm dans le rôle de système de mise en réseau gère désormais correctement les ponts

Auparavant, si vous utilisiez le fournisseur initscripts, le rôle de système de mise en réseau créait un fichier ifcfg qui configurait NetworkManager pour marquer les interfaces de pont comme non gérées. De plus, NetworkManager ne détectait pas les actions de suivi initscript. Par exemple, les actions down et absent du fournisseur initscript ne changeront pas la compréhension du NetworkManager sur l'état non géré de cette interface si la connexion n'est pas rechargée après les actions down et absent. Avec ce correctif, le rôle de système de réseau utilise la fonction NM.Client.reload_connections_async() pour recharger NetworkManager sur les hôtes gérés avec NetworkManager 1.18. Par conséquent, NetworkManager gère l'interface de pont lors de la commutation du fournisseur de initscript à nm.

Correction d'une erreur de typographie pour la prise en charge de active-backup pour le mode de liaison correct

Auparavant, il y avait une faute de frappe,active_backup, dans la prise en charge du port InfiniBand tout en spécifiant le mode de liaison active-backup. En raison de cette faute de frappe, la connexion ne prenait pas en charge le mode de liaison correct pour le port de liaison InfiniBand. Cette mise à jour corrige la faute de frappe en remplaçant le mode de liaison par active-backup. La connexion prend désormais en charge avec succès le port de liaison InfiniBand.

Le rôle de système d'enregistrement n'appelle plus les tâches plusieurs fois

Auparavant, le rôle Logging appelait plusieurs fois des tâches qui n'auraient dû être appelées qu'une seule fois. En conséquence, les appels de tâches supplémentaires ralentissaient l'exécution du rôle. Avec cette correction, le rôle d'enregistrement a été modifié pour n'appeler les tâches qu'une seule fois, améliorant ainsi les performances du rôle d'enregistrement.

Les rôles système RHEL gèrent désormais les commentaires ansible_managed sur plusieurs lignes dans les fichiers générés

Auparavant, certains rôles système RHEL utilisaient # {{ ansible_managed }} pour générer certains fichiers. Par conséquent, si un client avait un paramètre personnalisé de plusieurs lignes pour ansible_managed, les fichiers étaient générés de manière incorrecte. Avec cette correction, tous les rôles système utilisent l'équivalent de {{ ansible_managed | comment }} lors de la génération de fichiers, de sorte que la chaîne ansible_managed est toujours correctement commentée, y compris les valeurs multilignes ansible_managed. Par conséquent, les fichiers générés ont la valeur multiligne ansible_managed correcte.

Le rôle de système de pare-feu recharge désormais immédiatement le pare-feu lorsque target est modifié

Auparavant, le rôle de système de pare-feu ne rechargeait pas le pare-feu lorsque le paramètre target était modifié. Avec cette correction, le rôle de pare-feu recharge le pare-feu lorsque le paramètre target est modifié et, par conséquent, la modification de target est immédiate et disponible pour les opérations suivantes.

L'option group dans le rôle de système de certificats ne permet plus de maintenir les certificats inaccessibles au groupe

Auparavant, lors de la définition du groupe pour un certificat, le site mode n'était pas configuré pour autoriser la lecture par le groupe. Par conséquent, les membres du groupe ne pouvaient pas lire les certificats émis par le rôle Certificat. Avec cette correction, la configuration du groupe garantit maintenant que le mode de fichier inclut l'autorisation de lecture de groupe. Par conséquent, les certificats émis par le rôle Certificat pour les groupes sont accessibles aux membres du groupe.

Le rôle Logging ne manque plus de citations pour la valeur d'intervalle du module immark

Auparavant, la valeur du champ interval pour le module immark n'était pas correctement citée, car le module immark n'était pas correctement configuré. Cette correction permet de s'assurer que la valeur du champ interval est correctement citée. Le module immark fonctionne désormais comme prévu.

Le fichier /etc/tuned/kernel_settings/tuned.conf comporte un en-tête ansible_managed approprié

Auparavant, le rôle de système RHEL kernel_settings avait une valeur codée en dur pour l'en-tête ansible_managed dans le fichier /etc/tuned/kernel_settings/tuned.conf. Par conséquent, les utilisateurs ne pouvaient pas fournir leur propre en-tête ansible_managed. Dans cette mise à jour, le problème a été résolu de sorte que kernel_settings mette à jour l'en-tête de /etc/tuned/kernel_settings/tuned.conf avec le paramètre ansible_managed de l'utilisateur. En conséquence, /etc/tuned/kernel_settings/tuned.conf a un en-tête ansible_managed correct.

Le plugin de filtrage VPN System Role vpn_ipaddr convertit désormais en FQCN (Fully Qualified Collection Name)

Auparavant, la conversion de l'ancien format de rôle au format de collection ne convertissait pas le plugin de filtre vpn_ipaddr en FQCN (Fully Qualified Collection Name) redhat.rhel_system_roles.vpn_ipaddr. Par conséquent, le rôle VPN ne pouvait pas trouver le plugin par son nom court et signalait une erreur. Avec cette correction, le script de conversion a été modifié pour que le filtre soit converti au format FQCN dans la collection. Désormais, le rôle VPN s'exécute sans émettre d'erreur.

L'emploi pour kdump.service n'échoue plus

Auparavant, le code du rôle Kdump pour la configuration de la taille du crash du noyau n'a pas été mis à jour pour RHEL9, qui nécessite l'utilisation de kdumpctl reset-crashkernel. En conséquence, le rôle kdump.service ne pouvait pas démarrer et émettait une erreur. Avec cette mise à jour, le rôle kdump.service utilise kdumpctl reset-crashkernel pour configurer la taille du crash du noyau. Maintenant, le rôle kdump.service démarre avec succès le service kdump et la taille de crash du noyau est configurée correctement.

Le débranchement à chaud d'un disque virtuel monté ne provoque plus le plantage du noyau invité sur IBM Z

Auparavant, lors du détachement d'un disque monté d'une machine virtuelle (VM) en cours d'exécution sur du matériel IBM Z, le noyau de la VM se bloquait dans les conditions suivantes :

Les conteneurs UBI 9-Beta peuvent fonctionner sur les hôtes RHEL 7 et 8

Auparavant, les images de conteneurs UBI 9-Beta avaient un profil seccomp incorrect dans le paquetage containers-common. En conséquence, les conteneurs n'étaient pas en mesure de traiter certains appels système, ce qui entraînait une défaillance. Avec cette mise à jour, le problème a été corrigé.

Le processus FDO est disponible en avant-première technologique

Le processus FDO pour le provisionnement automatique et l'onboarding des images RHEL for Edge est disponible en tant qu'aperçu technologique. Vous pouvez ainsi créer une image RHEL for Edge Simplified Installer, l'intégrer à une image RHEL for Edge et utiliser le processus FDO (FIDO device onboarding) pour approvisionner et intégrer automatiquement vos périphériques Edge et échanger des données avec d'autres périphériques et systèmes connectés sur les réseaux. Par conséquent, le protocole FIDO d'accueil des appareils effectue l'initialisation de l'appareil au stade de la fabrication, puis la liaison tardive pour l'utilisation effective de l'appareil.

ReaR disponible sur l'architecture IBM Z 64 bits en tant qu'aperçu technologique

La fonctionnalité de base Relax and Recover (ReaR) est désormais disponible sur l'architecture IBM Z 64 bits en tant qu'aperçu technologique. Vous pouvez créer une image de secours ReaR sur IBM Z uniquement dans l'environnement z/VM. La sauvegarde et la récupération des partitions logiques (LPAR) n'ont pas été testées.

GIMP disponible en avant-première technologique dans RHEL 9

GNU Image Manipulation Program (GIMP) 2.99.8 est maintenant disponible dans RHEL 9 en tant qu'aperçu technologique. La version 2.99.8 du paquet gimp est une pré-version avec un ensemble d'améliorations, mais un ensemble limité de fonctionnalités et aucune garantie de stabilité. Dès que la version officielle de GIMP 3 sera publiée, elle sera introduite dans RHEL 9 en tant que mise à jour de cette version préliminaire.

WireGuard VPN est disponible en avant-première technologique

WireGuard, que Red Hat fournit en tant qu'aperçu technologique non pris en charge, est une solution VPN de haute performance qui fonctionne dans le noyau Linux. Elle utilise une cryptographie moderne et est plus facile à configurer que d'autres solutions VPN. En outre, la petite base de code de WireGuard réduit la surface d'attaque et, par conséquent, améliore la sécurité.

KTLS disponible en avant-première technologique

RHEL fournit Kernel Transport Layer Security (KTLS) en tant qu'aperçu technologique. KTLS traite les enregistrements TLS à l'aide des algorithmes de chiffrement ou de déchiffrement symétriques du noyau pour le chiffrement AES-GCM. KTLS inclut également l'interface permettant de décharger le chiffrement des enregistrements TLS sur les contrôleurs d'interface réseau (NIC) qui fournissent cette fonctionnalité.

Le service systemd-resolved est disponible en tant qu'aperçu technologique

Le service systemd-resolved fournit la résolution de noms aux applications locales. Le service met en œuvre un résolveur de stub DNS avec mise en cache et validation, un résolveur et un répondeur de DNS multidiffusion (Link-Local Multicast Name Resolution - LLMNR) et multidiffusion.

Le pilote Intel data streaming accelerator pour le noyau est disponible en tant qu'aperçu technologique

Le pilote de l'accélérateur de flux de données Intel (IDXD) pour le noyau est actuellement disponible en tant qu'aperçu technologique. Il s'agit d'un accélérateur intégré au processeur Intel qui comprend la file d'attente partagée avec la soumission de l'espace d'adressage du processus (pasid) et la mémoire virtuelle partagée (SVM).

SGX disponible en avant-première technologique

Software Guard Extensions (SGX) est une technologie Intel® destinée à protéger le code et les données des logiciels contre la divulgation et la modification. Le noyau RHEL fournit partiellement les fonctionnalités SGX v1 et v1.5. La version 1 permet aux plateformes utilisant le mécanisme Flexible Launch Control d'utiliser la technologie SGX.

Le pilote Soft-iWARP est disponible en tant qu'aperçu technologique

Soft-iWARP (siw) est un logiciel, Internet Wide-area RDMA Protocol (iWARP), pilote de noyau pour Linux. Soft-iWARP met en œuvre la suite de protocoles iWARP sur la pile réseau TCP/IP. Cette suite de protocoles est entièrement mise en œuvre dans le logiciel et ne nécessite pas de matériel RDMA (Remote Direct Memory Access) spécifique. Soft-iWARP permet à un système doté d'un adaptateur Ethernet standard de se connecter à un adaptateur iWARP ou à un autre système sur lequel Soft-iWARP est déjà installé.

DAX est maintenant disponible pour ext4 et XFS en tant qu'aperçu technologique

Dans RHEL 9, le système de fichiers DAX est disponible en tant qu'aperçu technologique. DAX permet à une application de mapper directement la mémoire persistante dans son espace d'adressage. Pour utiliser DAX, un système doit disposer d'une certaine forme de mémoire persistante, généralement sous la forme d'un ou plusieurs modules de mémoire double en ligne non volatile (NVDIMM), et un système de fichiers compatible DAX doit être créé sur le(s) module(s) NVDIMM. Le système de fichiers doit également être monté avec l'option de montage dax. Ensuite, mmap d'un fichier sur le système de fichiers monté sur dax entraîne un mappage direct du stockage dans l'espace d'adressage de l'application.

Stratis est disponible en avant-première technologique

Stratis est un gestionnaire de stockage local. Il fournit des systèmes de fichiers gérés au-dessus des pools de stockage avec des fonctionnalités supplémentaires pour l'utilisateur :

Fonctionnalités du service de découverte NVMe-oF disponibles en tant qu'aperçu technologique

Les fonctions du service de découverte NVMe-oF, définies dans les propositions techniques (TP) 8013 et 8014 de NVMexpress.org, sont disponibles en tant qu'aperçu technologique. Pour obtenir un aperçu de ces fonctionnalités, utilisez le paquetage nvme-cli 2.0 et attachez l'hôte à un périphérique cible NVMe-oF qui implémente le TP-8013 ou le TP-8014. Pour plus d'informations sur les TP-8013 et TP-8014, voir les TPs NVM Express 2.0 Ratifiés sur le site web https://nvmexpress.org/developers/nvme-specification/.

jmc-core et owasp-java-encoder disponible en avant-première technologique

RHEL 9 est distribué avec les paquets jmc-core et owasp-java-encoder en tant que fonctionnalités d'aperçu technologique.

DNSSEC disponible en tant qu'aperçu technologique dans IdM

Les serveurs de gestion de l'identité (IdM) avec DNS intégré mettent désormais en œuvre les extensions de sécurité DNS (DNSSEC), un ensemble d'extensions du DNS qui renforcent la sécurité du protocole DNS. Les zones DNS hébergées sur les serveurs IdM peuvent être automatiquement signées à l'aide de DNSSEC. Les clés cryptographiques sont générées automatiquement et font l'objet d'une rotation.

L'API JSON-RPC de gestion des identités est disponible en avant-première technologique

Une API est disponible pour la gestion des identités (IdM). Pour visualiser l'API, IdM fournit également un navigateur API en tant qu'aperçu technologique.

ACME disponible en avant-première technologique

Le service Automated Certificate Management Environment (ACME) est désormais disponible dans Identity Management (IdM) en tant qu'aperçu technologique. ACME est un protocole de validation automatisée des identifiants et d'émission de certificats. Son objectif est d'améliorer la sécurité en réduisant la durée de vie des certificats et en évitant les processus manuels de gestion du cycle de vie des certificats.

GNOME pour l'architecture ARM 64 bits disponible en tant qu'aperçu technologique

L'environnement de bureau GNOME est disponible pour l'architecture ARM 64 bits en tant qu'aperçu technologique.

GNOME pour l'architecture IBM Z disponible en avant-première technologique

L'environnement de bureau GNOME est disponible pour l'architecture IBM Z en tant qu'aperçu technologique.

Stratis disponible en tant qu'aperçu technologique dans la console web RHEL

Avec cette mise à jour, la console web de Red Hat Enterprise Linux permet de gérer le stockage Stratis en tant qu'aperçu technologique.

AMD SEV et SEV-ES pour les machines virtuelles KVM

En tant qu'aperçu technologique, RHEL 9 fournit la fonction Secure Encrypted Virtualization (SEV) pour les machines hôtes AMD EPYC qui utilisent l'hyperviseur KVM. Si elle est activée sur une machine virtuelle (VM), SEV crypte la mémoire de la VM pour la protéger contre l'accès de l'hôte. La sécurité de la VM s'en trouve renforcée.

La virtualisation est désormais disponible sur ARM 64

En tant qu'aperçu technologique, il est désormais possible de créer des machines virtuelles KVM sur des systèmes utilisant des processeurs ARM 64.

virtio-mem est désormais disponible sur AMD64 et Intel 64

En tant qu'aperçu technologique, RHEL 9 introduit la fonctionnalité virtio-mem sur les systèmes AMD64 et Intel 64. L'utilisation de virtio-mem permet d'ajouter ou de supprimer dynamiquement de la mémoire hôte dans les machines virtuelles (VM).

Commandes Kickstart obsolètes

Les commandes Kickstart suivantes sont obsolètes :

SHA-1 est déprécié à des fins cryptographiques

L'utilisation du condensé de message SHA-1 à des fins cryptographiques a été supprimée dans RHEL 9. Le condensé produit par SHA-1 n'est pas considéré comme sûr en raison des nombreuses attaques réussies documentées basées sur la recherche de collisions de hachage. Les composants cryptographiques de base de RHEL ne créent plus de signatures à l'aide de SHA-1 par défaut. Les applications de RHEL 9 ont été mises à jour pour éviter d'utiliser SHA-1 dans les cas d'utilisation liés à la sécurité.

SCP est obsolète dans RHEL 9

Le protocole de copie sécurisée (SCP) est obsolète car il présente des failles de sécurité connues. L'API SCP reste disponible pour le cycle de vie de RHEL 9, mais son utilisation réduit la sécurité du système.

Digest-MD5 dans SASL est obsolète

Le mécanisme d'authentification Digest-MD5 du cadre Simple Authentication Security Layer (SASL) est obsolète et pourrait être supprimé des paquets cyrus-sasl dans une prochaine version majeure.

OpenSSL supprime MD2, MD4, MDC2, Whirlpool, RIPEMD160, Blowfish, CAST, DES, IDEA, RC2, RC4, RC5, SEED et PBKDF1

Le projet OpenSSL a déprécié un ensemble d'algorithmes cryptographiques parce qu'ils ne sont pas sûrs, qu'ils sont peu utilisés, ou les deux. Red Hat déconseille également l'utilisation de ces algorithmes, et RHEL 9 les fournit pour migrer les données chiffrées afin d'utiliser de nouveaux algorithmes. Les utilisateurs ne doivent pas dépendre de ces algorithmes pour la sécurité de leurs systèmes.

/etc/system-fips est désormais obsolète

La prise en charge de l'indication du mode FIPS par le fichier /etc/system-fips a été supprimée et le fichier ne sera pas inclus dans les versions futures de RHEL. Pour installer RHEL en mode FIPS, ajoutez le paramètre fips=1 à la ligne de commande du noyau lors de l'installation du système. Vous pouvez vérifier si RHEL fonctionne en mode FIPS à l'aide de la commande fips-mode-setup --check.

libcrypt.so.1 est désormais obsolète

La bibliothèque libcrypt.so.1 est désormais obsolète et pourrait être supprimée dans une prochaine version de RHEL.

fapolicyd.rules est obsolète

Le répertoire /etc/fapolicyd/rules.d/, qui contient les fichiers contenant les règles d'exécution d'autorisation et de refus, remplace le fichier /etc/fapolicyd/fapolicyd.rules. Le script fagenrules fusionne désormais tous les fichiers de règles de ce répertoire dans le fichier /etc/fapolicyd/compiled.rules. Les règles contenues dans /etc/fapolicyd/fapolicyd.trust sont toujours traitées par le cadre fapolicyd, mais uniquement dans un souci de compatibilité ascendante.

ipset et iptables-nft sont obsolètes

Les paquets ipset et iptables-nft sont obsolètes dans RHEL. Le paquet iptables-nft contient différents outils tels que iptables, ip6tables, ebtables et arptables. Ces outils ne recevront plus de nouvelles fonctionnalités et leur utilisation pour les nouveaux déploiements n'est pas recommandée. En remplacement, préférez l'outil en ligne de commande nft fourni par le paquet nftables. Les installations existantes devraient migrer vers nft si possible.

Les équipes réseau sont obsolètes dans RHEL 9

Le service teamd et la bibliothèque libteam sont obsolètes dans Red Hat Enterprise Linux 9 et seront supprimés dans la prochaine version majeure. En remplacement, configurez un lien au lieu d'une équipe réseau.

NetworkManager stocke les nouvelles configurations de réseau sur /etc/NetworkManager/system-connections/ dans un fichier clé

Auparavant, NetworkManager stockait les nouvelles configurations réseau à l'adresse /etc/sysconfig/network-scripts/ au format ifcfg. À partir de RHEL 9.0, RHEL stocke les nouvelles configurations réseau à l'adresse /etc/NetworkManager/system-connections/ dans un format de fichier clé. Les connexions pour lesquelles les configurations sont stockées sur /etc/sysconfig/network-scripts/ dans l'ancien format continuent de fonctionner sans interruption. Les modifications apportées aux profils existants continuent de mettre à jour les anciens fichiers.

Le back-end iptables dans firewalld est obsolète

Dans RHEL 9, le cadre iptables est obsolète. Par conséquent, le backend iptables et le direct interface dans firewalld sont également obsolètes. Au lieu de direct interface, vous pouvez utiliser les fonctionnalités natives de firewalld pour configurer les règles requises.

L'encapsulation ATM est obsolète dans RHEL 9

L'encapsulation du mode de transfert asynchrone (ATM) permet une connectivité de couche 2 (protocole point à point, Ethernet) ou de couche 3 (IP) pour la couche d'adaptation ATM 5 (AAL-5). Red Hat ne fournit plus de support pour les pilotes ATM NIC depuis RHEL 7. La prise en charge de l'implémentation ATM est abandonnée dans RHEL 9. Ces protocoles ne sont actuellement utilisés que dans les chipsets, qui prennent en charge la technologie ADSL et sont progressivement abandonnés par les fabricants. Par conséquent, l'encapsulation ATM est dépréciée dans Red Hat Enterprise Linux 9.

v4l/dvb les appareils de télévision et de capture vidéo ne sont plus pris en charge

Avec RHEL 9, Red Hat ne prend plus en charge les périphériques Video4Linux (v4l) et Linux DVB (DVB) qui consistent en diverses cartes de tuner de télévision et diverses cartes de capture vidéo et Red Hat ne fournit plus leurs pilotes associés.

lvm2-activation-generator et ses services générés sont supprimés dans RHEL 9.0

Le programme lvm2-activation-generator et ses services générés lvm2-activation, lvm2-activation-early, et lvm2-activation-net sont supprimés dans RHEL 9.0. Le paramètre lvm.conf event_activation, utilisé pour activer les services, n'est plus fonctionnel. La seule méthode d'activation automatique des groupes de volumes est l'activation basée sur les événements.

libdb a été supprimé

RHEL 8 et RHEL 9 fournissent actuellement la version 5.3.28 de Berkeley DB (libdb), qui est distribuée sous la licence LGPLv2. La version 6 de Berkeley DB en amont est disponible sous la licence AGPLv3, qui est plus restrictive.

SHA-1 dans OpenDNSSec est maintenant obsolète

OpenDNSSec prend en charge l'exportation de signatures numériques et d'enregistrements d'authentification à l'aide de l'algorithme SHA-1. L'utilisation de l'algorithme SHA-1 n'est plus prise en charge. Avec la version RHEL 9, SHA-1 dans OpenDNSSec est déprécié et pourrait être supprimé dans une future version mineure. En outre, la prise en charge d'OpenDNSSec est limitée à son intégration avec Red Hat Identity Management. OpenDNSSec n'est pas pris en charge de manière autonome.

Le domaine du fournisseur de fichiers implicites SSSD est désactivé par défaut

Le domaine fournisseur implicite SSSD files, qui récupère les informations sur les utilisateurs à partir de fichiers locaux tels que /etc/shadow et les informations sur les groupes à partir de /etc/groups, est désormais désactivé par défaut.

Le serveur X.org est désormais obsolète

Le serveur d'affichage X.org est obsolète et sera supprimé dans une prochaine version majeure de RHEL. La session de bureau par défaut est désormais la session Wayland dans la plupart des cas.

Motif a été supprimé

La boîte à outils Motif a été supprimée dans RHEL, car le développement de la communauté Motif en amont est inactif.

Le rôle de système networking affiche un avertissement de dépréciation lors de la configuration des équipes sur les nœuds RHEL 9

Par conséquent, l'utilisation du rôle de système networking RHEL sur un contrôleur RHEL 8 pour configurer une équipe réseau sur des nœuds RHEL 9 affiche un avertissement concernant son obsolescence.

La vérification de l'image SecureBoot à l'aide de signatures basées sur SHA1 est obsolète

La vérification de l'image SecureBoot à l'aide de signatures basées sur l'algorithme SHA1 sur les exécutables UEFI (PE/COFF) est devenue obsolète. Red Hat recommande plutôt d'utiliser des signatures basées sur l'algorithme SHA2 ou plus récent.

Prise en charge limitée des instantanés de machines virtuelles

La création d'instantanés de machines virtuelles (VM) n'est actuellement prise en charge que pour les VM n'utilisant pas le micrologiciel UEFI. En outre, pendant l'opération de snapshot, le moniteur QEMU peut se bloquer, ce qui a un impact négatif sur les performances de l'hyperviseur pour certaines charges de travail.

virt-manager a été supprimé

L'application Virtual Machine Manager, également connue sous le nom de virt-manager, a été supprimée. La console web RHEL, également connue sous le nom de Cockpit, est destinée à la remplacer dans une version ultérieure. Il est donc recommandé d'utiliser la console web pour gérer la virtualisation dans une interface graphique. Notez toutefois que certaines fonctionnalités disponibles sur virt-manager peuvent ne pas être encore disponibles dans la console web RHEL.

libvirtd est devenu obsolète

Le démon monolithique libvirt, libvirtd, a été abandonné dans RHEL 9 et sera supprimé dans une prochaine version majeure de RHEL. Notez que vous pouvez toujours utiliser libvirtd pour gérer la virtualisation sur votre hyperviseur, mais Red Hat recommande de passer aux démons modulaires libvirt récemment introduits. Pour obtenir des instructions et des détails, consultez le document RHEL 9 Configuring and Managing Virtualization (Configuration et gestion de la virtualisation ).

Le pilote de disquette virtuelle est devenu obsolète

Le pilote isa-fdc, qui contrôle les périphériques de disquette virtuels, est désormais obsolète et ne sera plus pris en charge dans une prochaine version de RHEL. Par conséquent, pour assurer la compatibilité avec les machines virtuelles (VM) migrées, Red Hat déconseille l'utilisation de périphériques à disquette dans les VM hébergées sur RHEL 9.

le format d'image qcow2-v2 est obsolète

Avec RHEL 9, le format qcow2-v2 pour les images de disques virtuels est devenu obsolète et ne sera plus pris en charge dans une prochaine version majeure de RHEL. En outre, RHEL 9 Image Builder ne peut pas créer d'images de disque au format qcow2-v2.

L'exécution de conteneurs RHEL 9 sur un hôte RHEL 7 n'est pas prise en charge

L'exécution de conteneurs RHEL 9 sur un hôte RHEL 7 n'est pas prise en charge. Cela peut fonctionner, mais ce n'est pas garanti.

L'algorithme de hachage SHA1 utilisé dans Podman est obsolète

L'algorithme SHA1 utilisé pour générer le nom de fichier de l'espace de noms du réseau sans racine n'est plus pris en charge dans Podman. Par conséquent, les conteneurs sans racine démarrés avant la mise à jour vers Podman 4.1.1 à partir de l'avis RHBA-2022:5951 doivent être redémarrés s'ils sont connectés à un réseau (et pas seulement en utilisant slirp4netns) pour s'assurer qu'ils peuvent se connecter aux conteneurs démarrés après la mise à jour.

rhel9/pause a été supprimé

L'image du conteneur rhel9/pause a été supprimée.

Les commandes reboot --kexec et inst.kexec ne fournissent pas un état prévisible du système

L'installation de RHEL à l'aide de la commande reboot --kexec Kickstart ou des paramètres de démarrage du noyau inst.kexec n'offre pas le même état prévisible du système qu'un redémarrage complet. Par conséquent, le passage au système installé sans redémarrage peut produire des résultats imprévisibles.

Local Media la source d'installation n'est pas détectée lors du démarrage de l'installation à partir d'une clé USB créée à l'aide d'un outil tiers

Lors du démarrage de l'installation RHEL à partir d'une clé USB créée à l'aide d'un outil tiers, le programme d'installation ne détecte pas la source d'installation Local Media (seule Red Hat CDN est détectée).

Les commandes auth et authconfig Kickstart nécessitent le dépôt AppStream

Le paquetage authselect-compat est requis par les commandes Kickstart auth et authconfig lors de l'installation. Sans ce paquet, l'installation échoue si auth ou authconfig est utilisé. Cependant, par conception, le paquet authselect-compat n'est disponible que dans le dépôt AppStream.

Politiques SELinux inattendues sur les systèmes où Anaconda s'exécute en tant qu'application

Lorsqu'Anaconda est exécuté en tant qu'application sur un système déjà installé (par exemple pour effectuer une autre installation sur un fichier image à l'aide de l'option –image anaconda), il n'est pas interdit au système de modifier les types et attributs SELinux au cours de l'installation. Par conséquent, certains éléments de la politique SELinux peuvent changer sur le système où Anaconda est exécuté. Pour contourner ce problème, n'exécutez pas Anaconda sur le système de production et exécutez-le dans une machine virtuelle temporaire. Ainsi, la politique SELinux sur un système de production n'est pas modifiée. L'exécution d'Anaconda dans le cadre du processus d'installation du système, tel que l'installation à partir de boot.iso ou dvd.iso, n'est pas concernée par ce problème.

Le lecteur de CD-ROM USB n'est pas disponible comme source d'installation dans Anaconda

L'installation échoue lorsque le lecteur de CD-ROM USB en est la source et que la commande Kickstart ignoredisk --only-use= est spécifiée. Dans ce cas, Anaconda ne peut pas trouver et utiliser ce disque source.

L'installation minimale de RHEL ne comprend plus le paquetage s390utils-base

Dans RHEL 8.4 et les versions ultérieures, le paquet s390utils-base est divisé en un paquet s390utils-core et un paquet auxiliaire s390utils-base. Par conséquent, le fait de définir l'installation RHEL sur minimal-environment n'installe que le paquet s390utils-core nécessaire et non le paquet auxiliaire s390utils-base. Pour contourner ce problème, installez manuellement le paquet s390utils-base après avoir terminé l'installation RHEL ou installez explicitement s390utils-base à l'aide d'un fichier kickstart.

Échec des installations de disques durs partitionnés avec le système de fichiers iso9660

Vous ne pouvez pas installer RHEL sur des systèmes dont le disque dur est partitionné avec le système de fichiers iso9660. Cela est dû à la mise à jour du code d'installation qui est configuré pour ignorer tout disque dur contenant une partition du système de fichiers iso9660. Cela se produit même lorsque RHEL est installé sans utiliser de DVD.

Anaconda ne parvient pas à vérifier l'existence d'un compte d'utilisateur administrateur

Lors de l'installation de RHEL à l'aide d'une interface graphique, Anaconda ne vérifie pas si le compte administrateur a été créé. En conséquence, les utilisateurs peuvent installer un système sans aucun compte d'utilisateur administrateur.

Anaconda ne parvient pas à se connecter au serveur iSCSI à l'aide de la méthode no authentication après une tentative d'authentification CHAP infructueuse

Lorsque vous ajoutez des disques iSCSI à l'aide de l'authentification CHAP et que la tentative de connexion échoue en raison d'informations d'identification incorrectes, une nouvelle tentative de connexion aux disques à l'aide de la méthode no authentication échoue. Pour contourner ce problème, fermez la session en cours et connectez-vous à l'aide de la méthode no authentication.

De nouvelles fonctionnalités XFS empêchent le démarrage des systèmes PowerNV IBM POWER dont le microprogramme est antérieur à la version 5.10

Les systèmes PowerNV IBM POWER utilisent un noyau Linux pour le micrologiciel et Petitboot en remplacement de GRUB. Ainsi, le noyau du microprogramme monte /boot et Petitboot lit la configuration de GRUB et démarre RHEL.

Impossible d'installer RHEL lorsque la taille du PReP n'est pas de 4 ou 8 MiB

Le programme d'installation RHEL ne peut pas installer le chargeur de démarrage si la partition PowerPC Reference Platform (PReP) est d'une taille différente de 4 MiB ou 8 MiB sur un disque qui utilise des secteurs de 4 kiB. Par conséquent, vous ne pouvez pas installer RHEL sur le disque.

De nouvelles fonctionnalités XFS empêchent le démarrage des systèmes PowerNV IBM POWER dont le noyau du micrologiciel est antérieur à la version 5.10

Les systèmes PowerNV IBM POWER utilisent un noyau Linux pour le micrologiciel et Petitboot en remplacement de GRUB. Ainsi, le noyau du microprogramme monte /boot et Petitboot lit la configuration de GRUB et démarre RHEL.

virt-who ne peut pas se connecter aux serveurs ESX en mode FIPS

Lors de l'utilisation de l'utilitaire virt-who sur un système RHEL 9 en mode FIPS, virt-who ne peut pas se connecter aux serveurs ESX. Par conséquent, virt-who ne signale aucun serveur ESX, même s'il est configuré pour cela, et affiche le message d'erreur suivant :

Le processus d'installation ne répond parfois plus

Lorsque vous installez RHEL, le processus d'installation ne répond parfois plus. Le fichier /tmp/packaging.log affiche le message suivant à la fin :

Le renommage des interfaces réseau à l'aide des fichiers ifcfg échoue

Sur RHEL 9, le paquetage initscripts n'est pas installé par défaut. Par conséquent, le renommage des interfaces réseau à l'aide des fichiers ifcfg échoue. Pour résoudre ce problème, Red Hat vous recommande d'utiliser les règles udev ou les fichiers de liens pour renommer les interfaces. Pour plus de détails, reportez-vous à Nommage cohérent des périphériques d'interface réseau et à la page de manuel systemd.link(5).

Le paquet chkconfig n'est pas installé par défaut dans RHEL 9

Le paquet chkconfig, qui met à jour et interroge les informations de niveau d'exécution des services système, n'est pas installé par défaut dans RHEL 9.

Les deux sites bind et unbound désactivent la validation des signatures basées sur SHA-1

Les composants bind et unbound désactivent la prise en charge de la validation de toutes les signatures RSA/SHA1 (algorithme numéro 5) et RSASHA1-NSEC3-SHA1 (algorithme numéro 7), et l'utilisation de SHA-1 pour les signatures est restreinte dans la politique cryptographique DEFAULT applicable à l'ensemble du système.

named ne démarre pas si le même fichier de zone inscriptible est utilisé dans plusieurs zones

BIND n'autorise pas l'utilisation du même fichier de zone inscriptible dans plusieurs zones. Par conséquent, si une configuration comprend plusieurs zones qui partagent un chemin d'accès à un fichier qui peut être modifié par le service named, named ne démarre pas. Pour contourner ce problème, utilisez la clause in-view pour partager une zone entre plusieurs vues et veillez à utiliser des chemins différents pour les différentes zones. Par exemple, incluez les noms des vues dans le chemin d'accès.

OpenSSL ne détecte pas si un jeton PKCS #11 prend en charge la création de signatures RSA ou RSA-PSS brutes

Le protocole TLS 1.3 nécessite la prise en charge des signatures RSA-PSS. Si un jeton PKCS #11 ne prend pas en charge les signatures RSA ou RSA-PSS brutes, les applications serveur qui utilisent la bibliothèque OpenSSL ne fonctionnent pas avec une clé RSA si la clé est détenue par le jeton PKCS #11. Par conséquent, la communication TLS échoue dans le scénario décrit.

OpenSSL traite incorrectement les jetons PKCS #11 qui ne prennent pas en charge les signatures RSA ou RSA-PSS brutes

La bibliothèque OpenSSL ne détecte pas les capacités liées aux clés des jetons PKCS #11. Par conséquent, l'établissement d'une connexion TLS échoue lorsqu'une signature est créée avec un jeton qui ne prend pas en charge les signatures RSA ou RSA-PSS brutes.

La cryptographie non approuvée par la FIPS fonctionne dans OpenSSL en mode FIPS

La cryptographie qui n'est pas approuvée par le FIPS fonctionne dans la boîte à outils OpenSSL, quels que soient les paramètres du système. Par conséquent, vous pouvez utiliser des algorithmes cryptographiques qui devraient être désactivés lorsque le système fonctionne en mode FIPS, par exemple :

OpenSSL ne peut pas utiliser de moteurs en mode FIPS

L'API Engine est obsolète dans OpenSSL 3.0 et est incompatible avec l'implémentation FIPS (Federal Information Processing Standards) d'OpenSSL et d'autres implémentations compatibles FIPS. Par conséquent, OpenSSL ne peut pas exécuter les moteurs en mode FIPS. Il n'existe pas de solution à ce problème.

Les suites de chiffrement PSK ne fonctionnent pas avec la politique cryptographique FUTURE

Les suites de chiffrement à clé pré-partagée (PSK) ne sont pas reconnues comme des méthodes d'échange de clés à secret parfait (PFS). Par conséquent, les ciphersuites ECDHE-PSK et DHE-PSK ne fonctionnent pas avec OpenSSL configuré à SECLEVEL=3, par exemple avec la politique cryptographique FUTURE. Comme solution de contournement, vous pouvez définir une politique cryptographique moins restrictive ou un niveau de sécurité inférieur (SECLEVEL) pour les applications qui utilisent des suites de chiffrement PSK.

GnuPG permet incorrectement d'utiliser des signatures SHA-1 même si cela est interdit par la norme crypto-policies

Le logiciel cryptographique GNU Privacy Guard (GnuPG) peut créer et vérifier des signatures qui utilisent l'algorithme SHA-1 indépendamment des paramètres définis par les politiques cryptographiques du système. Par conséquent, vous pouvez utiliser SHA-1 à des fins cryptographiques dans la politique cryptographique DEFAULT, ce qui n'est pas cohérent avec la dépréciation de cet algorithme peu sûr pour les signatures à l'échelle du système.

Certaines opérations d'OpenSSH n'utilisent pas les interfaces approuvées par le FIPS

La bibliothèque cryptographique OpenSSL, utilisée par OpenSSH, fournit deux interfaces : l'ancienne et la nouvelle. En raison des modifications apportées aux composants internes d'OpenSSL, seules les interfaces modernes utilisent des implémentations d'algorithmes cryptographiques certifiées FIPS. Comme OpenSSH utilise des interfaces anciennes pour certaines opérations, il n'est pas conforme aux exigences de la FIPS.

gpg-agent ne fonctionne pas comme agent SSH en mode FIPS

L'outil gpg-agent crée des empreintes MD5 lors de l'ajout de clés au programme ssh-agent, même si le mode FIPS désactive le condensé MD5. Par conséquent, l'utilitaire ssh-add ne parvient pas à ajouter les clés à l'agent d'authentification.

SELinux staff_u Les utilisateurs peuvent passer à tort à l'option unconfined_r

Lorsque le booléen secure_mode est activé, les utilisateurs de staff_u peuvent passer par erreur au rôle unconfined_r. En conséquence, les utilisateurs de staff_u peuvent effectuer des opérations privilégiées affectant la sécurité du système.

La politique SELinux par défaut autorise les exécutables non confinés à rendre leur pile exécutable

L'état par défaut du booléen selinuxuser_execstack dans la politique SELinux est activé, ce qui signifie que les exécutables non confinés peuvent rendre leur pile exécutable. Les exécutables ne devraient pas utiliser cette option, qui pourrait indiquer des exécutables mal codés ou une attaque possible. Cependant, en raison de la compatibilité avec d'autres outils, paquetages et produits tiers, Red Hat ne peut pas modifier la valeur du booléen dans la stratégie par défaut. Si votre scénario ne dépend pas de ces aspects de compatibilité, vous pouvez désactiver l'option booléenne dans votre politique locale en entrant la commande setsebool -P selinuxuser_execstack off.

Les règles de délai SSH dans les profils STIG configurent des options incorrectes

Une mise à jour d'OpenSSH a affecté les règles des profils suivants du Guide de mise en œuvre technique de la sécurité de l'Agence des systèmes d'information de la défense (DISA STIG) :

fagenrules --load ne fonctionne pas correctement

Le service fapolicyd ne gère pas correctement le signal de raccrochage (SIGHUP). Par conséquent, fapolicyd se termine après avoir reçu le signal SIGHUP. Par conséquent, la commande fagenrules --load ne fonctionne pas correctement et les mises à jour des règles nécessitent un redémarrage manuel de fapolicyd. Pour contourner ce problème, redémarrez le service fapolicyd après toute modification des règles, ce qui permettra à fagenrules --load de fonctionner correctement.

Les remédiations Ansible nécessitent des collectes supplémentaires

Avec le remplacement d'Ansible Engine par le paquetage ansible-core, la liste des modules Ansible fournis avec l'abonnement RHEL est réduite. Par conséquent, l'exécution de remédiations qui utilisent le contenu Ansible inclus dans le paquetage scap-security-guide nécessite des collections du paquetage rhc-worker-playbook.

Le service nm-cloud-setup supprime les adresses IP secondaires configurées manuellement sur les interfaces

Sur la base des informations reçues de l'environnement cloud, le service nm-cloud-setup configure les interfaces réseau. Désactivez nm-cloud-setup pour configurer manuellement les interfaces. Cependant, dans certains cas, d'autres services sur l'hôte peuvent également configurer les interfaces. Par exemple, ces services peuvent ajouter des adresses IP secondaires. Pour éviter cela, nm-cloud-setup supprime les adresses IP secondaires :

Une option rd.znet vide dans la ligne de commande du noyau entraîne l'échec de la configuration du réseau

Une option rd.znet sans arguments, tels que les types de réseau ou les sous-canaux, dans le noyau ne configure pas la mise en réseau. Pour contourner ce problème, supprimez complètement l'option rd.znet de la ligne de commande ou spécifiez les types de réseau, les sous-canaux et les autres options pertinentes. Pour plus d'informations sur ces options, consultez la page de manuel dracut.cmdline(7).

L'absence de mise à jour de la clé de session entraîne l'interruption de la connexion

Le protocole Kernel Transport Layer Security (kTLS) ne prend pas en charge la mise à jour de la clé de session, qui est utilisée par le chiffrement symétrique. Par conséquent, l'utilisateur ne peut pas mettre à jour la clé, ce qui entraîne une interruption de la connexion. Pour contourner ce problème, il faut désactiver le protocole kTLS. Par conséquent, avec la solution de contournement, il est possible de mettre à jour la clé de session avec succès.

Le paquet initscripts n'est pas installé par défaut

Par défaut, le paquetage initscripts n'est pas installé. Par conséquent, les utilitaires ifup et ifdown ne sont pas disponibles. Vous pouvez utiliser les commandes nmcli connection up et nmcli connection down pour activer et désactiver les connexions. Si l'alternative proposée ne fonctionne pas, signalez le problème et installez le paquetage NetworkManager-initscripts-updown, qui fournit une solution NetworkManager pour les utilitaires ifup et ifdown.

L'adresse IP principale d'une instance change après le lancement du service nm-cloud-setup dans Alibaba Cloud

Après le lancement d'une instance dans le nuage Alibaba, le service nm-cloud-setup attribue l'adresse IP principale à une instance. Toutefois, si vous attribuez plusieurs adresses IP secondaires à une instance et que vous lancez le service nm-cloud-setup, l'ancienne adresse IP primaire est remplacée par l'une des adresses IP secondaires déjà attribuées. La liste des métadonnées renvoyée le confirme. Pour contourner le problème, configurez les adresses IP secondaires manuellement afin d'éviter que l'adresse IP primaire ne change. Ainsi, une instance conserve les deux adresses IP et l'adresse IP principale ne change pas.

kdump ne démarre pas sur le noyau RHEL 9

Le paramètre crashkernel=auto n'est pas configuré par défaut dans le noyau RHEL 9. Par conséquent, le service kdump ne démarre pas par défaut.

Le mécanisme kdump ne parvient pas à capturer vmcore sur les cibles chiffrées par LUKS

Lors de l'exécution de kdump sur des systèmes dotés de partitions chiffrées Linux Unified Key Setup (LUKS), les systèmes requièrent une certaine quantité de mémoire disponible. Lorsque la mémoire disponible est inférieure à la quantité de mémoire requise, le service systemd-cryptsetup ne parvient pas à monter la partition. Par conséquent, le second noyau ne parvient pas à capturer le fichier de vidage d'urgence (vmcore) sur les cibles chiffrées LUKS.

L'allocation de la mémoire du noyau de crash échoue au démarrage

Sur certains systèmes Ampere Altra, l'allocation de la mémoire du noyau de crash pour l'utilisation de kdump échoue au démarrage lorsque la mémoire disponible est inférieure à 1 Go. Par conséquent, la commande kdumpctl ne parvient pas à démarrer le service kdump car la mémoire requise est supérieure à la taille de la mémoire disponible.

kTLS ne prend pas en charge le délestage de TLS 1.3 vers les cartes réseau

Kernel Transport Layer Security (kTLS) ne prend pas en charge le délestage de TLS 1.3 vers les cartes réseau. Par conséquent, le chiffrement logiciel est utilisé avec TLS 1.3 même lorsque les cartes réseau prennent en charge le délestage TLS. Pour contourner ce problème, désactivez TLS 1.3 si le délestage est nécessaire. Par conséquent, vous ne pouvez décharger que TLS 1.2. Lorsque TLS 1.3 est utilisé, les performances sont moindres, car TLS 1.3 ne peut pas être déchargé.

L'activation de FADump avec Secure Boot peut entraîner une perte de mémoire (OOM) dans GRUB

Dans l'environnement Secure Boot, GRUB et PowerVM allouent ensemble une zone de mémoire de 512 Mo, connue sous le nom de Real Mode Area (RMA), pour la mémoire de démarrage. La région est divisée entre les composants de démarrage et, si l'un d'entre eux dépasse son allocation, des pannes de mémoire se produisent.

Les systèmes en mode Secure Boot ne peuvent pas exécuter d'opérations dynamiques sur les LPAR

Les utilisateurs ne peuvent pas exécuter d'opérations de partition logique dynamique (DLPAR) à partir de la console de gestion du matériel (HMC) si l'une ou l'autre de ces conditions est remplie :

Les nouveaux noyaux perdent les options de ligne de commande précédentes

Le chargeur d'amorçage GRUB n'applique pas aux nouveaux noyaux les options de ligne de commande personnalisées et configurées précédemment. Par conséquent, lorsque vous mettez à jour le paquetage du noyau, le comportement du système peut changer après le redémarrage en raison des options manquantes.

Device Mapper Multipath n'est pas pris en charge avec NVMe/TCP

L'utilisation de Device Mapper Multipath avec le pilote nvme-tcp peut entraîner des avertissements Call Trace et une instabilité du système. Pour contourner ce problème, les utilisateurs de NVMe/TCP doivent activer le multipathing NVMe natif et ne pas utiliser les outils device-mapper-multipath avec NVMe.

Le service blk-availability systemd désactive les piles de dispositifs complexes

Dans systemd, le code de désactivation des blocs par défaut ne gère pas toujours correctement les piles complexes de blocs virtuels. Dans certaines configurations, les périphériques virtuels peuvent ne pas être supprimés lors de l'arrêt, ce qui entraîne l'enregistrement de messages d'erreur. Pour contourner ce problème, désactivez les piles de blocs complexes en exécutant la commande suivante :

Valeur invalide de sysfs pour supported_speeds

Le pilote qla2xxx indique 20Gb/s au lieu des 64Gb/s prévus comme l'une des vitesses de port prises en charge dans l'attribut sysfs supported_speeds:

Impossible de se connecter aux espaces de noms NVMe à partir d'un initiateur Broadcom sur les systèmes AMD EPYC

Par défaut, le noyau RHEL active l'IOMMU sur les plateformes basées sur AMD. Par conséquent, lorsque vous utilisez des plates-formes activées par IOMMU sur des serveurs équipés de processeurs AMD, vous pouvez rencontrer des problèmes d'E/S NVMe, tels que l'échec des E/S en raison de la non-concordance des longueurs de transfert.

L'option --ssl-fips-mode dans MySQL et MariaDB ne modifie pas le mode FIPS

L'option --ssl-fips-mode dans MySQL et MariaDB dans RHEL fonctionne différemment que dans upstream.

Certaines sondes basées sur des symboles ne fonctionnent pas dans SystemTap sur l'architecture ARM 64 bits

La configuration du noyau désactive certaines fonctionnalités nécessaires à SystemTap. Par conséquent, certaines sondes basées sur des symboles ne fonctionnent pas sur l'architecture ARM 64 bits. Par conséquent, les scripts SystemTap concernés peuvent ne pas s'exécuter ou ne pas recueillir de résultats sur les points de sonde souhaités.

Le client RHEL 9 Kerberos ne parvient pas à authentifier un utilisateur à l'aide de PKINIT contre Heimdal KDC

Lors de l'authentification PKINIT d'un utilisateur IdM sur un client Kerberos RHEL 9, le Centre de distribution Heimdal Kerberos (KDC) sur RHEL 9 ou antérieur utilise l'algorithme de signature de sauvegarde SHA-1 car le client Kerberos ne prend pas en charge le champ supportedCMSTypes. Cependant, l'algorithme SHA-1 a été déprécié dans RHEL 9 et l'authentification de l'utilisateur échoue.

L'authentification PKINIT d'un utilisateur échoue si un agent Kerberos RHEL 9 communique avec un agent Kerberos non RHEL 9

Si un agent Kerberos RHEL 9 interagit avec un autre agent Kerberos non RHEL 9 dans votre environnement, l'authentification d'un utilisateur par cryptographie à clé publique pour l'authentification initiale (PKINIT) échoue. Pour contourner le problème, effectuez l'une des actions suivantes :

La sous-politique DEFAULT:SHA1 doit être définie sur les clients RHEL 9 pour que PKINIT fonctionne avec les anciens KDC RHEL et les KDC AD

L'algorithme de condensé SHA-1 a été supprimé dans RHEL 9, et les messages CMS pour la cryptographie à clé publique pour l'authentification initiale (PKINIT) sont désormais signés avec l'algorithme SHA-256, plus puissant.

La prise en charge FIPS de la confiance AD nécessite la sous-politique cryptographique AD-SUPPORT

Active Directory (AD) utilise des types de chiffrement AES SHA-1 HMAC, qui ne sont pas autorisés par défaut en mode FIPS sur RHEL 9. Si vous souhaitez utiliser des hôtes IdM RHEL 9 avec une confiance AD, activez la prise en charge des types de chiffrement AES SHA-1 HMAC avant d'installer le logiciel IdM.

Directory Server se termine de manière inattendue lorsqu'il est démarré en mode de référence

En raison d'un bogue, le mode de renvoi global ne fonctionne pas dans Directory Server. Si vous démarrez le processus ns-slapd avec l'option refer en tant qu'utilisateur dirsrv, Directory Server ignore les paramètres du port et se termine de manière inattendue. Essayer d'exécuter le processus en tant qu'utilisateur root modifie les étiquettes SELinux et empêche le service de démarrer à l'avenir en mode normal. Il n'y a pas de solution de rechange disponible.

La configuration d'un renvoi pour un suffixe échoue dans Directory Server

Si vous définissez une référence de back-end dans Directory Server, la définition de l'état du back-end à l'aide de la commande dsconf <instance_name> backend suffix set --state referral échoue avec l'erreur suivante :

L'utilitaire dsconf n'a pas d'option pour créer des tâches de correction pour le plug-in entryUUID

L'utilitaire dsconf ne propose pas d'option permettant de créer des tâches de correction pour le plug-in entryUUID. Par conséquent, les administrateurs ne peuvent pas utiliser dsconf pour créer une tâche permettant d'ajouter automatiquement des attributs entryUUID aux entrées existantes. Une solution de contournement consiste à créer une tâche manuellement :

Risque potentiel lié à l'utilisation de la valeur par défaut de l'option ldap_id_use_start_tls

L'utilisation de ldap:// sans TLS pour les recherches d'identité peut constituer un risque pour un vecteur d'attaque. En particulier une attaque de type "man-in-the-middle" (MITM) qui pourrait permettre à un pirate d'usurper l'identité d'un utilisateur en modifiant, par exemple, l'UID ou le GID d'un objet renvoyé lors d'une recherche LDAP.

Les modules complémentaires de Firefox sont désactivés après la mise à niveau vers RHEL 9

Si vous passez de RHEL 8 à RHEL 9, tous les modules complémentaires que vous avez précédemment activés dans Firefox sont désactivés.

VNC ne fonctionne pas après la mise à niveau vers RHEL 9

Après une mise à niveau de RHEL 8 vers RHEL 9, le serveur VNC ne démarre pas, même s'il était activé auparavant.

Matrox G200e n'affiche aucune sortie sur un écran VGA

Il se peut que votre écran n'affiche aucune sortie graphique si vous utilisez la configuration suivante :

Les utilitaires de configuration X.org ne fonctionnent pas sous Wayland

Les utilitaires X.org permettant de manipuler l'écran ne fonctionnent pas dans la session Wayland. En particulier, l'utilitaire xrandr ne fonctionne pas sous Wayland en raison de son approche différente de la gestion, des résolutions, des rotations et de la mise en page.

Les pilotes NVIDIA pourraient revenir à X.org

Dans certaines conditions, les pilotes propriétaires de NVIDIA désactivent le protocole d'affichage Wayland et reviennent au serveur d'affichage X.org :

Night Light n'est pas disponible sur Wayland avec NVIDIA

Lorsque les pilotes NVIDIA propriétaires sont activés sur votre système, la fonction Night Light de GNOME n'est pas disponible dans les sessions Wayland. Les pilotes NVIDIA ne prennent pas actuellement en charge Night Light.

La suppression de périphériques hôtes USB à l'aide de la console web ne fonctionne pas comme prévu

Lorsque vous attachez un périphérique USB à une machine virtuelle (VM), le numéro de périphérique et le numéro de bus du périphérique USB peuvent changer après avoir été transmis à la VM. Par conséquent, l'utilisation de la console web pour supprimer ces périphériques échoue en raison de la corrélation incorrecte des numéros de périphérique et de bus. Pour contourner ce problème, supprimez la partie <hostdev> du périphérique USB de la configuration XML de la VM.

L'attachement de plusieurs périphériques hôtes à l'aide de la console web ne fonctionne pas

Lorsque vous sélectionnez plusieurs périphériques à attacher à une machine virtuelle (VM) à l'aide de la console web, seul un périphérique est attaché et les autres sont ignorés. Pour contourner ce problème, attachez un seul périphérique à la fois.

L'installation d'une machine virtuelle via https échoue dans certains cas

Actuellement, l'utilitaire virt-install échoue lorsqu'il tente d'installer un système d'exploitation invité à partir d'une source ISO via une connexion https - par exemple en utilisant virt-install --cdrom https://example/path/to/image.iso. Au lieu de créer une machine virtuelle (VM), l'opération décrite se termine de manière inattendue par un message internal error: process exited while connecting to monitor.

L'utilisation des pilotes NVIDIA dans les machines virtuelles désactive Wayland

Actuellement, les pilotes NVIDIA ne sont pas compatibles avec la session graphique Wayland. Par conséquent, les systèmes d'exploitation invités RHEL qui utilisent des pilotes NVIDIA désactivent automatiquement Wayland et chargent une session Xorg à la place. Cela se produit principalement dans les scénarios suivants :

Le type de CPU Milan VM n'est parfois pas disponible sur les systèmes AMD Milan

Sur certains systèmes AMD Milan, les options Enhanced REP MOVSB (erms) et Fast Short REP MOVSB (fsrm) sont désactivées par défaut dans le BIOS. Par conséquent, le type de CPU "Milan" peut ne pas être disponible sur ces systèmes. En outre, la migration en direct de VM entre des hôtes Milan avec des paramètres de drapeaux de fonctionnalités différents peut échouer. Pour résoudre ces problèmes, activez manuellement erms et fsrm dans le BIOS de votre hôte.

Les performances du trafic réseau dans les machines virtuelles peuvent être réduites

Dans certains cas, les machines virtuelles invitées (VM) RHEL 9.0 ont des performances quelque peu réduites lorsqu'elles gèrent des niveaux élevés de trafic réseau.

La désactivation d'AVX rend les machines virtuelles non amorçables

Sur une machine hôte qui utilise un processeur avec support Advanced Vector Extensions (AVX), la tentative de démarrage d'une VM avec AVX explicitement désactivé échoue actuellement et déclenche une panique du noyau dans la VM.

Les cartes réseau virtio de basculement ne reçoivent pas d'adresse IP sur les machines virtuelles Windows

Actuellement, lors du démarrage d'une machine virtuelle (VM) Windows avec seulement une carte d'interface réseau virtio de basculement, la VM ne parvient pas à attribuer une adresse IP à la carte d'interface réseau. Par conséquent, la carte d'interface réseau n'est pas en mesure d'établir une connexion réseau. Il n'existe actuellement aucune solution de contournement.

Une interface hostdev avec des paramètres de basculement ne peut pas être branchée à chaud après avoir été débranchée à chaud

Après avoir supprimé une interface réseau hostdev avec une configuration de basculement d'une machine virtuelle (VM) en cours d'exécution, l'interface ne peut actuellement pas être réattachée à la même VM en cours d'exécution.

Échec de la migration post-copie en direct de VM avec des VF de basculement

Actuellement, la tentative de migration post-copie d'une machine virtuelle (VM) en cours d'exécution échoue si la VM utilise un périphérique dont la capacité de basculement de la fonction virtuelle (VF) est activée. Pour contourner le problème, utilisez le type de migration standard plutôt que la migration post-copie.

SR-IOV fonctionne de manière sous-optimale dans les machines virtuelles ARM 64 RHEL 9 sur Azure

Actuellement, les dispositifs de mise en réseau SR-IOV ont un rendement nettement plus faible et une latence plus élevée que prévu dans les machines virtuelles ARM 64 RHEL 9 fonctionnant sur une plateforme Microsoft Azure.

La souris n'est pas utilisable dans les machines virtuelles RHEL 9 sur XenServer 7 avec un proxy de console

Lors de l'exécution d'une machine virtuelle (VM) RHEL 9 sur une plateforme XenServer 7 avec un proxy de console, il n'est pas possible d'utiliser la souris dans l'interface graphique de la VM. Pour contourner ce problème, désactivez le protocole compositeur Wayland dans la VM comme suit :

Le clonage ou la restauration de machines virtuelles RHEL 9 utilisant LVM sur Nutanix AHV entraîne la disparition des partitions non root

Lors de l'exécution d'un système d'exploitation invité RHEL 9 sur une machine virtuelle (VM) hébergée sur l'hyperviseur Nutanix AHV, la restauration de la VM à partir d'un snapshot ou le clonage de la VM provoque actuellement la disparition des partitions non racine dans la VM si l'invité utilise Logical Volume Management (LVM). En conséquence, les problèmes suivants se produisent :

La fonctionnalité SR-IOV d'une carte réseau connectée à une machine virtuelle Hyper-V peut ne pas fonctionner

Actuellement, lors de la connexion d'un adaptateur réseau avec la virtualisation d'E/S à racine unique (SR-IOV) activée à une machine virtuelle RHEL 9 fonctionnant sur l'hyperviseur Microsoft Hyper-V, la fonctionnalité SR-IOV ne fonctionne pas correctement dans certains cas.

La personnalisation des invités RHEL 9 sur ESXi entraîne parfois des problèmes de réseau

Actuellement, la personnalisation d'un système d'exploitation invité RHEL 9 dans l'hyperviseur VMware ESXi ne fonctionne pas correctement avec les fichiers clés NetworkManager. Par conséquent, si l'invité utilise un tel fichier clé, il aura des paramètres réseau incorrects, tels que l'adresse IP ou la passerelle.

Délai d'attente lors de l'exécution de sos report sur IBM Power Systems, Little Endian

Lors de l'exécution de la commande sos report sur des systèmes IBM Power, Little Endian avec des centaines ou des milliers de CPU, le plugin processeur atteint son délai d'attente par défaut de 300 secondes lors de la collecte de l'énorme contenu du répertoire /sys/devices/system/cpu. Pour contourner ce problème, augmentez le délai d'attente du plugin en conséquence :

Les images de conteneurs signées avec une clé Beta GPG ne peuvent pas être extraites

Actuellement, lorsque vous essayez d'extraire des images de conteneurs RHEL 9 Beta, podman s'arrête avec le message d'erreur : Error: Source image rejected: None of the signatures were accepted. Les images ne peuvent pas être extraites car les versions actuelles sont configurées pour ne pas faire confiance aux clés GPG de RHEL Beta par défaut.

Podman ne parvient pas à extraire un conteneur "X509 : certificat signé par une autorité inconnue"

Si vous disposez de votre propre registre interne signé par notre propre certificat d'autorité de certification, vous devez importer le certificat sur votre machine hôte. Sinon, une erreur se produit :

L'exécution de systemd dans une ancienne image de conteneur ne fonctionne pas

L'exécution de systemd dans une ancienne image de conteneur, par exemple, centos:7, ne fonctionne pas :

podman system connection add et podman image scp échoue

Podman utilise des hachages SHA-1 pour l'échange de clés RSA. La connexion SSH normale entre les machines utilisant des clés RSA fonctionne, mais les commandes podman system connection add et podman image scp ne fonctionnent pas avec les mêmes clés RSA, car les hachages SHA-1 ne sont pas acceptés pour l'échange de clés sur RHEL 9 :