Automating system administration by using RHEL system roles

Procedure

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

   [root@control-node]# useradd ansible

2. Switch to the newly created ansible user:

   [root@control-node]# su - ansible

   Perform the rest of the procedure as this user.

3. Create an SSH public and private key:

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

   Use the suggested default location for the key file.

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

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

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

   Note

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

   With these settings, Ansible performs the following actions:

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

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

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

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

7. Install RHEL system roles:

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

     [root@control-node]# 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 checks, such as for parse errors, before installing the file.

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

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

        ansible   ALL=(ALL) ALL

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

        ansible   ALL=(ALL) NOPASSWD: ALL

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

Verification

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

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

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

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

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

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

Procedure

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

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

Procedure

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   The settings specified in the example playbook include the following:

   cockpit_manage_selinux: true

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

   cockpit_manage_firewall: true

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

   cockpit_certificates: <YAML_dictionary>

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   ---
   - name: Configure 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>
       ha_cluster_manage_firewall: true
       ha_cluster_manage_selinux: true
       # Set a different resource-stickiness value during
       # and outside work hours. This allows resources to
       # automatically move back to their most
       # preferred hosts, but at a time that
       # does not interfere with business activities.
       ha_cluster_resource_defaults:
         meta_attrs:
           - id: core-hours
             rule: date-spec hours=9-16 weekdays=1-5
             score: 2
             attrs:
               - name: resource-stickiness
                 value: INFINITY
           - id: after-hours
             score: 1
             attrs:
               - name: resource-stickiness
                 value: 0
       # Default the timeout on all 10-second-interval
       # monitor actions on IPaddr2 resources to 8 seconds.
       ha_cluster_resource_operation_defaults:
         meta_attrs:
           - rule: resource ::IPaddr2 and op monitor interval=10s
             score: INFINITY
             attrs:
               - name: timeout
                 value: 8s

   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. Store your sensitive variables in an encrypted file:

   1. Create the vault:

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

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

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

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

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

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

3. Validate the playbook syntax:

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

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

4. Run the playbook:

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

Procedure

1. 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 an inventory file specifying the nodes in the cluster, as described in Specifying an inventory for the ha_cluster system role.

2. Create a playbook file, for example new-cluster.yml.

   Note

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

   The following example playbook file configures a cluster running the firewalld and selinux services with node attributes configured for the nodes in the cluster.

   - hosts: node1 node2
     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_node_options:
         - node_name: node1
           attributes:
             - attrs:
                 - name: attribute1
                   value: value1A
                 - name: attribute2
                   value: value2A
         - node_name: node2
           attributes:
             - attrs:
                 - name: attribute1
                   value: value1B
                 - name: attribute2
                   value: value2B
   
     roles:
       - linux-system-roles.ha_cluster

3. Save the file.

4. Run the playbook, specifying the path to the inventory file inventory you created in Step 1.

   # ansible-playbook -i inventory new-cluster.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 journald
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure persistent logging
         ansible.builtin.include_role:
           name: rhel-system-roles.journald
         vars:
           journald_persistent: true
           journald_max_disk_size: <size>
           journald_per_user: true
           journald_sync_interval: <interval>

   The settings specified in the example playbook include the following:

   journald_persistent: true

   Enables persistent logging.

   journald_max_disk_size: <size>

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

   journald_per_user: true

   Configures journald to keep log data separate for each user.

   journald_sync_interval: <interval>

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   ---
   - name: Configure PCP webhooks
     hosts: servers
     tasks:
       - name: Configure PCP metrics recording
         ansible.builtin.include_role:
           name: rhel-system-roles.metrics
         vars:
           metrics_retention_days: 7
           metrics_manage_firewall: true
   
   
   - name: Configure the PMIE webhooks
     hosts: metrics_monitor
     tasks:
       - name: Configure the monitoring node
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.metrics
         vars:
           metrics_manage_firewall: true
           metrics_retention_days: 7
           metrics_monitored_hosts:  "{{ groups['servers'] }}"
           metrics_webhook_endpoint: "http://<webserver>:<port>/<endpoint>"

   The settings specified in the example playbook include the following:

   metrics_manage_firewall

   When true, the firewall RHEL system role manages the ports used by the metrics role.

   metrics_retention_days

   Number of days to keep the collected metrics.

   metrics_monitored_hosts

   Hosts that the monitoring system should observe.

   metrics_webhook_endpoint

   A webhook endpoint where notifications of any detected performance issues are sent. By default, these detections are logged to the local system only.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.metrics/README.md file on the control node. The playbook configures the pcp-monitor-node-01.example.com host as the central monitoring site for itself and the server-node-01.example.com and server-node-02.example.com systems. The playbook also configures the global webhook_action and global webhook_endpoint PMIE configuration options for all 3 systems and restarts the PMIE service to apply the changes.

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. Check the configuration summary on pcp-monitor-node-01.example.com:

   [root@pcp-monitor-node-01 ~]# pcp summary
   Performance Co-Pilot configuration on pcp-monitor-node-01.example.com:
   
    platform: Linux pcp-monitor-node-01.example.com 5.14.0-427.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Feb 23 01:51:18 EST 2024 x86_64
    hardware: 8 cpus, 1 disk, 1 node, 1773MB RAM
    timezone: CEST-2
    services: pmcd pmproxy
    pmcd: Version 6.2.0-1, 12 agents, 6 clients
    pmda: root pmcd proc pmproxy xfs linux nfsclient mmv kvm jbd2
          	dm openmetrics
    pmlogger: primary logger: /var/log/pcp/pmlogger/pcp-monitor-node-01.example.com/20240510.16.25
              server-node-01.example.com: /var/log/pmlogger/server-node-01.example.com/20240510.16.25
              server-node-02.example.com: /var/log/pmlogger/server-node-02.example.com/20240510.16.25
    pmie: primary engine: /var/log/pcp/pmie/pcp-monitor-node-01.example.com/pmie.log
          server-node-01.example.com: : /var/log/pcp/pmie/server-node-01.example.com/pmie.log
          server-node-02.example.com: : /var/log/pcp/pmie/server-node-02.example.com/pmie.log

   The final three lines of the summary show that PMIE is configured to monitor all three systems.

