Automatiser l'administration du système en utilisant les rôles système RHEL

Procédure

1. Installez le paquetage rhel-system-roles:

   [root@control-node]# dnf install rhel-system-roles

   Cette commande installe le paquet ansible-core en tant que dépendance.

   Note

   Dans RHEL 8.5 et les versions antérieures, les packages Ansible étaient fournis via Ansible Engine au lieu d'Ansible Core, et avec un niveau de support différent. N'utilisez pas Ansible Engine car les packages peuvent ne pas être compatibles avec le contenu d'automatisation Ansible dans RHEL 8.6 et les versions ultérieures. Pour plus d'informations, voir Étendue de la prise en charge du package Ansible Core inclus dans les référentiels AppStream RHEL 9 et RHEL 8.6 et versions ultérieures.

2. Créez un utilisateur nommé ansible pour gérer et exécuter les playbooks :

   [root@control-node]# useradd ansible

3. Passez à l'utilisateur nouvellement créé ansible:

   [root@control-node]# su - ansible

   Effectuez le reste de la procédure en tant qu'utilisateur.

4. Créez une clé publique et une clé privée SSH :

   [ansible@control-node]$ ssh-keygen
   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/ansible/.ssh/id_rsa): <password>
   ...

   Utilisez l'emplacement par défaut proposé pour le fichier clé.

5. Facultatif : Pour éviter qu'Ansible ne vous demande le mot de passe de la clé SSH à chaque fois que vous établissez une connexion, configurez un agent SSH.

6. Créez le fichier ~/.ansible.cfg avec le contenu suivant :

   [defaults]
   inventory = /home/ansible/inventory
   remote_user = ansible
   
   [privilege_escalation]
   become = True
   become_method = sudo
   become_user = root
   become_ask_pass = True

   Note

   Les paramètres du fichier ~/.ansible.cfg ont une priorité plus élevée et remplacent les paramètres du fichier global /etc/ansible/ansible.cfg.

   Avec ces paramètres, Ansible effectue les actions suivantes :

   • Gère les hôtes dans le fichier d'inventaire spécifié.
   • Utilise le compte défini dans le paramètre remote_user lorsqu'il établit des connexions SSH avec les nœuds gérés.
   • Utilise l'utilitaire sudo pour exécuter des tâches sur les nœuds gérés en tant qu'utilisateur root.
   • Demande le mot de passe root de l'utilisateur distant à chaque fois que vous appliquez un playbook. Ceci est recommandé pour des raisons de sécurité.

7. Créez un fichier ~/inventory au format INI ou YAML qui répertorie les noms d'hôtes gérés. Vous pouvez également définir des groupes d'hôtes dans le fichier d'inventaire. Par exemple, voici un fichier d'inventaire au format INI avec trois hôtes et un groupe d'hôtes nommé US:

   managed-node-01.example.com
   
   [US]
   managed-node-02.example.com ansible_host=192.0.2.100
   managed-node-03.example.com

   Notez que le nœud de contrôle doit être en mesure de résoudre les noms d'hôte. Si le serveur DNS ne peut pas résoudre certains noms d'hôtes, ajoutez le paramètre ansible_host à côté de l'entrée de l'hôte pour spécifier son adresse IP.

Procédure

1. Créez un utilisateur nommé ansible:

   [root@managed-node-01]# useradd ansible

   Le nœud de contrôle utilise ensuite cet utilisateur pour établir une connexion SSH avec cet hôte.

2. Définir un mot de passe pour l'utilisateur ansible:

   [root@managed-node-01]# passwd ansible
   Changing password for user ansible.
   New password: <password>
   Retype new password: <password>
   passwd: all authentication tokens updated successfully.

   Vous devez saisir ce mot de passe lorsque Ansible utilise sudo pour effectuer des tâches en tant qu'utilisateur root.

3. Installez la clé publique SSH de l'utilisateur ansible sur le nœud géré :

   1. Connectez-vous au nœud de contrôle en tant qu'utilisateur ansible et copiez la clé publique SSH sur le nœud géré :

      [ansible@control-node]$ ssh-copy-id managed-node-01.example.com
      /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/ansible/.ssh/id_rsa.pub"
      The authenticity of host 'managed-node-01.example.com (192.0.2.100)' can't be established.
      ECDSA key fingerprint is SHA256:9bZ33GJNODK3zbNhybokN/6Mq7hu3vpBXDrCxe7NAvo.

   2. Lorsque vous y êtes invité, connectez-vous en entrant yes:

      Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
      /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
      /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

   3. Lorsque vous y êtes invité, saisissez le mot de passe :

      ansible@managed-node-01.example.com's password: <password>
      
      Number of key(s) added: 1
      
      Now try logging into the machine, with:   "ssh '<managed-node-01.example.com>'"
      and check to make sure that only the key(s) you wanted were added.

   4. Vérifiez la connexion SSH en exécutant à distance une commande sur le nœud de contrôle :

      [ansible@control-node]$ ssh <managed-node-01.example.com> whoami
      ansible

4. Créer une configuration sudo pour l'utilisateur ansible:

   1. Créez et modifiez le fichier /etc/sudoers.d/ansible à l'aide de la commande visudo:

      [root@managed-node-01]# visudo /etc/sudoers.d/ansible

      L'avantage d'utiliser visudo plutôt qu'un éditeur normal est que cet utilitaire fournit des contrôles de base et vérifie les erreurs d'analyse avant d'installer le fichier.

   2. Configurez une politique sudoers dans le fichier /etc/sudoers.d/ansible qui réponde à vos besoins, par exemple :

      • Pour autoriser l'utilisateur ansible à exécuter toutes les commandes en tant qu'utilisateur et groupe sur cet hôte après avoir saisi le mot de passe de l'utilisateur ansible, utilisez l'option suivante :

        ansible ALL=(ALL) ALL

      • Pour autoriser l'utilisateur ansible à exécuter toutes les commandes en tant qu'utilisateur et groupe sur cet hôte sans saisir le mot de passe de l'utilisateur ansible, utilisez la commande suivante

        ansible ALL=(ALL) NOPASSWD: ALL

   Vous pouvez également configurer une politique plus fine qui correspond à vos exigences en matière de sécurité. Pour plus d'informations sur les politiques de sudoers, voir la page de manuel sudoers(5).

Vérification

1. Vérifiez que vous pouvez exécuter des commandes à partir du nœud de contrôle sur tous les nœuds gérés :

   [ansible@control-node]$ ansible all -m ping
   BECOME password: <password>
   managed-node-01.example.com | SUCCESS => {
       	"ansible_facts": {
       	    "discovered_interpreter_python": "/usr/bin/python3"
       	},
       	"changed": false,
       	"ping": "pong"
   }
   ...

   Le groupe all codé en dur contient dynamiquement tous les hôtes répertoriés dans le fichier d'inventaire.

2. Vérifiez que l'escalade des privilèges fonctionne correctement en exécutant l'utilitaire whoami sur un hôte géré à l'aide du module Ansible command:

   [ansible@control-node]$ ansible managed-node-01.example.com -m command -a whoami
   BECOME password: <password>
   managed-node-01.example.com | CHANGED | rc=0 >>
   root

   Si la commande renvoie la valeur root, vous avez configuré correctement sudo sur les nœuds gérés.

1. Exécutez la commande suivante :

   $ ansible-playbook -c local -i localhost, --check --become /usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/tests/kernel_settings/tests_default.yml

Procédure

1. Définissez Red Hat Automation Hub comme source de contenu par défaut dans le fichier de configuration ansible.cfg. Voir Configurer Red Hat Automation Hub en tant que source primaire de contenu .

2. Installez la collection redhat.rhel_system_roles à partir du Hub d'automatisation :

   # ansible-galaxy collection install redhat.rhel_system_roles

   Une fois l'installation terminée, les rôles sont disponibles à l'adresse redhat.rhel_system_roles.<role_name>. En outre, vous pouvez trouver la documentation de chaque rôle à l'adresse /usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/roles/<role_name>/README.md.

1. Exécutez la commande suivante :

   $ ansible-playbook -c local -i localhost, --check --become /usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/tests/kernel_settings/tests_default.yml

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   ---
   - name: Deploy session recording
     hosts: all
     vars:
       tlog_scope_sssd: some
       tlog_users_sssd:
         - recordeduser
   
     roles:
       - redhat.rhel-system-roles.tlog

   Où ?

   • tlog_scope_sssd:

     • some spécifie que vous souhaitez enregistrer uniquement certains utilisateurs et groupes, pas all ou none.

   • tlog_users_sssd:

     • recordeduser spécifie l'utilisateur à partir duquel vous souhaitez enregistrer une session. Notez que cette fonction n'ajoute pas l'utilisateur à votre place. Vous devez définir l'utilisateur vous-même.

2. Optionnellement, vérifier la syntaxe du playbook.

   # ansible-playbook --syntax-check playbook.yml

3. Exécutez le playbook sur votre fichier d'inventaire :

   # ansible-playbook -i IP_Address /path/to/file/playbook.yml -v

Verification steps

1. Tester la syntaxe du fichier /etc/rsyslog.conf:

   # rsyslogd -N 1
   rsyslogd: version 8.1911.0-6.el8, config validation run (level 1), master config /etc/rsyslog.conf
   rsyslogd: End of config validation run. Bye.

2. Vérifiez que le système envoie des messages au journal :

1. Naviguez jusqu'au dossier dans lequel le fichier de dépôt de la configuration SSSD a été créé :

   # cd /etc/sssd/conf.d

2. Vérifier le contenu du fichier :

   # cat sssd-session-recording.conf

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   ---
   - name: Sets which boot device will be used on next boot
     hosts: localhost
       tasks:
       - redhat.rhel_mgmt.ipmi_boot:
          name: bmc.host.example.com
            user: admin_user
            password: basics
            bootdev: hd

