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

   Copy to Clipboard

2. Switch to the newly created ansible user:

   [root@control-node]# su - ansible

   Copy to Clipboard

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

   Copy to Clipboard

   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

   Copy to Clipboard
   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

   Copy to Clipboard

   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]# dnf install rhel-system-roles

     Copy to Clipboard

     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

        Copy to Clipboard

        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

   Copy to Clipboard

   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.

   Copy to Clipboard

   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.

      Copy to Clipboard

   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

      Copy to Clipboard

   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.

      Copy to Clipboard

   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

      Copy to Clipboard

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

      Copy to Clipboard

      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

        Copy to Clipboard

      • 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

        Copy to Clipboard

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

   Copy to Clipboard

   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 a managed host by using the Ansible command module:

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

   Copy to Clipboard

   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>

      Copy to Clipboard

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

      usr: administrator
      pwd: <password>

      Copy to Clipboard
   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"

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

Procedure

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

   ---
   - name: Configuration and management of GRUB2 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-6.12.0-0.el10_0.aarch64
               options:
                 - name: quiet
                   state: present
           bootloader_reboot_ok: true

   Copy to Clipboard

   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 needed 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

   Copy to Clipboard

   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

   Copy to Clipboard

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>

      Copy to Clipboard

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

      pwd: <password>

      Copy to Clipboard
   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 GRUB2 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

   Copy to Clipboard

   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 needed 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

   Copy to Clipboard

   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

   Copy to Clipboard

Verification

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

   

2. You will be 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 GRUB2 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

   Copy to Clipboard

   The settings specified in the example playbook include the following:

   bootloader_timeout: 10

   Input an integer to control for how long the GRUB2 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

   Copy to Clipboard

   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

   Copy to Clipboard

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
   }

   Copy to Clipboard

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

   

   The highlighted entry will be executed automatically in 10s

   For how long this boot menu is displayed before GRUB2 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

     Copy to Clipboard

Procedure

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

   ---
   - name: Configuration and management of GRUB2 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

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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_port: 9090
           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

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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

   Copy to Clipboard

   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 subpolicies. The specified base policy and subpolicies 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

   Copy to Clipboard

   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

   Copy to Clipboard

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

   Copy to Clipboard

   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

   Copy to Clipboard

3. Run the playbook:

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

   Copy to Clipboard

   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>

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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>

      Copy to Clipboard

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

      cluster_password: <cluster_password>

      Copy to Clipboard
   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

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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>

      Copy to Clipboard

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

      cluster_password: <cluster_password>

      Copy to Clipboard
   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

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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>

      Copy to Clipboard

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

      cluster_password: <cluster_password>

      Copy to Clipboard
   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

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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>

      Copy to Clipboard

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

      cluster_password: <cluster_password>

      Copy to Clipboard
   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

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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>

      Copy to Clipboard

   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>

      Copy to Clipboard
   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

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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>

      Copy to Clipboard

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

      cluster_password: <cluster_password>

      Copy to Clipboard
   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

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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>

      Copy to Clipboard

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

      cluster_password: <cluster_password>

      Copy to Clipboard
   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

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

Procedure

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

   ---
   - name: Export high availability cluster configuration
     hosts: node1
     Tasks:
       - name: Export configuration that does not modify existing cluster
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.ha_cluster
         vars:
           ha_cluster_cluster_present: null
           ha_cluster_qnetd: null
           ha_cluster_export_configuration: true
       - name: Print ha_cluster_info_result variable
         ansible.builtin.debug:
           var: ha_cluster_facts
       - name: Save current cluster configuration to a file
         delegate_to: localhost
         ansible.builtin.copy:
           content: "{{ ha_cluster_facts | to_nice_yaml(sort_keys=false) }}"
           dest: /path/to/file
           mode: "0640"

   Copy to Clipboard

   The settings specified in the example playbook include the following:

   hosts: node1

   A node containing the cluster information to export.

   ha_cluster_cluster_present: null

   Setting to indicate that the cluster configuration will not be changed on the specified host.

   ha_cluster_qnetd: null

   Setting to indicate that the qnetd host configuration will not be changed on the specified host.

   ha_cluster_export_configuration: true

   A variable that determines whether to export the current cluster configuration and store it in the ha_cluster_facts variable, which is generated by the ha_cluster_info module.

   ha_cluster_facts

   A variable that contains the exported cluster configuration.

   delegate_to: localhost

   Specifies the control node as the location for the exported configuration file.

   content: "{{ ha_cluster_facts | to_nice_yaml(sort_keys=false) }"}, dest: /path/to/file, mode: "0640"

   Copies the configuration file in a YAML format to /path/to/file, setting the file permissions to 0640.

2. Write a playbook for your system using the variables you exported to /path/to/file on the control node.

   You must add the ha_cluster_hacluster_password variable, as it is a required variable but is not present in the export. Optionally, add the ha_cluster_corosync_key_src, ha_cluster_pacemaker_key_src, ha_cluster_fence_virt_key_src, and ha_cluster_regenerate_keys variables if your system requires them. These variables are never exported.

