Hi, Quoting Simon McVittie (2020-01-16 19:47:02) > I think I dimly remember someone setting up "the buildd from hell" which > deliberately did this as a QA mechanism, but it doesn't seem to have > continued in any systematic way. is there more information about it somewhere? My inbox has only two emails from xnox and pabs (in CC) about it. How did it work? > I think in an ideal world, we'd have better tools for those users to build > modified packages in a way that more closely resembles what happens on the > production Debian infrastructure - which might for instance mean CI services, > or my vectis[1] tool, or sbuild-debian-developer-setup, or even autopkgtest > (which is really for testing packages, but as a side-effect, it knows how to > build packages in an environment that in practice is going to be > close-to-minimal). My advice would also be to switch from debootstrap to mmdebstrap because the latter is able to create a chroot with only Essential:yes packages in it while debootstrap includes Priority:required packages as well. Alternatively, debootstrap could gain a variant only installing Essential:yes packages and their dependencies (why doesn't it have that already?). > pbuilder and the usual sbuild+schroot setup have the disadvantage of > requiring root privileges and crossing privilege boundaries, but vectis uses > virtual machines (in practice this means kvm group membership or udev/logind > uaccess, to get write access to /dev/kvm) and as namespace/container stuff > gets more powerful and more trusted, I'd hope that we'll get a better ability > to install build-dependencies and do builds in unprivileged containers. That can be done with sbuild. With --chroot-mode=unshare, sbuild looks for rootfs tarballs in ~/.cache/sbuild or you can give it your own tarball with the --chroot option. Since you can create rootfs tarballs without sudo using mmdebstrap, you can setup arbitrary chroots and build packages without any process running with root privileges. If you don't like the security implications of unshared user namespaces, then you might want to try --chroot-mode=autopkgtest and --autopkgtest-virt-server=qemu. Using --autopkgtest-virt-server-opts you can then supply any qemu compatible system image. Using mmdebstrap with fakechroot mode and guestfish you can create these system images without becoming root and without having to enable kernel.unprivileged_userns_clone. Or if lxc/lxd are the unprivileged containers you are talking about, then you can just use --autopkgtest-virt-server=lxc and let sbuild do builds in your existing lxc container. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature