during UEFI HTTPBoot testing, @Roman_Plevka discovered that our default dhcpd.conf does not handle HTTPClients corectly. I would like to do an update of our puppet template, however there are few things to discuss. Looking at you @ekohl
IP address instead of hostname should be probably safer to use.
HTTP protocol should be the default, when the endpoint is enabled.
Probably when only HTTPS is enabled then we should return HTTPS URL, however EFI firmware will refuse to download the file unless CA is enrolled.
This looks like a more complex change, there is this $bootfiles variable defined. This probably needs to be broken up into two variables - one for PXE clients and one for HTTP clients. Or what is your suggestion @ekohl?
I took a very quick stab at this and is entirely untested. There are acceptance tests which I’m firing up now, but here’s the draft code:
In my PR I’ve used the same IP as the PXE server. It may be a bit unlogical to have the parameter --foreman-proxy-dhcp-pxeserver influence the HTTPBoot IP, but it was the quickest way in my draft. It’s also a pretty safe assumption that PXE and HTTPBoot are served on the same IP.
Done
Done. I think this can be documented as a known limitation that users with disabled HTTP need to deal with. Having the code in place allows orgs to disable HTTP in particular use cases.
Thanks, how can I test this on a production installation? I remember that last time when I tried to replace .pp file puppet was complaining. Is there a good way?
The installer maintains a parser cache of all exposed classes (from .pp files). If they change, the cache is considered invalid. I think this is an internal class so the parser cache shouldn’t be affected, but it’s safe to install puppet-agent-puppet-strings (available in our packaging repos) which allows parsing at runtime.