Procedure

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

   [root@control-node]# useradd ansible

2. Switch to the newly created ansible user:

   [root@control-node]# su - ansible

   Perform the rest of the procedure as this user.

3. Create an SSH public and private key:

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

   Use the suggested default location for the key file.

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

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

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

   Note

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

   With these settings, Ansible performs the following actions:

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

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

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

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

7. Install RHEL system roles:

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

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

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

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

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

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

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

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

Procedure

1. Create a user named ansible:

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

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

2. Set a password for the ansible user:

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

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

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

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

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

   2. When prompted, connect by entering yes:

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

   3. When prompted, enter the password:

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

   4. Verify the SSH connection by remotely executing a command on the control node:

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

4. Create a sudo configuration for the ansible user:

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

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

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

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

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

        ansible   ALL=(ALL) ALL

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

        ansible   ALL=(ALL) NOPASSWD: ALL

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

Verification

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

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

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

2. Verify that privilege escalation works correctly by running the whoami utility on 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

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

Procedure

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

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

Procedure

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   • Set the name parameter to the desired name of the certificate, such as mycert.
   • Set the dns parameter to the domain to be included in the certificate, such as *.example.com.
   • Set the ca parameter to self-sign.

   By default, certmonger automatically tries to renew the certificate before it expires. You can disable this by setting the auto_renew parameter in the Ansible playbook to no.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   • Set the name parameter to the desired name of the certificate, such as mycert.
   • Set the dns parameter to the domain to be included in the certificate, such as www.example.com.
   • Set the principal parameter to specify the Kerberos principal, such as HTTP/www.example.com@EXAMPLE.COM.
   • Set the ca parameter to ipa.

   By default, certmonger automatically tries to renew the certificate before it expires. You can disable this by setting the auto_renew parameter in the Ansible playbook to no.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   • Set the name parameter to the desired name of the certificate, such as mycert.
   • Set the dns parameter to the domain to be included in the certificate, such as www.example.com.
   • Set the ca parameter to the CA you want to use to issue the certificate, such as self-sign.
   • Set the run_before parameter to the command you want to execute before this certificate is issued or renewed, such as systemctl stop httpd.service.
   • Set the run_after parameter to the command you want to execute after this certificate is issued or renewed, such as systemctl start httpd.service.

   By default, certmonger automatically tries to renew the certificate before it expires. You can disable this by setting the auto_renew parameter in the Ansible playbook to no.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   You can replace the FUTURE value with your preferred crypto policy, for example: DEFAULT, LEGACY, and FIPS:OSPP.

   The crypto_policies_reboot_ok: true setting causes the system to reboot after the system role changes the cryptographic policy.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

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

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

2. Validate the playbook syntax:

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

3. Run the playbook:

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

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

Procedure

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   The permanent: true option makes the new settings persistent across reboots.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   ---
   - name: Create TLS certificates and key files in a high availability cluster
     hosts: node1 node2
     roles:
       - rhel-system-roles.ha_cluster
     vars:
       ha_cluster_cluster_name: my-new-cluster
       ha_cluster_hacluster_password: <password>
       ha_cluster_manage_firewall: true
       ha_cluster_manage_selinux: true
       ha_cluster_pcsd_certificates:
         - name: FILENAME
           common_name: "{{ ansible_hostname }}"
           ca: self-sign

   This playbook configures a cluster running the firewalld and selinux services and creates a self-signed pcsd certificate and private key files in /var/lib/pcsd. The pcsd certificate has the file name FILENAME.crt and the key file is named FILENAME.key.

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   ---
   - name: Create a high availability cluster with no fencing and which runs no resources
     hosts: node1 node2
     roles:
       - rhel-system-roles.ha_cluster
     vars:
       ha_cluster_cluster_name: my-new-cluster
       ha_cluster_hacluster_password: <password>
       ha_cluster_manage_firewall: true
       ha_cluster_manage_selinux: true

   This example playbook file configures a cluster running the firewalld and selinux services with no fencing configured and which runs no resources.

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   ---
   - name: Create a high availability cluster that includes a fencing device and resources
     hosts: node1 node2
     roles:
       - rhel-system-roles.ha_cluster
     vars:
       ha_cluster_cluster_name: my-new-cluster
       ha_cluster_hacluster_password: <password>
       ha_cluster_manage_firewall: true
       ha_cluster_manage_selinux: true
       ha_cluster_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

   This example playbook file configures a cluster running the firewalld and selinux services. The cluster includes fencing, several resources, and a resource group. It also includes a resource clone for the resource group.

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   ---
   - name: Create a high availability cluster that defines resource and resource operation defaults
     hosts: node1 node2
     roles:
       - rhel-system-roles.ha_cluster
     vars:
       ha_cluster_cluster_name: my-new-cluster
       ha_cluster_hacluster_password: <password>
       # 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

   This example playbook file configures a cluster running the firewalld and selinux services. The cluster includes resource and resource operation defaults.

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   ---
   - name: Create a high availability cluster with resource constraints
     hosts: node1 node2
     roles:
       - rhel-system-roles.ha_cluster
     vars:
       ha_cluster_cluster_name: my-new-cluster
       ha_cluster_hacluster_password: <password>
       ha_cluster_manage_firewall: true
       ha_cluster_manage_selinux: true
       # 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

   This example playbook file configures a cluster running the firewalld and selinux services. The cluster includes resource location constraints, resource colocation constraints, resource order constraints, and resource ticket constraints.

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   This example playbook file configures a cluster running the firewalld and selinux services that configures Corosync properties.

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   ---
   - name: Configure active/passive Apache server in a high availability cluster
     hosts: z1.example.com z2.example.com
     roles:
       - rhel-system-roles.ha_cluster
     vars:
       ha_cluster_hacluster_password: <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

   This example playbook file configures a previously-created Apache HTTP server in an active/passive two-node HA cluster running the firewalld and selinux services.

   This example uses an APC power switch with a host name of zapc.example.com. If the cluster does not use any other fence agents, you can optionally list only the fence agents your cluster requires when defining the ha_cluster_fence_agent_packages variable, as in this example.

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

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

   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

Verification

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

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

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

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

   Hello

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

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

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

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

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

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

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

   Note

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

Procedure

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

   ---
   - name: Configure persistent logging
     hosts: managed-node-01.example.com
     vars:
       journald_persistent: true
       journald_max_disk_size: 2048
       journald_per_user: true
       journald_sync_interval: 1
     roles:
       - rhel-system-roles.journald

   As a result, the journald service stores your logs persistently on a disk to the maximum size of 2048 MB, and keeps log data separate for each user. The synchronization happens every minute.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   ---
   - hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.kdump
     vars:
       kdump_path: /var/crash

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   • name: optional key which associates an arbitrary string with the play as a label and identifies what the play is for.
   • hosts: key in the play which specifies the hosts against which the play is run. The value or values for this key can be provided as individual names of managed hosts or as groups of hosts as defined in the inventory file.
   • vars: section of the playbook which represents a list of variables containing selected kernel parameter names and values to which they have to be set.

   • role: key which specifies what RHEL system role is going to configure the parameters and values mentioned in the vars section.

     Note

     You can modify the kernel parameters and their values in the playbook to fit your needs.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

4. Restart your managed hosts and check the affected kernel parameters to verify that the changes have been applied and persist across reboots.

Procedure

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

1. Test the syntax of the /etc/rsyslog.conf file:

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

2. Verify that the system sends messages to the log:

   1. Send a test message:

      # logger test

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

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

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

Procedure

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

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

   Using this configuration, all messages that contain the error string are logged in /var/log/errors.log, and all other messages are logged in /var/log/others.log.

   You can replace the error property value with the string by which you want to filter.

   You can modify the variables according to your preferences.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

1. Test the syntax of the /etc/rsyslog.conf file:

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

2. Verify that the system sends messages that contain the error string to the log:

   1. Send a test message:

      # logger error

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

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

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

