On Tue, 25 May 2010, Andy Akins wrote:
8. Confirmed user is not in /etc/passwd
9. Confirmed using “getent passwd | grep username” that the user is listed.
10. Confirmed using “getent passwd” shows two records for each user except
ldap-only users (one for /etc/passwd, one for LDAP).
However,
“id username”
Returns unknown user
Before the heavy troubleshooting starts, double-check that nscd is
installed, configured, and working. You might want to restart it to
make sure.
Second -- and I personally hate this, though I can attest it sometimes
works -- rebooting the machine will sometimes fix this. In particular,
I've see the nss_ldap stuff have trouble in TLS environments when the
server cert (or the CA that signed it) wasn't present at boot time.
The next step would be to run something like
strace -o /tmp/getent.trace getent passwd username
strace -o /tmp/id.trace id username
I'd identify where id is trying to locate user info and make sure it
looks like the same place getent is using.
On my CentOS systems, I note that id uses read() to access nscd while
getent uses recvmsg(). I'm unsure if that difference would cause the
problem, but it might be a place to look if you've got SELinux logs
auditing things.
--
Paul Heinlein <> heinlein@xxxxxxxxxx <> http://www.madboa.com/
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
