Automating system administration by using RHEL system roles

Procedure

1. Create a user named ansible to manage and run playbooks:

   [root@control-node]# useradd ansible

2. Switch to the newly created ansible user:

   [root@control-node]# su - ansible

   Perform the rest of the procedure as this user.

3. Create an SSH public and private key:

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

   Use the suggested default location for the key file.

4. Optional: To prevent Ansible from prompting you for the SSH key password each time you establish a connection, configure an SSH agent.

5. Create the ~/.ansible.cfg file with the following content:

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

   Note

   Settings in the ~/.ansible.cfg file have a higher priority and override settings from the global /etc/ansible/ansible.cfg file.

   With these settings, Ansible performs the following actions:

   • Manages hosts in the specified inventory file.
   • Uses the account set in the remote_user parameter when it establishes SSH connections to managed nodes.
   • Uses the sudo utility to execute tasks on managed nodes as the root user.
   • Prompts for the root password of the remote user every time you apply a playbook. This is recommended for security reasons.

6. Create an ~/inventory file in INI or YAML format that lists the hostnames of managed hosts. You can also define groups of hosts in the inventory file. For example, the following is an inventory file in the INI format with three hosts and one host group named US:

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

   Note that the control node must be able to resolve the hostnames. If the DNS server cannot resolve certain hostnames, add the ansible_host parameter next to the host entry to specify its IP address.

7. Install RHEL system roles:

   • On a RHEL host without Ansible Automation Platform, install the rhel-system-roles package:

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

     This command installs the collections in the /usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/ directory, and the ansible-core package as a dependency.

   • On Ansible Automation Platform, perform the following steps as the ansible user:

     1. Define Red Hat automation hub as the primary source for content in the ~/.ansible.cfg file.

     2. Install the redhat.rhel_system_roles collection from Red Hat automation hub:

        [ansible@control-node]$ ansible-galaxy collection install redhat.rhel_system_roles

        This command installs the collection in the ~/.ansible/collections/ansible_collections/redhat/rhel_system_roles/ directory.

Procedure

1. Create a user named ansible:

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

   The control node later uses this user to establish an SSH connection to this host.

2. Set a password for the ansible user:

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

   You must enter this password when Ansible uses sudo to perform tasks as the root user.

