Here's my initial version of the cleaned up patch for adding a --chroot-mode=systemd-nspawn. Some things I'm not sure about: - Should we maybe ping upstream and/or Debian maintainers on https://github.com/systemd/systemd/issues/13297 to see how hard it would be to get it fixed so I could remove that whole ugly workaround? (The workaround also only handles bind mount settings at present - and for example, I've found that a lot of package builds will require SystemCallFilter=@memlock due to a lot of crypto libraries and utilities giving errors if they're denied access to mlock. So I would probably want to add that to my /etc/systemd/nspawn/unstable-amd64-sbuild.nspawn config file.) - It currently requires giving sudo access for systemd-run, which essentially would open up execution of anything desired. And the fact that it requires NOPASSWD (because some of the commands redirect stdin/stdout) makes things even worse. And even if you restrict it to e.g. "systemd-run -M unstable-amd64-sbuild*" it still seems it would be possible to fool that with something like "sudo systemd-run -M unstable-amd64-sbuild -M .host ~/myevilcmd". - If you want to ignore the small patch in lib/Sbuild/Chroot.pm that's fine. It's not really related to the systemd-nspawn chroot mode. - It does add a dependency on libipc-run-perl. - It would be nice (as a future enhancement) if it would be possible to configure this backend to start the container in --network-veth mode and set up the host's side of the veth to forward only traffic to/from apt-cacher-ng on localhost:3142. Not sure how hard that would be to accomplish.
I just realized based on some testing that I forgot to send part of the patch, which is needed for sbuild-update to work with the systemd-nspawn chroot backend.
workaround? would As mentioned on https://github.com/systemd/systemd/issues/13297 adding --ephemeral means the machine name has a randomized suffix. Passing -- machine=$chroot should ensure the config files are picked up as expected. fact to This seems to be used to implement manual synchronization, but this is not necessary as it's already implemented, see: https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#--notify-ready=
OK, if I did that, then would that mean that it's no longer possible to have two sbuild processes using the same base chroot at the same time? (Not that that would be too much of an issue in practice. Though I do admit it's convenient to be able to have my micro_buildd script running one sbuild instance, while on another terminal I can run a manual build with e.g. DEB_BUILD_OPTIONS=nocheck sbuild ... --profiles=nocheck tobootstrap_1.0 .) That's just one use of systemd-run, and a minor one at that. The main use is to run the commands that sbuild needs to invoke, from "apt-get update", "apt-get dist-upgrade", "apt-get source package=ver", "dpkg-source -x filename.dsc", "dpkg-buildpackage" (with --property=PrivateNetwork=yes on this one), "cat *.changes" into a pipe, etc. And as for synchronization, I think I do remember seeing the --notify-ready option. But the man page said the notification would be going to systemd, and I didn't immediately see any way for the sbuild parent process to get that notification or to wait for it.
On Mon, 4 Apr 2022 15:28:01 -0700 Daniel Schepler <dschepler@gmail.com> wrote: wrote: it - require https://github.com/systemd/systemd/issues/13297 adding -- Ok, sounds like it's worth supporting: https://github.com/systemd/systemd/pull/23110 it would is https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#--notify-ready= main Any reason to boot the chroot instead of just running commands in it? That would remove the need for all of this, no?