Managing servers with the Cockpit admin tool
From the Cockpit
Meet Cockpit, an easy management tool that lets you watch your Linux servers from a convenient, web-based interface.
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).
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).
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").
Theory vs Practice
I've found that the tool and the docs don't always match. For example, the website says that you may set a LoginTitle
variable to the browser title for the login screen and a Banner
variable to display the contents of a given file (/etc/issue
by default) as a welcome or information message on the login page.
On my Ubuntu system, however, none of the values I gave to those variables seemed to have any effect. This might be a bug that the team has already solved by the time you read this. For what it's worth, I had the feeling that Cockpit is so usable out of the box that, paradoxically, bugs of this kind may remain unseen for long periods, exactly because almost nobody needs to change the default values.
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
-
Halcyon Creates Anti-Ransomware Protection for Linux
As more Linux systems are targeted by ransomware, Halcyon is stepping up its protection.
-
Valve and Arch Linux Announce Collaboration
Valve and Arch have come together for two projects that will have a serious impact on the Linux distribution.
-
Hacker Successfully Runs Linux on a CPU from the Early ‘70s
From the office of "Look what I can do," Dmitry Grinberg was able to get Linux running on a processor that was created in 1971.
-
OSI and LPI Form Strategic Alliance
With a goal of strengthening Linux and open source communities, this new alliance aims to nurture the growth of more highly skilled professionals.
-
Fedora 41 Beta Available with Some Interesting Additions
If you're a Fedora fan, you'll be excited to hear the beta version of the latest release is now available for testing and includes plenty of updates.
-
AlmaLinux Unveils New Hardware Certification Process
The AlmaLinux Hardware Certification Program run by the Certification Special Interest Group (SIG) aims to ensure seamless compatibility between AlmaLinux and a wide range of hardware configurations.
-
Wind River Introduces eLxr Pro Linux Solution
eLxr Pro offers an end-to-end Linux solution backed by expert commercial support.
-
Juno Tab 3 Launches with Ubuntu 24.04
Anyone looking for a full-blown Linux tablet need look no further. Juno has released the Tab 3.
-
New KDE Slimbook Plasma Available for Preorder
Powered by an AMD Ryzen CPU, the latest KDE Slimbook laptop is powerful enough for local AI tasks.
-
Rhino Linux Announces Latest "Quick Update"
If you prefer your Linux distribution to be of the rolling type, Rhino Linux delivers a beautiful and reliable experience.