On Wed, 29 Apr 2015, [email protected] wrote:
See below.
The first rsyslog server uses the config below, so template is:
$template
rel,"%fromhost% %fromhost-ip% %rawmsg%\n"
The recieving rsyslog server uses this template and logs to file:
$template raw,"%rawmsg%"
Ok, if the sending server is using the template rel to send the message
to
the second server you have a problem (this is what I thought was
happening
with the omspoof config above)
a valid syslog message is
<###>timestamp hostname syslogtag[pid]: message
you are sending
hostname ip <###>timestamp hostname syslogtag[pid]: message
the receiving message is going to try to 'do the right thing' and correct
for the malformed message, but it's unlikely to be right all the time.
the fact that you are getting framing errors indicates that the sending
server is doing something very wrong
I guess there is a numeric hostname. That would trigger octet-counted
framing, and that in turn could trigger the error message.
or just no DNS for the hostname, so that field contains an IP address
instead.
indeed, that's the most probably cause.
Rainer
Hi together,
Thanks for all your support.
Never the less I did not get that at all:
What I want to do is to set a prefix consisting of "original" Source and
hostname before the raw message and keep the raw message as it is without any
modification.
From my understanding, the raw-message is keept and concatinated to the new
syslog message sent.
I also think, that octet-counted framing should never apply to the
message-contents, because we never know if a syslog message might not contain
one ore more exotic strings.
Actually in the most cases it seems to work as expected:
2015-04-29T10:58:01.108756+02:00 localhost localhost ::1 Real-syslog-Message
So, what is my mistake and what possibilities do I have to archive my aim
without conflicts?
what you are missing is that you can't just ignore the definition of the
over-the-wire protocol and send random data without running the risk of
triggering other problems,
you aren't just changing the message part of what you are sending, you are
changing the entire message that's being sent. Some of the time you are getting
away with this because rsyslog's heuristics for trying to do something sane with
invalid messages is getting you the result you want. But in other cases, you are
accidently sending something that is 'valid' in a way that you don't intend it
to be. In other cases you are sending something that triggers some other feature
of rsyslog (causing framing errors in the examples show, it will also cause
compression erros in other cases)
If you want to add metadata to what's being sent, you need to do it in a way
that's compatible with the over-the-wire protocol.
I do this by leaving the syslog header portion alone and changing the message
portion. I do this by wrapping the original message in JSON and then I can add
whatever metadata I want and either reconstruct the original or save it in
whatever format I want on the final destination(s)
I've posted on this in the last week or two, if you can't easily find it in the
archives, I'll post more details and examples from the office.
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
