© christianbo / 123RF.com

Das ISC hat im Herbst 2022 das Lebensende des Standard-DHCP-Daemons verkündet. Dessen designierter Nachfolger Kea befindet sich bereits seit Jahren in der Entwicklung.

Anfang Oktober 2022 veröffentlichte das Internet Systems Consortium (ISC) die Versionen 4.4.3-P1 und 4.1-ESV-R16-P2 des DHCP-Servers ISC DHCP. Gleichzeitig gab die Non-Profit-Organisation bekannt, dabei handle es sich um das voraussichtlich letzte Release der Software, und legte deren End-of-Life-Datum auf Dezember 2022 fest. Zwar bleibt DHCPD weiter funktional, erhält aber laut ISC keinerlei Aktualisierungen mehr, es sei denn, es träten ernsthafte Sicherheitslücken auf. Höchste Zeit also für Admins, sich mit Kea zu beschäftigen, der neuen DHCP-Server-Suite des ISC.

Die Entwicklung des designierten DHCPD-Nachfolgers begann bereits 2014. Zu Redaktionsschluss lag Kea in den Versionen 2.2.0 (Juli 2022, Current-Stable) und 2.3.6 (März 2023, Experimental-Development) vor. Die meisten Distributionen führen fertige Kea-Pakete in ihren Repositories, das ISC selbst offeriert eigene DEB-, RPM- und APK-Pakete. Daneben steht auch der Quellcode als Tarball zum Herunterladen bereit.

Die Struktur

Beim alten ISC-DHCPD waren IPv4- und IPv6-DHCP noch vollständig getrennte Prozesse, deren Konfiguration nichts miteinander zu tun hatte. Kea hält hier zwar noch zwei eigene Dienste mit separaten Konfigurationsdateien vor, die aber ein gemeinsamer Kea-Control-Agent steuert. Er bietet auch eine REST-API an, über die sich die Dienste einheitlich konfigurieren lassen. Als vierte Komponente gibt es schließlich noch den DDNS-Update-Daemon, der aufgrund erteilter DHCP-Leases Einträge in DNS-Servern vornimmt. Diese Funktion war im klassischen ISC-DHCPD direkt integriert.

Ein weiterer wesentlicher Unterschied liegt in der Speicherung der Daten. Der ISC-DHCPD erlaubte LDAP als externe Datenquelle. Kea unterstützt für Leases und Host-Reservierungen die SQL-Datenbanken PostgreSQL und MySQL. Dabei warnt der Admin Guide von Kea, dass sich das auf die Performance auswirkt. Er rät dazu, Host-Reservierungen über die Konfigurationsdatei vorzunehmen, wenn es sich nicht um große Mengen handelt. Ohne die Datenbank stehen die Host-Reservierungen direkt in der Konfigurationsdatei, die Leases verwaltet Kea in einem CSV-File.

Kea ist modular aufgebaut. Um bestimmte Funktionen zu aktivieren, müssen erst eigene Bibliotheken geladen werden. Das betrifft beispielsweise die Unterstützung für die Backend-Datenbank und die Aktivierung der REST-API-Kommandos zur Verwaltung von Leases.

Installation

Am einfachsten installieren Sie Kea mittels Apt, Yum, Emerge oder Pacman. Sollte die Distribution nicht die gewünschte Version anbieten, empfiehlt sich die Nutzung der ISC-Repositories [1]. Je nach Distribution gibt es die diversen Komponenten auch als einzelne Pakete, zum Beispiel bei Ubuntu.

Zuerst müssen Sie die Entscheidung treffen, welche der Komponenten laufen sollen. Verwenden Sie kein IPv6, braucht der v6-Server nicht zu laufen. Ebenso muss der DDNS-Updater nicht laufen, wenn die Infrastruktur das nicht erfordert. Auch hier unterscheidet sich das Vorgehen von Distribution zu Distribution. Bei Ubuntu etwa gibt es einen Systemd-Service pro Komponente. Bei Gentoo Linux steuern Einträge in der Datei »/etc/conf.d/kea«, welche Komponenten unter dem Dienst »kea« gestartet werden.

Konfiguration

Der wesentlichste Unterschied zu DHCPD besteht im Format der Konfigurationsdatei: Kea setzt hier auf JSON. Damit ist die Basissyntax standardisiert. Die einzelnen Komponenten haben jeweils eine eigene, strukturell stets ähnlich aufgebaute Konfigurationsdatei. Den äußersten Block bildet ein JSON-Dictionary, das als einzigen Schlüssel den Typ der Datei beziehungsweise der Konfiguration enthält. Für die Konfiguration von DHCP in IPv4 beziehungsweise IPv6 ist das »Dhcp4« respektive »Dhcp6«, für den Control-Agent »Ctrl-agent«. Listing 1 zeigt eine sehr einfache Konfiguration für den DHCP4-Daemon.

"Dhcp4": {
 "interfaces-config": {
  "interfaces": [ "eth0" ]
 },
 "control-socket": {
  "socket-type": "unix",
  "socket-name": "/run/kea/kea4-ctrl-socket"
 },
 "lease-database": {
  "type": "memfile",
  "lfc-interval": 3600
 },
 "renew-timer": 900,
 "rebind-timer": 1800,
 "valid-lifetime": 3600,
 "option-data": [{
  "name": "domain-name-servers",
  "data": "192.168.2.1, 192.168.2.2"
 }, {
  "name": "domain-search",
  "data": "mydomain.example.com, example.com"
  }],
 "subnet4": [{
  "subnet": "192.168.2.0/24",
  "pools": [{"pool":"192.168.2.1 - 192.168.2.50"}],
  "option-data": [{
   "name: "routers",
   "value": "192.168.2.254"
   }],
  "reservations": [{
   "hw-address": "00:11:22:33:44:55",
   "ip-address": "192.168.2.60",
   "hostname": "host-2-60"
   }, {
   "hw-address": "00:00:00:00:00:01",
   "ip-address": "192.168.2.253",
   "hostname": "special-host",
   "option-data": [{
    "name": "domain-name-servers",
    "data": "192.168.1.1"
   }]
  }]
 }]
}

Dieses Beispiel definiert den Service für das Subnetz 192.168.2.0/24. Die DNS-Server in diesem Netz haben die IP-Adressen 192.168.2.1 und 192.168.2.2, die Clients sollen in den Domains »mydomain.example.com« und »example.com« nach Host-Einträgen suchen. Die Konfiguration definiert ein Subnetz (»subnet4«, 192.168.2.0/24), für das die Default-Router-Option mit dem Router unter der Adresse 192.168.2.254 gilt. In diesem Netz werden dynamische IP-Adressen aus dem Pool von 192.168.2.1 bis 192.168.2.50 vergeben. Schließlich gibt es in diesem Subnetz noch zwei Reservierungen auf Basis der MAC-Adresse. Für die zweite wird explizit ein bestimmter DNS-Server gesetzt.

Die gesamte Konfiguration verwendet für die vergebenen Leases die in einer CSV-Textdatei abgelegte In-Memory-Datenbank. Deren Speicherort hängt von der verwendeten Distribution ab, typischerweise liegt sie unter »/var/lib/kea/«. Die Struktur der Konfiguration ist logisch durchdacht. Der Block »option-data« taucht auf drei verschiedenen Hierarchiestufen auf, es handelt sich aber stets um ein Feld mit einzelnen Dictionary-Einträgen. Statt des Schlüsselworts »name« kann ein Eintrag auch »code« verwenden, gefolgt von der Nummer der konfigurierten DHCP-Option. Der Block aus Listing 2 setzt beispielsweise die Option »domain-name«.

{
 "code": 15,
 "data": "example.org" }

