OK, let me try to answer a few of the questions that have been raised by various people all in one place (while at the same time starting a new thread that doesn't have my name in the subject line :) ** Why not existing programs ** It would be much easier to just plunk in someone else's config program and call it done. The biggest problem I've seen with that approach is that the other programs won't integrate well into our existing infrastructure. See the "What TO do" section below for more details. Now that's not to say that users can't use fwbuilder and firestarter. Both are already packaged to work with fedora, and I think they should be included in the "extras" set. I just don't think that those programs should be the default app that pops up when users click "Firewall". If you run fwbuilder of firestarter, I think that you should know that you're using a 3rd party app that is not 100% compatible with fedora's own infrastructure (because they're not). ** What not to do ** There are a number of similarities between all of the existing firewall apps that I've examined that I'd really like to avoid. To make it easier to understand my stance, take a look at redhat-config-httpd. Back when it was first introduced, I was SO excited to have a GUI tool for configuring my webserver. I quickly became extraordinarily disappointed when I realized just how small a subset of Apache's configuration I could manipulate with this tool. What was even more distressing was the fact that, because my apache configuration was so complicated, I couldn't use the tool at all, because it would overwrite what I had already created. The situation has since improved somewhat (or at least I hope it has.. haven't really checked), but the lesson learned is important. Redhat-config-network was a lot better in this respect. Since I first tried it, I was impressed. It can help you to configure many things that may be difficult otherwise, but if you want to get under the hood and do it yourself, it is good enough to stay out of your way. I can manually configure some aspects of my network, and still use r-c-n to help with other parts. And, it works *with* all the existing tools and scripts, rather than attempting to replace them. ** What TO do ** 1. Avoid duplicating work. Users shouldn't have to dump init.d/iptables et al to use our tool. A lot of work and improvements have gone into the existing infrastructure, and it's still being maintained and improved. It behooves us to work *with* them, rather than attempting to compete. That also means avoiding proprietary rule stores. I think I've already covered this point ad nauseum. 2. Assume some users need help. That means make it trivially easy to set up common things like NAT. Autodetecting relevant settings, etc., will probably be part of that. As will be easy-to-use interfaces. 3. Assume some users know more than we do. While we won't (can't) have a checkbox or menu entry for virtually everything you can do with a firewall, we CAN support every syntactically valid iptables configuration. Other firewall tools claim to be compatible with things like NAT or TOS. We can be compatible with iptables itself, and therefore, everything that goes along with it, including NAT, TOS, and literally everything else. Our tool will most definitely have a convenient GUI for setting up masquerading, but at first probably won't have anything for setting TOS values on packets originating from userID=48. (yes, you CAN do that with iptables). Still, he WILL be able to use our tool to easily create such arcane rules if he really knows what he wants. And if such a rule exists, our tool will still be able to intelligibly display what it is and how it works. This is where other tools break down. I have a design in mind that will very well with this principle. More to come on that when I get the design spec done. 4. Integrate into other fedora projects. As Brent pointed out, we should be able to service simple requests from programs like s-c-network saying "yes, masquerading is enabled using outbound eth1". ** Getting things going ** I've heard bad things about SourceForge, so until RedHat sets up an external CVS server, I can host the project on one of my public servers. I've got plenty of bandwidth and plenty of space. The next thing I'm going to do is put together a draft design spec. That should at least give us a solid starting point for any debate about the product itself. Once we know what we want, we can start assigning out tasks to people who want to help. -- Tyler Larson Colorado Springs, CO USA TZ: MST (GMT-7:00)