2. Verify that the global webhook_action PMIE configuration option is enabled:

   [root@pcp-monitor-node-01 ~]# grep webbook_action /var/lib/pcp/config/pmie/config.default
   // 0 global webhook_action = yes

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

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

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

      sa_pwd: <sa_password>

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

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

   ---
   - name: Installing and configuring Microsoft SQL Server
     hosts: managed-node-01.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: SQL Server with an existing private key and certificate
         ansible.builtin.include_role:
           name: microsoft.sql.server
         vars:
           mssql_accept_microsoft_odbc_driver_17_for_sql_server_eula: true
           mssql_accept_microsoft_cli_utilities_for_sql_server_eula: true
           mssql_accept_microsoft_sql_server_standard_eula: true
   
           mssql_version: 2022
           mssql_password: "{{ sa_pwd  }}"
           mssql_edition: Developer
           mssql_tcp_port: 1433
           mssql_manage_firewall: true
   
           mssql_tls_enable: true
           mssql_tls_cert: sql_crt.pem
           mssql_tls_private_key: sql_cert.key
           mssql_tls_version: 1.2
           mssql_tls_force: true

   The settings specified in the example playbook include the following:

   mssql_tls_enable: true

   Enables TLS encryption. If you enable this setting, you must also define mssql_tls_cert and mssql_tls_private_key.

   mssql_tls_cert: <path>

   Sets the path to the TLS certificate stored on the control node. The role copies this file to the /etc/pki/tls/certs/ directory on the managed node.

   mssql_tls_private_key: <path>

   Sets the path to the TLS private key on the control node. The role copies this file to the /etc/pki/tls/private/ directory on the managed node.

   mssql_tls_force: true

   Replaces the TLS certificate and private key in their destination directories if they exist.

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

3. Validate the playbook syntax:

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

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

4. Run the playbook:

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

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

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

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

      sa_pwd: <sa_password>

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

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

   ---
   - name: Installing and configuring Microsoft SQL Server
     hosts: managed-node-01.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: SQL Server with certificates issued by Red Hat IdM
         ansible.builtin.include_role:
           name: microsoft.sql.server
         vars:
           mssql_accept_microsoft_odbc_driver_17_for_sql_server_eula: true
           mssql_accept_microsoft_cli_utilities_for_sql_server_eula: true
           mssql_accept_microsoft_sql_server_standard_eula: true
   
           mssql_version: 2022
           mssql_password: "{{ sa_pwd  }}"
           mssql_edition: Developer
           mssql_tcp_port: 1433
           mssql_manage_firewall: true
   
           mssql_tls_enable: true
           mssql_tls_certificates:
             - name: sql_cert
               dns: server.example.com
               ca: ipa

   The settings specified in the example playbook include the following:

   mssql_tls_enable: true

   Enables TLS encryption. If you enable this setting, you must also define mssql_tls_certificates.

   mssql_tls_certificates

   A list of YAML dictionaries with settings for the certificate role.

   name: <file_name>

   Defines the base name of the certificate and private key. The certificate role stores the certificate in the /etc/pki/tls/certs/<file_name>.crt and the private key in the /etc/pki/tls/private/<file_name>.key file.

   dns: <hostname_or_list_of_hostnames>

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

   ca: <ca_type>

   Defines how the certificate role requests the certificate. Set the variable to ipa if the host is enrolled in an IdM domain or self-sign to request a self-signed certificate.

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

