Re: firehol extra tools

Hello Costa:

Thanks for your prompt reply.

I slept on your email. Now, I think, I have a better view.

On 01/01/16 03:20, Tsaousis, Costa wrote:
> Well, given the fact that we are talking about just shell scripts, I
> think the whole idea of splitting them, is overkill.

From a distribution packaging perspective, being shell scripts or not
is not the issue.

> 
> It is reasonable for someone to say he just needs fireqos,

agree

 but at the
> same time I don't believe it will bother anyone if firehol and
> link-balancer are also installed (given that they do nothing if not
> configured - so an accidental run will not harm).

They do nothing indeed but at the same they occupy space for nothing
and they let some not configured stuff here and there: it is
better to avoid this kind of dust or noise.
The current firehol configure.ac provides a full set of options
that reflect these point.

> 
> Keep also in mind the following:
> 
> From what I read on forums, a lot of users are using firehol to just
> learn iptables.

It is not an issue of a democracy by majority.
Every need must be taken into account.



 Firehol has the 'explain' feature that generates
> iptables statements from configuration statements given to it
> interactivery.

This is indeed a great feature. Beside learning it also allows some
amateurs (so to speak) to set up their own firewall without a deep
knowledge of  iptable related stuff (quite a complex matter that certainly
needs a lot of time, experience and practice to master)

 A lot of users that do not use firehol for their
> firewall,

so a few do.

 are using this feature to learn how to write iptables
> statements by hand.
> 
> On the other hand, as time passes we identify needs and therefore code
> that should be common to all tools (IP version handling is similar and
> could be unified, fireqos has a very nice state machine for nested
> classes that could be used in other tools too, link-balancer has a
> nice code for resolving a dependency tree, etc). So we think of moving
> parts of the code from the individual tools to a common shell library.
> At some point in future, firehol, fireqos and probably other tools may
> be mainly front ends to the same shell library.

This is a very useful information and it will definitely help me
for may final decision.

> 
> So you have a few options:
> 
> 1. Package all as "firehol"

not reasonable from a distribution packager perspective:
each package may correspond to a specific need.
As packager, I must find a balanced point.

> 
> 2. Identify the main needs: firehol, fireqos, firehol-common, firehol-tools

This approach fits distribution goals.
I will keep firehol and fireqos. A firehol-common package seems inevitable now.


> 
> 3. Split them all: firehol, fireqos, link-balancer, update-ipsets,
> vnetbuild, firehol-common

Too atomized, I am afraid.

> 
> I don't know. My suggestion is option 1.

For now, I think I will favour the second suggestion,
or something between the second and the third one:
I must think about what firehol-common and firehol-tools must contain.
Some more time are needed from my side to clarify the situation.

 I think all the other options
> add complexity without any actual gains.
> Of course, this is your call...


Any more hint or suggestion is welcome, BTW.


Thanks for your insights,
Jerome

> 
> Costa
> 
> On Fri, Jan 1, 2016 at 3:33 AM, Jerome BENOIT <[email protected]> wrote:
>> Hello Costa:
>>
>> Thanks for your prompt reply.
>>
>> Currently the debian pacakges for firehol is split into two packages:
>> firehol and fireqos.
>>
>> For practical reasons, I have already add firehol-common,
>> and I am on my way to add vnetbuild .
>>
>> This splitting approach sound reasonable to me because firehol, fireqos,
>> and vnetbuild have clearly different objectives. Of course, the package
>> firehol-common is meant to contain common material, so far only
>> functions.common.sh .
>>
>> On the other hand, packages cannot be atomize ad infinitum.
>>
>> Right now, I am wondering whether or not these extra tools might be put
>> in the firehol-common package. I was on the edge to introduce a firehol-tools
>> (or something) package, but it begins to get ridiculous.
>> What do you think ?
>>
>> Thanks,
>> Jerome
>>
>>
>> On 01/01/16 02:17, Tsaousis, Costa wrote:
>>> I have to add that update-ipsets depends on iprange and uses it (like
>>> firehol does) to optimize the ipsets loaded in kernel for maximum
>>> performance.
>>>
>>> update-ipsets also makes sure that IP lists downloaded from internet
>>> sources (it download everything from the maintainers sites), are
>>> parsed in such a way that no code injection is possible, and kernel
>>> updates are atomic, meaning that for every ipset kernel update either
>>> it succeeds and the new ipset is loaded, or it fails and the old ipset
>>> is left untouched - the ipset is never empty - not even for a
>>> nanosecond.
>>>
>>> Costa
>>>
>>>
>>> On Fri, Jan 1, 2016 at 3:10 AM, Tsaousis, Costa <[email protected]> wrote:
>>>> link-balancer is a tool that allows to setup and maintain multiple
>>>> concurrently active, balanced gateways (default or any other kind). It
>>>> tries to fill the gap that the standard linux tools (like iproute2) do
>>>> not address (for example, when there is a balanced gateway setup and
>>>> one of them is lost, the whole gateway route is lost - it also allows
>>>> you to setup some kind of inheritance among routing tables).
>>>>
>>>> So, it is a tool that complements both firehol and fireqos, but is
>>>> independent of them. Currently firehol, fireqos and link-balancer
>>>> share only custom mark definitions (defined in firehol, saved in
>>>> /var/cache/firehol and loaded/used by fireqos and link-balancer - this
>>>> is only used to reference marks by name - the admin can define marks
>>>> by number to avoid this dependency).
>>>>
>>>> update-ipsets is again a standalone tool. It can complement any
>>>> firewall, not only firehol. It allows downloading and unifying third
>>>> party IP lists (the admin can configure more IP lists sources too) and
>>>> can update ipsets in kernel for any firewall (this is not firehol
>>>> specific - it will update ipsets in kernel for any netfilter ipset
>>>> based firewall).
>>>>
>>>> Costa
>>>>
>>>>
>>>> On Fri, Jan 1, 2016 at 2:25 AM, Jerome BENOIT <[email protected]> wrote:
>>>>> Hello List:
>>>>>
>>>>> On 30/12/15 07:10, Tsaousis, Costa wrote:
>>>>>> Excellent!
>>>>>> Thank you.
>>>>>
>>>>> You are welcome.
>>>>>
>>>>>>
>>>>>> On Wed, Dec 30, 2015 at 7:18 AM, Jerome BENOIT <[email protected]> wrote:
>>>>>>> Hello Forum:
>>>>>>>
>>>>>>> I am please to announce that iprange is reaching Debian Sid.
>>>>>>> For now the package is in the NEW queue [1],
>>>>>>> while the git debian material is available a Alioth [2].
>>>>>>>
>>>>>>> Now I will focus on refreshing the debian material for firehol and its friends.
>>>>>
>>>>> My current understanding is that update-ipsets is a tool meant to be used with firehol .
>>>>> Concerning link-balancer , is it meant to be used with firehol ? or fireqos ?
>>>>>
>>>>> Thanks in advance,
>>>>> Jerome
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jerome
>>>>>>>
>>>>>>>
>>>>>>> [1] https://ftp-master.debian.org/new/iprange_1.0.2%2Bds-1.html
>>>>>>> [2] https://anonscm.debian.org/cgit/collab-maint/iprange.git/
>>>>>>> _______________________________________________
>>>>>>> Firehol-support mailing list
>>>>>>> [email protected]
>>>>>>> http://lists.firehol.org/mailman/listinfo/firehol-support
_______________________________________________
Firehol-support mailing list
[email protected]
http://lists.firehol.org/mailman/listinfo/firehol-support