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
per@erix.UUCP (Per Hedeland) (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 >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. Actually, you will find that the shell does not *exit* when encountering 'exit' in .profile or .cshrc, it merely starts reading from the terminal. Replacing 'rm -f ...' with 'exec rm -f ...' will have the desired effect. (This is on 4.2, which ought to be relevant since the question was on Ultrix.) >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 4.2, dump will ask for the help from /dev/tty (and keep asking forever(?), hanging the system in single user). If /dev/tty can't be opened, dump just quits - i.e. running dump from a little program that takes away the controlling terminal (via TIOCNOTTY) is a good idea. We have used essentially this scheme for a long time; it works fine (although there are a couple of additional minor details to consider). ---- Per Hedeland {seismo,mcvax}!enea!erix!per or per@erix.uucp
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. ----