Date: Sat, 23 Aug 1997 21:06:31 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: roberte@MEP.Ruhr-Uni-Bochum.de (Robert Eckardt) Cc: ejc@bazzle.com, hackers@freebsd.org Subject: Re: NIS-master/slave w/ 2.1.7+2.2.2 Message-ID: <199708240106.VAA00297@skynet.ctr.columbia.edu> In-Reply-To: <199708232355.BAA02073@ghost.mep.ruhr-uni-bochum.de> from "Robert Eckardt" at Aug 24, 97 01:55:27 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, Robert Eckardt had to walk into mine and say: > > It was Eric J. Chet who wrote: > > > > On Sat, 23 Aug 1997, Robert Eckardt wrote: > [..] > > > The problem is simply that I want to use a 2.2.2 box as a NIS slave server > > > with a 2.1.7 box as a NIS master. > > > > > > However, when pushing from the master with > > > % yppush -d XYZ amd.home > > > yppush: Transfer request refused by ypserv > > > > > > On the slave side I get messages like: > > > ypserv[24772]: couldn't find master for map amd.home@XYZ > > > ypserv[24772]: host at ZYX (134.147.xxx.yyy) may be pulling my leg > [..] > > Hello > > The only way I could get the first transfer was manually using > > ypxfr. Start rpc.ypxfrd, and then use ypxfr. After that everything > > worked normally with the slave updates. > > Thanks ! That was it. > I just had to call on the slave machine `ypxfr <mapname>' for all maps. > Now yppush works again. For the record, the reason you get the error is that ypserv on the 2.2.2 slave is trying to learn the hostname of the master server from the local copy of the map database file, as opposed to trusting the 'peername' supplied with the ypproc_xfr request. This is a security feature: you don't want to blindly trust the hostname supplied by the caller since the caller may not be a trusted server (you can try to reduce the risk of bogus requests being processed using the securenets feature, but that may not help in the face of IP spoofing). When you first set up an NIS slave, it doesn't have any copies of the maps yet, so the attempt to learn the name of the master fails and you get an error. Same thing happens if you have an already running slave server and you add a new map on the master: you have to go to each slave and ypxfr an intial copy over before future yppush attempts will work. This change was made to the 2.2.x and current branches a while ago. I also patched ypserv in the 2.1.x branch even though there won't be another 2.1.x release. Note that many (most?) ypserv implementations handle the signalling of the error back to yppush incorrectly. The signalling itself is a bit strange because of how map transfers work: when ypserv on a slave receives a request to do a map transfer, it fork()s and exec()s an instance of ypxfr to do the actual transfer rather than doing it itself. This means that ypxfr is the one that has to send the success or failure code back to yppush. It's not possible for ypxfr to inherit the RPC server transport handle from ypserv, so instead ypserv passes arguments to ypxfr that tell it how to 'call back' to the waiting yppush process and let it know what happened. The problem comes when ypserv fails to run ypxfr. In this case, ypserv realizes that it doesn't have an existing local copy of the map in the xfr request, so it doesn't bother launching ypxfr. The SunOS ypserv does the same thing. But since ypxfr is never launched, no error status is ever sent back to yppush, so it ends up just sitting there until the transfer times out. (With the FreeBSD yppush, the timeout is 5 minutes.) The FreeBSD ypserv gets this right: I added code to ypserv to allow it to 'call back' to yppush itself in the event that it can't get ypxfr off the ground. In this case, the error was YPXFR_REFUSED. Yppush gets the message immediately, prints the appropriate error and moves on. What I'm getting at is that if you use a FreeBSD master with a non-FreeBSD slave server, you may get these long delays on the master when trying to yppush a map that the slave doesn't have yet, and this is the reason why. If the 5 minute timeout is too long, you can recompile yppush to use something less (look for YPPUSH_RESPONSE_TIMEOUT in src/usr.sbin/yppush/yppush_extern.h). Oh, lastly: be aware that rpc.ypxfrd should only be run on the NIS master host. Running on the slave won't hurt, but it won't gain you anything either. Also be aware that 2.1.x doesn't support rpc.ypxfrd, so it will always use the 'old' transfer method. -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" =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708240106.VAA00297>