Somewhat related: if someone whose technical proficiency you don't hold in high regard needs to perform a limited number of administrative actions on a network-connected Linux machine (like restarting a specific service or installing updates), there's OliveTin. You pre-program it with the list of actions you need by writing a small yaml config, and it builds a simple web interface which the person in question can use to solve simple problems without calling you all the time.
I've been developing a Cockpit alternative (using Rust and Qt) since I wasn't satisfied with how Cockpit worked. So anyone trying to avoid any extra daemons or dependencies might be interested in Lightkeeper: https://github.com/kalaksi/lightkeeper. It's modular and only requires an SSH connection to run commands, similar to how you'd do by hand.
This looks amazing. But. I assume I cannot use this on Mac, right?. Would it work with x11 forwarding?
I haven't tried. I don't think there would be any major blockers for that, but currently I'm developing this for Linux so there might be issues. I'm open to expanding the support for Mac too.
X11 forwarding should work like with any other linux GUI app.
This looks great, nice work
Just tried it out, very nice.
I use cockpit as a 'read only' interface as everything else is defined in code to configure my homelab but it but it's great to have easy access to a terminal via web browser and also access to kvm machines console just via web interface.
Really the only web interface I consider putting on my machines is this one as it uses the normal system as available instead of doing everything custom.
Hopefully, someday Cockpit will be as complete as Webmin (which does just everything, and then some more, but is ugly and fragile).
Cockpit interests me a great deal. I used to use webmin many, many years ago, but only for a short time...It wasn't anything that webmin did poorly, simply that my need for it diminished. Nowadays, I'm more interested in what cockpit or webmin or similar alternatives have to offer...but the thing that I'm most curious about is the cockpit desktop client. I understand that its a flatpak app...But i think - if i'm not wrong - it seems to leverage connection to cockpit via ssh, which i prefer. Does anyone have experience they can share on use of the desktop client? Also, does anyone even know where i can review the source code for the desktop client? (Can't seem to find the github repo for it, though i know the app requires python for its use.)
Couple of questions I assume the answer is no, but:
1) Can you define a list of hosts and have a view with a list of all of them that you can click and go into each?
2. If so, does it allow you to send commands to multiple hosts at the same time?
1: yes, they can talk together. I believe simply requiring ssh keys
2: Each system hosts their pane of glass, you can view either directly local, or through another. Tabs and gssapi integration make this very nice
Too late to fix now - there should be a comma between 'directly' and 'local'.
You can run cockpit locally to access remote, go to the remote directly, or put a third in the middle
Is anyone actually using this on production servers? A web user/password login with sudo powers sounds... risky.
Yet managing the server through a web interface sounds nice.
Any feedback here?
It's not that different from having the same user/password accessible via ssh. It's best to not have direct access to important machines anyway, and go for a bastion or similar service.
But... you can switch to Kerberos SSO, or setup smart cards login instead.
You can also use it kind of like a jump host and do ssh keys I to secondary server.
I find it cool to give nice way to access in environments where ssh is not allowed by default, but https is. It's sometimes easier to setup proxies/reverse proxies in corporate forest instead of opting for direct ash access.
Wait, who's using SSH pass auth?
Folks, private keys. Change your SSH port and use an SSH tarpit on port 22.
How necessary is it to change ssh ports? You can't really spray/brute force a private key
It's not "necessary", but, when combined with a tarpit on port 22:
1. You can monitor if your private key is compromised and automatically rotate it.
2. It's fun to mess around with hackers and script kidies.
The tarpit on 22 is amazing. I love looking at all the access logs every fee months and seeing connection attempts that last minutes.
> user/password accessible via ssh
This is the first thing you should disable as soon as your public key is on the server.
I think most people who are serious have disabled ssh password authentication.
You don't have to run the web interface on the server.
You can use Cockpit Client (from flathub) to connect with SSH.
It depends on how you run your services.
We tested it before, however it is not quite good in our case.
Most of our services are running in a K8S cluster. The servers are just something we run the K8S node.
If we need to patch the system, we just “drain” the node, update and add it back.
So, if you do not need to directly operate the server, it will not be necessary.
You could also make Cocpit accesible only through VPN. Tailscale (and others) make it pretty easy.
Cockpit leverages the PAM stack, so you can have any authentication methodology you like.
Not production servers, but I use it on my home server running RHEL (and RockyLinux in the future).
I'm okay with using it instead of the shell because I know how to do stuff via the shell but I just got lazy.
It's not risky. For anything serious that can be an attractive target, it's a matter of time before getting doomed.
That's not a reason to make it faster...
cockpit is pretty nice as a headless alternative to manage and interact with kvms vs virt-manager
I also like storaged interface for exporting and mounting NFS and ISCSI. A killer feature would be to add support for nvme-tcp / nvme-rdma
Also have been meaning to look into what is involved for creating a plugin/extension for gtk-broadway - seems like the perfect fit for the browser.
Keep up the great work cockpit team
What I am missing in cockpit, is a way to manage user services. Like a webinterface for "systemctl --user status" etc.
It does exists, though you can only manage services from the user that you login with afaik.
[dead]
Friends don't let friends manage Linux servers with GUI
Friends don't let friends do anything by the way of "cargo-culture".
Some things make sense in some contexts, others don't. But you ain't no friend of mine if you try to dictate what I do, without knowing the full context.
This is where cockpit shines IMO. It's only using the commands you'd use anyway, but convenient for quick overviews. I don't manage anything through cockpit, but I log in every now and then for quick diagnostics.