2012/1/20 Michael <[email protected]>: > Iñigo, thanks for stepping in ! > > Arturo, > > Please don't feel discouraged. As Iñigo already said, it is totally ok to > create a system for a specific purpose, restricted to some usage scenario. It > is 100 time better than giving up upon the too big task ! > > Iñigos' suggestions are already hitting the point. When you make it highly > configurable, and keep different scenarios in mind, it still can be > restricted and 'narrow' in the beginning, but be expanded in future. > > Commenting Iñigos good suggestions a little, > >> One good publicity for your package, could be to make a detailed >> comparison with currently available tools > > While this is for sure a good idea, generally, but i would not throw the > burden upon you, to analyze all of them ...! Maybe investigate only those who > seem to have a similar target or those that you simply are interested in. > > One should be aware that the real value of your work is not in the code, but > in the choices and decisions what specific situations to tackle and how to > solve it, i.e. your security / networking knowledge. Ideally, you would have > an UML flowchart that does not even depend on a specific platform or network > backend. That would be the real value, and no other available package would > include exactly your experiences. > > For example, personally i installed shorewall but that's more just a more > complex backend (still using iptables of course), it does not ship any > specific scenario. It still leaves what you already have done to the admin. > > I strongly support to just source the /etc/default files (it is a shell > inbuilt command) to keep it simple. Some config sanity / bug checking could > be done catching the shell return code (man trap). > > Try to stay compatible to the Linux Standard Base as much as possible, it > makes your package easier to port to another distribution. > http://www.linuxfoundation.org/collaborate/workgroups/lsb/about > In this respect, it is another good idea to make anything configurable which > uses specific Debian infrastructure (like backends.) > >> + Debian if-up-down maybe extended to match firewall policies > > But, isn't if-up-down somehow spinning towards becoming obsolete somehow ? It > already does not bring up all available interfaces, today. I think this > shifts to udev (and desktop daemons using dbus), but anyway, IMHO the > firewall should not bring interfaces up or down, you could easily run into a > bad mess with other managers. It should not bother about who manages that as > long as it can poll the actual network state, and as long as there are > triggering hooks. (Maybe add udev monitoring rules ?) But YMMV. > >> > The problem is that document is in my native language (spanish) and >> > the translation is pending. > > Arturo, I think that you are the only one who really will be able to > translate your doc w/o mistakes... and your English is quite good. > >> You can start by pasting the docs at debian wiki, under the "es" >> (spanish) namespace, and requesting translators using such link (you >> will need people that is able to edit a wiki and know Spanish+other >> language). > > I wonder if anyone would dare to pick up the job :) it is not like there are > many people with your knowledge, who are also working as translators. > > But Arturo, you may ask for 50:50 teamwork, maybe someone picks it up as a > matter of exercise then. > >> It's always great when people wants to share acquired knowledge and >> help to others. Congrats. > > ACK > > Also Iñigo for good suggestions. > > > -- > To UNSUBSCRIBE, email to [email protected] > with a subject of "unsubscribe". Trouble? Contact [email protected] > Archive: http://lists.debian.org/[email protected] >
Hi there! First, thanks Iñigo and Michael for your detailed post, and thanks for your interest. I thank you for your time and hassle. Reading all emails, you give me a lot of TODO. Just give me time to think about some issues both you said and i will come back with a better package. I promisse it :) I can't say when, because my extremely-full-time job. About Iñigo and Michael ideas, i have to say: I approached my package as a standar service in the system. Mostly (maybe) inspired by RHEL iptables-save+iptables-restore method. I miss (in debian) a standar way to deploy iptables rules. I know that the system lacks of methods that a real firewall must have (with vpn, checking interfaces, checking conectivity, a system to avoid dns queries in each rule, and a long etc..) But that's not the scope of the package. In real deployment of a firewall, it's not rare to find a custom script to manage the specific system. Thats my case: in my job (5k+ iptables rules, both IPv6 and IPv4) I have a totally different system. I want you to understand the scope difference. Said that, i will continue working on it. About the HA-cluster-firewall documentation, I absolutely have no time to translate it. So I will go to debian-wiki. And again, thanks for all. I had doubt about how could a newbie packager join a discussions like this. -- /* Arturo Borrero Gonzalez || [email protected] */ /* Use debian gnu/linux! Best OS ever! */ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CAPfcJatrNfaMDN68Ynk=egvamdqdh1q1wcv7wbkwhe3ueuo...@mail.gmail.com
