If you haven't seen this before, you should definitely give it a try. I am a big CLI person but I still find it useful, especially for displaying/visualizing metrics/performance.
If you're on a RHEL or Fedora base, it might be already installed and running. You just hit it on port 9090 with your web browser, and log in with your OS creds (same that you use for SSH). If it's not installed yet and/or you want to also add performance co-pilot[1], it's pretty easy to do:
# Install cockpit and pcp and activate services
dnf install -y cockpit pcp cockpit-pcp
systemctl enable --now cockpit.socket
systemctl enable --now pmlogger
# If needed, open port 9090 in the firewall
firewall-cmd --zone=public --permanent --add-service=cockpit
# Alternatively you can open it for just your own IP
firewall-cmd --zone=public --permanent --add-rich-rule='rule family="ipv4" source address="38.14.154.124" port protocol="tcp" port="9090" accept'
A friend of mine came from the enterprise storage field, our thing was kinda him making fun of Linux and me making fun of Enterprise proprietary software.
Two years ago he started using cockpit on his fedora homelab server and now every time we talk I'm so proud of how he's getting into Linux thanks to Cockpit.
Is it like minimalist version of Netdata[1]? Netdata doesn't require fiddling for the most part too, Unless we need to customize alarms, logging etc. It's discovery of services and visualizations for monitoring are excellent.
My only complaint on Netdata is that its resource heavy(especially the Go plugins) and so they're not fit for resource-constrained systems like Raspberry Pi; I wonder whether Cockpit is a good replacement there.
Not just fedora or red hat flavors, it works great on most distros. Unified package management and updates, network and observability, podman and kvm… rocks, highly recommended
This is an abstraction over the terminal interface. We can use either way. It even provides a slick html5 terminal so you can use it directly from cockpit without exposing sshd.
For what it's worth, I've been using it on prod boxes for 6 years now and I've never even thought about release cadence, so I don't think the average user has to know or care.
Quick, what's your version and the release cadence of: top, bash, coreutils, systemd? It's very likely you don't know, don't care and just get them with the distribution. Nobody's forcing users to care about this either.
> It's also a tacit admission that they have a QA process that is dogshit and simply expect users to catch bugs
Since when did we expect OSS to have QA process that is not the users ? It's telling that the co-opting of OSS by business led to this expectation that OSS is something to consume rather than participate in.
Oh hey, Cockpit; I remember when this was started. It was the Red Hat desktop team's skunkworks project to make an actual good server UI after the last few attempts failed; I can't find any evidence of it, but I swear there was this ridiculous project to generate a "Linux API" by automatically combining every other API and adding prefixes and headers. That came down from management since "APIs" were the hotness.
The goal was to make in-roads on Windows Server-like deployments. "Cattle, not pets" was becoming uber-popular, but the thinking on the desktop team was that there was still a wide market for pets. People with toy servers, small businesses that just want a server inside their network, they all deserve UIs that don't require heavy sysadmin-ing.
I think it turned out quite nicely, and it seems it's still going!
Are you thinking of Augeas? That was a project inside RH to parse nearly every config found in /etc, and be able to view and modify them all from a standard API.
I wanted to parse INI files a few weeks back and briefly looked at Augeas... the augtool syntax was a little too nonsensical or verbose for me. Felt like I had to be an expert with the entire tool even though all I wanted was 3% of its functionality.
I looked a little harder and then found jc[1] which made parsing the ini file easy, and since I didn't need full CRUD support I threw my hands up and used that instead. I _would_ like to find a fast and easy way to convert json/yaml to simple INI file syntax at the command line, or do idempotent modifications to the INI files without writing a command where 99% of it is describing to jq or awk what an INI file looks like.
It's basically a pluggable lexer, it is stable. And especially new config files have standardized on some variation of INI, Toml or YAML so there's less need for app-specific parsing.
Isn't this Martin Pitt's project? And it says it started in 2013. He was working for Canonical until 2014 IIRC. I would not be surprised if Red Hat scooped him up after this project was launched. Hard to know the timeline, though.
Cockpit is an impressively robust “server in a box” frontend for homelabs or my favorite, running on a little ARM SBC with a USB Ethernet gadget exported.
Why is this a cool setup? B/c I can carry around a little Radxa Zero that looks like a USB-C Ethernet adapter to my iPad, Windows laptop, etc., and gets powered by the same port, and gives me Cockpit on a known local IP, mDNS advert, etc.
It’s a pretty good “hacking on the plane/train/mountain” setup, if you’re ever in the mood to try such a thing. :)
Edit/P.S.: why not just run a VM? See above re: iPad or other locked-down device; also, exposed GPIOs are useful sometimes too.
Used it mostly for cockpit-docker.
Sadly, IBM decided to totally uproot (i believe their most popular) module to leverage podman over docker.
First it was CentOS, now this.
Started using Cockpit when installing Fedora 21 on the old dog NAS - HP ProLiant MicroServer N54l), it has been continuously improved over time and become a easy to use & robust Web UI for beginners (very intuitive, e.g. enabling metric collection will trigger toggling `pmlogger.service` and so on), even CLI warriors love it as a supplement.
Found it a useful single point of view / administration covering networking, storage, virtualization, containerization, etc. when managing a small group of servers over nebula (overlay network), across home, multiple cloud service providers. Haven't used it at scale though, will dip into it when time comes (it supports FreeIPA).
I first ran into Cockpit when it was included on a Fedora Server install, and I've been really impressed! It's sleek, I've never had any major[1] issues with it, and I really appreciate the wide variety[2] of functionality that you can include, eg. cockpit-machines for Virtual Machines and the EOL[3] cockpit-zfs for all sorts of regular RAID activities.
My sole gripe is that, IIRC, it's really tied into a dependency on Systemd, so I can't use it on any of my current machines which run elogind-based distros like GuixSD or a typical Gentoo installation. I don't happen to have any systemd-based distros installed atm, and if I did, can't imagine I'd use Cockpit regularly unless I could use it everywhere-- but I do wish I could! Maybe the systemd functionality can be factored out and re-implemented, but I'm not sure if anyone's going to decide it's worth their time and effort.
[1]: I did have to set $TERM=linux for the web-shell to behave correctly, but am not convinced that's an issue with Cockpit itself.
I have an old personal dedicated server that has been running with Webmin for nearly 10 years, and Webmin is pretty thorough and actually helped me learn to manage servers with command line by exposing in a safer way all the config files.
What are the biggest differences between the two ? Besides the fact Cockpit's probably not written in perl :-)
I use Cockpit on isolated Debian Bullseye VM hosts to provide a UI to libvirt.
It's very nice for that - it's minimalist, it doesn't get in the way of anything you want to do manually, and it doesn't wreck your VM configs if you just want to use it as a nice way to get console access.
I tried it on Ubuntu two years ago and it didn't feel very polished. I was able to create virtual machines and inspect basic metrics, but it would throw errors on about half of the features, assumed it was because it was built for RedHat and things were done differently on Ubuntu, or that I had simply done something incompatible in my manual configuration.
Would you say all the features of cockpit work on Debian?
We recently made a new Red Hat server and it prompted us to enable this when we logged into SSH.
Was very pleasantly surprised, and we used the web interface to configure everything, from VMs to bridging and bonding. Everything just worked really well.
I'll admit though: it does feel a little "AJAX-ey" and it has this weird buggy/cheap feel that I don't get from i.e. Dell iDRAC or Enterprise switch interfaces. I think that is entirely because of the bootstrap-esque styling, and nothing to do with the way it works.
Yes, you can get it installed and running pretty easy - however because Ubuntu does networking differently it wasn't able to do a bunch of things.
Cockpit kept thinking the machine was offline, so wouldn't do software updates.
It wouldn't do network management, because networking wasn't done in the way that Cockpit wanted.
Yes, I could manually screw around and move from one type of network manager to another to make it work - but it wasn't easy, and easily broke networking on the machines.
I ended up installing Fedora instead to get Cockpit working nicely.
I had no trouble at all running cockpit on ubuntu, but the Fedora experience is definitely super polished. I was blown away at how easy and useful it was.
The first command you ran "sourced" a file - it basically read a file and set some environment variables - because that is what was in that file. The second one ran a command to install stuff and it referenced a variable - that variable was not mentioned in the sourced file.
In general, when you install a package in Ubuntu or Debian you should not do anything more fancy than:
$ sudo apt install <package>
Don't put -y - you can then read any messages and make up your own mind what to do. If you know what you are doing then obviously use -y.
You may find this handy:
$ apt-cache search cockpit
There are loads of web site scrapes these days relating to Linux stuff, just as Windows pioneered them years ago.
Sign up to the forums for say Debian, Ubuntu, Arch and Gentoo and Mint, Fedora too. Don't rely on a general search unless you really know what you are looking for.
I started using this recently when I installed Rocky Linux, since the installer had it as an option and I was curious.
I still use ssh for the vast majority of what I need to do (partially out of habit), but my experience with Cockpit has been great. The SELinux app, which is a GUI for things like setroubleshoot, audit2allow, etc is definitely my favorite part.
This comes included in Debian (and a bunch of other distros as well). I'm using it on a few home servers.
I wish it had integrated support for containers (Docker, Podman); don't need anything fancy, but I have to set up Portainer as well just for managing those (start, stop, add a new docker, read logs, etc.)
I'm nearly certain that cockpit does have integrated support for containers, although you may need to install an extra package to get it. In my setup scripts I have:
I used to manage single board computers behind home routers. I tunneled their ssh ports to a beacon vps instance using frp (more stable than autossh) to make a poor man's vpn and connected them all to cockpit. I think at the time the free version only allowed 15 connections, though.
I think Cockpit project seems really cool, I remember seeing a Youtube video from some conference when they explained how it was working. It was basically acting as some new type of terminal.
But is it useful for non-RedHat-distributions? It seems quite tailored to that world.
Yeah it works great on most distros. I run it on at least 5 different flavors of Linux and while the control panels are slightly different (if the feature set is not used on the OS), they all link up and you can use a single machine cockpit to laterally move to other cockpit instances. Works well for bastion hosts too.
I’m a fan.
It seems so. I hope Cockpit is small enough so one day it could replace LuCi as OpenWRT interface, also on smaller devices. I recall of some quirks with LuCi, such as the interface not synced to system files, so that one was forced to edit them by hand. Although I'm a Linux guy, I'm a fan of OpnSense and XigmaNAS, both BSD based, and their super clean, stable and efficient web UI which looks somewhat similar to Cockpit.
The LuCi model is to generate the configs for a service from a separate config that the config generation system stores and the UI understands. Personally I think that is a terrible model, because if you want to set an option the config generation system doesn't set, there will be no documentation for that and you have to edit/trace the undocumented shell scripts that do the generation. A better model for this is Augeas (or Config::Model), which understand config files and offer a more sane API that allows you to modify them in-place.
I wish this tool was more useful but currently it's nothing but a simple dashboard and other parts are better handled inside a shell.
Graphs, logs and stats are nothing actionable and package manager and service manager was kind of broken the last time I tried and it provides nothing better than command line by showing bunch of entries to make it hard to look at.
Ansible and tmux require a lot more knowledge to be effective with than cockpit does, if you have that knowledge great, but if you have fairly low (linux) skilled first line support or junior sysadmins then giving them a gui lets them solve lots of basic issues without escalating.
If you're on a RHEL or Fedora base, it might be already installed and running. You just hit it on port 9090 with your web browser, and log in with your OS creds (same that you use for SSH). If it's not installed yet and/or you want to also add performance co-pilot[1], it's pretty easy to do:
Here's the same commands in a gist if preferred: https://gist.github.com/FreedomBen/62b348ed45045e53356aeb714...[1]: https://cockpit-project.org/guide/latest/feature-pcp