WASD Hypertext Services - Technical Overview

[next] [previous] [contents]

8 - HTTPd Server Administration

All server configuration files, with the execption of the authentication databases, are plain text and may be modified with any prefered editor. However the majority of this can also be administered on-line through a browser.

A menu of administration functions is provided by the server.

In addition a Web Update facility allows some administration of file system portions of the Web. See 11 - HTTPd Web Update.

If authorization is in use (see 7 - HTTPd Authentication and Authorization) it is recommended that the path to these reports be controlled via authentication and authorization, using both host and username restrictions, similar to the following:

  [WHATEVER-REALM]
  /httpd/-/admin/*  host.ip.addr,~WebMaster,~WhoEverElse,r+w

To restrict server administration to browsers executing on the server system itself use a restriction list similar to the following.

  [VMS]
  /httpd/-/admin/*  localhost,~WebMaster,r+w

8.1 - HTTPd Server Reports

The server provides a number of internally generated reports.

  1. Statistics - Server process up-time, CPU-time and other resources consumed, number of connections processed, number of requests of each HTTP method, type of processing involved (HTTPd module used), number of bytes processed, etc.

  2. Configuration - A tabular summary of the server's current configuration. This is a convenient method for viewing the information from the HTTPD$CONFIG file.

  3. Mapping - All loaded mapping rules. In addition a query-form interface allows the user to input a path and watch the rules as the server resolves it.

  4. Path Authorization - If authorization is in use (see 7 - HTTPd Authentication and Authorization) this report lists the paths with associated authorization and access control.

  5. User Authentication - List any users that have been authorized since the server was last started, the realm authorized from, the group it applies to (if any), and what the user's capabilities are (allowed HTTP methods). A time-stamp and counters provide additional information.

  6. Request - Lists current requests (always shows at least your own connection accessing this report :^) and if enabled by configuration a history list of the most recent requests. Enabled by the configuration parameter [RequestHistory].

  7. Script - Provides some DCL, CGI and CGIplus scripting information.

  8. Activity - Provide a graphical snapshot of server activity of a given period.

    This is dynamic data, held in memory only, and so is current only from the latest server startup. It is enabled by the configuration parameter [ActivityDays]. The administration menu provides several, represented as a period of hours before the present time. Number of requests and bytes sent to the client are represented by a histogram with respective means for each during the period by a line graph. A greyed area indicates no data available for that time (i.e. before the latest server startup, or in the future).

    Activity data is accumulated on a per-minute basis. This is the maximum granularity of any report. When reports are selected that can display less than this one minute granularity (i.e. with periods greater than four hours) the value shown is the peak of the number of minutes sampled for display. This better represents the load on the server than would a mean of those samples.

    For browsers recognised as capable (with v4.3 of the server these are Netscape Navigator 3.0ff and Microsoft Internet Explorer 3.02ff) this report is JavaScript-enabled, and if in focus the browser refreshes itself at an interval appropriate to the reporting period. If not in focus, the report is automatically refreshed when the browser is brought back into focus.

    The graph is an image map, various regions of which allow the selection of other reports with different periods or durations. This allows previous periods to be examined at various levels of detail using the graph for navigation. Various sections may have no mapping as appropriate to the current report.

    The following example shows the layout for a four hour report. The upper and lower sections have distinct functions. The middle 50% of the upper section allows the same end time (most commonly the current hour) to be examined over twice the current period, in this case it would be over eight hours. The left 25% allows the previous fours hours to be viewed (if such data exists), and for non-current reports the right 25% allows the next four hours to be viewed. The lower half can be divided into sections representing hours or days depending on the period of the current report. This allows that period to be viewed in greater detail. For single hour reports this section, of course, is not mapped.

    Remember that the URL of the mapped section will be displayed in the status bar of the browser. As the URL contains time components it is not a difficult task to decipher the URL displayed to see the exact time and period being selected.

    [activity map example]

8.2 - HTTPd Server Revise

The server provides a limited configuration revision facility.

  1. Configuration - A form-driven interface allows the current configuration of the server to be altered on-line. This configuration may then be saved to the on-disk file and then the server could be restarted using the new parameters. The source of the current configuration can be either the server itself (from it's volatile, in-memory parameters) or from the on-disk configuration file. In addition it is possible to directly edit and update the on-disk file.

  2. Mapping - No form-driven interface is currently available for changing the mapping rules. However it is possible to directly edit and update the on-disk file. The mapping rules could the nbe reloaded, changing the current server rules (see 8.3 - HTTPd Server Action).

  3. Path Authorization - No form-driven interface is currently available for changing the path authorization configuration. However it is possible to directly edit and update the on-disk file. The path authorization directives could the be reloaded, changing the current server authorization (see 8.3 - HTTPd Server Action).

  4. User Authentication - User authentication comprises a number of dialogues that allow the authentication databases to be administered. These include:

    Chapter 7 - HTTPd Authentication and Authorization covers authentication detail.

8.3 - HTTPd Server Action

The server allows certain run-time actions to be initiated.

  1. Statistics Zeroed - All counters are zeroed (except the number-of-times-zeroed counter!)

  2. Mapping Rules Reload - Reloads the path mapping rules from the on-disk file into the running server.

    Caution! If changing CGIplus script mapping it is advised to restart the server rather than reload. Some conflict is possible when using new rules while existing CGIplus scripts are executing.

  3. Path Authorization Reload - Reloads the path authorization directives from the on-disk file into the running server.

  4. User Authentication Cache Purge - For efficiency reasons authenticated user information is cached for a limited period within the running server. All this cached information may be completely purged using this action, forcing subsequent requests to be reauthenticated from the on-disk database.


[next] [previous] [contents]