Hi Robert, On Friday, April 11, 2014 12:19 PM, syslog-ng-bounces@lists.balabit.hu wrote:
Hi,
I guess the problem is that patterndb parsers were not thought to be used this way, and each parser sets the .classifier.class value based on its own rules, overwriting any previous values. Consequently, merging the patterndbs into a single file would definitely work.
As it turns out all of the pattern DBs here (these are just the stock files from: https://github.com/balabit/syslog-ng-patterndb) define the same 'class' (so the results of .classifier.class should always be 'system' after running through each of the parsers, no?).
Another option could be a variant of your second idea: you use a single log statement, and embed the parsers into a junction, where each channel of the junction contains a filter (to process only the messages that the parser can parse), and one of the parsers. Something like: log { filter(f_auth); junction{ channel {filter (program(sshd)); parser("sshd");} channel {filter (program(sudo)); parser("sudo");} .... } }
Thanks, I've tried this and it does appear to address this problem (notwithstanding the fact I mention above, where each pattern file specifies the same .classifier.class value). I'm going to follow-up with another question related to boolean filters and embedded log statements since some of the follow-on filtering criteria now appears unexplainable. Thanks, -David
Robert
On Friday, April 11, 2014 19:18 CEST, David Hauck <davidh@netacquire.com> wrote:
Hello,
I've only recently dug into some more intricate 'syslog-ng' configurations and had a question regarding 'log' construct blocks where multiple 'parser' references exist. I've been trying to do something like the following (testing with the supplied example pattern databases):
log { filter(f_auth); parser("login"); parser("sshd"); parser("su"); parser("sudo"); log { filter(f_class_system); ... }; };
The problem I'm having is that extracted values from matched rules appear to be lost when the matched rule exists in a pattern db *other than the last referenced parser() db*. Specifically, if a rule is matched in the 'sshd' db above the following 'f_class_system' filter (which attempts to match '.classifier.class') *does not* match; however, if a rule is matched in the 'sudo' db above the 'f_class_system' filter *does* match.
I'm sure this is perfectly explainable, but I can't find any documentation/Google references specifically outlining this behaviour. Given the above and in order to work around this I assume I would have to, either: 1) combine all of the rules into a single db file, or 2) break out each 'parser' reference into a separate embedded 'log' construct (not ideal since the filtering et mechanics in each would be identical and for maintenance reasons I'd like to consolidate these into a single 'log' construct). Both options are less than ideal. Is there a better way?
Really appreciate any help you might be able to offer.
Thanks, -David
__________________________________________________________ ____________
________ 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