[syslog-ng] Correct Usage of Multiple 'pattern' Databases

Fekete Róbert frobert at balabit.hu
Fri Apr 11 21:18:50 CEST 2014


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. 

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");}
....
  }
}

Robert

On Friday, April 11, 2014 19:18 CEST, David Hauck <davidh at 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
> 
> 
 
 
 
 




More information about the syslog-ng mailing list