[mod.unix] Unix Technical Digest V1 #49

netnews@wnuxb.UUCP (Heiby) (04/28/85)

Unix Technical Digest       Sat, 27 Apr 85       Volume  1 : Issue  49

Today's Topics:
                  Computer Technology Group classes
                        dump reminder service
                     File system limit in 4.2 BSD
               Limit to number of file structures... ?
             Non-root (assistant) System Admins (2 msgs)
----------------------------------------------------------------------

Date: Tue, 2 Apr 85 10:50:56 cst
From: ihnp4!gargoyle!sphinx!west (Steve Westfall)
Subject: Computer Technology Group classes

Ken,

I took a C programming course last spring from CTG.  It was taught
by Mark Pearson, author of the Viewcomp spreadsheet, who has been
a C programmer for about 10 years, and it was excellent.  I came
back from it and wrote a major applications program for my
employer interfacing with the Informix dbms.  I am sure that the
quality would depend on the instructor, and this is the only class
I took, but it was great.  The course assumed that you already had
programming experience in another language, of course; it definitely
was not for beginning programmers.

My only gripe was that CTG provided these little, TINY, terminals
(about half the size of a Macintosh!) with a small screen and a
keyboard so small that half the time you couldn't help hitting
two keys instead of the one you wanted.  On top of that, each
terminal was shared by two persons.

So, in summary, the creature-comforts might have been better,
but the quality of instruction was great.

Steve Westfall
Staff Analyst
U. Chicago Computation Center
...ihnp4!gargoyle!sphinx!west

------------------------------

Date: Fri, 29 Mar 85 13:26:59 est
From: allegra!phri!roy (Roy Smith)
Subject: dump reminder service

	The 4.2 installation guide suggest that operators run "dump w"
from their .login files to remind them what dumps to do.  We did that
for a while here, but found that it added another few seconds to the
already long login process.  As a solution, we run the following shell
script out of crontab in the middle of the night.  If dumps get missed,
all the operators automatically get hate mail the next morning.

	This works on our 4.2 11/750 system, but depends on the format
of the dump output being what it is.  If your "dump W" command produces
output in a different format, you will have to play with the grep/sed
stuff to get it to work.

|  #!/bin/csh
|  set operators = (roy reisberg)
|  set tempdir = /tmp
|  
|  dump W | grep "^>" > $tempdir/dm$$a
|  set x = `wc -c $tempdir/dm$$a | sed "s/ \([0-9][0-9]*\) .*/\1/"`
|  if ($x != 0) then
|  	echo "the following file system dump(s) are overdue" > $tempdir/dm$$b
|  	cat $tempdir/dm$$a >> $tempdir/dm$$b
|  	mail -s "file system backups" $operators < $tempdir/dm$$b
|  endif
|  
|  rm -f $tempdir/dm$$[ab]

cmcl2!rocky2!cubsvax -\
       vax135!timeinc -> !phri!roy (Roy Smith, System Administrator)
             allegra -/

------------------------------

Date: Wed, 3 Apr 85 23:04:31 est
From: seismo!hadron!jsdy (Joseph S. D. Yao)
Subject: File system limit in 4.2 BSD

I have trouble believing that the core-dump problem is due to a limit
on the number of mountable devices!
First suggestion:  check internal consistency of the following:
	disk partitions
	fstab
	compiled-in swap devices.
Pay particular attention to devices not in fstab in your smaller
configuration.  Check for a "sw" device in fstab that is also
either a mounted device (!) or part of a mounted device.  Then, if
you find anything, check for file system corruption.  Let me know
whether or not you find anything, and/or what you find.

	Joe Yao		hadron!jsdy@seismo.{ARPA,UUCP}

------------------------------

Date: Wed, 3 Apr 85 22:36:21 est
From: seismo!hadron!jsdy (Joseph S. D. Yao)
Subject: Limit to number of file structures... ?

> [Ed note: In some Unix systems, the number of mountable file systems is
> a tunable parameter (e.g. AT&T 3B2 SVR2).  RWH.]

In all source versions this is a tunable parameter.  I'd be surprised
to find it tunable in any binary version.

	Joe Yao		hadron!jsdy@seismo.{ARPA,UUCP}

[Ed note: Sorry I didn't make myself clear.  The AT&T 3B2 SVR2 *is*
a binary release.  There are lots of tunable parameters that can be
adjusted, including file buffers, max process memory, max procs in
system, max procs per user, etc.  All done with no source.  RWH.]

------------------------------

Date: Fri, 22 Mar 85 00:25:28 est
From: seismo!hadron!jsdy (Joseph S. D. Yao)
Subject: Non-root (assistant) System Admins

> Has anybody else looked at the potential protections afforded by
> having as little as possible owned by root, &, therefore, less risk if
> a user does get back his own shell with uid set?

I've tried to make the managers of every system I've worked on aware
that, not only is this a good idea, it is almost essential, for exactly
the reasons that jhull and RWH mentioned.  Because a few of us do on
occasion malke misteaks, the amount of time that anyone should be
super-user should be absolutely minimised.  One very quick corollary
is that there is   n o   excuse for any file to be owned by root,
save those few that must be setuid-root.  Even many of these may be
made setuid-someone else: e.g., make /etc/passwd owned by bin, and
setuid to  b i n  the programs /bin/passwd, /usr/ucb/chfn, and
/usr/ucb/chsh!  Works just as well, maybe better.  (Especially after
you re-write chfn!)

	Joe Yao		hadron!jsdy@seismo.{ARPA,UUCP}

------------------------------

Date: Fri, 22 Mar 85 10:46:36 est
From: ihnp4!encore!ptw (P. Tucker Withington)
Subject: Non-root (assistant) System Admins

Back in v6 days, I had an account "bin" that owned all the sources (don't
remember if this was a local idea (at MITRE) or just how it came from Bell
Labs).  Folks could play with recompiling and massaging sources without being
root.  You only became root to "install" something, once you had supposedly
fully debugged it.

Under 4.2 I have a group "bin" that works the same and anyone who is a sysadmin
is allowed in that group.  Then all you have to do is get everyone to use a
umask of 002 rather than 022.  On plus with this is that the "owner" of the file
now also identifies the last sysadmin to munge it (so you know where to go when
it breaks).  This setup, plus using SCCS or RCS for all sources greatly reduces
the number of "oops" that root makes.

One last thing that is definitely not in the spirit of Unix, but I'm sure many
folks either do or wish they did is to have a library version of link/unlink
(and open, creat, rename, etc.) that doesn't *really* delete files.  There
being no standard for this, I have had some vehement arguments about what to
do with the "not-quite-deleted" file.  My personal preference is to rename it
with a ".," prefix in the same directory (with appropriate checking for
conflicts) and to purge them as soon as they are dumped.

                               o.o      --tucker
                                ~

------------------------------

End of Unix Technical Digest
******************************
-- 
Ronald W. Heiby / netnews@wnuxb.UUCP | unix-request@cbosgd.UUCP
AT&T Information Systems, Inc., Lisle, IL  (CU-D21)