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
