I am going to open this blog post with a confession: I like systemd. In fact, I prefer it over SysV and upstart init systems on Linux.
It feels good to have that admission up front and in the open. If systemd isn’t something you like or have time for, then this post will have very little relevance to you. If, however, you’re using systemd, or simply interested in learning more about it then read on (especially if you’ve not heard about, or seen the Red Hat Enterprise Linux web console in action).
The Red Hat Enterprise Linux web console is an open source project called Cockpit that provides a user-friendly web interface allowing for the remote administration of servers. For the purposes of this blog, I’ll be using Red Hat Enterprise Linux 7.4 as the basis of all examples unless otherwise stated. Being a web console, this also means that it is equally easy to use on mobile devices as well.
Starting with Red Hat Enterprise Linux 7, the cockpit package provides a powerful and extensible web console for system administration. I like to equate the Red Hat Enterprise Linux command line interface (CLI) to the major cloud providers software development kit CLIs, and by extension equate Cockpit to the cloud providers’ web front ends.
As per my opening confession, it is important to be aware that the Cockpit project is strongly integrated with systemd. The systemd DBus APIs drive the services and logs pages, as well as providing the majority of the functionality of the system information page. Given this reliance on systemd, any porting to Red Hat Enterprise Linux 6 would offer significantly reduced functionality and, currently, there are no plans for a Red Hat Enterprise Linux 6 version.
Starting with a minimal installation of Red Hat Enterprise Linux 7, the cockpit package and dependencies are not installed by default, however, it is a simple install from the rhel-7-server-rpms repository.
[root@rhel-test ~]# yum install -y cockpit … Installed: cockpit.x86_64 0:138-10.el7_4 Dependency Installed: cockpit-bridge.x86_64 0:138-10.el7_4 cockpit-system.noarch 0:138-10.el7_4 cockpit-ws.x86_64 0:138-10.el7_4 json-glib.x86_64 0:1.2.6-1.el7
The installation has brought in some dependencies, and has installed the cockpit service, which I’ll start using the systemctl command:
[root@rhel-test ~]# systemctl start cockpit [root@rhel-test ~]# ps uaxwww | grep cockpit cockpit+ 1886 0.0 0.4 174656 4644 ? Ssl 09:13 0:00 /usr/libexec/cockpit-ws root 1891 0.0 0.0 112660 972 pts/0 S+ 09:14 0:00 grep --color=auto cockpit [root@rhel-test ~]# netstat -tunap | grep cockpit [root@rhel-test ~]# netstat -tunap | grep 9090 tcp6 0 0 :::9090 :::* LISTEN 1/systemd
As the output above demonstrates, the cockpit service can be started via the usual systemctl command, which executes the cockpit-ws binary – the ‘ws’ is the ‘web service’ component of Cockpit. However, looking at the output from netstat, we can see that it is actually systemd that is listening on port 9090. Port 9090 is the well known “websm” or “Web System Manager” IANA port.
One of the goals of the Cockpit project is to have a minimal footprint and be as lightweight as possible. Therefore, it makes sense that the cockpit service is run on-demand. This is achieved by having systemd listen to a TCP socket and start the cockpit web service on-demand when a connection is made to this socket. The correct method to enable the service at boot is:
[root@rhel-test ~]# systemctl enable cockpit.socket Created symlink from /etc/systemd/system/sockets.target.wants/cockpit.socket to /usr/lib/systemd/system/cockpit.socket.
As a result, following a reboot, we have the following netstat output:
[root@rhel-test ~]# netstat -tunap | grep 9090 tcp6 0 0 :::9090 :::* LISTEN 1/systemd [root@rhel-test ~]# ps auxwww | grep cockpit root 1918 0.0 0.0 112660 972 pts/0 R+ 09:29 0:00 grep --color=auto cockpit
As can be seen, systemd is listening on port 9090, however, the cockpit-ws binary is not running. Since we have enabled the systemd cockpit.socket and it is listening on TCP port 9090 the Cockpit web service will be started on demand when a connection is made to port 9090.
Further to the above: If I use the traditional systemctl enable cockpit command, the cockpit service will not automatically start on server boot as you might expect:
[root@rhel-test ~]# systemctl status cockpit ● cockpit.service - Cockpit Web Service Loaded: loaded (/usr/lib/systemd/system/cockpit.service; static; vendor preset: disabled) Active: inactive (dead) Docs: man:cockpit-ws(8) [root@rhel-test ~]# ps uaxwww | grep cockpit root 1463 0.0 0.0 112660 976 pts/0 R+ 09:21 0:00 grep --color=auto cockpit
As the title of this blog indicates, I’m administering Red Hat Enterprise Linux via the web console, so from this point on, most of the interaction will be via a web browser. However, I need to also open the firewall to allow traffic on port 9090, so there is one final piece of command line administration required:
[root@rhel-test ~]# firewall-cmd --add-service cockpit success [root@rhel-test ~]# firewall-cmd --add-service cockpit --perm Success
Let’s connect to the Red Hat Enterprise Linux web UI service:
As seen from the image, Firefox has presented a warning that the connection is not secure. This has been presented because, by default, the Cockpit web service will use a self-signed certificate, and we must instruct Firefox to trust this certificate. Once that is done we are presented with the web console login screen. All interaction via the web console is performed over encrypted connections, and we can create and use certificates signed by an external authority.
This is a useful feature for enterprises that have their own internal CA that is pushed out as a trusted CA to the browsers in use, which would avoid the certificate warning being presented when Cockpit is configured to use a certificate signed by the same CA. Place such server certificates in the /etc/cockpit/ws-certs.d/ directory.
The login credentials are the same as those that you would use to login to a server console or via SSH. There is no separate user accounts database to use the web console as it is intended to be tightly integrated with the operating system.
As per the image, I’m logging in using a user account named ‘server_admin’. The server_admin user is a user I have created and added to the ‘wheel’ group. I have also checked the ‘Reuse my password for privileged tasks’ checkbox, to provide an experience that is equivalent to using the sudo utility ensuring a similar workflow that CLI administrators would be used to. Using the web console is therefore similar to a text console and there is no hacked workaround or black box making this work. As you would expect, authentication is managed by a Cockpit specific pam stack at /etc/pam.d/cockpit.
Once logged in, I am presented with the following screen:
From the default install, I am able to perform a significant amount of local system administration. The initial ‘system’ screen provides an overview of current system performance metrics such as CPU, memory, disk, and memory utilization (highlighted in green). It’s also possible to alter the tuned performance profile – in the above screenshot, my server is currently running the virtual-guest profile (highlighted in orange). The area highlighted in purple at the top right displays the logged in username, and in this instance indicates that the session is unlocked, as the re-use password for privileged tasks option had been selected during login.
I am also able to select items on the left-hand side for further administrative functionality such as reviewing logs (highlighted in light blue). Using systemd provides a view of the journald logs with easy filtering options (highlighted in purple):
I’m not going to fill this blog post with screenshots of every piece of functionality – that is a task I will leave to the reader to perform on a test system. The subsections on the left-hand side of the screenshot should demonstrate the ability to administer the networking configuration, local user accounts, managing services, generating an sosreport, configuring the kdump service, managing SELinux, and checking the subscription status. There is also the capability to run a terminal command line as the logged in user.
According to the Cockpit project website, another of the ideals of Cockpit is that it is pluggable which means functionality can be extended by additional plugins. Within Red Hat Enterprise Linux 7.4 there are some further plugins available that are not installed by default.
[root@rhel-test ~]# yum install -y cockpit-packagekit cockpit-pcp cockpit-storaged
With the above command, I’ve installed the plugins for packagekit, pcp, and storaged. This extends the web console options to also provide the ability to administer software updates, performance metric logging, and the storage on the server. Logging out and logging back into the web console presents these new options.
The cockpit-pcp plugin has added the option to store the performance logs – it is possible to view the performance metrics in this interface up to one year previous, so long as the data has been stored. As its name suggests this plugin is utilizing the functionality brought by performance co-pilot (pcp).
Additional options on the left-hand menu have also been added allowing storage administration using the storaged subsystem, and software updates can also be checked and installed from the ‘Software Updates’ section. For complete functionality, this plugin requires that the server is subscribed to a Red Hat Satellite server or to the Red Hat Subscription Manager service.
These additional plugin packages are installed from the extras channel to reflect that they may be updated more regularly than packages in the ‘standard’ rpms channel.
So far, I have connected to and worked on a single server. While the functionality demonstrated is impressive, the cockpit-dashboard plugin allows connection to remote servers. One such use case, very common in public cloud deployments, is that of a publicly accessible bastion host that can be accessed remotely by the system administrator and then used to connect to additional hosts in private subnets. This provides the system administrator the ability to manage a private host over a more secure connection.
[root@rhel-test ~]# yum install -y cockpit-dashboard
Once again, logging out and logging in presents the web console interface, this time with the dashboard plugin activated.
The change here is that we now have the ‘Dashboard’ option above the general system information that is presented. Otherwise, the information and options remain the same. Selecting the dashboard will provide a tabbed display of the performance metrics that we’ve already seen, however, it also provides the ability to connect to other hosts and retrieve and display the same information from those hosts.
In this screenshot, I have added an additional server called icarus to the dashboard – the screen capture is displaying the CPU performance metrics for both the original server (blue line) and the new server (green line). The connection is made over SSH, and whilst setting up the connection, I have chosen to synchronize the server_admin username and password from rhel-test to icarus, and this has created the user server_admin on the server named icarus.
Selecting my newly added server I am then presented with the now familiar web console screen, this time displaying information for the server name icarus.
The above screenshot demonstrates that my web browser is connected to the server named rhel-test, although I am actually viewing the data from icarus. The green bar to the left is consistent with the green lines displayed on the dashboard. The server name is also now a drop down giving the user an easy option to switch between servers.
The server named icarus also has the cockpit-docker plugin installed, which provides the ‘Container’ option on the left-hand side list of plugins. The web console interface can, therefore, provide an easy to use interface for spinning up containers on the Red Hat Enterprise Linux host.
Cockpit is also heavily featured in Red Hat Enterprise Linux Atomic Host providing an easy-to-use front end for the Atomic hosts and the containers they host. Likewise, Red Hat Virtualization also employs specific plugins to allow for management of Red Hat Virtualization hypervisors and setting up and managing the hosted engine service. Red Hat CloudForms uses the Red Hat Enterprise Linux web console to easily jump to the selected Red Hat Enterprise Linux host. Features are being developed and added to Cockpit regularly, with the Cockpit blog being a great source of information.
Although this blog has concentrated on the Red Hat Enterprise Linux web console, Cockpit is not just limited to Red Hat Enterprise Linux other distributions are following suit and making Cockpit packages available. It should be no surprise there are Cockpit packages available for CentOS and Fedora. However, there are also Cockpit packages available for Ubuntu, Debian, openSUSE, and ArchLinux and they provide similar functionality allowing for a unified administrative view in environments with multiple distributions installed.
Above is a Cockpit screenshot from a Debian 9 installation running on a Raspberry Pi system.
Above is a web console screenshot from a Fedora 26 system. The Fedora packages also include plugins to manage virtual machines running on the host and this particular host also has the ‘Fleet Commander’ plugin installed which, in the future, will provide the ability to centrally administer and manage a fleet of Fedora desktop systems. On this host, there is also an additional option at the top, ‘Cluster’ which is used to manage Kubernetes clusters.
Cockpit provides a flexible and powerful web console to administer Red Hat Enterprise Linux 7 servers with an extensible framework allowing it to extend beyond base functionality and reach multiple servers. The dashboard functionality allowing one server to be configured as a ‘bastion host’ and connecting to many more servers in a more secure fashion integrates well with cloud deployments which more customers are deploying.
In my opinion, the combination of ease of use and intuitiveness of Cockpit, with the flexibility of systemd should be a strong reason to consider upgrading Red Hat Enterprise Linux 6 servers to Red Hat Enterprise Linux 7.
If this article has whet your appetite for further details on the Red Hat Enterprise Linux 7 web console, then please contact your Red Hat TAM or account manager and they’ll be happy to help.
Jonathan Ervine is a TAM from Hong Kong. He provides support to enterprise customers in the financial, logistics, and technology sectors in the APAC region. Recently, Jonathan has helped his customers deploy private cloud infrastructure and maintain their existing platform deployments on a supported platform. Learn more about Jonathan.
A Red Hat Technical Account Manager (TAM) is a specialized product expert who works collaboratively with IT organizations to strategically plan for successful deployments and help realize optimal performance and growth. The TAM is part of Red Hat’s world-class Customer Experience and Engagement organization and provides proactive advice and guidance to help you identify and address potential problems before they occur. Should a problem arise, your TAM will own the issue and engage the best resources to resolve it as quickly as possible with minimal disruption to your business.
Connect with TAMs at a Red Hat Convergence event near you! Red Hat Convergence is a free, invitation-only event offering technical users an opportunity to deepen their Red Hat product knowledge and discover new ways to apply open source technology to meet their business goals. These events travel to cities around the world to provide you with a convenient, local one-day experience to learn and connect with Red Hat experts and industry peers.