171–180 of 199 posts
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…
clickops is no way to run a server server state should be reproducible from scratch Why? I'm not necessarily disagreeing, but too often are these kinds of statements thrown about without any qualification, as if they are self-evident truths. But they're not -- there are engineering trade-offs behind any choice, and it's no different here. So, in order to guide this discussion away from dogmatic platitudes: why should…
Changes done are only captured at snapshot intervals and are no coherent and atomic, so you can easily miss changes that are crucial but capture destructive changes in between deltas. Worse are flaws that are introduced but not observed for a long time and are now hopelessly intermixed with other changes. Reproducible build systems allow you to use a revision control system to manage change and cherry pick changesets to resolve intermixed flaws, and even if they’re deeply intermixed you can resolve in an offline server until it’s healthy to rebuild your online server.
The issue with reproducible build systems isn’t they aren’t superior to backup and restore in every way. It’s the interfaces we provide today are overly complex compared to the simple interface of “backup and restore,” which despite its promised interface always works in the backup part but often fails in the restore. These ideas of hermetic server builds are relatively new and the tooling hasn’t matured.
I would say actually click ops is an ideal way to solve that issue. Click ops that serializes resiliently to a metadata store that drives the build and is revision controlled solves that usability issue. If the metadata store is text configs and can be modified directly without breaking the user interfaces would be necessary to deal with the tedium for complex changes in a UI, while providing a nice rendering of state for simple exploratory changes. Backup and restore would be only necessary for stateful changes, but since the stateful changes aren’t at the OS layer, you won’t end up with a bricked server.
Earlier quoted context omitted.
I've not noticed any dependencies on NetworkManager when using Cockpit for VMs on Debian? My servers configure their networking using Debian's usual ifupdown, and NetworkManager isn't even installed!
What Cockpit version? Maybe it is compiled differently on RH-based distros.
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…
FTP, SMTP were all stateful, so living under inetd worked OK. One process per overall session rather than individual messages within a session.
Obviously, inetd could have been hammered on to basically consume the pre-forking model then dominant in something like Apache, caching server processes, etc.
But it wasn't. Then databases became the other dominant server process, and they didn't run behind inetd either.
Apache + CGI was the "inetd" of the web age.
Earlier quoted context omitted.
Distribution upgrades have never been an unobtrusive thing. Despite this, everything will continue working exactly as configured before the upgrade, which applies new configuration recommendations by the vendor. What is wrong with that?
What's wrong is the config file moved. If a sysadmin is used to a config file being somewhere they know, and then it disappears that can be extremely frustrating. Especially on a production system.
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…
This sounds like the dream.
Earlier quoted context omitted.
Sure. I used to be one of the ideological ones using Devuan. "A number" being the operative word here. It's a small number, and for a pretty good reason. I get there is an important reason to have choice, but bragging about how you don't use systemd is just meme-y and comes from a place of (misplaced) elitism usually.
>I get there is an important reason to have choice, but bragging about how you don't use systemd is just meme-y and comes from a place of (misplaced) elitism usually. I think you're projecting. No one bragged about such a thing, they just merely mentioned their specific situation. It's not all text-editor-wars and squabbles, as stated and even acknowledged before : there exist reasons aside from nerd elitism to choos…
name one.
For self hosting a NAS, I find Cockpit to be leagues better than OMV.
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…
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).
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 (…
Abstractions leak. They’re great, but you still need to know how they work.