smee
smee copied to clipboard
tinkerbell
When an IPXe URL is a data-url, expand the url into ipxe content
Expected Behaviour
When providing an IPXe URL, that is data-uri encoded, boots should expand this URI into the decoded content and pass this to IPXE. This would be equivalent to #!ipxe userdata, but frees the userdata metadata to be consumed as userdata (cloud-init, ignition, etc).
Current Behaviour
Data URIs are not handled.
See also
- https://github.com/ipxe/ipxe/issues/174
sorry for the dumb questions, i don't think i fully understand the value here. Is this just a different format to provide the ipxe script? what data would be encoded here? the kernel? how is this any different than a normal ipxe script? would you mind expanding on this statement? "frees the userdata metadata to be consumed as userdata"
@jacobweinstock
would you mind expanding on this statement? "frees the userdata metadata to be consumed as userdata"
When providing an IPXE Script, you can currently take advantage of the userdata field with a value of #!ipxe\n.... In doing so, you lose the ability to take advantage of userdata for the intended purpose, which is for tools like cloud-init and afterburn to have a predefined location to discover platform-specific metadata. While this location is hardcoded into some systems (afterburn) it is generally configurable in the kernel command line.
We provide only one custom URL that can be consumed in this way. When that facility is repurposed to provide an IPXE script, we lose ability to treat the userdata field as cloud-config, kickstart config, multi-part mime cloud-configs and scripts, etc.
what data would be encoded here? the kernel?
The IPXE Script would be encoded.
To provide an ipxe_script_url today, you must have a web server that is accessible to the node, which may have networking restrictions that prevent that. But allowing for public internet routing and assuming I have a web-host available and my data is not sensitive (too many assumptions), I can park my IPXE Script URL on Github.
ipxe_script_url=https://gist.githubusercontent.com/displague/cd5938eb7584dd1c1cc76c28a3f9c762/raw/67e2047ca6304a8aaec80e49fdf38bf4da4f5a48/centos8-stream.ipxe
Rather than finding a remote host, making my IPXE script publicly, relying on DNS and internet routes, I could say ipxe_script_url=data:text/plain;charset=utf-8;base64,IyFpcHhlDQpkaGNwIG5ldDANCg0KIyBodHRwczovL3d3dy5jZW50b3Mub3JnL2Rvd25sb2FkL21pcnJvcnMvDQpzZXQgbWlycm9yIGh0dHA6Ly9taXJyb3IucGl0LnRlcmFzd2l0Y2guY29tDQoNCiMgeDg2XzY0LCBhYXJjaF82NCwgcHBjNjRsZQ0Kc2V0IGFyY2ggeDg2XzY0DQoNCnNldCBwYXRoIC9jZW50b3MvOC1zdHJlYW0vQmFzZU9TL3g4Nl82NC9vcw0Kc2V0IGJhc2UgJHttaXJyb3J9JHtwYXRofQ0KDQpzZXQgY29uc29sZSBjb25zb2xlPXR0eVMxLDExNTIwMG44DQoNCiMgY29yZW9zLmxpdmUucm9vdGZzX3VybD0ke21pcnJvcn0ke3BhdGh9L2Jvb3QuaXNvIA0Ka2VybmVsICR7YmFzZX0vaW1hZ2VzL3B4ZWJvb3Qvdm1saW51eiBjb25zb2xlPXR0eVMxLDExNTIwMG44IGluaXRyZD1pbml0cmQuaW1nIGluc3QucmVwbz0ke2Jhc2V9IGluc3QuaW5zdGFsbF9kZXY9L2Rldi9zZGEgcmQubmV0LnRpbWVvdXQuY2Fycmllcj0zMCBpbnN0LnBsYXRmb3JtX2lkPXBhY2tldA0KaW5pdHJkICR7YmFzZX0vaW1hZ2VzL3B4ZWJvb3QvaW5pdHJkLmltZw0KDQpib290
The effect is the same.
You could argue that I could take advantage of the userdata field for this (which removes the need for hosting and potentially DNS and public routes). As I previously mentioned, this removes our ability to use userdata for its intended purpose. If we suggest that cloud-config is not the explicit intention of userdata, then there is no reason for #ipxe support in userdata because a user should be able to use "ipxe_script_url": "https://{hegel:port}/userdata" along with "userdata": "#!/dev/null doesn't matter\n...my ipxe script...".
what data would be encoded here? the kernel?
I understand that one way to consume IPXE is to take advantage of relative paths for resources like the initrd and kernel, treating the host as a location for IPXE scripts and other assets.
For example, if https://myhost/ipxescript.ipxe references a kernel and initrd without a base path, I believe it is presumed that the base path to those resources (if not provided) will be https://myhost/.
As my gist shows, this is not a requirement for all IPXE scripts.
@displague thank you for the great explanations. I do believe I understand now.
With https://github.com/tinkerbell/boots/pull/192, being merged, there is now a new field metadata.instance.operatiing_system.InstallerData.Script that can be used for custom_ipxe and ipxe scripts. This frees up the userdata field for use with cloud-init, afterburn, etc.
Does this solve the issue the data-URI support was looking to solve?