Red Hat Bugzilla – Bug 449126
nscd does not follow NIS server binding changes
Last modified: 2008-09-26 16:02:38 EDT
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. :-)
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.
Would the dhclient folks be interested in an enhancement to /sbin/dhclient-script to restart nscd when HUP-ing ypbind?
(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.
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).
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.