kea/src/bin/ddns/ddns_messages.mes

# Copyright (C) 2011  Internet Systems Consortium, Inc. ("ISC")
#
# Permission to use, copy, modify, and/or distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
# AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
# PERFORMANCE OF THIS SOFTWARE.

# No namespace declaration - these constants go in the global namespace
# of the ddns messages python module.

# When you add a message to this file, it is a good idea to run
# <topsrcdir>/tools/reorder_message_file.py to make sure the
# messages are in the correct order.

% DDNS_ACCEPT_FAILURE error accepting a connection: %1
There was a low-level error when we tried to accept an incoming connection
(probably coming from b10-auth). We continue serving on whatever other
connections we already have, but this connection is dropped. The reason
is logged.

% DDNS_CC_SESSION_ERROR error reading from cc channel: %1
There was a problem reading from the command and control channel. The
most likely cause is that the msgq process is not running.

% DDNS_CC_SESSION_TIMEOUT_ERROR timeout waiting for cc response
There was a problem reading a response from another module over the
command and control channel. The most likely cause is that the
configuration manager b10-cfgmgr is not running.

% DDNS_CONFIG_ERROR error found in configuration data: %1
The ddns process encountered an error when installing the configuration at
startup time.  Details of the error are included in the log message.

% DDNS_CONFIG_HANDLER_ERROR failed to update ddns configuration: %1
An update to b10-ddns configuration was delivered but an error was
found while applying them.  None of the delivered updates were applied
to the running b10-ddns system, and the server will keep running with
the existing configuration.  If this happened in the initial
configuration setup, the server will be running with the default
configurations.

% DDNS_DROP_CONN dropping connection on file descriptor %1 because of error %2
There was an error on a connection with the b10-auth server (or whatever
connects to the ddns daemon). This might be OK, for example when the
authoritative server shuts down, the connection would get closed. It also
can mean the system is busy and can't keep up or that the other side got
confused and sent bad data.

% DDNS_MODULECC_SESSION_ERROR error encountered by configuration/command module: %1
There was a problem in the lower level module handling configuration and
control commands.  This could happen for various reasons, but the most likely
cause is that the configuration database contains a syntax error and ddns
failed to start at initialization.  A detailed error message from the module
will also be displayed.

% DDNS_NEW_CONN new connection on file descriptor %1 from %2
Debug message. We received a connection and we are going to start handling
requests from it. The file descriptor number and the address where the request
comes from is logged. The connection is over a unix domain socket and is likely
coming from a b10-auth process.

% DDNS_RECEIVED_SHUTDOWN_COMMAND shutdown command received
The ddns process received a shutdown command from the command channel
and will now shut down.

% DDNS_REQUEST_PARSE_FAIL failed to parse update request: %1
b10-ddns received an update request via b10-auth, but the received
data failed to pass minimum validation: it was either broken wire
format data for a valid DNS message (e.g. it's shorter than the
fixed-length header), or the opcode is not update, or TSIG is included
in the request but it fails to validate.  Since b10-auth should have
performed this level of checks, such an error shouldn't be detected at
this stage and should rather be considered an internal bug.  This
event is therefore logged at the error level, and the request is
simply dropped.  Additional information of the error is also logged.

% DDNS_RESPONSE_SOCKET_ERROR failed to send update response to %1: %2
Network I/O error happens in sending an update request.  The
client's address that caused the error and error details are also
logged.

% DDNS_RUNNING ddns server is running and listening for updates
The ddns process has successfully started and is now ready to receive commands
and updates.

% DDNS_SESSION session arrived on file descriptor %1
A debug message, informing there's some activity on the given file descriptor.
It will be either a request or the file descriptor will be closed. See
following log messages to see what of it.

% DDNS_SHUTDOWN ddns server shutting down
The ddns process is shutting down. It will no longer listen for new commands
or updates. Any command or update that is being addressed at this moment will
be completed, after which the process will exit.

% DDNS_STOPPED ddns server has stopped
The ddns process has successfully stopped and is no longer listening for or
handling commands or updates, and will now exit.

% DDNS_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down
There was a keyboard interrupt signal to stop the ddns process. The
process will now shut down.

% DDNS_UNCAUGHT_EXCEPTION uncaught exception of type %1: %2
The b10-ddns process encountered an uncaught exception and will now shut
down. This is indicative of a programming error and should not happen under
normal circumstances. The exception type and message are printed.

% DDNS_UPDATE_NOTIFY notified %1 of updates to %2
Debug message.  b10-ddns has made updates to a zone based on an update
request and has successfully notified an external module of the updates.
The notified module will use that information for updating its own
state or any necessary protocol action such as zone reloading or sending
notify messages to secondary servers.

% DDNS_UPDATE_NOTIFY_FAIL failed to notify %1 of updates to %2: %3
b10-ddns has made updates to a zone based on an update request and
tried to notify an external module of the updates, but the
notification fails.  Severity of this effect depends on the type of
the module.  If it's b10-xfrout, this means DNS notify messages won't
be sent to secondary servers of the zone.  It's suboptimal, but not
necessarily critical as the secondary servers will try to check the
zone's status periodically.  If it's b10-auth and the notification was
needed to have it reload the corresponding zone, it's more serious
because b10-auth won't be able to serve the new version of the zone
unless some explicit recovery action is taken.  So the administrator
needs to examine this message and takes an appropriate action.  In
either case, this notification is generally expected to succeed; so
the fact it fails itself means there's something wrong in the BIND 10
system, and it would be advisable to check other log messages.