We were wondering why confined snaps see host info in /etc/lsb-release but base-snap info in /etc/os-release. Is this intended? Could it be an oversight?
Context
We’re using Qt (QSysInfo) to find system info across the platforms where Multipass can be installed (including Windows and macOS). When in a snap, it produces the wrong info from /etc/os-release.
We know we could read from /var/lib/snapd/hostfs/etc/os-release directly on Linux, but we’d need a custom implementation, either reading os-release and plugging system-observe or bypassing the extra interface and reading from lsb-release. We now got a PR proposing the latter and would like to clarify this, to decide how best to proceed. Thanks!
what i remember is that lsb-release has not been parseable from shell for a long time (it used to have spaces around the equal signs and no quoting for strings containing spaces) and actually forced you to use the python lsb_release tool which in turn pulled in a bunch of python dependencies …
AFAIK that was the reason systemd standardized around the shell/C parseable os-release file …
snapd (and with it Ubuntu Core as well as the core/base snaps) followed suit here … i’d always go with os-release, especially since there are distros you can install snapd on that will not support/have lsb-release at all, but every distro having systemd will have os-release since it is required for it …
Well, as the other posts says, you can use system-observe and will have access to /var/lib/snapd/hostfs/etc/os-release to see the hosts os-release file … sadly you can not use a layout to overlay this file, so accessing it likely requires code changes in your app …
they are two different tools coming from two different sources/places and are of different age … no idea why they never got synced up (i assume you’d have to merge the info from both in both files to make sure they are backwards compatible …)
ah, well, os-release gets adjusted at build time, since the base snaps do not ship all the python modules and the lsb_release binary and since lsb-release is said to only be read by the lsb_release utility, it does not get touched at all but contains what comes from the archive …
here are some respective bugs where it was discussed back when we made the changes:
Hmm, sorry if I am missing something, but skimming through those bugs, I couldn’t find anything directly bearing on this.
OTH, does your explanation mean that this is just some sort of fortuitous outcome of implementation details, not necessarily the way the filesystem is supposed to look like to snaps? Since snaps see contradictory info in those files, that would be a bug, right?
I’m trying to puzzle out all the info you’re providing but I am afraid I am still unable to figure out an answer to my original questions: “Is this intended? Could it be an oversight?”
IMO, there is a difference between running a core snap on a host and running Ubuntu Core as the host. If it’s the core{16|18|20} snap, then shouldn’t /etc/os-release reflect what the host is?
If it’s Ubuntu Core{16|18|20} running, then yeah, I think /etc/os-release should reflect what we see now like PRETTY_NAME="Ubuntu Core 16".
not from a snap perspective … the base snap is your runtime env … host files are only accessible via /var/lib/snapd/hostfs in both cases…
(note that i was proposing several times in these bugs to remove /etc/lsb-release but that was turned down by architects … perhaps we should re-consider this and simply remove it)
The difference is caused by the fact that much of /etc comes from the host (at least on classic systems). This coupled with /etc/os-release being a symlink to /usr/lib/os-release produces this confusing view.
So you get /etc/lsb-release which comes from the host, and /etc/os-release which points to /usr/lib/os-releases which inside the snap mount namespace happens to be /usr/lib/os-release shipped by the base.
Note, the apparmor profile may actually prevent the application from reading /etc/lsb-release. If you really want to know about the host system, there’s a system-observe interface which @ogra linked to earlier.
Yeah, it would be nice to have /etc/lsb-release removed since it’s basically being said not to use that and it only adds confusion that it differs from /etc/os-release.
Yes, we could connect system-observe and poke the host’s /etc/os-release, but we are trying to use Qt’s QSysInfo which hard codes the /etc/os-release path. QSysInfo works for all other platforms we support (macOS, Windows, and running non-snapped Multipass) so having a special case just for snaps is extra maintenance.
In the end, this is an intentional decision and is the hand we are dealt, so we’ll have to deal with it. Thanks!
tell me about it (i do maintain the zoom-client snap … who decided to base the ability to run properly on wayland on the content of os-release … ) … QSysinfo is definitely a bit painful here …
Thanks @mborzecki, @ogra, I get the picture. So it’s back to the system-observe option I mentioned in the OP.
As an aside, I think QSysInfo can hardly be blamed. /etc/os-release is part of the interface systemd offers, it’s just snaps that change that. It’s one thing to deny access to things, another to silently replace contents…
As I was saying early, IMO there is a difference between a core snap running on a host and Core being the host. I understand the core snap is a runtime environment, but it’s a hybrid in that it still relies on the underlying host’s environment. The core snap still uses the host’s systemd (amongst other services) to do things it needs to do, but Ubuntu Core has systemd and other services with it. Silently replacing what the host’s systemd sets up is quite confusing. I guess we’ll agree to disagree on this
what exactly is that difference from a snap perspective ?
in both cases you are running on top of the core snap, in both cases you can only access the outside world through pre-defined interfaces and in both cases any filesystem bits of the host are only visible in /var/lib/snapd/hostfs. why and how would it matter how the OS was originally booted, if it is yocto, gentoo, fedora, SuSE, debian, majaro or ubuntu (core) outside ??
as soon as we make this difference matter in any way, the snap concept has failed IMHO … (and in fact the snapd team works hard to make things as generic as possible to not make the underlying distro matter)
