Cockpit on Debian 8.2

For a while now, the Cockpit team has been thinking about how to get Cockpit running on Debian. Last weekend at the systemd conference 2015 we had the opportunity to talk with a few Debian maintainers and made some progress.

The good news: it works!

Cockpit on Debian 8.2
Cockpit 0.83 on Debian – System overview

Inside a Debian 8.2 system we managed to download Cockpit from git, then built and ran it. Thanks Michael Biebl!

Building Cockpit 0.83 on Debian 8.2

The steps aren’t really different from setting up a Cockpit build on Fedora, so we can follow HACKING.md.

On Debian, we used these dependencies to be able to compile cockpit:

apt-get install npm autotools autoconf automake intltool libssh-dev \
 libssl-dev zlib1g-dev libkrb5-dev libxslt1-dev docbook-xsl \
 libkeyutils-dev libglib2.0-dev libsystemd-dev libpolkit-agent-1-dev \
 libpcp3-dev gdb libjson-glib-dev libpam-dev xsltproc \
 libpcp-import1-dev libpcp-pmda3-dev nodejs-legacy

There is one more dependency which is related to the documentation and should be installed without its recommended packages, otherwise it will pull in a lot of extra packages:

apt-get --no-install-recommends install xmlto

The package nodejs-legacy has to do with a binary name conflict which needs to be looked at upstream.

Docker

In order to run the docker container management in Cockpit, we only needed to install docker on the target system – this isn’t necessary for the build.

I added deb http://ftp.de.debian.org/debian/ stretch main to  /etc/apt/sources.listand then ran apt-get install docker.io.

What works, issues

A lot of Cockpit seems to work out of the box on Debian. This doesn’t come as a big surprise, since Cockpit heavily utilizes systemd and systemd is part of Debian 8.2. So all parts that rely on systemd aren’t an issue: System overview, changing the hostname, datetime settings (manual or use an ntp service), shutdown/restart, journal, services. We can also use the terminal (console in the browser with a full shell session), configure networking (interfaces with ip addresses, bridges, bonds, vlans, et cetera) and work with docker containers if docker is installed. Awesome!

Cockpit Networking
Cockpit 0.83 on Debian – Networking
Cockpit Services
Cockpit 0.83 on Debian – Services
Cockpit Journal
Cockpit 0.83 on Debian – Journal
Cockpit 0.83 on Debian - Docker
Cockpit 0.83 on Debian – Docker

Account management seems to work (including managing the ssh keys) with only a cosmetic issue: the real names for an account aren’t parsed/displayed correctly. It would be great to have a dbus api for local accounts instead of having to touch files on the disk directly!

Privilege escalation seems to work differently, so we’ll need to take a closer look at non-root use of Cockpit on Debian. The way Cockpit checks for permissions is described in the documentation.

The storage panel doesn’t work at all on Debian, since storaged currently isn’t supported on Debian. I’m not sure how much effort it would be to get that working.

What next?

The Cockpit build system requires a few changes, since it currently only supports rpm-based distributions. What all this should lead to is continuous integration and continuous delivery into Debian unstable. Once we can build packages and run the integration tests, Debian should be one of the checks that are run on all pull requests before they are merged into master.

It would also be great to have a package maintainer for Cockpit releases, who can also keep an eye on the feature roadmap (see the trello board) to be aware of possible dependency conflicts early in the development process. Actual packaging shouldn’t be difficult, considering Cockpit automates as much as possible on that front.

5 thoughts on “Cockpit on Debian 8.2”

  1. Hi. I actually started debian packages for cockpit quite a while ago but gave up before finishing as I saw cockpit move from udisks2 to storaged fork because:
    – at the time didn’t seem to have any useful features over udisks2
    – I was unable to find an good explanation on why storaged forked instead of contributing to udisks2 (which could use more people working on it).
    – I’m not interested in maintaining yet another udisks fork in Debian myself.

    Happy to see there’s interest from others into making cockpit running on Debian. Would be interesting to read more about why storaged exists and if you’re aiming at deprecating udisks2 (and if so what you’re doing to make current udisks2 users migrate to storaged).

    1. I don’t know the specifics of why storaged was forked from udisks2, but looking at the upstream activity (http://cgit.freedesktop.org/udisks vs https://github.com/storaged-project/storaged) I’d put my money on storaged to be more viable from this point forward. I definitely know that is has become easier for Cockpit fixes to go into storaged, so we have less downtime in case there is something to fix. Long waits hurt Cockpit especially badly, since it depends on so many other interfaces.

      Maybe having Cockpit run on Debian is the little incentive necessary to get storaged there as well.

      I can understand that the udisks/storaged fork made you step back. I invite you to keep tabs on where Cockpit goes on Debian – maybe being a maintainer will sound better once our integration tests pass on Debian for every single pull request. =)

  2. Hi. There is actually quite a long history behind the storaged fork…

    There were several projects trying to use udisks for non-desktop storage management. The people behind storaged come from the (now discontinued) OpenLMI project—it was another remote system management API attempt—and at the time we started with storage module we reached out to the udisks upstream (David Zeuthen) and talked about our needs and what would we want from udisks. David’s stance was quite firm on this: udisks was to be focused on desktop use-cases and any “enterprise” feature (LVM was the most painful one…) was considered to be unnecessary bloat making the code harder to maintain. We respected (and understood) that position, however we needed to solve our problem with missing storage API. OpenLMI has then decided to build on Blivet (Fedora/RHEL library created for the Anaconda installer) which was AFAIK another project launched because udisks upstream was not willing to accept some features and it happened even long before OpenLMI. Blivet was however tailored to the installer requirements and not that good for generic storage management. So OpenLMI had to find some other API. And in parallel, there came Cockpit facing the same problem.

    Cockpit was originally built with udisks2 as a backend and another daemon that complemented udisks2 adding LVM support. (It was called storaged.) However this scheme with two daemons was causing problems and since the split was made for mostly “political” reasons, we decided to give up and merge the LVM code into udisks2 ourselves and continue developing one universal daemon/API. And again: there were attempts to convince udisks2 upstream to accept the LVM code prior the decision: the fork was actually even suggested by udisks upstream (https://bugs.freedesktop.org/show_bug.cgi?id=68609). I admit that many of the conversations happened in person and by e-mails, so it’s not that easy to find out.

    If udisks upstream would be willing to support the server-type use cases, we would of course gladly join them. But again: it’s many years old topic. And unless udisks2 upstream changes their mind, there is no other option than continue with storaged.

Leave a Reply

Your email address will not be published.