Hi all
first of all thank you for this really impressive piece of code.
Premise: I'm a contributor of Koozali SME server linux distribution (http://www.koozali.org); ATM our distro is C6 based, but we (finally) starting moving to C7 we need to rethink/redo our server manager (from here S-M) web gui and cockpit come to our attention.
the idea is to use cockpit as a base for our S-M, but we need to know if it supports some kind of customization.. we don't want to create "our" cockpit, just enhance it via plugin, trying to stay adherent to the upstream version
I have some question: 1) I know that branding is possible/quite easy, but, for example, I didn't find any way to change the background color of the main bar, on top of the page.. I see that all the style is inline.. is it a choiche? is editing that code the only way to change colors/fonts and so on? 2) is there any way to "override" some features? for example, I'd like to replace users' logic creation with mine; is it feasible? moreover, is possible to disable/hide some elements (buttons or a single menu item in the left bar)? 3) OTOH, is there an easy way to enhance an available panel with some custom buttons/elements?
IIUC, supposing that only root will have access to cockpit, I can override an existing module just creating a new one in ////root///.local/share/cockpit/ /dir.. am I right?
thank you in advance for your patience and attention.
Ciao S.
On 04.02.2016 11:34, Stefano Zamboni wrote:
Hi all
first of all thank you for this really impressive piece of code.
Thanks. Appreciate that.
Premise: I'm a contributor of Koozali SME server linux distribution (http://www.koozali.org); ATM our distro is C6 based, but we (finally) starting moving to C7 we need to rethink/redo our server manager (from here S-M) web gui and cockpit come to our attention.
the idea is to use cockpit as a base for our S-M, but we need to know if it supports some kind of customization.. we don't want to create "our" cockpit, just enhance it via plugin, trying to stay adherent to the upstream version
Yup, Cockpit supports plugins and customization. You can add stuff to the sidebar, or dashboards to the top navbar:
http://stef.thewalter.net/creating-plugins-for-the-cockpit-user-interface.ht...
I have some question:
- I know that branding is possible/quite easy, but, for example, I
didn't find any way to change the background color of the main bar, on top of the page.. I see that all the style is inline.. is it a choiche? is editing that code the only way to change colors/fonts and so on?
On the login page most of the styling is inline, to very simply serve a page without authentication or requiring access to the packages. I think it should be able to put CSS in the branding with the flag "!important" that would override the styling on the login page.
- is there any way to "override" some features? for example, I'd like
to replace users' logic creation with mine; is it feasible? moreover, is possible to disable/hide some elements (buttons or a single menu item in the left bar)?
Yes, definitely, each part of Cockpit is its own package, including the local user modification stuff. See 'cockpit-bridge --packages' for a list of the packages installed. Here's the documentation:
http://cockpit-project.org/guide/latest/packages.html
For example, if you put a package in /usr/local/share/cockpit/users (ie: the same name as the one installed by default in /usr/share/cockpit) then it'll be used in its place.
- OTOH, is there an easy way to enhance an available panel with some
custom buttons/elements?
Yup, see this documentation:
http://cockpit-project.org/guide/latest/packages.html
Or this example:
http://stef.thewalter.net/creating-plugins-for-the-cockpit-user-interface.ht...
IIUC, supposing that only root will have access to cockpit, I can override an existing module just creating a new one in ////root///.local/share/cockpit/ /dir.. am I right?
Yes, that's possible. In addition see /usr/local/share/cockpit above.
Stef
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..
or, for example, editing an user profile could involve quota management (just thinking loud about what we have now and what we'd replicate)
and, finally, is there any way to show to a non root user just a subset of the available modules?
thank you, your work is really, really amazing.
ciao S.
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
Il 02/03/2016 14:42, Stef Walter ha scritto:
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.
Hi Stef.. thank you for your answer and your point of view
I/we will reflect and then decide..
anyway, I personally will continue to keep an eye on cockpit.
Thank you
Ciao S.
cockpit-devel@lists.fedorahosted.org
-
Stef Walter -
Stefano Zamboni