Shorewall users - Jan 2011 - any chance of having params values available in started?

I need to do a tiny bit of tables manipulation in started:

$IPTABLES -A accounting -i eth0.1 -j LOG --log-prefix
"Shorewall:acct:DROP:"
$IPTABLES -A accounting -o eth0.1 -j LOG --log-prefix
"Shorewall:acct:DROP:"

But I also want to define interfaces in params:

CGCOIF=eth1

which allows me to just define what the interface name is for a given
brand of router that I drop in for my firewall in a params file and then
use all of the same configuration files for more than one brand of
router.

The resulting code in firewall is however:

$IPTABLES -A accounting -i $CGCOIF -j LOG --log-prefix
"Shorewall:acct:DROP:"
$IPTABLES -A accounting -o $CGCOIF -j LOG --log-prefix
"Shorewall:acct:DROP:"

which means that params is not being evaluated in that context.

Looking at firewall, I could simply source params in started but that
would wind up sourcing params in run_started_exit(), which I wouldn''t
mind if all of the values in params became local to that function.  But
they don''t and it seems really bad that calling run_started_exit()
should have such an effect on the global namespace.

Thots?

b.



------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl

On 1/6/11 2:44 PM, Brian J. Murrell wrote:
> I need to do a tiny bit of tables manipulation in started:
> 
> $IPTABLES -A accounting -i eth0.1 -j LOG --log-prefix
"Shorewall:acct:DROP:"
> $IPTABLES -A accounting -o eth0.1 -j LOG --log-prefix
"Shorewall:acct:DROP:"
> 
> But I also want to define interfaces in params:
> 
> CGCOIF=eth1
> 
> which allows me to just define what the interface name is for a given
> brand of router that I drop in for my firewall in a params file and then
> use all of the same configuration files for more than one brand of
> router.
> 
> The resulting code in firewall is however:
> 
> $IPTABLES -A accounting -i $CGCOIF -j LOG --log-prefix
"Shorewall:acct:DROP:"
> $IPTABLES -A accounting -o $CGCOIF -j LOG --log-prefix
"Shorewall:acct:DROP:"
> 
> which means that params is not being evaluated in that context.
> 
> Looking at firewall, I could simply source params in started but that
> would wind up sourcing params in run_started_exit(), which I
wouldn''t
> mind if all of the values in params became local to that function.  But
> they don''t and it seems really bad that calling run_started_exit()
> should have such an effect on the global namespace.
> 
> Thots?
EXPORTPARAMS=Yes in shorewall.conf.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl

On 1/6/11 2:59 PM, Tom Eastep wrote:
> On 1/6/11 2:44 PM, Brian J. Murrell wrote:
>> The resulting code in firewall is however:
>>
>> $IPTABLES -A accounting -i $CGCOIF -j LOG --log-prefix
"Shorewall:acct:DROP:"
>> $IPTABLES -A accounting -o $CGCOIF -j LOG --log-prefix
"Shorewall:acct:DROP:"
>>
>> which means that params is not being evaluated in that context.
>>
>> Looking at firewall, I could simply source params in started but that
>> would wind up sourcing params in run_started_exit(), which I
wouldn''t
>> mind if all of the values in params became local to that function.  But
>> they don''t and it seems really bad that calling
run_started_exit()
>> should have such an effect on the global namespace.
>>
>> Thots?
> 
> EXPORTPARAMS=Yes in shorewall.conf.
I should point out, however, that what you are doing is a *really* bad
idea (using the LOG target out of accounting). Better to use ULOG if you
insist on capturing every packet in and out of the interface.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl

On Thu, 2011-01-06 at 15:07 -0800, Tom Eastep wrote: 
> 
> I should point out, however, that what you are doing is a *really* bad
> idea (using the LOG target out of accounting).
Probably not as bad as you think.  ;-)
> Better to use ULOG if you
> insist on capturing every packet in and out of the interface.
Not every packet.  I have "return"s after each packet is accounted
for.
The log entries I put at the end only end up logging packets which have
managed to get missed by any other accounting rule.  Those log entries
should be the exception and when there is nothing new in the network
that is not being accounted for (and needing a new rule in accounting),
never hit.

Cheers,
b.



------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl

On Thu, 2011-01-06 at 14:59 -0800, Tom Eastep wrote: 
> 
> EXPORTPARAMS=Yes in shorewall.conf.
This is in conflict with the solution in this thread however:

