home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / sun / admin / 9744 < prev    next >
Encoding:
Text File  |  1992-12-27  |  2.8 KB  |  64 lines
  1. Newsgroups: comp.sys.sun.admin
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!batcomputer!bouncer
  3. From: eirik@elf.TN.Cornell.EDU (Eirik Fuller)
  4. Subject: default route for diskless clients
  5. Message-ID: <1992Dec28.044346.4184@tc.cornell.edu>
  6. Sender: news@tc.cornell.edu
  7. Nntp-Posting-Host: earache.tc.cornell.edu
  8. Organization: Cornell Theory Center
  9. Date: Mon, 28 Dec 1992 04:43:46 GMT
  10. Lines: 52
  11.  
  12. Empirical observations have led me to the following conclusion:
  13.  
  14. The default route for a diskless client is provided by rpc.bootparamd,
  15. and it chooses the first entry in the kernel's network routing table
  16. which is on the same subnet as the client.  This can lead to some
  17. silly choices, such as one end of a PPP link, or a gateway to an
  18. optical network.  Both of those have happened, with no contortions on
  19. my part.
  20.  
  21. If this conclusion about how the client gets its default route is
  22. wrong, I welcome corrections.
  23.  
  24. It might seem irrelevant which default route is used, but what happens
  25. if the default route (the silly choice, not the natural choice) goes
  26. down?  Our networks have dedicated routers, which provide a natural
  27. choice of default route.  Randomly choosing a host on the same subnet
  28. as a default route does not seem like a sensible algorithm.
  29.  
  30. It might also seem trivial to fix this poor choice of default route.
  31. However, if the client's /usr lives on another subnet, there is a
  32. chicken-and-egg problem.  The route command, even if copied to the
  33. root partition, still requires shared libraries, which become
  34. inaccessible (but are apparently still necessary) after the routing
  35. table is flushed.
  36.  
  37. The 4.1.3 /etc/rc.boot mentions a statically linked route command, but
  38. I think that's just there to torment people like me.  Providing a
  39. statically linked route command as part of the SunOS distribution
  40. would be almost as useful as providing a dynamically linked mount
  41. command.  Had the designers of /sbin been on the ball, there would
  42. have been both static and dynamic versions of everything in there, and
  43. route would have been there.
  44.  
  45. I could put libc.so.* into the client root partition, but that's gross.
  46.  
  47. I could decide against mounting /usr from another subnet, but that's
  48. not what I want.
  49.  
  50. I could settle for the silly choice of default route, but that's not
  51. what I want either.
  52.  
  53. What are my other options?  Is there some way to tell bootparamd what
  54. route to use for each client, or some way to convince it to use the
  55. default route, if applicable (i.e. if it's on the same subnet as the
  56. client)?  Is there some way to rig the routing tables so that the
  57. default route comes first?  Is there a SunOS patch somewhere that
  58. provides alternate linkages of the commands that live (or should live)
  59. in /sbin/?
  60.  
  61. Will I have to start beating up some lawyers so we can get the SunOS
  62. source code we tried to get years ago?  Perhaps the next thing to do
  63. is to look for a free implementation of the route command ...
  64.