In the course of my job at Red Hat, I work with a lot of servers. Many of them are a mix of reproducers for customer environments and production boxes. Some of these are dedicated boxes, but there are also plenty of virtual machines, and a few Docker instances. That means I need to view and manage a lot of server resources daily.
Fortunately there’s a great way to do that which is part of Fedora. Cockpit is an elegant, beautiful way to see and manage my servers using just a web browser. It’s open source, and it is quickly growing new features and capabilities all the time. Best of all, it’s part of Fedora already, and for example ships with the Fedora Server edition.
I fired up a Fedora 23 cloud server on Digital Ocean to see what Cockpit’s all about.
First I installed the cockpit package and its dependencies:
# dnf install cockpit
I was then prompted with a pretty login screen with the Fedora logo.
From here I logged in and was greeted with real-time stats of my cloud server:
I noticed I could perform all sorts of management tasks here, such as setting the hostname or restarting the system. From the Tools menu I could also add users, or call up a web terminal. So far I’m really liking this. It reminds me of Webmin, but it’s more powerful and attractive.
I then started exploring the other options. For instance, I can see all my logs from the systemd journal via journalctl. You can see the numerous drive-by SSH attempts since I spun up the server:
I don’t have Docker running on this virtual private server, but if I did, I could manage and see real-time stats of my containers:
Looking at the Storage tab, I’m able to see realtime statistics of activity on my disk. I even have the ability to create LVM or RAID setups on my connected storage.
I looked at the Networking tab, where I can see realtime info on my network traffic, per adapter. I can also add bonds, VLANs, and bridges:
I then looked at the Service tab which lets me view all my currently running services:
I can click on a service, which allows me to enable, disable, restart, stop, or start each service right from Cockpit. (If you don’t remember the differences, check out this Fedora Magazine article on systemd units.)
I’m pretty impressed by Cockpit, and I’m going to start installing it on some of my boxes to see how much it increases my productivity. Cockpit is available for Fedora, CentOS, and Red Hat Enterprise Linux.
Image courtesy Roger Schultz – originally posted to Flickr as Cockpit
Thank you for the article. Are you aware if in time cockpit will gain the capability to execute ‘root’ commands when logged in as a user with sudo access?
You can get a shell on there in a web page so you can do whatever your user has access to
yes, but the whole point was about using cockpit … i can not see for example all system logs in cockpit if i am not logged in as ‘root’.
I agree with this point, the point is to be able to manage items as root when logged in as a non-root user. Webmin and Usermin have had this ability for years. There are long established use cases and valid arguments for this feature.
Also, taking this a step further, it would be nice to have fine grained controls to give users without sudo privileges or even shell access certain permissions. Consider allowing a user (the person responsible for code deployment) permission via cockpit to log in and run only 1 command as root. That command may be your code deploy mechanism like capistrano.
Now the latter feature may be way down the road, but this is a valid use case and should not have to have full shell access. A web (cockpit) only user that an admin can allow that access would be ideal.
The article is a bit misleading when it says it uses journalctl (and thus you can think it wouldn’t be that much of a stretch to use “sudo journalctl” instead). AFAIK it actually uses the journal’s APIs, not the command line client (I could be wrong).
However, I think there is a more elegant solution here. If your user can use sudo journalctl (and I presume you have it setup to use it without an additional password entry), then you may as well just add your user to the system-journal group instead. This has pretty much the same effect but avoids the need to be root.
System journals are owned by this group by default and adding your user to the group should make everything “just work” in cockpit without any further configuration.
HTHs (and that I’m right!)
Cockpit wraps the functionality of journalctl and is therefore reliant on the authorization decisions that it makes. Here’s what journalctl(1) says:
“Members of the groups “systemd-journal”, “adm”, and “wheel” can read all journal files. Note that the two latter groups traditionally have additional privileges specified by the distribution. Members of the “wheel” group can often perform administrative tasks.”
So if you want to allow a non-root user to read the whole journal, add them to the “systemd-journal” group.
Thank you. I’ll try this.
Cockpit uses sudo and polkit for many operations that support them already. The use of each one is dependent upon the specific task. Generally, polkit gets used for tasks which have a D-BUS API and sudo is used for tasks that do not.
Logging is a special-case; see my other reply for that.
One of the major principles of Cockpit is that it doesn’t make any changes itself. Everything Cockpit does, it calls out to a system API which does the work (this makes it so that changes coming from Cockpit don’t take over the system like the system-config-* scripts used to or break down when you make a manual change outside of it).
Cockpit is indeed beautiful but one thing I’m missing is visualizing the steal time not just CPU load. This could be really helpful to debug “slow” VMs. Do you know if this is planned already?
I would also like to point out that the Cockpit upstream provides a COPR repository that contains the weekly releases. So anyone who wants to be adventurous with the latest Cockpit features can enable this repository with
and then update to the latest public release.
Have ben some change in the cockpit packaging for the cloud edition? Just
dnf install cockpit
There is not need to start the service with systemctl? Open the cockpit port with firewalld-cmd?
This is seriously becoming a real go-to resource for discovering what all Fedora can do. Love the article length, amount of information shared and writing style (almost zero fluff).
I discovered a new tool today. Thank you.
This is a lovely innovation. We’re yet to see the best of it. I just hope the project continues to blossom as its a superb backend for administrators to monitor and evaluate what goes on in their Cloud environment.