4.16. Rôles du système Red Hat Enterprise Linux
La règle de routage permet de consulter une table de routage par son nom
Avec cette mise à jour, le rôle système rhel-system-roles.network RHEL prend en charge la recherche d'une table de routage par son nom lorsque vous définissez une règle de routage. Cette fonctionnalité permet une navigation rapide pour les configurations réseau complexes où vous devez avoir différentes règles de routage pour différents segments du réseau.
Le rôle de système network permet de définir une valeur de priorité DNS
Cette amélioration ajoute le paramètre dns_priority au rôle système RHEL network. Vous pouvez attribuer à ce paramètre une valeur comprise entre -2147483648 et 2147483647. La valeur par défaut est 0. Les valeurs inférieures ont une priorité plus élevée. Notez que les valeurs négatives conduisent le rôle de système à exclure d'autres configurations ayant une valeur de priorité numérique supérieure. Par conséquent, en présence d'au moins une valeur de priorité négative, le rôle de système n'utilise que les serveurs DNS des profils de connexion ayant la valeur de priorité la plus basse.
Par conséquent, vous pouvez utiliser le rôle de système network pour définir l'ordre des serveurs DNS dans différents profils de connexion.
Nouveaux paramètres de personnalisation IPsec pour le rôle de système vpn RHEL
Étant donné que certains périphériques réseau nécessitent une personnalisation d'IPsec pour fonctionner correctement, les paramètres suivants ont été ajoutés au rôle de système vpn RHEL :
Ne modifiez pas les paramètres suivants sans connaissances préalables. La plupart des scénarios ne nécessitent pas de personnalisation.
De plus, pour des raisons de sécurité, cryptez une valeur du paramètre shared_key_content en utilisant Ansible Vault.
Paramètres du tunnel :
-
shared_key_content -
ike -
esp -
ikelifetime -
salifetime -
retransmit_timeout -
dpddelay -
dpdtimeout -
dpdaction -
leftupdown
-
- Paramètres par hôte :
-
leftid -
rightid
Par conséquent, vous pouvez utiliser le rôle vpn pour configurer la connectivité IPsec avec un large éventail de périphériques réseau.
Le rôle de système selinux RHEL prend désormais en charge le paramètre local
Cette mise à jour du rôle système selinux RHEL introduit la prise en charge du paramètre local. En utilisant ce paramètre, vous pouvez supprimer uniquement les modifications de votre politique locale et préserver la politique SELinux intégrée.
Le rôle de système ha_cluster prend désormais en charge l'exécution automatisée des rôles de système firewall, selinux et certificate
Le rôle de système RHEL ha_cluster prend désormais en charge les fonctionnalités suivantes :
- Utilisation des rôles de système
firewalletselinuxpour gérer l'accès aux ports -
Pour configurer les ports d'un cluster afin qu'ils exécutent les services
firewalldetselinux, vous pouvez définir les nouvelles variables de rôleha_cluster_manage_firewalletha_cluster_manage_selinuxsurtrue. Cela configure le cluster afin qu'il utilise les rôles de systèmefirewalletselinux, en automatisant et en exécutant ces opérations dans le rôle de systèmeha_cluster. Si ces variables sont définies sur leur valeur par défaut defalse, les rôles ne sont pas exécutés. Avec cette version, le pare-feu n'est plus configuré par défaut, car il n'est configuré que lorsqueha_cluster_manage_firewallest défini surtrue. - Utilisation du rôle de système
certificatepour créer une paire de clés privées et de certificatspcsd -
Le rôle de système
ha_clusterprend désormais en charge la variable de rôleha_cluster_pcsd_certificates. La définition de cette variable transmet sa valeur à la variablecertificate_requestsdu rôle de systèmecertificate. Il s'agit d'une méthode alternative pour créer la paire clé privée/certificat pourpcsd.
Le rôle de système RHEL postfix peut désormais utiliser les rôles de système RHEL firewall et selinux pour gérer l'accès aux ports
Grâce à cette amélioration, vous pouvez automatiser la gestion de l'accès aux ports en utilisant les nouvelles variables de rôle postfix_manage_firewall et postfix_manage_selinux:
-
S'ils sont définis sur
true, chaque rôle est utilisé pour gérer l'accès au port. -
S'ils sont réglés sur
false, ce qui est la valeur par défaut, les rôles ne s'engagent pas.
Le rôle de système RHEL vpn peut désormais utiliser les rôles firewall et selinux pour gérer l'accès aux ports
Grâce à cette amélioration, vous pouvez automatiser la gestion de l'accès aux ports dans le rôle de système RHEL vpn via les rôles firewall et selinux. Si vous définissez les nouvelles variables de rôle vpn_manage_firewall et vpn_manage_selinux sur true, les rôles gèrent l'accès aux ports.
Le rôle de système logging RHEL prend désormais en charge l'accès aux ports et la génération des certificats
Grâce à cette amélioration, vous pouvez utiliser le rôle de journalisation pour gérer l'accès aux ports et générer des certificats à l'aide de nouvelles variables de rôle. Si vous définissez les nouvelles variables de rôle logging_manage_firewall et logging_manage_selinux sur true, les rôles gèrent l'accès aux ports. La nouvelle variable de rôle pour la génération de certificats est logging_certificates. Le type et l'utilisation sont les mêmes que pour le rôle certificate certificate_requests . Vous pouvez maintenant automatiser ces opérations directement en utilisant le rôle logging.
Le rôle de système RHEL metrics peut désormais utiliser les rôles firewall et selinux pour gérer l'accès aux ports
Grâce à cette amélioration, vous pouvez contrôler l'accès aux ports. Si vous définissez les nouvelles variables de rôle metrics_manage_firewall et metrics_manage_firewall sur true, les rôles gèrent l'accès aux ports. Vous pouvez désormais automatiser et effectuer ces opérations directement en utilisant le rôle metrics.
Le rôle de système RHEL nbde_server peut désormais utiliser les rôles firewall et selinux pour gérer l'accès aux ports
Avec cette amélioration, vous pouvez utiliser les rôles firewall et selinux pour gérer l'accès aux ports. Si vous définissez les nouvelles variables de rôle nbde_server_manage_firewall et nbde_server_manage_selinux sur true, les rôles gèrent l'accès aux ports. Vous pouvez maintenant automatiser ces opérations directement en utilisant le rôle nbde_server.
Le fournisseur du réseau initscripts prend en charge la configuration de la métrique de route de la passerelle par défaut
Avec cette mise à jour, vous pouvez utiliser le fournisseur de réseau initscripts dans le rôle de système RHEL rhel-system-roles.network pour configurer la métrique de route de la passerelle par défaut.
Les raisons d'une telle configuration peuvent être les suivantes :
- Répartition de la charge de trafic sur les différents chemins
- Spécification des itinéraires primaires et des itinéraires de secours
- Exploiter les stratégies de routage pour envoyer le trafic vers des destinations spécifiques via des chemins spécifiques
Intégration du rôle de système RHEL cockpit avec les rôles firewall, selinux et certificate
Cette amélioration vous permet d'intégrer le rôle cockpit avec les rôles firewall et selinux pour gérer l'accès aux ports et le rôle certificate pour générer des certificats.
Pour contrôler l'accès au port, utilisez les nouvelles variables cockpit_manage_firewall et cockpit_manage_selinux. Ces deux variables sont définies par défaut sur false et ne sont pas exécutées. Définissez-les à true pour permettre aux rôles firewall et selinux de gérer l'accès au port du service de la console web RHEL. Les opérations seront alors exécutées dans le cadre du rôle cockpit.
Notez que vous êtes responsable de la gestion de l'accès aux ports pour le pare-feu et SELinux.
Pour générer des certificats, utilisez la nouvelle variable cockpit_certificates. La variable est définie par défaut sur false et n'est pas exécutée. Vous pouvez utiliser cette variable de la même manière que la variable certificate_request dans le rôle certificate. Le rôle cockpit utilisera alors le rôle certificate pour gérer les certificats de la console web RHEL.
Nouveau rôle de système RHEL pour une intégration directe avec Active Directory
Le nouveau rôle de système RHEL rhel-system-roles.ad_integration a été ajouté au package rhel-system-roles. Ainsi, les administrateurs peuvent désormais automatiser l'intégration directe d'un système RHEL avec un domaine Active Directory.
Nouveau rôle Ansible pour Red Hat Insights et la gestion des abonnements
Le paquetage rhel-system-roles inclut désormais le rôle système de configuration d'hôte à distance (rhc). Ce rôle permet aux administrateurs d'enregistrer facilement les systèmes RHEL sur les serveurs Red Hat Subscription Management (RHSM) et Satellite. Par défaut, lorsque vous enregistrez un système en utilisant le rôle système rhc, le système se connecte à Red Hat Insights. Avec le nouveau rôle système rhc, les administrateurs peuvent désormais automatiser les tâches suivantes sur les nœuds gérés :
- Configurez la connexion à Red Hat Insights, y compris la mise à jour automatique, les remédiations et les balises pour le système.
- Activer et désactiver les référentiels.
- Configurer le proxy à utiliser pour la connexion.
- Définir le déblocage du système.
Pour plus d'informations sur l'automatisation de ces tâches, voir Utilisation du rôle système RHC pour enregistrer le système.
Ajout de la prise en charge de l'adresse MAC clonée
L'adresse MAC clonée est l'adresse MAC du port WAN de l'appareil qui est la même que l'adresse MAC de la machine. Avec cette mise à jour, les utilisateurs peuvent spécifier l'interface de liaison ou de pont avec l'adresse MAC ou la stratégie telle que random ou preserve pour obtenir l'adresse MAC par défaut pour l'interface de liaison ou de pont.
Le rôle Ansible de Microsoft SQL Server prend en charge les répliques asynchrones à haute disponibilité
Auparavant, le rôle Ansible de Microsoft SQL Server ne prenait en charge que les répliques primaires, synchrones et témoins de haute disponibilité. Désormais, vous pouvez définir la variable mssql_ha_replica_type sur asynchronous pour la configurer avec un type de réplique asynchrone pour une réplique nouvelle ou existante.
Le rôle Ansible de Microsoft SQL Server prend en charge le type de cluster "read-scale"
Auparavant, le rôle Microsoft SQL Ansible ne prenait en charge que le type de cluster externe. Désormais, vous pouvez configurer le rôle avec une nouvelle variable mssql_ha_ag_cluster_type. La valeur par défaut est external, utilisez-la pour configurer le cluster avec Pacemaker. Pour configurer le cluster sans Pacemaker, utilisez la valeur none pour cette variable.
Le rôle Ansible de Microsoft SQL Server peut générer des certificats TLS
Auparavant, vous deviez générer manuellement un certificat TLS et une clé privée sur les nœuds avant de configurer le rôle Microsoft SQL Ansible. Avec cette mise à jour, le rôle Microsoft SQL Server Ansible peut utiliser le rôle redhat.rhel_system_roles.certificate à cette fin. Désormais, vous pouvez définir la variable mssql_tls_certificates au format de la variable certificate_requests du rôle certificate pour générer un certificat TLS et une clé privée sur le nœud.
Microsoft SQL Server Le rôle Ansible prend en charge la configuration de la version 2022 du serveur SQL
Auparavant, le rôle Microsoft SQL Ansible ne prenait en charge que la configuration de SQL Server version 2017 et version 2019. Cette mise à jour prend en charge la version 2022 de SQL Server pour le rôle Microsoft SQL Ansible. Désormais, vous pouvez définir la valeur mssql_version sur 2022 pour configurer un nouveau serveur SQL 2022 ou mettre à niveau un serveur SQL de la version 2019 à la version 2022. Notez que la mise à niveau d'un serveur SQL de la version 2017 à la version 2022 n'est pas disponible.
Microsoft SQL Server Le rôle Ansible prend en charge la configuration de l'authentification Active Directory
Avec cette mise à jour, le rôle Microsoft SQL Ansible prend en charge la configuration de l'authentification Active Directory pour un serveur SQL. Désormais, vous pouvez configurer l'authentification Active Directory en définissant des variables avec le préfixe mssql_ad_.
Le rôle de système journald RHEL est désormais disponible
Le service journald collecte et stocke les données de journalisation dans une base de données centralisée. Avec cette amélioration, vous pouvez utiliser les variables de rôle du système journald pour automatiser la configuration du journal systemd et configurer la journalisation persistante à l'aide de Red Hat Ansible Automation Platform.
Le rôle de système ha_cluster prend désormais en charge la configuration des dispositifs de quorum
Un dispositif quorum fait office de dispositif d'arbitrage tiers pour une grappe. Il est recommandé d'utiliser un dispositif quorum pour les grappes comportant un nombre pair de nœuds. Dans le cas des clusters à deux nœuds, l'utilisation d'un dispositif quorum permet de mieux déterminer quel nœud survit dans une situation de cerveau divisé. Vous pouvez maintenant configurer un dispositif de quorum avec le rôle système ha_cluster, à la fois qdevice pour une grappe et qnetd pour un nœud d'arbitrage.
