Cockpit client: connecting to remote system with no Cockpit packages, and then installing cockpit-pcp results in issue connecting

[briansmith0]

Explain what happens

1. Using Cockpit Client flatpak, version 296 from Fedora 38 workstation
2. Connect to a remote Fedora 38 Server, which has no cockpit packages installed
3. Go to the "View metrics and history" section of Cockpit, and click the button to install cockpit-pcp
4. cockpit-pcp is installed, and I am prompted to logon again
5. Still using Cockpit Client, try to login again, and now get a message that "Server is missing the cockpit-system package"

I understand that we don't support mixing/merging packages between what is included in Cockpit Client and what is installed on the remote system.

In the scenario above, when we go to install cockpit-pcp, could Cockpit detect that the system doesn't have any Cockpit packages installed, and therefor the base Cockpit packages need to be installed along with cockpit-pcp?

Expanding on this, an additional idea would be a dialog box coming up and explaining that currently you are connected to a remote system that has no Cockpit packages installed. And that in order to add this additional functionality (cockpit-pcp or whatever else it might be) Cockpit will need to be installed on the remote host. And then provide an interface to select which Cockpit applications you'd like to install (with it defaulting to whatever the user currently sees as options in Cockpit).

Version of Cockpit

296

Where is the problem in Cockpit?

Unknown or not applicable

Server operating system

Fedora

Server operating system version

Fedora 38

What browsers are you using?

No response

System log

No response

[martinpitt]

Thanks @briansmith0 for the report. This scenario is exactly the case why we decided to keep the "distro package" and "beiboot magic" worlds strictly non-overlapping, at least for the first versions. See https://issues.redhat.com/browse/COCKPIT-943 for the full details.

I think eventually we will have to find a solution to transition such a system into a "distro package" state (by e.g. always installing at least cockpit-system together with any other on-demand install), but this requires some careful consideration as it can change the UI quite dramatically.

For now we need to disable on-demand install in Cockpit in general when we are in the beiboot scenario. Fortunately we have some centralized code for that.

@allisonkarlitskaya @marusak Do you agree with the above, at least for now? Then I'm happy to think about how we implement this.

[marusak]

For now we need to disable on-demand install in Cockpit in general when we are in the beiboot scenario. Fortunately we have some centralized code for that.

Hmm, we will need to communicate this clearly and also explain how one can move into the "distro" scenario. The thing is that normal user does not care if is in "distro" or "beiboot" scenario, they just want to connect and use cockpit so preventing them to do some action just because they used valid way of connecting might be frustrating.

[briansmith0]

Agree with @marusak. As a user, I'm likely connecting to lots of different systems using Cockpit Client. It would not be obvious to me that some are using beiboot and some are using the locally installed Cockpit packages, so it would be confusing that on some of my systems I don't have the option to install extra packages like cockpit-pcp.

Another idea would be to have a card on the Overview page that shows information on this. It could show if you connected with beiboot or with the distro packages, and explain the difference between the two. If you connected with beiboot, it could provide a button to convert to the distro packages (prompting the user for which applications should be installed).

[allisonkarlitskaya]

My 2¢: there's no good reason for cockpit-pcp to depend on the bridge. That will take a long time to fix and filter down through the distros, though, and in light of #19036, probably we want to take a different direction here, anyway.

Something else to consider: installing cockpit-pcp would actually be futile right now anyway, even if we didn't pull in /usr/bin/cockpit-bridge, since when we beiboot we never scan the packages on the server (and would therefore never find the bridge config).

I think Martin's suggestion makes sense, for the time being.

Do we have a good way of communicating the "this is beibooted" state to the frontend?

[allisonkarlitskaya]

One more separate thought: I wonder if we want to remove support for general purpose peer bridges based on match rules in the future, including in the non-beiboot scenario (ie: python /usr/bin/cockpit-bridge), leaving only support for superuser and remote hosts.

[martinpitt]

Yeah, this would definitively be a stopgap for now. We need to make up our minds when/how to transition to the distro scenario. The "Software Updates" packagekit usage makes sense (in fact, that's one major use case), and places which install e.g. nfs-utils or vdo make sense too. Just the on-demand install of cockpit-* packages doesn't, i.e. we need to disable the Apps page and the cockpit-pcp button. And go through to check if there is any other.

[martinpitt]

I checked our code, and the on-demand cockpit-pcp install on the metrics page is the only problematic instance. The others install packages like realmd, vdo, dnf-automatic, kpatch, which are all fine and desirable for beiboot mode, too.