3. Install the ansible user’s SSH public key on the managed node:

   1. Log in to the control node as the ansible user, and copy the SSH public key to the managed node:

      [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. When prompted, connect by entering 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. When prompted, enter the password:

      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. Verify the SSH connection by remotely executing a command on the control node:

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

4. Create a sudo configuration for the ansible user:

   1. Create and edit the /etc/sudoers.d/ansible file by using the visudo command:

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

      The benefit of using visudo over a normal editor is that this utility provides basic checks, such as for parse errors, before installing the file.

   2. Configure a sudoers policy in the /etc/sudoers.d/ansible file that meets your requirements, for example:

      • To grant permissions to the ansible user to run all commands as any user and group on this host after entering the ansible user’s password, use:

        ansible   ALL=(ALL) ALL

      • To grant permissions to the ansible user to run all commands as any user and group on this host without entering the ansible user’s password, use:

        ansible   ALL=(ALL) NOPASSWD: ALL

   Alternatively, configure a more fine-granular policy that matches your security requirements. For further details on sudoers policies, see the sudoers(5) manual page.

Verification

1. Verify that you can execute commands from the control node on an all managed nodes:

   [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"
   }
   ...

   The hard-coded all group dynamically contains all hosts listed in the inventory file.

2. Verify that privilege escalation works correctly by running the whoami utility on all managed nodes by using the Ansible command module:

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

   If the command returns root, you configured sudo on the managed nodes correctly.

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Set boot device to be used on next boot
     hosts: managed-node-01.example.com
     tasks:
       - name: Ensure boot device is HD
         redhat.rhel_mgmt.ipmi_boot:
           user: <admin_user>
           password: <password>
           bootdev: hd

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Power management
     hosts: managed-node-01.example.com
     tasks:
       - name: Ensure machine is powered on
         redhat.rhel_mgmt.ipmi_power:
           user: <admin_user>
           password: <password>
           state: on

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

1. redfish_info: The redfish_info module retrieves information about the remote Out-Of-Band (OOB) controller such as systems inventory.
2. redfish_command: The redfish_command module performs Out-Of-Band (OOB) controller operations like log management and user management, and power operations such as system restart, power on and off.
3. redfish_config: The redfish_config module performs OOB controller operations such as changing OOB configuration, or setting the BIOS configuration.

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Manage out-of-band controllers using Redfish APIs
     hosts: managed-node-01.example.com
     tasks:
       - name: Get CPU inventory
         redhat.rhel_mgmt.redfish_info:
           baseuri: "<URI>"
           username: "<username>"
           password: "<password>"
           category: Systems
           command: GetCpuInventory
         register: result

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Manage out-of-band controllers using Redfish APIs
     hosts: managed-node-01.example.com
     tasks:
       - name: Power on system
         redhat.rhel_mgmt.redfish_command:
           baseuri: "<URI>"
           username: "<username>"
           password: "<password>"
           category: Systems
           command: PowerOn

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Manages out-of-band controllers using Redfish APIs
     hosts: managed-node-01.example.com
     tasks:
       - name: Set BootMode to UEFI
         redhat.rhel_mgmt.redfish_config:
           baseuri: "<URI>"
           username: "<username>"
           password: "<password>"
   	category: Systems
           command: SetBiosAttributes
           bios_attributes:
             BootMode: Uefi

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      usr: administrator
      pwd: <password>

   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Active Directory integration
     hosts: managed-node-01.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: Join an Active Directory
         ansible.builtin.include_role:
           name: rhel-system-roles.ad_integration
         vars:
           ad_integration_user: "{{ usr }}"
           ad_integration_password: "{{ pwd }}"
           ad_integration_realm: "ad.example.com"
           ad_integration_allow_rc4_crypto: false
           ad_integration_timesync_source: "time_server.ad.example.com"

   The settings specified in the example playbook include the following:

   ad_integration_allow_rc4_crypto: <true|false>

   Configures whether the role activates the AD-SUPPORT crypto policy on the managed node. By default, RHEL does not support the weak RC4 encryption but, if Kerberos in your AD still requires RC4, you can enable this encryption type by setting ad_integration_allow_rc4_crypto: true.

   Omit this the variable or set it to false if Kerberos uses AES encryption.

   ad_integration_timesync_source: <time_server>

   Specifies the NTP server to use for time synchronization. Kerberos requires a synchronized time among AD domain controllers and domain members to prevent replay attacks. If you omit this variable, the ad_integration role does not utilize the timesync RHEL system role to configure time synchronization on the managed node.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ad_integration/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configuration and management of GRUB boot loader
     hosts: managed-node-01.example.com
     tasks:
       - name: Update existing boot loader entries
         ansible.builtin.include_role:
           name: rhel-system-roles.bootloader
         vars:
           bootloader_settings:
             - kernel:
                 path: /boot/vmlinuz-5.14.0-362.24.1.el9_3.aarch64
               options:
                 - name: quiet
                   state: present
           bootloader_reboot_ok: true

   The settings specified in the example playbook include the following:

   kernel

   Specifies the kernel connected with the boot loader entry that you want to update.

   options

   Specifies the kernel command-line parameters to update for your chosen boot loader entry (kernel).

   bootloader_reboot_ok: true

   The role detects that a reboot is required for the changes to take effect and performs a restart of the managed node.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.bootloader/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      pwd: <password>

   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configuration and management of GRUB boot loader
     hosts: managed-node-01.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: Set the bootloader password
         ansible.builtin.include_role:
           name: rhel-system-roles.bootloader
         vars:
           bootloader_password: "{{ pwd }}"
           bootloader_reboot_ok: true

   The settings specified in the example playbook include the following:

   bootloader_password: "{{ pwd }}"

   The variable ensures protection of boot parameters with a password.

   bootloader_reboot_ok: true

   The role detects that a reboot is required for the changes to take effect and performs a restart of the managed node.

   Important

   Changing the boot loader password is not an idempotent transaction. This means that if you apply the same Ansible playbook again, the result will not be the same, and the state of the managed node will change.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.bootloader/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

Verification

1. On your managed node during the GRUB boot menu screen, press the e key for edit.

   

2. You are prompted for a username and a password:

   

   Enter username: root

   The boot loader username is always root and you do not need to specify it in your Ansible playbook.

   Enter password: <password>

   The boot loader password corresponds to the pwd variable that you defined in the vault.yml file.

3. You can view or edit configuration of the particular boot loader entry:

   

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configuration and management of the GRUB boot loader
     hosts: managed-node-01.example.com
     tasks:
       - name: Update the boot loader timeout
         ansible.builtin.include_role:
           name: rhel-system-roles.bootloader
         vars:
           bootloader_timeout: 10

   The settings specified in the example playbook include the following:

   bootloader_timeout: 10

   Input an integer to control for how long the GRUB boot loader menu is displayed before booting the default entry.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.bootloader/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

1. Remotely restart your managed node:

   # ansible managed-node-01.example.com -m ansible.builtin.reboot
   managed-node-01.example.com | CHANGED => {
       "changed": true,
       "elapsed": 21,
       "rebooted": true
   }

2. On the managed node, observe the GRUB boot menu screen.

   

   The highlighted entry will be executed automatically in 10s

   For how long this boot menu is displayed before GRUB automatically uses the default entry.

   • Alternative: you can remotely query for the "timeout" settings in the /boot/grub2/grub.cfg file of your managed node:

     # ansible managed-node-01.example.com -m ansible.builtin.command -a "grep 'timeout' /boot/grub2/grub.cfg"
     managed-node-01.example.com | CHANGED | rc=0 >>
     if [ x$feature_timeout_style = xy ] ; then
       set timeout_style=menu
       set timeout=10
     # Fallback normal timeout code in case the timeout_style feature is
       set timeout=10
     if [ x$feature_timeout_style = xy ] ; then
         set timeout_style=menu
         set timeout=10
         set orig_timeout_style=${timeout_style}
         set orig_timeout=${timeout}
           # timeout_style=menu + timeout=0 avoids the countdown code keypress check
           set timeout_style=menu
           set timeout=10
           set timeout_style=hidden
           set timeout=10
     if [ x$feature_timeout_style = xy ]; then
       if [ "${menu_show_once_timeout}" ]; then
         set timeout_style=menu
         set timeout=10
         unset menu_show_once_timeout
         save_env menu_show_once_timeout

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configuration and management of GRUB boot loader
     hosts: managed-node-01.example.com
     tasks:
       - name: Gather information about the boot loader configuration
         ansible.builtin.include_role:
           name: rhel-system-roles.bootloader
         vars:
           bootloader_gather_facts: true
   
       - name: Display the collected boot loader configuration information
         debug:
           var: bootloader_facts

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.bootloader/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Create certificates
     hosts: managed-node-01.example.com
     tasks:
       - name: Create a self-signed certificate
         ansible.builtin.include_role:
           name: rhel-system-roles.certificate
         vars:
           certificate_requests:
             - name: web-server
               ca: ipa
               dns: www.example.com
               principal: HTTP/www.example.com@EXAMPLE.COM
               run_before: systemctl stop httpd.service
               run_after: systemctl start httpd.service

   The settings specified in the example playbook include the following:

   name: <path_or_file_name>

   Defines the name or path of the generated private key and certificate file:

   • If you set the variable to web-server, the role stores the private key in the /etc/pki/tls/private/web-server.key and the certificate in the /etc/pki/tls/certs/web-server.crt files.

   • If you set the variable to a path, such as /tmp/web-server, the role stores the private key in the /tmp/web-server.key and the certificate in the /tmp/web-server.crt files.

     Note that the directory you use must have the cert_t SELinux context set. You can use the selinux RHEL system role to manage SELinux contexts.

   ca: ipa

   Defines that the role requests the certificate from an IdM CA.

   dns: <hostname_or_list_of_hostnames>

   Sets the hostnames that the Subject Alternative Names (SAN) field in the issued certificate contains. You can use a wildcard (*) or specify multiple names in YAML list format.

   principal: <kerberos_principal>

   Optional: Sets the Kerberos principal that should be included in the certificate.

   run_before: <command>

   Optional: Defines a command that certmonger should execute before requesting the certificate from the CA.

   run_after: <command>

   Optional: Defines a command that certmonger should execute after it received the issued certificate from the CA.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.certificate/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Create certificates
     hosts: managed-node-01.example.com
     tasks:
       - name: Create a self-signed certificate
         ansible.builtin.include_role:
           name: rhel-system-roles.certificate
         vars:
           certificate_requests:
             - name: web-server
               ca: self-sign
               dns: test.example.com

   The settings specified in the example playbook include the following:

   name: <path_or_file_name>

   Defines the name or path of the generated private key and certificate file:

   • If you set the variable to web-server, the role stores the private key in the /etc/pki/tls/private/web-server.key and the certificate in the /etc/pki/tls/certs/web-server.crt files.

   • If you set the variable to a path, such as /tmp/web-server, the role stores the private key in the /tmp/web-server.key and the certificate in the /tmp/web-server.crt files.

     Note that the directory you use must have the cert_t SELinux context set. You can use the selinux RHEL system role to manage SELinux contexts.

   ca: self-sign

   Defines that the role created a self-signed certificate.

   dns: <hostname_or_list_of_hostnames>

   Sets the hostnames that the Subject Alternative Names (SAN) field in the issued certificate contains. You can use a wildcard (*) or specify multiple names in YAML list format.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.certificate/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Manage the RHEL web console
     hosts: managed-node-01.example.com
     tasks:
       - name: Install RHEL web console
         ansible.builtin.include_role:
           name: rhel-system-roles.cockpit
         vars:
           cockpit_packages: default
           cockpit_port: 9050
           cockpit_manage_selinux: true
           cockpit_manage_firewall: true
           cockpit_certificates:
             - name: /etc/cockpit/ws-certs.d/01-certificate
               dns: ['localhost', 'www.example.com']
               ca: ipa

   The settings specified in the example playbook include the following:

   cockpit_manage_selinux: true

   Allow using the selinux system role to configure SELinux for setting up the correct port permissions on the websm_port_t SELinux type.

   cockpit_manage_firewall: true

   Allow the cockpit system role to use the firewalld system role for adding ports.

   cockpit_certificates: <YAML_dictionary>

   By default, the RHEL web console uses a self-signed certificate. Alternatively, you can add the cockpit_certificates variable to the playbook and configure the role to request certificates from an IdM certificate authority (CA) or to use an existing certificate and private key that is available on the managed node.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.cockpit/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure cryptographic policies
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure the FUTURE cryptographic security policy on the managed node
         ansible.builtin.include_role:
           name: rhel-system-roles.crypto_policies
         vars:
           - crypto_policies_policy: FUTURE
           - crypto_policies_reboot_ok: true

   The settings specified in the example playbook include the following:

   crypto_policies_policy: FUTURE

   Configures the required cryptographic policy (FUTURE) on the managed node. It can be either the base policy or a base policy with some sub-policies. The specified base policy and sub-policies have to be available on the managed node. The default value is null. It means that the configuration is not changed and the crypto_policies RHEL system role will only collect the Ansible facts.

   crypto_policies_reboot_ok: true

   Causes the system to reboot after the cryptographic policy change to make sure all of the services and applications will read the new configuration files. The default value is false.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.crypto_policies/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

1. On the control node, create another playbook named, for example, verify_playbook.yml:

   ---
   - name: Verification
     hosts: managed-node-01.example.com
     tasks:
       - name: Verify active cryptographic policy
         ansible.builtin.include_role:
           name: rhel-system-roles.crypto_policies
       - name: Display the currently active cryptographic policy
         ansible.builtin.debug:
           var: crypto_policies_active

   The settings specified in the example playbook include the following:

   crypto_policies_active

   An exported Ansible fact that contains the currently active policy name in the format as accepted by the crypto_policies_policy variable.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/verify_playbook.yml

3. Run the playbook:

   $ ansible-playbook ~/verify_playbook.yml
   TASK [debug] **************************
   ok: [host] => {
       "crypto_policies_active": "FUTURE"
   }

   The crypto_policies_active variable shows the active policy on the managed node.

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configuring fapolicyd
     hosts: managed-node-01.example.com
     tasks:
       - name: Allow only executables installed from RPM database and specific files
         ansible.builtin.include_role:
           name: rhel-system-roles.fapolicyd
         vars:
           fapolicyd_setup_permissive: false
           fapolicyd_setup_integrity: sha256
           fapolicyd_setup_trust: rpmdb,file
           fapolicyd_add_trusted_file:
             - <path_to_allowed_command>
             - <path_to_allowed_service>

   The settings specified in the example playbook include the following:

   fapolicyd_setup_permissive: <true|false>

   Enables or disables sending policy decisions to the kernel for enforcement. Set this variable for debugging and testing purposes to false.

   fapolicyd_setup_integrity: <type_type>

   Defines the integrity checking method. You can set one of the following values:

   • none (default): Disables integrity checking.
   • size: The service compares only the file sizes of allowed applications.
   • ima: The service checks the SHA-256 hash that the kernel’s Integrity Measurement Architecture (IMA) stored in a file’s extended attribute. Additionally, the service performs a size check. Note that the role does not configure the IMA kernel subsystem. To use this option, you must manually configure the IMA subsystem.
   • sha256: The service compares the SHA-256 hash of allowed applications.

   fapolicyd_setup_trust: <trust_backends>

   Defines the list of trust backends. If you include the file backend, specify the allowed executable files in the fapolicyd_add_trusted_file list.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.fapolicyd.README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook ~/playbook.yml --syntax-check

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

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

   The settings specified in the example playbook include the following:

   previous: replaced

   Removes all existing user-defined settings and resets the firewalld settings to defaults. If you combine the previous:replaced parameter with other settings, the firewall role removes all existing settings before applying new ones.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.firewall/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

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

   The settings specified in the example playbook include the following:

   forward_port: 8080/tcp;443

   Traffic coming to the local port 8080 using the TCP protocol is forwarded to the port 443.

   runtime: true

   Enables changes in the runtime configuration. The default is set to true.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.firewall/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - 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
         ansible.builtin.include_role:
           name: rhel-system-roles.firewall
         vars:
           firewall:
             - zone: dmz
               interface: enp1s0
               service: https
               state: enabled
               runtime: true
               permanent: true

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.firewall/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      cluster_password: <cluster_password>

   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Create a high availability cluster
     hosts: node1 node2
     vars_files:
       - vault.yml
     tasks:
       - name: Create TLS certificates and key files in a high availability cluster
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_cluster_name: my-new-cluster
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true
           ha_cluster_pcsd_certificates:
             - name: FILENAME
               common_name: "{{ ansible_hostname }}"
               ca: self-sign

   The settings specified in the example playbook include the following:

   ha_cluster_cluster_name: <cluster_name>

   The name of the cluster you are creating.

   ha_cluster_hacluster_password: <password>

   The password of the hacluster user. The hacluster user has full access to a cluster.

   ha_cluster_manage_firewall: true

   A variable that determines whether the ha_cluster RHEL system role manages the firewall.

   ha_cluster_manage_selinux: true

   A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role.

   ha_cluster_pcsd_certificates: <certificate_properties>

   A variable that creates a self-signed pcsd certificate and private key files in /var/lib/pcsd. In this example, the pcsd certificate has the file name FILENAME.crt and the key file is named FILENAME.key.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      cluster_password: <cluster_password>

   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Create a high availability cluster
     hosts: node1 node2
     vars_files:
       - vault.yml
     tasks:
       - name: Create cluster with minimum required parameters and no fencing
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_cluster_name: my-new-cluster
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true

   The settings specified in the example playbook include the following:

   ha_cluster_cluster_name: <cluster_name>

   The name of the cluster you are creating.

   ha_cluster_hacluster_password: <password>

   The password of the hacluster user. The hacluster user has full access to a cluster.

   ha_cluster_manage_firewall: true

   A variable that determines whether the ha_cluster RHEL system role manages the firewall.

   ha_cluster_manage_selinux: true

   A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      cluster_password: <cluster_password>

   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Create a high availability cluster
     hosts: node1 node2
     vars_files:
       - vault.yml
     tasks:
       - name: Create cluster with fencing and resources
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_cluster_name: my-new-cluster
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true
           ha_cluster_resource_primitives:
             - id: xvm-fencing
               agent: 'stonith:fence_xvm'
               instance_attrs:
                 - attrs:
                     - name: pcmk_host_list
                       value: node1 node2
             - id: simple-resource
               agent: 'ocf:pacemaker:Dummy'
             - id: resource-with-options
               agent: 'ocf:pacemaker:Dummy'
               instance_attrs:
                 - attrs:
                     - name: fake
                       value: fake-value
                     - name: passwd
                       value: passwd-value
               meta_attrs:
                 - attrs:
                     - name: target-role
                       value: Started
                     - name: is-managed
                       value: 'true'
               operations:
                 - action: start
                   attrs:
                     - name: timeout
                       value: '30s'
                 - action: monitor
                   attrs:
                     - name: timeout
                       value: '5'
                     - name: interval
                       value: '1min'
             - id: dummy-1
               agent: 'ocf:pacemaker:Dummy'
             - id: dummy-2
               agent: 'ocf:pacemaker:Dummy'
             - id: dummy-3
               agent: 'ocf:pacemaker:Dummy'
             - id: simple-clone
               agent: 'ocf:pacemaker:Dummy'
             - id: clone-with-options
               agent: 'ocf:pacemaker:Dummy'
           ha_cluster_resource_groups:
             - id: simple-group
               resource_ids:
                 - dummy-1
                 - dummy-2
               meta_attrs:
                 - attrs:
                     - name: target-role
                       value: Started
                     - name: is-managed
                       value: 'true'
             - id: cloned-group
               resource_ids:
                 - dummy-3
           ha_cluster_resource_clones:
             - resource_id: simple-clone
             - resource_id: clone-with-options
               promotable: yes
               id: custom-clone-id
               meta_attrs:
                 - attrs:
                     - name: clone-max
                       value: '2'
                     - name: clone-node-max
                       value: '1'
             - resource_id: cloned-group
               promotable: yes

   The settings specified in the example playbook include the following:

   ha_cluster_cluster_name: <cluster_name>

   The name of the cluster you are creating.

   ha_cluster_hacluster_password: <password>

   The password of the hacluster user. The hacluster user has full access to a cluster.

   ha_cluster_manage_firewall: true

   A variable that determines whether the ha_cluster RHEL system role manages the firewall.

   ha_cluster_manage_selinux: true

   A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role.

   ha_cluster_resource_primitives: <cluster_resources>

   A list of resource definitions for the Pacemaker resources configured by the ha_cluster RHEL system role, including fencing

   ha_cluster_resource_groups: <resource_groups>

   A list of resource group definitions configured by the ha_cluster RHEL system role.

   ha_cluster_resource_clones: <resource_clones>

   A list of resource clone definitions configured by the ha_cluster RHEL system role.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      cluster_password: <cluster_password>

   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Create a high availability cluster
     hosts: node1 node2
     vars_files:
       - vault.yml
     tasks:
       - name: Create cluster with fencing and resource operation defaults
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_cluster_name: my-new-cluster
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true
           # Set a different resource-stickiness value during
           # and outside work hours. This allows resources to
           # automatically move back to their most
           # preferred hosts, but at a time that
           # does not interfere with business activities.
           ha_cluster_resource_defaults:
             meta_attrs:
               - id: core-hours
                 rule: date-spec hours=9-16 weekdays=1-5
                 score: 2
                 attrs:
                   - name: resource-stickiness
                     value: INFINITY
               - id: after-hours
                 score: 1
                 attrs:
                   - name: resource-stickiness
                     value: 0
           # Default the timeout on all 10-second-interval
           # monitor actions on IPaddr2 resources to 8 seconds.
           ha_cluster_resource_operation_defaults:
             meta_attrs:
               - rule: resource ::IPaddr2 and op monitor interval=10s
                 score: INFINITY
                 attrs:
                   - name: timeout
                     value: 8s

   The settings specified in the example playbook include the following:

   ha_cluster_cluster_name: <cluster_name>

   The name of the cluster you are creating.

   ha_cluster_hacluster_password: <password>

   The password of the hacluster user. The hacluster user has full access to a cluster.

   ha_cluster_manage_firewall: true

   A variable that determines whether the ha_cluster RHEL system role manages the firewall.

   ha_cluster_manage_selinux: true

   A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role.

   ha_cluster_resource_defaults: <resource_defaults>

   A variable that defines sets of resource defaults.

   ha_cluster_resource_operation_defaults: <resource_operation_defaults>

   A variable that defines sets of resource operation defaults.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      cluster_password: <cluster_password>
      fence1_password: <fence1_password>
      fence2_password: <fence2_password>

   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example ~/playbook.yml. This example playbook file configures a cluster running the firewalld and selinux services.

   ---
   - name: Create a high availability cluster
     hosts: node1 node2
     vars_files:
       - vault.yml
     tasks:
       - name: Configure a cluster that defines fencing levels
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_cluster_name: my-new-cluster
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true
           ha_cluster_resource_primitives:
             - id: apc1
               agent: 'stonith:fence_apc_snmp'
               instance_attrs:
                 - attrs:
                     - name: ip
                       value: apc1.example.com
                     - name: username
                       value: user
                     - name: password
                       value: "{{ fence1_password }}"
                     - name: pcmk_host_map
                       value: node1:1;node2:2
             - id: apc2
               agent: 'stonith:fence_apc_snmp'
               instance_attrs:
                 - attrs:
                     - name: ip
                       value: apc2.example.com
                     - name: username
                       value: user
                     - name: password
                       value: "{{ fence2_password }}"
                     - name: pcmk_host_map
                       value: node1:1;node2:2
           # Nodes have redundant power supplies, apc1 and apc2. Cluster must
           # ensure that when attempting to reboot a node, both power
           # supplies # are turned off before either power supply is turned
           # back on.
           ha_cluster_stonith_levels:
             - level: 1
               target: node1
               resource_ids:
                 - apc1
                 - apc2
             - level: 1
               target: node2
               resource_ids:
                 - apc1
                 - apc2

   The settings specified in the example playbook include the following:

   ha_cluster_cluster_name: <cluster_name>

   The name of the cluster you are creating.

   ha_cluster_hacluster_password: <password>

   The password of the hacluster user. The hacluster user has full access to a cluster.

   ha_cluster_manage_firewall: true

   A variable that determines whether the ha_cluster RHEL system role manages the firewall.

   ha_cluster_manage_selinux: true

   A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role.

   ha_cluster_resource_primitives: <cluster_resources>

   A list of resource definitions for the Pacemaker resources configured by the ha_cluster RHEL system role, including fencing

   ha_cluster_stonith_levels: <stonith_levels>

   A variable that defines STONITH levels, also known as fencing topology, which configure a cluster to use multiple devices to fence nodes.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      cluster_password: <cluster_password>

   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Create a high availability cluster
     hosts: node1 node2
     vars_files:
       - vault.yml
     tasks:
       - name: Create cluster with resource constraints
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_cluster_name: my-new-cluster
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true
           # In order to use constraints, we need resources
           # the constraints will apply to.
           ha_cluster_resource_primitives:
             - id: xvm-fencing
               agent: 'stonith:fence_xvm'
               instance_attrs:
                 - attrs:
                     - name: pcmk_host_list
                       value: node1 node2
             - id: dummy-1
               agent: 'ocf:pacemaker:Dummy'
             - id: dummy-2
               agent: 'ocf:pacemaker:Dummy'
             - id: dummy-3
               agent: 'ocf:pacemaker:Dummy'
             - id: dummy-4
               agent: 'ocf:pacemaker:Dummy'
             - id: dummy-5
               agent: 'ocf:pacemaker:Dummy'
             - id: dummy-6
               agent: 'ocf:pacemaker:Dummy'
           # location constraints
           ha_cluster_constraints_location:
             # resource ID and node name
             - resource:
                 id: dummy-1
               node: node1
               options:
                 - name: score
                   value: 20
             # resource pattern and node name
             - resource:
                 pattern: dummy-\d+
               node: node1
               options:
                 - name: score
                   value: 10
             # resource ID and rule
             - resource:
                 id: dummy-2
               rule: '#uname eq node2 and date in_range 2022-01-01 to 2022-02-28'
             # resource pattern and rule
             - resource:
                 pattern: dummy-\d+
               rule: node-type eq weekend and date-spec weekdays=6-7
           # colocation constraints
           ha_cluster_constraints_colocation:
             # simple constraint
             - resource_leader:
                 id: dummy-3
               resource_follower:
                 id: dummy-4
               options:
                 - name: score
                   value: -5
             # set constraint
             - resource_sets:
                 - resource_ids:
                     - dummy-1
                     - dummy-2
                 - resource_ids:
                     - dummy-5
                     - dummy-6
                   options:
                     - name: sequential
                       value: "false"
               options:
                 - name: score
                   value: 20
           # order constraints
           ha_cluster_constraints_order:
             # simple constraint
             - resource_first:
                 id: dummy-1
               resource_then:
                 id: dummy-6
               options:
                 - name: symmetrical
                   value: "false"
             # set constraint
             - resource_sets:
                 - resource_ids:
                     - dummy-1
                     - dummy-2
                   options:
                     - name: require-all
                       value: "false"
                     - name: sequential
                       value: "false"
                 - resource_ids:
                     - dummy-3
                 - resource_ids:
                     - dummy-4
                     - dummy-5
                   options:
                     - name: sequential
                       value: "false"
           # ticket constraints
           ha_cluster_constraints_ticket:
             # simple constraint
             - resource:
                 id: dummy-1
               ticket: ticket1
               options:
                 - name: loss-policy
                   value: stop
             # set constraint
             - resource_sets:
                 - resource_ids:
                     - dummy-3
                     - dummy-4
                     - dummy-5
               ticket: ticket2
               options:
                 - name: loss-policy
                   value: fence

   The settings specified in the example playbook include the following:

   ha_cluster_cluster_name: <cluster_name>

   The name of the cluster you are creating.

   ha_cluster_hacluster_password: <password>

   The password of the hacluster user. The hacluster user has full access to a cluster.

   ha_cluster_manage_firewall: true

   A variable that determines whether the ha_cluster RHEL system role manages the firewall.

   ha_cluster_manage_selinux: true

   A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role.

   ha_cluster_resource_primitives: <cluster_resources>

   A list of resource definitions for the Pacemaker resources configured by the ha_cluster RHEL system role, including fencing

   ha_cluster_constraints_location: <location_constraints>

   A variable that defines resource location constraints.

   ha_cluster_constraints_colocation: <colocation_constraints>

   A variable that defines resource colocation constraints.

   ha_cluster_constraints_order: <order_constraints>

   A variable that defines resource order constraints.

   ha_cluster_constraints_ticket: <ticket_constraints>

   A variable that defines Booth ticket constraints.

3. Validate the playbook syntax:

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      cluster_password: <cluster_password>

   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Create a high availability cluster
     hosts: node1 node2
     vars_files:
       - vault.yml
     tasks:
       - name: Create cluster that configures Corosync values
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_cluster_name: my-new-cluster
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true
           ha_cluster_transport:
             type: knet
             options:
               - name: ip_version
                 value: ipv4-6
               - name: link_mode
                 value: active
             links:
               -
                 - name: linknumber
                   value: 1
                 - name: link_priority
                   value: 5
               -
                 - name: linknumber
                   value: 0
                 - name: link_priority
                   value: 10
             compression:
               - name: level
                 value: 5
               - name: model
                 value: zlib
             crypto:
               - name: cipher
                 value: none
               - name: hash
                 value: none
           ha_cluster_totem:
             options:
               - name: block_unlisted_ips
                 value: 'yes'
               - name: send_join
                 value: 0
           ha_cluster_quorum:
             options:
               - name: auto_tie_breaker
                 value: 1
               - name: wait_for_all
                 value: 1

   The settings specified in the example playbook include the following:

   ha_cluster_cluster_name: <cluster_name>

   The name of the cluster you are creating.

   ha_cluster_hacluster_password: <password>

   The password of the hacluster user. The hacluster user has full access to a cluster.

   ha_cluster_manage_firewall: true

   A variable that determines whether the ha_cluster RHEL system role manages the firewall.

   ha_cluster_manage_selinux: true

   A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role.

   ha_cluster_transport: <transport_method>

   A variable that sets the cluster transport method.

   ha_cluster_totem: <totem_options>

   A variable that configures Corosync totem options.

   ha_cluster_quorum: <quorum_options>

   A variable that configures cluster quorum options.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Create a high availability cluster that uses SBD node fencing
     hosts: node1 node2
     roles:
       - rhel-system-roles.ha_cluster
     vars:
       ha_cluster_cluster_name: my-new-cluster
       ha_cluster_hacluster_password: <password>
       ha_cluster_manage_firewall: true
       ha_cluster_manage_selinux: true
       ha_cluster_sbd_enabled: yes
       ha_cluster_sbd_options:
         - name: delay-start
           value: 'no'
         - name: startmode
           value: always
         - name: timeout-action
           value: 'flush,reboot'
         - name: watchdog-timeout
           value: 30
       # Suggested optimal values for SBD timeouts:
       # watchdog-timeout * 2 = msgwait-timeout (set automatically)
       # msgwait-timeout * 1.2 = stonith-timeout
       ha_cluster_cluster_properties:
         - attrs:
             - name: stonith-timeout
               value: 72
       ha_cluster_resource_primitives:
         - id: fence_sbd
           agent: 'stonith:fence_sbd'
           instance_attrs:
             - attrs:
                 # taken from host_vars
                 - name: devices
                   value: "{{ ha_cluster.sbd_devices | join(',') }}"
                 - name: pcmk_delay_base
                   value: 30

   This example playbook file configures a cluster running the firewalld and selinux services that uses SBD fencing and creates the SBD Stonith resource.

   When creating your playbook file for production, vault encrypt the password, as described in Encrypting content with Ansible Vault.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      cluster_password: <cluster_password>

   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Create a high availability cluster
     hosts: node1 node2
     vars_files:
       - vault.yml
     tasks:
       - name: Create a cluster that defines node attributes
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_cluster_name: my-new-cluster
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true
           ha_cluster_node_options:
             - node_name: node1
               attributes:
                 - attrs:
                     - name: attribute1
                       value: value1A
                     - name: attribute2
                       value: value2A
             - node_name: node2
               attributes:
                 - attrs:
                     - name: attribute1
                       value: value1B
                     - name: attribute2
                       value: value2B

   ha_cluster_cluster_name: <cluster_name>

   The name of the cluster you are creating.

   ha_cluster_hacluster_password: <password>

   The password of the hacluster user. The hacluster user has full access to a cluster.

   ha_cluster_manage_firewall: true

   A variable that determines whether the ha_cluster RHEL system role manages the firewall.

   ha_cluster_manage_selinux: true

   A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role.

   ha_cluster_node_options: <node_settings>

   A variable that defines various settings that vary from one cluster node to another.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

   Additional resources

   • Pacemaker rules

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      cluster_password: <cluster_password>

   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Create a high availability cluster
     hosts: z1.example.com z2.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: Configure active/passive Apache server in a high availability cluster
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_cluster_name: my_cluster
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true
           ha_cluster_fence_agent_packages:
             - fence-agents-apc-snmp
           ha_cluster_resource_primitives:
             - id: myapc
               agent: stonith:fence_apc_snmp
               instance_attrs:
                 - attrs:
                     - name: ipaddr
                       value: zapc.example.com
                     - name: pcmk_host_map
                       value: z1.example.com:1;z2.example.com:2
                     - name: login
                       value: apc
                     - name: passwd
                       value: apc
             - id: my_lvm
               agent: ocf:heartbeat:LVM-activate
               instance_attrs:
                 - attrs:
                     - name: vgname
                       value: my_vg
                     - name: vg_access_mode
                       value: system_id
             - id: my_fs
               agent: Filesystem
               instance_attrs:
                 - attrs:
                     - name: device
                       value: /dev/my_vg/my_lv
                     - name: directory
                       value: /var/www
                     - name: fstype
                       value: xfs
             - id: VirtualIP
               agent: IPaddr2
               instance_attrs:
                 - attrs:
                     - name: ip
                       value: 198.51.100.3
                     - name: cidr_netmask
                       value: 24
             - id: Website
               agent: apache
               instance_attrs:
                 - attrs:
                     - name: configfile
                       value: /etc/httpd/conf/httpd.conf
                     - name: statusurl
                       value: http://127.0.0.1/server-status
           ha_cluster_resource_groups:
             - id: apachegroup
               resource_ids:
                 - my_lvm
                 - my_fs
                 - VirtualIP
                 - Website

   The settings specified in the example playbook include the following:

   ha_cluster_cluster_name: <cluster_name>

   The name of the cluster you are creating.

   ha_cluster_hacluster_password: <password>

   The password of the hacluster user. The hacluster user has full access to a cluster.

   ha_cluster_manage_firewall: true

   A variable that determines whether the ha_cluster RHEL system role manages the firewall.

   ha_cluster_manage_selinux: true

   A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role.

   ha_cluster_fence_agent_packages: <fence_agent_packages>

   A list of fence agent packages to install.

   ha_cluster_resource_primitives: <cluster_resources>

   A list of resource definitions for the Pacemaker resources configured by the ha_cluster RHEL system role, including fencing

   ha_cluster_resource_groups: <resource_groups>

   A list of resource group definitions configured by the ha_cluster RHEL system role.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

5. When you use the apache resource agent to manage Apache, it does not use systemd. Because of this, you must edit the logrotate script supplied with Apache so that it does not use systemctl to reload Apache.

   Remove the following line in the /etc/logrotate.d/httpd file on each node in the cluster.

   # /bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true

   • For RHEL 8.6 and later, replace the line you removed with the following three lines, specifying /var/run/httpd-website.pid as the PID file path where website is the name of the Apache resource. In this example, the Apache resource name is Website.

     /usr/bin/test -f /var/run/httpd-Website.pid >/dev/null 2>/dev/null &&
     /usr/bin/ps -q $(/usr/bin/cat /var/run/httpd-Website.pid) >/dev/null 2>/dev/null &&
     /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf -c "PidFile /var/run/httpd-Website.pid" -k graceful > /dev/null 2>/dev/null || true

   • For RHEL 8.5 and earlier, replace the line you removed with the following three lines.

     /usr/bin/test -f /run/httpd.pid >/dev/null 2>/dev/null &&
     /usr/bin/ps -q $(/usr/bin/cat /run/httpd.pid) >/dev/null 2>/dev/null &&
     /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf -c "PidFile /run/httpd.pid" -k graceful > /dev/null 2>/dev/null || true

Verification

1. From one of the nodes in the cluster, check the status of the cluster. Note that all four resources are running on the same node, z1.example.com.

   If you find that the resources you configured are not running, you can run the pcs resource debug-start resource command to test the resource configuration.

   [root@z1 ~]# pcs status
   Cluster name: my_cluster
   Last updated: Wed Jul 31 16:38:51 2013
   Last change: Wed Jul 31 16:42:14 2013 via crm_attribute on z1.example.com
   Stack: corosync
   Current DC: z2.example.com (2) - partition with quorum
   Version: 1.1.10-5.el7-9abe687
   2 Nodes configured
   6 Resources configured
   
   Online: [ z1.example.com z2.example.com ]
   
   Full list of resources:
    myapc  (stonith:fence_apc_snmp):       Started z1.example.com
    Resource Group: apachegroup
        my_lvm     (ocf::heartbeat:LVM-activate):   Started z1.example.com
        my_fs      (ocf::heartbeat:Filesystem):    Started z1.example.com
        VirtualIP  (ocf::heartbeat:IPaddr2):       Started z1.example.com
        Website    (ocf::heartbeat:apache):        Started z1.example.com

2. Once the cluster is up and running, you can point a browser to the IP address you defined as the IPaddr2 resource to view the sample display, consisting of the simple word "Hello".

   Hello

3. To test whether the resource group running on z1.example.com fails over to node z2.example.com, put node z1.example.com in standby mode, after which the node will no longer be able to host resources.

   [root@z1 ~]# pcs node standby z1.example.com

4. After putting node z1 in standby mode, check the cluster status from one of the nodes in the cluster. Note that the resources should now all be running on z2.

   [root@z1 ~]# pcs status
   Cluster name: my_cluster
   Last updated: Wed Jul 31 17:16:17 2013
   Last change: Wed Jul 31 17:18:34 2013 via crm_attribute on z1.example.com
   Stack: corosync
   Current DC: z2.example.com (2) - partition with quorum
   Version: 1.1.10-5.el7-9abe687
   2 Nodes configured
   6 Resources configured
   
   Node z1.example.com (1): standby
   Online: [ z2.example.com ]
   
   Full list of resources:
   
    myapc  (stonith:fence_apc_snmp):       Started z1.example.com
    Resource Group: apachegroup
        my_lvm     (ocf::heartbeat:LVM-activate):  Started z2.example.com
        my_fs      (ocf::heartbeat:Filesystem):    Started z2.example.com
        VirtualIP  (ocf::heartbeat:IPaddr2):       Started z2.example.com
        Website    (ocf::heartbeat:apache):        Started z2.example.com

   The web site at the defined IP address should still display, without interruption.

5. To remove z1 from standby mode, enter the following command.

   [root@z1 ~]# pcs node unstandby z1.example.com

   Note

   Removing a node from standby mode does not in itself cause the resources to fail back over to that node. This will depend on the resource-stickiness value for the resources. For information about the resource-stickiness meta attribute, see Configuring a resource to prefer its current node.

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure journald
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure persistent logging
         ansible.builtin.include_role:
           name: rhel-system-roles.journald
         vars:
           journald_persistent: true
           journald_max_disk_size: <size>
           journald_per_user: true
           journald_sync_interval: <interval>

   The settings specified in the example playbook include the following:

   journald_persistent: true

   Enables persistent logging.

   journald_max_disk_size: <size>

   Specifies the maximum size of disk space for journal files in MB, for example, 2048.

   journald_per_user: true

   Configures journald to keep log data separate for each user.

   journald_sync_interval: <interval>

   Sets the synchronization interval in minutes, for example, 1.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.journald/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configuring kernel crash dumping
     hosts: managed-node-01.example.com
     tasks:
       - name: Setting the kdump directory.
         ansible.builtin.include_role:
           name: rhel-system-roles.kdump
         vars:
           kdump_target:
             type: raw
             location: /dev/sda1
           kdump_path: /var/crash/vmcore
           kernel_settings_reboot_ok: true

   The settings specified in the example playbook include the following:

   kdump_target: <type_and_location>

   Writes vmcore to a location other than the root file system. The location refers to a partition (by name, label, or UUID) when the type is raw or file system.

   kernel_settings_reboot_ok: <true|false>

   The default is false. If set to true, the system role will determine if a reboot of the managed host is necessary for the requested changes to take effect and reboot it. If set to false, the role will return the variable kernel_settings_reboot_required with a value of true, indicating that a reboot is required. In this case, a user must reboot the managed node manually.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.kdump/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configuring kernel settings
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure hugepages, packet size for loopback device, and limits on simultaneously open files.
         ansible.builtin.include_role:
           name: 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
           kernel_settings_reboot_ok: true

   The settings specified in the example playbook include the following:

   kernel_settings_sysfs: <list_of_sysctl_settings>

   A YAML list of sysctl settings and the values you want to assign to these settings.

   kernel_settings_transparent_hugepages: <value>

   Controls the memory subsystem Transparent Huge Pages (THP) setting. You can disable THP support (never), enable it system wide (always) or inside MAD_HUGEPAGE regions (madvise).

   kernel_settings_reboot_ok: <true|false>

   The default is false. If set to true, the system role will determine if a reboot of the managed host is necessary for the requested changes to take effect and reboot it. If set to false, the role will return the variable kernel_settings_reboot_required with a value of true, indicating that a reboot is required. In this case, a user must reboot the managed node manually.

1. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

2. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Deploy the logging solution
     hosts: managed-node-01.example.com
     tasks:
       - name: Filter logs based on a specific value they contain
         ansible.builtin.include_role:
           name: rhel-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]

   The settings specified in the example playbook include the following:

   logging_inputs

   Defines a list of logging input dictionaries. The type: basics option covers inputs from systemd journal or Unix socket.

   logging_outputs

   Defines a list of logging output dictionaries. The type: files option supports storing logs in the local files, usually in the /var/log/ directory. The property: msg; property: contains; and property_value: error options specify that all logs that contain the error string are stored in the /var/log/errors.log file. The property: msg; property: !contains; and property_value: error options specify that all other logs are put in the /var/log/others.log file. You can replace the error value with the string by which you want to filter.

   logging_flows

   Defines a list of logging flow dictionaries to specify relationships between logging_inputs and logging_outputs. The inputs: [files_input] option specifies a list of inputs, from which processing of logs starts. The outputs: [files_output0, files_output1] option specifies a list of outputs, to which the logs are sent.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.logging/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

