Ray:
        Hey, I know you. :) 

> I think this attempt doesn't get to the essence of the design
> problem. [snip]
>
> The big problem with ipchains rulesets is that order matters.

        I agree, of course, order matters. But that's not
what I was trying to solve, cuz I didn't identify that as
the essence of the design problem.
        The design problem I was looking at is a platform
independent format for a *whole* ruleset. My presumption was 
that the whole ruleset would be installed, from top-to-bottom,
with no rule re-ordering. Sure there's no great trickery there,
but it's not been done before either.

> For that matter, I'm doubtful that XML'ing will help get individual
> rules right. That requires a rule pre-screener, and why not just let 
> it write its output in "ipchains-native" format? 
        
        Writing it in ipchains is the best way if you know it's
going into a 2.2 kernal firewall. If it's going into something
else, and you really don't know what that something else *is*,
then some platform-neutral format makes sense to me. Providing,
of course, you've the implicit understanding that when the rules
get converted, they get installed into the firewall in the same
order that they appear in the XML. And you agree to pay attention 
to as much as you can (ie, ignore the flag tags if your firewall 
can't deal with those).
        Given a *whole ruleset* written this way, it's a bit
of work to write a "ruleset-to-ipchains" converter. But after
that, it's easy to write the "ruleset-to-ipfwadm" one. Or
a netfilter one. 
        Once you've got the converter for your platform, now
you can write a UI that lets the user add, modify and (sure)
break some of the rules. The UI reads from and writes to the 
same platform-neutral format that the converter does. So 
*it* doesn't have to be "ipchains" aware either. That's pretty
powerful, especially if the UI (aka, #3 from an earlier thread)
was a remote process.

> In practice, though, I think this just won't fly.

        It might not. But it got some clear benefits in making
firewall-config UI design easier and making it easier to distribute
firewalls across platforms. Both fairly worthwhile.
        And, really, if there *was* a firewall schema out there
already defined by W3.org, it'd be even more compelling to use
it. But there isn't. So, lets do that. :)
 
> In a way, Dave Cinege always had the right idea about this problem
>... write some scripts that simplify the basics, and expect the advanced
> user to do the complicated bits by hand.

        That's the best model for the advanced user. But I don't
think it's the best model for the average user. The average user,
I think, would appreciate a better firewall-config UI than
editing ipchains commands directly in ae. Or, as you go on to
point out, the average LRP-emailer would appreciate a "how do I
make VNC work?" response that could be answered without needing 
to know the details of their firewall's OS. 

        Shrug.
        I think it's worthwhile enough to pursue if someone is
lit up on the idea and is comfy in XML and firewall rulesets.
If not, I wouldn't say this is the best use of LEAF's best
coders' time.

-Scott


_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel

Reply via email to