			  TARBALL INSTALLER

Olympus will provide for installing tar balls from source and track
which files are installed in a database for querying and uninstalling
at a later date.  In this second version of this file we will be
considering a tarball installer that installs using a sequence of four
messages to install software on the server.

NOTE: These assumptions are made about the Olympus tarball
installation. (1) the tarball initially is accessible on the client
host (2) The file when the tarball is expanded reside in one
directory, (3) The source tree for this tarball is assumed to have a
GNU auto configure script that is to be run from the top level
directory, (4) The command "make install" actually executes the
program "install".

netmessage (1).  Transfer the tarball to the server. (a) transfer the
tempfile. (b) send it to the server. (c) the server copies the
tempfile to the tarball in the $OLYMPUS/tmp directory.  Run tar to
expand this file into the source tree.

netmessage (2).  Execute ./configure.  Return the exit code and the
output.

netmessage (3).  Execute "make".  Return the exit code and the output.

netmessage (4).  Execute "make install".  Return the exit code and the
output.  When make executes "install", the PATH will execute a special
install that will create a temporary file to store installed file.

The external program that performs each of these actions takes the
following command line arguments: (1) session id, (2) a path to
$OLYMPUS/bin, (3) a path to $OLYMPUS/tmp, followed by arg[0-n] for the
command to execute.

The value of OLYMPUS is passed to netmessage::activate.  This program
assigns PATH the value $OLYMPUS/bin:$PATH before executing "tar zxvf",
"./configure", "make" and "make install" each with the popen(3) system
call.  The input from popen() would be saved until the processes
completed.  The data written to standard output would start with 4
bytes for the of the session id followed by 4 bytes for the netmessage
type.  This allows the process to tell the server which type of
netmessage returns the data to the client.  After that the rest of the
data would follow.

In the server connection loop, the activate() method returns a non
zero file handle to signify that that value is a file handle to add to
the list of file descriptors to poll for activity.  When the file
handle is active, the server will poll it for activity.  When it
becomes active the server will read the first 8 bytes which will give
it the the sessionID and the netmessage type.  From these the server
can create the correct netmessage.

The netmessage that is created as a result will read back the list of
files, insert them into the database, pack the output from "configure" 
