WASD Hypertext Services - Technical Overview

[next] [previous] [contents] [full-page]

5 - Server Account and Environment

The HTTPd 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

The following provides a guide to the account:

  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:       300000
  Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
  Maxdetach:       0  BIOlm:       512  JTquota:       1024
  Prclm:         100  DIOlm:       512  WSdef:         1000
  Prio:            4  ASTlm:       600  WSquo:         2000
  Queprio:         0  TQElm:       100  WSextent:     20000
  CPU:        (none)  Enqlm:       256  Pgflquo:     200000
  Authorized Privileges:
    NETMBX    TMPMBX
  Default Privileges:
    NETMBX    TMPMBX


5.2 - Account Support Files

NOTE: The recommended LOGIN.COM (and server startup in general) has been modified for version 4. It now involves three files, LOGIN.COM, HTTPD_BATCH.COM and HTTPD80.COM. This was done to more easily support multiple servers in VMS clusters.

NOTE AGAIN: The introduction of NETLIB support with v4.3 has again resulted in minor changes to startup procedures.

NOTE YET AGAIN: The introduction of the message file and some rationalization of the location of local configuration files and scripts for v4.4 requires some minor changes to startup procedures.

Examples may be found in HT_ROOT:[EXAMPLE].

HTTPd Executables

Two server executables are provided with the package.

LOGIN.COM

The following is suggested as the LOGIN.COM for the server account. It provides a secure DCL environment for the server image to execute within.

  $ SET NOON
  $ SET NOCONTROL=Y
  $ NODENAME = F$GETSYI("NODENAME")
  $ IF F$MODE() .EQS. "OTHER" THEN EXIT
  $ IF F$MODE() .EQS. "BATCH" THEN EXIT
  $!(interactive and network modes stop here!)
  $ STOP/ID=0

HTTPD_BATCH.COM

The following procedure is SUBMITted by system startup procedure under the HTTPd server account, and simply creates a detached process under the control of HTTPD80.COM, or its equivalent.

$! SET VERIFY
$ SET NOON
$ SET NOCONTROL=Y
$ NODENAME = F$GETSYI("NODENAME")
$ PORT = P1
$ IF PORT .EQS. "" THEN PORT = "80"
$ PURGE /KEEP=3 HT_SERVER_LOGS:'NODENAME'_'PORT'_HTTPD.LOG
$ RUN SYS$SYSTEM:LOGINOUT -
      /DETACHED /AUTHORIZE -
      /INPUT=HTTPD'PORT'.COM -
      /OUTPUT=HT_SERVER_LOGS:'NODENAME'_'PORT'_HTTPD.LOG
$ STOP/ID=0

HTTPD80.COM

The following is suggested as the procedure controlling the execution of the HTTPD.EXE image.

$! SET VERIFY
$ SET NOON
$ SET NOCONTROL=Y
$ NODENAME = F$GETSYI("NODENAME")
$ PORT = 80
$! DEFINE /JOB HTTPD$AUTH HTTPD$AUTH'PORT'
$! DEFINE /JOB HTTPD$CONFIG HTTPD$CONFIG'PORT'
$! DEFINE /JOB HTTPD$MAP HTTPD$MAP'PORT'
$! DEFINE /JOB HTTPD$MSG HTTPD$MSG'PORT'
$ DEFINE /PROCESS HTTPD$LOG "HT_LOGS:''NODENAME'_''PORT'_ACCESS.LOG"
$ IF F$TRNLNM("HTTPD$USENETLIB")
$    THEN HTTPD = "$HT_EXE:HTTPD_NETLIB"
$    ELSE HTTPD = "$HT_EXE:HTTPD"
$ ENDIF
$ HTTPD_LOOP:
$    WRITE SYS$OUTPUT F$TIME()
$    HTTPD /PRIORITY=6 /PORT='PORT'
$!   (non-error exit, must be a restart, loop immediately)
$    IF $STATUS THEN GOTO HTTPD_LOOP
$!   (error exit, wait, then try to start the server again)
$    WAIT 00:01:00
$    GOTO HTTPD_LOOP
$!END_HTTPD_LOOP:
$ STOP/ID=0

Privileged Image

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, 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) 

Logical Names

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 HTTPd server and defines the name of the control mailbox:

The following logical names are created by the executing HTTPd server if the HTTPd monitor utility is enabled:

Server Process Logging Directory