Je spezifischer die Hierarchie desto höher die Priorität. Eine Option auf Ebene eines Hosts überschreibt die Definition auf der Subnetzebene, diese überschreibt ihrerseits eine globale Definition. Der Block »control-socket« definiert die “Fernsteuerung”. Dieser Unix-Domain-Socket versteht die Kommandos des REST-APIs von KEA. Mit einem Werkzeug wie Socat senden Sie bei Bedarf direkt API-Kommandos im JSON-Format. Die Komponente Control-Agent fungiert im Wesentlichen als Übersetzung dieses Zugriffs auf eine HTTP-Schnittstelle und erlaubt den Zugriff auf alle weiteren Komponenten, die jeweils einen eigenen Control-Socket bereitstellen.

In komplexeren DHCP-Konfigurationen gibt es neben den logischen Hierarchiestufen Global, Subnetz und Host häufig noch Klassen, die Hosts aufgrund bestimmter Parameter zusammenfassen. Für eine solche Klasse lassen sich dann über einen »option-data«-Block andere Optionen setzen. Das kommt beispielsweise beim Booten via Netzwerk zum Tragen. Dabei senden die Boot-Agents in der Regel eigene Parameter in der DHCP-Anfrage mit.

Bei klassischen PXE-Boot etwa findet sich in der Option »vendor-class-identifier« ein String wie »PXEClient:Arch:00000:UNDI:002001«. In einer Klasse, die das prüft, stehen dann Parameter wie das Boot-File, das der Client per TFTP herunterladen soll. Bootet derselbe Client sein Betriebssystem von der lokalen Festplatte, ist in der Regel die Angabe eines Netzwerk-Boot-Files unnötig und muss dementsprechend nicht mitgeschickt werden. Klassen definiert die Kea-Konfiguration unter dem Schlüssel »client-classes«.

Listing 3 zeigt einen Block, der das beschriebene Szenario für ein Booten via TFTP implementiert. Die Syntax der möglichen Tests beschreibt ein Knowledge-Base-Artikel des ISC [2].

"client-classes": [{
 "name": "pxeplain",
 "test": "option[vendor-class-identifier].text == 'PXEClient:Arch:00000:UNDI:002001'",
 "next-server": "172.17.1.1",
 "boot-file-name": "pxelinux.0"
}]

Hook-Libraries

Kea ist modular aufgebaut. Bestimmte Funktionen, etwa für das Speichern in einer SQL-Datenbank, müssen erst in der Konfiguration geladen werden. Hier unterscheidet sich die freie Version der Software von der mit kommerziellem Support-Vertrag. Die freie Version enthält lediglich die die Hook-Bibliotheken für BOOTP, flexible Optionen, Hochverfügbarkeit, die MySQL- und PostgreSQL-Backends, Skriptausführung sowie API-Kommandos zur Verwaltung von Leases und für Statistik.

In der Version mit Support-Vertrag gibt es dann eine Reihe von API-Kommandos, mit denen sich einzelne Teile der Konfiguration – etwa die Subnetze – direkt per API-Aufruf verwalten lassen. Dann stehen auch Aufrufe wie »>add-network« zur Verfügung. Ohne diese Bibliotheken bleibt nur die Möglichkeit, die vollständige Konfiguration per API-Request zu übertragen.

Soll der Dhcp4-Server mit einer PostgreSQL-Datenbank arbeiten und zudem die Kommandos zur Verwaltung von Leases per API bereitstellen, erfordert das die Anweisungen aus Listing 4. Die Syntax für das Einbinden der Bibliotheken ist stets gleich: Hinter »library« folgt der zugehörige Speicherort. Einige der Bibliotheken benötigen auch Parameter, die Sie hinter dem Schlüssel »parameter« angeben.

"hooks-libraries": [{
 "library": "/usr/lib64/kea/hooks/libdhcp_lease_cmds.so",
 "parameters": {}
 }, {
 "library": "/usr/lib64/kea/hooks/libdhcp_pgsql_cb.so",
 "parameters": {}
}]

Datenbank-Backend

Soll Kea die Leases in einer Datenbank ablegen, sieht der Block »lease-database« in der Konfiguration wie in Listing 5 gezeigt aus. Vorab gilt es allerdings, die Datenbank gemäß der Anweisungen aus dem Admin Guide [3] einzurichten.

Nach dem Anlegen der Datenbank und des zugehörigen Benutzers müssen Sie noch das Schema initialisieren. Unter »/usr/share/kea/scripts/pgsql/« – der Pfad kann je nach Distribution variieren – findet sich die SQL-Datei »dhcpdb_create.pgsql«, die alle notwendigen Tabellen anlegt.

Liegen die Leases in der Datenbank, kann die Lease-Steuerung über die API entfallen, da sich die Angaben auch per SQL-Anweisung ändern lassen. Kea schlägt bei jeder Zuweisung in der Tabelle nach.

"lease-database": {
 "type": "postgresql",
 "name": "kea",
 "user": "dhcp",
 "password": "dhcp",
 "host": "localhost",
 "port": 5432,
 "lfc-interval": 3600
}

API-Zugriff

Wie beschrieben, erlaubt zwar auch der Control-Socket eine Steuerung via API, doch den primären Weg dazu weist der Control-Agent. Er stellt in der Standardkonfiguration seine Dienste auf Port 8000 bereit, nimmt die Verbindungen aber nur auf Localhost an. Das ist auch gut so, denn er bietet keinerlei Möglichkeiten zur Authentisierung. Die Dokumentation schlägt die Verwendung eines Reverse Proxys wie Apache oder Nginx vor, wenn der Zugriff mit Benutzerauthentisierung erfolgen soll. Listing 6 zeigt eine Beispielkonfiguration für den Control-Agent.

"Control-agent": {
 "http-host": "127.0.0.1",
 "http-port": 8000,
 "control-sockets": {
  "dhcp4": {
   "socket-type": "unix",
   "socket-name": "/run/kea/kea4-ctrl-socket"
  },
  "dhcp6": {
   "socket-type": "unix",
   "socket-name": "/run/kea/kea6-ctrl-socket"
  },
  "d2": {
   "socket-type": "unix",
   "socket-name": "/run/kea/kea-ddns-ctrl-socket"
  }
 }
}

Es besteht die Möglichkeit, TLS auf dem Server zu aktivieren. Damit gibt es zumindest die Variante, den Zugriff via TLS-Authentisierung zu schützen. Mittels Curl lässt sich die API bedienen. Das Kommando aus der ersten Zeile von Listing 7 fragt den Control-Agent nach den API-Kommandos, die der Dhcp4-Daemon unterstützt.

$ curl -s -H "Content-type: application/json" -X POST -d '{ "command": "list-commands", "service": [ "dhcp4" ] }' http://localhost:8000
$ curl -s -H "Content-type: application/json" -X POST -d '{ "command": "lease4-add", "arguments":{"ip-address":"172.17.6.8", "hw-address": "52:54:00:8a:17:9f"}, "service": [ "dhcp4" ] }' http://localhost:8000/
[ { "result": 0, "text": "Lease for address 172.17.6.8, subnet-id 2 added." } ]
$ curl -s -H "Content-type: application/json" -X POST -d '{ "command": "lease4-del", "service": [ "dhcp4" ], "arguments": { "ip-address": "172.17.6.8", "subnet-id": 1} }' http://localhost:8000/

Die Ausgabe hängt von den eingebundenen Hook-Bibliotheken ab. So tauchen etwa die Kommandos zur Verwaltung von DHCP-Leases erst auf, wenn Sie wie oben beschrieben die Hook-Bibliothek eingebunden haben. Die Version ohne Support-Vertrag erlaubt Änderungen an der Konfiguration nur bei den Leases oder in der vollständigen Konfiguration.

