On Mon, 4 Apr 2022 15:28:01 -0700 Daniel Schepler <dschep...@gmail.com> wrote: > On Mon, Apr 4, 2022 at 3:03 PM Luca Boccassi <bl...@debian.org> wrote: > > > > On Sat, 25 Jan 2020 11:36:09 -0800 Daniel Schepler > > <dschep...@gmail.com> wrote: > > > Package: sbuild > > > Version: 0.78.1-2 > > > Severity: wishlist > > > > > > 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.) > > > > 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. > > 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 .)
Ok, sounds like it's worth supporting: https://github.com/systemd/systemd/pull/23110 > > > - 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". > > > > 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= > > 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 Any reason to boot the chroot instead of just running commands in it? That would remove the need for all of this, no? -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
