brad@lsr-vax.UUCP (Brad J Zoltick) (05/12/91)
Has anyone had difficulty getting a SGI yp client to work with a Sun yp master when a router is involved on the subnet? We have no problems with Sun yp clients working in the same subnet. However, I can not get ypbind running on a SGI machine to connect to a ypserver on the subnet when a router is involved. Any suggestions? After countless hours wasted, I have tried everything I can think of. Somehow, I suspect it is the router as on another, isolated network of SGI and Suns, I have had no difficulty with Iris yp clients running with Sun ypservers. Brad Zoltick National Institutes of Health E-mail: UUCP: ...uunet!lsr-vax!brad INTERNET: lsr-vax!brad@uunet.uu.net or brad%lsr-vax.UUCP@uunet.uu.net
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (05/13/91)
In article <9105120711.AA01176@>, brad@lsr-vax.UUCP (Brad J Zoltick) writes: > > Has anyone had difficulty getting a SGI yp client > to work with a Sun yp master when a router is involved > on the subnet? > > We have no problems with Sun yp clients working in the > same subnet. However, I can not get ypbind running on a SGI > machine to connect to a ypserver on the subnet when a router > is involved. If the router is between the client and the server, then you don't have much hope, at least until the next release. This is because NIS (gotta keep those lawyers and PTT's happy) uses UDP/IP broadcasts for ypbind on the client to find servers. Broadcasts are not forwarded by routers. You can often get things working for a while by explicitly pointing the client to the server with the `ypset` command. (You'll need to use an IP number or some other non-NIS way to resolve the server hostname.) Unfortunately, if the NIS server router, network, or whatever hiccups, your ypbind will become unbound and your machine will be unhappy. I've proposed more than once using IGMP multicast for discovering YP servers. If routers were routing IGMP (IRIS's do now, and dedicated routers will as well with the advent of OSPF), then multicast would be a near perfect solution. Unfortunately, no other company seems to care, and especially not the main company that would have to be convinced. The next SGI release may have a mechanism for telling ypserv to bind to a pre-specified ypserv and to never unbind. Until then, your best bet might be to make the isolated client into a slave-server. Vernon Schryver, vjs@sgi.com
sgf@cfm.brown.edu (Sam Fulcomer) (05/13/91)
In article <103360@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >In article <9105120711.AA01176@>, brad@lsr-vax.UUCP (Brad J Zoltick) writes: >> >> Has anyone had difficulty getting a SGI yp client >> to work with a Sun yp master when a router is involved >> on the subnet? > >If the router is between the client and the server, then you don't have much >hope, at least until the next release. This is because NIS (gotta keep >those lawyers and PTT's happy) uses UDP/IP broadcasts for ypbind on Eh?, I haven't found this to be a problem. Let's assume subnets "a.b.c" and "1.2.3" and say a machine on "a.b.c" wants to ypbind through a router to a server on "1.2.3". All the client needs to do is change its broadcast address to "1.2.3.255" (assuming the server's using 255) before the ypbind. Since all our remote NIS clients don't have much association with other machines on their subnet I just leave the b-cast set to our local subnet. That avoids the complication of the client losing a binding and hanging if one of the intervening routers goes down. -- _/**/Sam_Fulcomer sgf@cfm.brown.edu What, me panic: uba crazy Associate Director for Computing Facilities and Scientific Visualization Brown University Center for Fluid Mechanics, Turbulence and Computation