fedora remote flatpaks require session dbus
As reported at Silverblue's Github issue tracker, there are some oddities in conjunction with flatpaks from the fedora remote.
It seems impossible to install flatpaks without access to a running session dbus. Neither sudo flatpak install nor sudo -i and then flatpak install works, it always fails with one of those two errors depending on the specific environment I'm in:
error: Failed to execute child process ?dbus-launch? (No such file or directory)
error: Cannot autolaunch D-Bus without X11 $DISPLAYMy working hypothesis is that OCI flatpaks require dbus for something OStree flatpaks do not.
My concrete use-case is remote configuration using puppet manifests which currently throws lots of errors of the first type.
Activity
AFAICS this is due to flatpak (the program/package itself). Because container registries may support or even require authentication (e.g. the Red Hat Container Catalog, or even Docker Hub wrt avoiding rate-limiting), flathub includes a
org.flatpak.Authenticator.Ociservice which handles registry authentication tokens when installing an OCI-formatted flatpak. AFAICS this seems to be used even when the registry does not require authentication (such as Fedora's). Without a session bus, the install therefore fails.Fedora and Red Hat have chosen to flatpaks in OCI format, so there is not much we can do about this, besides possibly document it. Perhaps there is a way for this to only be required when the registry actually requires authentication, but implementing that is certainly outside my purview, and maybe there just isn't.
I see. Thanks for the explanation. But this mechanism disrupts unattended provisioning, unattended updates, remote user support and several other use-cases. Other than avoiding OCI repositories there's nothing to do.
I will return to Silverblue's issue tracker with this information and ask where to report this downstream. IMHO this impedes the manageability of the OS.
Thanks again!
@MasinAD this is the right issue tracker, please don't report it again against the Silverblue's issue tracker.
While Tomáš is correct that the Silverblue folks can't do anything about this, to be honest, at least right now we can't either. Since this is an issue in flatpak itself, and we don't have anyone working on flatpak itself involved in the SIG, there is nothing we can currently do about this. At this time, your best bet would be to file a bug in Red Hat Bugzilla (Fedora product, flatpak component), or an issue upstream in the flatpak project, as that should be seen by people who actually work on the flatpak code.
