Mailing List Archive

Can RSyslog 'translate' Octet-Counting framing to Non-Transparant Framing between TCP hosts?
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.
Re: Can RSyslog 'translate' Octet-Counting framing to Non-Transparant Framing between TCP hosts? [ In reply to ]
yes, the octet counting is a per-link thing so you can enable it on receive (on
by default) and then not have it on when sending.

David Lang

On Thu, 30 Jun 2022, Martyn Hill via rsyslog wrote:

> Date: Thu, 30 Jun 2022 13:14:49 +0100
> From: Martyn Hill via rsyslog <rsyslog@lists.adiscon.com>
> To: rsyslog@lists.adiscon.com
> Cc: Martyn Hill <martyn.joseph.hill@gmail.com>
> Subject: [rsyslog] Can RSyslog 'translate' Octet-Counting framing to
> Non-Transparant Framing between TCP hosts?
>
> 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.
>
>
_______________________________________________
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.
Re: Can RSyslog 'translate' Octet-Counting framing to Non-Transparant Framing between TCP hosts? [ In reply to ]
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.