Newsgroups: comp.sys.next
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!umcvmb.missouri.edu!CCGREG
From: CCGREG@umcvmb.missouri.edu (Greg Johnson)
Subject: Toward a "Public NeXT Lab" guidebook
Message-ID: <9106141908.AA25449@cheops.cis.ohio-state.edu>
Sender: daemon@cis.ohio-state.edu
Reply-To: Greg Johnson <CCGREG%UMCVMB.MISSOURI.EDU@OHSTVMA.ACS.OHIO-STATE.EDU>
Organization: University of Missouri - Columbia
Date: Fri, 14 Jun 1991 18:51:48 GMT
Lines: 312

This is directed to persons charged with setting up a "public NeXT lab".

Disclaimer:  My experience with NeXT & Unix is simply what I've learned in
the last few months in deploying a lab.  Please weigh critically everything
I say here!  I hope my presumptiousness provokes experienced system
administrators to correct and expand these notes!!  If there is sufficient
modification over the summer, I will try to consolidate the improvements
into a new report.

There are at least two mandates one might have in configuring a NeXT network.

(1) Each person uses mainly one machine, but occasionally may want to use
NextStep on another machine to access files on his or her own system.
Options for implementing this "personal workstation" network are described
in the NeXT _Network_and_System_Administration_ manual.

(2) A different configuration is demanded for the "public workstation lab".
In this case each workstation is to be made available so that no matter
which head you use, you see as much as possible the SAME view as from other
workstations.  The effect is much the same as for a central system with
terminals, but in a workstation net each client bears the bulk of its own
processing load.  Network traffic is greatly reduced by sharing just those
items that a client workstation uses infrequently.  For NeXT, this is the
"extended" part of the extended OS (documentation, "demo" programs,
Shakespeare, and so on) plus local applications and libraries.  These
"extras" can consume hundreds of megabytes of disk.

HARDWARE

My recent postings of advice from EPS offer a starting point.  His emphasis
of buying plenty of RAM is verified by my experience to date.  Other recent
postings have mentioned sources of ethernet cable and connectors.  The NeXT
archive sites contain reports on 3rd party disk and RAM.

