[Nix-dev] Re: Chroot builds and NSS modules

[Ludovic Courtès]

Hi,

Eelco Dolstra <e.dolstra at tudelft.nl>
writes:

> No, it's not about build problems in the chroot but about this bug:
>
>   http://bugs.strategoxt.org/browse/NIXPKGS-79
>
> I.e. packages that link against the Nixpkgs Glibc cannot do DNS
> lookups on Ubuntu, because it has this line in /etc/nsswitch.conf:
>
>   hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
>
> This fails because "mdns4_minimal" can't be found and
> "NOTFOUND=return" causes Glibc to not continue to "dns".  This is
> actually a bug in Glibc: failure to load the service should cause an
> UNAVAIL error, not NOTFOUND (which means "the service says that the
> name doesn't exist").

That's actually the same problem as when you set `avahi.nssmdns' to
`true' in your configuration: the same `nsswitch.conf' is installed,
leading to the same problems in the chroot.

>> fact that the chroot sees a `resolv.conf' that specifies NSS modules
>> that aren't mapped in the chroot.  I can think of two solutions:
>>
>>   1. The best solution IMO would be to selectively bind-mount all NSS
>>      modules into the chroot and somehow make sure that they are in the
>>      lib search path of `curl' and other applications.
>>
>>   2. A simpler solution would be to provide the chroot with a
>>      `resolv.conf' that does not refer to any external NSS module.
>>
>> Now, I fail to see where the chroot gets its `/etc/resolv.conf' from.

I really meant `nsswitch.conf', not `resolv.conf'.  Sorry for the
confusion.

>> `DerivationGoal::startBuilder ()' in `libstore/build.cc' lists only
>> `/dev', `/proc', and `/nix/store' as the paths that are mounted by
>> default in the chroot.  So where's `/etc'?  Or is the above explanation
>> incorrect?
>
> No, you're right.  When I implemented the chroot option I didn't
> consider DNS resolution.  So fetchurl derivations currently just fail
> in a chroot.  But there is a simpler solution: we could just *not*
> execute fixed-output derivations like fetchurl in a chroot.  ("Fixed
> output derivations" are derivations that specify the outputHash
> attribute, i.e. the cryptographic hash required for the output.) Since
> they have a guaranteed output anyway, we don't really care about their
> purity, unlike normal derivations.

Hmm, yes, but I'd prefer solution (2) above, which avoids
special-casing.

So where does the chroot's `/etc' come from?

Thanks,
Ludovic.