Der API-Aufruf aus der zweiten Zeile von Listing 7 erzeugt einen Lease. Als Antwort schickt Kea die Ausgabe aus der Zeile 3 des Listings. Die beim Löschen des Leases relevante Subnet-ID ermittelt Kea aus seiner Konfiguration selbstständig. Beim Anlegen von Leases ist es anders als beim Anlegen einer Host-Reservierung nicht möglich, gesonderte DHCP-Parameter für den einzelnen Client zu hinterlegen. Das Löschen eines Leases erledigt der Aufruf aus der letzten Zeile von Listing 7.

Möchten Sie die Konfiguration beispielsweise um eine neue Subnet-Definition erweitern, bleibt ohne Support-Vertrag nur die Möglichkeit, die gesamte Konfiguration herunterzuladen, den JSON-Block zu parsen, im richtigen Teil der Datenstruktur das neue Subnetz zu ergänzen und dann die gesamte Konfiguration als JSON-Block zurück zum Kea-Server zu senden. Den JSON-Block zum Herunterladen der Konfiguration zeigt die erste Zeile von Listing 8.

Das Weiterverarbeiten der resultierenden JSON-Konfiguration erledigt die JSON-Bibliothek der bevorzugten Programmiersprache. Nach den gewünschten Änderungen lädt der Aufruf aus der zweiten Zeile von Listing 8 die gesamte Konfiguration. Damit ist sie aber noch nicht gespeichert. Dazu dient der API-Aufruf aus Zeile 3. Nach einer manuellen Änderung der Konfiguration gelingt das auch per API über das Kommando »config-reload«, das keine Argumente benötigt.

{ "command": "config-get", "service": [ "dhcp4" ] }
{ "command": "config-set", "service": [ "dhcp4" ], arguments: { gesamte_config } }
{ "command": "config-write", "service": [ "dhcp4" ], "arguments":{"filename":"/etc/kea/test123.json"} }

High Availability

Wie schon der alte DHCPD unterstützt Kea das Aufsetzen eines Clusters aus mehreren Servern. Dazu benötigt es zum einen die Lease-Commands-Bibliothek, um Leases per API auf einem Partner-Server anlegen zu können, und zum anderen die HA-Bibliothek, die in ihrem Parameterblock die Information vorhält, wie der Partner zu erreichen ist. Dazu können Sie die Verbindung zwischen den Cluster-Mitgliedern per TLS oder via Basic Auth sichern.

Sie können den Cluster entweder im Load-Balancing-Modus zur Lastverteilung betreiben oder den Hot-Standby-Modus nutzen, bei dem immer nur ein Kea-Server aktiv ist. Die Konfiguration in Listing 9 zeigt die Konfiguration für die Variante mit Lastverteilung. Sie haben die Möglichkeit, in der Konfiguration der Adress-Pools anzugeben, welcher der beiden Server welchen Pool bedienen soll. Dazu steht in der Konfiguration eine Zeile wie »”client-class”:”HA_server1″«. Hier heißt die Klasse automatisch »HA_Server-Name«.

"hooks-libraries": [{
 "library": "/usr/lib/kea/hooks/libdhcp_lease_cmds.so",
 "parameters": {}
 }, {
 "library": "/usr/lib/kea/hooks/libdhcp_ha.so",
 "parameters": {
  "high-availability": [{
   "this-server-name": "server1",
   "mode": "load-balancing",
   "heartbeat-delay": 10000,
   "max-response-delay": 60000,
   "max-ack-delay": 5000,
   "max-unacked-clients": 5,
   "delayed-updates-limit": 100,
   "peers": [{
    "name": "server1",
    "url": "http://172.17.1.43:8000/",
    "role": "primary",
    "auto-failover": true
   }, {
    "name": "server2",
    "url": "http://172.17.1.44:8000/",
    "role": "secondary",
    "auto-failover": true
   }]
  }]
 }
}]

Im Lastverteilungsmodus gibt jeder der beiden Server nur Adressen aus seinem Pool heraus. Sollte einer der Partner nicht laufen, übernimmt der andere die Aufgabe. Die weiteren Konfigurationsparameter geben an, zu welchen Zeiten überprüft werden soll, ob die anderen Cluster-Mitglieder noch arbeiten und in welchem Tempo Updates verteilt werden beziehungsweise, wie viel Rückstau erlaubt ist.

Sie können auch eigene Klassendefinitionen mit den vom Load Balancer vorgegebenen kombinieren. Der Kea Admin Guide gibt dazu unter der Überschrift “Load Balancing with Advanced Classification” eine Anleitung.

DDNS

Häufig sollen alle Hosts neben der IP-Adresse auch DNS-Einträge besitzen, und zwar sowohl zum Auflösen des Namens in die IP-Adresse (Forward) als auch umgekehrt (Reverse). Hierzu bot auch schon der alte ISC-DHCPD die Funktion, aus dem vergebenen Lease ein dynamisches DNS-Update (DDNS) zu senden. Kea realisiert diese Funktion nicht im eigentlichen DHCP-Daemon, sondern stellt dazu den eigenen Dienst »kea-dhcp-dns« bereit.

Wie die anderen Services müssen Sie auch diesen gesondert starten und aktivieren. Die zugehörige Konfiguration enthält neben Schlüsseln zum Authentisieren der Updates auch Angaben, auf welcher Kombination von IP-Adresse und Port der Dienst Anfragen annimmt. Hinzu kommen Listen von DNS-Servern für Forward- und Reverse-Zonen, sodass der Dienst weiß, welchen Servern er welche Updates zuschicken soll.

Listing 10 zeigt eine einfache Konfiguration, in der es nur einen Key gibt. Updates für jeweils eine Forward- und eine Reverse-Zone werden an den Nameserver auf dem Host 172.17.1.1 weitergeleitet. Bei der Reverse-Zone steht zusätzlich ein Eintrag für einen zweiten Nameserver, um zu zeigen, wie der Parameter »port« die Verbindung auf einen anderen Port leitet.

{
 "DhcpDdns": {
  "ip-address": "127.0.0.1",
  "port": 53001,
  "control-socket": {
   "socket-type": "unix",
   "socket-name": "/run/kea/kea-ddns-ctrl-socket"
  },
  "tsig-keys": [{
   "name": "dnstsigkey",
   "algorithm": "HMAC-MD5",
   "secret": "pjGqiQBjQUXELdUyP4lPzA=="
  }],
  "forward-ddns": {
   "ddns-domains": [{
    "comment": "Testdomain",
    "name": "demodomain.lmtest.de.",
    "key-name": "dnstsigkey",
    "dns-servers": [{
     "ip-address": "172.17.1.1"
    }]
   }]
  },
  "reverse-ddns": {
   "ddns-domains": [{
    "name": "6.17.172.in-addr.arpa.",
    "key-name": "dnstsigkey",
    "dns-servers": [{
     "ip-address": "172.17.1.1"
    }, {
    "ip-address": "192.168.77.88",
    "port": 53001
    }]
   }]
  },
  "loggers": [{
   // This specifies the logging for D2 (DHCP-DDNS)
 daemon.
   "name": "kea-dhcp-ddns",
   "output_options": [{
    "output": "@localstatedir@/log/kea/kea-ddns.log"
   }],
   "severity": "INFO",
   "debuglevel": 0
  }]
 }
}

Es erfordert weitere Konfigurationsarbeiten am DHCP-Server, damit dieser den DDNS-Server auch verwendet. Achten Sie darauf, dass der Eintrag im Feld »name« bei den Forward-Domains mit einem Punkt endet. Aus der Konfiguration in Listing 10 und Listing 11 folgt, dass der DHCP-Server eine DNS-Update-Anforderung für »name.demodomain.lmtest.de.« sendet, auch wenn in der DHCPD-Konfiguration kein Punkt am Ende der Domain steht. Diese Erkenntnis kostete den Autor eine halbe Stunde Suche.

