Re: Antw: [EXT] Re: Q: non-ASCII in syslog

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Do, 28.04.22 09:32, Ulrich Windl (Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx) wrote:

> Actually I wasn't quite sure about the default config in SLES12.
> It seems the flow is journald -> local rsyslogd -> remote syslogd
>
> > rsyslogd already knows if messages are UTF-8 because the system's $LANG
> > (well, nl_langinfo) says so. And if rsyslog can't trust that for some
> > reason (e.g. because a user might have a different locale), then
> > systemd-journald won't be able to trust it either, so it won't know whether
> > it could add the BOM.
>
> How could a remote syslog server know what the locale on the sending system
> is?

Your local rsyslogd could add the BOM when it transforms journal
messages to syslog datagrams.

> > RFC 3164 over the network to a remote server? Outside the scope for
> > systemd, since it doesn't generate the network packets; your local rsyslogd
> > forwarder does. (Also, why RFC 3164 and not 5425?)
>
> If you look outside the world of systemd, about 99% of systems create the RFC
> 3164 type of messages.

That's a wild claim, and simply wrong actually.

I am pretty sure that more than 50% of syslog messages generated on
this earth probably are synthesized by glibc's syslog() API. And that
turns out to be neither conformant to RFC 3164 nor to RFC 5425.

What glibc sends is close to RFC 3164 but omits one key field that
isn't really optionally according to RFC 3164: the 'HOSTNAME' field.

systemd is focussed on reality: we generate and process the same
format glibc generates.

Lennart

--
Lennart Poettering, Berlin