Ok guys,
Here's the followup I promised. In short, I liked the idea, and I
believe Bernard has done a fairly good job of recording the ideas from
our conversation. Comments and adjustments below...
Thus spake Bernard Li ([EMAIL PROTECTED]):
Hey guys:
I was talking to Brian Finley yesterday about the idea of having
first(re)boot scripts (Brian pointed out that it is actually first
_re_boot, as opposed to firstboot, so we will go with that name now).
We hashed out some ideas and I summarize them below for discussions.
Brian, if I got them wrong, please let me know.
So basically we wanted to have a set of scripts that are executed on
nodes when they are first rebooted after being imaged. This is along
the lines of pre-install and post-install scripts.
These scripts will reside in /etc/systemimager/firstreboot directory in
the image (and subsequently on the imaged node)
Yes.
and there will be a
README explaining the syntax as well as scripts with numerically ordered
names (so that they are executed in order).
Yes on the README.
Let's say, alpha-numerically ordered. Let's use the same scheme as init
script names in an /etc/rc?.d/ directory.
There will be a state file
(/var/state/systemimager-firstreboot) which will specify the state of
execution of these scripts, it will contain the last successfully
executed script in the firstreboot/ directory and thus gurantees that
each script is successfully executed and also that they won't be
executed upon each reboot.
I've been thinking about this, and I think we should go with a simpler
solution -- $0.done files. That is, after execution of a first-reboot
script, the exit code is echoed into:
/etc/systemimager/first-reboot/$scriptname.done.
This does a couple of things:
* It allows the calling init script to be less complex.
Yes, as you may have intuited, there would be a master init
script, perhaps /etc/init.d/systemimager-first-reboot that would
iterate through the execution of each of the first-reboot
scripts.
* It allows one to tell at a glance which scripts have been
executed, and which have not. If we put the .done files in a
different directory, then we lose part of this ease-of-use
feature.
* It allows one to turn certain script on or off by simply touching
a file. The test for "already been executed" will simply be,
"does $scriptname.done exist?"
* It allows one to find out if each script executed successfully by
checking the exit codes.
We didn't explicitly talked about this yesterday but I presume the user
would just drop these scripts in
/var/lib/systemimager/scripts/firstreboot and then the scripts will just
be copied to the image's /etc/systemimager/firstreboot directory.
As these will be part of the image, I believe they should be treated
in a manner consistent with any other files that are part of an image.
That is, they should be copied into the /etc/systemimager/first-reboot
directory on the golden client, prior to running si_getimage.
If you perform a get_clients operation, the state file will be removed
s/get_clients/si_getimage/ (I presume)
from the golden image but the scripts will be left intact such that they
will be executed after a node is successfully imaged.
Yes. Exactly. Except now with the change that any file in
/etc/systemimager/first-reboot in the image that ends in .done will be
removed when the image is retrieved -- before si_getimage exits.
I'm satisfied with implementation proceeding in trunk based on this
description, unless anyone thinks modifications should be made.
Cheers, -Brian
Potential uses are to report si_monitor status "rebooted" such that the
user can know when an imaged node is up and running, and potentially
used by OSCAR for doing some pre-OPM post_installation cleanup per
client for packages and such.
Hope that this is clear for everyone.
Cheers,
Bernard
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=ick
_______________________________________________
Oscar-devel mailing list
Oscar-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oscar-devel
--
Brian Elliott Finley
Mobile: 630.631.6621
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Sisuite-devel mailing list
Sisuite-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sisuite-devel
