Syslinux - Feb 2014 - [RFC, PATCH] core/pxe: Add architecture-specific discovery request for PXE config file

Hi all,
>> In other words, the dhcp server has to start the client on the
>> correct binary for it's arch and by virtue of running different
bins,
>> we can determine the most appropriate config file for the client?
> 
> That is definitely one way to deal with it.
> 
> There is no way around the fact that you have to have different binaries
> for different architectures; there is nothing that Syslinux can do about
> that, and it has to be dealt with before Syslinux is even running.
Yep, definitely.

As Gene has mentioned, we could indeed do this in pxelinux through
serving different binary images, but this means we need a different
method for different pxe loader implementations, and this won't work
when the loader binary is already present on the machine.

What I'm looking to do here is establish a bit of a convention for
allowing machines of multiple architectures to be perform PXE
configuration in a uniform way (in this case, without requiring the DHCP
server to send out different lease parameters in response to the
client's DHCP architecture ID).

For this to be useful, my aim is that different pxe loader
implementations to follow the arch-xxxx convention too; I'm proposing a
similar change in petitboot:

 http://git.ozlabs.org/?p=petitboot;a=commitdiff;h=3bc86f99

I have a patch in development for u-boot too.

In the petitboot & u-boot cases, the pxe loader code is already present
on the machine, so we don't have the "which loader binary to
serve"
issue, only the "which config to use" one.
> Now, with lpxelinux.0 you can also enable HTTP cookies which contain a
> *lot* of system information that you can use dynamically on your HTTP
> server via PHP or whatever you want.
That sounds great. I'd like to do the same in petitboot, and it'd be
good to use the same format there. However, I do still need to support
TFTP discovery too.

Cheers,


Jeremy

On Mon, Feb 24, 2014 at 8:41 PM, Jeremy Kerr <jk at ozlabs.org> wrote:
> As Gene has mentioned, we could indeed do this in pxelinux through
> serving different binary images, but this means we need a different
> method for different pxe loader implementations, and this won't work
> when the loader binary is already present on the machine.
>
> What I'm looking to do here is establish a bit of a convention for
> allowing machines of multiple architectures to be perform PXE
> configuration in a uniform way (in this case, without requiring the DHCP
> server to send out different lease parameters in response to the
> client's DHCP architecture ID).
How do you have multiple architectures booting from the same directory
at this time?  What exact string is used by network boot clients of
each of the three architectures?

-- 
-Gene

Ok, that makes sense.  PXELINUX had become a de facto standard and has in fact
been extended with ipv6 support by agreement between me and Peter Jones, used in
at least some versions of Grub.

Here is the problem I see: arch discovery is orthogonal with address-based
discovery.  It creates a complex problem because we don't want to try all
possible combinations.  One option is to have an extended filename string with
lots of info first and assume that people who need that have a TFTP server which
supports rewriting; another would be to do the arch-based ones right before
default, under the assumption that if you know your client you know what matters
already.

The final option is to introduce macros that can be used in an include
statement, so the file fetched would be a generic config file which can include
others based on all kind of parameters, making most of the discovery junk
unnecessary.  It also lets the sysadmin keep the common bits common.  Personally
this is the option I like the best.  iPXE has been doing this for years.


On February 24, 2014 5:41:35 PM PST, Jeremy Kerr <jk at ozlabs.org>
wrote:
>Hi all,
>
>>> In other words, the dhcp server has to start the client on the
>>> correct binary for it's arch and by virtue of running different
>bins,
>>> we can determine the most appropriate config file for the client?
>> 
>> That is definitely one way to deal with it.
>> 
>> There is no way around the fact that you have to have different
>binaries
>> for different architectures; there is nothing that Syslinux can do
>about
>> that, and it has to be dealt with before Syslinux is even running.
>
>Yep, definitely.
>
>As Gene has mentioned, we could indeed do this in pxelinux through
>serving different binary images, but this means we need a different
>method for different pxe loader implementations, and this won't work
>when the loader binary is already present on the machine.
>
>What I'm looking to do here is establish a bit of a convention for
>allowing machines of multiple architectures to be perform PXE
>configuration in a uniform way (in this case, without requiring the
>DHCP
>server to send out different lease parameters in response to the
>client's DHCP architecture ID).
>
>For this to be useful, my aim is that different pxe loader
>implementations to follow the arch-xxxx convention too; I'm proposing a
>similar change in petitboot:
>
> http://git.ozlabs.org/?p=petitboot;a=commitdiff;h=3bc86f99
>
>I have a patch in development for u-boot too.
>
>In the petitboot & u-boot cases, the pxe loader code is already present
>on the machine, so we don't have the "which loader binary to
serve"
>issue, only the "which config to use" one.
>
>> Now, with lpxelinux.0 you can also enable HTTP cookies which contain
>a
>> *lot* of system information that you can use dynamically on your HTTP
>> server via PHP or whatever you want.
>
>That sounds great. I'd like to do the same in petitboot, and it'd be
>good to use the same format there. However, I do still need to support
>TFTP discovery too.
>
>Cheers,
>
>
>Jeremy
-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Hi hpa,
> Ok, that makes sense.  PXELINUX had become a de facto standard and
> has in fact been extended with ipv6 support by agreement between me
> and Peter Jones, used in at least some versions of Grub.
Yep, exactly. This is why I'm proposing the patch to you folks first :)
> Here is the problem I see: arch discovery is orthogonal with
> address-based discovery.  It creates a complex problem because we
> don't want to try all possible combinations.
It is orthogonal, but I don't think that necessarily results in
combinatorial explosion of potential request paths. I see there being
two main scenarios for large-scale pxe usage:

 1) those where individual machines are tightly managed, and boot
    parameters are known in advance. Each machine is "registered"
    before booting. The UUID, MAC and lease-IP discovery requests
    are handy for this scenario.

 2) those with a "plug and play" approach to machine deployment;
    new machines can be racked and booted, and the infrastructure
    doesn't need prior knowledge of the boot parameters for
    individual machines (however, machines can register themselves
    as part of the initial provisioning).

    The "default" discovery requests are handy for this scenario, but
    *only if* you have a homogeneous set of machine architectures (so
    the one boot configuration suits all machines).  Hence, the arch-XXX
    requests to allow this.

I don't foresee these two scenarios being mixed in a way that requires
combining the orthogonal behaviours. Perhaps someone will use arch-XXXX
for machine provisioning & self-registration (which generates a
machine-specific conf file named by UUID), and then UUID for subsequent
boots, but that's still a separate boot process.
> The final option is to introduce macros that can be used in an
> include statement, so the file fetched would be a generic config file
> which can include others based on all kind of parameters, making most
> of the discovery junk unnecessary.  It also lets the sysadmin keep
> the common bits common.  Personally this is the option I like the
> best.  iPXE has been doing this for years.
That sounds good, but arch-XXX is a fairly unintrusive change to the
process (ie, doesn't require any changes to the config syntax & parser
implementations). Would you expect other loaders to implement the
includes (and parameterisation)? That would definitely be possible to
implement in petitboot, but I do have the luxury of a full flex/bison
parser :D

I've just been digging through u-boot, and it looks like they request
"default-<arch>" (and possibly
"default-<arch>-<board>") already. The
difference being that <arch> isn't a well-defined name (it's just
a
string defined by uboot). I'd prefer to use the IANA identifiers, and
will still submit the arch-XXXX patch to them for feedback, but that's
not crucial.

Cheers,


Jeremy

Hi Gene,
>> What I'm looking to do here is establish a bit of a convention for
>> allowing machines of multiple architectures to be perform PXE
>> configuration in a uniform way (in this case, without requiring the
DHCP
>> server to send out different lease parameters in response to the
>> client's DHCP architecture ID).
> 
> How do you have multiple architectures booting from the same directory
> at this time?  What exact string is used by network boot clients of
> each of the three architectures?
This is only in-development at this stage, so I only have this going in
a virtual environment. I have machines of separate architectures (x86
PC-BIOS and PowerPC OPAL) booting from the same directory of pxe
configuration files:

 /pxelinux.cfg/arch-0000
 /pxelinux.cfg/arch-000e

The arch-0000 file is being used by for the x86 machines running
pxelinux, and arch-000e for the powerpc machines running petitboot.

Cheers,


Jeremy