scc(5)



NAME

scc - introduction SCC

RELEASE

scc 1.6.26

DESCRIPTION

System Configuration Collector is yet another configuration collector. Just like the other collectors it collects configuration data on Unix systems. The difference is that each line of collected data is extended with a hierarchical classification of the nature of the data and with an indicator whether that data is supposed to be static or dynamic. For example: the size of a file system is static data and the current usage is dynamic data. Consecutive collections of configuration data (snapshots) are compared and differences in the static data are added to a logbook. Filling a file system will not be reported in the logbook, but the extension of a file system will be. Additional software converts the snapshot and logbook to html-format.

The classification of the data is a hierarchy with the following top-level items (among others):


- general
- boot
- hardware
- Volume Management
- kernel
- network
- software
- system
- users

Development of SCC started for HP-UX and later shifted to Solaris and Linux. At the moment, most of the Operating System configuration of HP-UX is collected. Additional configuration is collected for OS add-ons like MCServiceGuard and OmniBack.

INSTALLATION

SCC is available as HPUX depot, Solaris package, RPM, *BSD package, Debian package and source tarball. The software from the depots/packages/rpms on the website is NOT relocatable, it installs in /opt/scc/bin Data- and temporary files are located in /var/opt/scc and config files in /etc/opt/scc It is possible to install the software in other directories. Unpack the source tarball, edit and use the relocate script and generate the required depot/package/rpm. Throughout this documentation only the default directories are mentioned.

During the pre-install phase, the software runs a possibly installed version of SCC to capture the changes in configuration just before the installation. During the post-install phase, the software removes the current snapshot (made by the previous version of SCC) and starts the new version of SCC. This means that SCC does not compare two possibly incompatible snapshots, avoiding flooding the logbook.

This means that the installation may take some time (typically less than 5 minutes). On a moderate pentium with RedHat 9.0, SCC completed a run within a minute. On an old and overloaded HP-UX server, it was reorganizing its database, two runs of SCC took 45 minutes to complete.

To install release 1.5.32 on HP-UX, use the commands:

	swinstall -s $(pwd)/scc-1.5.32.hpux-1x.depot scc

To register this file as a depot, use the command:

	swreg -l depot $(pwd)/scc-1.5.32.hpux-1x.depot

To add this file to an existing depot, use the command:

	swcopy -s $(pwd)/scc-1.5.32.hpux-1x.depot scc @/your/depot

To install release 1.5.32 of the SunOS package, use the commands:

	pkgadd -d ./scc-1.5.32.sunos.pkg -a none scc

You will be prompted for the execution of the pre/post-install scripts.

To install release 1.5-32 of the RPM package, use the command:

	rpm -U ./scc-1.5-32.rpm

To install release 1.5-32 of the Debian package, use the command:

	dpkg -i ./scc-1.5-32_all.deb

To install release 1.5.32 of the source package, use the commands:

	tar xf scc-1.5.32.src.tar
	cd scc-1.5.32
	./scc-install

To install release 1.5.32 of the FreeBSD package, use the command:

	pkg_add scc-1.5.32.FreeBSD.tgz

To upgrade from release 1.5.31, use the command:

	pkg_delete scc-1.5.31
	pkg_add scc-1.5.32.FreeBSD.tgz

To install release 1.5.32 of the NetBSD package, use the command:

	pkg_add scc-1.5.32.NetBSD.tgz

To upgrade, use the command:

	pkg_add -u scc-1.5.32.NetBSD.tgz

To install release 1.5.32 of the OpenBSD package, use the command:

	pkg_add scc-1.5.32-OpenBSD.tgz

PROGRAMS

The programs of SCC have the following relationship:

scc: main program
this program calls scc-log and sends data to the SCC-server.
scc-log: this program calls:
- scc-collect: collect all data by calling modules in scc_modules
- compare new and old snapshots, add differences to logbook
- scc-snap2html: convert snapshot to HTML
- scc-log2html: convert logbook to HTML

Previous versions of SCC contained the programs scc-baseline and scc-syscmp to compare (parts of) snapshots. This functionality has been moved to the scc-srv. These programs are removed from the distribution and from the systems when the new version of SCC is installed.

USING SCC

After the installation, the data is available in directory /var/opt/scc/data. The file scc.<hostname>.log contains the logbook and the file scc.<hostname>.cur contains the current snapshot.

To run SCC again, just start /opt/scc/bin/scc. To keep an accurate logbook of your system, you can schedule it with cron:

	0 6 * * * /opt/scc/bin/scc

Any errors produced by programs called by scc-collect, appear under the classification "messages". Most of the times they indicate some hardware or software error on the system. Running SCC is some kind of a health check for your system.

It is possible to send your SCC-data (snapshots, logbooks and the html-files) to a server running the server-software of SCC (scc-srv). Before you send your data to a server, you have to prepare the server by installing scc-srv and configuring the server. On the server, summaries of the SCC-data are generated and all data is accessible through a web-interface.

To mark the completion of certain changes you performed on a system, use the -c option of scc(1). To mark changes in the snapshot when implementing a RFC, use the following commands:

scc                # record changes up to this moment
# perform the tasks required by the RFC
scc -c "RFC 123"   # record changes due to RFC

CUSTOMIZING/EXTENDING SCC

scc-collect(1) and its modules use sensible defaults to avoid that many systems require a configuration file. When the defaults are insufficient, check the code for a reference of scc-localize. This script contains several environment variables that influence the behavior of scc. To adjust scc, copy /etc/opt/scc/newconfig/scc-localize to /etc/opt/scc/conf/scc-localize and uncomment the required variables. Be sure to preserve the execution permission of the file.

scc-collect(1) collects OS and OS-related configuration data. It does not collect data of the applications you developed. To extend the snapshots, refer to the manual page of scc-plugin(1). It offers a starting point to collect other configuration data.

DBA's will only be interested in part of the SCC-data of a system. By using the file /etc/opt/scc/conf/scc-split.conf it is possible to split the snapshot in several parts. Each Oracle SID can have its' own snapshot and logfile. When these snapshots are send to the scc-server, they can be added to a separate realm that only contains SCC-data of Oracle SID's. Refer to /etc/opt/scc/newconfig/scc-split.conf and to scc-log(1) for examples and more details.

SCC ships with several user modules that are not run by default. Check the directory /opt/scc/bin/scc_modules for scripts containing "_u_" in their name. These are user-modules that can be activated by means of the -e option of scc. Refer to the manual page of scc-collect(1) and scc(1) for a more detailed description of the use of modules.

To add specific user modules for all your systems, customize the depot/rpm and packages. This can be achieved by unpacking the source tarball and adding the required files. Then regenerate the source tarball. This new tarball can be untarred for each depot/rpm/package you require for your systems. Refer to the README file in the source tree for more details concering producing the depot/rpm/package.

PERFORMANCE

Usually scc completes its runs within minutes. When you notice that runs of scc on a system take very long to complete, you can use the profiling data to determine the cause. Edit /etc/opt/scc/conf/scc-localize to activate the variable SCC_PROFILING and run scc. When this file does not exist, you can copy it from /etc/opt/scc/newconfig. Profiling data is added to the snapshot and can be found in the html-file under the classification: "profiling". Each line of the profiling data consists of the following fields:

- timestamp
- seconds since previous stamp
- seconds since start of run
- comment

Look for large values in the second column to locate the code of scc that is causing this performance problem. An example of profiling data is:

var:profiling::11.20.10:    0 :    0 :start of run
var:profiling::11.20.10:    0 :    0 :start of run:	scc_0000_s_general
var:profiling::11.20.13:    3 :    3 :end of run:	scc_0000_s_general
var:profiling::11.20.13:    0 :    3 :start of run:     scc_0100_s_boot
var:profiling::11.20.17:    4 :    7 :end of run: 	scc_0100_s_boot
var:profiling::11.20.17:    0 :    7 :start of run:     scc_0200_s_hardware
var:profiling::11.20.18:    1 :    8 :end of: hardware: AutoRAID
var:profiling::11.20.18:    0 :    8 :end of: hardware: FC60-array
var:profiling::11.21.43:   85 :   93 :end of: hardware: disk
var:profiling::11.21.54:   11 :  104 :end of: hardware: ioscan
var:profiling::11.22.18:   24 :  128 :end of: hardware: stm
var:profiling::11.22.18:  121 :  128 :end of run:     	scc_0200_s_hardware
var:profiling::11.22.18:    0 :  128 :start of run:     scc_0300_s_kernel
var:profiling::11.22.25:    7 :  135 :end of run:       scc_0300_s_kernel
var:profiling::11.22.25:    0 :  135 :start of run:     scc_0400_s_vol_mngt
var:profiling::11.22.34:    9 :  144 :end of: Volume Management: file systems
var:profiling::11.22.43:   18 :  153 :end of run:       scc_0400_s_vol_mngt
var:profiling::11.22.43:    0 :  153 :start of run:     scc_0500_s_network
var:profiling::11.26.43:  240 :  393 :end of run:       scc_0500_s_network
var:profiling::11.26.43:    0 :  393 :start of run:     scc_0500_u_named
var:profiling::11.26.44:    0 :  393 :end of run:       scc_0500_u_named
var:profiling::11.26.44:    1 :  394 :start of run:     scc_0600_s_software
var:profiling::11.28.14:   90 :  484 :end of: software: ignite
var:profiling::11.43.28: 1004 : 1398 :end of run:   	scc_0600_s_software
var:profiling::11.43.28:    0 : 1398 :start of run:     scc_0700_s_hp_ov
var:profiling::11.43.31:    3 : 1401 :end of run:       scc_0700_s_hp_ov
var:profiling::11.43.31:    0 : 1401 :start of run:     scc_0700_u_hp_ovou_srv
var:profiling::11.43.31:    0 : 1401 :end of run:       scc_0700_u_hp_ovou_srv
var:profiling::11.43.31:    0 : 1401 :start of run:     scc_0800_s_oracle
var:profiling::11.43.32:    1 : 1402 :end of run:       scc_0800_s_oracle
var:profiling::11.43.32:    0 : 1402 :start of run:     scc_0900_s_system
var:profiling::11.43.35:    3 : 1405 :end of run:       scc_0900_s_system
var:profiling::11.43.35:    0 : 1405 :start of run:     scc_1000_s_users
var:profiling::11.43.40:    5 : 1410 :end of run:       scc_1000_s_users
var:profiling::11.43.40: 1410 : 1410 :end of run
var:statistics::profiling 

The software module used 1004 seconds to complete after collecting ignite data. After adding some more calls to the profiling function, it appeared that the SD-UX commands took way too long. Further investigation indicated the source of the problem. After correcting the problem, scc ran much faster.

SECURITY

As the programs of SCC must run as root to obtain all the necessary configuration data, the environment of SCC must be well protected. This is accomplished by creating separate directories for the data and programs of SCC and properly securing them.

Therefore SCC is not relocatable during installation. As only root should run these programs there is no need for ordinary users to put the SCC-directory in their PATH.

COPYRIGHT

SCC is free software under the terms of the GNU General Public License. Copyright (C) 2001-2004 Open Challenge B.V., 2004-2005 OpenEyeT Professional Services.

SEE ALSO

 scc(1), scc-collect(1), scc-log(1), scc-log2html(1), scc-plugin(1),
 scc-snap2html(1), scc(4), scc(5)

VERSION

$Revision: 1.30 $