You might be aware already since your proxies work with it, but if not here some more information: ISC DHCP - ISC
1 Like
Yes, I’m aware of it. We’ve had some discussions with the RHEL teams since it also affects them. Ideally speaking RHEL would have a working dhcpd that scales to production levels. There have been some concerns about dnsmasq and the RHEL team also voiced some concerns about ISC Kea. IIRC it was about licensing, but also API changes. At this point I’d say it’s unclear where we should go.
2 Likes
bit worrying that a stable release date was October 2022 and the same release is EOL December 2022, doesn’t feel a great move to EOL ISC-DHCP when none of the distributions have adopted Kea yet ?
Kea looks very good, and I appreciate EOL’ing the older product may drive adoption of the newer, but this feels last minute and very gun to the head, rather then get a few core distributions/projects to begin migration
This is not how I’ve seen ISC behave in the past.
I understand the sentiment at ISC, they have this beast and a new pet and they would love to very much focus on the new kit on the block while everybody around is telling them - keep it alive. It’s hard.
Keep in mind that upstream EOLs do not mean that you are not getting any support from your distribution. RHEL9 will be supported 10+ years as any other RHEL release, the same for Ubuntu LTS etc. That version of ISC DHCP there will receive security updates for the whole time. Of course no new features, well, ISC DHCP haven’t seen a feature in quite some time now.
yeah, I get that, and RHEL do a great job with maintaining versions, I have no issue with them EOL’ing it (I’m surprised it’s lasted as long as it has) but the short official notice seems a bit brutal.
There is always a risk for distribution providers after upstream EOL a product, eg: RHEL struggled on RHEL 6 and 7 with PHP versions because upstream EOL and both compatibility and security holes kept appearing and RHEL basically became the unofficial maintainer of EOL products, look at Python too, the headache and risk against working on a maintained version is always troubling, but again for me it’s the short notice that’s disappointed me
Ah, I remember something very similar when ISC deprecated dhcpd 1.9 in favor of the new pet, dhcpd 3.0. A lot of distributions stuck with 1.9 for a long time, since it was stable and reliable. 3.0 eventually shook the bugs out, and now people are reluctant to leave its descendant 4.4.
Like @lzap said, RHEL is on the hook to provide support for dhcpd 4.x for at least 10 years, and it does not seem like much is going to change in the meantime.
What’s the concern about kea? That would seem to be the most logical next move. I understand it’s a very different thing, architecturally, but it seems those architectural differences are well-warranted.
Given RHEL 9 currently has ISC 4.4.2, the problem really only gets urgent in the Red Hat ecosystem for RHEL 10.
I recall when talking to the author of smart_proxy_dhcp_kea | RubyGems.org | your community gem host that the Kea REST API was only available with a paid license, so they used direct database queries. That is very prone to breaking. The ISC Kea website now features the REST API so perhaps this policy was changed.
It should also be noted that the 2.2.0 (released in July 2022) states:
PostgreSQL configuration backend. The PostgreSQL-based Config
Backend is now fully functional and there is feature parity between
MySQL and PostgreSQL.
and later:
- The PostgreSQL schema has been updated. Existing databases need
to be upgraded.
It looks like the source for smart_proxy_dhcp_kea was never uploaded, but that could be a good place for the community to start collaboration on support.
I agree direct database queries don’t seem like a particularly robust strategy.
I just installed the Fedora Kea package (2.2.0, from F37), and it certainly installs the REST API plumbing, and starts a listener on port 8000, though I haven’t been able to actually give it a command. I should have more time to mess around with it later (the default install doesn’t seem to come with any authentication config, for example). I turned debug to 99 and am not getting any better understanding why kea-shell doesn’t connect by default.
1 Like
API usage for a paid license only, that doesn’t feel like the ISC projects of the past.