Prise en charge de l'analyse automatique des LUN SCSI du FCP dans le programme d'installation

Le programme d'installation peut désormais utiliser l'analyse automatique des LUN lors de l'attachement des LUN SCSI FCP sur les systèmes IBM Z. L'analyse automatique des LUN est disponible pour les périphériques FCP fonctionnant en mode NPIV, si elle n'est pas désactivée par le paramètre du module du noyau zfcp.allow_lun_scan. Il est activé par défaut. Il permet d'accéder à tous les périphériques SCSI du réseau de stockage attachés au périphérique FCP avec l'ID de bus spécifié. Il n'est plus nécessaire de spécifier le WWPN et les LUN FCP et il suffit de fournir uniquement l'ID du bus du périphérique FCP.

Image builder on-premise prend désormais en charge la personnalisation de la partition /boot

La version sur site d'Image builder prend désormais en charge la construction d'images avec une taille de partition de point de montage /boot personnalisée. Vous pouvez spécifier la taille de la partition du point de montage /boot dans la personnalisation du plan, afin d'augmenter la taille de la partition /boot au cas où la taille de la partition de démarrage par défaut serait trop petite. Par exemple :

Ajout de l'option --allow-ssh kickstart pour activer les connexions racine SSH basées sur un mot de passe

Lors de l'installation graphique, vous avez la possibilité d'activer les connexions racine SSH basées sur un mot de passe. Cette fonctionnalité n'était pas disponible dans les installations kickstart. Avec cette mise à jour, une option --allow-ssh a été ajoutée à la commande rootpw kickstart. Cette option permet à l'utilisateur root de se connecter au système en utilisant SSH avec un mot de passe.

Menu du chargeur de démarrage caché par défaut

Le chargeur de démarrage GRUB est désormais configuré pour masquer le menu de démarrage par défaut. Il en résulte une expérience de démarrage plus fluide. Le menu de démarrage est caché dans tous les cas suivants :

L'installation minimale de RHEL n'installe plus que le paquet s390utils-core

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, si vous définissez l'installation RHEL sur minimal-environment, vous n'installez que le paquet s390utils-core nécessaire et non le paquet auxiliaire s390utils-base. Si vous souhaitez utiliser le paquet s390utils-base avec une installation RHEL minimale, vous devez installer manuellement le paquet après avoir terminé l'installation RHEL ou installer explicitement s390utils-base à l'aide d'un fichier kickstart.

Image builder on-premise prend désormais en charge le téléchargement d'images vers GCP

Grâce à cette amélioration, vous pouvez utiliser l'interface CLI de construction d'images pour créer une image gce, en fournissant les informations d'identification de l'utilisateur ou du compte de service que vous souhaitez utiliser pour télécharger les images. En conséquence, image builder crée l'image et télécharge ensuite l'image gce directement dans l'environnement GCP que vous avez spécifié.

L'interface de programmation (CLI) d'Image builder on-premise permet de pousser une image de conteneur directement vers un registre

Grâce à cette amélioration, vous pouvez pousser les images de conteneurs RHEL for Edge directement vers un registre de conteneurs après leur construction, à l'aide de l'interface CLI de construction d'images. Pour construire l'image de conteneur :

Les utilisateurs d'Image builder sur site peuvent désormais personnaliser leurs plans au cours du processus de création d'images

Avec cette mise à jour, la page Edit Blueprint a été supprimée afin d'unifier l'expérience de l'utilisateur dans le service de création d'images et dans l'application de création d'images sur cockpit-composer. Les utilisateurs peuvent désormais créer leurs plans et les personnaliser, par exemple en ajoutant des paquets et en créant des utilisateurs, au cours du processus de création d'images. Le versionnage des blueprints a également été supprimé, de sorte que les blueprints n'ont qu'une seule version : la version actuelle. Les utilisateurs ont accès aux versions antérieures des blueprints par l'intermédiaire de leurs images déjà créées.

RHEL for Edge prend désormais en charge l'utilitaire fdo-admin cli

Avec cette mise à jour, vous pouvez configurer les services FDO directement dans tous les scénarios de déploiement en utilisant le CLI.

L'utilitaire subscription-manager affiche l'état actuel des actions

L'utilitaire subscription-manager affiche désormais des informations sur la progression de l'opération en cours. Ceci est utile lorsque subscription-manager prend plus de temps que d'habitude pour terminer ses opérations liées à la communication avec le serveur, par exemple, l'enregistrement.

La commande modulesync est désormais disponible pour remplacer certains flux de travail dans RHEL 9

Dans RHEL 9, les paquets modulaires ne peuvent pas être installés sans métadonnées modulaires. Auparavant, vous pouviez utiliser la commande dnf pour télécharger des paquets, puis utiliser la commande createrepo_c pour redistribuer ces paquets.

Cronie ajoute la prise en charge d'un temps aléatoire dans une plage sélectionnée

L'utilitaire Cronie supporte désormais l'opérateur ~ (random within range) pour l'exécution des cronjob. Par conséquent, vous pouvez démarrer un cronjob à un moment aléatoire dans l'intervalle sélectionné.

ReaR ajoute de nouvelles variables pour l'exécution des commandes avant et après la récupération

Avec cette amélioration, ReaR introduit deux nouvelles variables pour faciliter l'automatisation des commandes à exécuter avant et après la récupération :

Un nouveau paquet : xmlstarlet

XMLStarlet est un ensemble d'utilitaires en ligne de commande permettant d'analyser, de transformer, d'interroger, de valider et d'éditer des fichiers XML. Le nouveau paquetage xmlstarlet fournit un ensemble simple de commandes shell que vous pouvez utiliser de la même manière que les commandes UNIX pour les fichiers de texte brut tels que grep, sed, awk, diff, patch, join, et autres.

opencryptoki repassé à la version 3.18.0

Le paquetage opencryptoki, qui est une implémentation de la norme de cryptographie à clé publique (PKCS) #11, a été mis à jour à la version 3.18.0. Les améliorations notables sont les suivantes :

powerpc-utils repassé à la version 1.3.10

Le paquetage powerpc-utils, qui fournit divers utilitaires pour une plate-forme PowerPC, a été mis à jour à la version 1.3.10. Les améliorations notables sont les suivantes :

Les modules Redfish font désormais partie de la collection Ansible redhat.rhel_mgmt

La collection Ansible de redhat.rhel_mgmt comprend désormais les modules suivants :

libvpd repassé à la version 2.2.9

Le paquetage libvpd, qui contient des classes permettant d'accéder aux données sur les produits vitaux (VPD), a été mis à jour à la version 2.2.9. Les améliorations notables sont les suivantes :

lsvpd repassé à la version 1.7.14

Le paquetage lsvpd, qui fournit des commandes pour constituer un système d'inventaire matériel, a été mis à jour à la version 1.7.14. Avec cette mise à jour, l'utilitaire lsvpd empêche la corruption du fichier de base de données lorsque vous exécutez la commande vpdupdate.

ppc64-diag repassé à la version 2.7.8

Le paquetage ppc64-diag pour les diagnostics de plateforme a été mis à jour à la version 2.7.8. Les améliorations notables sont les suivantes :

sysctl introduit la même syntaxe pour les arguments que systemd-sysctl

L'utilitaire sysctl du paquetage procps-ng, que vous pouvez utiliser pour modifier les paramètres du noyau au moment de l'exécution, utilise désormais la même syntaxe pour les arguments que l'utilitaire systemd-sysctl. Avec cette mise à jour, sysctl analyse désormais les fichiers de configuration qui contiennent des traits d'union (-) ou des globes (*) sur les lignes de configuration. Pour plus d'informations sur la syntaxe de systemd-sysctl, consultez la page de manuel sysctl.d(5).

chrony utilise désormais des serveurs NTP DHCPv6

Le script NetworkManager dispatcher pour chrony met à jour les sources NTP (Network Time Protocol) transmises par les options DHCP (Dynamic Host Configuration Protocol). Depuis RHEL 9.1, le script utilise les serveurs NTP fournis par DHCPv6 en plus de DHCPv4. L'option DHCP 56 spécifie l'utilisation du DHCPv6, l'option DHCP 42 est spécifique au DHCPv4.

chrony repassé à la version 4.2

La suite chrony a été mise à jour à la version 4.2. Les améliorations notables par rapport à la version 4.1 sont les suivantes :

unbound repassé à la version 1.16.2

Le composant unbound a été mis à jour vers la version 1.16.2. unbound est un résolveur DNS validant, récursif et de mise en cache. Les améliorations notables sont les suivantes :

La fonction de cryptage du mot de passe est désormais disponible dans whois

Le paquet whois fournit maintenant le binaire /usr/bin/mkpasswd, que vous pouvez utiliser pour crypter un mot de passe avec l'interface de la bibliothèque C crypt.

frr repassé à la version 8.2.2

Le paquetage frr pour la gestion de la pile de routage dynamique a été mis à jour à la version 8.2.2. Les changements et améliorations notables par rapport à la version 8.0 sont les suivants :

Les profils en temps réel de TuneD déterminent désormais automatiquement la configuration initiale de l'isolation du processeur

TuneD est un service qui permet de surveiller votre système et d'en optimiser le profil de performance. Vous pouvez également isoler les unités centrales de traitement (CPU) à l'aide du paquetage tuned-profiles-realtime afin de donner aux threads d'application le plus de temps d'exécution possible.

Nouveaux paquets : keylime

RHEL 9.1 introduit Keylime, un outil d'attestation des systèmes distants, qui utilise la technologie TPM (trusted platform module). Avec Keylime, vous pouvez vérifier et surveiller en permanence l'intégrité des systèmes distants. Vous pouvez également spécifier des charges utiles cryptées que Keylime délivre aux machines surveillées, et définir des actions automatisées qui se déclenchent chaque fois qu'un système échoue au test d'intégrité.

Une nouvelle option dans OpenSSH permet de définir la longueur minimale de la clé RSA

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

crypto-policies imposer une longueur minimale de clé RSA de 2048 bits pour OpenSSH par défaut

L'utilisation de clés RSA courtes rend le système plus vulnérable aux attaques. OpenSSH prenant désormais en charge la limitation de la longueur minimale des clés RSA, les règles cryptographiques applicables à l'ensemble du système imposent par défaut la longueur minimale de 2048 bits pour les clés RSA.

Une nouvelle option d'OpenSSL prend en charge SHA-1 pour les signatures

OpenSSL 3.0.0 dans RHEL 9 ne prend pas en charge SHA-1 pour la création et la vérification des signatures par défaut (les fonctions de dérivation de clé SHA-1 (KDF) et les codes d'authentification de message basés sur le hachage (HMAC) sont toujours pris en charge). Toutefois, pour assurer la rétrocompatibilité avec les systèmes RHEL 8 qui utilisent encore SHA-1 pour les signatures, une nouvelle option de configuration rh-allow-sha1-signatures est introduite dans RHEL 9. Cette option, si elle est activée dans alg_section de openssl.cnf, permet la création et la vérification de signatures SHA-1.

crypto-policies soutient désormais sntrup761x25519-sha512@openssh.com

Cette mise à jour des politiques cryptographiques du système ajoute la prise en charge de la méthode d'échange de clés (KEX) sntrup761x25519-sha512@openssh.com. L'algorithme post-quantique sntrup761 est déjà disponible dans la suite OpenSSH, et cette méthode offre une meilleure sécurité contre les attaques des ordinateurs quantiques. Pour activer sntrup761x25519-sha512@openssh.com, créez et appliquez une sous-politique, par exemple :

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 :

La politique SELinux limite les services supplémentaires

Les paquets selinux-policy ont été mis à jour, et par conséquent les services suivants sont maintenant confinés par SELinux :

SELinux prend en charge le mot-clé self dans les transitions de type

L'outil SELinux prend désormais en charge les règles de transition de type avec le mot-clé self dans les sources de politique. La prise en charge des transitions de type avec le mot-clé self prépare la politique SELinux à l'étiquetage des inodes anonymes.

Mise à jour des paquets SELinux pour l'espace utilisateur

Les paquets SELinux pour l'espace utilisateur libsepol, libselinux, libsemanage, policycoreutils, checkpolicy, et mcstrans ont été mis à jour vers la dernière version amont 3.4. Les changements les plus notables sont les suivants :

Le réétiquetage automatique SELinux est désormais parallèle par défaut

Étant donné que l'option de réétiquetage parallèle récemment introduite réduit considérablement le temps nécessaire au processus de réétiquetage SELinux sur les systèmes multicœurs, le script de réétiquetage automatique contient désormais l'option -T 0 dans la ligne de commande fixfiles. L'option -T 0 garantit que le programme setfiles utilise par défaut le maximum de cœurs de processeur disponibles pour le ré-étiquetage.

Guide de sécurité SCAP repassé à la version 0.1.63

Les paquets du guide de sécurité SCAP (SSG) ont été rebasés vers la version amont 0.1.63. Cette version apporte diverses améliorations et corrections de bogues, notamment :

Ajout d'une option de taille maximale pour les fichiers d'erreur Rsyslog

La nouvelle option action.errorfile.maxsize permet de spécifier le nombre maximal d'octets du fichier d'erreurs pour le système de traitement des journaux Rsyslog. Lorsque le fichier d'erreurs atteint la taille spécifiée, Rsyslog ne peut plus y écrire d'erreurs supplémentaires ou d'autres données. Cela permet d'éviter que le fichier d'erreurs ne remplisse le système de fichiers et ne rende l'hôte inutilisable.

clevis-luks-askpass est désormais activé par défaut

Le fichier /lib/systemd/system-preset/90-default.preset contient désormais l'option de configuration enable clevis-luks-askpass.path et l'installation du sous-paquet clevis-systemd garantit que le fichier d'unité clevis-luks-askpass.path est activé. Cela permet au client de chiffrement Clevis de déverrouiller également les volumes chiffrés LUKS qui se montent tardivement dans le processus de démarrage. Avant cette mise à jour, l'administrateur devait utiliser la commande systemctl enable clevis-luks-askpass.path pour permettre à Clevis de déverrouiller ces volumes.

fapolicyd repassé à la version 1.1.3

Les paquets fapolicyd ont été mis à jour vers la version 1.1.3. Les améliorations notables et les corrections de bogues incluent :

Le module du noyau act_ctinfo a été ajouté

Cette amélioration ajoute le module de noyau act_ctinfo à RHEL. En utilisant l'action ctinfo de l'utilitaire tc, les administrateurs peuvent copier la marque conntrack ou la valeur du point de code des services différenciés (DSCP) des paquets réseau dans le champ de métadonnées mark de la mémoire tampon de la socket. Par conséquent, vous pouvez utiliser des conditions basées sur la marque conntrack ou la valeur DSCP pour filtrer le trafic. Pour plus de détails, voir la page de manuel tc-ctinfo(8).

cloud-init met à jour la configuration du réseau à chaque démarrage sur Microsoft Azure

Microsoft Azure ne modifie pas l'identifiant de l'instance lorsqu'un administrateur met à jour la configuration de l'interface réseau alors qu'une VM est hors ligne. Grâce à cette amélioration, le service cloud-init met toujours à jour la configuration du réseau lorsque la VM démarre afin de garantir que RHEL on Microsoft Azure utilise les derniers paramètres réseau.

Le pilote PTP prend désormais en charge les horloges virtuelles et l'horodatage

Grâce à cette amélioration, le pilote Precision Time Protocol (PTP) peut créer des horloges matérielles PTP virtuelles (PHC) au-dessus d'une PHC fonctionnant librement en écrivant à /sys/class/ptp/ptp*/n_vclocks. Par conséquent, les utilisateurs peuvent exécuter la synchronisation de plusieurs domaines avec des horodateurs matériels sur une seule interface.

firewalld est passé à la version 1.1.1

Les paquets firewalld ont été mis à jour vers la version 1.1.1. Cette version apporte de nombreuses corrections de bogues et des améliorations par rapport à la version précédente :

NetworkManager supporte désormais les attributs de route advmss, rto_min, et quickack

Grâce à cette amélioration, les administrateurs peuvent configurer le paramètre ipv4.routes avec les attributs suivants :

Prise en charge de l'option 802.ad vlan-protocol en nmstate

L'API nmstate prend désormais en charge la création des interfaces linux-bridge à l'aide de l'option 802.ad vlan-protocol. Cette fonctionnalité permet la configuration de VLANs Service-Tag. L'exemple suivant illustre l'utilisation de cette fonctionnalité dans un fichier de configuration yaml.

Le service firewalld peut transférer les paquets NAT provenant de l'hôte local vers un autre hôte et un autre port

Vous pouvez transférer les paquets envoyés depuis l'hôte local qui exécute le service firewalld vers un port de destination et une adresse IP différents. Cette fonctionnalité est utile, par exemple, pour transférer les ports du périphérique loopback vers un conteneur ou une machine virtuelle. Avant cette modification, firewalld ne pouvait transférer des ports que lorsqu'il recevait un paquet provenant d'un autre hôte. Pour plus de détails et une configuration illustrative, voir Utilisation de DNAT pour transférer le trafic HTTPS vers un autre hôte.

NetworkManager supporte maintenant la migration de ifcfg-rh vers le fichier clé

Les utilisateurs peuvent migrer leurs fichiers de profil de connexion existants du format ifcfg-rh vers le format de fichier clé. De cette manière, tous les profils de connexion se trouveront à un seul endroit et dans le format préféré. Le format de fichier clé présente les avantages suivants :

D'autres attributs d'auto-configuration DHCP et IPv6 ont été ajoutés à l'API nmstate

Cette amélioration ajoute la prise en charge des attributs suivants à l'API nmstate :

NetworkManager indique désormais clairement que la prise en charge du WEP n'est pas disponible dans RHEL 9

Les paquets wpa_supplicant de RHEL 9.0 et des versions ultérieures ne contiennent plus l'algorithme de sécurité WEP (Wired Equivalent Privacy), qui est obsolète et peu sûr. Cette amélioration met à jour NetworkManager pour refléter ces changements. Par exemple, la commande nmcli device wifi list renvoie désormais les points d'accès WEP à la fin de la liste en couleur grise, et la connexion à un réseau protégé par WEP renvoie un message d'erreur significatif.

Le code MPTCP a été mis à jour

Le code MultiPath TCP (MPTCP) dans le noyau a été mis à jour en amont de Linux 5.19. Cette mise à jour apporte un certain nombre de corrections de bogues et d'améliorations par rapport à la version précédente :

Version du noyau dans RHEL 9.1

Red Hat Enterprise Linux 9.1 est distribué avec la version 5.14.0-162 du noyau.

La consommation de mémoire du site list_lru a été optimisée

La structure de données interne du noyau, list_lru, suit l'état \N "Least Recently Used" (le moins récemment utilisé) des inodes du noyau et des entrées de répertoire pour les fichiers. Auparavant, le nombre de structures allouées list_lru était directement proportionnel au nombre de points de montage et au nombre de mémoires présentes cgroups. Ces deux chiffres augmentaient avec le nombre de conteneurs en cours d'exécution, ce qui entraînait une consommation de mémoire de O(n^2) où n est le nombre de conteneurs en cours d'exécution. Cette mise à jour optimise la consommation de mémoire de list_lru dans le système à O(n). Par conséquent, les applications des utilisateurs disposent désormais de suffisamment de mémoire, en particulier sur les systèmes où un grand nombre de conteneurs sont en cours d'exécution.

BPF rebasé sur la version 5.16 du noyau Linux

Le filtre de paquets Berkeley (BPF) a été rebasé sur la version 5.16 du noyau Linux avec de nombreuses corrections de bogues et améliorations. Les changements les plus notables sont les suivants :

Les données BTF se trouvent désormais dans le module du noyau

BPF Type Format (BTF) est le format de métadonnées qui encode les informations de débogage relatives au programme et à la carte BPF. Auparavant, les données BTF pour les modules du noyau étaient stockées dans le paquetage kernel-debuginfo. Par conséquent, il était nécessaire d'installer le paquetage kernel-debuginfo correspondant afin d'utiliser le BTF pour les modules du noyau. Avec cette mise à jour, les données BTF sont maintenant situées directement dans le module du noyau. Par conséquent, vous n'avez pas besoin d'installer d'autres paquets pour que BTF fonctionne.

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

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-rt. Ces mises à jour apportent un certain nombre de corrections de bogues et d'améliorations.

Programmation dynamique préemptive activée sur les architectures ARM, AMD et Intel 64 bits

RHEL 9 offre la fonction de planification dynamique sur les architectures ARM, AMD et Intel 64 bits. Cette amélioration permet de modifier le mode de préemption du noyau au démarrage ou au moment de l'exécution plutôt qu'au moment de la compilation. Le fichier /sys/kernel/debug/sched/preempt contient la configuration actuelle et permet de modifier runtime.

stalld repassé à la version 1.17

Le programme stalld, qui fournit le démon stall, est un mécanisme permettant d'éviter l'état de famine des threads du système d'exploitation dans un système Linux. Cette version surveille les threads pour l'état de famine. L'état de famine survient lorsqu'un thread se trouve dans la file d'attente d'exécution du processeur pendant une durée supérieure au seuil de famine.

Le paquet tpm2-tools a été rebasé sur la version tpm2-tools-5.2-1

Le paquetage tpm2-tools a été rebasé vers la version tpm2-tools-5.2-1. Cette mise à jour apporte de nombreuses améliorations significatives et des corrections de bogues. Les changements les plus notables sont les suivants :

Les appareils Intel E800 prennent désormais en charge les protocoles iWARP et RoCE

Avec cette amélioration, vous pouvez désormais utiliser les paramètres enable_iwarp et enable_roce devlink pour activer et désactiver la prise en charge des protocoles iWARP ou RoCE. Grâce à cette fonctionnalité obligatoire, vous pouvez configurer l'appareil avec l'un des protocoles. Les appareils Intel E800 ne supportent pas les deux protocoles simultanément sur le même port.

GRUB est signé par de nouvelles clés

Pour des raisons de sécurité, GRUB est désormais signé par de nouvelles clés. Par conséquent, vous devez mettre à jour le micrologiciel RHEL vers la version FW1010.30 (ou ultérieure) ou FW1020 pour pouvoir démarrer la variante little-endian des systèmes IBM Power avec la fonction Secure Boot activée.

Stratis permet désormais de définir la taille du système de fichiers lors de sa création

Vous pouvez désormais définir la taille requise lors de la création d'un système de fichiers. Auparavant, la taille automatique par défaut était de 1 TiB. Avec cette amélioration, les utilisateurs peuvent définir une taille de système de fichiers arbitraire. La limite inférieure ne doit pas être inférieure à 512 MiB.

Amélioration de la gestion de l'overprovisionnement des pools Stratis

Grâce aux améliorations apportées à la gestion du thin provisioning, vous pouvez désormais bénéficier de meilleurs avertissements, d'une allocation précise de l'espace pour les métadonnées du pool, d'une meilleure prévisibilité, d'une sécurité globale et d'une fiabilité accrue de la gestion du thin pool. Un nouveau mode distinct désactive l'overprovisioning. Grâce à cette amélioration, l'utilisateur peut désactiver l'overprovisioning pour s'assurer qu'un pool contient suffisamment d'espace pour prendre en charge tous ses systèmes de fichiers, même si ceux-ci sont complètement pleins.

Stratis offre désormais une meilleure gestion des piscines individuelles

Vous pouvez désormais arrêter et démarrer des pools Stratis individuels arrêtés. Auparavant, stratisd tentait de démarrer tous les pools disponibles pour tous les périphériques qu'il détectait. Cette amélioration permet une gestion plus souple des pools individuels au sein de Stratis, ainsi que de meilleures capacités de débogage et de récupération. Le système ne nécessite plus de redémarrage pour effectuer des opérations de récupération et de maintenance pour un seul pool.

Activation de la configuration spécifique au protocole des chemins d'accès des dispositifs à trajets multiples

Auparavant, en raison des différentes configurations optimales pour les différents protocoles, il était impossible de définir la configuration correctement sans définir une option pour chaque protocole individuel. Grâce à cette amélioration, les utilisateurs peuvent désormais configurer les chemins d'accès des dispositifs à trajets multiples en fonction de leur protocole de transport. Utilisez la sous-section protocol de la section overrides dans le fichier /etc/multipath.conf pour configurer correctement les chemins d'accès des périphériques à trajets multiples en fonction de leur protocole.

Nouvelle bibliothèque de fonctionnalités libnvme

Auparavant, l'utilitaire de l'interface de ligne de commande du stockage NVMe (nvme-cli) incluait toutes les fonctions et définitions d'aide. Cette amélioration apporte une nouvelle bibliothèque libnvme à RHEL 9.1. Cette bibliothèque comprend les éléments suivants

Une nouvelle bibliothèque libnvme est maintenant disponible

With this update, nvme-cli is divided in two different projects: * nvme-cli now only contains the code specific to the nvme tool * libnvme library now contains all type definitions for NVMe specification structures, enumerations, bit fields, helper functions to construct, dispatch, decode commands and payloads, and utilities to connect, scan, and manage NVMe devices.

Prise en charge de la haute disponibilité sur la plateforme Red Hat OpenStack

Vous pouvez désormais configurer un cluster de haute disponibilité sur la plateforme Red Hat OpenStack. Pour prendre en charge cette fonctionnalité, Red Hat fournit les nouveaux agents de cluster suivants :

pcs prend en charge la mise à jour des périphériques SCSI à chemins multiples sans nécessiter un redémarrage du système

Vous pouvez désormais mettre à jour les périphériques SCSI multipath à l'aide de la commande pcs stonith update-scsi-devices. Cette commande met à jour les périphériques SCSI sans provoquer le redémarrage des autres ressources de la grappe fonctionnant sur le même nœud.

Prise en charge de l'UUID des clusters

Lors de l'installation d'un cluster, la commande pcs génère désormais un UUID pour chaque cluster. Comme le nom d'un cluster n'est pas un identifiant unique, vous pouvez utiliser l'UUID du cluster pour identifier les clusters portant le même nom lorsque vous administrez plusieurs clusters.

Nouvelle option de commande pcs resource config pour afficher les commandes pcs qui recréent les ressources configurées

La commande pcs resource config accepte désormais l'option --output-format=cmd. Cette option permet d'afficher les commandes pcs que vous pouvez utiliser pour recréer les ressources configurées sur un autre système.

Nouvelle option de commande pcs stonith config pour afficher les commandes pcs qui recréent les dispositifs de clôture configurés

La commande pcs stonith config accepte désormais l'option --output-format=cmd. Cette option permet d'afficher les commandes pcs que vous pouvez utiliser pour recréer les périphériques de clôture configurés sur un autre système.

Pacemaker passe à la version 2.1.4

Les paquets Pacemaker ont été mis à jour vers la version amont de Pacemaker 2.1.4. Les changements notables sont les suivants :

Samba n'est plus installé automatiquement avec les paquets cluster

À partir de cette version, l'installation des paquets pour le module complémentaire de haute disponibilité RHEL n'installe plus automatiquement les paquets Samba. Cela vous permet également de supprimer les paquets Samba sans supprimer automatiquement les paquets HA. Si votre cluster utilise des ressources Samba, vous devez maintenant les installer manuellement.

Le flux de modules nodejs:18 est désormais entièrement pris en charge

Le flux du module nodejs:18, précédemment disponible en tant qu'aperçu technologique, est entièrement pris en charge avec la publication de l'avis RHSA-2022:8832. Le flux de modules nodejs:18 fournit désormais Node.js 18.12, qui est une version de support à long terme (LTS).

Un nouveau flux de modules : php:8.1

RHEL 9.1 ajoute PHP 8.1 en tant que nouveau flux de modules php:8.1.

Un nouveau flux de modules : ruby:3.1

RHEL 9.1 introduit Ruby 3.1.2 dans un nouveau flux de modules ruby:3.1. Cette version 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 3.0 distribué avec RHEL 9.0.

httpd repassé à la version 2.4.53

Le serveur HTTP Apache a été mis à jour vers la version 2.4.53, qui apporte des corrections de bogues, des améliorations et des correctifs de sécurité par rapport à la version 2.4.51 distribuée avec RHEL 9.0.

Une nouvelle valeur par défaut pour la directive LimitRequestBody dans la configuration de httpd

Pour corriger CVE-2022-29404, la valeur par défaut de la directive LimitRequestBody dans le serveur HTTP Apache a été modifiée de 0 (illimité) à 1 GiB.

Nouveau paquet : httpd-core

À partir de RHEL 9.1, le fichier binaire httpd contenant tous les fichiers essentiels a été déplacé vers le nouveau paquet httpd-core afin de limiter les dépendances du serveur HTTP Apache dans les scénarios où seule la fonctionnalité de base httpd est nécessaire, par exemple, dans les conteneurs.

pcre2 repassé à la version 10.40

Le paquetage pcre2, qui fournit la bibliothèque Perl Compatible Regular Expressions v2, a été mis à jour à la version 10.40.

Le compilateur GCC mis à jour est désormais disponible pour RHEL 9.1

Le compilateur GCC du système, version 11.2.1, a été mis à jour pour inclure de nombreuses corrections de bogues et améliorations disponibles dans le GCC en amont.

Nouveau jeu d'outils GCC 12

GCC Toolset 12 est un ensemble d'outils de compilation qui fournit des versions récentes d'outils de développement. Il est disponible en tant que flux d'application sous la forme d'une collection de logiciels dans le dépôt AppStream.

GCC Toolset 12 : Annobin rebasé à la version 10.76

Dans GCC Toolset 12, le paquetage Annobin a été mis à jour à la version 10.76.

GCC Toolset 12 : binutils rebasé à la version 2.38

Dans GCC Toolset 12, le paquet binutils a été mis à jour à la version 2.38.

GCC 12 et les versions ultérieures prennent en charge _FORTIFY_SOURCE niveau 3

Avec cette amélioration, les utilisateurs peuvent construire des applications avec -D_FORTIFY_SOURCE=3 dans la ligne de commande du compilateur lorsqu'ils construisent avec la version 12 ou ultérieure de GCC. _FORTIFY_SOURCE niveau 3 améliore la couverture de la fortification du code source, améliorant ainsi la sécurité des applications construites avec -D_FORTIFY_SOURCE=3 dans la ligne de commande du compilateur. Cette fonctionnalité est prise en charge dans les versions 12 et ultérieures de GCC et dans tous les Clang de RHEL 9 avec l'intégration __builtin_dynamic_object_size.

L'option DNS stub resolver supporte désormais l'option no-aaaa

Avec cette amélioration, glibc reconnaît désormais l'option no-aaaa stub resolver dans /etc/resolv.conf et la variable d'environnement RES_OPTIONS. Lorsque cette option est active, aucune requête AAAA n'est envoyée sur le réseau. Les administrateurs système peuvent désactiver les recherches DNS AAAA à des fins de diagnostic, par exemple pour s'assurer que les recherches superflues sur les réseaux exclusivement IPv4 ne contribuent pas aux problèmes DNS.

Ajout de la prise en charge de la série IBM Z z16

La prise en charge du jeu d'instructions s390 est désormais disponible sur la plate-forme IBM z16. IBM z16 fournit deux capacités matérielles supplémentaires dans glibc, à savoir HWCAP_S390_VXRS_PDE2 et HWCAP_S390_NNPA. Par conséquent, les applications peuvent désormais utiliser ces capacités pour fournir des bibliothèques et des fonctions optimisées.

Les applications peuvent utiliser les caractéristiques de la séquence redémarrable par l'intermédiaire des nouvelles interfaces glibc

Pour accélérer la fonction sched_getcpu (en particulier sur aarch64), il est nécessaire d'utiliser la fonction noyau de séquences redémarrables (rseq) par défaut dans glibc. Pour permettre aux applications d'utiliser en permanence la zone rseq partagée, glibc fournit maintenant les symboles __rseq_offset, __rseq_size et __rseq_flags qui ont été ajoutés pour la première fois dans la version amont glibc 2.35. Grâce à cette amélioration, les performances de la fonction sched_getcpu sont accrues et les applications peuvent désormais utiliser les caractéristiques de la séquence redémarrable par l'intermédiaire des nouvelles interfaces glibc.

GCC Toolset 12 : GDB repassé à la version 11.2

Dans GCC Toolset 12, le paquetage GDB a été mis à jour à la version 11.2.

GDB supporte les instructions Power 10 PLT

GDB prend désormais en charge les instructions PLT Power 10. Grâce à cette mise à jour, les utilisateurs peuvent accéder aux fonctions de la bibliothèque partagée et inspecter les traces de la pile à l'aide de la version 10.2-10 de GDB et des versions ultérieures.

Le site dyninst est passé à la version 12.1

Le paquetage dyninst a été rebasé à la version 12.1. Les corrections de bogues et améliorations notables sont les suivantes :

Un nouveau jeu de fichiers /etc/profile.d/debuginfod.*

Ajout d'un nouveau jeu de fichiers pour l'activation des services de débogage organisationnel. Pour obtenir une activation du client debuginfod à l'échelle du système, vous devez ajouter l'URL au fichier /etc/debuginfod/FOO.urls.

Rust Toolset repassé à la version 1.62.1

Rust Toolset a été mis à jour à la version 1.62.1. Les changements notables sont les suivants :

Le jeu d'outils LLVM passe à la version 14.0.6

LLVM Toolset a été rebasé à la version 14.0.6. Les changements notables sont les suivants :

Go Toolset passe à la version 1.18.2

Go Toolset est passé à la version 1.18.2.

Un nouveau flux de modules : maven:3.8

RHEL 9.1 introduit Maven 3.8 en tant que nouveau flux de modules.

la version 7.0 de .NET est disponible

Red Hat Enterprise Linux 9.1 est distribué avec .NET version 7.0. Les améliorations notables sont les suivantes :

SSSD prend désormais en charge la mise en cache de la mémoire pour les demandes de SID

Avec cette amélioration, SSSD prend désormais en charge la mise en cache de la mémoire pour les requêtes SID, c'est-à-dire les recherches de GID et d'UID par SID et vice versa. La mise en cache de la mémoire permet d'améliorer les performances, par exemple, lors de la copie de grandes quantités de fichiers vers ou depuis un serveur Samba.

Les modules Ansible ipaservicedelegationtarget et ipaservicedelegationrule sont désormais disponibles

Vous pouvez désormais utiliser les modules ipaservicedelegationtarget et ipaservicedelegationrule ansible-freeipa pour, par exemple, configurer un client de console web afin de permettre à un utilisateur de gestion d'identité (IdM) qui s'est authentifié avec une carte à puce d'effectuer les opérations suivantes :

Support SSSD pour PKINIT anonyme pour FAST

Grâce à cette amélioration, SSSD prend désormais en charge la PKINIT anonyme pour l'authentification flexible via un tunnel sécurisé (FAST), également appelée blindage Kerberos dans Active Directory. Jusqu'à présent, pour utiliser FAST, un keytab Kerberos était nécessaire pour demander les informations d'identification requises. Vous pouvez désormais utiliser PKINIT anonyme pour créer ce cache d'informations d'identification afin d'établir la session FAST.

L'IdM prend désormais en charge les numéros de série aléatoires

Avec cette mise à jour, Identity Management (IdM) inclut désormais dogtagpki 11.2.0, qui vous permet d'utiliser Random Serial Numbers version 3 (RSNv3). Vous pouvez activer RSNv3 en utilisant l'option --random-serial-numbers lors de l'exécution de ipa-server-install ou ipa-ca-install. Lorsque RSNv3 est activé, IdM génère des numéros de série entièrement aléatoires pour les certificats et les demandes dans PKI sans gestion de plage. En utilisant RSNv3, vous pouvez éviter la gestion des plages dans les grandes installations IdM et prévenir les collisions communes lors de la réinstallation d'IdM.

IdM permet désormais de limiter le nombre de liaisons LDAP autorisées après l'expiration du mot de passe d'un utilisateur

Cette amélioration permet de définir le nombre de liaisons LDAP autorisées lorsque le mot de passe d'un utilisateur Identity Management (IdM) a expiré :

Nouveaux rôles ipasmartcard_server et ipasmartcard_client

Avec cette mise à jour, le paquet ansible-freeipa fournit des rôles Ansible pour configurer les serveurs et les clients de gestion des identités (IdM) pour l'authentification par carte à puce. Les rôles ipasmartcard_server et ipasmartcard_client remplacent les scripts ipa-advise pour automatiser et simplifier l'intégration. Le même inventaire et le même schéma de dénomination sont utilisés que dans les autres rôles ansible-freeipa.

IdM prend désormais en charge la configuration d'AD Trust avec Windows Server 2022

Grâce à cette amélioration, vous pouvez établir une confiance inter-forêts entre les domaines Identity Management (IdM) et les forêts Active Directory qui utilisent des contrôleurs de domaine fonctionnant sous Windows Server 2022.

Les messages de débogage de ipa-dnskeysyncd et ipa-ods-exporter ne sont plus enregistrés dans /var/log/messages par défaut

Auparavant, ipa-dnskeysyncd, le service responsable de la synchronisation entre LDAP et OpenDNSSEC, et ipa-ods-exporter, le service d'exportation OpenDNSSEC de Identity Management (IdM), enregistraient par défaut tous les messages de débogage sur /var/log/messages. Par conséquent, les fichiers journaux augmentaient considérablement. Avec cette amélioration, vous pouvez configurer le niveau de journalisation en définissant debug=True dans le fichier /etc/ipa/dns.conf. Pour plus d'informations, consultez default.conf(5), la page de manuel du fichier de configuration IdM.

samba repassé à la version 4.16.1

Les paquets samba ont été mis à jour vers la version amont 4.16.1, qui apporte des corrections de bogues et des améliorations par rapport à la version précédente :

SSSD prend désormais en charge l'intégration directe avec Windows Server 2022

Grâce à cette amélioration, vous pouvez utiliser SSSD pour intégrer directement votre système RHEL aux forêts Active Directory qui utilisent des contrôleurs de domaine exécutant Windows Server 2022.

Amélioration des performances multithread de SSSD

Auparavant, SSSD sérialisait les requêtes parallèles provenant d'applications multithread, telles que Red Hat Directory Server et Identity Management. Cette mise à jour corrige toutes les bibliothèques client SSSD, telles que nss et pam, afin qu'elles ne sérialisent pas les requêtes, permettant ainsi aux requêtes provenant de plusieurs threads d'être exécutées en parallèle pour de meilleures performances. Pour activer le comportement précédent de la sérialisation, définissez la variable d'environnement SSS_LOCKFREE sur NO.

Directory Server permet désormais d'annuler la tâche du plug-in Auto Membership.

Auparavant, la tâche du plug-in Auto Membership pouvait générer une utilisation élevée du CPU sur le serveur si Directory Server avait une configuration complexe (grands groupes, règles complexes et interaction avec d'autres plugins). Avec cette amélioration, vous pouvez annuler la tâche du plug-in Auto Membership. Par conséquent, les problèmes de performance ne se produisent plus.

Directory Server prend désormais en charge les opérations de suppression récursive lors de l'utilisation de ldapdelete

Avec cette amélioration, Directory Server prend désormais en charge le contrôle OpenLDAP Tree Delete Control [1.2.840.113556.1.4.805]. Par conséquent, vous pouvez utiliser l'utilitaire ldapdelete pour supprimer de manière récursive les sous-entrées d'une entrée parentale.

Vous pouvez désormais définir des options de réplication de base lors de l'installation de Directory Server

Avec cette amélioration, vous pouvez configurer les options de réplication de base comme les identifiants d'authentification et le découpage du changelog pendant l'installation d'une instance à l'aide d'un fichier .inf.

Directory Server prend désormais en charge la création d'instances par un utilisateur non root

Auparavant, les utilisateurs non root ne pouvaient pas créer d'instances de Directory Server. Avec cette amélioration, un utilisateur non root peut utiliser la sous-commande dscreate ds-root pour configurer un environnement dans lequel les commandes dscreate,dsctl,dsconf sont utilisées comme d'habitude pour créer et administrer des instances de Directory Server.

pki les paquets ont été renommés en idm-pki

Les paquetages pki suivants sont maintenant renommés en idm-pki afin de mieux distinguer les paquetages IDM de ceux du Système de certification Red Hat :

Wayland est maintenant activé avec les GPU Matrox

La session de bureau active désormais le back-end Wayland avec les GPU Matrox.

les GPU Intel Core de 12e génération sont désormais pris en charge

Cette version ajoute la prise en charge de plusieurs GPU intégrés pour les CPU Intel Core de la 12ème génération. Cela inclut les GPU intégrés Intel UHD Graphics et Intel Xe que l'on trouve avec les modèles de CPU suivants :

Prise en charge des nouveaux GPU AMD

Cette version ajoute la prise en charge de plusieurs GPU de la série AMD Radeon RX 6000 et des graphiques intégrés des CPU de la série AMD Ryzen 6000.

La page de progression des mises à jour dans la console web propose désormais une option de redémarrage automatique

La page de progression des mises à jour comporte désormais un interrupteur Reboot after completion. Celui-ci redémarre automatiquement le système après l'installation des mises à jour.

Le rôle de système network RHEL prend en charge la configuration du réseau à l'aide de l'API nmstate

Avec cette mise à jour, le rôle de système network RHEL prend en charge la configuration du réseau via l'API nmstate. Les utilisateurs peuvent désormais appliquer directement la configuration de l'état du réseau requis à une interface réseau au lieu de créer des profils de connexion. Cette fonctionnalité permet également la configuration partielle d'un réseau. Il en résulte les avantages suivants :

Les utilisateurs peuvent créer des connexions avec la capacité IPoIB en utilisant le rôle de système RHEL network

Le type de connexion infiniband du rôle de système RHEL network prend désormais en charge le protocole Internet sur Infiniband (IPoIB). Pour activer cette fonctionnalité, définissez une valeur à l'option p_key de la variable infiniband. Notez que si vous spécifiez p_key, l'option interface_name de la variable network_connections ne doit pas être définie. L'implémentation précédente du rôle de système RHEL network ne validait pas correctement la valeur p_key et l'option interface_name pour le type de connexion infiniband. Par conséquent, la fonctionnalité IPoIB n'a jamais fonctionné auparavant. Pour plus d'informations, voir le fichier README dans le répertoire /usr/share/doc/rhel-system-roles/network/.

Le rôle de système RHEL de cluster HA prend désormais en charge la clôture SBD et la configuration des paramètres Corosync

Le rôle de système de cluster HA prend désormais en charge les fonctionnalités suivantes :

Le rôle network RHEL configure désormais les paramètres réseau pour les règles de routage

Auparavant, vous pouviez acheminer le paquet en fonction du champ de l'adresse de destination dans le paquet, mais vous ne pouviez pas définir le routage de la source et d'autres règles de routage de la politique. Avec cette amélioration, le rôle de network RHEL prend en charge les règles de routage afin que les utilisateurs puissent contrôler la transmission des paquets ou la sélection des itinéraires.

La nouvelle configuration de previous:replaced permet au rôle du système firewall de réinitialiser les paramètres du pare-feu à leur valeur par défaut

Les administrateurs système qui gèrent différents ensembles de machines, où chaque machine a des paramètres de pare-feu préexistants différents, peuvent désormais utiliser la configuration previous: replaced dans le rôle firewall pour s'assurer que toutes les machines ont les mêmes paramètres de configuration de pare-feu. La configuration previous: replaced peut effacer tous les paramètres de pare-feu existants et les remplacer par des paramètres cohérents.

Nouvelle option dans le rôle de système postfix RHEL pour écraser la configuration précédente

Si vous gérez un groupe de systèmes dont les configurations postfix sont incohérentes, vous voudrez peut-être rendre la configuration cohérente sur chacun d'entre eux. Avec cette amélioration, vous pouvez spécifier l'option previous: replaced dans le dictionnaire postfix_conf pour supprimer toute configuration existante et appliquer la configuration souhaitée sur une installation postfix propre. Ainsi, vous pouvez effacer toute configuration existante de postfix et garantir la cohérence sur tous les systèmes gérés.

Amélioration de microsoft.sql.server RHEL system role

Les nouvelles variables suivantes sont désormais disponibles pour le rôle de système microsoft.sql.server RHEL :

Le rôle de système RHEL logging prend en charge les options startmsg.regex et endmsg.regex dans les entrées de fichiers

Grâce à cette amélioration, vous pouvez désormais filtrer les messages de journalisation provenant de fichiers en utilisant des expressions régulières. Les options startmsg_regex et endmsg_regex sont désormais incluses dans l'entrée des fichiers. L'option startmsg_regex représente l'expression régulière qui correspond au début d'un message, et l'option endmsg_regex représente l'expression régulière qui correspond à la dernière partie d'un message. Par conséquent, vous pouvez désormais filtrer les messages en fonction de propriétés telles que la date et l'heure, la priorité et la gravité.

Le rôle système sshd RHEL vérifie la directive include pour le répertoire de dépôt

Le rôle système sshd RHEL sur RHEL 9 ne gère qu'un fichier dans le répertoire de dépôt, mais ne vérifiait pas auparavant que le répertoire était inclus dans le fichier principal sshd_config. Avec cette mise à jour, le rôle vérifie que sshd_config contient la directive include pour le répertoire de dépôt. Par conséquent, le rôle applique de manière plus fiable la configuration fournie.

Le rôle de système sshd RHEL peut être géré par l'intermédiaire de /etc/ssh/sshd_config

Le rôle de système RHEL sshd appliqué à un nœud géré par RHEL 9 place la configuration du SSHD dans un répertoire de dépôt (/etc/ssh/sshd_config.d/00-ansible_system_role.conf par défaut). Auparavant, toute modification apportée au fichier /etc/ssh/sshd_config écrasait les valeurs par défaut de 00-ansible_system_role.conf. Avec cette mise à jour, vous pouvez gérer le SSHD en utilisant /etc/ssh/sshd_config au lieu de 00-ansible_system_role.conf tout en préservant les valeurs par défaut du système dans 00-ansible_system_role.conf.

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

Avec cette mise à jour, le rôle metrics 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 metrics 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 storage RHEL prend désormais en charge la gestion des membres du pool

Le rôle de système RHEL storage peut désormais ajouter ou supprimer des disques de pools LVM existants sans supprimer le pool au préalable. Pour augmenter la capacité du pool, le rôle système storage RHEL peut ajouter de nouveaux disques au pool et libérer les disques actuellement alloués au pool pour une autre utilisation.

La prise en charge des volumes à provisionnement fin est désormais disponible dans le rôle de système RHEL storage

Le rôle système storage RHEL permet désormais de créer et de gérer des volumes logiques LVM (LV) finement provisionnés. Les LV à provisionnement fin sont alloués au fur et à mesure de leur écriture, ce qui offre une plus grande souplesse lors de la création de volumes, car le stockage physique fourni pour les LV à provisionnement fin peut être augmenté ultérieurement en fonction des besoins. Le provisionnement fin de LVM permet également de créer des instantanés plus efficaces, car les blocs de données communs à un LV fin et à n'importe lequel de ses instantanés sont partagés.

Une meilleure prise en charge des volumes mis en cache est disponible sur le site storage RHEL System Role

Le rôle de système RHEL storage permet désormais d'attacher un cache aux volumes logiques LVM existants. 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. Cela améliore la prise en charge précédemment ajoutée pour la création de volumes mis en cache en permettant d'ajouter (attacher) un cache à un volume existant, qui n'était pas mis en cache auparavant.

Le rôle de système RHEL logging prend désormais en charge les options template, severity et facility

Le rôle de système RHEL logging comporte désormais de nouvelles options utiles severity et facility pour les entrées de fichiers, ainsi qu'une nouvelle option template pour les sorties de fichiers et de transferts. Utilisez l'option template pour spécifier le format d'heure traditionnel à l'aide du paramètre traditional, le format du protocole syslog 23 à l'aide du paramètre syslog, et le format de style moderne à l'aide du paramètre modern. Par conséquent, vous pouvez maintenant utiliser le rôle logging pour filtrer par gravité et facilité ainsi que pour spécifier le format de sortie par modèle.

Les rôles système RHEL sont désormais également disponibles dans les playbooks dont la collecte des faits est désactivée

La collecte de faits Ansible peut être désactivée dans votre environnement pour des raisons de performances ou autres. Auparavant, il n'était pas possible d'utiliser les rôles système RHEL dans de telles configurations. Avec cette mise à jour, le système détecte le paramètre ANSIBLE_GATHERING=explicit dans votre configuration et le paramètre gather_facts: false dans vos playbooks, et utilise le module setup: pour collecter uniquement les faits requis par le rôle donné, s'ils ne sont pas disponibles dans le cache de faits.

Le rôle de stockage a maintenant moins de verbosité par défaut

La sortie des rôles de stockage est désormais moins verbeuse par défaut. Avec cette mise à jour, les utilisateurs peuvent augmenter la verbosité de la sortie du rôle de stockage pour ne produire qu'une sortie de débogage s'ils utilisent le niveau de verbosité Ansible 1 ou plus.

Le rôle de système RHEL firewall ne nécessite pas le paramètre state lors de la configuration de masquerade ou de icmp_block_inversion

Lors de la configuration des zones de pare-feu personnalisées, les variables masquerade et icmp_block_inversion sont des paramètres booléens. Une valeur de true implique state: present et une valeur de false implique state: absent. Par conséquent, le paramètre state n'est pas nécessaire lors de la configuration de masquerade ou icmp_block_inversion.

Vous pouvez désormais ajouter, mettre à jour ou supprimer des services à l'aide des états absent et present dans le rôle de système RHEL firewall

Grâce à cette amélioration, vous pouvez utiliser l'état present pour ajouter des ports, des modules, des protocoles, des services et des adresses de destination, ou utiliser l'état absent pour les supprimer. Notez que pour utiliser les états absent et present dans le rôle de système RHEL firewall, définissez l'option permanent sur true. Avec l'option permanent définie sur true, les paramètres d'état s'appliquent jusqu'à ce qu'ils soient modifiés et ne sont pas affectés par les rechargements de rôle.

Le rôle système firewall peut ajouter ou supprimer une interface à la zone en utilisant l'ID de périphérique PCI

En utilisant l'ID du périphérique PCI, le rôle système firewall peut désormais attribuer ou supprimer une interface réseau d'une zone. Auparavant, si seul l'ID du périphérique PCI était connu au lieu du nom de l'interface, les utilisateurs devaient d'abord identifier le nom de l'interface correspondante pour utiliser le rôle système firewall. Avec cette mise à jour, le rôle système firewall peut désormais utiliser l'ID du périphérique PCI pour gérer une interface réseau dans une zone.

Le rôle de système firewall RHEL peut fournir des faits Ansible

Grâce à cette amélioration, vous pouvez désormais rassembler les faits Ansible du rôle de système RHEL firewall pour tous vos systèmes en incluant la variable firewall: dans le playbook sans aucun argument. Pour recueillir une version plus détaillée des données Ansible, utilisez l'argument detailed: true, par exemple :

Ajout de la définition de seuser et selevel au rôle de système RHEL selinux

Il est parfois nécessaire de définir les paramètres seuser et selevel lors de la définition des mappages de systèmes de fichiers contextuels SELinux. Avec cette mise à jour, vous pouvez utiliser les arguments facultatifs seuser et selevel dans selinux_fcontext pour spécifier l'utilisateur et le niveau SELinux dans les mappages du système de fichiers du contexte SELinux.

Nouvelle variable cockpit System Role pour définir un port d'écoute personnalisé

Le rôle système cockpit introduit la variable cockpit_port qui vous permet de définir un port d'écoute personnalisé autre que le port par défaut 9090. Notez que si vous décidez de définir un port d'écoute personnalisé, vous devrez également ajuster votre politique SELinux pour permettre à la console web d'écouter sur ce port.

Le rôle metrics peut exporter les données de performance de postfix

Vous pouvez désormais utiliser la nouvelle variable booléenne metrics_from_postfix dans le rôle metrics pour l'enregistrement et l'analyse détaillée des performances. Avec cette amélioration, la définition de la variable active l'agent de mesure pmdapostfix sur le système, ce qui permet d'obtenir des statistiques sur postfix.

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 nbde-client RHEL 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 RHEL nbde_client modifiait l'adresse IP du système. Avec cette mise à jour, les systèmes avec des adresses IP statiques sont pris en charge par le rôle nbde_client et leurs adresses IP ne changent pas après un redémarrage.

La console web RHEL propose désormais RHEL comme option pour le flux de travail de Download an OS VM

Avec cette amélioration, la console web RHEL prend désormais en charge l'installation de machines virtuelles (VM) RHEL à l'aide du flux de travail par défaut Download an OS. Vous pouvez ainsi télécharger et installer le système d'exploitation RHEL en tant que machine virtuelle directement dans la console web.

Amélioration de la conformité architecturale de KVM

Avec cette mise à jour, la conformité architecturale de l'hyperviseur KVM a été améliorée et rendue plus stricte. L'hyperviseur est ainsi mieux préparé à faire face aux changements futurs des systèmes d'exploitation basés sur Linux et d'autres systèmes.

ap-check est désormais disponible dans RHEL 9

L'outil mdevctl est désormais accompagné d'un nouvel utilitaire de support ap-check. Vous pouvez utiliser mdevctl pour configurer de manière persistante les adaptateurs cryptographiques et les domaines autorisés pour une utilisation pass-through dans les machines virtuelles, ainsi que les périphériques matrix et vfio-ap. Avec mdevctl, vous n'avez pas besoin de reconfigurer ces adaptateurs, domaines et périphériques après chaque IPL. En outre, mdevctl empêche le distributeur d'inventer d'autres façons de les reconfigurer.

open-vm-tools repassé à la version 12.0.5

Les paquets open-vm-tools ont été mis à jour vers la version 12.0.5, qui introduit un certain nombre de corrections de bogues et de nouvelles fonctionnalités. En particulier, la prise en charge de l'outil Salt Minion a été ajoutée pour être gérée par des variables du système d'exploitation invité.

Les machines virtuelles sélectionnées sur IBM Z peuvent désormais démarrer avec des lignes de commande du noyau de plus de 896 octets

Auparavant, le démarrage d'une machine virtuelle (VM) sur un hôte IBM Z RHEL 9 échouait toujours si la ligne de commande du noyau de la VM dépassait 896 octets. Avec cette mise à jour, l'émulateur QEMU peut gérer les lignes de commande du noyau de plus de 896 octets. Par conséquent, vous pouvez désormais utiliser le démarrage direct du noyau de QEMU pour les machines virtuelles dont les lignes de commande du noyau sont très longues, si le noyau de la machine virtuelle le prend en charge. Plus précisément, pour utiliser une ligne de commande de plus de 896 octets, la VM doit utiliser la version 5.16-rc1 du noyau Linux ou une version ultérieure.

La fonction Secure Execution d'IBM Z prend désormais en charge l'attestation à distance

La fonction Secure Execution sur l'architecture IBM Z prend désormais en charge l'attestation à distance. L'utilitaire pvattest peut créer une demande d'attestation à distance pour vérifier l'intégrité d'un invité pour lequel la fonction Secure Execution est activée.

Préallocation de la mémoire de la VM à l'aide de plusieurs threads

Vous pouvez désormais définir plusieurs threads de CPU pour l'allocation de la mémoire de la machine virtuelle (VM) dans la configuration XML du domaine, par exemple de la manière suivante :

Les invités RHEL 9 prennent désormais en charge SEV-SNP

Sur les machines virtuelles (VM) qui utilisent RHEL 9 comme système d'exploitation invité, vous pouvez désormais utiliser AMD Secure Encrypted Virtualization (SEV) avec la fonction Secure Nested Paging (SNP). Entre autres avantages, SNP améliore SEV en améliorant la protection de l'intégrité de la mémoire, ce qui permet de prévenir les attaques basées sur l'hyperviseur, telles que le rejeu de données ou le remappage de la mémoire. Notez que pour que SEV-SNP fonctionne sur une VM RHEL 9, l'hôte qui exécute la VM doit également prendre en charge SEV-SNP.

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.

Les paquets Container Tools ont été mis à jour

Les paquets Container Tools qui contiennent les outils Podman, Buildah, Skopeo, crun et runc sont maintenant disponibles. Cette mise à jour fournit une liste de corrections de bogues et d'améliorations par rapport à la version précédente.

GitLab Runner est maintenant disponible sur RHEL en utilisant Podman

A partir de GitLab Runner 15.1, vous pouvez utiliser Podman comme runtime de conteneur dans l'exécuteur Docker de GitLab Runner. Pour plus de détails, voir la note de version de GitLab.

Podman supporte désormais l'option --health-on-failure

Les commandes podman run et podman create prennent désormais en charge l'option --health-on-failure pour déterminer les actions à effectuer lorsque l'état d'un conteneur devient malsain.

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.

Nouveau paquet : catatonit dans le référentiel CRB

Un nouveau paquetage catatonit est maintenant disponible dans le dépôt CodeReady Linux Builder (CRB). Le paquet catatonit est utilisé comme programme d'initialisation minimal pour les conteneurs et peut être inclus dans l'image du conteneur d'application. Notez que les paquets inclus dans le dépôt CodeReady Linux Builder ne sont pas pris en charge.

Le programme d'installation n'installe plus les versions antérieures des paquets

Auparavant, le programme d'installation ne chargeait pas correctement le fichier de configuration DNF au cours du processus d'installation. En conséquence, le programme d'installation installait parfois des versions antérieures de certains paquets dans la transaction RPM.

L'installation d'Anaconda est réussie même si l'on modifie la configuration du réseau à l'étape 2

Auparavant, lors de l'utilisation de l'argument de démarrage rd.live.ram, Anaconda ne démontait pas un point de montage NFS utilisé dans initramfs pour récupérer l'image d'installation en mémoire. En conséquence, le processus d'installation pouvait ne plus répondre ou échouer avec une erreur de dépassement de délai si la configuration du réseau était modifiée à l'étape 2.

virt-who se connecte désormais correctement aux serveurs ESX en mode FIPS

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

Le DNF annule désormais correctement une transaction contenant un élément avec le type d'action Reason Change

Auparavant, l'exécution de la commande dnf history rollback sur une transaction contenant un élément avec le type d'action Reason Change échouait. Avec cette mise à jour, le problème a été corrigé et dnf history rollback fonctionne désormais comme prévu.

La commande vi dans ReaR n'entraîne plus de boucle infinie

Auparavant, le système de sauvetage ReaR ne contenait pas l'exécutable vi, mais seulement le script /bin/vi. Par conséquent, le script /bin/vi provoquait une boucle infinie lorsqu'il était invoqué. Avec cette mise à jour, le système de sauvetage ReaR contient l'exécutable vi /usr/libexec/vi , et l'exécution de la commande vi ne provoque plus de boucle infinie.

ReaR avec la méthode de sortie PXE n'échoue plus à stocker les fichiers de sortie dans l'emplacement rsync OUTPUT_URL

Auparavant, la gestion de la variable OUTPUT_URL avec les options OUTPUT=PXE et BACKUP=RSYNC a été supprimée. Par conséquent, lors de l'utilisation d'un emplacement rsync pour OUTPUT_URL, ReaR ne parvenait pas à copier les fichiers initrd et kernel à cet emplacement, bien qu'il les téléchargeait à l'emplacement spécifié par BACKUP_URL. Avec cette mise à jour, le comportement de RHEL 8.4 et des versions antérieures est rétabli. ReaR crée les fichiers requis à la destination OUTPUT_URL désignée à l'aide de rsync.

ReaR n'affiche plus de message d'erreur s'il ne met pas à jour l'UUID dans le fichier /etc/fstab

Auparavant, ReaR n'affichait pas de message d'erreur pendant la restauration lorsqu'il ne parvenait pas à mettre à jour l'identifiant universel unique (UUID) dans /etc/fstab pour qu'il corresponde à l'UUID de la partition nouvellement créée dans le cas où les UUID étaient différents. Cela aurait pu se produire si l'image de secours n'était pas synchronisée avec la sauvegarde. Avec cette mise à jour, un message d'erreur apparaît pendant la récupération si les fichiers du système de base restaurés ne correspondent pas au système recréé.

ReaR prend désormais en charge la restauration d'un système à l'aide de NetBackup version 9

Auparavant, la restauration d'un système à l'aide de la méthode NetBackup (NBU) avec NetBackup version 9 ou ultérieure échouait en raison de l'absence de bibliothèques et d'autres fichiers. Avec cette mise à jour, la variable NBU_LD_LIBRARY_PATH contient les chemins d'accès aux bibliothèques nécessaires et le système de secours intègre désormais les fichiers requis, et ReaR peut utiliser la méthode NetBackup.

ReaR n'affiche plus de faux message d'erreur concernant des cibles de liens symboliques manquantes

Auparavant, ReaR affichait des messages d'erreur incorrects concernant des cibles de liens symboliques manquantes pour les liens symboliques build et source sous /usr/lib/modules/ lors de la création de l'image de secours. Cette situation était inoffensive et vous pouviez ignorer le message d'erreur. Avec cette mise à jour, ReaR ne signale pas de faux message d'erreur concernant des cibles de liens symboliques manquantes dans cette situation.

L'opération cmx sans paramètre ne fait plus planter le client CIM

L'opération cmx appelle une méthode et renvoie du XML, un paramètre spécifie le nom de la méthode appelée. Auparavant, la ligne de commande sblim-wbemcli Common Information Model (CIM) Client se bloquait lors de l'exécution de l'opération cmx sans paramètre supplémentaire. Avec cette mise à jour, l'opération cmx nécessite le paramètre qui définit le nom de la méthode appelée. L'invocation de l'opération cmx sans ce paramètre génère un message d'erreur et le client CIM ne se bloque plus.

free la commande utilise une nouvelle méthode de calcul de la mémoire utilisée

Auparavant, le calcul de la mémoire utilisée dans l'utilitaire free soustrayait l'espace libre, l'espace cache et l'espace tampon de la mémoire totale. Par conséquent, une divergence survenait lorsque vous compariez la valeur de la mémoire utilisée avec les résultats d'un autre outil, car l'utilitaire free ne calculait pas la mémoire partagée. Avec cette mise à jour, la commande free utilise une nouvelle méthode de calcul qui fournit un état clair de la mémoire libre et prend en compte le cache non récupérable. La mémoire utilisée correspond désormais à toute mémoire qui n'est pas disponible et inclut également les objets tmpfs qui se trouvent dans la mémoire virtuelle.

Unbound ne valide plus les signatures RSA basées sur SHA-1

Auparavant, OpenSSL ne validait pas les signatures RSA basées sur SHA-1 dans la politique cryptographique du système DEFAULT. Par conséquent, lorsque Unbound essayait de valider ces signatures, l'erreur d'OpenSSL entraînait l'échec de la résolution. Avec cette mise à jour, Unbound désactive 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), ce qui résout la question. Notez que cela rend le résultat peu sûr dans le cadre de toutes les politiques cryptographiques à l'échelle du système.

La génération de clés OpenSSH utilise des interfaces compatibles FIPS

La bibliothèque cryptographique OpenSSL, utilisée par OpenSSH, propose deux interfaces : l'ancienne et la nouvelle. Auparavant, OpenSSH utilisait l'ancienne interface pour la génération de clés, qui n'était pas conforme aux exigences de la Federal Information Processing Standards (FIPS). Avec cette mise à jour, l'utilitaire ssh-keygen utilise l'API conforme aux normes FIPS au lieu de l'API de bas niveau incompatible avec les normes FIPS. Par conséquent, la génération de clés OpenSSH est conforme aux normes FIPS.

La cryptographie non approuvée par le FIPS ne fonctionne plus dans OpenSSL en mode FIPS

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

La spécification de courbes arbitraires est supprimée d'OpenSSL

Auparavant, les vérifications de la sécurité des paramètres explicites des courbes étaient incomplètes. Par conséquent, des courbes elliptiques arbitraires avec des valeurs p suffisamment grandes fonctionnaient dans RHEL. Avec cette mise à jour, les contrôles vérifient désormais que les paramètres explicites de la courbe correspondent à l'une des courbes bien connues prises en charge. Par conséquent, l'option permettant de spécifier des courbes arbitraires par l'utilisation de paramètres de courbe explicites a été supprimée d'OpenSSL. Les fichiers de paramètres, les clés privées, les clés publiques et les certificats qui spécifient des courbes explicites arbitraires ne fonctionnent plus dans OpenSSL. L'utilisation de paramètres de courbes explicites pour spécifier l'une des courbes bien connues et prises en charge telles que P-224, P-256, P-384, P-521 et secp256k1 reste prise en charge en mode non-FIPS.

OpenSSL req utilise AES-256-CBC pour le cryptage des clés privées

Auparavant, l'outil OpenSSL req chiffrait les fichiers de clés privées en utilisant l'algorithme 3DES. L'algorithme 3DES n'étant pas sûr et n'étant pas autorisé par la norme FIPS 140 actuelle pour les modules cryptographiques, req génère désormais des fichiers de clés privées chiffrés à l'aide de l'algorithme AES-256-CBC. Le format général du fichier PKCS#8 reste inchangé.

OpenSSL n'échoue plus à se connecter lorsque FFDHE est utilisé

Auparavant, les connexions TLS qui utilisent le mécanisme d'échange de clés éphémères FFDHE (Diffie-Hellman à champ fini) échouaient parfois lors du traitement des partages de clés FFDHE provenant d'un client. Cela était dû à des vérifications trop restrictives dans OpenSSL. En conséquence, le serveur OpenSSL interrompait la connexion avec une alerte internal_error. Avec cette mise à jour, OpenSSL accepte des parts de clés plus petites mais toujours conformes. Par conséquent, les connexions entre OpenSSL et d'autres implémentations ne sont plus interrompues de manière aléatoire lors de l'utilisation d'échanges de clés FFDHE.

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.

Permissions pour insights-client ajoutées à la politique SELinux

Le nouveau service insights-client nécessite des autorisations qui n'existaient pas dans les versions précédentes de selinux-policy. En conséquence, certains composants de insights-client ne fonctionnaient pas correctement et signalaient des messages d'erreur AVC (Access Vector Cache). Cette mise à jour ajoute de nouvelles autorisations à la politique SELinux. En conséquence, insights-client fonctionne correctement sans signaler d'erreurs AVC.

Les utilisateurs de SELinux staff_u ne peuvent plus basculer par erreur vers la fonction unconfined_r

Auparavant, lorsque le booléen secure_mode était activé, les utilisateurs de staff_u pouvaient passer au rôle unconfined_r, ce qui n'était pas le comportement attendu. En conséquence, les utilisateurs de staff_u pouvaient effectuer des opérations privilégiées affectant la sécurité du système. Avec cette mise à jour, la politique SELinux a été corrigée et les utilisateurs de staff_u ne peuvent plus passer à tort à unconfined_r.

OpenSCAP ne produit plus d'erreurs incorrectes lors de la vérification de la mémoire disponible

Auparavant, lors de l'évaluation de certaines règles XCCDF, OpenSCAP affichait de manière incorrecte le message d'erreur Failed to check available memory et produisait des résultats d'analyse non valides. Par exemple, cela se produisait pour les règles accounts_user_dot_no_world_writable_programs, accounts_user_dot_group_ownership et accounts_users_home_files_permissions. Avec cette mise à jour, le bogue dans la gestion des erreurs est corrigé et le message d'erreur n'apparaît que pour les échecs réels.

fagenrules --load fonctionne désormais correctement

Auparavant, le service fapolicyd ne gérait pas correctement le signal de raccrochage (SIGHUP). Par conséquent, fapolicyd se terminait après avoir reçu le signal SIGHUP et la commande fagenrules --load ne fonctionnait pas correctement. Cette mise à jour contient un correctif pour ce problème. Par conséquent, fagenrules --load fonctionne désormais correctement et les mises à jour des règles ne nécessitent plus le redémarrage manuel de fapolicyd.

Une instance conserve désormais l'adresse IP principale même après avoir démarré le service nm-cloud-setup dans Alibaba Cloud

Auparavant, après le lancement d'une instance dans Alibaba Cloud, le service nm-cloud-setup configurait l'adresse IP incorrecte comme adresse IP primaire en cas d'adresses IPv4 multiples. Par conséquent, cela affectait la sélection de l'adresse source IPv4 pour les connexions sortantes. Avec cette mise à jour, après avoir configuré manuellement les adresses IP secondaires, le paquet NetworkManager récupère l'adresse IP primaire à partir des métadonnées primary-ip-address et configure correctement les adresses IP primaires et secondaires.

L'utilitaire NetworkManager permet d'ordonner correctement les adresses IPv6 ajoutées manuellement

En général, l'ordre des adresses IPv6 affecte la priorité de la sélection de l'adresse source. Par exemple, lorsque vous établissez une connexion TCP sortante. Auparavant, la priorité relative des adresses IPv6 ajoutées par les méthodes manual, dhcpv6 et autoconf6 n'était pas correcte. Cette mise à jour corrige le problème et l'ordre de priorité reflète désormais la logique suivante : manual > dhcpv6 > autoconf6. En outre, l'ordre des adresses sous le paramètre ipv6.addresses a été inversé de sorte que l'adresse ajoutée en premier a la priorité la plus élevée.

Le marquage des prises de réseau fonctionne à nouveau

Certains contrôleurs cgroup v1 qui n'ont pas d'équivalent cgroup v2, tels que net_prio ou net_cls, interféraient auparavant avec le marquage de la prise cgroup v2 lorsqu'ils étaient montés avec d'autres contrôleurs cgroup v2 dans un environnement mixte cgroup v1/v2. Par conséquent, un environnement mixte cgroup v1/v2 utilisant le contrôleur net_prio ou net_cls v1 empêchait le marquage correct des sockets réseau avec cgroup v2. Cette mise à jour élimine cette limitation, ce qui permet d'utiliser le marquage des sockets réseau dans un environnement mixte cgroup v1/v2.

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

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

Les systèmes peuvent exécuter avec succès des opérations dynamiques sur les LPAR

Auparavant, les utilisateurs ne pouvaient 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 était remplie :

Aucun avertissement du noyau après avoir réglé la valeur du tampon circulaire de rx à max

Le noyau produisait un message d'avertissement Missing unregister, handled but fix driver lorsqu'une fonction interne attendant une entrée propre était appelée avec une structure réutilisée et déjà initialisée. Avec cette mise à jour, le problème a été corrigé en réinitialisant la structure avant de l'enregistrer à nouveau.

grubby transmet désormais les arguments aux futurs noyaux

Lors de l'installation d'une version plus récente du noyau, l'outil grubby ne transmettait pas les arguments de la ligne de commande du noyau de la version précédente. Par conséquent, le chargeur de démarrage GRUB ignorait les paramètres de l'utilisateur. Avec cette correction, les paramètres de l'utilisateur persistent maintenant après l'installation de la nouvelle version du noyau.

Les entrées de journal n'interrompent plus l'écriture du journal

Auparavant, dans le pilote VDO, pendant l'opération de suspension du device-mapper et après la reprise du fonctionnement du device, certains blocs de journal pouvaient encore être marqués comme étant en attente de certaines mises à jour de métadonnées avant de pouvoir être réutilisés, même si ces mises à jour avaient déjà été effectuées. Lorsqu'il y avait suffisamment d'entrées dans le journal pour que le journal puisse revenir au même bloc physique, celui-ci n'était pas disponible. Les écritures dans le journal s'arrêtaient, attendant que le bloc devienne disponible, ce qui ne se produisait jamais. Par conséquent, lorsque certaines opérations sur un périphérique VDO comprenaient un cycle de suspension ou de reprise, le périphérique se trouvait dans un état figé après certaines mises à jour du journal. Les mises à jour du journal avant cet état étaient imprévisibles car elles dépendaient des schémas d'allocation précédents au sein de la VDO, et des schémas d'écriture ou d'abandon entrants. Avec cette mise à jour, après le cycle de suspension ou de reprise de l'enregistrement des données, l'état de la structure de données interne est réinitialisé et les blocages ne se produisent plus.

L'ajout d'un périphérique de données ne déclenche plus d'échec d'assertion

Auparavant, lors de l'ajout de périphériques supplémentaires au cache, Stratis n'utilisait pas le cache immédiatement après l'initialisation. Par conséquent, le service stratisd renvoyait un message d'échec d'assertion chaque fois qu'un utilisateur tentait d'ajouter des périphériques de données supplémentaires à un pool. Avec cette correction, le cache est maintenant utilisé immédiatement après l'initialisation et aucun échec d'assertion ne se produit.

Résolution d'erreurs lors de l'ajout de nouveaux périphériques de données au pool crypté

Auparavant, lorsque l'utilisateur initialisait un pool chiffré avec des périphériques de données chiffrés, à l'aide d'une commande Clevis bind sur un serveur tang, spécifié avec l'option --trust-url, stratisd n'incluait pas la partie thumbprint de la configuration Clevis tang dans les structures de données internes. Par conséquent, un échec se produisait lors de la tentative d'ajout de nouveaux périphériques de données au pool. Avec cette mise à jour, les structures de données internes de stratisd incluent désormais la partie thumbprint de la configuration Clevis tang.

La connexion à des espaces de noms NVMe à partir d'initiateurs Broadcom sur des systèmes AMD EPYC ne nécessite plus de paramètres IOMMU autres que ceux par défaut

Par défaut, le noyau RHEL active l'IOMMU sur les plateformes basées sur AMD. Auparavant, le pilote lpfc n'utilisait pas les macros d'accesseur de la liste de dispersion. Par conséquent, certains serveurs équipés de processeurs AMD rencontraient des problèmes d'E/S NVMe, tels que des E/S échouant en raison de la non-concordance des longueurs de transfert.

pcs valide désormais la valeur de stonith-watchdog-timeout

Auparavant, il était possible de définir la propriété stonith-watchdog-timeout à une valeur incompatible avec la configuration du SBD. Cela pouvait entraîner une boucle de clôture ou faire en sorte que le cluster considère une action de clôture comme réussie même si l'action n'est pas terminée. Avec cette correction, pcs valide la valeur de stonith-watchdog-property lorsque vous la définissez, afin d'éviter une configuration incorrecte.

pcs reconnaît désormais l'option mode lors de la création d'un nouveau ticket Booth

Auparavant, lorsqu'un utilisateur spécifiait l'option mode lors de l'ajout d'un nouveau ticket de stand, pcs signalait l'erreur invalid booth ticket option 'mode'. Avec cette correction, vous pouvez maintenant spécifier l'option mode lors de la création d'un ticket de stand.

pcs fait désormais la distinction entre les ressources et les ressources en pierre

Auparavant, certaines commandes de pcs ne faisaient pas de distinction entre les ressources et les ressources stonith. Cela permettait aux utilisateurs d'utiliser les sous-commandes pcs resource pour les ressources stonith et d'utiliser les sous-commandes pcs stonith pour les ressources qui ne sont pas des ressources stonith. Cela pouvait entraîner une confusion chez les utilisateurs ou une mauvaise configuration des ressources. Avec cette mise à jour, pcs affiche un avertissement en cas de non concordance des types de ressources.

glibc restaure maintenant errno après le chargement d'un module NSS

Auparavant, l'implémentation de Name Service Switch (NSS) dans glibc définissait errno de manière incorrecte pendant l'énumération de la base de données à l'aide de fonctions telles que getpwent() si le dernier module NSS ne fournissait aucune donnée. Par conséquent, les applications utilisant ces fonctions d'énumération observaient des erreurs et échouaient. glibc rétablit désormais errno après le chargement d'un module NSS et, par conséquent, les applications utilisant ces fonctions n'échouent plus.

L'interface d'audit sauvegarde et restaure désormais le registre x8 et la totalité des registres NEON pour AArch64

Auparavant, un bogue dans l'implémentation de l'interface d'audit du chargeur dynamique faisait que l'état des registres sauvegardés sur AArch64 était incomplet par rapport à la norme d'appel de procédure. Ce bogue a été corrigé et l'interface d'audit sauvegarde et restaure désormais le registre x8 et toute la largeur des registres NEON pour AArch64. Les applications utilisant l'interface d'audit du chargeur dynamique peuvent désormais inspecter et influencer le registre x8 pour AArch64. Pour utiliser ce nouveau registre x8 et avoir accès à toute la largeur des registres NEON sur AArch64, les modules d'audit doivent être recompilés pour utiliser la nouvelle version de l'interface (LAV_CURRENT est 2).

La fonction strncpy optimisée pour POWER9 ne donne plus de résultats incorrects

Auparavant, la fonction strncpy de POWER9 n'utilisait pas le registre correct comme source des octets NUL pour le remplissage. Par conséquent, le tampon de sortie contenait un contenu de registre non initialisé à la place du remplissage NUL. Avec cette mise à jour, la fonction strncpy a été corrigée et la fin du tampon de sortie est maintenant correctement remplie d'octets NUL.

Valgrind override of glibc memmem function installé sur l'architecture IBMz15

Auparavant, une surcharge valgrind manquante de la fonction glibc memmem conduisait à des avertissements faussement positifs :

La sortie de ipa user-del --preserve user_login n'indique plus que l'utilisateur a été supprimé

Auparavant, si vous exécutiez la commande ipa user-del --preserve user_login pour préserver un compte d'utilisateur, le résultat renvoyait à tort le message Deleted user “user_login”. Avec cette mise à jour, la sortie renvoie désormais Preserved user “user_login”.

L'authentification des utilisateurs PKINIT fonctionne désormais correctement dans le scénario client Kerberos RHEL 9 - KDC Heimdal

Auparavant, l'authentification PKINIT d'un utilisateur IdM sur un client Kerberos RHEL 9 contre le centre de distribution Kerberos (KDC) Heimdal échouait. Cet échec était dû au fait que le client Kerberos ne prenait pas en charge le champ supportedCMSTypes requis dans le contexte de la dépréciation de l'algorithme SHA-1 dans RHEL 9.

Gestion des objets illisibles dans la liste des membres d'un groupe LDAP

Avant cette mise à jour, SSSD traitait de manière incohérente les objets illisibles dans la liste des membres d'un groupe LDAP, ce qui provoquait une erreur ou, dans certaines situations, les objets illisibles étaient ignorés.

L'enregistrement des abonnements avec des clés d'activation a été corrigé

Auparavant, vous ne pouviez pas enregistrer votre abonnement Red Hat dans Settings en utilisant des clés d'activation. Settings affichait l'erreur suivante après avoir appuyé sur Register:

X.org active désormais l'extension X11 SECURITY

Auparavant, le serveur d'affichage X.org ne fournissait pas l'extension X11 SECURITY. Par conséquent, les applications qui utilisaient cette extension se terminaient de manière inattendue.

Le GPU Matrox avec un écran VGA fonctionne désormais comme prévu

Avant cette version, votre écran n'affichait aucune sortie graphique si vous utilisiez la configuration système suivante :

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

Auparavant, lorsque vous attachiez 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 changeaient après avoir été transmis à la VM. Par conséquent, l'utilisation de la console web pour supprimer ces périphériques échouait en raison de la corrélation incorrecte des numéros de périphérique et de bus. Avec cette mise à jour, le problème a été corrigé et vous pouvez supprimer les périphériques hôtes USB à l'aide de la console web.

L'attachement de plusieurs périphériques hôtes à l'aide de la console web fonctionne désormais comme prévu

Auparavant, lorsque vous sélectionniez plusieurs périphériques à attacher à une machine virtuelle (VM) à l'aide de la console web, seul un périphérique était attaché et les autres étaient ignorés. Avec cette mise à jour, le problème a été corrigé et vous pouvez désormais attacher simultanément plusieurs périphériques hôtes à l'aide de la console web.

Le rôle network RHEL gère le paramètre ansible_managed dans les fichiers de configuration

Auparavant, le rôle Ansible n'était pas en mesure de fournir l'en-tête ansible_managed correct pour les fichiers de configuration gérés par le rôle network. En conséquence, les administrateurs système n'étaient pas certains des fichiers gérés par Ansible. Avec cette correction, les fichiers gérés par le rôle ont un en-tête ansible_managed correct, et les administrateurs système peuvent dire de manière fiable quels fichiers sont gérés par Ansible.

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.

La fonction IPRouteUtils.get_route_tables_mapping() accepte désormais toute séquence d'espaces blancs

Auparavant, l'analyseur de la base de données de la table de routage iproute2, telle que /etc/iproute2/rt_tables, affirmait que les entrées du fichier étaient de la forme 254 main et qu'un seul caractère d'espacement séparait l'identifiant numérique et le nom. Par conséquent, l'analyseur ne parvenait pas à mettre en cache toutes les correspondances entre le nom de la table de routage et l'identifiant de la table, ce qui empêchait l'utilisateur d'ajouter une route statique dans la table de routage en définissant le nom de la table de routage. Avec cette mise à jour, l'analyseur accepte toute séquence d'espaces blancs entre l'identifiant et le nom de la table. Par conséquent, comme l'analyseur met en cache toutes les correspondances entre le nom de la table d'itinéraires et l'identifiant de la table, les utilisateurs peuvent ajouter un itinéraire statique dans la table d'itinéraires en définissant le nom de la table d'itinéraires.

Le paramètre forward_port accepte désormais les options string et dict

Auparavant, dans le rôle firewall RHEL System, le paramètre forward_port n'acceptait que l'option string. Cependant, la documentation du rôle affirmait que les deux options string and dict étaient prises en charge. Par conséquent, les utilisateurs qui lisaient et suivaient la documentation obtenaient une erreur. Ce bogue a été corrigé en faisant en sorte que forward_port accepte les deux options. Par conséquent, les utilisateurs peuvent suivre la documentation en toute sécurité pour configurer la redirection de port.

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. En conséquence, le rôle metrics préserve les liens symboliques et configure correctement le fichier de configuration principal.

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 paramètre mount_options pour les volumes est désormais valable pour un volume

Auparavant, le paramètre avait été accidentellement supprimé de la liste des paramètres valides pour un volume. Par conséquent, les utilisateurs ne pouvaient pas définir le paramètre mount_options pour les volumes. Avec cette correction de bogue, le paramètre mount_options a été réintroduit dans la liste des paramètres valides et le code a été remanié pour détecter les erreurs. Par conséquent, le rôle système storage RHEL peut définir le paramètre mount_options pour les volumes.

Le rôle système storage RHEL prend désormais correctement en charge les niveaux striped et raid0 pour les volumes LVM

Le rôle système storage RHEL signalait auparavant de manière incorrecte que les niveaux RAID striped et raid0 n'étaient pas pris en charge pour les volumes LVM. Ce problème est désormais corrigé et le rôle peut maintenant créer correctement des volumes LVM de tous les niveaux RAID pris en charge par LVM : raid0, raid1, raid4, raid5, raid6, raid10, striped et mirror.

Le README et la documentation de metrics RHEL System Role spécifient désormais clairement les versions de Redis et de Grafana prises en charge sur des versions spécifiques de RHEL par le rôle

Auparavant, lorsque l'on essayait d'utiliser le rôle metrics avec des versions non prises en charge de Redis et de Grafana sur des plates-formes non prises en charge, le rôle échouait. Cette mise à jour clarifie la documentation concernant les versions de Redis et de Grafana prises en charge par le rôle sur les différentes versions de RHEL. Par conséquent, vous pouvez éviter d'essayer d'utiliser des versions non prises en charge de Redis et de Grafana sur des plates-formes non prises en charge.

Option de longueur minimale des bits de la clé RSA dans les rôles de système RHEL ssh et sshd

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 des clés RSA pour les clients et les serveurs OpenSSH en utilisant l'option RequiredRSASize dans les rôles système RHEL ssh et sshd.

Le rôle système nbde_client RHEL utilise désormais des espaces appropriés lorsqu'il spécifie des paramètres de ligne de commande Dracut supplémentaires

Le cadre Dracut exige un espacement approprié lors de la spécification de paramètres supplémentaires, tels que les paramètres de la ligne de commande du noyau. Si les paramètres ne sont pas spécifiés avec un espacement approprié, Dracut peut ne pas ajouter les paramètres supplémentaires spécifiés à la ligne de commande du noyau. Avec cette mise à jour, le rôle système nbde_client RHEL utilise un espacement approprié lors de la création de fichiers de configuration Dracut supplémentaires. Par conséquent, le rôle définit correctement les paramètres de ligne de commande de Dracut.

Le site tlog RHEL System Roles est désormais correctement superposé à SSSD

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

Le rôle de système metrics RHEL redémarre automatiquement les services pmie et pmlogger après une mise à jour de leur configuration

Auparavant, les services pmie et pmlogger ne redémarraient pas après une modification de leur configuration et attendaient l'exécution du gestionnaire. Cela provoquait des erreurs avec d'autres services metrics, qui nécessitaient la configuration de pmie et pmlogger pour correspondre à leur comportement d'exécution. Avec cette mise à jour, le rôle redémarre pmie et pmlogger immédiatement après une mise à jour de la configuration, leur configuration correspond au comportement d'exécution des services de métriques dépendants et ils fonctionnent correctement.

Les performances du trafic réseau dans les machines virtuelles ne sont plus réduites en cas de forte charge

Auparavant, les machines virtuelles RHEL avaient, dans certains cas, des performances réduites lorsqu'elles géraient des niveaux élevés de trafic réseau. Le code sous-jacent a été corrigé et les performances du trafic réseau fonctionnent désormais comme prévu dans les circonstances décrites.

La fonctionnalité SR-IOV d'une carte réseau attachée à une VM Hyper-V fonctionne désormais de manière fiable

Auparavant, lors de l'attachement d'un adaptateur réseau avec la virtualisation d'E/S à racine unique (SR-IOV) activée à une machine virtuelle (VM) RHEL 9 fonctionnant sur l'hyperviseur Microsoft Hyper-V, la fonctionnalité SR-IOV ne fonctionnait pas correctement dans certains cas. Un bogue dans le code d'allocation d'E/S en mémoire (MMIO) spécifique à Hyper-V a été corrigé et la fonctionnalité SR-IOV fonctionne désormais comme prévu sur les VM Hyper-V.

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

Auparavant, les périphériques de mise en réseau SR-IOV présentaient un débit nettement plus faible et une latence plus élevée que prévu dans les machines virtuelles (VM) ARM 64 RHEL 9 fonctionnant sur une plateforme Microsoft Azure. Le problème a été corrigé et les machines virtuelles concernées fonctionnent désormais comme prévu.

podman system connection add et podman image scp n'échoue plus

Podman utilise des hachages SHA-1 pour l'échange de clés RSA. Auparavant, la connexion SSH normale entre les machines utilisant des clés RSA fonctionnait, tandis que les commandes podman system connection add et podman image scp ne fonctionnaient pas avec les mêmes clés RSA, car les hachages SHA-1 n'étaient pas acceptés pour l'échange de clés sur RHEL 9. Avec la mise à jour, le problème a été corrigé.

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

Auparavant, lorsque vous retiriez des images de conteneurs RHEL Beta, Podman échouait avec le message d'erreur : Error: Source image rejected: None of the signatures were accepted. Les images ne pouvaient pas être extraites car les versions actuelles étaient configurées pour ne pas faire confiance aux clés GPG de RHEL Beta par défaut. Avec cette mise à jour, le fichier /etc/containers/policy.json supporte un nouveau champ keyPaths qui accepte une liste de fichiers contenant les clés de confiance. De ce fait, les images de conteneurs signées avec les clés GPG GA et Beta sont maintenant acceptées dans la configuration par défaut.

Podman n'échoue plus à extraire un conteneur "X509 : certificat signé par une autorité inconnue"

Auparavant, si vous aviez votre propre registre interne signé par notre propre certificat d'autorité de certification, vous deviez importer le certificat sur votre machine hôte. Sinon, une erreur se produisait :

DNF et YUM n'échouent plus à cause d'ID de référentiels non concordants

Auparavant, les ID de référentiel DNF et YUM ne correspondaient pas au format attendu par DNF ou YUM. Par exemple, si vous exécutez l'exemple suivant, l'erreur se produit :

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.

gnutls utilise désormais KTLS en tant qu'avant-première technologique

Les paquets gnutls mis à jour peuvent utiliser Kernel TLS (KTLS) pour accélérer le transfert de données sur des canaux cryptés en tant qu'aperçu technologique. Pour activer KTLS, ajoutez le module de noyau tls.ko à l'aide de la commande modprobe, et créez un nouveau fichier de configuration /etc/crypto-policies/local.d/gnutls-ktls.txt pour les politiques cryptographiques du système avec le contenu suivant :

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

Configurer le TCP Multipath avec NetworkManager est disponible en avant-première technologique

Avec cette mise à jour, l'utilitaire NetworkManager vous offre la fonctionnalité Multipath TCP (MPTCP). Vous pouvez utiliser les commandes nmcli pour contrôler MPTCP et rendre ses paramètres persistants.

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 de DNS 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/.

nvme-stas disponible en avant-première technologique

Le paquetage nvme-stas, qui est un client Central Discovery Controller (CDC) pour Linux, est maintenant disponible en tant qu'aperçu technologique. Il gère les notifications d'événements asynchrones (AEN), les contrôles automatisés des connexions au sous-système NVMe, la gestion et le signalement des erreurs, ainsi que la configuration automatique (zeroconf) et manuelle.

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.

RHEL IdM permet de déléguer l'authentification des utilisateurs à des fournisseurs d'identité externes en tant qu'aperçu technologique

Dans RHEL IdM, vous pouvez désormais associer des utilisateurs à des fournisseurs d'identité externes (IdP) qui prennent en charge le flux d'autorisation de périphérique OAuth 2. Lorsque ces utilisateurs s'authentifient avec la version SSSD disponible dans RHEL 9.1, ils bénéficient des fonctionnalités d'authentification unique de RHEL IdM avec des tickets Kerberos après avoir effectué l'authentification et l'autorisation auprès du fournisseur d'identité externe.

le sous-paquet sssd-idp est disponible en tant qu'aperçu technologique

Le sous-paquet sssd-idp pour SSSD contient les plugins oidc_child et krb5 idp, qui sont des composants côté client qui effectuent l'authentification OAuth2 contre les serveurs de gestion d'identité (IdM). Cette fonctionnalité n'est disponible qu'avec les serveurs IdM sur RHEL 8.7 et plus, et RHEL 9.1 et plus.

Le plugin idp krb5 interne de SSSD est disponible en tant qu'aperçu technologique

Le plugin SSSD krb5 idp vous permet de vous authentifier auprès d'un fournisseur d'identité externe (IdP) à l'aide du protocole OAuth2. Cette fonctionnalité n'est disponible qu'avec les serveurs IdM sur RHEL 8.7 et plus, et RHEL 9.1 et plus.

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.

Les machines virtuelles RHEL peuvent désormais être déployées sur des instances VMware ESXi fonctionnant sur des processeurs ARM64

En tant qu'aperçu technologique, il est désormais possible de déployer des machines virtuelles RHEL sur des instances d'hyperviseur VMware ESXi fonctionnant sur des processeurs ARM 64 bits.

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, Intel 64 et ARM 64

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

Les VM confidentielles RHEL sont désormais disponibles sur Azure en tant qu'aperçu technologique

Avec le noyau RHEL mis à jour, vous pouvez désormais créer et exécuter des machines virtuelles (VM) confidentielles sur Microsoft Azure en tant qu'aperçu technologique. Toutefois, il n'est pas encore possible de chiffrer les images de machines virtuelles confidentielles RHEL pendant le démarrage sur Azure.

La possibilité d'utiliser plusieurs clés GPG de confiance pour la signature des images est disponible en tant qu'aperçu technologique

Le fichier /etc/containers/policy.json prend en charge un nouveau champ keyPaths qui accepte une liste de fichiers contenant les clés de confiance. De ce fait, les images de conteneurs signées avec les clés GPG GA et Beta sont désormais acceptées dans la configuration par défaut.

Les signatures sigstore sont désormais disponibles en avant-première technologique

À partir de Podman 4.2, vous pouvez utiliser le format sigstore pour les signatures d'images de conteneurs. Les signatures sigstore sont stockées dans le registre des conteneurs avec l'image du conteneur, sans qu'il soit nécessaire d'avoir un serveur de signatures distinct pour stocker les signatures des images.

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.

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.

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.

Les clés de taille inférieure à 2048 sont dépassées par openssl 3.0

Les tailles de clés inférieures à 2048 bits sont dépréciées par openssl 3.0 et ne fonctionnent plus dans le mode FIPS de Go.

Certains modes de PKCS1 v1.5 sont désormais obsolètes

Certains modes de PKCS1 v1.5 ne sont pas approuvés dans FIPS-140-3 pour le cryptage et sont désactivés. Ils ne fonctionneront plus dans le mode FIPS de Go.

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.

-h et -p ont été supprimées dans les utilitaires clients OpenLDAP.

Le projet OpenLDAP en amont a déprécié les options -h et -p dans ses utilitaires et recommande d'utiliser l'option -H pour spécifier l'URI LDAP. Par conséquent, RHEL 9 a supprimé ces deux options dans tous les utilitaires clients OpenLDAP. Les options -h et -p seront supprimées des produits RHEL dans les prochaines versions.

GTK 2 est désormais obsolète

L'ancienne boîte à outils GTK 2 et les paquets suivants ont été supprimés :

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.

Les anciens modèles de CPU sont désormais obsolètes

Un nombre important de modèles de CPU sont devenus obsolètes et ne seront plus pris en charge pour une utilisation dans des machines virtuelles (VM) dans une prochaine version majeure de RHEL. Les modèles obsolètes sont les suivants :

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 ou une version ultérieure doivent être redémarrés s'ils sont relié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.

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

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.

Le programme d'installation affiche un espace disque total incorrect lors d'un partitionnement personnalisé avec des périphériques à chemins multiples

Le programme d'installation ne filtre pas les chemins individuels des périphériques à chemins multiples lors du partitionnement personnalisé. Le programme d'installation affiche donc les chemins d'accès individuels aux périphériques à chemins d'accès multiples et les utilisateurs peuvent sélectionner les chemins d'accès individuels aux périphériques à chemins d'accès multiples pour les partitions créées. En conséquence, une somme incorrecte de l'espace disque total est affichée. Elle est calculée en ajoutant la taille de chaque chemin d'accès individuel à l'espace disque total.

Échec de l'installation avec des périphériques NVMe sur Fibre Channel

Lors de l'installation de RHEL, le programme d'installation affiche et permet de sélectionner des périphériques Non-volatile Memory Express (NVMe) sur Fibre Channel. L'utilisation de ces périphériques pendant le processus d'installation n'est pas prise en charge. Par conséquent, le processus d'installation peut échouer ou le système installé peut ne pas démarrer correctement.

L'image d'installation de RHEL for Edge ne parvient pas à créer des points de montage lors de l'installation d'une charge utile rpm-ostree

Lors du déploiement des charges utiles rpm-ostree, utilisées par exemple dans une image d'installation RHEL for Edge, le programme d'installation ne crée pas correctement certains points de montage pour les partitions personnalisées. En conséquence, l'installation est interrompue avec l'erreur suivante :

NetworkManager ne démarre pas après l'installation lorsqu'il est connecté à un réseau mais qu'il n'y a pas d'adresse DHCP ou d'adresse IP statique configurée

À partir de RHEL 9.0, Anaconda active automatiquement les périphériques réseau lorsqu'il n'y a pas de configuration réseau spécifique ip= ou kickstart. Anaconda crée un fichier de configuration persistant par défaut pour chaque périphérique Ethernet. Dans le profil de connexion, les valeurs ONBOOT et autoconnect sont définies sur true. Par conséquent, lors du démarrage du système installé, RHEL active les périphériques réseau et le service networkManager-wait-online échoue.

L'utilitaire subscription-manager conserve le texte non essentiel dans le terminal après la fin d'une commande

À partir de RHEL 9.1, l'utilitaire subscription-manager affiche des informations sur la progression du traitement d'une opération. Pour certaines langues (généralement non latines), les messages de progression peuvent ne pas être effacés à la fin de l'opération. Par conséquent, vous pouvez voir des parties d'anciens messages de progression dans le terminal.

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 :

Une mise à niveau DNF de sécurité échoue pour les paquets qui changent d'architecture au cours de la mise à niveau

Le correctif pour BZ#2108969, publié avec l'avis RHBA-2022:8295, introduit la régression suivante : La mise à niveau DNF utilisant des filtres de sécurité échoue pour les paquets dont l'architecture passe de ou à noarch au cours de la mise à niveau. Par conséquent, elle peut laisser le système dans un état vulnérable.

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.

scp vide les fichiers copiés sur eux-mêmes lorsqu'une syntaxe spécifique est utilisée

L'utilitaire scp est passé du protocole de copie sécurisée (SCP) au protocole de transfert de fichiers SSH (SFTP), plus sûr. Par conséquent, la copie d'un fichier d'un emplacement vers le même emplacement efface le contenu du fichier. Le problème concerne la syntaxe suivante :

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.

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.

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.

La remédiation des règles d'audit SCAP échoue de manière incorrecte

La remédiation Bash de certaines règles SCAP liées à la configuration de l'Audit n'ajoute pas la clé Audit lors de la remédiation. Ceci s'applique aux règles suivantes :

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) :

Keylime pourrait échouer dans l'attestation des systèmes qui accèdent à plusieurs fichiers mesurés par l'IMA

Si un système qui exécute l'agent Keylime accède à plusieurs fichiers mesurés par l'architecture de mesure de l'intégrité (IMA) en succession rapide, le vérificateur Keylime peut traiter incorrectement les ajouts au journal de l'IMA. En conséquence, le hachage en cours d'exécution ne correspond pas à l'état correct du registre de configuration de la plate-forme (PCR), et le système échoue à l'attestation. Il n'existe actuellement aucune solution de contournement.

Le script de génération de la politique de démarrage mesurée par Keylime peut provoquer une erreur de segmentation et un vidage du noyau

Le script create_mb_refstate, qui génère des politiques pour l'attestation de démarrage sur mesure dans Keylime, peut calculer incorrectement la longueur des données dans le champ DevicePath au lieu d'utiliser la valeur du champ LengthOfDevicePath lors du traitement de la sortie de l'outil tpm2_eventlog en fonction de l'entrée fournie. En conséquence, le script tente d'accéder à une mémoire invalide en utilisant la longueur incorrectement calculée, ce qui entraîne une erreur de segmentation et un vidage du noyau. La fonctionnalité principale de Keylime n'est pas affectée par ce problème, mais il se peut que vous ne puissiez pas générer une politique de démarrage mesurée.

Certains certificats TPM provoquent le plantage du registraire Keylime

L'option de configuration require_ek_cert dans tenant.conf, qui devrait être activée dans les déploiements de production, détermine si le locataire Keylime nécessite un certificat de clé d'endossement (EK) du Trusted Platform Module (TPM). Lors de la cotation initiale de l'identité avec require_ek_cert activé, Kelime tente de vérifier si le dispositif TPM sur l'agent est authentique en comparant le certificat EK avec les certificats de confiance présents dans le magasin de certificats Keylime TPM. Cependant, certains certificats du magasin sont des certificats x509 malformés et provoquent le plantage du registre Keylime. Il n'existe actuellement aucune solution simple à ce problème, si ce n'est de configurer require_ek_cert en false et de définir un script personnalisé dans l'option ek_check_script qui effectuera la validation EK.

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 :

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.

Le pilote mlx5 échoue lors de l'utilisation de l'adaptateur Mellanox ConnectX-5

Dans le modèle de pilote de périphérique de commutateur Ethernet (switchdev), le pilote mlx5 échoue lorsqu'il est configuré avec le paramètre DMFS (device managed flow steering) et que l'adaptateur ConnectX-5 est pris en charge par le matériel. En conséquence, vous pouvez voir le message d'erreur suivant :

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.

weak-modules from kmod ne fonctionne pas avec les interdépendances de modules

Le script weak-modules fourni par le paquet kmod détermine quels modules sont compatibles avec les noyaux installés. Cependant, lors de la vérification de la compatibilité des modules avec le noyau, weak-modules traite les dépendances des symboles des modules de la version supérieure à la version inférieure du noyau pour lequel ils ont été construits. Par conséquent, les modules avec des interdépendances construits pour différentes versions du noyau peuvent être interprétés comme non compatibles, et le script weak-modules ne fonctionne donc pas dans ce cas.

Le service kdump ne parvient pas à créer le fichier initrd sur les systèmes IBM Z

Sur les systèmes IBM Z 64 bits, le service kdump ne parvient pas à charger le disque RAM initial (initrd) lorsque les informations de configuration liées à znet, telles que s390-subchannels, se trouvent dans un profil de connexion NetworkManager inactif. Par conséquent, le mécanisme kdump échoue avec l'erreur suivante :

Le mécanisme kdump ne parvient pas à capturer le fichier 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.

La fonctionnalité Delay Accounting n'affiche pas par défaut les colonnes de statistiques SWAPIN et IO%

La fonctionnalité Delayed Accounting, contrairement aux premières versions, est désactivée par défaut. Par conséquent, l'application iotop n'affiche pas les colonnes de statistiques SWAPIN et IO% et affiche l'avertissement suivant :

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

Le site iwl7260-firmware interrompt le Wi-Fi sur Intel Wi-Fi 6 AX200, AX210, et Lenovo ThinkPad P1 Gen 4

Après la mise à jour du pilote iwl7260-firmware ou iwl7260-wifi vers la version fournie par RHEL 8.7 et/ou RHEL 9.1 (et plus), le matériel se retrouve dans un état interne incorrect. Par conséquent, les cartes Intel Wifi 6 peuvent ne pas fonctionner et afficher le message d'erreur :

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.

Le comportement de grubby diverge de sa documentation

Lorsque vous ajoutez un nouveau noyau à l'aide de l'outil grubby et que vous ne spécifiez aucun argument, grubby transmet les arguments par défaut à la nouvelle entrée. Ce comportement se produit même sans passer l'argument --copy-default. L'utilisation des options --args et --copy-default permet de s'assurer que ces arguments sont ajoutés aux arguments par défaut, comme indiqué dans la documentation grubby.

Les instances RHEL sur Azure ne démarrent pas si elles sont provisionnées par cloud-init et configurées avec une entrée de montage NFSv3

Actuellement, le démarrage d'une machine virtuelle RHEL (VM) sur la plateforme cloud Microsoft Azure échoue si la VM a été provisionnée par l'outil cloud-init et que le système d'exploitation invité de la VM possède une entrée de montage NFSv3 dans le fichier /etc/fstab.

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.

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 périphériques 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 :

supported_speeds sysfs l'attribut signale des valeurs de vitesse incorrectes

Auparavant, en raison d'une définition incorrecte dans le pilote qla2xxx, l'attribut supported_speeds sysfs pour le HBA indiquait une vitesse de 20 Gb/s au lieu de la vitesse attendue de 64 Gb/s. Par conséquent, si l'adaptateur de bus hôte prenait en charge une vitesse de liaison de 64 Gb/s, la valeur de sysfs supported_speeds était incorrecte, ce qui affectait la valeur de la vitesse signalée.

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.

MIT Kerberos ne prend pas en charge les certificats ECC pour PKINIT

MIT Kerberos n'implémente pas le document RFC5349 request for comments, qui décrit la conception de la prise en charge de la cryptographie à courbe elliptique (ECC) dans la cryptographie à clé publique pour l'authentification initiale (PKINIT). Par conséquent, le paquet MIT krb5-pkinit, utilisé par RHEL, ne prend pas en charge les certificats ECC. Pour plus d'informations, voir Prise en charge de la cryptographie à courbe elliptique (ECC) dans la cryptographie à clé publique pour l'authentification initiale dans Kerberos (PKINIT).

La sous-politique DEFAULT:SHA1 doit être définie sur les clients RHEL 9 pour que PKINIT fonctionne contre 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.

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

Si un agent Kerberos RHEL 9, qu'il s'agisse d'un client ou d'un centre de distribution Kerberos (KDC), interagit avec un agent Kerberos non RHEL-9 qui n'est pas un agent Active Directory (AD), l'authentification PKINIT de l'utilisateur échoue. Pour contourner le problème, effectuez l'une des actions suivantes :

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.

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

Par défaut, un client Heimdal Kerberos initie l'authentification PKINIT d'un utilisateur IdM en utilisant Modular Exponential (MODP) Diffie-Hellman Group 2 pour Internet Key Exchange (IKE). Cependant, le Centre de distribution Kerberos (KDC) du MIT sur RHEL 9 ne prend en charge que les groupes MODP 14 et 16.

IdM en mode FIPS ne prend pas en charge l'utilisation du protocole NTLMSSP pour établir une confiance bidirectionnelle entre forêts

L'établissement d'une confiance bidirectionnelle entre Active Directory (AD) et Identity Management (IdM) avec le mode FIPS activé échoue parce que l'authentification NTLMSSP (New Technology LAN Manager Security Support Provider) n'est pas conforme à la norme FIPS. IdM en mode FIPS n'accepte pas le hachage NTLM RC4 que le contrôleur de domaine AD utilise lors de la tentative d'authentification.

Échec des demandes de certificats de transfert de technologie entre IdM et AD

Les informations du certificat d'attributs de privilèges (PAC) dans les tickets IdM Kerberos sont désormais signées avec le cryptage AES SHA-2 HMAC, qui n'est pas pris en charge par Active Directory (AD).

Le chiffrement et le déchiffrement de la chambre forte IdM échouent en mode FIPS

Le chiffrement OpenSSL RSA-PKCS1v15 est bloqué si le mode FIPS est activé. Par conséquent, les chambres fortes de gestion de l'identité (IdM) ne fonctionnent pas correctement, car IdM utilise actuellement le cryptage PKCS1v15 pour envelopper la clé de session avec le certificat de transport.

Les utilisateurs IdM migrés peuvent être incapables de se connecter en raison de la non-concordance des identifiants de domaine

Si vous avez utilisé le script ipa migrate-ds pour migrer des utilisateurs d'un déploiement IdM à un autre, ces utilisateurs peuvent avoir des problèmes pour utiliser les services IdM parce que leurs identifiants de sécurité (SID) n'ont pas le SID du domaine de l'environnement IdM actuel. Par exemple, ces utilisateurs peuvent récupérer un ticket Kerberos avec l'utilitaire kinit, mais ils ne peuvent pas se connecter. Pour résoudre ce problème, consultez l'article suivant de la base de connaissances : Migrated IdM users unable to log in due to mismatching domain SIDs (Utilisateurs IdM migrés incapables de se connecter en raison de la non-concordance des SID de domaine).

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 console VNC fonctionne mal à certaines résolutions

Lorsque vous utilisez la console Virtual Network Computing (VNC) sous certaines résolutions d'affichage, vous pouvez rencontrer un problème de décalage de la souris ou ne voir qu'une partie de l'interface. Par conséquent, l'utilisation de la console VNC peut s'avérer impossible. Pour contourner ce problème, vous pouvez essayer d'agrandir la taille de la console VNC ou utiliser la visionneuse de bureau dans l'onglet Console pour lancer la visionneuse à distance à la place.

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

Actuellement, l'utilitaire virt-install échoue lorsqu'il tente d'installer un système d'exploitation invité (OS) à partir d'une source ISO via une connexion https ou ssh - 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.

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.

VNC ne peut pas se connecter aux machines virtuelles UEFI après la migration

Si vous activez ou désactivez une file d'attente de messages lors de la migration d'une machine virtuelle (VM), le client Virtual Network Computing (VNC) ne parviendra pas à se connecter à la VM une fois la migration terminée.

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.

La VM Windows ne parvient pas à obtenir l'adresse IP après la réinitialisation de l'interface réseau

Il arrive que les machines virtuelles Windows ne parviennent pas à obtenir une adresse IP après une réinitialisation automatique de l'interface réseau. Par conséquent, la machine virtuelle ne parvient pas à se connecter au réseau. Pour résoudre ce problème, désactivez et réactivez le pilote de la carte réseau dans le gestionnaire de périphériques de Windows.

Les adaptateurs réseau Broadcom ne fonctionnent pas correctement sur les machines virtuelles Windows après une migration en direct

Actuellement, les adaptateurs réseau de la famille Broadcom, tels que Broadcom, Qlogic ou Marvell, ne peuvent pas être débranchés à chaud pendant la migration en direct des machines virtuelles (VM) Windows. Par conséquent, les adaptateurs ne fonctionnent pas correctement une fois la migration terminée.

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.

Le réseau de l'hôte ne peut pas envoyer de ping aux VMs avec VFs pendant la migration en direct

Lors de la migration en direct d'une machine virtuelle (VM) avec une fonction virtuelle (VF) configurée, telle qu'une VM qui utilise le logiciel SR-IOV virtuel, le réseau de la VM n'est pas visible pour les autres périphériques et la VM ne peut pas être atteinte par des commandes telles que ping. Cependant, une fois la migration terminée, le problème ne se produit plus.

L'utilisation d'un grand nombre de files d'attente peut entraîner l'échec des machines virtuelles Windows

Les machines virtuelles (VM) Windows peuvent échouer lorsque le périphérique virtuel Trusted Platform Module (vTPM) est activé et que la fonction multi-queue virtio-net est configurée pour utiliser plus de 250 files d'attente.

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

La définition d'une IP statique dans une machine virtuelle RHEL sur un hôte VMware ne fonctionne pas

Actuellement, lors de l'utilisation de RHEL en tant que système d'exploitation invité d'une machine virtuelle (VM) sur un hôte VMware, la fonction DatasourceOVF ne fonctionne pas correctement. Par conséquent, si vous utilisez l'utilitaire cloud-init pour configurer le réseau de la VM en IP statique et que vous redémarrez ensuite la VM, le réseau de la VM passera en DHCP.

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 :

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 :