[ipxe-devel] Custom syslog port

[Michael Schaller]

On Wed, Nov 18, 2020 at 2:35 PM Michael Schaller <misch at google.com> wrote:
>
> 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

Hi everyone,

This discussion has also sparked an in-house discussion if we should
move to the standard syslog port.
It would have some benefits and so we are currently exploring that option first.
Thanks for the excellent discussion so far though. :-)

Best,

Michael