Dave Miner wrote:
> Kyle McDonald wrote:
>> Sarah Jelinek wrote:
>>> Hi all,
>>>
>>>
>>>> Kyle McDonald wrote:
>>>>
>>>>> Dave Miner wrote:
>>>>>
>>>>>> Anyway, that's the history as best I remember. Sarah is in the
>>>>>> early stages of investigating what we'll do for automated
>>>>>> installs in Caiman. I'm sure she'll take the input into account
>>>>>> and we'll of course have quite open discussion of the proposal
>>>>>> when formulated. I'm not at all opposed to leveraging DHCP more
>>>>>> fully (it was my primary job for 5+ years, after all), but we as
>>>>>> always have to be pragmatic about where we put Sun's resources.
>>>>>>
>>> Yep, this is the plan. I will send out a proposal when I am ready
>>> and I am sure we will have a lot of discussion.
>>>>>>
>>>>> Thanks Dave!
>>>>>
>>>>> I understand that resources are limited. And if it needed to be
>>>>> developed fresh, i can see where it'd be not worth the effort. I
>>>>> just didn't understand why, with the code there and functioning,
>>>>> it would need to be removed. Precedence is one reason. I don't
>>>>> know how big a job that would have been.
>>>>>
>>>>> Truely, I'm surprised that the SPARC side needs the dhcp in 'boot
>>>>> net - install dhcp' since I would think that if bootparams failed
>>>>> then DHCP could be tried next. Or the otherway around.
>>>>>
>>>>> While I understand that groups maintianing the DHCP servers may
>>>>> not be interested in adding or setting Solaris options, is there
>>>>> anything specific about the Sun vendor options that makes them
>>>>> incompatible with the other DHCP servers out there?
>>>>>
>>>>
>>>> No, vendor options we have are very vanilla, however vendor options
>>>> are not widely used and thus many DHCP administrators are
>>>> unfamiliar with how to set them up.
>>>>
>>>>
>>>>> And If Sarah's listening, I'm not stuck on DHCP:
>>>>>
>>> I am listening.
>>>
>>>>> What I want is one place (NIS,NIS+,LDAP,DHCP,BOOTPARAMS or
>>>>> Something New,) to configure *ALL* the information for a network
>>>>> boot client.
>>>>>
>>>>> It should be the same for X86 and SPARC
>>>>>
>>>>>
>>> Agreed.
>>>
>>>>> Preferrably, it would not be stored on the client itself (not in
>>>>> OBP on SPARC.) Though that could be another option.
>>>>>
>>>>> It shouldn't require me to repeat/update the same info for every
>>>>> client over and over again, like I showed with my DHCP macro's in
>>>>> the previous Post. or maybe something a little more sophisticated
>>>>> than the '*' wildcard in bootparams?
>>>>>
>>>>> It should scale, and leave a managable configuration even when
>>>>> 100's or 1000's of clients are configured.
>>>>>
>>>>>
>>>>>
>>>>>
>>> All good suggestions.
>>>
>>>>> As a slightly related suggestion, I would like to see GRUB
>>>>> (especially if it is to appear on SPARC) expanded to be more like
>>>>> OBP. Possibly by storing what is in bootenv.rc now in menu.lst,
>>>>> or by referencing from there. the GRUB command line could be
>>>>> extended so that X86 could have something like 'boot net -
>>>>> install', or more importantly (if GRUB could read and use the
>>>>> contents of bootenv.rc) Solaris could actually make (the on disk
>>>>> GRUB - not PXEGRUB) honor a 'reboot -- 'net - install'' by
>>>>> automatically editing bootenv.rc before rebooting.
>>>>>
>>>>>
>>> Ok.
>>>
>>> All good thoughts. I am listening and will take this in to account.
>>> Thank you for taking the time to articulate your thoughts.
>>>
>> Thanks for reading.
>>
>> I thought of one more.
>>
>> Whatever it ends up being, it should be enduser/site extensible. Like
>> DHCP I should be able to create my own 'options' or key-value pairs
>> which I can use to store informationabout how I want a machine
>> installed. The mini root should have something (like dhcpinfo) that
>> will allow me to look up my options or keys in my begin or finish
>> scripts, or outside the miniroot on first (and maybe any other) boot up.
>>
>> As I wrote the other usefull features down, and added this one, it
>> again hits me how well DHCP (and dhcpinfo) already fit the bill. I
>> know there are issues at some sites with implementing it this way,
>> but if time or resources are short for developing a replacement,
>> re-enabling the DHCP Vendor options, and making it easier to use
>> dhcpinfo on Site options from the miniroot, are probably the best bet.
>>
>> Maybe a second pass could add a second alternative?
>>
>
> DHCP seems unlikely to be our primary choice to implement as a
> generalized solution to automating system configuration during
> install. There are several reasons for this:
>
> 1. As I said before, the operational issues with relaying on DHCP are
> significant at a large percentage of sites.
> 2. DHCP has the undesirable property of a very limited payload, as
> its absolute maximum message size is 64 KB, though practically a lot
> of implementations will break as soon as you go more than an Ethernet
> MTU size (1500 bytes). There's also the issue that many have run into
> with our use of vendor options leading to overflow of the normal
> option length (255 bytes) - you have to implement RFC 3396 to support
> the concatenation that Mike mentioned in a subsequent message, which
> is something that hasn't been done in the Solaris implementation (CR
> 4867934 for those of you keeping score at home). DHCPv6 may not have
> as many of these problems, but of course that takes us into the realm
> of depending on IPv6 to become fairly ubiquitous...
> 3. Our design space for the problem needs to consider the WAN
> installation case (which likely doesn't use DHCP at all as a
> configuration delivery mechanism) as a primary requirement.
>
Dave
Thanks again for the reply.
Those are all good reasons. I only suggested that it may be an
easy(ier?) way to provide a 'quick-fix' while we wait for the final
solution. Even this as a quick-fix won't solve the problem for wan-boot
though.
I really am not married to DHCP. I find the command line administration
interface cumbersome for the simple tasks I need to do ,and the GUI
isn't much better.
You and I have discussed in the past, and I understand why the DHCP
server can't use just a text file that can easily be edited by hand.
I really look forward to something new which might offer all the
benefits described, and be more useful to everyone (especially those
using wan-boot - whic I've never tried) involved.
Looking at /sbin/install-discovery, Am I correct in thinking that changing:
if [ "${PLATFORM}" = "${SPARC}" ]; then
echo "Using DHCP for network configuration information."
dhcp_find_and_mount_cdrom
fi
to:
#if [ "${PLATFORM}" = "${SPARC}" ]; then
echo "Using DHCP for network configuration information."
dhcp_find_and_mount_cdrom
#fi
Should restore the old functionality on X86?
-Kyle
> Dave
