|1New to WASD? Start Here!|
|0Welcome!|
|^ WASD is outlined in the
|link%|../features/##Introduction| and
|link%|../features/##Package Overview| sections of the
|link%|../features/##|WASD Features| document.
|^ There are a number of approaches to installing and updating a WASD package.
|^-The |/vanilla recipes| are |link|Installation| and |link|Update| but there are
|link|Other Ways to Deploy||.
|^ This section provides a quick guide to getting your WASD package installed,
configured and serving.
|number|
|item| |*Unzip Package||
|^ Install the files following the guidelines in |link|Installation||.
|^- |*Note| that more than one archive may be needed
(|link|Source Archive, Object Module Archives)||).
|^ If |*Transport Layer Security| (TLS - a.k.a. |*Secure Sockets Layer||
- SSL) is to be used and a TLS/SSL server image to be built the WASD [Open]SSL
product must be installed at this stage (see
|link%|../features/##TLS/SSL Functionality Sources++of++WASD Features and Facilities||).
An existing VSI SSL111 for OpenVMS product (all based on OpenSSL 1.0.2 and
earlier obsolete) requires no additional step. If the WASD [Open]SSL package
it must UNZIPed into the [.WASD_ROOT] tree at this stage.
|code|
$ UNZIP -d [.WASD_ROOT] device:[dir]OPENSSLWASD|/nnn-arch||.ZIP
|!code|
|^ Note the use of the |*."-d" switch||.
|item| |*INSTALL Package||
|^ Server installation is performed using the INSTALL.COM procedure
(|link|INSTALL.COM procedure||).
|bullet|
|item| |*Build Package |-| |
Compile and link, or just link supplied object files to produce VMS
executables for the system's version of VMS.
|item| |*Check Package |-| |
Check basic operation of the package (|link|Quick Check||).
|item| |*Create Server and Scripting Accounts |-| |
Create two independent accounts, one for executing the server, the other for
executing scripts (|link|VMS Server Account||). If quotas are enabled on
the target disk provides an ambit allocation for these accounts. Review this
at some stage.
|item| |*Set Package Security |-| |
This sections traverses the newly installed tree and sets all package
directories and files to required levels of access
(|link%|../config/##Maintaining Package Security++in++WASD Configuration||).
|item| |*Copy Support and Configuration Files |-| |
Copy the example server support and configuration files
(|link|Account Support Files||).
|item| |*Install Scripts |-| |
Selectively copy groups of scripts from package build directories into the
scripting directories.
|!bullet|
|item| |*Configure Package||
|^ Following the execution of the INSTALL.COM procedure the package should
require only minor, further configuration.
|^ |*Initially| two files may require alteration.
|number|
|item| The startup file, possibly to set the local WASD_CONFIG_GMT logical (for
systems not supporting DTSS (e.g. DECnet-Plus)). Consider using the
STARTUP_LOCAL.COM file for other site-specific requirements
(|link|Account Support Files||).
|item| The only configuration that should require immediate attention will be
the mapping rules
(|link%|../config/##Request Processing Configuration++in++WASD Configuration||).
|!number|
|^ |*More generally| server runtime configuration involves the considerations
discussed in |link%|../config/##Site Organisation++of++WASD Configuration|
along with the following aspects:
|bullet|
|item| Configuring the HTTP server run-time characteristics
(|link%|../config/##Configuration Considerations++in++WASD Configuration||).
|item| Mapping request paths to the VMS file system, and to other things such as
scripts
(|link%|../config/##Request Processing Configuration++in++WASD Configuration||).
|item| Customizing some or all messages
(|link%|../config/##Message Configuration++in++WASD Configuration||).
|item| Establishing an authentication and authorization environment
(|link%|../config/##Authorization Configuration (Basics)++in++WASD Configuration||).
|!bullet|
|item| |*Start Server||
|^ Execute the startup procedure (|link|STARTUP.COM||).
Get your browser and connect!
|item| |*Find Out What's Wrong| |'_frowny.\ |
|^ Of course |/something| will not be right! This can happen with
the initial configuration and sometimes when changing configuration. The
server provides information messages in the run-time log, look in the
WASD_ROOT:[LOG_SERVER] directory.
|^ Remember, the basic installation's integrity can always be checked
as described in |link|Quick-Check||).
This uses the configuration files from the [EXAMPLE] directory, so provided
these have not been altered the server should execute in
|/demonstration mode| correctly.
|^ Can't resolve it? See |link|Reporting Problems||.
|!number|
|2Using IA64-hosted X86 Cross-Complier?|
|^ Until a native X86 C compiler becomes available all WASD package and
additional application builds must be done in two phases.
|number|
|item| cross-compile on an IA64 system
|item| link resulting object file(s) on the X86 system
|!number|
|^ When building using the cross-compiler tools the procedures recognise the
XCC$COMPILER environment and adjust to create and use |= [.OBJ_X86_64]| object
code directories.
|^ For example; to build WASD package:
|number|
|item| On IA64 ensure |= @SYS$MANAGER:X86_XTOOLS$SYLOGIN.COM| and then select
"3. Compile only" and complete the compilation.
|bullet|
|item| For clustered IA64/X86 with an MSCP-mounted volume containing a shared
|= [WASD_ROOT]| the appropriate object files are now available to the X86
system.
|^ Proceed with the second phase.
|item| For non-clustered build environments the same WASD kit must be installed
on both IA64 and X86 systems. After compilation the resulting |= [.OBJ_X86_64]|
directories must be ZIPed into an archive, transferred to the X86 system and
restored into the corresponding |= [WASD_ROOT]||.
|^ For example:
|code|
IA64$ SET DEFAULT |/device||:[WASD_ROOT]
IA64$ ZIP "-V" |/location||:X86_1200_OBJ.ZIP [...OBJ_X86_64]*.OBJ
|!code|
|code|
X86$ SET DEFAULT |/device||:[WASD_ROOT]
X86$ UNZIP |/location||:X86_1200_OBJ.ZIP
|!code|
|^ Proceed with the second phase.
|!bullet|
|item| On X86 perform the corresponding "2. linking (separate package) object
modules", and continue the rest of the installation.
|!number|
|2Troubleshooting?|
|^ When initially installing or configuring WASD, and sometimes later where
something breaks spectacularly, it is most useful to be able to gain insight
into what the server is up to.
|^ The |/go-to| tool is\ |"WATCH||\
(yes, all capitals, and for no other reason than it makes it stand out).
|^ WATCH is described in detail in
|link%|../features/##WATCH Facility++of the++WASD Features and Facilities||
document.
|^ For most circumstances WATCH can be made available for troubleshooting even
if the configuration is significantly broken. This is done by using a
skeleton-key to authorise special access into the server.
|^ The skeleton-key is described in detail in
|link%|../features/##Skeleton-Key Authentication++of the++WASD Features and Facilities||
document.
|^ |*TL;DR|
|^ Enable at the command-line with the username anything beginning with an
underscore and at least 8 characters, same for the password length.
|code|
$ HTTPD /DO=AUTH=SKELKEY=_|/username||:|/password||
|!code|
|^ Then using a browser access any available service, entering the above
username (including underscore) and password when prompted.
|block|
|link%|/httpd/-/admin/report/WATCH|https://\the.host.name:port\\ /httpd/-/admin/report/WATCH|
|!block|
|^ The service administration facilities (of which WATCH is one) are also
available and useful.
|block|
|link%|/httpd/-/admin/|https://\the.host.name:port\\ /httpd/-/admin/|
|!block|