rhn-support-briasmit suggested providing the beiboot functionality to RHEL users – but neither the flatpack nor quay.io/cockpit/ws are officially supported by RHEL, as they are built from Fedora contents.

Opening up the beiboot feature from the rpms is difficult because of forward compatibility (e.g. connecting to RHEL 10 from an old RHEL 8 cockpit). Backwards compatibility is merely expensive, but technically feasible.

We normally keep rebasing cockpit all the way to the X.10 release, but it becomes locked down in the many years of EUS after that. Plus, in the future we may have other "replace docker by podman" transitions between major releases which we can't retrofit into older RHELs.

Ideas:

• ✅ In any case we want to keep the behaviour of not accidentally transitioning from beiboot to "installed rpms". Disable the Apps page and other on-demand installs of cockpit-* packages (we in fact just lost the last one with eliminating cockpit-pcp) with beibooting. https://github.com/cockpit-project/cockpit/pull/21117

• ✅ As an "entry level" feature, check the target os-release and only support connecting to the same distro/release as the host. https://github.com/cockpit-project/cockpit/pull/21121

• Extend this by carrying an automated list of vetted target OSes (matching our test maps). It could then either refuse to connect, or show a "here be dragons" warning. This requires reworking the login page "no-cockpit" alert a bit, to show a list, and support paragraphs.

• ❌ Provide a RHEL+extra build of cockpit/ws. But the caveat is, it must be "always up to date", i.e. keep up with upstream Cockpit versions even after the RHEL release and freeze. Research if it is possible to pull in contents which does not come from the RHEL distro, like EPEL or a COPR. if that's possible, then this makes sense. If only RHEL rpms can go in, we may just as well support beibooting with these directly (previous idea)

• 🛑 Do the RHEL cockpit/ws build on e.g. RHEL 10, and test/support running it on RHEL 8/9. Is that legit? (Asked Mark Russell and Scott McCarty) via rhn-support-briasmit). See RHEL container compatibility matrix, this is currently being updated for RHEL 10. Postpone this idea for now, but keep it on the shelf should the use case ever come up.

• ❌ There is also be the option of building a RHEL flatpak, see https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html-single/8.7_release_notes/index#deprecated-functionality_containers . However, Brian says they are not hugely popular, and the advantage/effort ratio is too low. Let's rather just check that the official public flatpak works well on RHEL 9/10.