Kickstart Methodology

[Philip Rowlands]

On Mon, 25 Oct 2004, Brian Long wrote:

>I'd like some ideas on how folks on this list customize their install
>base.  We currently create a completely customized kickstart tree based
>on RHEL 3 where we integrate third-party and internally-written RPMs.
>
>I'm thinking we should just use Red Hat's kickstart (comps.xml) as it
>comes on the CD (each quarter) and bootstrap Red Carpet or RHN into the
>mix to install all third-party and internal RPMs after the initial
>kickstart.

When considering deconstructing comps/comps.xml, I'd only modify the
file:
- if replacements to the RH-provided packages were required
- to exploit the dependency hierarchy of the comps structure
- certain multi-lingual issues (but this is kickstart-list, not
interactive-install-list)

In our [relatively homogenous] shop, all machines get the same base
packagelist, and there's no replacement of, say, RedHat's Ximian
collection with Red Carpet. What we *do* heavily customize are the
specific additions and removals to get exactly the required packages.
For example, gcc is in, but almost all of the -devel packages are out,
which helps to keep the installed image nice and small.

Pre-patch vs yum/up2date? Putting all the RPMs in RedHat/RPMS vs %post
scripts? Both will work fine technically, so the decision then moves
into softer areas such as time-to-deploy, maintainability etc.

Once the packages are on though, we use a good deal of %post-invoked
scripts to tweak about 30 different things; again what you do here will
depend a lot on internal requirements.


Cheers,
Phil