[ previous ] [ next ] [ threads ]
 From:  William Arlofski <waa dash m0n0wall at revpol dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Cc:  Manuel Kasper <mk at neon1 dot net>
 Subject:  "Safety" feature request
 Date:  Mon, 31 Oct 2005 10:19:14 -0500
Manuel, while driving home late last night I occured to me that I may
have an idea that would save people like myself who have fat-fingered a
client's config.xml file and uploaded it to their server.

The result was that the WRAP never came back up and I actually had to
walk my client through opening it up pulling the cf card, plugging it
into a CF reader/writer on a machine that I had remote access to so that
I could write a default image and then upload a good config.

Now, while I realize that this was completely my fault - I missed a
</rule> tage or something similarly simplistic, it would be nice to have
a safety in place to prevent this type of interaction with a customer,
or a long drive to a remote site.

Here's my thought:  On upload of a config file have m0n0wall vailidate
it on the spot. If it is invalid, ignore it and warn the user that file
is invalid/corrupt/not acceptable.

Alternatively, have m0n0wall check its validity when loading it after a
restart. If it is corrupt or invalid, m0n0wall could load the LAST
good/working config file.

As an addition to either of the above possibilities, one other thing
crossed my mind. What if on config upload, the user is required to click
a "config is OK" button on the main Status --> System page within a
specified time to accept the new configuration otherwise m0n0wall would
reload the LAST good/working config file.

As you probably know, XML is hard on the eyes and easy to mess up, but
when a client has several subnets and many requirements for rules, it is
much faster to use vi to modify rulesets than it is to do via web
browser one rule at a time, and this is where errors can quickly be

I wonder (have not googled yet) if there is a simple, command line XML
"lint" tool to validate a config.xml before uploading it... Heh, that
might even be a quick solution.

Thanks for listening.

Bill Arlofski