Procedure

1. Install the rhel-system-roles package:

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

   This command installs the ansible-core package as a dependency.

   Note

   In RHEL 8.5 and earlier versions, Ansible packages were provided through Ansible Engine instead of Ansible Core, and with a different level of support. Do not use Ansible Engine because the packages might not be compatible with Ansible automation content in RHEL 8.6 and later. For more information, see Scope of support for the Ansible Core package included in the RHEL 9 and RHEL 8.6 and later AppStream repositories.

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

   [root@control-node]# useradd ansible

3. Switch to the newly created ansible user:

   [root@control-node]# su - ansible

   Perform the rest of the procedure as this user.

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

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

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

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

Procedure

1. Create a user named ansible:

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

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

2. Set a password for the ansible user:

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

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

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

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

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

   2. When prompted, connect by entering yes:

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

   3. When prompted, enter the password:

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

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

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

4. Create a sudo configuration for the ansible user:

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

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

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

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

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

        ansible ALL=(ALL) ALL

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

        ansible ALL=(ALL) NOPASSWD: ALL

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

Verification

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

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

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

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

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

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

1. Enter the following command:

   $ ansible-playbook -c local -i localhost, --check --become /usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/tests/kernel_settings/tests_default.yml

Procedure

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

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

   # ansible-galaxy collection install redhat.rhel_system_roles

   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. Run the following command:

   $ ansible-playbook -c local -i localhost, --check --become /usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/tests/kernel_settings/tests_default.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 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 configuration files /etc/rsyslog.conf and /etc/rsyslog.d:

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

   ---
   - name: Sets which boot device will be used on next boot
     hosts: localhost
       tasks:
       - redhat.rhel_mgmt.ipmi_boot:
          name: bmc.host.example.com
            user: admin_user
            password: basics
            bootdev: hd

2. Execute the playbook against localhost:

   # ansible-playbook playbook.yml

Procedure

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

   ---
   - name: Turn the host on
     hosts: localhost
       tasks:
       - redhat.rhel_mgmt.ipmi_power:
          name: bmc.host.example.com
            user: admin_user
            password: basics
            state: on

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

   ---
   - name: Get CPU inventory
     hosts: localhost
     tasks:
       - redhat.rhel_mgmt.redfish_info:
           baseuri: "{{ baseuri }}"
           username: "{{ username }}"
           password: "{{ password }}"
           category: Systems
           command: GetCpuInventory
         register: result

2. Execute the playbook against localhost:

   # ansible-playbook playbook.yml

Procedure

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

   ---
   - name: Power on system
     hosts: localhost
     tasks:
       - redhat.rhel_mgmt.redfish_command:
           baseuri: "{{ baseuri }}"
           username: "{{ username }}"
           password: "{{ password }}"
           category: Systems
           command: PowerOn

2. Execute the playbook against localhost:

   # ansible-playbook playbook.yml

Procedure

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

   ---
   - name: "Set BootMode to UEFI"
     hosts: localhost
     tasks:
       - redhat.rhel_mgmt.redfish_config:
           baseuri: "{{ baseuri }}"
           username: "{{ username }}"
           password: "{{ password }}"
           category: Systems
           command: SetBiosAttributes
           bios_attributes:
             BootMode: Uefi

2. Execute the playbook against localhost:

   # ansible-playbook playbook.yml

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 more effectively against a specific set of systems.

2. Create a configuration file to set defaults and privilege escalation for Ansible 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:

      ---
      -
        hosts: testingservers
        name: "Configure kernel settings"
        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

      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 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. Create a vault to save the sensitive information:

   $ ansible-vault create secrets.yml
   New Vault password: password
   Confirm New Vault password: password

2. The ansible-vault create command creates an encrypted vault file and opens it in an editor. Enter the sensitive data you want to save in the vault, for example:

   activationKey: activation_key
   username: username
   password: password

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

   You can later edit the data in the vault by using the ansible-vault edit secrets.yml command.

4. Optional: Display the vault content:

   $ ansible-vault view secrets.yml

5. Create a playbook file, for example ~/registration.yml, and use one of the following options depending on the action you want to perform:

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

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

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

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

6. Run the playbook:

   # ansible-playbook ~/registration.yml --ask-vault-pass

Procedure

1. Create a vault to save the sensitive information:

   $ ansible-vault create secrets.yml
   New Vault password: password
   Confirm New Vault password: password

2. The ansible-vault create command creates an encrypted file and opens it in an editor. Enter the sensitive data you want to save in the vault, for example:

   activationKey: activation_key

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

   You can later edit the data in the vault by using the ansible-vault edit secrets.yml command.

4. Optional: Display the vault content:

   $ ansible-vault view secrets.yml

5. Create a playbook file, for example ~/registration-sat.yml.

6. Use the following text in ~/registration-sat.yml to register the system by using an activation key and organization ID:

   ---
   - name: Register to the custom registration server and CDN
     hosts: managed-node-01.example.com
     vars_files:
       - secrets.yml
     vars:
       rhc_auth:
         login:
           activation_keys:
             keys:
               - "{{ activationKey }}"
           rhc_organization: organizationID
       rhc_server:
         hostname: example.com
           port: 443
           prefix: /rhsm
       rhc_baseurl: http://example.com/pulp/content
      roles:
        - role: rhel-system-roles.rhc

7. Run the playbook:

   # ansible-playbook ~/registration-sat.yml --ask-vault-pass

Procedure

1. Create a playbook file, for example ~/dis-insights.yml and add the following content in it:

   ---
   - name: Disable Insights connection
     hosts: managed-node-01.example.com
     vars:
       rhc_insights:
         state: absent
     roles:
       - role: rhel-system-roles.rhc

2. Run the playbook:

   # ansible-playbook ~/dis-insights.yml

Procedure

1. Create a playbook file, for example ~/configure-repos.yml:

   1. To enable a repository:

      ---
      - name: Enable repository
        hosts: managed-node-01.example.com
        vars:
          rhc_repositories:
            - {name: "RepositoryName", state: enabled}
         roles:
           - role: rhel-system-roles.rhc

   2. To disable a repository:

      ---
      - name: Disable repository
        hosts: managed-node-01.example.com
        vars:
          rhc_repositories:
            - {name: "RepositoryName", state: disabled}
         roles:
           - role: rhel-system-roles.rhc

2. Run the playbook:

   # ansible-playbook ~/configure-repos.yml

Procedure

1. Create a playbook file, for example ~/release.yml:

   ---
   - name: Set Release
     hosts: managed-node-01.example.com
     vars:
       rhc_release: "8.6"
     roles:
       - role: rhel-system-roles.rhc

2. Run the playbook:

   # ansible-playbook ~/release.yml

Procedure

1. Create a vault to save the sensitive information:

   $ ansible-vault create secrets.yml
   New Vault password: password
   Confirm New Vault password: password

2. The ansible-vault create command creates an encrypted file and opens it in an editor. Enter the sensitive data you want to save in the vault, for example:

   username: username
   password: password
   proxy_username: proxyusernme
   proxy_password: proxypassword

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

   You can later edit the data in the vault by using the ansible-vault edit secrets.yml command.

4. Optional: Display the vault content:

   $ ansible-vault view secrets.yml

5. Create a playbook file, for example ~/configure-proxy.yml:

   1. To register to the RHEL customer portal by using a proxy:

      ---
      - name: Register using proxy
        hosts: managed-node-01.example.com
        vars_files:
          - secrets.yml
        vars:
          rhc_auth:
            login:
              username: "{{ username }}"
              password: "{{ password }}"
          rhc_proxy:
            hostname: proxy.example.com
            port: 3128
            username: "{{ proxy_username }}"
            password: "{{ proxy_password }}"
        roles:
          - role: rhel-system-roles.rhc

   2. To remove the proxy server from the configuration of the Red Hat Subscription Manager service:

      ---
      - name: To stop using proxy server for registration
        hosts: managed-node-01.example.com
        vars_files:
          - secrets.yml
        vars:
          rhc_auth:
            login:
              username: "{{ username }}"
              password: "{{ password }}"
           rhc_proxy: {"state":"absent"}
        roles:
          - role: rhel-system-roles.rhc

6. Run the playbook:

   # ansible-playbook ~/configure-proxy.yml --ask-vault-pass

Procedure

