[CLUG] IP Tables Front End Project

[adam beecher]

Sorry for disappearing, messy week. Thanks for setting that up AJ. I've
added a page on the database schema, feel free to comment.

http://projects.druid-web.com/projects/wiki/Database 

The rest is a response to an earlier message, that I never got around to.

> 1. Platform independance
>
As you say, not an issue. I know you're developing in PHP5 atm though, I
think we should try to avoid any PHP5-specific code, I'd say only a tiny
minority of live servers are using PHP5 at this point in time. Ditto Apache2
to a lesser degree, although that's unlikely to come up anyway.

> 2. Database independance - I suggest using pearDB or Adodb 
>
I'm not really fond of ADODB so I vote for PEAR.

> 3. Documentation
>
While I agree with you on documentation, I don't think we should go
overboard because it's a relatively simple application. We should document
the arse out of the code inline, but I wouldn't be particularly worried
about userspace documentation at the outset. If we can keep it as simple as
Plesk's implementation, that'll be easy to write in a Wiki when we're done
(I'll do it). We can use PHPDoc to suck the inline documentation out for
developers.

> 4. Set our base goals.
>
I think using Plesk as a template is enough to get us started. When we get a
Plesk-style interface done, we can come up with a new set of goals.

> For example how will IPtables know that a rule has been
> changed? Are we going to run some type of Firewall Daemon
> and message it with XML-RPC/SOAP when a change occurs?
> Or are we for version X just going to rely on a perl/php
> script called from crond?
>
That's what I'd suggest. It'll need to be kludgy at the start, but something
like this works for me:

"When you're finished editing, hit apply, and the firewall will reload in
one minute if changes have been made. This gives you one minute to test
connectivity, after which the the firewall will revert to the current
ruleset. You may then enter a password to apply the new ruleset
permanently."

> 5. As Adam and Peter have suggested, useability is a big
> driving factor! Therefore its gota be simple. I suggest a
> PHP api that manages all the rules and database stuff etc.
> By creating our own it also allows us to modularise our
> code and add multiple frontends in the future perhaps, so
> it don't just have to be web gui.
>
Good idea. So that should be base goal no.1, and the gui base goal no.2.

adam