home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / protocol / nfs / 2184 < prev    next >
Encoding:
Text File  |  1992-08-29  |  2.2 KB  |  55 lines
  1. Newsgroups: comp.protocols.nfs
  2. Path: sparky!uunet!munnari.oz.au!mips!mips!sgi!rhyolite!vjs
  3. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  4. Subject: Re: NIS across gateways
  5. Message-ID: <p6ete90@rhyolite.wpd.sgi.com>
  6. Organization: Silicon Graphics, Inc.  Mountain View, CA
  7. References: <1992Aug27.155241.7020@awdprime.austin.ibm.com>
  8. Date: Sat, 29 Aug 1992 17:16:12 GMT
  9. Lines: 44
  10.  
  11. 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:
  12. > I have a customer who sent me the following question:
  13. > 
  14. > >Within in an "area" there may or may not be routers.  We are thinking of
  15. > >proposing the following idea regarding NIS:
  16. > 
  17. > >Within an area, there is one NIS master.  All other servers are
  18. > >designated as slaves.  This will get around the router problem.
  19. > >However, we noted that slaves could not get new copies of the maps
  20. > >unless they were bound to the master.  Ideally, we would like to
  21. > >have each slave bound to itself.  This way if a server goes down,
  22. > >we know that users on the surviving servers do not have to wait
  23. > >until their server is rebound.  We are unsure of deciding how to
  24. > >best design around these binding issues.
  25. > 
  26. > NIS can't bind through a gateway generally since broadcasting doesn't
  27. > work.  What sort of strategy might work for this, here are two I thought
  28. > of:
  29. > 
  30. > 1.  Leave the slave bound to itself.  You might try having the master
  31. >     rsh to the slave and run a shell script which does the following
  32. >     whenever it's time to yppush:
  33. >         ypset master
  34. >         get all the maps
  35. >         ypset slave
  36. > 
  37. > 2.  Or you could try leaving the slave always bound to the master but
  38. >     running a cron job which tries to figure out when the master dies
  39. >     and at that time rebinds to the slave until the master comes back
  40. >     using ypset.
  41. > 
  42. > Can anyone tell me these ideas are wrong, or think of some others?
  43.  
  44.  
  45. How about using multicast and IGMP?
  46.  
  47. If your router does multicast, and you can change your portmapper
  48. and client libraries to try multicast, then it works fine.
  49.  
  50. I think there is an officially registered class-D address for this purpose.
  51. I think it is 224.0.2.2.
  52.  
  53.  
  54. Vernon Schryver,  vjs@sgi.com
  55.