|1Introduction|

|0Welcome!|

|^ WASD is outlined in the
|link%|../features/##Introduction| and
|link%|../features/##Package Overview| sections of the
|link%|../features/##|WASD Features| document.

|^ Installation and update of the package is covered by
|link%|../install/##|WASD Installation||.

|^ This document provides detailed configuration instructions of the WASD Web
Services package.

|^ Following installation the package should require only minor further
configuration for basic serving.

|^ WASD configuration is performed using the contents of five files located
using logical names

|table|
|~ |. WASD_CONFIG_AUTH |. request authorization control
|~ |. WASD_CONFIG_GLOBAL |. global server configuration
|~ |. WASD_CONFIG_MAP |. request processing control
|~ |. WASD_CONFIG_MSG |. provides server messages
|~ |. WASD_CONFIG_SERVICE |. specifies services (virtual servers)
|!table|

|^ along with server CLI parameters commonly provide by startup DCL procedures.

|^ |*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%|../install/##Account Support Files++in++WASD Installation||).

|item| The only configuration that should require immediate attention will be
the mapping rules (|link|Request Processing Configuration||).

|!number|

|^ |*More generally| server runtime configuration involves the considerations
discussed in |link|Site Organisation| along with the following aspects:

|bullet|

|item| Configuring the HTTP server run-time characteristics
(|link|Configuration Considerations||).

|item| Mapping request paths to the VMS file system, and to other things such as
scripts (|link|Request Processing Configuration||).

|item| Customizing some or all messages (|link|Message Configuration||).

|item| Establishing an authentication and authorization environment
(|link|Authorization Configuration (Basics)||).

|!bullet|

|0Keep site-specific resources and server installation separate and distinct.|

|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\&nbsp; |"<span style=\"font-size:110%\">WATCH</span>||\&nbsp; 
(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://\<i\>the.host.name:port\</i\>\&thinsp;/httpd/-/admin/report/WATCH|
|!block|

|^ The service administration facilities (of which WATCH is one) are also
available and useful.

|block|
|link%|/httpd/-/admin/|https://\<i\>the.host.name:port\</i\>\&thinsp;/httpd/-/admin/|
|!block|