Can someone please outline exactly what is broken with the current x86 PXE approach? We worked very hard to minimize the required configuration as much as possible and I was under the impression that this was largely successful, particularly when compared to SPARC wanboot.
Jan Damborsky wrote: > Hi Jan, > > > Jan Setje-Eilers wrote: >> >> What you're proposing won't do anything for the customer. They are >> putting up with the pain that is wanboot in order to get end-to-end >> authentication and encryption. Putting PXE with tftp in front of it >> invalidates the entire exercise and only adds pain and expense. > > the another consumer which is being considered is network hands-off > OpenSolaris installer (Automated Installer project). > > The problem we are trying to solve in that area (scope limited > to Automated Installer only) is > > * minimize need for configuring things using DHCP server > (as customers complain they often don't have access to it > and need to ask IT admins for any change in that area) So you're looking at SPARC wanboot to improve over what we did with x86 PXE???? I'm probably being impolite, but I really don't follow the logic that involves exposing a large number of vendor specific keys in order to simplify something that currently involves two keys (BootSrvA and BootFile, both standard keys). I recently extended this further allowing BootFile to be inferred. This means there's a single key, BootSvrA; the IP to boot from that needs to be supplied to allow a system to PXE boot. How exactly will adding a wanboot shim simplify this? > * allow implementation of more flexible algorithms with respect > to which microroot is picked up for particular client. In current > implementation, set of criteria DHCP server can use for making > decision about which GRUB menu (with information about which > microroot will be loaded) will be provided to pxeGRUB are limited. > > * consolidate Sparc and x86 boot process as much as possible We've largely done this. The process is ultimately initiated by the firmware which differs dramatically. We can abstract much of this in the deployment tool chain, but it's never going to have the same implementation. We can layer arbitrarily, but there's no win there as the first layer that is firmware dependent can not be removed. > These are the reasons why we were considering to introduce another > level of network boot process - pxeGRUB would chainload wanboot-like > variant for x86 which would then negotiate with install server > which microroot should be picked up and loaded during following > boot stage. Then Why? This only makes things more complex, go slower, adds more stuff for us to maintain and more stuff to be configured. > * DHCP setup would be simple for common scenario - only one > NBP+menu.lst for x86 - need to setup things on DHCP server > only once We have this today with PXE on x86. Please explain how we don't. > * Automated installer can implement different mechanisms for determining > which microroot should be picked up based on set of information client > would collect and send to server Why do we need wanboot for that? This happens today, keyed off the mac address of the host, which on the server side can trivially be translated into an IP and hostname. Once the loader it up, it can supply any number system specific data. We do this today for isa (i86hvm, i86pc and amd64 or not) and memory size as well as a couple of other things and are more than willing to extend this as needed. > * the same approach might be used for both x86 and Sparc What we need to do is simplify SPARC, not add complexity to x86. -jan > Thank you, > Jan > >> >> What they need is boot integrity services (BIS) on top of PXE. It's >> TPM'ish but basically allows a signature of the downloaded NBP and >> payload (in our case the microroot) to be computed and validated. >> >> I suppose if you wanted to build on the reputation that wanboot has >> earned, you could call and implementation of BIS for Solaris PXE boot >> wanboot on x86, but I'm going to suggest that that is counter productive. >> >> -jan >> >> Sundar Yamunachari wrote: >>> Jan, >>> >>> We were talking about wan boot support for X86. One of the >>> suggestion was to load wanboot binary after loading pxegrub in X86. >>> You and I had similar conversation last week. We would like to know >>> what are the issues with loading something like wanboot binary on to >>> the X86 system and make it work very similar to SPARC wan boot? Can >>> we meet and talk about this topic? >>> >>> Thanks, >>> Sundar >>> >>> -------- Original Message -------- >>> Subject: [Fwd: wanboot of x86 clinet] >>> Date: Fri, 05 Jun 2009 09:02:15 +0200 >>> From: Jan Damborsky <Jan.Damborsky at Sun.COM> >>> To: Sarah Jelinek <Sarah.Jelinek at Sun.COM>, Susan.Sohn at Sun.COM, >>> Ethan Quach <Ethan.Quach at Sun.COM>, Sundar Yamunachari >>> <sundar.yamunachari at Sun.COM> >>> >>> >>> >>> It is interesting that that we touched that topic >>> yesterday :-) It seems there might be customers >>> interested in x86 wanboot support. >>> >>> Jan >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> Subject: >>> wanboot of x86 clinet >>> From: >>> Peter ?str?m <Peter.Astrom at Sun.COM> >>> Date: >>> Thu, 04 Jun 2009 16:16:16 +0200 >>> To: >>> wanboot-interest at sun.com, jet-interest at sun.com >>> >>> To: >>> wanboot-interest at sun.com, jet-interest at sun.com >>> CC: >>> Peter ?str?m <Peter.Astrom at Sun.COM> >>> >>> >>> Hi >>> A Bank Customer is using JET wanboot on SPARC and want to use the >>> same installation routine for x86. For security reasons they are not >>> allowing nfs in the network. >>> I know that pxe boot don't support wanboot. >>> But is it possible to do a wanboot installation of an x86 system??? >>> With help of grub?? >>> If not, are there any plan to fix this?? >>> >>> Best Regards >>> Peter ?str?m >>> Sun Sweden >>
