In a development environment, any of several groups
of people --
Development, Integration, Test, and Training groups
-- may use
similar platforms configured differently over the life
of a product.
These groups often find they need an easy way to verify
configuration or to discern one system from another.
System verification determines whether a machine's hardware
are in a predefined configuration (baseline). If not
at the baseline
configuration, how far from baseline is the configuration?
many reasons to do automated configuration checks:To monitor and identify system parameters that affect
The verify script in Listing 1 shows an automated, reliable,
to use and maintain tool for verifying a system configuration.
article addresses each of the problems listed above
and contains a
technical description of the tool itself.
Ease of Use
At a site with many different systems, an administrator
is often unable
to check a system configuration as soon as a user requests
So it is convenient to enable users to differentiate
configurations. With this script, any user can verify
a system configuration
without having to learn new commands, new techniques,
or obscure system
calls. Placing this script in their path gives users
a fast, reliable
method of determining system configuration on their
Consistent System Resources
Changes to a system configuration may not immediately
to all machines, and this can confuse some users about
configuration. For example, suppose Development initially
60 shared memory segments as adequate for a system.
this is not enough, so they change the kernel to support
memory segments. Now two potentially different configurations
for the same system. If Development is not aware of
the change, they
can waste time chasing down an old problem. A user may
kernel has not been updated, but few reliable methods
exist to verify
this. The kernel configuration file can be manually
checked, but since
users can find or make kernels on any system and copy
them over, there
is no guarantee that the local configuration file belongs
kernel. Checksumming the kernel may show the two kernels
but it cannot tell how they differ. Changing the hostname
a new checksum, but a new checksum doesn't identify
a new hostname
as the cause. In this case, the best way to differentiate
is to create a tool that reads the kernel variable directly,
it into this script. Any user can run the script to
Also consider that if a set of machines in configured
the same during
development and integration, your organization will
spend less time
troubleshooting platform interface and dependency problems
the integration and delivery phases of a product. This
tool can help
provide that consistency.
Standard Working Environment
If you use a standard user environment, you must have
a way to ensure
that important settings have not been changed. For example,
require certain aliases, masks, or paths, you can use
to easily and consistently verify that users have not
environment in any detrimental way.
Monitoring system parameters with verify is easy. For
parameter you suspect is too low or too high, place
a check in the
script. For example, if the kernel has been configured
100 processes, you can compare the current number of
the maximum value built into the kernel and better estimate
Other Methods of Verification
Generally, all verification methods have one aspect
in common: they
compare a current configuration to a baseline configuration.
method does this by calculating checksums on a set of
files and comparing
those sums to the baseline sums. This method can work
slowly, for a small set of binary executables, such
as kernels, but
is unacceptable for databases, configuration files,
and network routing
tables. The contents of these files are imprecise. For
files often have spaces and tabs used interchangeably.
You may be
concerned not with the contents of an object but with
such as file permissions and file ownership.
Another verification method has an administrator manually
machine. This method is extremely labor intensive, prone
and boring. The task becomes unmanageable when a site
has a moderate
number of systems.
The verify script combines the best features of both
methods in one automated script. It checksums the contents
of a small
number of files. It performs content checks on configuration
verify also compares baseline values against dynamic
items, such as routing info, and compares file attributes.
is easy to maintain and distribute. Used from a central
it allows one administrator to quickly, reliably, and
determine the configuration of a set of systems.
The script is invoked by a privileged user from a shell.
one command line argument, "-v" (verbose),
that writes to
standard output the status of all configuration items,
baseline or not. Without the "-v" switch,
the script defaults
to output only configuration items that are out of baseline.
The most often used operation in the script is:
-- Get the current state of a configuration
item from the system.
-- Compare the current state to the baseline
state and determine which items are:
-- within the baseline,
-- extraneous to the baseline, and
-- missing from the baseline.
This operation is used for filesystem mounts, partitions,
routes, and other items where resources can be added,
changed. Another often used step is:
-- Check existence of a configuration item
This step verifies file existence, file permission,
application program existence, and product licenses.
The script itself contains all the baseline configuration
are no external configuration data files in this example
practice each system/baseline is unique enough to warrant
script. And as most sites run more than one platform/system,
much easier to maintain a single file rather than a
command file and
multiple data files for each system. If this is not
the case at your
site, then by all means set up a command file that uses
items in separate data files.
See Figure 1 for a sample run of the script invoked
with the "-v"
option. Note that baseline configuration items are tagged
prefix "Baseline". Non-baseline items are
Without the "-v" option, only the non-baseline
items are written.
The power of this method is in its flexibility. Any
can be done on a system can be written into that system's
executed many times faster and much more reliably than
by hand. You
can also use verify in a function that allows unattended
of all machines in a set, with non-baseline items automatically
to a file and mailed to interested parties.
It is also possible, though not described here, to automate
of baseline parameters into this script. Once a baseline
another script could extract pertinent data from the
and write it into this script. You might write such
a script if the
baseline changes often and the number of configuration
items is moderate
Porting the Script to Other Operating Systems
The script as presented here was written for DEC Ultrix
is easy to port to other operating systems. Each configuration
within the script has a precise data format and example.
a matter of massaging data into that format using common
like awk(1), sed(1), or cut(1). We successfully
ported the script to an SVID system in only two days
verify, as presented, checks about 100 configuration
It runs in about 30 seconds of real time per machine.
that performing the same number of checks with the same
take as long as 20-30 minutes per machine, preparing
script is well worth the effort.
About the Author
Packey Velleca received a BSEE degree from the Florida
of Technology in 1988. He currently works with a group
for a small system of real-time computers with UNIX-based
workstations. His earlier article, Reproducing Boot-Disk
appeared in the Jan/Feb 1994 issue of Sys Admin.