Re: os-release: extension to expose host's version variables to containers

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Do, 16.04.20 14:03, Luca Boccassi (Luca.Boccassi@xxxxxxxxxxxxx) wrote:

> Hi,
>
> We find ourselves in a situation where application running
> containerized (specifically as portable services, although this issue
> is general) need to either find information about the host, or alter
> their behaviour depending on the host's flavour.
> At the same time, applications also need to find information about the
> guest's OS, so simply bind mounting /etc/os-release from the host is
> not enough. We need both.

Hmm, usually containers are about isolation, i.e. avoiding that host
data leaks into the container as far as that's possible.

We currently pass very little info from host into container, i.e. just
the container manager's own name via the $container env var set for
PID 1 (see: https://systemd.io/CONTAINER_INTERFACE/).

I am not opposed to passing os-release into the container somehow. I
mean, effectively the info from os-release can be deduced from "uname
-a" usually, as kernel versions tend to correlate closely with distro
versions.

> I did some research and I cannot find a generalized, common solution.
> But I found at least one other use case where this is needed, and the
> solution there is to add a new directory /host/ which replicates part
> of the host's filesystem tree, including os-release:
>
> https://docs.netdata.cloud/packaging/docker/#run-netdata-with-the-docker-command
> https://github.com/netdata/netdata/issues/7488

Somewhat related but also not: nspawn has a magic dir for passing
mounts from host to container in /run/systemd/nspawn/incoming, I guess
passing info such as os-release or so into a containar is conceptually
not too different.

I think making os-release available in the container as-is would be OK
(either mounted immutable or copied in).

An alternative would be to just pass the most basic info from
os-release to the container, unconditionally, similar to the
$container stuff. i.e. just the identification bits from
/etc/os-release, i.e. introduce env vars $container_host_os,
$container_host_os_version, $container_host_os_build,
$container_host_os_variant, initialized from the various XYZ_ID=
fields from /etc/os-release. That would be simple enough to make it
something we could just declare part of the container iface and do
unconditionally. It leaks just the implementation ids into the
container but no host identifiers, and hence should be OK to do
unconditionally. Would that suffice for your usecase?

I am tempted to say this discussion is specific enough to be tracked
in a github RFE issue btw, so that we don't lose track of it.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel