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. 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 > >
