home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / wizards / 3675 < prev    next >
Encoding:
Internet Message Format  |  1992-08-22  |  1.7 KB
  1. Path: sparky!uunet!cs.utexas.edu!rutgers!igor.rutgers.edu!romulus.rutgers.edu!rauscher
  2. From: rauscher@romulus.rutgers.edu (Rich Rauscher)
  3. Newsgroups: comp.unix.wizards
  4. Subject: NIS question
  5. Keywords: ypyuk
  6. Message-ID: <Aug.22.10.04.26.1992.5528@romulus.rutgers.edu>
  7. Date: 22 Aug 92 14:04:26 GMT
  8. Organization: Center for Discrete Math. and Theor. Comp. Sci.
  9. Lines: 38
  10.  
  11.  
  12. Recently, I was moving all the machines of one yp domain
  13. to another new yp domain. 
  14.  
  15. 1) First, I set up the new yp master (ypinit -m)
  16.    Than I went into a couple of clients and said
  17.    "domainname NEW_DOMAIN".  I changed /etc/defaultdomain
  18.    (that's where rc.local looks when rebooting) to the new
  19.    domain.
  20.    I did a ypwhich -m and found that they were getting all their maps 
  21.    from the new master.
  22.  
  23. 2) I set up a few slave servers. Eventually I had moved the
  24.    entire network over to the new domain with the exception
  25.    of the former master and slave servers.
  26.  
  27. 3) I moved over the old slave-servers to the new domain (and
  28.    killed ypserv).
  29.  
  30. 4) I killed ypserv and moved the old master server over.
  31.  
  32. Then every machine on the network started complaining that
  33. they couldn't find the old NIS domain.  Huh?  Ok...I thought
  34. there may have been some risidual data structure in ypbind.
  35. So I killed and restarted and ypbinds that were running on
  36. a suffering machine.  Nothing...it still cried about not
  37. being able to find the old domain.  Eventually, every machine
  38. had to be rebooted.  Blah.
  39.  
  40. If anybody in netland can tell me why this didn't work, I would
  41. be most apreciative.
  42.  
  43. Thanks,
  44. Rich
  45. -- 
  46. Rich Rauscher, Systems Analyst, Federal Reserve Board of Governors
  47.               "In the long run, the computers will win."
  48. rauscher@dimacs.rutgers.edu     uunet!fed!rauscher   rauscher@NJIN.bitnet
  49.