1. Create a vault to save the sensitive information:

   $ ansible-vault create secrets.yml
   New Vault password: password
   Confirm New Vault password: password

2. The ansible-vault create command creates an encrypted file and opens it in an editor. Enter the sensitive data you want to save in the vault, for example:

   username: username
   password: password

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

   You can later edit the data in the vault by using the ansible-vault edit secrets.yml command.

4. Optional: Display the vault content:

   $ ansible-vault view secrets.yml

5. Create a playbook file, for example ~/auto-update.yml and add following content to it:

   ---
    - name: Disable Red Hat Insights autoupdates
      hosts: managed-node-01.example.com
      vars_files:
        - secrets.yml
      vars:
       rhc_auth:
         login:
           username: "{{ username }}"
           password: "{{ password }}"
       rhc_insights:
          autoupdate: false
          state: present
       roles:
         - role: rhel-system-roles.rhc

6. Run the playbook:

   # ansible-playbook ~/auto-update.yml --ask-vault-pass

Procedure

1. To enable the remediation, create a playbook file, for example ~/remediation.yml:

   ---
   - name: Disable remediation
     hosts: managed-node-01.example.com
     vars:
       rhc_insights:
         remediation: absent
         state: present
     roles:
       - role: rhel-system-roles.rhc

2. Run the playbook:

   # ansible-playbook ~/remediation.yml

Procedure

1. Create a vault to save the sensitive information:

   $ ansible-vault create secrets.yml
   New Vault password: password
   Confirm New Vault password: password

2. The ansible-vault create command creates an encrypted file and opens it in an editor. Enter the sensitive data you want to save in the vault, for example:

   username: username
   password: password

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

   You can later edit the data in the vault by using the ansible-vault edit secrets.yml command.

4. Optional: Display the vault content:

   $ ansible-vault view secrets.yml

5. Create a playbook file, for example ~/tags.yml, and add following content to it:

   ---
   - name: Creating tags
     hosts: managed-node-01.example.com
     vars_files:
       - secrets.yml
     vars:
       rhc_auth:
         login:
           username: "{{ username }}"
           password: "{{ password }}"
       rhc_insights:
         tags:
           group: group-name-value
             location: location-name-value
             description:
               - RHEL8
               - SAP
              sample_key:value
           state: present
     roles:
       - role: rhel-system-roles.rhc

6. Run the playbook:

   # ansible-playbook ~/remediation.yml --ask-vault-pass

Procedure

1. To unregister, create a playbook file, for example, ~/unregister.yml and add the following content to it:

   ---
   - name: Unregister the system
     hosts: managed-node-01.example.com
     vars:
       rhc_state: absent
     roles:
       - role: rhel-system-roles.rhc

2. Run the playbook:

   # ansible-playbook ~/unregister.yml

Procedure

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

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

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

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

2. Validate the playbook syntax:

   # ansible-playbook ~/ethernet-static-IP.yml --syntax-check

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

3. Run the playbook:

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

Procedure

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

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

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

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

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

2. Validate the playbook syntax:

   # ansible-playbook ~/ethernet-static-IP.yml --syntax-check

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

3. Run the playbook:

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

Procedure

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

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

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

2. Validate the playbook syntax:

   # ansible-playbook ~/ethernet-dynamic-IP.yml --syntax-check

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

3. Run the playbook:

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

Procedure

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

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

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

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

2. Validate the playbook syntax:

   # ansible-playbook ~/ethernet-dynamic-IP.yml --syntax-check

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

3. Run the playbook:

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

Procedure

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

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

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

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

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

2. Validate the playbook syntax:

   # ansible-playbook ~/vlan-ethernet.yml --syntax-check

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

3. Run the playbook:

   # ansible-playbook ~/vlan-ethernet.yml

Procedure

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

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

   These settings define a network bridge with the following settings:

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

   • Ports of the bridge - enp7s0 and enp8s0

     Note

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

2. Validate the playbook syntax:

   # ansible-playbook ~/bridge-ethernet.yml --syntax-check

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

3. Run the playbook:

   # ansible-playbook ~/bridge-ethernet.yml

Procedure

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

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

   These settings define a network bond with the following settings:

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

   • Bond mode - active-backup

     Note

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

2. Validate the playbook syntax:

   # ansible-playbook ~/bond-ethernet.yml --syntax-check

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

3. Run the playbook:

   # ansible-playbook ~/bond-ethernet.yml

Procedure

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

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

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

2. Validate the playbook syntax:

   # ansible-playbook ~/IPoIB.yml --syntax-check

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

3. Run the playbook:

   # ansible-playbook ~/IPoIB.yml

Verification

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

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

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

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

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

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

Procedure

1. Create a playbook file, for example ~/pbr.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
       include_role:
         name: rhel-system-roles.network
   
       vars:
         network_connections:
           - name: Provider-A
             interface_name: enp7s0
             type: ethernet
             autoconnect: True
             ip:
               address:
                 - 198.51.100.1/30
               gateway4: 198.51.100.2
               dns:
                 - 198.51.100.200
             state: up
             zone: external
   
           - name: Provider-B
             interface_name: enp1s0
             type: ethernet
             autoconnect: True
             ip:
               address:
                 - 192.0.2.1/30
               route:
                 - network: 0.0.0.0
                   prefix: 0
                   gateway: 192.0.2.2
                   table: 5000
             state: up
             zone: external
   
           - name: Internal-Workstations
             interface_name: enp8s0
             type: ethernet
             autoconnect: True
             ip:
               address:
                 - 10.0.0.1/24
               route:
                 - network: 10.0.0.0
                   prefix: 24
                   table: 5000
               routing_rule:
                 - priority: 5
                   from: 10.0.0.0/24
                   table: 5000
             state: up
             zone: trusted
   
           - name: Servers
             interface_name: enp9s0
             type: ethernet
             autoconnect: True
             ip:
               address:
                 - 203.0.113.1/24
             state: up
             zone: trusted

2. Validate the playbook syntax:

   # ansible-playbook ~/pbr.yml --syntax-check

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

3. Run the playbook:

   # ansible-playbook ~/pbr.yml

Verification

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

   1. Install the traceroute package:

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

      # yum install traceroute

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

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

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

3. On the RHEL router that you configured using the RHEL System Role:

   1. Display the rule list:

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

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

   2. Display the routes in table 5000:

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

   3. Display the interfaces and firewall zones:

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

   4. Verify that the external zone has masquerading enabled:

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

Procedure

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

   ---
   - name: Configure an Ethernet connection with 802.1X authentication
     hosts: managed-node-01.example.com
     tasks:
       - name: Copy client key for 802.1X authentication
         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: rhel-system-roles.network
   
         vars:
           network_connections:
             - name: enp1s0
               type: ethernet
               autoconnect: yes
               ip:
                 address:
                   - 192.0.2.1/24
                   - 2001:db8:1::1/64
                 gateway4: 192.0.2.254
                 gateway6: 2001:db8:1::fffe
                 dns:
                   - 192.0.2.200
                   - 2001:db8:1::ffbb
                 dns_search:
                   - example.com
               ieee802_1x:
                 identity: user_name
                 eap: tls
                 private_key: "/etc/pki/tls/private/client.key"
                 private_key_password: "password"
                 client_cert: "/etc/pki/tls/certs/client.crt"
                 ca_cert: "/etc/pki/ca-trust/source/anchors/ca.crt"
                 domain_suffix_match: example.com
               state: up

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

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

2. Validate the playbook syntax:

   # ansible-playbook ~/enable-802.1x.yml --syntax-check

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

3. Run the playbook:

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

Procedure

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

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

2. Validate the playbook syntax:

   # ansible-playbook ~/ethernet-connection.yml --syntax-check

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

3. Run the playbook:

   # ansible-playbook ~/ethernet-connection.yml

Procedure

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

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

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

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

   • Static routes:

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

2. Validate the playbook syntax:

   # ansible-playbook ~/add-static-routes.yml --syntax-check

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

3. Run the playbook:

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

Verification

1. On the managed nodes:

   1. Display the IPv4 routes:

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

   2. Display the IPv6 routes:

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

Procedure

1. Create a playbook file, for example ~/configure-ethernet-device-with-ethtool-features.yml, with the following content:

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

   Depending on whether it already exists, this playbook creates or updates the enp1s0 connection profile with the following settings:

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

   • ethtool features:

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

