>> Indeed. It works, though I have another question regarding macros:
>> since these are included in the chain 'inline' so to speak, is it
>> possible for a macro to get the name of the chain in which this
>> particular macro is going to be 'inlined'?
>>
>
> It would be possible but I don't think that it is desirable.
Eh? Who decides what is "desirable" and what isn't?
If I, as end-user, wish to create a macro, which has different switches
for different chains (so that I switch them "on" and "off" if and when I
well so please), I could do so, like:
M_DROP
~~~~~~~
LOG
NFLOG(1,0,1) - .... ${chain}_nflog_drop
When the macro is processed, the "${chain}_nflog_drop" switch would be
translated to "fw2net_nflog_drop", "net2fw_nflog_drop" and so on, and so
forth - different switches for different chains, obviously, and I could
selectively turn them "on" and "off" when I damn well please, regardless
of whether this is "desirable" or not, simply because it will be my
decision, as an administrator of my own firewall, to make.
If I need a macro which has the same switch for *all* chains regardless,
I could easily use a hard-coded value for the SWITCH column, like so:
M_ALL_DROP
~~~~~~~~~~~~
LOG
NFLOG(1,0,1) - .... nflog_all_drop
So, I don't see what the issue is here - by allowing the use of this
"${chain}" variable (this is just an example, you could use whatever
name is more appropriate - you get the point), whoever creates custom
macros can decide whether to use this variable in the SWITCH column to
switch the set of macros selectively, whether to use a hard-coded value
(like my 2nd example above) to switch all macros in one go, or whether
not to deploy any switch at all. This should always be a decision for
the end-user to make regardless.
> Such a
> scheme would prevent being able to use the same switch in multiple chains.
>
How so? If I need a single switch for multiple chains I could use a
hard-coded value for the SWITCH column (like in my 2nd example above)
and that would be that.
> It is not currently possible but it is something that I would like to do
> and it would be my preferred approach to providing the capability that
> you are looking for.
>
> If I can get it implemented in the next week, I'll include it in 4.5.10;
> otherwise, it will have to wait for 4.5.11.
>
The way I see it, this particular feature (passing more than 1 parameter
to a macro) goes more and more towards "inlined actions". In other
words, actions, which are inlined in the chain they are specified.
You may wish to leave the current implementation of a "macro" as it is
and add a new type of action (call it inline action or whatever) and
start afresh if that would be easier, instead of dragging the millstone
of backward compatibility with you by sticking with the old "macro"
definition. This, though, is a decision for you to make.
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