3. Validate the playbook syntax:

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

   Copy to Clipboard

   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

   Copy to Clipboard

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>

      Copy to Clipboard

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

      cluster_password: <cluster_password>

      Copy to Clipboard
   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: Configure a cluster with ACLs assigned
         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
             # To use an ACL role permission reference, the reference must exist in CIB.
             ha_cluster_resource_primitives:
               - id: not-for-operator
                 agent: 'ocf:pacemaker:Dummy'
             # ACLs must be enabled (using the enable-acl cluster property) in order to be effective.
             ha_cluster_cluster_properties:
               - attrs:
                   - name: enable-acl
                     value: 'true'
             ha_cluster_acls:
               acl_roles:
                 - id: operator
                   description: HA cluster operator
                   permissions:
                     - kind: write
                       xpath: //crm_config//nvpair[@name='maintenance-mode']
                     - kind: deny
                       reference: not-for-operator
                 - id: administrator
                   permissions:
                     - kind: write
                       xpath: /cib
               acl_users:
                 - id: alice
                   roles:
                     - operator
                     - administrator
                 - id: bob
                   roles:
                     - administrator
               acl_groups:
                 - id: admins
                   roles:
                     - administrator

   Copy to Clipboard

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

   ha_cluster_cluster_properties: <cluster properties>

   A list of sets of cluster properties for Pacemaker cluster-wide configuration.

   ha_cluster_acls: <dictionary>

   A dictionary of ACL role, user, and group values.

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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>

      Copy to Clipboard

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

      cluster_password: <cluster_password>

      Copy to Clipboard
   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: Configure a cluster with SBD fencing
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.ha_cluster
         vars:
           my_sbd_devices:
             # This variable is indirectly used by various variables of the ha_cluster RHEL system role.
             # Its purpose is to define SBD devices once so they do not need
             # to be repeated several times in the role variables.
             - /dev/disk/by-id/000001
             - /dev/disk/by-id/000002
             - /dev/disk/by-id/000003
           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_sbd_enabled: true
           ha_cluster_sbd_options:
             - name: delay-start
               value: 'no'
             - name: startmode
               value: always
             - name: timeout-action
               value: 'flush,reboot'
             - name: watchdog-timeout
               value: 30
           ha_cluster_node_options:
             - node_name: node1
               sbd_watchdog_modules:
                 - iTCO_wdt
               sbd_watchdog_modules_blocklist:
                 - ipmi_watchdog
               sbd_watchdog: /dev/watchdog1
               sbd_devices: "{{ my_sbd_devices }}"
             - node_name: node2
               sbd_watchdog_modules:
                 - iTCO_wdt
               sbd_watchdog_modules_blocklist:
                 - ipmi_watchdog
               sbd_watchdog: /dev/watchdog1
               sbd_devices: "{{ my_sbd_devices }}"
           # Best practice for setting 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:
                     - name: devices
                       value: "{{ my_sbd_devices | join(',') }}"
                     - name: pcmk_delay_base
                       value: 30

   Copy to Clipboard

   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_sbd_enabled: true

   A variable that determines whether the cluster can use the SBD node fencing mechanism.

   ha_cluster_sbd_options: <sbd options>

   A list of name-value dictionaries specifying SBD options. For information about these options, see the Configuration via environment section of the sbd(8) man page on your system.

   ha_cluster_node_options: <node options>

   A variable that defines settings which vary from one cluster node to another. You can configure the following SBD and watchdog items:

   • sbd_watchdog_modules - Modules to be loaded, which create /dev/watchdog* devices.
   • sbd_watchdog_modules_blocklist - Watchdog kernel modules to be unloaded and blocked.
   • sbd_watchdog - Watchdog device to be used by SBD.
   • sbd_devices - Devices to use for exchanging SBD messages and for monitoring. Always refer to the devices using the long, stable device name (/dev/disk/by-id/).

   ha_cluster_cluster_properties: <cluster properties>

   A list of sets of cluster properties for Pacemaker cluster-wide configuration.

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

   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

   Copy to Clipboard

   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

   Copy to Clipboard

Procedure

1. Create an inventory file for your cluster that configures watchdog and SBD devices for each node by using the ha_cluster variable, as in the following exampla;e

   all:
     hosts:
       node1:
         ha_cluster:
           sbd_watchdog_modules:
             - iTCO_wdt
           sbd_watchdog_modules_blocklist:
             - ipmi_watchdog
           sbd_watchdog: /dev/watchdog1
           sbd_devices:
             - /dev/disk/by-id/000001
             - /dev/disk/by-id/000001
             - /dev/disk/by-id/000003
       node2:
         ha_cluster:
           sbd_watchdog_modules:
             - iTCO_wdt
           sbd_watchdog_modules_blocklist:
             - ipmi_watchdog
           sbd_watchdog: /dev/watchdog1
           sbd_devices:
             - /dev/disk/by-id/000001
             - /dev/disk/by-id/000002
             - /dev/disk/by-id/000003

   Copy to Clipboard

   The SBD and watchdog settings specified in the example inventory include the following:

   sbd_watchdog_modules

   Watchdog kernel modules to be loaded, which create /dev/watchdog* devices.

   sbd_watchdog_modules_blocklist

   Watchdog kernel modules to be unloaded and blocked.

   sbd_watchdog

   Watchdog device to be used by SBD.

   sbd_devices

   Devices to use for exchanging SBD messages and for monitoring. Always refer to the devices using the long, stable device name (/dev/disk/by-id/).

   For general information about creating an inventory file, see Preparing a control node on RHEL 10.

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

      Copy to Clipboard

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

      cluster_password: <cluster_password>

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