1. On the managed node, test the syntax of the /etc/rsyslog.conf file:

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

2. On the managed node, verify that the system sends messages that contain the error string to the log:

   1. Send a test message:

      # logger error

   2. View the /var/log/errors.log log, for example:

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

      Where hostname is the host name of the client system. Note that the log contains the user name of the user that entered the logger command, in this case root.

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Deploy the logging solution
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure the server to receive remote input
         ansible.builtin.include_role:
           name: 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: Deploy the logging solution
     hosts: managed-node-02.example.com
     tasks:
       - name: Configure the server to output the logs to local files in directories named by remote host names
         ansible.builtin.include_role:
           name: 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]

   The settings specified in the first play of the example playbook include the following:

   logging_inputs

   Defines a list of logging input dictionaries. The type: remote option covers remote inputs from the other logging system over the network. The udp_ports: [ 601 ] option defines a list of UDP port numbers to monitor. The tcp_ports: [ 601 ] option defines a list of TCP port numbers to monitor. If both udp_ports and tcp_ports is set, udp_ports is used and tcp_ports is dropped.

   logging_outputs

   Defines a list of logging output dictionaries. The type: remote_files option makes output store logs to the local files per remote host and program name originated the logs.

   logging_flows

   Defines a list of logging flow dictionaries to specify relationships between logging_inputs and logging_outputs. The inputs: [remote_udp_input, remote_tcp_input] option specifies a list of inputs, from which processing of logs starts. The outputs: [remote_files_output] option specifies a list of outputs, to which the logs are sent.

   The settings specified in the second play of the example playbook include the following:

   logging_inputs

   Defines a list of logging input dictionaries. The type: basics option covers inputs from systemd journal or Unix socket.

   logging_outputs

   Defines a list of logging output dictionaries. The type: forwards option supports sending logs to the remote logging server over the network. The severity: info option refers to log messages of the informative importance. The facility: mail option refers to the type of system program that is generating the log message. The target: <host1.example.com> option specifies the hostname of the remote logging server. The udp_port: 601/tcp_port: 601 options define the UDP/TCP ports on which the remote logging server listens.

   logging_flows

   Defines a list of logging flow dictionaries to specify relationships between logging_inputs and logging_outputs. The inputs: [basic_input] option specifies a list of inputs, from which processing of logs starts. The outputs: [forward_output0, forward_output1] option specifies a list of outputs, to which the logs are sent.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.logging/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