Procedure

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

   ---
   - name: Deploying remote input and remote_files output
     hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.logging
     vars:
       logging_inputs:
         - name: remote_udp_input
           type: remote
           udp_ports: [ 601 ]
         - name: remote_tcp_input
           type: remote
           tcp_ports: [ 601 ]
       logging_outputs:
         - name: remote_files_output
           type: remote_files
       logging_flows:
         - name: flow_0
           inputs: [remote_udp_input, remote_tcp_input]
           outputs: [remote_files_output]
   
   - name: Deploying basics input and forwards output
     hosts: managed-node-02.example.com
     roles:
       - rhel-system-roles.logging
     vars:
       logging_inputs:
         - name: basic_input
           type: basics
       logging_outputs:
         - name: forward_output0
           type: forwards
           severity: info
           target: <host1.example.com>
           udp_port: 601
         - name: forward_output1
           type: forwards
           facility: mail
           target: <host1.example.com>
           tcp_port: 601
       logging_flows:
         - name: flows0
           inputs: [basic_input]
           outputs: [forward_output0, forward_output1]
   
   [basic_input]
   [forward_output0, forward_output1]

   Where <host1.example.com> is the logging server.

   Note

   You can modify the parameters in the playbook to fit your needs.

   Warning

   The logging solution works only with the ports defined in the SELinux policy of the server or client system and open in the firewall. The default SELinux policy includes ports 601, 514, 6514, 10514, and 20514. To use a different port, modify the SELinux policy on the client and server systems.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

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

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

2. Verify that the client system sends messages to the server:

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

      # logger test

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

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

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

