Re: Solving the syslogd problem

[christos%astron.com@localhost (Christos Zoulas)]

In article <CAGN_6pajraah6D0KrzpTF9rx-44npfXg-BRiOupJ29CgbtvA6g%mail.gmail.com@localhost>,
David Brownlee  <abs%absd.org@localhost> wrote:
>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 :)

Or have 2 syslogd binaries built from the same sources. One with only
localhost support in /sbin which starts up early during boot and another
which replaces it later when /usr is mounted. Having a split /usr makes
little sense today though as joerg mentioned, even in the space-constrained
systems.

christos