Ok then I need to see how I can fiddle that into the grammar ;)
Sent from phone, thus brief.
Am 19.11.2014 19:56 schrieb "David Lang" <da...@lang.hm>:
> On Wed, 19 Nov 2014, Rainer Gerhards wrote:
>
> 2014-11-19 16:40 GMT+01:00 Brian Knox <bk...@digitalocean.com>:
>>
>> Ok - perhaps we have accidently conflated two problems:
>>>
>>> 1) An empty ruleset
>>> 2) A ruleset with only "stop"
>>>
>>> this will pass validation:
>>>
>>> ------------------------------------
>>> ruleset(name="foo") {
>>> stop
>>> }
>>> *.* /var/log/test
>>> call foo
>>> ------------------------------------
>>>
>>> If the ruleset is empty, however, it will not:
>>>
>>> ------------------------------------
>>> ruleset(name="foo") {
>>> }
>>> *.* /var/log/test
>>> call foo
>>> ------------------------------------
>>>
>>> rsyslogd: version 8.5.0, config validation run (level 1), master config
>>> ./test.conf
>>> rsyslogd: error during parsing file ./test.conf, on or before line 2:
>>> syntax error on token '}' [try http://www.rsyslog.com/e/2207 ]
>>> rsyslogd: CONFIG ERROR: could not interpret master config file
>>> './test.conf'. [try http://www.rsyslog.com/e/2207 ]
>>> rsyslogd: run failed with error -2207 (see rsyslog.h or try
>>> http://www.rsyslog.com/e/2207 to learn what that number means)
>>>
>>>
>>> OK, that's a different question. Is the consensus we need to support
>> this
>> as well?
>>
>
> I think so, with a warning reported at startup or something like that.
>
> David Lang
>
> Rainer
>>
>>
>> Brian
>>>
>>>
>>>
>>> On Wed, Nov 19, 2014 at 10:35 AM, Brian Knox <bk...@digitalocean.com>
>>> wrote:
>>>
>>> For verifying the problem I ran rsyslog -N1 -f against just the subset
>>>> of
>>>> the config, if I recall correctly. I believe my coworker had the same
>>>> issue with the full config that definitely had actions in it - but I'll
>>>>
>>> ask
>>>
>>>> him to reproduce with the full configuration. Thanks!
>>>>
>>>> Brian
>>>>
>>>> On Wed, Nov 19, 2014 at 10:13 AM, Rainer Gerhards <
>>>> rgerha...@hq.adiscon.com> wrote:
>>>>
>>>> Brian,
>>>>>
>>>>> I just revisited this problem report. I have now taken a look at the
>>>>>
>>>> code.
>>>
>>>> The error message actually tells you that there is no action inside the
>>>>> *entire config*, not just an empty ruleset. Can you confirm there was
>>>>> nothing else in the config? If not, can you send me the config, so that
>>>>>
>>>> I
>>>
>>>> can try to see what's going on.
>>>>>
>>>>> I assume we agree that a totally action-less config is an error ;)
>>>>>
>>>>> Rainer
>>>>>
>>>>> 2014-11-11 22:49 GMT+01:00 Brian Knox <bk...@digitalocean.com>:
>>>>>
>>>>> If was able to use an empty ruleset, a warning resulting from that
>>>>>>
>>>>> wouldn't
>>>>>
>>>>>> bother me at all.
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>> On Tue, Nov 11, 2014 at 4:25 PM, David Lang <da...@lang.hm> wrote:
>>>>>>
>>>>>> On Tue, 11 Nov 2014, Rainer Gerhards wrote:
>>>>>>>
>>>>>>> 2014-11-11 17:22 GMT+01:00 David Lang <da...@lang.hm>:
>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>> I think that this is a sufficently corner case that I'm not sure
>>>>>>>
>>>>>> it's
>>>
>>>> worth the extra complexity to silence the warning. I think that
>>>>>>>
>>>>>> people
>>>
>>>> who
>>>>>>
>>>>>>> do this intentionally can just ignore the log message.
>>>>>>>
>>>>>>> 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?
>>>>>>>>
>>>>>>>>
>>>>>>> I am not saying that it should try to catch every possible case,
>>>>>>>
>>>>>> but I
>>>
>>>> was
>>>>>>
>>>>>>> thinking that the configuration optimization step would "optomize
>>>>>>>
>>>>>> away"
>>>>>
>>>>>> some impossible combinations, and that could result in an empty
>>>>>>>
>>>>>> ruleset.
>>>>>
>>>>>>
>>>>>>> David Lang
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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.
