Cockpit Web Console on Fedora Server: Managing LVM Storage and Podman Containers from the Browser - ITFROMZERO - Share tobe shared! After 6 months managing a Fedora Server with LVM storage and multiple Podman containers, I found Cockpit to be the most suitable web console solution. This article covers how to install cockpit-storaged, cockpit-podman, and configure security for a real-world environment.

Table of Contents

Problems I Ran Into After 6 Months Managing Fedora Server

I’ve been using Fedora as my main development machine for 2 years and have been pretty happy with the pace of package updates. When I expanded to a homelab with 3 Fedora servers, manual management started showing its limits: LVM storage spread across multiple volume groups, dozens of Podman containers running different services, and having to manage everything over SSH from multiple parallel terminals.

It’s not that CLI is bad — I still use it as my primary tool. But when I need to check disk usage on machine B while debugging a container on machine A — open a new terminal, SSH in, type df -h then podman ps — that routine repeats itself a dozen times a day. Each time only takes 2–3 minutes, but it adds up. Worse is when I need to explain the server’s state to someone else: sharing a URL is so much easier than walking them through SSH step by step.

When CLI Starts Creating More Work Instead of Saving Time

Looking back at my workflow, I identified 4 specific pain points where CLI was costing me extra unnecessary steps:

Monitoring multiple metrics simultaneously: CPU, RAM, disk I/O, network — I had to run top, iostat, netstat in parallel across multiple terminals with no single-screen overview
Managing LVM: Resizing a logical volume when a disk fills up requires remembering the exact syntax for lvcreate/lvextend/resize2fs and the precise device name — one wrong character causes trouble
Container lifecycle: Starting/stopping/inspecting multiple containers at once, watching logs in real time — each action requires its own command
Remote access from other devices: From a phone or a machine without an SSH client installed, a browser is always available

Solutions I Tried Before Cockpit

Netdata — Great Monitoring but Read-Only

Netdata gives you a beautiful dashboard with highly detailed real-time metrics. But it’s read-only — you can’t restart services, manage storage, or control containers from it. I still had to open a parallel terminal, so the original loop remained.

Webmin — Feature-Rich but Not Native to the Fedora Stack

Webmin has been around since I was first learning IT and supports almost everything. But the interface feels dated, configuration is complex, and more importantly: Webmin doesn’t integrate natively with systemd or Podman the way Fedora uses them. It wraps an extra layer on top, making it easy to get inconsistent behavior between Webmin and the CLI.

Portainer — Great for Containers, Doesn’t Solve the Storage Problem

Portainer is excellent for managing Docker/Podman containers. But it only handles the container side — storage and system monitoring still need separate tools.

Cockpit: Native to the Fedora Stack, No Trade-offs Required

Cockpit differs from the three above on one key point: it’s developed by Red Hat and integrates natively with the exact stack Fedora uses — systemd, NetworkManager, Podman, LVM. No extra wrapper layers, no separate background agent required. And it doesn’t try to do everything: it does what I actually need, and does it well.

Installing Cockpit and the Required Modules

On Fedora Server, Cockpit is often pre-installed. If it’s not, installation is very quick:

# Install Cockpit core
sudo dnf install cockpit -y

# Storage management module (LVM, RAID, Btrfs, iSCSI)
sudo dnf install cockpit-storaged -y

# Podman container management module
sudo dnf install cockpit-podman -y

# Enable and start immediately
sudo systemctl enable --now cockpit.socket

Important note: Cockpit uses socket activation — the service only actually runs when a connection comes in, sitting completely idle when not in use. On my server, Cockpit consumes virtually no RAM at idle, while Netdata or Webmin continuously consume 50–100MB. This matters a lot on resource-constrained servers.

Opening the Firewall and First Access

# Open port 9090 through firewalld
sudo firewall-cmd --add-service=cockpit --permanent
sudo firewall-cmd --reload

# Verify
sudo firewall-cmd --list-services

Access it at https://[SERVER-IP]:9090. The browser will warn about SSL because it uses a self-signed cert by default — that’s normal; accept the exception or install a real cert via Let’s Encrypt later. Log in with a Linux user that has sudo privileges.

Managing LVM Storage with cockpit-storaged

cockpit-storaged is the main reason I installed Cockpit. The Storage tab displays everything: physical disks, partitions, volume groups, logical volumes, and filesystems — all on one screen with real-time I/O graphs.

When I needed to extend the logical volume for /var after logs filled the disk, instead of having to type precisely:

sudo lvextend -L +20G /dev/fedora/var
sudo resize2fs /dev/fedora/var

With Cockpit: click the volume, drag the resize slider, click Grow — done in 10 seconds, no risk of mistyping the device path. The filesystem gets resized automatically too.

Beyond LVM, cockpit-storaged also supports:

Creating/deleting partitions and formatting filesystems directly
Mounting/unmounting and automatically updating /etc/fstab
Monitoring SMART status of hard drives — warning you before a drive dies
Configuring software RAID (mdadm) and iSCSI

Managing Podman Containers with cockpit-podman

Before using this module, make sure Podman is installed:

podman --version

# If not installed
sudo dnf install podman -y

The Podman containers tab displays both rootless (user) and rootful (root) containers with real-time CPU/RAM usage per container. Things you can do from the UI:

View container logs in real time — replaces podman logs -f
Start/stop/restart/delete containers
Inspect environment variables, mount points, port bindings
Commit a container into a new image

The best part is viewing logs in real time directly in the browser. When debugging at midnight from my phone, I don’t need to open a mobile SSH client — just open the browser, go to the Cockpit URL, and the logs are right there.

System Monitoring and Service Management

The default dashboard already shows CPU, RAM, disk I/O, and network traffic — continuously updating real-time graphs. The Services tab lists all systemd units with their status, allowing you to start/stop/restart and view journal logs directly without touching a terminal.

Managing Multiple Servers from a Single Interface

The most convenient feature: from Cockpit on machine A, add machine B and control both from a single browser tab without switching windows or opening new terminals. On the remote server, Cockpit just needs to be running:

# Check the remote server
sudo systemctl status cockpit.socket

In the Cockpit UI: Hosts → Add new host → enter the IP and authenticate via SSH. From there, switching between the two servers is just a click on the host name in the sidebar.

Restricting Access for Production Environments

By default, Cockpit allows any Linux user to log in. In production, you should lock this down:

sudo tee /etc/cockpit/cockpit.conf << 'EOF'
[WebService]
AllowedUsers = youradminuser
Origins = https://your-domain.com https://[SERVER-IP]:9090
EOF

sudo systemctl restart cockpit

Cockpit works fine in SELinux Enforcing mode — no need to disable SELinux like some other tools require. This is a big plus when combined with SELinux configuration on Fedora.

Why Cockpit Is the Best Fit for the Fedora Stack

After 6 months of real-world use, here’s why I keep using Cockpit:

Genuine native integration: Cockpit calls the systemd D-Bus API, Podman REST API, and LVM directly — it doesn’t parse CLI command output. Actions through the UI produce identical results to the CLI, with no surprises
Flexible modularity: Install only the modules you need. A homelab has different requirements than a production server
Zero resource usage at idle: Socket activation — nothing runs in the background when you’re not using it
Maintained by Red Hat: Fedora updates fast, and Cockpit keeps up — no compatibility concerns with the latest kernel and systemd versions
SELinux-aware: Works correctly in Enforcing mode without breaking your configured security policy

I still use the CLI for automation, scripting, and complex operations — Cockpit can’t replace a terminal. But for quickly checking system health, managing storage when a disk fills up, and debugging containers from any device — Cockpit has become a tab I keep pinned in my browser alongside my other dashboards.