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@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