I consider these big pluses, I use Cockpit on Debian on my servers that run VMs rather than something like Proxmox, because 1. it's much less invasive, 2. the machines tend to run other things too, like docker containers.
Have been using it for this since ~2019.
The stats views are useful too, but I wouldn't install it for that on it's own.
edit: and honestly, there's not another good (maintained!) option that fits the niche of 'let me create libvirt VMs from a web browser on a single machine without taking over my whole system'.
> It's for people who want to point and click, can't do a bash for/while loop, don't understand pipe chaining commands, and don't like using vim.
Lol! Are you ready to deploy an ssh-capable terminal emulator at all times? What's wrong with making simple tasks simple?
I run multiple Raspberry Pi cameras (with nicer camera modules) to watch the pets if the family travels. The RTSP camera streams run in a systemd unit on their boxes. I have some healthchecks to make sure packets are being streamed as other systemd units. Each camera gets its own private IP on a ZeroTier network I manage. Since copilot is only run on demand, it's a no brainer to have around for administration.
Sometimes one of the cameras just starts streaming out blank frames. I'd much rather manage this through a copilot web interface on my phone when I'm on vacation than find a keyboard to use SSH with and restart the camera stream unit. I mean sure, I could write a healthcheck which checks whether blank frames are being emitted, but it's just so much easier to restart it via copilot than it is to write that healthcheck and it only ever happens a few times a year. Shrug.
What terminal emulator isn't ssh-capable? Where would you not be able to open a terminal emulator? I am so confused.
> What's wrong with making simple tasks simple?
The limited tasks exposed by cockpit are also simple (or depending on the individual, simpler) in a terminal, but if you want a point-and-click UI for just a few things, go ahead.
That cockpit is very limited and seemingly has no future does not mean you can't like what it does now. Just might be worth considering if there are better-supported alternatives.
A mobile device. I don't use terminal emulators without access to some non-touch keyboard so I want a simple interface on my mobile device.
> That cockpit is very limited and seemingly has no future does not mean you can't like what it does now. Just might be worth considering if there are better-supported alternatives.
Sure then compare cockpit with other webmin-esque tools, not a terminal emulator. These are different interfaces, much like I don't compare a voice interface with a mouse-oriented one.
Whether you want to use a terminal emulator on your phone doesn't change whether it's available.
I wouldn't want to use a clumsy web app with dangerous buttons that put me a single mis-touch on a poorly thought out touch target away from messing up/rebooting/powering down a server from my phone either, but that doesn't change that cockpit is available.
> Sure then compare cockpit with other webmin-esque tools, not a terminal emulator.
You compare it to the options available, which includes both terminals and webmin equivalents.
I don't know if there's much of a space left for cockpit or webmin equivalents though. There's hypervisors with dedicated UIs like Proxmox and oVirt, but that's not the same.
Seems pretty cool to me, "meet your users where they are" and all that.
I actually wonder what other options for this sort of web based management panel there are out there, maybe more DEB oriented ones.
I hate the mouse so much that I've got a script to move it off-screen (it follows my focus), and I usually live in my terminal. But trying Fedora on one of my Pis I tried cockpit since it was installed by default and I'm surprised how much I like it.
I think the lack of features is a good thing, there's not much bloat and it recommends extra packages I could like. While i love my terminal cockpit has been nice to get a quick glance. So far the only thing I'm missing is support for doas.
Every tool does not have to be able to do all the things.
"Instagram filters are for people who don't know how to work with Photoshop layers, don't understand basic color blending operations, and who just want to swipe."
I mean, yes.
But I may have a problem with people who can't do a bash for/while loop or understand pipe chaining commands be responsible for administrating my company servers.
I don't see how the comparison between adminstrating servers and sharing pictures on social media is a useful comparison.
I suspect most people here used the HN web interface to post their comments, even though constructing an HTPP request to send to HN using curl to post your comment wouldn’t be significantly harder. The fact that they used the point and click HM Web UI doesn’t mean they’re incapable of constructing such a request where it actually is needed.
Reminds me of a colleague I met once who was happily boasting he's a 'real' HTML developer because he writes everything in Microsoft notepad. I took a look at his work and cried inside - broken tags, bad formatting and of course he didn't escape all his characters correctly.
Being able to type some characters on a keyboard does not make anyone superior to a user that uses a point+click interface.
There isn’t a causal relationship, but the two are heavily correlated. Getting deep into the details of most server software means doing so via CLI, because the people who built the software intended it to be used there, since servers are usually headless.
Even if you run a DE, chances are high you’ll still end up editing some config files in a text editor, and running commands in a terminal emulator.
It’s a bit like [n]vi[m] - learning its esoteric commands doesn’t make you good at coding or ops, but there’s a decent chance you wouldn’t bother to spend the time learning it unless you needed the speed increases it grants you.
I don't think like that at all. Of course someone can know bash for/while loop and still choose to use a point-and-click tool to administrate their servers. Nothing wrong with that.
Not sure where in my message did I say that if someone chooses to point and click, then they don't know what a bash for/while loop is.
What I said in my comment is that if someone doesn't know what a bash for/while loop is, then I may be uncomfortable adminstrating my servers.
My point was to show that comparing adminstrating servers and sharing pictures on social media is not a useful comparison.
Anyway, what has that got to do with my point though that sharing pictures on social media is not a meaningful comparison to make with something like administrating servers?
idk what kind of legacy orgs people in this thread work for where there are Linux sysadmins working for their companies which directly manage server configs and security settings. "Administering my servers" is an interesting phrase in 2023, because there often aren't any servers to directly administer (even a VPS is hard to find). The last few companies I worked for all used some kind of virtualized infrastructure and usually through some kind of declarative interface (Docker, Kubernetes, or some terraform-style tool). Certainly, the people who OWN the servers have sysadmins managing these things, but such things are an abstraction these days, where many organizations don't have to deal with CLI configuration and bash, and just leave infrastructure to devops or even the developers themselves
Which unfortunately is a problem in itself. A lot of core knowledge is lost and many people running infrastructure don't know how to read actual logs and debug outside of what the GUI shows. Just like you mention it's not even VPS these days it's a Dockerfile pushed to some cloud.
Copy/paste a Dockerfile, edit some yaml for the CI and claim you know DevOps. It's a shame really. I don't mind a nice minimal GUI when it makes sense, but it's important to understand the pieces below it.
Plenty of k8s users are accessing their services and logs through CLI. It's just that the relevant logs are from the application and not whatever the underlying infrastructure is. It makes it way easier to have amazon deal with the underlying server and just let me focus on the actual application. Saves labor costs (in theory) by not having to hire an IT guy, and you can put more faith in the security practices of the cloud providers than in your own organization.
Your criticism reads like old school developers complaining about new devs learning Javascript without learning C or Assembly. Technology progresses, the set of baseline skills required to do your job changes. Few software engineers know anything about hardware or electrical engineering, but that used to be a requirement many decades ago.
> Copy/paste a Dockerfile, edit some yaml for the CI and claim you know DevOps. It's a shame really. I don't mind a nice minimal GUI when it makes sense, but it's important to understand the pieces below it.
What you've described is a way to make it dead simple for engineers to develop code without having to interface with a human being (a sysadmin) in between. It makes deployments consistent and easy. When you add CI/CD into the mix, you don't even need to run the command anymore, you just merge the master and swap your staging and production instances. Amazon can hire the sysadmins, the client can hire engineers.
Valid point, but I'm a javascript dev tired of helping my peers figure out their tools when they're not even interested in discussing lower level topics on a normal day. I wish I had some grumpy old-timers around me to learn from.
> It makes deployments consistent and easy.
Consistent on the platform chosen at start, if you run into egress costs you might already be locked in to that platform and migrating AWS container format for every service might take time for those who don't understand what it does exactly. One simple mistake can be really costly if you forget to set limits. It's dangerous to put too much power in the hands of people who don't understand the possible consequences.
Don't get me wrong, I like modern software dev and day to day tasks should be easy. But too many people are lazy and uninterested in the details behind their craft. "Just install half the universe, why bother reinventing the wheel" is too common. You're not a DevOps unless you can setup and manage the workers on a CI on bare metal, you shouldn't always go that route in production though, but the knowledge is important.
It’d be great if JS devs could learn JS, but I’m not holding my breath.
Your comments read like someone who doesn’t believe you need to understand how the abstractions work, which tends to end in failure (or extremely high cloud bills).
I don't know if you consider Amazon/AWS "legacy org". When I worked there I didn't think it was a legacy org. Yet they needed skilled Linux sysadmins. Sure they are called by fancy names like infrastructure engineer, production engineer, etc. but the work they did used core Linux kernel skills, scripting skills and programming skills, just to name a few of the skills.
A few years later I worked for another cloud provider and it was no different. I don't understand why you think only legacy orgs care about good system-administration skills.
Abstractions leak. They’re great, but you still need to know how they work.
You could have godlike Photoshop skills and it will take orders of magnitude more effort to get results. With SSH and shell scripts you'll likely be faster than the web UI once you're skilled enough. And it's easy to automate.
Genuine question.
What would that be? I'm always on the lookout for better tools.
Even being in a leadership position and basically competing within Red Hat against this, I found no answer to your question.
Meanwhile I'm happier doing everything on command line on Linux, understanding and learning all its features has been worthwhile. But I can imagine some people just want a server set up and to get on with their day.
Cockpit is okay but it's basically Red Hat's equivalent to the Windows Server Manager tool, and I have no doubt it was directly inspired by Server Manager. It's development and improvement over the years has been painfully slow.
Nobody who is comfortable with an ssh session uses Cockpit, except maybe to create new VMs, and even then all of these comments comparing it to Proxmox are just whack because it doesn't have a quarter of the features the Proxmox UI offers. The utility for managing VMs is a recent development and even then I still prefer the Virtual Machine Manager tool because I don't want to deal with the latency increase and other limitations of working through a browser.
But anyway, there's a ton of things you can't do with Cockpit, and never will be able to do. It's for people who want to point and click, can't do a bash for/while loop, don't understand pipe chaining commands, and don't like using vim.
Like happyweasel said, it's basically webmin for Red Hat.
It's kinda cool, but it's so old now and development has been so slow and it's been so over-hyped that I don't pay attention to it at all and I've never used it except what was required to get certified.