sosreport: Explicitly specify "host" in download channel options

[mvollmer]

This makes it work when downloading from a remote machine.

No default will be provided by Cockpit itself, unlike with cockpit.channel() etc.

[mvollmer]

We should probably have a function in cockpit.js to create these URLs, and that function can provide the right default for host.

[martinpitt]

A test is straightforward (like in cockpit-project/cockpit-machines@6024303) but expensive 😢 We have quite a bunch of these cases, I wonder if we could do some nspawn magic to create some kind of fake container with a file system overlay?

[jelly]

A test is straightforward (like in cockpit-project/cockpit-machines@6024303) but expensive 😢 We have quite a bunch of these cases, I wonder if we could do some nspawn magic to create some kind of fake container with a file system overlay?

I also like the idea of not introducing a test for this but not an expensive one as in machines for files. As files tests are pretty speedy and that is awesome.

[martinpitt]

I wonder if we could do some nspawn magic to create some kind of fake container with a file system overlay?

Yes we can! nspawn can boot its own host OS/file system in a container:

# auto-manage the host side of container veths 
systemctl enable --now systemd-networkd
systemd-nspawn --machine=cockpit1 --ephemeral --network-veth --directory=/ --boot --bind /home

Afterwards, check the container IP in ip -c a and log in with e.g. ssh [email protected] from the outer VM, or directly from the host:

ssh -i ~/upstream/bots/machine/identity -o ProxyCommand='ssh -A c nc %h %p' [email protected]

This gets its own /tmp and similar, and we can add arbitrary --overlay or --bind options if we need to diverge paths in e.g. /usr/ between the host and the container.

[martinpitt]

See #21105 for a draft how this "lightweight container provision" can look like.

[martinpitt]

... that said, I'm fine with adding a test for this as a follow-up.