2. Validate the playbook syntax:

   # ansible-playbook ~/configure-ethernet-device-with-ethtool-features.yml --syntax-check

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

3. Run the playbook:

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

Procedure

1. Create a playbook file, for example ~/configure-ethernet-device-with-ethtoolcoalesce-settings.yml, with the following content:

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

   Depending on whether it already exists, this playbook creates or updates the enp1s0 connection profile with the following settings:

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

   • ethtool coalesce settings:

     • RX frames: 128
     • TX frames: 128

2. Validate the playbook syntax:

   # ansible-playbook ~/configure-ethernet-device-with-ethtoolcoalesce-settings.yml --syntax-check

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

3. Run the playbook:

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

Procedure

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

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

2. Validate the playbook syntax:

   # ansible-playbook ~/configure-ethernet-device-with-ethtoolcoalesce-settings.yml --syntax-check

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

3. Run the playbook:

   # ansible-playbook ~/reset-firewalld.yml

Procedure

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

   ---
   - name: Configure firewalld
     hosts: managed-node-01.example.com
     tasks:
     - name: Forward incoming traffic on port 8080 to 443
       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 ~/port_forwarding.yml --syntax-check

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

3. Run the playbook:

   # ansible-playbook ~/port_forwarding.yml

Procedure

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

   ---
   - name: Configure firewalld
     hosts: managed-node-01.example.com
     tasks:
     - name: Allow incoming HTTPS traffic to the local host
       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 ~/opening-a-port.yml --syntax-check

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

3. Run the playbook:

   # ansible-playbook ~/opening-a-port.yml

Procedure

1. Create a playbook file, for example ~/configuring-a-dmz.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
       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 ~/configuring-a-dmz.yml --syntax-check

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

3. Run the playbook:

   # ansible-playbook ~/configuring-a-dmz.yml

Procedure

1. Create a playbook that defines the postfix role:

   1. Create a new YAML file, for example ~/postfix-playbook.yml, and open it in a text editor, for example:

      # vi postfix-playbook.yml

   2. Configure the relay_domains=$mydestination and relayhost=example.com variables:

      - name: Manage postfix
        hosts: all
        vars:
      	postfix_conf:
        		relay_domains: $mydestination
        		relayhost: example.com
        roles:
      	- linux-system-roles.postfix

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

      myhostname = smtp.example.com

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

      mydomain = <example.com>

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

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

      Note

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

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

      Note

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

2. Run the playbook on a specific inventory:

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

   Where:

   • <inventory-file> is the inventory file.
   • <postfix-playbook.yml> is the playbook you use.

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 uses the required role:

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

      # vi <cryptographic-playbook.yml>

   2. Insert the following example:

      ---
      - name: Overriding the system-wide cryptographic policy
        hosts: all
        become: true
        roles:
          - rhel_system_roles.sshd
        vars:
          sshd_sysconfig: true
          sshd_sysconfig_override_crypto_policy: true
          sshd_KexAlgorithms: ecdh-sha2-nistp521
          sshd_Ciphers: aes256-ctr
          sshd_MACs: hmac-sha2-512-etm@openssh.com
          sshd_HostKeyAlgorithms: rsa-sha2-512,rsa-sha2-256

      On RHEL 9 managed nodes, the system role writes the configuration into the /etc/ssh/sshd_config.d/00-ansible_system_role.conf file, where cryptographic options are applied automatically. You can change the file by using the sshd_config_file variable. However, to ensure the configuration is effective, use a file name that lexicographicaly preceeds the /etc/ssh/sshd_config.d/50-redhat.conf file, which includes the configured crypto policies. For more information, see Examples of opting out of system-wide crypto policies.

      On RHEL 8 managed nodes, you must enable override by setting the sshd_sysconfig_override_crypto_policy and sshd_sysconfig variables to true.

      You can further customize the configuration on the SSH server by using the following variables of the rhel_system_roles.sshd RHEL System Role:

      sshd_Ciphers

      You can choose ciphers, for example, aes128-ctr, aes192-ctr, or aes256-ctr.

      sshd_MACs

      You can choose MACs, for example, hmac-sha2-256, hmac-sha2-512, or hmac-sha1.

      sshd_HostKeyAlgorithms

      You can choose a public key algorithm, for example, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, ssh-rsa, or ssh-dss.

      sshd_KexAlgorithms

      You can choose key exchange algorithms, for example, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521,diffie-hellman-group14-sha1, or diffie-hellman-group-exchange-sha256.

      For more variables and their possible values, see the sshd_config(5) man page.