2. Exécuter le playbook contre localhost :

   # ansible-playbook playbook.yml

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   ---
   - name: Turn the host on
     hosts: localhost
       tasks:
       - redhat.rhel_mgmt.ipmi_power:
          name: bmc.host.example.com
            user: admin_user
            password: basics
            state: on

2. Exécuter le cahier des charges :

   # ansible-playbook playbook.yml

1. redfish_info: Le module redfish_info récupère des informations sur le contrôleur hors bande (OOB) distant, telles que l'inventaire des systèmes.
2. redfish_command: Le module redfish_command effectue des opérations de contrôle hors bande (OOB) telles que la gestion des journaux et des utilisateurs, ainsi que des opérations d'alimentation telles que le redémarrage du système, la mise sous tension et la mise hors tension.
3. redfish_config: Le module redfish_config effectue les opérations du contrôleur OOB telles que la modification de la configuration OOB ou le réglage de la configuration BIOS.

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   ---
   - name: Get CPU inventory
     hosts: localhost
     tasks:
       - redhat.rhel_mgmt.redfish_info:
           baseuri: "{{ baseuri }}"
           username: "{{ username }}"
           password: "{{ password }}"
           category: Systems
           command: GetCpuInventory
         register: result

2. Exécuter le playbook contre localhost :

   # ansible-playbook playbook.yml

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   ---
   - name: Power on system
     hosts: localhost
     tasks:
       - redhat.rhel_mgmt.redfish_command:
           baseuri: "{{ baseuri }}"
           username: "{{ username }}"
           password: "{{ password }}"
           category: Systems
           command: PowerOn

2. Exécuter le playbook contre localhost :

   # ansible-playbook playbook.yml

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   ---
   - name: "Set BootMode to UEFI"
     hosts: localhost
     tasks:
       - redhat.rhel_mgmt.redfish_config:
           baseuri: "{{ baseuri }}"
           username: "{{ username }}"
           password: "{{ password }}"
           category: Systems
           command: SetBiosAttributes
           bios_attributes:
             BootMode: Uefi

2. Exécuter le playbook contre localhost :

   # ansible-playbook playbook.yml

Procédure

1. Si vous le souhaitez, vous pouvez consulter le fichier inventory à des fins d'illustration :

   #  cat /home/jdoe/<ansible_project_name>/inventory
   [testingservers]
   pdoe@192.168.122.98
   fdoe@192.168.122.226
   
   [db-servers]
   db1.example.com
   db2.example.com
   
   [webservers]
   web1.example.com
   web2.example.com
   192.0.2.42

   Ce fichier définit le groupe [testingservers] et d'autres groupes. Il vous permet d'exécuter Ansible plus efficacement sur un ensemble spécifique de systèmes.

2. Créer un fichier de configuration pour définir les valeurs par défaut et l'escalade des privilèges pour les opérations Ansible.

   1. Créez un nouveau fichier YAML et ouvrez-le dans un éditeur de texte, par exemple :

      #  vi /home/jdoe/<ansible_project_name>/ansible.cfg

   2. Insérez le contenu suivant dans le fichier :

      [defaults]
      inventory = ./inventory
      
      [privilege_escalation]
      become = true
      become_method = sudo
      become_user = root
      become_ask_pass = true

      La section [defaults] indique un chemin d'accès au fichier d'inventaire des hôtes gérés. La section [privilege_escalation] définit que les privilèges de l'utilisateur doivent passer à root sur les hôtes gérés spécifiés. Ceci est nécessaire pour une configuration réussie des paramètres du noyau. Lorsque le playbook Ansible est exécuté, vous serez invité à saisir le mot de passe de l'utilisateur. L'utilisateur passe automatiquement à root par le biais de sudo après s'être connecté à un hôte géré.

3. Créer un playbook Ansible qui utilise le rôle kernel_settings.

   1. Créez un nouveau fichier YAML et ouvrez-le dans un éditeur de texte, par exemple :

      #  vi /home/jdoe/<ansible_project_name>/kernel-roles.yml

      Ce fichier représente un playbook et contient généralement une liste ordonnée de tâches, également appelées plays, qui sont exécutées contre des hôtes gérés spécifiques sélectionnés dans votre fichier inventory.

   2. Insérez le contenu suivant dans le fichier :

      ---
      -
        hosts: testingservers
        name: "Configure kernel settings"
        roles:
          - rhel-system-roles.kernel_settings
        vars:
          kernel_settings_sysctl:
            - name: fs.file-max
              value: 400000
            - name: kernel.threads-max
              value: 65536
          kernel_settings_sysfs:
            - name: /sys/class/net/lo/mtu
              value: 65000
          kernel_settings_transparent_hugepages: madvise

      La clé name est facultative. Elle associe une chaîne arbitraire à la pièce en tant qu'étiquette et identifie l'objet de la pièce. La clé hosts de la pièce spécifie les hôtes contre lesquels la pièce est exécutée. La ou les valeurs de cette clé peuvent être fournies sous forme de noms individuels d'hôtes gérés ou de groupes d'hôtes tels que définis dans le fichier inventory.

      La section vars représente une liste de variables contenant les noms des paramètres du noyau sélectionnés et les valeurs auxquelles ils doivent être définis.

      La clé roles spécifie le rôle du système qui va configurer les paramètres et les valeurs mentionnés dans la section vars.

      Note

      Vous pouvez modifier les paramètres du noyau et leurs valeurs dans le playbook en fonction de vos besoins.

4. En option, vérifiez que la syntaxe de votre pièce est correcte.

   #  ansible-playbook --syntax-check kernel-roles.yml
   
   playbook: kernel-roles.yml

   Cet exemple montre la vérification réussie d'un playbook.

5. Exécutez votre cahier des charges.

   #  ansible-playbook kernel-roles.yml
   
   ...
   
   BECOME password:
   
   PLAY [Configure kernel settings] **********************************************************************************
   
   
   
   PLAY RECAP ********************************************************************************************************
   fdoe@192.168.122.226       : ok=10   changed=4    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0
   pdoe@192.168.122.98        : ok=10   changed=4    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0

   Avant qu'Ansible n'exécute votre playbook, vous allez être invité à saisir votre mot de passe afin qu'un utilisateur sur les hôtes gérés puisse être basculé sur root, ce qui est nécessaire pour configurer les paramètres du noyau.

   La section récapitulative montre que la lecture s'est terminée avec succès (failed=0) pour tous les hôtes gérés, et que 4 paramètres du noyau ont été appliqués (changed=4).

6. Redémarrez les hôtes gérés et vérifiez les paramètres du noyau concernés pour vous assurer que les changements ont été appliqués et qu'ils persistent après les redémarrages.

Procédure

1. Créez un coffre-fort pour sauvegarder les informations sensibles :

   $ ansible-vault create secrets.yml
   New Vault password: password
   Confirm New Vault password: password

2. La commande ansible-vault create crée un fichier crypté de l'espace de stockage et l'ouvre dans un éditeur. Saisissez les données sensibles que vous souhaitez enregistrer dans le coffre-fort, par exemple :

   activationKey: activation_key
   username: username
   password: password

3. Enregistrez les modifications et fermez l'éditeur. Ansible crypte les données dans le coffre-fort.

   Vous pouvez ensuite modifier les données dans l'espace de stockage à l'aide de la commande ansible-vault edit secrets.yml pour modifier les données du coffre-fort.

4. Optionnel : Afficher le contenu du coffre-fort :

   $ ansible-vault view secrets.yml

5. Créez un fichier playbook, par exemple ~/registration.yml, et utilisez l'une des options suivantes en fonction de l'action que vous souhaitez effectuer :

   1. Pour s'enregistrer à l'aide d'une clé d'activation et d'un identifiant d'organisation (recommandé), utilisez la procédure suivante :

      ---
      - name: Registering system using activation key and organization ID
        hosts: managed-node-01.example.com
        vars_files:
          - secrets.yml
        vars:
          rhc_auth:
            activation_keys:
              keys:
                -  "{{ activationKey }}"
           rhc_organization: organizationID
        roles:
          - role: rhel-system-roles.rhc

   2. Pour s'enregistrer en utilisant un nom d'utilisateur et un mot de passe, utilisez la procédure suivante :

      ---
      - name: Registering system with username and password
        hosts:  managed-node-01.example.com
        vars_files:
          - secrets.yml
        vars:
          rhc_auth:
            login:
              username: "{{ username }}"
              password: "{{ password }}"
        roles:
          - role: rhel-system-roles.rhc

6. Exécutez le manuel de jeu :

   # ansible-playbook ~/registration.yml --ask-vault-pass

Procédure

1. Créez un coffre-fort pour sauvegarder les informations sensibles :

   $ ansible-vault create secrets.yml
   New Vault password: password
   Confirm New Vault password: password

2. La commande ansible-vault create crée un fichier crypté et l'ouvre dans un éditeur. Saisissez les données sensibles que vous souhaitez enregistrer dans le coffre-fort, par exemple :

   activationKey : activation_key

3. Enregistrez les modifications et fermez l'éditeur. Ansible crypte les données dans le coffre-fort.

   Vous pouvez ensuite modifier les données dans l'espace de stockage à l'aide de la commande ansible-vault edit secrets.yml pour modifier les données du coffre-fort.

4. Optionnel : Afficher le contenu du coffre-fort :

   $ ansible-vault view secrets.yml

5. Créez un fichier playbook, par exemple ~/registration-sat.yml.

6. Utilisez le texte suivant à l'adresse ~/registration-sat.yml pour enregistrer le système à l'aide d'une clé d'activation et d'un identifiant d'organisation :

   ---
   - name: Register to the custom registration server and CDN
     hosts: managed-node-01.example.com
     vars_files:
       - secrets.yml
     vars:
       rhc_auth:
         login:
           activation_keys:
             keys:
               - "{{ activationKey }}"
           rhc_organization: organizationID
       rhc_server:
         hostname: example.com
           port: 443
           prefix: /rhsm
       rhc_baseurl: http://example.com/pulp/content
      roles:
        - role: rhel-system-roles.rhc

