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

[Tusa Viktor]

Hi David!

If a log message does not match any pattern for a parser, syslog-ng
db-parser sets its .classifier.class to "unknown" regardless of the field's
previous state. So if it matched on a previous parser, the next parser will
overwrite it if it doesn't match on that. I think it's a bug rather than a
feature, so could you please open an issue for that on github?

You can merge patterndb .pdb files easily with "pdbtool merge" command,
which is shipped with syslog-ng. It's simpler than having junctions :).

Best Regards,
Viktor


On Fri, Apr 11, 2014 at 9:52 PM, David Hauck <davidh at netacquire.com> wrote:

> Hi Robert,
>
> On Friday, April 11, 2014 12:19 PM, syslog-ng-bounces at lists.balabit.huwrote:
> > 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
>
> ______________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.balabit.hu/pipermail/syslog-ng/attachments/20140411/428050e3/attachment-0001.htm