CCGREG@umcvmb.missouri.edu (Greg Johnson) (06/15/91)
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-2000davis@usenet.INS.CWRU.Edu (Palmer Davis) (06/15/91)
In article <9106141908.AA25449@cheops.cis.ohio-state.edu> Greg Johnson <CCGREG%UMCVMB.MISSOURI.EDU@OHSTVMA.ACS.OHIO-STATE.EDU> writes: > >SECURITY AND NEW ACCOUNTS > One more thing: make sure you assign hardware passwords. The ROM monitor documentation is buried deep in the bowels of the N&SA manual, so it may not be obvious to a new SA that there's a security risk there. -- Palmer Davis <davis@po.cwru.edu> I'm probably wrong, so don't blame INS. CWRU Information Network Services Life is short. "Delaware has 1.1 million corporations -- I mean chickens." (sct)
windemut@lisboa.ks.uiuc.edu (Andreas Windemuth) (06/15/91)
In article <9106141908.AA25449@cheops.cis.ohio-state.edu> CCGREG@umcvmb.missouri.edu (Greg Johnson) writes: > > 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. > I don't think default read protection is a good idea. It leads to trouble with no end when you want to share data with others. No more "just get it from my home directory" if somebody wants some data from you. I have seen more than once huge amounts of time wasted when things didn't work because of some stupid read protection that nobody wanted anyway. Usually the Mailboxes are the only thing really requiring read protection from the beginning. -- Andreas Windemuth +-------------------------------------------------------------------- |Theoretical Biophysics windemut@lisboa.ks.uiuc.edu |University of Illinois Tel: (217)-244-1612 |3121 Beckman Institute Fax: (217)-244-8371 |405 N Mathews, Urbana, IL61801 NeXTmail Ok +--------------------------------------------------------------------
lemson@ux1.cso.uiuc.edu (David Lemson) (06/15/91)
First of all, I manage a lab of 22 NeXT workstations including 3 Color slabs, 3 030 Cubes and the rest 105MB Stations. I really appreciate your notes and have a bit to add. CCGREG@umcvmb.missouri.edu (Greg Johnson) writes: >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. Watch out that you have gobs of slab hard drive space available on NeXTStation Color machines. When a user opens up 20 1024x768x256 color GIF's at the same time, the /private/vm/swap file grows to around 50 MB. You can set in the /etc/swaptab guidelines for swapfile size, but the real way to get around the problem is to have more space available. In our lab, we have the luxury of not much serious work going on. Calculus courses taught on Mathematica (and we have a lot of them here) are taught exclusively on Mac II's in a different lab. Basically, our lab is for playing around with the NeXT. We also give free student UNIX accounts on another production machine, so we state in our user applications that users should not use the NeXT's for mail. Our mail has definitely been screwy. Mail mailed to a user at one of the station sometimes gets returned to sender, sometimes gets properly routed to the one NeXT designated (explicitly, in the sendmail.cf file) as mailhost. People setting up NeXT labs for student use should be prepared to stock all kinds of books about the DSP chips, for example. Our NeXT tech liasion has a set of these books, but we do not. I have had several requests for these references from Engineering students who want to use the DSP chip for various research. People say, "What are those NeXT's good for?" Some people answer "DSP." A large problem we have had is the server /Users drive getting full due to .snd and .gif/.tiff files. Sound files are huge, and people are bound to ftp them. (We have an external network connection, obviously). To tell the truth, I think that you might be happier without an external Internet connection if you've gotten along without it so far. Of course, it is nice to be able to do most all sys admin from home via dialup, of course. -- David Lemson University of Illinois Computing Services Consultant Internet : lemson@uiuc.edu UUCP :...!uiucuxc!uiucux1!lemson
eps@toaster.SFSU.EDU (Eric P. Scott) (06/15/91)
In article <9106141908.AA25449@cheops.cis.ohio-state.edu> Greg Johnson <CCGREG%UMCVMB.MISSOURI.EDU@OHSTVMA.ACS.OHIO-STATE.EDU> writes: > In fact, I am >running 20 NextStations (each 8MB RAM, 105 MB disk) Ugh! > There have been >occasional ethernet traffic jams Double ugh! Our NeXTs have to share their Ethernets with other (non-NeXT) people trying to do Real Work. If we put 8MB NetBoot clients on the wire the vigilantes would skin us alive... (By the same argument all my School's buildings are designated smoke- free; suicidal activity is merely discouraged, but homicidal activity is punishable.) >Our /users/1/ partition is further divided into "staff", "student", and >"visitor" subdirectories, under which come the actual user home directories. Here's where you've drifted away from technical considerations into political/religious ones. We find that segregating users (dare I say "apartheid") merely fuels antagonism and hostility. Hence, our NeXTs are set up to treat users as human beings! "Real Names" don't have titles associated with them, either. >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. We strongly disagree, except for e-mail and certain coursework. We instruct users to keep "confidential" material in protected subdirectories. In introductory courses, plagiarism is a consideration. In advanced courses, facilitating cooperation, team work, and information sharing is essential. >Preferences to set the file creation default permissions to allow access to >files only by the owner. We find this unacceptable. We create all home directories protected 755, and insist that permissions never be lower than 711. Otherwise many things (calendar, finger, inews, etc.) break. >You'll probably want to create some user groups to separate students, staff, >and administrative users. We call this approach "unclear on the concept." The purpose of groups is to provide users with ADDITIONAL access. Users who need access to licensed source code are added to an appropriate group. Students taking classes receive a group "cookie" for each class they're registered in. (There is another factor here too--it's hard to distinguish between students and staff when a lot of the system maintenance is done by students and the staff members are getting fee waivers to register for classes...) > We use >the student's birthdate as their initial password. We don't, it's too easy to obtain. >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 use Exabyte (8200). It's good enough for our needs. >(We don't even have an external network connection yet. When you do, I sincerely hope it's routed and not bridged. >Not all Unix thingies will know about NetInfo, so you should keep a passwd >file. We consider those "broken"--those thingies won't work with YP/NIS either. >vaguely recall that quotas weren't implemented under 1.0. Is anybody doing >disk quotas? Quotas are evil; they discourage users from learning how their greed impacts others. We're not here to parent users, we just provide a model electronic ecosystem. If they deplete their resources, they become extinct. A very simple concept... -=EPS=-
mmajka@next.com (Marc Majka) (06/20/91)
EPS writes: > Quotas are evil; [...] True, but a System Administrator is sometimes caught in the crossfire. Quotas may be a "necessary" evil. This thread reminded me that I wrote a disk space and printer page quota package which might be useful to those who need to be evil :-) I just cleaned it up a bit and put it up on cs.orst.edu, in pub/next/submissions/Quotas.tar.Z, and on cs.ubc.ca, in next/ubc/Quotas.tar.Z on cs.ubc.ca. I could not connect with purdue, so I'll try puting it over there later. *Disclaimer* This stuff was written when I worked for the University of British Columbia, and it did what it needed to do. It is not a product of, nor supported by NeXT. Feel free to cut it up, use any parts you want, and pass it around. Nutshell description: Users have new NetInfo Properties (pageusage, pagequota, diskquota). Page quotas do NOT work on NeXT printers. /usr/lib/transcript/psif updates NetInfo. A "du" based disk usage checker gets run by cron at 4am. Users over disk quota, or low on space get mailed a message. Chronic over-quota users get a * in their password after a while. A "Quotas" App allows users to inspect their own usage and quotas, and permits managers to change them. I forget if I put it in the package, but I ran a program that did "du -s ~ > ~/.diskusage" from LogoutHook. The Quotas App uses that value if it exists (and is faster!). As an added bonus, you get an App called PrinterQueue, which watches a printer queue. It is much like PrintManager's "Queue", but it lists jobs they you own in bold and doesn't permit reconfiguration of the printer. If you are interested, grab a copy and *read* the README.wn file. Installation requires some knowledge. --- Marc Majka, Speaking for Himself