- 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.
- Group Reviewers
- rS332510: Add RFC 5424 syslog message output to syslogd.
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.
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. :-/
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)?
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.
Please use fprintlog_rfc3164 instead of fprintlog_bsd to be consistent with the input parsing code.
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*().
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?