What do you think about cockpit?

Feature
21

We (@edoardo_spadoni, @giacomo and I) are running some experiments with Cockpit. I’d like to discuss a prototype during the Community Conference in September.

3 Likes
22

I paste here what Cockpit’s creator, Stef Walter, wrote me more than a year ago (in the meanwhile almost nothing changed in Cockpit regarding my original questions)

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.

    GitHub - mlichvar/timedatex: D-Bus service for system clock and RTC settings

  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

IOW, using Cockpit as a framework for a server manager UI (as intended in NS) will need a totally new API layer… de facto, rewriting Cockpit itself

4 Likes