"Not found" with direct cockpit-ws --local-session=/usr/bin/cockpit-bridge

[baude]

Cockpit version:

cockpit-bridge-255.1-1.fc34.x86_64
cockpit-ws-255.1-1.fc34.x86_64
cockpit-podman-34-1.fc34.noarch

OS: fedora coreos 24
Page: NA

When trying to run cockpit on fedora core-os using ssh, we get a fatal? error about locale no being supported. This is because fcos only installs one locale -- C.UTF-8. We are doing this to support the Podman on Mac effort where we would like to present cockpit as the GUI interface for interacting with containers.

Relevant parts of the system log are also useful:
Oct 26 18:19:27 localhost cockpit/ssh[2982]: invalid or unusable locale: en_US.UTF-8 <-- this is the key one I think

Steps to reproduce

1. boot an fcos vm
2. install cockpit packages ... rpm-ostree -A install ...
3. connect to that system with ssh
   ex. ssh -p 41149 -i /home/baude/.ssh/podman-machine-default -L 9190:localhost:9190 core@localhost /usr/libexec/cockpit-ws -a 127.0.0.1 -p 9190 --local-session=/usr/bin/cockpit-bridge
4. use browser to connect to localhost:9190

You will get a Not Found cockpit screen. It definitely hit the cockpit service as this is NOT a 404.

[baude]

Was also reported 4 years back -> #8263 It looks like the author self closed it.

[rhatdan]

This is really important for the Podman Desktop effort on MAC, our plan as @baude pointed out is to have GUI for managing podman machine, but if users want to manage the containers then we throw them into Cockpit.

This could lead to some good exposure for Cockpit-podman, but we need to have this working.

Our goal is to announce this at year end, at the same time that Docker is going to start charging users on MACs, so we are under some time pressure.

[mvollmer]

I would be surprised if this is really a "missing locale data" issue, that should just be warning. It might well be, of course.

Is this the actual thing that needs to work?

ssh -p 41149 -i /home/baude/.ssh/podman-machine-default -L 9190:localhost:9190 core@localhost /usr/libexec/cockpit-ws -a 127.0.0.1 -p 9190 --local-session=/usr/bin/cockpit-bridge

You are connecting to core@localhost, so this whole command is also running in the Fedora CoreOS vm? Is that essential or just done here in the reproducer?

I see if I can reproduce the "not found" behavior with our CoreOS image from CI.

[martinpitt]

This is actually conceptually not too far apart from what cockpit-desktop does, except that this won't work for this use case -- it does support SSH, but it runs cockpit-ws on the local machine (for very good reasons).

The "invalid or unusable locale" is not important. SSH has this irritating behaviour of blindly copying the client-side locale env to the server side, and then complain that it doesn't work. The internet is full of this, but it's not what breaks here.

I can run this on my Fedora 35 desktop:

❱❱❱ /usr/libexec/cockpit-ws -a 127.0.0.1 -p 9190 --local-session=/usr/bin/cockpit-bridge
invalid or unusable locale: de.UTF-8

and can connect to http://localhost:9190 just fine, with a running session.

The reproducer translated to our CI Fedora CoreOS image:

• In bots, start image with ./vm-run fedora-coreos
• Install the packages: ssh c "rpm-ostree install cockpit-ws cockpit-podman; reboot"
• Wait for reboot, shell to the image, with port redirection, and run cockpit: ssh -t -L 9190:localhost:9190 c /usr/libexec/cockpit-ws -a 127.0.0.1 -p 9190 --local-session=/usr/bin/cockpit-bridge

This also works fine for me, http://localhost:9190 has the session (even in German for me).

I stared at your reproducer a bit more, and saw the rpm-ostree -A option. So trying this again:

./vm-run fedora-coreos
ssh c "rpm-ostree -A install cockpit-ws cockpit-podman"

This fails:

