wedgingt@udenva.UUCP (Will Edgington/Ejeo) (01/14/87)
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@DUCAIR ( BITNET ) WEDGINGT@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@udenva.UUCP (Will Edgington/Ejeo) Newsgroups: net.unix,net.unix-wizards,net.decus Subject: Re: Automatic unattended execution of 'dump' ? Message-ID: <1993@udenva.UUCP> Date: 24 Sep 86 16:52:11 GMT Date-Received: 24 Sep 86 16:52:11 GMT References: <128@morgoth.UUCP> <3528@umcp-cs.UUCP> Reply-To: wedgingt@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.