Complete installation directions for Condor can be found in the Condor
Manual.  The complete Condor Manual is available for download or
online browsing at URL:
   http://www.cs.wisc.edu/condor/manual

We recommend that you go to the above URL and download the Condor
Manual.  However, section 3.3.3 of the 6.0 manual, which provides
installation directions for the CondorView Server contrib module, is
reproduced below in ASCII.

     _________________________________________________________________

3.3.3 Installing the CondorView Server Module

   The CondorView server is just an enhanced version of the
   condor_collector which can log information to disk, providing a
   persistant, historical database of your pool state. This includes
   machine state, as well as the state of jobs submitted by users, and so
   on. This enhanced condor_collector is simply the version 6.1
   development series, but it can be installed in a 6.0 pool. The
   historical information logging can be turned on or off, so you can
   install the CondorView collector without using up disk space for
   historical information if you don't want it.
   
   To install the CondorView server, you must download the appropriate
   binary module for whatever platform you are going to run your
   CondorView server on. This does not have to be the same platform as
   your exisiting central manager (see below). Once you uncompress and
   untar the module, you will have a directory with a view_server.tar
   file, a README, and so on. The view_server.tar acts much like the
   release.tar file for a main release of Condor. It contains all the
   binaries and supporting files you would install in your release
   directory:
        sbin/condor_collector
        sbin/condor_stats
        etc/examples/condor_config.local.view_server

   You have two options to choose from when deciding how to install this
   enhanced condor_collector in your pool:
   1.
          Replace your exisiting condor_collector and use the new version
          for both historical information and the regular role the
          collector plays in your pool.
   2.
          Install the new condor_collector and run it on a seperate host
          from your main condor_collector and configure your machines to
          send updates to both collectors.
          
   If you replace your existing collector with the enhanced version,
   because it is development code, there might be a bug or problem that
   would cause problems for your pool. On the other hand, if you install
   the enhanced version on a seperate host, if there are problems, only
   CondorView will be affected, not your entire pool. However, installing
   the CondorView collector on a seperate host generates more network
   traffic (from all the duplicate updates that are sent from each
   machine in your pool to both collectors). In addition, the
   installation procedure to have both collectors running is a more
   complicated process. You will just have to decide for yourself which
   solution you feel more comfortable with.
   
   Before we discuss the details of one type of installation or the
   other, we explain the steps you must take in either case.
   
  Setting up the CondorView Server Module
  
   Before you install the CondorView collector (as described in the
   following sections), you have to add a few settings to the local
   config file of that machine to enable historical data collection.
   These settings are described in detail in the Condor Version 6.1
   Administrator's Manual, in the section ``condor_collector Config File
   Entries''. However, a short explaination of the ones you must
   customize is provided below. These entries are also explained in the
   etc/examples/condor_config.local.view_server file, included in the
   contrib module. You should just insert that file into the local config
   file for your CondorView collector host and customize as appropriate
   at your site.
   
   POOL_HISTORY_DIR
          This is the directory where historical data will be stored.
          There is a configurable limit to the maximum space required for
          all the files created by the CondorView server
          (POOL_HISTORY_MAX_STORAGE). This directory must be writable by
          whatever user the CondorView collector is running as (usually
          "condor"). NOTE: This should be a seperate directory, not the
          same as either the Spool or Log directories you have already
          setup for Condor. There are a few problems putting these files
          into either of those directories.
          
   KEEP_POOL_HISTORY
          This is a boolean that determines if the CondorView collector
          should store the historical information. It is false by
          default, which is why you must specify it as true in your local
          config file.
          
   Once these settings are in place in the local config file for your
   CondorView server host, you must to create the directory you specified
   in POOL_HISTORY_DIR and make it writable by whomever your CondorView
   collector is running as. This would be the same user that owns the
   CollectorLog file in your Log directory (usually, ``condor'').
   
   Once those steps are completed, you are ready to install the new
   binaries and you will begin collecting historical information. Then,
   you should install the CondorView client contrib module which contains
   the tools used to query and display this information.
   
  CondorView Collector as Your Only Collector
  
   To install the new CondorView collector as your main collector, you
   simply have to replace your existing binary with the new one, found in
   the view_server.tar file. All you need to do is move your existing
   condor_collector binary out of the way with the ``mv'' command. For
   example:
        % cd /full/path/to/your/release/directory
        % cd sbin
        % mv condor_collector condor_collector.old

   Then, from that same directory, you just have to untar the
   view_server.tar file, into your release directory, which will
   install a new condor_collector binary, condor_stats, a tool that
   can be used to query this collector for historical information and
   an example config file.  Within 5 minutes, the condor_master will
   notice the new timestamp on your condor_collector binary, shutdown
   your existing collector, and spawn the new version. You will see
   messages about this in the log file for your condor_master (usually
   MasterLog in your log directory). Once the new collector is
   running, it is safe to remove your old binary, though you may want
   to keep it around in case you have problems with the new version
   and want to revert back.

  CondorView Collector in Addition to Your Main Collector
  
   To install the CondorView collector in addition to your regular
   collector requires a little extra work. First, you should untar the
   view_server.tar file into some temporary location (not your main
   release directory). Copy the sbin/condor_collector file out of there,
   and into your main release directory's sbin with a new name (such as
   condor_collector.view_server).  You will also want to copy the
   condor_stats program to your sbin release directory.
   
   Next, you must configure whatever host is going to run your seperate
   CondorView server to spawn this new collector in addition to whatever
   other daemons it's running. You do this by adding ``COLLECTOR'' to the
   DAEMON_LIST on this machine, and defining what ``COLLECTOR'' means.
   For example:
        DAEMON_LIST = MASTER, STARTD, SCHEDD, COLLECTOR
        COLLECTOR = $(SBIN)/condor_collector.view_server

   For this change to take effect, you must actually re-start the
   condor_master on this host (which you can do with the condor_restart
   command, if you run that command from a machine with ``ADMINISTRATOR''
   access to your pool. (See section 3.7 for full details of
   IP/host-based security in Condor). 
   
   Finally, you must tell all the machines in your pool to start sending
   updates to both collectors. You do this by specifying the following
   setting in your global config file:
        CONDOR_VIEW_HOST = full.hostname

   where ``full.hostname'' is the full hostname of the machine where you
   are running your CondorView collector.
   
   Once this setting is in place, you must send a condor_reconfig to your
   entire pool. The easiest way to do this is:
        % condor_reconfig `condor_status -master`

   Again, this command must be run from a trusted ``administrator''
   machine for it to work.
