build_ks 


Producing an Installable Image Structure

A custom perl script, build_ks (build KickStart), was developed to produce the KickStart environments on-the-fly. The 'man' page for the script is included below:
NAME
build_ks - Build a Linux KickStart environment

SYNOPSIS
build_ks [-d] [-l location] [-a annexfile [-a ...]] [-i image] \
[-ven vendor] [-arch arch] [-release releasename] \
[-r path [-r ...]] [--merge] [--listrpms] \
[--listgroup group] [-q] configfile

build_ks { --help | --man }

DESCRIPTION
Build the comps or comps.xml file, hdlist file, RPMS directory and other
appropriate structures necessary to produce a KickStart environment that
can be used to build a Linux workstation or server. This command can
only run on a system with access to a full RPM repository.

OPTIONS
-a annexfile | --annex annexfile
Specify a configuration annex file to be processed after the main
build configuration file. Multiple annex files may be specified with
repeated --annex options. Annex files are processed in the order
specified on the command line.

--arch arch
Override any settings for architecture in the given files with the
specified arch. The arch operand can be things like i386, amd64,
etc.

-d | --debug
Turn on debugging messages.

-h | --help
Display SYNOPSIS and OPTIONS.

-i image | --image image
Override any settings for base image in the given files with the
specified image. The image operand can be things like 7.3, 8.0, 9,
etc.

-l location | --location location
Path that the Kickstart environment should be built in. If not
specified, the environment will be built under
/export/linux/kickstarts/USERNAME where USERNAME will be replaced
with the login name of the user running the program.

-m | --man
Display this documentation.

--merge
Instead of building the Kickstart environment, merge the build_ks
config file with all annex files and write it. The default location
of the output file is /tmp/build_ks_merge.$USER.

--listrpms
Instead of building the Kickstart environment, list the full path to
each RPM in the release.

--listgroup group
Instead of building the Kickstart environment, list the packages in
the given group including all packages in any subgroups. The group
name must exactly match the name inside the configuration file.

-p | --production
If this option is specified, the kickstart environment will be built
directly under the base kickstart path (/export/linux/kickstarts)
instead of the user's name.

-q | --quiet
Enable $KSTools::QUIET which tells certain subroutines to only
output errors instead of warnings.

-r path | --rpmdir path
Specify an optional directory path in which to look for RPM's when
building a kickstart environment. RPM's that are found/used in this
directory will be copied into the resulting kickstart environment
instead of hard-linked. Multiple paths may be specified with
repeated --rpmdir options.

--release releasename
Override any settings for releasename in the given files with the
specified releasename.

-ven vendorname | --vendor vendorname
Override any settings for vendor in the given files with the
specified vendorname.

OPERANDS
configfile
The file containing the configuration information (release
definition) for the KickStart environment to be built.

NOTES
Kickstart environments will always be built under some base path,
followed by the release name and architecture. The base path defaults to
/export/linux/kickstarts. This can be changed with the -l, or -p options
mentioned above.

SEE ALSO
build_ks.conf(1)

AUTHOR
Josh Goldenhar (15 January 2004)
 Brian Long (5 September 2003)


The program works as follows:
 

  • The configuration file is partially read to determine the base image version and architecture to use for this custom distribution.
  • A list of all available '.rpm' files (and their locations) is generated from RPM's within the ALLRPMS directory and those included within the base image specified in the configuration file.
  • The complete configuration file is then read to build the package groups and determine which RPM's will be made available in the distribution to be created.
  • The KickStart distribution is created. The base and, if needed, instimage directory structures are copied (using rsync) from the base image into the specified custom distribution area. Necessary directory structures are created. Using the known list of RPM's (from the configuration file), hard links are created in the RPMS directory for each RPM to be included in the custom distribution.
  • The comps file to be used for KickStarts is created using the package groups defined in the configuration file.
  • genhdlist is run to produce an hdlist file within the base directory.

  • Once all this is done, the directory structure under the specified (or default) location looks like, and can be used like a RedHat installation CD. The advantage over actual modified copies of vendor supplied distributions is that these take up little space, they are easily modified and can be reproduced at any time by versioning the configuration files.

    Getting all your RPMS together:

    Before you can use build_ks you have to have a repository of RPMS. The layout of those directory's of RPMS is covered in the introduction .
    Now is the time to start building that structure. You don't have to have any RPMS in those directory's but you have to at least make sure the directory's exist.

    You also have to get copies of the base releases. A base release is what your personal kickstart installer is going to be based on.
    For example, you want to use RedHat 7.1 for the most part along with some changes. That would mean that your base release is 7.1.
    Most of your RPM's would come from /export/linux/distributions/redhat/7.1. Then any changes to that would come from your ALLRPMS repository.

    So, you should rsync, mirror,  or whatever way you want a copy of the base distribution you plan to use and put it in /export/linux/distributions/redhat/<version>.

    At Cisco we rsync various parts of RedHat's ftp site. This includes the base distributions as well as the updates directory for each distribution.
    The updates directory will come in handy when we talk about ks_updates .

    One of the things that needs to be changed in our scripts is to remove the hardcoding of these paths and make it into a variable in a configuration file that each of the utilities uses.

    Insert example here.