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?
-Kyle
> Regards,
> sarah
> ****
>>> -Kyle
>>>
>>>
>>> I'd even suggest that if GRUB is the prefferred way to pass this
>>> stuff to the kernel, then maybe GRUB should do the lookup of this
>>> info? This would support diskless clients also wouldn't it, since
>>> the rootfs could be configured this way?
>>>
>>
>> Let's be clear: there is no plan to use GRUB on SPARC; the
>> newboot-sparc project uses a boot archive, but not GRUB.
>>
>> Thanks for the requirements list, I'm sure Sarah will take it into
>> account.
>>
>> Dave
>> _______________________________________________
>> install-discuss mailing list
>> install-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/install-discuss
>>
>>
