The HP-UX Admin Man: System Configuration Repository

The only things in life that are free are those things that we don't want. At least, that is how Fred felt before the Interworks 2000 conference and the SCR announcement.

• 06/01/2000

About the only things in life that are actually free are those things that we don’t want. At least that is how I felt before the Interworks 2000 conference for HP-UX system administrators in early April. It seems that every year we are told of some new administration product the people in Fort Collins have developed or improved. I am always shocked to hear that it is being given away free. This year was no exception; instead, it was a bonus year. There were several system administration-related products being demonstrated, and HP is giving most of them away free.

This column is about the System Configuration Repository (SCR) product, so at least you know what you are missing, if you have not discovered it yet. SCR is both a database query system and a data collection system. The data it is designed to collect is system configuration information.

A couple years ago, I wrote about the great command print_manifest, which is part of the Ignite/UX product. That command lists out all sorts of information about a system, from hardware to disk configuration and network configuration information. If you are familiar with that command, you have a good idea about what data SCR stores about a managed host, but there is more. Also, it can contain usage and contact data, installed software, processes running, and even patches in HP-UX 11.

Generally speaking, it is probably capable of capturing more information that you might want, but then, that is better than too little when something goes wrong (if you have the disk space to store it, and network bandwidth to collect it). Each time information about a host is captured, this data is stored in what is called a snapshot. You can then compare snapshots over time to see what has changed, thus making it easier to determine the cause of a problem.

Let’s look at possible uses of SCR before we look into the general steps of using it. Knowing that we can compare system configurations over time, means that we might be able to use it for troubleshooting when something goes wrong. This might be after someone has changed the configuration of a piece of software, added a patch that broke something, or maybe some hardware has broken, such as a memory card dropping out. Using SCR to report on differences in configuration from a known good snapshot might make this troubleshooting process faster.

Another good use would be to ensure what is supposed to be a group of similarly configured machines are uniform. Comparing snapshots should show only host and network differences, with identical disk layout, LVM, memory, software, processes and patches. The use that you hope to never need would be disaster recovery. This means that you have been backing up the repository information, and storing it off site. Having this information would aid in rebuilding the lost machines exactly as they were.

On to how the software works. SCR is a Desktop Management Interface (DMI) application. This means that DMI (another free product from HP) must be installed and configured on any machine you want to capture information about. DMI provides the APIs that SCR calls to collect the data. You also need to install and configure DMI and SCR on the machine that you will be using to monitor the configurations of the "managed" nodes. It is called the Central Management System (CMS) in the documentation.

To get data collection started, you should first configure the probes. This is done by editing a filter file which determines what data to collect. This filter file is created with the following commands on the CMS:

You can then edit the filter file (named probefile in the example above) as desired, look at the documentation for how to edit the file.

Next, reinstall the edited probe filter file:

Now you can tell SCR which hosts to monitor (they must already have DMI installed and configured):

At this point, SCR will be ready to monitor the two hosts listed above (swift and puxy), but will only do so when told. To tell SCR to perform probes of the configured hosts, issue:

You can then use the scrviewer command to see what data was collected. There is a good chance you want the process of collecting information automatic. This is done with the scrconfig command. The following command would make SCR perform an update of all configured nodes at an interval of once per week:

Note that is "one w," not "ell w," you can specify any interval, using different options.

Once everything is set up and running, you should periodically check to see if anything has changed on any managed hosts. The command scrstatus will list out a record of snapshots taken, and if they were successful. Something to keep in mind about SCR is that it does not save a snapshot if there are no changes since the last saved snapshot. This is to save disk space (remember that if your probe filter looks at things like processes running, or free disk space, a probe will always be saved). To see if snapshots of a system contain any changes, use the scrhist command. This command will list out all snapshots of a system. The oldest and latest snapshot are given exactly those as names. If there is more than one, there was some change in the configuration. You can then use the scrdiff command to see what has changed. For example:

If you are using the identical, dataless client network model, you might be able to save just one snapshot of a "golden" system, and compare the current snapshot of a host with the "golden" snapshot. You could use the scrtag command to name a snapshot as the "golden" snapshot.

For other types of usage, for example, active troubleshooting, you can also tell SCR to take a current snapshot of a particular system, then compare it with what you have saved for that host or a similar configuration. The scrfilter command can also be used to install display filters for the scrdiff and scrviewer commands so that you don’t get flooded with information if you are only looking at one area, like software. I think that SCR would be rather handy for active troubleshooting even if you don’t have SCR configured to monitor a host. Just install DMI, configure it, then compare snapshots of software installed on two hosts, if, for example, one is experiencing problems with a product, and another is note.

As a final point, it occurs to me that you might want to know where to get DMI and SCR so you can start using this great free stuff, or at least look at the formal documentation to learn more. It is available for 10.20 and newer versions. It is found on newer Application Release CDs, or at www.software.hp.com/products/DMI. The latest version was released in March 2000.