Bug 449126 - nscd does not follow NIS server binding changes
Summary: nscd does not follow NIS server binding changes
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dhcp
Version: 5.1
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: David Cantrell
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-30 16:33 UTC by Chris Schanzle
Modified: 2008-09-26 20:02 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-09-26 20:02:38 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Chris Schanzle 2008-05-30 16:33:39 UTC
When switching NIS domains without rebooting, nscd continues to use the old NIS
server and thus, unexpected data.  Only when nscd is restarted does it use the
new NIS binding.

Version-Release number of selected component (if applicable):
glibc-2.5-18.el5_1.1

How reproducible:
Always

Steps to Reproduce:
We migrated to a new NIS domain and new set of servers, so we changed
"domainname" and /etc/yp.conf and HUP-ed ypbind (actually done via
DHCP/dhclient-script).  In the new domain, we have an account that doesn't exist
in the old domain.  So for testing, add the appropriate 'domain' lines for both
NIS domains to /etc/yp.conf and set up toggle functions new and old:

OLDDOMAIN=<OldNisDomain>
NEWDOMAIN=<NewNisDomain>
old () { domainname $OLDDOMAIN; pkill -HUP ypbind; ypwhich; }
new () { domainname $NEWDOMAIN; pkill -HUP ypbind; ypwhich; }

[ypbind will occasionally die if you toggle too quickly, but that's a different
issue.]

With the old domain as the current domain, ensure you start with clean nscd
cache data:

 service nscd stop; rm /var/db/nscd/*; service nscd start

Verify test account doesn't exist:
 getent passwd foo
 ypmatch foo passwd

switch to new server, wait for negative TTL to expire, repeat:
 new; sleep 22; getent passwd foo

Note, however, that ypmatch WILL find the data:
 ypmatch foo passwd

Running strace -f on nscd will show it is using the old domain's
/var/yp/binding/<olddomain> rather than the new domain.  Tracing network packets
confirms this.  This state remains unchanged (a week passed) until nscd is
restarted.

Additional info: test NIS clients are CentOS 5.1 systems; old NIS server is
Solaris, new NIS server is RHE..., err, Red Hat Enterprise Linux 5.  :-)

Comment 1 Ulrich Drepper 2008-06-04 14:45:17 UTC
Just as for resolv.conf, it is the sysadmin's responsibility to notify the
programs using NIS.  It's not acceptable to introduce the significant overhead
to monitor changes to that file.  Just restart nscd.

Comment 2 Chris Schanzle 2008-06-04 21:48:45 UTC
Would the dhclient folks be interested in an enhancement to
/sbin/dhclient-script to restart nscd when HUP-ing ypbind?

Comment 3 David Cantrell 2008-09-26 03:59:46 UTC
(In reply to comment #2)
> Would the dhclient folks be interested in an enhancement to
> /sbin/dhclient-script to restart nscd when HUP-ing ypbind?

Not really.  You can create /etc/dhclient-enter-hooks and /etc/dhclient-exit-hooks to extend what dhclient-script does when it's called.

Sending SIGHUP to nscd is more of a site-specific issue, which is what the hook scripts are supposed to solve.

See the man page for dhclient-script for more details.

Comment 4 Chris Schanzle 2008-09-26 17:46:12 UTC
David, if dhclient-script restarts ypbind and ntpd services "as needed", wouldn't it make sense to also restart nscd?  Is there something in particular that makes nscd more site-specific than ypbind/ntpd?

I'd be happy to attempt a patch (there's plenty of good sample code), but not if there's no chance to get it incorporated.

On a related note, sendmail also continues to use old DNS servers, so if DNS (resolve.conf) changes, sendmail needs to be restarted too (I'd be happy to file a separate bug report+fix if appropriate).

Comment 5 David Cantrell 2008-09-26 20:02:38 UTC
dhclient-script cannot infinitely expand for every program that needs a kick each time the network settings change.  If I allowed this, I would always be changing dhclient-script and that would get annoying for QA and testing.

For ntpd, we need to ensure it stays up to date with the latest required info because an accurate time keeper is required for NFS mounts (which you may have on your system) and for certain login services.

ypbind needs a restart because if we fail to do that, we could potentially prevent people from logging in.

So, ntpd and ypbind fall in to the critical category, so they are in dhclient-script.

nscd, sendmail, and other services that are not always running and not required to keep the system going, you need to deal with those in one of the hooks script.


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