Der Konfigurationsblock in Listing 11 sorgt dafür, dass Kea den Host-Namen »prefix-172-17-6-6.demodomain.lmtest.de« setzt, wenn der Client keinen eigenen Namen mitschickt. Die Anweisung bei »ddns-replace-client-name« können Sie auch mit den Werten »when-present«, »always« oder »never« besetzen. Zusätzlich zum »A«- und »PTR«-Record legt der DDNSD auch in der Forward- und der Reverse-Zone einen »DHCID«-Eintrag an. Gibt ein DHCP-Client seinen Lease ordentlich wieder frei, werden die Einträge auch wieder gelöscht.

"dhcp-ddns": {
 "enable-updates": true,
 "server-ip": "127.0.0.1",
 "server-port": 53001,
 "sender-ip": "127.0.0.1",
 "max-queue-size": 2048,
 "ncr-protocol": "UDP",
 "ncr-format": "JSON"
},
"ddns-send-updates": true,
"ddns-override-no-update": true,
"ddns-override-client-update": true,
"ddns-replace-client-name": "when-not-present",
"ddns-generated-prefix": "prefix",
"ddns-qualifying-suffix": "demodomain.lmtest.de",
"ddns-update-on-renew": false,
"ddns-use-conflict-resolution": true,
"hostname-char-set": "[^A-Za-z0-9.-]",
"hostname-char-replacement": "x",

Die Migration

Kea löst den alten DHCPD vollständig ab. In komplexeren Konfigurationen, die viele Reservierungen enthalten und Hunderte oder Tausende Zeilen umfassen, wäre eine manuelle Konvertierung sehr mühsam und äußerst fehlerträchtig. Daher stellt das ISC das Werkzeug Keama bereit, das aus einer »dhcpd.conf« eine Kea-DHCP-Konfiguration erstellt.

Keama ist jedoch kein Teil der Kea-Pakete, sondern findet sich in den Quellen des alten DHCPD. Nach dem Kompilieren können Sie Keama dafür einsetzen, die Konfiguration zu konvertieren. Dazu versteht das Kommandozeilenprogramm einige Optionen, deren wichtigste die Tabelle “Keama-Optionen (Auswahl)” zusammenfasst.

Im Test funktionierte der Konverter auch mit der etwas komplexeren Konfiguration des Autors ganz gut und beachtete sogar den Import einer zweiten Datei. Parameter in der Quelldatei, die Keama nicht versteht oder die bei Kea keinen Sinn ergeben (etwa die OMAPI-Konfiguration), werden in der Zieldatei auskommentiert. Daher sollten Sie das Ergebnis auf jeden Fall eingehend prüfen.

Fazit

Kea erledigt dieselben Aufgaben wie der alte DHCPD. Seine REST-API lässt sich in der Automatisierung einfacher bedienen als das etwas eigenwillige DHCPD-OMAPI. Dabei enttäuscht, dass das ISC ohne kostenpflichtigen Support-Vertrag nur einen Teil der Konfiguration per API zugänglich macht. Wie beschrieben, lässt sich das umgehen, indem man die vollständige Konfiguration extern generiert und per API-Request pusht. Immerhin besteht bei Kea die Möglichkeit, die gesamte Konfiguration per API zu steuern, was der alte DHCPD nicht erlaubte.

Ausführliche Beispiele zur Konfiguration der einzelnen Dienste finden Sie auf Github [4]. Mit dem Migrationswerkzeug Keama haben Sie es bei üblichen Konfigurationen gut in der Hand, auf Kea zu migrieren. Verwenden Sie bei DHCPD das LDAP-Backend, verkompliziert das allerdings die Migration deutlich: In diesem Fall kommen Sie um einen Export der in LDAP gespeicherten Daten und eine Umwandlung nicht herum. (jcb/jlu)