Re: changing the default syslog daemon for lenny?
- To: email@example.com
- Subject: Re: changing the default syslog daemon for lenny?
- From: Guillem Jover <firstname.lastname@example.org>
- Date: Fri, 1 Feb 2008 18:30:38 +0200
- Message-id: <[🔎] 20080201163038.GA1606@zulo.hadrons.org>
- Mail-followup-to: email@example.com
- In-reply-to: <47A14EF7.firstname.lastname@example.org>
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <20080130211741.GD19261@ouaza.com> <47A10430.firstname.lastname@example.org> <20080131032502.GA5275@zulo.hadrons.org> <47A14EF7.email@example.com>
On Thu, 2008-01-31 at 05:30:47 +0100, Michael Biebl wrote:
> Guillem Jover wrote:
> > On Thu, 2008-01-31 at 00:11:44 +0100, Michael Biebl wrote:
> > > For 12.) and 28.), I'd file a wishlist bug providing a config file
> > > snippet for /etc/rsyslog.d/
> > Can we please use /etc/syslog.d/ instead? this way we don't get locked
> > in any specific implementation. I'm preparing a patch for
> > inetutils-syslogd to support that, and it might also make sense to
> > require all system-log-daemon providers to support that dir as well.
> I'd rather not do that. There is no common config file format, that all
> sylog daemons understand. E.g. you can't mix syslog-ng configuration
> with metalog or rsyslog. The additional functionality of rsyslog is
> implemented via special directives, which other syslog daemons won't
> understand. So, I don't think this is a good idea.
I've just checked a bit and sysklogd, inetutils-syslogd and rsyslog
understand the standard syslog.conf format. rsyslog has additional
directives, but IMO those should not be used by third party packages
that would drop config snippets under /etc/syslog.d/. rsyslog could of
course read configs from syslog.d and rsyslog.d, and admins could
install those under /etc/rsyslog.d/ or edit /etc/rsyslog.conf to make
use of those additional features.
The only daemons not understanding the standard format are syslog-ng,
socklog, and metalog (which is not even on the distro).
My concern is making packages explicitely dependant on rsyslog, when
they could be generic, making it difficult for admins to switch
syslogd and also any future transition to another syslogd.