eric@picard.sbi.com (Eric Ho) (11/06/90)
Hi netlanders,
I'm writing several programs that involve YP -- actually, they interact with
the generic YP behavior. All these are done in the context of SunOS 4.1.
First of all, this is something I found strange :-
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
Assuming that you did 'cp -p /etc/passwd /var/yp/private/' beforehand.
And then you do a 'cd /var/yp ; make passwd DIR=/var/yp/private' just to
make sure that everything is updated.
2). Then, you go into /etc/passwd on the YP master and rename/delete a user
named, say, pooruser.
3). Then, do 'ypmatch pooruser passwd' and make sure that that user still
exists in the YP maps.
4). Then, if you telnet to a YP client, you can login as pooruser.
However, if you telnet to the YP master, you won't be able to login as
pooruser.
Now, can someone enlighten me as to why the YP master is not using the YP map
in this situation while the YP client is using the YP map perfectly ?
Now, the next question is a involves the above issue to some extent but I
question the relevance of using passwd(1) while one is on a YP master and that
the YP passwd map is based on the /etc/passwd file on the YP master.
Suppose, your YP master invokes rpc.yppasswdd *generically* - i.e.
rpc.yppasswdd /etc/passwd -m passwd
(from /etc/rc.local)
And that the YP passwd maps on the YP master are built from /etc/passwd.
I found that if one does passwd(1) on the YP master, one is basically inviting
trouble -- the reason is that the user (e.g. pooruser) exists in the YP
master's /etc/passwd file and passwd(1) will simply update this file *without*
updating the YP maps. So, after doing passwd(1), one cannot login to a YP
client with the new password and pooruser has to use the old password to get
into the YP clients. This situation will presist until another user
does a 'yppasswd' on a YP client or on the YP master -- at which time,
yppasswdd on the YP master will wake up and update *both* the YP passwd maps
and the /etc/passwd file on the YP master. So, our pooruser will be very
confused now -- s/he can login to a YP client using the old password at one
moment and then suddenly the old password is no longer valid and s/he has to
use the new password.
Of course, if one's YP passwd maps are *not* based on /etc/passwd but another
file on the YP master then this kind of confusion theoretically should not
happen but this drives us back to our very 1st issue -- namely, if only that
would work correctly.
Can anybody enlighten me on this ? (I tried calling Sun but obviously I
didn't get much out of them, as usual).eric@picard.sbi.com (Eric Ho) (11/27/90)
I'm writing several programs that involve YP -- actually, they interact
with the generic YP behavior. All these are done in the context of SunOS
4.1.
First of all, this is something I found strange :-
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
Assuming that you did 'cp -p /etc/passwd /var/yp/private/' beforehand.
And then you do a 'cd /var/yp ; make passwd DIR=/var/yp/private' just to
make sure that everything is updated.
2). Then, you go into /etc/passwd on the YP master and rename/delete a user
named, say, pooruser.
3). Then, do 'ypmatch pooruser passwd' and make sure that that user still
exists in the YP maps.
4). Then, if you telnet to a YP client, you can login as pooruser.
However, if you telnet to the YP master, you won't be able to login as
pooruser.
Now, can someone enlighten me as to why the YP master is not using the YP
map in this situation while the YP client is using the YP map perfectly ?
Now, the next question is a involves the above issue to some extent but I
question the relevance of using passwd(1) while one is on a YP master and
that the YP passwd map is based on the /etc/passwd file on the YP master.
Suppose, your YP master invokes rpc.yppasswdd *generically* - i.e.
rpc.yppasswdd /etc/passwd -m passwd
(from /etc/rc.local)
And that the YP passwd maps on the YP master are built from /etc/passwd.
I found that if one does passwd(1) on the YP master, one is basically
inviting trouble -- the reason is that the user (e.g. pooruser) exists in
the YP master's /etc/passwd file and passwd(1) will simply update this
file *without* updating the YP maps. So, after doing passwd(1), one
cannot login to a YP client with the new password and pooruser has to use
the old password to get into the YP clients. This situation will presist
until another user does a 'yppasswd' on a YP client or on the YP master --
at which time, yppasswdd on the YP master will wake up and update *both*
the YP passwd maps and the /etc/passwd file on the YP master. So, our
pooruser will be very confused now -- s/he can login to a YP client using
the old password at one moment and then suddenly the old password is no
longer valid and s/he has to use the new password.
Of course, if one's YP passwd maps are *not* based on /etc/passwd but
another file on the YP master then this kind of confusion theoretically
should not happen but this drives us back to our very 1st issue -- namely,
if only that would work correctly.
Can anybody enlighten me on this ? (I tried calling Sun but obviously I
didn't get much out of them, as usual).suskind@mdcbbs.com (Barry Suskind (E-Systems)) (11/28/90)
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.