* Peter van den Heuvel wrote on Sat, Apr 28, 2001 at 10:07 +0200:
echo "You have one minute to show you are still effectively connected by hitting ^C." echo "If you do not kill this script within one minute the machine will reboot."
I don't think that this is reliable. If the shell dies by some reason, which might be forced by SSH (sometimes bad Networkpacket may close an SSH connection), the script gets interrupted. To schedule a reboot, you may use "shutdown -r +1m". After restarting firewall, use "shutdown -c". This may cause confusion on non-dedicated firewalls where users are logged in. Aother thing is to improve the shell script a little. I played with this idea quite a while, but I found not time to implement it. The idea: The first action of the firewall script is to launch a subprocess. This should run "nohup" in an own session like: ( nohup setsid $WATCHER_SCRIPT 2>&1 | logger $LOGPARA ) & After that, the firewall script starts. On error, the firewall script dies which need to be deteted by WATCHER_SCRIPT. In this case the WATCHER inserts an "allow-SSH" rule with highest precedence into ipchains (ipchains -I $SSH_RULE) or similar. On success, the firewall script ends, too. The WATCHER needs to detect this, too. In this case, an SSH access test may be performed (ipchains -C $SSH_SOURCE -D any:22 -i ...). If that fails, a SSH_RULE become inserted. A better way is to automatizise the firewall restart more completly by remote, like: set +e ssh $HOST $FIREWALL_START ssh $HOST $FIREWALL_WATCHERKILL In this case the firewall lauches a WATCHER_SCRIPT like in the first example. The WATCHER waits 2 minutes and insertes a SSH_RULE under all cirumstances (nearly :)). The second script (or even just a command line) can get excuted only if the firewall_start succeeded and a second SSH connect works (still). The WATCHER_KILL sends a signal to the WATCHER, i.e. killall -INT $WACTHER_SCRIPT The WATCHER_SCRIPT catches this signal. The it looks for running instances of FIREWALL_START to avoid race conditions. If FIREWALL_START timed out (maybe 1 minute), it gets a TERM and 10 secs later a KILL. In this case an SSH_RULE gets inserted and an error gets reportet in some way. If WATCHER_SCRIPT sees that there are no running instances of FIREWALL_SCRIPT (normal case), it has nothing to do: SSH is working, otherwise it hadn't even started. WATCHER_SCRIPT does exit 0. I would like to hear some comments about this. I think this is not difficult to implement, seems to be reliable even on breaking network conenctions (like "network unreachble" which might stop a script which waits for CTRL-C or so). Did I miss some conditions? Is anyone interested to do such a thing together with me (as open source)? oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.