I set it up for my handrolled homelab server automation ( all Arch Linux servers ), back when I was doing everything with virsh.
It worked "ok". It required pulling in a bunch of dependencies I wouldn't have normally installed. I had it set up behind an HAproxy LB, with ssl terminated at the LB. When I was using it ~1 year ago, it was pretty buggy, and certain components would crash and I would have to restart the web page.
Overall it was a mediocre experience, but I suppose better than having to ssh into every server. The main pain point was that I still had to go in to every server, and install cockpit.
In the end, I ended up just moving on to Proxmox. But I suppose cockpit is nice if you don't want a centrally managed cluster, but still want a web interface.
Considering Cockpit is neither supported nor tested on Arch Linux[1], I think forming an opinion of it based on that would be unfair.
It's in the official Arch Linux repository. And they even decided to include it in their table from your link.
I think its definitely a valid opinion to have. And I would stand by not recommending Cockpit until it becomes more polished.
Glad I am not the only insane person running Arch for their homelab stuff.
If curious see also
Cockpit – Administer Linux servers via a web browser - https://news.ycombinator.com/item?id=16445612 - Feb 2018 (148 comments)
Has anyone tried to use this stuff at a scale of greater than a dozen servers? I briefly tried it in my homelab on CentOS 8, and immediately hit enough weirdness that I'm just back to SSH with Ansible now.
I suppose having a GUI can be nice for a health overview of your infrastructure, but in general I dislike GUIs for actual administrative work, since using them is a practice that steers you away from automation.
Most GUI tools don't provide you very good ways to make "atomic" changes, which is made very easy if you run your automation from a git repository, since the final review before hitting go is just "git diff".
Tried it on ubuntu, it also has weirdness there. The whole tool is definitely rough around the edges.
I would never use it to actually change machines though. Definitely Ansible over SSH is the way to go there.
I've mixed feelings about controlling the machines through cockpit. In theory there shouldn't be any difference between SSH and HTTPS on the security of the protocol side, but it definitely feels iffy to have a python (I think?) web app execute administration commands on a server.
I wonder what the security professionals think of it.
I have to admit the Cockpit architecture is not entirely clear to me, but at least it seems to allow using SSH as a remote transport, so you don't actually need to install the web stuff on all servers.
GUIs are great for discoverability and observation, but they always make my life harder when I actually need to manage change in a system.
As simple as it is, there's so far nothing that beats plain old text as the source of truth for how things should be; even if you have a fancy API to actually make changes into a system, you'd still want the desired state of that system to be stored as plain old text, so that changes may be tracked and reviewed easily.
You could have the best of both worlds and only modify the state of your system through a well defined API and then serialize the change in some kind of config file if and only if the change was successful (rollback to the last good state otherwise).
Would anyone be interested in a desktop application with similar functionality, accessing [multiple] hosts via SSH?
Depends. Open source or proprietary? Actually desktop or just electron? Are you going to maintain it? What use cases would it be intended for? Would the client software be available for macOS? Which GUI framework(s) would you be using?
proprietary, cross-platform desktop linux/mac/windows, javafx.
use cases: server management and monitoring, log viewer, ssh terminals, parallel execution of commands, vnc, sftp, secure storage of credentials and keys.
This is very cool actually.. neat idea! And this just uses ssh protocol for all communication? Nothing needs to be installed server-side right?
Actually no, the web interface is really slick. I would not install a desktop app for it even if there was one.
you do need to install cockpit on [all] your server[s], right?
i am trying to figure out if there is a business case for a desktop app. there is plenty of open source and commercial systems more or less similar to cockpit, and it's hard to compete with free
I don't like having to install cockpit on every instance/devices. That means I have to keep all of them up to date in addition of installing them and configuring the devices to make it operable.
I'd rather have a client-only app that connect through ssh and get its data from standard binaries installed on the server.
So, yes. I'd give that a try.
https://www.royalapps.com/ does this. I'm a happy paying user of RoyalTS.
I don’t think just an ssh client is exactly what he is going for/talking about. Check out the GitHub he references further on down in this thread.
Friends don't let friends configure linux from a web UI. It's messy, built off of assumptions, and is ripe for exploitation. Plus, if all you ever use is a web UI, how are you supposed to troubleshoot or fix the machine when said web UI stops working?
If you're looking for pretty, single host, read-only monitoring dashboards though, checkout Netdata: https://www.netdata.cloud/
I had to fire a guy in 2003 for installing webmin on a bunch of internet facing servers (webhost). Any Linux guy worth their salt isn't using a web gui for administration.
I would say it’s easier to just fix your web UI. And if that fails then revert to SSH and the command line.
Webmin is pretty useful.
Can vouch for netdata
Cockpit is super cool. I've been using it for personal stuff for years now, especially since it's trivial to enable and use.
I even use it in production for monitoring small sites/apps. The graphs for CPU/Mem/Network/Disk are really great, and I can leave them open in a tab on my browser. I run one fairly popular blog that as a web machine and a db machine, and it's great for that.
That said I don't use it for "serious production" where I have more than a couple of machines simply because at that scale I prefer cattle to pets and I prefer aggregation.
I also find myself strongly preferring SSH and the CLI, likely because I'm very familiar with all that and have been doing that for decades.
I've never heard of security issues with Cockpit, but I do firewall it off from everyone but my own IP (or a few others if they are involved). It's pretty easy to do:
# Get your IP address from home or work: curl -s 'https://api.ipify.org'
MY_IP=<ip>
firewall-cmd --zone-public --permanent --remove-service=cockpit
firewall-cmd --zone=public --permanent \
--add-rich-rule="rule family=\"ipv4\" source address=\"${MY_IP}\" port protocol=\"tcp\" port=\"9090\" accept"
firewall-cmd --reload
Shameless plug,I made a lightweight real time monitoring tools using websockets, it's open source: https://github.com/elestio/ws-monitoring/ Contributions are welcome :)
I installed on one of my ubuntu servers and allowed port 9090, but when I try accessing it from chrome it gives me a warning page
"You cannot (IP) right now because the website sent scrambled credentials that Google Chrome cannot process."
Is this because I run a NGINX server from that box?
This sounds like a certificate problem, or the browser trying to use https on an HTTP port. If you've deployed Let's Encrypt on the same host, the browser might force the connection to work over HTTPS because Let's Encrypt often adds a so-called HSTS header to the config.
If it's just Chrome not trusting the certificate, you can usually override the error by clicking "details" and then continuing by clicking a link. If the override isn't there (because of HSTS or similar), you can type "thisisunsafe" into the web page to override any non-technical certificate errors (there's no input field but it'll work)
Do you have an expired self signed certificate on that server? See https://support.google.com/chrome/thread/10551759?hl=en
sounds like a TLS cert error related to a 'snakeoil' self signed cert or something
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.