Procedure

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

   ---
   - name: Manage metrics
     hosts: localhost
     roles:
       - rhel-system-roles.metrics
     vars:
       metrics_graph_service: yes
       metrics_manage_firewall: true
       metrics_manage_selinux: true

   Because the metrics_graph_service boolean is set to value="yes", Grafana is automatically installed and provisioned with pcp added as a data source. Because metrics_manage_firewall and metrics_manage_selinux are both set to true, the metrics role uses the firewall and selinux system roles to manage the ports used by the metrics role.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   ---
   - name: Configure a fleet of machines to monitor themselves
     hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.metrics
     vars:
       metrics_retention_days: 0
       metrics_manage_firewall: true
       metrics_manage_selinux: true

   Because metrics_manage_firewall and metrics_manage_selinux are both set to true, the metrics role uses the firewall and selinux roles to manage the ports used by the metrics role.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   - name: Set up your local machine to centrally monitor a fleet of machines
     hosts: localhost
     roles:
       - rhel-system-roles.metrics
     vars:
       metrics_graph_service: yes
       metrics_query_service: yes
       metrics_retention_days: 10
       metrics_monitored_hosts: ["database.example.com", "webserver.example.com"]
       metrics_manage_firewall: yes
       metrics_manage_selinux: yes

   Because the metrics_graph_service and metrics_query_service booleans are set to value="yes", grafana is automatically installed and provisioned with pcp added as a data source with the pcp data recording indexed into redis, allowing the pcp querying language to be used for complex querying of the data. Because metrics_manage_firewall and metrics_manage_selinux are both set to true, the metrics role uses the firewall and selinux roles to manage the ports used by the metrics role.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Edit an existing playbook file, for example ~/playbook.yml, and add the authentication-related variables:

   ---
   - name: Set up authentication by using the scram-sha-256 authentication mechanism
     hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.metrics
     vars:
       metrics_retention_days: 0
       metrics_manage_firewall: true
       metrics_manage_selinux: true
       metrics_username: <username>
       metrics_password: <password>

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   ---
   - name: Configure and enable metrics collection for Microsoft SQL Server
     hosts: localhost
     roles:
       - rhel-system-roles.metrics
     vars:
       metrics_from_mssql: true
       metrics_manage_firewall: true
       metrics_manage_selinux: true

   Because metrics_manage_firewall and metrics_manage_selinux are both set to true, the metrics role uses the firewall and selinux roles to manage the ports used by the metrics role.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   ---
   - hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.nbde_server
     vars:
       nbde_server_rotate_keys: yes
       nbde_server_manage_firewall: true
       nbde_server_manage_selinux: true

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

   When nbde_server_manage_firewall and nbde_server_manage_selinux are both set to true, the nbde_server role uses the firewall and selinux roles to manage the ports used by the nbde_server role.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

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

   The nbde_client system role supports only scenarios with Dynamic Host Configuration Protocol (DHCP). To use NBDE for clients with static IP configuration use the following playbook:

   - hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.nbde_client
     vars:
       nbde_client_bindings:
         - device: /dev/rhel/root
           encryption_key_src: /etc/luks/keyfile
           servers:
             - http://server1.example.com
             - http://server2.example.com
         - device: /dev/rhel/swap
           encryption_key_src: /etc/luks/keyfile
           servers:
             - http://server1.example.com
             - http://server2.example.com
     tasks:
       - name: Configure a client with a static IP address during early boot
         ansible.builtin.command:
           cmd: grubby --update-kernel=ALL --args='GRUB_CMDLINE_LINUX_DEFAULT="ip={{ <ansible_default_ipv4.address> }}::{{ <ansible_default_ipv4.gateway> }}:{{ <ansible_default_ipv4.netmask> }}::{{ <ansible_default_ipv4.alias> }}:none"'

   In this playbook, replace the <ansible_default_ipv4.*> strings with IP addresses of your network, for example: ip={{ 192.0.2.10 }}::{{ 192.0.2.1 }}:{{ 255.255.255.0 }}::{{ ens3 }}:none.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   These settings define an Ethernet connection profile for the enp1s0 device with the following settings:

   • A static IPv4 address - 192.0.2.1 with a /24 subnet mask
   • A static IPv6 address - 2001:db8:1::1 with a /64 subnet mask
   • An IPv4 default gateway - 192.0.2.254
   • An IPv6 default gateway - 2001:db8:1::fffe
   • An IPv4 DNS server - 192.0.2.200
   • An IPv6 DNS server - 2001:db8:1::ffbb
   • A DNS search domain - example.com

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   These settings define an Ethernet connection profile with the following settings:

   • A static IPv4 address - 192.0.2.1 with a /24 subnet mask
   • A static IPv6 address - 2001:db8:1::1 with a /64 subnet mask
   • An IPv4 default gateway - 192.0.2.254
   • An IPv6 default gateway - 2001:db8:1::fffe
   • An IPv4 DNS server - 192.0.2.200
   • An IPv6 DNS server - 2001:db8:1::ffbb

   • A DNS search domain - example.com

     The match parameter in this example defines that Ansible applies the play to devices that match PCI ID 0000:00:0[1-3].0, but not 0000:00:02.0. For further details about special modifiers and wild cards you can use, see the match parameter description in the /usr/share/ansible/roles/rhel-system-roles.network/README.md file.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   These settings define an Ethernet connection profile for the enp1s0 device. The connection retrieves IPv4 addresses, IPv6 addresses, default gateway, routes, DNS servers, and search domains from a DHCP server and IPv6 stateless address autoconfiguration (SLAAC).

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   These settings define an Ethernet connection profile. The connection retrieves IPv4 addresses, IPv6 addresses, default gateway, routes, DNS servers, and search domains from a DHCP server and IPv6 stateless address autoconfiguration (SLAAC).

   The match parameter defines that Ansible applies the play to devices that match PCI ID 0000:00:0[1-3].0, but not 0000:00:02.0.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   These settings define a VLAN to operate on top of the enp1s0 device. The VLAN interface has the following settings:

   • A static IPv4 address - 192.0.2.1 with a /24 subnet mask
   • A static IPv6 address - 2001:db8:1::1 with a /64 subnet mask
   • An IPv4 default gateway - 192.0.2.254
   • An IPv6 default gateway - 2001:db8:1::fffe
   • An IPv4 DNS server - 192.0.2.200
   • An IPv6 DNS server - 2001:db8:1::ffbb
   • A DNS search domain - example.com

   • VLAN ID - 10

     The parent attribute in the VLAN profile configures the VLAN to operate on top of the enp1s0 device. As the child device, the VLAN connection contains the IP, default gateway, and DNS configurations.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   These settings define a network bridge with the following settings:

   • A static IPv4 address - 192.0.2.1 with a /24 subnet mask
   • A static IPv6 address - 2001:db8:1::1 with a /64 subnet mask
   • An IPv4 default gateway - 192.0.2.254
   • An IPv6 default gateway - 2001:db8:1::fffe
   • An IPv4 DNS server - 192.0.2.200
   • An IPv6 DNS server - 2001:db8:1::ffbb
   • A DNS search domain - example.com

   • Ports of the bridge - enp7s0 and enp8s0

     Note

     Set the IP configuration on the bridge and not on the ports of the Linux bridge.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   These settings define a network bond with the following settings:

   • A static IPv4 address - 192.0.2.1 with a /24 subnet mask
   • A static IPv6 address - 2001:db8:1::1 with a /64 subnet mask
   • An IPv4 default gateway - 192.0.2.254
   • An IPv6 default gateway - 2001:db8:1::fffe
   • An IPv4 DNS server - 192.0.2.200
   • An IPv6 DNS server - 2001:db8:1::ffbb
   • A DNS search domain - example.com
   • Ports of the bond - enp7s0 and enp8s0

   • Bond mode - active-backup

     Note

     Set the IP configuration on the bond and not on the ports of the Linux bond.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   If you set a p_key parameter as in this example, do not set an interface_name parameter on the IPoIB device.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

