WebDeploy V1.0 -- Web Site Archive Deploy/Gather Application

(c) 1997-8 South Pacific Information Services Ltd
software@spis.co.nz

This program is provided free of charge with SPIS WebQueue
(http://www.spis.co.nz/webcentr/webqueue.htm). You may use it
to provide Web site management functions on as many servers
and sites as you wish, provided it is used in conjunction with at least
one registered copy of SPIS WebQueue for each site it manages.

== Files supplied as part of WebDeploy:

WEBDEPLY.EXE -- application for Win95/98 or WinNT
WEBDEPLY.INI -- application control file

== Installing WebDeploy:

Start by copying both the above files to a directory on your Web
server. (Keep a backup copy of the INI file for future reference).

WebDeploy's functions are all controlled by settings in the WebDeply.INI
file. This means that changes to its behaviour can be made remotely by
simply altering the contents of the INI file and "instructing" it to
re-read the file (see Remote Control section later).

While WebDeploy has a simple user interface which allows you to amend
and add to the control settings, it is usually easiest to start
by editing the INI file directly, so refer to the next section for
information on the settings and alter them to suit your site(s).

Once you are happy with the settings, run WebDeply.EXE and experiment
with viewing and altering them using the user interface. Run a few
tests using the manual and remote control features (including with
WebQueue). Then, when you are happy it is operating correctly, set your
server to auto-start WebDeply.EXE after a reboot (e.g. by placing a
link to it n the StartUp folder on WinNT 4.0).

Note: WebDeply v1.0 cannot run as a service on WinNT, but you can
use the SRVANY utility from the NT resource kit to make it do so.

== Control Settings for WebDeploy:

The key WebDeploy settings (in both INI file and on screen) are:

* Current site. This is stored in the INI file as
[WebCompress]
Site=YourSite

...where Yoursite is any sensible name you wish to use to identify a
given site. WebDeploy can support any number of independent sites on
a server.  In the WebDeploy application, the current site name is shown
in the dropdown list at top left, and can be changed by altering
the dropdown selection.

* Sites list. This is stored in the INI file as:
[WebCompress.Sites]
0=YourSite
1=anotherSite
(and so on)

WebCompress uses this so it knows what sites it is handling on this
server. In the application, these are the names listed in the dropdown
box referred to above.

* Information for each site. In the INI file, this would appear as one
section per site of the following form:
[WebCompress.YourSite]
OriginPath=c:\sites\yoursite
UploadPath=c:\sites\yoursite
AppID=
Password=

The key settings are the first two (you can ignore AppID, and Password
should only be set if you are also setting a password for this site in
WebQueue).

OriginPath is provided purely for security reasons. Basically, ANY file
referenced in a Deploy or Gather operation will be ignored UNLESS it is
in or under the OriginPath location. This might be equivalent to the
actual path of the "FTP root" directory that the site owner has been
given for FTP update purposes.

UploadPath (which often matches OriginPath) is the location where archives
and control/signal files are uploaded, and whether the GATHER.LZH archive
is created for this site by a Gather operation.

* GatherList for each site. If used, this takes this form in the INI file:

[WebCompress.YourSite.GatherList]
1=c:\sites\yoursite\*.log

This instructs WebDeploy to honour a Gather request by creating a
Gather.LZH archive in the current site's UploadPath containing all files
IN  the c:\sites\yoursite directory which match "*.log". If you wanted
it to also search directories UNDER that one, append "/S" to the end of
the file specification, e.g. 
1=c:\sites\yoursite\*.log/S

Gather lists are shown on the WebDeploy main screen, but can only be
edited in the INI file. Usually, however, you don't bother because
they can be remotely specified using WebQueue's own Gather settings.

* User application. This allows a special purpose signal to be used
to run a particular application. The name of the signal file is always
"userapp.sig". If found in ANY upload path, the UserApp application will
be executed on the server. Note that this setting should only be used
if you know exactly what you are doing as it can open a security hole
if any of your users have the ability to see or modify your WebDeply.INI
file. Settings in the INI file are:
[WebCompress]
UserSignal=UserApp.sig    (never changes)
UserApp=notepad.exe       (application name or preferably full path)

* Responsiveness to remote control signals. This may only be needed when
running WebDeploy in test mode on a Win95 system, which allocates idle time
differently from WinNT. The INI setting for it is:
[WebCompress]
Responsive=1   (0 would be normal)

The equivalent WebDeploy program setting is the checkbox at top right of
the screen. Though it makes WebDeploy quicker to notice signal files,
this comes at a cost of slightly increased CPU time use, so don't turn
it on on a WinNT server unless you feel you must.

== Remote Control of WebDeploy

Once WebDeploy is running, it operates in the background on your Web
server, checking the UploadPath location for each site every 10-20
seconds for the existence of one of the following SIGNAL files:

DEPLOY.SIG -- deploy any archives in this directory
GATHER.SIG -- gather the GatherList files into GATHER.LZH
REFRESH.SIG -- re-read the WebDeply.INI file and use the new values
USERAPP.SIG -- run the defined User Application, if any

If it finds one of the signal files, it deletes it (which confirms to
an observer that it has "noticed" the signal) and then performs the
requested operation.

In the case of Deploy and Gather operations, it finishes up by
creating a file called STATUS.TXT in the UploadPath which contains
the results of the operation (e.g. a list of files deployed). It also deletes all archives that were deployed (including any that failed,
for whatever reason).

WebQueue uses the "upload signal file, signal file is deleted,
status.txt is created" sequence to keep you informed about what it
believes the site is doing. You can keep the same watch yourself
by using an FTP program to check the UploadPath directory, refreshing
it every few seconds to spot the appearance and deletion of the signal
files and the arrival of the Status file.
