Date: Thu, 5 Jun 1997 16:10:04 -0700 (PDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: freebsd-bugs Subject: Re: bin/3778: ypbind -S domainname,server1,... does not function Message-ID: <199706052310.QAA12470@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/3778; it has been noted by GNATS. From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: jin@george.lbl.gov (Jin Guojun[ITG]) Cc: freebsd-gnats-submit@freebsd.org Subject: Re: bin/3778: ypbind -S domainname,server1,... does not function Date: Thu, 5 Jun 1997 18:45:22 -0400 (EDT) Of all the gin joints in all the towns in all the world, Jin Guojun[ITG] had to walk into mine and say: > > > There are two things you can do: > > > > 1) Compile a static ypbind binary on a 2.2.x or better machine and use > > that on your 2.1.7.1 machine. > > This one does not work. Here is the errors: > > # ypbind -m -S itg,george,pesto > # Jun 5 10:36:00 fudd portmap[203]: connect from 128.3.3.93 to > unset(ypbind): request from unprivileged port > > Adding -s option has the same result. Hm... I'm not sure why this is... Oh wait, I think I know. The bindresvport code in the RPC library changed. Crap. I should have thought of that the other night. Sorry. > > 2) Since I develop this stuff on my home machine which still runs 2.1.0, > > I have compiled versions of the newer YP tools that will run on 2.1.x. > > You can FTP a copy of a ypbind executable from my home machine if you > > can't find a 2.2.x or better machine on which to build your own. > > The binary is at: ftp://skynet.ctr.columbia.edu/pub/freebsd/nis/ypbind > > I have a very slow link, but the binary is only about 30K. > > This one works, but seems only binding to FreeBSD server. > George is a Sun and pesto is a FreeBSD machine. > > # ypbind -m -s -S itg,george,pesto > # ypwhich > pesto.lbl.gov > # ps uxgw > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > root 217 0.0 0.8 628 252 p0 R+ 10:39AM 0:00.00 ps -uxgw > root 1 0.0 0.6 416 164 ?? Ss 10:00AM 0:00.02 /sbin/init -- > root 2 0.0 0.1 0 12 ?? DL 10:00AM 0:00.00 (pagedaemon) > root 3 0.0 0.1 0 12 ?? DL 10:00AM 0:00.00 (vmdaemon) > root 4 0.0 0.1 0 12 ?? DL 10:00AM 0:00.10 (update) > ... > root 193 0.0 1.1 480 328 p0 Ss 10:35AM 0:00.12 -sh (csh) > root 214 0.0 1.0 212 304 ?? Ss 10:39AM 0:00.01 ypbind -m -s -S itg > root 0 0.0 0.0 0 0 ?? DLs - 0:00.00 (swapper) > # kill -9 214 > # ypbind -m -s -S itg,pesto,george > # ypwhich > pesto.lbl.gov > > Any ideas? I think this is 'expected behavior.' From nslookup: Client ------ Name: iss-p1.lbl.gov Address: 131.243.2.47 Master server ------------- Name: george.lbl.gov Address: 128.3.196.93 Slave server ------------ Name: pesto.lbl.gov Address: 131.243.2.55 Pesto and iss-p1 are on the same subnet. The idea behind both the broadcast and the many-cast ping routines is that whichever server answers first is declared the winner, and that's the one ypbind binds to. The order in which you specify the servers when you use the -S isn't supposed to matter. The master server, george, is on a different network, and probably a hop or two away, so it is unlikely that it will get its response back to the client before pesto does. (That said, the many-cast code does transmit all of the pings in order (using a for() loop). So if george appears first in the list, then ypbind will transmit a packet to george first, and then pesto, and then any others. However, it transmits all the pings first and then listens for an answer. The fact that george's packet went out first makes no difference here because it takes longer for the packet to reach george and for george to reply than it does for pesto's packet to reach pesto and for pesto to reply. I hope this makes sense.) If it happens that pesto crashes or becomes unreachable, then ypbind should indeed bind to george since it's the only other server listed. To verify that it will actually bind to george, invoke ypbind like this: # ypbind -m -S itg,george If this works (and I think it should) then ypbind is actually behaving correctly; it can bind to the Solaris host, it just chooses not to because pesto answers faster. You can also use tcpdump to monitor the client's interface and see that a packet is in fact transmitted to george and that george does actually answer. I'm sorry if you don't like the fact that it favors the local server, but that was the idea behind the algorithm. :) -Bill PS: If you want, I can put together a quick source distribution for you so you can compile this newer version of ypbind yourself on your 2.1.x machines. I don't like giving away binary-only distributions, but I wanted to make sure this would work before I went any further. -- ============================================================================= -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?199706052310.QAA12470>