VSI Apache Web Server 2.4-65 (based on Apache HTTP Server)

The module MOD_PROXY was updated to support single-threaded builds.

The OpenVMS-specific authentication module MOD_AUTHNZ_OPENVMS can now optionally authenticate users (username and password) using the SYS$ACMW system service, thereby making it possible to authenticate OpenVMS users that are configured to use ACME LDAP or similar providers for user authentication. In order to enable this facility, it is necessary to define the logical name APACHE$AUTH_USE_ACM (to anything) in LOGIN.COM for the web server account.

LDAP-related modules now use the new OpenLDAP client API, providing better security and enhanced functionality. It should be noted that these modules are statically linked with the OpenLDAP client libraries, and it is therefore not necessary to install OpenLDAP for VSI OpenVMS in order to make use of this new feature.

The module MOD_SOCACHE_REDIS is included in this release, allowing the high-performance Redis object cache to be used for caching various data such as SSL session information. Redis may be installed on the same OpenVMS system as the web server or reside on another server that is accessible from the system hosting the web server.

The module MOD_WSGI is included in this release, and can be used in conjunction with Python 3.10 for VSI OpenVMS to create powerful Python-based web applications using the WSGI (Web Server Gateway Interface) framework. It should be noted that the MOD_WSGI module is available only for Integrity at this time.

Changes are required in HTTPD.CONF when upgrading from previous versions.

In APACHEWS Version 2.4, some dynamically loadable modules provided with previous releases are no longer available or are not loaded by default.

You must uncomment the modules in HTTPD.CONF to load them. To load other modules, see the file HTTPD-VMS.CONF.

Removal of AcceptMutex and related directives

