diff options
31 files changed, 61 insertions, 1583 deletions
diff --git a/configure.ac b/configure.ac index 1fcb031f77..68636d8a7e 100644 --- a/configure.ac +++ b/configure.ac @@ -1279,34 +1279,6 @@ AC_SUBST(PERL) AC_PATH_PROGS(AWK, gawk awk) AC_SUBST(AWK) - -# Kea configuration backend section -# Currently there are 2 backends available: BUNDY and JSON -# It is possible that we may extend this to accept additional backends. -AC_ARG_WITH(kea-config, - AC_HELP_STRING([--with-kea-config], - [Selects configuration backend; currently available options are: BUNDY - (Kea reads configuration and commands from Bundy framework) or JSON (default, - Kea reads configuration from a JSON file from disk)]), - [CONFIG_BACKEND="$withval"], - [CONFIG_BACKEND=JSON]) - -AM_CONDITIONAL(CONFIG_BACKEND_BUNDY, test "x$CONFIG_BACKEND" = "xBUNDY") -AM_CONDITIONAL(CONFIG_BACKEND_JSON, test "x$CONFIG_BACKEND" = "xJSON") - -if test "x$CONFIG_BACKEND" = "xBUNDY"; then - AC_DEFINE(CONFIG_BACKEND_BUNDY, 1, [Define to 1 if Kea config was set to BUNDY]) -fi - -if test "x$CONFIG_BACKEND" = "xJSON"; then - AC_DEFINE(CONFIG_BACKEND_JSON, 1, [Define to 1 if Kea config was set to JSON]) -fi - -# Let's sanity check if the specified backend value is allowed -if test "x$CONFIG_BACKEND" != "xBUNDY" && test "x$CONFIG_BACKEND" != "xJSON"; then - AC_MSG_ERROR("Invalid configuration backend specified: $CONFIG_BACKEND. The only supported are: BUNDY JSON") -fi - AC_ARG_ENABLE(generate_docs, [AC_HELP_STRING([--enable-generate-docs], [regenerate documentation using Docbook [default=no]])], enable_generate_docs=$enableval, enable_generate_docs=no) diff --git a/doc/devel/config-backend.dox b/doc/devel/config-backend.dox index 3a1cd5ba07..5e41dd8d44 100644 --- a/doc/devel/config-backend.dox +++ b/doc/devel/config-backend.dox @@ -1,4 +1,4 @@ -// Copyright (C) 2014 Internet Systems Consortium, Inc. ("ISC") +// Copyright (C) 2014, 2015 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 @@ -43,7 +43,7 @@ decided to keep it. However, even though the Kea team is focused on a backend that reads a JSON configuration file from disk, it decided to make it easy for others to use different backends. -While ISC currently (May 2014) plans to maintain only one configuration backend +While ISC currently (May 2015) maintains only one configuration backend (a JSON file read from disk), there may be other organizations (e.g. the Bundy project community) that will maintain other backends. It is quite possible that additional backends (e.g. using LDAP or XML) will be @@ -87,13 +87,12 @@ The following are some details of the JSON backend framework. -# A switch called --with-kea-config has been implemented in the configure script. It allows the selection at compilation time of how the servers will be configured. Currently (June 2014), - there are two values: JSON (the default, read configuration from a JSON file) - and BUNDY (use the BUNDY/BIND10 framework). Although the Bundy/BIND10 - framework has been removed from Kea, the configuration choice - is available for other projects (e.g. Bundy) that want to include an - implementation of Kea using that backend. Such projects are advised to - import the Kea modules and compile them with the Bundy backend - enabled.<br/><br/> + there is one value: JSON (read configuration from a JSON file) + Although the Bundy/BIND10 framework has been removed from Kea, the + configuration choice is available for other projects (e.g. Bundy) + that want to include an implementation of Kea using that backend. + Such projects are advised to import the Kea modules and compile + them with the Bundy backend enabled.<br/><br/> This switchable backend concept is quite simple. There are different implementations of ControlledXSrv class, each backend keeping its code in a separate file. It is a matter of compiling/linking diff --git a/doc/guide/config.xml b/doc/guide/config.xml index 565c7fa49a..a98772f9a3 100644 --- a/doc/guide/config.xml +++ b/doc/guide/config.xml @@ -6,20 +6,8 @@ <chapter id="kea-config"> <title>Kea configuration</title> - <para>Depending on the configuration backend chosen (see <xref - linkend="dhcp-config-backend"/>), the configuration mechanisms are different. The - following sections describe details of the different configuration backends. Note - that only one configuration backend can be used and its selection is - made when the configure script is run.</para> - - <section id="bundy-backend"> - <title>BUNDY configuration backend</title> - <para>This legacy configuration backend allows Kea to use the former BIND 10 - framework. That framework and this Kea configuration backend is no longer - supported by ISC. It is currently developed as part of the Bundy project (see - <ulink url="http://bundy-dns.de">Bundy homepage</ulink>). See the Bundy project - documentation regarding configuration.</para> - </section> + <para>The following section describe details of the only configuration + backend which can be configured and used.</para> <section id="json-backend"> <title>JSON configuration backend</title> diff --git a/doc/guide/install.xml b/doc/guide/install.xml index edfb374a98..c5eb785801 100644 --- a/doc/guide/install.xml +++ b/doc/guide/install.xml @@ -389,30 +389,13 @@ Debian and Ubuntu: <section id="dhcp-config-backend"> <title>Selecting the Configuration Backend</title> <para>Kea 0.9 has introduced configuration backends that are - switchable during the compilation phase. The backend is chosen using - the --with-kea-config switch when running the configure script. It - currently supports two values: BUNDY and JSON. JSON is the default. + switchable during the compilation phase. Only one backend, JSON, + is currently supported. </para> <variablelist> <varlistentry> - <term>BUNDY</term> - <listitem> - <simpara>BUNDY means - that Kea is linked with the Bundy configuration backend that - connects to the Bundy framework and in general works exactly the - same as Kea 0.8 and earlier BIND10 versions. The benefits - of that backend are uniform integration with the Bundy - framework, easy on-line reconfiguration using bindctl, - available RESTful API. On the other hand, it requires - the whole heavy Bundy framework that requires Python3 - to be present. That backend is likely to go away with - the release of Kea 1.0.</simpara> - </listitem> - </varlistentry> - - <varlistentry> <term>JSON</term> <listitem> <simpara>JSON is the new default configuration backend diff --git a/src/bin/Makefile.am b/src/bin/Makefile.am index c254189add..f1013e3fa6 100644 --- a/src/bin/Makefile.am +++ b/src/bin/Makefile.am @@ -1,8 +1,4 @@ # The following build order must be maintained. -SUBDIRS = dhcp4 dhcp6 d2 perfdhcp admin lfc - -if CONFIG_BACKEND_JSON -SUBDIRS += keactrl -endif +SUBDIRS = dhcp4 dhcp6 d2 perfdhcp admin lfc keactrl check-recursive: all-recursive diff --git a/src/bin/d2/Makefile.am b/src/bin/d2/Makefile.am index b1a837bb0b..afb80ad321 100644 --- a/src/bin/d2/Makefile.am +++ b/src/bin/d2/Makefile.am @@ -69,13 +69,7 @@ libd2_la_SOURCES += nc_remove.cc nc_remove.h libd2_la_SOURCES += nc_trans.cc nc_trans.h libd2_la_SOURCES += state_model.cc state_model.h -if CONFIG_BACKEND_BUNDY -libd2_la_SOURCES += bundy_d2_controller.cc bundy_d2_controller.h -else -if CONFIG_BACKEND_JSON libd2_la_SOURCES += d2_controller.cc d2_controller.h -endif -endif nodist_libd2_la_SOURCES = d2_messages.h d2_messages.cc EXTRA_DIST += d2_messages.mes diff --git a/src/bin/d2/bundy_d2_controller.cc b/src/bin/d2/bundy_d2_controller.cc deleted file mode 100644 index b0508c67fe..0000000000 --- a/src/bin/d2/bundy_d2_controller.cc +++ /dev/null @@ -1,319 +0,0 @@ -// Copyright (C) 2014, 2015 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. - -#include <config.h> - -#include <d2/bundy_d2_controller.h> -#include <d2/d2_process.h> -#include <d2/spec_config.h> - -#include <sstream> - -namespace isc { -namespace d2 { - -/// @brief Defines the application name, this is passed into base class -/// it may be used to locate configuration data and appears in log statement. -const char* D2Controller::d2_app_name_ = "DHCP-DDNS"; - -/// @brief Defines the executable name. This is passed into the base class -const char* D2Controller::d2_bin_name_ = "kea-dhcp-ddns"; - -DControllerBasePtr& -D2Controller::instance() { - // If the instance hasn't been created yet, create it. Note this method - // must use the base class singleton instance methods. The base class - // must have access to the singleton in order to use it within BUNDY - // static function callbacks. - if (!getController()) { - DControllerBasePtr controller_ptr(new D2Controller()); - setController(controller_ptr); - } - - return (getController()); -} - -DProcessBase* D2Controller::createProcess() { - // Instantiate and return an instance of the D2 application process. Note - // that the process is passed the controller's io_service. - return (new D2Process(getAppName().c_str(), getIOService())); -} - -D2Controller::D2Controller() - : DControllerBase(d2_app_name_, d2_bin_name_) { - // set the spec file either from the environment or - // use the production value. - if (getenv("KEA_FROM_BUILD")) { - setSpecFileName(std::string(getenv("KEA_FROM_BUILD")) + - "/src/bin/d2/dhcp-ddns.spec"); - } else { - setSpecFileName(D2_SPECFILE_LOCATION); - } -} - -D2Controller::~D2Controller() { -} - -void -D2Controller::launch(int argc, char* argv[], const bool test_mode) { - // Step 1 is to parse the command line arguments. - try { - parseArgs(argc, argv); - } catch (const InvalidUsage& ex) { - usage(ex.what()); - throw; // rethrow it - } - - // Do not initialize logger here if we are running unit tests. It would - // replace an instance of unit test specific logger. - if (!test_mode) { - // Now that we know what the mode flags are, we can init logging. - // If standalone is enabled, do not buffer initial log messages - isc::log::initLogger(getBinName(), - (isVerbose() ? isc::log::DEBUG : isc::log::INFO), - isc::log::MAX_DEBUG_LEVEL, NULL, true); - } - - LOG_DEBUG(dctl_logger, DBGLVL_START_SHUT, DCTL_STARTING) - .arg(getAppName()).arg(getpid()); - try { - // Step 2 is to create and initialize the application process object. - initProcess(); - } catch (const std::exception& ex) { - LOG_FATAL(dctl_logger, DCTL_INIT_PROCESS_FAIL) - .arg(getAppName()).arg(ex.what()); - isc_throw (ProcessInitError, - "Application Process initialization failed: " << ex.what()); - } - - // Next we connect to Bundy. - try { - establishSession(); - } catch (const std::exception& ex) { - LOG_FATAL(dctl_logger, DCTL_SESSION_FAIL).arg(ex.what()); - isc_throw (SessionStartError, - "Session start up failed: " << ex.what()); - } - - // Everything is clear for launch, so start the application's - // event loop. - try { - runProcess(); - } catch (const std::exception& ex) { - LOG_FATAL(dctl_logger, DCTL_PROCESS_FAILED) - .arg(getAppName()).arg(ex.what()); - isc_throw (ProcessRunError, - "Application process event loop failed: " << ex.what()); - } - - // Disconnect from Bundy. - try { - disconnectSession(); - } catch (const std::exception& ex) { - LOG_ERROR(dctl_logger, DCTL_DISCONNECT_FAIL) - .arg(getAppName()).arg(ex.what()); - isc_throw (SessionEndError, "Session end failed: " << ex.what()); - } - - // All done, so bail out. - LOG_INFO(dctl_logger, DCTL_STOPPING).arg(getAppName()); -} - -void -D2Controller::parseArgs(int argc, char* argv[]) -{ - // Iterate over the given command line options. If its a stock option - // ("s" or "v") handle it here. If its a valid custom option, then - // invoke customOption. - int ch; - opterr = 0; - optind = 1; - std::string opts(":v" + getCustomOpts()); - while ((ch = getopt(argc, argv, opts.c_str())) != -1) { - switch (ch) { - case 'v': - // Enables verbose logging. - setVerbose(true); - break; - - case '?': { - // We hit an invalid option. - isc_throw(InvalidUsage, "unsupported option: [" - << static_cast<char>(optopt) << "] " - << (!optarg ? "" : optarg)); - - break; - } - - default: - // We hit a valid custom option - if (!customOption(ch, optarg)) { - // This would be a programmatic error. - isc_throw(InvalidUsage, " Option listed but implemented?: [" - << static_cast<char>(ch) << "] " - << (!optarg ? "" : optarg)); - } - break; - } - } - - // There was too much information on the command line. - if (argc > optind) { - isc_throw(InvalidUsage, "extraneous command line information"); - } -} - -void -D2Controller::establishSession() { - LOG_DEBUG(dctl_logger, DBGLVL_START_SHUT, DCTL_CCSESSION_STARTING) - .arg(getAppName()).arg(getSpecFileName()); - - // Create the Bundy command control session with the our IOService. - cc_session_ = SessionPtr(new isc::cc::Session( - getIOService()->get_io_service())); - - // Create the Bundy config session with the stub configuration handler. - // This handler is internally invoked by the constructor and on success - // the constructor updates the current session with the configuration that - // had been committed in the previous session. If we do not install - // the dummy handler, the previous configuration would be lost. - config_session_ = ModuleCCSessionPtr(new isc::config::ModuleCCSession( - getSpecFileName(), *cc_session_, - dummyConfigHandler, - commandHandler, - false)); - // Enable configuration even processing. - config_session_->start(); - - // We initially create ModuleCCSession() with a dummy configHandler, as - // the session module is too eager to send partial configuration. - // Replace the dummy config handler with the real handler. - config_session_->setConfigHandler(configHandler); - - // Call the real configHandler with the full configuration retrieved - // from the config session. - isc::data::ConstElementPtr answer = configHandler( - config_session_->getFullConfig()); - - // Parse the answer returned from the configHandler. Log the error but - // keep running. This provides an opportunity for the user to correct - // the configuration dynamically. - int ret = 0; - isc::data::ConstElementPtr comment = isc::config::parseAnswer(ret, answer); - if (ret) { - LOG_ERROR(dctl_logger, DCTL_CONFIG_LOAD_FAIL) - .arg(getAppName()).arg(comment->str()); - } -} - -void D2Controller::disconnectSession() { - LOG_DEBUG(dctl_logger, DBGLVL_START_SHUT, DCTL_CCSESSION_ENDING) - .arg(getAppName()); - - // Destroy the Bundy config session. - if (config_session_) { - config_session_.reset(); - } - - // Destroy the Bundy command and control session. - if (cc_session_) { - cc_session_->disconnect(); - cc_session_.reset(); - } -} - -isc::data::ConstElementPtr -D2Controller::dummyConfigHandler(isc::data::ConstElementPtr) { - LOG_DEBUG(dctl_logger, DBGLVL_START_SHUT, DCTL_CONFIG_STUB) - .arg(getController()->getAppName()); - return (isc::config::createAnswer(0, "Configuration accepted.")); -} - -isc::data::ConstElementPtr -D2Controller::configHandler(isc::data::ConstElementPtr new_config) { - - LOG_DEBUG(dctl_logger, DBGLVL_COMMAND, DCTL_CONFIG_UPDATE) - .arg(getController()->getAppName()).arg(new_config->str()); - - // Invoke the instance method on the controller singleton. - return (getController()->updateConfig(new_config)); -} - -// Static callback which invokes non-static handler on singleton -isc::data::ConstElementPtr -D2Controller::commandHandler(const std::string& command, - isc::data::ConstElementPtr args) { - - LOG_DEBUG(dctl_logger, DBGLVL_COMMAND, DCTL_COMMAND_RECEIVED) - .arg(getController()->getAppName()).arg(command) - .arg(args ? args->str() : "(no args)"); - - // Invoke the instance method on the controller singleton. - return (getController()->executeCommand(command, args)); -} - -isc::data::ConstElementPtr -D2Controller::updateConfig(isc::data::ConstElementPtr new_config) { - if (!config_session_) { - // That should never happen as we install config_handler - // after we instantiate the server. - isc::data::ConstElementPtr answer = - isc::config::createAnswer(1, "Configuration rejected," - " Session has not started."); - return (answer); - } - - // Let's get the existing configuration. - isc::data::ConstElementPtr full_config = config_session_->getFullConfig(); - - // The configuration passed to this handler function is partial. - // In other words, it just includes the values being modified. - // In the same time, there may be dependencies between various - // configuration parsers. For example: the option value can - // be set if the definition of this option is set. If someone removes - // an existing option definition then the partial configuration that - // removes that definition is triggered while a relevant option value - // may remain configured. This eventually results in the - // configuration being in the inconsistent state. - // In order to work around this problem we need to merge the new - // configuration with the existing (full) configuration. - - // Let's create a new object that will hold the merged configuration. - boost::shared_ptr<isc::data::MapElement> - merged_config(new isc::data::MapElement()); - - // Merge an existing and new configuration. - merged_config->setValue(full_config->mapValue()); - isc::data::merge(merged_config, new_config); - - // Send the merged configuration to the application. - return (getProcess()->configure(merged_config)); -} - - -void -D2Controller::usage(const std::string & text) -{ - if (text != "") { - std::cerr << "Usage error: " << text << std::endl; - } - - std::cerr << "Usage: " << getBinName() << std::endl; - std::cerr << " -v: verbose output" << std::endl; - std::cerr << getUsageText() << std::endl; -} - - -}; // namespace isc::d2 -}; // namespace isc diff --git a/src/bin/d2/bundy_d2_controller.h b/src/bin/d2/bundy_d2_controller.h deleted file mode 100644 index 8ea0337f57..0000000000 --- a/src/bin/d2/bundy_d2_controller.h +++ /dev/null @@ -1,256 +0,0 @@ -// Copyright (C) 2014-2015 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. - -#ifndef BUNDY_D2_CONTROLLER_H -#define BUNDY_D2_CONTROLLER_H - -#include <asiolink/io_service.h> -#include <cc/data.h> -#include <cc/session.h> -#include <config/ccsession.h> -#include <d2/d2_log.h> -#include <d2/d_controller.h> -#include <d2/d_process.h> -#include <exceptions/exceptions.h> -#include <log/logger_support.h> - -#include <boost/shared_ptr.hpp> -#include <boost/noncopyable.hpp> - - -namespace isc { -namespace d2 { - -/// @brief Exception thrown when the session start up fails. -class SessionStartError: public isc::Exception { -public: - SessionStartError (const char* file, size_t line, const char* what) : - isc::Exception(file, line, what) { }; -}; - -/// @brief Exception thrown when the session end fails. -class SessionEndError: public isc::Exception { -public: - SessionEndError (const char* file, size_t line, const char* what) : - isc::Exception(file, line, what) { }; -}; - -/// @brief Defines a shared pointer to a Session. -typedef boost::shared_ptr<isc::cc::Session> SessionPtr; - -/// @brief Defines a shared pointer to a ModuleCCSession. -typedef boost::shared_ptr<isc::config::ModuleCCSession> ModuleCCSessionPtr; - -/// @brief Bundy-integrated Process Controller for D2 Process -/// This class is the DHCP-DDNS specific derivation of DControllerBase which -/// is managed by BUNDY. It creates and manages an instance of the DHCP-DDNS -/// application process, D2Process. -/// -/// D2 will be constructed with this class if the project is configured with -/// --with-kea-config=BUNDY -class D2Controller : public DControllerBase { -public: - /// @brief Static singleton instance method. This method returns the - /// base class singleton instance member. It instantiates the singleton - /// and sets the base class instance member upon first invocation. - /// - /// @return returns the pointer reference to the singleton instance. - static DControllerBasePtr& instance(); - - /// @brief Destructor. - virtual ~D2Controller(); - - /// @brief Defines the application name, this is passed into base class - /// and appears in log statements. - static const char* d2_app_name_; - - /// @brief Defines the executable name. This is passed into the base class - /// by convention this should match the BUNDY module name. - static const char* d2_bin_name_; - - /// @brief Acts as the primary entry point into the controller execution - /// and provides the outermost application control logic: - /// - /// 1. parse command line arguments - /// 2. instantiate and initialize the application process - /// 3. establish BUNDY session(s) if in integrated mode - /// 4. start and wait on the application process event loop - /// 5. upon event loop completion, disconnect from BUNDY (if needed) - /// 6. exit to the caller - /// - /// It is intended to be called from main() and be given the command line - /// arguments. Note this method is deliberately not virtual to ensure the - /// proper sequence of events occur. - /// - /// This function can be run in the test mode. It prevents initialization - /// of D2 module logger. This is used in unit tests which initialize logger - /// in their main function. Such logger uses environmental variables to - /// control severity, verbosity etc. Reinitialization of logger by this - /// function would replace unit tests specific logger configuration with - /// this suitable for D2 running as a Bundy module. - /// - /// @param argc is the number of command line arguments supplied - /// @param argv is the array of string (char *) command line arguments - /// @param test_mode is a bool value which indicates if - /// @c DControllerBase::launch should be run in the test mode (if true). - /// This parameter doesn't have default value to force test implementers to - /// enable test mode explicitly. - /// - /// @throw throws one of the following exceptions: - /// InvalidUsage - Indicates invalid command line. - /// ProcessInitError - Failed to create and initialize application - /// process object. - /// SessionStartError - Could not connect to BUNDY (integrated mode only). - /// ProcessRunError - A fatal error occurred while in the application - /// process event loop. - /// SessionEndError - Could not disconnect from BUNDY (integrated mode - /// only). - virtual void launch(int argc, char* argv[], const bool test_mode); - - /// @brief A dummy configuration handler that always returns success. - /// - /// This configuration handler does not perform configuration - /// parsing and always returns success. A dummy handler should - /// be installed using \ref isc::config::ModuleCCSession ctor - /// to get the initial configuration. This initial configuration - /// comprises values for only those elements that were modified - /// the previous session. The D2 configuration parsing can't be - /// used to parse the initial configuration because it may need the - /// full configuration to satisfy dependencies between the - /// various configuration values. Installing the dummy handler - /// that guarantees to return success causes initial configuration - /// to be stored for the session being created and that it can - /// be later accessed with \ref isc::config::ConfigData::getFullConfig. - /// - /// @param new_config new configuration. - /// - /// @return success configuration status. - static isc::data::ConstElementPtr - dummyConfigHandler(isc::data::ConstElementPtr new_config); - - /// @brief A callback for handling all incoming configuration updates. - /// - /// As a pointer to this method is used as a callback in ASIO for - /// ModuleCCSession, it has to be static. It acts as a wrapper around - /// the virtual instance method, updateConfig. - /// - /// @param new_config textual representation of the new configuration - /// - /// @return status of the config update - static isc::data::ConstElementPtr - configHandler(isc::data::ConstElementPtr new_config); - - /// @brief A callback for handling all incoming commands. - /// - /// As a pointer to this method is used as a callback in ASIO for - /// ModuleCCSession, it has to be static. It acts as a wrapper around - /// the virtual instance method, executeCommand. - /// - /// @param command textual representation of the command - /// @param args parameters of the command. It can be NULL pointer if no - /// arguments exist for a particular command. - /// - /// @return status of the processed command - static isc::data::ConstElementPtr - commandHandler(const std::string& command, isc::data::ConstElementPtr args); - - /// @brief Instance method invoked by the configuration event handler and - /// which processes the actual configuration update. Provides behavioral - /// path for both integrated and stand-alone modes. The current - /// implementation will merge the configuration update into the existing - /// configuration and then invoke the application process' configure method. - /// - /// @todo This implementation is will evolve as the D2 configuration - /// management task is implemented (trac #2957). - /// - /// @param new_config is the new configuration - /// - /// @return returns an Element that contains the results of configuration - /// update composed of an integer status value (0 means successful, - /// non-zero means failure), and a string explanation of the outcome. - virtual isc::data::ConstElementPtr - updateConfig(isc::data::ConstElementPtr new_config); - -protected: - /// @brief Processes the command line arguments. It is the first step - /// taken after the controller has been launched. It combines the stock - /// list of options with those returned by getCustomOpts(), and uses - /// cstdlib's getopt to loop through the command line. The stock options - /// It handles stock options directly, and passes any custom options into - /// the customOption method. Currently there are only two stock options - /// -s for stand alone mode, and -v for verbose logging. - /// - /// @param argc is the number of command line arguments supplied - /// @param argv is the array of string (char *) command line arguments - /// - /// @throw throws InvalidUsage when there are usage errors. - void parseArgs(int argc, char* argv[]); - - /// @brief Establishes connectivity with BUNDY. This method is used - /// invoked during launch, if running in integrated mode, following - /// successful process initialization. It is responsible for establishing - /// the BUNDY control and config sessions. During the session creation, - /// it passes in the controller's IOService and the callbacks for command - /// directives and config events. Lastly, it will invoke the onConnect - /// method providing the derivation an opportunity to execute any custom - /// logic associated with session establishment. - /// - /// @throw the BUNDY framework may throw std::exceptions. - void establishSession(); - - /// @brief Terminates connectivity with BUNDY. This method is invoked - /// in integrated mode after the application event loop has exited. It - /// first calls the onDisconnect method providing the derivation an - /// opportunity to execute custom logic if needed, and then terminates the - /// BUNDY config and control sessions. - /// - /// @throw the BUNDY framework may throw std:exceptions. - void disconnectSession(); - - /// @brief Prints the program usage text to std error. - /// - /// @param text is a string message which will preceded the usage text. - /// This is intended to be used for specific usage violation messages. - void usage(const std::string& text); - -private: - /// @brief Creates an instance of the DHCP-DDNS specific application - /// process. This method is invoked during the process initialization - /// step of the controller launch. - /// - /// @return returns a DProcessBase* to the application process created. - /// Note the caller is responsible for destructing the process. This - /// is handled by the base class, which wraps this pointer with a smart - /// pointer. - virtual DProcessBase* createProcess(); - - /// @brief Helper session object that represents raw connection to msgq. - SessionPtr cc_session_; - - /// @brief Session that receives configuration and commands. - ModuleCCSessionPtr config_session_; - - /// @brief Constructor is declared private to maintain the integrity of - /// the singleton instance. - D2Controller(); - - // DControllerTest is named a friend class to facilitate unit testing while - // leaving the intended member scopes intact. - friend class DControllerTest; -}; - -}; // namespace isc::d2 -}; // namespace isc - -#endif diff --git a/src/bin/d2/d2.dox b/src/bin/d2/d2.dox index fe57b57003..fa20b697f3 100644 --- a/src/bin/d2/d2.dox +++ b/src/bin/d2/d2.dox @@ -1,4 +1,4 @@ -// Copyright (C) 2014 Internet Systems Consortium, Inc. ("ISC") +// Copyright (C) 2014, 2015 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 @@ -54,8 +54,7 @@ an application process class derived from isc::d2::DProcess. These services incl - Command line argument handling - Process instantiation and initialization - Support for stand-alone execution - - Support for integrated operation as a BUNDY module (session management - and event handling) + - Support for integrated operation - Process event loop invocation and shutdown It creates and manages an instance of isc::d2::DProcessBase. The CPL is @@ -208,28 +207,8 @@ in the diagram below: - isc::d2::D2Controller - entry point for running D2, it processes command line options, starts and controls the application process, @c D2Process. -Currently there are two implementations of D2Controller selected through the -configuration script switch, "--with-kea-config": - --# --with-kea-config=JSON - The implementation is contained in isc/d2/d2_controller.*. This form allows D2 to run as a stand-alone process configured via JSON -text file specified as a command line argument. The file content is described -in isc/d2/dhcp-ddns.spec, unit tests are in -isc/d2/tests/bundy_d2_controller_unittests.cc. As of Kea 0.9, this form will -be the default form. --# --with-kea-config=BUNDY - The implementation is contained in -isc/d2/bundy_d2_controller.*, unit tests are in isc/d2/tests/d2_controller_unittests.cc and d_controller_unittests.cc This form allows D2 to run as a Bundy -module. It creates a BUNDY Session, allowing it to receive control commands -such as configuration updates, status requests, and shutdown. BUNDY modules -are required to supply two callbacks: one for configuration events and one for -command events. This form of D2Controller supplies these callbacks which -largely pass the information through to its @c D2Process instance. If the -controller cannot establish a BUNDY session it will exit with a fatal error. - -The configuration switch determines which of two forms and tests are compiled -and they are mutually exclusive. - -@note The inclusion of the BUNDY form should be considered temporary. Long range -planning should be based on the JSON form. +There were two implementations of D2Controller, today the only available +form is JSON. - isc::d2::D2Process - creates and manages D2's primary resources and implements the main event loop described in @ref d2EventLoop. diff --git a/src/bin/d2/d2_messages.mes b/src/bin/d2/d2_messages.mes index ee3e7a4a8e..885269615e 100644 --- a/src/bin/d2/d2_messages.mes +++ b/src/bin/d2/d2_messages.mes @@ -54,12 +54,6 @@ events is called. This only happens during initial startup. A debug message indicating that the controller has received an updated configuration from the Kea configuration system. -% DCTL_DISCONNECT_FAIL %1 controller failed to end session with Bundy: %2 -This message indicates that while shutting down, the DHCP-DDNS controller -encountered an error terminating communication with the Bundy configuration -system. The service will still exit. While theoretically possible, -this situation is rather unlikely. - % DCTL_INIT_PROCESS %1 initializing the application This debug message is issued just before the controller attempts to create and initialize its application instance. diff --git a/src/bin/d2/tests/Makefile.am b/src/bin/d2/tests/Makefile.am index c4b98b1900..5b4cc82d2c 100644 --- a/src/bin/d2/tests/Makefile.am +++ b/src/bin/d2/tests/Makefile.am @@ -1,9 +1,7 @@ SHTESTS = # The test of dynamic reconfiguration based on signals will work only # if we are using file based configuration approach. -if CONFIG_BACKEND_JSON SHTESTS += d2_process_tests.sh -endif noinst_SCRIPTS = d2_process_tests.sh @@ -68,14 +66,8 @@ d2_unittests_SOURCES += nc_test_utils.cc nc_test_utils.h d2_unittests_SOURCES += nc_trans_unittests.cc d2_unittests_SOURCES += state_model_unittests.cc -if CONFIG_BACKEND_BUNDY -d2_unittests_SOURCES += bundy_d2_controller_unittests.cc -else -if CONFIG_BACKEND_JSON d2_unittests_SOURCES += d2_controller_unittests.cc d2_unittests_SOURCES += d_controller_unittests.cc -endif -endif d2_unittests_CPPFLAGS = $(AM_CPPFLAGS) $(GTEST_INCLUDES) d2_unittests_LDFLAGS = $(AM_LDFLAGS) $(GTEST_LDFLAGS) diff --git a/src/bin/d2/tests/bundy_d2_controller_unittests.cc b/src/bin/d2/tests/bundy_d2_controller_unittests.cc deleted file mode 100644 index 05747261f2..0000000000 --- a/src/bin/d2/tests/bundy_d2_controller_unittests.cc +++ /dev/null @@ -1,189 +0,0 @@ -// Copyright (C) 2014, 2015 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. - -#include <config.h> - -#include <config/ccsession.h> -#include <d_test_stubs.h> -#include <d2/bundy_d2_controller.h> -#include <d2/spec_config.h> - -#include <boost/pointer_cast.hpp> -#include <boost/date_time/posix_time/posix_time.hpp> -#include <gtest/gtest.h> - -#include <sstream> - -using namespace boost::posix_time; - -namespace isc { -namespace d2 { - -/// @brief Test fixture class for testing D2Controller class. This class -/// derives from DControllerTest and wraps a D2Controller. Much of the -/// underlying functionality is in the DControllerBase class which has an -/// extensive set of unit tests that are independent of DHCP-DDNS. -/// @TODO Currently These tests are relatively light and duplicate some of -/// the testing done on the base class. These tests are sufficient to ensure -/// that D2Controller properly derives from its base class and to test the -/// logic that is unique to D2Controller. These tests will be augmented and -/// or new tests added as additional functionality evolves. -/// Unlike the stub testing, there is no use of SimFailure to induce error -/// conditions as this is production code. -class BundyD2ControllerTest : public DControllerTest { -public: - /// @brief Constructor - /// Note the constructor passes in the static D2Controller instance - /// method. - BundyD2ControllerTest() : DControllerTest(D2Controller::instance) { - } - -}; - -/// @brief Basic Controller instantiation testing. -/// Verifies that the controller singleton gets created and that the -/// basic derivation from the base class is intact. -TEST_F(BundyD2ControllerTest, basicInstanceTesting) { - // Verify the we can the singleton instance can be fetched and that - // it is the correct type. - DControllerBasePtr& controller = DControllerTest::getController(); - ASSERT_TRUE(controller); - ASSERT_NO_THROW(boost::dynamic_pointer_cast<D2Controller>(controller)); - - // Verify that controller's app name is correct. - EXPECT_TRUE(checkAppName(D2Controller::d2_app_name_)); - - // Verify that controller's bin name is correct. - EXPECT_TRUE(checkBinName(D2Controller::d2_bin_name_)); - - // Verify that controller's spec file name is correct. - EXPECT_TRUE(checkSpecFileName(D2_SPECFILE_LOCATION)); - - // Verify that controller's IOService exists. - EXPECT_TRUE(checkIOService()); - - // Verify that the Process does NOT exist. - EXPECT_FALSE(checkProcess()); -} - -/// @brief Tests basic command line processing. -/// Verifies that: -/// 1. Standard command line options are supported. -/// 2. Invalid options are detected. -TEST_F(BundyD2ControllerTest, commandLineArgs) { - char* argv[] = { const_cast<char*>("progName"), - const_cast<char*>("-v") }; - int argc = 2; - - // Verify that verbose flag is false initially. - EXPECT_TRUE(checkVerbose(false)); - - // Verify that standard options can be parsed without error. - EXPECT_NO_THROW(parseArgs(argc, argv)); - - // Verify that verbose flag is now true. - EXPECT_TRUE(checkVerbose(true)); - - // Verify that an unknown option is detected. - char* argv2[] = { const_cast<char*>("progName"), - const_cast<char*>("-x") }; - argc = 2; - EXPECT_THROW(parseArgs(argc, argv2), InvalidUsage); -} - -/// @brief Tests application process creation and initialization. -/// Verifies that the process can be successfully created and initialized. -TEST_F(BundyD2ControllerTest, initProcessTesting) { - ASSERT_NO_THROW(initProcess()); - EXPECT_TRUE(checkProcess()); -} - -/// @brief Configuration update event testing. -/// This really tests just the ability of the handlers to invoke the necessary -/// chain of methods and handle error conditions. Configuration parsing and -/// retrieval should be tested as part of the d2 configuration management -/// implementation. Note that this testing calls the configuration update event -/// callback, configHandler, directly. -/// This test verifies that: -/// 1. Configuration will be rejected in integrated mode when there is no -/// session established. (This is a very contrived situation). -/// 2. In stand-alone mode a configuration update results in successful -/// status return. -/// 3. That an application process error in configuration updating is handled -/// properly. -TEST_F(BundyD2ControllerTest, configUpdateTests) { - int rcode = -1; - isc::data::ConstElementPtr answer; - - // Initialize the application process. - ASSERT_NO_THROW(initProcess()); - EXPECT_TRUE(checkProcess()); - - // Create a configuration set using a small, valid D2 configuration. - isc::data::ElementPtr config_set = - isc::data::Element::fromJSON(valid_d2_config); - - // Configuration should be rejected as there is no session. This is a - // pretty contrived situation that shouldn't be possible other than the - // handler being called directly (like this does). - answer = D2Controller::configHandler(config_set); - isc::config::parseAnswer(rcode, answer); - EXPECT_EQ(1, rcode); -} - -/// @brief Command execution tests. -/// This really tests just the ability of the handler to invoke the necessary -/// chain of methods and to handle error conditions. Note that this testing -/// calls the command callback, commandHandler, directly. -/// This test verifies that: -/// 1. That an unrecognized command is detected and returns a status of -/// d2::COMMAND_INVALID. -/// 2. Shutdown command is recognized and returns a d2::COMMAND_SUCCESS status. -TEST_F(BundyD2ControllerTest, executeCommandTests) { - int rcode = -1; - isc::data::ConstElementPtr answer; - isc::data::ElementPtr arg_set; - - // Initialize the application process. - ASSERT_NO_THROW(initProcess()); - EXPECT_TRUE(checkProcess()); - - // Verify that an unknown command returns an COMMAND_INVALID response. - std::string bogus_command("bogus"); - answer = D2Controller::commandHandler(bogus_command, arg_set); - isc::config::parseAnswer(rcode, answer); - EXPECT_EQ(COMMAND_INVALID, rcode); - - // Verify that shutdown command returns COMMAND_SUCCESS response. - //answer = executeCommand(SHUT_DOWN_COMMAND, isc::data::ElementPtr()); - answer = D2Controller::commandHandler(SHUT_DOWN_COMMAND, arg_set); - isc::config::parseAnswer(rcode, answer); - EXPECT_EQ(COMMAND_SUCCESS, rcode); -} - -/// @brief Tests launch with a session establishment failure. -/// This test launches with a valid command line for integrated mode and no. -/// Attempting to connect to Bundy should fail, even if Bundy is running -/// UNLESS the test is run as root. Launch should throw SessionStartError. -TEST_F(BundyD2ControllerTest, launchSessionFailure) { - // Command line to run integrated - char* argv[] = { (char*)"progName" }; - int argc = 1; - - // Launch the controller in integrated mode. - EXPECT_THROW(launch(argc, argv), SessionStartError); -} - -}; // end of isc::d2 namespace -}; // end of isc namespace diff --git a/src/bin/d2/tests/d_test_stubs.h b/src/bin/d2/tests/d_test_stubs.h index 23d4efcd29..96325413fe 100644 --- a/src/bin/d2/tests/d_test_stubs.h +++ b/src/bin/d2/tests/d_test_stubs.h @@ -202,8 +202,6 @@ public: /// without polluting production derivations (e.g. D2Process). It uses /// DStubProcess as its application process class. It is a full enough /// implementation to support running both stand alone and integrated. -/// Obviously Bundy connectivity is not available under unit tests, so -/// testing here is limited to "failures" to communicate with Bundy. class DStubController : public DControllerBase { public: /// @brief Static singleton instance method. This method returns the diff --git a/src/bin/dhcp4/Makefile.am b/src/bin/dhcp4/Makefile.am index f085122bcd..cb5b50e3f5 100644 --- a/src/bin/dhcp4/Makefile.am +++ b/src/bin/dhcp4/Makefile.am @@ -56,13 +56,7 @@ libdhcp4_la_SOURCES += json_config_parser.cc json_config_parser.h libdhcp4_la_SOURCES += dhcp4_log.cc dhcp4_log.h libdhcp4_la_SOURCES += dhcp4_srv.cc dhcp4_srv.h -if CONFIG_BACKEND_BUNDY -libdhcp4_la_SOURCES += bundy_controller.cc -endif - -if CONFIG_BACKEND_JSON libdhcp4_la_SOURCES += kea_controller.cc -endif nodist_libdhcp4_la_SOURCES = dhcp4_messages.h dhcp4_messages.cc EXTRA_DIST += dhcp4_messages.mes diff --git a/src/bin/dhcp4/bundy_controller.cc b/src/bin/dhcp4/bundy_controller.cc deleted file mode 100644 index c5757485f0..0000000000 --- a/src/bin/dhcp4/bundy_controller.cc +++ /dev/null @@ -1,215 +0,0 @@ -// Copyright (C) 2012-2014 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. - -#include <config.h> - -#include <asiolink/asiolink.h> -#include <cc/data.h> -#include <cc/session.h> -#include <config/ccsession.h> -#include <dhcp/iface_mgr.h> -#include <dhcp4/json_config_parser.h> -#include <dhcp4/ctrl_dhcp4_srv.h> -#include <dhcp4/dhcp4_log.h> -#include <dhcp4/spec_config.h> -#include <dhcpsrv/cfgmgr.h> -#include <dhcpsrv/dhcp_config_parser.h> -#include <exceptions/exceptions.h> -#include <hooks/hooks_manager.h> -#include <util/buffer.h> - -#include <cassert> -#include <iostream> -#include <sstream> -#include <string> -#include <vector> - -using namespace isc::asiolink; -using namespace isc::cc; -using namespace isc::config; -using namespace isc::data; -using namespace isc::dhcp; -using namespace isc::hooks; -using namespace isc::log; -using namespace isc::util; -using namespace std; - -namespace isc { -namespace dhcp { - -/// @brief Helper session object that represents raw connection to msgq. -isc::cc::Session* cc_session_ = NULL; - -/// @brief Session that receives configuration and commands -isc::config::ModuleCCSession* config_session_ = NULL; - -/// @brief A dummy configuration handler that always returns success. -/// -/// This configuration handler does not perform configuration -/// parsing and always returns success. A dummy handler should -/// be installed using \ref isc::config::ModuleCCSession ctor -/// to get the initial configuration. This initial configuration -/// comprises values for only those elements that were modified -/// the previous session. The \ref dhcp4ConfigHandler can't be -/// used to parse the initial configuration because it needs the -/// full configuration to satisfy dependencies between the -/// various configuration values. Installing the dummy handler -/// that guarantees to return success causes initial configuration -/// to be stored for the session being created and that it can -/// be later accessed with -/// \ref isc::config::ConfigData::getFullConfig(). -/// -/// @param new_config new configuration. -/// -/// @return success configuration status. -ConstElementPtr -dhcp4StubConfigHandler(ConstElementPtr) { - // This configuration handler is intended to be used only - // when the initial configuration comes in. To receive this - // configuration a pointer to this handler must be passed - // using ModuleCCSession constructor. This constructor will - // invoke the handler and will store the configuration for - // the configuration session when the handler returns success. - // Since this configuration is partial we just pretend to - // parse it and always return success. The function that - // initiates the session must get the configuration on its - // own using getFullConfig. - return (isc::config::createAnswer(0, "Configuration accepted.")); -} - -ConstElementPtr -bundyConfigHandler(ConstElementPtr new_config) { - if (!ControlledDhcpv4Srv::getInstance() || !config_session_) { - // That should never happen as we install config_handler - // after we instantiate the server. - ConstElementPtr answer = - isc::config::createAnswer(1, "Configuration rejected," - " server is during startup/shutdown phase."); - return (answer); - } - - // The configuration passed to this handler function is partial. - // In other words, it just includes the values being modified. - // In the same time, there are dependencies between various - // DHCP configuration parsers. For example: the option value can - // be set if the definition of this option is set. If someone removes - // an existing option definition then the partial configuration that - // removes that definition is triggered while a relevant option value - // may remain configured. This eventually results in the DHCP server - // configuration being in the inconsistent state. - // In order to work around this problem we need to merge the new - // configuration with the existing (full) configuration. - - // Let's create a new object that will hold the merged configuration. - boost::shared_ptr<MapElement> merged_config(new MapElement()); - // Let's get the existing configuration. - ConstElementPtr full_config = config_session_->getFullConfig(); - // The full_config and merged_config should be always non-NULL - // but to provide some level of exception safety we check that they - // really are (in case we go out of memory). - if (full_config && merged_config) { - merged_config->setValue(full_config->mapValue()); - - // Merge an existing and new configuration. - isc::data::merge(merged_config, new_config); - LOG_DEBUG(dhcp4_logger, DBG_DHCP4_COMMAND, DHCP4_CONFIG_UPDATE) - .arg(full_config->str()); - } - - // Configure the server. - return (ControlledDhcpv4Srv::processConfig(merged_config)); -} - - - - -void ControlledDhcpv4Srv::init(const std::string& config_file) { - // Call base class's init. - Daemon::init(config_file); - - string specfile; - if (getenv("KEA_FROM_BUILD")) { - specfile = string(getenv("KEA_FROM_BUILD")) + - "/src/bin/dhcp4/dhcp4.spec"; - } else { - specfile = string(DHCP4_SPECFILE_LOCATION); - } - - /// @todo: Check if session is not established already. Throw, if it is. - - LOG_DEBUG(dhcp4_logger, DBG_DHCP4_START, DHCP4_CCSESSION_STARTING) - .arg(specfile); - cc_session_ = new Session(io_service_.get_io_service()); - // Create a session with the dummy configuration handler. - // Dumy configuration handler is internally invoked by the - // constructor and on success the constructor updates - // the current session with the configuration that had been - // committed in the previous session. If we did not install - // the dummy handler, the previous configuration would have - // been lost. - config_session_ = new ModuleCCSession(specfile, *cc_session_, - dhcp4StubConfigHandler, - processCommand, false); - config_session_->start(); - - // We initially create ModuleCCSession() without configHandler, as - // the session module is too eager to send partial configuration. - // We want to get the full configuration, so we explicitly call - // getFullConfig() and then pass it to our configHandler. - config_session_->setConfigHandler(bundyConfigHandler); - - try { - configureDhcp4Server(*this, config_session_->getFullConfig()); - - // Server will start DDNS communications if its enabled. - server_->startD2(); - - // Configuration may disable or enable interfaces so we have to - // reopen sockets according to new configuration. - CfgMgr::instance().getCurrentCfg()->cfg_iface_ - .openSockets(getPort(), useBroadcast()); - - } catch (const std::exception& ex) { - LOG_ERROR(dhcp4_logger, DHCP4_CONFIG_LOAD_FAIL).arg(ex.what()); - - } - - /// Integrate the asynchronous I/O model of former BIND 10/Bundy - /// configuration control with the "select" model of the DHCP server. - /// This is fully explained in \ref dhcpv4Session. - int ctrl_socket = cc_session_->getSocketDesc(); - LOG_DEBUG(dhcp4_logger, DBG_DHCP4_START, DHCP4_CCSESSION_STARTED) - .arg(ctrl_socket); - IfaceMgr::instance().addExternalSocket(ctrl_socket, sessionReader); -} - - -void ControlledDhcpv4Srv::cleanup() { - if (config_session_) { - delete config_session_; - config_session_ = NULL; - } - if (cc_session_) { - - int ctrl_socket = cc_session_->getSocketDesc(); - cc_session_->disconnect(); - - IfaceMgr::instance().deleteExternalSocket(ctrl_socket); - delete cc_session_; - cc_session_ = NULL; - } -} - -}; -}; diff --git a/src/bin/dhcp4/ctrl_dhcp4_srv.h b/src/bin/dhcp4/ctrl_dhcp4_srv.h index 2ac5533739..a0bd0369a3 100644 --- a/src/bin/dhcp4/ctrl_dhcp4_srv.h +++ b/src/bin/dhcp4/ctrl_dhcp4_srv.h @@ -1,4 +1,4 @@ -// Copyright (C) 2012-2014 Internet Systems Consortium, Inc. ("ISC") +// Copyright (C) 2012-2015 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 @@ -26,10 +26,8 @@ namespace dhcp { /// @brief Controlled version of the DHCPv4 server /// -/// This is a class that is responsible for DHCPv4 server being controllable. -/// It does various things, depending on the configuration backend. -/// For Bundy backend it establishes a connection with msqg and later receives -/// commands over it. For Kea backend, it reads configuration file from disk. +/// This is a class that is responsible for DHCPv4 server being controllable, +/// by reading configuration file from disk. /// /// For detailed explanation or relations between main(), ControlledDhcpv4Srv, /// Dhcpv4Srv and other classes, see \ref dhcpv4Session. @@ -58,12 +56,7 @@ public: /// @brief Performs cleanup, immediately before termination /// /// This method performs final clean up, just before the Dhcpv4Srv object - /// is destroyed. The actual behavior is backend dependent. For Bundy - /// backend, it terminates existing session with msgq. After calling - /// it, no further messages over msgq (commands or configuration updates) - /// may be received. For JSON backend, it is no-op. - /// - /// For specific details, see actual implementation in *_backend.cc + /// is destroyed. Currently it is a no-op. void cleanup(); /// @brief Initiates shutdown procedure for the whole DHCPv4 server. @@ -125,8 +118,7 @@ protected: /// /// This static callback method is called from IfaceMgr::receive6() method, /// when there is a new command or configuration sent over control socket - /// (that was sent from msgq if backend is Bundy, or some yet unspecified - /// sender if the backend is JSON file). + /// (that was sent from some yet unspecified sender). static void sessionReader(void); /// @brief IOService object, used for all ASIO operations. diff --git a/src/bin/dhcp4/dhcp4.dox b/src/bin/dhcp4/dhcp4.dox index 6638328c86..9364e8d175 100644 --- a/src/bin/dhcp4/dhcp4.dox +++ b/src/bin/dhcp4/dhcp4.dox @@ -1,4 +1,4 @@ -// Copyright (C) 2012-2014 Internet Systems Consortium, Inc. ("ISC") +// Copyright (C) 2012-2015 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 @@ -29,48 +29,9 @@ DHCPv4 server component does not support direct traffic (relayed only), as support for transmission to hosts without IPv4 address assigned is not implemented in IfaceMgr yet. -@section dhcpv4Session Bundy message queue integration - -DHCPv4 server now has two configuration backends: JSON and Bundy. The -following section applies only to the Bundy backend. - -DHCPv4 server component is now integrated with Bundy message queue. -The integration is performed by establishSession() and disconnectSession() -functions in isc::dhcp::ControlledDhcpv4Srv class. main() method defined -in the src/bin/dhcp4/main.cc file instantiates isc::dhcp::ControlledDhcpv4Srv -class that establishes connection with msgq and install necessary handlers -for receiving commands and configuration updates. It is derived from -a base isc::dhcp::Dhcpv4Srv class that implements DHCPv4 server functionality, -without any controlling mechanisms. - -ControlledDhcpv4Srv instantiates several components to make management -session possible. In particular, isc::cc::Session cc_session -object uses ASIO for establishing connection. It registers its socket -in isc::asiolink::IOService io_service object. Typically, other components -(e.g. auth or resolver) that use ASIO for their communication, register their -other sockets in the -same io_service and then just call io_service.run() method that does -not return, until one of the callback decides that it is time to shut down -the whole component cal calls io_service.stop(). DHCPv4 works in a -different way. It does receive messages using select() -(see isc::dhcp::IfaceMgr::receive4()), which is incompatible with ASIO. -To solve this problem, socket descriptor is extracted from cc_session -object and is passed to IfaceMgr by using isc::dhcp::IfaceMgr::set_session_socket(). -IfaceMgr then uses this socket in its select() call. If there is some -data to be read, it calls registered callback that is supposed to -read and process incoming data. - -This somewhat complicated approach is needed for a simple reason. In -embedded deployments there will be no message queue. Not referring directly -to anything related to message queue in isc::dhcp::Dhcpv4Srv and -isc::dhcp::IfaceMgr classes brings in two benefits. First, the can -be used with and without message queue. Second benefit is related to the -first one: \ref libdhcp is supposed to be simple and robust and not require -many dependencies. One notable example of a use case that benefits from -this approach is a perfdhcp tool. Finally, the idea is that it should be -possible to instantiate Dhcpv4Srv object directly, thus getting a server -that does not support msgq. That is useful for embedded environments. -It may also be useful in validation. +@section dhcpv4Session + +No longer applicable. @section dhcpv4ConfigParser Configuration Parser in DHCPv4 @@ -196,23 +157,13 @@ limited. @section dhcpv4ConfigBackend Configuration backend for DHCPv4 -There are many theoretical ways in which server configuration can be stored. Kea 0.8 and -earlier versions used BIND10/Bundy framework and its internal storage for DHCPv6 server configuration. +There are many theoretical ways in which server configuration can be stored. The legacy ISC-DHCP implementation uses flat files. Configuration stored in JSON files is becoming more and more popular among various projects. There are unofficial patches for ISC-DHCP that keep parts of the configuration in LDAP. It was also suggested that in some cases it would be convenient to keep configuration in XML files. -Kea 0.9 has introduced configuration backends that are switchable during compilation phase. -There is a new parameter for configure script: --with-kea-config. It currently supports -two values: BUNDY and JSON. - -BUNDY (which is the default value as of May 2014) means that Kea4 is linked with the -Bundy (former BIND10) configuration backend that connects to the Bundy/BIND10 framework and in general works -exactly the same as Kea 0.8 and earlier versions. The benefits of that backend are uniform -integration with Bundy/BIND10 framework, easy on-line reconfiguration using bindctl, available -RESTful API. On the other hand, it requires the whole heavy Bundy framework that requires -Python3 to be present. That framework is going away with the release of Kea 0.9. +Kea 0.9 has introduced configuration backends that are switchable during compilation phase. Currently the only choice is JSON. JSON is a new configuration backend that causes Kea to read JSON configuration file from disk. It does not require any framework and thus is considered more lightweight. It will @@ -221,10 +172,7 @@ API). This configuration backend is expected to be the default for upcoming Kea requires <tt> -c config-file </tt> command-line option. Internally, configuration backends are implemented as different implementations of the -isc::dhcp::ControlledDhcpv4Srv class, stored in {kea,bundy}_controller.cc files. Depending on -the choice made by ./configure script, only one of those files is compiled and linked. -There are backend specific tests in src/bin/dhcp4/tests/{kea,bundy}_controller_unittest.cc. -Only tests specific to selected backend are linked and executed during make distcheck. +isc::dhcp::ControlledDhcpv4Srv class, stored in kea_controller.cc files. While it is unlikely that ISC will support more than one backend at any given time, there are several aspects that make that approach appealing in the long term. First, having diff --git a/src/bin/dhcp4/tests/Makefile.am b/src/bin/dhcp4/tests/Makefile.am index 9a1a3df915..49dc7aed74 100644 --- a/src/bin/dhcp4/tests/Makefile.am +++ b/src/bin/dhcp4/tests/Makefile.am @@ -1,9 +1,7 @@ SHTESTS = # The test of dynamic reconfiguration based on signals will work only # if we are using file based configuration approach. -if CONFIG_BACKEND_JSON SHTESTS += dhcp4_process_tests.sh -endif noinst_SCRIPTS = dhcp4_process_tests.sh @@ -88,15 +86,7 @@ dhcp4_unittests_SOURCES += dhcp4_client.cc dhcp4_client.h dhcp4_unittests_SOURCES += inform_unittest.cc dhcp4_unittests_SOURCES += dora_unittest.cc -if CONFIG_BACKEND_BUNDY -# For Bundy backend, we only need to run the usual tests. There are no -# Bundy-specific tests yet. -dhcp4_unittests_SOURCES += bundy_controller_unittest.cc -endif - -if CONFIG_BACKEND_JSON dhcp4_unittests_SOURCES += kea_controller_unittest.cc -endif nodist_dhcp4_unittests_SOURCES = marker_file.h test_libraries.h diff --git a/src/bin/dhcp4/tests/bundy_controller_unittest.cc b/src/bin/dhcp4/tests/bundy_controller_unittest.cc deleted file mode 100644 index 802cef1a92..0000000000 --- a/src/bin/dhcp4/tests/bundy_controller_unittest.cc +++ /dev/null @@ -1,30 +0,0 @@ -// Copyright (C) 2014 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. - -#include <config.h> - -#include <gtest/gtest.h> - -namespace { - -/// As of May 2014, maintaining or extending Bundy support is very low -/// priority for Kea team. We are looking for contributors, who would -/// like to maintain this backend. - -// Bundy framework specific tests should be added here. -TEST(BundyBackendTest, dummy) { - -} - -} // End of anonymous namespace diff --git a/src/bin/dhcp6/Makefile.am b/src/bin/dhcp6/Makefile.am index 4c7827c55e..fb07d89478 100644 --- a/src/bin/dhcp6/Makefile.am +++ b/src/bin/dhcp6/Makefile.am @@ -58,13 +58,7 @@ libdhcp6_la_SOURCES += dhcp6_srv.cc dhcp6_srv.h libdhcp6_la_SOURCES += ctrl_dhcp6_srv.cc ctrl_dhcp6_srv.h libdhcp6_la_SOURCES += json_config_parser.cc json_config_parser.h -if CONFIG_BACKEND_BUNDY -libdhcp6_la_SOURCES += bundy_controller.cc -endif - -if CONFIG_BACKEND_JSON libdhcp6_la_SOURCES += kea_controller.cc -endif nodist_libdhcp6_la_SOURCES = dhcp6_messages.h dhcp6_messages.cc EXTRA_DIST += dhcp6_messages.mes diff --git a/src/bin/dhcp6/bundy_controller.cc b/src/bin/dhcp6/bundy_controller.cc deleted file mode 100644 index c4e12062c1..0000000000 --- a/src/bin/dhcp6/bundy_controller.cc +++ /dev/null @@ -1,226 +0,0 @@ -// Copyright (C) 2012-2014 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. - -#include <config.h> - -#include <asiolink/asiolink.h> -#include <cc/data.h> -#include <cc/session.h> -#include <config/ccsession.h> -#include <dhcp/iface_mgr.h> -#include <dhcpsrv/dhcp_config_parser.h> -#include <dhcpsrv/cfgmgr.h> -#include <dhcp6/json_config_parser.h> -#include <dhcp6/ctrl_dhcp6_srv.h> -#include <dhcp6/dhcp6_log.h> -#include <dhcp6/spec_config.h> -#include <exceptions/exceptions.h> -#include <hooks/hooks_manager.h> -#include <util/buffer.h> - -#include <cassert> -#include <iostream> -#include <string> -#include <vector> - -using namespace isc::asiolink; -using namespace isc::cc; -using namespace isc::config; -using namespace isc::data; -using namespace isc::dhcp; -using namespace isc::hooks; -using namespace isc::log; -using namespace isc::util; -using namespace std; - -namespace isc { -namespace dhcp { - -/// @brief Helper session object that represents raw connection to msgq. -isc::cc::Session* cc_session_ = NULL; - -/// @brief Session that receives configuration and commands -isc::config::ModuleCCSession* config_session_ = NULL; - -/// @brief A dummy configuration handler that always returns success. -/// -/// This configuration handler does not perform configuration -/// parsing and always returns success. A dummy handler should -/// be installed using \ref isc::config::ModuleCCSession ctor -/// to get the initial configuration. This initial configuration -/// comprises values for only those elements that were modified -/// the previous session. The \ref dhcp6ConfigHandler can't be -/// used to parse the initial configuration because it needs the -/// full configuration to satisfy dependencies between the -/// various configuration values. Installing the dummy handler -/// that guarantees to return success causes initial configuration -/// to be stored for the session being created and that it can -/// be later accessed with -/// \ref isc::config::ConfigData::getFullConfig(). -/// -/// @param new_config new configuration. -/// -/// @return success configuration status. -ConstElementPtr -dhcp6StubConfigHandler(ConstElementPtr) { - // This configuration handler is intended to be used only - // when the initial configuration comes in. To receive this - // configuration a pointer to this handler must be passed - // using ModuleCCSession constructor. This constructor will - // invoke the handler and will store the configuration for - // the configuration session when the handler returns success. - // Since this configuration is partial we just pretend to - // parse it and always return success. The function that - // initiates the session must get the configuration on its - // own using getFullConfig. - return (isc::config::createAnswer(0, "Configuration accepted.")); -} - -ConstElementPtr -bundyConfigHandler(ConstElementPtr new_config) { - - if (!ControlledDhcpv6Srv::getInstance() || !config_session_) { - // That should never happen as we install config_handler - // after we instantiate the server. - ConstElementPtr answer = - isc::config::createAnswer(1, "Configuration rejected," - " server is during startup/shutdown phase."); - return (answer); - } - - // The configuration passed to this handler function is partial. - // In other words, it just includes the values being modified. - // In the same time, there are dependencies between various - // DHCP configuration parsers. For example: the option value can - // be set if the definition of this option is set. If someone removes - // an existing option definition then the partial configuration that - // removes that definition is triggered while a relevant option value - // may remain configured. This eventually results in the DHCP server - // configuration being in the inconsistent state. - // In order to work around this problem we need to merge the new - // configuration with the existing (full) configuration. - - // Let's create a new object that will hold the merged configuration. - boost::shared_ptr<MapElement> merged_config(new MapElement()); - // Let's get the existing configuration. - ConstElementPtr full_config = config_session_->getFullConfig(); - // The full_config and merged_config should be always non-NULL - // but to provide some level of exception safety we check that they - // really are (in case we go out of memory). - if (full_config && merged_config) { - merged_config->setValue(full_config->mapValue()); - - // Merge an existing and new configuration. - isc::data::merge(merged_config, new_config); - LOG_DEBUG(dhcp6_logger, DBG_DHCP6_COMMAND, DHCP6_CONFIG_UPDATE) - .arg(merged_config->str()); - } - - // Configure the server. - - return (ControlledDhcpv6Srv::processConfig(merged_config)); -} - -void -ControlledDhcpv6Srv::init(const std::string& config_file) { - // Call base class's init. - Daemon::init(config_file); - - // This is Bundy configuration backed. It established control session - // that is used to connect to Bundy framework. - // - // Creates session that will be used to receive commands and updated - // configuration from cfgmgr (or indirectly from user via bindctl). - - string specfile; - if (getenv("KEA_FROM_BUILD")) { - specfile = string(getenv("KEA_FROM_BUILD")) + - "/src/bin/dhcp6/dhcp6.spec"; - } else { - specfile = string(DHCP6_SPECFILE_LOCATION); - } - - /// @todo: Check if session is not established already. Throw, if it is. - - LOG_DEBUG(dhcp6_logger, DBG_DHCP6_START, DHCP6_CCSESSION_STARTING) - .arg(specfile); - cc_session_ = new Session(io_service_.get_io_service()); - // Create a session with the dummy configuration handler. - // Dumy configuration handler is internally invoked by the - // constructor and on success the constructor updates - // the current session with the configuration that had been - // committed in the previous session. If we did not install - // the dummy handler, the previous configuration would have - // been lost. - config_session_ = new ModuleCCSession(specfile, *cc_session_, - dhcp6StubConfigHandler, - processCommand, false); - config_session_->start(); - - // The constructor already pulled the configuration that had - // been created in the previous session thanks to the dummy - // handler. We can switch to the handler that will be - // parsing future changes to the configuration. - config_session_->setConfigHandler(bundyConfigHandler); - - try { - // Pull the full configuration out from the session. - processConfig(config_session_->getFullConfig()); - - // Server will start DDNS communications if its enabled. - server_->startD2(); - - // Configuration may disable or enable interfaces so we have to - // reopen sockets according to new configuration. - // Configuration may disable or enable interfaces so we have to - // reopen sockets according to new configuration. - CfgMgr::instance().getConfiguration()->cfg_iface_ - .openSockets(getPort(), useBroadcast()); - - } catch (const std::exception& ex) { - LOG_ERROR(dhcp6_logger, DHCP6_CONFIG_LOAD_FAIL).arg(ex.what()); - - } - - /// Integrate the asynchronous I/O model of Bundy configuration - /// control with the "select" model of the DHCP server. This is - /// fully explained in \ref dhcpv6Session. - int ctrl_socket = cc_session_->getSocketDesc(); - LOG_DEBUG(dhcp6_logger, DBG_DHCP6_START, DHCP6_CCSESSION_STARTED) - .arg(ctrl_socket); - IfaceMgr::instance().addExternalSocket(ctrl_socket, sessionReader); - - return; -} - -void ControlledDhcpv6Srv::cleanup() { - if (config_session_) { - delete config_session_; - config_session_ = NULL; - } - if (cc_session_) { - - int ctrl_socket = cc_session_->getSocketDesc(); - cc_session_->disconnect(); - - // deregister session socket - IfaceMgr::instance().deleteExternalSocket(ctrl_socket); - - delete cc_session_; - cc_session_ = NULL; - } -} - -}; // end of isc::dhcp namespace -}; // end of isc namespace diff --git a/src/bin/dhcp6/ctrl_dhcp6_srv.h b/src/bin/dhcp6/ctrl_dhcp6_srv.h index 9789bb077f..e84afcddff 100644 --- a/src/bin/dhcp6/ctrl_dhcp6_srv.h +++ b/src/bin/dhcp6/ctrl_dhcp6_srv.h @@ -1,4 +1,4 @@ -// Copyright (C) 2012-2014 Internet Systems Consortium, Inc. ("ISC") +// Copyright (C) 2012-2015 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 @@ -26,10 +26,8 @@ namespace dhcp { /// @brief Controlled version of the DHCPv6 server /// -/// This is a class that is responsible for DHCPv6 server being controllable. -/// It does various things, depending on the configuration backend. -/// For Bundy backend it establishes a connection with msqg and later receives -/// commands over it. For Kea backend, it reads configuration file from disk. +/// This is a class that is responsible for DHCPv6 server being controllable, +/// by reading configuration file from disk. /// /// For detailed explanation or relations between main(), ControlledDhcpv6Srv, /// Dhcpv6Srv and other classes, see \ref dhcpv6Session. @@ -58,12 +56,7 @@ public: /// @brief Performs cleanup, immediately before termination /// /// This method performs final clean up, just before the Dhcpv6Srv object - /// is destroyed. The actual behavior is backend dependent. For Bundy - /// backend, it terminates existing session with msgq. After calling - /// it, no further messages over msgq (commands or configuration updates) - /// may be received. For JSON backend, it is no-op. - /// - /// For specific details, see actual implementation in *_backend.cc + /// is destroyed. Currently it is a no-op. void cleanup(); /// @brief Initiates shutdown procedure for the whole DHCPv6 server. @@ -83,7 +76,7 @@ public: /// /// @note It never throws. /// - /// @param command Text represenation of the command (e.g. "shutdown") + /// @param command Text representation of the command (e.g. "shutdown") /// @param args Optional parameters /// /// @return status of the command @@ -124,8 +117,7 @@ protected: /// /// This static callback method is called from IfaceMgr::receive6() method, /// when there is a new command or configuration sent over control socket - /// (that was sent from msgq if backend is Bundy, or some yet unspecified - /// sender if the backend is JSON file). + /// (that was sent from some yet unspecified sender). static void sessionReader(void); /// @brief IOService object, used for all ASIO operations. diff --git a/src/bin/dhcp6/dhcp6.dox b/src/bin/dhcp6/dhcp6.dox index 09d0316dd3..cf0349f4fc 100644 --- a/src/bin/dhcp6/dhcp6.dox +++ b/src/bin/dhcp6/dhcp6.dox @@ -28,33 +28,12 @@ DHCPv6 server component does not support relayed traffic yet, as support for relay decapsulation is not implemented yet. - @section dhcpv6Session Bundy message queue integration + @section dhcpv6Session -DHCPv6 server now has two configuration backends: JSON and Bundy. The -following section applies only to the Bundy backend. - - DHCPv6 server component is now integrated with Bundy/BIND10 message queue. - It follows the same principle as DHCPv4. See \ref dhcpv4Session for - details. + No longer applicable. @section dhcpv6ConfigParser Configuration Parser in DHCPv6 - kea-dhcp6 compiled with Bundy backend uses Bundy cfgmgr for commands and - configuration. During initial configuration (See \ref - isc::dhcp::ControlledDhcpv6Srv::init() in bundy_controller.cc), the configuration handler - callback is installed (see bundyConfigHandler(). - It is called every time there is a new configuration. In particular, it is - called every time during daemon start process. It contains a - isc::data::ConstElementPtr to a new configuration. This simple handler calls - \ref isc::dhcp::configureDhcp6Server() method that processes received configuration. - - This method iterates over list of received configuration elements and creates a - list of parsers for each received entry. Parser is an object that is derived - from a DhcpConfigParser class. Once a parser is created - (constructor), its value is set (using build() method). Once all parsers are - build, the configuration is then applied ("committed") and commit() method is - called. - \note With the implementation of the Kea ticket #3534 we're moving away from the concept of commit being called for individual parsers. When this ticket and a couple of followup tickets are implemented, the commit will be a @@ -232,23 +211,13 @@ limited. @section dhcpv6ConfigBackend Configuration backend for DHCPv6 -There are many theoretical ways in which server configuration can be stored. Kea 0.8 and -earlier versions used Bundy/BIND10 framework and its internal storage for DHCPv6 server configuration. +There are many theoretical ways in which server configuration can be stored. The legacy ISC-DHCP implementation uses flat files. Configuration stored in JSON files is becoming more and more popular among various projects. There are unofficial patches for ISC-DHCP that keep parts of the configuration in LDAP. It was also suggested that in some cases it would be convenient to keep configuration in XML files. -Kea 0.9 has introduced configuration backends that are switchable during compilation phase. -There is a new parameter for configure script: --with-kea-config. It currently supports -two values: BUNDY and JSON. - -BUNDY (which is the default value as of April 2014) means that Kea6 is linked with the -Bundy (former BIND10) configuration backend that connects to the Bundy/BIND10 framework and in general works -exactly the same as Kea 0.8 and earlier versions. The benefits of that backend are uniform -integration with Bundy/BIND10 framework, easy on-line reconfiguration using bindctl, available -RESTful API. On the other hand, it requires the whole heavy Bundy framework that requires -Python3 to be present. That framework is going away with the release of Kea 0.9. +Kea 0.9 has introduced configuration backends that are switchable during compilation phase. Currently the only choice is JSON. JSON is a new configuration backend that causes Kea to read JSON configuration file from disk. It does not require any framework and thus is considered more lightweight. It will @@ -256,11 +225,8 @@ allow dynamic on-line reconfiguration, but will lack remote capabilities (i.e. n API). This configuration backend is expected to be the default for upcoming Kea 0.9. It requires <tt> -c config-file </tt> command-line option. -Internally, configuration backends are implemented as different implementations of the -isc::dhcp::ControlledDhcpv6Srv class, stored in {kea,bundy}_controller.cc files. Depending on -the choice made by ./configure script, only one of those files is compiled and linked. -There are backend specific tests in src/bin/dhcp6/tests/{kea,bundy}_controller_unittest.cc. -Only tests specific to selected backend are linked and executed during make distcheck. +Internally, the configuration backend is implemented as am implementations of the +isc::dhcp::ControlledDhcpv6Srv class, stored in kea_controller.cc files. While it is unlikely that ISC will support more than one backend at any given time, there are several aspects that make that approach appealing in the long term. First, having diff --git a/src/bin/dhcp6/main.cc b/src/bin/dhcp6/main.cc index 9c74921f9a..3d801d0bdc 100644 --- a/src/bin/dhcp6/main.cc +++ b/src/bin/dhcp6/main.cc @@ -144,8 +144,7 @@ main(int argc, char* argv[]) { try { // Initialize the server, e.g. establish control session - // if Bundy backend is used or read a configuration file - // if Kea backend is used. + // Read a configuration file server.init(config_file); } catch (const std::exception& ex) { diff --git a/src/bin/dhcp6/tests/Makefile.am b/src/bin/dhcp6/tests/Makefile.am index eca758b340..e11e7d3a0d 100644 --- a/src/bin/dhcp6/tests/Makefile.am +++ b/src/bin/dhcp6/tests/Makefile.am @@ -1,9 +1,7 @@ SHTESTS = # The test of dynamic reconfiguration based on signals will work only # if we are using file based configuration approach. -if CONFIG_BACKEND_JSON SHTESTS += dhcp6_process_tests.sh -endif noinst_SCRIPTS = dhcp6_process_tests.sh @@ -88,15 +86,7 @@ dhcp6_unittests_SOURCES += confirm_unittest.cc dhcp6_unittests_SOURCES += infrequest_unittest.cc dhcp6_unittests_SOURCES += dhcp6_message_test.cc dhcp6_message_test.h -if CONFIG_BACKEND_BUNDY -# For Bundy backend, we only need to run the usual tests. There are no -# Bundy-specific tests yet. -dhcp6_unittests_SOURCES += bundy_controller_unittest.cc -endif - -if CONFIG_BACKEND_JSON dhcp6_unittests_SOURCES += kea_controller_unittest.cc -endif nodist_dhcp6_unittests_SOURCES = marker_file.h test_libraries.h diff --git a/src/bin/dhcp6/tests/bundy_controller_unittest.cc b/src/bin/dhcp6/tests/bundy_controller_unittest.cc deleted file mode 100644 index 0578ec6fe6..0000000000 --- a/src/bin/dhcp6/tests/bundy_controller_unittest.cc +++ /dev/null @@ -1,30 +0,0 @@ -// Copyright (C) 2014 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. - -#include <config.h> - -#include <gtest/gtest.h> - -namespace { - -/// As of May 2014, maintaining or extending Bundy support is very low -/// prority for Kea team. We are looking for contributors, who would -/// like to maintain this backend. - -// Bundy framework specific tests should be added here. -TEST(BundyBackendTest, dummy) { - -} - -} // End of anonymous namespace diff --git a/src/lib/cc/session.cc b/src/lib/cc/session.cc index f2d0f23135..a46fb18f77 100644 --- a/src/lib/cc/session.cc +++ b/src/lib/cc/session.cc @@ -1,4 +1,4 @@ -// Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") +// Copyright (C) 2009, 2015 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 @@ -309,10 +309,10 @@ public: void Session::establish(const char* socket_file) { if (socket_file == NULL) { - socket_file = getenv("BUNDY_MSGQ_SOCKET_FILE"); + socket_file = getenv("MSGQ_SOCKET_FILE"); } if (socket_file == NULL) { - socket_file = BUNDY_MSGQ_SOCKET_FILE; + socket_file = MSGQ_SOCKET_FILE; } impl_->establish(*socket_file); diff --git a/src/lib/cc/session_config.h.pre.in b/src/lib/cc/session_config.h.pre.in index 60eb7ac444..96ff421d43 100644 --- a/src/lib/cc/session_config.h.pre.in +++ b/src/lib/cc/session_config.h.pre.in @@ -1,2 +1,2 @@ -#define BUNDY_MSGQ_SOCKET_FILE "@@LOCALSTATEDIR@@/@PACKAGE@/msgq_socket" +#define MSGQ_SOCKET_FILE "@@LOCALSTATEDIR@@/@PACKAGE@/msgq_socket" diff --git a/src/lib/cc/tests/session_unittests.cc b/src/lib/cc/tests/session_unittests.cc index 241af59c61..6df848e4a4 100644 --- a/src/lib/cc/tests/session_unittests.cc +++ b/src/lib/cc/tests/session_unittests.cc @@ -1,4 +1,4 @@ -// Copyright (C) 2009,2015 Internet Systems Consortium, Inc. ("ISC") +// Copyright (C) 2009, 2015 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 @@ -84,7 +84,7 @@ public: ~TestDomainSocket() { socket_.close(); - unlink(BUNDY_TEST_SOCKET_FILE); + unlink(TEST_SOCKET_FILE); } static void acceptHandler(const asio::error_code&) { @@ -165,8 +165,8 @@ protected: SessionTest() : sess(my_io_service), work(my_io_service) { // The TestDomainSocket is held as a 'new'-ed pointer, // so we can call unlink() first. - unlink(BUNDY_TEST_SOCKET_FILE); - tds = new TestDomainSocket(my_io_service, BUNDY_TEST_SOCKET_FILE); + unlink(TEST_SOCKET_FILE); + tds = new TestDomainSocket(my_io_service, TEST_SOCKET_FILE); } ~SessionTest() { @@ -226,25 +226,25 @@ TEST_F(SessionTest, timeout_on_connect) { sess.setTimeout(100); EXPECT_EQ(100, sess.getTimeout()); // no answer, should timeout - EXPECT_THROW(sess.establish(BUNDY_TEST_SOCKET_FILE), SessionTimeout); + EXPECT_THROW(sess.establish(TEST_SOCKET_FILE), SessionTimeout); } TEST_F(SessionTest, connect_ok) { tds->setSendLname(); - sess.establish(BUNDY_TEST_SOCKET_FILE); + sess.establish(TEST_SOCKET_FILE); } TEST_F(SessionTest, connect_ok_no_timeout) { tds->setSendLname(); sess.setTimeout(0); - sess.establish(BUNDY_TEST_SOCKET_FILE); + sess.establish(TEST_SOCKET_FILE); } TEST_F(SessionTest, connect_ok_connection_reset) { tds->setSendLname(); - sess.establish(BUNDY_TEST_SOCKET_FILE); + sess.establish(TEST_SOCKET_FILE); // Close the session again, so the next recv() should throw sess.disconnect(); @@ -255,7 +255,7 @@ TEST_F(SessionTest, connect_ok_connection_reset) { TEST_F(SessionTest, run_with_handler) { tds->setSendLname(); - sess.establish(BUNDY_TEST_SOCKET_FILE); + sess.establish(TEST_SOCKET_FILE); sess.startRead(boost::bind(&SessionTest::someHandler, this)); isc::data::ElementPtr env = isc::data::Element::fromJSON("{ \"to\": \"me\" }"); @@ -279,7 +279,7 @@ TEST_F(SessionTest, run_with_handler) { TEST_F(SessionTest, run_with_handler_timeout) { tds->setSendLname(); - sess.establish(BUNDY_TEST_SOCKET_FILE); + sess.establish(TEST_SOCKET_FILE); sess.startRead(boost::bind(&SessionTest::someHandler, this)); sess.setTimeout(100); @@ -299,7 +299,7 @@ TEST_F(SessionTest, run_with_handler_timeout) { TEST_F(SessionTest, get_socket_descr) { tds->setSendLname(); - sess.establish(BUNDY_TEST_SOCKET_FILE); + sess.establish(TEST_SOCKET_FILE); int socket = 0; // session is established, so getSocketDesc() should work @@ -313,7 +313,7 @@ TEST_F(SessionTest, get_socket_descr) { TEST_F(SessionTest, group_sendmsg) { // Connect (to set the lname, so we can see it sets the from) tds->setSendLname(); - sess.establish(BUNDY_TEST_SOCKET_FILE); + sess.establish(TEST_SOCKET_FILE); // Eat the "get_lname" message, so it doesn't confuse the // test below. sess.getSentMessage(); diff --git a/src/lib/cc/tests/session_unittests_config.h.in b/src/lib/cc/tests/session_unittests_config.h.in index 9157d83e14..62571c1df4 100644 --- a/src/lib/cc/tests/session_unittests_config.h.in +++ b/src/lib/cc/tests/session_unittests_config.h.in @@ -1,2 +1,2 @@ -#define BUNDY_TEST_SOCKET_FILE "@builddir@/test_socket.sock" +#define TEST_SOCKET_FILE "@builddir@/test_socket.sock" diff --git a/src/lib/config/ccsession.cc b/src/lib/config/ccsession.cc index 532709a394..5cf4cc62a0 100644 --- a/src/lib/config/ccsession.cc +++ b/src/lib/config/ccsession.cc @@ -1,4 +1,4 @@ -// Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") +// Copyright (C) 2009, 2015 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 @@ -180,24 +180,7 @@ ConstElementPtr getValueOrDefault(ConstElementPtr config_part, /// @brief Prefix name with "kea-". /// -/// In BIND 10, modules had names taken from the .spec file, which are typically -/// names starting with a capital letter (e.g. "Resolver", "Auth" etc.). The -/// names of the associated binaries are derived from the module names, being -/// prefixed "b10-" and having the first letter of the module name lower-cased -/// (e.g. "b10-resolver", "b10-auth"). (It is a required convention that there -/// be this relationship between the names.) -/// -/// In Kea we're not using module names, but we do still keep some capability to -/// run Kea servers in Bundy framework. For that reason the whole discussion here -/// applies only to case when Kea is compiled with Bundy configuration backend. -/// -/// Within the binaries the root loggers are named after the binaries themselves. -/// (The reason for this is that the name of the logger is included in the -/// message logged, so making it clear which message comes from which Kea -/// process.) As logging is configured using module names, the configuration code -/// has to match these with the corresponding logger names. This function -/// converts a module name to a root logger name by lowercasing the first letter -/// of the module name and prepending "kea-". +/// should be no long applicable, kept for legacy. /// /// \param instring String to convert. (This may be empty, in which case /// "kea-" will be returned.) |