Managing servers with the Cockpit admin tool
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.


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.)
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.
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

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).
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Direct Download
Read full article as PDF:
Price $2.95
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Find SysAdmin Jobs
News
-
LibreOffice 7.5 has Arrived and is Loaded with New Features and Improvements
The favorite office suite of the Linux community has a new release that includes some visual refreshing and new features across all modules.
-
The Next Major Release of Elementary OS Has Arrived
It's been over a year since the developers of elementary OS released version 6.1 (Jólnir) but they've finally made their latest release (Horus) available with a renewed focus on the user.
-
KDE Plasma 5.27 Beta Is Ready for Testing
The latest beta iteration of the KDE Plasma desktop is now available and includes some important additions and fixes.
-
Netrunner OS 23 Is Now Available
The latest version of this Linux distribution is now based on Debian Bullseye and is ready for installation and finally hits the KDE 5.20 branch of the desktop.
-
New Linux Distribution Built for Gamers
With a Gnome desktop that offers different layouts and a custom kernel, PikaOS is a great option for gamers of all types.
-
System76 Beefs Up Popular Pangolin Laptop
The darling of open-source-powered laptops and desktops will soon drop a new AMD Ryzen 7-powered version of their popular Pangolin laptop.
-
Nobara Project Is a Modified Version of Fedora with User-Friendly Fixes
If you're looking for a version of Fedora that includes third-party and proprietary packages, look no further than the Nobara Project.
-
Gnome 44 Now Has a Release Date
Gnome 44 will be officially released on March 22, 2023.
-
Nitrux 2.6 Available with Kernel 6.1 and a Major Change
The developers of Nitrux have officially released version 2.6 of their Linux distribution with plenty of new features to excite users.
-
Vanilla OS Initial Release Is Now Available
A stock GNOME experience with on-demand immutability finally sees its first production release.