1. On the managed-node-01.example.com host, display the IP settings of the mlx4_ib0.8002 device:

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

2. Display the partition key (P_Key) of the mlx4_ib0.8002 device:

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

3. Display the mode of the mlx4_ib0.8002 device:

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

Procedure

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

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

   1. Install the traceroute package:

      # dnf install traceroute

   2. Use the traceroute utility to display the route to a host on the internet:

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

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

2. On a RHEL host in the server subnet:

   1. Install the traceroute package:

      # dnf install traceroute

   2. Use the traceroute utility to display the route to a host on the internet:

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

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

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

   1. Display the rule list:

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

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

   2. Display the routes in table 5000:

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

   3. Display the interfaces and firewall zones:

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

   4. Verify that the external zone has masquerading enabled:

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

Procedure

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

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

   These settings define an Ethernet connection profile for the enp1s0 device with the following settings:

   • A static IPv4 address - 192.0.2.1 with a /24 subnet mask
   • A static IPv6 address - 2001:db8:1::1 with a /64 subnet mask
   • An IPv4 default gateway - 192.0.2.254
   • An IPv6 default gateway - 2001:db8:1::fffe
   • An IPv4 DNS server - 192.0.2.200
   • An IPv6 DNS server - 2001:db8:1::ffbb
   • A DNS search domain - example.com
   • 802.1X network authentication using the TLS Extensible Authentication Protocol (EAP)

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   These settings define a wifi connection profile for the wlp1s0 interface. The profile uses 802.1X standard to authenticate the client to the wifi network. The connection retrieves IPv4 addresses, IPv6 addresses, default gateway, routes, DNS servers, and search domains from a DHCP server and IPv6 stateless address autoconfiguration (SLAAC).

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   Depending on whether it already exists, the procedure creates or updates the enp7s0 connection profile with the following settings:

   • A static IPv4 address - 192.0.2.1 with a /24 subnet mask
   • A static IPv6 address - 2001:db8:1::1 with a /64 subnet mask
   • An IPv4 default gateway - 192.0.2.254
   • An IPv6 default gateway - 2001:db8:1::fffe
   • An IPv4 DNS server - 192.0.2.200
   • An IPv6 DNS server - 2001:db8:1::ffbb
   • A DNS search domain - example.com

   • Static routes:

     • 198.51.100.0/24 with gateway 192.0.2.10
     • 2001:db8:2::/64 with gateway 2001:db8:1::10

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

1. On the managed nodes:

   1. Display the IPv4 routes:

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

   2. Display the IPv6 routes:

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

Procedure

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

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

   This playbook creates the enp1s0 connection profile with the following settings, or updates it if the profile already exists:

   • A static IPv4 address - 198.51.100.20 with a /24 subnet mask
   • A static IPv6 address - 2001:db8:1::1 with a /64 subnet mask
   • An IPv4 default gateway - 198.51.100.254
   • An IPv6 default gateway - 2001:db8:1::fffe
   • An IPv4 DNS server - 198.51.100.200
   • An IPv6 DNS server - 2001:db8:1::ffbb
   • A DNS search domain - example.com

   • ethtool features:

     • Generic receive offload (GRO): disabled
     • Generic segmentation offload (GSO): enabled
     • TX stream control transmission protocol (SCTP) segmentation: disabled

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure an Ethernet connection with ethtool coalesce settings
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         vars:
           network_connections:
             - name: enp1s0
               type: ethernet
               autoconnect: yes
               ip:
                 address:
                   - 198.51.100.20/24
                   - 2001:db8:1::1/64
                 gateway4: 198.51.100.254
                 gateway6: 2001:db8:1::fffe
                 dns:
                   - 198.51.100.200
                   - 2001:db8:1::ffbb
                 dns_search:
                   - example.com
               ethtool:
                 coalesce:
                   rx_frames: 128
                   tx_frames: 128
               state: up

   This playbook creates the enp1s0 connection profile with the following settings, or updates it if the profile already exists:

   • A static IPv4 address - 198.51.100.20 with a /24 subnet mask
   • A static IPv6 address - 2001:db8:1::1 with a /64 subnet mask
   • An IPv4 default gateway - 198.51.100.254
   • An IPv6 default gateway - 2001:db8:1::fffe
   • An IPv4 DNS server - 198.51.100.200
   • An IPv6 DNS server - 2001:db8:1::ffbb
   • A DNS search domain - example.com

   • ethtool coalesce settings:

     • RX frames: 128
     • TX frames: 128

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure an Ethernet connection with increased ring buffer sizes
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         vars:
           network_connections:
             - name: enp1s0
               type: ethernet
               autoconnect: yes
               ip:
                 address:
                   - 198.51.100.20/24
                   - 2001:db8:1::1/64
                 gateway4: 198.51.100.254
                 gateway6: 2001:db8:1::fffe
                 dns:
                   - 198.51.100.200
                   - 2001:db8:1::ffbb
                 dns_search:
                   - example.com
               ethtool:
                 ring:
                   rx: 4096
                   tx: 4096
               state: up

   This playbook creates the enp1s0 connection profile with the following settings, or updates it if the profile already exists:

   • A static IPv4 address - 198.51.100.20 with a /24 subnet mask
   • A static IPv6 address - 2001:db8:1::1 with a /64 subnet mask
   • An IPv4 default gateway - 198.51.100.254
   • An IPv6 default gateway - 2001:db8:1::fffe
   • An IPv4 DNS server - 198.51.100.200
   • An IPv6 DNS server - 2001:db8:1::ffbb
   • A DNS search domain - example.com

   • Maximum number of ring buffer entries:

     • Receive (RX): 4096
     • Transmit (TX): 4096

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   ---
   - name: Manage postfix
     hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.postfix
     vars:
       postfix_conf:
         relay_domains: $mydestination
           relayhost: example.com

   • If you want Postfix to use a different hostname than the fully-qualified domain name (FQDN) that is returned by the gethostname() function, add the myhostname parameter under the postfix_conf: line in the file:

     myhostname = smtp.example.com

   • If the domain name differs from the domain name in the myhostname parameter, add the mydomain parameter. Otherwise, the $myhostname minus the first component is used.

     mydomain = <example.com>

   • Use postfix_manage_firewall: true variable to ensure that the SMTP port is open in the firewall on the servers.

     Manage the SMTP related ports, 25/tcp, 465/tcp, and 587/tcp. If the variable is set to false, the postfix role does not manage the firewall. The default is false.

     Note

     The postfix_manage_firewall variable is limited to adding ports. It cannot be used for removing ports. If you want to remove ports, use the firewall RHEL system role directly.

   • If your scenario involves using non-standard ports, set the postfix_manage_selinux: true variable to ensure that the port is properly labeled for SELinux on the servers.

     Note

     The postfix_manage_selinux variable is limited to adding rules to the SELinux policy. It cannot remove rules from the policy. If you want to remove rules, use the selinux RHEL system role directly.

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   ---
   - name: Manage PostgreSQL
     hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.postgresql
     vars:
       postgresql_version: "13"

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

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

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

      activationKey: <activation_key>
      username: <username>
      password: <password>

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

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

   • To register by using an activation key and organization ID (recommended), use the following playbook:

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

   • To register by using a username and password, use the following playbook:

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

3. Validate the playbook syntax:

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

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

4. Run the playbook:

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