Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cockpit: Web-based graphical interface for servers

cockpit-project.org

Post reply on HN
Print view View original

131–140 of 199 posts

Re: Cockpit: Web-based graphical interface for servers

#131

Post by worksonmine »

shortrounddev2 wrote: post #118
distcs wrote: post #86

Earlier quoted context omitted.

That is totally fine. I was talking about people who CANNOT do a bash for/while loop. You are talking about people who CAN do a bash for/while loop but choose not to. We are talking about different types of people. I am comfortable with the latter type of people administrating my servers. I am not comfortable about the former. Anyway, what has that got to do with my point though that sharing pictures on social media…

> I am comfortable with the latter type of people administrating my servers. I am not comfortable about the former. 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 (…

> 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)

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.

Re: Cockpit: Web-based graphical interface for servers

#132

Post by 9dev »

talent_deprived wrote: post #122
tanelpoder wrote: post #41

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...

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" Wi…

What exactly is "garbage" about this? It's so tiring how systemd opponents insist on name-calling instead of substantiated criticism.

There is no reason every single application should manage network socket acquisition on its own - I'm not very fond of the times everyone and their mother wrote whacky shell scripts to start and stop their services, either. But somehow those seem to be the "good old times" you guys miss.

Re: Cockpit: Web-based graphical interface for servers

#133

Post by brancz »

TwoNineFive wrote: post #40

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…

I was architect leading all things Observability at Red Hat until 3 years ago there was an absurd amount of support for this project internally I never understood it either. But there were huge amounts of customer support, sales and engineers who adore this thing, I genuinely don't understand the appeal when we had next level cluster-wide Observability supported on and off OpenShift.

Even being in a leadership position and basically competing within Red Hat against this, I found no answer to your question.

Re: Cockpit: Web-based graphical interface for servers

#135

Post by berkes »

belthesar wrote: post #128
jameshart wrote: post #107

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.

Are there any tools that allow you to manage a server like a pet, yet ensure it can be restored/rebuild?

And, while with the analogy of pets, when you are on holiday, allow your neighbors to look after your pets?

Re: Cockpit: Web-based graphical interface for servers

#136

Post by all2 »

9dev wrote: post #132
talent_deprived wrote: post #122

Earlier quoted context omitted.

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" Wi…

What exactly is "garbage" about this? It's so tiring how systemd opponents insist on name-calling instead of substantiated criticism. There is no reason every single application should manage network socket acquisition on its own - I'm not very fond of the times everyone and their mother wrote whacky shell scripts to start and stop their services, either. But somehow those seem to be the "good old times" you guys mis…

I don't think its a systemD thing. This sounds more like an issue with changing a server's behaviour without asking.

Re: Cockpit: Web-based graphical interface for servers

#137

Post by shortrounddev2 »

worksonmine wrote: post #131
shortrounddev2 wrote: post #118

Earlier quoted context omitted.

> I am comfortable with the latter type of people administrating my servers. I am not comfortable about the former. 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 (…

> 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) 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…

> 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.

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.

Re: Cockpit: Web-based graphical interface for servers

#138

Post by belthesar »

berkes wrote: post #135
belthesar wrote: post #128

Earlier quoted context omitted.

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.

Are there any tools that allow you to manage a server like a pet, yet ensure it can be restored/rebuild? And, while with the analogy of pets, when you are on holiday, allow your neighbors to look after your pets?

In my homelab, I use Portainer to manage my hosts. All of my workloads are installed as collections of Docker containers, and I'm slowly but surely migrating even single container installs to Compose stacks. With some real bare bones GitOps, those stack files can be in Git, and deploy to the host in Portainer, thus at least giving me the recipes to rebuild my environment should it ever be lost.

Re: Cockpit: Web-based graphical interface for servers

#139

Post by codedokode »

barosl wrote: 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.

Socket activation means that every application must be modified so that it can run both with activation or without. So you need to patch every application for compatibility with systemd. And if tomorrow there will be an alternative system daemon, you will have to patch everything again?

Re: Cockpit: Web-based graphical interface for servers

#140

Post by JAlexoid »

smetj wrote: post #46
tanelpoder wrote: post #41

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.

TBH - for any non-server class machine on my network, I'm fine with that.

SSH should probably be running 24/7 on any server(to keep those resources allocated for maintenance access), but if it's my workstation with a monitor - then it's a non-issue.

Post reply on HN