config-backend.dox 6.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123
  1. // Copyright (C) 2014-2015 Internet Systems Consortium, Inc. ("ISC")
  2. //
  3. // This Source Code Form is subject to the terms of the Mozilla Public
  4. // License, v. 2.0. If a copy of the MPL was not distributed with this
  5. // file, You can obtain one at http://mozilla.org/MPL/2.0/.
  6. /**
  7. @page configBackend Kea Configuration Backends
  8. @section configBackendIntro Introduction
  9. Kea started as a sub-project in BIND10 that used a program (called
  10. bindctl) to deliver configuration information to its modules. This
  11. potentially allowed for modules to get their configuration information
  12. in a variaty of ways using what were known as configuration backends.
  13. After BIND10 was cancelled, the Kea project briefly tried to maintain
  14. backward compatibility with the BIND10 framework, but the effort
  15. was discontinued due to lack of interest.
  16. Currently the Kea team does not plan to develop any additional
  17. configuration backends. Instead, effort is being focused on enhancing
  18. the current control channel (see @ref ctrlSocket) to be as flexible
  19. as possible. If you are thinking about developing new ways to
  20. configure Kea, the recommendation is to write an external piece of
  21. software that will communicate with Kea using this channel.
  22. @section configBackendHistoric Alternate Configuration Backends
  23. While this section currently has no practical value, it may become useful
  24. one day to develop a minimalistic, stripped down Kea version that does
  25. not have any command interface at all. This could prove useful for running
  26. Kea in embedded regime.
  27. The following steps are needed for the DHCPv4 server to be able to
  28. process a new method of configuration. (It is assumed that the
  29. modified component is DHCPv4. Similar approach applies to the other
  30. components: DHCPv6 or DHCP-DDNS):
  31. -# Write your own implementation of isc::dhcp::ControlledDhcpv4Srv::init(),
  32. isc::dhcp::ControlledDhcpv4Srv::init() and isc::dhcp::ControlledDhcpv4Srv::cleanup(),
  33. and put it in the src/bin/dhcp4 directory (e.g. as foo_controller.cc).
  34. -# Modify src/bin/dhcp4/Makefile.am to include your file (e.g. foo_controller.cc) in
  35. the build.
  36. -# Modify the AC_ARG_WITH(kea-config,...) macro in configure.ac to include an
  37. entry for your configuration backend.
  38. -# Add your own AM_CONDITIONAL(CONFIG_BACKEND_FOO, ...) and
  39. AC_DEFINE(CONFIG_BACKEND_FOO, ...) macros to configure.ac (following the
  40. above-mentioned AC_ARG_WITH macro) to set the C++ macro for your backend.
  41. -# Modify the sanity check in configure.ac to allow your configuration backend name.
  42. Optionally you can also:
  43. -# Implement unit tests for your backend in the src/bin/dhcp4/tests directory.
  44. -# Modify src/bin/dhcp4/tests/Makefile.am to include the file(s) containing the
  45. unit tests.
  46. @section configBackendJSONDesign The JSON Configuration Backend
  47. The following are some details of the JSON backend framework.
  48. -# Each backend uses the common code for configuration and command
  49. processing callbacks. They all assume that JSON formatted parameters are sent
  50. and they are expected to return well formatted JSON responses. The exact
  51. format of configuration and commands is module-specific.<br/><br/>
  52. -# A command handler handles the reading the configuration from a
  53. file. Its main responsibility is to load the configuration and process
  54. it. The JSON backend must call that handler when starting up the server.
  55. This is implemented in configure() in the kea_controller.cc files
  56. in src/bin/dhcp4 and src/bin/dhcp6 directories.<br/><br/>
  57. -# The current JSON parser in @ref
  58. isc::data::Element::fromJSON() has been extended to allow optional
  59. preprocessing. For now, that capability simply removes whole-line
  60. comments starting with the hash character, but it is expected to grow over
  61. time (in-line comments and file inclusions are the obvious envisaged
  62. additions). This is implemented in @ref isc::data::Element::fromJSONFile.<br/><br/>
  63. -# The current format of the BIND10 configuration file (BIND 10 stored its
  64. configuration in (installation directory) /var/bind10/b10-config.db) has been
  65. retained as the configuration file format. Its actual naming is now arbitrary
  66. and left up to the user (it is passed as a parameter to the -c command line
  67. option). From the implementation perspective, this is slight change
  68. from the BIND10 days, as back then a subset of the configuration was received by
  69. the daemon processes. Nowadays the whole configuration is passed. To take a
  70. specific example, the following is how b10-config.db looks today:
  71. @code
  72. {
  73. "Init": { ... }
  74. "Dhcp4": {
  75. "subnet4" { subnet definitions here },
  76. "option-data" { option data here },
  77. "interfaces": [ "eth0" ],
  78. ...
  79. },
  80. "Dhcp6": {
  81. "subnet6" { subnet definitions here },
  82. "option-data" { option data here },
  83. "interfaces": [ "eth0" ],
  84. ...
  85. },
  86. "Logging": {
  87. "Loggers": [{"name": *, "severity": "DEBUG" }]
  88. }
  89. }
  90. @endcode
  91. The Kea components used to receive only relevant parts of it (e.g. Kea4
  92. received configuration data that only contained the content of the Dhcp4 element).
  93. Now each component receives all of it: the code
  94. iterates over the top level elements and picks the appropriate
  95. tree (or get the element by name). That approach makes the common configuration
  96. (such as the logging initialization code) very easy to share among Kea4, Kea6 and
  97. DHCP-DDNS.<br/><br/>
  98. -# The .spec files used in BIND 10 by the control program to validate commands
  99. have been retained. They will be kept and maintained even though no use of
  100. them is currently planned. At some future time syntax validation may be implemented,
  101. although it is out of scope for Kea 0.9 (and probably
  102. for 1.0 as well, as it is a pretty big task).<br/><br/>
  103. -# A shell script has been added (as src/bin/keactrl/keactrl) to
  104. start, stop and reconfigure the daemons. Its only
  105. job is to pass the configuration file to each daemon and remember its PID file, so
  106. that sending signals is possible (for configuration reload or shutdown). It is also
  107. able to print out a status.
  108. */