Description of Problem: With the following entries in /etc/nsswitch.conf: passwd: files nis shadow: files nis group: files nis When the server experiences a failure talking to the NIS server, it returns "YPBINDPROC_DOMAIN: Domain not bound" even though the user exists in the local /etc/passwd. Version-Release number of selected component (if applicable): glibc-2.2.4-24 Expected Results: Even when the NIS server is unavailable, accounts in the local files should still continue to work. Additional Information: The application that reports this error is vsftpd in case that is significant. This server is also running nscd.
See also Bug 71546: ldap for user files always used, regardless of nsswitch.conf Bug 63631: local users never authenticated if ldap server down Bug 58568: nis for host files always used, regardless of nsswitch.conf
I appears that this failure to use local file problem has been resolved in rawhide. See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84105#c6 for details.
A clarification on: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84105#c6 You should NOT install those RPMs on a production system. Rawhide is raw bits. Those RPMs were only in relationship to various DNS issues. Those rpms have a number of non-DNS related problems. For example, they cause the rpm command to dump core. They did, however, resolve the DNS issues, with the possible exception of excessive IPv6 lookups.
I don't think any recent release had any such problem. I wasn't able to interrupt the NIS communication but shutting down a NIS server didn't have any effect. In fact, there was no attempt to use NIS if the entry was found by nss_files. I'm cloing the bug now.
I can reproduce this at will on RHL 9 (and just did). 1. Set up a NIS master. 2. Set up a NIS client. 3. Put passwd: files nis shadow: files nis group: files nis in nsswitch.conf on the client. 4. Pull the network cable on the NIS master 5. Try to log into the NIS client using the root account (stored in /etc/passwd and /etc/shadow on the NIS client) and watch it fail 6. Plug the cable back in on the master, and discover that the NIS client is then able to use the account in /etc/passwd and /etc/shadow
That's unrelated. People, I've said more than once: glibc != PAM. If you want to show a bug in glibc don't use a problem which uses PAM. This screwed up lookup is, from all I can see, a PAM problem.
See Bug 71546 glibc *is* broken, and until 71546 is resolved, it won't be clear whether this breakage in NIS is glibc or PAM.
And 71546 is closed.