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:[email protected]] Sent: 18 April 2011 13:22 To: [email protected] Cc: Bannister, Mark, GBM Subject: Re: [ipxe-devel] PXE in a large corporate environment On Monday 18 Apr 2011 12:39:45 [email protected] 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 *********************************************************************************** _______________________________________________ ipxe-devel mailing list [email protected] https://lists.ipxe.org/mailman/listinfo/ipxe-devel
