From: cmaae47@cc.ic.ac.uk (Thomas Sippel-Dau)
Newsgroups: comp.sys.sgi
Subject: Re: How to feed my Indigoes
Date: 7 Apr 92 19:19:07 GMT
Organization: Imperial College Computer Centre
Originator: cmaae47@cc.ic.ac.uk

in Message-ID: <1992Apr3.200418.28043@umbc3.umbc.edu> alex@umbc4.umbc.edu 
  (Alex S. Crain) writes:
> I'm laying out some labs of Indigos for the university. These will be 
> unsupervised facilities for students, and may be open 24 hours, operated
> by a skeletal staff.

> We will be using the locking bars, and securing the units to the tables,
> but I understand that the power and reset switches will still be exposed.
> Is there any problem with this scenerio that I'm missing? I'm worried
> both about theft and the idea that a dedicated hacker might find a way to
> coerce the machine into single user mode.


We have some in Indigoes in a lab, and they are bolted down with a
triangular metal prop that extends into the hole for the normal security
bar, i.e.:

               +--------+
               | Indigo |
               |        |
               |x--------+        (side view)
               |        ||\
               |        || \
               |        ||  \
               |        ||   \
               |        ||    \
               +--------+|_____\
======================================

This has (so far) prevented theft of the machine - removal will generally 
destroy the machine and thus be pointless. Still, the front panel could be 
forced off (it is only plastic) and the motherboard and disk drives removed
intact.

They have also glued a piece of plastic in front of the reset button, but
then found the sudden need to drill pinholes through that, which means the
Macs and Indigoes now share another indipensible peripheral :-) It also
does not stop anybody from pulling the plug.

If you want to outsmart hackers, you should basically keep the file server
in a physically secure room, and stick to some other good practices, then 
the evil enemy will need a (portable) tape or CD drive to do anything
useful  with the machine (which means to install an operating system first)
Think of installing closed circuit TV - I guess you have a concierge in the
building to look at that.

Finally, to stop nuisance reboots (i.e. "machine is obviously broken as it 
is too slow running my job") you could prevent the machine from
automatically rebooting unless a password is entered (at the server). This
has the slight disadvantage that a short power outage will make the whole
lab useless until somebody comes and picks it up again, and that it is
vulnerable to crash attacks. We found, however, that after about two months
of giving people an earful after each restart request nuisance booting
is not so frequent any more. 

he continues :

> What's the best way to set this up? I'm thinking that I would put
> root, tmp and swap on the local disk and set up a server for with a
> couple of gigs.  Can I use one of the indigo's to serve the others, or
> should I look for a separate server machine.

Generally the Indigo is fine as a server for around 10 machines, to linked
ones for up to twenty. Above that it is probably better to split off
another Ethernet subnet. I found the Indigo has a sustained file throughput
of about twice those of comparable machines (Sparkstation2, DEC500/200,
RS6000/530, HP 720 were the ones I tested). I still believe this has not
much to do with faster chips or buses or disks, but with efs rather than
other file systems.

The file server can run number crunching batch jobs as long as paging is 
kept low, and of course, paging anything to do with nfs does not help at
all. Furiously paging jobs on user clients make the character response bad,
but not as bad as on the other machines mentioned.

I would keep root on the file server, it does not contain much that is
performance critcal (the kernel comes in at boot time, hopefully not too
frequently), and the other stuff (tar, ex, sh, csh and so on) is not really
read that often when its not already available in memory. Thus the
Network administration guides lead you just where you want to go.

You will need an Ethernet gateway or router unless SG comes up with an
add-on Ethernet board pdq.

The biggest performance problem generally is in a class when suddenly 20
or so machines start using the (Fortran, C, ...) compiler or Codevision
Explorer or whatever at the same time. The workaround is to keep talking
for a couple of minutes after the first instruction to issue a command,
later on courses will differentiate themselves to avoid the problem.

Local temp and swap space is a must. Also, set aside one or two disks (2 to
3 GByte) for scratch space, i.e. disk space not backed up and wiped after a
short time (three days non-access, seven non-modify) which is shared among
all clients and open to use for anyone. Create a directory for every user
in there so that people cannot accidentally trampel on each others files.
Enforce rabid quotas on the user file disks (/home or whatever). 235 Mb 
disk space on each client may just get you through this year, but for a
seven year life you will need more. Ditto memory - lets hope it will become
cheaper by the time you just must have it.

Hope you find this useful                         Thomas.
-- 
*** This is the operative statement, all previous statements are inoperative.
*   email: cmaae47 @ cc.ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic.cc on Janet)
*   voice: +44 715 895 111 x4937 or 4934 (day), or +44 718 239 497 (fax)
*   snail: Imperial College Center for Computing Services, Kensington SW7 2BX