http://www.mail-archive.com/shorewall-users@lists.sourceforge.net/msg10733.html

Cheers,
b.



------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers'' information
secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl

On 1/9/11 6:44 AM, Brian J. Murrell wrote:
> On Thu, 2011-01-06 at 14:59 -0800, Tom Eastep wrote:
>> 
>> EXPORTPARAMS=Yes in shorewall.conf.
> 
> This is in conflict with the solution in this thread however:
> 
>
http://www.mail-archive.com/shorewall-users@lists.sourceforge.net/msg10733.html
In an earlier message, you wrote:
> I could simply source params in started but that would wind up
> sourcing params in run_started_exit(), which I wouldn''t mind if
all
> of the values in params became local to that function. But they
don''t
> and it seems really bad that calling run_started_exit() should have
> such an effect on the global namespace.
So long as you follow the rules for naming your variables (man
shorewall-params), that isn''t an issue. But that solution simply
doesn''t
work. In an extension script, the SOURCE directive (like the shell
''.''
operator) is executed at run-time, not at compile time. You don''t have
access to the params file at run time (unless EXPORTPARAMS=Yes)

The compiler doesn''t process the params file so it doesn''t
currently
know what variables were set in it. Prior to Shorewall 4.4.15, the
contents of the params file were passed from /sbin/shorewall
(/sbin/shorewall6) to the compiler in the process environment.

Beginning with Shorewall 4.4.15, the compiler runs a small shell script
(/usr/share/shorewall/getparams) that processes the params file under
the -a option, then pipes its entire environment back to the compiler
who stores it in a hash (%params) for use in variable expansion in the
config files.

The compiler could infer, though, for each member of %params whether or
not the (param,value) was set in the params file or was part of the
process environment. I wouldn''t want the compiler to have to go through
that for each of the user exits though, so I would make those
assignments global to the firewall script anyway.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers'' information
secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl

On 1/9/11 8:09 AM, Tom Eastep wrote:
> On 1/9/11 6:44 AM, Brian J. Murrell wrote:
>> On Thu, 2011-01-06 at 14:59 -0800, Tom Eastep wrote:
> 
> The compiler could infer, though, for each member of %params whether or
> not the (param,value) was set in the params file or was part of the
> process environment. I wouldn''t want the compiler to have to go
through
> that for each of the user exits though, so I would make those
> assignments global to the firewall script anyway.
> 
Here''s a patch for 4.4.15 and 4.4.16.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers'' information
secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl

On 1/9/11 8:52 AM, Tom Eastep wrote:
> On 1/9/11 8:09 AM, Tom Eastep wrote:
>> On 1/9/11 6:44 AM, Brian J. Murrell wrote:
>>> On Thu, 2011-01-06 at 14:59 -0800, Tom Eastep wrote:
> 
>>
>> The compiler could infer, though, for each member of %params whether or
>> not the (param,value) was set in the params file or was part of the
>> process environment. I wouldn''t want the compiler to have to
go through
>> that for each of the user exits though, so I would make those
>> assignments global to the firewall script anyway.
>>
> 
> Here''s a patch for 4.4.15 and 4.4.16.
Of course, another solution that works without patching is to simply set
the variables in /etc/shorewall/init.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers'' information
secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl

On 1/9/11 9:26 AM, Tom Eastep wrote:
> On 1/9/11 8:52 AM, Tom Eastep wrote:
>> On 1/9/11 8:09 AM, Tom Eastep wrote:
>>> On 1/9/11 6:44 AM, Brian J. Murrell wrote:
>>>> On Thu, 2011-01-06 at 14:59 -0800, Tom Eastep wrote:
>>
>>>
>>> The compiler could infer, though, for each member of %params
whether or
>>> not the (param,value) was set in the params file or was part of the
>>> process environment. I wouldn''t want the compiler to have
to go through
>>> that for each of the user exits though, so I would make those
>>> assignments global to the firewall script anyway.
>>>
>>
>> Here''s a patch for 4.4.15 and 4.4.16.
> 
> Of course, another solution that works without patching is to simply set
> the variables in /etc/shorewall/init.
Never mind that one -- has the same drawback as hard-coding the values
in /etc/shorewall/started.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers'' information
secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl