From: jzwiebel@pgl-devsvr.den.mmc.com (John Zwiebel 303-977-1480)
Subject: Re: NIS across gateways
Organization: PAGE @ Martin-Marietta
Date: Sat, 5 Sep 1992 02:18:55 GMT

In article <1992Aug27.155241.7020@awdprime.austin.ibm.com>, curt@ekhadafi.austin.ibm.com (Curt Finch 903 2F021 curt@aixwiz.austin.ibm.com 512-838-2806) writes:
|> I have a customer who sent me the following question:
|> 
|> >Within in an "area" there may or may not be routers.  We are thinking of
|> >proposing the following idea regarding NIS:
|> 
|> >Within an area, there is one NIS master.  All other servers are
|> >designated as slaves.  This will get around the router problem.
|> >However, we noted that slaves could not get new copies of the maps
|> >unless they were bound to the master.  Ideally, we would like to
|> >have each slave bound to itself.  This way if a server goes down,
|> >we know that users on the surviving servers do not have to wait
|> >until their server is rebound.  We are unsure of deciding how to
|> >best design around these binding issues.
|> 
|> NIS can't bind through a gateway generally since broadcasting doesn't
|> work.  What sort of strategy might work for this, here are two I thought
|> of:
|> 
|> 1.  Leave the slave bound to itself.  You might try having the master
|>     rsh to the slave and run a shell script which does the following
|>     whenever it's time to yppush:
|>         ypset master
|>         get all the maps
|>         ypset slave
|> 
|> 2.  Or you could try leaving the slave always bound to the master but
|>     running a cron job which tries to figure out when the master dies
|>     and at that time rebinds to the slave until the master comes back
|>     using ypset.
|> 
|> Can anyone tell me these ideas are wrong, or think of some others?
|> -- 
|> curt@aixwiz.austin.ibm.com (Curt L. Finch) | AIX NFS/NIS Field Quality 
|> My views are unrelated to those of IBM     |        Austin, TX
|>   Social Security isn't a retirement plan.  It's middle class welfare.


I'm just asking more questions:

I was under the impression that it takes about 5 minutes for ypbind to figure out that it isn't getting service from ypserv.  Is it not true that during this time the ypbind clients should continue to get service from the slave server even if the slave cant contact the master?  Even if this is not so, I think the delay will only mean that someone who has not logged on to a client host will have to wait until the rebinding occurs, all the other clients should be able to continue operating (for the most part






) as if nothing happened right?

We have cisco routers also and the ip helper-address works very well.  I don't see a lot of extra broadcast packets running around my networks.  The 9.1 OS (and probably 9.0) can be set up to forward broadcasts via the bridge spanning tree (which avoids loops).  Even if your network isn't bridging you can still use the spanning tree to manage the broadcasts.  So when all this is taken into account, the clients can have their choice of slaves and masters.  The server that provides the best service wins.

I'm also wondering about the cron suggestion.  If ypbind looks for a new ypserv within 5 minutes how often will you have to be running the cron job?

Xref: sparky comp.protocols.nfs:2290 comp.protocols.tcp-ip.ibmpc:5165 comp.dcom.lans.ethernet:1875