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.
Process Quotas!
Server process quotas must be sufficient to support the expected traffic load. BYTLM in particular, and then BIOLM, DIOL, FILLM and PGFLQUO, are all considerations.
Symptoms of insufficient process quotas include:
TCP/IP Agent Resources!
On an associated topic; some TCP/IP agents require particular internal resources to be adjusted against given loads (e.g. buffer space allocations). Symptoms of resource starvation may be TCP/IP services, including WASD, "pausing" for significant periods or associated processes entering miscellaneous wait states, etc., during processing. Please ensure such TCP/IP agents are appropriately dimensioned for expected loads.Later versions of TCP/IP Services for OpenVMS seem to have large default values for socket send and receive buffers. MultiNet and TCPware are reported to improve transfer of large responses by increasing low default values for send buffer size. The WASD global configuration directives [SocketSizeRcvBuf] and [SocketSizeSndBuf] allow default values to be adjusted. WATCH can be used to report network connection buffer values.
The following provides a guide to the account.
Username: HTTP$SERVER Owner: WASD Server Account: HTTPD UIC: [077,001] ([HTTP$SERVER]) CLI: DCL Tables: DCLTABLES Default: WASD_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: 5000000 Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0 Maxdetach: 0 BIOlm: 2048 JTquota: 1024 Prclm: 100 DIOlm: 1024 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
The following provides a guide to the account.
Username: HTTP$NOBODY Owner: WASD Scripting Account: HTTPD UIC: [076,001] ([HTTP$NOBODY]) CLI: DCL Tables: DCLTABLES Default: WASD_ROOT:[HTTP$NOBODY] 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: 2048 JTquota: 1024 Prclm: 100 DIOlm: 1024 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 WASD_ROOT:[EXAMPLE].
Two server executables can be built by the package.
As the HTTP$SERVER account should be completely unprivileged, and the HTTPd image requires ALTPRI, CMKRNL, DETACH, NETMBX, TMPMBX, PRMGBL, PRMMBX, PSWAPM, SECURITY, SHMEM (VAX only), SYSGBL, SYSLCK, SYSNAM, SYSPRV and WORLD privileges (see the WASD_ROOT:[SRC.HTTPD]READMORE.TXT document for a description of how and why the server uses these privileges).
It is installed using a command similar to the following:
$ INSTALL = "$SYS$SYSTEM:INSTALL/COMMAND_MODE"
$ INSTALL ADD WASD_EXE:HTTPD.EXE -
/PRIVILEGE=(ALTPRI,CMKRNL,DETACH,PRMGBL,PRMMBX,PSWAPM,-
SECURITY,SYSGBL,SYSLCK,SYSNAM,SYSPRV,WORLD)
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 this way requires no modifications 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.
$ @DKA0:[WASD_ROOT.STARTUP]STARTUP WASD_DECNET=1 WASD_SSL=1 - WASD_SSL_CERTIFICATE="WASD_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 = "WASD_ROOT:[LOCAL]ALPHA.PEM" $ @DKA0:[WASD_ROOT.STARTUP]STARTUP
On VAX platforms prior to VMS V6.2 the startup uses a system batch queue. By default SYS$BATCH is used. An alternate queue can be specified.
$ @DKA0:[WASD_ROOT.STARTUP]STARTUP WASD_DECNET=1 WASD_BATCH_QUEUE=THIS$BATCH
Check the procedure itself for detail on symbol names and functionality.
See WASD_ROOT:[EXAMPLE]STARTUP.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. For example, a STARTUP.COM defined logical name could be modified here before the server proper is actually started.
See WASD_ROOT:[EXAMPLE]STARTUP_LOCAL.COM
This procedure serves two purposes.
See WASD_ROOT:[EXAMPLE]STARTUP_SERVER.COM
It is recommended to pass server startup command-line parameters using the WASD_SERVER_STARTUP logical name that this procedure checks for and uses if present. If this is defined the contents are applied to the server image when executed. It can be explicitly defined before WASD startup.
$ DEFINE /SYSTEM /EXECUTIVE WASD_STARTUP_SERVER "/SYSUAF=ID" $ @DKA0:[WASD_ROOT.STARTUP]STARTUP
The value can also be passed to the main startup procedure in a symbol. The startup procedure then defines a system logical name with that value (note that any quotes used must be escaped).
$ WASD_DECNET = 1 $ WASD_SSL = 1 $ WASD_SSL_CERTIFICATE = "WASD_ROOT:[LOCAL]ALPHA.PEM" $ WASD_STARTUP = "/SYSUAF=ID" $ @DKA0:[WASD_ROOT.STARTUP]STARTUP
It can also be manually redefined at any time and the server restarted to apply different startup parameters to the running server.
$ DEFINE /SYSTEM /EXECUTIVE WASD_STARTUP_SERVER "/SYSUAF=(SSL,ID)" $ HTTPD /DO=RESTART=NOW
Various accounting, cache and other shared data used by the server is provided by shared global memory. These requires one permananet global section (SYSGEN parameter GBLSECTIONS) and a number of permanent global pages (SYSGEN parameter GBLPAGES) per item. The number of items varies depending on configuration.
|
If there are insufficient global sections or pages the server will fail to start for all requirements except the activity statistics, this will just be disabled. Server process log startup messages advise on current usage.
As permanent, system-accessible global sections are deployed it may be necessary to explicitly delete them after ad hoc server experimentation, etc. (3.6 - Server Startup). The startup qualifier /GBLSEC=NOPERM disables the creation of permanent global sections eliminating this requirement.
WASD version 10 uses an independent logical name table (something previous versions did not, see 3.5.1 - WASD Name Table below) and a different logical naming schema to earlier versions.
The following logical names are used in the operation of the package. These are usually created by STARTUP.COM during server startup.
|
In an effort to localise WASD-related logical names and avoid polluting the SYSTEM logical name table WASD version 10 creates it's own world-readable, system-writable name table, and adds it to LNM$SYSTEM_DIRECTORY.
$ SHOW LOGICAL WASD_TABLE/TABLE=LNM$SYSTEM_DIRECTORY "WASD_TABLE" [table] = "" (LNM$SYSTEM_DIRECTORY)
WASD logical names are then defined in that table leaving the SYSTEM table with just a few essential names.
$ SHOW LOGICAL CGI*,HT*,WASD*,WWW*
(LNM$PROCESS_TABLE)
(LNM$JOB_81E3D580)
(WASD_TABLE)
"CGI-BIN" = "DKA0:[WASD_ROOT.CGI-BIN.]"
= "DKA0:[WASD_ROOT.AXP-BIN.]"
"CGI_BIN" = "WASD_ROOT:[CGI-BIN]"
"CGI_EXE" = "WASD_ROOT:[AXP-BIN]"
"HTBIN" = "CGI-BIN:[000000]"
"HT_CACHE_ROOT" = "DKA0:[HT_CACHE.]"
"HT_EXE" = "WASD_ROOT:[AXP]"
"HT_LOGS" = "WASD_ROOT:[LOG]"
"HT_SCRATCH" = "WASD_ROOT:[SCRATCH]"
"WASD_AUTH" = "WASD_ROOT:[LOCAL]"
"WASD_AXP" = "WASD_ROOT:[AXP]"
"WASD_CACHE_ROOT" = "DKA0:[HT_CACHE.]"
"WASD_CGILIBSHR32" = "CGI_EXE:CGILIBSHR32.EXE"
"WASD_CGI_AXP" = "WASD_ROOT:[AXP-BIN]"
"WASD_CGI_BIN" = "WASD_ROOT:[CGI-BIN]"
"WASD_CGI_EXE" = "WASD_ROOT:[AXP-BIN]"
"WASD_CGI_IA64" = "WASD_ROOT:[IA64-BIN]"
"WASD_CGI_VAX" = "WASD_ROOT:[VAX-BIN]"
"WASD_CONFIG" = "WASD_ROOT:[LOCAL]"
"WASD_CONFIG_AUTH" = "WASD_CONFIG:HTTPD$AUTH.CONF"
"WASD_CONFIG_GLOBAL" = "WASD_CONFIG:HTTPD$CONFIG.CONF"
"WASD_CONFIG_MAP" = "WASD_CONFIG:HTTPD$MAP.CONF"
"WASD_CONFIG_MSG" = "WASD_CONFIG:HTTPD$MSG.CONF"
"WASD_CONFIG_SERVICE" = "WASD_CONFIG:HTTPD$SERVICE.CONF"
"WASD_EXE" = "WASD_ROOT:[AXP]"
"WASD_HTTPD_EXE" = "WASD_EXE:HTTPD_SSL.EXE"
"WASD_IA64" = "WASD_ROOT:[IA64]"
"WASD_JAVA" = "WASD_ROOT:[JAVA]"
"WASD_LOCAL" = "WASD_ROOT:[LOCAL]"
"WASD_LOGS" = "WASD_ROOT:[LOG]"
"WASD_SCRATCH" = "WASD_ROOT:[SCRATCH]"
"WASD_SCRIPT" = "WASD_ROOT:[SCRIPT]"
"WASD_SCRIPT_LOCAL" = "WASD_ROOT:[SCRIPT_LOCAL]"
"WASD_SERVER_LOGS" = "WASD_ROOT:[LOG_SERVER]"
"WASD_SSL_CAFILE" = "WASD_CONFIG:CA-BUNDLE_CRT.TXT"
"WASD_SSL_CERT" = "WASD_CONFIG:HTTPD.PEM"
"WASD_STARTUP" = "WASD_ROOT:[STARTUP]"
"WASD_STARTUP_SERVER" = "/SYSUAF=(ID,SSL)/PERSONA=RELAXED/PROFILE"
"WASD_VAX" = "WASD_ROOT:[VAX]"
"WWW_ROOT" = "DKA0:[WASD_ROOT.SRC.OSU]"
"WWW_SCRIPT_MAX_REUSE" = "999"
(LNM$GROUP_000001)
(LNM$SYSTEM_TABLE)
"HT_ROOT" = "DKA0:[WASD_ROOT.]"
"WASD_DECNET_CGI_OBJECT" = "DKA0:[WASD_ROOT.CGI-BIN]CGIWASD.COM"
"WASD_DECNET_OSU_OBJECT" = "DKA0:[WASD_ROOT.CGI-BIN]WWWEXEC.COM"
"WASD_FILE_DEV" = "DKA0:[WASD_ROOT]WASD_FILE_DEV.COM"
"WASD_ROOT" = "DKA0:[WASD_ROOT.]"
(LNM$SYSCLUSTER_TABLE)
(DECW$LOGICAL_NAMES)
As can be seen the number of LNM$SYSTEM_TABLE names is small, five in this example (though it can vary). Logical name WASD_FILE_DEV locates a procedure to insert the WASD_TABLE into a process' LNM$FILE_DEV to make the table names available. Until that is done they are not visible without an explicit /TABLE=WASD_TABLE. The server automatically uses the procedure for itself and scripting processes. Site admins can simply
$ @WASD_FILE_DEVat the command-line or in their LOGIN.COM to have it done for their interactive session(s). This procedure location is variable within the file-system and needs to be located and accessed without initially knowing that location.
The WASD_ROOT logical provides a convenient, global logical location for the primary (default) WASD environment. HT_ROOT is used to provide pre-v10 backward-compatibility with existing sites. (If yours does not need the name you can deassign it during server startup.)
The WASD_DECNET_CGI_OBJECT and WASD_DECNET_OSU_OBJECT names provide global locations for the two DECnet scripting environments. These logicals are defined when a site uses the [STARTUP]STARTUP_DECNET.COM procedure. It is necessary to provide a global location for these with multiple WASD environments because DECnet objects are global entities. The one object must provide an infrastructure for potentially multiple WASD environments.
Other SYSTEM logical names, WASD_TABLEn name tables, and WASD_FILE_DEVn logical names are used for non-primary WASD environments (see "WASD VMS Web Services - Features and Facilities"; 8 - Instances and Environments WASD Web Services - Features and Facilities ).
The server code accepts both the v10 or later and pre-v10 schemas. If it cannot find a v10 logical name it attempts to use a pre-v10 logical name. This has been provided in an effort to make the transition as seamless as possible for existing sites. In addition the revised startup procedures configure and use WASD_TABLE but can be directed to use the SYSTEM table by STARTUP.COM being provided a WASD_TABLE=0 parameter (see STARTUP.COM).
$ WASD_TABLE = 0 $ @DKA0:[WASD_ROOT.STARTUP]STARTUP.COM
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. For clarity some esoteric and legacy qualifiers and parameters are not listed in this table.
|