The server process log directory (output for the detached HTTPd 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.5 - Logging.

Startup

NOTE: The server system startup DCL (SYSTARTUP_VMS.COM) has been modified for version 4.n.

Putting all this together the HTTPd server startup procedure becomes something similar to the following:

$!(change to "YES" to use NETLIB, otherwise it defaults to UCX)
$ DEFINE /SYSTEM HTTPD$USENETLIB "NO"
$ IF F$TRNLNM("HTTPD$USENETLIB") .AND. F$TRNLNM("NETLIB_SHRXFR") .EQS. "" -
     THEN @SYS$STARTUP:NETLIB_STARTUP.COM
$!
$!(it is recommended to provide a physically distinct area for Web documents)
$! DEFINE /SYSTEM /TRANSLATION=CONCEALED WEB DSA811:[WEB.]
$!
$ DEFINE /SYSTEM /TRANSLATION=CONCEALED HT_ROOT DSA811:[HT_ROOT.]
$!
$ 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))
$!
$ SCRIPT_ROOT = F$TRNLNM("HT_ROOT") - ".]" + ".SCRIPT.]"
$ DEFINE /SYSTEM HT_SCRIPT HT_ROOT:[SCRIPT]
$ SCRIPT_LOCAL_ROOT = F$TRNLNM("HT_ROOT") - ".]" + ".SCRIPT_LOCAL.]"
$ DEFINE /SYSTEM HT_SCRIPT_LOCAL HT_ROOT:[SCRIPT_LOCAL]
$ IF F$GETSYI("ARCH_NAME") .EQS. "VAX"
$ THEN
$    EXE_ROOT = F$TRNLNM("HT_ROOT") - ".]" + ".VAX.]"
$    DEFINE /SYSTEM /TRANSLATION=(CONCEALED) HT_EXE_ROOT 'EXE_ROOT'
$    DEFINE /SYSTEM HT_EXE HT_EXE_ROOT:[000000]
$ ELSE
$    EXE_ROOT = F$TRNLNM("HT_ROOT") - ".]" + ".AXP.]"
$    DEFINE /SYSTEM /TRANSLATION=(CONCEALED) HT_EXE_ROOT 'EXE_ROOT'
$    DEFINE /SYSTEM HT_EXE HT_EXE_ROOT:[000000]
$ ENDIF
$ DEFINE /SYSTEM /TRANSLATION=(CONCEALED) -
         CGI-BIN 'EXE_ROOT','SCRIPT_LOCAL_ROOT','SCRIPT_ROOT'
$ DEFINE /SYSTEM HT_AXP HT_ROOT:[AXP]
$ DEFINE /SYSTEM HT_VAX HT_ROOT:[VAX]
$!
$ DEFINE /SYSTEM HT_AUTH HT_ROOT:[LOCAL]
$ DEFINE /SYSTEM HT_LOCAL HT_ROOT:[LOCAL]
$ DEFINE /SYSTEM HT_LOGS HT_ROOT:[LOG]
$ DEFINE /SYSTEM HT_SERVER_LOGS HT_ROOT:[LOG.SERVER]
$!
$ DEFINE /SYSTEM HTTPD$AUTH HT_ROOT:[LOCAL]HTTPD$AUTH.CONF
$ DEFINE /SYSTEM HTTPD$CONFIG HT_ROOT:[LOCAL]HTTPD$CONFIG.CONF
$ DEFINE /SYSTEM HTTPD$MAP HT_ROOT:[LOCAL]HTTPD$MAP.CONF
$ DEFINE /SYSTEM HTTPD$MSG HT_ROOT:[LOCAL]HTTPD$MSG.CONF
$ DEFINE /SYSTEM HTTPD$GMT "+10:30"
$!
$ INSTALL = "$SYS$SYSTEM:INSTALL/COMMAND_MODE"
$ IF F$TRNLNM("HTTPD$USENETLIB")
$ THEN
$    SET SECURITY HT_EXE:HTTPD_NETLIB.EXE -
     /ACL=((IDENT=HTTP$SERVER,ACCESS=R+E),(IDENT=*,ACCESS=NONE))
$    INSTALL ADD HT_EXE:HTTPD_NETLIB.EXE -
                 /PRIVILEGE=(ALTPRI,SYSPRV,SYSNAM,PRMMBX,PSWAPM)
$ ELSE
$    SET SECURITY HT_EXE:HTTPD.EXE -
     /ACL=((IDENT=HTTP$SERVER,ACCESS=R+E),(IDENT=*,ACCESS=NONE))
