Live data from Hacker News

Cockpit: Web-based graphical interface for servers

cockpit-project.org

121–130 of 199 posts

Re: Cockpit: Web-based graphical interface for servers

#121
post #36

The cool thing about this project is that as it uses systemd's socket activation, it requires no server processes at all. There is no waste of resources when Cockpit is not being used. Accessing a page is literally the same as invoking a command-line tool (and quitting it). No more, no less. What a beautiful design.

Interesting, I always thought socket activation meant defer launching a process until somebody tries to access it through the network, but... does it also finish the web server process (or whatever is used here) as well after the request is serviced?

No, it doesn't automatically close the process. Two options I can think of: Application exit when it's done with its thing or RuntimeMaxSec to make it close after a while.

systemd passes the socket on to the application so I don't think it has any reference to it anymore, so it wouldn't be able to know when the socket closes.

Re: Cockpit: Web-based graphical interface for servers

#122
post #36

The cool thing about this project is that as it uses systemd's socket activation, it requires no server processes at all. There is no waste of resources when Cockpit is not being used. Accessing a page is literally the same as invoking a command-line tool (and quitting it). No more, no less. What a beautiful design.

I ended up reading more about this and looks like SSHD in Ubuntu 22.10 and later also uses systemd socket activation. So there should be no sshd process(es) started until someone SSHs in! https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-ac...

This is messed up, totally messed up:

"On upgrades from Ubuntu 22.04 LTS, users who had configured Port settings or a ListenAddress setting in /etc/ssh/sshd_config will find these settings migrated to /etc/systemd/system/ssh.socket.d/addresses.conf."

It's like Canonical is doing 1960's quality acid.

At least the garbage can be disabled:

"it is still possible to revert to the previous non-socket-activated behavior"

With having to remove snapd then mark it to not be installed and in the next Ubuntu having to fix ssh back to the current behavior, it might be easier to migrate my servers back to Debian, or look for a solid non-systemd OS.

Re: Cockpit: Web-based graphical interface for servers

#124

Earlier quoted context omitted.

What if they CAN do a bash for/while loop, but they prefer not to because bash is the ugliest effing language they've ever seen

Actually powercrap is far uglier than Bash, for real.

Being a somewhat C/C# inspired bracket syntax, Powershell's syntax is easily better than bash's schizophrenic usage of brackets and semi-colons. Somehow it seems that the people who measure their self worth and identity based on their proclivity for typing in a terminal are also the ones who bitch the most about how long cmdlet names are. I didn't realize Linux users were so allergic to typing (not to mentions aliases and auto-complete)

Re: Cockpit: Web-based graphical interface for servers

#125

I'm an actual RHCE. This thread has to be some big Red Hatter click farm or something. The artificial positivity is striking. Is Red Hat threatening to pull funding for this project or something? Just weird. 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…

Agree, all of it, like the term Red Hatter. This cockpit-project thing came up on Reddit yesterday as well. It feels like the podman astroturfing that was so strong last year. It also feels like Red Hat hired some of Jetbrains' hyper PR astroturfers who troll the Java and webdev forums on various sites, extolling the extreme virtues of all Jetbrains' products.

Your post implies there is something obviously better.

Genuine question.

What would that be? I'm always on the lookout for better tools.

Re: Cockpit: Web-based graphical interface for servers

#126

People who decry graphical admin interfaces in favor of command line are missing the wood for the trees. Sure, clickops is no way to run a server - but neither, if we’re honest, is ssh. For a working machine, server state should be reproducible from scratch. Install an OS, add software, apply configuration, leave well alone. If you’re going in with ssh or cockpit you’re just going to screw something up. So the only r…

Both are good for different reasons. I prefer working in a terminal but I didn't think it was controversial that a GUI is better for visualization.

Re: Cockpit: Web-based graphical interface for servers

#127
post #46

Earlier quoted context omitted.

I ended up reading more about this and looks like SSHD in Ubuntu 22.10 and later also uses systemd socket activation. So there should be no sshd process(es) started until someone SSHs in! https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-ac...

Certainly for SSH I find this a bad idea. If you need to ssh into a troubled machine then it might very well be it cannot be started.

I don't necessarily think it's an outright bad idea, but it's certainly a departure from how sshd is traditionally run, and without awareness of this kind of change, this kind of "magic" runtime change could lead you to not expecting sshd to be unavailable in this kind of a scenario, and increase time to resolution during an incident.

If your systems are more pets than cattle, then I think I too would prefer an always-running ssh daemon. If your workflow is only to ssh into machines during bootstrap, however, then having sshd run only during initial bootstrap and then shut itself off does seem like a nice way to free up a small amount of resources without stopping or disabling the daemon post-bootstrap.

Re: Cockpit: Web-based graphical interface for servers

#128

People who decry graphical admin interfaces in favor of command line are missing the wood for the trees. Sure, clickops is no way to run a server - but neither, if we’re honest, is ssh. For a working machine, server state should be reproducible from scratch. Install an OS, add software, apply configuration, leave well alone. If you’re going in with ssh or cockpit you’re just going to screw something up. So the only r…

This assumes that you're running in an environment where your servers are cattle and not pets, and in all fairness, not everyone is running large scale web platforms on some orchestration platform. I don't disagree that, even in a pets world one should know how to restore/rebuild a system, because without that, you don't have a sound BDR strategy.

Re: Cockpit: Web-based graphical interface for servers

#129

I'm an actual RHCE. This thread has to be some big Red Hatter click farm or something. The artificial positivity is striking. Is Red Hat threatening to pull funding for this project or something? Just weird. 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…

Agree, all of it, like the term Red Hatter. This cockpit-project thing came up on Reddit yesterday as well. It feels like the podman astroturfing that was so strong last year. It also feels like Red Hat hired some of Jetbrains' hyper PR astroturfers who troll the Java and webdev forums on various sites, extolling the extreme virtues of all Jetbrains' products.

I tend to not ever interact with /r/linux for this reason. It always seems overrun with corporate mouthpieces. I would really love to see a platform take this problem seriously, but I think for most of them (even this one) that would threaten the money supply either directly or indirectly. I'm tired of the "just don't talk about it" decorum when it's such a huge problem.
Post reply on HN