Well, I have a slightly different opinion. 1. I?ll channel Jon Postel here a little bit ? Networks and Systems should be as simple as possible and no simpler? IMHO, DNSMASQ is too simple for most of the DHCP environments I deal with and I find its structure frustrating at best. 2. Yes, KEA seems over complex when you first approach it. Mainly, that?s because there?s too much text book documentation and not enough basic example and HOWTO out there (yet). KEA is definitely capable of being much more complex than traditional ISC DHCPd that we all know and love? However? 3. ISC DHCPd has become quite a hodgepodge of hacks and a conglomeration of code spaghetti over the years as various ornaments got hung on the DHCP tree. KEA is a concerted effort by ISC to step back and look at creating a clean server with all the modern capabilities needed in a reference implementation of DHCP that provides literally every possible feature. IMHO, it?s an excellent effort by very talented people. That said, it does have some shortcomings. ARM support has been limited (nonexistent) until very recently. ARM packages still aren?t out (yet), but there is good progress towards this recently and I am hopeful that we will see full ARM support for KEA on par with x86 very soon now. In most use cases, KEA (once you get past a small learning curve) isn?t significantly harder to manage than ISC DHCP and actually offers much greater flexibility in where you put various things in the configuration file and how you manage things like reservations, pools, options, etc. The Client Classing engine in Kea is top notch and very functional, but again, it does come with a bit of a learning curve. The ability to have separate namespaces for vendor options (and custom options) will appeal to anyone who has had to deal with subnets with more than one different and incompatible vendor-specific use of DHCP options 43 and 60. (try that with DNSMASQ? I dare you). Unfortunately, i lack the Samba experience to reliably implement what is needed here, but I am happy to provide what kea expertise and experience I have to an effort to address this issue if someone more versed in Samba wants to collaborate. Owen On Nov 1, 2023, at 08:24, Rowland Penny via samba <samba at lists.samba.org> wrote: On Wed, 1 Nov 2023 15:56:46 +0100 Stefan Kania via samba <samba at lists.samba.org> wrote: > Hi to all, > nearly one year a<x-msg://95/#link>?????? <external.png><https://summary.us1.defend.egress.com/v3/summary?ref=email&crId=65426dd6d858dc90e68ea9dc&lang=en> <finance_warning.png><https://summary.us1.defend.egress.com/v3/summary?ref=email&crId=65426dd6d858dc90e68ea9dc&lang=en> On Wed, 1 Nov 2023 15:56:46 +0100 Stefan Kania via samba <samba at lists.samba.org> wrote:> Hi to all, > nearly one year ago someone ask about the kea-DHCP support for Samba. > In the Samba wiki I still can only find the idc-dhcp stuff. @Rowland > will you (and can you) replace or add the setup of kea to the wiki? > Would be nice :-) > > Stefan >Hi Stefan, the problem is two fold: A) At the moment my DCs are still running Bullseye (they are running on Raspberry pi 4 and Bookworm has only recently been released) B) In my opinon, Using Kea for the task is overkill (but then I think Kea is overkill for anything) If/When I do rewrite the script, it will be using the dhcp server built into dnsmasq, a much simpler set up. If some else whats to use Kea, then I wish them luck. Rowland -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
I think what we need is both a very simple way to setup DHCP (deffinetly NOT kea) and kea for more complex networks. We have the same with the internal DNS and Bind9. So having a script for both kea and dnsmasq would be nice :-). I took a look at kea and it's like buying a Porsche to get the breakfast rolls from the other side of the street. Most of my custemers will stayx with isc-dhcp (as log as it is possible) because kea is to complex and to overloaded. Am 01.11.23 um 18:30 schrieb Owen DeLong via samba:> Well, I have a slightly different opinion. > > 1. I?ll channel Jon Postel here a little bit ? Networks and Systems should be as simple > as possible and no simpler? IMHO, DNSMASQ is too simple for most of the > DHCP environments I deal with and I find its structure frustrating at best. > > 2. Yes, KEA seems over complex when you first approach it. Mainly, that?s because > there?s too much text book documentation and not enough basic example and > HOWTO out there (yet). KEA is definitely capable of being much more complex > than traditional ISC DHCPd that we all know and love? However? > > 3. ISC DHCPd has become quite a hodgepodge of hacks and a conglomeration > of code spaghetti over the years as various ornaments got hung on the DHCP > tree. KEA is a concerted effort by ISC to step back and look at creating a clean > server with all the modern capabilities needed in a reference implementation > of DHCP that provides literally every possible feature. IMHO, it?s an excellent > effort by very talented people. > > That said, it does have some shortcomings. ARM support has been limited > (nonexistent) until very recently. ARM packages still aren?t out (yet), but there > is good progress towards this recently and I am hopeful that we will see full > ARM support for KEA on par with x86 very soon now. > > In most use cases, KEA (once you get past a small learning curve) isn?t significantly > harder to manage than ISC DHCP and actually offers much greater flexibility in where > you put various things in the configuration file and how you manage things like > reservations, pools, options, etc. > > The Client Classing engine in Kea is top notch and very functional, but again, it > does come with a bit of a learning curve. The ability to have separate namespaces > for vendor options (and custom options) will appeal to anyone who has had to > deal with subnets with more than one different and incompatible vendor-specific > use of DHCP options 43 and 60. (try that with DNSMASQ? I dare you). > > Unfortunately, i lack the Samba experience to reliably implement what is needed > here, but I am happy to provide what kea expertise and experience I have to an > effort to address this issue if someone more versed in Samba wants to collaborate. > > Owen > > > On Nov 1, 2023, at 08:24, Rowland Penny via samba <samba at lists.samba.org> wrote: > > On Wed, 1 Nov 2023 15:56:46 +0100 Stefan Kania via samba <samba at lists.samba.org> wrote: > Hi to all, > nearly one year a<x-msg://95/#link>????? > <external.png><https://summary.us1.defend.egress.com/v3/summary?ref=email&crId=65426dd6d858dc90e68ea9dc&lang=en> > <finance_warning.png><https://summary.us1.defend.egress.com/v3/summary?ref=email&crId=65426dd6d858dc90e68ea9dc&lang=en> > > > On Wed, 1 Nov 2023 15:56:46 +0100 > Stefan Kania via samba <samba at lists.samba.org> wrote: > >> Hi to all, >> nearly one year ago someone ask about the kea-DHCP support for Samba. >> In the Samba wiki I still can only find the idc-dhcp stuff. @Rowland >> will you (and can you) replace or add the setup of kea to the wiki? >> Would be nice :-) >> >> Stefan >> > > Hi Stefan, the problem is two fold: > > A) At the moment my DCs are still running Bullseye (they are > running on Raspberry pi 4 and Bookworm has only recently been released) > > B) In my opinon, Using Kea for the task is overkill (but then I think > Kea is overkill for anything) > > If/When I do rewrite the script, it will be using the dhcp server built > into dnsmasq, a much simpler set up. > > If some else whats to use Kea, then I wish them luck. > > Rowland > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba > >
> Well, I have a slightly different opinion.> 1. I?ll channel Jon Postel here a little bit ? Networks and Systems should be as simple > as possible and no simpler? IMHO, DNSMASQ is too simple for most of the > DHCP environments I deal with and I find its structure frustrating at best.> 2. Yes, KEA seems over complex when you first approach it. Mainly, that?s because > there?s too much text book documentation and not enough basic example and > HOWTO out there (yet). KEA is definitely capable of being much more complex > than traditional ISC DHCPd that we all know and love? However?> 3. ISC DHCPd has become quite a hodgepodge of hacks and a conglomeration > of code spaghetti over the years as various ornaments got hung on the DHCP > tree. KEA is a concerted effort by ISC to step back and look at creating a clean > server with all the modern capabilities needed in a reference implementation > of DHCP that provides literally every possible feature. IMHO, it?s an excellent > effort by very talented people.> That said, it does have some shortcomings. ARM support has been limited > (nonexistent) until very recently. ARM packages still aren?t out (yet), but there > is good progress towards this recently and I am hopeful that we will see full > ARM support for KEA on par with x86 very soon now.> In most use cases, KEA (once you get past a small learning curve) isn?t significantly > harder to manage than ISC DHCP and actually offers much greater flexibility in where > you put various things in the configuration file and how you manage things like > reservations, pools, options, etc.> The Client Classing engine in Kea is top notch and very functional, but again, it > does come with a bit of a learning curve. The ability to have separate namespaces > for vendor options (and custom options) will appeal to anyone who has had to > deal with subnets with more than one different and incompatible vendor-specific > use of DHCP options 43 and 60. (try that with DNSMASQ? I dare you).> Unfortunately, i lack the Samba experience to reliably implement what is needed > here, but I am happy to provide what kea expertise and experience I have to an > effort to address this issue if someone more versed in Samba wants to collaborate.> Owen? All this, AND ISC's dhcpd is now deprecated and all new features etc will only see developer time for Kea.? dhcpd is on life-support. ? Sure, it'll probably get patches for a good while yet. There will probably be people still using it for another dozen years or more. But Kea is where sysadmins with forward-looking stances will look to migrate. (And, having been victim of a few really odd bugs in dhcpd [especially in embedded versions] I have hopes that Kea will be better.] ? The next time I have any major work on my largest pair, I'm migrating to Kea - and I've already started looking at the details, setting up a lab-environment server to test on etc. ? So, yeah - Kea is def where I'm headed for anything other than really trivial/small setups. ? Having Samba support Kea sooner rather than later would be good. ? -Greg ? ?