[syslog-ng]How do I adjust logging for "foreign" facilites?

[Wayne Sweatt]

Balasz,

 I'm not sure how much of your reply is use of a built-in methods or
just examples.
Is the "process" keyword an undocumented method, or just very new?

I've solved the problem with the CRON logs, by using the match() method.
Every log I received consistently had one of three keywords.
The only remaining facilities I need to deal with are the Darwin -
"netinfo", and Linux, etc - "authpriv".
I am not able to filter by OS Type, since the host names are irrelevant
to OS.
>From the logs that I've collected, I can see that I can safely translate
all incoming hex "c" facility values to "netinfo" and could also safely
replace all hex "a" facilities to "authpriv". No Solaris systems/apps
are using those values anywhere on our network.

I am able to use the pipe() method, but that means running a dedicated,
non-syslog-ng process in the background to write to the logs. I'm not
crazy about that convaluted scheme.

I haven't tried the program() method yet. Would that be the ticket for
me if I want to just replace strings? Could I write a simple Perl loop
that replaces the priority string on <STDIN> and then writes out to the
desired log file?

You use a "facility_rewrite_hack" in your example. How/where would that
be defined?

Thanks,

-Wayne

On Mon, Jun 02, 2003 at 05:03:45PM -0600, Wayne Sweatt wrote:
> I am running syslog-ng-1.6.0rc2+20030423 on Solaris 8.
> I see a problem with the udp logging of facilities from non-Solaris
> clients.
> For example, syslog-ng is storing the authpriv facility from Linux
> clients as "a" as the $FACILITY value, and cron as "9".
> It also sets the value of "a" for MacOS X client's netinfo facility.
> I can understand strange values for the "non_Solaris" facilites -
> authpriv and netinfo, but . the cron value is set correctly from
Solaris
> clients while not for Linux clients. I thought these numeric Facility
> codes were "standard' between OSes.
> Any explanations?

It should be, however it is not the case. Syslog-ng uses the values
whatever
platform it was compiled for. The table on Linux is:

#define LOG_KERN        (0<<3)  /* kernel messages */
#define LOG_USER        (1<<3)  /* random user-level messages */
#define LOG_MAIL        (2<<3)  /* mail system */
#define LOG_DAEMON      (3<<3)  /* system daemons */
#define LOG_AUTH        (4<<3)  /* security/authorization messages */
#define LOG_SYSLOG      (5<<3)  /* messages generated internally by
syslogd */
#define LOG_LPR         (6<<3)  /* line printer subsystem */
#define LOG_NEWS        (7<<3)  /* network news subsystem */
#define LOG_UUCP        (8<<3)  /* UUCP subsystem */
#define LOG_CRON        (9<<3)  /* clock daemon */
#define LOG_AUTHPRIV    (10<<3) /* security/authorization messages
(private) */
#define LOG_FTP         (11<<3) /* ftp daemon */

        /* other codes through 15 reserved for system use */
#define LOG_LOCAL0      (16<<3) /* reserved for local use */
#define LOG_LOCAL1      (17<<3) /* reserved for local use */
#define LOG_LOCAL2      (18<<3) /* reserved for local use */
#define LOG_LOCAL3      (19<<3) /* reserved for local use */
#define LOG_LOCAL4      (20<<3) /* reserved for local use */
#define LOG_LOCAL5      (21<<3) /* reserved for local use */
#define LOG_LOCAL6      (22<<3) /* reserved for local use */
#define LOG_LOCAL7      (23<<3) /* reserved for local use */


> 
> Is there a suggested way to convert these values at runtime using
> filters(?), or maybe there an easy way to re-compile this
functionality
> in for Solaris?
> The logs are arriving and being stored just fine, it's just the
> $FACILITY value that I would like to translate back to it's native
> "name" for clean parsing reasons.

It is not currently possible. It is not difficult to translate facility
values, the difficult thing is to select which translation table to
apply
(as each message might origin from a different platform)

Using a hack like:

filter f_solaris { host("^sol$") and facility_rewrite_hack(0x3, 0x9); };

this would result in facility_rewrite_hack() called in case the first
part
of the filter matches. A more elegant solution would be to introduce the
process keyword:

filter f_solaris { host("^sol$"); };
process p_remap_sol_fac { facility_map(0x3, 0x9); };
log { source(s_net); filter(f_solaris); process(p_remap_sol_fac);
destination(d_files); };



 Wayne Sweatt
 Sr. UNIX System Administrator
 Comforce Technical Services
 LANL SCC Team