[syslog-ng] config file parsing bugs in syslog-ng 3.0.7

[Balazs Scheidler]

Hi,

On Mon, 2010-07-26 at 19:43 -0700, Matthew Hall wrote:
> Hello list,
> 
> In the course of my work I discovered two small defects in syslog-ng 
> syslog-ng 3.0.7. Since I am not familiar enough with the code to patch 
> these I am trying to do the best I can by reporting them to the experts. 
> There are workarounds for these.
> 
> I am in the process of doing some other work on the product which I 
> would like to contribute back in the near future after I figure out how 
> the open-source contribution process works at this new company I joined.
> 
> Thank you for providing this product. I am impressed with the 
> documentation and all of the capabilities and I look forward to becoming 
> more expert with it over the coming few months.

Great to hear, we're always happy for more contributors. :) See my last
blog posts on the topic.

> 
> Best Regards,
> Matthew Hall.
> 
> 1) specifying the flags directive in a log stanza other than in the last 
> position causes a syntax error
> 
> This specific format works:
> 
> log {
>     filter(filter_local1);
>     destination(dst_local1);
>     parser(parse_switch);
>     flags(final);
> };
> 
> Any format like this raises an error:
> 
> log {
>     filter(filter_local1);
>     destination(dst_local1);
>     flags(final);
>     parser(parse_switch);
> };
> 
> Is there some reason why or just a parser glitch?

Yup, this was changed in 3.0, where the log path directive was
generalized. A log path can include branches to form a tree, rooted at
the source and the destinations being the leafs.

Message changes (e.g. rewrite rules) do not propagate over parallel
branches.

The syntax is like this:

log {
	source(s_all);
	log { filter(f_branch1); destination(d_branch1); };
	log { filter(f_branch2); destination(d_branch2); };
	flags(final);
};

So the flags can really appear at the last position.

> 
> 2) using a version directive newer than the daemon version has 
> unexpected behavior
> 
> If I feed 3.0 a file marked with @version: 3.1 tag, I get this error:
> 
> Configuration file has no version number, assuming syslog-ng 2.1 format. 
> Please add @version: maj.min to the beginning of the file;
> 
> I think it does not make sense to fall back to the oldest format if the 
> file has a newer version tag. Would it be better to try to process the 
> file as the newest version with a warning, or print an error that the 
> file is too new for 3.0 to read?

True enough, I've pushed these patches to syslog-ng 3.2 that implements
what you describe.

commit fb5c1444177e520124d578049dd53546faeaeb7c
Author: Balazs Scheidler <bazsi at balabit.hu>
Date:   Wed Jul 28 09:58:10 2010 +0200

    cfg: report too new config versions as well

commit 021ca88602ea04628ad426923215aeb7adfae8a3
Author: Balazs Scheidler <bazsi at balabit.hu>
Date:   Wed Jul 28 09:57:53 2010 +0200

    cfg-grammar: save the original formatting of LL_NUMBER/LL_FLOAT tokens
    
    Previously such tokens were reformatted in the case of the "string_or_number"
    rule, causing problems when the version number in the @version directive was
    parsed as 3.20 instead of 3.2.


-- 
Bazsi