From the Cockpit

Wouldn't it be wonderful if you could configure and control all your Linux systems from one friendly interface? More than twenty years ago, the answer to this wish was a project called Linuxconf [1], which stopped development in 2005 and is hardly missed. Linuxconf tried to do too much at once, too often in ways that clashed with the default management tools of most distributions. After Linuxconf came Webmin [2], which is still actively developed and useful; however, in my opinion, Webmin has a dated interface, and you need relatively good knowledge of Linux to use it properly.

The quest for a better admin tool led to the start of the Cockpit project [3] a few years ago. Cockpit is a free and open source, web-based interface for managing Linux systems. The official goals of the Cockpit project are to make "Linux servers usable by non-expert admins" and to make "complex Linux features discoverable" [4]. Cockpit is supported by Red Hat, but you can run it on any distribution. This tutorial explains how Cockpit works and how and why it might help you with simplifying and consolidating your Linux management tasks.

Advantages and Limits

The first thing to know about Cockpit is that it is not a configuration management system like Ansible [5] or Puppet [6]. You cannot tell Cockpit "I want all my Linux boxes to look like this" and then take a stroll while it executes your wishes. This limitation is also its strength, because Cockpit is deliberately light and therefore easy to use.

On the surface, Cockpit is clean, intuitive, and smooth, even in a browser with many other tabs open. The documentation says that graphical and interface designers are involved in the project, and it shows. The interface is much nicer than the standard, low-level Linux tools (Figure 1).

Figure 1: The Cockpit login screen to access the local computer on port 9090. Notice the "Reuse my password …" checkbox.

The Cockpit back end communicates with the Linux system it controls via systemd sockets [7]. Systemd sockets are connectors that do not use any memory when there is nothing to do but can activate a Cockpit component whenever it is needed.

By default, Cockpit does not store performance or status data, nor does it keep its own copy of the configuration for the computer it controls, except for the parameters necessary to connect with the computer.

Cockpit includes an embedded terminal that works over secure SSH connections. Another important benefit is the fact that one installation can control other remote machines that also run Cockpit, all from the same browser tab.

Cockpit has many capabilities that could potentially be of use to the average admin, but you might find that it is still useful even if you just need one or two of its functions.

Up Close

The Cockpit back end has three essential components. A component called cockpit-ws acts as something like a web server, talking with browsers through TCP port 9090, which is the port number reserved for web system manager services. Another executable program, called cockpit-session, takes care of authentication, using standard Linux mechanisms such as PAM or GSSAPI [8].

Once you are logged in, a component called cockpit-bridge creates and runs the cockpit session. Below the surface, Cockpit is just like any other ordinary session-based Linux tool (TTYs, X11, SSH, etc.); your login credentials, user privileges, SELinux settings, and other settings are exactly the same as if you had logged into the system from an ordinary prompt.

There is an exception, though. At a normal command prompt, you can always use sudo to run commands that require root privilege. The Cockpit graphical interface (not the embedded terminal), does not support a secondary authentication routine that would let you follow up a privileged command by entering your password. By default, if you click on any button corresponding to an operation that would require sudo, you get the error message (Figure 2). However, if you check the box labeled Reuse my password for privileged tasks in the Cockpit login screen (Figure 1), you allow Cockpit to transparently escalate your privileges when necessary. (Of course, this only works when your account is authorized to execute privileged commands through sudo.) Inside Cockpit, you can configure permission to execute root-level commands by selecting the Users tab and checking the box labeled Server Administrator (Figure 3).

Figure 2: Unless you check the "Reuse my password …" box at login, Cockpit will not allow you to execute sensitive, or potentially dangerous, actions.

Figure 3: Choose the Server Administrator role to configure the important parameters of Linux user accounts.

Cockpit Installation

Conceptually, the Cockpit installation procedure is very simple: first, install the Cockpit software, then configure the firewall to make that software accessible from the Internet. Next, point your browser to port 9090 of the computer, log in with your user account on the computer you are using, and start working. It is simpler than it sounds because all the steps are well supported and documented.

All images in this tutorial come from installation and usage of Cockpit on two Linux systems: a spare home desktop running Ubuntu 16.04 LTS and a CentOS 7.6 VPS that hosts some of my websites. One command was enough to get Cockpit running on the Ubuntu system:

#> sudo apt-get install cockpit

On the CentOS remote server, I had to type a bit more:

#> yum install epel-release
#> yum install cockpit
#> systemctl enable --now cockpit.socket
#> firewall-cmd --permanent --zone=public --add-service=cockpit
#> firewall-cmd --reload

The first command enables the EPEL repository that contains the Cockpit package for CentOS, the second installs it, and the third enables the socket that Cockpit will use to communicate with the system. The last two lines of that sequence change and reload the firewall configuration to make Cockpit accessible from the Internet.

These two installation examples show that the actual procedure depends on how Cockpit was packaged for each distribution; for instance, on CentOS, I had to explicitly enable the Cockpit socket. In practice, installation is very simple on all major Linux distributions because binary packages are available, and any extra commands you may need to type are well documented on the Cockpit website.

If you follow the documented procedures, Cockpit will be accessible from your browser without running any other server – at addresses like https://localhost:9090 if installed on your local computer or https://example.com:9090 on remote servers.

If you want, or need, to put Cockpit at different addresses, be it a subdomain like cockpit.example.com or a subfolder like example.com/cockpit, you'll need to hide Cockpit behind a web server like Apache or nGinx that acts as a reverse proxy, transparently relaying the traffic between Cockpit and the browsers of its users. You will find instructions and configuration files for this reverse proxy option online [9] [10] [11], but honestly, this configuration only seems worth it if the Cockpit installation must serve many different users without making any of them install any extra software. If one person wants to install and use Cockpit on several independent servers, a better solution is the multi-server approach I describe at the end of this article.

The Cockpit configuration file (/etc/cockpit/cockpit.conf) has a simple syntax, and all the options are described in the project documentation. However, I have experienced some discrepancies between the documentation and Cockpit's behavior in the wild (see the box entitled "Theory vs Practice").