• Prerequisites
  • Scheduler Platforms
  • GCC
  • Perl
  • DNS
  • Disk I/O
  • Module Dependencies
• Building
• Installing

Scheduler Platforms

• AIX 5.3 (powerpc)
• GNU/Linux 2.4.9 (RedHat 7.2, i686)
• GNU/Linux 2.4.18 (Debian 3.0/woody, powerpc)
• GNU/Linux 2.6.9 (RedHat ES4, i686)
• Solaris 7 (sparc)
  (This version of Solaris may encounter problems with debugging information. See Known Problems for more information.)
• Solaris 8 (sparc)
  (In order to run under Solaris 8, one or more patches to the operating system are required. Additionally, this version of Solaris may encounter problems with debugging information. See Known Problems for more information.)
• Solaris 9 (sparc)
  (Later versions of Solaris have better threading implementations. For this reason, Solaris 9 is the recommended Solaris platform, especially for large deployments.)

• Darwin 6.x,7.x,8.x/MacOS 10.2.x,10.3.x,10.4.x
  (sem_init is not implemented.)
• Darwin 5.x/MacOS X 10.1.5 and earlier
  (POSIX thread function pthread_kill is missing.)
• NetBSD
  (Pth does not support semaphores.)
• Solaris 2.5.1 and earlier
  (POSIX thread reader/writer locks are missing.)

GCC

Additionally, GCC (confirmed in v2.95.2) should not be used to build -g -O2. This will not happen by default.

Perl

For sites with large numbers of hosts and services, it is recommended to build a multi-threaded version of Perl (using ithreads, not 5005threads) in order for the Perl based checks to run more efficiently. The multi-threaded Perl is only required on the scheduler host, and must be version 5.8.0 or greater.

DNS

Disk I/O

1. Form the multiple disks into a RAID, and configure the state and history directories to be located on the RAID. Depending on the hardware and software of the RAID, it will most likely be RAID 0 (stripe), which increases write concurrency but decreases reliability by having additional points of failure.

2. Establish multiple scheduler instances, and store the data for each instance on a different disk.

Module Dependencies

Perl Module Dependencies can generally be downloaded from http://www.cpan.org. For scheduler check modules and transmit modules, the dependency perl module need only be installed on the scheduler host. For remote check modules, the dependency perl module must be installed on each host being checked. See About Check Modules for a description of scheduler vs. remote check modules.

To facilitate the installation of the more general perl modules, copy the bundle file from src/modules/Bundle/Survivor.pm to ~/.cpan/Bundle/Survivor.pm. Then, start the CPAN shell and install the bundle.

 $ perl -MCPAN -e shell
 cpan> install Bundle::Survivor
 

Modules not listed above should run out of the box. However, it is still important to read each module's documentation to properly configure it to check as desired.

1. First, determine the user and group that the package will be installed as. The default user is survivor. By default, the selected user will own the files that the package generates. No special system level services are required, so privileged users such as root should not be used.

   The default group is staff. Only users in the selected group will be able to run the command line interface. Note that any member of the selected group will have permission to edit the history files. If this is not desirable, then access to the system should not be provided via that command line interface (and those users should not be able to login to the scheduler host). This may be corrected in a future release.

   Important: The selected user must be a member of the selected group in order to properly set group ownership of files and directories.

2. Select an installation directory. By default, the package will install in /usr/local, but for ease of maintenance it may be desirable to use a name like /opt/survivor or /usr/local/survivor. Various subdirectories will be created (if they don't already exist) under the selected directory.

3. Run configure. By default, configure will attempt to build with OpenSSL. If OpenSSL is unavailable, or not in one of the compiler's default include directory, it may be necessary to tell configure. If building with SSL results in errors about openssl/des.h declarations, try adding -DNO_DES to $CXXFLAGS before invoking configure.

   A working version of g++ is required, other compilers may work. (Sun Workshop CC v6 did not previously test successfully.) A working version of lex is also required. flex and Solaris /usr/ccs/bin/lex are both known to work.

   On AIX, it may be necessary to configure --enable-shared=no in order to avoid errors about Cannot load program and Cannot load module libparsexml.a(libexpat.so.0) when starting the scheduler.

   On AIX, it is recommended that GNU tools such as make, install, and flex be used.

   An example using the default user and group but with OpenSSL in a non-default location:

        % ./configure --with-openssl=/opt/openssl
        

   Using a separate build directory, a custom installation directory, and a different username:

        % mkdir obj
        % cd obj
        % ../configure --prefix=/opt/survivor --enable-user=monitor
        

   Configure Option	Default	Description
   --enable-debug	yes	Compile in debugging.
   --enable-group=x	staff	Set the group that the package will be installed as to x.
   --enable-module-serialization	yes	Force module to start one at a time to avoid a race condition. (If disabled, an alternate workaround is implemented.)
   --enable-remote-only	no	If set, configure a build suitable only for remote installation. (No compiled programs will be built.) This is suitable for working with the remote gateway.
   --enable-shared	yes	If set, build subcomponents (eg: libexpat) using shared libraries. On some platforms (AIX), it may be necessary to disable shared libraries.
   --enable-user=x	survivor	Set the user that the package will be installed as to x.
   --prefix=x	/usr/local	Set installation location to x. If set, configure a build suitable only for remote installation. (No compiled programs will be built.) This is suitable for working with the remote gateway.
   --with-openssl[=x]	Yes, found in $PATH	Build with OpenSSL, for components that use SSL. If set, x indicates where to find the OpenSSL installation.

4. After configure runs successfully, type make.

1. In the top level directory, as root, type make install. The following will be installed:
   • INSTDIR/sbin/ss: The survivor scheduler.
   • INSTDIR/sbin/sg: The survivor mail gateway.
   • INSTDIR/sbin/sr: The survivor remote daemon, used by transport modules for certain types of monitoring.
   • INSTDIR/sbin/sw: The survivor CGI (web) interface.
   • INSTDIR/bin/sc: The survivor command line interface.
   • INSTDIR/mod: Various modules distributed with the package.

   SURVIVOR does not depend on the names of the executables. If desired, they may be renamed.

   sg and sw are installed setgid $INSTGROUP by default. This is because they are usually run by other unprivileged users (such as www or sendmail). If these users are members of $INSTGROUP, or if these interfaces will not be used, the setgid bit may be removed.

2. By default, the high performance pingx module is not installed because it must be installed setuid root. Instructions for installing the module are included in the module's documentation.

3. It may be advisable to install the watcher utility.

4. Some types of checks must be executed directly on the server being monitored, as explained in the transport module documentation. The documentation for the remote gateway discusses installation and configuration.