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

141–150 of 199 posts

Re: Cockpit: Web-based graphical interface for servers

#141

Post by distcs »

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

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

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.

Re: Cockpit: Web-based graphical interface for servers

#142

Post by JAlexoid »

It's "meh" level of quality, though. Useful for a very small subset and I would avoid it, if you're running a home server. (Cockpit's file server interface plugin is old and bad)

I don't really know what you'd use it for? Maybe to do minor monitoring, but it's not great to admin.

Re: Cockpit: Web-based graphical interface for servers

#143

Post by omgmajk »

xenator wrote: post #10
LanternLight83 wrote: post #3

Love it-- but since I'm not using systemd, it's a no-go. Would love to see it support more diverse systems, but last I checked it's pretty tightly coupled and I'm not sure who would have the bandwidth to adapt it.

Why you don't use systemd? Anything against it?

Systemd is still a sore spot for some people, in some ways me included, but I'm over it and use it daily.

Re: Cockpit: Web-based graphical interface for servers

#144

Post by bityard »

arghwhat wrote: post #48
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.

To be fair, we've had this since BSD4.3 (1986) through inetd - which worked slightly differently, but same overall idea. Once popular, it fell out of fashion because... Well, there isn't really any reason for it. A good server process is idle when nothing is happening, and should be using miniscule real memory that should be easy to swap out. If the server in question uses significant memory for your use-case, you al…

Around the time I was first learning Linux, I recall reading that there were two ways to run a service:

1. Start the daemon on boot and have it running all the time, like some undereducated neanderthal.

2. Configure your system to run a daemon which monitors a port/socket and starts up only when there is traffic, like a civilized person.

I believe which one of these to use is highly dependent on your resources, usage, and deployment model. For services that are fast and cheap to start but are rarely used, #1 makes more sense. If you have a server or VM which only does one thing (very much the norm, these days), then running just keeping that service running all the time is easier and better for performance.

Re: Cockpit: Web-based graphical interface for servers

#145

Post by marginalia_nu »

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.

Arguably, about 80% of those running their app on a cattle farm should really have gone with a pet cafe instead. Resumes would certainly be a lot less impressive, but they'd also have a lot less fires to put out and a significantly smaller infra bill.

But regarding the topic at hand, I don't think being able to manage these things with a graphical interface is necessarily a bad thing. It's basically user-space iDRAC/IPMI.

Re: Cockpit: Web-based graphical interface for servers

#146

Post by worksonmine »

shortrounddev2 wrote: post #137
worksonmine wrote: post #131

Earlier quoted context omitted.

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

> Your criticism reads like old school developers complaining about new devs learning Javascript without learning C or Assembly.

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.

Re: Cockpit: Web-based graphical interface for servers

#149

Post by bityard »

mrweasel wrote: post #39
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.

I should really spend more time learning systemd. The more I look into it, the more cool and useful features I discover.

If you have anything at all to do with OS administration, management, or software packaging, it's worth it.

If I could offer a little advice: The systemd man pages are useful as a reference, but are terrible to learn from. Part of this is because there are parts of systemd that everyone uses, and there are parts that almost nobody uses and it's hard to guess which these are at first. Also, the man pages are dry and long and quite often fail to describe things in a way that would make any sense whatsoever to someone who isn't already intimately familiar with systemd.

Most of my systemd learning came from random blog articles and of course the excellent Arch wiki.

Re: Cockpit: Web-based graphical interface for servers

#150

Post by shortrounddev2 »

distcs wrote: post #141
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 (…

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

Yes, obviously the people who offer the virtualized infrastructure are going to need the sysadmins. I'm talking about the majority of businesses and engineers which aren't cloud service providers, but rather customers of those providers.
Post reply on HN