Beta 1 is now available for testing.
New Features:
1) The variables $_loglevel and $_logtag (${_loglevel} and ${_logtag})
are now available within action bodies. Their contents are:
$_loglevel
The log level specified when the action was invoked. If no
level was specified, $_loglevel expands to ''none''.
$_logtag
The log tag specified when the action was invoked. If no tag
was specified, $_logtag expands to an empty string.
2) Action variables ($0, $1,...$n,$_loglevel and $_logtag) are now
available in ?IF and ?ELSIF directives.
3) A ''nolog'' option has been added to
/etc/shorewall[6]/actions. This
option causes the compiler to forego adding the log level and log
tag from the action invocation to those rules within the body that
do not specify a tag and/or level.
3) An ''ALLOWUNKNOWNVARIABLES'' option has been added to
/etc/shorewall[6]/shorewall[6].conf. When set to ''Yes'',
this option
instructs the compiler to expand unknown shell variables and
action parameters to an empty string rather than raising an error.
4) ?SET and ?RESET directives are now available:
?SET <variable> <value>
?RESET <variable>
To cater to both Shell and Perl programmers, the <variable> may
be entered with or without leading ''$''.
The ?SET command sets the named <variable> the the specified
<value> where <value> is a Perl-compatible expression.
The ?RESET command deletes the named <variable> from the
compiler''s
variable table.
Thank you for testing,
-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 \________________________________________________
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
> New Features: > > 1) The variables $_loglevel and $_logtag (${_loglevel} and ${_logtag}) > are now available within action bodies. Their contents are: > > $_loglevel > > The log level specified when the action was invoked. If no > level was specified, $_loglevel expands to ''none''. > > $_logtag > > The log tag specified when the action was invoked. If no tag > was specified, $_logtag expands to an empty string. > > 2) Action variables ($0, $1,...$n,$_loglevel and $_logtag) are now > available in ?IF and ?ELSIF directives. >Should I assume that the ''@_loglevel'', ''@_logtag'' (as well as ''@{_loglevel}'', ''@{_logtag}'') are also available? You may also wish to introduce "$_chain" (''@_chain, ''@{_chain}'') as an alternative to $0 (@0, @{0}) to keep this consistent. Also, am I right in assuming that these can be set with ?SET as described below?> 3) A ''nolog'' option has been added to /etc/shorewall[6]/actions. This > option causes the compiler to forego adding the log level and log > tag from the action invocation to those rules within the body that > do not specify a tag and/or level. >Would it be possible to choose these (i.e. use a custom-specified logtag for example) in the action itself? in other words, specify a custom/preset logtag as well as loglevel for both LOG as well as NFLOG/ULOG targets?> 3) An ''ALLOWUNKNOWNVARIABLES'' option has been added to > /etc/shorewall[6]/shorewall[6].conf. When set to ''Yes'', this option > instructs the compiler to expand unknown shell variables and > action parameters to an empty string rather than raising an error. >This is a bit misleading since you are not allowing unknown variables, but setting these to '''' (empty string). I would have thought ''IgnoreUnknownVariables'' would be more appropriate. In addition, you may introduce ''SetUnknownVariables=XX'' to assume a value for variables not already defined (that, of course, would implicitly set IgnoreUnknwonVariables to ''1''/''yes'').> 4) ?SET and ?RESET directives are now available: > > ?SET <variable> <value> > ?RESET <variable> > > To cater to both Shell and Perl programmers, the <variable> may > be entered with or without leading ''$''. > > The ?SET command sets the named <variable> the the specified > <value> where <value> is a Perl-compatible expression. > > The ?RESET command deletes the named <variable> from the compiler''s > variable table. >What about the ''@'' notation? Can I use set with ''@{something}'' for example (I am thinking altering logtags, mainly)? ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d
On 12/10/2012 10:04 AM, Mr Dash Four wrote:> >> New Features: >> >> 1) The variables $_loglevel and $_logtag (${_loglevel} and ${_logtag}) >> are now available within action bodies. Their contents are: >> >> $_loglevel >> >> The log level specified when the action was invoked. If no >> level was specified, $_loglevel expands to ''none''. >> >> $_logtag >> >> The log tag specified when the action was invoked. If no tag >> was specified, $_logtag expands to an empty string. >> >> 2) Action variables ($0, $1,...$n,$_loglevel and $_logtag) are now >> available in ?IF and ?ELSIF directives. >> > Should I assume that the ''@_loglevel'', ''@_logtag'' (as well as > ''@{_loglevel}'', ''@{_logtag}'') are also available? You may also wish to > introduce "$_chain" (''@_chain, ''@{_chain}'') as an alternative to $0 (@0, > @{0}) to keep this consistent.I see no requirement for @_loglevel and @_logtag and I really don''t want to expand the use of @... any more than is absolutely necessary.> > Also, am I right in assuming that these can be set with ?SET as > described below?Yes.> >> 3) A ''nolog'' option has been added to /etc/shorewall[6]/actions. This >> option causes the compiler to forego adding the log level and log >> tag from the action invocation to those rules within the body that >> do not specify a tag and/or level. >> > Would it be possible to choose these (i.e. use a custom-specified logtag > for example) in the action itself? in other words, specify a > custom/preset logtag as well as loglevel for both LOG as well as > NFLOG/ULOG targets?Can you elaborate a bit?> >> 3) An ''ALLOWUNKNOWNVARIABLES'' option has been added to >> /etc/shorewall[6]/shorewall[6].conf. When set to ''Yes'', this option >> instructs the compiler to expand unknown shell variables and >> action parameters to an empty string rather than raising an error. >> > This is a bit misleading since you are not allowing unknown variables, > but setting these to '''' (empty string). I would have thought > ''IgnoreUnknownVariables'' would be more appropriate. In addition, you may > introduce ''SetUnknownVariables=XX'' to assume a value for variables not > already defined (that, of course, would implicitly set > IgnoreUnknwonVariables to ''1''/''yes'').I''m okay with changing the name to IGNORE...> >> 4) ?SET and ?RESET directives are now available: >> >> ?SET <variable> <value> >> ?RESET <variable> >> >> To cater to both Shell and Perl programmers, the <variable> may >> be entered with or without leading ''$''. >> >> The ?SET command sets the named <variable> the the specified >> <value> where <value> is a Perl-compatible expression. >> >> The ?RESET command deletes the named <variable> from the compiler''s >> variable table. >> > What about the ''@'' notation? Can I use set with ''@{something}'' for > example (I am thinking altering logtags, mainly)?Again -- I''m not keen on expanding the set of those variables without a strong use case. -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 \________________________________________________ ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d
> I see no requirement for @_loglevel and @_logtag and I really don''t want > to expand the use of @... any more than is absolutely necessary. >The way I see it, there are at least 3 advantages when using ''@'' instead of ''$'': 1. Avoid possible clash of variables defined in "param" (I could define "_loglevel=OMG" for example) - this is bound to mess things up quite dramatically. If you confine the use of shorewall "system" variables to be specified with ''@'' instead of ''$'' that could be easily avoided and clashes in the way I just described will never happen. 2. It keeps things clean: ''$'' is used for all user-defined variables, while ''@'' is reserved for shorewall''s own "system" variables - the separation is quite obvious. 3. The above is, in a way, "future-proof": when ''@'' is completely separate from ''$'', if/when you decide to expand these "system" variables, there won''t be any clash with existing configurations (i.e. variables already defined in "param") in the way I described in 1 above. Currently, if I already have a variable in my param file called "_logtag", the upgrade won''t work and I have to scratch my head to find out why my firewall is messed up.>> Would it be possible to choose these (i.e. use a custom-specified logtag >> for example) in the action itself? in other words, specify a >> custom/preset logtag as well as loglevel for both LOG as well as >> NFLOG/ULOG targets? >> > > Can you elaborate a bit? >Please ignore this - it was before I realised that $_logtag and $_loglevel can be altered and I could specify something like: ?SET _logtag "MyLog1" ?SET _loglevel "6" LOG # -j LOG --log-level 6 --log-prefix "MyLog1" ?SET _logtag "MyLog2" ?SET _loglevel "7" LOG # -j LOG --log-level 7 --log-prefix "MyLog2"> I''m okay with changing the name to IGNORE... >Thanks, that''ll do.> Again -- I''m not keen on expanding the set of those variables without a > strong use case. >See above. ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d
On 12/10/12 3:38 PM, Mr Dash Four wrote:> >> I see no requirement for @_loglevel and @_logtag and I really don''t want >> to expand the use of @... any more than is absolutely necessary. >> > The way I see it, there are at least 3 advantages when using ''@'' instead > of ''$'': > > 1. Avoid possible clash of variables defined in "param" (I could define > "_loglevel=OMG" for example) - this is bound to mess things up quite > dramatically.Actually, it will not. Every instance of $_loglevel (${_loglevel}) will be expanded exactly as you intended when you set that variable in your params file. Of course, the new functionality that I provided won''t be available but C''est la Vie.> 2. It keeps things clean: ''$'' is used for all user-defined variables, > while ''@'' is reserved for shorewall''s own "system" variables - the > separation is quite obvious.Except that we invented ''@'' variables because they must be evaluated late (after the target chain is available).> > 3. The above is, in a way, "future-proof": when ''@'' is completely > separate from ''$'', if/when you decide to expand these "system" > variables, there won''t be any clash with existing configurations (i.e. > variables already defined in "param") in the way I described in 1 above. > Currently, if I already have a variable in my param file called > "_logtag", the upgrade won''t work and I have to scratch my head to find > out why my firewall is messed up.No -- Your config will continue to work perfectly -- you just can''t use the new features. -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 \________________________________________________ ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d
On 12/10/2012 01:22 PM, Tom Eastep wrote:> On 12/10/2012 10:04 AM, Mr Dash Four wrote: >> >>> New Features: >>> >>> 1) The variables $_loglevel and $_logtag (${_loglevel} and ${_logtag}) >>> are now available within action bodies. Their contents are: >>> >>> $_loglevel >>> >>> The log level specified when the action was invoked. If no >>> level was specified, $_loglevel expands to ''none''. >>> >>> $_logtag >>> >>> The log tag specified when the action was invoked. If no tag >>> was specified, $_logtag expands to an empty string. >>> >>> 2) Action variables ($0, $1,...$n,$_loglevel and $_logtag) are now >>> available in ?IF and ?ELSIF directives. >>> >> Should I assume that the ''@_loglevel'', ''@_logtag'' (as well as >> ''@{_loglevel}'', ''@{_logtag}'') are also available? You may also wish to >> introduce "$_chain" (''@_chain, ''@{_chain}'') as an alternative to $0 (@0, >> @{0}) to keep this consistent. > > I see no requirement for @_loglevel and @_logtag and I really don''t want > to expand the use of @... any more than is absolutely necessary. > >> >> Also, am I right in assuming that these can be set with ?SET as >> described below? > > Yes. >I mis-spoke here. In the current code, action variables cannot be altered using the ?set directive. -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 \________________________________________________ ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d
On 12/10/2012 07:02 PM, Tom Eastep wrote:> On 12/10/12 3:38 PM, Mr Dash Four wrote: >> >>> I see no requirement for @_loglevel and @_logtag and I really don''t want >>> to expand the use of @... any more than is absolutely necessary. >>> >> The way I see it, there are at least 3 advantages when using ''@'' instead >> of ''$'': >> >> 1. Avoid possible clash of variables defined in "param" (I could define >> "_loglevel=OMG" for example) - this is bound to mess things up quite >> dramatically. > > Actually, it will not. Every instance of $_loglevel (${_loglevel}) will > be expanded exactly as you intended when you set that variable in your > params file. Of course, the new functionality that I provided won''t be > available but C''est la Vie.Beta 1 does not support setting any variable that begins with ''_''.> >> 2. It keeps things clean: ''$'' is used for all user-defined variables, >> while ''@'' is reserved for shorewall''s own "system" variables - the >> separation is quite obvious. > > Except that we invented ''@'' variables because they must be evaluated > late (after the target chain is available). > >> >> 3. The above is, in a way, "future-proof": when ''@'' is completely >> separate from ''$'', if/when you decide to expand these "system" >> variables, there won''t be any clash with existing configurations (i.e. >> variables already defined in "param") in the way I described in 1 above. >> Currently, if I already have a variable in my param file called >> "_logtag", the upgrade won''t work and I have to scratch my head to find >> out why my firewall is messed up. >Yes -- if you have a variable named ''_loglevel'' in your params file, it will not be visible in ?if, ?elseif and ?set directives. But if you installed 4.5.10, you are already out of luck since that release doesn''t recognize shell variables that don''t begin with a letter. -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 \________________________________________________ ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d