45Drives uses cockpit as the UI layer of their "Houston" operating system. https://www.45drives.com/community/articles/New-Operating-Sy...
Also works for a single node cluster. Maybe that’s closer to what you’re looking for.
There was also Swarmpit but it didn’t really get that much love, sadly: https://github.com/swarmpit/swarmpit/issues/719
Portainer is pretty nice feature wise but even with lowered MTU I still get odd networking related issues (seems like the agent or whatever cannot reach the manager sometimes) but I’ve had those sorts of issues across multiple different clusters, both in cloud and on-prem with single leader setups and across both RPM and DEB only clusters. Weird stuff, otherwise perhaps the most established solution for Docker Swarm.
It's probably great for those who are new to Linux and want that NAS-like admin web UI to get the basics set up as a stepping-stone before launching deep into the command line.
It's pretty solid, but the limited amount of projects and lack of visibility into the CLI it uses on the backend hinder the ability to translate sysadmin work into tangible Linux skills, so I dumped it at home in favor of straight SSH sessions and some TUI stuff.
That said, if I gotta babysit Linux in an Enterprise without something like Centrify? Yeah, Cockpit is a solid, user-friendly abstraction layer, especially for WinFolks.
Troubleshooting and fluency on the command line are among what I consider core skills. Being able to dig through abstraction layers is not just essential for when things go wrong, they are essential for building infrastructure, and really tells you whether an architecture is fit for purpose.
Sometimes there aren't any docs. Sometimes the docs are wrong. It's important to be able to establish what the actual running situation is.
They all insisted that it was essential to have a CI/CD process but didn't even know what the "CD" part even did. Apparently you just "git push" and the code magically gets on the server. There are many ways to do deployments and a CI/CD process isn't always suitable and can have many forms, in my opinion, but I was happy to discuss any and all. But it's difficult to do that without the basics. As you said, before I was commissioned the platform had no documentation, was crumbling under tech debt and failing constantly so something like getting on the server to at least figure out what's going on was essential.
They asked me to double check that part because they assumed I just hadn't done that part, because apparently I was the first person who didn't need help with an SSH tunnel.
I suspect this is AI’s doing, but cannot be sure. It’s really critical that technical interviewers weed out the over-inflaters though, now more than ever.
# ip a
# ss -tulpn
# ps aux
# df -h
# apt install lnav
# journalctl -f | lnav
Mind you, my job title is MD, so I get that luxury.
And man, zero regrets. It's nice having an OS not fight me tooth and nail to do shit, even if it means letting me blow my feet off with some commands (which is why, to any junior readers out there, we always start with a snapshot when troubleshooting servers).
Now to finish my mono-compose for my homelab and get back to enjoying the fruits of my labor...
I don’t know why Windows as a whole is such a piece of fractal shit.
Maybe it is shinnegans like this: https://www.propublica.org/article/microsoft-cloud-fedramp-c...
I've spent much of my life inside Microsoft's ecosystems. Not merely my career, but my technological life itself started with Win 3.11 on a parental laptop. I've spent so long in their orbit that I can generally infer what their latest thing does and how it works from an IT POV based on its product name alone, because I understand how Microsoft thinks from a marketing and engineering perspective.
As you say, they have some truly brilliant folks in their ranks. Those few diamonds are buried under mountains of garbage and slop from above, though. I mean, this is the company who pioneered full-fat PC handhelds 20 years before the Steam Deck, the smart watch a full decade before Apple, the home media ecosystem years before streaming apps dominated, smartphones before the iPhone, I can go on and on. The problem isn't the engineers so much as corporate mismanagement, but they somehow survive like a cockroach based on install size alone.
I am more of a TUI person anyways. I have never found web based server management to be as responsive as TUI, same reason I prefer direct attaching than live tailing on a web tool.
I configure my router through a web interface and not the command line either. It isn’t something I want to mess with on my downtime.
The debugging was also impossible, because logs were not in the expected places and standard grep on log and conf files would give you nothing.
Cockpit is way better than that. Partially because of systemd, but also dbus and other relatively new APIs in the Linux plumbing layer, which finally allowed us to implement consistent and stateless management UI of a system.
I keep meaning to look into making plugins for it, but honestly I’ve barely needed to. Cockpit, the 45drives ZFS plugin fork, and the web terminal have been more than enough for me
I suspect that was user error on my end, so if you want a more-or-less no-nonsense way to manager a server, it's certainly worth checking out.
As an aside, GitHub made a change a while back where videos and gifs don't auto play without the user clicking play first. Boo.
Went to look and webmin's changed. Pretty crazy.
I've found that Cockpit Machines is really unreliable on Debian and it's nothing really to do with Cockpit - it's things like dbus settings that break Cockpit.
eg, having to add this to make it reliable on my Debian Trixie install:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<limit name="max_match_rules_per_connection">4096</limit>
</busconfig>
So try to stick to cli for things that aren’t unreasonable to manage by hand (eg docker)
It doesn't have a patch on Webmin, sadly.
Cockpit is great to get a quick glance at the state of servers, but for actual work the terminal is more convenient. Appreciate it for what it is and don't expect a full desktop environment to be included.
Edits which you make through cockpit and edits which you make through cli are exactly the same edits in same APIs. You do not need to choose one or the over. You can switch from one to the other seamlessly on a command by command basis.
However, I was wondering if there was any way to login using an SSH key rather than a password?
I could of course pipe it via SSH. But is there any way we can authenticate using SSH on the web?
Maybe someone here can help?
I don't know why but this reminded me of that.
[1] https://psdoom.sourceforge.net/ [2] https://psdoom.sourceforge.net/screenshots.html
I will not assume any liability for damage caused from running this code. Especially if you are running it as root. In fact, we both know that this will cause damage to the system, and that's why you want to try it. You have been warned.
Ended up wanting something CLI-first that could check all servers at once without opening a browser. The web UI is nice for a quick glance though.
Virtualmin in particular is more targeted towards production web servers, but I think they’re both something of a happy medium between a GUI and the terminal; The interfaces are all pretty explicit about the components you’re interfacing with, and nearly all of them include the ability to pop open the conf files to edit them directly.
The extensive UI isn’t the most flashy or polished, but it’s functional and if you get bored enough (as I did) you can theme the entire thing with a single CSS file (be prepared for a lot of ‘!important’ and other things that will drive UI/X folks nuts), and make it look rather stylish.
The only downside (and this isn’t really a downside for production servers) is it’s opinionated on how some things “should” be configured. It’s not restrictive, per se, but it’s not very tolerant for “coloring outside the lines”. You can run an Apache or Nginx reverse proxy, but if you want to use Caddy or Traefik or something similar, this may not be the admin panel for you.
Myself, I just run Webmin/Virtualmin on my production servers, and use a separate server for Docker and apps, where I’ve used both Cockpit and Portainer, but generally tend to stick with the CLI. The command line will always be the best, most efficient way of interfacing with Linux. Once I’d learned enough to be comfortable, I found it becomes increasingly preferable for most common tasks.
I believe when 'roscas' says this feature was dropped, they're talking about the requirement to enable 'AllowMultiHost'. As far as I know, this is still supported with some risk (according to the latest docs): https://cockpit-project.org/guide/latest/#secondary-auth
> This feature is deprecated as of Cockpit 322.
Still works on 357 (Fedora 43)... so it's one of those "you can use it, but don't expect fixes" things, I guess. ref: https://cockpit-project.org/guide/latest/#multi-host
I also experimented with skill-creator to generate a skill for “operating” my chezmoi in a read only way, and now when I use Claude in a certain directory it tells me what needs to be updated and which commands to issue. I can see why people are worried about human skill decline!
It’s miles away from like Webmin, which I used god knows how long ago.
I've never found any better interface than Fastpanel: https://fastpanel.direct
I'm not ashamed of shilling it. It's made managing servers and sites a pleasure instead of an exercise in teeth-grinding. Yet I never see it mentioned anywhere online when the subject comes up, even though the license is free.
avoid admin UIs... at best they make you lazy, at worst a security nightmare
1. insisted on a pre-war version of ubuntu
2. insisted on the cockpit. So you no longer can modify the NFS exports over ssh, you need to connect to this HTTP abomination. Very nice. Always wanted to open more ports on my servers
But, it doesn't offer any way to review my incus containers.
So, I tried wolfstack, which was recently listed on HN.
It appears it only supports lxc. I'm surprised, isn't lxc and incus more or less 1:1 synonymous (unless you get into recent more complexities)?
I'm feeling like it is hard to find a simple GUI to just review a system and manage a bunch of containers and VMs.
Finding a simple GUI is not going to be easy because everyone has a different definition of what "simple" means. It also depends on what you mean by "review" and "manage". There were a few web UIs for LXD containers and they were ported or used for Incus containers. Some are still maintained and active.
I personally prefer the command line and find it easier and simpler than using graphical interfaces so don't have a recommendation. When the number of containers and servers becomes large enough to warrant anything else, then that's when automation starts.
So if you get onboard with podman, you may get some benefits from the Cockpit UI for it.
But you are right, there are many different container technologies and we haven't catched up with all of them.
Incus does all three through the same web ui
* OCI compatible "app" containers - with support for registries like docker.io and ghcr.io
* LXC "system" containers
* virtual machines with qemu + kvm
Edit: so, this is the incus-ui-canonical package? It feels a bit ironic that canonical ships this, because I thought the whole point of incus was to avoid canonical and the direction they were taking lxd.
Thank you for this, I'll check it out.
Very handy to generate yaml config for machines and viewing their console / terminal.
I get what you mean, but IncusOS is running linux.
I like cockpit because I can use the machine as a regular Linux machine. It happens to have some containers and VMs running in a very ad hoc way. It wasn't the plan to use it for hosting originally but now it is. And cockpit can be configured to use other machines as well, right? So it makes it easy to grow into a quick way to review all the machines without me planning out nodes and centralized control.
Perhaps I'm mistaken, but I assumed proxmox was better if you planned on using a machine solely for the purpose of running virtualized machines.
LCD/incus seem like they would be a good fit for the way I used cockpit; because you can script them easily using CLI tools, so figured adding a cockpit plug-in would be easy. And you can migrate those containers and VMs to another host server easily.
This is all my homelab and I'm not being very intentional about the way I run things. I love to spin up a new server and then if things get overloaded (like I run out of ram on the host) I can easily move that server to another machine.
I have a bunch of host machines that are my kids gaming machines. They are basically unused during the day. ;)