[snap] need to reach out of $SNAP for host properties

[Saviq]

All of our instances are reported as launched on ubuntu-core-18 now, due to strict confinement and base: core18. We should try and find a way to reach out to get the actual host OS.

multipass/src/daemon/daemon.cpp

Lines 116 to 117 in d9a7264

	pollinate_user_agent_string += fmt::format("multipass/host/{}-{} # written by Multipass\n", QSysInfo::productType(),
	QSysInfo::productVersion());

[townsend2010]

Qt reads /etc/os-release when it exists and uses that. Of course, this is the Ubuntu Core info. However, /etc/lsb-release within the snap does have actual host OS info. Sadly, I don't see a way to force Qt to use this ☹️ so it looks like we'll need our own solution for the Linux case.

[Saviq]

I wonder if it's a snapd bug, then, and it should actually expose host's /etc/os-release…

[Saviq]

LXD has this:

https://github.com/snapcore/snapd/blob/5145669ea40e4b02f02605f41b456df540ecb5c9/interfaces/builtin/lxd_support.go#L45-L46

[townsend2010]

Given that the output of /etc/os-release looks like this:

NAME="Ubuntu Core"
VERSION="18"
ID=ubuntu-core
PRETTY_NAME="Ubuntu Core 18"
VERSION_ID="18"
HOME_URL="https://snapcraft.io/"
BUG_REPORT_URL="http://bugs.launchpad.net/snappy/"

I would say that's pretty intentional. That said, I agree that if it's not the actual Ubuntu Core distribution running (and not the core snap), then it should probably have what the host has in there.

Right about LXD, but that still doesn't help with Qt (it reads a hard-coded /etc/os-release) which is why I mentioned that we'd need our own Linux solution.

[Saviq]

I would say that's pretty intentional.

Well, that would be true on a Ubuntu Core 18 system, it is not, on a Classic system with the core18 snap, IMO. And then the discrepancy between lsb- and os-release…

[townsend2010]

Well, that would be true on a Ubuntu Core 18 system, it is not, on a Classic system with the core18 snap, IMO. And then the discrepancy between lsb- and os-release…

Right, what I was trying to say 😄

[townsend2010]

Looking at the core18 environment and code, /etc/os-release is a link to /usr/lib/os-release which is set up by https://github.com/snapcore/core18/blob/master/hooks/018-set-os-release.chroot. The strange thing is that I can't find anywhere in the code where that link is created 🤔

[surahman]

Is the proposed solution to parse the file in /etc/lsb-release when a specific OS hostname is returned by QSysInfo::productType(), and if so what string pattern should I be on the lookout for? Sorry if I am misunderstanding or am oversimplifying things.

I am not running a core-18 image but would it be safe to assume that reading the /etc/lsb-release on such a system would in fact have the core-18 distro information specified there as well?

Parsing the /etc/lsb-release file would require extraction of the two fields DISTRIB_ID and DISTRIB_RELEASE, in my case:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=21.04
DISTRIB_CODENAME=hirsute
DISTRIB_DESCRIPTION="Ubuntu 21.04"

[surahman]

What I am thinking is we try to open the /etc/os-release file if it exists, and if not we failover to the original solution. Psuedocode:

QFile fileDescriptor("/etc/lsb-release")
if (!fileDescriptor.open(read-only-mode))
{
    return make_pair(QSysInfo::productType(), QSysInfo::productVersion())
}
else
{
    // read-in and parse file, return pair.
}

The real question is if the /etc/os-release files have a standard format that would be predictably parsed. I would also be assuming that the /etc/os-release file could be treated as ground truth for version info on Linux based systems.