khui@brahms.amd.com (Kelvin Hui) (12/05/90)
I have two SUN SPARC 1+ workstation, one set up as master and the other as
client in NIS. When I change passwd (using yppasswd or passwd), the
/etc/passwd file on the master machine is updated. The password on the master
machine is changed accordingly but the client machine still uses the old
password. Reboot either machine doesn't change the situation. In fact
I have no way to change the passwd on the client.
--
_______________________________________________________________________
Kelvin Y. Hui |
khui@brahms.amd.com | I'm doing nothing, I'm doing research.
_____________________________|_________________________________________thurlow@convex.com (Robert Thurlow) (12/05/90)
In <1990Dec4.182751.10341@amd.com> khui@brahms.amd.com (Kelvin Hui) writes: >I have two SUN SPARC 1+ workstation, one set up as master and the other as >client in NIS. When I change passwd (using yppasswd or passwd), the >/etc/passwd file on the master machine is updated. The password on the master >machine is changed accordingly but the client machine still uses the old >password. Reboot either machine doesn't change the situation. In fact >I have no way to change the passwd on the client. Is the client actually seeing anything in the master NIS maps, or is it just referencing the local password file? Remember that you have to change your password file before the getpwent() routines will look at the NIS map information. A "+:" in /etc/passwd tells these routines to pull in NIS entries. Another idea: are you sure you don't have another machine set up as a slave? The way to test is to clear the domainname on the master server and kill or suspend the ypserv process, and then try ypwhich on the client to see where it's getting its maps. If you have another machine serving the maps, and if you haven't a mechanism to update those maps, your client may never see the new information. Rob T -- Rob Thurlow, thurlow@convex.com or thurlow%convex.com@uxc.cso.uiuc.edu ---------------------------------------------------------------------- "This opinion was the only one available; I got here kind of late."
shawn@litsun8.litsun.epfl.edu (Shawn Koppenhoefer) (12/06/90)
>client in NIS. When I change passwd (using yppasswd or passwd), the >/etc/passwd file on the master machine is updated. The password on the master >machine is changed accordingly but the client machine still uses the old I've just spent the last hour chasing this problem. <sigh> I should be sleeping at this hour!!! grrrr. >password. Reboot either machine doesn't change the situation. In fact >I have no way to change the passwd on the client. I tried rebooting the client *and* the server (server first). this seemed to sort of solve the problem in that the current values in the server passwd file were now the same on the client. But still, changing the password on either client or server didn't update on the client.... so. what I do *now* is to rlogin into the master and do passwd. Then I goto /var/yp and do a make. This works, but I can't believe this is necessary! Robert> Is the client actually seeing anything in the master NIS maps, or is it Robert> just referencing the local password file? Remember that you have to Robert> change your password file before the getpwent() routines will look at Robert> the NIS map information. A "+:" in /etc/passwd tells these routines to Robert> pull in NIS entries. my client is a diskless but the /etc/passwd *is* on it's mounted partition and there is a `+` in the 2nd line (no quotes). -- ___________________________________________________________________________ | shawn@litsun.epfl.ch -.- KLEIN BOTTLE FOR SALE ... \####### | Shawn Edwin Koppenhoefer \_/ ... enquire within \###### | LIT-EPFL (Ecole Polytechnique Federal De Lausanne)_________________\#####
hamish@waikato.ac.nz (12/06/90)
In article <1990Dec4.182751.10341@amd.com>, khui@brahms.amd.com (Kelvin Hui) writes: > I have two SUN SPARC 1+ workstation, one set up as master and the other as > client in NIS. When I change passwd (using yppasswd or passwd), the > /etc/passwd file on the master machine is updated. The password on the master > machine is changed accordingly but the client machine still uses the old > password. Reboot either machine doesn't change the situation. In fact > I have no way to change the passwd on the client. > I had a similar problem on our SS1's, running 4.0.3 and now 4.1, up until about 1/2 an hour ago. The /etc/passwd would get changed, nut the maps wouldn't be updated, necessitating a manual make from /var/yp by the root. I fixed it by moving the NIS password entirs into another file (/var/yp/passwd) and altering the Makefile in /var/yp to get its entries from /var/yp/passwd. Now with /usr/etc/rpc.yppasswdd /var/yp/passwd -m passwd in the rc.local script, everything works as its supposed to. Does anyone know why the problems with /etc/passwd being propogated automagically? The manuals all say it should work the original way. > -- > _______________________________________________________________________ > Kelvin Y. Hui | > khui@brahms.amd.com | I'm doing nothing, I'm doing research. > _____________________________|_________________________________________ -- ============================================================================== | Hamish Marson <hamish@waikato.ac.nz> | | Computer Support Person, Computer Science Department | | University of Waikato | |Disclaimer: Anything said in this message is the personal opinion of the | | finger hitting the keyboard & doesn't represent my employers | | opinion in any way. (ie we probably don't agree) | ==============================================================================
jjb@cs.wayne.edu (Jon J. Brewster) (12/06/90)
In article <1990Dec4.182751.10341@amd.com> khui@brahms.amd.com (Kelvin Hui) writes: >I have two SUN SPARC 1+ workstation, one set up as master and the other as >client in NIS. When I change passwd (using yppasswd or passwd), the >/etc/passwd file on the master machine is updated. The password on the master >machine is changed accordingly but the client machine still uses the old >password. Reboot either machine doesn't change the situation. In fact >I have no way to change the passwd on the client. > There is a bug which seems to be less than 100% reproducible... it has to do with the number of arguments with which one starts rpc.yppasswdd. There is a simple workaround, stick another argument in the invocation, so: rpc.yppasswdd /etc/passwd -nosingle -m passwd ^^^^^^^^^ I'm not sure this needs to be done in all cases, but when I recently moved our NIS master from a 3/180 to a SparcServer-1, it completely broke yppasswd until I put "-nosingle" in. The symptom is that doing a yppasswd will seem to work, but only the source file (/etc/passwd in our case) gets changed. The NIS maps are unchanged. -- -jjb
jjb@cs.wayne.edu (Jon J. Brewster) (12/07/90)
I apparently committed the tabs-instead-of-spaces sin in my previous article. The string of '^'s belong under the option "-nosingle". Sorry. -- -jjb
rob@wdl50.wdl.fac.com (Rob Riepel) (12/07/90)
>>client in NIS. When I change passwd (using yppasswd or passwd), the >>/etc/passwd file on the master machine is updated. The password on the master >>machine is changed accordingly but the client machine still uses the old >>password. Reboot either machine doesn't change the situation. In fact >>I have no way to change the passwd on the client. I have the gospel on this one...(i hope) I'm currently taking the SunOS system admin class and we were told that there is a bug in rpc.yppasswdd that prevents it from doing the automatic update of the passwd map. There is a simple fix, add "-noshell" in the rpc.yppasswdd startup in rc.local on the NIS master server. This should get the NIS map updated, and pass the update along to any slave servers. The placement of the "-noshell" option is critical, it should be included just before the "-m" option. ..rob (rob@ssd1.ssd.loral.com)
primer@math.harvard.edu (Jeremy Primer) (12/10/90)
In article <1990Dec7.022705.8901@wdl1.wdl.loral.com> rob@wdl50.wdl.fac.com (Rob Riepel) writes: >I'm currently taking the SunOS system admin class and we were told that there >is a bug in rpc.yppasswdd that prevents it from doing the automatic update of >the passwd map. I don't know whether Sun has volunteered the explanation for this bug, so for the record, here is what I observed while trying to get yppasswdd to work. Our rc.local line prior to SunOS 4.1 was 'rpc.yypasswdd /etc/passwd -m'. I figured the problem might be something amiss in the make in /var/yp. I observed that /var/yp/Makefile builds target "k" instead of target "all" by default, and that target "k" simply reruns make with the -k option, telling make to attempt successive targets even if some fail. Thus inspired, I tried yppasswdd as: rpc.yypasswdd /etc/passwd -m -k passwd and it worked. The question remained: what were the errors which -k convinced make to ignore? yppasswdd had to be invoking make incorrectly. So I changed my NIS password and then immediately ran 'ps ax | grep passwd' in another window and saw: 64 ? S 0:00 rpc.yppasswdd /etc/passwd -m -k passwd 28027 ? S 0:00 rpc.yppasswdd /etc/passwd -m -k passwd 28028 ? S 0:00 sh -c make rpc.yppasswdd /etc/passwd -m -k passwd 28029 ? S 0:00 make rpc.yppasswdd /etc/passwd -m -k passwd 28043 pd S 0:00 grep passwd The -k option convinces make to work even though it has been passed some inappropriate arguments. It seems that there are other workarounds which cause rpc.yppasswdd to invoke make properly. -- Jeremy Primer, Department of Mathematics, 1 Oxford Street, Cambridge MA 02138 primer@math.harvard.edu ...!harvard!zariski!primer primer@huma1.bitnet