In test mode the command that is used to schedule a reboot is:
echo '--**--**--'; echo '/sbin/shutdown -r +5'|batch; sh /etc/tmp/firewall.fw && echo 'Policy activated' '
Most of the devices that I use as firewalls are embedded devices. and don't support either the "shutdown" or "batch" commands. It would be great is it was possible to specify my own script that I could use to schedule a reboot.
I dont think that one set of commands would work for all devices. So allowing the use of two options to reboot the router would be good option (1) the schedule the reboot and (2) to cancel the reboot
The installer would first SSH to schedule the schedule specified reboot command.
Then SSH to copy and run the fw script.
The pause, and SSH again to cancel the reboot.
If you can perform the last SSH, no matter what is wrong with your script you can still SSH to fix it
If you cant perform the last SSH then the reboot will take effect an let you back in.
This is how I remember it working a year ago. However the new reboot command doesn't work for all, and it doesn't appear that any attempt is made to cancel the scheduled restart
Cheers
Logged In: YES
user_id=1622939
Originator: YES
This could be enhanced further.
When the installer SSH's in the last time to terminate the scheduled reboot. It could also copy the fw script to the correct location.
Since by SSHing back to the device, we have proven that we are still able to administer it after the update.
This way. Test mode could be used permanently..
Logged In: YES
user_id=6825
Originator: NO
good ideas, thanks.
Currently reboot is cancelled when you install and activate policy in a non-test mode. That is the sequence is 1) install in test mode, reboot is scheduled, 2) if all is ok, install again with test mode off. This will cancel reboot.
I agree that it would be useful if user could supply their own schedule reboot and cancel reboot commands. I want to move all commands used by installer to little scripts, each operation should be in a separate file. Right now these commands are in one large XML file which is hard to maintain and cetainly not very suitable for editing by the user. I plan to do this in the next major release. Once this is done, it should also be possible for the user to write their own replacement scripts.