3. Validate the playbook syntax:

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

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

4. Run the playbook:

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

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

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

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

      sa_pwd: <sa_password>

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

2. Edit an existing playbook file, for example ~/playbook.yml, and add the storage and log-related variables:

   ---
   - name: Installing and configuring Microsoft SQL Server
     hosts: managed-node-01.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: SQL Server with custom storage paths
         ansible.builtin.include_role:
           name: microsoft.sql.server
         vars:
           mssql_accept_microsoft_odbc_driver_17_for_sql_server_eula: true
           mssql_accept_microsoft_cli_utilities_for_sql_server_eula: true
           mssql_accept_microsoft_sql_server_standard_eula: true
   
           mssql_version: 2022
           mssql_password: "{{ sa_pwd  }}"
           mssql_edition: Developer
           mssql_tcp_port: 1433
           mssql_manage_firewall: true
   
           mssql_datadir: /var/lib/mssql/
           mssql_datadir_mode: '0700'
           mssql_logdir: /var/log/mssql/
           mssql_logdir_mode: '0700'

   The settings specified in the example playbook include the following:

   mssql_datadir_mode and mssql_logdir_mode

   Set the permission modes. Specify the value in single quotes to ensure that the role parses the value as a string and not as an octal number.

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

3. Validate the playbook syntax:

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

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

4. Run the playbook:

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

Verification

1. Display the mode of the data directory:

   $ ansible managed-node-01.example.com -m command -a 'ls -ld /var/lib/mssql/'
   drwx------. 12 mssql mssql 4096 Jul  3 13:53 /var/lib/mssql/

2. Display the mode of the log directory:

   $ ansible managed-node-01.example.com -m command -a 'ls -ld /var/log/mssql/'
   drwx------. 12 mssql mssql 4096 Jul  3 13:53 /var/log/mssql/

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

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

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

      sa_pwd: <sa_password>
      sql_pwd: <SQL_AD_password>
      ad_admin_pwd: <AD_admin_password>

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

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

   ---
   - name: Installing and configuring Microsoft SQL Server
     hosts: managed-node-01.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: SQL Server with AD authentication
         ansible.builtin.include_role:
           name: microsoft.sql.server
         vars:
           mssql_accept_microsoft_odbc_driver_17_for_sql_server_eula: true
           mssql_accept_microsoft_cli_utilities_for_sql_server_eula: true
           mssql_accept_microsoft_sql_server_standard_eula: true
   
           mssql_version: 2022
           mssql_password: "{{ sa_pwd }}"
           mssql_edition: Developer
           mssql_tcp_port: 1433
           mssql_manage_firewall: true
   
           mssql_ad_configure: true
           mssql_ad_join: true
           mssql_ad_sql_user: sqluser
           mssql_ad_sql_password: "{{ sql_pwd }}"
           ad_integration_realm: ad.example.com
           ad_integration_user: Administrator
           ad_integration_password: "{{ ad_admin_pwd }}"

   The settings specified in the example playbook include the following:

   mssql_ad_configure: true

   Enables authentication against AD.

   mssql_ad_join: true

   Uses the ad_integration RHEL system role to join the managed node to AD. The role uses the settings from the ad_integration_realm, ad_integration_user, and ad_integration_password variables to join the domain.

   mssql_ad_sql_user: <username>

   Sets the name of an AD account that the role should create in AD and SQL Server for administration purposes.

   ad_integration_user: <AD_user>

   Sets the name of an AD user with privileges to join machines to the domain and to create the AD user specified in mssql_ad_sql_user.

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

3. Validate the playbook syntax:

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

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

4. Run the playbook:

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

