Managing Linux servers with Cockpit

Cockpit is an interesting project for web-based Linux administration that has received relatively little attention over the years. Part of that may be due to the project's strategy of minor releases roughly every two weeks, rather than larger releases with many new features. While the strategy has done little to garner headlines, it has delivered a useful and extensible tool to observe, manage, and troubleshoot Linux servers.

Overview

The Cockpit project started in 2013, sponsored by Red Hat. It was primarily targeted at system administrators new to Linux, such as Windows administrators who were having to adapt to Linux's increasing presence in the server market. It is designed to be distribution-independent, and is available for and tested on many popular Linux distributions including Arch Linux, Debian, Fedora, openSUSE Tumbleweed, and Red Hat Enterprise Linux (RHEL) and its derivatives. See the full list on the running Cockpit page.

The project's goal is to provide a coherent, discoverable GUI to manage systems and make use of tools already present on the system without getting in the way of or conflicting with other tools. Cockpit doesn't save configuration state independently of the system; that is, if an administrator uses Cockpit to make changes to a system firewall and then makes further changes to the firewall using another tool like Ansible, Cockpit won't try to automatically revert Ansible's changes down the road.

One of the project's ideals is that people should "feel they are interacting with the underlying Server OS", and that its user interface should show the server name or operating system name rather than Cockpit branding. As a matter of fact, users are interacting with the underlying operating system when using Cockpit: it uses standard system tools behind the scenes for its tasks if they are available.

While Cockpit is meant to be distribution-independent, its heritage does show through a bit in its choices of default tools. Cockpit uses NetworkManager to manage network configurations, firewalld to manage a system's firewall, storaged for working with system storage, SOS report for creating diagnostic reports, and so forth if they're present on the system. If a distribution defaults to networkd instead of NetworkManager, then the options are to install NetworkManager, forego using Cockpit for network administration, or do the work and contribute the feature to the Cockpit project. For the most part, though, few users contribute features to the project—the majority of contributions to Cockpit come from a handful of Red Hat employees.

If one looks at the past two years of activity in the main Cockpit repository, the majority of commits come from Martin Pitt, Allison Karlitskaya, Jelle van der Waa, Marius Vollmer, and Katerina Koukiou, who are all Red Hat employees. This is not to say that contributions are unwelcome. The project has made a respectable attempt to encourage contributions, or at least make it possible for others to reuse its work. Cockpit has a detailed contribution guide and a developer guide for those interested in contributing to or reusing Cockpit's components.

Cockpit architecture

Cockpit is licensed under the LGPL v2.1 (or later) and consists of the web frontend, along with a web service for communication between the frontend and cockpit-bridge. The cockpit-bridge program is responsible for relaying commands via DBus to systemd, storaged, NetworkManager, and the other system tools used by Cockpit. Its web components are written in JavaScript, with the other components largely written in C or Python. The cockpit-bridge component has implementations in C and Python. The Python bridge was introduced in June 2023, in the Cockpit 294 release. Recent RHEL-based distributions and Fedora have switched to the Python implementation, while Debian 12 and Ubuntu 22.04 are still on the C version of cockpit-bridge.

Once Cockpit is installed and running on a system, its web interface is available on port 9090 by default. The port can be changed, if needed, or the web service can be turned off entirely and Cockpit clients can connect over SSH by using a desktop client, a container that runs the Cockpit web service, or by logging into another server running Cockpit and then connecting to a secondary server.

One might expect problems when mixing and matching versions of Cockpit, but because it is used on so many Linux distributions with varying release schedules, backward compatibility is another of the project's ideals. If a user is running Cockpit on Debian Bookworm, they should be still be able to connect to a server running Fedora Rawhide without problems, or vice versa. Having used Cockpit for years on a variety of systems running Alma Linux, CentOS, Debian, Fedora, RHEL, and Ubuntu, I can confirm that the project does a fine job of maintaining compatibility between releases.

The project recommends using Firefox or Chrome, and has automated tests to ensure compatibility with both browsers. The project also states that it "periodically" tests Edge, Safari, and GNOME's Epiphany web browser. Users trying to connect to Cockpit with Safari on iOS, iPadOS, and Arm-based Macs (at least of this writing), may have a bit of difficulty. Safari on those platforms is missing support for the self-signed certificates that Cockpit uses by default. Users can work around this, or just use a supported browser.

