[syslog-ng] consecutive pattern parsers, and some other pattern matching questions

[Balazs Scheidler]

On Tue, 2011-03-01 at 20:56 +0100, Valentijn Sessink wrote:
> Balázs, Marci, list,
> 
> Op 01-03-11 20:21, Balazs Scheidler schreef:
> > On Sun, 2011-02-20 at 17:00 +0100, Valentijn Sessink wrote:
> >> Op 20-02-11 14:25, Balazs Scheidler schreef:
> >>>> Yes, you can, but at a cost. To match one message with two patterns, you
> >>>> will need two different pattern databases:
> >>>> parser db1 {db_parser(file("/var/lib/syslog-ng/db1.xml"));};
> >>>> parser db2 {db_parser(file("/var/lib/syslog-ng/db2.xml"));};
> >>> Can you explain why you needed this? Why couldn't you do all processing
> >>> in your single rule?
> >> My question came from Postfix
> [cut: explanation about double message trails]
> > That really is a problem, you basically need two correllation states for
> > the same message, while I originally envisioned one. In fact the first
> > designs permitted this scenario as well, but the final design doesn't.
> 
> I don't understand your findings. If I'm having two db_parser entries in
> syslog-ng.conf, it does work, or doesn't it?

Yes, that works, and will do. The original intention of db-parser()
however is to do all kind of log -> event translation with the same
database.

Having to configure two of them is possible, but doesn't fit the
vision :)

> 
> But before you all start programming, please note that the very question
> came because I was interested in syslog-ng as a message parser for the
> very reason Balázs has put on his blog: getting syslog-ng to spit out
> evil IP addresses.
> 
> The rest of my tests were only conducted to see if I understood the
> pattern matching; I'm not currently using an smtpd correlating state
> machine, and I'm pretty sure I won't need the extra complexity of an
> *additional* smtpd connect/disconnect correlating pattern.
> 
> So, to summarize:
> 1) I'm pretty sure I can do without the double matching. I asked out of
> curiousity; I got things to work "sort-of". However...
> 2) If you think my solution (two db_pattern files with the same
> patterns) doesn't work in practice, then you might warn that there's a
> "collision" between these two databases.
> 
> As said, having two separate db_parser files did seem to solve the
> problem - but I could be wrong, of course. (In which case you might want
> to enlighten me ;)

It's just your use-case seems to be a perfectly valid scenario. We can
rule it out for now, but I guess it'll come back later :)

-- 
Bazsi