Procedure

1. Create the required Ansible inventory containing the hosts and groups that you want to manage. Here is an example using a file called inventory.ini of a group of hosts called webservers:

   [webservers]
   host1
   host2
   host3

2. Create an Ansible playbook including the required role. The following example shows how to use roles through the roles: option for a playbook:

   The following example shows how to use roles through the roles: option for a given play:

   ---
   - hosts: webservers
     roles:
        - rhel-system-roles.network
        - rhel-system-roles.timesync

   Note

   Every role includes a README file, which documents how to use the role and supported parameter values. You can also find an example playbook for a particular role under the documentation directory of the role. Such documentation directory is provided by default with the rhel-system-roles package, and can be found in the following location:

   /usr/share/doc/rhel-system-roles/SUBSYSTEM/

   Replace SUBSYSTEM with the name of the required role, such as selinux, kdump, network, timesync, or storage.

3. To execute the playbook on specific hosts, you must perform one of the following:

   • Edit the playbook to use hosts: host1[,host2,…​], or hosts: all, and execute the command:

     # ansible-playbook name.of.the.playbook

   • Edit the inventory to ensure that the hosts you want to use are defined in a group, and execute the command:

     # ansible-playbook -i name.of.the.inventory name.of.the.playbook

   • Specify all hosts when executing the ansible-playbook command:

     # ansible-playbook -i host1,host2,... name.of.the.playbook

     Important

     Be aware that the -i flag specifies the inventory of all hosts that are available. If you have multiple targeted hosts, but want to select a host against which you want to run the playbook, you can add a variable in the playbook to be able to select a host. For example:

     Ansible Playbook | example-playbook.yml:
     
     - hosts: "{{ target_host }}"
       roles:
          - rhel-system-roles.network
          - rhel-system-roles.timesync

     Playbook execution command:

     # ansible-playbook -i host1,..hostn -e target_host=host5 example-playbook.yml

1. Copy one of the tests_default.yml to your working directory.

   $ cp /usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/tests/kernel_settings/tests_default.yml .

2. Edit the file, replacing "hosts: all" with "hosts: localhost" to make the playbook run only on the local system.

3. Run the ansible-playbook in the check mode. This does not change any settings on your system.

   $ ansible-playbook --check tests_default.yml

Procedure

1. Install the redhat.rhel_system_roles collection from the Automation Hub:

   # ansible-galaxy collection install redhat.rhel_system_roles

2. Define Red Hat Automation Hub as the default source for content in the ansible.cfg configuration file. See Configuring Red Hat Automation Hub as the primary source for content .

   After the installation is finished, the roles are available as redhat.rhel_system_roles.<role_name>. Additionally, you can find the documentation for each role at /usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/roles/<role_name>/README.md.

1. Copy one of the tests_default.yml to your working directory.

   $ cp /usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/tests/kernel_settings/tests_default.yml .

2. Edit the file, replacing "hosts: all" with "hosts: localhost" to make the playbook run only on the local system.

3. Run the ansible-playbook on the check mode. This does not change any settings on your system.

   $ ansible-playbook --check tests_default.yml

   You can see the command returns with the value failed=0.

Procedure

1. Create a playbook that defines the required role:

   1. Create a new YAML file and open it in a text editor, for example:

      # vi logging-playbook.yml

   2. Insert the following content into the YAML file:

      ---
      - name: Deploying basics input and implicit files output
        hosts: all
        roles:
          - redhat.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. Execute the playbook on a specific inventory:

   # ansible-playbook -i inventory-file logging-playbook.yml

   Where:

   • inventory-file is the name of your inventory file.
   • logging-playbook.yml is the playbook you use.

Verification steps

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

      The hostname is the hostname of the client system. The log displays the user name of the user that entered the logger command, in this case, root.

Procedure

1. Enable the repository containing the necessary utilities for compiling custom Ansible execution environments:

   # subscription-manager repos --enable ansible-automation-platform-2.0-early-access-for-rhel-8-x86_64-rpms

   The repository makes available utilities such as ansible-builder, or ansible-navigator and their dependencies. These utilities are useful for creating and manipulating Ansible execution environments.

2. Install the ansible-core, ansible-builder, and ansible-navigator utilities:

   # yum install ansible-core ansible-builder ansible-navigator

   Ansible core is an automation utility for system configuration and deployment, orchestration of tasks and other advanced IT challenges.

   Ansible Builder is a utility that you can use to customize and build your own Ansible execution environments with the collections and dependencies you need. The utility uses metadata defined in various Ansible collections, as well as by the user.

   Ansible Navigator is a utility that you can use to debug automation, inspect multiple aspects of the automation environment, including execution environments, inventories, collections, modules and more.

3. Install the container-tools module:

   # yum module install container-tools

   The container-tools module includes software packages that install several utilities such as podman, or skopeo. You need these utilities to compile your execution environment with ansible-builder.

4. Login to the Red Hat Registry:

   # skopeo login registry.redhat.io
   Username:
   Password:
   Login Succeeded!

   Use your Customer Portal credentials to access a base container image when you compile your custom execution environment.

5. Create a new directory to store the files used to create the new execution environment:

   # mkdir ansible-execution-environment

6. In the new directory, create the execution-environment.yml file with this content:

   ---
   version: 1
   ansible_config: 'ansible.cfg' 1
   build_arg_defaults:
     EE_BASE_IMAGE: 'quay.io/ansible/ansible-runner:latest' 2
   dependencies:
     galaxy: requirements.yml 3
     python: requirements.txt 4
     system: bindep.txt 5

   The execution-environment.yml file is a definition file that outlines the execution environment’s collection-level dependencies, base image source, and overrides for specific items within the execution environment.

   1

   ansible.cfg is required if the new execution environment pulls collections from a location that requires authentication.

   2

   Initial base image to use as the starting point, in case you want to further customize your execution environment.

   3

   Specifies Ansible collections to be used by your execution environment. You can obtain such collections from servers such as Ansible Galaxy and Automation Hub on Red Hat Hybrid Cloud.

   4

   Defines Python packages to be installed for the execution environment to successfully run.

   5

   Specifies system-level dependencies and it can be used to specify cross-platform requirements.

