[ipxe-devel] Custom syslog port

[Michael Brown]

On 18/11/2020 11:46, Michael Schaller wrote:
> Michael, a syslog URI sounds like a good idea to me.
> 
> I'm not aware of any RFC other than
> https://tools.ietf.org/html/draft-lear-ietf-syslog-uri-00, which
> proposes a rather odd URI syntax IMHO.
> Others seem to use URIs like `[tcp/udp]://host:port` or they have
> their own schemes.
> I personally find a standard URI more idiomatic and it looks like this
> could be nicely handled by `uribase`, which is currently an open iPXE
> pull request: https://github.com/ipxe/ipxe/pull/114
> 
> URI examples:
> * https://www.netiq.com/documentation/securelogin-88/installation_guide/data/b1hxlq7p.html
> * https://docs.newrelic.com/docs/logs/enable-log-management-new-relic/enable-log-monitoring-new-relic/forward-your-logs-using-infrastructure-agent
> 
> Custom schemes examples:
> * https://www.grandmetric.com/knowledge-base/design_and_configure/syslog-configure-syslog-server-logging-cisco/
> * https://www.debian.org/releases/buster/amd64/ch05s03.en.html#installer-args

Thank you for doing the research.

We do already have support for `[tcp/udp]://host:port` as a URI syntax 
in iPXE so this could be a good minimal-code-size approach, given that 
there seems to be no globally agreed standard to which to conform.

We would still need to support the existing ${syslog} setting as an IPv4 
address (and only an IPv4 address), to maintain backwards compatibility 
and to allow for the syslog server to be set via DHCP option 7.

This suggests defining a new setting e.g. ${sysloguri} or ${loguri} and 
updating apply_syslog_settings() to something like:

- if ${sysloguri} is defined, then use that

- else if ${syslog6} is defined, then use that

- else if ${syslog} is defined, then use that

- use xfer_open_uri_string() or xfer_open_socket() as applicable for the 
choice taken

Given that a TCP connection (unlike UDP) can be closed by the remote 
end, it may also be worth separating out the xfer_open_*() logic and 
allowing the connection to be reopened if needed.

It may then be worth defining a syslogs:// URI opener (for 
syslog-over-TCP+TLS as already supported in syslogs.c), and potentially 
consolidating some of the logic between syslog.c and syslogs.c, while 
ensuring that the TLS stack doesn't get dragged in to builds that don't 
explicitly request it.

Please don't dive in to implement it yet, but does that sound sensible?

Thanks,

Michael