Defining a Distribution 




Defining a Cisco Distribution

Once the package and image storage requirements were met, the next step was to develop a process to define sets of packages. A distribution would be made up of various RPMs, grouped by arbitrary categories. There would also be a distinct base boot image associated with the set of packages. It was decided to use a text configuration file with a simple syntax to group packages and define the base install image.

The distibution configuration file syntax is purposefully very simple. It is composed of only two columns: a directive and that directive's parameters. Comments (lines beginning with a '#') and blank lines, or lines containing only whitespace, are ignored.

Directives:
 
Directive Parameters Description
group <group name> [default [options]] Package group declaration. All package and include directives listed after this directive will be part of this named group until another group declaration or end-of-file is reached. The 'group name' parameter is the name of the group to which named packages will be added. The 'group name' may contain spaces. The group directive can be repeated with the same 'group name' within the file if desired: named packages will be added to any packages in the existing group. The additional parameters 'default' and 'options' are not required. The 'default' parameter is the default installation status for this group in the comps file: it must be a 0 or 1 (defaults to 0). The 'options' parameter can be used to specify comps file options for this group: currently --hide is supported.
include <group name>[,...] Package group inclusion declaration. This directive is used to include package groups within one another. The 'group name' should be the name of a previously defined package group to be included in the most recent package group declaration. The 'group name's are comma separated with no extra spaces - spaces will be interpreted as part of the 'group name' if present. Group inclusion is order sensitive - a 'group name' must be defined (by a previous group declaration) before it can be included in another group.
package <rpm file name> Package declaration. This directive names and actual RPM file to be included in this distribution. The file must exist in one of the directories outlined above under the ALLRPMS directory or in the base distribution. The package named in the 'rpm file name' parameter will become part of the most recent package group declaration.
image <version number> Boot image/Base installer version. The 'version number' parameter must match one of the existing version numbers under /export/linux/distributions/redhat as outlined above.
arch <architecture type> CPU Archictecture for boot image. The 'architecture type' parameter must match one of the existing architectures under /export/linux/distributions/redhat/<version>/en/os/ as outlined above.
directory <path>
Additional directory to search when build_ks or ks_updates is run.  This allows you to specify an additional path to include, i.e. /export/ximian/xd2.

Sample configuration file:

# Sample Cisco Distribution configuration file
#
# Directive     Directive Parameters
# ---------     -----------------------------
image           6.2
arch            i386
directory       /export/ximian/xd2

group           Base
package         basesystem-6.0-4.noarch.rpm

group           Shells
package         zsh-3.0.7-4.i386.rpm
package         tcsh-6.09-4.i386.rpm
package         bash-1.14.7-22.i386.rpm

group           Utilities
package         gzip-1.2.4a-2.i586.rpm

group           NOTEBOOK
package         StarOffice-5.1-2.i386.rpm

group           Cisco Workstation
include         Base,Shells,Utilities
In the example above, it would only be necessary to reference the 'Cisco Workstation' package group in a ks.cfg file to install a workstation. You might have noticed that the group 'NOTEBOOK' is defined, but is not part of any other group. This makes the packages within the 'NOTEBOOK' group available for install if needed (with additional entries in the '%packages' section of a ks.cfg file).

Building and initial  build_ks.conf file is probably the hardest step of any of this. But once you have an initial version done, managing changes to your distribution is as simple as editing the build_ks.conf file.

We are working on a tool that will help you build an initial build_ks.conf file.

How that you have a build_ks.conf file that defines your distribution, you need to run build_ks so that it can build your Kickstart installer.