In pre-2.4 versions of Apache HTTPD, the AcceptMutex directive was used in HTTPD.CONF to specify the method used by the web server to serialize multiple child processes accepting requests on network sockets. In version 2.4, the AcceptMutex, LockFile, RewriteLock, SSLMutex, SSLStaplingMutex, and WatchdogMutexPath directives have been replaced with a single Mutex directive (for details, refer to https://httpd.apache.org/docs/2.4/mod/core.html#mutex).

With previous versions of the APACHEWS for OpenVMS, the value vmsdlm could be specified for AcceptMutex to instruct the web server to use the OpenVMS Distributed Lock Manager to coordinate access to network sockets and other shared resources. For version 2.4 of the APACHEWS for OpenVMS, the Distributed Lock Manager is always used to coordinate access to network sockets and does not need to be explicitly specified unless using the DBM or shared memory cache modules, MOD_SOCACHE_DBM and MOD_SOCACHE_SHMCB, respectively.

Other permitted (non-default) values for the Mutex directive are:

Note that if no Mutex type is defined and you attempt to use any modules that require a Mutex to be defined, the web server will silently fail to start. It is therefore recommended that you always define a Mutex, even if you do not currently make use of it.

Changes to OpenVMS authentication module

The authentication and authorization module used by Apache HTTP Server version 2.4 differs from that of previous versions. In version 2.4, it is necessary to register the specific authentication (or authorization) provider that you wish to use for a particular directory or location. This way it is possible to configure and use different providers with different directories or locations.

The following example illustrates use of the OpenVMS authentication provider for the /test directory:

<Directory /test>
   Options FollowSymLinks
   AllowOverride AuthConfig
   AuthType Basic
   AuthName "OpenVMS authentication"
   AuthBasicProvider OpenVMS
   require valid-user
</Directory> 

We have specified an AuthBasicProvider of OpenVMS (note that the name of the provider is case-sensitive). This causes the authentication infrastructure to use the OpenVMS password checking module (included in MOD_AUTHNZ_OPENVMS.EXE).

Note that in order for this to work correctly, the following modules must be loaded:

• MOD_AUTHN_CORE.EXE
• MOD_AUTHZ_CORE.EXE
• MOD_AUTH_BASIC.EXE
• MOD_AUTHNZ_OPENVMS.EXE

The MOD_AUTHZ_CORE.EXE module is strictly only required for authorization (as opposed to authentication), but since MOD_AUTHNZ_OPENVMS.EXE includes functionality to handle both authentication and authorisation, it is recommended to load MOD_AUTHZ_CORE.EXE whenever you use the MOD_AUTHNZ_OPENVMS.EXE module.

It should also be noted that the OpenVMS authentication and authorization module now accepts no configuration commands (as a consequence of the changes in 2.4 affecting how authentication and authorization are handled, such commands are now superfluous). Specifically, the following directives have been removed:

Setting a value for ServerName

Upon starting the web server for the first time you see a message similar to the following:

"Could not reliably determine the server's fully qualified domain name,
 using myhost.mydomain.com. Set the 'ServerName' directive globally to
 suppress this message"

where myhost.mydomain.com is the value that the web server has determined for the server's fully qualified domain name)

This message is informational and will not prevent the web server from starting; however, you may want to do as the message suggests and modify your HTTPD.CONF file to explicitly specify a value for the ServerName directive in accordance with the notes included in HTTPD.CONF (edit HTTPD.CONF and search for ServerName). It is strongly recommended that you also specify a port number, as illustrated in HTTPD.CONF, as this can prevent future issues if you plan to run multiple instances of the web server or if you plan to enable SSL, which uses a different port number (the value of ServerName in HTTPD.CONF cannot be the same as that used by the SSL VirtualHost specified in SSL.CONF).

Logical names marked for deprecation

The logical names APACHE$BG_PIPE_BUFFER_SIZE and APACHE$MB_PIPE_BUFFER_SIZE have been marked for deprecation, and site-specific command procedures using these logical names should be modified to instead use the names APR$BG_PIPE_BUFFER_SIZE and APR$MB_PIPE_BUFFER_SIZE, respectively. Use of either name is supported by this release; however the logical names with the APACHE$ prefix will be removed from subsequent releases. This change has been made in order to better reflect the name of the software sub-system to which the logical names pertain.

The logical name APACHE$SSL_DBM_TYPE has been deprecated

This logical name could be used in previous versions to define the DBM database manager to be used by the SSL session cache with MOD_SSL. APACHEWS Version 2.4 for OpenVMS only supports the SDBM database, therefore the logical name APACHE$SSL_DBM_TYPE is not required. However, for optimal performance, it is recommended that the shared memory cyclic buffer session cache is used. For additional information on setting up the SSL session cache, see https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslsessioncache.

All custom-written dynamically loaded modules must be rebuilt for Version 2.4

Most third-party modules designed for Version 2.x will otherwise work unchanged with the Apache HTTP Server version 2.4 (will only need to be recompiled); however, some modules may require changes. The document http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html provides details of the API changes that have been made with 2.4. Also, see the notes about building custom modules elsewhere in this document (building modules has been made easier with this release and does not require developers to download the APACHEWS source code).

APACHEWS will fail to start correctly if the audit server is not running. This requirement may be removed in future releases of APACHEWS.

APACHEWS may fail to start correctly if a Listen directive is not specified in HTTPD.CONF. The symptom of this problem is that the web server appears to be running but is not listening on any TCP/IP port for client requests. Inclusion of a simple Listen directive such as Listen 80 (where 80 is the desired port number) is sufficient to negate this problem. This issue will be resolved in future releases.

Do not attempt to use APACHEWS Version 2.4 with older CSWS optional kits.

Do not use APACHEWS Version 2.4 with the following optional kits. Using these kits together causes a process crash.

VMS Software Inc. is working to provide updated versions of these optional kits that can be used with APACHEWS Version 2.4.

Installing APACHEWS Version 2.4 on an ODS-2 volume may corrupt an existing installation. You must install the APACHEWS Version 2.4 kit only on an ODS-5 target volume; if you install this kit on an ODS-2 volume, the installation will fail.

Language variant filename restrictions

Specify language variants on an OpenVMS system in the same way as you do on a UNIX system, using multiple dots in the filename. For example, the French variant of a filename is FILENAME.HTML.FR.

WebDAV database manager type restriction

WebDAV support requires the SDBM database manager type. SDBM is the default and only DBM supported in this release.

Defining an alternative DBM using the logical name APACHE$DAV_DBM_TYPE will cause an error to be logged and the web server will fail to start. Other DBM types may be supported by future releases.

If suEXEC is enabled in the initial configuration, APACHEWS cannot add a node in a cluster environment.

If you enable suEXEC during the initial configuration of APACHEWS or by using Option 4 (Manage suEXEC users) of the APACHEWS Configuration Menu, then Option 10 of the APACHEWS Configuration Menu (Add a node to APACHEWS in a cluster environment) will fail.

As a workaround, use Option 4 to disable suEXEC, then use Option 10 to add the node, and then use Option 4 to re-enable suEXEC.

Option 2 in the APACHE$MENU.COM menu (“Create an Apache instance”) fails under the following circumstances:

The Require user directive for user authorization must specify user names in uppercase with the MOD_AUTHNZ_OPENVMS module.

The ScoreBoardFile directive is ignored.

A shared memory scoreboard is used by APACHEWS to facilitate sharing of information between parent and child processes. The ScoreBoardFile directive in HTTPD.CONF is intended to allow file-based shared memory to be used for this purpose on platforms that do not support the use of anonymous shared memory. VSI OpenVMS does support anonymous shared memory and changes made in this release to improve APACHEWS performance by reducing inter-process coordination requirements have required the ScoreBoardFile directive to be ignored.

For certain configuration errors, APACHEWS can fail silently on start-up without logging any details of the problem to the error log file, making it problematical to diagnose the problem. In such situations it is often useful to temporarily disable APACHEWS shared process logging by defining the logical name APACHE$SPL_DISABLED to TRUE in APACHE$ROOT:[000000]LOGIN.COM. This will ensure that all error messages are flushed to the error log file before the process terminates. For optimal performance be sure to re-enable shared process logging once the problem has been resolved.

In order for the web server to use IPv6, the two logical names TCPIP$IPV6_STARTED and APACHE$CAN_USE_IPV6 must be defined in the SYSTEM table (the logical names can be defined with any value). Having only TCPIP$IPV6_STARTED is not sufficient.

VSI OpenVMS Alpha Version 8.4-2L2 or higher, VSI OpenVMS IA-64 Version 8.4-2L1 or higher, VSI OpenVMS x86-64 Version 9.2-3 or higher

VSI TCP/IP, HPE TCP/IP Services for OpenVMS, or MultiNet TCP/IP stack

VSI SSL3 V3.0-16 or later

If you wish to run Python applications under APACHEWS using MOD_WSGI, it should be noted that this facility is currently only supported for Python 3.8.2F for VSI OpenVMS. It is envisaged that future releases of APACHEWS and MOD_WSGI will support Python 3.10 and/or later.

Enabling SSL:

Generate a self-signed certificate, which is valid for 30 days. To do so, use the following certificate tool:

$ @APACHE$COMMON:[OPENSSL.COM]OPENSSL_AUTO_CERT.COM

Uncomment the following directive in the APACHE$COMMON:[CONF]HTTPD.CONF file and restart the web server:

Include /apache$root/conf/ssl.conf

Disabling SSL:

To disable SSL, comment the following directive in the APACHE$COMMON:[CONF]HTTPD.CONF file:

Include /apache$root/conf/ssl.conf

When the server is built

Dynamically at run-time using the Apache HTTP Server Dynamic Shared Object (DSO) feature