IPXE instead of PXE for the initial menu and for discovery?

Hello,
I'm planning to integrate Foreman into our infrastructure.
We're currently using ipxe and we built a simple menu where the user
selects an installation profile. The user can also choose some variants of
OpenBSD and Windows, by chainloading WDS.
I'd like to integrate the Foreman Discovery plugin progressively while
retaining ipxe as the main technology.

I see ipxe is supported but how do I select my ipxe recipe/image as the one
to be provided by the TFTP server? The only type of recipes in the PXELinux
menu under the OS/Templates section are the ones marked as PXE (not ipxe).

Thanks,
Nicola

Did you ever find an answer?

> Did you ever find an answer?

What was the question again?

··· -- Later, Lukas #lzap Zapletal

IF I understand correctly the original question, the author was trying to
use iPXE instead of regular (and now actually legacy) PXELinux on
smart-proxy side.

This is something that I'm looking for as well, but Foreman TFTP
smart-proxy seems to be missing native "ipxe" variant, that would allow for
creation of <tftp_path>/01-<MAC>.ipxe by calling something like this (based
on syntax for smart-proxy TFTP API described in [3]):

curl -k --cacert /var/lib/puppet/ssl/certs/ca.pem --cert
/var/lib/puppet/ssl/certs/hostname -f.pem --key
/var/lib/puppet/ssl/private_keys/hostname -f.pem -H
"Accept:application/json" -X POST https://<foreman-proxy>:8443/tftp/ipxe/00:11:22:33:44:55
-d "pxeconfig=blah blah blah"

Something that I'm sure more people interested in these days as with iPXE
as main bootloader (as opposed to chain-booting iPXE from PXELinux 01-<MAC>
described in [1]).

There multiple reasons for that:

  • support of more protocols to download config file - HTTP/HTTPS, etc.
  • ability to create backward-compatible implementations - iPXE can chain
    PXELinux if its own rather extensive script-enabled config file is not
    found.
  • support for both UEFI and BIOS (both of which obviously understand iPXE
    script/config file making this rather attractive alternative to having to
    recognize the boot method of the system and create an appropriate config
    files as described in [2]

[1] -
http://projects.theforeman.org/projects/foreman/wiki/Fetch_boot_files_via_http_instead_of_TFTP
[2] -


[3] - API - Smart Proxy - Foreman

Is there a reason why Foreman/Smart-proxy only uses iPXE by chaining
through PXElinux and not natively? Is it hard to add at least on
smart-proxy side?

Thanks!

> Is there a reason why Foreman/Smart-proxy only uses iPXE by chaining
> through PXElinux and not natively? Is it hard to add at least on
> smart-proxy side?
>
>
The actual change is very simple:

]# pwd
/usr/share/foreman-proxy/modules/tftp

diff tftp_api.rb-orig tftp_api.rb

11c11
< VARIANTS = ["Syslinux", "Pxegrub", "Pxegrub2", "Ztp", "Poap"].freeze

··· --- > VARIANTS = ["Syslinux", "Pxegrub", "Pxegrub2", "Ztp", "Poap", "Ipxe"].freeze

diff server.rb-orig server.rb

70a71,82

class Ipxe < Server
def pxeconfig_dir
“#{path}/pxelinux.cfg”
end
def pxe_default
“#{pxeconfig_dir}/default.ipxe”
end
def pxeconfig_file mac
“#{pxeconfig_dir}/01-”+mac.gsub(/:/,“-”).downcase+“.ipxe”
end
end

However, I immediately ran into issue with the size of ipxe config file -
it could be much larger that syslinux config file and if ipxe config file
is large, TFTP API only writes 464 bytes for me:

curl -k --cacert /var/lib/puppet/ssl/certs/ca.pem --cert

/var/lib/puppet/ssl/certs/hostname -f.pem --key
/var/lib/puppet/ssl/private_keys/hostname -f.pem -H
“Accept:application/json” -X POST
https://:8443/tftp/ipxe/00:11:22:33:44:55 -d “pxeconfig=cat default.ipxe

ls -l default.ipxe 01-00-11-22-33-44-55.ipxe

-rw-r–r–. 1 foreman-proxy foreman-proxy 464 Aug 2 17:28
01-00-11-22-33-44-55.ipxe
-rw-r–r–. 1 foreman-proxy foreman-proxy 2976 Aug 2 17:28 default.ipxe

