[syslog-ng] Change the facility or the priority of a syslog message ?
Balazs Scheidler
bazsi at balabit.hu
Mon Apr 5 09:02:08 CEST 2010
Hi,
On Thu, 2010-04-01 at 17:55 +0200, Ilas, Yann wrote:
> ..So I changed the rule "r_rewrite_set" to modify the value to
> "facility" :
>
> rewrite r_rewrite_set {
>
> set (
>
> "local4"
>
> value("FACILITY")
>
> );
>
> };
>
> And when I restarted the syslog-ng, I had the following errors :
>
> # /etc/init.d/syslog-ng restart
>
> Macros are read-only, they cannot be changed in rewrite rules, falling
> back to MESSAGE instead; macro='FACILITY'
>
> Restarting syslog-ng: Stopping syslog-ng: [ OK ]
>
> Starting syslog-ng: Macros are read-only, they cannot be changed in
> rewrite rules, falling back to MESSAGE instead; macro='FACILITY'
>
> [ OK ]
>
> I have the same error when I changed the "PRIORITY" of the rule
> "r_rewrite_set" :
>
> > Macros are read-only, they cannot be changed in rewrite rules,
> falling back to MESSAGE instead; macro='PRIORITY'
>
> I tried to send a message by using "logger" but as it written in the
> above error, the MESSAGE was changed... :-(
>
> My questions are :
>
> 1. Which macros are read-only ? PRIORITY, FACILITY, another ?
There are two kind of references you can make from template() strings:
1) macros: this is the original stuff, these cannot be changed as they
usually involve some kind of code to transform data from the internal
representation to the expanded string, examples: FACILITY, PRIORITY,
date related macros, and so on
2) name-value pairs: these were introduced in syslog-ng 3.0 and cover
all values that are string-like properties of a message
Macros cannot be changed (at least not directly via set/subst) whereas
name-value pairs can be. To make things more complicated (all in the
name of compatibility) there are some macros that are in fact name-value
pairs, but require transformation when config version is for older
syslog-ng release (e.g. 2.1 or older).
That said, the list of macros are to be found in the templates.c source
file, but I'm including it for reference (this is from the current 3.1
sources):
{ "FACILITY", M_FACILITY },
{ "FACILITY_NUM", M_FACILITY_NUM },
{ "PRIORITY", M_LEVEL },
{ "LEVEL", M_LEVEL },
{ "LEVEL_NUM", M_LEVEL_NUM },
{ "TAG", M_TAG },
{ "TAGS", M_TAGS },
{ "BSDTAG", M_BSDTAG },
{ "PRI", M_PRI },
{ "DATE", M_DATE },
{ "FULLDATE", M_FULLDATE },
{ "ISODATE", M_ISODATE },
{ "STAMP", M_STAMP },
{ "YEAR", M_YEAR },
{ "YEAR_DAY", M_YEAR_DAY },
{ "MONTH", M_MONTH },
{ "MONTH_WEEK", M_MONTH_WEEK },
{ "MONTH_ABBREV", M_MONTH_ABBREV },
{ "MONTH_NAME", M_MONTH_NAME },
{ "DAY", M_DAY },
{ "HOUR", M_HOUR },
{ "MIN", M_MIN },
{ "SEC", M_SEC },
{ "WEEKDAY", M_WEEK_DAY_ABBREV }, /* deprecated */
{ "WEEK_DAY", M_WEEK_DAY },
{ "WEEK_DAY_ABBREV",M_WEEK_DAY_ABBREV },
{ "WEEK_DAY_NAME", M_WEEK_DAY_NAME },
{ "WEEK", M_WEEK },
{ "TZOFFSET", M_TZOFFSET },
{ "TZ", M_TZ },
{ "UNIXTIME", M_UNIXTIME },
{ "R_DATE", M_RECVD_OFS + M_DATE },
{ "R_FULLDATE", M_RECVD_OFS + M_FULLDATE },
{ "R_ISODATE", M_RECVD_OFS + M_ISODATE },
{ "R_STAMP", M_RECVD_OFS + M_STAMP },
{ "R_YEAR", M_RECVD_OFS + M_YEAR },
{ "R_YEAR_DAY", M_RECVD_OFS + M_YEAR_DAY },
{ "R_MONTH", M_RECVD_OFS + M_MONTH },
{ "R_MONTH_WEEK", M_RECVD_OFS + M_MONTH_WEEK },
{ "R_MONTH_ABBREV", M_RECVD_OFS + M_MONTH_ABBREV },
{ "R_MONTH_NAME", M_RECVD_OFS + M_MONTH_NAME },
{ "R_DAY", M_RECVD_OFS + M_DAY },
{ "R_HOUR", M_RECVD_OFS + M_HOUR },
{ "R_MIN", M_RECVD_OFS + M_MIN },
{ "R_SEC", M_RECVD_OFS + M_SEC },
{ "R_WEEKDAY", M_RECVD_OFS + M_WEEK_DAY_ABBREV }, /* deprecated */
{ "R_WEEK_DAY", M_RECVD_OFS + M_WEEK_DAY },
{ "R_WEEK_DAY_ABBREV",M_RECVD_OFS + M_WEEK_DAY_ABBREV },
{ "R_WEEK_DAY_NAME", M_RECVD_OFS + M_WEEK_DAY_NAME },
{ "R_WEEK", M_RECVD_OFS + M_WEEK },
{ "R_TZOFFSET", M_RECVD_OFS + M_TZOFFSET },
{ "R_TZ", M_RECVD_OFS + M_TZ },
{ "R_UNIXTIME", M_RECVD_OFS + M_UNIXTIME },
{ "S_DATE", M_STAMP_OFS + M_DATE },
{ "S_FULLDATE", M_STAMP_OFS + M_FULLDATE },
{ "S_ISODATE", M_STAMP_OFS + M_ISODATE },
{ "S_STAMP", M_STAMP_OFS + M_STAMP },
{ "S_YEAR", M_STAMP_OFS + M_YEAR },
{ "S_YEAR_DAY", M_STAMP_OFS + M_YEAR_DAY },
{ "S_MONTH", M_STAMP_OFS + M_MONTH },
{ "S_MONTH_WEEK", M_STAMP_OFS + M_MONTH_WEEK },
{ "S_MONTH_ABBREV", M_STAMP_OFS + M_MONTH_ABBREV },
{ "S_MONTH_NAME", M_STAMP_OFS + M_MONTH_NAME },
{ "S_DAY", M_STAMP_OFS + M_DAY },
{ "S_HOUR", M_STAMP_OFS + M_HOUR },
{ "S_MIN", M_STAMP_OFS + M_MIN },
{ "S_SEC", M_STAMP_OFS + M_SEC },
{ "S_WEEKDAY", M_STAMP_OFS + M_WEEK_DAY_ABBREV }, /* deprecated */
{ "S_WEEK_DAY", M_STAMP_OFS + M_WEEK_DAY },
{ "S_WEEK_DAY_ABBREV",M_STAMP_OFS + M_WEEK_DAY_ABBREV },
{ "S_WEEK_DAY_NAME", M_STAMP_OFS + M_WEEK_DAY_NAME },
{ "S_WEEK", M_STAMP_OFS + M_WEEK },
{ "S_TZOFFSET", M_STAMP_OFS + M_TZOFFSET },
{ "S_TZ", M_STAMP_OFS + M_TZ },
{ "S_UNIXTIME", M_STAMP_OFS + M_UNIXTIME },
{ "SDATA", M_SDATA },
{ "MSGHDR", M_MSGHDR },
{ "SOURCEIP", M_SOURCE_IP },
{ "SEQNUM", M_SEQNUM },
/* values that have specific behaviour with older syslog-ng config versions */
{ "MSG", M_MESSAGE },
{ "MESSAGE", M_MESSAGE },
{ "HOST", M_HOST },
>From these the last 3 (MSG, MESSAGE and HOST) are in fact name-value
pairs which can be changed.
>
> 2. Is there a way to change the facility or the priority of an
> event ?
There are currently only string based rewrite functionality in
syslog-ng, e.g. only string-like properties of a message can be changed.
E.g. facility/priority is not possible right now. Although we're
planning to have that functionality too.
With some hackery you can change the facility/priority field though:
* create a custom template that includes a static value as the PRI
field of the message:
e.g. template("<166>$DATE $HOST $MSGHDR$MSG\n");
The value 166 is equal to local4.info, calculated using the formula:
(numeric value of facility) * 8 + (numeric value of severity)
The numeric values can be found in RFC3164 or /usr/include/sys/syslog.h
* once you have the template, just send those to a pipe destination,
which you also read from the same syslog-ng instance with a pipe source.
Just make sure you don't create an infinite loop.
>
> 3. If not, why can't I change the facility or the priority ?
Simply because we're not there yet and because I didn't feel it that
important when we implemented the rewrite functionality. It seems that I
was wrong, because many of you are requesting this feature. That's why I
already scheduled it for syslog-ng 3.2
--
Bazsi
More information about the syslog-ng
mailing list