1. On both the client and the server system, test the syntax of the /etc/rsyslog.conf file:

   # 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. Verify that the client system sends messages to the server:

   1. On the client system, send a test message:

      # logger test

   2. On the server system, view the /var/log/<host2.example.com>/messages log, for example:

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

      Where <host2.example.com> is the host name of the client system. Note that the log contains the user name of the user that entered the logger command, in this case root.

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Monitoring performance metrics
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure Performance Co-Pilot
         ansible.builtin.include_role:
           name: rhel-system-roles.metrics
         vars:
           metrics_retention_days: 14
           metrics_manage_firewall: true
           metrics_manage_selinux: true

   The settings specified in the example playbook include the following:

   metrics_retention_days: <number>

   Sets the number of days after which the pmlogger_daily systemd timer removes old PCP archives.

   metrics_manage_firewall: <true|false>

   Defines whether the role should open the required ports in the firewalld service. If you want to remotely access PCP on the managed nodes, set this variable to true.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.metrics/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      metrics_usr: <username>
      metrics_pwd: <password>

   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Monitoring performance metrics
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure Performance Co-Pilot
         ansible.builtin.include_role:
           name: rhel-system-roles.metrics
         vars:
           metrics_retention_days: 14
           metrics_manage_firewall: true
           metrics_manage_selinux: true
   	metrics_username: "{{ metrics_usr }}"
           metrics_password: "{{ metrics_pwd }}"

   The settings specified in the example playbook include the following:

   metrics_retention_days: <number>

   Sets the number of days after which the pmlogger_daily systemd timer removes old PCP archives.

   metrics_manage_firewall: <true|false>

   Defines whether the role should open the required ports in the firewalld service. If you want to remotely access PCP on the managed nodes, set this variable to true.

   metrics_username: <username>

   The role creates this user locally on the managed node, adds the credentials to the /etc/pcp/passwd.db Simple Authentication and Security Layer (SASL) database, and configures authentication in PCP. Additionally, if you set metrics_from_bpftrace: true in the playbook, PCP uses this account to register bpftrace scripts.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.metrics/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      grafana_admin_pwd: <password>

   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Monitoring performance metrics
     hosts: managed-node-01.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: Set up Grafana to monitor multiple hosts
         ansible.builtin.include_role:
           name: rhel-system-roles.metrics
         vars:
           metrics_graph_service: true
           metrics_query_service: true
           metrics_monitored_hosts:
             - <pcp_host_1.example.com>
             - <pcp_host_2.example.com>
           metrics_manage_firewall: true
           metrics_manage_selinux: true
   
       - name: Set Grafana admin password
         ansible.builtin.shell:
           cmd: grafana-cli admin reset-admin-password "{{ grafana_admin_pwd }}"

   The settings specified in the example playbook include the following:

   metrics_graph_service: true

   Installs Grafana and the PCP plug-in. Additionally, the role adds the PCP Vector, PCP Redis, and PCP bpftrace data sources to Grafana.

   metrics_query_service: <true|false>

   Defines whether the role should install and configure Redis for centralized metric recording. If enabled, data collected from PCP clients is stored in Redis and, as a result, you can also display historical data instead of only live data.

   metrics_monitored_hosts: <list_of_hosts>

   Defines the list of hosts to monitor. In Grafana, you can then display the data of these hosts and, additionally, the host that runs Grafana.

   metrics_manage_firewall: <true|false>

   Defines whether the role should open the required ports in the firewalld service. If you set this variable to true, you can, for example, access Grafana remotely.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.metrics/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

