home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / sun / admin / 5602 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  2.5 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!unixhub!argus.SLAC.Stanford.EDU!kls
  2. From: kls@argus.SLAC.Stanford.EDU (Karl L. Swartz)
  3. Newsgroups: comp.sys.sun.admin
  4. Subject: problems multihomed YP master
  5. Message-ID: <5135@unixhub.SLAC.Stanford.EDU>
  6. Date: 18 Aug 92 04:44:22 GMT
  7. Sender: news@unixhub.SLAC.Stanford.EDU
  8. Organization: Stanford Linear Accelerator Center
  9. Lines: 56
  10. Nntp-Posting-Host: argus.slac.stanford.edu
  11.  
  12. We recently added several extra interfaces to our YP master, an FDDI
  13. and a second Ethernet.  Unfortunately, slave servers on the new nets
  14. seem to be rejecting pushes of new maps.  (All machines involved are
  15. Sun 4s running Sun OS 4.1 or later.)
  16.  
  17. Here's a simplfied picture of what we have:
  18.  
  19.     OLD ------------------------
  20.             |              |
  21.           ROUTER         MASTER
  22.             |              |
  23.     NEW ------------------------
  24.                    |
  25.                  SLAVE
  26.  
  27. In the old world, MASTER didn't have the link to NEW and thus SLAVE
  28. saw updates coming from MASTER(OLD).  No problem.
  29.  
  30. When I enable MASTER's interface on NEW it of course sends packets
  31. to SLAVE via the direct route.  When I try to do a yppush it simply
  32. hangs.  If I disable the interface and try again the yppush works
  33. just fine.
  34.  
  35. The YP hosts database contains the following entries:
  36.  
  37.     134.79.OLD.x    MASTER MASTER-OLD
  38.     134.79.NEW.x           MASTER-NEW
  39.  
  40. The YP .dbm files contain the entry
  41.  
  42.     YP_MASTER_NAME MASTER
  43.  
  44. i.e. YP thinks the unqualified name, which YP maps to the original
  45. address, is the name of the master.  My assumption is that SLAVE is
  46. translating the value of YP_MASTER_NAME to an address, comparing it
  47. to the one in the received packet, and rejecting the request because
  48. the addresses don't match.
  49.  
  50. One attempt was to add a host route on MASTER pointing to SLAVE via
  51. ROUTER(OLD) in the hope that the request would indicate it was from
  52. MASTER(OLD).  This still produced a hang of yppush.
  53.  
  54. Another attempt was to rebuild the slave server using MASTER-NEW as
  55. the master.  This caused ypinit to fail until I removed the check
  56. verifying the named master against what the databases claimed.  The
  57. install worked fine after that, but then ypserv dumped core as soon
  58. as it started.
  59.  
  60. Does anybody have any suggestions, or must I make sure that my YP
  61. master has only one network interface?
  62.  
  63. -- 
  64. Karl Swartz        |INet    kls@unixhub.slac.stanford.edu
  65. SLAC Computing Services    |       or kls@ditka.chicago.com
  66. 1-415/926-3630        |UUCP    uunet!lll-winken!unixhub!kls  -or-  ditka!kls
  67. (SLAC and the US Dept. of Energy don't necessarily agree with my opinions.)
  68.