>A bootparams parameter is a better approach rather than inventing a new >dhcp macro or overloading an exisiting one to provide this information. >That is the feedback I had gotten from Solaris NewBoot folks. Please note >that we are not using any special dhcp >macro to provide client specific information. We use the standard >solaris net installation >process to do the boot as well. Only thing new is the bootparams parameter.
I'm very much with Bill on this one: you cannot require DHCP and bootparams both; if anything, bootparams should die as it is a non-standard protocol with many shortcomings: - Bootparams doesn't work on all infrastructures - Bootparams is limited to a broadcast domain (no relaying has been defined for it); i.e., while your client gets the DHCP data from your server it may not be able to get the bootparams data from the same server. - Bootparam values need to be of the form hostname:value (which doesn't make sense for things like terminal types) - Bootparams requires rpcbind to be configured in "open" mode (broadcast RPC) Requiring bootparams in addition to DHCP is a deal breaker by itself. I'd expect to use DHCP and defined a new key (not macro) for this along the lines of: # # SunOS vendor space -- see the Solaris System Administrator # documentation for more information on these options. # SrootOpt VENDOR, 1, ASCII, 1, 0, smi SrootIP4 VENDOR, 2, IP, 1, 1, smi SrootNM VENDOR, 3, ASCII, 1, 0, smi SrootPTH VENDOR, 4, ASCII, 1, 0, smi SswapIP4 VENDOR, 5, IP, 1, 1, smi SswapPTH VENDOR, 6, ASCII, 1, 0, smi SbootFIL VENDOR, 7, ASCII, 1, 0, smi Stz VENDOR, 8, ASCII, 1, 0, smi SbootRS VENDOR, 9, UNUMBER16, 1, 1, smi SinstIP4 VENDOR, 10, IP, 1, 1, smi SinstNM VENDOR, 11, ASCII, 1, 0, smi SinstPTH VENDOR, 12, ASCII, 1, 0, smi SsysidCF VENDOR, 13, ASCII, 1, 0, smi SjumpsCF VENDOR, 14, ASCII, 1, 0, smi Sterm VENDOR, 15, ASCII, 1, 0, smi SbootURI VENDOR, 16, ASCII, 1, 0, smi SHTTPproxy VENDOR, 17, ASCII, 1, 0, smi I was under the impression bootparams was pretty much dead (except for legacy use) and I have not seen new bootparams defined for a while. Of course, if you also want to support bootparams boot then that is fine, but that should only be in addition to DHCP boot. And I don't think it's a requirement to support bootparams. Casper