7. Exécutez le manuel de jeu :

   # ansible-playbook ~/registration-sat.yml --ask-vault-pass

Procédure

1. Créez un fichier playbook, par exemple ~/dis-insights.yml et ajoutez-y le contenu suivant :

   ---
   - name: Disable Insights connection
     hosts: managed-node-01.example.com
     vars:
       rhc_insights:
         state: absent
     roles:
       - role: rhel-system-roles.rhc

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/dis-insights.yml

Procédure

1. Créez un fichier playbook, par exemple ~/configure-repos.yml:

   1. Pour activer un référentiel :

      ---
      - name: Enable repository
        hosts: managed-node-01.example.com
        vars:
          rhc_repositories:
            - {name: "RepositoryName", state: enabled}
         roles:
           - role: rhel-system-roles.rhc

   2. Pour désactiver un référentiel :

      ---
      - name: Disable repository
        hosts: managed-node-01.example.com
        vars:
          rhc_repositories:
            - {name: "RepositoryName", state: disabled}
         roles:
           - role: rhel-system-roles.rhc

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/configure-repos.yml

Procédure

1. Créez un fichier playbook, par exemple ~/release.yml:

   ---
   - name: Set Release
     hosts: managed-node-01.example.com
     vars:
       rhc_release: "8.6"
     roles:
       - role: rhel-system-roles.rhc

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/release.yml

Procédure

1. Créez un coffre-fort pour sauvegarder les informations sensibles :

   $ ansible-vault create secrets.yml
   New Vault password: password
   Confirm New Vault password: password

2. La commande ansible-vault create crée un fichier crypté et l'ouvre dans un éditeur. Saisissez les données sensibles que vous souhaitez enregistrer dans le coffre-fort, par exemple :

   username: username
   password: password
   proxy_username: proxyusernme
   proxy_password: proxypassword

3. Enregistrez les modifications et fermez l'éditeur. Ansible crypte les données dans le coffre-fort.

   Vous pouvez ensuite modifier les données dans l'espace de stockage à l'aide de la commande ansible-vault edit secrets.yml pour modifier les données du coffre-fort.

4. Optionnel : Afficher le contenu du coffre-fort :

   $ ansible-vault view secrets.yml

5. Créez un fichier playbook, par exemple ~/configure-proxy.yml:

   1. Pour s'inscrire au portail client RHEL en utilisant un proxy :

      ---
      - name: Register using proxy
        hosts: managed-node-01.example.com
        vars_files:
          - secrets.yml
        vars:
          rhc_auth:
            login:
              username: "{{ username }}"
              password: "{{ password }}"
          rhc_proxy:
            hostname: proxy.example.com
            port: 3128
            username: "{{ proxy_username }}"
            password: "{{ proxy_password }}"
        roles:
          - role: rhel-system-roles.rhc

   2. Pour supprimer le serveur proxy de la configuration du service Red Hat Subscription Manager :

      ---
      - name: To stop using proxy server for registration
        hosts: managed-node-01.example.com
        vars_files:
          - secrets.yml
        vars:
          rhc_auth:
            login:
              username: "{{ username }}"
              password: "{{ password }}"
           rhc_proxy: {"state":"absent"}
        roles:
          - role: rhel-system-roles.rhc

6. Exécutez le manuel de jeu :

   # ansible-playbook ~/configure-proxy.yml --ask-vault-pass

Procédure

1. Créez un coffre-fort pour sauvegarder les informations sensibles :

   $ ansible-vault create secrets.yml
   New Vault password: password
   Confirm New Vault password: password

2. La commande ansible-vault create crée un fichier crypté et l'ouvre dans un éditeur. Saisissez les données sensibles que vous souhaitez enregistrer dans le coffre-fort, par exemple :

   username: username
   password: password

3. Enregistrez les modifications et fermez l'éditeur. Ansible crypte les données dans le coffre-fort.

   Vous pouvez ensuite modifier les données dans l'espace de stockage à l'aide de la commande ansible-vault edit secrets.yml pour modifier les données du coffre-fort.

4. Optionnel : Afficher le contenu du coffre-fort :

   $ ansible-vault view secrets.yml

5. Créez un fichier playbook, par exemple ~/auto-update.yml et ajoutez-y le contenu suivant :

   ---
    - name: Disable Red Hat Insights autoupdates
      hosts: managed-node-01.example.com
      vars_files:
        - secrets.yml
      vars:
       rhc_auth:
         login:
           username: "{{ username }}"
           password: "{{ password }}"
       rhc_insights:
          autoupdate: false
          state: present
       roles:
         - role: rhel-system-roles.rhc

6. Exécutez le manuel de jeu :

   # ansible-playbook ~/auto-update.yml --ask-vault-pass

Procédure

1. Pour activer la remédiation, créez un fichier playbook, par exemple ~/remediation.yml:

   ---
   - name: Disable remediation
     hosts: managed-node-01.example.com
     vars:
       rhc_insights:
         remediation: absent
         state: present
     roles:
       - role: rhel-system-roles.rhc

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/remediation.yml

Procédure

1. Créez un coffre-fort pour sauvegarder les informations sensibles :

   $ ansible-vault create secrets.yml
   New Vault password: password
   Confirm New Vault password: password

2. La commande ansible-vault create crée un fichier crypté et l'ouvre dans un éditeur. Saisissez les données sensibles que vous souhaitez enregistrer dans le coffre-fort, par exemple :

   username: username
   password: password

3. Enregistrez les modifications et fermez l'éditeur. Ansible crypte les données dans le coffre-fort.

   Vous pouvez ensuite modifier les données dans l'espace de stockage à l'aide de la commande ansible-vault edit secrets.yml pour modifier les données du coffre-fort.

4. Optionnel : Afficher le contenu du coffre-fort :

   $ ansible-vault view secrets.yml

5. Créez un fichier playbook, par exemple ~/tags.yml, et ajoutez-y le contenu suivant :

   ---
   - name: Creating tags
     hosts: managed-node-01.example.com
     vars_files:
       - secrets.yml
     vars:
       rhc_auth:
         login:
           username: "{{ username }}"
           password: "{{ password }}"
       rhc_insights:
         tags:
           group: group-name-value
             location: location-name-value
             description:
               - RHEL8
               - SAP
              sample_key:value
           state: present
     roles:
       - role: rhel-system-roles.rhc

6. Exécutez le manuel de jeu :

   # ansible-playbook ~/remediation.yml --ask-vault-pass

Procédure

1. Pour annuler l'enregistrement, créez un fichier playbook, par exemple ~/unregister.yml, et ajoutez-y le contenu suivant :

   ---
   - name: Unregister the system
     hosts: managed-node-01.example.com
     vars:
       rhc_state: absent
     roles:
       - role: rhel-system-roles.rhc

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/unregister.yml

Procédure

1. Créez un fichier playbook, par exemple ~/ethernet-static-IP.ymlavec le contenu suivant :

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
     - name: Configure an Ethernet connection with static IP
       include_role:
         name: rhel-system-roles.network
   
       vars:
         network_connections:
           - name: enp7s0
             interface_name: enp7s0
             type: ethernet
             autoconnect: yes
             ip:
               address:
                 - 192.0.2.1/24
                 - 2001:db8:1::1/64
               gateway4: 192.0.2.254
               gateway6: 2001:db8:1::fffe
               dns:
                 - 192.0.2.200
                 - 2001:db8:1::ffbb
               dns_search:
                 - example.com
             state: up

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/ethernet-static-IP.yml

Procédure

1. Créez un fichier playbook, par exemple ~/ethernet-static-IP.ymlavec le contenu suivant :

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
     - name: Configure an Ethernet connection with static IP
       include_role:
         name: rhel-system-roles.network
   
       vars:
         network_connections:
           - name: example
             match:
               path:
                 - pci-0000:00:0[1-3].0
                 - &!pci-0000:00:02.0
             type: ethernet
             autoconnect: yes
             ip:
               address:
                 - 192.0.2.1/24
                 - 2001:db8:1::1/64
               gateway4: 192.0.2.254
               gateway6: 2001:db8:1::fffe
               dns:
                 - 192.0.2.200
                 - 2001:db8:1::ffbb
               dns_search:
                 - example.com
             state: up

   Le paramètre match dans cet exemple définit qu'Ansible applique la pièce aux périphériques qui correspondent à l'ID PCI 0000:00:0[1-3].0, mais pas à 0000:00:02.0. Pour plus de détails sur les modificateurs spéciaux et les jokers que vous pouvez utiliser, consultez la description du paramètre match dans le fichier /usr/share/ansible/roles/rhel-system-roles.network/README.md.

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/ethernet-static-IP.yml

Procédure

1. Créez un fichier playbook, par exemple ~/ethernet-dynamic-IP.ymlavec le contenu suivant :

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
     - name: Configure an Ethernet connection with dynamic IP
       include_role:
         name: rhel-system-roles.network
   
       vars:
         network_connections:
           - name: enp7s0
             interface_name: enp7s0
             type: ethernet
             autoconnect: yes
             ip:
               dhcp4: yes
               auto6: yes
             state: up

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/ethernet-dynamic-IP.yml

Procédure

1. Créez un fichier playbook, par exemple ~/ethernet-dynamic-IP.ymlavec le contenu suivant :

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
     - name: Configure an Ethernet connection with dynamic IP
       include_role:
         name: rhel-system-roles.network
   
       vars:
         network_connections:
           - name: example
             match:
               path:
                 - pci-0000:00:0[1-3].0
                 - &!pci-0000:00:02.0
             type: ethernet
             autoconnect: yes
             ip:
               dhcp4: yes
               auto6: yes
             state: up

   Le paramètre match dans cet exemple définit qu'Ansible applique la pièce aux périphériques qui correspondent à l'ID PCI 0000:00:0[1-3].0, mais pas à 0000:00:02.0. Pour plus de détails sur les modificateurs spéciaux et les jokers que vous pouvez utiliser, consultez la description du paramètre match dans le fichier /usr/share/ansible/roles/rhel-system-roles.network/README.md.

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/ethernet-dynamic-IP.yml

