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
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Latest Cinnamon Desktop Releases with a Bold New Look
Just in time for the holidays, the developer of the Cinnamon desktop has shipped a new release to help spice up your eggnog with new features and a new look.
-
Armbian 24.11 Released with Expanded Hardware Support
If you've been waiting for Armbian to support OrangePi 5 Max and Radxa ROCK 5B+, the wait is over.
-
SUSE Renames Several Products for Better Name Recognition
SUSE has been a very powerful player in the European market, but it knows it must branch out to gain serious traction. Will a name change do the trick?
-
ESET Discovers New Linux Malware
WolfsBane is an all-in-one malware that has hit the Linux operating system and includes a dropper, a launcher, and a backdoor.
-
New Linux Kernel Patch Allows Forcing a CPU Mitigation
Even when CPU mitigations can consume precious CPU cycles, it might not be a bad idea to allow users to enable them, even if your machine isn't vulnerable.
-
Red Hat Enterprise Linux 9.5 Released
Notify your friends, loved ones, and colleagues that the latest version of RHEL is available with plenty of enhancements.
-
Linux Sees Massive Performance Increase from a Single Line of Code
With one line of code, Intel was able to increase the performance of the Linux kernel by 4,000 percent.
-
Fedora KDE Approved as an Official Spin
If you prefer the Plasma desktop environment and the Fedora distribution, you're in luck because there's now an official spin that is listed on the same level as the Fedora Workstation edition.
-
New Steam Client Ups the Ante for Linux
The latest release from Steam has some pretty cool tricks up its sleeve.
-
Gnome OS Transitioning Toward a General-Purpose Distro
If you're looking for the perfectly vanilla take on the Gnome desktop, Gnome OS might be for you.