Server administration using Cockpit
Control Center
Cockpit [1] lets you manage a remote Linux system through a browser window. An administrator can take a look at the systemd journal, check the load, and start and stop services. Thanks to responsive design, the user interface automatically adapts to different screen sizes which, in turn, facilitates easy access via smartphones.
You can also easily switch to the command line, start web servers there, and create new user accounts at any time. They then appear in the web application, and you can use them to manage multiple Linux systems. To this end, just draw attention to Cockpit on the remaining servers, on which the software must also be running.
This functionality makes Cockpit – developed by Red Hat – similar to the well-known Webmin [2]. The user interface which, according to self-promotion, is easy to use and "very lightweight" especially appeals to less experienced administrators. However, Cockpit is also suitable for managing a home server or smaller business networks. Users should not mistake the tool licensed under LGPL 2.1 for the similarly named openITCOCKPIT [3].
All Inclusive
Red Hat has not even been working on Cockpit for a full two years. The work on it can now be done openly on GitHub [4], but those who observe the project will note its closeness to Red Hat (e.g., the distribution used). Also, Fedora 21 Server, CentOS Atomic, and RHEL Atomic are already preinstalling the tool for server management. Fedora 21 Workstation and Arch Linux only have finished packages. In Fedora 21 Workstation, the command
yum install cockpit
installs the control center.
Users of Arch Linux can install the cockpit package via the Arch User Repository (AUR). The Cockpit version accompanying Fedora 21 still reports as version 0.27 from autumn 2014, although the current version was already 0.52 at the time of writing. However, except for cosmetics, it has not particularly changed.
Those who want to use a different distribution, such as Ubuntu or Debian, will need to compile the source code themselves. Because Cockpit is strongly attached to Fedora, and especially systemd, commissioning turns out to be only a small hurdle. You first need to collect the numerous dependencies in the cockpit.spec
file. The "Vivid Vervet" box describes how to compile the software for Ubuntu 15.04.
Cockpit cannot even be put into operation on distributions without systemd. This relates to earlier versions of both Ubuntu and Debian systems up to and including version 7. Those who manually installed Cockpit must finally start it using the systemctl
systemd tool:
systemctl enable cockpit.socket systemctl start cockpit.socket
This happens automatically in Fedora 21 Server, CentOS Atomic, and RHEL Atomic.
Access
Cockpit can be accessed via HTTPS through the browser on TCP port 9090. If, for example, the server has the IP address 192.168.100.11, you can accordingly call up the URL https://192.168.100.11:9090, although you might sometimes still need to drill a hole in the firewall. In Fedora 21 Workstation, this is applied by two commands:
firewall-cmd --reload firewall-cmd --add-service=cockpit
The firewall in Fedora 21 Server innately accepts connections on port 9090. You should especially bear this in mind if you want to prevent access to Cockpit. Those who prefer a different port must customize the ListenStream
setting in the configuration file cockpit.socket
designated for systemd. This file is usually located in the /usr/lib/systemd/system/
folder; systemd must then apply the changes:
systemctl daemon-reload systemctl restart cockpit.socket
Cockpit forces a secure connection via HTTPS and automatically redirects the HTTP request. A self-signed certificate is used here, which the operator must accept when first accessing Cockpit in the browser. Access to the server itself via http://localhost:9090 is an exception. Here, Cockpit also allows unencrypted connections.
If you want to use your own certificate, you must store it as a cert
file with precisely this extension in the directory /etc/cockpit/ws-certs.d
. If there are multiple certificates, Cockpit always uses the first file in alphabetical order. The certificate a.cert
is therefore preferred over z.cert
. If there is no certificate in the said directory, Cockpit automatically creates one. A self-signed certificate /etc/cockpit/ws-certs.d/~self-signed.cert
is enclosed with Fedora 21.
Cockpit encrypts communication with the browser via TLS and current encryption methods. The standards SSLv3.0 and RC4, which are considered insecure, are disabled.
Logging On
You can log on to Cockpit using the same username and password pair you use to log directly onto the server. If the managed Linux system prevents you from setting up a user account, for example, Cockpit will also block this action. For full access to the system, the system administrator must therefore approach Cockpit as a root user.
At the Control Stick
On its homepage, Cockpit shows you all the servers with which it is familiar (Figure 1). Immediately after installation, this is only the server on which Cockpit is running. At this point, however, newer versions of Cockpit always present information about the server.
The server selection is hiding behind the Dashboard (Figure 2). The server operator can add additional machines via Add Host – or via the plus symbol in the newer versions. To do this, Cockpit needs only the server's IP address or hostname and the administrator's username and password. The software then responds with this information on the new machine and requests the required information. If an errors occurs, but there is no error message, the server is then simply missing in the list.
Select the server to be controlled by clicking on the corresponding line (localhost in Figure 1 ). Cockpit now provides updated information on the utilization of the most important hardware components every second (Figures 3 and 4). The menu on the left provides access to all the important functions and actions. For example, clicking Journal provides insight into the systemd journal, and you can manage user accounts under Tools | Administrator Accounts (Figure 3) or User Accounts (Figure 4).
Cockpit keeps a breadcrumb bar in the black bar at the top of the page: Clicking one of the items leads back to the corresponding page. The list with all the servers is waiting behind Hosts (Figure 4) or Dashboard (Figure 3).
Function Queue
The user interface does not always make it clear which items can be clicked. If you access the Networking entry in the main menu, it is only possible to create a bonding, a bridge, or a new VLAN via the corresponding buttons.
The remaining indicators provide information about the received and transmitted packages and the status of individual network interfaces. They can, however, also be clicked in the Interfaces list. There, you can then disable them (among other things) and set up the IPv4 and IPv6 addresses (Figure 5).
All the settings are self-explanatory; the possible actions are also very limited. You are, for example, neither allowed to view the user groups nor specifically assign groups to user accounts. However, you can fall back on the terminal in such cases. All maintenance work performed there is immediately reflected in Cockpit. A user account created by adduser
appears shortly afterward behind the User Accounts entry (Figure 6).
If you want to shut down or restart the server, in Fedora 21 call up the Hosts point. Or, in a current version of Cockpit, make your way to the corresponding server via the Dashboard. Either way, you will now discover a drop-down box – on the right-hand side in Fedora 21 and next to Power Options in current versions of Cockpit. In this way, you will reach the two functions.
Lifeline
A Rescue Terminal can also be opened in Fedora 21. In current versions of Cockpit, you need to call up Tools | Terminal. Cockpit then opens a shell within its own user interface; the shell can then be used to access the server directly. After finishing the work, you should log out again by clicking on an entry below your username at the top right.
Under the Hood
Cockpit itself consists of several components (Figure 7); the cockpit-ws
service launched by systemd supplies the switchboard. The ws
stands for web server. It delivers the web application to the browser and controls the remaining tools. In doing so, however, cockpit-ws
is not just permanently in the background; in fact, systemd listens to port 9090 and only automatically activates the web server when trying to establish a connection.
The cockpit-ws
service starts the cockpit-bridge
service as soon as you log on. This, in turn, communicates with systemd, the network manager, and other system components via the D-Bus interface. Docker and Kubernetes, which Cockpit controls via REST, are exceptions.
Whereas cockpit-ws
works using root privileges, cockpit-bridge
runs with normal user rights. In older versions of Cockpit, the service cockpitd
was used instead of cockpit-bridge
. This applies in particular to version 0.27, which came with Fedora 21.
A few other auxiliary programs are available besides cockpit-ws
and cockpit-bridge
. For example, Cockpit uses cockpit-session
and PAM to authenticate the user and to initiate a corresponding session.
If you register another server in the web interface, cockpit-ws
establishes contact with it via SSH. cockpit-ws
then directs the cockpit-bridge
running on the other server using the secured SSH connection. However, this procedure requires both that Cockpit is installed on each server and that an SSH daemon constantly listens to port 22.
Note that cockpit-ws
automatically terminates after 10 minutes of inactivity. If port 9090 is then accessed again, systemd starts the web application again. Alternatively, you can manually call up Cockpit via /usr/libexec/cockpit-ws
in Fedora 21.
Furthermore, a suitable systemd service called cockpit.service
can be used to shut down or restart Cockpit. If you stop the service, you should close the socket; otherwise, systemd will automatically start up Cockpit again if a connection is (accidentally) established:
systemctl stop cockpit.socket cockpit
If you delve more deeply into the structure of Cockpit and want to supplement the user interface with additional functions, you should take a look at the Developer Guide [7]. An updated version is enclosed with the source code in the subdirectory doc
[4].
Conclusions
You can easily manage one or more servers using Cockpit. Those who can deal with Gnome's system settings will find their way in Cockpit, too. Unlike its competitor Webmin, Cockpit focuses on Linux systems. You need to set up additional applications such as an Apache web server manually.
Additionally, Cockpit is currently strongly tailored to Fedora and especially systemd. Users should therefore at least have superficial knowledge of the init system and its concepts. By focusing on a few system components, however, Cockpit is able to work more reliably and, above all, shine with a consistent, uncluttered user interface. Like all web applications, however, Cockpit opens a new port on the server, which is in principle a security risk.