[syslog-ng] $DAY Macro not RFC Compliant

[Balazs Scheidler]

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