On Fri, 2013-03-15 at 17:03 -0400, Miloslav Trmac wrote: > Hello, > ----- Original Message ----- > > However, when using both features lets users override the trusted > > properties. > > I guess It's because the JSON parsing takes place after the trusted > > properties parsing. > <snip> > > Is there a way to make mmjsonparse parses the CEE payload before parsing > > the trusted properties ? (making the trusted properties override user > > fields) > > Alternatively, is there a way to make mmjsonparse put user data in a > > subtree ? > > Back in October Milan was working on a patch to modify mmjsonparse not to > override existing message properties (IOW, the "trusted" properties from > imuxsock would not be overwritten by JSON content of the message). It seems > that the "nonoverwrite" branch was never merged. > > I'm afraid after that time I can't remember whether the branch was finished > and ready for merging and/or acceptable by Rainer, and my mail archives don't > tell either - Milan?
I think I (barely) remember a merge request that I needed to reject because it disabled the ability to overwrite JSON variables at all. That would have prevented many things inside rsyslog, most importantly the "set" and "unset" statements. I think I don't remember any updated version. In the light of what is being discussed here, it would probably be sufficient to, inside mmjsonparse, provide an ability to check if a property is already present and, if so, do not update it. I also remember a mailing list discussion that talked about trusted fields, and I think I remember that we concluded it is somewhat messy, as we need to keep a list of trusted field names, because they are not contained inside some container. David's points go into that direction, and I think he made the same (valid) comments a couple of month ago. IIRC, the conclusion was that this is simply how it is in CEE/lumberjack, and we need to live with that. I also remember that we (I?) thought about providing config options to create such a container (Which would ease things). Maybe it would make sense to talk to the syslog-ng guys and see if we can reach agreement on containers - that would probably mean 90% of syslog installations. 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.
