To add to that, I've known of a few bugs in Solaris in the past which required tweaking PRIOR to first reboot to allow the machine to even be able to boot. Removal of the ability to call a finish script to do this work stops a workaround from being able to be quickly deployed.
(As an example, I've been seeing an error where sometimes the boot-archive on a just built system is out-of date on first reboot, I've now got a finish script that runs update-archive (possibly gratuitously) before the first reboot. ) This is just an example, but I'm sure you all will agree that no code is bug free. NOT having begin or finish script hooks, simply stop us from being able to interpose and workaround those bugs prior to an official fix being available. Mike Dotson wrote: > On Wed, 2009-03-25 at 19:03 -0700, Bart Smaalders wrote: >> Mike Dotson wrote: >>> On Wed, 2009-03-25 at 18:15 -0700, Bart Smaalders wrote: >>>> Frank Fitch wrote: >>>> >>>>> If you want folks to use your tool, you have to make the tool usable. An >>>>> install tool without the ability to completely customize installs is >>>>> like a race car without wheels. Sure, it looks real pretty, and may in >>>>> theory be the best car in the race. But it probably won't win. >>>> Why can such customizations not wait until during first boot? >>> lest we forget the telnet worm.... >> Telnet is enabled in single user mode? > > Nope but are your customizations going to be in single user? > >> If you wait to complete your customizations until first boot, >> the range of possible operations becomes much larger. You're >> no longer constrained by whatever binaries are part of the boot >> image, whatever OS version was used to install your software, >> etc. > > So that would mean after single user mode and network startup? Uhh-ohh, > wouldn't that mean telnet is now enabled prior to post boot > customizations to disable it? Or would I now need multiple packages and > smf services.... > >> The workaround for the telnet worm was to >> >> 1) install a patch. In IPS there is no distinction between >> packaging and patching operations; if there's a fix available >> in your install repo you'll get it. > > sure after days of exposure and it took two patches to get it right if I > remember correctly and the key phrase in you statement above is "if > there's a fix available"... > > Original fix/workaround was to disable telnet service then clean up your > system and patch available a day or so later... > >> or >> >> 2) disable the telnet service. A SMF profile that disables >> telnet could be installed, or a script could be run early on >> to disable the service. It's quite possible to have the >> capability to run finish scripts in AI; we want these >> installed on the system and run during boot instead of >> run after package installation. > > Or copy site.xml into place prior to the install that way it's done upon > manifest import - surely we have cp available and would be a much > simpler solution, yes? > > Also, I'm betting you probably haven't sat in front of big iron in a > while - say 25k domains that take shy of hours to boot. Perhaps you're > missing the other side of the equation... our customers. What is the > cost of a down system in lost revenue due to wages of contractors > waiting for a system to boot? > > If I configure the system ready to go post install boot, that's one > reboot. If I configure after the first reboot, I'm looking at another > reboot. Sometimes it's not about the technology but the price of that > technology. > > To play devils advocate, why not allow me begin/finish scripts? Good > examples please, like the ones we've provided for having begin/finish > scripts. And adding complication by creating a package that will > install an SMF service to run scripts (that I already have working) to > then have to add a script crafted to remove said package and service > once completed is not really a good reason. > > Also, how are you going to allow me to raidctl my boot disks prior to > install by doing it after install? Do I have to do two installs now? > More than just another reboot time there.... > > What about removing bogus fdisk labels or deleting linux swap partitions > or crafting x86 fdisk partitions with alternate partition numbers, > dealing EFI disks that usually choke the installer? > > What about changing the x86 active partition to something else other > than where it's currently pointing prior to install so I don't clobber > other system boot loader? Can't really do that after the fact now can > we? > > I'm all for revamping the install environment to make it easier and add > functionality but it doesn't look like it's any easier and we're > actually loosing functionality and worse, we're loosing the ability of > functionality for things that we haven't even invented yet. > >> - Bart >> -- Mike Ramchand Principal Field Technologist Systems Practice Sun Microsystems (UK) Tel: +44 125 2421091, Ext: (70)21091, Mob: +44 780 1179593 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature URL: <http://mail.opensolaris.org/pipermail/desktop-discuss/attachments/20090326/67e179f3/attachment.bin>
