+1 for permitEmpty=on - it would definitely simplify our lives. Brian
On Tue, Nov 11, 2014 at 11:40 AM, Boylan, James <[email protected]> wrote: > I think that the "permitEmpty=on" field is a reasonable starting place. I > have a config management app that I use with rsyslog that this field would > help significantly with. > > -- James > --- Sent from my mobile phone --- > > ----- Reply message ----- > From: "Rainer Gerhards" <[email protected]> > To: "rsyslog-users" <[email protected]> > Subject: [rsyslog] ruleset with only stop > Date: Tue, Nov 11, 2014 10:29 AM > > 2014-11-11 17:22 GMT+01:00 David Lang <[email protected]>: > > > On Tue, 11 Nov 2014, Brian Knox wrote: > > > > Rainer, > >> > >> I agree that an empty ruleset is an oddity. In our case, the short > answer > >> is that we are generating configurations from templates using chef, and > >> the > >> ability to have a ruleset that simply discards would make part of that > >> process much simpler for us. > >> > >> It is admittedly an edge case. > >> > > > > It's an edge case, but I think it's one that should be supported if > > possible. > > > > automated config generation is very useful, and being able to group rules > > into rulesets and call them with the calling function not having any idea > > of what is going to happen with the logs at that point is very useful, > > being able to have a high level config split the logs up and call > different > > rulesets on different logs without having to worry if the ruleset does > > something with the logs or just throws them away is _very_ useful. > > > > So it is a corner case, but I think it's a valuable one to support. > > > > > ack > > > > I would suggest that at config load time, that this is an odd enough > > corner case that it's worth logging a "ruleset X can't do anything with > the > > logs" message, not just for the case where the only action is to throw it > > away, but also for the cases where the conditions in a ruleset cannot > > possibly match any log message (if priority = info then *.crit also > cannot > > match anything for example) > > > > > Let's start with what we have on the table. I think it is best to add a > ruleset parameter "permitEmpty=on". That way, we don't generate > error/warning messages when the user is aware of what he is doing. In any > manual case (without config gen), I'd still say that's an error indication. > > On the topic of no filter matches. That's quite complex, as you would need > to evaluate all the filters and possible conditions. Not sure if it can > even reliably done. Am I overlooking something? > > Rainer > > > > David Lang > > > > > > Brian > >> > >> > >> > >> On Tue, Nov 11, 2014 at 4:06 AM, Rainer Gerhards < > >> [email protected]> > >> wrote: > >> > >> 2014-11-10 16:23 GMT+01:00 Brian Knox <[email protected]>: > >>> > >>> Today I noticed a ruleset with only "stop" as it's action will fail to > >>>> parse with rsyslog 8.4, but the same rule with a "~" will pass. > >>>> > >>>> ruleset(name="testme") { > >>>> *.* ~ > >>>> } > >>>> > >>>> bknox@seriamau:~$ rsyslogd -N1 -f ./test.conf > >>>> rsyslogd: version 8.5.0, config validation run (level 1), master > config > >>>> ./test.conf > >>>> rsyslogd: warning: ~ action is deprecated, consider using the 'stop' > >>>> statement instead [try http://www.rsyslog.com/e/2307 ] > >>>> > >>>> > >>>> Changing to "stop" : > >>>> ruleset(name="testme") { > >>>> stop > >>>> } > >>>> > >>>> bknox@seriamau:~$ rsyslogd -N1 -f ./test.conf > >>>> rsyslogd: version 8.5.0, config validation run (level 1), master > config > >>>> ./test.conf > >>>> rsyslogd: CONFIG ERROR: there are no active actions configured. Inputs > >>>> > >>> will > >>> > >>>> run, but no output whatsoever is created. [try > >>>> http://www.rsyslog.com/e/2103 > >>>> ] > >>>> rsyslogd: run failed with error -2103 (see rsyslog.h or try > >>>> http://www.rsyslog.com/e/2103 to learn what that number means) > >>>> > >>>> I have a situation where rules are being generated via templates in > >>>> chef, > >>>> and having a rule that just discards messages would actually be a > useful > >>>> thing to have, and ran into this. > >>>> > >>>> So my question is, should a rule that only calls a discard action be > >>>> valid? If so, is this a bug in the config parser? > >>>> > >>>> > >>>> It's a little bit complex. The thing is that "~" actually *is* an > >>> action, > >>> whereas "stop" is a statement. When I wrote that checking code, I never > >>> envisioned that an empty ruleset could be useful for any case (if there > >>> is > >>> just a "stop" inside it, it's practically empty, in that it simply does > >>> nothing). I think in most cases this really is a config error. Maybe I > >>> could add an "permitEmpty" parameter to the ruleset, which will then > not > >>> emit that error message. > >>> > >>> To understand the whole picture: why do you need these empty rulesets? > >>> > >>> Rainer > >>> > >>> Brian > >>> > >>>> _______________________________________________ > >>>> 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. > >>> > >>> _______________________________________________ > >> 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. > > > _______________________________________________ > 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. > _______________________________________________ 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.
