Re: running autoconf in chrooted environments

[Eric Blake]

On 07/07/2016 02:15 PM, Peter Crady wrote:

[your mailer isn't configured to wrap long lines, which makes it harder
to read and reply]

> This may be a stupid question but is there a good way to run autoconf
in a chrooted environment?

Do it the same way you run any other program - just run it.  Remember,
if you have to modify autoconf to behave differently, then you would
have to modify every other program in the chroot environment in the same
manner; the whole point of autoconf is to probe the actual environment
it is running under.  So if autoconf isn't getting the answers you want,
then it is your environment at fault, not autoconf.

And these days, chroot'd environments aren't as secure as cgroups,
containers or virtual machines, so you may want to look into those
technologies for better isolation of your test environment from your
host environment.

> From what I can tell the AS_UNAME function calls uname which gets
information about the base kernel that is installed and not the kernel
that is installed in the chrooted environment.

If you're referring to uname(1) (the command line utility run by
AS_UNAME), then it is up to you whatever uname(1) binary you installed
into your chroot.  If your uname(1) binary isn't returning the
information you want, then it's your fault for building an incomplete
chroot.  And if your uname(1) in the chroot is returning the modified
information, then AS_UNAME will see that modified information, not the
base kernel information.

If you're referring to uname(2) (the system call, which is generally
what gets used under the hood by the uname(1) binary), then that depends
on whatever kernel is actually running the binary that makes the
syscall.  If you are using merely chroot, then yeah, things are being
run by a single kernel (chroot isolates files, but not the kernel used
to run the files); which is where other technologies like containers
(such as docker) or virtual machines (such as qemu) indeed let you turn
on even more pieces to the point of completely running your test as if
it were a different machine and kernel than the host.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature