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 15 - HTTPd Web Update.
If authorization is in use (see 9 - 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
If a full authorization environment is not required but administration via browser is still desired restrict access to browsers executing on the server system itself, using an appropriate SYSUAF-authenticated username (start the server using the /SYSUAF qualifier):
[VMS] /httpd/-/admin/* #localhost,~username,r+w
If SSL is in use (see 10 - Secure Sockets Layer) then username/password privacy is inherently secured via the encrypted communications. To restrict server administration functions to this secure environment add the following to the HTTPD$MAP configuration file:
/httpd/-/admin/* "403 Access denied." ![sc:https]
When using the revise capability of the administration menu it is necessary to comply with all the requirements for Web update of files. This is discussed in general terms in 15 - HTTPd Web Update. Revision of server configuration files requires path permissions allowing write access for the username(s) doing the administration, as well as the required ACL on the target directory (in the following example HT_ROOT:[LOCAL]).
[VMS] /httpd/-/admin/* #localhost,~username,r+w /ht_root/local/* #localhost,~username,r+w
It is possible to allow general access to the administration menu and reports while restricting the ability to intiate server actions such as a restart! Using the WORLD realm against the path is necessary, for the obvious security reason, the server administration module will not allow itself to be used without an authenticated username, provided as a pseudo-authenticated "WORLD".
[VMS] /httpd/-/admin/control/* #localhost,~username,r+w [WORLD] /httpd/-/admin/* r
The server's authentication/authorization environment can be circumvented under special circumstances. Note that this is not possible without administrator action and persists only as long as the administrator actually performs the action!
This provision exists for only four foreseeable situations:
If performing the initial authentication configuration make sure the HT_AUTH logical is correctly defined.
Manually start a new instance of the server on a non-standard port using the /PROMISCUOUS qualifier. This can be done at the command line. There is now a security hole. Example:
$ HTTPD = "$HT_EXE:HTTPD.EXE" $ SPAWN /WAIT HTTPD /NOLOG /SERVICE=8088 /PROMISCUOUS
This server with then allow access using any username/password combination. Even if not completely paranoid it's perhaps a good idea to append a specific password to the qualifier, the server will then only authenticate to that.
$ SPAWN /WAIT HTTPD /NOLOG /SERVICE=8088 /PROMISCUOUS=VERYCAUTIOUS
Access this instance of the server with a browser and use the server administration menu.
http://host:port/httpd/-/admin/
It is now possible to review server-generated reports, check rule mappings, create databases, enter username details, change the administrator's password to something known, etc., etc. Shutdown that server again (ctrl-Y) and the security hole disappears.
Note that if a site authorization rule already maps the administration menu path or configuration file path the server may report duplicate path errors. This is due to the /PROMISCUOUS startup effectively introducing the following two rules, ensuring the menu and configuration files can be accessed regardless of anything already in or missing from the authorization file.
[PROMISCUOUS] # access to the server administration menu /httpd/-/admin/* r+w # access to write into the "usual" location for configuration files /ht_root/local/* r+w
Other rules may be placed in the local configuration file for the [PROMISCUOUS] realm specifically for use during this mode of access. They will not apply during normal server operation. Be sure they are placed before other rules in the file.
The server provides a number of internally generated reports.
It is possible to use this facility standalone, without configuring authorization, see 11.1 - Breaking-in To The Server!.
In addition a query-form interface allows the user to input a path and watch the rules as the server resolves it. Note that conditionals are not applied to rules when doing this checking (generally not possible such a situation), and so these cannot be assessed. As a result it is possible to see multiple paths indicated as matched. The resulting VMS specification and/or script specification will indicate the actual mapping.
This list will grow, up to the specified configuration maximum, as conconurrent scripting demand occurs. Maintained connections are indicated by the bolded, non-zero lifetime (in minutes). When this reaches zero the task is disconnected. The current/last task for that connection is indicated, along with the number of times the connection was reused and a total number of uses for that list item.
Purge and force buttons allow current links to be broken after request completion or forcibly disconnected.
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.
The server provides a limited configuration revision facility.
Chapter 9 - Authentication and Authorization covers authentication detail.
The server allows certain run-time actions to be initiated. Many of these functions can also be initiated from the command line, see 5.3 - HTTPd Command Line.
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.