Slow NIS update

A customer of ours is having a problem with their NIS server on a
machine, where changes to the password can take up to a few hours to
filter down to all the clients. We have tried to reproduce the problem
elsewhere but are unable to. Is anyone able to suggest a reason or a
solution to this problem? Any help is greatly appreciated. Thanks,

Anthony Perkins

Anthony Perkins <(E-Mail Removed)> said:
>A customer of ours is having a problem with their NIS server on a
>machine, where changes to the password can take up to a few hours to
>filter down to all the clients. We have tried to reproduce the problem
>elsewhere but are unable to. Is anyone able to suggest a reason or a
>solution to this problem?

Check that you don't have rogue NIS slave servers set up in your
environment (running "ypwhich" on all machines and comparing the
list of results to your authoritative list of NIS slave servers
should be a good start; even better would be to do a RPC scan
throughout your network and find out which machines provide NIS
server services). Configure clients with a list of authoritative
NIS servers for your NIS domain (if suported by your NIS client).

Check the configuration on master server to verify that passwd map
gets rebuilt whenever a password is changed (I recall this comes from
yppasswdd configuration).

Then check that the rebuilt map gets immediately pushed to the slave
servers (if you have any).

You can, to some extent, debug this with yppoll - it will show you the
map version numbers from different servers, so:
- check map version number on all NIS servers in the domain
- initially, version numbers for passwd map should be consistent
- change a password
- check map version numbers;
- should've changed on the master server immediately
- should change on the slave servers within couple of minutes
(if not in seconds)

If problems with the map distribution, check first the configuration and
log files on the master server (run the NIS server programs in debug
mode if possible). If nothing is found on the master, check the slaves.
Make sure that there are no authentication problems prohibiting updating
of slave server maps from the master.

Pretty much there; it's some years since I last saw a NIS environment, so
I'm writing based on a bit hazy recollection of things, so adjust where
it seems necessary.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

On Mon, 06 Sep 2004 09:20:50 +0000, Anthony Perkins wrote:

> A customer of ours is having a problem with their NIS server on a machine,
> where changes to the password can take up to a few hours to filter down to
> all the clients. We have tried to reproduce the problem elsewhere but are
> unable to. Is anyone able to suggest a reason or a solution to this
> problem? Any help is greatly appreciated. Thanks,

As well as Juha's suggestions, check if any of your clients are running
nscd. This interacts rather badly with NIS IME, certainly on Linux, and
can cause the effect you describe. It is especially likely to be the
problem if the various clients finally see the updates at different times.
If it is running, just stop and disable it. As long as your NIS servers
are reasonably close and responsive, it doesn't achieve a lot.
Alternatively, if you decide it is providing a benefit, review its
settings in /etc/nscd.conf.

SuSE is one distro which installs nscd by default. Not all do.

Regards, Ian