Bug#844459: autopkgtest: Please add autopkgtest-virt-uchroot
Hi,
Quoting Martin Pitt (2016-11-16 16:17:29)
> Johannes Schauer [2016-11-16 14:13 +0100]:
> > Unfortunately, I was unable to achieve the same I'm currently doing with
> > lxc-usernsexec and lxc-unshare with unshare and nsenter.
>
> Interesting; now you sparked my curiosity :-) Do you happen to
> remember the details what isn't working?
some archaeology from my side would be required to try to recover my attempts
from the past (as long as one year ago). Some of the problems are documented
here:
https://blog.mister-muffin.de/2015/10/25/unshare-without-superuser-privileges/
For example, most notably, "mount -t proc proc /proc" never worked without
doing the systemcalls manually using the perl script I present there. This
problem of course might also have been due to remaining bugs in the tools I
used (including my kernel) which are long fixed now. Though the fact that the
last line in that post still throws an error indicates otherwise:
lxc-usernsexec -m b:0:1000:1 -m b:1:558752:1 -- unshare --mount-proc=/tmp/buildroot/proc --ipc --pid --net --uts --mount --fork -- true
unshare: mount /tmp/buildroot/proc failed: Invalid argument
> > Despite reports claiming otherwise, I never got lxc to run without superuser
> > privileges. Is it easier with lxd?
>
> It's not hard to do, but indeed "classic" LXC hasn't really been
> designed for that from the start. Unprivileged containers are the
> default mode of operation for lxd, so it's literally "sudo apt install
> lxd", "sudo lxd init"(to set up its bridge, basically pecking on Enter
> 20 times), then "autopkgtest my-package/ -- lxd images:debian/sid/amd64"
> works as normal user.
Wow, that's awesome!
Now I'm wondering whether uchroot is still useful if there is just some
packaging of another piece of software that's missing.
> Right, that's why I think it should exclude /dev wholesale, and then the code
> below makes sure to construct a known-working and minimal /dev.
Can also be done.
> > That can be done. It will just not be used by sbuild because sbuild makes
> > no requirements for the backend to provide that functionality and thus
> > "squeezes everything through a pape" independent of the backend.
>
> That's got nothing to do with sbuild -- this is just internal
> communication between teh "autopkgtest" controller process on the host
> (which has the initial package) and the virt backend in the testbed
> (which receives the tests, and sends back results).
Of course. It just has something to do with sbuild for me, because my
motivation to write this backend is because I want to run sbuild without
superuser privileges.
> > I have another autopkgtest-specific question. Currently, when using this
> > code with sbuild and I hit Ctrl+C to send a SIGINT, it appears as if
> > autopkgtest would immediately call hook_cleanup(). Can that be? How do I
> > prevent that from happening? It only happens with my uchroot backend and
> > not any other, so I'm probably doing something wrong. Trapping SIGINT in
> > the shell script doesn't seem to have any effect.
>
> Right, lib/VirtSubproc.py does that in prepare(). The idea was that ^C
> would cleanly shut down the virt runner, then the frontend
> (autopkgtest) would notice and do its cleanup part.
>
> How is calling hook_cleanup() not working/not enough for uchroot? We can
> certainly make that more flexible if needed.
Then I still don't understand something. In sbuild, when I hit ^C, the
autopkgtest schroot backend does not seem to get closed immediately because
sbuild is still doing some cleanup stuff before sending the "close" command to
autopkgtest.
But with the autopkgtest uchroot backend, the hook_cleanup() seems to get
immediately called after my ^C, thus the cleanup code will fail and the "close"
command will be futile because the autopkgtest pipe does not even exist anymore
at that point.
So I don't understand this difference in behaviour.
Thanks!
cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20161116/6714da27/attachment-0001.sig>
Reply to: