Cockpit – Administer Linux servers via a web browser

> a lot of tasks people try to accomplish are just bad ideas.

For most people, the point of config management tooling is to turn all their manual, bus-factor-of-one crufty legacy processes into automated, documented, centralized crufty legacy processes.

Ops people don't want a system that is opinionated or that pushes back to force them to change their process. They want a Turing-complete system, and maybe macros as well, so that they can quickly encode their hairy manual process into a hairy automated process, and get back to all the other firefighting they have to do as ops people.

I've just watched a presentation [0] linked by someone else in this thread and am quite impressed by the architecture and UX shown.

But it seems to me that Cockpit is more about monitoring and doing ad-hoc changes and not permanent configuration. I base that assumption on the fact that for example there are multiple places where one can configure network interfaces in debian and there is no cli tool or api to persist network configuration created with ip (at least to my knowledge). I can imagine parsing and editing fstab automatically and 100% correctly to be tricky too.

On the other hand enabling or disabling systemd services is permanent by default and there are probably more cli tools that automatically persist changes done through them.

Can anybody more familiar to Cockpit shed some light on the persistence of most of the configuration options?

[0] https://media.ccc.de/v/ASG2017-99-cockpit_a_linux_sysadmin_s...

It was a workshop, but no videos that I'm aware of.

It was essentially "here's how to use React to build a cockpit plugin from the ground up -- it's easy"

I'm a Python/Go backend developer, mostly, but Cockpit is easy enough that even I can write plugins for it. The workshop basically walked through the git tags in https://github.com/evol262/cockpit-boilerplate

cockpit-ovirt has a "Hosted Engine" tab which is an otopi parser. You'd find it to present exactly the same questions/options as "hosted-engine --deploy" in 4.0/4.1, with ansible and otopi deployments and a new UX in 4.2 which isn't a 1:1 representation of the questions asked.

Once Hosted Engine is deployed, the oVirt cockpit plugin can show the complete status of the HE cluster, put nodes into local maintenance, the whole cluster into maintenance, etc.

A traditional CM tool in this new paradigm (which i'm coining App Management before somebody steals the idea) would probably become more of a configuration fulfiller (CF) in this context. It fulfills the configuration requirements that the app dictates.

The CF could modify its behavior to fit a given platform. If you're on Windows, it will do operation X in one way, and on Linux a different way. You could describe to the CF the information it needs to fulfill requests - where are the big data volumes, where are the credentials, how should it connect remote resources, etc. When the app asks for something, the CF will have just enough information to figure out how to provide it for that case.

The app can label resources however it wants. For example, if it called tmpfile("my_logfile_access"), a CF could return it a temp file, and record in some datastore that application X asked for a logfile 'my_logfile_access' and that it was provided. If you want to process logs, ask the CF where the 'my_logfile_access' file/directory is. If you abstract away the need to tag it and just have a function called logfiles() or something, you wouldn't even need to know this tag - your app could just write logs with some tag metadata, so when you go to process the logs, you figure out what it is after you've opened the logs.

Same for data, and ports, etc. Why should I have a Vagrantfile that maps ports? The app knows what ports it wants to offer. And why use numerical ports? We've had /etc/services for like 30 years and yet nobody seems to realize you can use a name instead of a port number and stop worrying about manually mapping numbers around. Honestly, so much of modern devops stuff is backwards.

Thank you very much for clearing this up.

Since I'm not familiar with networkmanager in combination with other config: what happens if I configure some network interface using Cockpit that is already defined in /etc/network/interfaces.d/*? Will it just throw an error or could it bring my system into a broken/undefined state so that it wouldn't be reachable after the next reboot?

If the latter is the case it would probably be unwise to install/use Cockpit on an already configured system.