config.xml 5.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
  3. "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
  4. <!ENTITY mdash "&#x2014;" >
  5. ]>
  6. <chapter id="kea-config">
  7. <title>Kea configuration</title>
  8. <para>Depending on the configuration backend chosen (see <xref
  9. linkend="dhcp-config-backend"/>), the configuration mechanisms are different. The
  10. following sections describe details of the different configuration backends. Note
  11. that only one configuration backend can be used and its selection is
  12. made when the configure script is run.</para>
  13. <section id="bundy-backend">
  14. <title>BUNDY configuration backend</title>
  15. <para>This legacy configuration backend allows Kea to use the former BIND 10
  16. framework. That framework and this Kea configuration backend is no longer
  17. supported by ISC. It is currently developed as part of the Bundy project (see
  18. <ulink url="http://bundy-dns.de">Bundy homepage</ulink>). See the Bundy project
  19. documentation regarding configuration.</para>
  20. </section>
  21. <section id="json-backend">
  22. <title>JSON configuration backend</title>
  23. <para>JSON is the default configuration backend.
  24. It assumes that the servers are started from the command line
  25. (either directly or using a script, e.g. <filename>keactrl</filename>).
  26. The JSON backend uses certain signals to influence Kea. The
  27. configuration file is specified upon startup using the -c parameter.</para>
  28. <section id="json-format">
  29. <title>JSON syntax</title>
  30. <para>Configuration files for DHCPv4, DHCPv6 and DDNS modules are defined
  31. in an extended JSON format. Basic JSON is defined in <ulink
  32. url="http://tools.ietf.org/html/rfc4627">RFC 4627</ulink>. Kea components
  33. use a slightly modified JSON, in that they allow shell-style
  34. comments in the file: lines with the hash (#) character in the first column
  35. are comment lines and are ignored.</para>
  36. <para>The configuration file consists of a single object (often colloquially
  37. called a map) started with a curly bracket. It comprises the "Dhcp4", "Dhcp6",
  38. "DhcpDdns" and/or "Logging" objects. It is possible to define additional
  39. elements, but they will be ignored. For example, it is possible to define
  40. Dhcp4, Dhcp6 and Logging elements in a single configuration file that can
  41. be used to start both the DHCPv4 and DHCPv6 components. When starting,
  42. the DHCPv4 component will use Dhcp4 object to configure itself and the
  43. Logging object to configure logging parameters; it will ignore the Dhcp6
  44. object.</para>
  45. <para>For example, a very simple configuration for both DHCPv4 and DHCPv6
  46. could look like this:
  47. <screen>
  48. # The whole configuration starts here.
  49. {
  50. # DHCPv4 specific configuration starts here.
  51. "Dhcp4": {
  52. "interfaces-config": {
  53. "interfaces": [ "eth0" ],
  54. "dhcp-socket-type": "raw"
  55. },
  56. "valid-lifetime": 4000,
  57. "renew-timer": 1000,
  58. "rebind-timer": 2000,
  59. "subnet4": [{
  60. "pools": [ { "pool": "192.0.2.1-192.0.2.200" } ],
  61. "subnet": "192.0.2.0/24"
  62. }],
  63. ...
  64. },
  65. # DHCPv4 specific configuration ends here.
  66. # DHCPv6 specific configuration starts here.
  67. "Dhcp6": {
  68. "interfaces-config": {
  69. "interfaces": [ "eth1" ]
  70. },
  71. "preferred-lifetime": 3000,
  72. "valid-lifetime": 4000,
  73. "renew-timer": 1000,
  74. "rebind-timer": 2000,
  75. "subnet6": [{
  76. "pools": [ { "pool": "2001:db8::/80" } ],
  77. "subnet": "2001:db8::/64"
  78. }],
  79. ...
  80. },
  81. # DHCPv6 specific configuration ends here.
  82. # Logger parameters (that could be shared among several components) start here.
  83. # This section is used by both the DHCPv4 and DHCPv6 servers.
  84. "Logging": {
  85. "loggers": [{
  86. "name": "*",
  87. "severity": "DEBUG"
  88. }],
  89. ...
  90. }
  91. # Logger parameters end here.
  92. # The whole configuration structure ends here.
  93. }
  94. </screen>
  95. </para>
  96. <para>More examples are available in the installed
  97. <filename>share/doc/kea/examples</filename> directory.</para>
  98. <para>To avoid repetition of mostly similar structures, examples in the
  99. rest of this guide will showcase only the subset of parameters appropriate for a given
  100. context. For example, when discussing the IPv6 subnets configuration in
  101. DHCPv6, only subnet6 parameters will be mentioned. It is implied that
  102. the remaining elements (the global map that holds Dhcp6, Logging and possibly
  103. DhcpDdns) are present, but they are omitted for clarity. Usually, locations
  104. where extra parameters may appear are denoted with an ellipsis.</para>
  105. </section>
  106. <section>
  107. <title>Simplified Notation</title>
  108. <para>It is sometimes convenient to refer to a specific element in the
  109. configuration hierarchy. Each hierarchy level is separated by a slash.
  110. If there is an array, a specific instance within that array is referenced by
  111. a number in square brackets (with numbering starting at zero). For example, in the above configuration the
  112. valid-lifetime in the Dhcp6 component can be referred to as
  113. Dhcp6/valid-lifetime and the pool in the first subnet defined in the DHCPv6
  114. configuration as Dhcp6/subnet6[0]/pool.</para>
  115. <!-- @todo Add a reference here after #3422 is done -->
  116. </section>
  117. </section>
  118. </chapter>