Using Cockpit for Everyday Administration on Rocky Linux 9

The problem: managing a Rocky Linux server without constant CLI juggling

When you inherit a Rocky Linux host that runs a mix of services—web servers, databases, and container workloads—you often need to check CPU usage, restart a service, or add a user. Doing all of that from the terminal works, but switching between multiple SSH tabs, remembering exact systemctl syntax, and parsing journal output can slow you down, especially if you’re not a daily shell power user.

Thesis: Cockpit gives you a lightweight, browser‑based dashboard that lets you monitor and administer Rocky Linux with minimal overhead

Cockpit is packaged in the default repositories for Rocky Linux 8 and 9. It runs as a privileged socket‑activated service, exposes a secure web UI on port 9090, and integrates with the same tools you already use (firewalld, Podman, SELinux). Once enabled, you can view real‑time metrics, control services, manage accounts, and even inspect logs—all from a familiar browser interface.

Installation and activation

Run the following commands as a user with sudo privileges (or root) on the Rocky Linux host:

# Install the cockpit package from the base repo
sudo dnf install -y cockpit

# Enable and start the socket‑activated service
sudo systemctl enable --now cockpit.socket

Required permissions: you need to be able to install packages and manage systemd services (typically via sudo). The command enables the socket so that cockpit-ws starts only when a connection arrives, keeping idle memory usage low.

Expected check: after enabling, verify the socket is active and listening:

sudo systemctl status cockpit.socket
# Look for "Active: active (running)"

# Confirm the port is bound
sudo ss -tlnp | grep 9090
# Expected output includes: LISTEN 0 128 *:9090 *:* users:((("cockpit-ws",pid=...,fd=...)))

Risk: if a firewall blocks port 9090, the UI will be unreachable. Ensure firewalld allows the port or adjust accordingly.

Worked example: restarting a service and viewing its logs

Suppose you need to restart httpd and quickly see if any errors appeared.

1. Open a browser and navigate to https://:9090. Accept the self‑signed certificate (or replace it with a trusted one later).
2. Log in with a local system account that has sudo privileges (e.g., your regular user).
3. In the Cockpit dashboard, select "Services" from the left menu.
4. Find httpd in the list, click the three‑dot menu, and choose "Restart". Cockpit runs the equivalent of sudo systemctl restart httpd behind the scenes.
5. After the restart, go to "Logs" → "Journal" and filter by the httpd unit. The live view shows the most recent entries, letting you confirm the service started without errors.

This workflow avoids typing journalctl -u httpd -f in a terminal and provides a visual filter interface.

Trade‑off and limitation

Cockpit adds a small, persistent memory footprint (the cockpit-ws process) and opens a network listener on port 9090. On very low‑resource devices—such as a minimal Raspberry Pi running Rocky Linux—the extra web socket and JavaScript load can be noticeable during heavy UI interaction. Additionally, because the service runs with root privileges, exposing the port to an untrusted network without proper TLS or firewall restrictions creates a potential attack surface.

Practical way to check the overhead: after enabling Cockpit, run top or htop and look for the cockpit-ws process. Its RES size is typically under 50 MB on a modern x86_64 host. If you notice sustained high CPU usage from the process while idle, consider disabling the socket (sudo systemctl disable --now cockpit.socket) and using the CLI instead.

Actionable closing

If you administer Rocky Linux servers and want a quick glance at system health without memorizing dozens of CLI flags, install Cockpit, enable the socket, and access the UI on port 9090. Verify the service is active, confirm the port is listening, and log in with a local account to start managing services, users, and logs right away. For production environments, replace the self‑signed certificate with one signed by your internal CA and restrict access to trusted networks via firewalld rules.