Fly by Sight

Cockpit [1] offers a graphical user interface for managing servers that takes care of network configuration, displays the server load, starts and stops system services, manages users, and more. All of these tasks can be handled conveniently in a web browser. Cockpit's feature scope is ideally suited to managing individual servers or server farms in corporate environments.

Unlike comparable products such as Webmin [2], which accesses the basic system through Perl scripts, Cockpit works exclusively and directly with systemd, as can be seen in the software versioning: The current version is 217. A glance at the blog [3] reveals that new versions of Cockpit are released approximately every two weeks.

In an article from 2015 [4], ADMIN looked into the topic of managing Linux servers with Cockpit; since then, much has changed. The Red Hat-sponsored project is now available for Fedora, Red Hat Enterprise Linux (RHEL), CentOS, Debian (version 9 and above), and Ubuntu (17.04 and above) and runs on x86_64 architectures, as well as 32-bit ARMv7 and 64-bit ARMv8 (AArch64). The server images of CentOS and Fedora come with Cockpit preinstalled.

Quickstart

On CentOS and Fedora, you can install Cockpit and enable and launch the matching systemd socket with:

dnf install cockpit
systemctl enable cockpit.socket
systemctl start cockpit.socket

These commands wake up a web server, which you can access with the Cockpit computer's IP address on local network port 9090 by entering https://192.168.2.3:9090 in a browser. Cockpit automatically generates a certificate for encrypted HTTPS connections.

To let all the admins on the network access the Cockpit server, you might need to modify your local firewall settings. On Fedora and CentOS, you can use the commands:

# firewall-cmd --add-service=cockpit
# firewall-cmd --reload

If you want to generate your own certificate or already have a suitable *.cert file, you can store it in /etc/cockpit/ws-certs.d/ as an alternative.

Secure Login

To log on to the system, you will usually have an account with administrative privileges (root or admin) and a password. Logging on as a non-privileged user is also possible, but you won't be able to change system settings. For single sign-on authentication, Cockpit can be teamed with Kerberos. Cockpit 118 also introduced two-factor authentication, including the use of YubiKeys.

The first system view after logging in is an overview that provides information about the server. The web interface also lets you manage other servers in this view. The primary server [5] on which an SSH daemon and the Cockpit web service (cockpit-ws) runs controls and monitors other machines over SSH connections.

Each of these secondary servers runs a Cockpit Bridge, which the primary computer controls over the aforementioned SSH connections. The bridges forward the commands and messages called by the admin in the web-based user interface to the servers by making extensive use of D-Bus and numerous systemd services.

Adding Servers

Further servers can be configured either from the graphical interface or with text files in JSON format [6] stored in the /etc/cockpit/machines.d/ directory. A configuration file would resemble Listing 1: "address" can be either the IP address or the DNS name of the computer that Cockpit manages. These entries are required; all others are optional.

01 {
02   "fedora-hc1.reschke.lan": {
03     "address": "192.168.2.17",
04     "visible": true,
05     "color": "green",
06     "user": "root"
07   },
08   "web server": {
09     "address": "192.168.2.4",
10     "visible": true,
11     "color": "rgb(100, 200, 0)",
12     "user": "admin"
13   }
14 }

The "visible" boolean parameter determines whether a server is visible in Cockpit. The "user" entry typically refers to "root" or "admin", as mentioned earlier. Because Cockpit accesses other machines over SSH, port 22 is the default. You can change this port, too, if necessary.

To distinguish the machines, you can also assign them different colors, changing how they are displayed in Cockpit. The ability to highlight subnets in different colors make them easier to distinguish for management tasks.

System Insights

The dashboard (Figure 1) provides a quick overview of CPU usage, memory consumption, and the status of other hardware components. Here, you can add more servers or edit the existing ones by clicking the plus symbol. You can toggle back and forth between the configured servers quite quickly. If no user name is specified, Cockpit prompts you for one during the login process. If errors occur, messages to that effect are displayed.

On the left side, the Cockpit's graphical web interface lists the existing or installed services and applications. Admins can see a wide variety of parameters. The Logs section contains error messages from the connected machines. You can filter error messages by Severity, with a choice of Everything, Critical, Notice, or Debug. When you click on such a message, additional details are displayed.

The Storage entry takes you to a central display that you can use to keep track of hard drive read and write speeds. You can also check out an overview of mounted mass storage devices with their partitions and remaining capacity. Another area shows data about existing NFS mounts. This section also usefully provides logfiles from the mounted storage systems.

In the Networking section, Cockpit tells you about the current network throughput on a server, also detailing the configured firewall rules, which you can edit. The network interfaces are also shown, including details about MTUs or IPv4 and IPv6 support.

New: Virtual Machines

One of the new features in Cockpit since the last article is the Virtual Machines option, where you can create and manage virtual machines. Under the hood, Cockpit relies on KVM/Qemu, and Libvirt. To use this feature, you also need to install the cockpit-machines package and set up the Libvirt daemon:

# dnf install libvirt cockpit-machines
# systemctl enable libvirtd --now
# systemctl enable cockpit.socket --now

Once the service is running, you can set up a new virtual machine by pressing the Create New VM button. Managing virtual machines in Cockpit offers a central advantage over the Virtual Machine Manager (virt-manager): You do not need a graphical interface on the server, which is probably one of the reasons Cockpit replaced virt-manager in Fedora, RHEL, and CentOS [7].

In the Pod

Wherever you find virtual machines, you normally don't have to look hard to find containers. The Podman Container section (Figure 2) is where Cockpit groups various options for Red Hat's variant of Docker. Unlike Docker, Podman doesn't use root privileges or a central daemon; otherwise, it is compatible with Docker.

The user interface in Cockpit makes using Podman even easier. Pressing the Get new image link provisions Docker images from the official repository. In the example in Figure 2, I installed the Nextcloud image from Own Your Bits [8].

Various services can be started and stopped from the Services sidebar item. Updates lets you check for new updates for the packages that make up Cockpit; further modules for Cockpit can be installed in Applications. The tools include the Image builder extension [9], which admins should be able to use to create image files (e.g., an Anaconda boot image or Live CDs). For reasons hitherto unknown, this feature did not work in our lab.

Even though admins can complete some tasks in the intuitively designed interface, you still have to switch to a terminal from time to time. Thankfully, Cockpit also comes with a terminal, found in the Terminal section on the left side of the web interface.

Conclusions

Cockpit turns out to be a practical collection of server management tools and understands how to leverage the capabilities of distribution standards like D-Bus and systemd. The software has been mature for some time, but the development team behind it is constantly expanding the tool and adding new features. The source code for the project is available from GitHub [10].