Contato

Automation can help increase efficiency, save time, and improve consistency, which is why Red Hat Enterprise Linux (RHEL) includes features that help automate many tasks. The RHEL System Roles is a collection of Ansible content that helps provide consistent workflows and streamline the execution of many manual tasks.

RHEL includes a web-based graphical interface for managing and monitoring systems, named the web console (which is based on the upstream Cockpit project). The web console can be used to complete a wide variety of tasks, such as managing storage, users, and the firewall, monitoring performance metrics, reviewing log files, installing system updates, and many other tasks. For more information on the web console, see the Managing systems using the RHEL 8 web console documentation.

With RHEL 9.0 and 8.6 Red Hat is introducing a new cockpit RHEL System Role for automating the management and implementation of the web console. This role can automate tasks such as installing Cockpit related packages, configuring settings within cockpit.conf, starting/enabling the cockpit.socket systemd unit, and optionally configuring a TLS certificate for the web console to use.

The web console uses self-signed certificates by default, but many organizations, for security reasons, discourage the use of self-signed certificates or prohibit them altogether. We recommend using the web console with a certificate signed by a trusted certificate authority (CA).

The certificate RHEL System Role can automate issuing and renewing certificates. The certificate role can issue certificates from the Red Hat Identity Management (IdM) CA, or from a self-signed/local CA.

In this article, I’ll show you how to use the cockpit and certificate roles to automate the deployment of the web console, with certificates issued from IdM.

What is the difference between the web console and Cockpit?

Throughout this blog post, and also in the RHEL documentation, you’ll see references to both web console and Cockpit. Web console is the name of the functionality within RHEL, which is based on the upstream Cockpit project. In RHEL the RPM packages start with the cockpit name, and the systemd socket is named cockpit.socket. In addition, the new RHEL System Role is named cockpit.

Environment overview

In my example environment, I have a control node system named rhel9-controlnode.example.com and two managed nodes: rhel9-server1.example.com and rhel9-server2.example.com, all running RHEL 9 Beta. I also have Red Hat Identity Management (IdM) configured in the environment, and each of my nodes is configured as an IdM client.

Environment overview

I’m using the latest version (1.12.1) of the RHEL System Roles collection on Ansible Automation Hub, because it is currently the latest release of RHEL System Roles and includes updates to the cockpit RHEL System Role that are not yet available in RHEL 9 Beta. Red Hat Ansible Automation Hub is only available to Red Hat Ansible Automation Platform customers, however, when RHEL 9.0 GA and 8.6 are released, the rhel-system-roles RPM in each of these releases are planned to include the functionality outlined in this blog.

I would like to implement the following configuration:

  • The web console should be installed on each managed node, with the following additional Cockpit packages:

    • cockpit-session-recording

    • cockpit-podman

    • cockpit-storaged

  • The cockpit.socket service should be started/enabled on each managed node so that the web console is available for use both now and after a reboot.

  • The cockpit.conf configuration file should be configured with the following on each managed node:

    • The IdleTimeout option should be set to 15 minutes.

    • The web console should display the contents of the /etc/issue file on the login screen (the cockpit.conf Banner option). The /etc/issue file already exists on my managed nodes and contains my desired login banner.

  • The cockpit service should be open in the firewall on each managed node.

  • A new certificate should be issued from my existing IdM CA environment.

    • The web console should be configured to use this newly issued IdM certificate.

If you would like to implement certificates with a combination of thecertificate and cockpit roles, as I will in this blog post, Cockpit version 257 or later is required. RHEL 9 Beta currently includes a version of Cockpit that meets this requirement, and the upcoming RHEL 8.6 release will as well.  

Because RHEL 7 is in the Maintenance Support 2 phase of its lifecycle, it generally does not receive updated packages to enable new features or functionality. Due to this, the procedure outlined in this blog related to using the certificate role with the cockpit role is not compatible with RHEL 7. However, the other functionality of the cockpit role is compatible with RHEL 7. For example, you can use the cockpit role to install Cockpit packages, configure Cockpit, and enable/start cockpit.socket on RHEL 7.  

In summary, the procedure using the certificate and cockpit roles outlined in this blog is planned to be compatible with the upcoming RHEL 9.0 and 8.6 releases, however it will not be compatible with RHEL 8.5 or below or RHEL 7 systems.  

Introduction to the certificate RHEL system role

I’ll be using a combination of the certificate, cockpit, and firewall roles in this scenario, so I’ll cover an introduction to each of these roles.  

