[systemd-devel] os-release: extension to expose host's version variables to containers

Luca Boccassi Luca.Boccassi at microsoft.com
Thu Apr 16 14:03:43 UTC 2020


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.

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

We could of course apply a similar internal work-around as well and be
done with it, but in my opinion this is a general issue, and the very
nice thing about the os-release interface is that of course it's common
and generalized, and everyone uses it, so it can be relied upon without
downstream out-of-tree patches.

I would like to propose an extension for this use case, so that we can
have the same advantages.

Given time, I'd be of course happy to implement it in various
components, starting with systemd-portabled and nspawn.

Here's a couple of ways this could look like:

1) separate os-release-host

The component responsible for setting up the mount namespace will mount
the host's os-release under a different path. This can be an existing
ephemeral directory like /run or a new one like /host.

Pros:

- very simple to implement

Cons:

- finding agreement on a new path is harder (bikeshedding on new file
name is likely to ensue!)
- since the new file won't exist in images, it can't be in the logical
place in /etc but will have to be in an ephemeral new location, like
/run or /host
- existing permissions to open os-release (eg: SELinux) will not be
enough
- behaviour if running in host vs running in container is quite
different


2) "merged" os-release

The component responsible for setting up the mount namespace will merge
the content of os-release files from host and guest. Variables from the
host will be prefixed with HOST_ to disambiguate (or the other way
around with GUEST_).

Pros: 

- same file used, no additional paths/permissions required
- behaviour running in host vs running in container is more similar

Cons:

- much more additional work required to set up the FS namespace


I'm sure there are many more options, these are the first two that
sprung to mind.

Thoughts?

Thanks!

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200416/2babb7de/attachment.sig>


More information about the systemd-devel mailing list