[ipxe-devel] Custom syslog port

[Michael Schaller]

Michael, that sounds like a solid plan (as far as I can follow it).
Maybe it would be better if `syslog` or `syslog6` is set to set
`sysloguri` based on these settings. Then all code that follows
afterwards could just use `sysloguri`. I think quite a lot of
documentation would also require an update.

Before I would try to implement it I would also need to discuss with
my colleagues if we want to spend the time on implementing this as it
won't be a simple change to implement and test... ;-)

On Wed, Nov 18, 2020 at 2:08 PM Michael Brown <mcb30 at ipxe.org> wrote:
>
> 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