Releases come out roughly every two weeks. The release numbering for the project is somewhat unusual. In 2016 Cockpit adopted a new scheme and started with version 118, with subsequent versions being 119, 120, etc. Note that some releases receive subsequent bugfix releases of their own, such as the 310 release that received a 310.1 release to fix a race condition, and 310.2 with fixes for curl and SELinux. The most recent release as of this writing is Cockpit 313, which comes with a note saying that it contains "assorted bug fixes and improvements" on its release page. The project's blog usually has more descriptive posts that advertise new features such as Btrfs support for 309 or the addition of LVM2 RAID layout support in 304.

The project has a mailing list for development but it is not a lively list. Two messages have been sent in 2024, one in January and one in February. The GitHub discussions page is more lively, and most of the work happens in Cockpit's issue tracker on GitHub.

The fast pace of releases means that the upstream version of Cockpit may be significantly newer than the version packaged for stable or long-term support (LTS) versions of Debian and Ubuntu. The project recommends installing from the Debian backports or Ubuntu backports repositories to use a more up-to-date version if possible.

Taking the controls

Cockpit can be set up to use standard system password or Kerberos authentication when logging in directly. It can use SSH key-based authentication when connecting over SSH to secondary servers. Unlike tools like Webmin, Cockpit doesn't maintain a set of users independently of the system, users log in as themselves, and have the same permissions and privileges as if they had connected via SSH or logged in at the console. Users can also gain administrative access if they have sudo privileges on the host.

After logging in, users will see a system overview page with a dashboard displaying system health, CPU and memory usage, basic system information, and navigation to pages for working with user accounts, system logs, system services, networking, and other tools. The exact services available via Cockpit will vary based on the services available on the host OS and which optional components are installed. This makes it simple to log in and see, at a glance, whether a system has any pending software updates, whether it has logged any errors to be concerned about, and much more.

Drilling down into the metrics and history page, Cockpit offers a more detailed set of metrics about the system's load, which applications are consuming the most memory, the disk usage and throughput, and network interfaces and bandwidth consumption. Note that Cockpit's memory-usage information comes from control groups (cgroups) to provide a quick overview of system usage rather than a full accounting of resident set and virtual memory by process. For historical data, Cockpit uses Performance Co-Pilot (PCP) if it's available. If it isn't available, Cockpit provides an option to install PCP to begin collecting metrics and then display system usage and load over time. Cockpit will even note spikes in load or I/O, with links to logs from that timeframe that might help shed light on the cause.

The services tab allows an administrator to browse the available systemd services, targets, timers, sockets, or paths. From there, administrators can manage the various systemd services, see their relationships with other services, and view their logs. If relevant to a service, Cockpit will also show its memory usage. As an example, browsing the apache2.service on my Debian server running a few WordPress blogs shows 628MB memory in use.

As one might expect, Cockpit's accounts tab will let administrators view users on the system and work with users and groups. In addition to the basic operations like adding or removing users, changing passwords, managing a users' groups, administrators can also browse a users' login history and manage authorized SSH keys.

Extending Cockpit

Cockpit also has number of additional applications one might want to install, depending on what workloads a system is running. For instance, the Cockpit project has applications for working with virtual machines, managing containers with Podman, managing OSTree updates, working with SELinux, and a number of others. There are also third-party application add-ons like the Navigator file browser for Cockpit, another to manage Samba and NFS file sharing, a ZFS on Linux administration utility, and more. If none of the available applications fit the bill, users can create their own custom applications and add them to Cockpit's navigation.

Even with the array of third-party applications for Cockpit, the odds are that eventually one will need to do some system task that isn't doable via its interface. Even then, all is not lost: when all else fails, Cockpit has a web-based terminal for quick and easy access to the command line.

As noted, the Cockpit team churns out releases on a regular basis. The developers don't tend to make much noise about the releases, so the project goes unnoticed by a lot of the users who would benefit most from it. It's a handy, deceptively useful tool that's well worth a look as part of a well-balanced administrator's diet.