scc(5)
NAME
scc - introduction SCC
RELEASE
scc 1.17.23
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 log-
book, 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/pack-
ages/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 relo-
cate 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 hard-
ware 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, sum-
maries 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 insuffi-
cient, 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 snap-
shot 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 or modify specific user modules for all your systems, customize
the depot/rpm and packages. This can be achieved by unpacking the
source tarball and adding/modifying the required files. Refer to the
README file in the source tree for more details concerning 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. Pro-
filing 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 inves-
tigation 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 Profes-
sional Services, 2005-2011 QNH.
SEE ALSO
scc(1), scc-cmp(1), scc-collect(1), scc-log(1), scc-log2html(1),
scc-plugin(1), scc-snap2html(1), scc(4), scc(5)
VERSION
$Revision: 4592 $