Closed mrguitar closed 1 year ago
With isc-dhcp sunsetting (https://www.isc.org/blogs/isc-dhcp-eol/) it's unfortunately not a good idea to aim for more features on this subject (unless someone forks and keeps maintaining it, which by my knowledge isn't the case). No long term plans yet, but to avoid increasing the problem, I personally would like to opt for a feature freeze on dhcpd.
Thanks for the response. Oh yeah I forgot about the whole Kea thing. I definitely understand not wanting to keep investing in the current implementation. I'm not sure the existing "Advanced Options" is capable implementing the setup I need. Is there a way to manually work around the UI and add/edit this config periodically manually? I have a loose idea for how the UI generates the config and restarts the services, but really just at that level. If I can manipulate that safely that would be a suitable alternative for now.
Regarding kea, it does look like it supports this going forward: https://www.mail-archive.com/kea-users@lists.isc.org/msg01663.html so that's at least a good thing!
the problem with kea is that it's likely not a practical candidate for us in terms of complexity and dependencies. In the mean time you could try to add manual config files (https://docs.opnsense.org/manual/dhcp.html#advanced-settings), these are merged directly into the config
This is a perfect resolution IMO. I just placed the config snippet in the directory provided and bounced the service. It works perfectly! Thanks so much for this!!
@mrguitar you're more than welcome, we often try to add these type of imports to allow people to make their own modifications. If isc-dhcp
wasn't being deprecated, I probably would have added the feature in this case, but as long as the road ahead is unclear, these imports work like a charm.
@mrguitar close then? :)
Ah sorry, I thought I hit close on my last response and I apparently clicked comment erroneously. btw, I put this in a quick blog to maybe help others looking to do this. Hopefully this will help cut down on similar chatter. https://mrguitar.net/?p=2517 cheers!
No worries. Thanks for the guide!
Cheers, Franco
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
Is your feature request related to a problem? Please describe.
PXE had an epic run, but it's deprecation has been planned by major silicon vendors and UEFI HTTPboot is the replacement. The UI and dhcpd config only need to be modified slightly to enable support along side the existing PXE options - as that's likely to continue to be used for the next few years.
We essentially need a stanza in the dhcp config to match HTTPClient (60) and pass (67) filename of the NBP via http/https. So it's similar to PXE except there's no dependency on TFTP and can work with things like secure boot and leverage certificates loaded in the firmware.
A simple config could look similar to this: class "httpclients" { option vendor-class-identifier "HTTPClient"; match if substring (option vendor-class-identifier, 0, 10) = "HTTPClient"; filename "http://mywebserverip/boot/grub/x86_64-efi/core.efi"; }
for reference:
Describe the solution you like
I would like an additional field in the DHCP configuration box to configure a URL via http/https for an NBP that UEFI HTTPBOOT clients will fetch. This should work along side the existing options (bios pxe, EFI PXE, etc).
Describe alternatives you considered
I can't think of an alternative and the one above worked well for pfsense.
Additional context
Add any other context or screenshots about the feature request here or links to relevant forum thread or similar
UEFI HTTPS boot background info: https://edk2-docs.gitbook.io/getting-started-with-uefi-https-boot-on-edk-ii/introduction Suse's "how to" docs: https://en.opensuse.org/UEFI_HTTPBoot_Server_Setup
was implemented in pfsense here: https://redmine.pfsense.org/issues/11659 and here: https://redmine.pfsense.org/issues/12892