5.12. Rôles du système Red Hat Enterprise Linux

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

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

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

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

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

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

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

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

L'option logging_purge_confs supprime correctement les fichiers de configuration inutiles

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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