Resolving dependencies...done
Will download: 7 packages (6.8 MB)
Downloading from 'fedora'...done
Downloading from 'updates'...done
Importing packages...done
Checking out packages...done
Running pre scripts...done
Running post scripts...done
Running posttrans scripts...done
Writing rpmdb...done
Writing OSTree commit...done
Staging deployment...done
error: packages would be changed: 6, enable replacement to override

It did install cockpit-{system,bridge,networkmanager}, but not cockpit-podman nor cockpit-ws.

@baude:

• Please expand ... rpm-ostree -A install ... to the full command that you did. Does this work without a reboot? Can you try without -A and a reboot?

• Please run cockpit-bridge --packages on the image after your install command and make sure that you have at least "base1", "shell", and "system" (and of course you eventually also want "podman", but I understand it fails even before that)

• What is the exact URL that you connected to? Just http://localhost:9190, or did you perhaps have a /podman suffix?

[martinpitt]

Some general remarks:

• Please be aware that every user and process on the ssh client machine (MacOS) has total, unauthorized root access to the FCOS VM through that opened port. cockpit-desktop avoids that by running cockpit-ws+browser in a separate network namespace, but that architecture won't work for you as (1) no namespaces in MacOS, and (2) cockpit-ws is not running on the MacOS side. So this architecture is horribly insecure, and should not be productized like that.

• You may at least want to run cockpit-ws/bridge as unprivileged user, and set that up for user containers (/etc/sub[ug]id), and reset that frequently, to at least limit the impact of exploits; this depends on how long-lived that FCOS VM is, of course.

• You probably don't want to expose the whole cockpit UI/shell, but just the podman frame: http://localhost:9190/cockpit/@localhost/podman/index.html . cockpit-desktop goes a step beyond that by using a webkit browser window without any chrome, so that the whole thing looks and feels like an actual desktop app, not like a browser. That ought to be possible on the MacOS side as well?

[gbraad]

You probably don't want to expose the whole cockpit UI/shell, but just the podman frame:
http://localhost:9190/cockpit/@localhost/podman/index.html .

This is also the location that was used in the Proof of Concept and what CodeReady Containers will do:
https://github.com/gbraad/podman-desktop/blob/f168be849ae5538fda3a1426618845ad19a83740/main.js#L22 Like the PoC and the tray implementation we will be using, this is based on Electron. The native solution gave too many problems.

Note: The only problem that exist is that 'authentication' is needed, but that is a different issue

[garrett]

Electron security

As it's somewhat related to the thread here (about running Cockpit Podman in Electron), here are a few Electron-related security resources I saw recently:

• 1Password recently remade their "native" UI using Electron and released https://github.com/1password/electron-hardener with some defaults https://github.com/1Password/electron-secure-defaults (which also has a bunch of good best practices for security).
• https://github.com/doyensec/electronegativity is also useful for checking Electron apps.

Apologies if you already know about these. If not, I hope you find them useful.

(Of course, a proof of concept doesn't need to worry about this. Once we start to get to a basic working implementation which uses Electron, we'll want to consider the above.)

[martinpitt]

@baude just posted this to IRC:

^C[baude@fedora ~]$ podman machine ssh cockpit-bridge --packages
Warning: Permanently added '[localhost]:44055' (ED25519) to the list of known hosts.
base1                                                         /usr/share/cockpit/base1
podman               Podman containers                        /usr/share/cockpit/podman
ssh                                                           /usr/share/cockpit/ssh
static                                                        /usr/share/cockpit/static
checksum = e3c50b0e4c707c4a9ecc234246505bd0ecd467530acb7e19a000f39d741eff54

I.e. you don't have cockpit-system installed, and thus no cockpit shell or overview. So you have to use the direct frame URL, http://localhost:9190/cockpit/@localhost/podman/index.html -- with just localhost:9190 you would get the "not found" due to the missing shell.

[baude]

As @martinpitt says, the correct url is http://localhost:9190/cockpit/@localhost/podman/index.html ... i'm closing out this bug.

[gbraad]

@baude it might help to sync as a lot of this was already concluded in our spike for CRC. We also implemented a bearer token method to authenticate.

[baude]

@gbraad excellent ... will do!