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
$ UNZIP -v
The ZIP archive will contain brief installation instructions. Use the following command to read this and any other information provided.
$ UNZIP -z device:[dir]archive.ZIP
It is recommended to check the integrity of, then list the contents of, the archive before UNZIPing.
$ UNZIP -t device:[dir]archive.ZIP $ UNZIP -l device:[dir]archive.ZIP
The archive will have the structure:
Archive: SYS$SYSDEVICE:[WASD]WASD1100.ZIP;1 WASD VMS Web Services, Copyright (C) 1996-2016 Mark G.Daniel. This package (all associated programs), comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under the conditions of the GNU GENERAL PUBLIC LICENSE, version 3, or any later version. http://www.gnu.org/licenses/gpl.txt * Full release of v11.0.0 (May 2016) ************************************************** *** CONTAINS SOURCE FILES, DOCUMENTATION, ETC. *** ************************************************** Package must be built using INSTALL or UPDATE as described below. * To install files: $ SET DEFAULT device: $ UNZIP device:[dir]WASD1100.ZIP * To build/link images use the appropriate one of: $ @device:[WASD_ROOT]INSTALL $ @WASD_ROOT:UPDATE 8< snip 8< VMS file attributes saved ... use UnZip 5.2+ on OpenVMS Archive created 1-MAY-2016 Length Date Time Name -------- ---- ---- ---- 0 04-17-16 00:50 wasd_root/axp-bin/ 0 04-17-16 00:50 wasd_root/axp/ 0 04-17-16 00:50 wasd_root/cgi-bin/ 0 04-17-16 00:51 wasd_root/doc/ 0 04-17-16 00:51 wasd_root/example/ 0 04-17-16 00:51 wasd_root/exercise/ 2734 03-06-03 17:20 wasd_root/favicon.ico 8< snip 8< 270 11-05-09 06:59 wasd_root/startup/readme.html 426 11-05-09 06:38 wasd_root/vax-bin/readme.html 452 11-05-09 06:18 wasd_root/vax/readme.html -------- ------- 20288784 919 files
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.
$ SET DEFAULT device: $ UNZIP device:[dir]archive.ZIP
Updating From v9.3 or Earlier
Before UNZIPing the v11 package and when updating an existing v9.3 or earlier installation the root directory must be renamed from HT_ROOT.DIR to WASD_ROOT.DIR. The v10 and later packages use [WASD_ROOT] as the top-level directory in line with other naming schema changes employing "WASD". Remember to modify local startup procedures in-line with this new top-level directory name. Also note that the v11 package is not suitable for updating from existing v8.0 or earlier installation.
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 UNZIPped 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.
$ UNZIP device:[dir]archive-AXP.ZIP $ UNZIP device:[dir]archive-IA64.ZIP $ UNZIP device:[dir]archive-VAX.ZIP
The WASD distribution and package organisation fully supports mixed-architecture clusters (AXP, Itanium and/or VAX in the one cluster) as one integrated installation.
Building an SSL-capable version of the server is a common requirement. WASD SSL is discussed in detail in "WASD VMS Web Services - Features and Facilities"; 4 - Transport Layer Security WASD Web Services - 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.
The WASD OpenSSL kit is designed as an update to an existing WASD installation and so expects to be UNZIPed under the root directory. Note the use of the "-d" switch in the following example.
$ UNZIP -d [.WASD_ROOT] device:[dir]OPENSSLWASDnnn-arch.ZIP
When installing an archive as an update to an existing installation consider the following.
$ BACKUP WASD_ROOT:[000000...] location:WASDROOT.BCK/SAVE/VERIFY $ ZIP "-V" location:WASDROOT.ZIP device:[WASD_ROOT...]*.* $ ZIP "-T" location:WASDROOT.ZIPIf using ZIP then ensure that a previous version of the target ZIP file does not already exist. If it does then that version is updated, a new version is not created.
$ SET DEFAULT device: $ UNZIP device:[dir]archive-AXP.ZIP ht_root/src/httpd/obj_axp/*.*
Multiple, independent installations and builds of WASD are supported. See 2.13 - Multiple Installations later in this chapter.
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.
$ SHOW SECURITY /CLASS=VOLUME DKA0: ALPHASYS object of class VOLUME Owner: [1,1] Protection: (System: RWCD, Owner: RWCD, Group: RWCD, World: RWCD) Access Control List: <empty>
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 (5.1 - Recommended Package Security).
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 WASD installation procedure does, and to a lesser degree the update procedure can, make additions and/or modifications to SYSUAF.DAT and RIGHTLIST.DAT, for default server and scripting accounts and to facilitate their access to the package directory tree.
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 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:
$ SET DEFAULT device:[WASD_ROOT] $ @INSTALL
It performs the following tasks:
Support files to consider when customizing startup, etc. (see 3.3 - Account Support Files for further detail):
The UPDATE.COM procedure assists with subsequent updates of WASD. It assumes 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 questions carefully!
Updating From v9.3 or Earlier
Before UNZIPing the v11 package and when updating an existing v9.3 or earlier installation the current root directory must be renamed from HT_ROOT.DIR to WASD_ROOT.DIR. The v10 and later packages use [WASD_ROOT] as the top-level directory in line with other naming schema changes employing "WASD". Remember to modify local startup procedures in-line with this new top-level directory name. Also note that the v11 package is not suitable for updating from an existing v8.0 or earlier installation.
Of course it is best (read mandatory) for the server to be shut down during an update!
After UNZIPing the updated package do the following:
$ SET DEFAULT WASD_ROOT: $ @UPDATE
It provides the following functions:
If declined during the update procedure the post-update steps 6 and 7 can be performed at any subsequent time using
$ SET DEFAULT WASD_ROOT: $ @UPDATE CLEANUP $ PURGE [...]
Linking the server code against older versions of OpenSSL (less likely) or the HP SSL product (more likely, V1.4 for instance) will result in the reporting of one, two or three undefined symbols (usually one or two as shown below).
%LINK-W-NUDFSYMS, 1 undefined symbol: %LINK-I-UDFSYM, SSL_GET_SERVERNAME %LINK-W-NUDFSYMS, 2 undefined symbols: %LINK-I-UDFSYM, TLSV1_1_METHOD %LINK-I-UDFSYM, TLSV1_2_METHODAny of these three reports may safely be ignored as the server is designed to detect the absence and disable the related functionality.
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.
$ @WASD_ROOT:[INSTALL]DEMO.COM ******************************* * WASD PACKAGE DEMONSTRATOR * ******************************* When finished using demonstrator abort server execution using control-Y (a subprocess will be spawned to preserve current process environment) Use a browser to access either of the "%HTTPD-I-SERVICE"s when the server starts. (There will be one for a standard service and another for SSL.) The server will be running in promiscuous mode! Any username with the password specified below can be used for authentication. Enter a string to use as a password when later prompted by your browser. Password (for demo authentication)? : anyoldpassword %DCL-S-SPAWNED, process SYSTEM_61053 spawned %DCL-S-ATTACHED, terminal now attached to process SYSTEM_61053 %HTTPD-I-SOFTWAREID, HTTPd-WASD/11.0.0 OpenVMS/AXP SSL WASD VMS Web Services, Copyright (C) 1996-2016 Mark G.Daniel. This package (all associated programs), comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under the conditions of the GNU GENERAL PUBLIC LICENSE, version 3, or any later version. http://www.gnu.org/licenses/gpl.txt %HTTPD-I-STARTUP, 01-MAY-2016 22:39:04 %HTTPD-I-ALIGN, start collecting alignment faults (64kB,128,0xFFFFFFF0) %HTTPD-I-WASD_ROOT, $1$DKA0:[WASD_ROOT] %HTTPD-I-ENVIRONMENT, 0 %HTTPD-I-SYSTEM, Digital Personal WorkStation VMS V8.3 %HTTPD-W-SYSPRV, operating with implicit SYSPRV (UIC group 1) %HTTPD-I-TCPIP, HP TCPIP$IPC_SHR V5.7-ECO1 (21-MAY-2010 14:44:46.64) %HTTPD-I-MODE, INTERACTIVE %HTTPD-I-ODS5, supported by Alpha VMS V8.3 %HTTPD-I-GMT, +09:30 %HTTPD-I-INSTANCE, supervisor %HTTPD-I-GZIP, using GNV$LIBZSHR32 V1.2.8 %HTTPD-I-GBLSEC, created global section of 16 page(let)s %HTTPD-I-INSTANCE, 1 process %HTTPD-I-SSL, OpenSSL 1.0.2g 1 Mar 2016 -SSL-I-PROTOCOL, TLSv1,TLSv1.1,TLSv1.2 -SSL-I-OPTIONS, 0x80510BFF -SSL-I-SNI, Server Name Indication enabled -SSL-I-DH, ephemeral DH param 1024,2048 bits %HTTPD-I-HTTP2, enabled %HTTPD-W-HTTP2, network/mailbox read buffer size increased to 16384 bytes %HTTPD-I-INSTANCE, process name WASD:7080 %HTTPD-I-WEBDAV, disabled %HTTPD-W-AUTH, 1 informational, 1 warning, 0 errors at load 1.w PROMISCUOUS authenticating any username with specified password! 2.i Cache for 32 records of 768 bytes in local storage of 49 page(let)s %HTTPD-W-MAP, 1 informational, 0 warning, 0 errors at load 1.i ODS-5 processing enabled %HTTPD-I-PROXYVERIFY, for 32 records in local storage of 14 page(let)s %HTTPD-I-SCRIPTING, as HTTP$NOBODY %HTTPD-I-DCL, subprocess scripting %HTTPD-I-ACTIVITY, created global section of 1312 page(let)s %HTTPD-I-SERVICE, http://klaatu.private:7080 %HTTPD-I-SERVICE, https://klaatu.private:7443 %HTTPD-I-SSL, klaatu.private:7443 %HTTPD-I-DEMO, demonstration mode 1.i subprocess scripting 2.i promiscuous authentication 3.i directory access control files ignored 4.i [DirAccess] enabled 5.i [DirMetaInfo] enabled 6.i [DirWildcard] enabled 7.i [Logging] disabled 8.i [ReportBasicOnly] disabled 9.i [ReportMetaInfo] enabled %HTTPD-I-BEGIN, 01-MAY-2016 22:39:05, accepting requests
When http://the.host.name:7080 is accessed the browser should display the package home page
The WASD server which is started by the [INSTALL]DEMO.COM procedure does not have the full environment setup at that time. It is deliberately limited to the single process context. For instance, do not try to execute the command-line directives described in this document.
The [INSTALL]CLONE.COM procedure assists in creating a ZIP archive of an existing WASD installation suitable for recreating the server on another system without the necessity of a full installation. This could be used to populate a series of systems with pre-configured servers.
After a major update to the operating system the package may refuse to start, reporting a message like:
%DCL-W-ACTIMAGE, error activating image WHATEVER -CLI-E-IMGNAME, image file DKA0:[SYS0.SYSCOMMON.][SYSLIB]WHATEVER_SHR.EXE -SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
This implies the executables require re-linking for your particular version of VMS. This can be accomplished quite simply, perform the linking section only of the update DCL procedure, 2.8 - Update DCL Procedure.
It is possible, and often useful, to build another WASD on a system with an existing and/or running installation. One purpose might be to maintain the previous version as a fallback in case of unexpected problems when migrating to a more recent version. Another, to maintain multiple releases for regression testing.
The general process is as follows:
$ SET DEFAULT device: $ UNZIP -d [.BLAH] device:[dir]archive.ZIPDo the same with object module archive(s) if required.
$ UNZIP -d [.BLAH.WASD_ROOT] device:[dir]OPENSSLWASDnnn-arch.ZIP
$ RENAME [.BLAH]WASD_ROOT.DIR WASD_ROOT_nnnn.DIR $ DELETE BLAH.DIR;*
$ SET DEFAULT [WASD_ROOT_nnnn] $ @INSTALL INSTALLThe INSTALL parameter overrides the install check and advisory message otherwise generated:
***************************************** * "WASD_ROOT" LOGICAL NAME DETECTED. * * THIS DOES NOT LOOK LIKE AN INSTALL! * *****************************************
$ COPY WASD_ROOT:[LOCAL]*.* [WASD_ROOT_nnnn.LOCAL]Other site-specific localisations similarly may need to be copied or otherwise reproduced.
To move the running WASD environment from one installation to another:
$ @device:[WASD_ROOT_nnnn.STARTUP]STARTUP.COMWASD logical names and environment will reflect the particular WASD root directory.
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!
WASD does not build or run under VMS 5.5-2 or earlier.
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-ever 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