5. In your AD domain, enable 128 bit and 256 bit Kerberos authentication for the AD SQL user which you specified in the playbook. Use one of the following options:

   • In the Active Directory Users and Computers application:

     1. Navigate to ad.example.com > Users > sqluser > Accounts.
     2. In the Account options list, select This account supports Kerberos AES 128 bit encryption and This account supports Kerberos AES 256 bit encryption.
     3. Click Apply.

   • In PowerShell in admin mode, enter:

     C:\> Set-ADUser -Identity sqluser -KerberosEncryptionType AES128,AES256

6. Authorize AD users that should be able to authenticate to SQL Server. On the SQL Server, perform the following steps:

   1. Obtain a Kerberos ticket for the Administrator user:

      $ kinit Administrator@ad.example.com

   2. Authorize an AD user:

      $ /opt/mssql-tools/bin/sqlcmd -S. -Q 'CREATE LOGIN [AD\<AD_user>] FROM WINDOWS;'

      Repeat this step for every AD user who should be able to access SQL Server.

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: Ethernet connection profile with static IP address settings
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         vars:
           network_connections:
             - name: enp1s0
               interface_name: enp1s0
               type: ethernet
               autoconnect: yes
               ip:
                 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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   The settings specified in the example playbook include the following:

   match

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

   path

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   The settings specified in the example playbook include the following:

   dhcp4: yes

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

   auto6: yes

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   The settings specified in the example playbook include the following:

   match: path

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

   path: <path_and_expressions>

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

   dhcp4: yes

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

   auto6: yes

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   e settings specified in the example playbook include the following:

   type: <profile_type>

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

   dhcp4: <value>

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

   auto6: <value>

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

   parent: <parent_device>

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   The settings specified in the example playbook include the following:

   type: <profile_type>

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

   dhcp4: yes

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

   auto6: yes

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

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

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

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

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

Procedure

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

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

   The settings specified in the example playbook include the following:

   type: <profile_type>

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

   dhcp4: yes

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

   auto6: yes

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

   mode: <bond_mode>

   Sets the bonding mode. Possible values are:

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

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   The settings specified in the example playbook include the following:

   type: <profile_type>

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

   parent: <parent_device>

   Sets the parent device of the IPoIB connection profile.

   p_key: <value>

   Sets the InfiniBand partition key. If you set this variable, do not set interface_name on the IPoIB device.

   transport_mode: <mode>

   Sets the IPoIB connection operation mode. You can set this variable to datagram (default) or connected.

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

1. Display the IP settings of the mlx4_ib0.8002 device:

   # ansible managed-node-01.example.com -m command -a 'ip address show mlx4_ib0.8002'
   managed-node-01.example.com | CHANGED | rc=0 >>
   ...
   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:

   # ansible managed-node-01.example.com -m command -a 'cat /sys/class/net/mlx4_ib0.8002/pkey'
   managed-node-01.example.com | CHANGED | rc=0 >>
   0x8002

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

   # ansible managed-node-01.example.com -m command -a 'cat /sys/class/net/mlx4_ib0.8002/mode'
   managed-node-01.example.com | CHANGED | rc=0 >>
   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

   The settings specified in the example playbook include the following:

   table: <value>

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

   routing_rule: <list>

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

   zone: <zone_name>

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

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

   1. Install the traceroute package:

      # 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. Store your sensitive variables in an encrypted file:

   1. Create the vault:

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

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

      pwd: <password>

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

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

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

   The settings specified in the example playbook include the following:

   ieee802_1x

   This variable contains the 802.1X-related settings.

   eap: tls

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

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

3. Validate the playbook syntax:

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

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

4. Run the playbook:

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

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

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

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

      pwd: <password>

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

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

   ---
   - name: Configure 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"
   
       - name: Wifi connection profile with dynamic IP address settings and 802.1X
         ansible.builtin.import_role:
           name: rhel-system-roles.network
         vars:
           network_connections:
             - name: Wifi connection profile with dynamic IP address settings and 802.1X
               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: "{{ pwd }}"
                 private_key_password_flags: none
                 client_cert: "/etc/pki/tls/client.pem"
                 ca_cert: "/etc/pki/tls/cacert.pem"
                 domain_suffix_match: "example.com"

   The settings specified in the example playbook include the following:

   ieee802_1x

   This variable contains the 802.1X-related settings.

   eap: tls

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

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

3. Validate the playbook syntax:

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

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

4. Run the playbook:

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

Procedure

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

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

1. Display the IPv4 routes:

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

2. Display the IPv6 routes:

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