7. Create the requirements.yml file with similar content according to your needs:

   ---
   collections:
     - name: community.general 1
       version: 3.2.0 2
       source: https://galaxy.ansible.com/ 3
     - name: amazon.aws
   …​

   1

   Ansible collection name

   2

   Specific version to be obtained. If not defined, the latest version is used.

   3

   Server that contains the collection

8. Create the requirements.txt file with similar content according to your needs:

   awxkit>=13.0.0
   boto>=2.49.0
   botocore>=1.12.249
   boto3>=1.9.249
   openshift>=0.6.2
   requests-oauthlib
   …​

   The requirements.txt file contains the Python packages you want to use for your execution environment. You can list a specific package version. If you do not specify any version, the latest will be used.

9. Create the bindep.txt file with similar content according to your needs:

   libxml2-devel [platform:rpm]
   grep >=3.1
   …​

   The bindep.txt file lists requirements for any system-level application or library.

10. The final directory structure of your ansible-execution-environment could look like this:

    ├── bindep.txt
    ├── execution-environment.yml
    ├── requirements.txt
    └── requirements.yml

Procedure

1. Build a container image with the execution environment.

   # ansible-builder build --tag my_first_image:v1.0
   Running command:
     podman build -f context/Containerfile -t my_first_image:v1.0 context
   Complete! The build context can be found at: /root/ansible-execution-environment/context

   The --tag option provides a name to the container image. The name has two parts: a name and an optional tag. For example, you can use --tag my_first_image:v1.0 to name the container my_first_image and give it the v1.0 tag. The tag defaults to latest if not specified.

   After compilation, your project directory will have a similar structure as in the following example:

   ├── context
   │   ├── _build
   │   │   ├── requirements.txt
   │   │   └── requirements.yml
   │   └── Containerfile
   ├── execution-environment.yml
   ├── requirements.txt
   └── requirements.yml

   Each run of the ansible-builder build command recreates the context/Containerfile file, which removes any manual changes made to that file.

2. Verify the newly created image:

   # podman images
   REPOSITORY                      TAG     IMAGE ID        CREATED          SIZE
   localhost/my_first_image        v1.0    9cf1f71d0631    6 minutes ago    776 MB

Procedure

1. Optionally, review the inventory file for illustration purposes:

   #  cat /home/jdoe/<ansible_project_name>/inventory
   [testingservers]
   pdoe@192.168.122.98
   fdoe@192.168.122.226
   
   [db-servers]
   db1.example.com
   db2.example.com
   
   [webservers]
   web1.example.com
   web2.example.com
   192.0.2.42

   The file defines the [testingservers] group and other groups. It allows you to run Ansible Engine more effectively against a specific collection of systems.

2. Create a configuration file to set defaults and privilege escalation for Ansible Engine operations.

   1. Create a new YAML file and open it in a text editor, for example:

      #  vi /home/jdoe/<ansible_project_name>/ansible.cfg

   2. Insert the following content into the file:

      [defaults]
      inventory = ./inventory
      
      [privilege_escalation]
      become = true
      become_method = sudo
      become_user = root
      become_ask_pass = true

      The [defaults] section specifies a path to the inventory file of managed hosts. The [privilege_escalation] section defines that user privileges be shifted to root on the specified managed hosts. This is necessary for successful configuration of kernel parameters. When Ansible playbook is run, you will be prompted for user password. The user automatically switches to root by means of sudo after connecting to a managed host.

3. Create an Ansible playbook that uses the kernel_settings role.

   1. Create a new YAML file and open it in a text editor, for example:

      #  vi /home/jdoe/<ansible_project_name>/kernel_roles.yml

      This file represents a playbook and usually contains an ordered list of tasks, also called plays, that are run against specific managed hosts selected from your inventory file.

   2. Insert the following content into the file:

      ---
      - name: Configure kernel settings
        hosts: testingservers
      
        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
      
        roles:
          - linux-system-roles.kernel_settings

      The name key is optional. It associates an arbitrary string with the play as a label and identifies what the play is for. The hosts key in the play 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.

      The vars section represents a list of variables containing selected kernel parameter names and values to which they have to be set.

      The roles key specifies what 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.

4. Optionally, verify that the syntax in your play is correct.

   #  ansible-playbook --syntax-check kernel-roles.yml
   
   playbook: kernel-roles.yml

   This example shows the successful verification of a playbook.

5. Execute your playbook.

   #  ansible-playbook kernel-roles.yml
   BECOME password:
   
   PLAY [Configure kernel settings]  ... PLAY RECAP **
   fdoe@192.168.122.226       : ok=10   changed=4    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0
   pdoe@192.168.122.98        : ok=10   changed=4    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0

   Before Ansible Engine runs your playbook, you are going to be prompted for your password and so that a user on managed hosts can be switched to root, which is necessary for configuring kernel parameters.

   The recap section shows that the play finished successfully (failed=0) for all managed hosts, and that 4 kernel parameters have been applied (changed=4).

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

Procedure

1. If the host on which you want to execute the instructions in the playbook is not yet inventoried, add the IP or name of this host to the /etc/ansible/hosts Ansible inventory file:

   node.example.com

2. Create the ~/ethernet-static-IP.yml playbook with the following content:

   ---
   - name: Configure an Ethernet connection with static IP
     hosts: node.example.com
     become: true
     tasks:
     - include_role:
         name: linux-system-roles.network
   
       vars:
         network_connections:
           - name: enp7s0
   	  interface_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
             state: up

