Introduction 


 In rolling out a Linux distribution custom tailored to Cisco, it quickly became apparent that a system to track software packages and a method for determining which packages make up a release was imperative for success. There were three main requirements that had to be met in order to get started.

  1. We needed a method of simply cataloging all the software packages (we chose to use RPM's) we would ever use in a distribution.

  2. We needed a method to define which sets of packages made up a given Cisco distribution. This method had to allow for recall of any given release and be compatible with Kickstart installation methods. Lastly, we needed a process that would allow us to take a Cisco distribution definition and produce an installable image structure that could be used for Kickstart or transferred to a CD-ROM or other media. This process had to allow for on-going development of the next release without impacting installations of the current release.

  3. It had to allow for multiple distribution developers to work simultaneously without interfering with each other.

We believe we have developed a total solution which meets all three requirements.

RPM Storage and Categorization

The team responsible for developing a Cisco Linux distribution agreed early on that utilizing pre-packaged software to make up a distribution was key to success. A Cisco Linux distribution would be loosely based on a RedHat Linux release with the addition of in-house, third party and public domain packages. With all software installed as RPMs (Redhat Package Manager), a distinct set of packages could be grouped to form a particular release with relative ease. Additionally, with this list of packages under a form of version control, recalling the set of packages from a past release could be easily accomplished.

A simple directory structure is outlined below which serves as the repository for all RPMs that would ever be used in any in-house Linux distribution. Individual RPM files (.rpm's) reside in these directories. No other file types or directories should be created within these directories. The structure is split into four categories (directories), under /export/linux/ALLRPMS :

redhat
RPMs provided by RedHat within one of their Linux releases.
cisco
RPMs either developed by, modified by or compiled/maintained within Cisco.
vendorsup
RPMs supplied by a vendor (other than RedHat) such as Frame, StarOffice, Acrobat, etc.
publicdomain
RPMs available in the Public Domain (from reputable sources, Example: xemacs from xemacs.org).

In Brief :
/export/linux/ALLRPMS/redhat      /*.rpm
                     /cisco       /*.rpm
                     /vendorsup   /*.rpm
                     /publicdomain/*.rpm
At the time of this writing, the exact procedure for adding RPMs to a given directory has not been decided. A possible method is a script that would:
  1. check out a directory listing (a file containing the output of an 'ls command') per category from CVS
  2. copy the new RPMs to the appropriate directories
  3. generate new directory listings
  4. Check in the new directory listing files to CVS - developer is expected to comment on why the new RPM was added.
In addition to the individual RPMs contained in the directory structure, it is also necessary to keep versions of the actual RedHat releases the majority of the RPMs came from. These are needed for historical record as well as storing the actual boot images that accompanied the RPM sets.

The structure of the directories that will contain distributions from RedHat is as follows:

/export/linux/distributions/<vendor>/<version>/<architecture>/<distribution contents>
For example:
/export/linux/distributions/redhat/6.2/i386/...
                                      /sparc/...
/export/linux/distributions/redhat/7.0/i386/...
                                      /sparc/...

Now that we have a way of storing and catagorizing our RPMS we need a way of getting these RPMS on to a new computer. We didn't want to re-invent the wheel so we decided to go with RedHat's Kickstart since it did basically everything we needed. To understand the tools we have written you will now need to know how Kickstart works.