On Mon, Jul 28, 2008 at 10:30:41AM +0100, Charlie Clark wrote:
> Almir Karic wrote:
>
>> diff of a loaded ruleset is not that useful (for humans) IMHO, a better
>> way would be to diff the ruleset (possibly excluding the comments and
>> spaces etc). even better way to do that would be to JustDoIt (no diff
>> checking whatsoever, and let the admins reload the rule when they commit
>> any changes to it.
>>
> With no diff it would mean that if the admin loaded a ruleset which locked
> him/her out, they would have to go to the box and change the rules, not
> ideal if you have alot of boxes scattered over distances.
> And if we diff'ed the ruleset, how could you be sure that the ruleset was
> loaded correctly, which means that the file it creates to compare newly
> loaded rulesets against might not have been the currently running config
Come on people.
If your admins lock themselves out, they shouldn't have been typing on
the machine in the first place. Accidents do happen, so surely you
have OOB access (serial console, anyone ?). Then, if this is still
such a big issue, you can write some scripts that will give you
something along the lines of Junipers 'commit confirmed' .. you first
enable a ruleset which will be automatically reverted in 5 or 10 (or
however many you like) minutes. Then, if you don't lock yourself out,
and your changes look good, you stop the revert from happening (ie,
you 'commit confirmed').
Think about your scenario and solve it your own way. The tools (and
the documentation) are all there.
I wonder .. what would you do if that same admin that locked himself
out did an accidental halt or rm -rf / ? Surely you have a means to
fix that ? Why is the firewall so special ?
Short story : don't break stuff - but prepare for when you do.
Cheers,
Paul 'WEiRD' de Weerd
--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
