CCGREG%UMCVMB.BITNET@OHSTVMA.ACS.OHIO-STATE.EDU (Greg Johnson) (06/06/91)
Two months ago I posted a plea for general advice for setting up a NeXT lab. Due to possible problems with the Bitnet feed to comp.sys.next, I received only one response, but as you will see, an informative one. Still, we all could profit from the experiences of seasoned NeXT managers. My request stands! I did say I would summarize to the net, so following is Eric's reply to my initial posting. I will send as a second note a followup exchange we had. Thanks again, Eric! : Greg Johnson, Senior Scientific Programmer/Analyst -- Computing Services : : 233 Heinkel Building, University of Missouri, Columbia, MO 65203 : : CCGREG@UMCVMB.MISSOURI.EDU / CCGREG@UMCVMB.BITNET / phone 314-882-2000 : Date: Sat, 13 Apr 91 23:02:54 PDT From: eps@toaster.SFSU.EDU (Eric P. Scott) To: CCGREG@umcvmb.missouri.edu Subject: Re: Networking NeXTs in a student lab environment >Friends, System Administrators, and Users, lend me your experience! > >I'd like to hear from persons who've had experience with student labs >containing multiple networked NeXts. What advice do you have for anyone >planning and administering such an environment? > >The U of Mo is obtaining several NeXTs to go into a workstation cluster. >Access to the lab will probably be "open". We'd like to maximize >access, but to do this will probably need to minimize maintenance of >hard-disk space for user files, instead encouraging users to provide >their own media when their projects allow this. They're going to bring in their own SCSI hard disks??? >Additionally we want to create a more-nearly homogeneous lab of a dozen >or more NeXTs or Sparc2s (probably NeXTs), $ allowing. Oh boy. Well, now you know why default paths on the NeXT contain ~/Unix/bin instead of ~/bin on the SPARC. Since executables aren't binary-compatible, all users have to compile their personal programs for two platforms. >Some specific questions for people living with networked NeXTs: > >1) What is your configuration (types of systems, connectivity, servers, > backup mechanisms, etc.)? We have original NeXTs, NeXTstations, and NeXTstation Color machines. (Also some "off brand" curiosities (e.g. Apollo DN 2500, IBM RS/6000)). We purchased '040 upgrades for *all* of our original NeXTs. No machine has less than 16MB. All NeXTstations have 20MB *minimum* (they really, really need it); we haven't ordered memory upgrades for the Color machines yet, but we're going to try to get them to at least 24MB each, if not the full 32MB. Client:server ratio limited to 6:1. We're using the fastest disks we can find, and planning to expand as usage increases (i.e. treat disk space as a non-renewable resource, users keep their access for as long as they want, no personal use restrictions). We just received some Fujitsu 2266 1.2GB drives, we're rather pleased with them so far. Backups are done to an Exabyte 8mm cartridge tape drive (mostly over the network). Each cartridge holds 2.3GB, the tapes are $5 each. Backups are handled by cron jobs; someone puts in a tape each evening, it gets written on starting at 2:30 a.m., someone takes the tape out the next morning so the drive's available for "whatever" during the day. I don't know the details of what gets backed up each day, but it works out. >2) What most pleases you about your configuration? We don't have Suns. :-) Our school (School of Science, one of 8 within the University) has a lot of different machines (including Suns). Since we started using NeXTs, Suns became a *lot* less attractive. (The people who have Suns have them to run specific commercial software packages, and as time goes on, the "gap" is narrowing.) Thank God we don't have to run YP/NIS on the NeXTs. NetInfo is *so* much nicer. And we can do so much more than X Window- based systems would permit, and faster. >3) What most irritates you about your configuration? One of the problems is that we have users' files spread across several machines. In most cases, they're on external disks, so if a machine is going to be out of service, we can plug it into another NeXT with minimum grief. I'd much rather have something like an Auspex NS 3000 or NS 5000 dedicated NFS server so all users would see a consistent view of the universe. Getting electronic mail to go to the right place (and not to the "wrong" places) is annoying. We don't believe in a central mailhost. >4) What modifications or customizations are installed where you are? > For example: security settings, software organization, network > organization, hardware hacks, ... Tons of stuff, but no hardware hacks. Mostly Internet-related things (no inbound connections from unregistered sites, no "nethopping" (telnetting to one machine then telnetting out from there), etc. We have as much documentation as possible available online, including the BSD documents and NextAnswers. We provide many useful things in /LocalApps and /usr/local/bin. We intend for the machines to be fully functional as conventional UNIX workstations (we have a lot of people dialing in from home and telnetting in). >5) What practical advice do you have for an open lab situation? For > example, how do you handle disk quotas, No disk quotas. Each user understands that we operate in a cooperative environment, and they can't be too piggish. We have students with 150MB online, and that's o.k. as long as it doesn't become a long-term habit. > virus protection, Ha ha ha. We only have virus problems on PCs and Macs. We've pretty much exterminated all the PCs, and on the Macs we use Disinfectant (it's FREE; comparable software for the PC would cost us $18,000 annually in licensing fees), and keep a lot of stuff on AppleShare servers in write-protected folders. The NeXTs are an absolute joy in comparison--each user has his or her own username (sharing accounts is strictly forbidden). Each user must sign a "certification of use" that explains relevant sections of California's Penal Code as it applies to computer and network abuse. Violators are dealt with through University disciplinary procedure (that a computer means little) and/or criminal prosecution. There's no "screw up and lose your computer access"--there's "screw up and be suspended or expelled from the University." Other than that, users do pretty much whatever they want, whenever they want, with little or no supervision, and an assurance that their privacy will be protected (no one searches though their files without a damn good reason, and preferably a court order). > and so on, > especially regarding the NeXT? Treat the machines as workstations, not as PCs. Make sure you know *who* is using each machine, especially if they're connected to the Internet (as ours are). No anonymous usage! If budget constraints force you to choose between more seats or better- equipped machines, go for the latter. Don't skimp on memory or disk space. Think BIG--4 to 20 times bigger than what might be "normal" for a PC. Don't fall into the GUI trap. Programs like NetManager and UserManager often don't do what you want--and don't tell you what they're REALLY up to. Learn how to use the "advanced" tools, be able to manage your machines remotely. Provide low-cost printing solutions--people shouldn't have to burn expensive laser toner on program listings. Network EVERYTHING. -=EPS=-
SLVQC@CUNYVM.BITNET (Salvatore Saieva) (06/11/91)
I'm curious how you Lab Managers are using the 105MB HD on the client
machines. Do you netboot the clients mounting / from the server or do
you keep boot files (and other pre-installed files) on the local client
disk and do some other magic to access the extended release of OS
from the servers? I've been toying with both net configurations for the
past few days and (as you'd guess) there are drawbacks to each:
Netbooting and mounting / remotely doesn't make use good use of an
available 105MB HD and it's slow to startup NeXT apps; Booting the
NeXTstations from the local HD is faster, provides quicker startup for
the available pre-installed NeXT software, but it looks like a nuisance
to setup a NeXTstation to run the dev tool available on the server.
I've been thinking about some sort of compromise: Netbooting the
NeXTstations and mounting / remotely, using the local 105 HD for
/private files, and also installing frequently used NeXT apps (such as
Terminal, Edit, WriteNow, Websters, etc) in a separate partition on
the local disk. If this were all possible it would seem to provide
the best features of both setups: Avoid the work to access dev tools
if / were not mounted remotely, and have local access to frequently
used adm files (/private is mounted locally) and apps. Does this
sound too nutty? Am I missing something, or maybe just trying to
complicate the issue?
How is everyone else setting-up their lab file systems and using
the local 105MB drives?
Sal.
-------
Salvatore Saieva Internet: slvqc@cunyvm.cuny.edu
Queens College, Academic Computer Center BITNET: slvqc@cunyvm.bitnet
65-30 Kissena Blvd, Flushing, N.Y. 11367 DeskNet: (718) 520-7662
awk, sed, grep, lex, yacc, make, >, <, |,... ``I got the Power!''grd@cmn9 (glen diener) (06/11/91)
In article <91161.143520SLVQC@CUNYVM.BITNET> SLVQC@CUNYVM.BITNET (Salvatore Saieva) writes: > I'm curious how you Lab Managers are using the 105MB HD on the client > machines. Do you netboot the clients mounting / from the server or do > you keep boot files (and other pre-installed files) on the local client --stuff deleted We use a script, written by Wayde Schroeder at NeXT tech support, which mounts the root directory from a machine with an "extended" os, then creates symlinks to the appropriate places to make the the slab appear as if it had the extended release. The script is called "NfsExtend", and I assume NeXT make it available just for the asking. -glen grd@ccrma.stanford.edu
eps@toaster.SFSU.EDU (Eric P. Scott) (06/11/91)
In article <91161.143520SLVQC@CUNYVM.BITNET> SLVQC@CUNYVM.BITNET (Salvatore Saieva) writes: >I'm curious how you Lab Managers are using the 105MB HD on the client >machines. Do you netboot the clients mounting / from the server or do >you keep boot files (and other pre-installed files) on the local client Absolutely not. We COMPLETELY wiped the 105s and named them all swapdisk. So far they've been adequate, but I think we've been extremely lucky. Once Mathematica 2.0 turns up, no doubt someone will burn up every last bit of the local swap and start hammering on the server. :-( >Netbooting and mounting / remotely doesn't make use good use of an >available 105MB HD and it's slow to startup NeXT apps I disagree. Unless you're trying to get away with 8MB machines, in which case you deserve to lose. Our "showcase" cluster has a 32MB NeXTstation with a 400MB ST1480 serving 20MB NeXTstations. Launch time is comparable to or better than using the local 105MB drives--those Quantums are total dogs. "We only bought them because we knew we wouldn't have to use them." > Booting the >NeXTstations from the local HD is faster, Not in our experience. And there's no root fsck needed after a client crash, either. > provides quicker startup for >the available pre-installed NeXT software, Nope. > it looks like a nuisance >to setup a NeXTstation to run the dev tool available on the server. And just think about how much fun you'll have upgrading when the next Software Release comes out. Life's much easier with "dataless" workstations (one of the better ideas from MIT's Project Athena, IMHO). >I've been thinking about some sort of compromise: Netbooting the >NeXTstations and mounting / remotely, using the local 105 HD for >/private files, /private/etc on each workstation? Won't that be an absolute joy to administrate? Where's my eleven-foot pole? On my server, I have a lot of /clients/*/etc/whatevers hard-linked--this guarantees consistency. > Does this >sound too nutty? Am I missing something, or maybe just trying to >complicate the issue? Something smells with your setup. Do you have an unusually busy network (e.g. large and bridged rather than routed) or are your machines dying for lack of RAM? If the machines are OK, I'd beg/borrow/steal a protocol analyzer and a TDR and start hunting for network gremlins. -=EPS=-