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 => {
           ...
       	"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. 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: redhat.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 use 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: redhat.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: redhat.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: redhat.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: redhat.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: redhat.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: redhat.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: redhat.rhel_system_roles.cockpit
         vars:
           cockpit_packages: default
           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: redhat.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: redhat.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: redhat.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: redhat.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: redhat.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 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: redhat.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: redhat.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: redhat.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: redhat.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: redhat.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: redhat.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: redhat.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: redhat.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
             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 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: redhat.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: redhat.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 website 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: redhat.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: redhat.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: redhat.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.

   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: 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: redhat.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: redhat.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: redhat.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]

   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 are 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 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.