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.
- We needed a method of
simply cataloging all the software packages (we chose to use RPM's) we
ever use in a distribution.
- We needed a method to
define which sets of packages made up a given Cisco distribution. This
had to allow for recall of any given release and be compatible with
Kickstart installation methods. Lastly, we needed a process that would
to take a Cisco distribution definition and produce an installable
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.
- 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
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 :
RPMs provided by RedHat
within one of their Linux releases.
RPMs either developed
by, modified by or compiled/maintained within Cisco.
RPMs supplied by a
vendor (other than RedHat) such as Frame, StarOffice, Acrobat, etc.
RPMs available in the
Public Domain (from reputable sources, Example: xemacs from
In Brief :
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
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.
- check out a directory listing (a file containing the output of
an 'ls command') per category from CVS
- copy the new RPMs to the appropriate directories
- generate new directory listings
- Check in the new directory listing files to CVS -
developer is expected to comment on why the new RPM was added.
The structure of the directories that will contain distributions
from RedHat is as follows:
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
want to re-invent the wheel so we decided to go with RedHat's Kickstart
it did basically everything we needed. To understand the tools we have
you will now need to know how