3. Create a playbook file, for example ~/playbook.yml, as in the following example. Since you have specified the SBD and watchog variables in an inventory, you do not need to include them in the playbook.

   ---
   - name: Create a high availability cluster
     hosts: node1 node2
     vars_files:
       - ~/vault.yml
     tasks:
       - name: Configure a cluster with sbd fencing devices configured in an inventory file
         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_sbd_enabled: true
             ha_cluster_sbd_options:
               - name: delay-start
                 value: 'no'
               - name: startmode
                 value: always
               - name: timeout-action
                 value: 'flush,reboot'
               - name: watchdog-timeout
                 value: 30
             # Best practice for setting 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
                       # this only works if all nodes have the same sbd_devices
                       - name: devices
                         value: "{{ ha_cluster.sbd_devices | join(',') }}"
                       - name: pcmk_delay_base
                         value: 30

   Copy to Clipboard

   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_sbd_enabled: true

   A variable that determines whether the cluster can use the SBD node fencing mechanism.

   ha_cluster_sbd_options: sbd options

   A list of name-value dictionaries specifying SBD options. For information about these options, see the Configuration via environment section of the sbd(8) man page on your system.

   ha_cluster_cluster_properties: cluster properties

   A list of sets of cluster properties for Pacemaker cluster-wide configuration.

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

   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.

4. Validate the playbook syntax:

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

   Copy to Clipboard

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

5. Run the playbook:

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

   Copy to Clipboard

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>

      Copy to Clipboard

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

      cluster_password: <cluster_password>

      Copy to Clipboard
   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: Configure a cluster with utilization 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_cluster_properties:
               - attrs:
                   - name: placement-strategy
                     value: utilization
             ha_cluster_node_options:
               - node_name: node1
                 utilization:
                   - attrs:
                       - name: utilization1
                         value: 1
                       - name: utilization2
                         value: 2
               - node_name: node2
                 utilization:
                   - attrs:
                       - name: utilization1
                         value: 3
                       - name: utilization2
                         value: 4
             ha_cluster_resource_primitives:
               - id: resource1
                 agent: 'ocf:pacemaker:Dummy'
                 utilization:
                   - attrs:
                       - name: utilization1
                         value: 2
                       - name: utilization2
                         value: 3

   Copy to Clipboard

   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_cluster_properties: <cluster properties>

   List of sets of cluster properties for Pacemaker cluster-wide configuration. For utilization to have an effect, the placement-strategy property must be set and its value must be different from the value default.

   `ha_cluster_node_options: <node options>

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

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

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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>

      Copy to Clipboard

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

      cluster_password: <cluster_password>

      Copy to Clipboard
   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: Configure a cluster with alerts
         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_alerts:
               - id: alert1
                 path: /alert1/path
                 description: Alert1 description
                 instance_attrs:
                   - attrs:
                       - name: alert_attr1_name
                         value: alert_attr1_value
                 meta_attrs:
                   - attrs:
                       - name: alert_meta_attr1_name
                         value: alert_meta_attr1_value
                 recipients:
                   - value: recipient_value
                     id: recipient1
                     description: Recipient1 description
                     instance_attrs:
                       - attrs:
                           - name: recipient_attr1_name
                             value: recipient_attr1_value
                     meta_attrs:
                       - attrs:
                           - name: recipient_meta_attr1_name
                             value: recipient_meta_attr1_value

   Copy to Clipboard

   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_alerts: <alert definitions>

   A variable that defines Pacemaker alerts.

   • id - ID of an alert.
   • path - Path to the alert agent executable.
   • description- Description of the alert.
   • instance_attrs - List of sets of the alert’s instance attributes. Currently, only one set is supported, so the first set is used and the rest are ignored.
   • meta_attrs - List of sets of the alert’s meta attributes. Currently, only one set is supported, so the first set is used and the rest are ignored.
   • recipients - List of alert’s recipients.
   • value- Value of a recipient.
   • id - ID of the recipient.
   • description - Description of the recipient.
   • instance_attrs -List of sets of the recipient’s instance attributes. Currently, only one set is supported, so the first set is used and the rest are ignored.
   • meta_attrs - List of sets of the recipient’s meta attributes. Currently, only one set is supported, so the first set is used and the rest are ignored.

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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>

      Copy to Clipboard

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

      cluster_password: <cluster_password>

      Copy to Clipboard
   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

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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>

      Copy to Clipboard

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

      cluster_password: <cluster_password>

      Copy to Clipboard
   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

   Copy to Clipboard

   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

   Copy to Clipboard

   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

   Copy to Clipboard

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

   Copy to Clipboard

   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

   Copy to Clipboard