
Cockpit – Administer Linux servers via a web browser - rayascott
http://cockpit-project.org/
======
maxaf
Personally I'd much rather see a GUI that can help string together snippets of
Terraform/CFN and Ansible/Chef/Puppet/Salt/whathaveyou. A visual IDE for
infrastructure automation, if you will.

~~~
sciurus
So the idea is that you would choose your changes in the GUI, but instead of
actually changing the target, it spits out the required code to do it for you
in a repeatable way?

I would definitely find that useful for Terraform and Cloudformation.
Searching for it, I see that AWS has a tool targeted at that: Cloudformation
Designer.

[https://aws.amazon.com/blogs/aws/new-aws-cloudformation-
desi...](https://aws.amazon.com/blogs/aws/new-aws-cloudformation-designer-
support-for-more-services/)

[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/working-
with-templates-cfn-designer.html)

~~~
peterwwillis
A better idea would be to spit out a spec that tools could use to perform the
thing, and get tools to follow the spec. Unfortunately, even though most tools
do virtually the exact same thing, they all use their own incompatible ways to
describe it in a config. I'm not sure why devs enjoy reinventing the wheel in
incompatible ways all the time.

For example: you have Puppet, Chef, Ansible, Salt, etc. They can all make a
directory. They do _exactly the same thing_ on almost all systems they
support, because _POSIX_.

They literally all just run this syscall: _int mkdir(const char pathname,
mode_t mode);_.

But each tool has their own goofy way of being _told_ to make the directory.
Why can't I just pass "{'mkdir': [ '/the/path/name', '0700' ]}" to all of
them? This is literally all they will be doing, and all they need to know.
Just make this path with this permission. This is declarative programming,
without a custom language!

Anything else, like directory ownership, should be an extra object, like
"{'chown': [ '/the/path/name', '1000', '1000' ] }". Again, this is literally
called the same way everywhere: _int chown(const char pathname, uid_t owner,
gid_t group);_.