Verification

1. Open http://<grafana_server_IP_or_hostname>:3000 in your browser, and log in as the admin user with the password you set in the procedure.

2. Display monitoring data:

   • To display live data:

     1. Click the Performance Co-Pilot icon in the navigation bar on the left, and select PCP Vector Checklist.
     2. By default, the graphs display metrics from the host that runs Grafana. To switch to a different host, enter the hostname in the hostspec field and press Enter.
   • To display historical data stored in a Redis database: Create a panel with a PCP Redis data source. This requires that you set metrics_query_service: true in the playbook.

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Deploy a Tang server
     hosts: tang.server.example.com
     tasks:
     - name: Install and configure periodic key rotation
       ansible.builtin.include_role:
           name: rhel-system-roles.nbde_server
       vars:
         nbde_server_rotate_keys: yes
         nbde_server_manage_firewall: true
         nbde_server_manage_selinux: true

   This example playbook ensures deploying of your Tang server and a key rotation.

   The settings specified in the example playbook include the following:

   nbde_server_manage_firewall: true

   Use the firewall system role to manage ports used by the nbde_server role.

   nbde_server_manage_selinux: true

   Use the selinux system role to manage ports used by the nbde_server role.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.nbde_server/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure clients for unlocking of encrypted volumes by Tang servers
     hosts: managed-node-01.example.com
     tasks:
       - name: Create NBDE client bindings
         ansible.builtin.include_role:
           name: rhel-system-roles.nbde_client
         vars:
           nbde_client_bindings:
             - device: /dev/rhel/root
               encryption_key_src: /etc/luks/keyfile
               nbde_client_early_boot: true
               state: present
               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

   This example playbook configures Clevis clients for automated unlocking of two LUKS-encrypted volumes when at least one of two Tang servers is available.

   The settings specified in the example playbook include the following:

   state: present

   The values of state indicate the configuration after you run the playbook. Use the present value for either creating a new binding or updating an existing one. Contrary to a clevis luks bind command, you can use state: present also for overwriting an existing binding in its device slot. The absent value removes a specified binding.

   nbde_client_early_boot: true

   The nbde_client role ensures that networking for a Tang pin is available during early boot by default. If you scenario requires to disable this feature, add the nbde_client_early_boot: false variable to your playbook.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.nbde_client/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

