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.
Regards,
Sean.
.
>
> Dave
>
>> Would it be possible for instance to have such an action enabled in AI ?
>>
>> Example (off the head), a new AI element:
>>
>> <optional>
>> <element name="ai_post_install">
>> <attribute name="url">
>> <text/>
>> </attribute>
>> </element>
>> </option>
>>
>>
>> possibly used like:
>>
>> <ai_post_install>
>> <url="http://$server/path/to/post/install/script"/>
>> </ai_post_install>
>>
>> (my xml isn't too good, apologies :)
>>
>> auto-installer could then grab and run this script before rebooting.
>>
>> In the future we could envision using the current method of choosing
>> a manifest for a client, and using that method to choose such scripts.
>> (the current method involving gathering some hw info, sending that to
>> the service on the install server and recieving a manifest in return)
>>
>> - some QE groups have a pre-install script which looks at the hardware
>> and builds a jumpstart profile from it (I think).
>>
>> - even the ability to add custom AI elemnets could be seen ?
>>
>> Regards,
>> Sean.
>> .
>> < < Thank again !
>> < Jan
>> < < Regards,
>> < Sean.
>> < .
>> < < Thank you very much,
>> < Jan
>> < < < [1] introduce new element in AI manifest
>> < < ...
>> < <optional>
>> < <element name="ai_auto_reboot">
>> < <data type="boolean"/>
>> < </element>
>> < </optional>
>> < ...
>> < < It would be optional - if not specified, machine would not reboot.
>> < < [2] If 'ai_auto_reboot' option is provided and set
>> < to 'true', AI would 'touch' file in /tmp/ directory
>> < as indicator that auto reboot should take place.
>> < < [3] Reboot in AI SMF service
>> < < Reboot itself would be done from auto-installer SMF method as the
>> < last action - after AI engine is done and only if it returned success
>> < (in order to allow user inspect log files in case installer failed,
>> < since they might be unaccessible after reboot):
>> < < SMF AI start method (/lib/svc/method/auto-installer):
>> < < ...
>> < # Invoke AI engine to install the machine
>> < $AI_ENGINE -p $AISC_MANIFEST
>> < ret=$?
>> < < if [ $ret -eq 0 ] ; then
>> < echo "Automated Installation finished successfully" > /dev/msglog
>> < if [ -f "$AUTO_REBOOT" ] ; then
>> < echo "Machine will be rebooted now" > /dev/msglog
>> < /usr/sbin/reboot
>> < else
>> < fi
>> < else
>> < fi
>> < < _______________________________________________
>> < caiman-discuss mailing list
>> < caiman-discuss at opensolaris.org
>> < http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>
>
--
Sean.
.
