[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: acme-firewall

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
> 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.


Also Iñigo for good suggestions.

Reply to: