Upgrade PHP with Oracle Application Server on Linux

Oracle includes PHP with its mid-tier Application Server 10g Release 3 allowing you to use the same web server for PHP and for J2EE applications.

PHP is enabled by default. The Oracle HTTP Server document root is

$ORACLE_HOME/Apache/Apache/htdocs
Files with .php or .phtml extensions in this directory will be executed by PHP. Files with a .phps extension will be displayed as formatted source code.

Version 10.1.3.0 of the Application Server (AS) comes with PHP 4.3.11. The AS 10.1.3.2 patchset adds PHP 5.1.2. If you have a strong need to use a different version of PHP without installing a new web server, you may be able to compile your own PHP release.

Note: Changing the version of PHP in AS is not supported (and hence is not recommended) but is technically possible in some circumstances. For any AS support calls, regardless of whether they are PHP related, Oracle Support will ask you to revert the changes before beginning investigation.

The technical problem faced with building PHP is that the Oracle libraries for AS do not include header files. This can be overcome by linking PHP with Oracle Instant Client but care needs to be taken so that AS itself does not use the Instant Client libraries. Otherwise you will get errors or unpredictable behavior.

These steps are very version and platform specific. They may not be technically feasible in all deployments of AS.

A previous installation of AS 10.1.3 is assumed. To install a new version of PHP:

1. Logon as the oracle user and change to the home directory
cd $HOME
2. Download the Oracle 10.2.0.3 Basic and SDK Instant Client packages from the Instant Client page on the Oracle Technology Network, http://www.oracle.com/technology/tech/oci/instantclient/instantclient.html.

3. Extract the ZIP files:
unzip instantclient-basic-linux32-10.2.0.3-20061115.zip
unzip instantclient-sdk-linux32-10.2.0.3-20061115.zip
4. Change to the Instant Client directory and symbolically link libclntsh.so.10.1:
cd instantclient_10_2
ln -s libclntsh.so.10.1 libclntsh.so
The Instant Client RPMs could also be used, in which case this last step is unnecessary.

Be wary of having Instant Client in /etc/ld.so.conf since Instant Client libraries can cause conflicts with AS. The opmnctl tool may fail with the error Main: NLS Initialization Failed!!.

5. Download PHP 5.2.2 from http://www.php.net/downloads.php and extract the file:
cd $HOME
tar -jxf php-5.2.2.tar.bz2
6. Set the ORACLE_HOME environment variable to your AS install directory:
export ORACLE_HOME=$HOME/product/10.1.3/OracleAS_1
7. Shutdown the HTTP Server:
$ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=HTTP_Server
8. Edit $ORACLE_HOME/Apache/Apache/conf/httpd.conf and comment out the PHP 4 LoadModule line by prefixing it with #:
#LoadModule php4_module             libexec/libphp4.so
If you had enabled PHP 5 for AS 10.1.3.2, the commented line will be:
#LoadModule php5_module             libexec/libphp5.so
Also, backup $ORACLE_HOME/Apache/Apache/libexec/libphp5.so since it will be replaced.

9. Set environment variables required for the build to complete:
export PERL5LIB=$ORACLE_HOME/perl/lib
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
export CFLAGS=-DLINUX
There is no need to set CFLAGS if you have AS 10.1.3.2. It is needed with AS 10.1.3.0 to avoid a duplicate prototype error with gethostname() that results in compilation failure.

10. Configure PHP:
cd php-5.2.2
./configure 
  --prefix=$ORACLE_HOME/php 
  --with-config-file-path=$ORACLE_HOME/Apache/Apache/conf 
  --with-apxs=$ORACLE_HOME/Apache/Apache/bin/apxs 
  --with-oci8=instantclient,$HOME/instantclient_10_2 
  --enable-sigchild
With the older AS 10.1.2 and older Instant Client releases, some users reportedly also specified --disable-rpath.

11. Make and install PHP
make
make install
Installation copies the binaries and updates $ORACLE_HOME/Apache/Apache/conf/httpd.conf, automatically adding the line:
LoadModule php5_module        libexec/libphp5.so
12. Backup and update $ORACLE_HOMEApache/Apache/conf/php.ini with options for PHP 5.2.2, for example all the new oci8 directives. Refer to $HOME/php-5.2.2/php.ini-recommended for new options.

13. The HTTP Server can now be restarted:
$ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=HTTP_Server
Reminder: following these steps invalidates all support for AS, not just for the PHP component, and should not be used in production environments.

These steps are based on those that Michael Sekurski from one of our infrastructure groups sent me a while back.  They will appear in the next release of the Underground PHP and Oracle Manual so let me know of any suggestions.

Comments:

I think to any normal person, these instructions sound far to complex. - Since they are comming out of oracle, and not some poor developer. You would expect RPM/DEB pre-builts and using standard linux commands. - Modifying Enviroment variables? - non-standard install paths all over the place! think /usr/share/oracle... etc. - no understanding of when to switch to ROOT? I guess I expect better from oracle.. (although I've no idea why, track record is a bit flakey)

Posted by Alan Knowles on June 01, 2007 at 01:31 PM PDT #

The instructions are for a non-standard build. If it were supported I would expect it to be easier too. Your points about paths and root are mistaken - I'm not even sure where they are coming from. At the bigger picture since Application Server is multi-platform and uses its own installer, RPM/DEB packages are not something that spring to mind in this particular context. But thanks for your comments - I do get your general drift. I'll will definitely pass your post along to our Application Server team.

Posted by Christopher Jones on June 01, 2007 at 05:52 PM PDT #

Compiling php is fine with me, since we always use custom bulds of Apache+Php on our servers anyway. What bothers me is the fact that Oracle always includes WAAY old technology inside its stacks. As long as it was a single jre I would not mind too much, but now every single "little" Oracle app globs together the complete open source stack (take a look at OEM agent: 500+ MB for an agent???), so you end up with 5 different versions of java,perl,php installed. Sooner or later you'll end up screwing your PATH and LD_LIBRARY_PATH and get everything borked. What about security patches? Did oracle backport MOPB bug fixes to their own php 5.1.2? The "all of this is not supported and will void your PRICEY support contract" part is the bet, really. Not only you have to jump through hoops to get the thing built (eg. the missing oci headers), but you are in fact not allowed to do that. What I really would appreciate is a more modular oracle ecosystem, where single pieces can be swapped in/out at the choice of the sysadmin...

Posted by Gaetano Giunta on June 10, 2007 at 08:12 PM PDT #

I appreciate the direct comments and hope you'll all keep telling us where we don't satisfy your needs. From my inside-of-Oracle perspective we provide software with a rich set of features and requirements. While modular is a goal, and things like Oracle Instant Client or Zend Core for Oracle are steps in that direction, certifying a full stack of comprehensive software will always place some limits on dependencies because the cost/effort to certify every combination is prohibitive.

Posted by Christopher Jones on June 11, 2007 at 01:29 PM PDT #

One thing that I have been championing for a long time is for Oracle to treat things like this (and the jdk, as well as others) the same way they treat the OS and its required RPMs. Indicate what versions are supported, what components are required, and stick to having the installer deploy the Oracle specific stack. As the comment of an earlier poster illustrated, this type of solution wouldn't be for everyone as there are people that need things kept simple but to have the solution limited by catering to the lowest common denominator also restricts the ability to convince certain organizations to put Oracle in because of cross-cutting concerns within the environment / organization. Honestly, the huge leaps forward in the quality of the application server product are astounding I just think for the long term viability of the platform that a more "pluggable" architecture will end up being required. Particularly when one takes into consideration the Fusion philosophy and the continuous stream of acquisitions.

Posted by Shaun O'Brien on June 14, 2007 at 04:54 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

Tourists looking out over an Opal mine
I'm a Product Manager in Server Technologies, working on scripting languages and developer-access.
Email: christopher.jones@oracle.com
Twitter: http://twitter.com/ghrd
Book: Free PHP Oracle book
Download: PHP Linux RPMs with the OCI8 extension
Links: OTN PHP Developer Center

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today