[ previous ] [ next ] [ threads ]
 From:  Adam Nellemann <adam at nellemann dot nu>
 To:  EXT dash Mike dot Bradshaw at nokia dot com
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] A few GUI related suggestions
 Date:  Thu, 04 Mar 2004 23:01:07 +0100

Thanks for the feedback Mike and Joachim! My comments are below:

EXT dash Mike dot Bradshaw at nokia dot com wrote:
> How about writing something in Perl? I have only briefly played 
> with the LWP package (and i am a real beginner in Perl Hacking), 
> but it did what i needed in a few lines.
> Only downside i can see is if Manuel changes the HTML that is 
> produced (so that your parseing code no-longer works).
> In *Concept* this is similar to the Yahoo/Hotmail etc downloaders 
> that are out there. Some open source projects that might have code 
> you can gain inspiration from. 
> http://freshmeat.net/projects/webbiff/ 
> http://freshmeat.net/projects/yosucker/ 
> http://freshmeat.net/projects/fetchyahoo/ 
> http://freshmeat.net/projects/gotmail/
> the reason for suggesting this is that m0n0 stays 
> Clean/Simple/Good. This complex stuff runs on another machine which
>  connects to m0n0 to perform the work, via the nice Standard port 
> 80/443 provided pages, so there is only ONE place where paramters 
> are altered (well baring hacking the XML file :)
> just some thoughts

I havn't checked the links your provide, but I assume from the context
that your are talking about parsing the HTML and then using HTTP
responses to simulate the "user" input.

Well, of course one could write a huge and complex HTML parser and
HTTP response thingie. Only, the reason behind my suggestion was to
AVOID having to do so, and thus make it a bit easier for people
wanting to make clients and scripts interacting with m0n0wall (which
should in turn benefit m0n0wall and its users, as some of these
utilities might be made available to the community).

The only downside you say you can see with your suggestion is also a
rather big one (as it is VERY likely that changes will be made to the
HTML in nearly every release). As mentioned I also find it a downside
having to do a lot of complex parsing which is very hard to debug and
maintain. Finally you would be strictly limited to the functionality
and information present in the webGUI, which might not be sufficient,
at least not in the long run (lets say Manuel finds the time to
implement the traffic grapher on his whishlist, what would a client do
with the produced images? There would be no way to obtain the
underlying statistical data?)

Regarding your comment about "keeping m0n0wall clean/simple/good": I
really don't see the problem. What I suggested would only entail
adding a single PHP script (and not even a very complex one, I should
think?) to the bunch already in m0n0wall, there would be no added
complexity (unless you also consider exec.php an "added complexity"?),
it would work via http on port 80 or 443 just like the webGUI, and it
would be using the same code as the webGUI does. So what exactly is it
you feel would make m0n0wall unclean/complex/bad?

= = =

Christiaens Joachim wrote:
> an alternative way to do this, would be to make it possible to 
> upload/download the config.xml via a PHP page, but in a scriptable
> way (if this isn't possible yet). This way, changes could be made
> externally to the config and put in place.
> Only problem is that you would need to reboot each time... or some 
> processes could be restarted after the process, just like adjusting
> stuff in the GUI that doesn't need a reboot.
> Just an alternative maybe (and somewhat easyer to implement).

I guess you could use the trick suggested by Mike above to download 
and upload the XML file, and you are probably right that a PHP script 
specifically for this purpose would be simpler than the one I suggest. 
Actually I think this has been suggested before (possibly by myself?)

As you say yourself, the problem would be to avoid the reboot, which 
would probably require an advanced script capable of determining if 
any of the changes made to the config file made the reboot necessary. 
As I see it, this alone would quickly make my idea simpler to 
implement (although I know little of PHP and thus can't say for sure 
which one is the easier task?)

Another issue would be the need to upload and download the entire XML 
file each time a change is made. In cases where a small change is made 
frequently, this would result in an unnecessary amount of traffic and 
a lot of needless work for m0n0wall, which might just make a 
difference in some cases (ie. when the changes are made through a low 
bandwidth connection etc.)

Finally your suggestion suffer the same problem as Mikes: You are 
limited to the information in the config file, and thus won't be able 
to obtain additional information or take any actions not directly 
related to the configuration (unless of course the config file were to 
be filled with various statistics and other informational stuff, but I 
don't think we want to go there!)

= = =

In conclusion I still feel that my idea would be the better trade-off 
between simplicity/security and flexibility/useability.

If I had the time, knew more about PHP, and knew anything at all about 
how to integrate such a script with the existing m0n0wall codebase, I 
would make a a proof-of-concept version of the needed PHP script. 
Perhaps someone out  there will take on this task?

A good and simple place to start would be a script that just 
understood two simple "commands", one to upload and one to download 
the config.xml file. This way, should the project get stranded at that 
point, it could be used in conjunction with the solution suggested by