2012/1/20 Michael <firstname.lastname@example.org>:
> Iñigo, thanks for stepping in !
> 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
> 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.
> Also Iñigo for good suggestions.
> To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com
> Archive: firstname.lastname@example.org">http://email@example.com
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
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
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 || firstname.lastname@example.org */
/* Use debian gnu/linux! Best OS ever! */