I’d like to get your thoughts on the future of managed DHCP support in Foreman.
Currently, Foreman provides managed DHCP to automate and control IP assignments during provisioning. However, the default DHCP provider we rely on, ISC DHCP, is no longer being maintained and won’t be supported in CentOS 10 (see ISC DHCP Server has reached EOL - ISC).
Given this, we’re considering whether it still makes sense to maintain managed DHCP support or if we should focus on alternative approaches - such as unmanaged DHCP, where Foreman does not control the DHCP server and cannot read or display leases.
It’d be great to hear your feedback:
Do you use Foreman’s managed DHCP?
If yes, what DHCP provider are you using?
How important is managed DHCP for your setup?
Do you see value in exploring alternatives, or do you have other suggestions?
Your input will help us figure out the best way forward for the project.
Yes, in nearly all environments where the customer wants provisioning.
Most use ISC DHCP so need a replacement, some Infoblox and Active Directory.
From customer feedback they like to get one tool to manage the full provisioning. From my experience environments where we have no control over DHCP are much harder to manage (only good workflow without control over DHCP is Bootdisk on VMware).
I would like to see a new default as good as ISC DHCP, but I am not sure if ISC Kea is this with its limitations as Open Core!
I still think the term “unmanaged DHCP” is wildly confusing so perhaps we can first clarify exactly what we mean by it.
The first level means the Smart Proxy is configured to talk to a DHCP server. This to me means managed. Smart Proxy DHCP Providers that work on this level are smart_proxy_dhcp_infoblox and smart_proxy_dhcp_remote_isc.
A tighter integration is where the installer also manages the DHCP server implementation. We only have this with the dhcp_isc provider. Note you can configure the installer to not manage the DHCP server and still use dhcp_isc.
By those definitions you can’t read and display leases on unmanaged DHCP because it’s all a black box what happens at the DHCP layer.
Perhaps you can elaborate how you see these definitions.
Yes, switching to KEA DHCP is the option we’re looking into for support. We’ve checked out the Smart Proxy plugin by Pierfrancesco Cifra (Smart Proxy DHCP KEA) on GitLab and are considering it for our setup.
libdhcp_lease_cmds.so is part of the open source code and is available to every Kea user.
That has APIs to manages leases for both IPv4 and IPv6.I know the libdhcp_host_cmds.so hook library is a premium feature, but with ISC DHCP we also only use leases so I’m not sure why it would be difficult.
I have had contact with CERN about this in the past, but never chased it. I’d expect that changing it to use the REST API shouldn’t be hard.
First of all we would definitely keep a way of setting up a DHCP server along with Foreman (Proxy) in order to provide a working network setup if there is no existing DHCP environment at all.
This would include at least a default configuration with a subnet configuration. Not sure if this is then already “managed” by definition or not - let’s say it’s still unmanaged.
Alternatively, users have to set it up themselves which could be covered by documentation.
In an unmanged DHCP scenario, we basically lose the ability for host specific configuration. This includes a) a desired, fixed IP address and b) the option for the network bootstrap program (NBP) per host. Furthermore, Foreman is not aware of any connection details in the first place.
The first could probably be mitigated by static IP configuration in the bootloader configuration, however there might be conflicts if the DHCP server is not aware of them. It’s basically up to the user to take care of ranges - and this can get difficult if static addresses need to be distributed in the subnet.
I think there are use-cases for static IP addresses and we should not limit the user in this aspect.
Regarding NBP, there are ways (= various DHCP options) of basically distinguishing between the actual firmware (BIOS vs. UEFI) of a host. But for our current Secure Boot implementation this is not enough. This also brings us to the topic of supported bootloaders in Foreman, which is another topic that we might need/want to strip them.
Making Foreman aware of a host’s IP address might be easy by reporting the corresponding fact from the host to the Foreman. Alternatively, use a working DNS environment (mDNS, DDNS).
Overall I vote for keeping a managed DHCP which keeps the flexibility we have at the moment and being better prepared for use-cases like Secure Boot, upcoming bootloaders, or even upcoming provisioning methods. Whether it’s KEA DHCP or something else.
Both Infoblox and remote_isc (for different network zones)
Pretty important. We use the infoblox DHCP provider to double up as a DNS provider via the Infoblox host records. Also, we are running in a heterogeneous environment, where Foreman manages many, but far from all hosts in the datacenter, and the DHCP/IPAM systems are the single source of truth for network addresses in use.
I would suspect that many enterprise users have similar requirements than we do. So I would expect that keeping DHCP management would a must-have feature for most of them, especially since the dedicated IPAM integration never really took of afaik.
Dropping DHCP management in general would be a major downside for us, since we would then need to implement some form of alternative in our workflows ourself. That would drastically lower the usefulness of the Foreman stack for us.
To summarize the discussion so far, we should continue supporting DHCP management. The best solution we have identified is to set KEA DHCP as the default server instead of ISC. This can be achieved using the Smart Proxy plugin: Pierfrancesco Cifra / Smart Proxy DHCP KEA, though it likely needs updates to support the latest version of KEA.
The plugin manages KEA through direct access to the database, but KEA also provides a RESTful API for interaction. The challenge with the KEA RESTful API is that not all requests are available in the open-source version; some require a premium subscription. Therefore, to access all of KEA’s features, we would need to use the plugin.
1.) Yes I use Foremans managed dhcp in almost all situations
2.) ISC is the main one I use as it’s the most widely adopted, dns_nsupdate_gss has been used for environments that use AD as their source of truth for all IP management, and I expect to see adoption of Kea as it matures and the license/features stabilise, it looks a big step forward in terms of dhcp tech, just problems with the way ISC have developed/licensed features for it, I’d hope to see foreman create a kea provider, especially as EL10 will move to kea
3.) as one of foreman’s core functionality is provisioning, having something that can manage all aspects of the provisioning lifecycle is very important, and from personal experience any environment that is not over 50% Windows servers (excluding desktops) tends to have a non-AD based IP management service, which then the expectation is that the provisioning tools can at least integrate with or centrally manage. so the capability is essential and the use of it is high from personal experience
4.) I’m not sure what other options there are, I wouldn’t want Foreman to write it’s own IP management service, the model of building providers to integrate with (and then depending on how mature/desired) write a management function to move from integrate to manage seems to be the only viable option the deployment project to move Foreman to container based deployment may open some other options I can’t think of at the moment, but beyond a.) integration to big DHCP providers is essential b.) full lifecycle management of the biggest DHCP providers is almost as essential c.) the provider model seems the only viable option I can see at this time, and it’s just a question of which DHCP resources to build a provider fore and which DHCP resources should be invested in for full lifecycle management
But yes, DHCP management of at least the biggest main providers is essential