You can combine the two into one JSON blob in the output of this config
management tool (that's what this GUI really is - a GUI CM with a dashboard).
You can have sets of blobs with tags that are discrete reusable pieces of
configuration. And every tool can just read them, _follow a spec based on
POSIX_ , and execute them.

~~~
kilburn
Sure, you picked the simplest possible case for a configuration management
system. Now, in this very simple case:

\- What happens when "/the/path" changes depending on the distribution? How do
you specify that?

\- What should happen if the "/the/path/name" already exists? Should the
system touch it or something?

\- What if it exists but is _not_ a directory? Should it delete whatever
exists and create a directory instead?

There is no way to define that stuff using POSIX semantics, because POSIX is
inherently imperative. "mkdir" means "make a directory", not "on this path
there must be a directory".

That mismatch in semantics is real, and each configuration management system
tries to close that gap in the simplest, most user-friendly way they can
figure out. Most have flocked towards defining their own, as declarative as
possible, API. For instance, ansible defines this as:

    
    
      - name: Ensure name's base folder exists
        file:
          path: /the/path/name
          state: directory
          recurse: no
          owner: pid/name
          group: gid/name
    

I do think that, like that snippet above demonstrates, none of them do an
astounding job at defining that API. However, I blame their failure to the
hardness of the task, not to the incompetence of the developers of
ansible/salt/puppet/etc.

~~~
peterwwillis
Well let's be clear: a lot of tasks people try to accomplish are just bad
ideas. Config management is not about having a magical tool that does
everything you want exactly how you want on 50 platforms using one config
file. Config management is just managing complexity. It works better the less
complex it is.

The example above is two basic operations: mkdir and chown. On top of those
operations are _policies_ , rules which need to be applied. And then there are
_transforms_ , where the arguments or policies may change depending on some
variables.

These are all different things that the above rule is mixing together, and
we're supposed to think this is a good thing. We pretend it's less complex,
but it's not, it's just obscured. And the end result is a lot of wasted effort
to redo the same thing.

The GUI is useful because it can craft the operations, policies, and
transforms for you, and output instructions to be interpreted and executed by
an agent. You could keep all the complexity, but make it standard among a set
of common tools. They really all do the same things - they just don't speak
the same language.

Another way to think about this is from an app's perspective. It just wants to
write to a log file in a directory, it does not care where. That's somebody
else's job to figure out - just tell me where the file is! Wouldn't it be
handy if the app had a language to _tell_ a CM tool what it needed? It
wouldn't have to say "make me file X in Y dir", it would say "give me a
writeable file that I will call 'log_fd'".

Then we wouldn't need to craft an environment for it like parents assembling a
nursery. The apps could be more self-sufficient, and the CM tools would just
do their bidding. Using a standard language.

~~~
derefr
> 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.

~~~
peterwwillis
In theory, with unlimited resources and fully automated systems, there should
be no infrastructure problems to firefight. But probably even with limited
resources we shouldn't need to firefight so much if it was engineered
correctly.

I think about cars and planes, and wonder what life would be like if we needed
a team of engineers sitting on the wing of a plane to keep it in the sky when
the pilot moves the flaps.

~~~
derefr
> what life would be like if we needed a team of engineers sitting on the wing
> of a plane to keep it in the sky

It's the world we'd be in if new planes were in such high demand that the
number of startups building them totally outstripped the supply of
aeronautical engineers, to the point that most new designs only had ~5 man-
years of effort invested in them on release, rather than the thousands they
get today.

Software is really a different world, economically.

------
LaSombra
I watched this year's Fosdem talk on Cockpit[0] and was seriously impressed.
It looks like there is a contender for an easy-to-use Linux web admin.

[0] [https://www.youtube.com/watch?v=Oq6Vbwl-
HqM](https://www.youtube.com/watch?v=Oq6Vbwl-HqM)

~~~
maeln
There is also this talk from All Systems Go! [0] that goes in details about
the architecture of cockpit :) .

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

------
kruffin
Why does it require that the server has password logins enabled? This seems
contrary to every "secure your server" guide I've seen and opens your server
up to the password guessing game. It seems like a cool product, but that's a
huge non-starter.

    
    
        The target server will need to have password based authentication enabled in sshd. When this is setup for the first time, Cockpit will ensure that the user connected to primary server has the same password on the secondary server.

~~~
dvfjsdhgfv
Probably because these "security guides" just repeat what others said without
any real consideration?

In fact, using key-based authentication just shifts the weak point from one
server to another, and, if implemented incorrectly (let's login without
passwords to several servers - how convenient!), it's a security disaster.
People need to think rather than follow recommendations blindly.

~~~
freehunter
"Common knowledge" is a big problem in the security industry, like you
mentioned. It's common knowledge that you need a 32 character randomly
generated password with special characters and numbers and mixed case, right?
But actually that's less secure, and now security folks have to work overtime
to convince people otherwise.

And it's common knowledge that passwords are super insecure and should be
replaced, but oftentimes the people replacing them don't understand that it's
possible to replace passwords with a less secure system, and don't have the
skills necessary to judge that risk.

Key-based systems do have their risks. If I compromise your dev machine
(probably using a simple password), I now have free access to all the machines
your key unlocks.

Defense-in-depth is important, as well as a strong IAM system. You need
physical security to protect your dev workstation, coupled with a strong login
system to your machine, hopefully a VPN (locked with a physical token) or
local network requirement to get onto your production servers, and then break-
the-glass methods to check out permission to escalate your privileges when
needed, followed with a keylogger for your admin session and attestation that
your break-the-glass in production was necessary.

That being said, if you're looking for a replacement for logging into your
production machines over the Internet with a simple password... key-based
authentication is lightyears ahead of what you're doing. Passwords are far too
easy to guess or brute force.

~~~
briffle
the part that gets me is that key based authentication is much, much more
secure, as long as you have a passphrase. How many 'howtos' and other sites on
the internet say to just create a key with no passphrase? Its right up there
with the number of guides I see for deploying things on Redhat, that first
have you disable selinux.

~~~
freehunter
Yeah as someone who works in the security industry, the ubiquity of security
awareness targeted at end users is both a blessing and a curse. It's a
blessing because now many more people know what key-based authentication is.
It's a curse because now people get mad when my report has a finding that
their no-passcode single key authentication system is worse than the "use your
RSA token to check out the constantly-revolving root password" system they
just replaced.

Like when people use the phrase "two-factor authentication" without knowing
what the three factors actually are and why they matter.

------
dmoreno
Does it work on non fedora/redhat? Does it need an agent on managed systems?

I'm developing a somewhat similar system[1], based purely on very easy to
develop plugins, agentless, and integration with third parties where needed
(Prometheus, for example).But without big corporate backup it is being
difficult to keep the development pace.

[1]
[https://github.com/serverboards/serverboards/](https://github.com/serverboards/serverboards/)

~~~
guhcampos
I've used it before on Ubuntu and it worked just fine. As far as I understand,
Cockpit deals directly with Systemd and Docker, so any system based on Systemd
should just work.

~~~
evol262
Again, Cockpit does not explicitly deal with systemd.

Cockpit deals with dbus, and systemd is conveniently available there
(hostnamectl, etc). storaged, networkmanager, and other functionality is not
dependent on systemd, so it's really just the system journal, changing the
hostname, and checking service status which would fail without systemd.

Docker is not required at all either, though it's an option.

~~~
JdeBP
That is directly contradicted by Cockpit's own doco, which explicitly states
that Cockpit uses the systemd APIs and that "use of alternate system APIs are
not currently implemented".

* [http://cockpit-project.org/guide/latest/feature-systemd.html](http://cockpit-project.org/guide/latest/feature-systemd.html)

It should of course be obvious that Cockpit _does_ explicitly deal with
systemd. Desktop Bus is a _transport layer_ , and the important thing about it
is _what DBus servers are on the other side_ of the broker are being talked
to. In the case of Cockpit they are things like systemd's own idiosyncratic
API for process #1 ...

* [https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14...](https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14300c39278fd60872bf406887723a/pkg/lib/service.js#L97)

... systemd's hostnamed server ...

* [https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14...](https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14300c39278fd60872bf406887723a/pkg/lib/machines.js#L275)

* [https://www.freedesktop.org/wiki/Software/systemd/hostnamed/](https://www.freedesktop.org/wiki/Software/systemd/hostnamed/)

... and systemd's timedated server.

* [https://github.com/cockpit-project/cockpit/blob/dbd7f3a8487a...](https://github.com/cockpit-project/cockpit/blob/dbd7f3a8487a229ff8ba0ff9189c2feab6285d1c/pkg/systemd/host.js#L68)

* [https://www.freedesktop.org/wiki/Software/systemd/timedated/](https://www.freedesktop.org/wiki/Software/systemd/timedated/)

Cockpit also hardwires use of systemd's journalctl program.

* [http://cockpit-project.org/guide/latest/feature-journal.html](http://cockpit-project.org/guide/latest/feature-journal.html)

* [https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14...](https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14300c39278fd60872bf406887723a/pkg/lib/journal.js#L101)

~~~
evol262
Yes, cockpit uses hostnamed and timedated. Plus journalctl, which I noted. I'm
perfectly aware of how dbus works, and if you think that hostnamed or
timedated have 'idiosyncractic' APIs, I'd challenge you to look at the API for
glib.

But it uses these because they are readily available over dbus. Not because
cockpit has a hard dependency on systemd.

While that functionality wouldn't work, it would be really trivial to write
your own using cockpit.spawn() to call `date`... or `hostname ...` instead of
hostnamed or timedated. The truth is that hostnamed and timedated are simply
better than the CLI tools.

However, I'm sure the Cockpit team would welcome a patch.

More to the point, there is absolutely nothing in Cockpit which is explicitly
using systemd APIs outside of dbus, and this would not be hard to work around.

I know it's cool on HN to hate on systemd, but this is dumb. Cockpit already
uses bare `hostname`: [https://github.com/cockpit-
project/cockpit/blob/dbd7f3a8487a...](https://github.com/cockpit-
project/cockpit/blob/dbd7f3a8487a229ff8ba0ff9189c2feab6285d1c/pkg/systemd/host.js#L555)

It would be a 20 line patch to break the systemd "dependency" on hostnamed.
This is not a project intrinsically linked to systemd.

Even your hardwired "example" of journalctl is literally calling a process,
which could just as easily be "cat /var/log/messages". It's 'hardwired'
because systemd is the standard these days, whether you like it or not.
However, extending the promise to simply do that if journalctl fails is
trivial.

Maybe your idea of 'hard' dependencies and mine are very different. To me, a
'dependency' on, say, Python, means that there are Python calls all over the
place which a reliance on specific semantics. That means that stubbing it out
for Ruby or Lua or whatever would be hard. It is not "we wrote our application
with this in mind, but we could patch it into stubbable modules in 3 minutes".

~~~
morganvachon
I think you just proved my original point[1]: As shipped, Cockpit will not
function as intended on any OS that doesn't use _systemd_. If it requires
patching and legwork the maintainers have not and do not yet plan to
implement, it's up to the server maintainer to shoehorn it into their system.
That would probably be more work than it's worth just to try out something
that may still end up broken with each future update.

Again, no hate for _systemd_ here, I was just pointing out what I had read in
the documentation and making it known. FYI my laptop runs Elementary OS which
fully depends on _systemd_ and I have no issues with that situation, nor do I
"hate" it. If I did I would run a different OS on it. _systemd_ is part of
Linux for the majority of distros, it's likely here to stay, and these days
it's stable enough for daily use.

[1]
[https://news.ycombinator.com/item?id=16445943](https://news.ycombinator.com/item?id=16445943)

------
fchaverri
What's different between this and Webmin?

~~~
digi_owl
This one seems to be tied to systemd...

~~~
PrimHelios
Only for the journal and hostname functionalities, it should work fine for
everything else without systemd.

~~~
JdeBP
... and systemd timedated and systemd's idiosyncratic process #1 API. Its own
doco also states that it targets systemd and does not implement use of other
APIs.

* [https://news.ycombinator.com/item?id=16448768](https://news.ycombinator.com/item?id=16448768)

~~~
PrimHelios
Thank you for the correction!

------
benevol
How much of an added security risk does adding a web-based admin interface (to
the usual ssh tunnel) represent?

~~~
number6
SSH has a lot of neat features that mitigate MITM, Eavesdropping, Bruteforcing
etc.

Where a Web-based Admin Interface should have SSL and maybe some protection
against bruteforcing.

Plus, you get all the vulns that come with the modern web

~~~
andyrj
Add nginx/apache with client certificate authentication in front of this and
most of those concerns go away. Plus this way you don't have to worry about
exposing the port but you need to distribute your client keys before hand.

------
SlowBro
Does it have an SSH terminal built right in the browser? Not clear from the
screenshots or documentation.

If not you could also use Gate One[1].

[1]
[http://liftoffsoftware.com/Products/GateOne](http://liftoffsoftware.com/Products/GateOne)

~~~
Mashimo
Yes it does.

~~~
oblio
I wonder what library they use for it. The one used by VS Code seems to be
nice and its developers active.

Ah, found it:
[https://github.com/xtermjs/xterm.js](https://github.com/xtermjs/xterm.js)

------
laveur
This looks really awesome but the thing that i feel is missing from the
website is simply what is it capable of doing? Like I want a list of features
that it is capable of so I can evaluate whether or not I may have use for it.

------
themtutty
@authors The "Try it out" page shows nothing about where to get Cockpit or how
to configure and run it. #plsfix

~~~
gtfierro
It could definitely be clearer, but if you click on the name of the operating
systems on that page, they'll produce a little dialog that tells you how to
run Cockpit.

------
sgeisler
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...](https://media.ccc.de/v/ASG2017-99-cockpit_a_linux_sysadmin_session_in_your_browser)

~~~
evol262
Cockpit uses hostnamed, networkmanager, and other services for configuration,
not 'ip' or 'hostname'.

Everything you can see is persistent.

~~~
sgeisler
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.

~~~
evol262
NetworkManager handles the config file management on its own.

Debian appears to require a flag to enable this on its own:
[https://wiki.debian.org/NetworkManager#Enabling_Interface_Ma...](https://wiki.debian.org/NetworkManager#Enabling_Interface_Management)

If it's enabled, networkmanager will parse out the files and present them over
dbus, nmcli, etc. Changes with nmcli, gnome-network (which also uses NM), or
other tooling will update the config files. The same ones in
/etc/network/interfaces.d/

So, hypothetically:

    
    
        auto eth0
        iface eth0 inet static
            address 192.168.40.112
            netmask 255.255.255.0
            gateway 192.168.40.1
            dns-nameservers 8.8.8.8
    

NM/Cockpit will show all of this information. If you change the address to
192.168.40.113, the config file will be updated (but otherwise unchanged), and
the address will change on the running interface.

If it's not enabled, Cockpit will not see the interfaces at all.

------
fazza99
what was wrong with webmin?

(ducks)

~~~
excalibur
How to get recommendations for a software solution on HN: 1\. Submit an Ask HN
thread, and ask for advice. 2\. Watch your thread get no response or interest
from anybody. 3\. Give up on HN and go build your own solution. 4\. When it's
ready, submit it to HN to help others in your situation. 5\. The
recommendations you were looking for will appear in the comments.

~~~
nathan_f77
Haha, now I'm worried that this is going to happen to me. I'm looking for a
production-ready Terraform/CloudWatch project for Rails + Sidekiq:
[https://news.ycombinator.com/item?id=16447092](https://news.ycombinator.com/item?id=16447092)

If I can't find anything, I'm going to build it myself. (And I'm going to add
Cockpit to my servers.)

------
erric
Its pretty, usable, friendly, however No one is going to use this to manage
more then a few systems.

~~~
d1mo
If you need to manage a large and diverse infrastructure you should also
consider Mist.io:
[https://github.com/mistio/mist.io](https://github.com/mistio/mist.io)

Disclaimer: I'm one of the founders

~~~
structural
How's the open source version of mist.io these days? I remember evaluating it
(and cockpit, among others) for managing a small isolated network of about two
dozen machines in early 2017 and it seemed that the open source release had
been somewhat ignored and wasn't really working at that point.

Note that all of my work is on networks that are disconnected from the
internet, so I ignore SaaS offerings or versions completely.

~~~
d1mo
I think it's worth a second try. We've been updating it quite regularly lately
and we're about to release version 3.0.0 of the Community Edition, most likely
next week. It introduces support for monitoring and alerting w/ Telegraf &
InfluxDB, among other things. If you're anxious ( and somewhat brave ;) you
can try installing it from the staging branch today.

Also, there's a Mist.io Enteprise Edition nowadays that you can install on-
premises. There's more info about that at [https://mist.io](https://mist.io)

------
rscupper
Cockpit looks cool, but I'm using the new Jupyter Lab as a pretty awesome
Python remote web shell. Access to a terminal, file explorer, and editor
covers most everything I need and being able to run Python/Shell code in cells
has covered most everything else.

------
dten
This is cool, but there's no information on how to set it up. Am I missing
something?

~~~
phren0logy
I recently spun up a Debian 18.04 server to play with the beta. Installing it
on that system was as easy as:

sudo apt install cockpit

~~~
dten
ah, thanks (that should probably be in the documentation somewhere)

------
happyhotpocket
Maybe I'm just missing something but where is the name of the package? How do
I install this? Is it an `apt-get install cockpit`? I don't see that written
anywhere obvious.

~~~
burdzwastaken
click your distribution (I assume Ubuntu?) here to reveal the way to install
it [http://cockpit-project.org/running.html](http://cockpit-
project.org/running.html).

if you are running Ubuntu seems to require backports for anything below 17.04
though.

~~~
jniles
I also had this question and it took me about 5 minutes to figure out that you
needed to click to reveal. It's fancy, but not at all practical. Hopefully
someone updates it to just a flat list.

------
hestefisk
Linuxconf for Web anyone?

------
nailer
I just want to consolidate journald entries across multiple boxes with a nice
wen based UI. Anyone used cockpit for this? Or another solution?

~~~
chrisper
Splunk?

~~~
nailer
Seems like too much code. Like I just want journald, consolidation and search.

------
cateye
How would Cockpit compare with [http://vestacp.com/](http://vestacp.com/) ?

------
dalore
Would be nice if this was in a docker container I could just run.

~~~
evol262
It is:
[https://hub.docker.com/r/cockpit/ws/](https://hub.docker.com/r/cockpit/ws/)

~~~
dalore
It mentions atomic though. And nothing about docker on the install guide.

~~~
evol262
'atomic' is a wrapper. Just look at the dockerfile.

Given how much cockpit wants to, y'know, manage the real system, running it in
docker is senseless, and there's no reason to have it in the install guide. If
you want it to actually manage your host, use the dockerfile.

------
morganvachon
For those who may wonder, it looks like this is GNU/Linux only, no support for
BSD or any Linux distro that doesn't use _systemd_. That means no Alpine Linux
and no OpenBSD/FreeBSD.

~~~
evol262
cockpit is not dependent on systemd. They don't ship sysvinit scripts, but
there's no hard dependencies on systemd anywhere. I'd expect that the system
logging may not be very nice without journald, but the vast majority of the
interface runs over dbus or spawns processes on the server.

It _is_ dependent on dbus.

~~~
morganvachon
From their documentation, it certainly sounds like it is:

> _Cockpit uses systemd and the DBus APIs it provides to configure and monitor
> core aspects of the system. Use of alternate system APIs are not currently
> implemented._

and

> _Cockpit configures the system time and time zone via the_ timedated
> _daemon. To perform similar tasks from the command line use the_ timedatectl
> _command_

That's a _systemd_ specific daemon.

[http://cockpit-project.org/guide/latest/feature-systemd.html](http://cockpit-
project.org/guide/latest/feature-systemd.html)

Edit: Also please note that I'm not disparaging Cockpit nor _systemd_ , just
pointing out that (according to their documentation linked above) it is tied
to _systemd_ which may be an issue for some.

~~~
JdeBP
See
[https://news.ycombinator.com/item?id=16448768](https://news.ycombinator.com/item?id=16448768)
and
[https://news.ycombinator.com/item?id=16451862](https://news.ycombinator.com/item?id=16451862)
.

------
cztomsik
This is great!

I've noticed you're using jquery (and that's fine) so what is YOUR opinion
about current state of js? Are you considering any js framework? And if so,
which one would it be and why?

------
ausjke
it is possible to make cockpit loosely coupling with dbus? so that you can add
bsd, non-dbus-Linux-devices(e.g. openwrt) to it?

------
digi_owl
1\. Anyone remember Webmin?

2\. Seems to rely heavily on Systemd being present...

------
INTPenis
I tried it on my fedora 26 last year and my impression is that it has a far
way to go and a lot of problems to resolve on the way.

It's nowhere near a complete server administration product that will let you
avoid the terminal.

Perhaps for simple tasks but I fail to see the purpose.

~~~
snuxoll
Cockpit itself is trying to be a "platform of sorts for modules to hook into.
oVirt, for example, will install a cockpit plugin during installation of a
hypervisor node allowing you to manage the local host or global cluster
maintenance state and see how many VM's are running on the system (I would
argue this is of limited benefit since you could just login to the oVirt Admin
portal to do the same thing, but hey).

So, yes, you're right - a lot of work still needs to be done, but Cockpit
itself seems to be an adequate base, just need to add support for managing
commonly needed services at least at a rudimentary level though
(MySQL/PostgreSQL, Apache/Nginx/lighttpd, Postfix/Dovecot/exim/cyrus, etc).

~~~
evol262
I'm the maintainer of the oVirt plugin.

The real advantage of it is that it allows installation of hosted engine
easily, and a 'single pane' overview of a host (oVirt Node status without
using nodectl, etc)

Since Cockpit wants to deal with dbus, the push is for other utilities
(postfix, snmpd, etc) to publish relevant information over dbus, rather than
teaching Cockpit the format of each and every configuration file on the
system.

I wrote the Tuned plugin for Cockpit, and I maintain the oVirt plugin. I gave
a talk at Devconf about plugin development, which is extremely easy, but the
Cockpit team is small. It's very easy to write plugins for it, but even easier
if they expose dbus.

That said, the cockpit API ([http://cockpit-project.org/guide/latest/api-
base1](http://cockpit-project.org/guide/latest/api-base1)) makes handling
files/processes from client-side Javascript in plugins simple. It's just that
you'd need yet another config file parser...

~~~
snuxoll
Never realized it was even possible to do a hosted engine deployment via
Cockpit, that's certainly useful (I've always just used hosted-engine --deploy
from the command line because that's how I've done it since the 3.x days).

Do you have a link to a video of the presentation?

~~~
evol262
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](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.

