RHEL Advanced #7: Cockpit for GUI Management and Web Console — Series Wrap

The RHEL Advanced series has been CLI-centric across its first six posts. The last post adds a GUI on top. Cockpit is the web console Red Hat officially recommends. Instead of SSH’ing in and editing files with vi /etc/..., some tasks go faster in a browser. This post lays out where Cockpit fits, the modules you reach for most, multi-machine management, and how the seven-post series wraps up.

Position of this post in the RHEL Advanced series:

• #1 Boot Process — GRUB2, dracut, Recovery Mode
• #2 Kernel Tuning — sysctl, tuned, kdump
• #3 Performance Analysis — sar, top/htop, iostat, vmstat, perf
• #4 SELinux Advanced — Writing Policy and audit2allow
• #5 Security Hardening — auditd, OpenSCAP, FIPS
• #6 Subscription, Satellite, Insights — Operations Infrastructure
• #7 Cockpit for GUI Management and Web Console — Series Wrap ← this post

Where Cockpit Fits #

It is not that you cannot use the CLI — but CLI is powerful with a narrow field of view, and Cockpit fills that gap. Grabbing the big picture of a newly accessed machine (which services are up, how the disks are laid out, and how many containers are running) is fastest in Cockpit.

Install and Enable #

RHEL 9 usually ships it pre-installed.

$ sudo systemctl status cockpit.socket
○ cockpit.socket - Cockpit Web Service Socket
     Loaded: loaded (/usr/lib/systemd/system/cockpit.socket; disabled; preset: disabled)

# enable
$ sudo systemctl enable --now cockpit.socket

# firewall — Cockpit uses 9090/tcp
$ sudo firewall-cmd --add-service=cockpit --permanent
$ sudo firewall-cmd --reload

An important point: enable cockpit.socket, not cockpit.service. Socket activation means the daemon does not stay up; it wakes when a connection hits port 9090. Resource use at rest is essentially zero.

Connecting #

In your browser:

https://<host>:9090

The default certificate is self-signed, so the first connection shows a warning. On production machines, place a Let’s Encrypt or internal CA cert under /etc/cockpit/ws-certs.d/.

/etc/cockpit/ws-certs.d/0-self-signed.cert  # default self-signed
/etc/cockpit/ws-certs.d/1-fullchain.pem     # custom (alphabetical, last wins)

Logging in #

Authentication goes through PAM, so you log in as a system user. If your user has sudo, the “Limited access” toggle in the upper-left switches to administrator mode.

browser → https://<host>:9090
       │
       ▼
PAM auth (passwd / SSH key / FreeIPA …)
       │
       ▼
session starts → if you have privilege, "administrator access" enabled

Built-in Modules — What You Can See #

The core modules that ship with Cockpit:

Add-on modules (separate install) #

$ sudo dnf install -y \
    cockpit-podman \         # container management
    cockpit-machines \       # KVM/libvirt VM management
    cockpit-pcp \            # performance analysis (PCP integration)
    cockpit-files \          # file manager
    cockpit-storaged \       # advanced storage (Stratis, etc.)
    cockpit-selinux \        # SELinux denial analysis
    cockpit-packagekit       # package management

Once installed, they appear in the menu automatically.

Common Workflows #

1. First inspection of a new machine #

Overview     → big picture of CPU/memory/disk
Networking   → interface IPs, routing, firewall
Storage      → disk partitions, LVM layout, mounts
Services     → which services are up, enabled state
Logs         → recent errors

Five minutes to grasp the whole machine. The equivalent of SSH’ing in and running df -h && free -h && ss -tlnp && systemctl list-units --state=failed && journalctl -p err -n 50, but visually consolidated.

2. Container operations — cockpit-podman #

Podman from Intermediate #7 in a GUI:

• Running container list
• Image pull / build / remove
• Start / stop / restart
• Live log view
• Visualize env vars, mounts, port mappings
• Pod group management

Even if podman ps and podman logs -f are second nature, surveying a freshly accessed machine’s whole container layout is faster in the GUI. Standard operational practice is to use both side by side.

3. Performance analysis — cockpit-pcp #

The sar/iostat data from #3 Performance Analysis graphed in a GUI. Time-series visualization backed by Performance Co-Pilot (PCP).

$ sudo dnf install -y cockpit-pcp pcp
$ sudo systemctl enable --now pmcd pmlogger

After installing, the Cockpit Overview shows time-series graphs for CPU/memory/disk/network — a GUI visualization of the same data sar logs to file.

4. SELinux denial analysis — cockpit-selinux #

A GUI for sealert from #4 SELinux Advanced. The list of AVC denials, an explanation per denial, and even auto-suggested fix commands (semanage fcontext -a ... && restorecon ...) — all in the GUI.

Recommended flow:

1. Spot a denial in the Cockpit SELinux menu
2. Review the suggested fix
3. Either apply the command directly, or modularize via a policy module (#4)

The GUI is where denials get aggregated in human-readable form.

5. VM management — cockpit-machines #

If you run VMs on KVM, in a GUI:

• VM list, state, resource use
• Start / stop / restart / snapshot
• Console (VNC/SPICE) access
• Network / storage configuration
• Create new VMs (from ISO or cloud image)

You can do all of this with virsh, but its learning cost is high. Cockpit gets you to your first VM in five minutes.

Multi-Machine Management — Dashboard #

The Cockpit feature for adding other machines. SSH into other RHEL machines and switch between them in one browser.

Cockpit (https://main:9090) → Dashboard → "Add new host"
                                                │
                                                ▼
                                          ssh other-host
                                          (auto-launches cockpit-bridge)

The other machine does not need Cockpit installed — cockpit-bridge (or a bootstrap via python3) runs over SSH.

Where dashboard fits #

Multi-machine management normally lives in Satellite or Ansible territory. Cockpit’s dashboard is the gap — a few dozen machines or fewer, ad hoc, visual inspection when needed.

Diagnostic Integration — sosreport #

The standard diagnostic bundle Red Hat asks for when you open a support case is sosreport. Generate it via Cockpit’s Diagnostic Reports menu in one click:

$ sudo dnf install -y sos
$ sudo sos report

Press ENTER to continue, or CTRL-C to quit.
...
Your sos report has been generated and saved in:
        /var/tmp/sosreport-host-2026-05-02-abc123.tar.xz

In the GUI: one click → progress display → download the result. Attach to your Red Hat case.

What sosreport collects #

• Major config files under /etc/
• journalctl logs
• dmesg
• rpm -qa (installed package list)
• Network state (ip, ss, routes)
• systemd unit state
• SELinux state
• Memory / CPU info
• Plus 60+ plugins gathering diagnostic data per module

Sensitive material like passwords is scrubbed, but always review the report before sending to Red Hat.

Cockpit and the RHEL Operations Tools #

Each module just calls the same backend commands. Cockpit is not a new tool, but a visual layer over the familiar RHEL tools.

Common Pitfalls #

• Enabling cockpit.service — cockpit.socket is correct. Activating the service directly removes the socket-activation benefit.
• Port 9090 blocked at the firewall — missing firewall-cmd --add-service=cockpit --permanent. No external access.
• Running with self-signed certs — browser warnings every time, and some browsers restrict features (clipboard, etc.). Production needs proper certificates.
• Ignoring SELinux denials — Cockpit itself runs under SELinux policy. Moving custom certs may produce label mismatches and visibility issues. Always pair with restorecon.
• Treating Cockpit as automation — Cockpit is for click-driven humans. Automate with Ansible / Satellite / dnf scripts. If you need to reproduce a GUI action consistently, move it to CLI.
• Adopting the multi-machine dashboard as the standard — it is an ad hoc tool for fewer than tens of machines. Real multi-machine ops live in Satellite or Ansible.
• Exposing the firewall port externally — port 9090 directly on the internet is an attack surface. Stay behind a VPN or SSH tunnel.

Commands Worth Remembering #

Wrap-up #

• Where Cockpit fits — a visual layer where the CLI’s view is narrow. Not a new tool, but a GUI for familiar pieces (systemd, NetworkManager, journalctl, podman, etc.).
• Enabling — cockpit.socket only. Note: not the service. 9090/tcp through the firewall + a real certificate.
• Common workflows — first inspection (Overview → Networking → Storage → Services → Logs), containers (cockpit-podman), performance (cockpit-pcp), SELinux denials (cockpit-selinux), VMs (cockpit-machines).
• Multi-machine dashboard — an ad hoc tool for fewer than tens of machines. Real multi-ops in Satellite or Ansible.
• sosreport — the standard diagnostic bundle for Red Hat cases. One click in the GUI or sos report.
• Automation is always separate — Cockpit is for humans; automate via Ansible / Satellite / scripts.

Series Wrap-up #

That closes the seven-post RHEL Advanced series. From decomposing the boot stages, through kernel tuning, performance analysis, SELinux policy authoring, security hardening, multi-machine operations infrastructure, and adding a GUI layer — we walked one full cycle covering the tools for going deep on a single machine and the tools for running many.

If you followed along, you have a near-complete grasp on the RHEL 9 day-to-day tooling. Where to go next:

• Certification track — RHCSA (EX200) → RHCE (EX294, Ansible automation). Series #6 (Satellite) and #5 (security hardening) overlap with exam domains.
• Practical track — separate series going deep into a single domain: web server operations, DB operations, Podman + systemd quadlets, Ansible automation, etc.
• Linux deep dive — comparison with non-RHEL Linux distros, the kernel itself, modern tools like eBPF.

Thanks for reading this far. May RHEL 9 become a machine you have firmly in hand.