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 - GNOME / gnome-software · GitLab

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:

4 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.)

1 Like

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.

Will Cockpit be available as a flatpak or are there any plans to include it in the base Silverblue image?

Overview

While several of us on the Cockpit team are running it on our Silverblue workstations, we’re doing so with the goal of development.

In general:

  • Cockpit is intended for servers.
  • Flatpak is for desktops.
  • Silverblue is a workstation (desktop-oriented) OS.

So it doesn’t make sense to distribute Cockpit in a Flatpak. I’m not sure if it’s even possible to do so, as Cockpit hooks into systemd and other services at a level that Flatpak probably wouldn’t allow. And then Cockpit also doesn’t have a desktop-based UI, but a web-based one.

Cockpit on an ostree based server (Fedora CoreOS)

If you’d like to have something like Silverblue on servers, check out Fedora CoreOS: Fedora CoreOS

And there are official instructions for running Cockpit on Fedora CoreOS: Running Cockpit — Cockpit Project

Installing Cockpit for Development

And for development purposes, here’s how to get Cockpit working on Silverblue:

We overlay the Cockpit packages with rpm-ostree install and use a symlink for local development. We also use testing VMs for trying out things too.

The easiest approach is to overlay the various packages:

  1. rpm-ostree install cockpit-system cockpit-ws cockpit-ostree cockpit-podman
    • this will provide a web-based UI in Cockpit for both rpm-ostree and podman
  2. (optional) for virtual machine support, also overlay cockpit-machines libvirt-client libvirt-dbus tuned-utils virt-install
  3. Reboot to make the packages active.
  4. systemctl enable --now cockpit.socket

Then you’d want to read (and follow along with):

While it works fine as overlays, it’s not really intended to run Cockpit on Silverblue outside of development.

Bastion host

You can use Cockpit on one machine that’s running Cockpit to log into another machine (in the backend via SSH) within the Cockpit web session. This is called a “bastion host”.

There’s some very old documentation on this, with a video, when it first landed in Cockpit, from 2016. It’s the same concept today, although the UI looks a different (with a different style and slightly different widgets):

Bastion overlay method

I think you’d need to do the following:

  1. rpm-ostree install cockpit-system cockpit-ws cockpit-dashboard
  2. Reboot to make the packages active.
  3. systemctl enable --now cockpit.socket

Then connect to https://localhost:9090/ and click on “Other Options” and put in the remote server address.

I haven’t tested this. It will probably work. :wink:

Bastion container

Check out the bastion container. The command uses docker, but I think you should be able to swap it out for podman:

https://github.com/cockpit-project/cockpit/tree/master/containers/bastion

(The README has everything you need. Ignore the source files above, unless you’re going to build the container yourself.)

Summary

  1. Cockpit is intended for servers
  2. Fedora Silverblue is a desktop OS
  3. Fedora CoreOS is where Cockpit is better suited
  4. You can still have Cockpit on Fedora for development and as a bastion host (a passthrough to machines that don’t have Cockpit listening on 9090, but do have SSH)
  5. (All that said: You can also, of course, still install Cockpit locally for web-based interfaces for podman and ostree even if it’s not the intended use case. This is Free Software after all and you’re free to do so. In that case, you’d just follow the development profile up until the point of enabling Cockpit. You wouldn’t need to do the symlink, check out the repo, care about testing VMs, etc.)

I hope this helps out!

2 Likes

I want to use it as a bastion.
Does it work inside the toolbox?
I have installed it in the toolbox and also installed systemd but it does not work when I try to enable the socket…
I was wondering if there was an easy way to install it on Silverblue without overlay.
I will try the bastion container with podman.
At the moment I run it inside a vm with Ubuntu and use it to connect to other machines.

Most things work in a toolbox. Cockpit doesn’t; it needs systemd and other system resources that toolbox containers don’t provide. You’d either need to run it as an overlay or in a VM. (A VM could technically run either inside the toolbox container or on the system.)

When we build Cockpit, we do so in a container (or build it in a VM for testing), but it’s running on the host (or in the VM).

So the answer basically is to choose one of the following options to run Cockpit as a bastion:

  1. Run it as an overlay with rpm-ostree install (and the packages listed above, then rebooting) on the host itself.
  2. Run Cockpit in a VM and connect through it (either on a browser on that VM or, if the network allows, from a browser on your host).
  3. Run Cockpit on another machine and connect through that to other machines.
1 Like

I’m so sorry, I know this is an ancient post, but I just wanted to mention very briefly the most “normal” experience I’ve had with vs code on silverblue was using the microsoft-maintained snapd image.

This script moves mount location to user folder: GitHub - realgrm/snapd-in-Silverblue: This is an test based on some comments found in the Fedora Silverblue and snap repos

The systemd service might be installable via /etc - I just ran snapdSB.sh on login, myself.

snapd’s nice because includes all the telemetry for settings sync, installing extensions

Can cockpit control CoreOS if running from inside a container, or does it need to be installed as an RPM or overlay to control the host?

Thanks so much :slight_smile: