[syslog-ng] Macros expansion in pattern-db actions
Balazs Scheidler
bazsi at balabit.hu
Thu Jul 14 09:19:01 CEST 2011
On Mon, 2011-06-20 at 20:00 +0200, Denis Gasparin wrote:
> Hi to all.
>
> We're using syslog-ng 3.2.4 and we're having a weird behaviour in
> using macros with actions values.
>
> Here it is a sample pattern-db rule:
>
> <?xml version='1.0' encoding='UTF-8'?>
> <patterndb version='4' pub_date='2011-06-20'>
> <ruleset name='cron' id='cron-ruleset'>
> <pattern>/usr/sbin/cron</pattern>
> <rules>
> <rule provider="patterndb" id="cron-1" class="system"
> context-id="sample-context-id">
> <patterns>
> <pattern>(@ESTRING:usracct.username:) @CMD
> (@ESTRING:details:)@</pattern>
> </patterns>
> <actions>
> <action trigger="match" condition="match('mymatch'
> value('details'))">
> <message>
> <values>
> <value
> name="MESSAGE">[${details}] was found in a cron log message. Rule
> number [${.classifier.rule_id}]</value>
> <value
> name="TRIGGER">yes</value>
> </values>
> </message>
> </action>
> </actions>
> </rule>
> </rules>
> </ruleset>
> </patterndb>
>
> We tested the rule using pdtool match command and the output was:
>
> # pdbtool match -P "/usr/sbin/cron" -M "(root) CMD (mymatch)"
> MESSAGE=(root) CMD (mymatch)
> PROGRAM=/usr/sbin/cron
> .classifier.class=system
> .classifier.rule_id=cron-1
> usracct.username=root
> details=mymatch
>
> HOST=
> MESSAGE=[] was found in a cron log message. Rule number []
> PROGRAM=/usr/sbin/cron
> PID=
> TRIGGER=yes
>
> We instead expected the following output from pdtool match execution:
>
> # pdbtool match -P "/usr/sbin/cron" -M "(root) CMD (mymatch)"
> MESSAGE=(root) CMD (mymatch)
> PROGRAM=/usr/sbin/cron
> .classifier.class=system
> .classifier.rule_id=cron-1
> usracct.username=root
> details=mymatch
>
> HOST=
> MESSAGE=[mymatch] was found in a cron log message. Rule number
> [cron-1]
> PROGRAM=/usr/sbin/cron
> PID=
> TRIGGER=yes
>
> Macro expansion was not executed in action values but it was in action
> definition... What are we missing?
>
> Thank you in advance for your help
Sorry for not answering any sooner. The reason is that the messages
generated by an <action> sees the complete correllation context, and the
message being generated is at the top of the context (e.g. ${details}
maps to the "details" attribute of the message being generated), the one
which matched the rule is @1, e.g. you'd need to write ${details}@1 to
extract that name-value pair.
--
Bazsi
More information about the syslog-ng
mailing list