The ISC DHCP server (dhcpd) was traditionally used to set up a DHCP server in Linux, but the software is reaching end-of-life, and the Internet Systems Consortium is now recommending their own Kea DHCP server or alternatives such as Dnsmasq or udhcpd (as found in Busybox) as a replacement.
I was unaware of this having just used the isc-dhcp-server package to set up a DHCP server in NanoPi R6C router/mini PC earlier this month. But a blog post on Ubuntu informed us dhcpd was going away, and Canonical plans to switch over the Kea DHCP server instead.
The main difference from the user perspective is that Kea relies on JSON configuration files so all your dhcpd files will have to be rewritten.
Other highlights for the Kea DHCP server include:
- Modular component design, extensible with hooks modules. Kea includes daemons for a DHCPv4 server, a DHCPv6 server, and a dynamic DNS (DDNS) module, and optional features are enabled with dynamically-loaded “hooks modules,” which you need run only if you are using them. It’s also possible to write your own hooks modules in C++.
- On-line re-configuration with REST API. Kea uses a JSON configuration file that can be modified remotely via set commands and reloaded without stopping and restarting the server. While the ISC DHCP server needs to be restarted when updating the configuration.
- Designed to integrate with your existing systems. Kea allows you to separate the data from the execution environment, so your network data – leases, host reservation definitions, and most configuration data – can be located separately from the DHCP server itself, using a Kea “backend” to store the data in MySQL or PostgreSQL databases
- Web-based graphical dashboard. Kea has a graphical dashboard, called Stork, for monitoring multiple Kea servers. The system uses agents deployed on the Kea servers to relay information to a centralized management platform.
Here’s an example of Kea JSON configuration file:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
"subnet-default": [ { "subnet": "192.168.0.0/24", "reservations-global": true, "reservations-in-subnet": true, "reservations": [ { "hw-address": "08:72:A6:57:29:FE", "ip-address": "192.168.100.4", "hostname": "region1", "client-classes": [ "MAAS" ] } ] } ] |
That’s quite different from your typical dhcpd.conf file. There’s already extensive documentation for the Kea DHCP server, and it is already officially supported in several Linux and BSD distributions including Alpine 3.12/3.13, CentOS 7/8, Debian 9/10/11, Fedora 33/34, FreeBSD 12.1/13.0, and Ubuntu 18.04/20.04/21.04.
There are several Kea packages in Ubuntu 22.04:
|
1 2 3 4 5 6 7 8 9 10 |
jaufranc@cnx-laptop-4:~$ aptitude search kea- p kea-admin - Administration utilities for Kea DHCP serv p kea-common - Common libraries for the Kea DHCP server p kea-ctrl-agent - REST API service for Kea DHCP server p kea-dev - Development headers for Kea DHCP server p kea-dhcp-ddns-server - DHCP Dynamic DNS service p kea-dhcp4-server - IPv4 DHCP server p kea-dhcp6-server - IPv6 DHCP server p kea-doc - Documentation for Kea DHCP server p python3-kea-connector - Python3 management connector for Kea DHCP |
You can install a specific package:
|
1 |
$ sudo apt-get install kea-dhcp4-server |
or install them all:
|
1 |
$ sudo apt-get install kea* |
You’ll find more details to build it from source, install it in your specific distro, and configuration in the Quick Start section of the documentation. The official project page may also have additional information.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Given the numerous deployments and the amount of software that were designed to interact with such config files and leases, purposely breaking compatibility with what is deployed is the best way to make sure that outdated and insecure versions will continue to run in field for the next decade. At the very least a compatibility mode would help with the transition. A smart move, really… Some people do not understand that for many users (especially in enterprise), config files are extremely precious assets. This is for example how rsyslog managed to take over sysklogd despite syslog-ng being known for longer and by then being far superior in terms of capabilities and performance: only the former was able to load existing configs. I suspect that commercial DHCP vendors will take this opportunity to try sell their software and offer the migration for free.
This
For “normal” users, a compatibility layer is required. Personally, it’s not worth the energy to learn a whole new architecture.
The best migration I’ve yet seen is from docker to podman – the same commands are used, so the migration is basically “Remove docker. Symlink docker -> podman. Done”
Ugg, as someone just rolling out new servers in their home, I recenlty moved my ISC-DHCP server configs to new machines, so this is fresh in my memory. I’ve been using ISC-DHCP for over a decade. I know what I want out of a DHCP server and kea brings *nothing* to the table. As a matter of fact all the changes it makes are liabilities. JSON config? Why?
If I decide to move (and not just stay with my current setup forever), it won’t be to kea as it offers me nothing that I see any value in. I have built up knowledge of the config files. I have developed tools to manage remote servers. I know how to work with the lease files. None of that is of use anymore with kea.
Congratulations, ISC, you made a clean break with your DHCP server design. I guess I will make one, too.
Anyone got a recommendation for a DHCP server that supports server redundancy? I’d prefer at least two servers.
> Anyone got a recommendation for a DHCP server that supports server redundancy?
Just a suggestion if it’s your home (lab): if you increase lease time to a few days then once a DHCP server disappears you have some time to set up another fresh one that will then learn automagically from DHCP compliant clients the former MAC <–> IPA assignments (at least with dnsmasq it works that way, the internal ‘lease database’ of a new server will repopulate over time).
That’s an option, but I have come to enjoy having redundant DHCP servers because I have a lot of new devices coming on the network frequently–ESP dev boards, etc. I could just use non-redundant servers (I could keep a backup configured but not running) and do the work manually, but I have really come to like having the fault tolerant nature of the old ISC DHCP server.
> I could just use non-redundant servers
I was really talking about something different: using just one server (basic config in gitlab oder something like that) serving the clients. Once the server fails clients aren’t affected as long as the leases don’t expire, then setting up a new DHCP server (pulling in the config via git) will end up with the new server learning the assignments automagically. No redundancy at all just increasing lease times.
I understood that. I was just saying that (since I have redundant machines) I might as well pre-configure the ‘backup’ server and only have to start the service when I notice the primary has failed.
I’ve asked ChatGPT to convert a dhcpd.conf files into Kea JSON and it did come up with something, so maybe that’s a way…
kb.isc.org/docs/migrating-from-isc-dhcp-to-kea-dhcp-using-the-migration-assistant
There’s a migration tool to convert the config files. Though, they suggest migrating when you’re changing something else too, which sounds like terrible advice.
If I ever read another article about ChatGPT, it will be too soon…
Well, seems to be the future of system administration. Just throw whatever task into that AI (artificial idiocy), trust blindly into the output, deploy it.
Nobody knows how the stuff works, why it works or why it doesn’t work. But ofc we have this already today. This Reddit Outage post mortem is really fun to read. What could go possibly wrong stacking up sh*tloads of complexity w/o anyone fully understanding what’s going on. 🙂
Yes, that’s issue. ChatGPT is too easy to use. It will output some code that runs, but unless the code is carefully checked you don’t know whether it outputs what should be really expected.
Some admins are discovering that it invents CVEs and Git commit IDs but they trust it 🙂 I showed to some how to make it invent them in a very trustable form, just by asking. When you see this, any admin should be scared to rely on it for their systems. They don’t understand the principle of predicting text, nowhere it’s claimed that in addition to looking valid it must be true, but it speaks with authority (in fact the same authority as some admins in certain enterprises who say bullshit all the day), so people will trust it.
Geeez! I thought it was silly to blindly trust things I found on stackexchange for sysadmin work, but just giving ChatGPT root??? That’s insane!
“You want SkyNet? That’s how you get SkyNet!”
I was begging it for an SVG file for a 3 by 4 by 5 triangle for half an hour out of sheer spite. It failed.
First and obvious question: is there a .conf convertion/migration tool available?
I went to technitium. It seems even faster than dnsmasq and has a nice gui. DNS, DHCP, caching, blocklists etc.