| ↩︎ | ↖︎ | ↑︎ | ↘︎ | ↪︎ |
The WASD package is distributed as ZIP archives.
It generally pays to use the latest version of VMS UNZIP available. Archives will contain a comment about the minimum version required, check that as described in the next paragraph. To show the version of the current UNZIP utility, use
The ZIP archive will contain brief installation instructions. Use the following command to read this and any other information provided.
It is recommended to check the integrity of, then list the contents of, the archive before UNZIPing.
The archive will have the structure:
The archive contains the complete directory tree. Hence it is necessary to SET DEFAULT into the top-level directory of the volume the package is to be installed on.
The complete package, source code, documentation, examples, etc., is provided in a single main archive. Installation and other build procedures allow the entire package to be compiled and linked from this if prefered. This requires a later version of DEC C (preferably v6.n or greater).
In addition, for those unable or not wishing to fully build the distribution, three other platform-specific archives are available, AXP (Alpha) IA64 (Itanium) and VAX, containing a complete set of object modules, allowing the package to be built via a link operation only.
If a complete build is planned then only the main archive is required. If a link-only build then an additional archive for each architecture must be UNZIPed as described above. This applies to both full installations and subsequent updates. The archives will be clearly identified with the architecture type, as illustrated in this example.
OpenSSL is no longer supported for VAX.
Building an SSL-capable version of the server is a common requirement. WASD SSL is discussed in detail in Transport Layer Security of WASD Features and Facilities. and if using the WASD SSL package it is also possible to install (or update) that package after UNZIPing the primary archive and optional object module(s). As noted in the above SSL section, the server can also be built against an existing VMS SSL product and an existing OpenSSL installation.
Expat is an XML parser required for WASD WebDAV. From WASD v11.5.0 the Expat library uses 64 bit data types unavailable to the 32 bit VAX CPU. WASD v11.5.0 and later on VAX requires the replacement of the 64 bit Expat directory with the earlier 32 bit Expat release. The WASD download page notes this and provides an archive of the 32 bit release. After download, UNZIP, and before building, the following additional step is required.
The package directories and content are organised as follows. Note that only some of these can be accessed by the server account (and therefore seen in server-generated directory listings) due to directory and file protections (see Recommended Package Security in WASD Configuration).
Package Directory Structure
| Directory | Description |
|---|---|
| [AXP-BIN] | Alpha executable script files |
| [AXP] | Alpha build and utility area |
| [CGI-BIN] | architecture-neutral script files |
| [EXAMPLE] | package examples |
| [EXERCISE] | package test files |
| [HTTP$NOBODY] | scripting account default home area |
| [HTTP$SERVER] | server account default home area |
| [IA64-BIN] | Itanium executable script files |
| [IA64] | Itanium build and utility area |
| [INSTALL] | installation, update and security procedures |
| [LOCAL] | site configuration files |
| [LOG] | site access logs |
| [LOG_SERVER] | server process (SYS$OUTPUT) logs |
| [RUNTIME] | graphics, help files, etc. |
| [SCRATCH] | working file space for scripts |
| [SCRIPT] | example architecture-neutral scripts |
| [SRC] | package source files |
| [STARTUP] | package startup procedures |
| [VAX-BIN] | VAX executable script files |
| [VAX] | VAX build and utility area |
| [WASDOC] | package documentation |
The WASD package can be installed on and used from ODS-5 (extended file specification) volumes. Note that the installation procedures and file system organisation of the package tree has been designed for ODS-2 compliance. (Of course the issue of installing WASD on an ODS-5 volume is completely separate from the ability to serve the contents of an ODS-5 volume!)
Unlikely as it might be to install the package on a private or otherwise protected volume, the server and scripting accounts being unprivileged in themselves, require access sufficient to read, write and delete files from the volume (disk). The following illustrates how to check this and what the protections should look like. Generally any device that an unprivileged user can use the server accounts can use.
Should WASD_ROOT be located on a volume with disk quota enabled then suitable entries must exist for the server account (default HTTP$SERVER), SYSTEM account, and any scripting account(s) (default HTTP$NOBODY). The server account requires quota for the server process log, SYSTEM (due to SYSPRV use) for access log(s), and scripting account(s) requiring default temporary storage ([SCRATCH]) during processing.
As of WASD v10.1 the minimum supported version for build and operation is VMS V7.0. Had to drag ourselves into the mid-1990s at some stage!
Also, when the server image begins execution it may add an identifier, required for script process management, to RIGHTSLIST.DAT.
These behaviours must be considered in site environments where such changes are prohibited or closely controlled.
The WASD installation assumes that the system's TCP/IP infrastructure is correctly installed and configured, and is operating normally. For example, it is not unknown for a freshly built system to experience host name resolution problems preventing its own host name from being resolved and making even elementary server startup impossible.
The INSTALL.COM procedure assists with the first installation of WASD. It provides a vanilla setup, using the standard directories and account environment described in this document. All sections prompt before performing any action and generally default to "no". Read the information and questions carefully!
After UNZIPing the package do the following:
It performs the following tasks:
Support files to consider when customizing startup, etc. (4.3 Account Support Files):
Once installed or updated it is possible to check the basic package at any time using the [INSTALL]DEMO.COM procedure. This invokes the server image using the /DEMO qualifier allowing some behaviours not possible under general use. Follow the displayed instructions. Basically, the server should start and become reachable via port number 7080. So, to test availability, using your prefered browser enter the URL listed on line starting with "%HTTPD-I-SERVICE" and the WASD welcome page should be displayed.
If a TLS (SSL) -enabled server has been built the demonstration server will also provide a TLS port number 7443 for access (this also can be explicitly activated using @[INSTALL]DEMO.COM SSL). WASD will dynamically generate a X509 certificate for use by the service. In modern browsers there are security constraints associated with self-signed certificates — lots! Interestingly, Incognito/[In]Private instances of a browser are often more relaxed about accepting certificates with security deficiencies (at least at the time of writing), so perhaps try those with the demonstration server. Also see Server Certificate in WASD Features.
When http://the.host.name:7080 is accessed the browser should display the package home page
Package updates will never contain anything in these directories:
To prevent the overwriting of local configuration files it is suggested these be placed in the WASD_ROOT:[LOCAL] directory. Local authentication databases could also be placed in the [LOCAL] directory. Startup files can be placed where the local site manages system startup. These could be placed in the WASD_ROOT:[STARTUP] directory.
This package, as is generally the case with freeware, is mainly developed and supported outside of the author's main occupation and working hours. Reports of problems and bugs (while not necessarily welcome :-), as well as general queries, are responded to as soon as practicable. If the documentation is inaccurate or could benefit from clarification in some area please advise of this also (the better the documentation the less queries you have to field personally … or so the theory goes).
With all reports please include the version of the server or script, and the hardware platform, operating system and TCP/IP package and version in use.
If a server error message is being generated please examine the HTML source of the error page. The "<META...>" information contains version information as well as valuable source code module and line information. Include this with the report.
If the server is exiting with a server-generated error message this information also contains module and line information. Please include this with the report.
The WATCH facility is often a powerful tool for problem investigation. It is also very useful when supplying details during problem resolution. When supplying WATCH output as part of a problem report please ZIP the file and include it an an e-mail attachment. Mailers often mangle the report format making it difficult to interpret.
Image crash dumps may also be generated, although these are of less value than the case of the previous two.
Reports may be e-mailed to [email protected]
| ↩︎ | ↖︎ | ↑︎ | ↘︎ | ↪︎ |