Could be an interesting project, but as @stephdl pointed out, lets wait and see if this matures into a viable administration tool.
@davidep has studied it and he could add more info about it
Cockpit has a beautiful architecture, tightly integrated with the underlying system and allows managing multiple servers from the same interface. It is light fast and I love the way it handles user privileges.
It is a RedHat sponsored project and comes with Fedora Server by default. In the future it can become the base for the current Server Manager, so I hope to check it out in depth soon!
This would be definitely of value for SME customers.
Great tool it would be nice to have it.
Great interview with Stef Walter
and an interesting post about The Ideals of Cockpit
I think that it should be a must-have for the new NethGUI
I repeat … somehow, you are spying on me
I had just read the interview and i had installed cockpit preview on a ns7alpha just to see it
(btw the container section seems nice)
ahahah no dude, really! No spyware installed
and? How it looks?
yeah i know, i know
looks nice, and it works also with multiple ns7alpha…
if you want to try it on ns7alpha:
$ wget https://copr.fedoraproject.org/coprs/g/cockpit/cockpit-preview/repo/epel-7/msuchy-cockpit-preview-epel-7.repo $ cp msuchy-cockpit-preview-epel-7.repo /etc/yum.repos.d/ $ yum install cockpit $ config set fw_cockpit service TCPPort 9090 access public status enabled $ signal-event firewall-adjust $ systemctl start cockpit.socket $ systemctl enable cockpit.socket $ systemctl start docker $ systemctl enable docker https://IP:9090
ah… and changing hostname from ns webui seems to change the transient hostname and not the Static hostname…
edit: updated service key as suggested
Hi @dz00te, great shot!
Did you also try the version from
On your command list I’d add
fw_ to the service key, to be compliant with http://docs.nethserver.org/en/latest/third_party.html#firewall
config set fw_cockpit service TCPPort 9090 access public status enabled
WOW, successfully started a
nethserver/docker-demo container from Cockpit
You’re making me extremely curious
I would like to revive this discussion and have (another) serious look at cockpit. I just think it is AMAZINGLY easy to use and if you want to add an extra feature to your server, just look at the docker repository and it is 1 click away.
I am going to try this on both Ubuntu (Karoshi and Zentyal server) and CentOS (NetServer) servers the coming weeks.
Of course, since it is so easy to add and use, it could be installed just on a NethServer, but a real integration would be an admins wet dream…
Een bericht is gesplitst naar een nieuw topic: Install cockpit on NethServer 7b2
Any experience with cockpit is welcome! I’ll join your initiative ASAP after ns7 Final release!
I reply here regarding the e-smith layer and its implications
In cockpit, when you change a parameter (for example IP address) the change is in real time, just like you do via CLI
In NS, when you change a parameter, its value is stored into a database and one or more events is/are triggered, making all involved services work in a transparent manner
In cockpit, when you change a valute, almost no service is aware of the change
So the conclusion of this phenomenon is that you stay off any settings of the NethServer you run Cockpit on and only use it to easily deploy docker containers? Or would there still be options to manage the local NethServer (and maybe multiple remote NethServers)?
thnx anyway for this clear comment. It points exactly to the power and limitations of Cockpit.
I guess that the disk management panel of cockpit can help also
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
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:
Contribute to the underlying systemd-timesyncd to do what you
would expect, and call out once configuration changes.
Implement your own timedated based DBus API replacement, much like
the timedatex project did.
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
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:
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.
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