Procédure

1. Créez un fichier playbook, par exemple ~/vlan-ethernet.ymlavec le contenu suivant :

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
     - name: Configure a VLAN that uses an Ethernet connection
       include_role:
         name: rhel-system-roles.network
   
       vars:
         network_connections:
           # Add an Ethernet profile for the underlying device of the VLAN
           - name: enp1s0
             type: ethernet
             interface_name: enp1s0
             autoconnect: yes
             state: up
             ip:
               dhcp4: no
               auto6: no
   
           # Define the VLAN profile
           - name: enp1s0.10
             type: vlan
             ip:
               address:
                 - "192.0.2.1/24"
                 - "2001:db8:1::1/64"
               gateway4: 192.0.2.254
               gateway6: 2001:db8:1::fffe
               dns:
                 - 192.0.2.200
                 - 2001:db8:1::ffbb
               dns_search:
                 - example.com
             vlan_id: 10
             parent: enp1s0
             state: up

   L'attribut parent du profil VLAN configure le VLAN pour qu'il fonctionne au-dessus du dispositif enp1s0.

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/vlan-ethernet.yml

Procédure

1. Créez un fichier playbook, par exemple ~/bridge-ethernet.ymlavec le contenu suivant :

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
     - name: Configure a network bridge that uses two Ethernet ports
       include_role:
         name: rhel-system-roles.network
   
       vars:
         network_connections:
           # Define the bridge profile
           - name: bridge0
             type: bridge
             interface_name: bridge0
             ip:
               address:
                 - "192.0.2.1/24"
                 - "2001:db8:1::1/64"
               gateway4: 192.0.2.254
               gateway6: 2001:db8:1::fffe
               dns:
                 - 192.0.2.200
                 - 2001:db8:1::ffbb
               dns_search:
                 - example.com
             state: up
   
           # Add an Ethernet profile to the bridge
           - name: bridge0-port1
             interface_name: enp7s0
             type: ethernet
             controller: bridge0
             port_type: bridge
             state: up
   
           # Add a second Ethernet profile to the bridge
           - name: bridge0-port2
             interface_name: enp8s0
             type: ethernet
             controller: bridge0
             port_type: bridge
             state: up

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/bridge-ethernet.yml

Procédure

1. Créez un fichier playbook, par exemple ~/bond-ethernet.ymlavec le contenu suivant :

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
     - name: Configure a network bond that uses two Ethernet ports
       include_role:
         name: rhel-system-roles.network
   
       vars:
         network_connections:
           # Define the bond profile
           - name: bond0
             type: bond
             interface_name: bond0
             ip:
               address:
                 - "192.0.2.1/24"
                 - "2001:db8:1::1/64"
               gateway4: 192.0.2.254
               gateway6: 2001:db8:1::fffe
               dns:
                 - 192.0.2.200
                 - 2001:db8:1::ffbb
               dns_search:
                 - example.com
             bond:
               mode: active-backup
             state: up
   
           # Add an Ethernet profile to the bond
           - name: bond0-port1
             interface_name: enp7s0
             type: ethernet
             controller: bond0
             state: up
   
           # Add a second Ethernet profile to the bond
           - name: bond0-port2
             interface_name: enp8s0
             type: ethernet
             controller: bond0
             state: up

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/bond-ethernet.yml

Procédure

1. Créez un fichier playbook, par exemple ~/IPoIB.ymlavec le contenu suivant :

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
     - name: Configure IPoIB
       include_role:
         name: rhel-system-roles.network
   
       vars:
         network_connections:
   
           # InfiniBand connection mlx4_ib0
           - name: mlx4_ib0
             interface_name: mlx4_ib0
             type: infiniband
   
           # IPoIB device mlx4_ib0.8002 on top of mlx4_ib0
           - name: mlx4_ib0.8002
             type: infiniband
             autoconnect: yes
             infiniband:
               p_key: 0x8002
               transport_mode: datagram
             parent: mlx4_ib0
             ip:
               address:
                 - 192.0.2.1/24
                 - 2001:db8:1::1/64
             state: up

   Si vous définissez un paramètre p_key comme dans cet exemple, ne définissez pas de paramètre interface_name sur le périphérique IPoIB.

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/IPoIB.yml

Vérification

1. Sur l'hôte managed-node-01.example.com, affichez les paramètres IP du périphérique mlx4_ib0.8002:

   # ip address show mlx4_ib0.8002
   ...
   inet 192.0.2.1/24 brd 192.0.2.255 scope global noprefixroute ib0.8002
      valid_lft forever preferred_lft forever
   inet6 2001:db8:1::1/64 scope link tentative noprefixroute
      valid_lft forever preferred_lft forever

2. Affichez la clé de partition (P_Key) de l'appareil mlx4_ib0.8002:

   # cat /sys/class/net/mlx4_ib0.8002/pkey
   0x8002

3. Affiche le mode de l'appareil mlx4_ib0.8002:

   # cat /sys/class/net/mlx4_ib0.8002/mode
   datagram

Procédure

1. Créez un fichier playbook, par exemple ~/pbr.yml, avec le contenu suivant :

   ---
   - name: Configuring policy-based routing
     hosts: managed-node-01.example.com
     tasks:
     - name: Routing traffic from a specific subnet to a different default gateway
       include_role:
         name: rhel-system-roles.network
   
       vars:
         network_connections:
           - name: Provider-A
             interface_name: enp7s0
             type: ethernet
             autoconnect: True
             ip:
               address:
                 - 198.51.100.1/30
               gateway4: 198.51.100.2
               dns:
                 - 198.51.100.200
             state: up
             zone: external
   
           - name: Provider-B
             interface_name: enp1s0
             type: ethernet
             autoconnect: True
             ip:
               address:
                 - 192.0.2.1/30
               route:
                 - network: 0.0.0.0
                   prefix: 0
                   gateway: 192.0.2.2
                   table: 5000
             state: up
             zone: external
   
           - name: Internal-Workstations
             interface_name: enp8s0
             type: ethernet
             autoconnect: True
             ip:
               address:
                 - 10.0.0.1/24
               route:
                 - network: 10.0.0.0
                   prefix: 24
                   table: 5000
               routing_rule:
                 - priority: 5
                   from: 10.0.0.0/24
                   table: 5000
             state: up
             zone: trusted
   
           - name: Servers
             interface_name: enp9s0
             type: ethernet
             autoconnect: True
             ip:
               address:
                 - 203.0.113.1/24
             state: up
             zone: trusted

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/pbr.yml

Vérification

1. Sur un hôte RHEL dans le sous-réseau des stations de travail internes :

   1. Installez le paquetage traceroute:

      # dnf install traceroute

   2. Utilisez l'utilitaire traceroute pour afficher l'itinéraire vers un hôte sur Internet :

      # traceroute redhat.com
      traceroute to redhat.com (209.132.183.105), 30 hops max, 60 byte packets
       1  10.0.0.1 (10.0.0.1)     0.337 ms  0.260 ms  0.223 ms
       2  192.0.2.1 (192.0.2.1)   0.884 ms  1.066 ms  1.248 ms
       ...

      La sortie de la commande indique que le routeur envoie des paquets sur 192.0.2.1, qui est le réseau du fournisseur B.

2. Sur un hôte RHEL dans le sous-réseau du serveur :

   1. Installez le paquetage traceroute:

      # dnf install traceroute

   2. Utilisez l'utilitaire traceroute pour afficher l'itinéraire vers un hôte sur Internet :

      # traceroute redhat.com
      traceroute to redhat.com (209.132.183.105), 30 hops max, 60 byte packets
       1  203.0.113.1 (203.0.113.1)    2.179 ms  2.073 ms  1.944 ms
       2  198.51.100.2 (198.51.100.2)  1.868 ms  1.798 ms  1.549 ms
       ...

      La sortie de la commande indique que le routeur envoie des paquets sur 198.51.100.2, qui est le réseau du fournisseur A.

3. Sur le routeur RHEL que vous avez configuré à l'aide du rôle de système RHEL :

   1. Affichez la liste des règles :

      # ip rule list
      0:      from all lookup local
      5:    from 10.0.0.0/24 lookup 5000
      32766:  from all lookup main
      32767:  from all lookup default

      Par défaut, RHEL contient des règles pour les tables local, main, et default.

   2. Afficher les itinéraires dans la table 5000:

      # ip route list table 5000
      0.0.0.0/0 via 192.0.2.2 dev enp1s0 proto static metric 100
      10.0.0.0/24 dev enp8s0 proto static scope link src 192.0.2.1 metric 102

   3. Affichez les interfaces et les zones de pare-feu :

      # firewall-cmd --get-active-zones
      external
        interfaces: enp1s0 enp7s0
      trusted
        interfaces: enp8s0 enp9s0

   4. Vérifiez que le masquage est activé dans la zone external:

      # firewall-cmd --info-zone=external
      external (active)
        target: default
        icmp-block-inversion: no
        interfaces: enp1s0 enp7s0
        sources:
        services: ssh
        ports:
        protocols:
        masquerade: yes
        ...

Procédure

1. Créez un fichier playbook, par exemple ~/enable-802.1x.ymlavec le contenu suivant :

   ---
   - name: Configure an Ethernet connection with 802.1X authentication
     hosts: managed-node-01.example.com
     tasks:
       - name: Copy client key for 802.1X authentication
         copy:
           src: "/srv/data/client.key"
           dest: "/etc/pki/tls/private/client.key"
           mode: 0600
   
       - name: Copy client certificate for 802.1X authentication
         copy:
           src: "/srv/data/client.crt"
           dest: "/etc/pki/tls/certs/client.crt"
   
       - name: Copy CA certificate for 802.1X authentication
         copy:
           src: "/srv/data/ca.crt"
           dest: "/etc/pki/ca-trust/source/anchors/ca.crt"
   
       - include_role:
           name: rhel-system-roles.network
   
         vars:
           network_connections:
             - name: enp1s0
               type: ethernet
               autoconnect: yes
               ip:
                 address:
                   - 192.0.2.1/24
                   - 2001:db8:1::1/64
                 gateway4: 192.0.2.254
                 gateway6: 2001:db8:1::fffe
                 dns:
                   - 192.0.2.200
                   - 2001:db8:1::ffbb
                 dns_search:
                   - example.com
               ieee802_1x:
                 identity: user_name
                 eap: tls
                 private_key: "/etc/pki/tls/private/client.key"
                 private_key_password: "password"
                 client_cert: "/etc/pki/tls/certs/client.crt"
                 ca_cert: "/etc/pki/ca-trust/source/anchors/ca.crt"
                 domain_suffix_match: example.com
               state: up

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/enable-802.1x.yml

Procédure

1. Créez un fichier playbook, par exemple ~/enable-802.1x.ymlavec le contenu suivant :

   ---
   - name: Configure a wifi connection with 802.1X authentication
     hosts: managed-node-01.example.com
     tasks:
       - name: Copy client key for 802.1X authentication
         copy:
           src: "/srv/data/client.key"
           dest: "/etc/pki/tls/private/client.key"
           mode: 0400
   
       - name: Copy client certificate for 802.1X authentication
         copy:
           src: "/srv/data/client.crt"
           dest: "/etc/pki/tls/certs/client.crt"
   
       - name: Copy CA certificate for 802.1X authentication
         copy:
           src: "/srv/data/ca.crt"
           dest: "/etc/pki/ca-trust/source/anchors/ca.crt"
   
       - block:
           - import_role:
               name: linux-system-roles.network
             vars:
               network_connections:
                 - name: Configure the Example-wifi profile
                   interface_name: wlp1s0
                   state: up
                   type: wireless
                   autoconnect: yes
                   ip:
                     dhcp4: true
                     auto6: true
                   wireless:
                     ssid: "Example-wifi"
                     key_mgmt: "wpa-eap"
                   ieee802_1x:
                     identity: "user_name"
                     eap: tls
                     private_key: "/etc/pki/tls/client.key"
                     private_key_password: "password"
                     private_key_password_flags: none
                     client_cert: "/etc/pki/tls/client.pem"
                     ca_cert: "/etc/pki/tls/cacert.pem"
                     domain_suffix_match: "example.com"

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/enable-802.1x.yml

Procédure

1. Créez un fichier playbook, par exemple ~/ethernet-connection.ymlavec le contenu suivant :

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
     - name: Configure an Ethernet connection with static IP and default gateway
       include_role:
         name: rhel-system-roles.network
   
       vars:
         network_connections:
           - name: enp1s0
             type: ethernet
             autoconnect: yes
             ip:
               address:
                 - 198.51.100.20/24
                 - 2001:db8:1::1/64
               gateway4: 198.51.100.254
               gateway6: 2001:db8:1::fffe
               dns:
                 - 198.51.100.200
                 - 2001:db8:1::ffbb
               dns_search:
                 - example.com
             state: up

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/ethernet-connection.yml

Procédure

1. Créez un fichier playbook, par exemple ~/add-static-routes.ymlavec le contenu suivant :

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
     - name: Configure an Ethernet connection with static IP and additional routes
       include_role:
         name: rhel-system-roles.network
   
       vars:
         network_connections:
           - name: enp7s0
             type: ethernet
             autoconnect: yes
             ip:
               address:
                 - 192.0.2.1/24
                 - 2001:db8:1::1/64
               gateway4: 192.0.2.254
               gateway6: 2001:db8:1::fffe
               dns:
                 - 192.0.2.200
                 - 2001:db8:1::ffbb
               dns_search:
                 - example.com
               route:
                 - network: 198.51.100.0
                   prefix: 24
                   gateway: 192.0.2.10
                 - network: 2001:db8:2::
                   prefix: 64
                   gateway: 2001:db8:1::10
             state: up

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/add-static-routes.yml

Vérification

1. Sur les nœuds gérés :

   1. Afficher les itinéraires IPv4 :

      # ip -4 route
      ...
      198.51.100.0/24 via 192.0.2.10 dev enp7s0

   2. Afficher les itinéraires IPv6 :

      # ip -6 route
      ...
      2001:db8:2::/64 via 2001:db8:1::10 dev enp7s0 metric 1024 pref medium

Procédure

1. Créez un fichier playbook, par exemple ~/configure-ethernet-device-with-ethtool-features.ymlavec le contenu suivant :

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
     - name: Configure an Ethernet connection with ethtool features
       include_role:
         name: rhel-system-roles.network
   
       vars:
         network_connections:
           - name: enp1s0
             type: ethernet
             autoconnect: yes
             ip:
               address:
                 - 198.51.100.20/24
                 - 2001:db8:1::1/64
               gateway4: 198.51.100.254
               gateway6: 2001:db8:1::fffe
               dns:
                 - 198.51.100.200
                 - 2001:db8:1::ffbb
               dns_search:
                 - example.com
             ethtool:
               features:
                 gro: "no"
                 gso: "yes"
                 tx_sctp_segmentation: "no"
             state: up

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/configure-ethernet-device-with-ethtool-features.yml

Procédure

1. Créez un fichier playbook, par exemple ~/reset-firewalld.ymlavec le contenu suivant :

   ---
   - name: Reset firewalld example
     hosts: managed-node-01.example.com
     tasks:
     - name: Reset firewalld
       include_role:
         name: rhel-system-roles.firewall
   
       vars:
         firewall:
           - previous: replaced

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/configuring-a-dmz.yml

Procédure

1. Créez un fichier playbook, par exemple ~/port_forwarding.ymlavec le contenu suivant :

   ---
   - name: Configure firewalld
     hosts: managed-node-01.example.com
     tasks:
     - name: Forward incoming traffic on port 8080 to 443
       include_role:
         name: rhel-system-roles.firewall
   
       vars:
         firewall:
           - { forward_port: 8080/tcp;443;, state: enabled, runtime: true, permanent: true }

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/port_forwarding.yml

Procédure

1. Créez un fichier playbook, par exemple ~/opening-a-port.ymlavec le contenu suivant :

   ---
   - name: Configure firewalld
     hosts: managed-node-01.example.com
     tasks:
     - name: Allow incoming HTTPS traffic to the local host
       include_role:
         name: rhel-system-roles.firewall
   
       vars:
         firewall:
           - port: 443/tcp
             service: http
             state: enabled
             runtime: true
             permanent: true

   L'option permanent: true rend les nouveaux paramètres persistants à travers les redémarrages.

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/opening-a-port.yml

Procédure

1. Créez un fichier playbook, par exemple ~/configuring-a-dmz.ymlavec le contenu suivant :

   ---
   - name: Configure firewalld
     hosts: managed-node-01.example.com
     tasks:
     - name: Creating a DMZ with access to HTTPS port and masquerading for hosts in DMZ
       include_role:
         name: rhel-system-roles.firewall
   
       vars:
         firewall:
           - zone: dmz
             interface: enp1s0
             service: https
             state: enabled
             runtime: true
             permanent: true

2. Exécutez le manuel de jeu :

   # ansible-playbook ~/configuring-a-dmz.yml

Procédure

1. Préparez votre playbook. Vous pouvez partir de zéro ou modifier le playbook d'exemple installé avec le paquetage rhel-system-roles:

   # cp /usr/share/doc/rhel-system-roles/selinux/example-selinux-playbook.yml my-selinux-playbook.yml
   # vi my-selinux-playbook.yml

2. Modifiez le contenu du playbook pour l'adapter à votre scénario. Par exemple, la partie suivante garantit que le système installe et active le module SELinux selinux-local-1.pp:

   selinux_modules:
   - { path: "selinux-local-1.pp", priority: "400" }

3. Enregistrez les modifications et quittez l'éditeur de texte.

4. Exécutez votre manuel de jeu sur les systèmes host1, host2 et host3:

   # ansible-playbook -i host1,host2,host3 my-selinux-playbook.yml

Procédure

1. Créez un cahier de jeu qui définit le rôle requis :

   1. Créez un nouveau fichier YAML et ouvrez-le dans un éditeur de texte, par exemple :

      # vi logging-playbook.yml

   2. Insérer le contenu suivant :

      ---
      - name: Deploying basics input and implicit files output
        hosts: all
        roles:
          - rhel-system-roles.logging
        vars:
          logging_inputs:
            - name: system_input
              type: basics
          logging_outputs:
            - name: files_output
              type: files
          logging_flows:
            - name: flow1
              inputs: [system_input]
              outputs: [files_output]

2. Exécuter le manuel de jeu sur un inventaire spécifique :

   # ansible-playbook -i inventory-file /path/to/file/logging-playbook.yml

   Où ?

   • inventory-file est le fichier d'inventaire.
   • logging-playbook.yml est le manuel de jeu que vous utilisez.

Vérification

1. Tester la syntaxe du fichier /etc/rsyslog.conf:

   # rsyslogd -N 1
   rsyslogd: version 8.1911.0-6.el8, config validation run...
   rsyslogd: End of config validation run. Bye.

2. Vérifiez que le système envoie des messages au journal :

   1. Envoyer un message test :

      # logger test

   2. Consultez le journal /var/log/messages, par exemple :

      # cat /var/log/messages
      Aug  5 13:48:31 hostname root[6778]: test

      Où `hostname` est le nom d'hôte du système client. Notez que le journal contient le nom de l'utilisateur qui a entré la commande de l'enregistreur, dans ce cas root.

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   ---
   - name: Deploying files input and configured files output
     hosts: all
     roles:
       - linux-system-roles.logging
     vars:
       logging_inputs:
         - name: files_input
           type: basics
       logging_outputs:
         - name: files_output0
           type: files
           property: msg
           property_op: contains
           property_value: error
           path: /var/log/errors.log
         - name: files_output1
           type: files
           property: msg
           property_op: "!contains"
           property_value: error
           path: /var/log/others.log
       logging_flows:
         - name: flow0
           inputs: [files_input]
           outputs: [files_output0, files_output1]

   Avec cette configuration, tous les messages contenant la chaîne error sont enregistrés dans /var/log/errors.log, et tous les autres messages sont enregistrés dans /var/log/others.log.

   Vous pouvez remplacer la valeur de la propriété error par la chaîne de caractères par laquelle vous souhaitez filtrer.

   Vous pouvez modifier les variables selon vos préférences.