3. Run the playbook:

   • To connect as root user to the managed host, enter:

     # ansible-playbook -u root ~/ethernet-static-IP.yml

   • To connect as a user to the managed host, enter:

     # ansible-playbook -u user_name --ask-become-pass ~/ethernet-static-IP.yml

     The --ask-become-pass option makes sure that the ansible-playbook command prompts for the sudo password of the user defined in the -u user_name option.

   If you do not specify the -u user_name option, ansible-playbook connects to the managed host as the user that is currently logged in to the control node.

Procedure

1. If the host on which you want to execute the instructions in the playbook is not yet inventoried, add the IP or name of this host to the /etc/ansible/hosts Ansible inventory file:

   node.example.com

2. Create the ~/ethernet-dynamic-IP.yml playbook with the following content:

   ---
   - name: Configure an Ethernet connection with dynamic IP
     hosts: node.example.com
     become: true
     tasks:
     - include_role:
         name: linux-system-roles.network
   
       vars:
         network_connections:
           - name: enp7s0
   	  interface_name: enp7s0
             type: ethernet
             autoconnect: yes
             ip:
               dhcp4: yes
               auto6: yes
             state: up

3. Run the playbook:

   • To connect as root user to the managed host, enter:

     # ansible-playbook -u root ~/ethernet-dynamic-IP.yml

   • To connect as a user to the managed host, enter:

     # ansible-playbook -u user_name --ask-become-pass ~/ethernet-dynamic-IP.yml

     The --ask-become-pass option makes sure that the ansible-playbook command promptsv for the sudo password of the user defined in the -u user_name option.

   If you do not specify the -u user_name option, ansible-playbook connects to the managed host as the user that is currently logged in to the control node.

Procedure

1. If the host on which you want to execute the instructions in the playbook is not yet inventoried, add the IP or name of this host to the /etc/ansible/hosts Ansible inventory file:

   node.example.com

2. Create the ~/vlan-ethernet.yml playbook with the following content:

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

   The parent attribute in the VLAN profile configures the VLAN to operate on top of the enp1s0 device.

3. Run the playbook:

   • To connect as root user to the managed host, enter:

     # ansible-playbook -u root ~/vlan-ethernet.yml

   • To connect as a user to the managed host, enter:

     # ansible-playbook -u user_name --ask-become-pass ~/vlan-ethernet.yml

     The --ask-become-pass option makes sure that the ansible-playbook command prompts for the sudo password of the user defined in the -u user_name option.

   If you do not specify the -u user_name option, ansible-playbook connects to the managed host as the user that is currently logged in to the control node.

Procedure

1. If the host on which you want to execute the instructions in the playbook is not yet inventoried, add the IP or name of this host to the /etc/ansible/hosts Ansible inventory file:

   node.example.com

2. Create the ~/bridge-ethernet.yml playbook with the following content:

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

3. Run the playbook:

   • To connect as root user to the managed host, enter:

     # ansible-playbook -u root ~/bridge-ethernet.yml

   • To connect as a user to the managed host, enter:

     # ansible-playbook -u user_name --ask-become-pass ~/bridge-ethernet.yml

     The --ask-become-pass option makes sure that the ansible-playbook command prompts for the sudo password of the user defined in the -u user_name option.

   If you do not specify the -u user_name option, ansible-playbook connects to the managed host as the user that is currently logged in to the control node.

Procedure

1. If the host on which you want to execute the instructions in the playbook is not yet inventoried, add the IP or name of this host to the /etc/ansible/hosts Ansible inventory file:

   node.example.com

2. Create the ~/bond-ethernet.yml playbook with the following content:

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

3. Run the playbook:

   • To connect as root user to the managed host, enter:

     # ansible-playbook -u root ~/bond-ethernet.yml

   • To connect as a user to the managed host, enter:

     # ansible-playbook -u user_name --ask-become-pass ~/bond-ethernet.yml

     The --ask-become-pass option makes sure that the ansible-playbook command prompts for the sudo password of the user defined in the -u user_name option.

   If you do not specify the -u user_name option, ansible-playbook connects to the managed host as the user that is currently logged in to the control node.

Procedure

1. If the host on which you want to execute the instructions in the playbook is not yet inventoried, add the IP or name of this host to the /etc/ansible/hosts Ansible inventory file:

   node.example.com

2. Create the ~/enable-802.1x.yml playbook with the following content:

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

3. Run the playbook:

   • To connect as root user to the managed host, enter:

     # ansible-playbook -u root ~/enable-802.1x.yml

   • To connect as a user to the managed host, enter:

     # ansible-playbook -u user_name --ask-become-pass ~/ethernet-static-IP.yml

     The --ask-become-pass option makes sure that the ansible-playbook command prompts for the sudo password of the user defined in the -u user_name option.

   If you do not specify the -u user_name option, ansible-playbook connects to the managed host as the user that is currently logged in to the control node.

Procedure

1. If the host on which you want to execute the instructions in the playbook is not yet inventoried, add the IP or name of this host to the /etc/ansible/hosts Ansible inventory file:

   node.example.com

2. Create the ~/ethernet-connection.yml playbook with the following content:

   ---
   - name: Configure an Ethernet connection with static IP and default gateway
     hosts: node.example.com
     become: true
     tasks:
     - include_role:
         name: linux-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

3. Run the playbook:

   • To connect as root user to the managed host, enter:

     # ansible-playbook -u root ~/ethernet-connection.yml

   • To connect as a user to the managed host, enter:

     # ansible-playbook -u user_name --ask-become-pass ~/ethernet-connection.yml

     The --ask-become-pass option makes sure that the ansible-playbook command prompts for the sudo password of the user defined in the -u user_name option.

   If you do not specify the -u user_name option, ansible-playbook connects to the managed host as the user that is currently logged in to the control node.

