In message <[email protected]>,
686f6c6d writes:
>I was trying to be smart during first time SEC set-up over here, so I
>split my config files like
> sec-00-main.conf (main settings, some variables)
> sec-10-suppress.conf (early suppression of irrelevant stuff)
> sec-20-single.conf (early handling of simple, single log entries)
> sec-... (more complicated stuff)
>
>So I had some really simple Suppress rules like
> type=Suppress
> ptype=SubStr
> pattern=AF_INET
>
>...and a final catch-all Single rule like
> type=Single
> ptype=RegExp
> pattern=.+
> desc=$0
> action=write <somewhere> unhandled event "$0" at %t
Yup that looks fine, especially with the catchall rule.
>I ran sec with
> # perl sec.pl -conf=sec*.conf -<otherstuff>
>
>The Suppress rules seemed to be fine, but the (temporary, debug) final
>catch-all Single rule still wrote out every single message (including
>those containing "AF_INET") and I couldn't find out why.
>
>I finally found the sentence "Also, note that even if A.conf [...]"
>below "TIMING AND IPC" in the manual. After some more digging I
>finally understood that the immediately following example was no
>solution to my problem, and about the order of configuration files
>instead.
Also, you missed this section of the sec man page:
Rules from the same configuration file are compared with the input
buffer in the order they were given in that file. When multiple
configuration files have been specified, each file containing a
distinct ruleset, events are processed virtually in parallel - the
buffer is always processed by all rulesets.
>So, to help other newbies like me avoid this kind of problem, please
>please pretty please[0] add a hint to the "SUPPRESS RULE" section in
>the manual, like:
Hmm, it applies to all rules, not just suppress so that's the wrong
place to put it IMO. A single rule that fired and supposedly disposed
of the event could still have the event matched by a rule in a later
ruleset.
Perhaps a better place would be a caveat at the description of the
-conf command line parameter.
> [...]
> To suppress those messages too, you have to move or copy your
> Suppress rules to these other configuration files.
While that works, it's makes for a maintainance nightmare as the same
suppress rule is in multiple places. One other solution is to set up a
context based framework that allows rules to indicate that a
particular event was handled, and the other rulesets should ignore it.
Such a framework is used/described at
http://www.cs.umb.edu/~rouilj/sec/. Rather than using suppress, it
would use:
type = single
...
action = create handled
since you need to create a context and suppress can't do that.
Equivalently, given your ruleset structure:
> sec-00-main.conf (main settings, some variables)
> sec-10-suppress.conf (early suppression of irrelevant stuff)
> sec-20-single.conf (early handling of simple, single log entries)
> sec-... (more complicated stuff)
you can set up sec-10-suppress to act like a traffic cop and use it to
identify what ruleset a given event should go to. Then the sec-20
sec-30.... rulesets would not be run by default (see OPTIONS RULE
procallin setting) on every event. They would only be run if the
sec-10-suppress (maybe better named sec-10-sort) ruleset selected an
event to be processed by one or more rulesets.
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/blackberry
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
