Date: Thu, 11 Feb 1999 12:27:56 -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: <199902111727.MAA23424@skynet.ctr.columbia.edu> In-Reply-To: <199902111553.KAA17750@misha.cisco.com> from "Mikhail Teterin" at Feb 11, 99 10:53:23 am
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: > >Number: 10031 > >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. > > The master server nis1, apparently, redirects requests to another > (slave?) server nis2. No, the 'master' server is redirecting ypxfr to another server because of a problem with the maps. 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. > Both of them run Solaris. _WHAT VERSION_ of Solaris. > >Description: > > Local, FreeBSD-3.0-RELEASE machine tries to > > ypxfr -p /var/yp -h nis1 -c -d mydomain > > I put debug messages into ypxfr, which is why it is a bit more > verbose here: > > 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. > >How-To-Repeat: > > See the setup above Wrong. The information you provide is not sufficient to duplicate the problem you describe. You have made the assumption that the Solaris server machines are configured correctly. The Solaris machines are not configured correctly (or at the very least are not configured the way you think they are). > >Fix: > > I think, this has to do with ypxfr not failing over properly to > the SunOS compatable strategy, but I'm not sure... I wish, there > was a switch to not even try the FreeBSD-specific algorithm... No, this has nothing at all to do with the FreeBSD-specific ypxfr protocol; if you look at the code closer, you'd see that the error happens before you even reach the part of the program that probes for the FreeBSD rpc.ypxfrd. The NIS maps contain the name of the NIS master host embedded within them: this information is placed in a special record with a key of YP_MASTER_NAME by the makedbm utility, and ypserv makes this information available via the YPPROC_MASTER procedure. The ypxfr program learns the name of the NIS master server either by reading the YP_MASTER_NAME record embedded in the local copies of the maps, or by calling the YPPROC_MASTER procedure on the specified source host (specified with -h). You specified nis1 as the source host, but the maps say that the master server is nis2. This can happen if: - The host "nis2" was the original NIS master server, and somebody tried to make "nis1" the new NIS master server by copying the map database files from nis2 to nis1. The map databases created on nis2 will still have nis2's hostname embedded in them, hence nis1 will tell anyone that asks that nis2 is still the master server. - The host identified as nis1 via DNS actually thinks that its hostname is nis2, and so the makedbm program is encoding the YP_MASTER_NAME records incorrectly (probably based on the output of /bin/hostname). - The host nis1 really isn't the master server. It could be that nis2 is actually the master and nis1 is a slave, but ypserv on nis2 has crashed and nobody has bothered to fix it yet. You mistook nis1 for the master, and when nis1 rightly tries to redirect ypxfr to nis2, ypxfr bombs because nis2 isn't running ypserv (maybe the ypserv processes encounted some runtime error and crashed; maybe somebody rebooted nis2 and didn't set things up correctly so that ypserv would be automatically restarted; maybe the DNS entry for nis2 is pointing a the wrong machine). If you don't believe me, run 'yppoll passwd.byname' from the FreeBSD host (assuming it's set up as a client as well as a server) and observe the results: it should say that the master server is nis1, and it should show you the last time the passwd.byname map was updated. Unless somebody corrects the error before you get a chance to do this, yppoll will actually show that nis2 is the master server, which wrong since nis2 is obviously not running ypserv (if it had been, you would not have gotten the 'RPC program not registered' error). -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?199902111727.MAA23424>