Re: new policy topic --- syslog() [was Re: syslog facilities]
[You (Manoj Srivastava)]
> The problem with this is that specifying a syslog policy is so
> hard to do (it is a very personal issue).
Sure, but I think we could keep our thoughts at the level of "what would
you think is reasonable out of the box". There's a lot of generality;
the baseline and de facto "policy" is what ships w/ sysklogd.
> For example, if we ask
> people to show what their syslog.conf does, I think we shall find
> little convergence. For example, I like some duplication, as can be
> seen in my syslog.conf below (I log indexed on facilities as well as
> priorities).
I guess if we find situations or issues on which we can't reach a
consensus, we should just back off that issue.
> On the other hand, if a reasonable consensus is achievable,
> this might be a good thing ;-). However, I think we should at east
> decide on a set of faciliteies reserved for the local sysadmin,
> before starting on the grand syslog.conf unification.
Well, yes, I agree, the locally-reserved facility issue is the first
one to solve.
Attacking that issue a bit, it's clear that the set of "hands off, package
maintainer" facilities are in the local? range. "local2" is currently
taken by ppp, and "local5" by hylafax. I think it might be reasonable to
keep that state of affairs, perhaps arriving at:
local2 ppp subsystem
local5 fax subsystem
local0,1,3,4,5,6,7 hands off (I don't know what's going into local0 ---
you seem to be capturing it.)
It might be more elegant to instead just reserve
local[0-2]
and keep truly local
local[3-7]
Even that's a bit icky; since by the definition in <sys/syslog.h>, local?
should be locally defined and not reserved or structured in anyway. But
the reality is we either have to hack <sys/syslog.h> and make some new
facilities for the essential/prevalent oddballs, or reserve some of the
locals. And I'm lazy; therefore would opt for the latter.
Changing gears a bit, to address the other issue, my sense is that, at
least, debug priority messages should be kept out of system-critical logs
in many cases. You're doing this too. 'sysklogd' doesn't ship this way,
however --- I think it should. (I'll submit a wishlist to that package
in a day or so.)
>daemon.info -/var/log/daemon.log
>kern.info /var/log/kernel
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>
Reply to: