🌱 enable https download in ipxe

[defo89]

What this PR does / why we need it: I am trying to use TLS in every part of the deployment chain and it seems that by default HTTPS is disabled in iPXE image.

As per https://ipxe.org/buildcfg/download_proto_https this commit would enable support (tested this in our environment).

[metal3-io-bot]

Hi @defo89. Thanks for your PR.

I'm waiting for a metal3-io member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[tuminoid]

/ok-to-test

[tuminoid]

/test metal3-centos-e2e-integration-test-main metal3-ubuntu-e2e-integration-test-main

[tuminoid]

/test metal3-centos-e2e-integration-test-main metal3-ubuntu-e2e-integration-test-main

[dtantsur]

/approve /test metal3-centos-e2e-integration-test-main metal3-ubuntu-e2e-integration-test-main

[metal3-io-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dtantsur

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files: - ~~[OWNERS](https://github.com/metal3-io/ironic-image/blob/main/OWNERS)~~ [dtantsur] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[tuminoid]

/retest

[tuminoid]

/retest CI should be better now.

[Rozzii]

/hold, for https you need to also supply the certificates unless the specific url is compatible with ipxe's default credential chain (Mozzilla) also you have to configure the dnsmasq server of ironic with the same certs, we have already tooling to build https enabled ipxe on the fly or to use pre-built ipxe firmware https://github.com/metal3-io/utility-images.

What you are editing @defo89 in this PR is the default / statically compiled ipxe firmware (that is why it is compiled at container build time) that is suitable for those who have no special requirements, for those who need more advanced ipxe firmware I would recommend to deploy the ipxebuilder as an init container of the Ironic pod or just patch the Dockerfile downstream but IMO we should in no scenario edit the upstream docker file to get this functionality.

[Rozzii]

/hold

[metal3-io-bot]

@defo89: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
metal3-centos-e2e-integration-test-main	a6d12bb3b165dd951f3ecf2aa63e4baf2cf12b2b	link	true	/test metal3-centos-e2e-integration-test-main

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository. I understand the commands that are listed [here](https://go.k8s.io/bot-commands).

[defo89]

I would recommend to deploy the ipxebuilder as an init container of the Ironic pod or just patch the Dockerfile downstream We use this in production - problem with this approach would be delayed pod readiness on reschedule/failure of the node previously running this pod.

@Rozzii Would you consider an option to override the IPXE image location per env var like its done with IPA_BASEURI env? E.g. I could provide them via volume. My issue atm is that ironic-image provides all means to leverage TLS (I could do it for ironic and httpd) and only this bit is missing.

[Rozzii]

I would recommend to deploy the ipxebuilder as an init container of the Ironic pod or just patch the Dockerfile downstream We use this in production - problem with this approach would be delayed pod readiness on reschedule/failure of the node previously running this pod.

@Rozzii Would you consider an option to override the IPXE image location per env var like its done with IPA_BASEURI env? E.g. I could provide them via volume. My issue atm is that ironic-image provides all means to leverage TLS (I could do it for ironic and httpd) and only this bit is missing.

I plan to document this topic a bit more (or a lot more) in the future but I think we have such variables:

IPXE_CUSTOM_FIRMWARE_DIR can be used to specify where should the dnsmasq container find the custom firmware files IPXE_SSL_PROTOCOL is should set the SSL/TLS versions that IPXE_CERT_FILE the should be the same as the one embedded in the firmware IPXE_KEY_FILE same as above IPXE_TLS_PORT by default 8084 this is the port that the pxe firmware will use to call "home" and download the pxe files and the ramdisk

You are AFAIK the first user who would like to run things with custom PXE firmware so please keep me in the loop if you run into some issues.

[Rozzii]

Would it be okay to close this ticket @defo89 ?

[defo89]

@Rozzii sure, we can close it. Thanks!