Wanting to contribute KEA DHCP server plugin

[mirabilos]

Hi!

People may have noticed that ISC desupported their former DHCP software (DHCP client, server, relay) and now offers a product called KEA instead which is a DHCP server, a DHCPv6 server and a DDNS update server bundled into one (though the three services are independently installed and configured).

A client had me write a monitoring plugin specifically for the DHCP server (not the DHCPv6 server) to use instead of the isc_dhcpd plugin shipped in base.

I would like to contribute this (the client has agreed and leaves details to me). Since the isc_dhcpd plugin is in base, perhaps you’d like this in base as well?

This is comprised of one agent plugin (written in Python3) and one check plugin (v2 API) that offers both one service per DHCP pool (exactly like isc_dhcpd) and additionally one extra service for the dæmon’s globals (PID, uptime, errors).

The agent plugin requires check_mk_agent to be run as root (or at least with permissions to test for existence of the dhcpd4 config file (it is inert if absent) and access the management UNIX domain socket), and the kea-dhcp4-server to be configured with the "libdhcp_subnet_cmds.so” hook library enabled (it is FOSS from KEA 3.x onwards, which I managed to get into trixie-backports, and was a paid add-on before).

As for DHCPv6, I don’t have a setup of that anywhere (personally I just use rtadvd) and not the time on the contract to work on it, but KEA is so structured that changing a few 4 into 6 in both agent and check plugin will give you one for DHCPv6 (they could even share the same files, I’d think). I’m not sure how kea-dhcp-ddns-server fits into this, I don’t think a plugin for it would be even remotely similar, other than the agent code to access the management socket.

I’d attach what I already have here if the forum would let me, as basis for further discussion. Please note that this is my very first foray into modern (as in, less than 15 years old) Nagios/check_mk.

How to best proceed?

Given that ISC DHCPD is EOL as of 2023, many users will want to have this.

[mbunkus (Moritz Bunkus)]

Talking as a Checkmk user & contributor but not an employee of Checkmk-the-company: much appreciated! We’re running KEA DHCPv6, and I’m willing to look into porting your existing work to it once I can get my hands on it. Though I have to check if our setup meets your requirements and maybe look into upgrading.

[r.sander (Robert Sander)]

@mirabilos

How to best proceed?

Put your code in a publicly accessible git repo. And/or publish an MKP.

[mirabilos]

@mbunkus

Talking as a Checkmk user & contributor but not an employee of Checkmk-the-company: much appreciated!

Gladly. We all stand on the shoulders of giants here wrt. FOSS, so it’s natural to do one’s own part.

Since the forum won’t let me post it here (and apparently only do three replies as well), I’ve put the agent and check plugins up at: KEA dhcpd4 check_mk monitoring plugin ($38) · Snippets · GitLab

@mbunkus

We’re running KEA DHCPv6, and I’m willing to look into porting your existing work to it once I can get my hands on it.

That would be nice.

As I said, very likely you can change a few 4 into 6 and it’ll just work. Even less for the check plugin as the agent output format is designed to work with either, so just renaming the things will do (and the service_name='DHCP %s' is IP-version-agnostic already anyway).

@mbunkus

Though I have to check if our setup meets your requirements and maybe look into upgrading.

The subnet{4,6}-get API is required to find out the pools for each (subnet-id, pool-index-within-subnet) tuple, and it is only available from that plugin. But there are more good reasons to go to 3.x already¹, which is why I persuaded my fellow packagers to upload it to trixie-backports.

An alternative way that could work with KEA 2.x would be to use config-get and get the pools from that. That raises criticality (the acquired config object also contains e.g. the database password), but, more importantly, misses any subnet and pool changes done at runtime via the management API. If you don’t do that, that could be a way. You’d have to write a different _get_pools() function that uses [config-get]( 19. Management API — Kea 2.6.3 documentation ).

¹) major bump introduced changes you will have to do anyway (e.g. the old KEA agent is now deprecated, which is why _kea_request() (like the Ansible kea_command I submitted there) uses the UNIX domain socket API), bugfixes, new features, and other new plugins and plugins that used to be pay-for are now FOSS and included with the kea-common Debian package (or however you get your software)

[Sara]

Hi @mirabilos !

As a new forum member you were restricted in posting before and I already changed your permissions, so posting should work correctly now

Welcome to the community

[mirabilos]

@Sara

Welcome to the community

Thanks!

I’m attaching the current version of the plugins here:

• kea_dhcpd4.py (12.9 KB) agent plugin
• kea_dhcpd4.py (12.4 KB) check plugin for API v2 (tested with CMK 2.4)
• kea_dhcpd4_cmkv1.py (13.9 KB) quick hack backport for CMK 2.1 (API v1), which I hope to not have to support, it’s only until the old systems go away

@r.sander

Put your code in a publicly accessible git repo. And/or publish an MKP.

