Automatic Execution of Dump, Backup, Tar, Cpio, etc.

[Will Edgington/Ejeo]

Once upon a time, in several newsgroups far, far away, I replied to an article
with a similar title to this one's (I still have that article, even).  At the
time, I offered to mail (or post, if sufficient requests arrived, and they
did!!) the sources to my group's solution to the automatically-perform-dumps-
even-if-the-operators-don't-know-Unix problem.  Since the best description of
the scheme is still that article, most of it is repeated after my signature.

Needless to say, I was overwhelmed with requests; I'm still getting them now
and then.  Unfortunately, we have had all sorts of delays in getting BSD 4.3
up, which I was going to do before cleaning up the various pieces of code and
shell scripts that are involved (as I promised to do before posting; I wouldn't
inflict this code on my worst enemy :-).  Since I'm sure many of you out there
are wondering what happened and where things are, I'm posting this (that's
right; it's not in here either; sorry).

With BSD 4.3 w/ NFS from Mt. Xinu just installed on our brand new MicroVax II
and USENIX (which I am attending again) coming up Real Soon Now, this is to
inform all of you out there to be on the lookout for the code in question.
Anyone who wants to talk with me about it should either see me during USENIX
(there will almost certainly be another Backup BOF session) and/or send me
mail (see my signature for the many addresses I can be reached at).  Since
I have not actually started cleaning up the code yet, I am also open to
suggestions as to portability to System V, enhancements, security
considerations, etc.

Followups, which I probably won't see before USENIX, have been directed to
comp.sources.d.
-----
Will Edgington, Computing and Information Resources, University of Denver
		BusAd 469, 2020 S. Race, Denver CO 80208, (303) 871-2081
	hplabs! hao!    udenva!wedgingt  /                  \
	seismo!/       /                ( USENET, UUCP, etc. )
	ucbvax!nbires!/                  \                  /

	WEDGINGT at DUCAIR			( BITNET )
	WEDGINGT at UDENVER		( CSNET )

Yes, it's a mess, but udenva is BSD 4.2, DUCAIR is VMS 4.4, and
	UDENVER is Pyramid's OSx ...
----
From: wedgingt at udenva.UUCP (Will Edgington/Ejeo)
Newsgroups: net.unix,net.unix-wizards,net.decus
Subject: Re: Automatic unattended execution of 'dump' ?
Message-ID: <1993 at udenva.UUCP>
Date: 24 Sep 86 16:52:11 GMT
Date-Received: 24 Sep 86 16:52:11 GMT
References: <128 at morgoth.UUCP> <3528 at umcp-cs.UUCP>
Reply-To: wedgingt at udenva.UUCP (Will Edgington/Ejeo)
Organization: U of Denver
Lines: 64
Xref: udenva net.unix:6973 net.unix-wizards:10839 net.decus:397

  We do dumps 'auotmatically' by telling our operators to pick a certain
choice on their menu (they log in as UID 0, but into a *very* restricted
shell), which runs shutdown after echoing 'backup' into a certain file.
Then, in /.profile, we have a test of the contents of that file; if it
is 'backup', it runs a shell script '/etc/local/backup' which tells the
operators which tape(s) to mount before it starts /etc/dump, the output
of which is redirected using tee to both the console and /tmp/dump.out
(or some such).  /bin/awk is then used to see if the dump failed by
checking for 'DUMP IS DONE' in /tmp/dump.out.  If it failed, it's redone
via a goto in /etc/local/backup; if not, the awk script enters a line in
/etc/local/dump.inv(entory) listing the file system, mount point, number
of tapes required, the date from /etc/dumpdates (or where ever /etc/dump
puts it), the label(s) put on the outside of the tape, etc.  After the
dumps are done, /etc/local/backup exits, returning control to /.profile.
If it exited 0, /.profile assumes the dump(s) worked and does a 'kill -9 $$'
(which is probably excessive, but you don't want it to fail ...).  If
/etc/local/backup exits other than 0, /.profile echos 'Backup failed; leave
machine down and call so and so at 8am.' to the console.  Thus, the operators
know exactly what to do at every step and *they never see Unix directly*, so
we don't have to train them in it.
  I am about to totally rewrite our /etc/local/backup to be more generic about
which disks are backed up and how often, whether or not it's over the ether-
net using rdump, etc., or I would post it.  Anyone who wants any of the
programs described above should send me mail; if I get enough requests, I'll
post everything when I get it in decent shape.  Note that it is (and will be)
only dependent on /etc/dump in a very small section of /etc/local/backup; if
you System V people want to use it with cpio(1) or tar(1), it should be
fairly easy.