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
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
