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

[David Hauck]

Hi Robert,
 
On Friday, April 11, 2014 12:19 PM, syslog-ng-bounces at 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 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
>> 
>> 
> 
> 
> 
> 
> 
> 
> __________________________________________________________
> ____________________ 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