Is Cockpit supported?

Hi all, I just tried to install Cockpit, but the Software GUI tells me it’s not supported. Is this true, or just some random glitch? (I’ve tried Googling, honest, but no hits)/ I’m on Silverblue and want to remotely administer a headless Fedora 30 box. If no Cockpit, then what are my options?

Thanks heaps for Silverblue, after 1 week I’m loving it and using it as my main OS.

If you use rpm-ostree, I do not think that there is any difference in relation to the usual Fedora.

But what I really do not understand, because silverbluy is aimed at the desktop, why is there a cockpit?

@johnfrombluff I am not using cockpit on my system but I have installed it from the command line and it seems working for me.

systemctl status cockpit
● cockpit.service - Cockpit Web Service
   Loaded: loaded (/usr/lib/systemd/system/cockpit.service; static; vendor pres>
   Active: active (running) since Wed 2019-07-17 17:35:28 CEST; 5min ago
     Docs: man:cockpit-ws(8)
  Process: 7566 ExecStartPre=/usr/sbin/remotectl certificate --ensure --user=ro>
 Main PID: 7569 (cockpit-ws)
    Tasks: 3 (limit: 4915)
   Memory: 7.2M
   CGroup: /system.slice/cockpit.service
           ├─7569 /usr/libexec/cockpit-ws
           └─7635 /usr/bin/ssh-agent

Thanks, that’s very helpful. I wonder why the Software GNOME app have me that error message. Does anyone know how I could help debug that issue?

Best wishes from sunny New Zealand,

John

Try filing an issue with the gnome-software team upstream - https://gitlab.gnome.org/GNOME/gnome-software/

They’ll be more knowledgeable about those kind of errors.

A few of us Cockpit developers are now running Silverblue the main laptops we use for development.

Background

  • Andreas switched first and is using his laptop as a remote UI to a development server. He’s the earliest switcher.
  • Martin composes his own trees with i3 and a bunch of development stuff baked in. He redid his laptop a week or so ago and is doing development 100% on his laptop.
  • I backed up, nuked my laptop’s data, and installed Silverblue last weekend. This week, I have been figuring out ways to get development working for me. Previously, I’ve been toying with Silverblue on an old laptop and also have been using Podman and Buildah on traditional Fedora.

Cockpit on a laptop (or workstation)

Firstly: Cockpit is intended for servers.

There are three reasons why you might want to use Cockpit on a laptop though.

  1. Bastion host.
    • You connect locally to Cockpit running on your machine and then through your laptop’s instance, you connect to a remote machine over SSH. This means you don’t have to expose port 9090 on the servers.
    • You could also run this in a VM instead of as an overlay. If you’re using GNOME Boxes as a flatpak, I think connecting to the VM from your browser won’t work though. (You’d need gnome-boxes or virt-manager installed as an overlay.)
  2. Development.
    • This is what Martin and I are doing. (Andreas is also doing development, but his dev server and his laptop are separate.)
    • If you’re an admin and you want to make custom Cockpit plugins, you’d probably want to run Cockpit locally too.
  3. A UI for your laptop.
    • Usually native apps are better for this, as they take desktop use into account and we design for server use cases.
    • There is some overlap, of course, but a lot of things work a bit differently on a server versus a workstation.
    • For example:
      • Firewalls are used in completely different ways. Servers are on a fixed network and laptops often use a variety of different, untrusted networks.
      • Software on servers is often built in-house or suited to task and ran by experts. Apps on a laptop are often plentiful, run by people who know nothing about the development of the app, and people using software on laptops all have different knowledge, experience, and technical levels (and this is a good thing).

So, I’d recommend running Cockpit on your laptop for reason 1 or 2, but not really for reason 3 (but no one will stop you, and it’ll still work fine).


This all said, I’ve found that you can rpm-ostree install cockpit-ws cockpit-system for a minimal install (this is what Martin and I do; we use the system packages to bootstrap and then overlay our development builds of Cockpit on top).

I’m pretty certain you can add additional Cockpit packages too. You might even be able to just rpm-ostree install cockpit to get the typical packages. (I haven’t tried it yet.)

Cockpit things that won’t work as expected on Silverblue

  • Typical “Software Updates” won’t work, as it uses PackageKit, which uses dnf on Fedora. We do have some ostree support from the Atomic days, in the cockpit-ostree package. It could possibly work. (I should try this, actually…)
  • Automatic install of dependencies in Cockpit’s UI (this uses PackageKit too).
  • PCP (installing it as an overlay seems to not work when I tried).

The rest of the cockpit-* packages would probably work, and should pull in the necessary dependencies.


An aside about using Silverblue to develop Cockpit

Overall, for development, I’ve found Silverblue better than I had expected. It’s mainly thanks to having the apps I need in Flatpak already (some on Flathub — epsecially the design-related ones like Inkscape, where fonts properly work on the Flathub version, but not on the Fedora flatpak yet) and especially :heart: toolbox :heart:. (Yes, it’s “just” a wrapper around podman, but it’s an amazing wrapper. Huge shoutout to podman and buildah doing the heavy lifting too!)

Visual Studio Code (and running a few GUI apps from toolbox)

Meanwhile, I also switched from Vim to VSCode for development a few months ago.

I’m not entirely certain which is the best way to run it. I’ve tried an overlay (which works, but then some extensions don’t work, as they have external deps), as a Flatpak (which has a workaround for getting a toolbox container), or from running in a toolbox container.

Installing inside a toolbox and running it there seems to be the best method, as you don’t have to do anything special to get the terminal working, performance is good, and you can easily install npm deps like webhint and nearly any RPM via dnf. The one drawback: I don’t have a good way to launch VSCode aside from “toolbox run code” from a terminal. I tried making a desktop file with various permutations of “toolbox run code” — with paths, running in sh -c "", using a wrapper script, appending -w so VSCode waits instead of forks, and so on.

It would be awesome to be able to have a launcher for toolbox'd apps. Yes, usually Flatpak is the way to go here, but I think this is a special case. Official Chrome (including the dev version) works just as well in a toolbox like this, by-the-way… but I think I’ll stick to the Chromium overlay.


Summary

Cockpit can run on a Silverblue system. But you should have a good reason as to why you’d want to run it on a laptop or workstation. (See above.)

As for running Cockpit on Silverblue for development: The three of us really like using Silverblue so far, even though all of our experiences are quite varied. :+1:

3 Likes

have you had any luck getting Cockpit to run from inside a container? i want to limit the overlays on the host and would prefer a non-host install. i was just working on trying to get cockpit running from docker, but have had trouble ensuring the correct host resources (ie, volumes) are available for the container.

I haven’t tried, but I do know that Cockpit was able to run as a system container on Atomic (the predecessor to Silverblue & Fedora CoreOS).

The website is still around; here are the docs:
https://www.projectatomic.io/docs/cockpit/

However, the atomic command isn’t around anymore and I don’t know how long the container will exist (or if there have been or will be updates).

So it’s definitely possible to run Cockpit in a container.

Of course, the more you want Cockpit to do on a system, the more dependencies you’d need installed. (For example, Cockpit supports running virtual machines and containers, but you’d need the appropriate packages installed for that to work. Running from within a container would probably not include that functionality.)

I’ll have to review that atomic Dockerfile in more detail.

I had installed the docker packages and allowed the container to access the docker sock, but my most immediate issue is that when the container launches, it’s in the isolated environment without access to my host user authentication or to see host system resources.

I’ll keep investigating this.