Procedure

1. If the host on which you want to execute the instructions in the playbook is not yet inventoried, add the IP or name of this host to the /etc/ansible/hosts Ansible inventory file:

   node.example.com

2. Create the ~/add-static-routes.yml playbook with the following content:

   ---
   - name: Configure an Ethernet connection with static IP and additional routes
     hosts: node.example.com
     become: true
     tasks:
     - include_role:
         name: linux-system-roles.network
   
       vars:
         network_connections:
           - name: enp7s0
             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
               route:
                 - network: 192.0.2.0
                   prefix: 24
                   gateway: 198.51.100.1
                 - network: 203.0.113.0
                   prefix: 24
                   gateway: 198.51.100.2
             state: up

3. Run the playbook:

   • To connect as root user to the managed host, enter:

     # ansible-playbook -u root ~/add-static-routes.yml

   • To connect as a user to the managed host, enter:

     # ansible-playbook -u user_name --ask-become-pass ~/add-static-routes.yml

     The --ask-become-pass option makes sure that the ansible-playbook command prompts for the sudo password of the user defined in the -u user_name option.

   If you do not specify the -u user_name option, ansible-playbook connects to the managed host as the user that is currently logged in to the control node.

Procedure

1. If the host on which you want to execute the instructions in the playbook is not yet inventoried, add the IP or name of this host to the /etc/ansible/hosts Ansible inventory file:

   node.example.com

2. Create the ~/configure-ethernet-device-with-ethtool-features.yml playbook with the following content:

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

3. Run the playbook:

   • To connect as root user to the managed host, enter:

     # ansible-playbook -u root ~/configure-ethernet-device-with-ethtool-features.yml

   • To connect as a user to the managed host, enter:

     # ansible-playbook -u user_name --ask-become-pass ~/configure-ethernet-device-with-ethtool-features.yml

     The --ask-become-pass option makes sure that the ansible-playbook command prompts for the sudo password of the user defined in the -u user_name option.

   If you do not specify the -u user_name option, ansible-playbook connects to the managed host as the user that is currently logged in to the control node.

Procedure

1. If the host on which you want to execute the instructions in the playbook is not yet inventoried, add the IP or name of this host to the /etc/ansible/hosts Ansible inventory file:

   node.example.com

2. Create the ~/configure-ethernet-device-with-ethtoolcoalesce-settings.yml playbook with the following content:

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

3. Run the playbook:

   • To connect as root user to the managed host, enter:

     # ansible-playbook -u root ~/configure-ethernet-device-with-ethtoolcoalesce-settings.yml

   • To connect as a user to the managed host, enter:

     # ansible-playbook -u user_name --ask-become-pass ~/configure-ethernet-device-with-ethtoolcoalesce-settings.yml

     The --ask-become-pass option makes sure that the ansible-playbook command prompts for the sudo password of the user defined in the -u user_name option.

   If you do not specify the -u user_name option, ansible-playbook connects to the managed host as the user that is currently logged in to the control node.

Procedure

1. Prepare your playbook. You can either start from the scratch or modify the example playbook installed as a part of the rhel-system-roles package:

   # cp /usr/share/doc/rhel-system-roles/selinux/example-selinux-playbook.yml my-selinux-playbook.yml
   # vi my-selinux-playbook.yml

2. Change the content of the playbook to fit your scenario. For example, the following part ensures that the system installs and enables the selinux-local-1.pp SELinux module:

   selinux_modules:
   - { path: "selinux-local-1.pp", priority: "400" }

3. Save the changes, and exit the text editor.

4. Run your playbook on the host1, host2, and host3 systems:

   # ansible-playbook -i host1,host2,host3 my-selinux-playbook.yml

Procedure

1. Create a playbook that defines the required role:

   1. Create a new YAML file and open it in a text editor, for example:

      # vi logging-playbook.yml

   2. Insert the following content:

      ---
      - name: Deploying basics input and implicit files output
        hosts: all
        roles:
          - linux-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. Run the playbook on a specific inventory:

   # ansible-playbook -i inventory-file /path/to/file/logging-playbook.yml

   Where: * inventory-file is the inventory file. * logging-playbook.yml is the playbook you use.

Verification

