The paradigm you described sounds very robust and well thought out.
Thanks, I have spent quite some time on the planning and manage similar infrastructures with other applications.
However, I think that is this particular case, it adds an unjustifiable
extra level of complexity.
Always did prefer using a rocket launcher over an M-16 ;-)
Now please hear out my reasoning before hitting "reply".
I'm not one for rash replies.
We're writing a configuration tool (not a service) that will become part of the system-config-* suite of applications. The majority of our users will be using this tool to configure their own (one) machine from the desktop on that computer. I'm not interested in designing an enterprise-class firewall management suite. That's far beyond the needs of well over 99% of our users, and would take much longer to build. What I'm looking to build is a powerful but user-friendly iptables frontend. It shouldn't depend on any third-party database or communications software--that is, the user shouldn't have to install SSH or MySQL in order to configure their own box's iptables rule set.
OK, having a clear picture of who is going to be using your program certainly helps you meet their needs.
That's not to say that there isn't a place for such a firewall
management suite as you've described. I'm just saying that the place
isn't system-config-network.
I do think that is a place for such a management suite, but I see your point.
The program I've been working on follows the following principles:
* Should be easy enough to use by people who don't even know what a firewall is so that they can harden their box, set up masquerading, etc. with extremely little effort.
* Should avoid proprietary internal function that would limit its value outside of what the developer had envisioned. I.e., if you can do it with iptables, you should be able to do it with system-config-firewall.
* Should be simple enough to write and test quickly, but still perform the required function. We need this tool yesterday, not next year.
* Should inter-operate without any problems with other firewall management software (including iptables itself). To the user, system-config-firewall should behave as if the user was working on "the firewall" itself, no matter what the other config tools may do. That means directly accessing the kernel's current iptables rule set (for both read and write), as well as using already-standard repositories for saved rule sets (such as /etc/sysconfig/iptables). That means iptables-save format, rather than XML or third-party databases.
Sounds like the start of a project home page!
The problem with creating your own internal rule store is this: Say the user creates his rule set with our tool. He then (for whatever reason) uses some other piece of software (e.g. iptables) to make a change to the firewall. He then goes back to our tool to view/edit the rule set. Our tool reads the rule set from its own store (that hasn't changed). The problem now is that our tool displays what it thinks the firewall should look like, rather than the actual true state. Also, any changes the user had previously made are undone when we active our own (stale) rule set. We could pompously suggest that ours is the only tool that matters, and the user shouldn't be messing around with other configuration tools, but that attitude is counterproductive and tends to make your product go unused.
Hhmmm. For your above mentioned project goals, this is probably the correct approach (you know a but is coming), but if you start managing more than 50+ network objects (objects used in the rule base) it will become a little unwieldy. I have also read of some "strange behavior" using the iptables-restore/save. See: http://iptables-tutorial.frozentux.net/iptables-tutorial.html#DRAWBACKSWITHRESTORE
Another potential issue that I see is variance in the output of iptables-save. If Rusty has so liberally changed out the entire firewall code three times, I'm not sure how much restraint he'll exercise changing minor things like the output of iptables-save. OK, OK, I'm speaking about eventualities, but keep it in mind.
Having said all this, I think we have different overall goals, but (people in Germany love the word but :-)) some common areas do exist that I would be willing to help with. For example, I could whip up a class of methods that check if objects used in the rules are valid or not. Such as isValidIPv4(), isValidFQDN(), ... back end logic scripting type of stuff.
Regards,
Neil