Procedure

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

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

   The settings specified in the example playbook include the following:

   gro: no

   Disables Generic receive offload (GRO).

   gso: yes

   Enables Generic segmentation offload (GSO).

   tx_sctp_segmentation: no

   Disables TX stream control transmission protocol (SCTP) segmentation.

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

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

   The settings specified in the example playbook include the following:

   rx_frames: <value>

   Sets the number of RX frames.

   gso: <value>

   Sets the number of TX frames.

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
       - name: Ethernet connection profile with dynamic IP address setting and increased ring buffer sizes
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         vars:
           network_connections:
             - name: enp1s0
               type: ethernet
               autoconnect: yes
               ip:
                 dhcp4: yes
                 auto6: yes
               ethtool:
                 ring:
                   rx: 4096
                   tx: 4096
               state: up

   The settings specified in the example playbook include the following:

   rx: <value>

   Sets the maximum number of received ring buffer entries.

   tx: <value>

   Sets the maximum number of transmitted ring buffer entries.

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

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

   - name: Configure Podman
     hosts: managed-node-01.example.com
     tasks:
       - name: Create a web application and a database
         ansible.builtin.include_role:
           name: rhel-system-roles.podman
         vars:
           podman_create_host_directories: true
           podman_firewall:
             - port: 8080-8081/tcp
               state: enabled
             - port: 12340/tcp
               state: enabled
           podman_selinux_ports:
             - ports: 8080-8081
               setype: http_port_t
           podman_kube_specs:
             - state: started
               run_as_user: dbuser
               run_as_group: dbgroup
               kube_file_content:
                 apiVersion: v1
                 kind: Pod
                 metadata:
                   name: db
                 spec:
                   containers:
                     - name: db
                       image:  quay.io/linux-system-roles/mysql:5.6
                       ports:
                         - containerPort: 1234
                           hostPort: 12340
                       volumeMounts:
                         - mountPath: /var/lib/db:Z
                           name: db
                   volumes:
                     - name: db
                       hostPath:
                         path: /var/lib/db
             - state: started
               run_as_user: webapp
               run_as_group: webapp
               kube_file_src: /path/to/webapp.yml

   The settings specified in the example playbook include the following:

   run_as_user and run_as_group

   Specify that containers are rootless.

   kube_file_content

   Contains a Kubernetes YAML file defining the first container named db. You can generate the Kubernetes YAML file using the podman kube generate command.

   • The db container is based on the quay.io/db/db:stable container image.
   • The db bind mount maps the /var/lib/db directory on the host to the /var/lib/db directory in the container. The Z flag labels the content with a private unshared label, therefore, only the db container can access the content.

   kube_file_src: <path>

   Defines the second container. The content of the /path/to/webapp.yml file on the controller node will be copied to the kube_file field on the managed node.

   volumes: <list>

   A YAML list to define the source of the data to provide in one or more containers. For example, a local disk on the host (hostPath) or other disk device.

   volumeMounts: <list>

   A YAML list to define the destination where the individual container will mount a given volume.

   podman_create_host_directories: true

   Creates the directory on the host. This instructs the role to check the kube specification for hostPath volumes and create those directories on the host. If you need more control over the ownership and permissions, use podman_host_directories.

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

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

3. Run the playbook:

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

Procedure

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

   - name: Configure Podman
     hosts: managed-node-01.example.com
     tasks:
       - name: Start Apache server on port 8080
         ansible.builtin.include_role:
           name: rhel-system-roles.podman
     vars:
       podman_firewall:
         - port: 8080/tcp
           state: enabled
       podman_kube_specs:
         - state: started
           kube_file_content:
             apiVersion: v1
             kind: Pod
             metadata:
               name: ubi8-httpd
             spec:
               containers:
                 - name: ubi8-httpd
                   image: registry.access.redhat.com/ubi8/httpd-24
                   ports:
                     - containerPort: 8080
                       hostPort: 8080
                   volumeMounts:
                     - mountPath: /var/www/html:Z
                       name: ubi8-html
               volumes:
                 - name: ubi8-html
                   persistentVolumeClaim:
                     claimName: ubi8-html-volume

   The settings specified in the example playbook include the following:

   kube_file_content

   Contains a Kubernetes YAML file defining the first container named db. You can generate the Kubernetes YAML file using the podman kube generate command.

   • The ubi8-httpd container is based on the registry.access.redhat.com/ubi8/httpd-24 container image.
   • The ubi8-html-volume maps the /var/www/html directory on the host to the container. The Z flag labels the content with a private unshared label, therefore, only the ubi8-httpd container can access the content.
   • The pod mounts the existing persistent volume named ubi8-html-volume with the mount path /var/www/html.

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

2. Validate the playbook syntax:

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

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

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure