8.13. Rôles du système Red Hat Enterprise Linux
Le rôle du système nbde_client gère désormais correctement les différents noms de clevis-luks-askpass
Le rôle de système nbde_client a été mis à jour pour gérer les systèmes sur lesquels l'unité clevis-luks-askpass systemd a un nom différent. Le rôle fonctionne désormais correctement avec les différents noms de clevis-luks-askpass sur les nœuds gérés, ce qui nécessite de déverrouiller également les volumes cryptés LUKS qui se montent tardivement dans le processus de démarrage.
Les journaux des rôles du système ha_cluster n'affichent plus les mots de passe et les secrets non chiffrés
Le rôle de système ha_cluster accepte des paramètres qui peuvent être des mots de passe ou d'autres secrets. Auparavant, certaines tâches consignaient leurs entrées et sorties. Par conséquent, les journaux des rôles pouvaient contenir des mots de passe non cryptés et d'autres secrets.
Avec cette mise à jour, les tâches ont été modifiées pour utiliser la directive Ansible no_log: true et la sortie de la tâche n'est plus affichée dans les journaux de rôle. Les journaux des rôles du système ha_cluster ne contiennent plus de mots de passe ni d'autres secrets. Bien que cette mise à jour protège les informations sécurisées, les journaux de rôle fournissent désormais moins d'informations que vous pouvez utiliser lors du débogage de votre configuration.
Les clusters configurés avec le rôle de système ha_cluster pour utiliser le SBD et ne pas démarrer au démarrage fonctionnent désormais correctement
Auparavant, si un utilisateur configurait un cluster à l'aide du rôle système ha_cluster pour utiliser le SBD et ne pas démarrer au démarrage, le service SBD était désactivé et le SBD ne démarrait pas. Avec cette correction, le service SBD est toujours activé si un cluster est configuré pour utiliser le SBD, qu'il soit ou non configuré pour démarrer au démarrage.
L'activation du fournisseur de fichiers implicites permet de corriger la configuration de cockpit-session-recording SSSD
Un fournisseur de fichiers implicites SSSD désactivé entraînait la création d'une configuration SSSD (System Security Services Daemon) invalide par les modules cockpit-session-recording. Cette mise à jour active inconditionnellement le fournisseur de fichiers et, par conséquent, la configuration SSSD créée par cockpit-session-recording fonctionne désormais comme prévu.
Le rôle nbde_client_clevis ne signale plus de traceback aux utilisateurs
Auparavant, le rôle nbde_client_clevis échouait parfois dans une exception, ce qui entraînait un retour en arrière et la communication de données sensibles, telles que le champ encryption_password, à l'utilisateur. Avec cette mise à jour, le rôle ne signale plus de données sensibles, mais uniquement les messages d'erreur appropriés.
Bugzilla:2162782
La définition de la propriété stonith-watchdog-timeout avec le rôle de système ha_cluster fonctionne désormais dans un cluster arrêté
Auparavant, lorsque vous définissiez la propriété stonith-watchdog-timeout avec le rôle système ha_cluster dans un cluster arrêté, la propriété reprenait sa valeur précédente et le rôle échouait. Avec cette correction, la configuration de la propriété stonith-watchdog-timeout à l'aide du rôle système ha_cluster fonctionne correctement.
Le trafic réseau est désormais dirigé vers l'interface réseau prévue lors de l'utilisation de initscripts avec le rôle de système RHEL networking
Auparavant, lors de l'utilisation du fournisseur initscripts, la configuration du routage pour les connexions réseau ne spécifiait pas le périphérique de sortie par lequel le trafic devait passer. Par conséquent, le noyau pouvait utiliser un périphérique de sortie différent de celui prévu par l'utilisateur. Désormais, si le nom de l'interface réseau est spécifié dans le playbook pour la connexion, il est utilisé comme périphérique de sortie dans le fichier de configuration de l'itinéraire. Cela aligne le comportement avec NetworkManager, qui configure le périphérique de sortie dans les routes lors de l'activation des profils sur les périphériques. Ainsi, les utilisateurs peuvent s'assurer que le trafic est dirigé vers l'interface réseau prévue.
Le rôle selinux gère désormais les modules de politique de manière idempotente
Auparavant, le rôle selinux copiait un module existant sur le nœud géré à chaque fois, signalant un changement même si le module était déjà présent. Avec cette mise à jour, le rôle selinux vérifie si le module a été installé sur le nœud géré et ne tente pas de copier et d'installer le module s'il est déjà installé.