With perfect hindsight I can say we should have traded one of the two laser
printers and even a NextStation toward getting a backup tape device and more
memory.  (I wasn't consulted on this, but might not have known any better.)
One should also budget for an external network connection.

You'll probably remember tables, chairs, and wiring in your lab budget, but
don't forget surge protectors and toner cartridges and paper.  A few extra
ethernet cables, connectors and terminators, an extra NeXT mouse, and mouse
pads will make life easier.  Once you hear 15 people taking the NeXT Guided
Tour at the same time, you may also want to provide headphones.  Manuals,
headphones, and other items that might "walk" should be checked out through
some help desk or lab assistant procedure.  Speaking of things that walk,
depending upon your environment you might also consider securing your sleek
black machine to its table.  Or get NextDobermans to go with you NextLab...

If you anticipate hands-on training or instruction with your NeXT lab, then
be aware that workstations such as NeXTs tend to overwhelm LCD projection or
some large-screen monitors used with PC's or Macs.  Perhaps someone might
contribute their evaluations of presentation technology that has worked with
NeXTs.  One option for teaching with NeXTs is provided by the "GreyBoard"
application available via FTP from the NeXT archive sites.  This allows an
instructor to put a draw window on each student's screen, and draw, write,
and cut and paste into this.


TO NETBOOT OR NOT TO NETBOOT?

The advice observed on comp.sys.next which is definitely verified by my
tests, is that you don't want to have more than about seven Netboot clients
per server if they are 8MB NeXTs.  If users are running Mathematica or other
memory gluttons, then decrease this ratio.  With more memory on each client
(go for at least 16M) or if the stations are intended for word-processing or
other light applications, you can probably have a larger client/server
ratio.

At a 7:1 NetBoot client/server ratio, it is more economical to NOT NetBoot.
Since NeXT has not offered a diskless NextStation, it makes more sense to
use the 105M disk of each NextStation for paging and perhaps essential
system files and thereby allow more clients per server.  In fact, I am
running 20 NextStations (each 8MB RAM, 105 MB disk) with one server (32MB
RAM, 661 MB disk), with every client workstation busy running Mathematica or
other heavy applications every minute the lab is open.  There have been
occasional ethernet traffic jams ("ok class, let's all login") but
performance has thus far been adequate when all stations are occupied, and
excellent at other times.

By not netbooting, the clients can also function to some extent if the
server or network is unavailable.  Currently, a Calculus II course depends
on this NeXT lab as a daily classroom using Mathematica.  Hence the option
to have the clients function without a net is a requirement for us.
Consequently, I kept all the files that came with the 105MB NextStations,
and added Mathematica.app to these.

Others may not regard this standalone option as necessary, and can clean out
most files EXCEPT /private, /mach, /etc, /bin, /dev, /usr/shlib, and
/usr/lib.  It is possible to have a functioning Unix console with no GUI on
a NeXT booted from a 2.8M floppy and nothing else!  However, my impression
is that though one can free a few meg by removing /NextApps, /NextLibrary,
/NextDeveloper, and odds and ends of specific files in /usr, frankly,
there's not much fat on a 105MB slab that NeXT has not already sacrificed.

The reason for trying to free up more disk space on a client workstation is
to use that space for exported home directories or for backup, as I will
describe.  It's EASIER to buy more disk, if you have the money.

You still need to netboot to restore a damaged NextStation.


NFS MOUNTS

Via NFS mounts we have provided each workstation including the server with
exactly the same view of the system, with the exception that root
directories such as /LocalLibrary can be updated only from the server.
Network accounts allows the user to login to any workstation.

Our server has two partitions.  The root partition is the standard
arrangment.  The root partition also includes a directory /users which
contains a ".dir.tiff" file.  "/" is exported read-only to all clients.  The
clients mount these server root subdirectories over their own:  /LocalApps,
/LocalLibrary, /bin, and /NeXTLibrary.

I do not mount /NextApps, since with just a little copying from server to
each slab, the slab /NextApps is the same as the server /NextApps.  This
doesn't help local or network performance that much;  for example, once
Mathematica is loaded from the net, it just pages in and out locally;
performance is best improved by buying more RAM.

When our NeXTs arrived, 16 of the slabs had NeXT 2.1, but a few of the slabs
had NeXT 2.0 and the server had NeXT extended 2.0.  Mainly because
/usr/shlib and the workspace files in /usr/lib differ significantly between
2.0 and 2.1, I couldn't just mount the server /usr over the client /usr.
There are also symbolic links in /usr to /private that caused me some
troubles.  So, although I have since gotten everything up to 2.1, I have not
mounted /usr/shlib from the net, which helps performance anyway.

The second server disk partition contains user home directories.  This
user-home-directories partition is mounted as "/users/1" (this is specified
in /etc/fstab).  The server exports /users/1/ as read-write to all clients.

Each client workstation also has a local "/users" directory with a silly
.dir.tiff file in it.  Each client NFS-mounts the "server:/users/1"
directory as its "/users/1" directory.

Why not mount /users/1 with one less level, say as "/users" or "/clients"?
The arrangement I've described allows us to add external disks or use the
disks of clients for user home directories!  For example, on workstation
number 2, I could define a local directory /users/2/, export this read-write
to the network, and mount it as /users/2/ on all the other workstations
(including the server).  We have chosen not to do this at this time, but
it's an option to squeeze the last byte out of the disks we own.

There should be value in separating /private & mail-related directories into
their own partitions, but I haven't played with this yet.

Our /users/1/ partition is further divided into "staff", "student", and
"visitor" subdirectories, under which come the actual user home directories.
This makes it easier for students to find course directories via the
browser, though we further simplified this via links.

SECURITY AND NEW ACCOUNTS

NeXT Inc offers courses in system administration, in service, and in
application development.  Go.  See the factory.  Learn why there is a car in
their parking lot that is without license plates.

To allow the new private owner of a NeXT freedom to play and configure, the
NeXT comes with defaults set to allow that individual wide freedom.  Files
he or she creates on one account can be accessed from another.  This is fine
for a workstation you own, but is undesirable in a public lab situation.

The NeXT System Admin manual toward the end offers suggestions for protecting
system files.  Follow them.  There are more protections to consider, and when
I become more confident in my pronouncements, or get some of that expert
advice I have here solicited, I will try to summarize specific security
considerations for a public NeXT lab.

One thing you must do is set up a model account, and make that the default
configuration for creating new accounts.  Create a new account, and use
Preferences to set the file creation default permissions to allow access to
files only by the owner.  Put the applications you want the new user to see
in the Icon dock.  Put important directories on the file viewer shelf!
Clean up unneeded files;  I left only Mailboxes for my default user so they
could get their message from Steve J.  Use chmod -R go-wrx ~ to disallow
access to the remaining files.  Test security via yet another account.

When you're done, go to your wheel account and back up /usr/template/user
and replace it with the home directory of your model account.

You'll probably want to create some user groups to separate students, staff,
and administrative users.  I suggest that except for the few who will be in
the wheel group, that you make new groups and not use "other", "staff" and
so on that come with the system.

Modify /etc/nu.cf to suit your configuration.  My changes to the include:

   NetInfoDomain = "/"  ; "." -> Local domain
   DefaultGroup=21 ; default user-group number (studenti)
   DefaultHome = "/Users/1/students"
   GroupHome=  21 "/Users/1/students"
   GroupHome=  22 "/Users/1/students"
   GroupHome=  23 "/Users/1/students"
   GroupHome=  25 "/Users/1/staff"
   GroupHome=  26 "/Users/1/staff"
   GroupHome=  27 "/Users/1/staff"
   GroupHome=  28 "/Users/1/staff"

You will probably find the "nu" command more convenient than UserManager.
To load dozens of student ids, I extract data from our registration system,
transfer it to the NeXT, massage it to form, and feed it to "nu -a".  We use
the student's birthdate as their initial password.

HELPING THE NEW USER

Wanted:  a login hook module that will force a first-ever login to change
the password.  Contributions will be, ahem, gratefully acknowledged.

A public lab will probably want to install the MOTD (message of the day)
login hook obtainable from Internet NeXT archives like nova.cc.purdue.edu.
Not only does this issue system messages, it also makes up for an oversight
by NeXT in updating the file that journals user logins.  One enhancement to
MOTD that I have considered is a button to take the NeXT Tour, via the
"system()" function.

The first-time user can profit from easy access to such items as local
policies ("the user is ultimately responsible for his or her own data", "be
good", etc.).  A simple way to do this is to put the directory or file icons
for such must-read items in the shelf of the template user's FileViewer.
Change the default bookshelf used by Librarian to include the files you
want;  see ~/Library/Bookshelves in your model user or if you deleted this
as I did, see /NextLibrary/Bookshelves/Librarian.bkshlf.

I went a bit further and made a simple panel ("Accessor") that is launched
at a new user's login via WorkSpaceManager preferences.  It has oversized
buttons which open appropriate bookshelves for Librarian, open individual
files for Edit, invoke the NeXT Guided Tour app, open the Tour of
Mathematica, select a "Questions&Suggestions" application, and other things
I thought will be of particular interest to our new users.  Please, my
Accessor is wonderful to see but an ugly kludge inside;  what would be good
is for someone to make a build-your-own-Accessor, a kind of floating dock,
into which the builder could drag not just App icons, but file icons and
bookshelves.  The buttons must offer room for some non-cryptic explanation
besides the icon or filename.


SYSTEM MAINTENANCE FOR THE PUBLIC NEXT LAB

My backup procedure has been simplified since my management neglected to
budget a tape drive.  Those of you with tapes, what evaluations and
suggestions do you have?

(We don't even have an external network connection yet.  So I am doing
backups by utilizing the extra 15MB or so on the slabs for local mods, and
lugging in a cube with an optical disk for occasional system backups, and
also occasionally cloning the server to an identical cube.)

There are several screen dimmers on the public archives;  that's because
none of them is satisfactory for all situations.  NeXT!  please provide an
option to prevent panel burn-in for BOTH workspace and login modes!  Totally
blanking EVS & NVRAM screen video would suffice.  The option of moving
images on the screen would be ok, but at least let us black the screen.  You
do like black, don't you?  In a public lab users cannot be counted on to do
the right thing manually.  Until I get something better working this is in
the /etc/crontab.local file of each workstation:

0 0,1,5,17 * * * root /usr/local/bin/bright 0

The little "bright" program is available from the public archives.  It can
be enhanced to handle both EVS & NVRAM video.  To warn users
the lab is closing down at midnight, etc., I do annoying things like:

55 23 * * * root /usr/bin/sndplay /LocalLibrary/Sounds/shutdown.snd
55 23 * * * root /usr/local/bin/bright 20
59 23 * * * root /usr/bin/sndplay /LocalLibrary/Sounds/latelatelateshow.snd

For the server, I also run the following shell after the lab closes.  There
are surely lots of improvements to be made here, but this may offer a start
for other dilettantes.

# update Unix passwd & group files from NetInfo database:
 nidump passwd / | awk 'BEGIN {FS=":"; OFS=":"} {$2="";print}' |
    sort -t: - > /etc/passwd
 nidump group / > /etc/group
# Make list of accounts & names for easy reference:
 awk 'BEGIN {FS=":"} {printf "%-8s\t%s\n", $1, $5}' /etc/passwd >
   /LocalLibrary/Misc/Users
# Summarize user disk usage:
 df > /LocalLibrary/Misc/DiskUsage
 du -s /Users/1/students/* | sort -nr >> /LocalLibrary/Misc/DiskUsage
 du -s /Users/1/staff/*    | sort -nr >> /LocalLibrary/Misc/DiskUsage
 du -s /Users/1/visitors/* | sort -nr >> /LocalLibrary/Misc/DiskUsage

Not all Unix thingies will know about NetInfo, so you should keep a passwd
file.  Blanking the password hinders brute force crackers.  There's a link
to /etc/passwd as /LocalLibrary/Images/People/passwd.

The disk usage report allows users to identify hogs among themselves.  I
haven't implemented quotas because (a) I wanted to see what usage profiles
develop if I don't, (b) if space is used for reasonable things then perhaps
I can persuade the money people to buy more disk, (c) I haven't had time to
study how quotas are handled, and (d) it may not even be possible;  I
vaguely recall that quotas weren't implemented under 1.0.  Is anybody doing
disk quotas?

THAT'S ALL FOR NOW

Some of this may be incorrect or best done in other ways.  Definitely there
is more to be said generally about policies of public workstation labs and
Unix security.  There are news groups and FTP-able reports that cover such
general matters.  In future updates to this "public NeXT lab" report, I hope
to receive contributions in such If an immediate correction or item for
discussion is warranted, please post to comp.sys.next.  I will try to
summarize what comes to me.  On behalf of the students, faculty, and others
all over the world who will profit from well-planned NeXT labs, I solicit
your advice!  Thank you!

:  Greg Johnson, Senior Scientific Programmer/Analyst -- Computing Services
:      233 Heinkel Building, University of Missouri, Columbia, MO 65203
:   CCGREG@UMCVMB.MISSOURI.EDU / phone 314-882-2000
