VSI Apache Web Server V2.4-59A (based on Apache HTTP Server)

The mod_proxy module 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.

mod_access_compat

mod_actions

mod_alias

mod_allowmethods

mod_asis

mod_authnz_ldap

mod_authnz_openvms

mod_authn_anon

mod_authn_core

mod_authn_dbd

mod_authn_dbm

mod_authn_file

mod_authn_socache

mod_authz_core

mod_authz_dbd

mod_authz_dbm

mod_authz_groupfile

mod_authz_host

mod_authz_owner

mod_authz_user

mod_auth_basic

mod_auth_digest

mod_auth_form

mod_autoindex

mod_buffer

mod_cache

mod_cache_disk

mod_cache_socache

mod_cern_meta

mod_cgi

mod_charset_lite

mod_dav

mod_dav_fs

mod_dbd

mod_deflate

mod_dir

mod_dumpio

mod_echo

mod_env

mod_expires

mod_ext_filter

mod_file_cache

mod_filter

mod_headers

mod_include

mod_info

mod_isapi

mod_lbmethod_bybusyness

mod_lbmethod_byrequests

mod_lbmethod_bytraffic

mod_lbmethod_heartbeat

mod_ldap

mod_logio

mod_log_config

mod_log_debug

mod_macro

mod_mime

mod_mime_magic

mod_negotiation

mod_osuscript

mod_proxy

mod_proxy_ajp

mod_proxy_balancer

mod_proxy_connect

mod_proxy_express

mod_proxy_fcgi

mod_proxy_ftp

mod_proxy_http

mod_proxy_scgi

mod_proxy_wstunnel

mod_ratelimit

mod_remoteip

mod_reqtimeout

mod_request

mod_rewrite

mod_sed

mod_session

mod_session_cookie

mod_session_dbd

mod_setenvif

mod_slotmem_shm

mod_socache_dbm

mod_socache_memcache

mod_socache_redis

mod_socache_shmcb

mod_speling

mod_ssl

mod_status

mod_substitute

mod_suexec

mod_unique_id

mod_unixd

mod_userdir

mod_usertrack

mod_version

mod_vhost_alias

mod_wsgi (OpenVMS Integrity with Python 3.8.2F only)

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. See the file httpd-vms.conf to load other modules.

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.

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:

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 (where myhost.mydomain.com is the value that the web server has determined for the server's fully qualified domain name):

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

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

Do not attempt to use APACHEWS Version 2.4 with older APACHEWS 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 8.4-2L1 or higher (IA64), VSI OpenVMS 8.4-2L1 or higher (Alpha)

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

VSI SSL111 V1.1-1p 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

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.