Commit 72a0beb8 authored by Stephen Morris's avatar Stephen Morris
Browse files

Merge branch 'master' into trac1024

parents 4d17de95 aa4405d5
270. [func] jinmei
Added python bindings for ACLs using the DNS request as the
context. They are accessible via the isc.acl.dns module.
(Trac #983, git c24553e21fe01121a42e2136d0a1230d75812b27)
269. [bug] y-aharen
Modified IntervalTimerTest not to rely on the accuracy of the timer.
This fix addresses occasional failure of build tests.
(Trac #1016, git 090c4c5abac33b2b28d7bdcf3039005a014f9c5b)
268. [func] stephen
Add environment variable to allow redirection of logging output during
unit tests.
......
......@@ -139,6 +139,16 @@ else
AC_SUBST(pkgpyexecdir)
fi
# We need to store the default pyexecdir in a separate variable so that
# we can specify in Makefile.am the install directory of various BIND 10
# python scripts and loadable modules; in Makefile.am we cannot replace
# $(pyexecdir) using itself, e.g, this doesn't work:
# pyexecdir = $(pyexecdir)/isc/some_module
# The separate variable makes this setup possible as follows:
# pyexecdir = $(PYTHON_SITEPKG_DIR)/isc/some_module
PYTHON_SITEPKG_DIR=${pyexecdir}
AC_SUBST(PYTHON_SITEPKG_DIR)
# Check for python development environments
if test -x ${PYTHON}-config; then
PYTHON_INCLUDES=`${PYTHON}-config --includes`
......@@ -793,6 +803,7 @@ AC_CONFIG_FILES([Makefile
src/bin/stats/tests/isc/cc/Makefile
src/bin/stats/tests/isc/config/Makefile
src/bin/stats/tests/isc/util/Makefile
src/bin/stats/tests/isc/log/Makefile
src/bin/stats/tests/testdata/Makefile
src/bin/stats/tests/http/Makefile
src/bin/usermgr/Makefile
......@@ -809,6 +820,8 @@ AC_CONFIG_FILES([Makefile
src/lib/cc/tests/Makefile
src/lib/python/Makefile
src/lib/python/isc/Makefile
src/lib/python/isc/acl/Makefile
src/lib/python/isc/acl/tests/Makefile
src/lib/python/isc/util/Makefile
src/lib/python/isc/util/tests/Makefile
src/lib/python/isc/datasrc/Makefile
......
......@@ -570,8 +570,8 @@ WARN_LOGFILE =
INPUT = ../src/lib/cc ../src/lib/config \
../src/lib/cryptolink ../src/lib/dns ../src/lib/datasrc \
../src/bin/auth ../src/bin/resolver ../src/lib/bench \
../src/lib/log ../src/lib/asiolink/ ../src/lib/nsas \
../src/bin/auth ../src/bin/resolver ../src/lib/bench ../src/lib/log \
../src/lib/log/compiler ../src/lib/asiolink/ ../src/lib/nsas \
../src/lib/testutils ../src/lib/cache ../src/lib/server_common/ \
../src/bin/sockcreator/ ../src/lib/util/ \
../src/lib/resolve ../src/lib/acl
......
......@@ -462,8 +462,7 @@ class BoB:
self.log_starting("ccsession")
self.ccs = isc.config.ModuleCCSession(SPECFILE_LOCATION,
self.config_handler,
self.command_handler,
None, True)
self.command_handler)
self.ccs.start()
self.log_started()
......
......@@ -674,7 +674,10 @@ class BindCmdInterpreter(Cmd):
elif cmd.command == "revert":
self.config_data.clear_local_changes()
elif cmd.command == "commit":
self.config_data.commit()
try:
self.config_data.commit()
except isc.config.ModuleCCSessionError as mcse:
print(str(mcse))
elif cmd.command == "diff":
print(self.config_data.get_local_changes());
elif cmd.command == "go":
......
......@@ -252,8 +252,7 @@ class CommandControl():
self._cc = isc.cc.Session()
self._module_cc = isc.config.ModuleCCSession(SPECFILE_LOCATION,
self.config_handler,
self.command_handler,
None, True)
self.command_handler)
self._module_name = self._module_cc.get_module_spec().get_module_name()
self._cmdctl_config_data = self._module_cc.get_full_config()
self._module_cc.start()
......
......@@ -208,8 +208,7 @@ main(int argc, char* argv[]) {
cc_session = new Session(io_service.get_io_service());
config_session = new ModuleCCSession(specfile, *cc_session,
my_config_handler,
my_command_handler,
true, true);
my_command_handler);
LOG_DEBUG(resolver_logger, RESOLVER_DBG_INIT, RESOLVER_CONFIG_CHANNEL);
// FIXME: This does not belong here, but inside Boss
......
......@@ -16,151 +16,174 @@
# along with the resolver methods.
% RESOLVER_AXFR_TCP AXFR request received over TCP
A debug message, the resolver received a NOTIFY message over TCP. The server
cannot process it and will return an error message to the sender with the
RCODE set to NOTIMP.
This is a debug message output when the resolver received a request for
an AXFR (full transfer of a zone) over TCP. Only authoritative servers
are able to handle AXFR requests, so the resolver will return an error
message to the sender with the RCODE set to NOTIMP.
% RESOLVER_AXFR_UDP AXFR request received over UDP
A debug message, the resolver received a NOTIFY message over UDP. The server
cannot process it (and in any case, an AXFR request should be sent over TCP)
and will return an error message to the sender with the RCODE set to FORMERR.
This is a debug message output when the resolver received a request for
an AXFR (full transfer of a zone) over UDP. Only authoritative servers
are able to handle AXFR requests (and in any case, an AXFR request should
be sent over TCP), so the resolver will return an error message to the
sender with the RCODE set to NOTIMP.
% RESOLVER_CLIENT_TIME_SMALL client timeout of %1 is too small
An error indicating that the configuration value specified for the query
timeout is too small.
During the update of the resolver's configuration parameters, the value
of the client timeout was found to be too small. The configuration
update was abandoned and the parameters were not changed.
% RESOLVER_CONFIG_CHANNEL configuration channel created
A debug message, output when the resolver has successfully established a
connection to the configuration channel.
This is a debug message output when the resolver has successfully
established a connection to the configuration channel.
% RESOLVER_CONFIG_ERROR error in configuration: %1
An error was detected in a configuration update received by the resolver. This
may be in the format of the configuration message (in which case this is a
programming error) or it may be in the data supplied (in which case it is
a user error). The reason for the error, given as a parameter in the message,
will give more details.
An error was detected in a configuration update received by the
resolver. This may be in the format of the configuration message (in
which case this is a programming error) or it may be in the data supplied
(in which case it is a user error). The reason for the error, included
in the message, will give more details. The configuration update is
not applied and the resolver parameters were not changed.
% RESOLVER_CONFIG_LOADED configuration loaded
A debug message, output when the resolver configuration has been successfully
loaded.
This is a debug message output when the resolver configuration has been
successfully loaded.
% RESOLVER_CONFIG_UPDATED configuration updated: %1
A debug message, the configuration has been updated with the specified
information.
This is a debug message output when the resolver configuration is being
updated with the specified information.
% RESOLVER_CREATED main resolver object created
A debug message, output when the Resolver() object has been created.
This is a debug message indicating that the main resolver object has
been created.
% RESOLVER_DNS_MESSAGE_RECEIVED DNS message received: %1
A debug message, this always precedes some other logging message and is the
formatted contents of the DNS packet that the other message refers to.
This is a debug message from the resolver listing the contents of a
received DNS message.
% RESOLVER_DNS_MESSAGE_SENT DNS message of %1 bytes sent: %2
A debug message, this contains details of the response sent back to the querying
system.
This is a debug message containing details of the response returned by
the resolver to the querying system.
% RESOLVER_FAILED resolver failed, reason: %1
This is an error message output when an unhandled exception is caught by the
resolver. All it can do is to shut down.
This is an error message output when an unhandled exception is caught
by the resolver. After this, the resolver will shut itself down.
Please submit a bug report.
% RESOLVER_FORWARD_ADDRESS setting forward address %1(%2)
This message may appear multiple times during startup, and it lists the
forward addresses used by the resolver when running in forwarding mode.
If the resolver is running in forward mode, this message will appear
during startup to list the forward address. If multiple addresses are
specified, it will appear once for each address.
% RESOLVER_FORWARD_QUERY processing forward query
The received query has passed all checks and is being forwarded to upstream
This is a debug message indicating that a query received by the resolver
has passed a set of checks (message is well-formed, it is allowed by the
ACL, it is a supported opcode etc.) and is being forwarded to upstream
servers.
% RESOLVER_HEADER_ERROR message received, exception when processing header: %1
A debug message noting that an exception occurred during the processing of
a received packet. The packet has been dropped.
This is a debug message from the resolver noting that an exception
occurred during the processing of a received packet. The packet has
been dropped.
% RESOLVER_IXFR IXFR request received
The resolver received a NOTIFY message over TCP. The server cannot process it
and will return an error message to the sender with the RCODE set to NOTIMP.
This is a debug message indicating that the resolver received a request
for an IXFR (incremental transfer of a zone). Only authoritative servers
are able to handle IXFR requests, so the resolver will return an error
message to the sender with the RCODE set to NOTIMP.
% RESOLVER_LOOKUP_TIME_SMALL lookup timeout of %1 is too small
An error indicating that the configuration value specified for the lookup
timeout is too small.
During the update of the resolver's configuration parameters, the value
of the lookup timeout was found to be too small. The configuration
update will not be applied.
% RESOLVER_MESSAGE_ERROR error parsing received message: %1 - returning %2
A debug message noting that the resolver received a message and the
parsing of the body of the message failed due to some error (although
the parsing of the header succeeded). The message parameters give a
textual description of the problem and the RCODE returned.
This is a debug message noting that parsing of the body of a received
message by the resolver failed due to some error (although the parsing of
the header succeeded). The message parameters give a textual description
of the problem and the RCODE returned.
% RESOLVER_NEGATIVE_RETRIES negative number of retries (%1) specified in the configuration
An error message indicating that the resolver configuration has specified a
negative retry count. Only zero or positive values are valid.
This error is issued when a resolver configuration update has specified
a negative retry count: only zero or positive values are valid. The
configuration update was abandoned and the parameters were not changed.
% RESOLVER_NON_IN_PACKET non-IN class request received, returning REFUSED message
A debug message, the resolver has received a DNS packet that was not IN class.
The resolver cannot handle such packets, so is returning a REFUSED response to
the sender.
This debug message is issued when resolver has received a DNS packet that
was not IN (Internet) class. The resolver cannot handle such packets,
so is returning a REFUSED response to the sender.
% RESOLVER_NORMAL_QUERY processing normal query
The received query has passed all checks and is being processed by the resolver.
This is a debug message indicating that the query received by the resolver
has passed a set of checks (message is well-formed, it is allowed by the
ACL, it is a supported opcode etc.) and is being processed the resolver.
% RESOLVER_NOTIFY_RECEIVED NOTIFY arrived but server is not authoritative
The resolver received a NOTIFY message. As the server is not authoritative it
cannot process it, so it returns an error message to the sender with the RCODE
set to NOTAUTH.
The resolver has received a NOTIFY message. As the server is not
authoritative it cannot process it, so it returns an error message to
the sender with the RCODE set to NOTAUTH.
% RESOLVER_NOT_ONE_QUESTION query contained %1 questions, exactly one question was expected
A debug message, the resolver received a query that contained the number of
entires in the question section detailed in the message. This is a malformed
message, as a DNS query must contain only one question. The resolver will
return a message to the sender with the RCODE set to FORMERR.
This debug message indicates that the resolver received a query that
contained the number of entries in the question section detailed in
the message. This is a malformed message, as a DNS query must contain
only one question. The resolver will return a message to the sender
with the RCODE set to FORMERR.
% RESOLVER_NO_ROOT_ADDRESS no root addresses available
A warning message during startup, indicates that no root addresses have been
set. This may be because the resolver will get them from a priming query.
A warning message issued during resolver startup, this indicates that
no root addresses have been set. This may be because the resolver will
get them from a priming query.
% RESOLVER_PARSE_ERROR error parsing received message: %1 - returning %2
A debug message noting that the resolver received a message and the parsing
of the body of the message failed due to some non-protocol related reason
(although the parsing of the header succeeded). The message parameters give
a textual description of the problem and the RCODE returned.
This is a debug message noting that the resolver received a message and
the parsing of the body of the message failed due to some non-protocol
related reason (although the parsing of the header succeeded).
The message parameters give a textual description of the problem and
the RCODE returned.
% RESOLVER_PRINT_COMMAND print message command, arguments are: %1
This message is logged when a "print_message" command is received over the
command channel.
This debug message is logged when a "print_message" command is received
by the resolver over the command channel.
% RESOLVER_PROTOCOL_ERROR protocol error parsing received message: %1 - returning %2
A debug message noting that the resolver received a message and the parsing
of the body of the message failed due to some protocol error (although the
parsing of the header succeeded). The message parameters give a textual
description of the problem and the RCODE returned.
This is a debug message noting that the resolver received a message and
the parsing of the body of the message failed due to some protocol error
(although the parsing of the header succeeded). The message parameters
give a textual description of the problem and the RCODE returned.
% RESOLVER_QUERY_SETUP query setup
A debug message noting that the resolver is creating a RecursiveQuery object.
This is a debug message noting that the resolver is creating a
RecursiveQuery object.
% RESOLVER_QUERY_SHUTDOWN query shutdown
A debug message noting that the resolver is destroying a RecursiveQuery object.
This is a debug message noting that the resolver is destroying a
RecursiveQuery object.
% RESOLVER_QUERY_TIME_SMALL query timeout of %1 is too small
An error indicating that the configuration value specified for the query
timeout is too small.
During the update of the resolver's configuration parameters, the value
of the query timeout was found to be too small. The configuration
parameters were not changed.
% RESOLVER_RECEIVED_MESSAGE resolver has received a DNS message
A debug message indicating that the resolver has received a message. Depending
on the debug settings, subsequent log output will indicate the nature of the
message.
This is a debug message indicating that the resolver has received a
DNS message. Depending on the debug settings, subsequent log output
will indicate the nature of the message.
% RESOLVER_RECURSIVE running in recursive mode
This is an informational message that appears at startup noting that the
resolver is running in recursive mode.
This is an informational message that appears at startup noting that
the resolver is running in recursive mode.
% RESOLVER_SERVICE_CREATED service object created
A debug message, output when the main service object (which handles the
received queries) is created.
This debug message is output when resolver creates the main service object
(which handles the received queries).
% RESOLVER_SET_PARAMS query timeout: %1, client timeout: %2, lookup timeout: %3, retry count: %4
A debug message, lists the parameters being set for the resolver. These are:
This debug message lists the parameters being set for the resolver. These are:
query timeout: the timeout (in ms) used for queries originated by the resolver
to upstream servers. Client timeout: the interval to resolver a query by
to upstream servers. Client timeout: the interval to resolve a query by
a client: after this time, the resolver sends back a SERVFAIL to the client
whilst continuing to resolver the query. Lookup timeout: the time at which the
whilst continuing to resolve the query. Lookup timeout: the time at which the
resolver gives up trying to resolve a query. Retry count: the number of times
the resolver will retry a query to an upstream server if it gets a timeout.
......@@ -169,17 +192,18 @@ resolution of the client query might require a large number of queries to
upstream nameservers. Even if none of these queries timeout, the total time
taken to perform all the queries may exceed the client timeout. When this
happens, a SERVFAIL is returned to the client, but the resolver continues
with the resolution process. Data received is added to the cache. However,
with the resolution process; data received is added to the cache. However,
there comes a time - the lookup timeout - when even the resolver gives up.
At this point it will wait for pending upstream queries to complete or
timeout and drop the query.
% RESOLVER_SET_ROOT_ADDRESS setting root address %1(%2)
This message may appear multiple times during startup; it lists the root
addresses used by the resolver.
This message gives the address of one of the root servers used by the
resolver. It is output during startup and may appear multiple times,
once for each root server address.
% RESOLVER_SHUTDOWN resolver shutdown complete
This information message is output when the resolver has shut down.
This informational message is output when the resolver has shut down.
% RESOLVER_STARTED resolver started
This informational message is output by the resolver when all initialization
......@@ -189,35 +213,36 @@ has been completed and it is entering its main loop.
An informational message, this is output when the resolver starts up.
% RESOLVER_UNEXPECTED_RESPONSE received unexpected response, ignoring
A debug message noting that the server has received a response instead of a
query and is ignoring it.
This is a debug message noting that the resolver received a DNS response
packet on the port on which is it listening for queries. The packet
has been ignored.
% RESOLVER_UNSUPPORTED_OPCODE opcode %1 not supported by the resolver
A debug message, the resolver received a message with an unsupported opcode
(it can only process QUERY opcodes). It will return a message to the sender
with the RCODE set to NOTIMP.
% RESOLVER_SET_QUERY_ACL query ACL is configured
A debug message that appears when a new query ACL is configured for the
resolver.
% RESOLVER_QUERY_ACCEPTED query accepted: '%1/%2/%3' from %4
A debug message that indicates an incoming query is accepted in terms of
the query ACL. The log message shows the query in the form of
<query name>/<query type>/<query class>, and the client that sends the
query in the form of <Source IP address>#<source port>.
% RESOLVER_QUERY_REJECTED query rejected: '%1/%2/%3' from %4
An informational message that indicates an incoming query is rejected
in terms of the query ACL. This results in a response with an RCODE of
REFUSED. The log message shows the query in the form of <query
name>/<query type>/<query class>, and the client that sends the
query in the form of <Source IP address>#<source port>.
% RESOLVER_QUERY_DROPPED query dropped: '%1/%2/%3' from %4
An informational message that indicates an incoming query is dropped
in terms of the query ACL. Unlike the RESOLVER_QUERY_REJECTED
case, the server does not return any response. The log message
shows the query in the form of <query name>/<query type>/<query
class>, and the client that sends the query in the form of <Source
IP address>#<source port>.
This is debug message output when the resolver received a message with an
unsupported opcode (it can only process QUERY opcodes). It will return
a message to the sender with the RCODE set to NOTIMP.
% RESOLVER_SET_QUERY_ACL query ACL is configured
This debug message is generated when a new query ACL is configured for
the resolver.
% RESOLVER_QUERY_ACCEPTED query accepted: '%1/%2/%3' from %4
This debug message is produced by the resolver when an incoming query
is accepted in terms of the query ACL. The log message shows the query
in the form of <query name>/<query type>/<query class>, and the client
that sends the query in the form of <Source IP address>#<source port>.
% RESOLVER_QUERY_REJECTED query rejected: '%1/%2/%3' from %4
This is an informational message that indicates an incoming query has
been rejected by the resolver because of the query ACL. This results
in a response with an RCODE of REFUSED. The log message shows the query
in the form of <query name>/<query type>/<query class>, and the client
that sends the query in the form of <Source IP address>#<source port>.
% RESOLVER_QUERY_DROPPED query dropped: '%1/%2/%3' from %4
This is an informational message that indicates an incoming query has
been dropped by the resolver because of the query ACL. Unlike the
RESOLVER_QUERY_REJECTED case, the server does not return any response.
The log message shows the query in the form of <query name>/<query
type>/<query class>, and the client that sends the query in the form of
<Source IP address>#<source port>.
......@@ -7,14 +7,18 @@ pkglibexec_SCRIPTS = b10-stats b10-stats-httpd
b10_statsdir = $(pkgdatadir)
b10_stats_DATA = stats.spec stats-httpd.spec stats-schema.spec
b10_stats_DATA += stats-httpd-xml.tpl stats-httpd-xsd.tpl stats-httpd-xsl.tpl
pyexec_DATA = stats_messages.py stats_httpd_messages.py
CLEANFILES = b10-stats stats.pyc
CLEANFILES += b10-stats-httpd stats_httpd.pyc
CLEANFILES += stats_messages.py stats_messages.pyc
CLEANFILES += stats_httpd_messages.py stats_httpd_messages.pyc
man_MANS = b10-stats.8 b10-stats-httpd.8
EXTRA_DIST = $(man_MANS) b10-stats.xml b10-stats-httpd.xml
EXTRA_DIST += stats.spec stats-httpd.spec stats-schema.spec
EXTRA_DIST += stats-httpd-xml.tpl stats-httpd-xsd.tpl stats-httpd-xsl.tpl
EXTRA_DIST += stats_messages.mes stats_httpd_messages.mes
if ENABLE_MAN
......@@ -26,6 +30,12 @@ b10-stats-httpd.8: b10-stats-httpd.xml
endif
stats_messages.py: stats_messages.mes
$(top_builddir)/src/lib/log/compiler/message -p $(top_srcdir)/src/bin/stats/stats_messages.mes
stats_httpd_messages.py: stats_httpd_messages.mes
$(top_builddir)/src/lib/log/compiler/message -p $(top_srcdir)/src/bin/stats/stats_httpd_messages.mes
# this is done here since configure.ac AC_OUTPUT doesn't expand exec_prefix
b10-stats: stats.py
$(SED) -e "s|@@PYTHONPATH@@|@pyexecdir@|" stats.py >$@
......
......@@ -25,6 +25,16 @@ from collections import defaultdict
from isc.config.ccsession import ModuleCCSession, create_answer
from isc.cc import Session, SessionError
import isc.log
from stats_messages import *
isc.log.init("b10-stats")
logger = isc.log.Logger("stats")
# Some constants for debug levels, these should be removed when we
# have #1074
DBG_STATS_MESSAGING = 30
# for setproctitle
import isc.util.process
isc.util.process.rename()
......@@ -143,9 +153,8 @@ class SessionSubject(Subject, metaclass=Singleton):
"""
A concrete subject class which creates CC session object
"""
def __init__(self, session=None, verbose=False):
def __init__(self, session=None):
Subject.__init__(self)
self.verbose = verbose
self.session=session
self.running = False
......@@ -165,9 +174,8 @@ class CCSessionListener(Listener):
A concrete listener class which creates SessionSubject object and
ModuleCCSession object
"""
def __init__(self, subject, verbose=False):
def __init__(self, subject):
Listener.__init__(self, subject)
self.verbose = verbose
self.session = subject.session
self.boot_time = get_datetime()
......@@ -203,8 +211,7 @@ class CCSessionListener(Listener):
kwargs = self.initialize_data(cmd["command_args"])
self.add_event(Callback(name=name, callback=callback, args=(), kwargs=kwargs))
except AttributeError as ae:
sys.stderr.write("[b10-stats] Caught undefined command while parsing spec file: "
+str(cmd["command_name"])+"\n")
logger.error(STATS_UNKNOWN_COMMAND_IN_SPEC, cmd["command_name"])
def start(self):
"""
......@@ -217,8 +224,7 @@ class CCSessionListener(Listener):
self.stats_data['stats.lname'] = self.session.lname
self.cc_session.start()
# request Bob to send statistics data
if self.verbose:
sys.stdout.write("[b10-stats] request Bob to send statistics data\n")
logger.debug(DBG_STATS_MESSAGING, STATS_SEND_REQUEST_BOSS)
cmd = isc.config.ccsession.create_command("sendstats", None)
seq = self.session.group_sendmsg(cmd, 'Boss')
self.session.group_recvmsg(True, seq)
......@@ -239,8 +245,8 @@ class CCSessionListener(Listener):
"""
handle a configure from the cc channel
"""
if self.verbose:
sys.stdout.write("[b10-stats] newconfig received: "+str(new_config)+"\n")
logger.debug(DBG_STATS_MESSAGING, STATS_RECEIVED_NEW_CONFIG,
new_config)
# do nothing currently
return create_answer(0)
......@@ -262,8 +268,7 @@ class CCSessionListener(Listener):
"""
handle shutdown command
"""
if self.verbose:
sys.stdout.write("[b10-stats] 'shutdown' command received\n")
logger.info(STATS_RECEIVED_SHUTDOWN_COMMAND)
self.subject.running = False
return create_answer(0)
......@@ -283,13 +288,14 @@ class CCSessionListener(Listener):
"""
handle remove command
"""
if self.verbose:
sys.stdout.write("[b10-stats] 'remove' command received, args: "+str(args)+"\n")
# 'args' must be dictionary type
if args and args['stats_item_name'] in self.stats_data:
stats_item_name = args['stats_item_name']
logger.debug(DBG_STATS_MESSAGING, STATS_RECEIVED_REMOVE_COMMAND,
stats_item_name)
# just remove one item
self.stats_data.pop(stats_item_name)
......@@ -299,8 +305,6 @@ class CCSessionListener(Listener):
"""
handle show command
"""
if self.verbose:
sys.stdout.write("[b10-stats] 'show' command received, args: "+str(args)+"\n")
# always overwrite 'report_time' and 'stats.timestamp'
# if "show" command invoked
......@@ -310,16 +314,21 @@ class CCSessionListener(Listener):
# if with args
if args and args['stats_item_name'] in self.stats_data:
stats_item_name = args['stats_item_name']
logger.debug(DBG_STATS_MESSAGING,
STATS_RECEIVED_SHOW_NAME_COMMAND,
stats_item_name)
return create_answer(0, {stats_item_name: self.stats_data[stats_item_name]})
logger.debug(DBG_STATS_MESSAGING,
STATS_RECEIVED_SHOW_ALL_COMMAND)
return create_answer(0, self.stats_data)
def command_reset(self, args):
"""
handle reset command
"""
if self.verbose:
sys.stdout.write("[b10-stats] 'reset' command received\n")
logger.debug(DBG_STATS_MESSAGING,
STATS_RECEIVED_RESET_COMMAND)
# re-initialize internal variables
self.stats_data = self.initialize_data(self.stats_spec)
......@@ -336,8 +345,7 @@ class CCSessionListener(Listener):
"""
handle status command
"""
if self.verbose:
sys.stdout.write("[b10-stats] 'status' command received\n")
logger.debug(DBG_STATS_MESSAGING, STATS_RECEIVED_STATUS_COMMAND)
# just return "I'm alive."
return create_answer(0, "I'm alive.")
......@@ -345,9 +353,7 @@ class CCSessionListener(Listener):
"""
handle an unknown command
"""
if self.verbose:
sys.stdout.write("[b10-stats] Unknown command received: '"
+ str(command) + "'\n")
logger.error(STATS_RECEIVED_UNKNOWN_COMMAND, command)
return create_answer(1, "Unknown command: '"+str(command)+"'")
......@@ -394,20 +400,21 @@ def main(session=None):
parser.add_option("-v", "--verbose", dest="verbose", action="store_true",
help="display more about what is going on")
(options, args) = parser.parse_args()
subject = SessionSubject(session=session, verbose=options.verbose)
listener = CCSessionListener(subject, verbose=options.verbose)
if options.verbose:
isc.log.init("b10-stats", "DEBUG", 99)
subject = SessionSubject(session=session)
listener = CCSessionListener(subject)
subject.start()
while subject.running:
subject.check()