This problem exist even w/o above changes and is not ipxe-related. For
example, here’s an attempt to create “syslinux” variant from a larger file
and resulting file is still 464 bytes in length:

curl -k --cacert /var/lib/puppet/ssl/certs/ca.pem --cert

/var/lib/puppet/ssl/certs/hostname -f.pem --key
/var/lib/puppet/ssl/private_keys/hostname -f.pem -H
“Accept:application/json” -X POST
https://spc.vip.syd.ebay.com:8443/tftp/syslinux/00:11:22:33:44:55 -d
“pxeconfig=cat default.ipxe

ls -l default.ipxe 01-00-11-22-33-44-55

-rw-r–r–. 1 foreman-proxy foreman-proxy 464 Aug 2 17:31
01-00-11-22-33-44-55
-rw-r–r–. 1 foreman-proxy foreman-proxy 2976 Aug 2 17:28 default.ipxe

> This is something that I'm looking for as well, but Foreman TFTP
> smart-proxy seems to be missing native "ipxe" variant, that would allow for
> creation of <tftp_path>/01-<MAC>.ipxe by calling something like this (based
> on syntax for smart-proxy TFTP API described in [3]):

I don't understand how would you download the script from proxy, using
HTTP? There is no preconfigured httpd service by default.

> - support of more protocols to download config file - HTTP/HTTPS, etc.

But no TFTP, right? I am not following why someone would do this.

> - support for both UEFI and BIOS (both of which obviously understand iPXE
> script/config file making this rather attractive alternative to having to
> recognize the boot method of the system and create an appropriate config
> files as described in [2]

iPXE UEFI is in quite early stage of development, you need to get a
recent build (2015). But sure, it's a great option for the future.

> Is there a reason why Foreman/Smart-proxy only uses iPXE by chaining
> through PXElinux and not natively? Is it hard to add at least on
> smart-proxy side?

No specific reason, the feature hasn't been delivered yet simply.

··· -- Later, Lukas #lzap Zapletal

> However, I immediately ran into issue with the size of ipxe config file -
> it could be much larger that syslinux config file and if ipxe config file
> is large, TFTP API only writes 464 bytes for me:
>
> # curl -k --cacert /var/lib/puppet/ssl/certs/ca.pem --cert
> /var/lib/puppet/ssl/certs/hostname -f.pem --key
> /var/lib/puppet/ssl/private_keys/hostname -f.pem -H
> "Accept:application/json" -X POST
> https://<proxy>:8443/tftp/ipxe/00:11:22:33:44:55 -d "pxeconfig=cat &gt; default.ipxe"

I believe your patch is correct, what's I believe is wrong is the way
you load data via shell. Doesn't the first newline break it? Try to use
stdin to provide the content.

··· -- Later, Lukas #lzap Zapletal

> I don't understand how would you download the script from proxy, using
> HTTP? There is no preconfigured httpd service by default.
>
> > - support of more protocols to download config file - HTTP/HTTPS, etc.
>
> But no TFTP, right? I am not following why someone would do this.
>

No, TFTP is still there. So really not any different from PXELinux, just
has more features for those who needs them. I'd just prefer to chain-load
PXELinux from iPXE rather than the other way around as it is done in
Foreman now. Enabling "ipxe" variant in TFTP proxy would be the first step
anyway, IMHO.

iPXE UEFI is in quite early stage of development, you need to get a
> recent build (2015). But sure, it's a great option for the future.
>

Hmm, I can't say that I fully agree with this statement - yes, you do need
the recent version, but I wouldn't say that it is at early stages. Works
for me pretty steadily so far.

> I believe your patch is correct, what's I believe is wrong is the way
> you load data via shell.

Should I submit a PR myself or create a new feature request for someone in
your team then?

> Doesn't the first newline break it? Try to use
> stdin to provide the content.
>

Yes, it turns out to be a content of the file that I was cat'ing had
special characters interpreted by shell and breaking curl data.

> Should I submit a PR myself or create a new feature request for someone in
> your team then?

Please go ahead.

··· -- Later, Lukas #lzap Zapletal

Here you go - https://github.com/theforeman/smart-proxy/pull/451

Please ignore https://github.com/theforeman/smart-proxy/pull/450 - already
closed it on github, but Redmine still shows that
Feature #16009: Support for native iPXE - Smart Proxy - Foreman has 2 PRs for some reason…