> Our prototype doesn't offer the full m0n0wall functionality, but as a
> proof of concept the basics are certainly working.  We have a
> workable, useful Linux-based router running m0n0wall as the GUI.  And
> with the exception of stuff Linux just doesn't support, our method can
> with little effort be extended to do under Linux anything that
> m0n0wall can do on FreeBSD.
>
> Surprisingly, the diff against the m0n0 code is less than 100 lines.
>
> (The magic to allow all this isn't part of m0n0wall, and hence, isn't
> part of the 100 lines)
>

That sounds pretty interesting - I assume the 'magic' is pretty non-trivial?

>  - Regarding languages, we are happy with PHP.  Disk and RAM-wise,
> once you've taken the memory hit of the PHP interpreter, running the
> actual PHP page is very very low cost in terms of memory.  I believe
> the expressiveness, clarity and density of PHP is very good, and
> things such as the string handling make it much easier to write secure
> maintainable programs.  Michael Hanselmann suggested that PHP be
> retained because it's what makes m0n0 unique.  That's preserving PHP
> simply for uniqueness' sake.  I'd suggest a more practical way of
> looking at it:  m0n0 is uniquely customizable *because* it's written
> in PHP.  And an architectural update changes nothing about that
> compelling reason.
>
That is quite a good argument.

>  - As a communication mechanism between front ends and the back end,
> we are considering using XMLRPC.  Very light weight (lighter than
> SOAP), easy to debug and well supported, especially in PHP.
> Multi-language, cross platform, no problems.  While any RPC-using
> program tends to be complicated by the possibility of unreliable comms
> (maybe the server goes away!), things in the m0n0wall case are
> simplified somewhat by having the server and the client on the same
> machine.  The server can just be assumed to be there all the time. For
> the remainder of problems, PHP5's exceptions help keep code clear,
> while still handling problems gracefully.
>
I have limited experience of both SOAP and XMLRPC, but would prefer the latter 
because it is a bit more straightforward IMHO.

> My idea is to have the (minimal) webserver do two jobs.  The first is
> to listen to requests for UI pages from a browser to the web-based
> front end.  The second is to listen to XMLRPC requests from front
> ends, then spawn the PHP backend.  That way, we can get away with only
> having the back-end in memory when it's needed, while still
> permanently listening to XMLRPC and GUI requests (via the webserver).
> We may also add throttling to prevent simultaneous PHP backends, or do
> some sort of back-end "hang-around" mechanism.  (Marc Fargas' email
> said much the same thing).
>

I think you have a good idea here. 

It strikes me that ultimately most of the current m0n0 functionality is either 
producing a config file for a daemon to read, or making discrete calls to 
standard commands like ifconfig or route.  In reality, what is needed is a 
single interface to this mechanism - this need not be threaded or even 
multi-process.  My experience of hacking the m0n0 internals (which covers 
about 6 separate projects now) is a frustration with the level of hacking 
that has to be done in multiple places to integrate a new feature that 
touches the firewall, or the routing logic.

I certainly strongly support the idea of a layered approach - but I think that 
much of the PHP in the current GUI will have to be re-written as it normally 
directly mucks around with the config[] array.  The HTML stuff is probably 
OK, but for some files the PHP logic hidden behind the GUI is pretty large 
and complicated.

I think that separation of the front and back ends would be sooo much easier 
to work with, but a well specified interface would have to be documented and 
agreed.  I suspect that will take a while to do and can probably only be 
completed when a 2.0RC20 is available!

How does m0n0-on-LInux perform compared to the regular system?

Peter

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.