2. Facultatif : Vérifier la syntaxe du playbook.

   # ansible-playbook --syntax-check playbook.yml

3. Exécutez le playbook sur votre fichier d'inventaire :

   # ansible-playbook -i inventory_file /path/to/file/playbook.yml

Vérification

1. Tester la syntaxe du fichier /etc/rsyslog.conf:

   # rsyslogd -N 1
   rsyslogd: version 8.1911.0-6.el8, config validation run...
   rsyslogd: End of config validation run. Bye.

2. Vérifiez que le système envoie au journal les messages contenant la chaîne error:

   1. Envoyer un message test :

      # logger error

   2. Consultez le journal /var/log/errors.log, par exemple :

      # cat /var/log/errors.log
      Aug  5 13:48:31 hostname root[6778]: error

      Où hostname est le nom d'hôte du système client. Notez que le journal contient le nom de l'utilisateur qui a entré la commande logger, dans ce cas root.

Procédure

1. Créez un cahier de jeu qui définit le rôle requis :

   1. Créez un nouveau fichier YAML et ouvrez-le dans un éditeur de texte, par exemple :

      # vi logging-playbook.yml

   2. Insérez le contenu suivant dans le fichier :

      ---
      - name: Deploying remote input and remote_files output
        hosts: server
        roles:
          - rhel-system-roles.logging
        vars:
          logging_inputs:
            - name: remote_udp_input
              type: remote
              udp_ports: [ 601 ]
            - name: remote_tcp_input
              type: remote
              tcp_ports: [ 601 ]
          logging_outputs:
            - name: remote_files_output
              type: remote_files
          logging_flows:
            - name: flow_0
              inputs: [remote_udp_input, remote_tcp_input]
              outputs: [remote_files_output]
      
      - name: Deploying basics input and forwards output
        hosts: clients
        roles:
          - rhel-system-roles.logging
        vars:
          logging_inputs:
            - name: basic_input
              type: basics
          logging_outputs:
            - name: forward_output0
              type: forwards
              severity: info
              target: _host1.example.com_
              udp_port: 601
            - name: forward_output1
              type: forwards
              facility: mail
              target: _host1.example.com_
              tcp_port: 601
          logging_flows:
            - name: flows0
              inputs: [basic_input]
              outputs: [forward_output0, forward_output1]
      
      [basic_input]
      [forward_output0, forward_output1]

      Où host1.example.com est le serveur de journalisation.

      Note

      Vous pouvez modifier les paramètres du cahier de jeu en fonction de vos besoins.

      Avertissement

      La solution de journalisation ne fonctionne qu'avec les ports définis dans la politique SELinux du serveur ou du système client et ouverts dans le pare-feu. La stratégie SELinux par défaut inclut les ports 601, 514, 6514, 10514 et 20514. Pour utiliser un autre port, modifiez la stratégie SELinux sur les systèmes client et serveur.

2. Créez un fichier d'inventaire qui répertorie vos serveurs et vos clients :

   1. Créez un nouveau fichier et ouvrez-le dans un éditeur de texte, par exemple :

      # vi inventory.ini

   2. Insérez le contenu suivant dans le fichier d'inventaire :

      [servers]
      server ansible_host=host1.example.com
      [clients]
      client ansible_host=host2.example.com

      Où ?

      • host1.example.com est le serveur de journalisation.
      • host2.example.com est le client de journalisation.

3. Exécutez le manuel de jeu sur votre inventaire.

   # ansible-playbook -i /path/to/file/inventory.ini /path/to/file/_logging-playbook.yml

   Où ?

   • inventory.ini est le fichier d'inventaire.
   • logging-playbook.yml est le cahier de jeu que vous avez créé.

Vérification

1. Sur le système client et le système serveur, testez la syntaxe du fichier /etc/rsyslog.conf:

   # rsyslogd -N 1
   rsyslogd: version 8.1911.0-6.el8, config validation run (level 1), master config /etc/rsyslog.conf
   rsyslogd: End of config validation run. Bye.

2. Vérifiez que le système client envoie des messages au serveur :

   1. Sur le système client, envoyez un message de test :

      # logger test

   2. Sur le système serveur, affichez le journal /var/log/messages, par exemple :

      # cat /var/log/messages
      Aug  5 13:48:31 host2.example.com root[6778]: test

      Où host2.example.com est le nom d'hôte du système client. Notez que le journal contient le nom de l'utilisateur qui a entré la commande logger, dans ce cas root.

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   ---
   - hosts: all
     vars:
       journald_persistent: true
       journald_max_disk_size: 2048
       journald_per_user: true
       journald_sync_interval: 1
     roles:
       - linux-system-roles.journald
   ---

   Par conséquent, le service journald stocke vos journaux de manière persistante sur un disque d'une taille maximale de 2048 Mo, et conserve les données des journaux séparément pour chaque utilisateur. La synchronisation a lieu toutes les minutes.

2. Facultatif : Vérifier la syntaxe du playbook.

   # ansible-playbook --syntax-check playbook.yml -i inventory_file

3. Exécutez le playbook sur votre fichier d'inventaire :

   # ansible-playbook -i inventory_file /path/to/file/playbook.yml

Procédure

1. Copiez l'exemple de playbook pour le rôle de système sshd:

   # cp /usr/share/doc/rhel-system-roles/sshd/example-root-login-playbook.yml path/custom-playbook.yml

2. Ouvrez le playbook copié en utilisant un éditeur de texte, par exemple :

   # vim path/custom-playbook.yml
   
   ---
   - hosts: all
     tasks:
     - name: Configure sshd to prevent root and password login except from particular subnet
       include_role:
         name: rhel-system-roles.sshd
       vars:
         sshd:
           # root login and password login is enabled only from a particular subnet
           PermitRootLogin: no
           PasswordAuthentication: no
           Match:
           - Condition: "Address 192.0.2.0/24"
             PermitRootLogin: yes
             PasswordAuthentication: yes

   Le playbook configure le nœud géré en tant que serveur SSH configuré de telle sorte que :

   • et le login de l'utilisateur root est désactivé
   • et root n'est possible qu'à partir du sous-réseau 192.0.2.0/24

   Vous pouvez modifier les variables en fonction de vos préférences. Pour plus de détails, voir Variables de rôle du système du serveur SSH.

3. Facultatif : Vérifier la syntaxe du playbook.

   # ansible-playbook --syntax-check path/custom-playbook.yml

4. Exécutez le playbook sur votre fichier d'inventaire :

   # ansible-playbook -i inventory_file path/custom-playbook.yml
   
   ...
   
   PLAY RECAP
   **************************************************
   
   localhost : ok=12 changed=2 unreachable=0 failed=0
   skipped=10 rescued=0 ignored=0

Vérification

1. Connectez-vous au serveur SSH :

   $ ssh user1@10.1.1.1

   Où ?

   • user1 est un utilisateur du serveur SSH.
   • 10.1.1.1 est l'adresse IP du serveur SSH.

2. Vérifiez le contenu du fichier sshd_config sur le serveur SSH :

   $ cat /etc/ssh/sshd_config.d/00-ansible_system_role.conf
   #
   # Ansible managed
   #
   PasswordAuthentication no
   PermitRootLogin no
   Match Address 192.0.2.0/24
     PasswordAuthentication yes
     PermitRootLogin yes

3. Vérifiez que vous pouvez vous connecter au serveur en tant que root depuis le sous-réseau 192.0.2.0/24:

   1. Déterminez votre adresse IP :

      $ hostname -I
      192.0.2.1

      Si l'adresse IP se situe dans la plage 192.0.2.1 - 192.0.2.254, vous pouvez vous connecter au serveur.

   2. Se connecter au serveur en tant que root:

      $ ssh root@10.1.1.1

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   ---
   - hosts: all
     tasks:
     - name: "Configure ssh clients"
       include_role:
         name: rhel-system-roles.ssh
       vars:
         ssh_user: root
         ssh:
           Compression: true
           GSSAPIAuthentication: no
           ControlMaster: auto
           ControlPath: ~/.ssh/.cm%C
           Host:
             - Condition: example
               Hostname: example.com
               User: user1
         ssh_ForwardX11: no

   Ce playbook configure les préférences du client SSH de l'utilisateur root sur les nœuds gérés avec les configurations suivantes :

   • La compression est activée.
   • Le multiplexage ControlMaster est réglé sur auto.
   • L'alias example pour se connecter à l'hôte example.com est user1.
   • L'alias example l'alias de l'hôte est créé, ce qui représente une connexion à l'hôte example.com hôte avec le user1 nom d'utilisateur.
   • Le transfert X11 est désactivé.

   En option, vous pouvez modifier ces variables selon vos préférences. Pour plus de détails, voir ssh System Role variables.

2. Facultatif : Vérifier la syntaxe du playbook.

   # ansible-playbook --syntax-check path/custom-playbook.yml

3. Exécutez le playbook sur votre fichier d'inventaire :

   # ansible-playbook -i inventory_file path/custom-playbook.yml

Procédure

