Hi Jan,
Jan Setje-Eilers wrote: > > > Can someone please outline exactly what is broken with the current x86 > PXE approach? As far as I am aware of, nothing is wrong with PXE per se :-) My apologies if it was indicated by this discussion - this was not the intent. > 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. It seems like using 'wanboot' in context of this discussion might have inappropriate connotations - let me try to explain scope of the problem without referring to 'wanboot' technology. In legacy jumpstart technology, in order to make install server aware of particular client, per client setup is required - client is identified by its MAC address and appropriate client specific DHCP macro along with appropriate menu.lst.01<macid> is created - it contains information about the install environment used for the installation (kernel,miniroot, ...) and where to find installation parameters (sysid_config, install_config, ...). There are some limitations with this approach. It is not flexible, as when clients are being added, removed, appropriate changes have to be done on DHCP server and menu.lst files. It doesn't scale very well - when bunch of new clients are added, per client setup is required for each of them. Clients can't be grouped by set of criteria they share (e.g. similar functionality xvm Ops center provides). It is problematic when user which would like to configure installation for particular clients doesn't have control over DHCP server. There are constraints how client could be identified to the server for determining which installation environment (kernel, microroot, user archives, configuration files) will be used for particular client - client is identified by MAC address. With Automated installation project, we are thinking if we could mitigate some of those issues. Different model is being considered where all pieces necessary to deploy particular group of machines will be encapsulated and treated as one entity called 'install service' - it is assumed to encompass at this point: * installation environment (kernel, microroot, other archives) * installation configuration files On install server, it would be possible to create groups of clients served by particular install service. Group would be identified by set of criteria client can provide during boot process (e.g. system architecture, mac, ip, memory size, list of recognized hard drives, ...). 'Ranges' and 'wildcards' would be supported. On install client, 'service discovery engine' would be run as early as possible for determining which install service should be used by particular client. Then one of the considered scenario might be that during boot process, * NBP would load and launch 'service discovery engine' provided by install server * install client would collect all information and send it to the install server * install server would determine appropriate group client belongs to and would provide client with appropriate install service * install client would boot kernel & microroot defined by that install service * the whole decision making process is assumed to be run on install server * DHCP server would provide only necessary configuration - for x86 - IP address - location and name of NBP - name of menu.lst which would only contain location of 'service discovery engine' > > > 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? To be honest, maybe I misunderstood what all falls under wanboot technology - it seems we would need only utilize small portion of this. Sparc vendor specific options will not be used by Automated installer. In current prototype, the only DHCP option which needs to be created for Sparc is BootFile - it is set to URL locating wanboot-cgi script, e.g. BootFile=http://192.168.100.1:5555/cgi-bin/wanboot-cgi Sparc client then obtains boot file and appropriate wanboot configuration (contains location of microroot with kernel) for install server using http protocol - it uses GET method: GET http://<install_server>:<port>/cgi-bin/wanboot-cgi/?CONTENT=bootfile&IP=192.168.100.0&CID=010003BAFB20C1 What is actually send to the client can be fully controlled by install webserver - it depends on what CGI script allows. Apparently there are limitations with current implementation - only IP address and mac are send by client to the server. But those limitations could be addressed - In this first step install server would send similar 'service discovery engine' as mentioned above which would collect more data and obtain the install service in the same way as described for x86. > > >> * 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. Agreed. > > >> 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. Please see above. > >> * 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. I was assuming in this point that DHCP server has to be accessed each time client configuration changes (client specific macros have to be added/removed). If this is not required, it would at least mitigate the problem with limited access to DHCP server. > > >> * 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. In current proposal, it is assumed that install server will decide which install service (kernel, microroot, ...) will be provided to the client based on the set of criteria client sends. In current PXE implementation, is it possible to send the information to the server and let it determine which kernelµroot will be loaded by the client ? Thank you, Jan > >> * 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 >>> >
