RHEL System Roles are a collection of Ansible roles and modules that provide a stable and consistent configuration interface to automate and manage multiple releases of Red Hat Enterprise Linux. Our wide variety of System Roles can automate many aspects of RHEL, saving you time and helping to configure your RHEL systems consistently.  

In this post, we’ll walk through how to combine Satellite and RHEL System Roles to provide an effective method of automating the management of RHEL systems.  

Background 

RHEL System Roles are normally run from a central control node where Ansible and the RHEL System Roles are installed. Utilizing Ansible, the control node establishes SSH connections to each of the RHEL instances.  

There are three main options that can be used as your RHEL System Roles control node: Ansible automation controller, Red Hat Satellite, or a standalone RHEL system.

Ansible automation controller offers the most advanced functionality out of these three options, and is the recommended control node for RHEL System Roles for customers with an Ansible Automation Platform subscription.   

The remaining two options for the RHEL System Roles control node are Red Hat Satellite or utilizing a standalone RHEL system. Red Hat Satellite, provided as part of the RHEL Smart Management subscription, provides several benefits over a standalone RHEL System, including:

  • Web based interface to manage RHEL System Roles: This web based interface is simpler than needing to manually edit playbook and inventory files and run Ansible commands from the command line.

  • Inventory management: Use your existing list of RHEL systems in Satellite as your Ansible inventory. Hosts in Satellite can be grouped into host groups, and Ansible roles can be assigned to these host groups. 

  • Ansible job log retention: View previous Ansible job execution history and Ansible log files from Satellite web interface.

  • Utilizes Satellite Remote Execution: Ansible functionality within Satellite utilizes the existing Satellite Remote Execution framework. If you provision hosts with Satellite, you can have the Remote Execution SSH keys automatically deployed as part of the provisioning process.  

  • Ansible Variable management: Import and override Ansible role variable values utilizing the Satellite web interface. Satellite also supports setting up conditional role variable values via matchers. 

  • Recurring job runs: Configure Satellite to run the RHEL System Roles on a recurring basis (such as daily or weekly) to help ensure your systems stay correctly configured.

  • Host status: Satellite tracks the configuration status of each host so you can quickly identify hosts that have not recently had the Ansible roles run, or where the Ansible roles have failed.  

Utilizing RHEL System Roles from Satellite is supported under the Scope of Support for Ansible Components included with Red Hat Satellite 6

Red Hat recently released an updated rhel-system-roles RPM for RHEL 7 that provides the currently available system roles included in RHEL 8.4 (previously only a subset of the current System Roles were available on RHEL 7). Due to this, all of the currently available System Roles are now available to Satellite running on RHEL 7.  

Environment overview

In my example environment, I have a Satellite server named satellite.example.com, and two RHEL 8 Satellite clients: rhel8-server1.example.com and rhel8-server2.example.com.

I would like to use RHEL System Roles within Satellite to apply the following configuration to the two RHEL 8 clients:

  • Session recording should be installed and configured to record all users.

  • The system-wide crypto policy should be set to the DEFAULT policy, with the NO-SHA1 policy modifier to disable SHA-1 in signature algorithms.

Configuring Satellite

Before utilizing RHEL System Roles within Satellite, I need to enable the rhel-7-server-extras-rpms repository and install the rhel-system-roles package on the Satellite server by running these commands:

# subscription-manager repos --enable=rhel-7-server-extras-rpms
# satellite-maintain packages install rhel-system-roles

Note that this satellite-maintain command will restart Satellite services, so it is recommended to run this during a maintenance window. For more information on these steps, refer to this section of the Satellite documentation

Importing the RHEL System Roles and variables

Now that the rhel-system-roles package has been installed on the Satellite server, the next step is to log in to the Satellite web interface and import the roles.  

From the web interface, I’ll go to the Configure menu, and click Roles under the Ansible section. Next, I’ll click on the Import from satellite.example.com button that is in the upper right section of the screen.

Figure 1.

This will bring up a list of available roles that can be imported from Satellite. In this example, I’ll be utilizing the rhel-system-roles.tlog and rhel-system-roles.crypto_policies roles so I will select these two and click the Update button.

Figure 2.

Next, I’ll import the Ansible variables I’ll use with the System Roles. Each role has a README.md file available on the Satellite server at /usr/share/doc/rhel-system-roles-1.0.1/<role name>/README.md

 This file contains information on the available role variables and their function.  

Once I’ve identified which role variables I’ll need, I’ll import the variables by going to the Configure menu, and clicking on Variables under the Ansible section. From there, I’ll click on the blue Import from satellite.example.com button in the upper right section of the screen.

Figure 3.

A list of available variables that can be imported are displayed. I’ll select the variables I’ve identified that I’ll be using based on the system role README.md files:

  • crypto_policies_policy: will specify the desired crypto policy that I would like to be set on the hosts

  • crypto_policies_reboot_ok: It is recommended that hosts be rebooted after their system-wide crypto policy is changed. This variable will allow me to specify if I would like the hosts to be automatically rebooted by the role when needed.  

  • tlog_scope_ssd: will specify the scope of which users should have Session Recording enabled (possible values are all, some, or none).

    Figure 5.

Now that I’ve imported the roles, the next step is to set their values. I’ll start by clicking on the crypto_policies_policy variable, and then check the Override box. I’ll uncheck the Hidden Value box, and then type DEFAULT:NO-SHA1 as the Default Value, then click Submit.  

Figure 6.

The crypto_policies_reboot_ok variable defaults to false, and in my case, I do not want the system role to automatically reboot the hosts, so I will not override this variable. If I would like to have the role automatically reboot the hosts if needed, I could override the default value of this variable to true. Also note that by default, the crypto_policies role will force the reload of some of the daemons affected by crypto policies in the system (this behavior could be changed by overriding the crypto_policies_reload variable; see role README.md file for more information).  

And finally, I’ll click on the tlog_scope_sssd variable, again check the Override box, uncheck the Hidden Value box, and change the Default Value to all to specify that I would like all users sessions to be recorded.  

Figure 7.

Satellite will show a flag icon next to the variables that have been overridden:

Figure 8.

In these examples, we are overriding the variable with a value that will apply to all hosts that we configure Satellite to run the role on. However, it is also possible to utilize variable matchers to conditionally apply different variable values depending on a specific criteria. 

It is even possible to merge multiple matchers in the event that the host matches more than one. For more information on this, please refer to the Advanced Ansible variables in Satellite blog post.  

Assigning the roles to a host group

Next, I need to assign the roles to the hosts, which can be done in two different ways: assigning the roles to individual hosts, or assigning the roles to a host group. In this example, I’ll create a new host group, assign the roles to it, and then assign my two hosts to the host group.  

To create a new host group, I’ll go to the Configure menu, and select Host Groups

From there, I’ll click the blue Create Host Group button in the upper right section of the screen. I’ll name this host group RHEL 8 standard config.  

Figure 9.

I’ll then click on the Ansible Roles tab, and click on the plus sign for rhel-system-roles.crypto_polices and rhel-system-roles.tlog roles to move them from the Available Ansible Roles section to the Assigned Ansible Roles section, and then click the Submit button.

Figure 10.

The next step is to assign the hosts I want to be managed by these system roles to be members of this new host group. To do this, I’ll go to the Hosts menu and select All Hosts. I’ll place checkboxes in each of the two hosts that I would like added to the host group, then click the Select Action drop down, and select Change Group.

 

Figure 11.

This will bring up a menu prompting for which host group these hosts should be assigned to. I’ll select my new RHEL 8 standard config host group and click the Submit button.  

Figure 12.

Running the roles

At this point I’m ready to run the roles on the two clients. This can be done by going to the Configure menu, and selecting Host Groups. To the right of the RHEL 8 standard config host group is a drop down menu that contains an option to Run all Ansible roles.  

Figure 13.

The roles are run on the hosts and a status screen is shown. In the event that there is a failure, each host has a link at the bottom of the status screen which will show the output of the Ansible execution. In this example, both hosts successfully ran the roles.

Figure 14.

Validating the configuration

To validate that my desired system-wide crypto policy configuration was implemented, I can run the update-crypto-policies --show command the hosts, either through a Satellite remote execution job, or manually on the hosts. The output of the command should be DEFAULT:NO-SHA1 which is my desired system-wide crypto policy. 

To validate that session recording is working, I can login to the hosts and verify that I get a notification that my session is being recorded:

Figure 15.

Next steps

You might notice that, by default, your hosts will report their status as Warning, and report that their Configuration status is Out of sync if it has been longer than 30 minutes since the Ansible roles were run on the hosts.  

Figure 16.

For more information on how to configure this functionality, and how to schedule automated recurring runs of the Ansible roles from Satellite, refer to the Scheduling Automatic Runs of Ansible Roles section of the Getting started with Ansible in Satellite post.  

Conclusion

Automation is a key component of managing RHEL environments at scale. Combining Satellite and RHEL System Roles together provides an effective method of automating the management of RHEL systems.  

To explore the RHEL System Roles that are available, review the list of available RHEL System Roles and start managing your RHEL servers in a more efficient, consistent and automated manner today. 


About the author

Brian Smith is a Product Manager at Red Hat focused on RHEL automation and management.  He has been at Red Hat since 2018, previously working with Public Sector customers as a Technical Account Manager (TAM).  

Read full bio