Skip to main content

A brief introduction to Ansible roles for Linux system administration

In this part one of two articles, learn to use rhel-system-roles with your Ansible deployment to better manage functionality such as network, firewall, SELinux, and more on your Red Hat Enterprise Linux servers.

Photo by RODNAE Productions from Pexels

Ansible is an open source automation platform that includes configuration management, application deployment, and infrastructure orchestration. It is a  popular automation tool for DevOps engineers and for system administrators. System administrators often face career burnout due to long hours and from performing repetitive tasks on many systems, but Ansible helps make these tasks easier to complete. Tasks such as user creation, service management, and software installs can be accomplished using Ansible. Ansible is procedure-based rather than declarative, which means you write all required steps into a YAML file and then run them sequentially on all target systems.

[ You might also like to read: Using an Ansible playbook to manage workstation and server updates ]


In Ansible architecture, you have a controller node and managed nodes. Ansible is installed on only the controller node. It’s an agentless tool and doesn’t need to be installed on the managed nodes. Controller and managed nodes are connected using the SSH protocol. All tasks are written into a "playbook" using the YAML language. Each playbook can contain multiple plays, which contain tasks, and tasks contain modules. Modules are reusable standalone scripts that manage some aspect of a system's behavior. Ansible modules are also known as task plugins or library plugins.


Playbooks for complex tasks can become lengthy and therefore difficult to read and understand. The solution to this problem is Ansible roles. Using roles, you can break long playbooks into multiple files making each playbook simple to read and understand. Roles are a collection of templates, files, variables, modules, and tasks. The primary purpose behind roles is to reuse Ansible code. DevOps engineers and sysadmins should always try to reuse their code. An Ansible role can contain multiple playbooks. It can easily reuse code written by anyone if the role is suitable for a given case. For example, you could write a playbook for Apache hosting and then reuse this code by changing the content of index.html to alter options for some other application or service.

The following is an overview of the Ansible role structure. It consists of many subdirectories, such as:

|-- defaults
|-- files
|-- handlers
|-- meta
|-- tasks
|-- templates
|-- tests
|-- vars

Initially, all files are created empty by using the ansible-galaxy command. So, depending on the task, you can use these directories. For example, the vars directory stores variables. In the tasks directory, you have main.yml, which is the main playbook. The templates directory is for storing Jinja templates. The handlers directory is for storing handlers.

Advantages of Ansible roles:

  • Allow for content reusability
  • Make large projects manageable

Ansible roles are structured directories containing sub-directories.

But did you know that Red Hat Enterprise Linux also provides some Ansible System Roles to manage operating system tasks?

System roles

The rhel-system-roles package is available in the Extras (EPEL) channel. The rhel-system-roles package is used to configure RHEL hosts. There are seven default rhel-system-roles available:

  • rhel-system-roles.kdump - This role configures the kdump crash recovery service. Kdump is a feature of the Linux kernel and is useful when analyzing the cause of a kernel crash.
  • - This role is dedicated to network interfaces. This helps to configure network interfaces in Linux systens.
  • rhel-system-roles.selinux - This role manages SELinux. This helps to configure the SELinux mode, files, port-context, etc.
  • rhel-system-roles.timesync - This role is used to configure NTP or PTP on your Linux system.
  • rhel-system-roles.postfix - This role is dedicated to managing the Postfix mail transfer agent.
  • rhel-system-roles.firewall - As the name suggests, this role is all about managing the host system's firewall configuration.
  • rhel-system-roles.tuned - Tuned is a system tuning service in Linux to monitor connected devices. So this role is to configure the tuned service for system performance.

The rhel-system-roles package is derived from open source Linux system-roles. This Linux-system-role is available on Ansible Galaxy. The rhel-system-roles is supported by Red Hat, so you can think of this as if rhel-system-roles are downstream of Linux system-roles. To install rhel-system-roles on your machine, use:

$ sudo yum -y install rhel-system-roles
$ sudo dnf -y install rhel-system-roles

These roles are located in the /usr/share/ansible/roles/ directory. 

This is the default path, so whenever you use playbooks to reference these roles, you don’t need to explicitly include the absolute path. You can also refer to the documentation for using Ansible roles. The path for the documentation is /usr/share/doc/rhel-system-roles

The documentation directory for each role has detailed information about that role. For example, the file is an example of that role, etc. The documentation is self-explanatory.

The following is an example of a role.


If you want to change the SELinux mode of the localhost machine or any host machine, then use the system roles. For this task, use rhel-system-roles.selinux

For this task the ansible-playbook looks like this:


- name: a playbook for SELinux mode
 hosts: localhost

- rhel-system-roles.selinux

- selinux_state: disabled

After running the playbook, you can verify whether the SELinux mode changed or not.

[ Looking for more on system automation? Get started with The Automated Enterprise, a free book from Red Hat. ] 

Wrap up

This brief introduction to Ansible roles should be enough to get you started using them in your playbooks. Remember that Ansible is meant to streamline and simplify those repetitive tasks and to make your sysadmin life easier.

Ansible Galaxy is a repository for Ansible Roles that are available to drop directly into your Playbooks to streamline your automation projects.
Topics:   Linux   Linux administration   Ansible  
Author’s photo

Shiwani Biradar

Shiwani Biradar is an Associate Technical support Engineer in Red Hat. She loves contributing to open source projects and communities. Shiwani never stops exploring new technologies. If you don't find her exploring technologies then you will find her exploring food. More about me

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.