Name: Tyler Larson I've been a programmer for about 12 years, now working professionally writing network-related code in C++. I've been programming for Linux since 1998, largely in C++ and perl, while doing professional web design using PHP. I was attracted to the Fedora project because I regularly use RedHat at home and at work. I appreciate the progress it has made, but think there's still a lot left to do. The iptables configuration project, in particular, interests me because of my networking background. Since I'd never written a program using Glade, GTK, or even python, I started building an iptables configuration project to see how difficult it would be. I think it's a tribute to the simplicity of the language and development kit, and depth of the documentation that the first program I've ever written with this system turned out so well. I tried downloading and installing other firewall configuration programs, such as Firestarter. I certainly hope no one is considering adapting any of the existing applications for Fedora. What we need is an application with sufficient flexibility that would attract even the advanced users, but that is extensible enough to allow non-technical users to configure their computer to do what they want. If you're currently working on an iptables configuration tool for fedora, drop me a line. If you'd like to see what I've done so far, you can download my work-in-progress at www.tlarson.com/fireconf.tar.gz. It reads and parses the output of iptables-save, parses out the rules according to the explanations in the iptables HOWTOs and man pages, and displays the results in an easy-to-understand manner. Here are some of my thoughts on the project: * We should use iptables-save and iptables-restore instead of iptables to retrieve and insert rules into the kernel. The transactional paradigm of iptables-save and -restore can be incorporated into a GUI much more cleanly. Also, using iptables-save and -restore removes a lot of the complexity that you'd otherwise have to deal with. * We shouldn't attempt to completely hide the underlying rule-based nature of the netfilter: don't just try to expand the lokkit interface to do NAT. An interface that gives users the option of creating their own rules can be user-customized to do anything--we need to avoid locking the user into performing just a few preset tasks when iptables allows so much flexibility. * Common tasks, such as basic system lock-down or configuring masquerade should be accomplished using easy-to-understand and easy-to-find druids, but without destroying unrelated firewall rules (like lokkit does). * Developers should have a clean, straight-forward interface for adding new configuration druids to automate other common tasks that we may not have thought of. * The iptables tool should peacefully co-exist with other related tools. E.g. I should be able to use lokkit to configure my firewall and use this new tool to edit the result. It should get all its firewall information from standard already-in-use sources: /etc/rc.d/init.d/iptables should continue to work unmodified.