|
|
@@ -146,7 +146,7 @@
|
|
|
The processes started by the <command>bind10</command>
|
|
|
command have names starting with "b10-", including:
|
|
|
</para>
|
|
|
-
|
|
|
+
|
|
|
<para>
|
|
|
|
|
|
<itemizedlist>
|
|
|
@@ -547,7 +547,7 @@ Debian and Ubuntu:
|
|
|
<varlistentry>
|
|
|
<term>--prefix</term>
|
|
|
<listitem>
|
|
|
- <simpara>Define the the installation location (the
|
|
|
+ <simpara>Define the installation location (the
|
|
|
default is <filename>/usr/local/</filename>).
|
|
|
</simpara>
|
|
|
</listitem>
|
|
|
@@ -1480,61 +1480,679 @@ then change those defaults with config set Resolver/forward_addresses[0]/address
|
|
|
<chapter id="logging">
|
|
|
<title>Logging</title>
|
|
|
|
|
|
-<!-- TODO: how to configure logging, logging destinations etc. -->
|
|
|
+ <section>
|
|
|
+ <title>Logging configuration</title>
|
|
|
|
|
|
- <para>
|
|
|
- Each message written by BIND 10 to the configured logging destinations
|
|
|
- comprises a number of components that identify the origin of the
|
|
|
- message and, if the message indicates a problem, information about the
|
|
|
- problem that may be useful in fixing it.
|
|
|
- </para>
|
|
|
+ <para>
|
|
|
|
|
|
- <para>
|
|
|
- Consider the message below logged to a file:
|
|
|
- <screen>2011-06-15 13:48:22.034 ERROR [b10-resolver.asiolink]
|
|
|
- ASIODNS_OPENSOCK error 111 opening TCP socket to 127.0.0.1(53)</screen>
|
|
|
- </para>
|
|
|
+ The logging system in BIND 10 is configured through the
|
|
|
+ Logging module. All BIND 10 modules will look at the
|
|
|
+ configuration in Logging to see what should be logged and
|
|
|
+ to where.
|
|
|
|
|
|
- <para>
|
|
|
- Note: the layout of messages written to the system logging
|
|
|
- file (syslog) may be slightly different. This message has
|
|
|
- been split across two lines here for display reasons; in the
|
|
|
- logging file, it will appear on one line.)
|
|
|
- </para>
|
|
|
+<!-- TODO: what is context of Logging module for readers of this guide? -->
|
|
|
|
|
|
- <para>
|
|
|
- The log message comprises a number of components:
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>Loggers</title>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ Within BIND 10, a message is logged through a component
|
|
|
+ called a "logger". Different parts of BIND 10 log messages
|
|
|
+ through different loggers, and each logger can be configured
|
|
|
+ independently of one another.
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ In the Logging module, you can specify the configuration
|
|
|
+ for zero or more loggers; any that are not specified will
|
|
|
+ take appropriate default values..
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ The three most important elements of a logger configuration
|
|
|
+ are the <option>name</option> (the component that is
|
|
|
+ generating the messages), the <option>severity</option>
|
|
|
+ (what to log), and the <option>output_options</option>
|
|
|
+ (where to log).
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>name (string)</title>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ Each logger in the system has a name, the name being that
|
|
|
+ of the component using it to log messages. For instance,
|
|
|
+ if you want to configure logging for the resolver module,
|
|
|
+ you add an entry for a logger named <quote>Resolver</quote>. This
|
|
|
+ configuration will then be used by the loggers in the
|
|
|
+ Resolver module, and all the libraries used by it.
|
|
|
+ </para>
|
|
|
+
|
|
|
+<!-- TODO: later we will have a way to know names of all modules
|
|
|
+
|
|
|
+Right now you can only see what their names are if they are running
|
|
|
+(a simple 'help' without anything else in bindctl for instance).
|
|
|
+
|
|
|
+ -->
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ If you want to specify logging for one specific library
|
|
|
+ within the module, you set the name to
|
|
|
+ <replaceable>module.library</replaceable>. For example, the
|
|
|
+ logger used by the nameserver address store component
|
|
|
+ has the full name of <quote>Resolver.nsas</quote>. If
|
|
|
+ there is no entry in Logging for a particular library,
|
|
|
+ it will use the configuration given for the module.
|
|
|
+
|
|
|
+<!-- TODO: how to know these specific names?
|
|
|
+
|
|
|
+We will either have to document them or tell the administrator to
|
|
|
+specify module-wide logging and see what appears...
|
|
|
+
|
|
|
+-->
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+<!-- TODO: severity has not been covered yet -->
|
|
|
+
|
|
|
+ To illustrate this, suppose you want the cache library
|
|
|
+ to log messages of severity DEBUG, and the rest of the
|
|
|
+ resolver code to log messages of severity INFO. To achieve
|
|
|
+ this you specify two loggers, one with the name
|
|
|
+ <quote>Resolver</quote> and severity INFO, and one with
|
|
|
+ the name <quote>Resolver.cache</quote> with severity
|
|
|
+ DEBUG. As there are no entries for other libraries (e.g.
|
|
|
+ the nsas), they will use the configuration for the module
|
|
|
+ (<quote>Resolver</quote>), so giving the desired behavior.
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ One special case is that of a module name of <quote>*</quote>
|
|
|
+ (asterisks), which is interpreted as <emphasis>any</emphasis>
|
|
|
+ module. You can set global logging options by using this,
|
|
|
+ including setting the logging configuration for a library
|
|
|
+ that is used by multiple modules (e.g. <quote>*.config</quote>
|
|
|
+ specifies the configuration library code in whatever
|
|
|
+ module is using it).
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ If there are multiple logger specifications in the
|
|
|
+ configuration that might match a particular logger, the
|
|
|
+ specification with the more specific logger name takes
|
|
|
+ precedence. For example, if there are entries for for
|
|
|
+ both <quote>*</quote> and <quote>Resolver</quote>, the
|
|
|
+ resolver module — and all libraries it uses —
|
|
|
+ will log messages according to the configuration in the
|
|
|
+ second entry (<quote>Resolver</quote>). All other modules
|
|
|
+ will use the configuration of the first entry
|
|
|
+ (<quote>*</quote>). If there was also a configuration
|
|
|
+ entry for <quote>Resolver.cache</quote>, the cache library
|
|
|
+ within the resolver would use that in preference to the
|
|
|
+ entry for <quote>Resolver</quote>.
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ One final note about the naming. When specifying the
|
|
|
+ module name within a logger, use the name of the module
|
|
|
+ as specified in <command>bindctl</command>, e.g.
|
|
|
+ <quote>Resolver</quote> for the resolver module,
|
|
|
+ <quote>Xfrout</quote> for the xfrout module, etc. When
|
|
|
+ the message is logged, the message will include the name
|
|
|
+ of the logger generating the message, but with the module
|
|
|
+ name replaced by the name of the process implementing
|
|
|
+ the module (so for example, a message generated by the
|
|
|
+ <quote>Auth.cache</quote> logger will appear in the output
|
|
|
+ with a logger name of <quote>b10-auth.cache</quote>).
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>severity (string)</title>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ This specifies the category of messages logged.
|
|
|
+ Each message is logged with an associated severity which
|
|
|
+ may be one of the following (in descending order of
|
|
|
+ severity):
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <itemizedlist>
|
|
|
+ <listitem>
|
|
|
+ <simpara> FATAL </simpara>
|
|
|
+ </listitem>
|
|
|
+
|
|
|
+ <listitem>
|
|
|
+ <simpara> ERROR </simpara>
|
|
|
+ </listitem>
|
|
|
+
|
|
|
+ <listitem>
|
|
|
+ <simpara> WARN </simpara>
|
|
|
+ </listitem>
|
|
|
+
|
|
|
+ <listitem>
|
|
|
+ <simpara> INFO </simpara>
|
|
|
+ </listitem>
|
|
|
+
|
|
|
+ <listitem>
|
|
|
+ <simpara> DEBUG </simpara>
|
|
|
+ </listitem>
|
|
|
+ </itemizedlist>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ When the severity of a logger is set to one of these
|
|
|
+ values, it will only log messages of that severity, and
|
|
|
+ the severities above it. The severity may also be set to
|
|
|
+ NONE, in which case all messages from that logger are
|
|
|
+ inhibited.
|
|
|
+
|
|
|
+<!-- TODO: worded wrong? If I set to INFO, why would it show DEBUG which is literally below in that list? -->
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>output_options (list)</title>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ Each logger can have zero or more
|
|
|
+ <option>output_options</option>. These specify where log
|
|
|
+ messages are sent to. These are explained in detail below.
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ The other options for a logger are:
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>debuglevel (integer)</title>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ When a logger's severity is set to DEBUG, this value
|
|
|
+ specifies what debug messages should be printed. It ranges
|
|
|
+ from 0 (least verbose) to 99 (most verbose).
|
|
|
+ </para>
|
|
|
+
|
|
|
+
|
|
|
+<!-- TODO: complete this sentence:
|
|
|
+
|
|
|
+ The general classification of debug message types is
|
|
|
+
|
|
|
+TODO; there's a ticket to determine these levels, see #1074
|
|
|
+
|
|
|
+ -->
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ If severity for the logger is not DEBUG, this value is ignored.
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>additive (true or false)</title>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ If this is true, the <option>output_options</option> from
|
|
|
+ the parent will be used. For example, if there are two
|
|
|
+ loggers configured; <quote>Resolver</quote> and
|
|
|
+ <quote>Resolver.cache</quote>, and <option>additive</option>
|
|
|
+ is true in the second, it will write the log messages
|
|
|
+ not only to the destinations specified for
|
|
|
+ <quote>Resolver.cache</quote>, but also to the destinations
|
|
|
+ as specified in the <option>output_options</option> in
|
|
|
+ the logger named <quote>Resolver</quote>.
|
|
|
+
|
|
|
+<!-- TODO: check this -->
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>Output Options</title>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ The main settings for an output option are the
|
|
|
+ <option>destination</option> and a value called
|
|
|
+ <option>output</option>, the meaning of which depends on
|
|
|
+ the destination that is set.
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>destination (string)</title>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ The destination is the type of output. It can be one of:
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <itemizedlist>
|
|
|
+
|
|
|
+ <listitem>
|
|
|
+ <simpara> console </simpara>
|
|
|
+ </listitem>
|
|
|
+
|
|
|
+ <listitem>
|
|
|
+ <simpara> file </simpara>
|
|
|
+ </listitem>
|
|
|
+
|
|
|
+ <listitem>
|
|
|
+ <simpara> syslog </simpara>
|
|
|
+ </listitem>
|
|
|
+
|
|
|
+ </itemizedlist>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>output (string)</title>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ Depending on what is set as the output destination, this
|
|
|
+ value is interpreted as follows:
|
|
|
+
|
|
|
+ </para>
|
|
|
|
|
|
<variablelist>
|
|
|
- <varlistentry>
|
|
|
- <term>2011-06-15 13:48:22.034</term>
|
|
|
- <listitem><para>
|
|
|
- The date and time at which the message was generated.
|
|
|
- </para></listitem>
|
|
|
- </varlistentry>
|
|
|
-
|
|
|
- <varlistentry>
|
|
|
- <term>ERROR</term>
|
|
|
- <listitem><para>
|
|
|
- The severity of the message.
|
|
|
- </para></listitem>
|
|
|
- </varlistentry>
|
|
|
-
|
|
|
- <varlistentry>
|
|
|
- <term>[b10-resolver.asiolink]</term>
|
|
|
- <listitem><para>
|
|
|
- The source of the message. This comprises two components:
|
|
|
- the BIND 10 process generating the message (in this
|
|
|
- case, <command>b10-resolver</command>) and the module
|
|
|
- within the program from which the message originated
|
|
|
- (which in the example is the asynchronous I/O link
|
|
|
- module, asiolink).
|
|
|
- </para></listitem>
|
|
|
- </varlistentry>
|
|
|
-
|
|
|
- <varlistentry>
|
|
|
- <term>ASIODNS_OPENSOCK</term>
|
|
|
- <listitem><para>
|
|
|
+
|
|
|
+ <varlistentry>
|
|
|
+ <term><option>destination</option> is <quote>console</quote></term>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ The value of output must be one of <quote>stdout</quote>
|
|
|
+ (messages printed to standard output) or
|
|
|
+ <quote>stderr</quote> (messages printed to standard
|
|
|
+ error).
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ </varlistentry>
|
|
|
+
|
|
|
+ <varlistentry>
|
|
|
+ <term><option>destination</option> is <quote>file</quote></term>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ The value of output is interpreted as a file name;
|
|
|
+ log messages will be appended to this file.
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ </varlistentry>
|
|
|
+
|
|
|
+ <varlistentry>
|
|
|
+ <term><option>destination</option> is <quote>syslog</quote></term>
|
|
|
+ <listitem>
|
|
|
+ <simpara>
|
|
|
+ The value of output is interpreted as the
|
|
|
+ <command>syslog</command> facility (e.g.
|
|
|
+ <emphasis>local0</emphasis>) that should be used
|
|
|
+ for log messages.
|
|
|
+ </simpara>
|
|
|
+ </listitem>
|
|
|
+ </varlistentry>
|
|
|
+
|
|
|
+ </variablelist>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ The other options for <option>output_options</option> are:
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>flush (true of false)</title>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ Flush buffers after each log message. Doing this will
|
|
|
+ reduce performance but will ensure that if the program
|
|
|
+ terminates abnormally, all messages up to the point of
|
|
|
+ termination are output.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>maxsize (integer)</title>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ Only relevant when destination is file, this is maximum
|
|
|
+ file size of output files in bytes. When the maximum
|
|
|
+ size is reached, the file is renamed and a new file opened.
|
|
|
+ (For example, a ".1" is appended to the name —
|
|
|
+ if a ".1" file exists, it is renamed ".2",
|
|
|
+ etc.)
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ If this is 0, no maximum file size is used.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>maxver (integer)</title>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ Maximum number of old log files to keep around when
|
|
|
+ rolling the output file. Only relevant when
|
|
|
+ <option>destination</option> is <quote>file</quote>.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>Example session</title>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ In this example we want to set the global logging to
|
|
|
+ write to the file <filename>/var/log/my_bind10.log</filename>,
|
|
|
+ at severity WARN. We want the authoritative server to
|
|
|
+ log at DEBUG with debuglevel 40, to a different file
|
|
|
+ (<filename>/tmp/debug_messages</filename>).
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ Start <command>bindctl</command>.
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ <screen>["login success "]
|
|
|
+> <userinput>config show Logging</userinput>
|
|
|
+Logging/loggers [] list
|
|
|
+</screen>
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ By default, no specific loggers are configured, in which
|
|
|
+ case the severity defaults to INFO and the output is
|
|
|
+ written to stderr.
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ Let's first add a default logger:
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+<!-- TODO: adding the empty loggers makes no sense -->
|
|
|
+ <para>
|
|
|
+
|
|
|
+ <screen><userinput>> config add Logging/loggers</userinput>
|
|
|
+> <userinput>config show Logging</userinput>
|
|
|
+Logging/loggers/ list (modified)
|
|
|
+</screen>
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ The loggers value line changed to indicate that it is no
|
|
|
+ longer an empty list:
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ <screen>> <userinput>config show Logging/loggers</userinput>
|
|
|
+Logging/loggers[0]/name "" string (default)
|
|
|
+Logging/loggers[0]/severity "INFO" string (default)
|
|
|
+Logging/loggers[0]/debuglevel 0 integer (default)
|
|
|
+Logging/loggers[0]/additive false boolean (default)
|
|
|
+Logging/loggers[0]/output_options [] list (default)
|
|
|
+</screen>
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ The name is mandatory, so we must set it. We will also
|
|
|
+ change the severity as well. Let's start with the global
|
|
|
+ logger.
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ <screen>> <userinput>config set Logging/loggers[0]/name *</userinput>
|
|
|
+> <userinput>config set Logging/loggers[0]/severity WARN</userinput>
|
|
|
+> <userinput>config show Logging/loggers</userinput>
|
|
|
+Logging/loggers[0]/name "*" string (modified)
|
|
|
+Logging/loggers[0]/severity "WARN" string (modified)
|
|
|
+Logging/loggers[0]/debuglevel 0 integer (default)
|
|
|
+Logging/loggers[0]/additive false boolean (default)
|
|
|
+Logging/loggers[0]/output_options [] list (default)
|
|
|
+</screen>
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ Of course, we need to specify where we want the log
|
|
|
+ messages to go, so we add an entry for an output option.
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ <screen>> <userinput> config add Logging/loggers[0]/output_options</userinput>
|
|
|
+> <userinput> config show Logging/loggers[0]/output_options</userinput>
|
|
|
+Logging/loggers[0]/output_options[0]/destination "console" string (default)
|
|
|
+Logging/loggers[0]/output_options[0]/output "stdout" string (default)
|
|
|
+Logging/loggers[0]/output_options[0]/flush false boolean (default)
|
|
|
+Logging/loggers[0]/output_options[0]/maxsize 0 integer (default)
|
|
|
+Logging/loggers[0]/output_options[0]/maxver 0 integer (default)
|
|
|
+</screen>
|
|
|
+
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ These aren't the values we are looking for.
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ <screen>> <userinput> config set Logging/loggers[0]/output_options[0]/destination file</userinput>
|
|
|
+> <userinput> config set Logging/loggers[0]/output_options[0]/output /var/log/bind10.log</userinput>
|
|
|
+> <userinput> config set Logging/loggers[0]/output_options[0]/maxsize 30000</userinput>
|
|
|
+> <userinput> config set Logging/loggers[0]/output_options[0]/maxver 8</userinput>
|
|
|
+</screen>
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ Which would make the entire configuration for this logger
|
|
|
+ look like:
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ <screen>> <userinput> config show all Logging/loggers</userinput>
|
|
|
+Logging/loggers[0]/name "*" string (modified)
|
|
|
+Logging/loggers[0]/severity "WARN" string (modified)
|
|
|
+Logging/loggers[0]/debuglevel 0 integer (default)
|
|
|
+Logging/loggers[0]/additive false boolean (default)
|
|
|
+Logging/loggers[0]/output_options[0]/destination "file" string (modified)
|
|
|
+Logging/loggers[0]/output_options[0]/output "/var/log/bind10.log" string (modified)
|
|
|
+Logging/loggers[0]/output_options[0]/flush false boolean (default)
|
|
|
+Logging/loggers[0]/output_options[0]/maxsize 30000 integer (modified)
|
|
|
+Logging/loggers[0]/output_options[0]/maxver 8 integer (modified)
|
|
|
+</screen>
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ That looks OK, so let's commit it before we add the
|
|
|
+ configuration for the authoritative server's logger.
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ <screen>> <userinput> config commit</userinput></screen>
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ Now that we have set it, and checked each value along
|
|
|
+ the way, adding a second entry is quite similar.
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ <screen>> <userinput> config add Logging/loggers</userinput>
|
|
|
+> <userinput> config set Logging/loggers[1]/name Auth</userinput>
|
|
|
+> <userinput> config set Logging/loggers[1]/severity DEBUG</userinput>
|
|
|
+> <userinput> config set Logging/loggers[1]/debuglevel 40</userinput>
|
|
|
+> <userinput> config add Logging/loggers[1]/output_options</userinput>
|
|
|
+> <userinput> config set Logging/loggers[1]/output_options[0]/destination file</userinput>
|
|
|
+> <userinput> config set Logging/loggers[1]/output_options[0]/output /tmp/auth_debug.log</userinput>
|
|
|
+> <userinput> config commit</userinput>
|
|
|
+</screen>
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ And that's it. Once we have found whatever it was we
|
|
|
+ needed the debug messages for, we can simply remove the
|
|
|
+ second logger to let the authoritative server use the
|
|
|
+ same settings as the rest.
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ <screen>> <userinput> config remove Logging/loggers[1]</userinput>
|
|
|
+> <userinput> config commit</userinput>
|
|
|
+</screen>
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+
|
|
|
+ And every module will now be using the values from the
|
|
|
+ logger named <quote>*</quote>.
|
|
|
+
|
|
|
+ </para>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ </section>
|
|
|
+
|
|
|
+ <section>
|
|
|
+ <title>Logging Message Format</title>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ Each message written by BIND 10 to the configured logging
|
|
|
+ destinations comprises a number of components that identify
|
|
|
+ the origin of the message and, if the message indicates
|
|
|
+ a problem, information about the problem that may be
|
|
|
+ useful in fixing it.
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ Consider the message below logged to a file:
|
|
|
+ <screen>2011-06-15 13:48:22.034 ERROR [b10-resolver.asiolink]
|
|
|
+ ASIODNS_OPENSOCK error 111 opening TCP socket to 127.0.0.1(53)</screen>
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ Note: the layout of messages written to the system logging
|
|
|
+ file (syslog) may be slightly different. This message has
|
|
|
+ been split across two lines here for display reasons; in the
|
|
|
+ logging file, it will appear on one line.)
|
|
|
+ </para>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ The log message comprises a number of components:
|
|
|
+
|
|
|
+ <variablelist>
|
|
|
+ <varlistentry>
|
|
|
+ <term>2011-06-15 13:48:22.034</term>
|
|
|
+<!-- TODO: timestamp repeated even if using syslog? -->
|
|
|
+ <listitem><para>
|
|
|
+ The date and time at which the message was generated.
|
|
|
+ </para></listitem>
|
|
|
+ </varlistentry>
|
|
|
+
|
|
|
+ <varlistentry>
|
|
|
+ <term>ERROR</term>
|
|
|
+ <listitem><para>
|
|
|
+ The severity of the message.
|
|
|
+ </para></listitem>
|
|
|
+ </varlistentry>
|
|
|
+
|
|
|
+ <varlistentry>
|
|
|
+ <term>[b10-resolver.asiolink]</term>
|
|
|
+ <listitem><para>
|
|
|
+ The source of the message. This comprises two components:
|
|
|
+ the BIND 10 process generating the message (in this
|
|
|
+ case, <command>b10-resolver</command>) and the module
|
|
|
+ within the program from which the message originated
|
|
|
+ (which in the example is the asynchronous I/O link
|
|
|
+ module, asiolink).
|
|
|
+ </para></listitem>
|
|
|
+ </varlistentry>
|
|
|
+
|
|
|
+ <varlistentry>
|
|
|
+ <term>ASIODNS_OPENSOCK</term>
|
|
|
+ <listitem><para>
|
|
|
The message identification. Every message in BIND 10
|
|
|
has a unique identification, which can be used as an
|
|
|
index into the <ulink
|
|
|
@@ -1542,25 +2160,29 @@ then change those defaults with config set Resolver/forward_addresses[0]/address
|
|
|
Manual</citetitle></ulink> (<ulink
|
|
|
url="http://bind10.isc.org/docs/bind10-messages.html"
|
|
|
/>) from which more information can be obtained.
|
|
|
- </para></listitem>
|
|
|
- </varlistentry>
|
|
|
-
|
|
|
- <varlistentry>
|
|
|
- <term>error 111 opening TCP socket to 127.0.0.1(53)</term>
|
|
|
- <listitem><para>
|
|
|
- A brief description of the cause of the problem. Within this text,
|
|
|
- information relating to the condition that caused the message to
|
|
|
- be logged will be included. In this example, error number 111
|
|
|
- (an operating system-specific error number) was encountered when
|
|
|
- trying to open a TCP connection to port 53 on the local system
|
|
|
- (address 127.0.0.1). The next step would be to find out the reason
|
|
|
- for the failure by consulting your system's documentation to
|
|
|
- identify what error number 111 means.
|
|
|
- </para></listitem>
|
|
|
- </varlistentry>
|
|
|
- </variablelist>
|
|
|
+ </para></listitem>
|
|
|
+ </varlistentry>
|
|
|
+
|
|
|
+ <varlistentry>
|
|
|
+ <term>error 111 opening TCP socket to 127.0.0.1(53)</term>
|
|
|
+ <listitem><para>
|
|
|
+ A brief description of the cause of the problem.
|
|
|
+ Within this text, information relating to the condition
|
|
|
+ that caused the message to be logged will be included.
|
|
|
+ In this example, error number 111 (an operating
|
|
|
+ system-specific error number) was encountered when
|
|
|
+ trying to open a TCP connection to port 53 on the
|
|
|
+ local system (address 127.0.0.1). The next step
|
|
|
+ would be to find out the reason for the failure by
|
|
|
+ consulting your system's documentation to identify
|
|
|
+ what error number 111 means.
|
|
|
+ </para></listitem>
|
|
|
+ </varlistentry>
|
|
|
+ </variablelist>
|
|
|
+ </para>
|
|
|
+
|
|
|
+ </section>
|
|
|
|
|
|
- </para>
|
|
|
</chapter>
|
|
|
|
|
|
<!-- TODO: how to help: run unit tests, join lists, review trac tickets -->
|
Dima Volodin