Configuration Considerations for Apache Web Server

Before you create Apache resource hierarchies, you will need to make sure you have completed the following configuration tasks for the Apache Web Server application:

1. In the case Apache package attached to a distribution is installed, it is normally set to autostart at system startup, so it conflicts with LifeKeeper’s protection. To avoid the conflict, refer to the manual of each distribution and disable the automatic start up.

*Note: For Apache on SuSE: The default installation of Apache on SuSE does not place the httpd.conf configuration file in a subdirectory of ServerRoot called conf. If you are using the default installation of Apache on SuSE, you must relocate the configuration file to the directory /etc/httpd/conf.

2. You must create a separate, distinct root directory for each LifeKeeper Apache Web Server hierarchy. This “server root” directory corresponds to the Apache “ServerRoot” configuration and command line parameters. Each LifeKeeper Apache resource hierarchy will correspond to a unique Apache instance with its associated server root directory. Note that the server root directory must be identical on all servers that are configured for a particular Apache hierarchy. You must place all configuration file information for the web site in the standard location relative to the server root (conf/httpd.conf) so that it can be found and accessed by the LifeKeeper software.

3. You must configure all web sites (virtual hosts) to listen on specific LifeKeeper IP addresses using BindAddress or Listen directives. These LifeKeeper-protected IP addresses must already be created and available to be brought in-service where the Apache hierarchy is to be created. They will automatically be added to the Apache resource hierarchy.

If you will be using a LifeKeeper shared file system, you must make all necessary preparations for the file system creation prior to creating the Apache hierarchy. In particular, the file system must be mounted on the server where the Apache hierarchy is to be created. If the LifeKeeper file system hierarchy has not already been created, it will automatically be created along with the Apache hierarchy, then joined to the Apache resource hierarchy.

Consult the Apache Web Server documentation for detailed information on configuring virtual hosts. As noted above, you must configure all Apache instances to listen on specific LifeKeeper-protected addresses. For example, the configuration file for an instance that combines IP-based and name-based virtual hosts would include directives like the following:

User webuser
Group webgroup
ServerName localhost

Listen 172.17.100.55:8000
NameVirtualHost 172.17.100.55:8000
Listen 172.17.100.56:80

<Virtualhost site.name_one:8000>
ServerName site.name_one
DocumentRoot /shared/site/name_one
</VirtualHost>

<VirtualHost site.name_two:8000>
ServerName site.name_two
DocumentRoot /shared/site/name_two
</VirtualHost>

<VirtualHost 172.17.100.56:80>
ServerName site.ip
DocumentRoot /shared/site/ip
</VirtualHost>

4. If SSL support is enabled for your Apache instance, you must configure the SSL Listen directive, often found in a separate ssl.conf file, to use the appropriate LifeKeeper-protected IP address. Otherwise, the creation of your Apache hierarchy will fail with an error indicating that the IP address 0.0.0.0 is not LifeKeeper protected. Note that SSL support is enabled by default in the Apache configuration files of some Linux distributions.

For example, change the following entry in the default SSL configuration file at /etc/httpd/conf.d/ssl.conf from

Listen 0.0.0.0:443

to

Listen 172.17.100.55:443

5. For a Local configuration, you must install and configure Apache in the same location on both the primary and all backup servers and set up identical (or equivalent) configuration files in the same server root directory on all servers. Also, all document root directories must exist on all servers and should contain identical files. (See the section on Local Configuration in Configuration Definitions and Examples.)

6. For a Shared configuration, you will typically configure the server root directory on a LifeKeeper shared file system. Note that only one shared file system may be used, since this assures that all required components which are on shared storage will be available at the same time. Therefore, all document root directories must be subdirectories of the same shared file system, but they need not be subdirectories of the server root directory itself. You may place an Apache executable on the same shared file system as well, but this executable will only be available for use by this particular Apache resource hierarchy.

*Note: You don’t necessarily need to place the server root directory on a shared file system in order to make use of shared storage. You may choose a local server root directory for configuration files, etc., and place only the document root directories on a shared file system. However, you must configure identical server root directories and identical (or equivalent) configuration files on all servers (as for a Local configuration as described above), and all document root directories must be on the same shared file system. (See the section on Shared Configuration in Configuration Definitions and Examples.)

7. Some web site implementations make use of DSO (Dynamic Shared Object) modules to extend Apache support for certain features. For example, there are modules available that implement functionality for PHP and Perl. These modules can be loaded and accessed at runtime by the Apache core. If you are using modules, they must be identically configured on every server in the cluster. Consult the documentation for the module package, and the vendor-supplied documentation for configuring Apache to use modules on your Linux platform. Depending on the module and the resources it uses, some objects may be required to reside on shared storage to facilitate proper failover. In some cases, a module may even need to be protected separately using the Generic Application Recovery Kit, or a custom recovery kit.

8. If you are using the SSL (Secure Sockets Layer) module with Apache, it is important that the server not be password protected. When the web server is password protected, the administrator must interactively type in the password at a prompt each time the daemon starts. Since this manual step is not consistent with a High Availability environment where recovery time is critical, LifeKeeper does not support password protected instances. Use the following command to remove the password:

openssl rsa -in server.key -out unprotected_server.key

Enter the server key password when prompted. To preserve the security of your site, make sure that the file is readable only by root!

chmod 400 unprotected_server.key

During the hierarchy creation of an Apache instance, the Recovery Kit checks that the resource is not password protected. If it is password protected, hierarchy creation will fail with an error message. However, when the instance is extended to another server, the Recovery Kit does not check for password protection on the backup server. You need to make sure that the hierarchy you are extending is not password protected.

The server key file(s) (specified by the SSLCertificateKeyFile directive(s) in the Apache configuration file) must have the same name and be at the same location on all servers in the cluster.

*Note: The PID file name of the httpd process that LifeKeeper uses has the following format:

“/var/run/httpd.<TAG name>.pid”

This PID file name is different from the default PID file name used by the OS. If you need to reference this PID file (ex. log rotate), please note the LifeKeeper PID file name and format.

9. In the case where “APACHE_SERVER_FLAGS” is defined in “/etc/sysconfig/apache2” in SuSE environments, add a “-D” in front of the flag name.

Example: APACHE_SERVER_FLAGS=”-D SSL”

If there is no “-D”, the resource creation and start up can fail.