LWN: Comments on "Managing Linux servers with Cockpit"

Managing Linux servers with Cockpit

ballombe — Sat, 23 Mar 2024 17:45:22 +0000

> Perl has not been a required component of the platform since python3 effectively took over nearly every instance of it's utility, including becoming the defacto dependancy of nearly every package management system besides openwrt and slackware style tarballs.

You forget Debian and Ubuntu... perl-base is Essential: yes.

Also in shell scripts, having to rewrite perl one-liners as awk one-liners is not a progress.

Managing Linux servers with Cockpit

dsommers — Thu, 21 Mar 2024 19:15:45 +0000

Cockpit is not running on the system when not used. When you need it, the needed services starts. When they don't need to run, they stop automatically.

When you log in, you have the same privileges as if you logged in via ssh or on a physical console. This goes through the standard authentication and authorisation steps as any login on the system. Cockpit is this way more or less just a graphical view of what you can do with command line tools.

In a setup with distributed authentication (SSO, ssh keys, etc), you can log into the web portal on one host and manage other hosts from that single point.

These days Cockpit is has packages available on the majority of larger Linux distributions. And the user experience will be pretty much the same across all distributions, even across versions. Naturally, if one version on one host lacks features available in a newer version, that feature won't be available.

Using Cockpit is an instant experience. Changes can happen in the moment you click a button, not when the web server has parsed a request and done some operations on the server side. How? The webview you see is essentially a D-Bus client which interacts instantly with the service you really want to modify.

D-Bus policies and polkit handles the authorisation, so unprivileged users will not be allowed to do operations they are restricted from. That means, the "web channel" between your browser and the "web server" merely passes data. It does not do any security checks itself; that is handled by the standard authentication and authorisation stack which the console logins, GUI desktop logins, ssh, etc already depends on. Cockpit itself does not need to start any privileged support service on its own; it leverages from what is already on the system from before.

Webmin is an entirely different beast. Last time I used it (which is veeeery long ago, though), it started with needing to set up a web server capable of running PHP. And that PHP code would run commands, some which would require sudo-type run environment. And that was started from PHP code on a web server with its own authentication and authorisation approach. So, an attacker capable of tricking that with whatever PHP or web server vulnerabilities available, could pass all security checks and run arbitrary executables with privileges from an unprivileged account.

Because Cockpit doesn't need to run the web portal with any kind of privileges, it's not vulnerable to those type of attacks, since the authentication and authorisation is only triggered, not performed, by Cockpit.

Authorship

corbet — Thu, 21 Mar 2024 14:25:39 +0000

The article was written by an LWN staff member — one who has been involved with the site in various ways for for over 20 years — with no involvement by any other company. If you did not enjoy it then I am sorry, and we would be happy to hear about how you think it could have been done better. But please do not suggest that it was some sort of paid placement; LWN has never done that in its history.

Managing Linux servers with Cockpit

jnabasny — Thu, 21 Mar 2024 14:08:06 +0000

I was excited to see the subtitle of this article in the weekly mailer mention "new features,"
but the only new developments mentioned were bug fixes. Moreover the entire article reads like a plea from RedHat for community contributions or a sales pitch for Cockpit. No wonder it was written by a publicist at RedHat. I've come to admire the deeply technical and community-focused articles in LWN over the years. Unfortunately this article does not fit that mold and I hope it is not a sign of more to come.

Managing Linux servers with Cockpit

lis — Thu, 21 Mar 2024 08:16:21 +0000

> This is also why the cockpit-python bridge is "new and interesting" and also, from my perspective, a possible security issue. The old bridge was C, but written mostly defensively.

Neither the C nor Python bridge acts as a security boundary in any way whatsoever. The protocol is "run this command", "write this file", "make this dbus call", with no restrictions. Keep in mind that once you're logged in to Cockpit, you can easily flip over to the terminal window and do whatever you want as the account you're logged in to, and this is by design. The bridge is in the business of doing *anything* you ask it to do. It's up to the kernel to impose the restrictions (as the currently logged in user).

The bridge only starts running after you've successfully logged in. The actual security transition there is managed by a very small C program (cockpit-session). In many cases (and increasing) we actually use ssh as the way to log in before running the bridge, in which case the security is down to ssh.

Managing Linux servers with Cockpit

andreashappe — Thu, 21 Mar 2024 07:28:31 +0000

