The HTTP server account should be a standard account, preferably in a
group of its own (definitely at least a non-system, non-user group), with
sufficient quotas to handle the expected traffic.
5.1 - VMS Account
PROCESS QUOTAS: Server process quotas must be sufficient to support the expected traffic load. In particlular PRCLM must support expected script usage. BYTLM, BIOLM, DIOL, FILLM and PGFLQUO are all significant considerations. Symptoms of insufficient process quotas include:
Username: HTTP$SERVER Owner: HyperText Daemon Account: HTTPD UIC: [377,377] ([HTTPD,HTTP$SERVER]) CLI: DCL Tables: DCLTABLES Default: HT_ROOT:[HTTP$SERVER] LGICMD: LOGIN Flags: Restricted DisNewMail Primary days: Mon Tue Wed Thu Fri Secondary days: Sat Sun Primary 000000000011111111112222 Secondary 000000000011111111112222 Day Hours 012345678901234567890123 Day Hours 012345678901234567890123 Network: ##### Full access ###### ##### Full access ###### Batch: ##### Full access ###### ##### Full access ###### Local: ----- No access ------ ----- No access ------ Dialup: ----- No access ------ ----- No access ------ Remote: ----- No access ------ ----- No access ------ Expiration: (none) Pwdminimum: 6 Login Fails: 0 Pwdlifetime: 90 00:00 Pwdchange: (pre-expired) Last Login: (none) (interactive), 11-MAY-1995 08:44 (non-interactive) Maxjobs: 0 Fillm: 300 Bytlm: 500000 Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0 Maxdetach: 0 BIOlm: 512 JTquota: 1024 Prclm: 100 DIOlm: 512 WSdef: 1000 Prio: 4 ASTlm: 2000 WSquo: 5000 Queprio: 0 TQElm: 100 WSextent: 20000 CPU: (none) Enqlm: 256 Pgflquo: 500000 Authorized Privileges: NETMBX TMPMBX Default Privileges: NETMBX TMPMBX
NOTE: Support procedures often change between versions. It is always advisable to check the versions documentation before installing or updating.
Examples may be found in
HT_ROOT:[EXAMPLE].
HTTPd Executables
Two server executables can be built by the package.
As this image is to be installed with privileges unauthorized use should be prevented by applying an ACL similar to the following against the executable image:
$ SET SECURITY HT_EXE:HTTPD.EXE - /ACL=((IDENT=HTTP$SERVER,ACCESS=R+E),(IDENT=*,ACCESS=NONE))
This can be done once, at installation, or for peace-of-mind (a.k.a. VMS-ish paranoia) at each server startup.
As the HTTP$SERVER account should be completely unprivileged, and the HTTPd image requires NETMBX, TMPMBX, PRMMBX, PSWAPM, SYSNAM and SYSPRV privileges (see the "Nuts and Bolts" document for a description of how and why the server uses these privileges). It must be installed using a command similar to the following:
$ INSTALL = "$SYS$SYSTEM:INSTALL/COMMAND_MODE" $ INSTALL ADD HT_EXE:HTTPD.EXE /PRIVILEGE=(ALTPRI,PRMMBX,PSWAPM,SYSPRV,SYSNAM)
The following logical names are essential for the operation of the HTTPd server and must be defined before startup:
The following logical name is created by the executing HTTP server and defines the name of the control mailbox:
The following logical names are created by the executing HTTP server if the HTTPd monitor utility is enabled:
The server process log directory (output for the detached HTTP server processes) may require explicit access controls for the HTTPd account. This can be done by applying an ACL similar to the following:
$ SET SECURITY HT_ROOT:[LOG]SERVER.DIR - /ACL=((IDENT=HTTP$SERVER,ACCESS=R+W+E, OPTIONS=DEFAULT), - (IDENT=HTTP$SERVER,ACCESS=R+W+E), - (IDENT=*,ACCESS=NONE, OPTIONS=DEFAULT), - (IDENT=*,ACCESS=NONE))
As with the ACL on the server executable this can be done once, at
installation (or, if right over the top, at each server startup). Appropriate
disk quotas may also need to be applied. Also see
5.3.2.6 - Logging.
STARTUP.COM
Putting all this together the HTTP server startup procedure becomes something similar to the supplied example. It should be called from SYSTARTUP_VMS.COM or the site's equivalent.
This procedure will support simple and quite complex sites. It works closely with STARTUP_SERVER.COM (see below). It is designed to accept parameters from the command-line or as pre-assigned symbols. Operating in this fashion should mean that no modifications will need to be made to the procedure itself. Startup characteristics are essentially determined by DCL symbol values. Some symbols are booleans, switching functionality off and on, others require string values. When relevant startup values are not assigned a reasonable default will be applied. See the following examples.
Startup characteristics can be determined by supplying symbol assignment values as command-line parameters when calling the procedure.
$ @$1$DKA0:[HT_ROOT.LOCAL]STARTUP WASD_DECNET=1 WASD_SSL=1 - WASD_SSL_CERTIFICATE="HT_ROOT:[LOCAL]ALPHA.PEM"
Startup characteristics can also be determined by assigning the symbol values before calling the procedure itself.
$ WASD_DECNET = 1 $ WASD_SSL = 1 $ WASD_SSL_CERTIFICATE = "HT_ROOT:[LOCAL]ALPHA.PEM" $ @$1$DKA0:[HT_ROOT.LOCAL]STARTUP
Check the procedure itself for detail on symbol names and functionality.
See
HT_ROOT:[EXAMPLE]STARTUP.COM
STARTUP_LOCAL.COM
This file is automatically executed by the STARTUP.COM procedure immediately before the server is actually started. It is provided to supply all the local site's additional startup requirements. Place site-specific server environment startup in here, leaving STARTUP.COM alone as much as possible.
See
HT_ROOT:[EXAMPLE]STARTUP_LOCAL.COM
STARTUP_SERVER.COM
This procedure serves a dual purpose.
After deciding on the organisation of nodes and/or services copy this procedure, locating the files in the same directory as STARTUP.COM, and having destination file names representing the nodes and/or ports desired. Ensure any copies have read and execute permission for the HTTP$SERVER account!
STARTUP_SERVER_nodename.COM
STARTUP_SERVER_nodename_port.COM
For any given system, STARTUP.COM searches for these, based on the node name, and will execute any found, one per node and/or node-port. If none of these are found it executes the basic STARTUP_SERVER.COM, which itself should not be modified.
Backward-compatibility is provided for pre-v5.3 installations, with STARTUP.COM executing HT_ROOT:[HTTP$SERVER]HTTPD_BATCH.COM and HT_ROOT:[HTTP$SERVER]HTTPD80.COM if none of the above are found.
To pass parameters to the HTTPd executable for startup configuration (e.g. /SERVICE, /SYSUAF, etc.) two methods are available, the second is the recommended.
HTTPD$STARTUP_SERVER HTTPD$STARTUP_SERVER_nodename HTTPD$STARTUP_SERVER_nodename_portas in the following example
$ DEFINE /SYSTEM HTTPD$STARTUP_SERVER_ALPHA - "/SYSUAF /SERVICE=""http://alpha.wasd.dsto.defence.gov.au:8000"""
See
HT_ROOT:[EXAMPLE]STARTUP_SERVER.COM
LOGIN.COM
This procedure provides the HTTP server account login control.
See
HT_ROOT:[EXAMPLE]LOGIN.COM
5.3 - HTTPd Command Line
Command-line qualifiers provide some server startup control as well as
server runtime control.
5.3.1 - Server Startup
When starting up the server several characteristics of the server may be specified using qualifiers on the command line. If not specified appropriate defaults are employed. For recommended methods of passing parameters to the executable at server startup see STARTUP_SERVER.COM.
Note: buffer sizes apply on a per-request (thread)
basis, and may be tailored for specific environments at server startup.
5.3.2 - Server Command Line Control
A foreign command for the HTTPD control functionality will need to be assigned in the adminstration users' LOGIN.COM, for example:
HTTPD == "$HT_EXE:HTTPD" !HTTPD == "$HT_EXE:HTTPD_SSL"
Some control of the executing server is available from the DCL command
line on the system on which it is executing. This functionality, via the /DO=
qualifier, is available to the privileged user. If a non-default server port,
or multiple servers on the one system are being used, then it will be
necessary to provide a /PORT= qualifier with any command, and possibly issue
it multiple times. Of course, these commands are available from batch jobs as
well as interactively.
5.3.2.1 - Accounting
Server counters may be zeroed. These counters are those visible from the statistics admininstration menu item and when using the HTTPDMON utility.
$ HTTPD /DO=ZERO
See 11 - Authentication and Authorization.
The authorization rule file (HTTP$AUTH) may be reloaded.
$ HTTPD /DO=AUTH=LOAD
The authentication cache may be purged, resulting in re-authentication for all subsequent authorization-controlled accesses. This may be useful when disabling authorization or if a user has been locked-out due to too many invalid password attempts (see 11.8 - Authorization Cache).
$ HTTPD /DO=AUTH=PURGE
Server cache control may also be exercised from the server administration menu, see 14 - Server Administration. The file cache (see 16 - Cache) may be enabled, disabled and have it's contents purged (declared invalid and reloaded) using
$ HTTPD /DO=CACHE=ON $ HTTPD /DO=CACHE=OFF $ HTTPD /DO=CACHE=PURGE
These commands can be useful for flushing any currently executing CGIplus applications from the server, enabling a new version to be loaded with the next access. See "Scripting Environment" document.
All scripting subprocesses, busy with a request or not, can be deleted (this may cause the client to lose data).
$ HTTPD /DO=DCL=DELETE
A gentler alternative is to delete idle subprocesses and mark busy ones for deletion when completed processing.
$ HTTPD /DO=DCL=PURGE
All DECnet connections, busy with a request or not, can be disconnected (this may cause the client to lose data).
$ HTTPD /DO=DECNET=DISCONNECT
Purging is a better alternative, disconnecting idle tasks and marking busy ones for disconnection when complete.
$ HTTPD /DO=DECNET=PURGE
Server logging control may also be exercised from the server administration menu, see 14 - Server Administration.
Open a log file.
$ HTTPD /DO=LOG=OPEN
Optionally open and specify a log file name. This overrides any /LOG=file-name or HTTPD$LOG specified file name.
$ HTTPD /DO=LOG=OPEN=file-name
The log file may be closed and reopened using a different name (allowing continuous operation but, for example, with daily log files). This overrides any /LOG=file-name or HTTPD$LOG specified file name.
$ HTTPD /DO=LOG=REOPEN=file-name
Close the log file.
$ HTTPD /DO=LOG=CLOSE
Unwritten log records may be flushed to the file.
$ HTTPD /DO=LOG=FLUSH
The format and period specification of the log may be changed (only takes effect after the next log file open/reopen) using
$ HTTPD /DO=LOG=FORMAT=string $ HTTPD /DO=LOG=PERIOD=string
See 9 - Mapping Rules.
The mapping rule file (HTTPD$MAP) may be reloaded.
$ HTTPD /DO=MAP
Server shutdown may also be exercised from the server administration menu, see 14 - Server Administration.
The server may be shut down, without loss of existing client requests. Connection acceptance is stopped and any existing requests continue to be processed until conclusion.
$ HTTPD /DO=EXIT
The server may be immediately and unconditionally shut down.
$ HTTPD /DO=EXIT=NOW
The server may be restarted, without loss of existing client requests. Connection acceptance is stopped and any existing requests continue to be processed until conclusion. This effectively causes the server to exit normally and the DCL wrapper procedure to restart it.
$ HTTPD /DO=RESTART
This variant restarts the server immediately regardless of existing connections.
$ HTTPD /DO=RESTART=NOW