Jan,

[5] mentions ISC DHCP servers are a supported configuration,
but in [8] the statement is unclear.

Is it possible to define the SUNW* vendor specific options on an
ISC DHCP server?


thanks,
-ethan


Jan Damborsky wrote:
> Hi Caimaniacs,
>
> As part of install service redesign project, the following problem
> was identified and captured below along with investigation done and
> proposed high level approach how to address it.
> Please yell with questions/comments :-)
> The outcome of this discussion will be reflected in install service
> functional specification.
>
> Thank you,
> Jan
>
>
> [1] Problem statement
> ---------------------
> Boot AI client from network in deterministic way in heterogeneous
> client environment using DHCP without need for client specific setup.
>
> [1a] Current state
> ------------------
> In current implementation, if both Sparc as well as x86 AI clients
> are configured to be served by one DHCP server without creating
> per client DHCP configuration, unpredictable behavior can occur.
> x86 client can be provided with Sparc NBP or vice versa based on
> the order of configuration steps accomplished.
>
> [2] Scope of the problem
> ------------------------
> Only early stage of network boot process which serves for obtaining
> NBP is covered here as this is where x86 and Sparc share the boot
> mechanism and where undeterministic behavior could occur.
> Once NBP is obtained, different subsequent boot mechanisms are used by 
> x86
> and Sparc.
>
> For x86, PXEgrub downloads GRUB menu.lst file containing information
> about what to boot in the next stage.
>
> For Sparc, wanboot-cgi script locates wanboot.conf file containing
> the similar set of information.
>
> [3] Definition of terms
> -----------------------
> NBP
> - network bootstrap program
> - PXEgrub for x86, wanboot-cgi for Sparc
>
> heterogeneous client environment
> - both Sparc & x86 clients are present
>
> AI environment
> - everything which is necessary to allow AI client to be successfully
> deployed using Automated installer - e.g.
> - DHCP server
> - TFTP server
> - AI server providing AI images, install services, AI manifests
> to AI clients using HTTP protocol
> - ... ?
>
> heterogeneous AI environment
> - parts of AI environment are deployed across
> different platforms - e.g. DHCP server running on Linux
> AI server running on Solaris 10
>
> per client scope
> - applies to AI clients with client specific setup
>
> general scope
> - applies to AI clients without client specific setup
>
> [4] Requirements
> ----------------
> * AI network boot process has to be deterministic
> * AI network boot process has to work in heterogeneous environment
> without need for client specific setup
> * AI boot process can be configured in heterogeneous AI environment
> - modification of shared pieces (existing DHCP server in this case)
> will be supported and will be as less intrusive as possible
>
> [5] Supported configurations
> ----------------------------
> * local/remote Sun DHCP server deployed on OpenSolaris & Solaris 10
> * local/remote ISC DHCP server deployed on OpenSolaris, Solaris 10, Linux
>
> [6] Feasibility study
> ---------------------
> The purpose of technical feasibility study is to do initial research
> if technologies to meet the functional requirements exist.
>
> [6.1] Constraints
> -----------------
> Constraints are determined by the existing technologies AI has to plug 
> into.
>
> client side:
> * PXE boot for x86 and early stage of DHCP net boot for Sparc.
>
> server side:
> * DHCP server
>
> [6.2] AI client identification
> ------------------------------
> In order to provide client with correct NBP, client has to identify 
> itself
> to the DHCP server in some way. For the time being, following information
> are passed as part of DHCPDISCOVER message which initiates DHCP 
> handshake:
>
> x86 PXE client (see [1] for more details):
> * MAC address
> * UUID
> * system architecture (DCHP option 93 - e.g. 0 for x86)
> * class identifier (DHCP option 60 string:
> "PXEClient:Arch:xxxxx:UNDI:yyyzzz,
> "PXEClient:Arch:00000:UNDI:002001" is the only known to be implemented
> for the time being)
> * ...
>
> Sparc:
> * MAC address
> * class identifier (DHCP option 60 string: "SUNW.*", e.g.
> "SUNW.Sun-Fire-v210")
>
> Based on this observation, it seem that there is a way to meet
> the functional requirements taking existing constraints into account:
>
> * per-client scope
> identify client on DHCP server by MAC address
>
> * general scope
> distinguish between x86 & Sparc client architecture by
> inspecting client class identifier string
>
> [7] Proposed high level solution
> --------------------------------
> Set up DHCP server, so that NBP correctly matching client platform
> will be selected by inspecting client class identifier provided by
> particular AI client.
>
> [8] Deliverables
> ----------------
> * define DHCP server configuration parameters for supported DHCP
> server implementations for per-client scope and general scope
> (e.g. format of client class identifier macros for SUN DHCP server
> and how they will plug into whole DHCP server configuration)
>
> [9] Related problems/interdependencies
> --------------------------------------
> * installadm redesign
> - mechanism/API for obtaining valid up-to-date list of client
> class identifiers for Sparc platform
> - mechanism for local/remote update of supported DHCP server
> implementations
>
> * following stages of boot and process of establishing working AI
> client install environment
>
> [10] Related documentation
> --------------------------
> [1] Preboot Execution Environment Specification v2.1
> http://download.intel.com/design/archives/wfm/downloads/pxespec.pdf
>
> [2] PXE Wiki
> http://en.wikipedia.org/wiki/Preboot_Execution_Environment
>
> [3] Setting up PXE netboot for x86 clients
> http://www.riddleware.com/solx86/PXE/pxe-netboot.html
>
> [4] Supported AI scenarios and use cases
> http://www.opensolaris.org/os/project/caiman/auto_install/ai_svs_redesign_scenarios.txt
>  
>
>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss

Reply via email to