|author||Joey Hess||2019-04-08 13:32:32 -0400|
|committer||Joey Hess||2019-04-08 13:32:32 -0400|
change from inChroot to granular container capabilities info
* Removed inChroot, instead use hasContainerCapability FilesystemContained. (API change) * Hostname: Properties that used to not do anything in a systemd or docker container will now change the container's hostname, since it's namespaced. More container capabilities can easily be added later, to fine grain control what properties will run in different kinds of containers. This changed CmdLine's Read instance, which should be ok, because propellor inside the container is always updated at the same time as propellor outside, so when it chains into the chroot, it will know to expect the capability list. Docker was not setting InChroot before, but now sets both container capabilities, so chroot setting will also work in it. Note that, things that used to check inChroot before would not work in docker, but things that check FilesystemContained now will. It may be that some of those properties don't really work properly in docker. And, Grub.installed used to run grub-mkconfig in a docker container before, I doubt that made sense (was it even safe?); it doesn't do it now. This commit was sponsored by Trenton Cronholm on Patreon.
Diffstat (limited to 'doc/todo/Hostname_is_not_set_in_a_systemd_container.mdwn')
1 files changed, 2 insertions, 0 deletions
diff --git a/doc/todo/Hostname_is_not_set_in_a_systemd_container.mdwn b/doc/todo/Hostname_is_not_set_in_a_systemd_container.mdwn
index e88dcac6..6b6db329 100644
@@ -8,3 +8,5 @@ Note: I use `Systemd.containerCfg "network-bridge=br0"`, so the container has
a different network stack.
I suppose that the `check (not <$> inChroot)` might be the problem here.