Sean McGrath stated: < Dave Miner stated: < > Sean McGrath wrote: < >> jan damborsky stated: < >> < Hi Sean, < >> < < On 03/02/09 16:16, Sean McGrath wrote: < >> < < jan damborsky stated: < >> < < Currently, when Automated Installation is done, it waits for user < >> < to manually reboot the system. There is a desire to support < >> < automatic reboot feature, so that the overall process of the < >> < installation might be hands-off. This requirement is tracked < >> < by bug 6556. < >> < < In order to provide end user with possibility to automatically < >> < reboot machine after AI is done, I am thinking about approach < >> < described in proposal below. < >> < < Please let me know, if you think it should be modified or < >> different < >> < approach should be taken. < >> < < Thanks Jan, looks good. < >> < < Thanks a lot for looking at this ! < >> < < This will be a step towards fully automated < >> < and configured installs - just needing the pre/post install 'script' < >> < features next :) < >> < < To be honest, I am not sure what you mean by pre/post install < >> 'scripts' - < >> < could you please elaborate more on this and what kind of problem you might < >> < need to solve ? < >> < >> Theses pre/post install 'scripts' are akin to the pre/post install < >> scripts of jumpstart - listed in a rules file. They get run before < >> the installer starts and another script after the installer finishes, < >> after this second 'finish' script is done the installer then reboots < >> the machine. < >> < >> Eg, we (perfpit) use a finish script to kick off installing our benchmark < >> harness, the benchmarks and running them. < >> < > < > 1. Installing the benchmark harness and benchmarks should be done using < > pkg operations, like all of the other software, not using scripts. Where < > are you at in converting those to IPS? < < We've our own internal discussion around our harness, looking to have < a small IPS repo where theres a small package to install - this then < would bring over the harness/benchmarks etc. In effect this pacakge < may simply install either a SMF service or a script to /etc/rc3.d. < < > < > 2. Running the benchmarks would seem to be a post-reboot task, not a < > post-installation task. I don't see how scripting in installation < > context is required for this. < < The above is just an example scenario, taken from what we do today. < < > < > < >> Customers use finish scripts to setup a box to be a webserver say, in < >> amongst a bank of similar installed boxs to be used as a rack of webservers < >> for load balancing. < >> < > < > Those should be cases of installing packages. Perhaps even < > pre-configured images in the manner of Flash. Install-time scripting? < > Not so clear. < > < > < >> So while this auto-reboot feature is good and what we're asking for, < >> its part of the whole 'fully-automated, hands free' net install + < >> kick < >> off running type scenario we're used to. < >> < > < > As we say in similar discussions about IPS, some adjustment of < > expectations seems to be in order. When all you had was a fairly < > minimally capable installation framework that was closed source, plus < > scripting, the answer to everything was "write a script". At the < > moment, I would like bugs filed for specific functions that are needed < > which might be commonly implemented as part of the installer framework. < > We're a *long* ways from deciding to implement what you suggest below; < > the cases presented so far are not compelling. < < I think I have the idea. Whereby a method is desired to perform < some actions at a given time during install. This 'method' and < associated actions could be custom defined by whoever is doing an install. < < We shoudl try perhaps and stay clear of older jumpstart lingo since we're < in a new space here. < < I'll log a new RFE on this for discussion.
logged: 7072 Enhancement of AI to perform actions via some method at times during install http://defect.opensolaris.org/bz/show_bug.cgi?id=7072 Sean. . < < Regards, < Sean. < . < > -- Sean. .