2. Run the playbook:

   $ ansible-playbook <cryptographic-playbook.yml>

Verification

1. You can verify the success of the procedure by using the verbose SSH connection and check the defined variables in the following output:

   $ ssh -vvv localhost
   ...
   debug2: peer server KEXINIT proposal
   debug2: KEX algorithms: ecdh-sha2-nistp521
   debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256
   debug2: ciphers ctos: aes256-ctr
   debug2: ciphers stoc: aes256-ctr
   debug2: MACs ctos: hmac-sha2-512-etm@openssh.com
   debug2: MACs stoc: hmac-sha2-512-etm@openssh.com
   ...

Procedure

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

   - name: Deploy and start systemd unit
     hosts: all
     vars:
       systemd_unit_files:
         - <name1>.service
         - <name2>.service
         - <name3>.service
       systemd_started_units:
         - <name1>.service
         - <name2>.service
         - <name3>.service
       systemd_enabled_units:
         - <name1>.service
         - <name2>.service
         - <name3>.service
     roles:
       - linux-system-roles.systemd

2. Optional: Verify playbook syntax:

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

3. Run the playbook on your inventory file:

   # ansible-playbook -i inventory_file /path/to/file/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:
          - 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. Run the playbook on a specific 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 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...
   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_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. 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...
   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:
          - 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: clients
        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. 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/<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 new playbook.yml file with the following content:

   ---
   - hosts: all
     vars:
       journald_persistent: true
       journald_max_disk_size: 2048
       journald_per_user: true
       journald_sync_interval: 1
     roles:
       - linux-system-roles.journald
   ---

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

2. Optional: Verify playbook syntax.

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

3. Run the playbook on your inventory file:

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

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

   $ cat /etc/ssh/sshd_config
   …
   PasswordAuthentication no
   PermitRootLogin no
   …
   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 System 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. Add a configuration snippet with the sshd_config_namespace variable to the playbook:

   ---
   - hosts: all
     tasks:
     - name: <Configure SSHD to accept some useful environment variables>
       include_role:
         name: rhel-system-roles.sshd
       vars:
         sshd_config_namespace: <my-application>
         sshd:
           # Environment variables to accept
           AcceptEnv:
             LANG
             LS_COLORS
             EDITOR

   When you apply the playbook to the inventory, the role adds the following snippet, if not already present, to the /etc/ssh/sshd_config file.

   # BEGIN sshd system role managed block: namespace <my-application>
   Match all
     AcceptEnv LANG LS_COLORS EDITOR
   # END sshd system role managed block: namespace <my-application>

Procedure

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

   - name: Host to host VPN
     hosts: managed_node1, managed_node2
     roles:
       - rhel-system-roles.vpn
     vars:
       vpn_connections:
         - hosts:
             managed_node1:
             managed_node2:
       vpn_manage_firewall: true
       vpn_manage_selinux: true

   This playbook configures the connection managed_node1-to-managed_node2 using pre-shared key authentication with keys auto-generated by the system role. Because vpn_manage_firewall and vpn_manage_selinux are both set to true, the vpn role uses the firewall and selinux roles to manage the ports used by the vpn 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:
       - rhel-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:
       - rhel-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
       vpn_manage_firewall: true
       vpn_manage_selinux: true

   Note

   Because vpn_manage_firewall and vpn_manage_selinux are both set to true, the vpn role uses the firewall and selinux roles to manage the ports used by the vpn role.

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: 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 variable causes the system to reboot after the System Role changes the cryptographic 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: rhel-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
       nbde_server_manage_firewall: true
       nbde_server_manage_selinux: true
   
     roles:
       - rhel-system-roles.nbde_server

   Note

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

4. Apply the finished playbook:

   # ansible-playbook -i inventory-file my-tang-playbook.yml

   Where:

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

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