> 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
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?
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.