Hello again
I have been able to devise a suitable configuration which tested
successfully to transcode the 'framing' of RFC 6587 Syslog over TCP
messages between input and output.
In case anyone here finds it of use, I paste below the rsyslog.conf I
developed.
Another fine example of RSyslog's flexibility!
<code>
# Sample rsyslog.conf file (usually /etc/rsyslog.conf)
# For Syslog Forwarding between remote TCP Host (in Octet-Counting
format) and a local (or remote) TCP Receiver (in Non-Transparent Framing
format)
# - This is a simple syslog-forwarding arrangement, leveraging RSyslog's
capability to 'translate' the Framing method between source device and
receiver
# - References:
# RFC 6587 "Syslog over TCP":
https://datatracker.ietf.org/doc/html/rfc6587
# RSyslog Documentation:
# Input Module (imptcp):
https://www.rsyslog.com/doc/v8-stable/configuration/modules/imptcp.html
# Output/Forwarding Module (omfwd):
https://www.rsyslog.com/doc/v8-stable/configuration/modules/omfwd.html
#
# Modules section
module(load="imptcp") # needs to be done just once
#module(load="omfwd" Template="RSYSLOG_SyslogProtocol23Format") # no
need to explicitly load this module
# NB. Current RSyslog documentation suggests appending the 'Template'
property to the module, but this did not seem to take effect.
# - Adding the property to the action clause did work as expected.
# Ruleset/Action section
# Match ALL inbound events to be forwarded to localhost on TCP 10514
# StreamDriver as 'ptcp' (plain tcp) is default
# TCP_Framing as 'traditional' is default (i.e. 'Non-Transparanet
Framing' with NL=ASCII 10d)
# Template as 'RSYSLOG_SyslogProtocol23Format' enforces RFC 5424 (as
per the incoming event stream)
ruleset(name="forwarder") {
action( type="omfwd"
Target="127.0.0.1"
Port="10514"
Protocol="tcp"
TCP_Framing="traditional"
Template="RSYSLOG_SyslogProtocol23Format" )
stop
}
# Input section
# Receive on TCP 514,
# Expect 'Octet-Counting' framing format (default),
# Pass to our custom RuleSet "forwarder"
input( type="imptcp"
Port="514"
ruleset="forwarder" )
</code>
On 30/06/2022 13:14, Martyn Hill wrote:
Hello RSyslog gurus!
I am trying to determine whether RSyslog can be configured to act as a
'translator' between a device that sends Syslog over TCP using the
'Octet-Counting' framing method (according to RFC 6587) to an
application/daemon that (currently) only supports the 'Non-Transparant
Framing' method (also RFC 6587 compliant, just minus Octet Counting
support.)
In addition, I would like the original (RFC 5424) Syslog Header to
remain intact, without rewriting or pre-pending an additional header -
i.e. it is only the 'framing' method that i need to adjust between
input/output.
Ideally, no local-disk store/log-file would be used - just a straight
TCP listener to an application/daemon running on the same host as
RSyslogD, either via UDP or TCP.
In RFC speak:
MUST receive Octet-Counting based framing over TCP
MUST send Non-Transparant Framing over TCP or UDP
SHOULD leave the original Syslog Header intact
SHOULD not pre-pend a new Syslog Header
MAY avoid any local disk/log-file storage
:-)
Thanks for any guidance you could offer - I have attempted to research
the question via the Archive and other online resources, but nothing
quite seems to match this use-case...
Martyn.
--
"There are 10 types of people in this world. Those who understand binary and those
who don't."
_______________________________________________
rsyslog mailing list
https://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.
