Brew: glibc: Programs linked against brewed glibc fail to look up username from user id

[sjackman]

_From @waedt on July 31, 2015 6:19_

Basically what the title says. For example, running whoami from brewed coreutils results in whoami: cannot find name for user ID 100358403.

_Copied from original issue: Linuxbrew/legacy-linuxbrew#500_

[sjackman]

Yes, I can confirm that I've also observed this bug. Do you know whether your system is using LDAP or /etc/passwd, or some author authentication system?

[sjackman]

If you're using /etc/passwd, a workaround may be

ln -s /etc/passwd `brew --prefix glibc`/etc/

[sjackman]

I found that the time zone was also incorrect unless I did

ln -s /etc/localtime `brew --prefix glibc`/etc/

[sjackman]

You may need to add the nsswitch.conf file.
See http://www.linuxfromscratch.org/lfs/view/development/chapter06/glibc.html
and look for 6.9.2.1. Adding nsswitch.conf.

[sjackman]

Perhaps also try

ln -s /etc/nsswitch.conf `brew --prefix glibc`/etc/

[sjackman]

_From @neil1hart on July 16, 2016 19:30_

I'm having the same problem after following https://github.com/Linuxbrew/linuxbrew/wiki/Standalone-Installation on red hat. Our work computer doesn't use /etc/passwd but some other authentication.

whoami
whoami: cannot find name for user ID 11230

/usr/bin/whoami
nhart

[sjackman]

_From @waedt on July 16, 2016 21:16_

The workaround I came up with was to symlink /lib64/libnss_sss.so.2 to $(brew --cellar)/glibc/2.19/lib/libnss_sss.so.2. That fixed the issue for me on Fedora 22.

[sjackman]

_From @maxim-belkin on July 17, 2016 20:56_

Thanks for the note. It might be that we have to make glibc depend on sssd

[sjackman]

On my system where whoami fails as above, I noticed that the host glibc has libnss_ldap.so.2, but the brewed glibc does not have this library.

[sjackman]

_From @maxim-belkin on July 19, 2016 16:14_

Fun fact: we need sssd, which needs samba, which is currently compiled --without-ldap ;)

[sjackman]

There is the formula homebrew/dupes/openldap. Perhaps samba could be compiled against that on Linuxbrew.

[sjackman]

_From @andrewyatz on October 14, 2016 10:37_

Also just encountered this same problem on RedHat. @waedt solution worked for me though as @maxim-belkin pointed out we're going to need to compile a lot more to make this work.

[sjackman]

Glad to hear the workaround worked for you. Would you be interested in submitting a PR for glibc that enables compiling libnss_ldap.so and libnss_sss.so?

[sjackman]

_From @andrewyatz on October 14, 2016 16:7_

Ha one PR at a time @sjackman hey ;).

I'd like to but I'm not sure how much time I have to do this ATMO. I would probably require some help from @maxim-belkin who sounds like they've started down this path and help direct me to a sssd client. All I could find was the sssd distro (https://fedorahosted.org/sssd/) and that seemed to talk more about running daemons vs. clients.

[sjackman]

I can't find anything in the glibc documentation on how to enable libnss_ldap or libnss_sss. I hope it's in there somewhere. May have to grep through the sources.

[sjackman]

_From @andrewyatz on October 14, 2016 16:16_

I think what happens is that if you compile sssd that will generate the
required lib for libnss_sss and deposits that into the /lib64 dir.
Depending on the nss file that tells it what plugins to use when performing
lookups (well that's my guess at least). There's some chatter on the NixOS
GitHub org suggesting this is correct
https://github.com/NixOS/nixpkgs/issues/1868.

[sjackman]

Ah, I see. I assumed is was provided by glibc.

• libnss_ldap.so.2 on Debian is provided by http://www.padl.com/OSS/nss_ldap.html
• libnss_sss.so.2 on Debian is provided by sssd

[sjackman]

_From @neil1hart on October 24, 2016 23:36_

Haven't been back here for a bit. I followed waedt comment
ln -s /lib64/libnss_sss.so.2 $(brew --cellar)/glibc/2.19/lib/libnss_sss.so.2
resolved my issues with whoami, ls -al, groups

[nickfraser]

FYI, I believe I had the same issue. htop was unable to convert uids into usernames. For me, adding symlinks to the host's libnss_sss.so.2 _and_ libnss_ldap.so.2 fixed things. Specifically, running the following fixed the issue on 3 separate RHEL systems / versions:

$ ln -s /lib64/libnss_sss.so.2 $(brew --cellar)/glibc/2.19/lib/libnss_sss.so.2
$ ln -s /lib64/libnss_ldap.so.2 $(brew --cellar)/glibc/2.19/lib/libnss_ldap.so.2

Update 22/11/2017:

Still having this issue, however the workaround is slightly different due to glibc being updated to 2.23. Current workaround is:

$ ln -s /lib64/libnss_sss.so.2 $(brew --cellar)/glibc/2.23/lib/libnss_sss.so.2
$ ln -s /lib64/libnss_ldap.so.2 $(brew --cellar)/glibc/2.23/lib/libnss_ldap.so.2

[sjackman]

Thanks for the workaround, Nick. I'm curious to learn how to build these two files within Linuxbrew.

[andrewyatz]

FYI https://arthurdejong.org/nss-pam-ldapd/ also seems to be a fork of the original libraries that provides a libnss_ldap.so.2 library.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[alanhoyle]

I believe I have this issue with getent (installed with glibc/2.19) and namei (installed with util-linux/2.29). I'm running this on a system with an AD/LDAP domain serving users and groups. On my system, I only needed to link in the libnss_ldap.so.2 to make it work. (didn't need libnss_sss.so.2 or /etc/nsswitch.conf.

[jwhite007]

I just wanted to add to this conversation as I ran into a similar situation after my company switched to using Centrify for authentication (https://www.centrify.com/). The brewed coreutils commands and getent were not resolving names from IDs after the switch. I then came across this thread. Thanks to all of you above who have contributed to this solution. ln -s /lib64/libnss_centrifydc.so.2 $(brew --prefix)/Cellar/glibc/2.23/lib/ solved the issue. Name resolution now works.

From /etc/nsswitch.conf:

passwd: centrifydc files nis
shadow: centrifydc files nis
group: centrifydc files nis

[jwhite007]

Amendment to my comment above.

I wanted this to persist through upgrades of glibc, so I've added the symlink to /home/linuxbrew/lib64/ and then I appended that path to my LD_LIBRARY_PATH. Everything works just fine. I suppose that I could have just added /lib64/ to my LD_LIBRARY_PATH, but I didn't want to risk the other files in there interfering with any of the Linuxbrew stuff.