Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: suskind@mdcbbs.com (Barry Suskind (E-Systems))
Newsgroups: comp.sys.sun
Subject: Re: YP problems/semantic questions...
Keywords: Miscellaneous
Message-ID: <470@brchh104.bnr.ca>
Date: 27 Nov 90 20:32:29 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 20
Approved: Sun-Spots@rice.edu
X-Original-Date: Mon, 12 Nov 90 05:56:52 PDT
X-Refs:  Original: v9n379
X-Sun-Spots-Digest: Volume 9, Issue 380, message 2
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

In article <ERIC.90Nov5180119@picard.sbi.com>, eric@picard.sbi.com (Eric Ho) writes:

> 1). Suppose you're on a YP master and you invoked rpc.yppasswdd as this from
>     rc.local :-
> 
> 	rpc.yppasswdd /var/yp/private/passwd -nogecos -m passwd \
> 	DIR=/var/yp/private
> 

I have to assume you have YPSERV and YPBIND running on the master & you
have the "+::0:0:::" at the bottom of your /etc/passwd file on the master.

> I found that if one does passwd(1) on the YP master, one is basically inviting
> trouble... user doing a "passwd" only updates the password in /etc/passwd
> and not the YP maps.

Yes, futhermore, in SunOS 4.1 you cannot do a "mv yppasswd passwd" to
prevent this from happening as your could in SunOS 4.0.3 because SUN has
merge the two programs and uses argv[0] when the program is invoked to
determine what to do.