1. On your NBDE client, check that the encrypted volume that should be automatically unlocked by your Tang servers contain the corresponding information in its LUKS pins:

   # ansible managed-node-01.example.com -m command -a 'clevis luks list -d /dev/rhel/root'
   1: tang '{"url":"<http://server1.example.com/>"}'
   2: tang '{"url":"<http://server2.example.com/>"}'

2. If you do not use the nbde_client_early_boot: false variable, verify that the bindings are available for the early boot, for example:

   # ansible managed-node-01.example.com -m command -a 'lsinitrd | grep clevis-luks'
   lrwxrwxrwx   1 root     root           48 Jan  4 02:56 etc/systemd/system/cryptsetup.target.wants/clevis-luks-askpass.path -> /usr/lib/systemd/system/clevis-luks-askpass.path
   …

Procedure

1. Create a file with the network settings of your hosts, for example, static-ip-settings-clients.yml, and add the values you want to dynamically assign to the hosts:

   clients:
     managed-node-01.example.com:
       ip_v4: 192.0.2.1
       gateway_v4: 192.0.2.254
       netmask_v4: 255.255.255.0
       interface: enp1s0
     managed-node-02.example.com:
       ip_v4: 192.0.2.2
       gateway_v4: 192.0.2.254
       netmask_v4: 255.255.255.0
       interface: enp1s0

