On Tue, 1 Feb 2011, Rainer Gerhards wrote:
-----Original Message-----
From: [email protected] [mailto:rsyslog-
[email protected]] On Behalf Of [email protected]
On Tue, 1 Feb 2011, Rainer Gerhards wrote:
-----Original Message-----
From: [email protected] [mailto:rsyslog-
[email protected]] On Behalf Of [email protected]
Sent: Tuesday, February 01, 2011 7:04 AM
To: rsyslog-users
Subject: [rsyslog] notes on parser development with a couple of
questions
the rsyslog git repository is configured to not allow you to check
in
Makefile.am but you must have a file by that name in your
plugins/pm*
directory
question: should this be forced manually with git add -f filename?
or
is
there some other way that this should be done.
I guess you are mixing s/t up: Makefile and Makefile.in are not
accepted, but
Makefile.am is (at least in my git and the central repository).
hmm, you seem to be right. I thought I had tried that. oh well.
the pmaixforwardedfrom submission is missing the Makefile.am file
Can you pls mail it ;)
sent
the parser modules get hold of the string, _after_ it has been
sanitized,
so instead of tab characters you have #011 strings to work with.
question: how can the parser module tell what options were used in
receiving the log message? I am trying to write a snare log receiver
module (which sends tab separated logs), how can I tell if tabs have
been
sanitized when I'm looking at the message?
You can turn the sanitizion off, and also pri parsing. Here are the
settings:
http://git.adiscon.com/?p=rsyslog.git;a=blob;f=tools/pmrfc3164.c;h=38f5
56a2a3
9418fb5ddea3ffff41f55f448fe36c;hb=HEAD#l63
Return RS_RET_NO (actually anything else but OK), and that will not
happen.
I'm not wanting to force the user to turn the settings off, I just want
to
be able to detect if the user has turned them off or not.
the easiest thing would be if I could get the message pre-sanitization
and then after I finish mucking with it, allow it to fall through and
get
sanitized later, but I doubt that's possible.
Ah, I did not explain well enough. This is NOT a user-setting! It just says
if your module wants to have messages sanitized or not. So it tells the core
about your module's needs. Most importantly, it will not affect any other
module. But, for obvious reasons, when any module is run that requires
sanitation, this is carried out by the core and can not be undone after that.
So modul execution order is important.
You want your module to load first, and instruct the core to not use
sanitazion. Then you do whatever you want to the message. When the next
parser (e.g. legacy syslog) is run, it has the sanitation flag set and the
core will *then* call the sanitizer.
The user setting is reflected only inside the sanitizer.
So what the flag in you code says is that you are not "compatible" with
sanitation, that is you do not want it for your needs. I guess this is
exactly what you need.
I hope this clarifies.
this makes sense. I'll have to think about this for a bit. I hate the
thought of building something that won't work depending on module loading
order (or evaluation order), especially something subtle like this.
the snare module I sent should work with the sanitization, If I have some
way to detect that the sanitization has not taken place there is one
#define that would need to be changed.
will the config validation step detect if a parser that is 'incompatible'
with sanitization is loaded after a module that uses sanitization? If that
is detected it would make me much more willing to do things this way.
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
