What to Do with Cockpit

Cockpit lets you monitor, analyze, and configure Linux systems running Cockpit, as well as any container or virtual machines they host.

You get a quick, dynamic overview of the performance of all the systems in which you log in from the browser, and all are immediately reachable from the menu. Figures 4 and 5 show examples of the hardware performance diagrams and the storage management interface, which summarizes the status of all devices and partitions. All the charts created by Cockpit have a very clean style and, in my experience, their continuous refresh never slows down the browser. Figure 6 shows an equally clean summary of system logs.

Figure 4: The performance charts in the system section of a Cockpit control panel. The peaks in disk I/O and network traffic shown in the two bottom charts are due to the download of an ISO image.

Figure 5: The Cockpit server menu (left) and default storage panel layout, in privileged mode, showing partition and devices statuses, disk accesses (top), and storage logs (bottom).

Figure 6: Cockpit displays a summary of system logs.

In addition to its support for monitoring, Cockpit also lets you create and launch Linux or FreeBSD virtual machines and Docker containers, update software, manage LVM volumes, and define systemd timers to automatically run programs at specified times. You can also configure, stop, and restart system services or network interfaces. All the corresponding panels are basically visual representations of the main options you normally have at the command line, so I will not describe them in detail.

By default, the Cockpit charts only display the present status of a computer. By displaying the present status, the charts can give immediate, albeit qualitative feedback of what happens to your local or remote server if its load suddenly changes (e.g., if you start updating packages or uploading files). It is possible to enable persistent metrics by enabling an optional module, but this operation is distribution-dependent.

The Cockpit embedded terminal is visible in Figure 7. The terminal gives you a secure SSH session into any remote Linux box running Cockpit. Unless you block access, that SSH access will be possible even when you are borrowing someone's non-Linux computer or working from a public Internet kiosk. (You'll need to decide for yourself if an Internet kiosk is secure enough for what you are doing.)

Figure 7: The Cockpit embedded terminal, connecting via SSH to a server running Cockpit.

The most important thing to say about the terminal option is that you can use it when and how you want. The very fact that Cockpit is nothing more than a graphical intermediary between its user and a command prompt means that you can move back and forth between the Cockpit terminal and Cockpit GUI any way you want. Even the error messages you type in the terminal will show up in the Cockpit journal.

Managing Multiple Servers

Another feature of Cockpit that I like a lot is shown in Figure 8: the possibility to use a local copy of the software to manage any remote Linux machine, as long as it also runs Cockpit. In Figure 8, the Cockpit dashboard in the browser is connected to the Cockpit instance listening on port 9090 of the local machine that runs Ubuntu (see detail 1), but this instance can also control a remote CentOS server and display its performances in real time.

Figure 8: One Cockpit dashboard controlling two servers.

All the servers controlled from one Cockpit installation are listed in its dashboard. To add a server, click on the plus button of the dashboard (detail 2 of Figure 8) and add the server address in the pop-up window (Figure 9). Use the following syntax:

servername:portnumber

Figure 9: To add another server to the Cockpit dashboard, enter its name, SSH port number if needed, and a color for its graphs.

The optional port number refers to the number of the SSH port for that server, if it is different from the default value of 22. Please note that this procedure only works if you log into Cockpit with escalated privileges.

This scenario is also the main exception to the design rule that Cockpit does not store server data. With the exception of passwords, which, as far as I can tell, you have to retype every time, the parameters that are needed to connect to servers are stored in one JSON file in the /etc/cockpit/machines.d folder in the following format:

{
  "SERVER_NAME" : {
    "visible" : true,
    "color" : "rgb(103, 211, 0)",
    "user" : "USERNAME",
    "port" : "SSH_PORT_NUMBER",
    "address" : "ADDRESS"
  }
}

The ADDRESS can be either a domain name or a numeric IP address. The SSL certificates and keys needed for secure connections are, instead, stored inside the other Cockpit folder you need to back up regularly, /etc/cockpit/ws-certs.d.

Using Cockpit Securely

Making a server manageable from the Internet increases its exposure to attacks. As far as Cockpit is concerned, you can sensibly reduce that exposure in two simple steps.

One thing I really dislike about Cockpit is that, by default, it bypasses one basic security practice for SSH connections, which is "NO direct SSH logins with the root account!" The idea is that whoever wants to do root work using SSH should first log in with a normal account and then switch to root. In Cockpit, this barrier is bypassed, but the way to restore it is easy, though not well documented [12]. On each server where you want to forbid direct root logins via Cockpit, add the following setting:

auth requisite pam_succeed_if.so uid >= 1000

as the first line in the file /etc/pam.d/cockpit. This tells the Linux daemon for Pluggable Authentication Modules (pam.d) to refuse login requests from all privileged accounts that have numeric identifiers (uid) below 1000 (root's uid is zero).

The other step to reduce the exposure of a Cockpit-managed Linux server is what the Cockpit documentation calls the bastion host model. To begin with, configure the firewall of the host(s) where Cockpit runs to block external connections to the TCP port number 9090. On CentOS, these are the commands that would permanently close that port, and immediately apply the following configuration change without rebooting the system:

#> firewall-cmd --permanent --zone=public --remove-service=cockpit
#> firewall-cmd --reload

The trick here is these actions only block remote connections. Closing port 9090 on a computer does not prevent a browser and a Cockpit instance that both run on that same computer from communicating. Couple that with the fact that two Cockpit instances can directly, securely talk to each other through the same SSH port that should remain open anyway, and the problem is solved: A Cockpit instance running on your local computer will be all you need to control any other Cockpit-enabled server where you have an account. In Figure 10, the browser is connected to the local copy of Cockpit on the local Ubuntu desktop (detail 1). The Cockpit of the remote CentOS server is not reachable in the same way with a browser because its port 9090 was closed (detail 2). However, that same server is reachable from the local Cockpit (detail 3).

Figure 10: One Cockpit instance, controlling a remote server whose Cockpit is unreachable by browsers.