summaryrefslogtreecommitdiff
path: root/doc/guide/config.xml
blob: ac8965fa41af474021cfdf56f5979034d4e49424 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
<!--
 - Copyright (C) 2014-2018 Internet Systems Consortium, Inc. ("ISC")
 -
 - This Source Code Form is subject to the terms of the Mozilla Public
 - License, v. 2.0. If a copy of the MPL was not distributed with this
 - file, You can obtain one at http://mozilla.org/MPL/2.0/.
-->

<!-- Converted by db4-upgrade version 1.1 -->
<chapter xmlns="http://docbook.org/ns/docbook" version="5.0" xml:id="kea-config">
  <title>Kea Configuration</title>

  <para>Kea is using JSON structures to handle configuration. Previously
  we there was a concept of other configuration backends, but that never was
  implemented and the idea was abandoned.</para>

  <section xml:id="json">
    <title>JSON Configuration</title>
    <para>JSON is notation used throughout the Kea project. The most obvious
    usage is for configuration file, but it is also used for sending commands
    over Management API (see <xref linkend="ctrl-channel"/>) and for
    communicating between DHCP servers and DDNS update daemon.</para>

    <para>Typical usage assumes that the servers are started from the command line
    (either directly or using a script, e.g. <filename>keactrl</filename>).
    The JSON backend uses certain signals to influence Kea. The
    configuration file is specified upon startup using the -c parameter.</para>

    <section xml:id="json-format">
      <title>JSON Syntax</title>
      <para>Configuration files for DHCPv4, DHCPv6 and DDNS modules are defined
      in an extended JSON format. Basic JSON is defined in <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://tools.ietf.org/html/rfc7159">RFC 7159</link>. Note that Kea
      1.2 introduces a new parser that is better at following the JSON spec.  In
      particular, the only values allowed for boolean are true or false (all
      lowercase). The capitalized versions (True or False) are not accepted.
      </para>

      <para>Kea components use an extended JSON with additional features
      allowed:
      <itemizedlist>
        <listitem>
          <simpara>shell comments: any text after the hash (#)
          character is ignored. Both Dhcp4 and Dhcp6 allow # in any column,
          while Ddns requires hash to be in the first column.</simpara>
        </listitem>
        <listitem>
          <simpara>C comments: any text after the double slashes (//)
          character is ignored. Both Dhcp4 and Dhcp6 supports this
          feature.</simpara>
        </listitem>
        <listitem>
          <simpara>Multiline comments: any text between /* and */ is
          ignored. This commenting can span multiple lines. Both Dhcp4 and
          Dhcp6 supports this feature.</simpara>
        </listitem>
        <listitem>
          <simpara>File inclusion: JSON files can include other JSON
          files. This can be done by using &lt;?include
          "file.json"?&gt;. Both Dhcp4 and Dhcp6 supports this
          feature.</simpara>
        </listitem>
      </itemizedlist>
      </para>

      <para>The configuration file consists of a single object (often colloquially
      called a map) started with a curly bracket. It comprises the "Dhcp4", "Dhcp6",
      "DhcpDdns" and/or "Logging" objects. It is possible to define additional
      elements, but they will be ignored. For example, it is possible to define
      Dhcp4, Dhcp6 and Logging elements in a single configuration file that can
      be used to start both the DHCPv4 and DHCPv6 components. When starting,
      the DHCPv4 component will use Dhcp4 object to configure itself and the
      Logging object to configure logging parameters; it will ignore the Dhcp6
      object.</para>

      <para>A very simple configuration for both DHCPv4 and
      DHCPv6 could look like this:
<screen>
# The whole configuration starts here.
{

# DHCPv4 specific configuration starts here.
"Dhcp4": {
    "interfaces-config": {
        "interfaces": [ "eth0" ],
        "dhcp-socket-type": "raw"
    },
    "valid-lifetime": 4000,
    "renew-timer": 1000,
    "rebind-timer": 2000,
    "subnet4": [{
       "pools": [ { "pool": "192.0.2.1-192.0.2.200" } ],
       "subnet": "192.0.2.0/24"
    }]
},
# DHCPv4 specific configuration ends here.

# DHCPv6 specific configuration starts here.
"Dhcp6": {
    "interfaces-config": {
        "interfaces": [ "eth1" ]
    },
    "preferred-lifetime": 3000,
    "valid-lifetime": 4000,
    "renew-timer": 1000,
    "rebind-timer": 2000,
    "subnet6": [{
       "pools": [ { "pool": "2001:db8::/80" } ],
       "subnet": "2001:db8::/64"
    }]
},
# DHCPv6 specific configuration ends here.

# Logger parameters (that could be shared among several components) start here.
# This section is used by both the DHCPv4 and DHCPv6 servers.
"Logging": {
   "loggers": [{
        "name": "*",
        "severity": "DEBUG"
    }]
}
# Logger parameters end here.

# The whole configuration structure ends here.
}
</screen>
        </para>

        <para>More examples are available in the installed
        <filename>share/doc/kea/examples</filename> directory.</para>

        <para>To avoid repetition of mostly similar structures, examples in the
        rest of this guide will showcase only the subset of parameters appropriate for a given
        context. For example, when discussing the IPv6 subnets configuration in
        DHCPv6, only subnet6 parameters will be mentioned. It is implied that
        the remaining elements (the global map that holds Dhcp6, Logging and possibly
        DhcpDdns) are present, but they are omitted for clarity. Usually, locations
        where extra parameters may appear are denoted by an ellipsis.</para>
    </section>

    <section>
      <title>Simplified Notation</title>

        <para>It is sometimes convenient to refer to a specific element in the
        configuration hierarchy. Each hierarchy level is separated by a slash.
        If there is an array, a specific instance within that array is referenced by
        a number in square brackets (with numbering starting at zero). For example, in the above configuration the
        valid-lifetime in the Dhcp6 component can be referred to as
        Dhcp6/valid-lifetime and the pool in the first subnet defined in the DHCPv6
        configuration as Dhcp6/subnet6[0]/pool.</para>

      <!-- @todo Add a reference here after #3422 is done -->
    </section>

  </section>

</chapter>