2. Create a playbook file, for example, ~/playbook.yml, with the following content:

   - name: Configure clients for unlocking of encrypted volumes by Tang servers
     hosts: managed-node-01.example.com,managed-node-02.example.com
     vars_files:
       - ~/static-ip-settings-clients.yml
     tasks:
       - name: Create NBDE client bindings
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         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
   
       - name: Configure a Clevis client with static IP address during early boot
         ansible.builtin.include_role:
           name: rhel-system-roles.bootloader
         vars:
           bootloader_settings:
             - kernel: ALL
               options:
                 - name: ip
                   value: "{{ clients[inventory_hostname]['ip_v4'] }}::{{ clients[inventory_hostname]['gateway_v4'] }}:{{ clients[inventory_hostname]['netmask_v4'] }}::{{ clients[inventory_hostname]['interface'] }}:none"

   This playbook reads certain values dynamically for each host listed in the ~/static-ip-settings-clients.yml file.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.network/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Edit the ~/inventory file, and append the host-specific settings to the host entries:

   managed-node-01.example.com interface=enp1s0 ip_v4=192.0.2.1/24 ip_v6=2001:db8:1::1/64 gateway_v4=192.0.2.254 gateway_v6=2001:db8:1::fffe
   
   managed-node-02.example.com interface=enp1s0 ip_v4=192.0.2.2/24 ip_v6=2001:db8:1::2/64 gateway_v4=192.0.2.254 gateway_v6=2001:db8:1::fffe

2. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com,managed-node-02.example.com
     tasks:
       - name: Ethernet connection profile with static IP address settings
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         vars:
           network_connections:
             - name: "{{ interface }}"
               interface_name: "{{ interface }}"
               type: ethernet
               autoconnect: yes
               ip:
                 address:
                   - "{{ ip_v4 }}"
                   - "{{ ip_v6 }}"
                 gateway4: "{{ gateway_v4 }}"
                 gateway6: "{{ gateway_v6 }}"
                 dns:
                   - 192.0.2.200
                   - 2001:db8:1::ffbb
                 dns_search:
                   - example.com
               state: up

   This playbook reads certain values dynamically for each host from the inventory file and uses static values in the playbook for settings which are the same for all hosts.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.network/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
       - name: Ethernet connection profile with static IP address settings
         ansible.builtin.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

   The settings specified in the example playbook include the following:

   match

   Defines that a condition must be met in order to apply the settings. You can only use this variable with the path option.

   path

   Defines the persistent path of a device. You can set it as a fixed path or an expression. Its value can contain modifiers and wildcards. The example applies the settings to devices that match PCI ID 0000:00:0[1-3].0, but not 0000:00:02.0.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.network/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

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

   The settings specified in the example playbook include the following:

   dhcp4: yes

   Enables automatic IPv4 address assignment from DHCP, PPP, or similar services.

   auto6: yes

   Enables IPv6 auto-configuration. By default, NetworkManager uses Router Advertisements. If the router announces the managed flag, NetworkManager requests an IPv6 address and prefix from a DHCPv6 server.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.network/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
       - name: Ethernet connection profile with dynamic IP address settings
         ansible.builtin.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

   The settings specified in the example playbook include the following:

   match: path

   Defines that a condition must be met in order to apply the settings. You can only use this variable with the path option.

   path: <path_and_expressions>

   Defines the persistent path of a device. You can set it as a fixed path or an expression. Its value can contain modifiers and wildcards. The example applies the settings to devices that match PCI ID 0000:00:0[1-3].0, but not 0000:00:02.0.

   dhcp4: yes

   Enables automatic IPv4 address assignment from DHCP, PPP, or similar services.

   auto6: yes

   Enables IPv6 auto-configuration. By default, NetworkManager uses Router Advertisements. If the router announces the managed flag, NetworkManager requests an IPv6 address and prefix from a DHCPv6 server.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.network/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      pwd: <password>

   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure an Ethernet connection with 802.1X authentication
     hosts: managed-node-01.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: Copy client key for 802.1X authentication
         ansible.builtin.copy:
           src: "/srv/data/client.key"
           dest: "/etc/pki/tls/private/client.key"
           mode: 0600
   
       - name: Copy client certificate for 802.1X authentication
         ansible.builtin.copy:
           src: "/srv/data/client.crt"
           dest: "/etc/pki/tls/certs/client.crt"
   
       - name: Copy CA certificate for 802.1X authentication
         ansible.builtin.copy:
           src: "/srv/data/ca.crt"
           dest: "/etc/pki/ca-trust/source/anchors/ca.crt"
   
       - name: Ethernet connection profile with static IP address settings and 802.1X
         ansible.builtin.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: "{{ pwd }}"
                 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

   The settings specified in the example playbook include the following:

   ieee802_1x

   This variable contains the 802.1X-related settings.

   eap: tls

   Configures the profile to use the certificate-based TLS authentication method for the Extensible Authentication Protocol (EAP).

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.network/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
       - name: Bond connection profile with two Ethernet ports
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         vars:
           network_connections:
             # Bond profile
             - name: bond0
               type: bond
               interface_name: bond0
               ip:
                 dhcp4: yes
                 auto6: yes
               bond:
                 mode: active-backup
               state: up
   
             # Port profile for the 1st Ethernet device
             - name: bond0-port1
               interface_name: enp7s0
               type: ethernet
               controller: bond0
               state: up
   
             # Port profile for the 2nd Ethernet device
             - name: bond0-port2
               interface_name: enp8s0
               type: ethernet
               controller: bond0
               state: up

   The settings specified in the example playbook include the following:

   type: <profile_type>

   Sets the type of the profile to create. The example playbook creates three connection profiles: One for the bond and two for the Ethernet devices.

   dhcp4: yes

   Enables automatic IPv4 address assignment from DHCP, PPP, or similar services.

   auto6: yes

   Enables IPv6 auto-configuration. By default, NetworkManager uses Router Advertisements. If the router announces the managed flag, NetworkManager requests an IPv6 address and prefix from a DHCPv6 server.

   mode: <bond_mode>

   Sets the bonding mode. Possible values are:

   • balance-rr (default)
   • active-backup
   • balance-xor
   • broadcast
   • 802.3ad
   • balance-tlb
   • balance-alb.

   Depending on the mode you set, you need to set additional variables in the playbook.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.network/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
       - name: VLAN connection profile with Ethernet port
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         vars:
           network_connections:
             # Ethernet profile
             - name: enp1s0
               type: ethernet
               interface_name: enp1s0
               autoconnect: yes
               state: up
               ip:
                 dhcp4: no
                 auto6: no
   
             # VLAN profile
             - name: enp1s0.10
               type: vlan
               vlan:
                 id: 10
               ip:
                 dhcp4: yes
                 auto6: yes
               parent: enp1s0
               state: up

   The settings specified in the example playbook include the following:

   type: <profile_type>

   Sets the type of the profile to create. The example playbook creates two connection profiles: One for the parent Ethernet device and one for the VLAN device.

   dhcp4: <value>

   If set to yes, automatic IPv4 address assignment from DHCP, PPP, or similar services is enabled. Disable the IP address configuration on the parent device.

   auto6: <value>

   If set to yes, IPv6 auto-configuration is enabled. In this case, by default, NetworkManager uses Router Advertisements and, if the router announces the managed flag, NetworkManager requests an IPv6 address and prefix from a DHCPv6 server. Disable the IP address configuration on the parent device.

   parent: <parent_device>

   Sets the parent device of the VLAN connection profile. In the example, the parent is the Ethernet interface.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.network/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
       - name: Bridge connection profile with two Ethernet ports
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         vars:
           network_connections:
             # Bridge profile
             - name: bridge0
               type: bridge
               interface_name: bridge0
               ip:
                 dhcp4: yes
                 auto6: yes
               state: up
   
             # Port profile for the 1st Ethernet device
             - name: bridge0-port1
               interface_name: enp7s0
               type: ethernet
               controller: bridge0
               port_type: bridge
               state: up
   
             # Port profile for the 2nd Ethernet device
             - name: bridge0-port2
               interface_name: enp8s0
               type: ethernet
               controller: bridge0
               port_type: bridge
               state: up

   The settings specified in the example playbook include the following:

   type: <profile_type>

   Sets the type of the profile to create. The example playbook creates three connection profiles: One for the bridge and two for the Ethernet devices.

   dhcp4: yes

   Enables automatic IPv4 address assignment from DHCP, PPP, or similar services.

   auto6: yes

   Enables IPv6 auto-configuration. By default, NetworkManager uses Router Advertisements. If the router announces the managed flag, NetworkManager requests an IPv6 address and prefix from a DHCPv6 server.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.network/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

1. Display the link status of Ethernet devices that are ports of a specific bridge:

   # ansible managed-node-01.example.com -m command -a 'ip link show master bridge0'
   managed-node-01.example.com | CHANGED | rc=0 >>
   3: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bridge0 state UP mode DEFAULT group default qlen 1000
       link/ether 52:54:00:62:61:0e brd ff:ff:ff:ff:ff:ff
   4: enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bridge0 state UP mode DEFAULT group default qlen 1000
       link/ether 52:54:00:9e:f1:ce brd ff:ff:ff:ff:ff:ff

2. Display the status of Ethernet devices that are ports of any bridge device:

   # ansible managed-node-01.example.com -m command -a 'bridge link show'
   managed-node-01.example.com | CHANGED | rc=0 >>
   3: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master bridge0 state forwarding priority 32 cost 100
   4: enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master bridge0 state listening priority 32 cost 100

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
       - name: Ethernet connection profile with static IP address settings
         ansible.builtin.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

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.network/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
       - name: Ethernet connection profile with static IP address settings
         ansible.builtin.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

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.network/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

1. Display the IPv4 routes:

   # ansible managed-node-01.example.com -m command -a 'ip -4 route'
   managed-node-01.example.com | CHANGED | rc=0 >>
   ...
   198.51.100.0/24 via 192.0.2.10 dev enp7s0

2. Display the IPv6 routes:

   # ansible managed-node-01.example.com -m command -a 'ip -6 route'
   managed-node-01.example.com | CHANGED | rc=0 >>
   ...
   2001:db8:2::/64 via 2001:db8:1::10 dev enp7s0 metric 1024 pref medium

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configuring policy-based routing
     hosts: managed-node-01.example.com
     tasks:
       - name: Routing traffic from a specific subnet to a different default gateway
         ansible.builtin.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

   The settings specified in the example playbook include the following:

   table: <value>

   Assigns the route from the same list entry as the table variable to the specified routing table.

   routing_rule: <list>

   Defines the priority of the specified routing rule and from a connection profile to which routing table the rule is assigned.

   zone: <zone_name>

   Assigns the network interface from a connection profile to the specified firewalld zone.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.network/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

1. On a RHEL host in the internal workstation subnet:

   1. Install the traceroute package:

      # yum install traceroute

   2. Use the traceroute utility to display the route to a host on the 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
       ...

      The output of the command displays that the router sends packets over 192.0.2.1, which is the network of provider B.

2. On a RHEL host in the server subnet:

   1. Install the traceroute package:

      # yum install traceroute

   2. Use the traceroute utility to display the route to a host on the 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
       ...

      The output of the command displays that the router sends packets over 198.51.100.2, which is the network of provider A.

3. On the RHEL router that you configured using the RHEL system role:

   1. Display the rule list:

      # 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

      By default, RHEL contains rules for the tables local, main, and default.

   2. Display the routes in 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. Display the interfaces and firewall zones:

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

   4. Verify that the external zone has masquerading enabled:

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

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
       - name: Ethernet connection profile with dynamic IP address settings and offload features
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         vars:
           network_connections:
             - name: enp1s0
               type: ethernet
               autoconnect: yes
               ip:
                 dhcp4: yes
                 auto6: yes
               ethtool:
                 features:
                   gro: no
                   gso: yes
                   tx_sctp_segmentation: no
               state: up

   The settings specified in the example playbook include the following:

   gro: no

   Disables Generic receive offload (GRO).

   gso: yes

   Enables Generic segmentation offload (GSO).

   tx_sctp_segmentation: no

   Disables TX stream control transmission protocol (SCTP) segmentation.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.network/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml