Delay in user password change using NIS

[Mike King_7]

Sceneiro:
We have a NIS master and clients.
A new user signs on to a client and is required to change his password per the way we set up the account.
The system asks for his old NIS password and then a new password and confirmation.
The system then asks the user to login again and here is where the trouble occurs--- If the user does this right away, the system will not accept the new password but expects the old one. The new password never takes effect and the user is not forced to change his password till the expiration period we have set up. However, if the user waits about 5 minnutes and then re-logins in, the new password is in effect. I tested the time delay thing quite a bit and it seems to be about 5 minnutes.

We have a fairly large (about 1000 users) passwd file on the NIS master.
I assume this delay is the time it is taking the NIS master to process the yppasswd data issuef from the client.

Having to wait 5 min to relog in after someone changes their password is not a good thing. Is there some way to reduce (or practically eliminate) this lag time

[A. Clay Stephenson]

It looks like you need to add the -m flag to the ypasswdd daemon. That will push the changes out instantly. Man yppasswdd for details.

[Mike King_7]

It looks to me like the -m is specified. Looking in /etc/rc.config.d/namesvrs the line YPPASSWDD_OPTIONS is set to "/etc/passwd -m passwd PWFILE=/etc/passwd"

[Shannon Petry]

I dont think it's a -m option, as much as it is a ypxfr issue, or yppasswd issue.

First, ensure that all systems are on the same subnet mask. This will cause delays in broadcasts being read.
Next, are is the problem more/less/same on clients connected to the NIS Slaves as opposed to the NIS master? Usually this means that a netmask/broadcast address is different between the 2.

Next, is your network overloaded? Check capacity. Also, in a windows network, I have seen the broadcast saturated. Put unix on it's own subnet to clear broadcast crap. WIndblows will holler everything not answered on the local net, to every broadcast address in range even if netmask excludes it. This will cause problems simply because of the amount of broadcasts any WIndblows box makes.

Regards,
Shannon

[Mike King_7]

I see no indication of any network overload or broadcast issues when looking at network statistics. We have no slave, only a master and clients. All is on the same subnet mask. I don't think its a network or server saturation problem as also there are no other signs of slowness.

[A. Clay Stephenson]

I suppose now we need top nail down whether the problem is related to propagation delays or to the yppasswdd itself.

On the NIS master, using the passwd command, change a passwd but do not run ypmake. To make certain that you are working as expected, try to login on a client as this user. The login should fail with the new passwd but work with the old one. Now on the master server, cd /var/yp, and make. The passwd map should be rebuilt and pushed. Immediately, repeat your test on the client. If that works then network or propagation delays are not your problem.

One thing that can kill yppasswdd is the existance of the lockfile /var/adm/ptmp. I would also change your YPPASSWDD_OPTIONS to
"/etc/passwd -l /var/adm/ypasswd.log -m passwd PWFILE=/etc/passwd". The logging may help you to spot any booboo's.

[A. Clay Stephenson]

Hi Mike:

One last thought: Look in /var/yp/Makefile and make sure that NOPUSH is not set to 1.

[Mike King_7]

I tried the test you mentioned. It worked as you described: Changing the password on the master still needed the old password on the client. However, immediately after running the make on the master, the client wanted/took the new password. Hence, as you suspect, propigation/network delays do not appear to be the problem.

Also, the lock file you mentioned does not exist and YPPUSH is not set to anything.

I also have enabled logging as you suggested but so far have seen no clues there.

[A. Clay Stephenson]

NOTE: I said NOPUSH rather than YPPUSH in /var/yp/Makefile. Check to see if you have a file /var/yp/passwd on the master server; if so, remove it (or at least rename it).

Last point, have you looked for NIS patches?

1,000 NIS users should not be a problem at all. My yppasswd changes propagate within seconds.

[S.K. Chan]

I agree with Clay's point on the patches. Though I've never experience such symptom before ( we got over 2000 entries in the password file ), you might want to install the latest NFS/NIS General Release/ Performance patch. When I roll out NIS to one of our site, I make sure all nodes had the latest networking related patches. So far I've not seen any major problem except for some minor file locking issue ( due to nis distributed automounter map ).

[Mike King_7]

Sorry, I ment NOPUSH, I just mistyped myself. I will look into the NIS patches. Also,
I need to watch and see for a day or so, but since I added the logging option to yppasswdd, I have not had any delay problems!! Perhaps yppasswdd was just 'confused' and killing and restarting it (with log option now) was all it needed.