My use-case: occasional remote web-based managed of virtual machines on a small embedded computer that I use as a home server. While I do most of the administration through SSH, it's sometimes very nice to have a web-based overview of the system-state, web-shell into the different VMs if something broke, etc.

Why not webmin? Because I don't want it to manage my system but prefer a slim and minimal add-on (that not even has it's own user database) that reuses as much of the system as possible.

Oh, the home-server is running debian, not fedora or redhat BTW.

Managing Linux servers with Cockpit

Kamilion — Thu, 21 Mar 2024 03:02:58 +0000

That probably came off a bit too snarky towards someone who is admittedly hobbying around from the raspberry pi side of the culture that has arisen "recently."

So! In the interest of meeting you in the middle of the ELI5 request, I'll hook you up with my meandering opinion of thirty years of painful mistakes in technology.

First system I had to myself was an Atari ST. All GUI, no commandline. Had TRS80 & C64s around to "learn" basic on, but never leaned on it. Knew basic would be fruitless in the future. DarkBasic and Gambas3 are the last remnants, and are slowly dying as maintainers lose interest.

I thought it would be a good idea to learn some scripting skills around the turn of the century. Grabbed myself the newest shinest book about it: Perl 6 and Parrot Essentials, first edition.

I cannot possibly explain to you exactly how bad of a mistake this was.
I'll put it this way: there is a reason perl5 is still a package in most distributions, and there is not a perl6 package.

Okay, I said, it can't be as bad as I think, this Ruby on Rails thing seems popular...
Now ruby has kind of a... not so great reputation. It's "still around" but, after twitter dropped it, it "popped like a zit".

I'm not even sure where Rails went after they removed the 'scaffold' system around 3.0.

At that point, I started learning PHP4/5. Now, with the context of what I had touched before? This was a hot garbagefire. Get a line of code wrong? white page render. Wanna debug stuff? throw random prints in. Logging framework? Objects? Nope. you *could* but nobody did yet. But I tried. I found OOP packages, worked my way up into getting deep into WHMCS billing package for a VPS provider, and have dived unfortunately deep into the invision files over the years.

PHP leaves nothing but sadness in your heart. Sometimes it leaves money in your wallet.

Hark, what say thee, stack exchange, forsooth shall i continue my quest for sanity in templated web tooling?
"hey, if you messed with sinatra for ruby, try this flask joke for python, it's just one file."

Soon, I found joy in scripting again. Grand python class trees with flask-classy/classful.

The code made sense, the output looked... better than my early scaffolded rails projects...

There were no pickles, I refused to apply financial SQL databases to plain content that a filesystem could address behind nginx better.
Flask and jinja have truly stood the test of time for me -- nearly a decade in production and the only failures we've had has been uplink related.

So when I say "python's pretty alright from a security perspective so long as you don't step on the big five landmines", I mean it.

But still, I'll rewind back to 2012 for a moment more; I don't buy raspberry pis because I personally dislike how broadcom has treated the linux community for two decades. I inherit them from others, but my collection of SBCs has only expanded because of that personal opinion. Allwinners, Amlogics, Mediateks, Rockchips, *anybody that will support linux more than broadcom used to*... Well, not allwinnner *anymore* but that's here nor there. The other three are visibly working hard in the community.

As such I've been exposed to a *lot* of arm distro roots, way back to the NSLU2 and rootfs endianness.

Cockpit's actually been around on more of them than I expected. I've found bits and pieces of it all over the place, since about 2017.
As an authentication service against the machine accounts, it seems to be pretty popular.
It's also used in that context for openSUSE's agama although it's most likely on it's way out, if it's not been extracted already.
https://github.com/openSUSE/agama/discussions/1000#discus...
And in that comment, it's alluded to the fact that future releases of the Anaconda installer will be rebased on top of cockpit's functionality.

So it's clear that python is winning out for a significant number of reasons:
* Most of the other competitors had a sharp spike of popularity, jumped the shark, and calmed
* It has stood against the hostile internet about as well as rust or golang, the two current golden children of memory safety and concurrency, respectively.
* Erlang and elixir are not well known enough to be recognized outside of a few large public services like Discord
* It has gained extreme popularity in the machine learning space

Meanwhile, PHP had admittedly improved by leaps and bounds by version 8, but it still hurts me inside every time I see ?php tags.
A lot of PHP code couldn't upgrade to PHP6... so I still have to scream and cry every time I see a living php5 installation in the wild.
And every time someone chooses to start off learning PHP, the cycle of destruction only continues.

