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