Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 66682 - unexpected nsswitch behavior
Summary: unexpected nsswitch behavior
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 9
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On: 71546
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-06-13 15:27 UTC by Need Real Name
Modified: 2016-11-24 15:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-04-25 03:45:12 UTC


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.