kea/doc/devel/config-backend.dox

// 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.

/**

 @page configBackend Kea Configuration Backends

@section configBackendIntro Introduction

Kea is a flexible DHCP protocol engine. It offers a selection of lease database
backends, extensibility via the hooks API and the definition of custom options.
Depending on the environment, one lease database backend may be better than
other. Similarly, because the best way of configuring the server can depend on
the environment, Kea provides different ways of obtaining configuration
information, through the Configuration Backend. Since the means by which
configuration information is received cannot be part of the configuration itself, it
has to be chosen at the compilation time (when configuring the sources).

This page explains the background to the Configuration Backend and how
it is implemented. It is aimed at people who want to develop and
maintain their own backends.

@section configBackendMotivation Motivation for Different Backends

BIND10 (the project under which the first stages of Kea were developed)
used to maintain an extensive framework that was responsible for the
configuration of components.  After BIND10 was cancelled, two projects
were created: <a href="http://kea.isc.org">Kea</a> (focused on DHCP)
and <a href="http://www.bundy-dns.de">Bundy</a> (aimed at DNS). The
Kea team decided to remove the BIND10 framework, while the Bundy team
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
(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
developed and maintained by other organizations.

@section configBackendAdding How to Add a New Configuration Backend

The configuration backend concept was designed to make external (i.e. not
maintained by ISC) configurations backends easy to maintain. In particular,
the set of patches vs. separate files required strongly favors separate
files. This is important if an external organization wants to develop its
own configuration backend and then needs to apply it to every ISC release
of Kea.

The following steps are needed to add new configuration backend (it is assumed
that the modified component is DHCPv4. Similar approach applies to the other
components: DHCPv6 or DHCP-DDNS):

-# Write your own implementation of isc::dhcp::ControlledDhcpv4Srv::init(),
   isc::dhcp::ControlledDhcpv4Srv::init() and isc::dhcp::ControlledDhcpv4Srv::cleanup()
   and put it in the src/bin/dhcp4 directory (e.g. as foo_controller.cc).
-# Modify src/bin/dhcp4/Makefile.am to include your file (e.g. foo_controller.cc) in
   the build.
-# Modify the AC_ARG_WITH(kea-config,...) macro in configure.ac to include an
   entry for your configuration backend.
-# Add your own AM_CONDITIONAL(CONFIG_BACKEND_FOO, ...) and
   AC_DEFINE(CONFIG_BACKEND_FOO, ...) macros to configure.ac (following the
   above-mentioned AC_ARG_WITH macro) to set the C++ macro for your backend.
-# Modify the sanity check in configure.ac to allow your configuration backend name.

Optionally you can also:

-# Implement unit tests for your backend in the src/bin/dhcp4/tests directory.
-# Modify src/bin/dhcp4/tests/Makefile.am to include the file(s) containing the
   unit tests.

@section configBackendJSONDesign The JSON Configuration Backend

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/>
   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
   one file or another. Hence it is easy to remove the old backend (and for
   external projects, like Bundy, to keep it if they desire). It is also easy
   for other organizations to add and maintain their own backends (e.g. LDAP).<br/><br/>
-# Each backend uses the common code for configuration and command
   processing callbacks. They all assume that JSON formatted parameters are sent
   and they are expected to return well formatted JSON responses. The exact
   format of configuration and commands is module-specific.<br/><br/>
-# A command handler handles the reading the configuration from a
   file. Its main responsibility is to load the configuration and process
   it. The JSON backend must call that handler when starting up the server.
   This is implemented in configure() in the kea_controller.cc files
   in src/bin/dhcp4 and src/bin/dhcp6 directories.<br/><br/>
-# The current JSON parser in @ref
   isc::data::Element::fromJSON() has been extended to allow optional
   preprocessing.  For now, that capability simply removes  whole-line
   comments starting with the hash character, but it is expected to grow over
   time (in-line comments and file inclusions are the obvious envisaged
   additions). This is implemented in @ref isc::data::Element::fromJSONFile.<br/><br/>
-# The current format of the BIND10 configuration file (BIND 10 stored its
   configuration in (installation directory) /var/bind10/b10-config.db) has been
   retained as the configuration file format. Its actual naming is now arbitrary
   and left up to the user (it is passed as a parameter to the -c command line
   option). From the implementation perspective, this is slight change
   from the BIND10 days, as back then a subset of the configuration was received by
   the daemon processes. Nowadays the whole configuration is pased. To take a
   specific example, the following is how b10-config.db looks today:
   @code
   {
     "Init": { ... }
     "Dhcp4": {
       "subnet4" { subnet definitions here },
       "option-data" { option data here },
       "interfaces": [ "eth0" ],
       ...
    },
     "Dhcp6": {
       "subnet6" { subnet definitions here },
       "option-data" { option data here },
       "interfaces": [ "eth0" ],
       ...
     },
     "Logging": {
       "Loggers": [{"name": *, "severity": "DEBUG" }]
      }
   }
   @endcode
   The Kea components used to receive only relevant parts of it (e.g. Kea4
   received configuration data that only contained the content of the Dhcp4 element).
   Now each component receives all of it: the code
   iterates over the top level elements and picks the appropriate
   tree (or get the element by name). That approach makes the common configuration
   (such as the logging initialization code) very easy to share among Kea4, Kea6 and
   DHCP-DDNS.<br/><br/>
-# The .spec files used in BIND 10 by the control program to validate commands
   have been retained. They will be kept and maintained even though no use of
   them is currently planned. At some future time syntax validation may be implemented,
   although it is out of scope for Kea 0.9 (and probably
   for 1.0 as well, as it is a pretty big task).<br/><br/>
-# A shell script has been added (as src/bin/keactrl/keactrl) to
   start, stop and reconfigure the daemons. Its only
   job is to pass the configuration file to each daemon and remember its PID file, so
   that sending signals is possible (for configuration reload or shutdown). It is also
   able to print out a status.

Future changes planned for this part of the code are:

-# Implement a common base class for the Kea4, Kea6, and D2 servers. Some
   operations will be common for all three components: logger initialization,
   handling and, at some future point, control socket. This calls for a small
   base class that @ref isc::dhcp::Dhcpv4Srv "Dhcpv4Srv", @ref
   isc::dhcp::Dhcpv6Srv "Dhcpv6Srv" and the @ref isc::d2::D2Controller
   "D2Controller" classes can use.  It is expected that the base class (@ref
   isc::dhcp::Daemon) will be a small one but will grow over time as the code is
   unified. This has been implemented in @ref isc::dhcp::Daemon.<br/><br/>
-# After Kea 0.9 is released, a form of secure socket will be implemented
   through which commands can be sent. Whatever the design, it will allow the
   sending of configurations and commands in JSON format and the receiving of
   responses.  Once that is done, Kea will have the same capability the BIND10
   framework to send additional parameters. One obvious use case will be to send
   a new configuration file name as the parameter for "reload".

*/