Appendix J. Setting up PHP5 in parallel with PHP4 in SuSE 10.1

Table of Contents

J.1. Configuration files and directories for Apache2 in SuSE 10.1
J.2. Making sure you have the correct Apache2 setup
J.3. Approaches to running multiple PHP versions
J.4. Outline of the remainder of the chapter
J.5. Part I - Installing PHP4
J.5.1. Step one; Compiling PHP4 as a module for Apache2
J.5.2. Step two; Enable the PHP4 module in the Apache2 configuration
J.6. Part II - Creating a virtual host
J.6.1. Step 1; Adding an alias IP-address to Your server
J.6.2. Step 2; Creating different document and cgi roots
J.6.3. Step 3; Configure Apache with a virtual host
J.7. Part III - Installing PHP5
J.8. Part IV - Verifying the setup
J.8.1. Troubleshooting

Even though PHP4 is officially deprecated and is no longer actively maintained a large number of existing installations are stiil (and will be) using PHP4. For this reason it can be important to be able to test scripts running both PHP4 and PHP5. This section shows how to do this on Linux SuSE 10.1 installation. Other Linux dialects can use similar but not identical setups.

SuSE 10.1 ships with Apache2 and PHP5 as standard. In order to install PHP4 in parallel some extra work is therefore required. This chapter explains how to setup both PHP4 and PHP5 on the same server by configuring Apache2 using virtual hosts.

We will show how to maintain a simultaneous installation of both PHP4 and PHP5 at the same time without the need to run a switching script to select which PHP version to activate. In this setup we have opted to configure Apache with two virtual hosts based on IP-address, one host running PHP4 as a SAPI module and the other virtual host running PHP5 as a CGI module.

J.1. Configuration files and directories for Apache2 in SuSE 10.1

Before we start we give a short overview of where important configuration files and directories for Apache2 are located in SuSE

Note

The configuration files setup by SuSE is slightly different from the standard one-single "/etc/httpd.conf" used by other systems. The way SuSE does it is to create a hierarchy of setup files under "/etc/apache2/". While this might look complicated at first sight it has several advantages specially when You consider that some script have to modify and add configurations to Apache2. Doing automatic (and safe) edits in a large config file that can also be manually edited is almost impossible to guarantee.

Dir: /etc/apache2/

General configuration directory for Apache2, this is where the "httpd.conf" lives.

Dir: /etc/apache2/conf.d/

Module configuration files for loaded modules, for example php4.conf. All the configuration files in this directory will be automatically read by the main httpd.conf by means of an "include conf.d/*.conf" command so the exact name doesn't really matter as long as the file ends in "*.conf".

Dir: /etc/apache2/vhosts.d/

Virtual host configuration files. All files in this directory will be automatically read by the main httpd.conf the exact name doesn't really matter as long as the file ends in "*.conf". Note: When yast2 is used to edit virtual hosts it will add its "yast2_*.conf" in this directory. Unfortunately the virtual host configuration in yast2 in not without problem (bugs) for IP based virtual hosts so we prefer to create the configuration files manually. This will be shown later on in this article.

File: /etc/sysconfig/apache2

This is the main Apache2 configuration file. This file is the one that is really used to configure apache when it is started. This is also the file that the "Yast2" HTTPD-module edits.

From our point of view the most important thing is that this is the place where we tell Apache2 what external modules to load.

In the SuSE configuration this is done by listing all the modules in the string variable APACHE_MODULES. In the SuSE configuration there are no static "AddModule" directives in any of the configuration files for Apache. Instead this is dynamically generated each time apache is started (for example by /etc/init.d/apache2 start)

The generation of the actual module file names is quite clever in that the script looks at the core module name in the APACHE_MODULE variable and automatically determines the name of the file name of the load modules. This means that for PHP we only have to give the name "php4" or "php5" as the name of the module.

The script will then discover that the name of the file load module is in fact "libphp4.so" or "libphp5.so" automatically. The dynamically created list of load modules will be written to "/etc/apache2/sysconfig/loadmodule.conf" just before the startup script activates apache2 daemon which will then read the modules from this file which is included from the main "httpd.conf" file.