The problem turned out to be self-inflicted. I didn't mention it in
sufficient detail in my post, but this system was set up as a master in
its own domain where there are *no* other slave servers or clients. A
lot of people suggested that my server wasn't pushing maps out to the
other systems and that's why I wasn't seeing the changes, which I
figured was not the case. Well, that was actually part of the problem
even though I had no other servers. Because I only started NIS in order
to get DNS easily I set the NOPUSH flag in the /var/yp/Makefile
thinking that pushing maps wasn't an issue. This was a mistake. Once I
unset the NOPUSH flag everything worked fine.
/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/
Jim Napier jnapier@soe.ucsd.edu
Systems Administration (619)534-5212
School of Engineering
UC San Diego
/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/
My original post:
>System: Sparc 10
>OS: 4.1.3U1
>
>When a person uses yppasswd to change passwords it does not take effect
>even though everything appears to work. No errors are returned. The
>command works as expected and afterwards I can see that the
>passwd.byuid and passwd.byname maps have been updated. Once the
>password has changed, if I do a "ypcat passwd", I see the new encrypted
>password in the entry for that user. But if I do a "ypmatch user
>passwd" I see the old password. It's as though despite the change to
>the password maps that the old password is cached somewhere. If the
>user logs out and back in they will have to use the old password. I've
>checked SunSolve for any patches related to yppasswd, but the only ones
>I've found don't seem to apply to this problem. I'm running the
>identical NIS model on other systems without this failure.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:52 CDT