CentOS - Dec 2005 - Post postinstall configuration

I'm building kickstart files for use in doing automated installs of
various systems.  I would prefer to do fairly minimal amounts of work
in the "%post" and postpone further installation and configuration
until after the first reboot (or even later).  It should be easy
enough to add something to rc.local that will download scripts and run
them, but I'm wondering if there is a preferred technique.  I haven't
found anything in the Red Hat documentation I've read so far.

This isn't about figuring out a way to do the update, it's about
trying to follow the "Law Of Least Astonishment".  I've dealt with
too
many really screwed up systems that had customised stuff everywhere
and nothing worked as expected.

Suggestions?

-- Matt

Matt Lawrence <a400hz at gmail.com> wrote:
> I'm building kickstart files for use in doing automated
> installs of various systems.  I would prefer to do fairly
> minimal amounts of work in the "%post" and postpone further
> installation and configuration until after the first reboot
> (or even later).  It should be easy enough to add something
> to rc.local that will download scripts and run them, but
I'm
> wondering if there is a preferred technique. 
> I haven't found anything in the Red Hat documentation I've
> read so far.
Read up on the Red Hat "Setup Agent" aka "firstboot".

There is a "firstboot" init script (e.g.,
/etc/init.d/firstboot) that looks for select files (e.g.,
/etc/sysconfig/firstboot).  Depending whether it exists or
doesn't exist, the firstboot init script -- if set to start
for the run-level -- does or doesn't do something.  It will
then create/delete the file at the end of the run, as
appropriate, to prevent it from running next time.

This is a good practice -- create an initscript that looking
for the existance of a file, and acts accordingly --
creating/deleting at the end to prevent it from running the
next time.  The initscript itself can also be disabled so
there is no chance of it running, regardless of the file.
> This isn't about figuring out a way to do the update, it's
> about trying to follow the "Law Of Least Astonishment".
> I've dealt with too many really screwed up systems that had
> customised stuff everywhere and nothing worked as expected.
> Suggestions?
I'm not saying that's what you should do, you could put some
similar logic in /etc/rc.d/rc.local.  You could just put the
commands in /etc/rc.d/rc.local and delete them or disable
them (maybe with a "sed -e" command).

Or you could put a conditional in /etc/rc.d/rc.local, look
for the existance of a file, and run/not run the commands
based on its existance.

But in either case it means you have to run an "echo >>" or
"sed -e" command to modify /etc/rc.d/rc.local.

It's much easier just to plunk down 2 files -- one in
/etc/init.d/ and one in /etc/sysconfig/ (or wherever you want
to put it).  You can do put those commands to copy those
files in the "%post" section.  Or you can put them in their
own RPM too, including running "chkconfig --level" to
enable/disable it's execution at start-up as part of the RPM.

There are a lot of options.  I just find (and this is just my
experience/preference), that the little extra time in
creating an /etc/init.d/ script (with a simple
start|stop|status parameter) and associated config/flag file,
is a lot easier and less ambiguous than running "echo >>" or,
better yet, "sed -e" on /etc/rc.d/rc.local.



-- 
Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith at ieee.org     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)