$    INSTALL ADD HT_EXE:HTTPD.EXE -
                 /PRIVILEGE=(ALTPRI,SYSPRV,SYSNAM,PRMMBX,PSWAPM)
$ ENDIF
$ SUBMIT /QUEUE=SYS$BATCH /USER=HTTP$SERVER /NOLOG /NOPRINT -
         HT_ROOT:[HTTP$SERVER]HTTPD_BATCH.COM /PARAM="80"


5.3 - HTTPd Command Line


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.

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_NETLIB"

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


5.3.2.2 - Authentication

See 9 - 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.

  $ HTTPD /DO=AUTH=PURGE


5.3.2.3 - Cache

Server cache control may also be exercised from the server administration menu, see 10 - Server Administration. The file cache (see 12 - 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


5.3.2.4 - DCL/Scripting Subprocesses

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 11 - Scripting.

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


5.3.2.5 - Logging

Server logging control may also be exercised from the server administration menu, see 10 - 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


5.3.2.6 - Mapping

See 8 - Mapping Rules.

The mapping rule file (HTTP$MAP) may be reloaded.

  $ HTTPD /DO=MAP


5.3.2.7 - Shutdown

Server shutdown may also be exercised from the server administration menu, see 10 - 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=ABORT

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


5.4 - Multi-Homed Hosts With Digital TCP/IP

A multi-homed host responds to connections for more than one network address. Details on configuring Digital TCP/IP (UCX) for this behaviour may be found in the Digital TCP/IP Management manual, section on "Subnetwork Routing" (3.4.8 in the November 1995 edition) and Digital TCP/IP Management Command Reference, section on "SET INTERFACE" (November 1995 edition). The server configuration parameter [Service] allows for the processing of requests for multiple host-names and/or ports (see 6.2 - Current Directives) while conditional mapping rules enhance this basic capability (see 8.5 - Conditional Mapping).

Assuming an alternate, unused host name exists (for example):

  $ UCX
  UCX> SET HOST "second.host.name" /ADDRESS=131.185.30.2 /ALIAS=("second","SECOND")
  UCX> [EXIT]
  $

The system IP interface can be determined as follows (in this example it is SE0, the LO0 is the localhost interface):

  UCX> SHOW INTERFACE
                                                             Packets
  Interface   IP_Addr         Network mask          Receive          Send     MTU

   SE0        131.185.30.1    255.255.0.0            595567        262764    1500
   LO0        127.0.0.1       255.0.0.0                   1           573   65535  ?
  UCX> SHOW INTERFACE SE0 /FULL
  Interface: SE0
    IP_Addr: 131.185.30.1      NETWRK: 255.255.0.0       BRDCST: 131.185.255.255
                        Ethernet_Addr: AA-00-04-00-59-04    MTU:  1500
  .
  .
  .
    Restarting attempts                  0
    Successful restarts                  0

Note the network and broadcast masks of the interface above. The basic procedure then is to create a pseudo-interface (the "A" added to the hardware device name) as follows:

  UCX> SET INTERFACE SEA0 /HOST="second" /NET=255.255.0.0 /BROAD=131.185.255.255
  UCX> SET PROTOCOL IP /FORWARD

After the above commands the interfaces should appear as shown below:

  UCX> SHOW INTERFACE
                                                             Packets
  Interface   IP_Addr         Network mask          Receive          Send     MTU

   SE0        131.185.30.1    255.255.0.0            595567        262764    1500
   SEA0       131.185.30.2    255.255.0.0               169            99    1500
   LO0        127.0.0.1       255.0.0.0                   0          2263   65535  ?

These commands can be done interactively, during each startup, or placed in the permanent UCX configuration database once, as follows:

  UCX> SET CONFIG INTERFACE SEA0 /HOST="second" /NET=255.255.0.0 /BROAD=131.185.255.255
  UCX> SET CONFIG PROTOCOL IP /FORWARD

Note: Originating Host Address

Digital TCP/IP Services v4.1 at least, appears to determine an outgoing connection's originating host address from the IP address of the "highest" pseudo-interface defined (in this case from the SEA0, resulting in an apparent source address of 131.185.30.2). This can cause some confusion on remote hosts as to the origin of a connection, and otherwise be generally undesirable.

A solution appears to be to assign the primary address to the last defined interface. This means the original interface must be removed using a

  UCX> SET CONFIG NOINTERFACE SE0
then explicitly redefining it and then the new interface, ensuring the first is the non-primary address and the second the primary.


[next] [previous] [contents] [full-page]