Date: Thu, 11 Feb 1999 13:47:51 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: mi@aldan.algebra.com Cc: bugs@FreeBSD.ORG Subject: Re: bin/10031: ypxfr does not work with Solaris master server(s) Message-ID: <199902111847.NAA23584@skynet.ctr.columbia.edu> In-Reply-To: <199902111811.NAA18222@misha.cisco.com> from "Mikhail Teterin" at Feb 11, 99 01:11:37 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Mikhail Teterin
had to walk into mine and say:
> > > >Category: bin
> > > >Synopsis: ypxfr does not work with Solaris master server(s)
> >
> > No, ypxfr works fine with a Solaris master server. It's your NIS
> > master server (or what you believe to be the master server) that's the
> > problem.
>
> That's quite possible, actually. The reason I started to bother was
> because yp-related lookups are very slow and fail on occasion here.
Oh no you don't. You have other problems, file a new PR. None of this
"while I've got your ear stuff."
> > The fact that you put (slave?) in parentheses and with a question mark
> > gives me the impression that you aren't even really sure how NIS is
> > configured on your network. This could also be part of the problem.
>
> Absolutely!
>
> > > Both of them run Solaris.
>
> > _WHAT VERSION_ of Solaris.
>
> Good question. I do not have a login account there...
Arrrrghhh... Well find out. It will probably enlighten the both of us.
> > > ypxfr: couldn't create udp handle to ypserv: RPC: Program not registered
> > > ypxfr: source was: nis2 <-- my message on ypxfr_misc.c:229
> > > ypxfr: failed to get order number of passwd.byname from nis2:
> > > RPC failure talking to server <-- my modifiction of message
> > > on ypxfr_main.c:368
>
> > The error messages clearly indicate that host "nis2" is not running ypserv.
> > This is why I questioned your reasons for saying "(slave?)" before in
> > reference to nis2. It also clearly indicates the real problem, and it
> > has nothing to do with ypxfr.
>
> Perhaps. All I know, is that `ypwich' return nis1, but ypxfr -h nis1 talks
> to nis2. May be, it is nis1's fault for redirecting to non-functional nis2,
> I don't know.
Grrr! Read the ypwhich man page. If you want to make it tell you the
master server name for a given map, you have to use the -m flag. If you
just type 'ypwhich' without any arguments, it tells you the name of the
server that the client is currently bound to; this is _not_ _necessarily_
the master server!
> > You specified nis1 as the source host, but the maps say that the master
> > server is nis2. This can happen if:
>
> [...]
>
> > If you don't believe me, run 'yppoll passwd.byname' from the FreeBSD
>
> Well, not that I do not believe you, but yppoll does not work:
> # yppoll passwd
> yppoll: no such map passwd. Reason: YP server error
GRRRR!!! You did not follow my instructions! This is what I said:
If you don't believe me, run 'yppoll passwd.byname' from the FreeBSD
--------------------
Here's what you typed:
# yppoll passwd
-------------
Are these the same thing? No! Go back and do it again!
> Any chance of getting the initial databases from one of the funcitonal
> slaves?
The whole point of this excersize is that the slave servers obtain
map updates from the master. If the master is not running, or if the
maps are being built with the wrong master name in them, then the
master/slave update mechanism won't work. You're supposed to _fix_ this,
not invent new and exciting ways to ignore it! March immediately over
to your Solaris admin and either pump him for the appropriate information
of get him to fix nis2.
-Bill
--
=============================================================================
-Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu
Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research
Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
=============================================================================
"It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=============================================================================
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902111847.NAA23584>