Bringing up a new system: summary

From: kovar%popvax@harvard.harvard.edu
Date: Thu May 03 1990 - 08:00:49 CDT


  Many thanks to all who replied, and to those who tried to reply
but couldn't get through. Our gateway decided to have it's disk for
lunch last week and I suspect some mail fell on the floor.

  In any case, I asked for tips on what I should be concerned with
when I brought up a new system. I've included the responses below. I'm
going to end up using the following:

1) Unix Systems Administration Handbook - Very comprehensive. It covers
   just about anything you ever wanted to know and is a very good investment.

2) Berkeley System Manager's Toolkit - A collection of scripts and other
   tools for maintaining systems. I've been using pieces of V1.0 for
   quite some time on a network of Sun 386is. V2.0 will hopefully be out
   in a month or so and will support distributed systems more cleanly.

3) COPS - (Can't remember what it stands for.) - Useful for periodic
   security checks. Don't assume that you're secure if it gives you a
   clean bill of health, and make sure you secure it somehow (ie, don't
   let someone modify it to ignore a certain hole), but it provides a
   good base to work from.

4) SNMP - Simple Network Management Protocol - Very useful for managing
   network devices, like gateways. You can also use it on just about
   anything else that has a network connection. I picked up a copy from
   MIT and another from CMU. They're very experimental so this'll be
   something that gets added in as I get time.

5) Log book - Just a normal notebook for recording modifications, errors,
   and the like. It really helps to refresh your memory when something
   fails and you're trying to remember what you modified last week that
   might have caused it.

6) sa - Unix utility. I've got to cook up some scripts for massaging the
   output into something presentable, but it's good stuff.

7) supersaver - Backup utility for Exabytes that allows many machines on
   a network to automatically backup to an Exabyte. ics.uci.edu (128.195.1.1)

  I'm sure other things will appear, but this gives me a framework to
start with.

-David C. Kovar
        Consultant ARPA: kovar@popvax.harvard.edu
        Eclectic Associates BITNET: corwin@harvarda.bitnet
        Ma Bell: 617-643-3373 MacNET: DKovar

         "It is easier to get forgiveness than permission."
[All opinions expressed are my own. Noone else assumes responsibility for me.]

And now the replies....

----------
From: mjk@mayo.EDU (Mark Korinek)

In response to your use of an Exabyte drive, I am currently in charge of
backing up between 7 and 8 Gig of data across multiple architectures
(Sun, SGI, Masscomp, etc) and we are using a Delta drive (Exabyte) with
drivers and specialized software to take care of backups overnight and
automatically (maybe semi-automatically).

This has been an excellent choice for us and I would recommend it if you
still have the option to buy the drive. The utilities they offer are
well worth the money.

Contact: Delta Microsystems
         Peripheral Devices
         215-640-0446
----------
From: "Peter L. Wargo" <wargopl@sun.soe.clarkson.edu>

The "sa" - system accounting command in the Sun OS has many, many neat things
to play with (if you haven't already noticed...). I use it to track cpu/user
usage on a regular basis...
----------
Jeffrey R. Tunison <tunison@brazos.rice.edu>

Since you are bringing this system up from scratch, you might want to
think about a software layout scheme we have been developing here.
Motivation is keeping local changes out of /usr, SunOS's home partition.
One can then gut /usr (say, for an operating system upgrade) without
having to track down the local changes off of a set of dump tapes. (This
gets old pretty fast and you are forever breaking some researcher's
favorite tool because you missed a link somewhere.)

Each of our servers has a partition set aside for user data. This is
named /server. Each of our servers also has a partition set aside for
local applications. That is named /server2.

We have a few links in /usr pointing at /server2 that move constant
changes to /server2. For example:

/usr/local -> /server2/local
/usr/man/local -> /server2/man OR /usr/man/manl -> /server2/man
/usr/src -> /server2/src

We also have some local software installation conventions that are
of great assistance to us in managing our dozen or so file servers,
but you may not want to get into them for just one machine. I am
writing them up in a latex document for my group to use, and I'd
be happy to send a draft to you if you'd like.
----------
From: selig%wizard%xanth.msfc.nasa.gov@Fedex.Msfc.Nasa.Gov (Bill Selig)

I have some account management scripts that I use for setting up
and removing accounts. Also for disbaling and reenabling them. At some
point I decided the structure of things and then embedded it in the scripts.
To add a user, all I do is enter the line in /etc/passwd and the script
takes it from there setting up the directories, including the name in
/ets/group and other things. The remove user script takes it all away.

Our usage here is not a large group of students in/out all the time, so
I don't know how these scripts would deal with volume. You would probably
want to change some stuff. If you would like to see them, I'll send a compy.
Just let me know.
----------
From: keener@upenn5.hep.upenn.edu (Paul T. Keener)

I found that most shell scripts and the like to be insufficient for account
creation. This is partly because I do not completely trust them. When I
started using the hesiod server the the Computer and Information Science
department setup, I wrote a C program to add userids. At this point, it
is a very simple program that call a routine that gets/creates a hesiod
entry on the server. It then asks a bunch of questions about the users
home directory, preferred shell, etc. It then adds the record to /etc/passwd
and makes a log of who created the userid, the userid itself, and the date
of creation. The program was designed to be run setiud so that trusted
users (as determined by looking in a file) can run the program without
knowing the root password.

This program can easily be modified to add whatever features you desire.
If you want I can send you the program (except for the hesiod interface,
as I did not write that).

        -paul

PS Please mail a summary of your findings to the list. Thanx.

----------

From: stevej@Synopsys.COM (Steven Jukoff)

See "Unix System Administration Handbook" by Nemeth, Snyder, Seebass
published by Prentice Hall

----------
From: cpaloma@UCSD.EDU

Hi David,

I'm a system manager at UCSD in the Computer Science Department. The
machines I administer are for the use of CSE faculty, staff, grad students,
and researchers. The environment consists mostly of Suns, but there
is also a VAX, a CCI, a Celerity, Macs, PCs, etc.

 1) What information should be logged? We'd like to be able to track
    application use, disk use, cpu use, etc over a long period of time.
    This helps justify various things to the bean counters, among other
    things. Should all this be kept on disk? Are there good report formats
    for producing daily, weekly, and monthly logs?

Sorry, we don't count beans.

 2) What sort of automatic procedures should be used to insure the health
    of the system? I currently use "watch" one on set of Sun 386is to keep
    an eye on it as I'm rarely on site. What other tools are available
    for doing this? What sorts of things should be checked? Disk quotas,
    failed login attempts, long running jobs, etc.

We have a script run out of cron which checks disk quotas on the file
server nightly, and sends mail to the user and to the system folks
(csehelp) when the quota is exceeded. The quotawarn script is included
in the end of this message.

The COPS program is helpful for finding holes in system security.

 3) We're geting an Exabyte with it. I, of course, didn't save any of the
    pointers to software to use it because I never expected to have one.
    We're going to need to back up the 390 and a number of other workstations
    and would like to automate it as much as possible. Any pointers on how
    best to do this?

We bought a Exabyte from APUNIX. Drivers and software for doing multiple
dumps per exabyte tape (for multiple filesystems and network backup) is
provided with the hardware. Peter Behrens is very helpful.

 4) Account management software and policy is always a fun one. We'll have
    three distinct groups of people: staff, students, and researchers.
    We'd like to simplify the management of accounts, be able to track
    creation, deletion, and the like. I know about, but lost the address
    for, the system managers toolkit from Berkeley. (I think.) Any other
    good, comprehensive packages? I'd prefer not to put together a lot
    of small pieces into a management mess.

We have different groups of users: faculty, staff, grad students,
guests, other system administrators, researchers, non CSE grads taking
CSE grad courses. We whipped up a script for automatic account
addition, but it is pretty site specific. The Berkeley System
Managers Toolkit info:

        Campus Software Office
        2320 Shattuck Ave Suite B
        University of California
        Berkeley, CA 94704
        (415) 643-7201
        hleung@garnet.berkeley.edu

        Price: License Agreement required. The fee is:

        End User license: Single user machine $300
        Site license: Non-networked multi-user machine $550
        Site license: Networked multi-user machine $750

 Any other pointers on managing systems would be welcome. (Talking about
 opening a can of worms!) As I said, I've done this for awhile but I think
 it's time to do it a bit more systematically this time.

You might want to take a look at the Unix System Administration
Handbook by Evi Nemeth for more ideas.

 Many thanks, in advance.

No problem!

Cindy Paloma
cpaloma@ucsd.edu (Internet)
cpaloma@ucsd (BITnet)

-----
#! /bin/sh
# This script is to be run periodically on each NFS server to check for
# over-quota users and send them mail so that they will know they are
# over-quota.

PATH="/bin:/usr/bin:/usr/ucb:/etc:/usr/etc"
export PATH
umask 077
tempfile=/tmp/qw.$$
host=`hostname`
filesystems=`mount | awk '$NF ~ /quota/ {print $3}'`

if [ "x$filesystems" != x ]
then
        for fs in $filesystems
        do
                repquota $fs | awk 'NR > 2 && $2 ~ /\+/ {print $1}'
        done | sort -u > $tempfile

        for name in `cat $tempfile`
        do
                case $name in
                \#*)
                        name=`echo $name | sed 's/#//'`
                        quota -v $name | /usr/ucb/mail -s "UID $name (no account) is over-quota on $host" csehelp
                        ;;
                *)
                        quota -v $name | sed '1i\
~c csehelp' | /usr/ucb/mail -s "Warning: You are over-quota on $host" $name
                        ;;
                esac
        done

        /bin/rm -f $tempfile
fi



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:57 CDT