Hi Ethan,
Ethan Quach wrote:
> 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?
So far it seems that we wouldn't need to deal with vendor specific
options. The proposed solution assumes taking a look at string
sent by client to DHCP server as DHCP option 60 (vendor class identifier)
For Sun DHCP server, it would mean to create bunch of client class macros -
one for each client class.
ISC DHCP provides more flexible matching algorithms, e.g.
it is possible to match for substring, something like
class "ai_x86" {
match if substring (option vendor-class-identifier, 0, 9) ="PXEClient";
filename "pxe_grub";
}
class "ai_sparc" {
match if substring (option vendor-class-identifier, 0, 4) ="SUNW";
filename "http://192.168.100.2:5555/cgi-bin/wanboot-cgi";;
}
Thank you for your comments !
Jan
>
>
> 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
