[syslog-ng] Incompatible Version Warnings
Budai, László
laszlo.budai at balabit.com
Mon Mar 9 10:02:29 CET 2015
Hi,
Well... if this is because of only SLES11 then I agree with your idea:
we should have only one exception for that "null"...
L.
On Mon, Mar 9, 2015 at 9:09 AM, Scheidler, Balázs
<balazs.scheidler at balabit.com> wrote:
> In addition what Gergely just said, this seems to be a genuine bug in the
> system() source as it unconditionally uses newer features, even though the
> version you specified is older than that.
>
> Too bad. the code for the system source is pretty inconvinient a fragile to
> modify, but anyway I wrote an untested patch that should solve this issue.
> However while trying I noticed it is not enough, SCL is pretty incompatible
> with early @version tags. With my 3.7 tree, we are using stuff like
> "template-function" declarations, which is again unsupported in old config
> versions. If stuff like python blocks appear in SCL include files, then the
> entire @version stuff would become futile if the config in question uses
> SCL.
>
> I'm starting to think that new keywords shouldn't be considered identifiers
> even with old config versions, as that's the only thing preventing your
> configuration to work. In that case if someone used a keyword as an
> identifier would have a conflict, but that's probably less likely than an
> inoperable construct in SCL, and I don't want to put too much ifdef mockery
> into SCL itself.
>
> Would you like to try this patch:
>
> $ git diff
> diff --git a/lib/cfg-lexer.c b/lib/cfg-lexer.c
> index 80d36f2..d0fd30c 100644
> --- a/lib/cfg-lexer.c
> +++ b/lib/cfg-lexer.c
> @@ -195,7 +195,7 @@ cfg_lexer_lookup_keyword(CfgLexer *self, YYSTYPE
> *yylval, YYLTYPE *yylloc, const
> if (token[j] == 0 && keywords[i].kw_name[j] == 0)
> {
> /* match */
> - if (cfg_is_config_version_older(configuration,
> keywords[i].kw_req_version))
> + if (0 && cfg_is_config_version_older(configuration,
> keywords[i].kw_req_version))
> {
> msg_warning("WARNING: Your configuration uses a newly
> introduced reserved word as identifier, please use a different name or
> enclose it in quotes before upgrading",
> evt_tag_str("keyword",
> keywords[i].kw_name),
>
>
> Google may clobber the patch itself, but it simply disables the "too new
> keyword for this config version" check and lets syslog-ng process any new
> keywords (such as channel generated by system()).
>
> The entire "too new keyword" used was added becauses SLES 11 used "null" as
> a destination name, which became reserved in 3.1-3.2 timeframe causing
> syntax errors in established configs. We might just add one such exception
> for the "null" keyword and be done with the generic check.
>
> Any opinions?
>
>
>
> --
> Bazsi
>
> On Sat, Mar 7, 2015 at 12:49 AM, Dan Mahoney <dmahoney at isc.org> wrote:
>>
>> Hey there,
>>
>> We have a number of systems that we're trying to deploy syslog-ng on, with
>> puppet, which means we're dealing with multiple versions out there -- so
>> we're trying to stay compatible with 3.4.
>>
>> On a newer version (3.6), we get the following errors on startup:
>>
>> (snip)
>>
>> [2015-03-06T20:47:33.065077] WARNING: Configuration file format is too
>> old, syslog-ng is running in compatibility mode Please update it to use
>> the syslog-ng 3.6 format at your time of convinience, compatibility mode
>> can operate less efficiently in some cases. To upgrade the configuration,
>> please review the warnings about incompatible changes printed by
>> syslog-ng, and once completed change the @version header at the top of the
>> configuration file.;
>> [2015-03-06T20:47:33.096433] WARNING: Starting with syslog-ng 3.6, the
>> system() source performs JSON parsing of messages starting with the
>> '@cim:' prefix. No additional action is needed;
>> [2015-03-06T20:47:33.096495] WARNING: Your configuration uses a newly
>> introduced reserved word as identifier, please use a different name or
>> enclose it in quotes before upgrading; keyword='channel',
>> config-version='3.3', version='3.4', filename='source confgen system',
>> line='1:1'
>> Error parsing source, source plugin channel not found in source confgen
>> system at line 1, column 1:
>> included from
>> /usr/local/etc/syslog-ng.conf line 27, column 9
>>
>> channel
>> ^^^^^^^
>>
>> (snip)
>>
>> I've found if I comment out the "system()" source it makes this error go
>> away, but the requisiste lines are exactly what are referenced in the
>> manual:
>>
>>
>> source s_local {
>> system();
>> internal();
>> };
>>
>> I suppose what's most confusing here, is syslog-ng is trying to tell me
>> exactly where it finds the error, in the word "channel" saying "here,
>> change this, this is the bad word I'm tripping over", but I don't find
>> that word anywhere -- nor does it say *which* included file it's tripping
>> over. Maybe it's telling me that's the word it *needs* to find, but
>> that's less clear.
>>
>> I'm not finding anything in the mailing lists for this.
>>
>> Finally, I should probably ask -- since syslog-ng has the ability to tag
>> your config files with a given version, is there a way to say "use this
>> config if you're on 3.4 and this version if you're on 3.6", so I can stay
>> compatible with the various versions I've got deployed.
>>
>> One other little nit: "Convenience"
>>
>> -Dan Mahoney
>>
>> ______________________________________________________________________________
>> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
>> Documentation:
>> http://www.balabit.com/support/documentation/?product=syslog-ng
>> FAQ: http://www.balabit.com/wiki/syslog-ng-faq
>>
>
>
> ______________________________________________________________________________
> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
> Documentation:
> http://www.balabit.com/support/documentation/?product=syslog-ng
> FAQ: http://www.balabit.com/wiki/syslog-ng-faq
>
>
More information about the syslog-ng
mailing list