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
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
|
.. ischooklib:: libdhcp_class_cmds.so
.. _hooks-class-cmds:
``libdhcp_class_cmds.so``: Class Commands
=========================================
This hook library exposes
several control commands for manipulating client classes (part of the
Kea DHCP servers' configurations) without the need to restart those
servers. Using these commands it is possible to add, update, delete, and
list the client classes configured for a given server.
.. note::
:ischooklib:`libdhcp_class_cmds.so` is available only to ISC customers with
a paid support contract. For more information on subscription options,
please complete the form at https://www.isc.org/contact.
.. note::
This library can only be loaded by the :iscman:`kea-dhcp4` or
:iscman:`kea-dhcp6` process.
.. isccmd:: class-add
.. _command-class-add:
The ``class-add`` Command
~~~~~~~~~~~~~~~~~~~~~~~~~
The :isccmd:`class-add` command adds a new client class to the DHCP server
configuration. This class is appended at the end of the list of classes
used by the server and may depend on any of the already-configured
client classes.
The following example demonstrates how to add a new client class to the
DHCPv4 server configuration:
::
{
"command": "class-add",
"arguments": {
"client-classes": [
{
"name": "ipxe_efi_x64",
"test": "option[93].hex == 0x0009",
"next-server": "192.0.2.254",
"server-hostname": "hal9000",
"boot-file-name": "/dev/null"
}
]
}
}
Note that the ``client-classes`` parameter is a JSON list, but it allows
only a single client class to be present.
Here is the response to the :isccmd:`class-add` command in our example:
::
{
"result": 0,
"text": "Class 'ipxe_efi_x64' added."
}
.. isccmd:: class-update
.. _command-class-update:
The ``class-update`` Command
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The :isccmd:`class-update` command updates an existing client class in the
DHCP server configuration. If the client class with the given name
does not exist, the server returns the result code of 3, which means that
the server configuration is not modified and the client class does not
exist. The :isccmd:`class-add` command must be used instead to create the new
client class.
The :isccmd:`class-update` command has the same argument structure as the
:isccmd:`class-add` command:
::
{
"command": "class-update",
"arguments": {
"client-classes": [
{
"name": "ipxe_efi_x64",
"test": "option[93].hex == 0x0017",
"next-server": "0.0.0.0",
"server-hostname": "xfce",
"boot-file-name": "/dev/null"
}
]
}
}
Here is the response for our example:
::
{
"result": 0,
"text": "Class 'ipxe_efi_x64' updated."
}
Any parameter of the client class can be modified with this command,
except ``name``. There is currently no way to rename the class, because
the class name is used as a key for searching the class to be updated.
To achieve a similar effect to renaming the class, an existing class can
be removed with the :isccmd:`class-del` command and then added again with a
different name using :isccmd:`class-add`. Note, however, that the class with
the new name will be added at the end of the list of configured classes.
As with other update commands, this command overwrites all the contents of the
entry. If the client class previously had a resource assigned to it, and the
:isccmd:`class-update` command is missing the resource, it is deleted from the server
configuration. If an incremental update of the class is desired, then this can
be achieved by doing a :isccmd:`class-get` to get the current state
of the client class, picking the client class out of the response, modifying it
to the required outcome, and then issuing the ``client-update`` command with the
resulting client class attached.
.. isccmd:: class-del
.. _command-class-del:
The ``class-del`` Command
~~~~~~~~~~~~~~~~~~~~~~~~~
The :isccmd:`class-del` command is used to remove a particular class from the server
configuration. The class to be removed is identified by name. The class
is not removed if there are other classes depending on it; to remove
such a class, the dependent classes must be removed first.
The following is a sample command removing the ``ipxe_efi_x64`` class:
::
{
"command": "class-del",
"arguments": {
"name": "ipxe_efi_x64"
}
}
Here is the response to the :isccmd:`class-del` command in our example, when
the specified client class has been found:
::
{
"result": 0,
"text": "Class 'ipxe_efi_x64' deleted."
}
If the class does not exist, the result of 3 is returned.
.. isccmd:: class-list
.. _command-class-list:
The ``class-list`` Command
~~~~~~~~~~~~~~~~~~~~~~~~~~
:isccmd:`class-list` is used to retrieve a list of all client classes. This
command includes no arguments:
::
{
"command": "class-list"
}
Here is the response of the server in our example, including the list of
client classes:
::
{
"result": 0,
"text": "2 classes found",
"arguments": {
"client-classes": [
{
"name": "ipxe_efi_x64"
},
{
"name": "pxeclient"
}
]
}
}
Note that the returned list does not contain full class definitions, but
merely class names. To retrieve full class information, the
:isccmd:`class-get` command should be used.
.. isccmd:: class-get
.. _command-class-get:
The ``class-get`` Command
~~~~~~~~~~~~~~~~~~~~~~~~~
:isccmd:`class-get` is used to retrieve detailed information about a specified
class. The command structure is very simple:
::
{
"command": "class-get",
"arguments": {
"name": "pxeclient"
}
}
If the class with the specified name does not exist, the status code of
3 is returned. If the specified client class exists, the class details
are returned in the following format:
::
{
"result": 0,
"text": "Class 'pxeclient' definition returned",
"arguments": {
"client-classes": [
{
"name": "pxeclient",
"only-if-required": true,
"test": "option[vendor-class-identifier].text == 'PXEClient'",
"option-def": [
{
"name": "configfile",
"code": 209,
"type": "string"
}
],
"option-data": [ ],
"next-server": "0.0.0.0",
"server-hostname": "xfce",
"boot-file-name": "/dev/null"
}
]
}
}
Note that the example above is DHCPv4-specific; the last three
parameters are only returned by the DHCPv4 server and are never returned
by the DHCPv6 server. Also, some of the parameters provided in this
example may not be returned if they are not specified for the class.
Specifically, ``only-if-required``, ``test``, and ``option-def`` are not
returned if they are not specified for the class.
|