Tom:
Hello! Yes, you described it better than I did.
My #3 below says *usually* defined in platform-specific
format: that was a nod to status quo, is all. What I hear
suggested with this XML work breaks from that paradigm,
and is (exactly) as you put it: build the UI to generate
output that is entirely platform-neutral and have a backend
process translate this platform-neutral representation into
a platform-specific ruleset.
Sign me up. :)
-Scott
On Wed, 7 Feb 2001, Tom Eastep wrote:
> Hi Scott,
>
> Thus spoke Scott C. Best:
>
> >
> > Hmmm. I think we're speaking about different things. :)
>
> Quite possibly :-)
>
> > Let me see if I can remember my thinking on this...a firewall
> > system includes these things:
> >
> > 1. A OS with packet-filtering capability (eg, okay, Linux ;)
> > 2. A command interface to that capability (eg, ipchains)
> > 3. A base ruleset, usually defined in terms of #2 (eg,
> > a *order-dependent* list of ipchains commands).
> > 4. User customizations to augment #3.
> >
> > What I've heard discussed over the last few weeks is:
> > "what sort of user interface can LEAF provide to make the
> > installation of #3 and the creation of #4 easier for the
> > non-learned user?".
>
> Good.
>
> > My opinion has been that the design of this user
> > interface can be simplified if it is independent of #2. It
> > would read and write to a platform-neutral format, and so
> > the talk naturally comes around to XML for that. In that
> > format, we'd specify the whole of #3, including its
> > required order dependencies (which is as Ray pointed out).
>
> What is the point of using a platform-neutral format such as XML to
> represent the firewall if what's being represented is very
> platform-specific? Wouldn't it be better for the UI to generate output
> that is entirely platform-neutral and have a backend process translate
> this platform-neutral representation into a platform-specific ruleset
> (#3). I can understand representing #4 in terms of platform-specific
> rules but those rules can be opaque with respect to the XML representation
> (e.g., just blobs of text). This would be analagous to what I do in the
> various /etc/seawall/<chain> files; they can contain whatever
> platform-specific commands that the users wants included in the associated
> chain and the "behind the scenes" translation script (the firewall
> script in the case of Seattle Firewall), simply passes them to the shell
> for execution at the proper point in building the chains.
>
> This approach would allow the UI to be substantially independent from the
> target platform (ipchains, iptables, <whatever Rusty comes up with next>,
> ...).
>
> > We'd also store "user intentions" which can be much higher
> > level as you suggest: "FTP_SERVER=192.168.1.2" is all it
> > should take.
> >
> > I'm a big proponent of "solve the UI" problem, so I'm
> > willing to swallow the pill that comes with it: if we *do*
> > make this step away from defining a firewall in terms of
> > ipchains, then there is a "magic happens here" piece of code
> > that translates the XML data back into it. The overall complexity
> > of the task is unchanged; I'm just advocating the shift of
> > the complexity from the "what you see everyday" UI to the
> > "behind the scenes" translation script/process.
>
> In that, we're in total agreement.
>
> -Tom
> --
> Tom Eastep \ Alt Email: [EMAIL PROTECTED]
> ICQ #60745924 \ Websites: http://seawall.sourceforge.net
> [EMAIL PROTECTED] \ http://seattlefirewall.dyndns.org
> Shoreline, Washington USA \___________________________________________
>
>
> _______________________________________________
> 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
