On Mon, 2010-05-10 at 10:03 -0500, Michael Starks wrote:

I have a situation where I am trying to construct a RFC3164-compliant message from component parts of a non-compliant message.

The non-compliant message expresses the day as dd, and if the day is before the tenth of the month, it is 0d. I thought it would be better to use the syslog-ng $DAY macro, but I learned that it also does the same thing. The RFC, however, requires two-digit days to be expressed as " d" (space digit) when the day is before 10.

I then thought that perhaps I could just rewrite the day as expressed by the original message, which is actually my preference, using a rewrite rule. As a test, I tried this:

rewrite r_test{ subst("07", " 7", value("${PARSER.DD}")); };

This attempted to change "07" to " 7" in PARSER.DD, which has been successfully extracted in a former parser.

And of course I attempt to use it in a log statement (some names have been changed for demonstration purposes):

log { source(s_source); parser(p_parser); filter(f_filter); destination(d_destination); rewrite(r_test);};

So my questions are:

1. Why is the $DAY macro not RFC3164-compliant? Is that a design choice? Was it simply never meant to be?

well, I'd say I haven't thought about this implication. The primary use for macros was in filenames (e.g. /var/log/messages.$YEAR.$MONTH.$DAY) in which case space would be a problem. I never wanted to handcraft BSD-like dates before using macros, nor have received such a report. Why is that necessary? You want to rewrite the date portion of a syslog message?

2. Why doesn't the rewrite rule work? I know PARSER.DD has been successfully extracted because I can use it in a destination.

I guess because it is after your destination statement. Starting with 3.0 the order in log statements do matter, simply because what you describe is a graph of primitive log processing elements. Anything in syslog-ng (filter, parser, rewrite, destination, but also sources) are "pipes" that get connected during configuration initialization. The order of log statements and the statements inside a log statements describe in which order a pipe is constructed. But you can also nest log statements starting with 3.0: log { source(s_all); filter(f_step1); log { filter(f_step2a); destination(d_step2a); }; log { filter(f_step2b); destination(d_step2b); }; } e.g the f_step1 filter will apply to _both_ of the following two embedded log statements. -- Bazsi