1. Ajoutez un extrait de configuration avec la variable sshd_config_file au playbook :

   ---
   - hosts: all
     tasks:
     - name: <Configure sshd to accept some useful environment variables>
       include_role:
         name: rhel-system-roles.sshd
       vars:
         sshd_config_file: /etc/ssh/sshd_config.d/<42-my-application>.conf
         sshd:
           # Environment variables to accept
           AcceptEnv:
             LANG
             LS_COLORS
             EDITOR

   Dans la variable sshd_config_file, définissez le fichier .conf dans lequel le rôle de système sshd écrit les options de configuration.

   Utilisez un préfixe à deux chiffres, par exemple 42- pour spécifier l'ordre dans lequel les fichiers de configuration seront appliqués.

   Lorsque vous appliquez le playbook à l'inventaire, le rôle ajoute les options de configuration suivantes au fichier défini par la variable sshd_config_file.

   # Ansible managed
   #
   AcceptEnv LANG LS_COLORS EDITOR

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   - name: Host to host VPN
     hosts: managed_node1, managed_node2
     roles:
       - rhel-system-roles.vpn
     vars:
       vpn_connections:
         - hosts:
             managed_node1:
             managed_node2:
       vpn_manage_firewall: true
       vpn_manage_selinux: true

   Ce playbook configure la connexion managed_node1-to-managed_node2 en utilisant l'authentification par clé pré-partagée avec des clés générées automatiquement par le rôle système. Puisque vpn_manage_firewall et vpn_manage_selinux sont tous deux définis sur true, le rôle vpn utilisera les rôles firewall et selinux pour gérer les ports utilisés par le rôle vpn.

2. Facultatif : Configurez les connexions entre les hôtes gérés et les hôtes externes qui ne sont pas répertoriés dans le fichier d'inventaire en ajoutant la section suivante à la liste d'hôtes vpn_connections:

       vpn_connections:
         - hosts:
             managed_node1:
             managed_node2:
             external_node:
               hostname: 192.0.2.2

   Cela permet de configurer deux connexions supplémentaires : managed_node1-to-external_node et managed_node2-to-external_node.

1. Facultatif : vous pouvez spécifier plusieurs connexions VPN pour les nœuds gérés en utilisant des sections supplémentaires dans vpn_connections, par exemple un plan de contrôle et un plan de données :

   - name: Multiple VPN
     hosts: managed_node1, managed_node2
     roles:
       - rhel-system-roles.vpn
     vars:
       vpn_connections:
         - name: control_plane_vpn
           hosts:
             managed_node1:
               hostname: 192.0.2.0 # IP for the control plane
             managed_node2:
               hostname: 192.0.2.1
         - name: data_plane_vpn
           hosts:
             managed_node1:
               hostname: 10.0.0.1 # IP for the data plane
             managed_node2:
               hostname: 10.0.0.2

2. Facultatif : vous pouvez modifier les variables selon vos préférences. Pour plus de détails, voir le fichier /usr/share/doc/rhel-system-roles/vpn/README.md.

3. Facultatif : Vérifier la syntaxe du playbook.

   # ansible-playbook --syntax-check /path/to/file/playbook.yml -i /path/to/file/inventory_file

4. Exécutez le playbook sur votre fichier d'inventaire :

   # ansible-playbook -i /path/to/file/inventory_file /path/to/file/playbook.yml

Vérification

1. Sur les nœuds gérés, confirmez que la connexion est chargée avec succès :

   # ipsec status | grep connection.name

   Remplacez connection.name par le nom de la connexion de ce nœud, par exemple managed_node1-to-managed_node2.

1. Sur les nœuds gérés, confirmez que la connexion a été lancée avec succès :

   # ipsec trafficstatus | grep connection.name

2. Facultatif : si une connexion n'a pas été chargée avec succès, ajoutez-la manuellement en entrant la commande suivante. Vous obtiendrez ainsi des informations plus précises sur la raison pour laquelle la connexion n'a pas pu être établie :

   # ipsec auto --add connection.name

   Note

   Toutes les erreurs qui ont pu se produire au cours du processus de chargement et de démarrage de la connexion sont signalées dans les journaux, qui se trouvent à l'adresse /var/log/pluto.log. Comme ces journaux sont difficiles à analyser, essayez d'ajouter manuellement la connexion afin d'obtenir les messages de journaux à partir de la sortie standard à la place.

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   - name: Mesh VPN
     hosts: managed_node1, managed_node2, managed_node3
     roles:
       - rhel-system-roles.vpn
     vars:
       vpn_connections:
         - opportunistic: true
           auth_method: cert
           policies:
             - policy: private
               cidr: default
             - policy: private-or-clear
               cidr: 198.51.100.0/24
             - policy: private
               cidr: 192.0.2.0/24
             - policy: clear
               cidr: 192.0.2.7/32
       vpn_manage_firewall: true
       vpn_manage_selinux: true

   Note

   Puisque vpn_manage_firewall et vpn_manage_selinux sont tous deux définis sur true, le rôle vpn utilisera les rôles firewall et selinux pour gérer les ports utilisés par le rôle vpn.

2. Facultatif : vous pouvez modifier les variables selon vos préférences. Pour plus de détails, voir le fichier /usr/share/doc/rhel-system-roles/vpn/README.md.

3. Facultatif : Vérifier la syntaxe du playbook.

   # ansible-playbook --syntax-check playbook.yml

4. Exécutez le playbook sur votre fichier d'inventaire :

   # ansible-playbook -i inventory_file /path/to/file/playbook.yml

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   ---
   - hosts: all
     tasks:
     - name: Configure crypto policies
       include_role:
         name: rhel-system-roles.crypto_policies
       vars:
         - crypto_policies_policy: FUTURE
         - crypto_policies_reboot_ok: true

   Vous pouvez remplacer la valeur FUTURE par votre politique cryptographique préférée, par exemple : DEFAULT, LEGACY, et FIPS:OSPP.

   La variable crypto_policies_reboot_ok: true provoque le redémarrage du système après que le rôle système a modifié la stratégie cryptographique.

   Pour plus de détails, voir crypto_policies Variables et faits relatifs au rôle du système.

2. Facultatif : Vérifier la syntaxe du playbook.

   # ansible-playbook --syntax-check playbook.yml

3. Exécutez le playbook sur votre fichier d'inventaire :

   # ansible-playbook -i inventory_file playbook.yml

Vérification

1. Sur le nœud de contrôle, créez un autre playbook nommé, par exemple, verify_playbook.yml:

   - hosts: all
     tasks:
    - name: Verify active crypto policy
      include_role:
        name: rhel-system-roles.crypto_policies
   
    - debug:
        var: crypto_policies_active

   Ce playbook ne modifie aucune configuration sur le système, mais signale uniquement la politique active sur les nœuds gérés.

2. Exécutez le playbook sur le même fichier d'inventaire :

   # ansible-playbook -i inventory_file verify_playbook.yml
   
   TASK [debug] **************************
   ok: [host] => {
       "crypto_policies_active": "FUTURE"
   }

   La variable "crypto_policies_active": indique la politique active sur le nœud géré.

Procédure

1. Préparez votre playbook contenant les paramètres des serveurs Tang. Vous pouvez partir de zéro ou utiliser l'un des playbooks d'exemple du répertoire /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/.

   # cp /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/simple_deploy.yml ./my-tang-playbook.yml

2. Modifiez le playbook dans un éditeur de texte de votre choix, par exemple :

   # vi my-tang-playbook.yml

3. Ajoutez les paramètres requis. L'exemple de playbook suivant assure le déploiement de votre serveur Tang et une rotation des clés :

   ---
   - hosts: all
   
     vars:
       nbde_server_rotate_keys: yes
       nbde_server_manage_firewall: true
       nbde_server_manage_selinux: true
   
     roles:
       - rhel-system-roles.nbde_server

   Note

   Puisque nbde_server_manage_firewall et nbde_server_manage_selinux sont tous deux définis sur true, le rôle nbde_server utilisera les rôles firewall et selinux pour gérer les ports utilisés par le rôle nbde_server.

4. Appliquer le manuel de jeu terminé :

   # ansible-playbook -i inventory-file my-tang-playbook.yml

   Where: * inventory-file is the inventory file. * logging-playbook.yml is the playbook you use.

Procédure

1. Préparez votre playbook contenant les paramètres pour les clients Clevis. Vous pouvez partir de zéro ou utiliser l'un des playbooks d'exemple du répertoire /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/.

   # cp /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/high_availability.yml ./my-clevis-playbook.yml

2. Modifiez le playbook dans un éditeur de texte de votre choix, par exemple :

   # vi my-clevis-playbook.yml

3. Ajoutez les paramètres requis. L'exemple suivant configure les clients Clevis pour le déverrouillage automatique de deux volumes cryptés LUKS lorsqu'au moins l'un des deux serveurs Tang est disponible :

   ---
   - hosts: all
   
     vars:
       nbde_client_bindings:
         - device: /dev/rhel/root
           encryption_key_src: /etc/luks/keyfile
           servers:
             - http://server1.example.com
             - http://server2.example.com
         - device: /dev/rhel/swap
           encryption_key_src: /etc/luks/keyfile
           servers:
             - http://server1.example.com
             - http://server2.example.com
   
     roles:
       - rhel-system-roles.nbde_client

4. Appliquer le manuel de jeu terminé :

   # ansible-playbook -i host1,host2,host3 my-clevis-playbook.yml

Procédure

