On system with nsscache required "cannot find name for user"

[berdario]

Issue description

I just tried to use Nixops on a new system, this system is managed by puppet and has the following in /etc/nsswitch.conf:

passwd:         files cache

Which means that it's using the following nss module:

https://github.com/google/nsscache
https://github.com/google/libnss-cache

This has thus very similar symptoms (and workarounds) as #31700 but it's a different issue.

Running strace over whoami shows this:

open("/nix/store/g1g31ah55xdia1jdqabv1imf6mcw0nb1-glibc-2.25-49/lib/libnss_cache.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

I see that nsscache is not available in nixpkgs, and I can thus volunteer to package it (when I'll find time for it, unfortunately). But even by having it available, I'm not sure what would be the best way forward:

Adding it as a dependency of glibc seems a bit heavy handed, given that most people won't need it. Should we expect users that require this to create an overlay to add it as a dependency of glibc? (but this means that all their packages will need to be rebuilt from scratch, without being able to rely on the binary caches)

A possible workaround is to set LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libnss_cache.so.2 (or whatever is the path to the libnss_cache)

Steps to reproduce

> nix run nixpkgs.coreutils -c whoami
whoami: cannot find name for user ID 498066

Technical details

• system: "x86_64-linux"
• host os: Linux 4.9.0-5-amd64, Debian GNU/Linux, noversion
• multi-user?: no
• sandbox: no
• version: nix-env (Nix) 2.0
• channels(berdario): "nixpkgs-18.03pre129212.098c7f3d945"
• nixpkgs: /nix/store/lmg9r94g2dq9prd87n8jzcdga6nglmk7-cfc4fcf05293f15d02a1f6358e24ec389d7f9b30.tar.gz

[dezgeg]

In NixOS, we enable NSCD and set system.nssModules which adds such packages to nscd's LD_LIBRARY_PATH.

[berdario]

Uhm, good to know. But in this case it's not a system service. Every program that requires to find information from /etc/passwd seems to have a dependency on it (whoami, sudo, ssh, etc.)... So I don't think I can change the LD_LIBRARY_PATH of a single system Sent from mobile. Please excuse my brevity. On 4 Mar 2018 16:14, "Tuomas Tynkkynen" <notifications@github.com> wrote:

[dezgeg]

That was the suggestion; i.e. to enable NSCD as a system service from your distro. In fact if you do that, you don't even need to package nsscache at all and just use the version from your distro.

[bhipple]

I'm running into the same problem, but with sssd and libnss_sss.so. Assuming that we don't want to modify the host OS (RHEL 7.4 in my case), is the best way forward to set an overlay that adds sssd as a dependency of glibc, as berdario suggests?

[knedlsepp]

I'd also love to know if there is a better solution than setting LD_LIBRARY_PATH?

[bhipple]

I've been using this successfully on RedHat 7.4 for the last 8+ months:

  glibc = super.glibc.overrideAttrs(old: {
    # By default, it only supports LC_ALL=C, not en_US.UTF-8
    installLocales = true;

    # Hack: this adds the RedHat SSSD library in a location where anything using
    # the NixPkgs glibc can find it. Ideally this would depend on
    # ${super.sssd}/lib/ instead of /lib64, since that would keep the
    # dependencies closed in NixPkgs, however adding a sssd dependency in glibc
    # creates a circular dependency. We could add sssd to the stdenv multi-phase
    # bootstrap processes, but doing so would drag a large number of packages
    # into stdenv and is much more complicated to implement.
    postInstall = old.postInstall + ''
      ln -s /lib64/libnss_sss.so.2 $out/lib/libnss_sss.so.2
    '';
  });

As @berdario mentions, the libnss_xxx.so library is a dependency of glibc itself and is needed to resolve uid, gid, etc. lookups; this means just about every package on the system needs a glibc that can find this shared library. Rather than modifying user and application environments, the above puts a symlink next to the NixPkg glibc. This obviously is going to blow your build cache for just about everything, but it does let you avoid having to set env vars for basic system utilities to work.

(I noticed that the glibcLocales package wasn't being brought in the way you'd expect, so that's there too.)

If someone has suggestions for a pure solution I'd be eager to hear it!

[flokli]

As suggested by @dezgeg, simply installing and enabling nscd on your distro (and disabling its caching as done in nixpkgs' nscd.conf will cause the glibc used for nix-built packages to use whatever nss modules are available on your system, including nsscache.