[comp.sys.sun] Bad YP handling

schriste@uceng.uc.edu (Steven V. Christensen) (12/02/89)

I think I may have sent this request out imbedded in another problem, but
here it is specifically.

Machine A: Sun 3/60, SunOS 4.0 (I know...), YP server
Machine B: Microvax II, Ultrix-32 V3.0 (Rev 64), YP client

Situation: When I run "make all" in /var/yp on the Sun to re-make and
redistribute the YP databases, it says (for example):

updated passwd

yp server not registered at <Machine B>.

yp server not registered at <Machine B>.
pushed passwd

... and so on for the other databases.  I verified that the YP service is
correctly running on the MicroVAX, and in fact I can log in on the VAX,
showing that it correctly uses the YP databases.  The files _do_ correctly
end up on the VAX, though when I don't know.

Could I have a problem in one of the /etc files?

Thanks for help in advance,
	Steven

Steven V. Christensen
U.C. College of Eng.
schriste@uceng.uc.edu

nao@cuatro.bellcore.com (Neil Ostroff) (12/12/89)

In article <3495@brazos.Rice.edu> Steven V. Christensen writes:

>Situation: When I run "make all" in /var/yp on the Sun to re-make and
>redistribute the YP databases, it says (for example):
>
>updated passwd
>
>yp server not registered at <Machine B>.
>
>yp server not registered at <Machine B>.
>pushed passwd

This occurs when <Machine B>'s ypserv(8) is not running.  Most likely, you
either have a yp configuration problem on the Sun or <Machine B> is not
set up to be a slave server.  To figure out what's going on, you need to
know whether <Machine B> is supposed to be a yp slave server or just a yp
client (the Sun is the yp master server).  Now verify your Sun yp
configuration by cd-ing to /var/yp/your_domain and typing:
"/usr/etc/yp/makedbm -u ypservers".  If it returns the name of <Machine
B>, then your Sun wants <Machine B> to be a yp slave server.
Unconfiguring your Sun is somewhat of a pain, however the procedure is
described in Chapter 14 of the System and Network Administration manual.
If you want <Machine B> to be a slave server, then it needs to be set up.

Neil Ostroff
Bell Communications Research  |  UUCP:  bcr!nao
100 Schultz Dr.  NVC-5J443    |  ARPA:  nao@cuatro.bellcore.com
Red Bank, NJ  07701           |  PHONE: (201) 758-5741