I honestly hate to say this, but there's some software packages that are better off dead.
Cpanel, Webmin, and WHMCS are some of those. But they just won't die. Because someone's still making money off their corpse.

I guess that was more like ELI17, but that's probably more the sort of "what happened while I was asleep under this pi hat" you were after ?

Managing Linux servers with Cockpit

Kamilion — Thu, 21 Mar 2024 02:06:38 +0000

cockpit is a thing because PHP is an abomination, webmin is an abomination, whmcs is an *ungodly abomination*, and anything even remotely adjacent to it has destroyed lives and left a path of burning servers, .well-known vulnerabilities, and a culture of refusing to learn when taught.

"We'll just do it again in laravel, and it'll be okay this time!"

Perl has not been a required component of the platform since python3 effectively took over nearly every instance of it's utility, including becoming the defacto dependancy of nearly every package management system besides openwrt and slackware style tarballs.

This is also why the cockpit-python bridge is "new and interesting" and also, from my perspective, a possible security issue.
The old bridge was C, but written mostly defensively.
Now I'm recalling the bad old days of Xen's configuration being executable python files.

"A culture of refusing to learn when taught..."

Can't blame us though. Culture's a massive mix from us old farts that remember IRQ jumper settings to the kids running steamos and mint trying to get away from the MSOffice culture.

Managing Linux servers with Cockpit

bferrell — Thu, 21 Mar 2024 01:43:39 +0000

Uh... Other than having used Webmin since the outset and finding it useful the entire time for every system I've attempted (respberry PIs included), packaged or not.

To address other comments, webmin uses the existing system admin utilities (systemd etc) so if you understand making STANDARD system admin changes, webmin does nothing extra.

I suspect a 5 year old could understand that IS they understand sysadmin tasks

Managing Linux servers with Cockpit

sjj — Wed, 20 Mar 2024 21:23:38 +0000

So you didn’t read even the second paragraph before pissing on this project. And of course it is big bad Red Hat “pushing” it into their distros - why such language?

FWIW, I want to thank the people working on this. Really nice how it works with existing tools, all you need is ssh access like a regular bastion host.

Managing Linux servers with Cockpit

adam820 — Wed, 20 Mar 2024 21:03:55 +0000

> Webmin was released a very long time ago, is under active development, updated as needed and has a active, thriving community adding modules to encompass just about anything you can imaging.

Fantastic. Glad it exists. Cockpit comes out of the box on some distros without having to install or configure anything, ready to log in immediately after installation, which can be a boon to productivity, especially if you're new to Linux and don't even know how to install a package right away. But the MOTD mentions you can manage your server at this URL... hey, it's clicky buttons! I know how to do that!

> Explain to me like I'm 5 why cockpit is even a thing? If you must, go ahead and bring up PERL.

Why is webmin a thing? Why is any software a thing? Why have 2 of thing, when 1 of thing exist?!

Managing Linux servers with Cockpit

mgb — Wed, 20 Mar 2024 19:08:33 +0000

Webmin works well if you only enable the bits you need.

Managing Linux servers with Cockpit

Cyberax — Wed, 20 Mar 2024 18:46:47 +0000

Webmin is a Cthulhu-like horror with tentacles reaching into all parts of the system to take it over. So in practice, to make it run smoothly you need to stop administering the system directly.

Cockpit is a fairly simple frontend, that integrates with the existing infrastructure. You just install it, and get a couple of additional daemons running, and that's it. Super-easy.

Managing Linux servers with Cockpit

mbunkus — Wed, 20 Mar 2024 18:20:45 +0000

My very short research of clicking through to the downloads page[1] reveals that not only does it target the usual big distros, Cockpit is even packaged & available from distro repositories for most of them.

You didn't even do the bare minimum of research. So please explain to me like I'm 5 why you're even posting?

[1] https://cockpit-project.org/running.html

Managing Linux servers with Cockpit

bferrell — Wed, 20 Mar 2024 18:16:11 +0000

Redhat developed cockpit and pushed it into their releases and from what I can tell can only be used there.

Webmin was released a very long time ago, is under active development, updated as needed and has a active, thriving community adding modules to encompass just about anything you can imaging.

Explain to me like I'm 5 why cockpit is even a thing? If you must, go ahead and bring up PERL.