In article <cagn_6pajraah6d0krzptf9rx-44npfxg-brioupj29cgbtv...@mail.gmail.com>, David Brownlee <a...@absd.org> wrote: >On Tue, 28 Jan 2020 at 21:21, Roy Marples <r...@marples.name> 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
