If you have a git repo for anything that's supposed to be an interface to anything, please put one screenshot at the top of your readme. I get that the website has these, but its the best way to let me know more about your product in one shot.
Do you mean LXD and Incus? If so, sort of. Incus is a fork of LXD but it diverged quite a bit and due to the LXD licensing change, Incus can't take anything from LXD but LXD can from Incus. Incus is a community project and is a lot more active. They both use LXC under the hood.
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.
Mostly I want a quick glance at the state. I don't really do much using cockpit. It is read only for me and I'm using command line to do anything. I like that cockpit is generally mobile friendly because I can use it remotely as all my machines are on tailscale/headscale.
We do have a cockpit-podman plugin and have added recently some features to simplify management of podman quadlets. (podman quadlets is like a systemd-friendly version of docker compose, which is a good fit for a single server use case)
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.
I recently moved from a docker-compose setup with portainer as a manager to podman+quadlets+cockpit . After the initial pain of migration i'm really happy! I can also manage VMs, volumes, and check systemd logs so it's a good all-in-one solution for managing standalone servers. Also i think it uses systemd activation so it's really light on resources. For someone who dislikes the proxmox approach of custom kernel/os this is a good alternative.
I've never used proxmox, but I've heard good things. Personally (and this is a bit crazy) the best bar none interface for containers I've used is the OpenMediaVault compose plugin - it's a NAS distro but I literally ran it on all my servers for years because of the UI
TrueNAS is also a NAS distribution and it has pretty good support for containers and VMs, so I’m not that surprised. They generally expect to be individual all-in-one type of servers.
Am I wrong that proxmox takes over the entire machine?
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. ;)
Proxmox is just KVM/qemu with management modules running on Debian. I set up Plasma on a node for a while and used it for a workstation for a couple years, and it worked fine.
I tried using this to handle my 10-ish Docker containers, but I ended up using Portainer. Sure, not the same thing, but if someone (like me) thought Cockpit might be nice for managing a small Docker host, this didn't work for me
Hey that’s pretty cool, nice to see someone paying attention to Docker Swarm (it’s nice for simple deployments, like multi-server Compose). You might want to add some screenshots to the docs though.
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.
Yeah, I was a long time Swarmpit user, but as you said it’s abandoned, has lots of unfixed bugs, and is pretty heavy. So I set out to build something light on Go to replace it.
I love swarm! If only it wasn’t the unloved step child…
I ended up on this journey using Dockge. Inoffensive and you can stick your compose files in a directory and manage with git vs. Portainer’s attempt to hide them.
It's neutered and not as full featured, but not bad in a pinch. All of these web admin tools are hacks that call out to shell scripts and whatnot. It requires a lot of conditional behavior and/or vertical integration. "Linux" has no consistent API for control, so its all duct tape. Webmin is the same, tbh (swap perl for whatever cockpit is written in)
I installed the latest Fedora Server on my Framework Desktop and noticed that Cockpit was enabled automatically. Overall impression is that its pretty good for getting a quick overview of things and you can certainly do _some_ administration with it, but you run into its limitations pretty fast trying to get any serious work done with it.
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.
I've used this before in the early days of my Linux SysAdmin work, especially in the homelab.
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.
Part of the technical assessment I have for hiring new platform engineers involves troubleshooting a service hosted in a headless Linux vm.
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.
When I was interviewing people on behalf of a client, I was surprised at the number of people who didn't even know what SSH was. This was for a mid-level software developer and not a junior and they all came with glowing resumes.
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.
Gathering and mapping unfamiliar systems is part of that skillset. I’m also looking at being able to think laterally, being able descend abstraction layers, and understanding architectural characteristics and constraints (Roy Fielding’s Dissertation), which will recur at each level of abstraction.
From a professional perspective, this is a solid question. And yeah, between the basic tool suite (top/cd/ls -l/df -H/grep/pipe '|'/ssh) and some common sysadmin/engie knowledge, I could get by with Linux just fine. "Just fine" doesn't cut it for troubleshooting sludgepipes and Kubernetes though, and my skills with Powershell finally gave me the confidence boost to take CLI/TUI seriously on Linux.
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...
It's the management structure focused on short-term gains and promotion cycles, combined with a corporate culture focused very much on the same as management with the added twist of politicking, backstabbing, and undercutting other teams.
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.
Sure... but, I’ve got decades of experience doing that stuff, just not frequently enough to keep it in my head, these days. I usually want a small project server to just do shit and the less there is between that and booting up a fresh Linux install, the better. For example, I don’t keep firewall command line syntax in my head, but I know what needs to be done, and I always seem to need it with small home projects. I lose nothing by having a trustworthy gui do it. I’d give this a shot. I doubt I’d use it in a professional environment, but that’s not really my use case these days.
Which goes to show, experience and maturity changes how people use tools. The person I was responding to was at an earlier maturity stage and realized it was hampering their growth
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.
Cockpit is great! My NAS (built on a weird “N17” AMD 7840HS laptop processor put into a desktop “server”mITX motherboard by those wizards in China) stuck in a Jonsbo N2 with 5x4TB Samsung 870 evos in ZFS raidz1 is entirely managed by it
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
Cockpit is rudimentary and hardly worth the time. And as far as I can tell, there's very little interest in expanding it from the broader community, as the lack of plugins would seem to indicate.
My own early sysadmin experience was with Ubuntu eBox and I hated it. Because none of the expected configuration files or commands you would find on Stackoverflow would work on a eBox managed server. You would do configuration through the UI or nothing.
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 run a small homelab (Mac Mini + RPi5) and
tried Cockpit too. Great for single server
monitoring, but once I had multiple nodes,
I kept SSH-ing into each box anyway.
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.
I used Cockpit for years after I started having issues with my network card in FreeNAS. It's generally very good, though I never really figured out how to graphically swap out a hard disk in a RAID without trashing the data (which happened once).
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.
I tried this out about 2 months ago when setting up a new server. I wanted something simpler and less resource heavy as webmin but it was just too simple. Adding questionable, half baked add-ons to get various functions to work just didn't give me the flexibility of webmin.
This thing came by default on AlmaLinux, which I am evaluating for some HomeLab stuff. It's pretty neat! Definitely not a replacement for cotnainer management though - it is really more of a sysadmin portal where you can view services and open a terminal and such, but from a web console.
It is very nice. I hope more apps and options are added as it makes very simple to do some admin tasks.
Want to manage services? No problem, it is very easy. Clear failed and disable? Easy.
Want to see some disks and do admin operations on disks? It does.
Want a simple system monitor? It tracks cpu, ram and more in a pretty interface.
RHEL is dropping old interfaces like cluster management and starting to use Cockpit only.
I just wish Cockpit would replace Hawk2 for cluster management as it is better then the old deprecated cluster manager web interface.
But yes, install Cockpit or keep it installed ready to be use cause one day it saves the day...
- Easy OIDC
- Generally improve the file manager addon
- ncdu-like addon
- interface to create simple systemd services
- more visibility into which commands you can run to do the same thing
I would love to resize drives/partitions on Linux machines without it feeling like open heart surgery, in a place I already have handy for generally poking around those machines.
Some more love for the updates page. E.g. select a subset of updates to install, be more clear that the last update time could be different if you installed updates via CLI, that kind of thing.
I don't mind UI, but I think it's a bad approach.
Instead of hiding all those complexities of the server behind UI, I would like to see each part of the application teach me how to achieve the same result in CLI. That would be useful for people to teach themselves, because UI comes and goes but basic linux commands - will stay
I have been using Webmin/Virtualmin for all of my 15-years as a web host. I love it, although it can be a little idiosyncratic in places, once you know how to operate with it, you won’t ever need anything else. It’s never been the most bleeding-edge or fully-featured, but it’s also never fallen behind with security and compatibility updates, and it’s had a surge in new development lately, which is exciting. On a Debian system, it’s always been rock solid for me.
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.
Both can have their place. I'm pretty familiar with the podman cli, but having a dashboard I can access from a bookmark in my browser is handy when I just want a quick overview of everything.
I have a handful of unique pet Linux machines at home and at work. The number one reason I love Cockpit is because I probably don't even remember which distro which is using, so it's really nice to have a common place I can establish a baseline when I know a given one of my machines is sad.
For the longest time I wanted to automated things with ansible. But it was a massive paint to plan/create new playbooks to manage servers and services. But now with Claude Code and other AI agents the ground has shifted. I have created a git repo that contains all my infra information minus credentials. Claude uses it to manage my infra using tools like terraform/tofu and Ansible. I also review the changes before they are pushed. And it is exceptionally good at debugging issues. If something breaks or starts acting weird I asked Claude to take a look and it can get to the bottom of it far quicker than me pocking around. Particularly when I get a call when I was sleeping.
I’m on a similar trajectory. Claude is excellent at writing Dockerfiles, compose files, and operating docker. “Add a daily backup container to this compose file which writes to a new volume”, and it’s done.
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!
The main difference of Cockpit as opposed to more old school visual server administration tools that it doesn't replace standard server management approaches with its own configuration storage in some weird database.
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.
I use it for certain use cases, where it definitely is more convenient. For example, adding a new user or adding an ssh key for a user or debugging SELinux issues.
Web UIs are nicer to deal with for simpler tasks. You can use this on your phone easily. Less technical users can be instructed on how to perform simple tasks like remotely powering off a machine.
i used to set up webmin for the linux challenged admins so they could do basic tasks. it was nice because you could lock them to specific functions in certain modules and make it difficult for them to break things
It's pretty single-server focused... but there is a 'Multi Host' mode. One instance can use SSH to look at N systems [independently]. This consolidates the Cockpit endpoints you might need to use/ports to open... but doesn't give much in the way of orchestration.
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
I think they dropped multi server managment because it was possible to add a few servers but I guess they drop that one out. You do can logon into a server right on the logon page. That is nice.
Does anyone else remember when someone ported kill to the DOOM engine? So you could fire up DOOM and kill processes using different guns for different kill levels?
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.
I don‘t like the whole idea because it is less secure to have a web browser instead of a standard client. Think what an attacker could do if they take control of the server.
I had a bad experience with it. We hired a contractor and he
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
That advice crumbles fast when you're babysitting a fleet and someone wants metrics or logs ASAP while SSH is blocked for reasons no one can explain. Laziness isn't the issue. The problem is people treating a GUI as if they acctually understand the system, and if your security falls over because a web UI got installed, you already had bigger problmes waiting to bite you.
I just want to check from my phone how my home server is doing. Maybe someone else gets a perverse pleasure out of catting /proc/meminfo but I don't understand the need to make things more complicated than necessary.
When it evolved a couple years ago to automatically set up the bridge for libvirt correctly, it had arrived. When that thing can set up pushbutton podman apps with decent net and persistence defaults it will be gold.
As a certified graybeard (just literally graying on my beard now) who now prefers the CLI, I am SO GLAD that tools like this exist. I owe probably all of my high job satisfaction and higher income to the fact that I got to play around with Linux via Ubuntu (and Compiz Fusion via CCSM) and later Webmin and other tools I eventually played around with. I learned so much without realizing I'd be using it later, though IIRC it involved much swearing and gnashing of teeth. It's crazy to think that 20 years later so much of it comes naturally. Though I'm still learning just as much (with just as much swearing at the computer usually) every day.
If you have a git repo for anything that's supposed to be an interface to anything, please put one screenshot at the top of your readme. I get that the website has these, but its the best way to let me know more about your product in one shot.
Agreed. With a multi tab/page interface system like this, it would be nice to see a slideshow of different useful pages and nice data vis metrics.
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.
I have used cockpit and like it. It allows me to quickly see the entirety of my system.
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.
Do you mean LXD and Incus? If so, sort of. Incus is a fork of LXD but it diverged quite a bit and due to the LXD licensing change, Incus can't take anything from LXD but LXD can from Incus. Incus is a community project and is a lot more active. They both use LXC under the hood.
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.
Mostly I want a quick glance at the state. I don't really do much using cockpit. It is read only for me and I'm using command line to do anything. I like that cockpit is generally mobile friendly because I can use it remotely as all my machines are on tailscale/headscale.
We do have a cockpit-podman plugin and have added recently some features to simplify management of podman quadlets. (podman quadlets is like a systemd-friendly version of docker compose, which is a good fit for a single server use case)
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.
I recently moved from a docker-compose setup with portainer as a manager to podman+quadlets+cockpit . After the initial pain of migration i'm really happy! I can also manage VMs, volumes, and check systemd logs so it's a good all-in-one solution for managing standalone servers. Also i think it uses systemd activation so it's really light on resources. For someone who dislikes the proxmox approach of custom kernel/os this is a good alternative.
> 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.
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
I've never used proxmox, but I've heard good things. Personally (and this is a bit crazy) the best bar none interface for containers I've used is the OpenMediaVault compose plugin - it's a NAS distro but I literally ran it on all my servers for years because of the UI
TrueNAS is also a NAS distribution and it has pretty good support for containers and VMs, so I’m not that surprised. They generally expect to be individual all-in-one type of servers.
Curious if you have tried IncusOS or if you are just using Incus on linux? I'm doing the latter and have been considering moving to IncusOS.
> IncusOS or if you are just using Incus on linux
I get what you mean, but IncusOS is running linux.
I use proxmox. I only use it for a home lab but it's pretty good and all I use are lxc containers.
Am I wrong that proxmox takes over the entire machine?
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. ;)
Proxmox is just KVM/qemu with management modules running on Debian. I set up Plasma on a node for a while and used it for a workstation for a couple years, and it worked fine.
proxmox
Would be nice if the landing page had some graphical pictures for a graphical interface...
Try https://cockpit-project.org/ :)
Which is fine and all but repos with such sparse README's are not doing themselves any favors.
Including images in a readme means committing (maybe large) binary files to the repo.
They could commit thumbnails linking to originals hosted on their website.
Thumbnails are not even needed - they can just use a plain old img tag in the readme with an external src.
I tried using this to handle my 10-ish Docker containers, but I ended up using Portainer. Sure, not the same thing, but if someone (like me) thought Cockpit might be nice for managing a small Docker host, this didn't work for me
Going for a shameless plug - I am working on an observability dashboard for Docker Swarm: https://github.com/Radiergummi/cetacean
Also works for a single node cluster. Maybe that’s closer to what you’re looking for.
Hey that’s pretty cool, nice to see someone paying attention to Docker Swarm (it’s nice for simple deployments, like multi-server Compose). You might want to add some screenshots to the docs though.
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.
Yeah, I was a long time Swarmpit user, but as you said it’s abandoned, has lots of unfixed bugs, and is pretty heavy. So I set out to build something light on Go to replace it.
I love swarm! If only it wasn’t the unloved step child…
Thanks for this, going to check it out now
can you please add some screenshots?
What you're looking for is Dokploy. It's much better than it's predecessors like Dokku, CapRover, etc.
I was heavily impressed with CapRover 5 years ago, so if you’re right, it’s worth checking this out.
I ended up on this journey using Dockge. Inoffensive and you can stick your compose files in a directory and manage with git vs. Portainer’s attempt to hide them.
Portainer still needs to be run as rootful container? Then thanks, but no thanks.
I used Webmin[0] back in the day, I wonder how more recent server web UIs like Cockpit stack up.
[0] https://webmin.com/
I looked at this and said "They've made Webmin again."
with all the potential vulnerabilities of 400 npm dependencies (I'm guessing. It's probably higher)
It's neutered and not as full featured, but not bad in a pinch. All of these web admin tools are hacks that call out to shell scripts and whatnot. It requires a lot of conditional behavior and/or vertical integration. "Linux" has no consistent API for control, so its all duct tape. Webmin is the same, tbh (swap perl for whatever cockpit is written in)
45Drives uses cockpit as the UI layer of their "Houston" operating system. https://www.45drives.com/community/articles/New-Operating-Sy...
Cockpit tends to be less ad-hoc than others ime. Often it'll use dbus on the backend.
It's also socket activated, which is nice.
I installed the latest Fedora Server on my Framework Desktop and noticed that Cockpit was enabled automatically. Overall impression is that its pretty good for getting a quick overview of things and you can certainly do _some_ administration with it, but you run into its limitations pretty fast trying to get any serious work done with it.
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.
I've used this before in the early days of my Linux SysAdmin work, especially in the homelab.
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.
Part of the technical assessment I have for hiring new platform engineers involves troubleshooting a service hosted in a headless Linux vm.
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.
One of my favorite interview questions: "Here are some SSH credentials. What does this system do?"
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.
When I was interviewing people on behalf of a client, I was surprised at the number of people who didn't even know what SSH was. This was for a mid-level software developer and not a junior and they all came with glowing resumes.
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.
Mind you, my job title is MD, so I get that luxury.
Gathering and mapping unfamiliar systems is part of that skillset. I’m also looking at being able to think laterally, being able descend abstraction layers, and understanding architectural characteristics and constraints (Roy Fielding’s Dissertation), which will recur at each level of abstraction.
From a professional perspective, this is a solid question. And yeah, between the basic tool suite (top/cd/ls -l/df -H/grep/pipe '|'/ssh) and some common sysadmin/engie knowledge, I could get by with Linux just fine. "Just fine" doesn't cut it for troubleshooting sludgepipes and Kubernetes though, and my skills with Powershell finally gave me the confidence boost to take CLI/TUI seriously on Linux.
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 know there are some brilliant engineers at Microsoft. There are some incredible engineering in some components.
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...
It's the management structure focused on short-term gains and promotion cycles, combined with a corporate culture focused very much on the same as management with the added twist of politicking, backstabbing, and undercutting other teams.
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.
Sure... but, I’ve got decades of experience doing that stuff, just not frequently enough to keep it in my head, these days. I usually want a small project server to just do shit and the less there is between that and booting up a fresh Linux install, the better. For example, I don’t keep firewall command line syntax in my head, but I know what needs to be done, and I always seem to need it with small home projects. I lose nothing by having a trustworthy gui do it. I’d give this a shot. I doubt I’d use it in a professional environment, but that’s not really my use case these days.
Which goes to show, experience and maturity changes how people use tools. The person I was responding to was at an earlier maturity stage and realized it was hampering their growth
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.
Cockpit is great! My NAS (built on a weird “N17” AMD 7840HS laptop processor put into a desktop “server”mITX motherboard by those wizards in China) stuck in a Jonsbo N2 with 5x4TB Samsung 870 evos in ZFS raidz1 is entirely managed by it
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
Same here. Using it on two boxes, makes Linux sysadmin work easier.
Cockpit is rudimentary and hardly worth the time. And as far as I can tell, there's very little interest in expanding it from the broader community, as the lack of plugins would seem to indicate.
It doesn't have a patch on Webmin, sadly.
Agreed, I'd like to hear what actual tasks people are doing with it
Reminds me of cpanel, from the late 1900s: https://en.wikipedia.org/wiki/CPanel
My own early sysadmin experience was with Ubuntu eBox and I hated it. Because none of the expected configuration files or commands you would find on Stackoverflow would work on a eBox managed server. You would do configuration through the UI or nothing.
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.
Trigger warning. This is taking me back to when I ran my own "web hosting provider" on a PIII with 128mb of ram back in the early 2000s (I was 13).
Came here to say this too.
The very first thing I remove when I install Fedora. It's such a bloat that only takes up space and memory for most people.
It's socket-activated, so doesn't really take up memory unless you actively use it.
Same!
remove cockpit*, install fish shell :-)
I run a small homelab (Mac Mini + RPi5) and tried Cockpit too. Great for single server monitoring, but once I had multiple nodes, I kept SSH-ing into each box anyway.
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.
I used Cockpit for years after I started having issues with my network card in FreeNAS. It's generally very good, though I never really figured out how to graphically swap out a hard disk in a RAID without trashing the data (which happened once).
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.
I tried this out about 2 months ago when setting up a new server. I wanted something simpler and less resource heavy as webmin but it was just too simple. Adding questionable, half baked add-ons to get various functions to work just didn't give me the flexibility of webmin.
This thing came by default on AlmaLinux, which I am evaluating for some HomeLab stuff. It's pretty neat! Definitely not a replacement for cotnainer management though - it is really more of a sysadmin portal where you can view services and open a terminal and such, but from a web console.
It is very nice. I hope more apps and options are added as it makes very simple to do some admin tasks. Want to manage services? No problem, it is very easy. Clear failed and disable? Easy. Want to see some disks and do admin operations on disks? It does. Want a simple system monitor? It tracks cpu, ram and more in a pretty interface. RHEL is dropping old interfaces like cluster management and starting to use Cockpit only. I just wish Cockpit would replace Hawk2 for cluster management as it is better then the old deprecated cluster manager web interface. But yes, install Cockpit or keep it installed ready to be use cause one day it saves the day...
Question from a Cockpit PO: if you were to choose one feature to add to the project what that feature would be?
- Easy OIDC - Generally improve the file manager addon - ncdu-like addon - interface to create simple systemd services - more visibility into which commands you can run to do the same thing
I would love to resize drives/partitions on Linux machines without it feeling like open heart surgery, in a place I already have handy for generally poking around those machines.
Some more love for the updates page. E.g. select a subset of updates to install, be more clear that the last update time could be different if you installed updates via CLI, that kind of thing.
Incus support.
A streamlined way to control "systemctl --user ..." without needing root auth.
I don't mind UI, but I think it's a bad approach. Instead of hiding all those complexities of the server behind UI, I would like to see each part of the application teach me how to achieve the same result in CLI. That would be useful for people to teach themselves, because UI comes and goes but basic linux commands - will stay
Comes and goes? Webmin would like a word
I have been using Webmin/Virtualmin for all of my 15-years as a web host. I love it, although it can be a little idiosyncratic in places, once you know how to operate with it, you won’t ever need anything else. It’s never been the most bleeding-edge or fully-featured, but it’s also never fallen behind with security and compatibility updates, and it’s had a surge in new development lately, which is exciting. On a Debian system, it’s always been rock solid for me.
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.
Both can have their place. I'm pretty familiar with the podman cli, but having a dashboard I can access from a bookmark in my browser is handy when I just want a quick overview of everything.
I have a handful of unique pet Linux machines at home and at work. The number one reason I love Cockpit is because I probably don't even remember which distro which is using, so it's really nice to have a common place I can establish a baseline when I know a given one of my machines is sad.
For the longest time I wanted to automated things with ansible. But it was a massive paint to plan/create new playbooks to manage servers and services. But now with Claude Code and other AI agents the ground has shifted. I have created a git repo that contains all my infra information minus credentials. Claude uses it to manage my infra using tools like terraform/tofu and Ansible. I also review the changes before they are pushed. And it is exceptionally good at debugging issues. If something breaks or starts acting weird I asked Claude to take a look and it can get to the bottom of it far quicker than me pocking around. Particularly when I get a call when I was sleeping.
I’m on a similar trajectory. Claude is excellent at writing Dockerfiles, compose files, and operating docker. “Add a daily backup container to this compose file which writes to a new volume”, and it’s done.
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!
What is the use case for this over standard command line tools like systemctl, journalctl, top, docker ps?
The main difference of Cockpit as opposed to more old school visual server administration tools that it doesn't replace standard server management approaches with its own configuration storage in some weird database.
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.
I use it for certain use cases, where it definitely is more convenient. For example, adding a new user or adding an ssh key for a user or debugging SELinux issues.
Sometimes I like a web page to bring information to me rather than having to go on a command line use those tools to find the data I want. YMMV.
Web UIs are nicer to deal with for simpler tasks. You can use this on your phone easily. Less technical users can be instructed on how to perform simple tasks like remotely powering off a machine.
Is the overhead of such tools, and added attack surface, justified over sshing and issuing a shutdown command though?
What kind of attack are you anticipating? Surely only a fool or a madman would make such a thing publicly accessible.
You can just run it via ssh anyway....
I built a bit torrent extension for Cockpit. it was pretty fun building software for it
Interesting. This looks nice. Made me think of webmin which I used... years ago.
Went to look and webmin's changed. Pretty crazy.
i used to set up webmin for the linux challenged admins so they could do basic tasks. it was nice because you could lock them to specific functions in certain modules and make it difficult for them to break things
yeah! I had some things through there early on when I was building sites. I had some custom scripts that could also be triggered by the users.
Yeah, I used to use Virtualmin and webmin 10 years ago. Looks just like em!
Does this work well with fleets? I remember looking at this early on it seemed fairly single-server focused.
It's pretty single-server focused... but there is a 'Multi Host' mode. One instance can use SSH to look at N systems [independently]. This consolidates the Cockpit endpoints you might need to use/ports to open... but doesn't give much in the way of orchestration.
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
I think they dropped multi server managment because it was possible to add a few servers but I guess they drop that one out. You do can logon into a server right on the logon page. That is nice.
Red Hat wants you to use Ansible for that.
Red Hat wants you to use Satellite for that, which uses Ansible but also does other things based around package management.
Does anyone else remember when someone ported kill to the DOOM engine? So you could fire up DOOM and kill processes using different guns for different kill levels?
I don't know why but this reminded me of that.
I need to know more about this.
Probably [1], [2]
[1] https://psdoom.sourceforge.net/ [2] https://psdoom.sourceforge.net/screenshots.html
Thanks. I like the spirit of this.
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.
Ripe for a supply chain attack. What safeguards do they have to protect against one?
Well you can use it via ssh so you don't have to open it up to the Internet directly.
The same that OpenSSL had with thousands of eyeballs looking at its source code for decades.
Aka 0. Security is a theater for the amateurs.
The worst one is password based login it enables
I've come across this before. Maybe a few years ago, but the surface area was too high. How do you navigate your security ?
I don‘t like the whole idea because it is less secure to have a web browser instead of a standard client. Think what an attacker could do if they take control of the server.
Me too, I set up a WG tunnel to access this.
Uhhh what? If they take control of the server they have control over the box.
Also the first thing I uninstall on a new system.
I use this in my homelab. I really appreciate the systemd logging functionality in Cockpit.
It’s miles away from like Webmin, which I used god knows how long ago.
I used to have this, but it takes up so much resources. not fit for small servers.
I had a bad experience with it. We hired a contractor and he
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
> 1. insisted on a pre-war version of ubuntu
Which war?
February 2022 war
Presumably the Snap War.
Sounds like you had a bad experience with a contractor.
Is it worth switching off Komodo to this?
cockpit has a great virtualization interface, in my opinion this alone makes it a better "buy" than truenas for a home server.
cPanel reborn
But does it work on a Gibson??
the opinion you didn't ask for:
avoid admin UIs... at best they make you lazy, at worst a security nightmare
That advice crumbles fast when you're babysitting a fleet and someone wants metrics or logs ASAP while SSH is blocked for reasons no one can explain. Laziness isn't the issue. The problem is people treating a GUI as if they acctually understand the system, and if your security falls over because a web UI got installed, you already had bigger problmes waiting to bite you.
I just want to check from my phone how my home server is doing. Maybe someone else gets a perverse pleasure out of catting /proc/meminfo but I don't understand the need to make things more complicated than necessary.
Technology is here to make us lazy
If you want people to self-host, this is a gateway to that.
And those who are actually curious will look into what it's doing under the hood.
Everyone has to start somewhere.
When it evolved a couple years ago to automatically set up the bridge for libvirt correctly, it had arrived. When that thing can set up pushbutton podman apps with decent net and persistence defaults it will be gold.
Sooooo.... webmin?
Very well done. For me cockpit is more than enough a mainstream proxmox
As a certified graybeard (just literally graying on my beard now) who now prefers the CLI, I am SO GLAD that tools like this exist. I owe probably all of my high job satisfaction and higher income to the fact that I got to play around with Linux via Ubuntu (and Compiz Fusion via CCSM) and later Webmin and other tools I eventually played around with. I learned so much without realizing I'd be using it later, though IIRC it involved much swearing and gnashing of teeth. It's crazy to think that 20 years later so much of it comes naturally. Though I'm still learning just as much (with just as much swearing at the computer usually) every day.