[bind10-dev] Default logging to file/syslog instead of console?

[Shane Kerr]

Stephen,

On Tue, 2011-07-19 at 15:37 +0100, Stephen Morris wrote:
> > Right now logging defaults to the console, like this:
> > 
> > 2011-07-19 14:18:10.402 INFO  [b10-xfrin.xfrin] XFRIN_AXFR_TRANSFER_SUCCESS AXFR transfer of zone time-travellers.nl.eu.org. succeeded
> > 2011-07-19 14:18:10.403 INFO  [b10-xfrout.xfrout] XFROUT_NOTIFY_COMMAND received command to send notifies for time-travellers.nl.eu.org./IN
> > 2011-07-19 14:18:22.348 INFO  [b10-auth.datasrc] DATASRC_QUERY_NO_ZONE no zone containing 'borg.c-l-i.net.' in class 'IN'
> > 2011-07-19 14:18:22.348 INFO  [b10-auth.datasrc] DATASRC_QUERY_NO_ZONE no zone containing 'madras.curryboys.net.' in class 'IN'
> > 
> > I was thinking perhaps the default logging should go to a file or syslog
> > instead.
> 
> We can change the default quite easily.

Okay, cool. Does anyone have any preferences on what the defaults should
be?

Question 1: syslog or files?

My personal preference is log files. I've had a few problems throughout
the years with syslog, so you may need to disregard this opinion. :)

Question 2: single log file or several?

The simplest solution is to have a single lot file, of course. However,
since we prepend each message with an ISO 8601-formatted timestamp it
should be easy for administrators to combine them if they need to:

  # cd /var/log/bind10
  # sort *| less

(Note you can't do that with default syslog on any system I've seen,
since "Dec" gets sorted before "Nov"... another strike against syslog!)

While this can be changed of course, whatever we end up picking as a
default will get used by most people, so probably we should try to get
it right. 

One possible split might be:

     1. "generic" BIND 10 logging
     2. logging for zone maintenance (xfrin/xfrout/zonemgr and perhaps
        notify messages, and probably future DNSSEC automatic signers)
     3. auth
     4. resolver
     5. DHCPv4
     6. DHCPv6

> > Or maybe we set this up to have errors (and more severe
> > messages) go to the console and informational (and more severe) messages
> > go to files/syslog?
> 
> At the moment, although you can attach multiple destinations to a
> particular logger, you can only associate it with one severity.
> 
> However, I think that the underlying log4cplus supports the idea of
> associating a severity with a logger's destination (as well as
> associating a severity with a logger), so this capability should not be
> too hard to add.

Okay, then probably we don't need to worry about it for now. However in
Y4 we'll need this to support conversion from BIND 9 logging
configurations.

--
Shane