1. Optional: Créer un fichier d'inventaire, par exemple inventory.file:

   $ *touch inventory.file* (toucher le fichier d'inventaire)

2. Ouvrez votre fichier d'inventaire et définissez les hôtes sur lesquels vous souhaitez demander le certificat, par exemple :

   [webserver]
   server.idm.example.com

3. Créez un fichier playbook, par exemple request-certificate.yml:

   • Définissez hosts pour inclure les hôtes sur lesquels vous souhaitez demander le certificat, par exemple webserver.

   • Définissez la variable certificate_requests de manière à ce qu'elle contienne les éléments suivants :

     • Attribuez au paramètre name le nom souhaité pour le certificat, par exemple mycert.
     • Le paramètre dns correspond au domaine à inclure dans le certificat, par exemple *.example.com.
     • Réglez le paramètre ca sur self-sign.

   • Définir le rôle de rhel-system-roles.certificate sous roles.

     Il s'agit du fichier du playbook pour cet exemple :

     ---
     - hosts: webserver
     
       vars:
         certificate_requests:
           - name: mycert
             dns: "*.example.com"
             ca: self-sign
     
       roles:
         - rhel-system-roles.certificate

4. Enregistrer le fichier.

5. Exécutez le manuel de jeu :

   *ansible-playbook -i inventory.file request-certificate.yml* $ *ansible-playbook -i inventory.file request-certificate.yml* $ *ansible-playbook -i inventory.file

Procédure

1. Optional: Créer un fichier d'inventaire, par exemple inventory.file:

   $ *touch inventory.file* (toucher le fichier d'inventaire)

2. Ouvrez votre fichier d'inventaire et définissez les hôtes sur lesquels vous souhaitez demander le certificat, par exemple :

   [webserver]
   server.idm.example.com

3. Créez un fichier playbook, par exemple request-certificate.yml:

   • Définissez hosts pour inclure les hôtes sur lesquels vous souhaitez demander le certificat, par exemple webserver.

   • Définissez la variable certificate_requests de manière à ce qu'elle contienne les éléments suivants :

     • Attribuez au paramètre name le nom souhaité pour le certificat, par exemple mycert.
     • Le paramètre dns correspond au domaine à inclure dans le certificat, par exemple www.example.com.
     • Le paramètre principal indique le principal Kerberos, par exemple HTTP/www.example.com@EXAMPLE.COM.
     • Réglez le paramètre ca sur ipa.

   • Définir le rôle de rhel-system-roles.certificate sous roles.

     Il s'agit du fichier du playbook pour cet exemple :

     ---
     - hosts: webserver
       vars:
         certificate_requests:
           - name: mycert
             dns: www.example.com
             principal: HTTP/www.example.com@EXAMPLE.COM
             ca: ipa
     
       roles:
         - rhel-system-roles.certificate

4. Enregistrer le fichier.

5. Exécutez le manuel de jeu :

   *ansible-playbook -i inventory.file request-certificate.yml* $ *ansible-playbook -i inventory.file request-certificate.yml* $ *ansible-playbook -i inventory.file

Procédure

1. Optional: Créer un fichier d'inventaire, par exemple inventory.file:

   $ *touch inventory.file* (toucher le fichier d'inventaire)

2. Ouvrez votre fichier d'inventaire et définissez les hôtes sur lesquels vous souhaitez demander le certificat, par exemple :

   [webserver]
   server.idm.example.com

3. Créez un fichier playbook, par exemple request-certificate.yml:

   • Définissez hosts pour inclure les hôtes sur lesquels vous souhaitez demander le certificat, par exemple webserver.

   • Définissez la variable certificate_requests de manière à ce qu'elle contienne les éléments suivants :

     • Attribuez au paramètre name le nom souhaité pour le certificat, par exemple mycert.
     • Le paramètre dns correspond au domaine à inclure dans le certificat, par exemple www.example.com.
     • Définissez le paramètre ca en fonction de l'autorité de certification que vous souhaitez utiliser pour émettre le certificat, par exemple self-sign.
     • Attribuez au paramètre run_before la valeur de la commande que vous souhaitez exécuter avant l'émission ou le renouvellement de ce certificat, par exemple systemctl stop httpd.service.
     • Attribuez au paramètre run_after la commande que vous souhaitez exécuter après l'émission ou le renouvellement de ce certificat, par exemple systemctl start httpd.service.

   • Définir le rôle de rhel-system-roles.certificate sous roles.

     Il s'agit du fichier du playbook pour cet exemple :

     ---
     - hosts: webserver
       vars:
         certificate_requests:
           - name: mycert
             dns: www.example.com
             ca: self-sign
             run_before: systemctl stop httpd.service
             run_after: systemctl start httpd.service
     
       roles:
         - rhel-system-roles.certificate

4. Enregistrer le fichier.

5. Exécutez le manuel de jeu :

   *ansible-playbook -i inventory.file request-certificate.yml* $ *ansible-playbook -i inventory.file request-certificate.yml* $ *ansible-playbook -i inventory.file

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   ---
   - hosts: kdump-test
     vars:
       kdump_path: /var/crash
     roles:
       - rhel-system-roles.kdump

2. Facultatif : Vérifier la syntaxe du playbook.

   # ansible-playbook --syntax-check playbook.yml

3. Exécutez le playbook sur votre fichier d'inventaire :

   # ansible-playbook -i inventory_file /path/to/file/playbook.yml

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   ---
   - name: Configure the storage
     hosts: managed-node-01.example.com
     tasks:
     - name: Create a RAID on sdd, sde, sdf, and sdg
       include_role:
         name: rhel-system-roles.storage
       vars:
       storage_safe_mode: false
       storage_volumes:
         - name: data
           type: raid
           disks: [sdd, sde, sdf, sdg]
           raid_level: raid0
           raid_chunk_size: 32 KiB
           mount_point: /mnt/data
           state: present

   Avertissement

   Les noms de périphériques peuvent changer dans certaines circonstances, par exemple lorsque vous ajoutez un nouveau disque à un système. Par conséquent, pour éviter toute perte de données, n'utilisez pas de noms de disques spécifiques dans le guide de lecture.

2. Facultatif : Vérifiez la syntaxe du playbook :

   # ansible-playbook --syntax-check playbook.yml

3. Exécutez le manuel de jeu :

   # ansible-playbook -i inventory.file /path/to/file/playbook.yml

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   - hosts: all
     vars:
       storage_safe_mode: false
       storage_pools:
         - name: my_pool
           type: lvm
           disks: [sdh, sdi]
           raid_level: raid1
           volumes:
             - name: my_pool
               size: "1 GiB"
               mount_point: "/mnt/app/shared"
               fs_type: xfs
               state: present
     roles:
       - name: rhel-system-roles.storage

   Note

   Pour créer un pool LVM avec RAID, vous devez spécifier le type de RAID à l'aide du paramètre raid_level.

2. Facultatif. Vérifier la syntaxe du playbook.

   # ansible-playbook --syntax-check playbook.yml

3. Exécutez le playbook sur votre fichier d'inventaire :

   # ansible-playbook -i inventory.file /path/to/file/playbook.yml

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   - hosts: all
     vars:
       storage_volumes:
         - name: barefs
           type: disk
           disks:
            - sdb
           fs_type: xfs
           fs_label: label-name
           mount_point: /mnt/data
           encryption: true
           encryption_password: your-password
     roles:
      - rhel-system-roles.storage

   Vous pouvez également ajouter les autres paramètres de cryptage tels que encryption_key, encryption_cipher, encryption_key_size, et encryption_luks version dans le fichier playbook.yml.

2. Facultatif : Vérifier la syntaxe du playbook :

   # ansible-playbook --syntax-check playbook.yml

3. Exécutez le playbook sur votre fichier d'inventaire :

   # ansible-playbook -i inventory.file /path/to/file/playbook.yml

Vérification

1. Visualiser l'état du cryptage :

   # cryptsetup status sdb
   
   /dev/mapper/sdb is active and is in use.
   type: LUKS2
   cipher: aes-xts-plain64
   keysize: 512 bits
   key location: keyring
   device: /dev/sdb
   [...]

2. Vérifiez le volume crypté LUKS créé :

   # cryptsetup luksDump /dev/sdb
   
   Version:       	2
   Epoch:         	6
   Metadata area: 	16384 [bytes]
   Keyslots area: 	33521664 [bytes]
   UUID:          	a4c6be82-7347-4a91-a8ad-9479b72c9426
   Label:         	(no label)
   Subsystem:     	(no subsystem)
   Flags:       	allow-discards
   
   Data segments:
     0: crypt
   	offset: 33554432 [bytes]
   	length: (whole device)
   	cipher: aes-xts-plain64
   	sector: 4096 [bytes]
   [...]

3. Consultez les paramètres cryptsetup dans le fichier playbook.yml que le rôle storage prend en charge :

   # cat ~/playbook.yml
   
       - hosts: all
         vars:
           storage_volumes:
             - name: foo
               type: disk
               disks:
                - nvme0n1
               fs_type: xfs
               fs_label: label-name
               mount_point: /mnt/data
               encryption: true
               #encryption_password: passwdpasswd
               encryption_key: /home/passwd_key
               encryption_cipher: aes-xts-plain64
               encryption_key_size: 512
               encryption_luks_version: luks2
   
         roles:
          - rhel-system-roles.storage

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   ---
   - hosts: timesync-test
     vars:
       timesync_ntp_servers:
         - hostname: 2.rhel.pool.ntp.org
           pool: yes
           iburst: yes
     roles:
       - rhel-system-roles.timesync

2. Facultatif : Vérifier la syntaxe du playbook.

   # ansible-playbook --syntax-check playbook.yml

3. Exécutez le playbook sur votre fichier d'inventaire :

   # ansible-playbook -i inventory_file /path/to/file/playbook.yml

Procédure

1. Créer un fichier playbook.yml avec le contenu suivant :

   ---
   - hosts: timesync-test
     vars:
       timesync_ntp_servers:
         - hostname: ptbtime1.ptb.de
           iburst: yes
           nts: yes
     roles:
       - rhel-system-roles.timesync

   ptbtime1.ptb.de est un exemple de serveur public. Vous pouvez utiliser un autre serveur public ou votre propre serveur.

2. Facultatif : Vérifier la syntaxe du playbook.

   # ansible-playbook --syntax-check playbook.yml

3. Exécutez le playbook sur votre fichier d'inventaire :

   # ansible-playbook -i inventory_file /path/to/file/playbook.yml

Vérification

1. Effectuez un test sur la machine cliente :

   # chronyc -N authdata
   
   Name/IP address         Mode KeyID Type KLen Last Atmp  NAK Cook CLen
   =====================================================================
   ptbtime1.ptb.de         NTS     1   15  256  157    0    0    8  100

2. Vérifiez que le nombre de cookies signalés est supérieur à zéro.