No more DHCP(d)

“He’s dead, Jim.”  Dr. McCoy

DHCP is dead; long live DHCP.

Yes, the end-of-life announcement for ISC DHCP means that the ISC will no longer provide official support or updates for the software. Our ever-faithful, omnipresent friend — the familiar dhcpd daemon — is retiring, albeit over a really long walk to that cabin in the mountains.  While the software will continue to function, it will become increasingly vulnerable to breakage, security vulnerabilities, and other issues over time as the software ages.

Not that it isn’t time.  ISC DHCP is really mature code (think “frangible”), meaning it’s really hard to refactor it for things like unit tests and instrumentation.  Ever tried putting a debug print in DHCP code? I have.  It can be incredibly tricky to even log things. Like the famous “clean code” example of the disconnecting FAX program that was “cured” by adding a diagnostic printf, DHCP code also suffers from a nasty sensitivity to timing issues — among other things.

Migrating to a new DHCP server can take time and effort, as it often requires changes to network configurations and other systems that depend on the server. However, it is important for the MAAS engineering team to plan and execute a controlled and staged migration to supported DHCP server software in order to ensure the continued security and stability of your network.

If it ain’t broke, don’t fix it?

“I’m not a magician, just an old country doctor.” Dr. McCoy

It’s natural to feel nostalgic about tools and configurations that have been a reliable part of our daily work for a long time. I personally have depended on this snippet for several years:

group { # MAAS Clients
   host region-controller {
      hardware ethernet 08:72:A6:57:29:FE;
      option host-name "region1";
      fixed-address 192.168.100.4;
   }
}

However, it’s important to keep in mind that technology is always evolving, and retiring outdated tools and systems is necessary to make way for better, more secure, and more efficient solutions.

There are a number of alternative DHCP server software options available, such as Kea DHCP and Dnsmasq, that are actively maintained and supported. Considering these options, we are leaning toward Kea as we plan the migration away from ISC DHCP.

MAAS will be transitioning from dhcpd to Kea, the ISC replacement for DHCP, in the next few cycles. Before we do, though, we’d like to gather your input. We recognise that you may have invested significant time in DHCP snippets and other customisations. We want to carefully consider your feedback in our migration planning. Just like we use feature polls to deliver the features you desire, we want to ensure that our migration strategy is aligned with your requirements.

Gathering input from users and customers is a crucial step in ensuring a smooth migration to a new technology, especially in the open-source domain. We want to understand your specific needs and use cases, and especially the customisations and snippets that you use.

Enter Kea

“It’s life, Jim, but not as we know it.”  Dr. McCoy

The ISC recognised the need for a new DHCP tool, and Kea was created to meet many of the most-requested DHCP features. One of the main advantages of Kea is its ability to make real-time updates through a REST API, allowing for changes to parameters without needing to restart the daemon.

Kea does have some limitations that we’ll need to address. While it claims to support both active/active and active/passive failover, the reality is that only active/active is functional due to node limits and sync times.

On the other hand, Kea uses IPC for replication, making it less likely for flapping to occur when all DHCP servers are in the same network or LAN cluster. This approach aligns well with MAAS, which uses RPC for region-rack communications, making Kea a better match for the MAAS model of local networking.

The biggest difference, though, is the way Kea configures DHCP, as it uses a fundamentally different parameter architecture from traditional DHCP. This means that the concept of snippets will need to be replaced with a more modern approach.

In fact, Kea configuration files are a lot different from dhcpd.conf:

• Kea configuration files use JSON, with the obligatory key-value pairs:

"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"
            ]
         }
      ]
   }
]

• They also use different parameters in many places.
• They also have the concept of “classes”, which wasn’t exactly prominent in the old dhcpd.conf files.

Of course, MAAS DHCP snippets are just little pieces of dhcpd configuration that you can enter. It doesn’t take much imagination to realise that moving to Kea will break MAAS DHCP snippets, in a way that isn’t easy to fix.

Active discussion

“I’m a doctor, not an engineer.” Dr. McCoy

We want to provide clear guidance and support to our users to help you help us make the transition as smoothly as possible. This will include documentation, tutorials, training sessions, and a dedicated forum channel to address any issues that may arise during the planning and migration process.

In addition, we will be offering Thursday video calls with one or more MAAS team members to discuss and better understand your requirements. This will help us ensure that we are providing the best possible solutions for your needs, and give us a chance to directly address any concerns you may have.

We want to gaining a better understanding of how you — our users — are currently utilising DHCP snippets, so that we can ensure that we can meet your needs in the future. We seek feedback from all users, regardless of whether or not you have used snippets in the past. Even if you haven’t previously used snippets, we encourage you to share any potential use cases that you may have. Our goal is to gather as much input as possible so that we can make sensible and informed decisions about replacing dhcpd.

Book some Thursday time with us

Book some time on a Thursday to talk to us about this. If necessary, we’re also willing to schedule an online conversation with one or many developers, at another time convenient for you.

We understand that the switch from traditional DHCP to Kea may seem like a significant change, because — frankly — it is. We want to assure you that we are committed to making this transition as smooth as possible for our users. We strongly believe that involving you in this process is paramount to achieving our primary goal: to become the best open-source company in the world, without exception.

Your input will help us ensure that we are providing the best possible product for your needs. We invite you to join us in planning and executing this critical change to the MAAS product.

All our yesterdays

“The man you knew won’t exist for another 5,000 years.” Dr. McCoy

Somewhere on a thumb-drive, I have a few rudimentary programs I wrote when I first started using UNIX about 50 years ago. Looking back, these programs have long been surpassed by advances in technology that I never even imagined. Although they could still run on current versions of Ubuntu (which is really saying something), I wouldn’t use them today. There are far more effective and efficient methods available to achieve the same tasks, which just goes to show how much technology has evolved over the years.

And we need to evolve with it. While it may take some time and effort to migrate to a new DHCP solution, it’s important to approach the process with a positive mindset and a willingness to learn and adapt. If the MAAS engineering team has its way, you may even find that the new solution offers features and capabilities that you never had before.

And who knows? Maybe someday in the future, you’ll look back on your old dhcpd.conf snippets with fondness and appreciation for the role they played in your career!