Hm. That would make it an add-on package and have nobody else maintaining it (adapting to newer CMK when needed), even though I could at least merge the DHCPv6 changes once they appear. As you may have noticed, I did this for a customer, but I’m not running CMK myself anywhere; and have not much incentive of diving deep into developing for it, as I have already so many FOSS projects…

I was hoping it could possibly be merged into CMK itself, so it’ll be available for everyone the same as the ISC DHCPD plugin is.

[mbunkus (Moritz Bunkus)]

@mbunkus

We’re running KEA DHCPv6

Damn it, I really misremembered this… We tried to use KEA for both DHCPv4 & v6 but ran into the limitation that KEA DHCPv6 at least in KEA 2.x cannot use the MAC address as an identifier when matching for fixed leases (yes, its predecessor, the ISC DHCPv6, could do that). I get why it cannot, but this was a problem for us, which is why we decided to use KEA for DHCPv4 only & switch to dhcpy6d for DHCPv6.

I’ll see if I can spin up a KEA DHCPv6 in a test environment for development purposes, but that will take a moment due to current workload.

Sorry for misremembering and maybe getting someone’s hopes up too quickly.

@mirabilos

I was hoping it could possibly be merged into CMK itself, so it’ll be available for everyone the same as the ISC DHCPD plugin is.

I would very much like to see KEA DHCPv4+6 support in official Checkmk, agreed, especially given ISC dhcpd’s deprecation. If that doesn’t happen, I might take up maintaining a KEA DHCP plugin as an external MKP if none of the other usual suspects of plugin development/maintenance here in the forum don’t jump on it first. But no promises. I’ll definitely look into v6 support first.

[mirabilos]

@mbunkus

the limitation that KEA DHCPv6 at least in KEA 2.x cannot use the MAC address as an identifier when matching for fixed leases

Oh. Found that this is apparently a DHCPv6-specific problem: 10. The DHCPv6 Server — Kea 3.0.3 documentation has an overview and lists the implemented workarounds, one of them might help (they ought to just implement raw sockets…). Seems like running a relay might also work (now, if there was a large internet consortium that has a DHCP relay… )

@mbunkus

I’ll see if I can spin up a KEA DHCPv6 in a test environment for development purposes, but that will take a moment due to current workload.

OK, cool. We’re not in a hurry here, or at least I’m not.

@mbunkus

@mirabilos

I was hoping it could possibly be merged into CMK itself, so it’ll be available for everyone the same as the ISC DHCPD plugin is.

I would very much like to see KEA DHCPv4+6 support in official Checkmk, agreed, especially given ISC dhcpd’s deprecation. If that doesn’t happen, I might take up maintaining a KEA DHCP plugin as an external MKP if none of the other usual suspects of plugin development/maintenance here in the forum don’t jump on it first.

That would be appreciated. Ideally, you could take the plugins I wrote as starting point.

@mbunkus

I’ll definitely look into v6 support first.

If needed, I can hack around on it a bit to modularise/parametrise this, in the hope of making adding DHCPv6 support easier. I first wanted something that works…

Remember you will need KEA 3.x for the way the agent plugin is written. (Or the paid KEA 2.x add-on library.)

I’ll gladly cooperate on this, and I can test the v4 setup on my test VMs as well, to make sure it doesn’t break. A publicly accessible git repo seems to be a common requirement, so I’m thinking setting one up on Codeberg, would that work for you?

[mbunkus (Moritz Bunkus)]

@mirabilos

one of them might help (they ought to just implement raw sockets…)

Exactly, that’s what dhcpy6d does. Sure, this doesn’t work with DHCP relays as far as I’m aware, but still — for us this wouldn’t be a problem; our DHCPv6 server is in the same layer 2 network.

@mirabilos

If needed, I can hack around on it a bit to modularise/parametrise this, in the hope of making adding DHCPv6 support easier. I first wanted something that works…

Agreed; let’s wait until I have done some initial testing.

@mirabilos

Remember you will need KEA 3.x for the way the agent plugin is written.

I do remember. Our current server is running Ubuntu 24.04 which only contains v2, and I wouldn’t want to compile from source on our production system. But in a test VM I’ll just use Ubuntu 26.04 which contains KEA v3, so the version won’t be a problem for that.

@mirabilos

o I’m thinking setting one up on Codeberg, would that work for you?

Definitely. I’m on Codeberg, too (mbunkus there).

[mirabilos]

OK, I’ve set it up as mirabilos/kea-dhcp: check_mk plugin for KEA DHCP servers - Codeberg.org for now, with the same files as I posted above.

The customer has reported that something is not quite right in a multi-pool setup, which I’ll need to debug, so I’ll update it with fixes as I find them. Update: yes, there was a line missing, which I fixed in a commit there, so the repo is now the quilt-leading version, the snippet and the attached files from the post above are obsolete.