Hello Eric,
Agreed.
However, I beg to differ with Scott in the following saying: "to
make UI design easier..."; because that config file may not being
processed only by the UI Configurator tool. I certainly hope in the
future that same file can be processed by other applications on the
firewall box as well.
For the current situation, storing the XML firewall config file on
the same (firewall) box does not serve any purpose other than for
tracking which config file goes with which box (I presume). But, on the
other hand, if the config file is rich enough, and the applications (ie.
ipchain, httpd, ipfwd...) can read & parse that XML file directly, then
it becomes valuable to keep the XML file there. In other words, that XML
config file provides the configuration parameters & rules to the
applications running on the box.
Cheers,
Ly
-------------
Eric Wolzak wrote:
> ...
> 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
--
"If you find yourself digging a deeper and deeper hole... stop digging."
- Anonymous
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
