My humble advice is don’t. KEA is a boat-load of work and disappointment. From functional changes to design decisions, you will only find complexity and loss.
Lets start with
comments in the configuration file. Their major design decision to use JSON (JavaScript
Object Notation), a data interchange format. While it is “human readable” it is
NOT inherently a configuration file format. Comments in ISC DHCP where text
sequences started with #. Useful everywhere as any text following a # on a
line, is ignored. In KEA comments become a JSON object in a JSON array. So here
is an example:
"user-context": {
"comment": "second
floor",
"floor": 2
}
You can no
longer put it where you need it. It doesn’t help with organizing the elements
of the configuration. You can’t comment-out something you don’t need right now,
but don’t want to delete. And, frankly, it makes the configuration more obscure
and significantly more work. This is just a bad design decision; period.
Verbosity:
From ISC DHCP
configuration of hosts the simple statement:
option host-name
"server-one";
becomes lots of
name/value pairs:
“option-data”: [
{
“space”:”dhcp4”,
”name”:”host-name”,
”code”:12,
”data”:”server-one”
}
]
From ISC DHCP
logging:
log-facility
local6;
becomes this
simple JSON array:
"loggers":
[
{
"name":
"kea-dhcp4",
"output_options": [
{"output":"/var/log/kea-dhcp4.log"},
{"output":"stdout"}
],
"severity": "INFO",
"debuglevel": 0
}
],
Let’s move on to
functional changes:
“ddns-updates”:
true/false scope has been moved from “subnet” and “host” to a global “enable-updates:
true/false”. Isn’t this a loss of functionality?
“update-static-leases”
is obsolete. I have no idea what replaces it if anything.
“qualifying-suffix”
has been rescoped from “subnet” to global.
Dynamic DNS updates
has been moved to a separate server (D2) which must be separately configured
from the KEA DHCP server and managed.
