Syslinux - Jun 2011 - Chainloading from one PXELINUX to another (with some iPXE in the mix)?

Hello SYSLINUX folks, thanks for all your hard work over the years!

I'm working on a fairly complex deployment services project, and one of the 
aspects of it is to make it possible to federate deployment services across
our university. Supporting existing deployment services is a priority, so
I am presently trying to integrate an existing PXELINUX install, part of a 
FOG windows imaging service, with a larger iPXE / SYSLINUX setup.

The boot order is as follows:
F12 network boot -> local PXE -> iPXE from master server -> Syslinux
VESA menu.

iPXE is in the chain first because we have some custom scripting that runs that
could result in a machine not booting to SYSLINUX, but that functionality is all
working well at the moment.

Once we hit Syslinux, one of the submenus covers a department's existing FOG
server. FOG uses PXELINUX itself, and provides a number of static boot lines 
in its own pxelinux.cfg/default file. Those lines were simply integrated into 
our new master Syslinux setup. 
However, FOG assigns a "task" to a machine by creating a MAC-address
specific
config file in its TFTP pxelinux.cfg directory, so that when the machine boots, 
it runs a specific kernel with a complex APPEND string of options (including the
image file to use and more). Without this APPEND line, FOG is broken.

Within the framework of this federated deployment project, after much head
scratching, the next easiest method for me to use was to create a shim of 
sorts, written in PHP and executing on the FOG server.

When provided with the MAC address of a machine as a GET parameter, it 
searches for a pxelinux.cfg file specific to that MAC, and outputs an iPXE 
script that causes iPXE to start FOG the same way with the same parameters.

I then call iPXE as 'ipxe.lkrn' from within the master SYSLINUX, with a 
parameter that is a short one-line script to get a DHCP address, download
the output of that script from the FOG server, and execute it:

LABEL fog.currentTask
 kernel ipxe.lkrn dhcp && chain
http://[FQDN]/tftpboot/fog-ipxe.php?mac=${mac}
 MENU LABEL Boot to FOG server and run assigned task

This works really well on *most* machines, and ends up being quite robust. 
However, 'ipxe.lkrn' seems to require native network driver support in
order to
function, unlike the initial iPXE instance which uses the network card's
UNDI
support. So, on machines with even slightly weird network hardware (read: most
laptops), this second iPXE instance can't get to the network.

The iPXE development mailing list had a suggestion for me to try using 
SYSLINUX's CONFIG statement, wherein I provide the TFTP address of a 
pxelinux.cfg file. 

LABEL fog.currentTaskDebug1
	CONFIG tftp://[FQDN]/pxelinux.cfg/default
	MENU LABEL Fog with Syslinux CONFIG directive

This works, sort of. What it will do is display the PXELINUX menu from the FOG 
server. However, it cannot run the 'current task' for the machine,
because doing
so would have required that we fetch instead something like:

  tftp://[FQDN]/pxelinux.cfg/01-11-22-33-44-55-66

There is no variable support in SYSLINUX yet, unfortunately, so I can't just
issue
a line like the iPXE ${mac} above.

Is there some way to use this CONFIG line (or the mysteriously undocumented 
config COM32 module, which could be the same thing?) to load the SYSLINUX config
file from some other server using the same order of precedence that SYSLINUX
uses
when first loading its own config file?

If this feature doesn't exist, could some kind soul that knows how to
program
better than I whip it up for me? I'll find a way to repay you in coffee/beer
somehow :-)

Much appreciated,

Mike Sollanych - msollany at sfu.ca
IT Services - Research Computing Group
Simon Fraser University

On Tue, 2011-06-07 at 18:04 -0700, Mike Sollanych wrote:
> Hello SYSLINUX folks, thanks for all your hard work over the years!
> 
> I'm working on a fairly complex deployment services project, and one of
the
> aspects of it is to make it possible to federate deployment services across
> our university. Supporting existing deployment services is a priority, so
> I am presently trying to integrate an existing PXELINUX install, part of a 
> FOG windows imaging service, with a larger iPXE / SYSLINUX setup.
> 
> The boot order is as follows:
> F12 network boot -> local PXE -> iPXE from master server ->
Syslinux VESA menu.
> 
> iPXE is in the chain first because we have some custom scripting that runs
that
> could result in a machine not booting to SYSLINUX, but that functionality
is all
> working well at the moment.
> 
> Once we hit Syslinux, one of the submenus covers a department's
existing FOG
> server. FOG uses PXELINUX itself, and provides a number of static boot
lines
> in its own pxelinux.cfg/default file. Those lines were simply integrated
into
> our new master Syslinux setup. 
> However, FOG assigns a "task" to a machine by creating a
MAC-address specific
> config file in its TFTP pxelinux.cfg directory, so that when the machine
boots,
> it runs a specific kernel with a complex APPEND string of options
(including the
> image file to use and more). Without this APPEND line, FOG is broken.
> 
> Within the framework of this federated deployment project, after much head
> scratching, the next easiest method for me to use was to create a shim of 
> sorts, written in PHP and executing on the FOG server.
> 
> When provided with the MAC address of a machine as a GET parameter, it 
> searches for a pxelinux.cfg file specific to that MAC, and outputs an iPXE 
> script that causes iPXE to start FOG the same way with the same parameters.
Why not skip all this complexity, and simply use PXECHAIN.COM to
chain-boot a new copy of PXELINUX from the FOG server?  Then it can
manage the TFTP directory however it wants, provide whatever PXELINUX it
wants to run, associated com32 modules, etc., and the rest of your
system doesn't need to know anything about it.



This approach also has the advantage that PXECHAIN can pass control to
_any_ PXE NBP, not just PXELINUX, so you can hand off to pretty much
anything that thinks it ought to be running or installed on a PXE
server.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

On 6/7/2011 6:04 PM, Mike Sollanych wrote:
> Hello SYSLINUX folks, thanks for all your hard work over the years!
>
> I'm working on a fairly complex deployment services project, and one of
the
> aspects of it is to make it possible to federate deployment services across
> our university. Supporting existing deployment services is a priority, so
> I am presently trying to integrate an existing PXELINUX install, part of a
> FOG windows imaging service, with a larger iPXE / SYSLINUX setup.
>
> The boot order is as follows:
> F12 network boot ->  local PXE ->  iPXE from master server -> 
Syslinux VESA menu.
>
> iPXE is in the chain first because we have some custom scripting that runs
that
> could result in a machine not booting to SYSLINUX, but that functionality
is all
> working well at the moment.
>
> Once we hit Syslinux, one of the submenus covers a department's
existing FOG
> server. FOG uses PXELINUX itself, and provides a number of static boot
lines
> in its own pxelinux.cfg/default file. Those lines were simply integrated
into
> our new master Syslinux setup.
> However, FOG assigns a "task" to a machine by creating a
MAC-address specific
> config file in its TFTP pxelinux.cfg directory, so that when the machine
boots,
> it runs a specific kernel with a complex APPEND string of options
(including the
> image file to use and more). Without this APPEND line, FOG is broken.
>
> Within the framework of this federated deployment project, after much head
> scratching, the next easiest method for me to use was to create a shim of
> sorts, written in PHP and executing on the FOG server.
>
> When provided with the MAC address of a machine as a GET parameter, it
> searches for a pxelinux.cfg file specific to that MAC, and outputs an iPXE
> script that causes iPXE to start FOG the same way with the same parameters.
>
> I then call iPXE as 'ipxe.lkrn' from within the master SYSLINUX,
with a
> parameter that is a short one-line script to get a DHCP address, download
> the output of that script from the FOG server, and execute it:
>
> LABEL fog.currentTask
>   kernel ipxe.lkrn dhcp&&  chain
http://[FQDN]/tftpboot/fog-ipxe.php?mac=${mac}
>   MENU LABEL Boot to FOG server and run assigned task
>
> This works really well on *most* machines, and ends up being quite robust.
> However, 'ipxe.lkrn' seems to require native network driver support
in order to
> function, unlike the initial iPXE instance which uses the network
card's UNDI
> support. So, on machines with even slightly weird network hardware (read:
most
> laptops), this second iPXE instance can't get to the network.
>
> The iPXE development mailing list had a suggestion for me to try using
> SYSLINUX's CONFIG statement, wherein I provide the TFTP address of a
> pxelinux.cfg file.
>
> LABEL fog.currentTaskDebug1
> 	CONFIG tftp://[FQDN]/pxelinux.cfg/default
> 	MENU LABEL Fog with Syslinux CONFIG directive
>
> This works, sort of. What it will do is display the PXELINUX menu from the
FOG
> server. However, it cannot run the 'current task' for the machine,
because doing
> so would have required that we fetch instead something like:
>
>    tftp://[FQDN]/pxelinux.cfg/01-11-22-33-44-55-66
>
> There is no variable support in SYSLINUX yet, unfortunately, so I can't
just issue
> a line like the iPXE ${mac} above.
>
> Is there some way to use this CONFIG line (or the mysteriously undocumented
> config COM32 module, which could be the same thing?) to load the SYSLINUX
config
> file from some other server using the same order of precedence that
SYSLINUX uses
> when first loading its own config file?
>
> If this feature doesn't exist, could some kind soul that knows how to
program
> better than I whip it up for me? I'll find a way to repay you in
coffee/beer
> somehow :-)
>
> Much appreciated,
>
> Mike Sollanych - msollany at sfu.ca
> IT Services - Research Computing Group
> Simon Fraser University
>
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
Out of curiosity, Have you looked at gpxecmd.c32? I haven't personally 
used it (yet), but from my understanding it is supposed to be able to 
use and gpxe command. I read on the mailing list (I believe) that it 
appears to be compatible with iPXE as well.

Assuming all the above is correct you should be able to do something 
like (untested):

set 209:string pxelinux.0
set 210:string tftp://[some server]
chain pxelinux.0

As another possibility, Can you run a pre-menu from iPXE to split your 
requests? iPXE can call syslinux 3.x com32 modules directly, so you 
could run vesamenu.c32 with a configuration file that gives your users 
two choices, new server / old server ?

An example of this could be found @ 
http://etherboot.org/wiki/appnotes/authmenus scroll down to vesamenu.c32 
directly.

While possibly not being the most elegant solution, if none of the other 
proposed solutions work, hopefully this one will.

-A

--
Andrew Stuart
iPXE/SYSLINUX mailing list lurker

Hallo, Mike,

Du meintest am 07.06.11:

[FOG]
> Once we hit Syslinux, one of the submenus covers a department's
> existing FOG server. FOG uses PXELINUX itself, and provides a number
> of static boot lines in its own pxelinux.cfg/default file. Those
> lines were simply integrated into our new master Syslinux setup.
> However, FOG assigns a "task" to a machine by creating a
MAC-address
> specific config file in its TFTP pxelinux.cfg directory, so that when
> the machine boots, it runs a specific kernel with a complex APPEND
> string of options (including the image file to use and more). Without
> this APPEND line, FOG is broken.
FOG is an unsecure program. I have tried it, I have put it onto another  
server which only serves FOG.

And I have used the "dnsmasq" lines

# --------------------------------------
# Tipp von Clemens Fischer, dnsmasq-Mailingliste 12.6.2010

# dhcp-mac = set:fog, 00:0d:60:76:4f:1c
dhcp-mac = set:fog, 11:22:33:44:55:66
# Think40w. 0.60
# beliebig oft zu wiederholen

pxe-service = tag:fog,x86PC,"fog",gpxelinux,192.168.0.5
pxe-service = tag:!fog,x86PC,"Arktur",gpxelinux,192.168.0.1
#
# --------------------------------------


Viele Gruesse!
Helmut