On 27.02.2016 12:21, tdidsg@gmail.com wrote:
Hi Stef, thank you for your answer, which I missed it and saw it just now...
is cockpit "pluggable" in any way, meaning that I can creare a plugin that just alter/enhance existing modules?
for example, some features now available should be disabled or changed in their logic: changing the ntp server needs to store some info in our backend configuration db before being applied..
In general Cockpit subscribes to the idea of calling local system APIs to do its work. The goal is to be pure UI layer, and not a management system. The underlying API takes care of changing the system state as expected and storing the configuration in the correct place. Cockpit does not track or keep state/configuration on its own.
Think about it this way. The current time/date UI calls through to the timedated DBus API to configure the time. This means that whether the user uses Cockpit or the command line tool timedatectl the results will be the same, and both the UI and tools will report the new state properly.
So for this particular example, there are some options:
1. Contribute to the underlying systemd-timesyncd to do what you would expect, and call out once configuration changes.
2. Implement your own timedated based DBus API replacement, much like the timedatex project did.
https://github.com/mlichvar/timedatex
3. Contribute work to make the time/date/NTP UI replacable. A good example to follow is how the 'Join Domain' button calls into another 'realmd' module which itself could be replaced. And instead of calling timedated or systemd-timesyncd a replacement could call a custom API such as the backend db you're talking about.
However if you're thinking about doing this for *all* configuration state on the system, then you need another approach. Essentially such a system would no longer allow calling the actual system APIs to configure things, but expect calling your custom configuration db API layer, which in turn would configure the system.
or, for example, editing an user profile could involve quota management (just thinking loud about what we have now and what we'd replicate)
I would encourage you to contribute such functionality upstream so that everyone can have that option available? First step is figuring out if there a standard API, or system format that is broadly used for quotas.
and, finally, is there any way to show to a non root user just a subset of the available modules?
Hmmm, we don't have that yet. But thinking outloud ... we do theoretically have a way to specify alternate location to look up the modules, using XDG_DATA_DIRS:
http://cockpit-project.org/guide/latest/packages.html
But in practice this has caused problems, because there's no way to set that environment variable during login. I've been brainstorming with Peter Volpe about how we might come up with a per-user environment file. Needs a bit more thought. But that would solve this problem.
Stef