[net.decus] Automatic unattended execution of 'dump' ?

glidden@morgoth.UUCP (Ken A. Glidden) (09/13/86)

  We have a uVAX II running Ultrix 1.2.  I'd like very much to use
the crontab to start up a shell script late at night to perform 
a dump.   Specifically I'd like the shell script to "simulate"
single user mode by preventing any logins, killing any processes which
have the potential to alter the disk during the dump, and preventing 
any processes which may alter the disk during the dump from starting
while the dump is in progress.  Once finish the script should undo all
its protections and allow business as usual.

  I haven't had too much luck yet.

  Before I press on I'd like to ask, "ANYONE ALREADY DONE THIS?"
"DOES ANYONE KNOW OF A REASON I SHOULDN'T DO IT THIS WAY?"

--Ken

mjranum@gouldsd.UUCP (Marcus J. Ranum) (09/14/86)

In article <128@morgoth.UUCP>, glidden@morgoth.UUCP (Ken A. Glidden) writes:
> 
>   We have a uVAX II running Ultrix 1.2.  I'd like very much to use
> the crontab to start up a shell script late at night to perform 
> a dump.   Specifically I'd like the shell script to "simulate"
> single user mode by preventing any logins, killing any processes which
> have the potential to alter the disk during the dump, and preventing 
> any processes which may alter the disk during the dump from starting
> while the dump is in progress.  Once finish the script should undo all
> its protections and allow business as usual.

	Um, how about something cheesy like this: 
1)create /etc/nologin.
2)log out your users (for a in `ps -ag | sed /root/d | awk print{$1} `;do
	kill -9 $a; done     or something equally sleazy
3)run dump
4)remove /etc/nologin
5)voila
	to prevent crontab processes from fiddling with the disks, make
sure your crontab is corretly tuned.

  I have a set of shell scripts that do this in a rather more sophisticated
manner, but I can't send 'em to you.  You might want to trap exit statuses,
and print results, etc, etc...   Since you have a relatively small system,
really think the best way to solve your problem is to just do everything in
a simple shell script.

Live Free
mjr
-- 
 
I raised my knife to it:
Some fresh young morning-glory
As we too, alas...

chris@umcp-cs.UUCP (Chris Torek) (09/22/86)

In article <128@morgoth.UUCP> glidden@morgoth.UUCP (Ken A. Glidden) writes:
>  We have a uVAX II running Ultrix 1.2.  I'd like very much to use
>the crontab to start up a shell script late at night to perform 
>a dump.   Specifically I'd like the shell script to "simulate"
>single user mode by preventing any logins, killing any processes which
>have the potential to alter the disk during the dump, and preventing 
>any processes which may alter the disk during the dump from starting
>while the dump is in progress.  Once finish the script should undo all
>its protections and allow business as usual.

Unfortunately, just about every process might alter the disk.  About
the only way to do this would be to kill everything, then start only
trusted processes.  Indeed, the easiest way to do this would be to
run shutdown.

If your root shell is /bin/sh, you could then put this in /.profile:

	PATH=/bin:/etc; export PATH
	if [ -f /etc/autodump ]; then
		sh /etc/autodump
		rm -f /etc/autodump
		exit 0
	fi
	# rest of /.profile

For /bin/csh, use

	set path = (/bin /etc)
	if (-f /etc/autodump) then
		sh /etc/autodump
		rm -f /etc/autodump
		exit 0
	endif
	# rest of /.cshrc

You can then have cron copy a script to /etc/autodump and run
shutdown.  When the machine goes to single user mode, the shell
will read .profile or .cshrc and run autodump, then remove the
script and exit, bringing the machine back up in multi-user mode.

This, like all unattended dump schemes, can run into one problem:
Dumps do not always succeed.  If the dump fails, dump will attempt
to get help; this too will fail, and I am not certain just what
will happen after that.  It should be easy enough to find out: just
leave the tape drive off line and force a run.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu

wedgingt@udenva.UUCP (Will Edgington/Ejeo) (09/24/86)

In article <3528@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes:
>If your root shell is /bin/sh, you could then put this in /.profile:
>
>	PATH=/bin:/etc; export PATH
>	if [ -f /etc/autodump ]; then
>		sh /etc/autodump
>		rm -f /etc/autodump
>		exit 0
>	fi
>	# rest of /.profile
>
>For /bin/csh, use
>
>	set path = (/bin /etc)
>	if (-f /etc/autodump) then
>		sh /etc/autodump
>		rm -f /etc/autodump
>		exit 0
>	endif
>	# rest of /.cshrc

  Both the 'exit 0's above want to be 'kill $$'s instead.  Exit called
in either a .profile, a .cshrc, or a .login will merely exit the file
and continue the regular interactive shell, waiting for input from the
terminal (in this case, the console).  I use this 'feature' of exit in
my .cshrc and .login to avoid running them if I answer 'no' to a prompt
my .cshrc gives.
  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.
-- 
------------------------------------------------------------------------
|"Input!"|"Number 5 is Alive!!"|"Beautiful software"|"Not disassemble!!"
------------------------------------------------------------------------
Will Edgington|Computing and Information Resources, University of Denver
(303) 871-2081|BusAd 469, 2020 S. Race, Denver CO 80208 (work)|"Input!!"
(303) 759-9071|5001 E. Iliff, Denver CO 80222 (home)|"Where's Input?!!?"
{{hplabs,seismo}!hao,ucbvax!nbires,boulder,cires,cisden}!udenva!wedgingt
COMING SOON: wedgingt@eos.cair.du.edu, wedgingt@eos.BITNET ( == udenva )

braun@drivax.UUCP (Karl T. Braun (kral)) (09/27/86)

In article <1993@udenva.UUCP> wedgingt@udenva.UUCP (Will Edgington/Ejeo) 
writes:

...
>  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.  
...
>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.
>-- 
>------------------------------------------------------------------------
>|"Input!"|"Number 5 is Alive!!"|"Beautiful software"|"Not disassemble!!"
>------------------------------------------------------------------------
>Will Edgington|Computing and Information Resources, University of Denver
>(303) 871-2081|BusAd 469, 2020 S. Race, Denver CO 80208 (work)|"Input!!"
>(303) 759-9071|5001 E. Iliff, Denver CO 80222 (home)|"Where's Input?!!?"
>{{hplabs,seismo}!hao,ucbvax!nbires,boulder,cires,cisden}!udenva!wedgingt


I tried to mail, but neither the mailer nor myself could quite make out
the address.  I am interested in the script, and I'm sure I'm not the
only one.  Thanx in advance for anything you may send or post.



-- 
-- 
			  kral
		      408/646-6112
		...!{amdahl,ihnp4}!drivax!braun
-----
The opinions expressed here are my own, and do not necessarily reflect the 
opinions of my employers, my country, the minor deities from the Halls of
Asgaard, or the great Prophet Zarquon.
----