Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 66682

Summary: unexpected nsswitch behavior
Product: [Retired] Red Hat Linux Reporter: Need Real Name <aander07>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: chris.ricker, fweimer, jos
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-04-25 03:45:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 71546    
Bug Blocks:    

Description Need Real Name 2002-06-13 15:27:10 UTC
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.

Comment 1 Chris Ricker 2003-01-07 05:52:53 UTC
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

Comment 2 Landon Curt Noll 2003-02-22 15:22:14 UTC
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.

Comment 3 Landon Curt Noll 2003-02-25 19:27:16 UTC
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. 

Comment 4 Ulrich Drepper 2003-04-24 04:18:11 UTC
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.

Comment 5 Chris Ricker 2003-04-24 14:35:33 UTC
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


Comment 6 Ulrich Drepper 2003-04-24 20:37:47 UTC
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.

Comment 7 Chris Ricker 2003-04-24 20:40:56 UTC
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.

Comment 8 Ulrich Drepper 2003-04-25 03:45:12 UTC
And 71546 is closed.