Some questions before packaging LXC4

[PEB (Pierre-Elliott Bécue)]

Hi,

This question is more specifically targeted at LXC developers (@stgraber, @brauner, if you find some time…)

I see that LXC4 supports CGroups v2. Packaging it into Debian will mean that unprivileged containers won’t work out of the box for users using the unified cgroup hierarchy. Some question arose in my mind following to that:

1. Should we create a custom lxc-start that, if not root, and running systemd, calls systemd --user or ${otherinit} good feature? Do you plan to offer such specific scripts/commands?
2. What about libpam_cgfs? Should it still be packaged and integrated?
3. Are there some other specific things I could have missed and should care about?

Thanks in advance for your help!

[brauner (Christian Brauner)]

Hi,>

This question is more specifically targeted at LXC developers
(@stgraber, @brauner, if you find some time…) >

I see that LXC4 supports CGroups v2. Packaging it into Debian will mean
that unprivileged containers won’t work out of the box for users using
the unified cgroup hierarchy. Some question arose in my mind following
to that:>

1. Should we create a custom lxc-start that, if not root, and running
   systemd, calls systemd --user or ${otherinit} good feature? Do you plan
   to offer such specific scripts/commands?>

Hm, well you could start with providing a downstream wrapped for such cases for sure.
So far we haven’t considered adding a wrapper like that to lxc though I wouldn’t nack it as a workaround if someone were to add it.
I think the better solution would be to teach liblxc to request a delegated cgroup from systemd directly.
So far we have stayed away from that because it might require us to introduce a dependency on dbus (but maybe not) and I didn’t want that (not without a compile-time option).

1. What about libpam_cgfs? Should it still be packaged and integrated?>

We have no current plans of supporting libpam_cgfs for pure unified layouts simply because it doesn’t work and there’s no nice way to make it work, I think.
But I’m happy to hear the input of users.

1. Are there some other specific things I could have missed and should
   care about?>

• Package 4.0.3 directly as it contains a bunch of bugfixes and improvements.
• 4.0.3 will ignore any lxc.cgroup.* directives on pure unified layouts.
• 4.0.3 supports the ebpf devices controller for root-started (both privileged and unprivileged) containers.
  It has the same semantics as the legacy devices configuration keys.
  But instead of specifying lxc.cgroup.devices.{allow,deny} it is specified as lxc.cgroup2.devices.{allow,deny}
  For that to be used the default or common.conf file needs to be changed, specifically all lxc.cgroup.devices lines need to be replaced with lxc.cgroup2.devices lines.

[PEB (Pierre-Elliott Bécue)]

@brauner

Hm, well you could start with providing a downstream wrapped for such cases for sure.
So far we haven’t considered adding a wrapper like that to lxc though I wouldn’t nack it as a workaround if someone were to add it.
I think the better solution would be to teach liblxc to request a delegated cgroup from systemd directly.
So far we have stayed away from that because it might require us to introduce a dependency on dbus (but maybe not) and I didn’t want that (not without a compile-time option).

Are there other init systems that would require specific actions?

Regarding your tweak in liblxc, I guess it would be a better thing for the long term.

[brauner (Christian Brauner)]

@PEB

Are there other init systems that would require specific actions?

Not that I know of. I don’t think openrc makes use of cgroups on its own and I don’t know if it works on cgroup2 layouts if it does.

[PEB (Pierre-Elliott Bécue)]

@brauner I’ve released lxc4 and lxcfs4 in Debian unstable, I’ll try to fine some time to create a script shell that’d do proper things for unprivileged containers when lxc-start is called.