Hello Scott
>
> DOH.
> Forgot something: only #1 really *needs* to be local
> to the firewall itself. #2 and #3 could both be remote processes.
>
> -Scott
>
> > 1. To make UI design easier for everyone, it'd be *nice* if the user's
> > intentions for the firewall were stored on the firewall in XML format.
> > A firewall.conf, as it were.
> >
I do agree about the description of the firewall in XML (see my
mail) but why does this description has to be physical on the
Firewall ?
because the Firewall as a machine and the description belong
formally together as a kind of source code ?
As nr 2 is not on the Firewall itself the output from 2 which is
machine /project dependant is the real effector. and has to be on
the machine itself. if #2 is too big, too complex or whatsoever that
we decide not to run it on the box itself why should the "source
code be on the box
> > 2. Given this firewall.conf file, a middleware process/app/script would
> > be needed to turn this data into the OS-specific firewall commands
> > (e.g. ipchains, ipfwadm, netfilter, etc). This middleware piece could
> > produce either a root-executable script, install the rules directly,
> > or even do both.
> >
> > 3. Given #2, you don't care *how* #1 gets updated. It could be thru a
> > command-line console interface, a LAN-based Windoze app, or a remote
> > server running some ASP scripts connected via an SSH session. Or
> > just vi.
>
>
> _______________________________________________
> Leaf-devel mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/leaf-devel
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
