On Tue, 30 Apr 2013, Rainer Gerhards wrote:
So in essence this is a search-and-replace of some message fields,
and
the fields are permanently replaced with the new value, right?
Yep.
Couple of questions before I can decide if such a thing makes sense
inside rsyslog:
Is there an advantage of replacing the original content vs. just
replacing the value in the output part? In other words: what's the
use
case? (I ask because in the past 10 years nobody ever requested such
a
feature).
My case was very simple: trimming long program names to shorter for
saving disk space.
But in general this universal functionality can be used for masking
CreditCards numbers in PCI environments log, for anonymization IP
addresses what you introduced in v7.3.7
http://blog.gerhards.net/2013/04/log-anonymization-with-rsyslog.html,
for filter out unnecessary data from logs before sending it to other
log or writing to disk, DB.
In real live we can face with case when is not possible change log
data on client side...
I agree that these are use cases, but they must be used very careful, as false
positives are easy to get with search-and-replace. Wouldn't work well on IP
addresses, for example, as you need to zero out bits (at least under many
legislations).
I core question you have not yet answered is why this must MODIFY the ORIGINAL
message instead of not just modifying the OUTPUT (what you can do with
templates).
I don't think there is a need to modify the original message
$!newfar = sed("regex","newtext",$!oldvar)
should get the job done.
I agree that modifying the original message (or worse, a portion of the original
message) and then having to re-parse it to properly update all the derived
variables is extremely ugly.
David Lang
What if fields are interdependent, for example msg is a virtual
property
which points into rawmsg. So if one is changed, the other changes as
well.
In general, if e.g. fromhost is changed, should/must that be
reflected
in rawmsg? Or is it OK if for some properties things become
inconsistent
(but for others not, like rawmsg/msg pair).
If we can change fromhost in real(not virtual) property then in
virtual property it should change aswell.
Personally I don't see any problems with this.
It's very computationally-intense, as it needs to trigger a re-parse of the
message. What also makes it very complex, because that means we need to re-run
the parser chain, something the interface is definitely not designed for.
If e.g. the fromhost is changed, what happens to associated IP
addresses?
Any answer to that?
For fields with required syntax (e.g. fromhost), is a syntax check
necessary? (because otherwise you could include malicious sequences).
Or to this?
Thanks,
Rainer
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
