Chapter 2. Preparing a control node and managed nodes to use RHEL system roles Before you can use individual RHEL system roles to manage services and settings, you must prepare the control node and managed nodes. 2.1. Preparing a control node on RHEL 8 Before using RHEL system roles, you must configure a control node. This system then configures the managed hosts from the inventory according to the playbooks. Prerequisites RHEL 8.6 or later is installed. For more information about installing RHEL, see Interactively installing RHEL from installation media . 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 . The system is registered to the Customer Portal. A Red Hat Enterprise Linux Server subscription is attached to the system. Optional: An Ansible Automation Platform subscription is attached to the system. Procedure Create a user named ansible to manage and run playbooks: Switch to the newly created ansible user: Perform the rest of the procedure as this user. Create an SSH public and private key: Use the suggested default location for the key file. Optional: To prevent Ansible from prompting you for the SSH key password each time you establish a connection, configure an SSH agent. Create the ~/.ansible.cfg file with the following content: 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. 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 : 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 to the host entry to specify its IP address. Install RHEL system roles: On a RHEL host without Ansible Automation Platform, install the rhel-system-roles package: This command installs the collections in the /usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/ directory, and the ansible-core package as a dependency. On Ansible Automation Platform, perform the following steps as the ansible user: Define Red Hat automation hub as the primary source for content in the ~/.ansible.cfg file. Install the redhat.rhel_system_roles collection from Red Hat automation hub: This command installs the collection in the ~/.ansible/collections/ansible_collections/redhat/rhel_system_roles/ directory. step Prepare the managed nodes. For more information, see Preparing a managed node . Additional resources Scope of support for the Ansible Core package included in the RHEL 9 and RHEL 8.6 and later AppStream repositories How to register and subscribe a system to the Red Hat Customer Portal using subscription-manager (Red Hat Knowledgebase) The ssh-keygen(1) manual page Connecting to remote machines with SSH keys using ssh-agent Ansible configuration settings How to build your inventory Updates to using Ansible in RHEL 8.6 and 9.0 2.2. Preparing a managed node Managed nodes are the systems listed in the inventory and which will be configured by the control node according to the playbook. You do not have to install Ansible on managed hosts. Prerequisites You prepared the control node. For more information, see Preparing a control node on RHEL 8 . You have SSH access from the control node. Important Direct SSH access as the root user is a security risk. To reduce this risk, you will create a local user on this node and configure a sudo policy when preparing a managed node. Ansible on the control node can then use the local user account to log in to the managed node and run playbooks as different users, such as root . Procedure Create a user named ansible : The control node later uses this user to establish an SSH connection to this host. Set a password for the ansible user: You must enter this password when Ansible uses sudo to perform tasks as the root user. Install the ansible user's SSH public key on the managed node: Log in to the control node as the ansible user, and copy the SSH public key to the managed node: When prompted, connect by entering yes : When prompted, enter the password: Verify the SSH connection by remotely executing a command on the control node: Create a sudo configuration for the ansible user: Create and edit the /etc/sudoers.d/ansible file by using the visudo command: The benefit of using visudo over a normal editor is that this utility provides basic checks, such as for parse errors, before installing the file. 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: 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: Alternatively, configure a more fine-granular policy that matches your security requirements. For further details on sudoers policies, see the sudoers(5) manual page. Verification Verify that you can execute commands from the control node on an all managed nodes: [ansible@control-node]USD 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. Verify that privilege escalation works correctly by running the whoami utility on all managed nodes by using the Ansible command module: If the command returns root, you configured sudo on the managed nodes correctly. Additional resources Preparing a control node on RHEL 8 sudoers(5) manual page

Commands:
useradd ansible
su - ansible
[ansible@control-node]USD 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>
[defaults] inventory = /home/ansible/inventory remote_user = ansible [privilege_escalation] become = True become_method = sudo become_user = root become_ask_pass = True
managed-node-01.example.com [US] managed-node-02.example.com ansible_host=192.0.2.100 managed-node-03.example.com
yum install rhel-system-roles
[ansible@control-node]USD ansible-galaxy collection install redhat.rhel_system_roles
useradd ansible
passwd ansible Changing password for user ansible. New password: <password> Retype new password: <password> passwd: all authentication tokens updated successfully.
[ansible@control-node]USD 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.
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
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.
[ansible@control-node]USD ssh managed-node-01.example.com whoami ansible
visudo /etc/sudoers.d/ansible
ansible ALL=(ALL) ALL
ansible ALL=(ALL) NOPASSWD: ALL
[ansible@control-node]USD 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" }
[ansible@control-node]USD ansible all -m command -a whoami BECOME password: <password> managed-node-01.example.com | CHANGED | rc=0 >> root