nscd does not honour NIS compat notation. Consider this /etc/passwd:
If you run it without nscd, the result will be to make available all
the NIS passwd entries as-is, but with the password hash replaced by
"*". If you run it with nscd and do a getent passwd as root, the
password hash will not be replaced (you will get the records wiht the
password hash from NIS).
One would not expect the semantics to change by enabling a cache
daemon. This may be considered a security exposure; someone may have
setup their system this way intentionally, perhaps for example to
require Kerberos authentication on their system but to stil use NIS
for the user directory (this is why I did it). Then they enable nscd
to improve NIS performance, and suddenly the system allows NIS
authentication where it didn't before.
nscd also is not a valid package choice when submitting Bugzilla
tickets. Hopefully assigning to authconfig puts this ticket somewhere
Can't reproduce it here, with
at the end I'm seeing:
while with files nis in nsswitch.conf and that line missing I'm getting
nscd is running in both cases.
Are you sure you have flushed nscd's cache after making the changes in
nscd -i passwd
in this case.
I have upgraded to latest development. I used to be able to get it to fail
every time, no matter what I did (restart nscd, reboot computer, etc.). Now I
got it to fail once (returning NIS password hash instead of *, per the example).
I will do some more testing to see if I can identify what circumstances caused
Well, I have tried for the last 30 mins to make it do it, and I can't -- both
iterating over the entire password file (getent passwd) and looking for specific
users returns the right thing. I also ran nscd in debug and timed the
difference between cached/uncached results, and am fairly sure nscd is doing
something. Sorry for wasting your time on something that was already fixed.
Please go ahead and close.