home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / sun / admin / 9752 < prev    next >
Encoding:
Internet Message Format  |  1992-12-28  |  3.4 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!udel!princeton!siemens!aad
  2. From: aad@siemens.com (Anthony Datri)
  3. Newsgroups: comp.sys.sun.admin
  4. Subject: Re: default route for diskless clients
  5. Message-ID: <1992Dec28.151142.2167@siemens.com>
  6. Date: 28 Dec 92 15:11:42 GMT
  7. References: <1992Dec28.044346.4184@tc.cornell.edu>
  8. Sender: news@siemens.com (NeTnEwS)
  9. Organization: Siemens Corporate Research, Princeton (Plainsboro), NJ
  10. Lines: 72
  11. Nntp-Posting-Host: lovecraft
  12.  
  13. >The default route for a diskless client is provided by rpc.bootparamd,
  14. >and it chooses the first entry in the kernel's network routing table
  15. >which is on the same subnet as the client.
  16.  
  17. I had several hundred diskless machines (against my wishes) in a previous
  18. life, and what you describe sounds pretty much like what I saw.
  19.  
  20. >This can lead to some
  21. >silly choices, such as one end of a PPP link, or a gateway to an
  22. >optical network.  Both of those have happened, with no contortions on
  23. >my part.
  24.  
  25. I didn't have those sorts of problems because our net was a little different
  26. from yours.  Each subnet was connected to one router, and we didn't have
  27. PPP or SLIP links to worry about, and if we did, they'd have been on the
  28. router, not on hosts.  And the whole net was optical 8^)
  29.  
  30. >It might seem irrelevant which default route is used
  31.  
  32. I was wondering that, since I always had rc.whatever explicitly set one through
  33. the router anyway.  We made sure that the router was always host 254 on each
  34. subnet, which made it easy.
  35.  
  36. >However, if the client's /usr lives on another subnet, there is a
  37. >chicken-and-egg problem.
  38.  
  39. Wow.  I have to admit that all of mine were on the same net.  Is it safe to
  40. assume that there's some reason you can't move the client to the other net?
  41.  
  42. >The 4.1.3 /etc/rc.boot mentions a statically linked route command, but
  43. >I think that's just there to torment people like me.  Providing a
  44. >statically linked route command as part of the SunOS distribution
  45. >would be almost as useful as providing a dynamically linked mount
  46. >command.
  47.  
  48. Weeeeeeel, ftp to your fav-o-rite BSD source site and get yerself the
  49. sources.  You can find them on ftp.uu.net under systems/unix/bsd-sources,
  50. for example.
  51.  
  52. I can't claim that I've built from these sources, but in said previous life
  53. I *did* build mount from that vendor's sources to try to get a binary that
  54. would reliably mount a pcfs filesystem.  I gave up on that when I found mtools,
  55. though.
  56.  
  57. >I could put libc.so.* into the client root partition, but that's gross.
  58.  
  59. True enough, but you could hard-link the copies of it together for all of
  60. the clients like I did with kernels.
  61.  
  62. >I could decide against mounting /usr from another subnet, but that's
  63. >not what I want.
  64.  
  65. The typical argument for that decision would be speed, but if you've got a
  66. nifty router like a Cisco AGS+ then it's not so much of an issue.
  67.  
  68. >What are my other options?  Is there some way to tell bootparamd what
  69. >route to use for each client,
  70.  
  71. Man, I miss not being at a vendor any more 8^(.
  72.  
  73. >client)?  Is there some way to rig the routing tables so that the
  74. >default route comes first?
  75.  
  76. Well, you're not running routed, are you?  If so, don't.  Have the "server"
  77. set the default route first upon startup and then explicitly set any
  78. non-default routes with /usr/etc/route.  I would think that this would
  79. ensure the desired order in the kernel table, not to mention making netstat -r
  80. far more pleasant.
  81.  
  82. -- 
  83.  
  84. ======================================================================8--<
  85.