The certificate RHEL System Role can automate the process of issuing and renewing TLS certificates.  It supports both self-signed certificates as well as certificates issued from Red Hat Identity Management (IdM). In my example environment, I would like to have certificates issued from my IdM server.  

For more information on the certificate role, refer to the Requesting certificates using RHEL System Roles or the role README.md file which is available at /usr/share/doc/rhel-system-roles/certificate/README.md

I’ll be placing all of my role variables into my Ansible inventory file. To issue new certificates for web console from my IdM environment for each of my managed nodes, I’ll define the certificate_requests variable as follows:

    certificate_requests:      - name: "{{ inventory_hostname }}-cockpit"        dns: "{{ inventory_hostname}}"        principal: "cockpit/{{ inventory_hostname }}@EXAMPLE.COM"        ca: ipa

The {{ inventory_hostname }} variable will contain the hostname (from the inventory) of the current server that the certificate role is running on. My inventory will contain the server's fully qualified domain names (rhel9-server1.example.com and rhel9-server2.example.com).

I’ll define that the name of the certificate should be the {{ inventory_hostname }} variable followed by -cockpit. Based on this, the certificate and private key will be placed in the following locations on rhel9-server1.example.com and rhel9-server2.example.com:

rhel9-server1.example.com:

  • Certificate file:  /etc/pki/tls/certs/rhel9-server1.example.com-cockpit.crt

  • Private key:  /etc/pki/tls/private/rhel9-server1.example.com-cockpit.key

rhel9-server2.example.com:

  • Certificate file: /etc/pki/tls/certs/rhel9-server2.example.com-cockpit.crt

  • Private key: /etc/pki/tls/private/rhel9-server2.example.com-cockpit.key

I’ll specify that the DNS name for each certificate should be the {{ inventory_hostname }} variable, and that the principal should be set to cockpit/{{ inventory_hostname }}@EXAMPLE.COM.

Finally, I’ll specify that the certificate should be issued from IdM by setting ca to ipa (FreeIPA is the upstream project that IdM is based on). If I would like to have a self-signed certificate issued, I could set ca to self-signed

Introduction to the cockpit RHEL System Role

The cockpit RHEL System Role provides the ability to automate the installation and configuration of the web console across RHEL environments.

It is possible to specify which Cockpit related packages should be installed, if Cockpit should be started and enabled, options within the /etc/cockpit/cockpit.conf configuration file, and to specify which certificate should be used. If the certificate options are not utilized, the web console will generate a self signed certificate by default.

For more information on the cockpit system role, refer to the role README.md file at /usr/share/doc/rhel-system-roles/cockpit/README.md

To achieve my desired web console configuration, I’ll be using the following cockpit role variables in my inventory file:

    cockpit_cert: "/etc/pki/tls/certs/{{ inventory_hostname }}-cockpit.crt"    cockpit_private_key: "/etc/pki/tls/private/{{ inventory_hostname }}-cockpit.key"    cockpit_packages:       - cockpit-session-recording      - cockpit-podman      - cockpit-storaged    cockpit_config:      Session:        IdleTimeout: 15        Banner: /etc/issue

Thecockpit_cert and cockpit_private_key variables will point to the certificate and private key files, respectively, that will be created by the certificate role.

Thecockpit_packages variable lists the three Cockpit packages that I would like to be installed. The cockpit_config variable specifies the configuration options I would like set in /etc/cockpit/cockpit.conf, which has an INI style syntax. I specify that under the Session section, the IdleTimeout option should be set to 15 minutes, and the Banner option should be set to display the contents of the /etc/issue file (which already exists on my managed nodes and contains my desired login banner).

Introduction to the firewall RHEL System Role

The firewall RHEL System Role provides the ability to automate the configuration of the firewall. In my scenario, I’ll simply use it to open the cockpit service, but the firewall role also provides functionality to manage zones, implement rich rules, configure port forwarding, enable masquerading, etc.

For more information on the firewall system role, refer to the README.md file at /usr/share/doc/rhel-system-roles/firewall/README.md  

In my environment, I simply need to ensure the cockpit service is open in the firewall on my managed nodes, so I’ll use the following in my inventory file:

    firewall:      service: 'cockpit'      state: 'enabled'

Creating the inventory

At this point I’ll create my inventory file, named inventory.yml. In this file, I’ll list my managed nodes and define the previously covered role variables for the certificate, cockpit and firewall system roles.

all:  hosts:    rhel9-server1.example.com:    rhel9-server2.example.com:  vars:    certificate_requests:      - name: "{{ inventory_hostname }}-cockpit"        dns: "{{ inventory_hostname}}"        principal: "cockpit/{{ inventory_hostname }}@EXAMPLE.COM"        ca: ipa    cockpit_cert: "/etc/pki/tls/certs/{{ inventory_hostname }}-cockpit.crt"    cockpit_private_key: "/etc/pki/tls/private/{{ inventory_hostname }}-cockpit.key"    cockpit_packages:       - cockpit-session-recording      - cockpit-podman      - cockpit-storaged    cockpit_config:      Session:        IdleTimeout: 15        Banner: /etc/issue    firewall:      service: 'cockpit'      state: 'enabled'

Under the all group, I define my two managed nodes under the hosts section. Under the vars section, I define all of the role variables previously discussed that will be needed to implement my desired configuration.  

image If using Ansible automation controller as your control node, this Inventory can be imported into Red Hat Ansible Automation Platform via an SCM project (example GitHub or GitLab) or using the awx-manage Utility as specified in the documentation.

Writing the playbook

The next step is creating the playbook file, which I’ll name cockpit.yml, with this information:

- name: Configure IPA certificates  hosts: all  roles:    - redhat.rhel_system_roles.certificate- name: Configure firewall   hosts: all  roles:    - redhat.rhel_system_roles.firewall- name: Configure Cockpit  hosts: all  roles:    - role: redhat.rhel_system_roles.cockpit

This playbook simply calls the three roles I’ll be using:  certificate, firewall and cockpit. Note that the order in which these roles run is important: I need to generate the certificates with the certificate role before I run the cockpit role that is configured to use the certificates.    

imageIf you are using Ansible automation controller as your control node, you can import this Ansible playbook into Red Hat Ansible Automation Platform by creating a Project, following the documentation provided here. It is very common to use Git repos to store Ansible playbooks. Ansible Automation Platform stores automation in units called Jobs which contain the playbook, credentials and inventory. Create a Job Template following the documentation here

Running the playbook

At this point, everything is in place, and I’m ready to run the playbook. For this demonstration, I’m using a RHEL control node and will run the playbook from the command line. I’ll use the cd command to move into the cockpit directory where I created the inventory file and playbook, and then use the ansible-playbook command to run the playbook. 

[ansible@rhel9-controlnode ~]$ cd cockpit[ansible@rhel9-controlnode cockpit]$ ansible-playbook cockpit.yml -b -i inventory.yml

I specify that the cockpit.yml playbook should be run, that it should escalate to root (the -b flag), and that the inventory.yml file should be used as my Ansible inventory (the -i flag).

After the playbook completes, I need to verify that there were no failed tasks:

Verify there are no failed tasks.

imageIf you are using Ansible automation controller as your control node, you can launch the job from the automation controller web interface. 

Validating the configuration

To validate the configuration, I’ll start by attempting to connect to the web console on the rhel9-server1.example.com server on port 9090. If I do this from a web browser that trusts my IdM certificate authorities certificate, I should be able to establish a connection without any warnings regarding the TLS certificates:

Connecting to the web console.

I am able to successfully connect without any TLS warnings. I can also validate that the contents of the /etc/issue file are shown (Authorized users only).  

Once I log in to the web console, I’ll go to Applications in the menu on the left to validate that my list of desired Cockpit packages was installed:

List of Cockpit packages.

The cockpit-session-recording, cockpit-storaged, and cockpit-podman packages were installed and show up within web console.

To validate the 15 minute timeout, I can leave my session idle for more than 15 minutes and validate that I am automatically logged out due to inactivity, as shown:

Validating the 15 minute timeout.

Conclusion

The certificate, cockpit and firewall RHEL System Roles can help you quickly and consistently implement the web console across your RHEL environment, utilizing certificates issued from Red Hat Identity Management.  

Red Hat offers many RHEL System Roles that can help automate other important aspects of your RHEL environment. To explore additional roles, review the list of available RHEL System Roles and start managing your RHEL servers in a more efficient, consistent and automated manner today.

Want to learn more about the Red Hat Ansible Automation Platform? Check out our e-book, The automation architect's handbook.


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
Red Hat logoLinkedInYouTubeFacebookTwitter

Produtos

Ferramentas

Experimente, compre, venda

Comunicação

Sobre a Red Hat

A Red Hat é a líder mundial em soluções empresariais open source como Linux, nuvem, containers e Kubernetes. Fornecemos soluções robustas que facilitam o trabalho em diversas plataformas e ambientes, do datacenter principal até a borda da rede.

Assine nossa newsletter Red Hat Shares

Cadastre-se agora

Selecione um idioma