home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / large / 380 < prev    next >
Encoding:
Internet Message Format  |  1992-11-13  |  5.0 KB
  1. Xref: sparky comp.unix.large:380 mi.misc:744
  2. Path: sparky!uunet!know!hri.com!noc.near.net!news.Brown.EDU!qt.cs.utexas.edu!yale.edu!jvnc.net!darwin.sura.net!zaphod.mps.ohio-state.edu!caen!destroyer!cs.ubc.ca!newsserver.sfu.ca!sfu.ca!vanepp
  3. From: vanepp@fraser.sfu.ca (Peter Van Epp)
  4. Newsgroups: comp.unix.large,mi.misc
  5. Subject: Re: LISA VI paper availible via anon ftp
  6. Message-ID: <vanepp.721671320@sfu.ca>
  7. Date: 13 Nov 92 16:15:20 GMT
  8. References: <1dmrsdINNcs4@nigel.msen.com> <scs.721401144@hela.iti.org> <vanepp.721411740@sfu.ca> <5c4efaf4.1bc5b@pisa.citi.umich.edu> <vanepp.721543207@sfu.ca> <5c53cdbd.1bc5b@pisa.citi.umich.edu>
  9. Sender: news@sfu.ca
  10. Organization: Simon Fraser University, Burnaby, B.C., Canada
  11. Lines: 74
  12.  
  13. rees@pisa.citi.umich.edu (Jim Rees) writes:
  14.  
  15. >In article <vanepp.721543207@sfu.ca>, vanepp@fraser.sfu.ca (Peter Van Epp) writes:
  16.  
  17. >  If I had thought of it, I knew that :-), I was expecting that you might be 
  18. >  big enough to run out of 65000+ uids.
  19.  
  20. >It's worse than that.  There are still some Unix systems out there that
  21. >store the uid in a signed short, which means you've only got 32,000 of them
  22. >available.  That's roughly the size of our user community, and I think we
  23. >have about 28,000 assigned now, even without IFS extensively deployed.  That
  24. >doesn't leave much breathing room.
  25.  
  26. I know, we have some uids above 32k and we see some interesting problems
  27. at times. Several of our part time operators couldn't do sudo on some
  28. machines before we diddled sudo to use an unsigned int (which I'm suprised
  29. worked, since the system still thinks its a signed int!), maybe we were
  30. just lucky :-)
  31.  
  32.  
  33. >  We are small enough that we could make do with
  34. >  a single NFS fileserver to give us central file services...
  35.  
  36. >No way will that work with 30,000 users.  Client caching is absolutely
  37. >essential, and it's also nice to have some sane kind of sharing semantics
  38. >(unlike what NFS gives you).
  39.  
  40. While I completely agree that some form of AFS like system is the final
  41. answer, at the time we did this (and even now for that matter) most of the
  42. people here are not Unix experts (including me!), we had only one person that
  43. was an experienced Unix sys admin, all the rest of us are MTS retreads (not
  44. a bad point to be starting out from I will admit :-) ). At that time (and
  45. probably even now) Transarc didn't support the Silicon Graphics machines,
  46. and we already had some. 
  47.     Since we run an Auspex file server with 6 (of the possible 8) Ethernet
  48. ports and all the NFS service is in the machine room on secure Ethernets, we
  49. in fact manage to support some 11,00 active users (of a total of > 20,000)
  50. home directories from that single NFS server. We selected NFS because all
  51. the machines we had support it (and at that point we didn't know of all the
  52. security problems present in both NFS and Unix!). This entire phase of the
  53. conversion was designed with the thought that it was a 2 year solution (whether
  54. that ends up being true remains to be seen :-) ), and hoepfully when (and if!)
  55. the time comes to move on, AFS, DFS or IFS will be a more mainstream solution
  56. or equally possibly, we will have enough confidence in our Unix expertese to
  57. be able to do the work required to install it for ourselves.
  58.     The security problems we are seeing and the lack of security in NFS
  59. (at least NFS that will work with all vendors) have caused us to restrict
  60. access to the file server to our machines, in our machine room, where we had
  61. hoped to be able to provide it to the desk top. 
  62.     We are currently looking at the Novell Netware product on a Sun to 
  63. see if we can use that to export NFS mounted home directories to Macs and PCs
  64. in a semi secure manner (i.e. the NFS side will be controlled on a secure
  65. ethernet on the Sun not exposing the NFS mount point to the backbone Ethernet).
  66.     In general all parts of this conversion were probably over specified
  67. and in most cases, selected with the capability to increase capacity by just
  68. adding money if we found that we had under estimated the load. Both the Auspex
  69. and the SGI machines are upgradeable to more capacity, the Auspex by adding 
  70. more disks (which we have done) and more ethernets (which we haven't so far),
  71. and the SGI machines by just adding more CPU boards and booting the machine.
  72. I will note that after I commented in the the selection meeting that the
  73. single CPU model was probably alright, after all we could just give SGI more
  74. money and buy a another couple of cpus when it fell over dead (about 15
  75. minutes after we turned it on), which caused the bosses to buy the 2 cpu
  76. model right off... We in fact haven't had to upgrade yet (although with
  77. 20/20 hindsight I expect we might have had to with the single CPU model).
  78. Should we have to, we can plug in another 2 cpu board and boot, and away
  79. we will go, no fuss no muss, we have done it before on our previous SGI 
  80. systems.
  81.     I expect that this could have been done more cheaply, but no matter
  82. what happened, we would (and still could) find uses for all the machines that
  83. we have if we had indeed made a major under estimate of our requirements.
  84.  
  85. Peter Van Epp / Operations and Technical Support 
  86. Simon Fraser University, Burnaby, B.C. Canada
  87.