[Bug 149] New: patterndb action message does not do variable substitution
https://bugzilla.balabit.com/show_bug.cgi?id=149 Summary: patterndb action message does not do variable substitution Product: syslog-ng Version: 3.3.x Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: unspecified Component: syslog-ng AssignedTo: bazsi@balabit.hu ReportedBy: erempel@uvic.ca Type of the Report: --- Estimated Hours: 0.0 When using a simple message action in a patterndb rule the message can not be populated with any variables. I am not using any correlation, I am just performing the message action every time I match the rule pattern. <rule id="463e34dd-f946-4f25-9cd2-9c00e25eba62" class="cluster" provider="UVic"> <patterns> <pattern>@ESTRING:: @@ESTRING:: @@NUMBER::@ @NUMBER@:@NUMBER@:@NUMBER@.@NUMBER@ @NUMBER@: VERBS RDMA library libibverbs.so failed to load: libibverbs.so: cannot open shared object file: No such file or directory.</pattern> </patterns> <actions> <action> <message> <values> <value name="MESSAGE">$.classifier.rule_id</value> <value name="PROGRAM">patterndb</value> </values> </message> </action> </actions> </rule> results in the verbatim log line of 2011-11-28T10:12:21-08:00 int@catamount.comp.uvic.ca kern.emerg patterndb: $.classifier.rule_id The log line should be 2011-11-28T10:12:21-08:00 int@catamount.comp.uvic.ca kern.emerg patterndb: 463e34dd-f946-4f25-9cd2-9c00e25eba62 -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
The patterndb has a great feature for limiting the rate that actions are executed. The rate limit needs to have a scope within which to count the action events that will in turn determine when the limit has been reached and throttling is to occur. The problem with the current patterndb format is that the context is defined in the rule, which means that I can NOT have different rate contexts for multiple actions for the same rule :-( Am I misreading the patterndb specification? Another not is that I have a case where I want to rate limit an action based on the rule ID. In my case I don't care about which host or process, or process ID the message came from. I know that Balazs will ask for a use case to determine if I am "insane" or if this context-scope of MESSAGE will be of general use. What I am trying to do is determine which patterns are being matched. I would like to generate an action for every match and feed that to a program that will record the date/time that the matching pattern last matched a message. If the pattern has not seen a match for a year, then I can (and probably should) remove it from my pattern database. I don't want my program to have to deal with a rule_id for *every* match. I could safely throttle the matched information to 1 every 10 minutes, or perhaps every hour. That would still let me know if a pattern is "active" and should be kept in the pattern database. Does this sound reasonable (or am I really insane :-) ? Evan.
On Monday, November 28, 2011 19:44 CET, Evan Rempel <erempel@uvic.ca> wrote:
The patterndb has a great feature for limiting the rate that actions are executed. The rate limit needs to have a scope within which to count the action events that will in turn determine when the limit has been reached and throttling is to occur.
The problem with the current patterndb format is that the context is defined in the rule, which means that I can NOT have different rate contexts for multiple actions for the same rule :-(
Am I misreading the patterndb specification? Hi,
If I got that right, you would like to have multiple actions for a rule, and define different rate limits for each action. Like: <actions> <action1 ratelimit1> <action2 ratelimit2> </actions> This should be possible in OSE 3.3, because the rate limit is an option of the action object, not of the actions group. See https://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.3-guid...
Another not is that I have a case where I want to rate limit an action based on the rule ID. In my case I don't care about which host or process, or process ID the message came from.
I know that Balazs will ask for a use case to determine if I am "insane" or if this context-scope of MESSAGE will be of general use.
What I am trying to do is determine which patterns are being matched. I would like to generate an action for every match and feed that to a program that will record the date/time that the matching pattern last matched a message.
If the pattern has not seen a match for a year, then I can (and probably should) remove it from my pattern database.
I don't want my program to have to deal with a rule_id for *every* match. I could safely throttle the matched information to 1 every 10 minutes, or perhaps every hour. That would still let me know if a pattern is "active" and should be kept in the pattern database.
Does this sound reasonable (or am I really insane :-) ?
That's right, this is not currently possible, and using suppress on the triggered messages would not work, because with many rules the triggered messages would be intermixed. And unfortunately correlation does not work either (like adding identical messages to a $RULE_ID context), because every message would update the context timeout, and the contexts of high-traffic patterns would be kept indefinitely (or at least until they eat up the memory). With that said, I see a point for this use case :) One more thought on this: could you try to increase the stats_level() global option to 3, and see if the statistics contain details for patterndb matches? It might be possible that they do (statistics is sadly underdocumented in the admin guide - my fault, sorry). If this works, then you'd only have to query the statistics every ten minutes or so, and process the needed parts with a script. Robert
Evan. ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
Yes, you get the idea. Multiple actions for a single matched message with different rate limits on each. Sadly, I have not yet gotten to the statistics portion of this work, so I can't answer your question, and probably will not be able to for another month (I'm going somewhere warm. Happy me:-) Evan. Fekete Róbert wrote:
On Monday, November 28, 2011 19:44 CET, Evan Rempel <erempel@uvic.ca> wrote:
The patterndb has a great feature for limiting the rate that actions are executed. The rate limit needs to have a scope within which to count the action events that will in turn determine when the limit has been reached and throttling is to occur.
The problem with the current patterndb format is that the context is defined in the rule, which means that I can NOT have different rate contexts for multiple actions for the same rule :-(
Am I misreading the patterndb specification? Hi,
If I got that right, you would like to have multiple actions for a rule, and define different rate limits for each action. Like: <actions> <action1 ratelimit1> <action2 ratelimit2> </actions>
This should be possible in OSE 3.3, because the rate limit is an option of the action object, not of the actions group. See https://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.3-guid...
Another not is that I have a case where I want to rate limit an action based on the rule ID. In my case I don't care about which host or process, or process ID the message came from.
I know that Balazs will ask for a use case to determine if I am "insane" or if this context-scope of MESSAGE will be of general use.
What I am trying to do is determine which patterns are being matched. I would like to generate an action for every match and feed that to a program that will record the date/time that the matching pattern last matched a message.
If the pattern has not seen a match for a year, then I can (and probably should) remove it from my pattern database.
I don't want my program to have to deal with a rule_id for *every* match. I could safely throttle the matched information to 1 every 10 minutes, or perhaps every hour. That would still let me know if a pattern is "active" and should be kept in the pattern database.
Does this sound reasonable (or am I really insane :-) ?
That's right, this is not currently possible, and using suppress on the triggered messages would not work, because with many rules the triggered messages would be intermixed. And unfortunately correlation does not work either (like adding identical messages to a $RULE_ID context), because every message would update the context timeout, and the contexts of high-traffic patterns would be kept indefinitely (or at least until they eat up the memory). With that said, I see a point for this use case :)
One more thought on this: could you try to increase the stats_level() global option to 3, and see if the statistics contain details for patterndb matches? It might be possible that they do (statistics is sadly underdocumented in the admin guide - my fault, sorry). If this works, then you'd only have to query the statistics every ten minutes or so, and process the needed parts with a script.
Robert
Evan. ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
-- Evan Rempel erempel@uvic.ca Senior Systems Administrator 250.721.7691 Unix Services, University Systems, University of Victoria
On Monday, November 28, 2011 21:11 CET, Evan Rempel <erempel@uvic.ca> wrote:
Yes, you get the idea. Multiple actions for a single matched message with different rate limits on each.
That should work.
Sadly, I have not yet gotten to the statistics portion of this work, so I can't answer your question, and probably will not be able to for another month (I'm going somewhere warm. Happy me:-)
Thinking about it, patterndb-related statistics are available in our commercial syslog-ng server appliance (syslog-ng Store Box), so I believe that these stats are available in OSE as well on stats_level 3. Happy Holidays! Robert
Evan.
Fekete Róbert wrote:
On Monday, November 28, 2011 19:44 CET, Evan Rempel <erempel@uvic.ca> wrote:
The patterndb has a great feature for limiting the rate that actions are executed. The rate limit needs to have a scope within which to count the action events that will in turn determine when the limit has been reached and throttling is to occur.
The problem with the current patterndb format is that the context is defined in the rule, which means that I can NOT have different rate contexts for multiple actions for the same rule :-(
Am I misreading the patterndb specification? Hi,
If I got that right, you would like to have multiple actions for a rule, and define different rate limits for each action. Like: <actions> <action1 ratelimit1> <action2 ratelimit2> </actions>
This should be possible in OSE 3.3, because the rate limit is an option of the action object, not of the actions group. See https://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.3-guid...
Another not is that I have a case where I want to rate limit an action based on the rule ID. In my case I don't care about which host or process, or process ID the message came from.
I know that Balazs will ask for a use case to determine if I am "insane" or if this context-scope of MESSAGE will be of general use.
What I am trying to do is determine which patterns are being matched. I would like to generate an action for every match and feed that to a program that will record the date/time that the matching pattern last matched a message.
If the pattern has not seen a match for a year, then I can (and probably should) remove it from my pattern database.
I don't want my program to have to deal with a rule_id for *every* match. I could safely throttle the matched information to 1 every 10 minutes, or perhaps every hour. That would still let me know if a pattern is "active" and should be kept in the pattern database.
Does this sound reasonable (or am I really insane :-) ?
That's right, this is not currently possible, and using suppress on the triggered messages would not work, because with many rules the triggered messages would be intermixed. And unfortunately correlation does not work either (like adding identical messages to a $RULE_ID context), because every message would update the context timeout, and the contexts of high-traffic patterns would be kept indefinitely (or at least until they eat up the memory). With that said, I see a point for this use case :)
One more thought on this: could you try to increase the stats_level() global option to 3, and see if the statistics contain details for patterndb matches? It might be possible that they do (statistics is sadly underdocumented in the admin guide - my fault, sorry). If this works, then you'd only have to query the statistics every ten minutes or so, and process the needed parts with a script.
Robert
Evan. ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
-- Evan Rempel erempel@uvic.ca Senior Systems Administrator 250.721.7691 Unix Services, University Systems, University of Victoria
The statistics may address my current needs, however, I think there will be many more cases where multiple actions may benefit from rate limiting on different scopes. For instance, if I wanted to feed a program() destination that sends e-mail, I may wish to rate limit for each destination address. This can't be done inside patterndb at all since you can not select an arbitrary string as the context_scope, nor could you send email to two different destinations for the same match and have them rate limited differently. A real world example of this is that we are going to tag messages with "Network Operations Center" tags, so they can then be sent to alerting systems and ticketing systems. We will want to rate limit these events on a "destination address/problem keywords (ticket queue/host/app/state)" type of context_scope. We will have to do this external to syslog-ng for now, but the problem with that is if syslog-ng feeds data to the external program without a rate limit, the program may not be able to keep up, and some events will get dropped. If an arbitrary string, possibly with macro/variable expansion, the rate limiting feature would be much more versatile. Evan. Fekete Róbert wrote:
On Monday, November 28, 2011 21:11 CET, Evan Rempel <erempel@uvic.ca> wrote:
Yes, you get the idea. Multiple actions for a single matched message with different rate limits on each.
That should work.
Sadly, I have not yet gotten to the statistics portion of this work, so I can't answer your question, and probably will not be able to for another month (I'm going somewhere warm. Happy me:-)
Thinking about it, patterndb-related statistics are available in our commercial syslog-ng server appliance (syslog-ng Store Box), so I believe that these stats are available in OSE as well on stats_level 3.
Happy Holidays!
Robert
Evan.
Fekete Róbert wrote:
On Monday, November 28, 2011 19:44 CET, Evan Rempel <erempel@uvic.ca> wrote:
The patterndb has a great feature for limiting the rate that actions are executed. The rate limit needs to have a scope within which to count the action events that will in turn determine when the limit has been reached and throttling is to occur.
The problem with the current patterndb format is that the context is defined in the rule, which means that I can NOT have different rate contexts for multiple actions for the same rule :-(
Am I misreading the patterndb specification? Hi,
If I got that right, you would like to have multiple actions for a rule, and define different rate limits for each action. Like: <actions> <action1 ratelimit1> <action2 ratelimit2> </actions>
This should be possible in OSE 3.3, because the rate limit is an option of the action object, not of the actions group. See https://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.3-guid...
Another not is that I have a case where I want to rate limit an action based on the rule ID. In my case I don't care about which host or process, or process ID the message came from.
I know that Balazs will ask for a use case to determine if I am "insane" or if this context-scope of MESSAGE will be of general use.
What I am trying to do is determine which patterns are being matched. I would like to generate an action for every match and feed that to a program that will record the date/time that the matching pattern last matched a message.
If the pattern has not seen a match for a year, then I can (and probably should) remove it from my pattern database.
I don't want my program to have to deal with a rule_id for *every* match. I could safely throttle the matched information to 1 every 10 minutes, or perhaps every hour. That would still let me know if a pattern is "active" and should be kept in the pattern database.
Does this sound reasonable (or am I really insane :-) ? That's right, this is not currently possible, and using suppress on the triggered messages would not work, because with many rules the triggered messages would be intermixed. And unfortunately correlation does not work either (like adding identical messages to a $RULE_ID context), because every message would update the context timeout, and the contexts of high-traffic patterns would be kept indefinitely (or at least until they eat up the memory). With that said, I see a point for this use case :)
One more thought on this: could you try to increase the stats_level() global option to 3, and see if the statistics contain details for patterndb matches? It might be possible that they do (statistics is sadly underdocumented in the admin guide - my fault, sorry). If this works, then you'd only have to query the statistics every ten minutes or so, and process the needed parts with a script.
Robert
Evan. ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
-- Evan Rempel erempel@uvic.ca Senior Systems Administrator 250.721.7691 Unix Services, University Systems, University of Victoria
-- Evan Rempel erempel@uvic.ca Senior Systems Administrator 250.721.7691 Unix Services, University Systems, University of Victoria
I am attempting to parse information from a message that is proving difficult. The data is of the form; this data:should be:parsed:on colons but the only tool I have to use is ESTRING since the text between the : characters may contain spaces. The problem is that ESTRING will return the text AND the : following it. I got to thinking some more (and that is dangerous for everyone) and realized that I can not parse the key words are (one two three) to look at and get a variable that matches (one two three) because QSTRING does not include the braces. I would like to see something like ESTRING - return all the text up to and include the terminator character eSTRING - return all the text up to but NOT including the terminator character But now I have a problem. For consistency I would like to see QSTRING - return all of the quoted text including the quote characters qSTRING - return all of the quoted text excluding the quote characters. These would be consistent with ESTRING and eSTRING but would be inconsistent with the current use of QSTRING. There was a recent patch submitted for SET, that I would change to MSET - return all of the text (M)atching any character in the set mSET - return all of the text not (m)atching any character in the set So I am asking for suggestions on how to get my new eSTRING and my changed QSTRING functionality? comments? suggestions? Evan
Having a discussion with myself :-) I still prefer my recommended parsers commands from my previous mail included below, however, if breaking backwards compatibility is thought to be too much of a hurdle, I could be convinced to go with these options. Rather than eSTRING, the parser SSTRING (stop string) could return the data excluding the stop string. Rather than changing QSTRING, CSTRING (cite string) could return the quoted data including the quoting characters. The MSET and mSET would seem out of place using these parser names, so I would recommend MATCH - return data matching any of the characters specified EXCLUDE - return data that does not match any of the characters specified. I thought this topic would generate a lot of discussion, but that's just me. Evan. ________________________________________ From: Evan Rempel [erempel@uvic.ca] Sent: Wednesday, November 30, 2011 12:51 PM To: Syslog-ng users' and developers' mailing list Subject: Another patterndb limitation I am attempting to parse information from a message that is proving difficult. The data is of the form; this data:should be:parsed:on colons but the only tool I have to use is ESTRING since the text between the : characters may contain spaces. The problem is that ESTRING will return the text AND the : following it. I got to thinking some more (and that is dangerous for everyone) and realized that I can not parse the key words are (one two three) to look at and get a variable that matches (one two three) because QSTRING does not include the braces. I would like to see something like ESTRING - return all the text up to and include the terminator character eSTRING - return all the text up to but NOT including the terminator character But now I have a problem. For consistency I would like to see QSTRING - return all of the quoted text including the quote characters qSTRING - return all of the quoted text excluding the quote characters. These would be consistent with ESTRING and eSTRING but would be inconsistent with the current use of QSTRING. There was a recent patch submitted for SET, that I would change to MSET - return all of the text (M)atching any character in the set mSET - return all of the text not (m)atching any character in the set So I am asking for suggestions on how to get my new eSTRING and my changed QSTRING functionality? comments? suggestions? Evan
Hi Evan, I like the idea of optionally including/excluding the stop characters, as both are valid usecases that can come handy. I do not know about the technical details, that is, how it is best to implement it. From usability point of view, I'd prefer using a flag/option in the parser, as it would make recognizing the option easier. I think that changing the capitalization of the parser is not too intuitive and can lead to errors and user frustration (but then again, this might be the least frustration in getting patterndb to work :) ). Robert On 12/02/2011 07:33 AM, Evan Rempel wrote:
Having a discussion with myself :-)
I still prefer my recommended parsers commands from my previous mail included below, however, if breaking backwards compatibility is thought to be too much of a hurdle, I could be convinced to go with these options.
Rather than eSTRING, the parser SSTRING (stop string) could return the data excluding the stop string. Rather than changing QSTRING, CSTRING (cite string) could return the quoted data including the quoting characters.
The MSET and mSET would seem out of place using these parser names, so I would recommend MATCH - return data matching any of the characters specified EXCLUDE - return data that does not match any of the characters specified.
I thought this topic would generate a lot of discussion, but that's just me.
Evan. ________________________________________ From: Evan Rempel [erempel@uvic.ca] Sent: Wednesday, November 30, 2011 12:51 PM To: Syslog-ng users' and developers' mailing list Subject: Another patterndb limitation
I am attempting to parse information from a message that is proving difficult. The data is of the form;
this data:should be:parsed:on colons
but the only tool I have to use is ESTRING since the text between the : characters may contain spaces.
The problem is that ESTRING will return the text AND the : following it.
I got to thinking some more (and that is dangerous for everyone) and realized that I can not parse
the key words are (one two three) to look at
and get a variable that matches (one two three) because QSTRING does not include the braces.
I would like to see something like
ESTRING - return all the text up to and include the terminator character eSTRING - return all the text up to but NOT including the terminator character
But now I have a problem. For consistency I would like to see
QSTRING - return all of the quoted text including the quote characters qSTRING - return all of the quoted text excluding the quote characters.
These would be consistent with ESTRING and eSTRING but would be inconsistent with the current use of QSTRING.
There was a recent patch submitted for SET, that I would change to
MSET - return all of the text (M)atching any character in the set mSET - return all of the text not (m)atching any character in the set
So I am asking for suggestions on how to get my new
eSTRING and my changed QSTRING functionality?
comments? suggestions?
Evan
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
https://bugzilla.balabit.com/show_bug.cgi?id=149 --- Comment #1 from Balazs Scheidler <bazsi@balabit.hu> 2011-11-28 20:49:51 --- when a variable contains non-alpha-numeric characters (dot in this case), you need to use braces. ${.classifier.rule_id} -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=149 --- Comment #2 from Evan Rempel <erempel@uvic.ca> 2011-11-28 20:53:25 --- Using the braces does not change the way that it works. <actions> <action context-scope="program" trigger="match"> <rate>1/60</rate> <message> <values> <value name="MESSAGE">message id ${.classifier.rule_id}</value> <value name="PROGRAM">patterndb</value> </values> </message> </action> </actions> generates the line 2011-11-28T11:52:29-08:00 int@catamount.comp.uvic.ca kern.emerg patterndb: message id 2011-11-28T11:52:29-08:00 int@catamount.comp.uvic.ca kern.emerg patterndb: message id -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=149 --- Comment #3 from Balazs Scheidler <bazsi@balabit.hu> 2011-11-28 20:56:37 --- one additonal thing: @0 is the new message being generated by the action and not the matched one. what about ${.classifier.rule_id}@1 ? -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=149 --- Comment #4 from Evan Rempel <erempel@uvic.ca> 2011-11-28 20:58:48 --- Yes, using the {..}@1 produces the messages 2011-11-28T11:58:10-08:00 int@catamount.comp.uvic.ca kern.emerg patterndb: message id 463e34dd-f946-4f25-9cd2-9c00e25eba62 2011-11-28T11:58:10-08:00 int@catamount.comp.uvic.ca kern.emerg patterndb: message id 463e34dd-f946-4f25-9cd2-9c00e25eba62 -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=149 --- Comment #5 from Evan Rempel <erempel@uvic.ca> 2011-11-29 21:38:29 --- Oops. I spoke too soon. ${classifier.rule_id}@1 only works if a context-id="xxx" has been specified for the rule. I'm not sure if that was the intention or not. I think that these values should be available for rules that have no context ID. Evan. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=149 --- Comment #6 from Balazs Scheidler <bazsi@balabit.hu> 2011-11-29 22:04:50 --- hmm maybe no mesage context is opened in that case. this is definitely a discrepancy that should be solved. -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.balabit.com/show_bug.cgi?id=149 Balazs Scheidler <bazsi@balabit.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution| |FIXED Status|NEW |RESOLVED --- Comment #7 from Balazs Scheidler <bazsi@balabit.hu> 2011-12-17 20:26:17 --- This patch should fix this behaviour (but at the same time it is an incompatible change for those who worked around the previous broken behaviour) commit 97353039a7441090a49e6002a6bbe38f5b8a0e52 Author: Balazs Scheidler <bazsi@balabit.hu> Date: Sat Dec 17 20:22:07 2011 +0100 dbparser: fixed message indexing in action rules with no correllation (incompatible) Actions that are attached to rules having context-id (e.g. correllation), use @0 for the message being generated and @1 the last message in the context. This is inconsistent with rules that have no correllation, where @0 was the triggering message. This patch fixes this behaviour, but at the same time it is incompatible with previous versions. Reported-By: Evan Rempel <erempel@uvic.ca> Signed-off-by: Balazs Scheidler <bazsi@balabit.hu> -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (4)
-
bugzilla＠bugzilla.balabit.com
-
Evan Rempel
-
Fekete Robert
-
Fekete Róbert