Re: Solving the syslogd problem

[David Brownlee <abs%absd.org@localhost>]

On Tue, 28 Jan 2020 at 21:21, Roy Marples <roy%marples.name@localhost> wrote:
>
> syslogd is a powerful syslog implementation.
> It supports authenticated and encrypted TLS connections and signing messages.
> Because of this it lives in /usr due to the libraries it needs.
> /usr traditionally depends on mountcritremote which in turn relies on networking
> being up.
>
> The irony being that the default syslogd option is secure mode, which means none
> of the above actually matters.
>
> On the flip side, we have a lot of networking daemons which log to ..... syslog!
> So this is a chicken and egg, because when they start up and start logging the
> log goes nowhere until they are restarted. Which is not exactly optimal.
>
> To fix this, I suggest that we split syslogd into syslogd and syslogd-network.
>
> syslogd should live in /sbin and have no reliance on /usr being mounted.
> It *only* handles local connections. It will attempt to forward to
> syslogd-network if it needs to go outside.
>
> syslogd-network should live in /usr/sbin and handles all network connections,
> tls, signing, etc.
> Startup of this is optional as our default is secure.
>
> Does anyone see any problem with this or have any better ideas?
> Maybe something for GSOC?

A variant would be to have syslog in /sbin and have a way to nudge it
later in startup to load a shared library from usr/lib which includes
all the network code... But I would prefer your syslogd +
syslogd-network split :)

David