1. 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 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 new playbook.yml file with the following content:

   ---
   - name: Deploying files input and configured files output
     hosts: all
     roles:
       - linux-system-roles.logging
     vars:
       logging_inputs:
         - name: files_input0
           type: files
           input_log_path: /var/log/containerA/*.log
         - name: files_input1
           type: files
           input_log_path: /var/log/containerB/*.log
       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_input0, files_input1]
           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. Optional: Verify playbook syntax.

   # ansible-playbook --syntax-check playbook.yml

3. Run the playbook on your inventory file:

   # ansible-playbook -i inventory_file /path/to/file/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 (level 1), master config /etc/rsyslog.conf
   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 that defines the required role:

   1. Create a new YAML file and open it in a text editor, for example:

      # vi logging-playbook.yml

   2. Insert the following content into the file:

      ---
      - name: Deploying remote input and remote_files output
        hosts: server
        roles:
          - linux-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: clients
        roles:
          - linux-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. Configuring the firewall through system roles is not yet supported.

2. Create an inventory file that lists your servers and clients:

   1. Create a new file and open it in a text editor, for example:

      # vi inventory.ini

   2. Insert the following content into the inventory file:

      [servers]
      server ansible_host=host1.example.com
      [clients]
      client ansible_host=host2.example.com

      Where:

      • host1.example.com is the logging server.
      • host2.example.com is the logging client.

3. Run the playbook on your inventory.

   # ansible-playbook -i /path/to/file/inventory.ini /path/to/file/_logging-playbook.yml

   Where:

   • inventory.ini is the inventory file.
   • logging-playbook.yml is the playbook you created.

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/messages log, for example:

      # cat /var/log/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. Copy the example playbook for the SSHD System Role:

   # cp /usr/share/doc/rhel-system-roles/sshd/example-root-login-playbook.yml path/custom-playbook.yml

2. Open the copied playbook by using a text editor, for example:

   # vim path/custom-playbook.yml
   
   ---
   - hosts: all
     tasks:
     - name: Configure sshd to prevent root and password login except from particular subnet
       include_role:
         name: rhel-system-roles.sshd
       vars:
         sshd:
           # root login and password login is enabled only from a particular subnet
           PermitRootLogin: no
           PasswordAuthentication: no
           Match:
           - Condition: "Address 192.0.2.0/24"
             PermitRootLogin: yes
             PasswordAuthentication: yes

   The playbook configures the managed node as an SSH server configured so that:

   • password and root user login is disabled
   • password and root user login is enabled only from the subnet 192.0.2.0/24

   You can modify the variables according to your preferences. For more details, see SSHD Server System Role variables .

3. Optional: Verify playbook syntax.

   # ansible-playbook --syntax-check path/custom-playbook.yml

4. Run the playbook on your inventory file:

   # ansible-playbook -i inventory_file path/custom-playbook.yml
   
   ...
   
   PLAY RECAP
   **************************************************
   
   localhost : ok=12 changed=2 unreachable=0 failed=0
   skipped=10 rescued=0 ignored=0

Verification

1. Log in to the SSH server:

   $ ssh user1@10.1.1.1

   Where:

   • user1 is a user on the SSH server.
   • 10.1.1.1 is the IP address of the SSH server.

2. Check the contents of the sshd_config file on the SSH server:

   $ vim /etc/ssh/sshd_config
   
   # Ansible managed
   HostKey /etc/ssh/ssh_host_rsa_key
   HostKey /etc/ssh/ssh_host_ecdsa_key
   HostKey /etc/ssh/ssh_host_ed25519_key
   AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
   AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
   AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
   AcceptEnv XMODIFIERS
   AuthorizedKeysFile .ssh/authorized_keys
   ChallengeResponseAuthentication no
   GSSAPIAuthentication yes
   GSSAPICleanupCredentials no
   PasswordAuthentication no
   PermitRootLogin no
   PrintMotd no
   Subsystem sftp /usr/libexec/openssh/sftp-server
   SyslogFacility AUTHPRIV
   UsePAM yes
   X11Forwarding yes
   Match Address 192.0.2.0/24
     PasswordAuthentication yes
     PermitRootLogin yes

3. Check that you can connect to the server as root from the 192.0.2.0/24 subnet:

   1. Determine your IP address:

      $ hostname -I
      192.0.2.1

      If the IP address is within the 192.0.2.1 - 192.0.2.254 range, you can connect to the server.

   2. Connect to the server as root:

      $ ssh root@10.1.1.1

Procedure

1. Create a new playbook.yml file with the following content:

   ---
   - hosts: all
     tasks:
     - name: "Configure ssh clients"
       include_role:
         name: rhel-system-roles.ssh
       vars:
         ssh_user: root
         ssh:
           Compression: true
           GSSAPIAuthentication: no
           ControlMaster: auto
           ControlPath: ~/.ssh/.cm%C
           Host:
             - Condition: example
               Hostname: example.com
               User: user1
         ssh_ForwardX11: no

   This playbook configures the root user’s SSH client preferences on the managed nodes with the following configurations:

   • Compression is enabled.
   • ControlMaster multiplexing is set to auto.
   • The example alias for connecting to the example.com host is user1.
   • The example host alias is created, which represents a connection to the example.com host the with user1 user name.
   • X11 forwarding is disabled.

   Optionally, you can modify these variables according to your preferences. For more details, see SSH Client Role variables .

2. Optional: Verify playbook syntax.

   # ansible-playbook --syntax-check path/custom-playbook.yml

3. Run the playbook on your inventory file:

   # ansible-playbook -i inventory_file path/custom-playbook.yml

Procedure

1. Create a new playbook.yml file with the following content:

   - name: Host to host VPN
     hosts: managed_node1, managed_node2
     roles:
       - linux-system-roles.vpn
     vars:
       vpn_connections:
         - hosts:
             managed_node1:
             managed_node2:

   This playbook configures the connection managed_node1-to-managed_node2 using pre-shared key authentication with keys auto-generated by the system role.

2. Optional: Configure connections from managed hosts to external hosts that are not listed in the inventory file by adding the following section to the vpn_connections list of hosts:

       vpn_connections:
         - hosts:
             managed_node1:
             managed_node2:
             external_node:
               hostname: 192.0.2.2

   This configures two additional connections: managed_node1-to-external_node and managed_node2-to-external_node.

1. Optional: You can specify multiple VPN connections for the managed nodes by using additional sections within vpn_connections, for example a control plane and a data plane:

   - name: Multiple VPN
     hosts: managed_node1, managed_node2
     roles:
       - linux-system-roles.vpn
     vars:
       vpn_connections:
         - name: control_plane_vpn
           hosts:
             managed_node1:
               hostname: 192.0.2.0 # IP for the control plane
             managed_node2:
               hostname: 192.0.2.1
         - name: data_plane_vpn
           hosts:
             managed_node1:
               hostname: 10.0.0.1 # IP for the data plane
             managed_node2:
               hostname: 10.0.0.2

2. Optional: You can modify the variables according to your preferences. For more details, see the /usr/share/doc/rhel-system-roles/vpn/README.md file.

3. Optional: Verify playbook syntax.

   # ansible-playbook --syntax-check /path/to/file/playbook.yml -i /path/to/file/inventory_file

4. Run the playbook on your inventory file:

   # ansible-playbook -i /path/to/file/inventory_file /path/to/file/playbook.yml

Verification

1. On the managed nodes, confirm that the connection is successfully loaded:

   # ipsec status | grep connection.name

   Replace connection.name with the name of the connection from this node, for example managed_node1-to-managed_node2.

1. On the managed nodes, confirm that the connection is successfully started:

   # ipsec trafficstatus | grep connection.name

2. Optional: If a connection did not successfully load, manually add the connection by entering the following command. This will provide more specific information indicating why the connection failed to establish:

   # ipsec auto --add connection.name

   Note

   Any errors that may have occurred during the process of loading and starting the connection are reported in the logs, which can be found in /var/log/pluto.log. Because these logs are hard to parse, try to manually add the connection to obtain log messages from the standard output instead.

Procedure

1. Create a new playbook.yml file with the following content:

   - name: Mesh VPN
     hosts: managed_node1, managed_node2, managed_node3
     roles:
       - linux-system-roles.vpn
     vars:
       vpn_connections:
         - opportunistic: true
           auth_method: cert
           policies:
             - policy: private
               cidr: default
             - policy: private-or-clear
               cidr: 198.51.100.0/24
             - policy: private
               cidr: 192.0.2.0/24
             - policy: clear
               cidr: 192.0.2.7/32

2. Optional: You can modify the variables according to your preferences. For more details, see the /usr/share/doc/rhel-system-roles/vpn/README.md file.

3. Optional: Verify playbook syntax.

   # ansible-playbook --syntax-check playbook.yml

4. Run the playbook on your inventory file:

   # ansible-playbook -i inventory_file /path/to/file/playbook.yml

Procedure

1. Create a new playbook.yml file with the following content:

   ---
   - hosts: all
     tasks:
     - name: Configure crypto policies
       include_role:
         name: linux-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 variable causes the system to reboot after the system role changes the crypto policy.

   For more details, see Crypto Policies System Role variables and facts .

2. Optional: Verify playbook syntax.

   # ansible-playbook --syntax-check playbook.yml

3. Run the playbook on your inventory file:

   # ansible-playbook -i inventory_file playbook.yml

Verification

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

   - hosts: all
     tasks:
    - name: Verify active crypto policy
      include_role:
        name: linux-system-roles.crypto_policies
   
    - debug:
        var: crypto_policies_active

   This playbook does not change any configurations on the system, only reports the active policy on the managed nodes.

2. Run the playbook on the same inventory file:

   # ansible-playbook -i inventory_file 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. Prepare your playbook containing settings for Tang servers. You can either start from the scratch, or use one of the example playbooks from the /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/ directory.

   # cp /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/simple_deploy.yml ./my-tang-playbook.yml

2. Edit the playbook in a text editor of your choice, for example:

   # vi my-tang-playbook.yml

3. Add the required parameters. The following example playbook ensures deploying of your Tang server and a key rotation:

   ---
   - hosts: all
   
     vars:
       nbde_server_rotate_keys: yes
   
     roles:
       - linux-system-roles.nbde_server

4. Apply the finished playbook:

   # ansible-playbook -i host1,host2,host3 my-tang-playbook.yml

Procedure

1. Prepare your playbook containing settings for Clevis clients. You can either start from the scratch, or use one of the example playbooks from the /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/ directory.

   # cp /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/high_availability.yml ./my-clevis-playbook.yml

2. Edit the playbook in a text editor of your choice, for example:

   # vi my-clevis-playbook.yml

3. Add the required parameters. The following example playbook configures Clevis clients for automated unlocking of two LUKS-encrypted volumes by when at least one of two Tang servers is available:

   ---
   - hosts: all
   
     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
   
     roles:
       - linux-system-roles.nbde_client

4. Apply the finished playbook:

   # ansible-playbook -i host1,host2,host3 my-clevis-playbook.yml

Procedure

1. Optional: Create an inventory file, for example inventory.file:

   $ touch inventory.file

2. Open your inventory file and define the hosts on which you want to request the certificate, for example:

   [webserver]
   server.idm.example.com

3. Create a playbook file, for example request-certificate.yml:

   • Set hosts to include the hosts on which you want to request the certificate, such as webserver.

   • Set the certificate_requests variable to include the following:

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

   • Set the rhel-system-roles.certificate role under roles.

     This is the playbook file for this example:

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

4. Save the file.

5. Run the playbook:

   $ ansible-playbook -i inventory.file request-certificate.yml

Procedure

1. Optional: Create an inventory file, for example inventory.file:

   $ touch inventory.file

2. Open your inventory file and define the hosts on which you want to request the certificate, for example:

   [webserver]
   server.idm.example.com

3. Create a playbook file, for example request-certificate.yml:

   • Set hosts to include the hosts on which you want to request the certificate, such as webserver.

   • Set the certificate_requests variable to include the following:

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

   • Set the rhel-system-roles.certificate role under roles.

     This is the playbook file for this example:

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

4. Save the file.

5. Run the playbook:

   $ ansible-playbook -i inventory.file request-certificate.yml

Procedure

1. Optional: Create an inventory file, for example inventory.file:

   $ touch inventory.file

2. Open your inventory file and define the hosts on which you want to request the certificate, for example:

   [webserver]
   server.idm.example.com

3. Create a playbook file, for example request-certificate.yml:

   • Set hosts to include the hosts on which you want to request the certificate, such as webserver.

   • Set the certificate_requests variable to include the following:

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

   • Set the rhel-system-roles.certificate role under roles.

     This is the playbook file for this example:

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

4. Save the file.

5. Run the playbook:

   $ ansible-playbook -i inventory.file request-certificate.yml

Procedure

1. Create a new playbook.yml file with the following content:

   ---
   - hosts: kdump-test
     vars:
       kdump_path: /var/crash
     roles:
       - rhel-system-roles.kdump

2. Optional: Verify playbook syntax.

   # ansible-playbook --syntax-check playbook.yml

3. Run the playbook on your inventory file:

   # ansible-playbook -i inventory_file /path/to/file/playbook.yml

Procedure

1. Create a new playbook.yml file with the following content:

   - hosts: all
     vars:
       storage_safe_mode: false
       storage_volumes:
         - name: data
           type: raid
           disks: [sdd, sde, sdf, sdg]
           raid_level: raid0
           raid_chunk_size: 32 KiB
           mount_point: /mnt/data
           state: present
     roles:
       - name: rhel-system-roles.storage

   Warning

   Device names can change in certain circumstances; for example, when you add a new disk to a system. Therefore, to prevent data loss, we do not recommend using specific disk names in the playbook.

2. Optional. Verify playbook syntax.

   # ansible-playbook --syntax-check playbook.yml

3. Run the playbook on your inventory file:

   # ansible-playbook -i inventory.file /path/to/file/playbook.yml

Procedure

1. Create a new playbook.yml file with the following content:

   - hosts: all
     vars:
       storage_safe_mode: false
       storage_pools:
         - name: my_pool
           type: lvm
           disks: [sdh, sdi]
           raid_level: raid1
           volumes:
             - name: my_pool
               size: "1 GiB"
               mount_point: "/mnt/app/shared"
               fs_type: xfs
               state: present
     roles:
       - name: rhel-system-roles.storage

   Note

   To create an LVM pool with RAID, you must specify the RAID type using the raid_level parameter.

2. Optional. Verify playbook syntax.

   # ansible-playbook --syntax-check playbook.yml

3. Run the playbook on your inventory file:

   # ansible-playbook -i inventory.file /path/to/file/playbook.yml

Procedure

1. Create a new playbook.yml file with the following content:

   - hosts: all
     vars:
       storage_volumes:
         - name: barefs
           type: disk
           disks:
            - sdb
           fs_type: xfs
           fs_label: label-name
           mount_point: /mnt/data
           encryption: true
           encryption_password: your-password
     roles:
      - rhel-system-roles.storage

2. Optional: Verify playbook syntax:

   # ansible-playbook --syntax-check playbook.yml

3. Run the playbook on your inventory file:

   # ansible-playbook -i inventory.file /path/to/file/playbook.yml

Procedure

1. Create a new playbook.yml file with the following content:

   ---
   - hosts: timesync-test
     vars:
       timesync_ntp_servers:
         - hostname: 2.rhel.pool.ntp.org
           pool: yes
           iburst: yes
     roles:
       - rhel-system-roles.timesync

2. Optional: Verify playbook syntax.

   # ansible-playbook --syntax-check playbook.yml

3. Run the playbook on your inventory file:

   # ansible-playbook -i inventory_file /path/to/file/playbook.yml

Procedure

1. Create a playbook.yml file with the following content:

   ---
   - hosts: timesync-test
     vars:
       timesync_ntp_servers:
         - hostname: ptbtime1.ptb.de
           iburst: yes
           nts: yes
     roles:
       - rhel-system-roles.timesync

   ptbtime1.ptb.de is an example of public server. You may want to use a different public server or your own server.

2. Optional: Verify playbook syntax.

   # ansible-playbook --syntax-check playbook.yml

3. Run the playbook on your inventory file:

   # ansible-playbook -i inventory_file /path/to/file/playbook.yml

Verification

1. Perform a test on the client machine:

   # chronyc -N authdata
   
   Name/IP address         Mode KeyID Type KLen Last Atmp  NAK Cook CLen
   =====================================================================
   ptbtime1.ptb.de         NTS     1   15  256  157    0    0    8  100

2. Check that the number of reported cookies is larger than zero.

Procedure

1. Configure localhost in the the /etc/ansible/hosts Ansible inventory by adding the following content to the inventory:

   localhost ansible_connection=local

2. Create an Ansible playbook with the following content:

   ---
   - hosts: localhost
     vars:
       metrics_graph_service: yes
     roles:
       - rhel-system-roles.metrics

3. Run the Ansible playbook:

   # ansible-playbook name_of_your_playbook.yml

   Note

   Since the metrics_graph_service boolean is set to value="yes", grafana is automatically installed and provisioned with pcp added as a data source.

4. To view visualization of the metrics being collected on your machine, access the grafana web interface as described in Accessing the Grafana web UI.

Procedure

1. Add the name or IP of the machines you wish to monitor via the playbook to the /etc/ansible/hosts Ansible inventory file under an identifying group name enclosed in brackets:

   [remotes]
   webserver.example.com
   database.example.com

2. Create an Ansible playbook with the following content:

   ---
   - hosts: remotes
     vars:
       metrics_retention_days: 0
     roles:
       - rhel-system-roles.metrics

3. Run the Ansible playbook:

   # ansible-playbook name_of_your_playbook.yml

Procedure

1. Create an Ansible playbook with the following content:

   ---
   - hosts: localhost
     vars:
       metrics_graph_service: yes
       metrics_query_service: yes
       metrics_retention_days: 10
       metrics_monitored_hosts: ["database.example.com", "webserver.example.com"]
     roles:
       - rhel-system-roles.metrics

2. Run the Ansible playbook:

   # ansible-playbook name_of_your_playbook.yml

   Note

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

3. To view graphical representation of the metrics being collected centrally by your machine and to query the data, access the grafana web interface as described in Accessing the Grafana web UI.

Procedure

1. Include the following variables in the Ansible playbook you want to setup authentication for:

   ---
     vars:
       metrics_username: your_username
       metrics_password: your_password

2. Run the Ansible playbook:

   # ansible-playbook name_of_your_playbook.yml

Procedure

1. Configure localhost in the the /etc/ansible/hosts Ansible inventory by adding the following content to the inventory:

   localhost ansible_connection=local

2. Create an Ansible playbook that contains the following content:

   ---
   - hosts: localhost
     roles:
       - role: rhel-system-roles.metrics
         vars:
           metrics_from_mssql: yes

3. Run the Ansible playbook:

   # ansible-playbook name_of_your_playbook.yml

Procedure

1. Refresh your subscriptions:

   # subscription-manager refresh

2. Enable the RHEL Ansible subscription:

   # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms

3. Install Ansible:

   # yum install ansible

4. Install microsoft.sql.server Ansible role:

   # yum install ansible-collection-microsoft-sql

Procedure

1. Create a file with the .yml extension. For example, mssql-server.yml.

2. Add the following content to your .yml file:

   ---
   - hosts: all
     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_password: <password>
       mssql_edition: Developer
       mssql_tcp_port: 1443
     roles:
       - microsoft.sql.server

   Replace <password> with your SQL Server password.

3. Run the mssql-server.yml ansible playbook:

   # ansible-playbook mssql-server.yml

Procedure

1. Create a new playbook.yml file with the following content:

   ---
   - name: Deploy session recording
     hosts: all
     vars:
       tlog_scope_sssd: some
       tlog_users_sssd:
         - recordeduser
   
     roles:
       - rhel-system-roles.tlog

   Where,

   • tlog_scope_sssd:

     • some specifies you want to record only certain users and groups, not all or none.

   • tlog_users_sssd:

     • recordeduser specifies the user you want to record a session from. Note that this does not add the user for you. You must set the user by yourself.

2. Optionally, verify the playbook syntax.

   # ansible-playbook --syntax-check playbook.yml

3. Run the playbook on your inventory file:

   # ansible-playbook -i IP_Address /path/to/file/playbook.yml -v

1. Navigate to the folder where the SSSD configuration drop file is created:

   # cd /etc/sssd/conf.d

2. Check the file content:

   # cat /etc/sssd/conf.d/sssd-session-recording.conf

Procedure

1. Create a new playbook.yml file with the following content:

   ---
   - name: Deploy session recording excluding users and groups
     hosts: all
     vars:
       tlog_scope_sssd: all
       tlog_exclude_users_sssd:
         - jeff
         - james
       tlog_exclude_groups_sssd:
         - admins
   
     roles:
       - rhel-system-roles.tlog

   Where,

   • tlog_scope_sssd:

     • all: specifies that you want to record all users and groups.

   • tlog_exclude_users_sssd:

     • user names: specifies the user names of the users you want to exclude from the session recording.

   • tlog_exclude_groups_sssd:

     • admins specifies the group you want to exclude from the session recording.

2. Optionally, verify the playbook syntax;

   # ansible-playbook --syntax-check playbook.yml

3. Run the playbook on your inventory file:

   # ansible-playbook -i IP_Address /path/to/file/playbook.yml -v

1. Navigate to the folder where the SSSD configuration drop file is created:

   # cd /etc/sssd/conf.d

2. Check the file content:

   # cat sssd-session-recording.conf

Procedure

1. Create a user and assign a password for this user:

   # useradd recordeduser
   # passwd recordeduser

2. Relog to the system as the user you just created:

   # ssh recordeduser@localhost

3. Type "yes" when the system prompts you to type yes or no to authenticate.

4. Insert the recordeduser’s password.

   The system prompts a message to inform that your session is being recorded.

   ATTENTION! Your session is being recorded!

5. Once you have finished recording the session, type:

   # exit

   The system logs out from the user and closes the connection with the localhost.

1. Run the command below:

   # journalctl -o verbose -r

2. Search for the MESSAGE field of the tlog-rec recorded journal entry.

   # journalctl -xel _EXE=/usr/bin/tlog-rec-session

Procedure

1. On the CLI terminal, play the user session recording:

   # journalctl -o verbose -r

2. Search for the tlog recording:

   $ /tlog-rec

   You can see details such as:

   • The username for the user session recording
   • The out_txt field, a raw output encode of the recorded session
   • The identifier number TLOG_REC=ID_number
3. Copy the identifier number TLOG_REC=ID_number.

4. Playback the recording using the identifier number TLOG_REC=ID_number.

   # tlog-play -r journal -M TLOG_REC=ID_number

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.

   The following example playbook file configures a cluster with no fencing configured and which runs no resources. When creating your playbook file for production, it is recommended that you vault encrypt the password, as described in Encrypting content with Ansible Vault.

   - hosts: node1 node2
     vars:
       ha_cluster_cluster_name: my-new-cluster
       ha_cluster_hacluster_password: password
   
     roles:
       - rhel-system-roles.ha_cluster

3. Save the file.

4. Run the playbook:

   $ ansible-playbook -i inventory new-cluster.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:

   The following example playbook file configures a cluster that 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, it is recommended that you vault encrypt the password, as described in Encrypting content with Ansible Vault.

   - hosts: node1 node2
     vars:
       ha_cluster_cluster_name: my-new-cluster
       ha_cluster_hacluster_password: password
       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
   
     roles:
       - rhel-system-roles.ha_cluster

3. Save the file.

4. Run the playbook:

   $ ansible-playbook -i inventory new-cluster.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 http-cluster.yml:

   The following example playbook file configures a previously-created Apache HTTP server in an active/passive two-node HA cluster

   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, it is recommended that you vault encrypt the password, as described in Encrypting content with Ansible Vault.

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

3. Save the file.

4. Run the playbook:

   $ ansible-playbook -i inventory http-cluster.yml

Verification steps

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):   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):   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 on the resource-stickiness meta attribute, see Configuring a resource to prefer its current node.