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
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
