System Configuration Collector FAQ
For which version of scc is this FAQ?
fix:software:cron:configuration::/var/adm/cron/cron.allow:root fix:software:cron:configuration::/var/adm/cron/cron.allow:adm fix:software:cron:configuration::/var/adm/cron/cron.allow:uucpHow can I customize SCC?
Obtain the software from the sourceforge SVN repository and refer to the README file in the development environments.
To collect the contents of additional files on individual systems, consult module scc_0640_s_local and follow the instructions in the comments. To extend the collection of these additional files on all systems, customize the code and generate your own version of SCC.
Why is my Linux-distro not recognized?
The recognition of a Linux-distro is based on a list of 'known' version/release-files in the scc_utils module. Distro's are only recognized by SCC when their version-file (like /etc/redhat-release) is added to this list. Several distros are based on other distros like Debian or RedHat. When the version-file of a distro is not known in SCC and the version-file of the base distro is known, SCC indicates the base distro. When your distro is not recognized, please send us the full path and contents of its version file and it will be added to SCC.
What are the differences in the software for all supported operating systems?
All clients use the same code base to simplify software maintenance. On a limited number of places the software checks the operating system it is running on to determine specific actions. The generic code checks the existence of all configuration files and commands before they are used.
How are snapshots compared?
To compare two snapshots (current and previous run), all data whose classification start with 'fix' is extracted into two temporary files. These two files are compared by means of diff and the output is processed to indicate to which snapshot (old or new) each reported line belongs. The differences are added to the logbook.
Why does the data from a module appear twice in the snapshot?
This happens when you are modifying a module and kept a copy of the original module by appending some string to its name. The name of this file is considered a valid module name by scc-collect and it will execute the module, resulting in data from the original and modified module. To keep a copy of an original module, you better prefix the name with some string.
At what frequency should SCC run on the clients?
In our experience SCC can easily run on a daily base. When you want to specifically mark certain changes caused by maintenance to be executed, you can run SCC prior and after your maintenance. With the latter run, you can specify the -c option to add a remark to the logbook.
How do I "randomize" running scc on many clients?
When the -d or --delay option with scc or scc-pull is used, the software waits for a random number of seconds before collecting configuration data. The argument of this option specifies the maximum number of seconds to wait.
What does the message concerning rpm in first run mean?
When SCC is installed by rpm, no rpm-data can be retrieved. The database of RPM is locked during installation and during the pre- and post-install this database cannot be queried. To avoid a list of changes on the second run of SCC, all rpm-changes are ignored when the previous snapshot does not contain any rpm-data and the new snapshot does contain rpm-data. This means that the (first) install of SCC by means of rpm is not recorded as a change in the logbook.
Why is my scc client hanging?
Check the process hierarchy with the command "UNIX95= ps -Hef" and look for the scc processes. You could also check the most recent file in /tmp to determine the collected data at the moment of the hang.
Why does module x take much time?
Run module X in debug mode via
export SCC_DEBUG=1; /opt/scc/bin/scc-collect -i -e Xand notice when the data on stdout stalls.
Why does apache config data 'disappear' from the snapshot?
Some data is hard to determine. For example, Apache is installed in many ways/directories. To avoid a scan of the entire file system during each run of SCC, the install directory of Apache is determined from the process list. When Apache is down during a run of SCC, the install directory cannot determined and the Apache configuration will be missing in the snapshot. This results in differences to be reported in the logbook. To avoid this, the install directory of Apache is kept in a separate keep-file for the next runs of SCC. When Apache is down, SCC uses the Apache directory from the keep-file to determine the configuration. This does not go on indefinitely as the keepfile also contains the number of remaining runs that the data is kept. When this reaches 0, the corresponding data is removed from the keep-file and will no longer be part of the snapshot (until Apache is running during a run of SCC).
How is data collected?
Data is collected by issuing system commands and by copying the contents of configuration files. All collected data is examined for variable and fixed data. All data is also extended with a hierarchical classification to indicate the origin of the data.
Can the collection be configured?
The software uses sensible defaults to avoid that many systems require a manually customized configuration file. When the defaults are insufficient, copy the file /etc/opt/scc/newconfig/scc-localize to /etc/opt/scc/conf/scc-localize and uncomment the required variables.
When scc cannot find required programs because they are installed in directories that are not part of our default PATH, change the contents of the variable SCC_PATH in this file (after copying the file).
Can SCC run without root permissions?
Running in this mode will reduce the amount of data retrieved and requires non-default (non-system) directories for the software. Install for non-root users is only available in source package format. To install and run SCC in user mode, unpack the source distribution file, use the relocation script to change the install and data directories of the software. Then generate the source package by means of src-gen-src and distribute and install the package (untar and call scc-install).
What do these 'messages' in the snapshot mean?
An example is:
messages::inspect scc.<system>.cur to determine cause of messages in system/user-modules fix:messages::not enough fields in classification: fix:::/dev/mem: mmap: Bad addressSCC snapshots consist of lines of data preceded by their hierarchical classification. Most lines are produced by calling a program and adding the classification with sed. When the program produces data on stderr, this data is not handled by sed and therefore does not have the desired format. All data in the snapshot is checked for the classification and when it is missing, the first message is placed at the start of the snapshot and the stderr data is extended with the classification "fix:messages::" to match the required format.
When this occurs, you can examine the code of the corresponding module and find out which program causes the stderr. This can either point to a wrong configuration on your system or on a defect in SCC. Please let us know when the latter is the case and we will fix the module.
In some cases it can be difficult to locate the cause of a general message like 'file not found'. In that case you can run module X in debug mode via:
export SCC_DEBUG=1; /opt/scc/bin/scc-collect -i -e X >mod.log
Is it possible to reduce the size of big snapshots?
Copy file /etc/opt/scc/newconfig/scc-split.conf to /etc/opt/scc/conf/scc-split.conf and edit it. This will split the snapshot in parts based on the classifications of data. The file contains examples to place the data for each Oracle SID in a seperate snapshot (and logbook). The data from the additional "virtual" hosts is also sent to scc-srv.
What does it mean that there are too many changes?
When scc-cmp detects that a new and an old snapshot differ too much in size or when there are more than 20.000 changes in the current run, it is likely that some error occurred during the collection of data. To avoid massive amounts of changes in the logbook, the following remark is added to the logbook:
Too many changes; reduced to # of lines per classificationand the number of changes per classification are recorded in the logbook. This enables you to find out which module caused the possible hiccup in the collection of the data. Note that correcting the hiccup will cause this situation to happen again as the next snapshot will contain much more data than the old snapshot.
Why is the logbook empty?
On certain (small) distros busybox implements a limited version of diff and this is an essential program for SCC to determine differences for the logbook. In this case an empty logbook-file is produced and when this is transferred to the server-part of SCC, the newly arrived snapshot is compared with the one already present (provided scc-srv runs on a system with a fully functional diff implementation). Note that is this case you have to send the data to the server after each run of SCC or some differences are lost.
How to upgrade SCC on systems with limited diff?
Execute the following steps to upgrade SCC on systems with a limited (busybox) diff:
- run scc and transfer data to scc-srv - upgrade scc - run scc with -n option to avoid data collection, but with transfer optionsWhy does the logbook contain may changes after changing the order of the modules?
When the order (number part of the name) changes, RPM will only remove the old name after the postinstall. This means that the postinstall run of SCC runs both the old and the new name and thus collect the corresponding data twice. The next run of SCC only runs the new module and the data from the old module is reported missing. You can correct this by running scc-log --reset after the install. Or the order of the modules should not be changed when customizing the code.
How can I transfer SCC data from clients to server?
Basically there are three setups: push, pull and two-step. Refer to manual page scc(5) for more details.
Can you extend the collection of data by SCC?
To extend the collection, we need the following items: