Add RFC 5424 syslog message output to syslogd.

[ed]

Summary

• Move all of the code responsible for transmitting log messages into a separate function, fprintlog_write().
• Instead of manually modifying a list of iovecs, add a structure iovlist with some helper functions.
• Alter the F_FORW (UDP message forwarding) case to also use iovecs like the other cases. Use sendmsg() instead of sendto().
• In the case of F_FORW, truncate the message to a size dependent on the address family (AF_INET, AF_INET6), as proposed by RFC 5426.
• Move all traditional message formatting into fprintlog_bsd(). Get rid of some of the string copying and snprintf()'ing. Simply emit more iovecs to get the job done.
• Increase ttymsg()'s limit of 7 iovecs to 32. Add a definition for this limit, so it can be reused by iovlist.
• Add fprintlog_rfc5424() to emit RFC 5424 formatted log entries.
• Add a "-5" command line option to enable RFC 5424 formatting. It would have been nicer if we supported "-o rfc5424", just like on NetBSD. Unfortunately, the "-o" flag is already used for a different purpose on FreeBSD.
• Don't truncate hostnames in the RFC 5424 case, as suggested by that specific RFC.

[ed]

Always show the <PRI>VERSION. Don't let it depend on LogFacPri.

It looks like rsyslog and friends also do this when enabling RFC 5424
output.

[ed]

Don't conditionalize the addition of the pointer.

[kib]

usr.sbin/syslogd/syslogd.c

1592

Are you sure that such assert is the good way to handle the situation ? You truncate the output anyway, at least for some formats. IMO it is somewhat frightening to know that such important service as syslogd could be shut down by some inaccuracy instead of tolerating it.

In other words, I believe that in case of programming error, most people would prefer to get even truncated message instead of losing all their logs.

If you make iov dynamically allocated, you re-invent struct uio.

[ed]

Process feedback from kib@.

[ed]

usr.sbin/syslogd/syslogd.c

1592

That's a good point. I've changed the code to tolerate running out of iovecs.

Indeed; this is sort of a poor man's uio. It looks like we have nothing like that in userspace yet. :-/

[woodsb02]

Hi Ed, I haven’t had a chance to do a full review yet, but here are some initial comments for your consideration.

Also, would the architecture of the new message creation functions change if we have options to vary the transport in the future (e.g. UDP, TCP plaintext, TLS)?

usr.sbin/syslogd/syslogd.8

63

Rather than a binary -5 option, I think we should use a generic output modifier, which would be coupled with a string argument, to allow more than just 2 output options (as per NetBSD). Whilst we can’t use -o, another character could be used.

In the future, there may be new output formats (e.g. RFC5424 version 2).

We may also want to set the transport (e.g. UDP, TCP plaintext, TLS). This would probably be a separate flag, but could be combined.

E.g.
-o syslog_rfc5425
-o syslog_rfc5426

usr.sbin/syslogd/syslogd.c

1820

Please use fprintlog_rfc3164 instead of fprintlog_bsd to be consistent with the input parsing code.

[ed]

Hi Ben,

In D15011#316102, @woodsb02 wrote:

Also, would the architecture of the new message creation functions change if we have options to vary the transport in the future (e.g. UDP, TCP plaintext, TLS)?

Adding additional transport protocols should become somewhat easier because of this change. I think all of that stuff can now be placed in fprintlog_write() without modifying any of the message creation in fprintlog_rfc*().

usr.sbin/syslogd/syslogd.8

63

Configuring UDP vs TCP vs TLS is something that likely needs to be done in syslog.conf as opposed to using command line flags. Still, I've renamed the flag to -O, having values similar to NetBSD. Does that look all right?

usr.sbin/syslogd/syslogd.c

1820

Done!

[ed]

Process woodsb02's feedback.

[ed]

Ben: any final thoughts before I commit this?