PXE Dispatcher for iPXE

[robinsmidsrod]

I have created a simple Perl-based script which can be hooked into any web server that supports a standard CGI interface.

You can find the code at: http://github.com/robinsmidsrod/pxe-dispatcher

What I usually do is to symlink this script in the root of my TFTP root (/srv/tftp/ on Ubuntu, which I use) and then I share out that folder as a Samba share (so I can edit the files from a Windows desktop machine). At the end I create a symlink in /var/www/tftp that points to /srv/tftp. This way I can easily boot from either TFTP or HTTP with the same files.

If I create /srv/tftp/pxeboot/default.pxe, this script will automatically be executed by iPXE on boot. If default.pxe doesn't exist, pxelinux.0 is booted if it exists. pxelinux.0 should be installed alongside pxeboot.cgi.

The more interesting part of the script is the part that allows you to create custom boot scripts by MAC of the client. They should be named something like /srv/tftp/pxeboot/0025b35fd52f.pxe. The content of the file is just a normal iPXE script.

My laptop has a boot script file which contains the following code:

Code:

#!ipxe
echo
echo Booting HP laptop
chain freedos.pxe

And for that to work I have a separate file named /srv/tftp/pxeboot/freedos.pxe with the following code in it:

Code:

#!ipxe
echo
echo Booting FreeDOS for ${hostname} from SAN
set keep-san 1
set root-path iscsi:nas.smidsrod.lan::::iqn.2011-02.lan.smidsrod:${hostname}.boot.freedos
sanboot ${root-path}
echo Boot from ${root-path} failed, dropping to shell
shell

This enables me to boot FreeDOS on my laptop entirely from an iSCSI target.

Another script I have is named ubuntu-install.pxe and it contains the following code:

Code:

#!ipxe
echo
echo Installing Ubuntu for ${hostname} from SAN
# Setup iSCSI root path
set root-path iscsi:nas.smidsrod.lan::::iqn.2011-02.lan.smidsrod:${hostname}.boot.ubuntu
set skip-san-boot 1
set keep-san 1
# Hook iSCSI target
sanboot ${root-path}
# Boot kernel+initrd for Ubuntu install
kernel http://boot.smidsrod.lan/ubuntu-10.10-amd64-server/boot/linux
initrd http://boot.smidsrod.lan/ubuntu-10.10-amd64-server/boot/initrd.gz
imgargs linux ks=http://boot.smidsrod.lan/ubuntu-10.10-amd64-server/boot/ks.cfg
boot

echo Booting failed, dropping to shell
shell

For booting Ubuntu, I just use a script similar to the FreeDOS variant, just with the strings "freedos" replaced with "ubuntu".

Hope some of you will find it useful, and I would love if any of you have any ideas for improvements. If you make any improvements, do send me a pull request on GitHub.

[mcb30]

(2011-04-05 18:10)robinsmidsrod Wrote:  I have created a simple Perl-based script which can be hooked into any web server that supports a standard CGI interface.

Very neat. I especially like the idea of sending back a fixed script that causes iPXE to call the same CGI script again but with additional parameters for ${uuid} etc.

(2011-04-05 18:10)robinsmidsrod Wrote:  And for that to work I have a separate file named /srv/tftp/pxeboot/freedos.pxe with the following code in it:

Code:

#!ipxe
echo
echo Booting FreeDOS for ${hostname} from SAN
set keep-san 1
set root-path iscsi:nas.smidsrod.lan::::iqn.2011-02.lan.smidsrod:${hostname}.boot.freedos
sanboot ${root-path}
echo Boot from ${root-path} failed, dropping to shell
shell

You need something like

Code:

sanboot ${root-path} ||

to prevent the script from exiting immediately if the sanboot command fails.

[robinsmidsrod]

(2011-04-05 18:24)mcb30 Wrote:  You need something like

Code:

sanboot ${root-path} ||

to prevent the script from exiting immediately if the sanboot command fails.

Actually, I don't expect the sanboot command to return in this case, and as you can see, I drop to the shell if it actually returns.

[mcb30]

(2011-04-05 18:34)robinsmidsrod Wrote:  

(2011-04-05 18:24)mcb30 Wrote:  You need something like

Code:

sanboot ${root-path} ||

to prevent the script from exiting immediately if the sanboot command fails.

Actually, I don't expect the sanboot command to return in this case, and as you can see, I drop to the shell if it actually returns.

The sanboot command will never return successfully. If it returns at all, it will return with a failure, which will terminate the script before reaching the "drop to shell" line. (See http://ipxe.org/scripting#error_handling).

[robinsmidsrod]

(2011-04-05 20:22)mcb30 Wrote:  

(2011-04-05 18:34)robinsmidsrod Wrote:  

(2011-04-05 18:24)mcb30 Wrote:  You need something like

Code:

sanboot ${root-path} ||

to prevent the script from exiting immediately if the sanboot command fails.

Actually, I don't expect the sanboot command to return in this case, and as you can see, I drop to the shell if it actually returns.

The sanboot command will never return successfully. If it returns at all, it will return with a failure, which will terminate the script before reaching the "drop to shell" line. (See http://ipxe.org/scripting#error_handling).

This behaviour does seem a bit counter-intuitive. I'm not entirely sure what would be the best behaviour, but failure to actually connect to the SAN URL and failure to actually boot the SAN drive (e.g. missing boot sector) could be considered different.
Failing to connect to the iSCSI target would for me indicate a hard fail, and should throw an exception, but failure to boot the drive is a sort of soft fail, because the problem is with the contents of the drive, and not in communicating with it. I would consider the last one a case of success (in a way).

[mcb30]

(2011-04-05 22:51)robinsmidsrod Wrote:  This behaviour does seem a bit counter-intuitive. I'm not entirely sure what would be the best behaviour, but failure to actually connect to the SAN URL and failure to actually boot the SAN drive (e.g. missing boot sector) could be considered different.
Failing to connect to the iSCSI target would for me indicate a hard fail, and should throw an exception, but failure to boot the drive is a sort of soft fail, because the problem is with the contents of the drive, and not in communicating with it. I would consider the last one a case of success (in a way).

For the sake of backwards compatibility, the sanboot command will have to fail for either reason. As mentioned elsewhere, I'm looking at implementing separate hook/unhook commands, which would allow you to do something like

Code:

sanhook ${root-path} || goto cannot_connect_to_target
sanboot || goto cannot_boot_from_target
sanunhook

Syntax may change before implementation.

[Sha0]

Cool stuff!

For what it's worth, I might just mention that .pxe is used as the file extension for NBPs (Network Bootstrap Programs) under [at least] PXELINUX and 3Com Boot Services.

Personally, I prefer .ipxe as the extension for iPXE scripts.

[robinsmidsrod]

At first I had .gpxe as the extension (before I noticed the iPXE project), and then I switched it to .ipxe, and eventually I switched it to .pxe because it actually works with both gPXE and iPXE. Some of the more advanced features obviously doesn't work with gPXE, but pxe-dispatcher itself doesn't emit any iPXE-specific script commands.

[mymycracra]

Hi robin,

Juste wanted to let you know that the PXE dispatcher doesn't with the latest pxelinux (cf http://forum.ipxe.org/showthread.php?tid=1024).

Regards,
JM

[robinsmidsrod]

"Doesn't work" is a bit vague. Could you add some more detail, or explain in what part of the process things fail? If it is indeed a failure, I'd appreciate a bug report here: https://github.com/robinsmidsrod/pxe-dispatcher/issues