161–170 of 199 posts
I've been using this from time to time on my laptops repurposed as home servers. Mainly for monitoring. Spinning up a VM or container here and there. Too bad they removed Docker support. To hell with Podman.
Why to hell with podman? I'd rather use something not encumbered by shady licenses.
Why use this when Webmin has done the job for decades? https://webmin.com/
God I hate these comments. "X exists so why would anyone ever build Y". Why not? Competition is good, think about it for a minute and I'm sure you'll figure out how.
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…
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 server state be reproducible from scratch? What does "from scratch" mean? Why is clickops no way to run a server?
Install an OS, add software, apply configuration
Do you think this captures "server state" completely? Software patch levels are not part of server state? What about application data? User data?
So here's my counterstatement: for any working machine, I can reproduce the server state exactly by performing a restore from backup. Backup/restore is perfectly compatible with clickops, and it's faster and more reliable than reinstalling an OS, adding software and applying configuration -- even when the software and configuration are scripted. And if your server stores non-volatile data, as is often the case in clickops environments, you will need to have a backup system anyway to restore the user data after deploying a new server.
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…
It's because different people think in different levels of abstraction. One admin might be thinking about a handful of servers and another an entire fleet of VMs. The way you manage each is very different. Clickops can work well for a small number of servers and a full orchestration setup can be over engineering.
But your real issue is that blanket statements never work in such scenarios. However, I think it's pretty well established that reproducible server state is a best-practice. How you get there is up to you.
But as an argument against backup/restore -- you can't use backup/restore to generate new servers from an existing template without some kind of extra scripting (if for no other reason to avoid address/naming conflicts). And if you're already scripting that...
Earlier quoted context omitted.
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.
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?
The reason that (some) people don't do this is the cost/benefit analysis looks kind of weird. You'll spend a lot of time mucking around in puppet/chef/ansible/whatever for a single snowflake server, and it would be a lot faster to just go edit that config file directly.
In reality, proper backups and shell history can get you pretty far if you ever find you need to replicate a snowflake.
Earlier quoted context omitted.
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?
There's no reason you can't use puppet/chef/ansible/whatever on pets! The reason that (some) people don't do this is the cost/benefit analysis looks kind of weird. You'll spend a lot of time mucking around in puppet/chef/ansible/whatever for a single snowflake server, and it would be a lot faster to just go edit that config file directly. In reality, proper backups and shell history can get you pretty far if you ever…
Also Ansible is incredibly useful at my work and there's a very large overlap. Which is obviously the main motivation.
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…
Meanwhile I'm happier doing everything on command line on Linux, understanding and learning all its features has been worthwhile. But I can imagine some people just want a server set up and to get on with their day.
Earlier quoted context omitted.
I don't think its a systemD thing. This sounds more like an issue with changing a server's behaviour without asking.
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?
For others curious, https://github.com/cockpit-project/cockpit shows that it's written in several languages, with C at the #1 place, with JS and Python following. "src/cockpit" (main backend logic?) is Python.
Piggybacking off your comment I wonder how many other people really care about the tech stack used to create any product they are running on a server. What dependencies does it have? Do I need to be conscious of vulnerabilities in some logging library or Curl? And I also find it really interesting to see whether a product is programmed using one clear stack or a mixture.