[ipxe-devel] PXE in a large corporate environment

[Mark.Bannister at rbs.com]

Hi Michael,

This is all very interesting, thank you.

How much of what has been implemented in iPXE is compliant with the exact wording of PXE-2.1, and how much of it is an extension that isn't really covered in any specification but was introduced separately during the Etherboot/gPXE/iPXE lifecycles?  I ask this because, as you know, PXE-2.1 is not an open standard, it's an Intel copyrighted spec that hasn't changed since 1999.  Intel are focused now on UEFI PXE, which I'm already learning through discussions with them has its own set of stumbling blocks to adoption (such as requiring 64-bit types).

Do you think that ultimately, iPXE will have to move away from PXE-2.1 and embrace a new standard?  And what will that standard be?  UEFI PXE?  Or something else?

Will vendors with gPXE firmware be looking to move to iPXE, and do you think they see this as a long-term proposition or an intermediate one until UEFI PXE becomes more viable?

Regards,
Mark.

-----Original Message-----
From: Michael Brown [mailto:mbrown at fensystems.co.uk] 
Sent: 18 April 2011 13:22
To: ipxe-devel at lists.ipxe.org
Cc: Bannister, Mark, GBM
Subject: Re: [ipxe-devel] PXE in a large corporate environment

On Monday 18 Apr 2011 12:39:45 Mark.Bannister at rbs.com wrote:
> I posted some suggestions for improvement to the PXE specification to 
> the  DHC mailing list earlier this month:
> 
> http://www.ietf.org/mail-archive/web/dhcwg/current/msg11581.html
> 
> I'm interested to know if the problems I'm trying to solve can be 
> addressed  in iPXE?

Several of them can be addressed quite easily.

The system UUID is already transmitted by iPXE (and by any compliant PXE
client) in both DHCPDISCOVER and DHCPREQUEST.

The "PXE environment" field that you describe is functionally equivalent to the DHCP user class, which is already supported by iPXE and by most DHCP servers.  
For example: in iPXE:

  iPXE> set user-class fileserver
  iPXE> autoboot

and in /etc/dhcpd.conf

  if option user-class = "fileserver" {
    ... boot options for "fileserver" class of machines ...
  }

Both ISC dhcpd and the Microsoft DHCP server already support per-user-class configuration, so there would be no additional programming required.

On network cards that support non-volatile stored options, you can configure the user class semi-permanently using either the "config" UI, which is
(partially) documented at

  http://ipxe.org/cmd/config

or using the command line:

  set net0.nvo/user-class fileserver

Another possibility is to use values extracted from SMBIOS, such as the system asset tag, e.g. by setting the boot filename to

  http://boot.server.name/boot.php?asset=${asset}

Michael

*********************************************************************************** 
The Royal Bank of Scotland plc. Registered in Scotland No 90312. 
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. 
Authorised and regulated by the Financial Services Authority. The 
Royal Bank of Scotland N.V. is authorised and regulated by the 
De Nederlandsche Bank and has its seat at Amsterdam, the 
Netherlands, and is registered in the Commercial Register under 
number 33002587. Registered Office: Gustav Mahlerlaan 10, 
Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and 
The Royal Bank of Scotland plc are authorised to act as agent for each 
other in certain jurisdictions. 
  
This e-mail message is confidential and for use by the addressee only. 
If the message is received by anyone other than the addressee, please 
return the message to the sender by replying to it and then delete the 
message from your computer. Internet e-mails are not necessarily 
secure. The Royal Bank of Scotland plc and The Royal Bank of Scotland 
N.V. including its affiliates ("RBS group") does not accept responsibility 
for changes made to this message after it was sent. For the protection
of RBS group and its clients and customers, and in compliance with
regulatory requirements, the contents of both incoming and outgoing
e-mail communications, which could include proprietary information and
Non-Public Personal Information, may be read by authorised persons
within RBS group other than the intended recipient(s). 

Whilst all reasonable care has been taken to avoid the transmission of 
viruses, it is the responsibility of the recipient to ensure that the onward 
transmission, opening or use of this message and any attachments will 
not adversely affect its systems or data. No responsibility is accepted 
by the RBS group in this regard and the recipient should carry out such 
virus and other checks as it considers appropriate. 

Visit our website at www.rbs.com 

***********************************************************************************