Skip to content
GitLab
Menu
Projects
Groups
Snippets
Loading...
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
Sebastian Schrader
Kea
Commits
ba5dc889
Commit
ba5dc889
authored
Jul 09, 2014
by
Tomek Mrugalski
🛰
Browse files
[3396] Changes after review:
- Configuration backend description updated - ChangeLog entry updated
parent
bcdb6c33
Changes
2
Hide whitespace changes
Inline
Side-by-side
ChangeLog
View file @
ba5dc889
7XX. [doc] tomek
Developer's Guide updated with pointers updated from BIND10 to
Kea.
Developer's Guide updated to Change BIND 10 references to Kea.
(Trac #3396, git tbd)
791. [func] tmark
...
...
doc/devel/config-backend.dox
View file @
ba5dc889
...
...
@@ -60,17 +60,18 @@ 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 other
components):
components
: DHCPv6 or D2
):
-# Modify AC_ARG_WITH(kea-config,...) macro in configure.ac
-# Add your own AM_CONDITIONAL(CONFIG_BACKEND_FOO, ...) macro in configure.ac
-# Add your own conditional AC_DEFINE(CONFIG_BACKEND_FOO, ...) invocation
in configure.ac
-# Modify sanity check in configure.ac to allow your configuration backend name.
-# Modify
the
sanity check in configure.ac to allow your configuration backend name.
-# Modify src/bin/dhcp4/Makefile.am to include your own backend
implementation (e.g. foo_controller.cc).
-# Write your own implementation of isc::dhcp::ControlledDhcpv4Srv::init(),
isc::dhcp::ControlledDhcpv4Srv::init() and isc::dhcp::ControlledDhcpv4Srv::cleanup().
isc::dhcp::ControlledDhcpv4Srv::init() and isc::dhcp::ControlledDhcpv4Srv::cleanup()
and put it in foo_controller.cc
Optionally you can also:
...
...
@@ -83,20 +84,21 @@ Optionally you can also:
The following are some considerations that shaped the design of the configuration
backend framework.
-# A new parameter called --with-kea-config w
ill be
implemented in the
configure script. It
will
allow the selection at compilation time of how the
servers will be configured.
For the next 2-3 months (until around
June 2014),
there
will b
e two values: JSON (
read from file) and BUNDY (use the BUNDY/BIND10 framework).
Once the file based configuration is implemented and the Kea team is ready to switch
(i.e. enough confidence, Forge tests updated for new configuration
mechanism), the Bundy/BIND10 framework will be removed from the Kea repository. Other projects
(e.g. Bundy) who want to maintain it, are advised to just revert the single
commit that will bring
th
e
Bundy
framework back to their repositories
.
-# A new parameter called --with-kea-config w
as
implemented in the
configure script. It allow
s
the selection at compilation time of how the
servers will be configured.
Currently (
June 2014),
there
ar
e two values: JSON (
the default, read configuration from a JSON file)
and BUNDY (use the BUNDY/BIND10 framework). The Bundy/BIND10 framework was removed
from the Kea repository. Other projects
(e.g. Bundy) who want to maintain Bundy framework, are advised to maintain
the framework in their repositories, import Kea modules and compile them
wi
th Bundy
backend
.
This switchable backend concept is quite simple. There are just different
implementations of ControlledXSrv class, so it is a matter of compiling/linking
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
Bundy to keep it if they desire so). It is also easy
for other
organizations to add and maintain their own backends (e.g. LDAP).
external projects, like
Bundy
,
to keep it if they desire so). It is also easy
for other
organizations to add and maintain their own backends (e.g. LDAP).
-# Each backend must use the common code for configuration and command
processing callbacks. They all assume that JSON formatted parameters are sent
...
...
@@ -113,13 +115,15 @@ backend framework.
-# A command handler needs to be added for 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() function in kea_controller.cc files
in src/bin/dhcp4 and src/bin/dhcp6 directories.
-# Extend the existing JSON parser. The current JSON parser in @ref
isc::data::Element::fromJSON() needs to be extended to allow optional
preprocessing. For now that capability
will
simply remove whole-line
preprocessing. For now that capability simply remove
s
whole-line
comments staring with the hash character, but it is expected to grow over
time (in-line comments and file inclusions are the obvious envisaged
additions).
additions).
This is implemented in @ref isc::data::Element::fromJSONFile.
-# Implement a common base class for the Kea4, Kea6, and D2 servers. Some
operations will be common for all three components: logger initialization,
...
...
@@ -128,16 +132,19 @@ backend framework.
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.
unified.
This has been implemented in @ref isc::dhcp::Daemon.
-# A way is needed to initialize stand-alone logging (i.e. each
Kea component will initialize it on its own).
-# The current format of the BIND10 configuration file, b10-config.db will be
retained as the configuration file format. This is slight change
from the BIND10 days, as then a subset of the configuration was received by
the daemon processes. To take a specific example, the following is how
b10-config.db looks today:
-# The current format of the BIND10 configuration file (BIND 10 stored its
configuration in (installation directory)/var/bind10/b10-config.db) will be
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": { ... }
...
...
@@ -186,4 +193,7 @@ backend framework.
- this could also decide if D2 should still be running or not, and react accordingly (post 0.9)
-# Stop the processes in an orderly fashion
-# Perhaps return status of each process
This script has been implemented in src/bin/keactl/keactl.
*/
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment