Is Cockpit supported?

Project Discussion
6

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:

4 Likes