On 3/17/20 2:33 PM, Wolfgang Bumiller wrote: > On 3/17/20 2:24 PM, Thomas Lamprecht wrote: >> On 3/17/20 2:10 PM, Wolfgang Bumiller wrote: >>> On 3/17/20 12:31 PM, Thomas Lamprecht wrote: >>>> On 3/17/20 10:27 AM, Wolfgang Bumiller wrote: >>>>> On 3/17/20 7:35 AM, Thomas Lamprecht wrote: >>>>>> CONTAINER_INTERFACE[0] is omething systemd people call their API and >>>>>> we need to adapt to it a bit, even if it means doing stupid >>>>>> unnecessary things, as else systemd decides to regress and suddenly >>>>>> break network stack in CT after an upgrade[1]. >>>>>> >>>>>> This mounts the parent /sys as ro, child mounts can be whatever. >>>>>> Fixes the system regression introduced by[2]. >>>>>> >>>>>> [0]: https://systemd.io/CONTAINER_INTERFACE/ >>>>>> [1]: >>>>>> https://github.com/systemd/systemd/issues/15101#issuecomment-598607582 >>>>>> [2]: >>>>>> https://github.com/systemd/systemd/commit/bf331d87171b7750d1c72ab0b140a240c0cf32c3 >>>>>> >>>>>> Signed-off-by: Thomas Lamprecht <t.lampre...@proxmox.com> >>>>>> --- >>>>>> >>>>>> I hate it. >>>>>> >>>>>> Just a POC for commenting or picking up, probably belongs in a LXC >>>>>> config or in >>>>>> a "per distro, per systemd version" specific thing >>>>> >>>>> Could `sys:mixed` be enough? >>>>> >>>>> We might need to explicitly rw-mount /sys/kernel/security for nested >>>>> apparmor with either of them. >>>>> >>>>> Since we're effectively reducing access this will surely annoy some >>>>> users. We probably want this to be configurable at first at least. We can >>>>> make it default/opt-out IMO, at least for archlinux containers, but I >>>>> don't like the idea of a more "complex" version check for this. >>>> >>>> Sooner or later you need that anyway, we get now already warning for >>>> the v4/v6 DHCP systemd-network settings, they will be dropped in a future >>>> release, but the new variants ("ipv4", "ipv6") are only available since >>>> systemd version v219 or v220, and other settings will surely also get >>>> replaced sometimes in the future. >>>> >>>> IMO, a "get CT systemd version" helper allows to differentiate between >>>> old and new methods easily without much hassle. >>> >>> I suppose so. Need to figure out a *good* way to do that then. >> >> >> I mean, the single and for me obvious way was to get the systemd binary >> by checking common /lib and /usr path(s) and the just do a `systemd >> --version` >> on that.. > > I'd prefer not to have to execute a guest binary ;-)
Then we need to drop support for CT, because that consist of just executing guest binaries ;) I'd do it in the CT namespace, if possible. > Howabout checking the equivalent of `readelf -d /bin/init` > It's a symlink to /lib/systemd/systemd and links against > libsystemd-shared-245.so > (Taking lxc.init.cmd/lxc.execute.cmd custom settings into account to find the > right init) Yeah, works OK too, I guess. _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
