[rsyslog] more 5.1.3 errors (fwd)

[Rainer Gerhards]

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of david at lang.hm
> Sent: Thursday, August 20, 2009 11:05 AM
> To: rsyslog-users
> Subject: [rsyslog] more 5.1.3 errors (fwd)
> 
> re-sending
> 
> ---------- Forwarded message ----------
> Date: Fri, 31 Jul 2009 21:53:57 -0700 (PDT)
> From: david at lang.hm
> To: rsyslog-users <rsyslog at lists.adiscon.com>
> Subject: more 5.1.3 errors
> 
> I have the following in the config file
> 
> $template raw,"%rawmsg%\n%fromhost% %hostname% %syslogtag%\n\n\n"
> if $fromhost == '192.168.210.216' then /var/log/scribe1a-p;raw
> if $fromhost == '192.168.210.217' then /var/log/scribe1a-b;raw
> if $fromhost == '192.168.210.219' then /var/log/scribe1b-p;raw
> if $fromhost == '192.168.210.220' then /var/log/scribe1b-b;raw
> if $fromhost == '192.168.210.222' then /var/log/scribe1c-p;raw
> if $fromhost == '192.168.210.223' then /var/log/scribe1c-b;raw
> if $fromhost == '192.168.210.245' then /var/log/scribe1d-p;raw
> 
> 
> but if I do a tail of these files I get very wierd results
> 
> I have some logs in the wrong files, and I have some of them where the
> fromhost
> in in the hostname (and the hostname is in the syslogtag)
> 
> the second error seems fairly consistant with a given source,
> unfortunantly the
> worst offender is another rsyslog 5.1.3 box.
> 
> this first example shows the sceibe1b boxes with the incorrect hostname
> and
> system tag (scribe1b is the other rsyslog box, the one showing the
> problem)
> 
> # tail scribe1*
> ==> scribe1a-b <==
> <22>Jul 31 21:39:21 192.168.242.126 smelter v0.88.5[23535]: n714dL7N010869:
unable to open S/MIME certificate

This looks strange. Is this from rsyslog with default templates? If so, is
the sender actually relaying data from some other source? I am asking because
the only reason I can think of why there is an IP address in front of the
hostname is that an original sender is issuing a malformed message, this is
received and re-interpreted by rsyslogd, which then sends out a message in
"invalid" format because the parser populated the wrong fields (and thus
resulting in what you see on the ultimate end system). I have to admit I am
heavily puzzled ;)

Rainer