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
_______________________________________________
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel
