Compiling PHP, OCI8 on Sparc64 Solaris 10 with Oracle10g

This problem beat me about the head for most of yesterday until I worked out that PHP 5.0.5 doesn’t actually know about Oracle 10.    8 and 9, sure thing – otherwise it decides it is an older version (very silly).

The other problem is that when PHP tries to link to the oracle client libraries, by default it attempts to link against the 64 bit libraries – which with PHP being a 32bit app just isn’t going to fly.

So here I will attempt to guide you in all that is good with PHP and Oracle 10.

The first thing to do is ensure you have a working Solaris 10 install with Oracle 10g already
installed.   As this was to be an actual server machine I installed the full database server including client libraries (which happens by default when you install server).  However the purpose of this is not to help you install Oracle – there are plenty of guides out there for that.  This is to help you get PHP compiled in this environment – there are no guides for that.

So lets unpack the PHP source:
#->tar xf php-5.0.5.tar
#->cd php-5.0.5
php-5.0.5-#->

Now, If you run a straight ./configure –with-oci8 it will most likely fail being unable to find the oracle install:
checking Oracle version… configure: error: Oracle (OCI8) required libraries not found

We need to tell it where to find the oracle libraries.
./configure –with-oci8=/u01/app/oracle/product/10.2.0/Db_1
(assuming this is where your default database was installed to)

This will enable configure to complete.

Next, naturally, we try to make php – all should go well right up until the final link:
php-5.0.5-#->make
… [snip] …
ld: fatal: file /u01/app/oracle/product/10.2.0/Db_1/lib/libclntsh.so: wrong ELF class: ELFCLASS64
ld: fatal: File processing errors. No output written to sapi/cgi/php
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php] Error 1

This fails because PHP has decided to link against lib/libclntsh.so when it should have linked against lib32/libclntsh.so

No amount of adding –includedir= and –libdir= on the configure command will result in make doing the right thing and linking against the lib32 version.

The solution? We need to edit the configure script to tell it that lib isn’t the be-all and end-all of oracle libraries.  This is a pain, I know, but hopefully the PHP people will fix this for 5.0.6 and above.

At line 64660 in configure you will see the line:
  elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then

Change /lib/ to /lib32/

And at line 69134 you’ll notice that it is missing any reference to Oracle 10.1, so we need to add it – add the following two lines just before the 9.0 line:
  elif test -f $ORACLE_DIR/lib32/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then
    ORACLE_VERSION=10.1

At line 64977 change:
  if test -z "$OCI8_DIR/lib" || echo "$OCI8_DIR/lib" | grep ‘^/’ >/dev/null ; then
    ai_p=$OCI8_DIR/lib
to:
  if test -z "$OCI8_DIR/lib32" || echo "$OCI8_DIR/lib32" | grep ‘^/’ >/dev/null ; then
    ai_p=$OCI8_DIR/lib32

Line 64368: add
  OCI8_SHARED_LIBADD="-L$OCI8_DIR/lib32"
  LIBS="$LIBS -L$OCI8_DIR/lib32"

Now make clean;
cd to your database and rename the lib directory to lib.unused temporarily so that PHP cannot link against it and leave the lib32 one as is.

Switch back to php dir. Run your configure command, make (which should now complete) and make install.

Go back and rename the lib.unused back to lib as other things will need this to exist.

Finally, make sure you add the lib32 path to your LD_LIBRARY_PATH variable before starting apache/php

LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/u01/app/oracle/product/10.2.0/Db_1/lib32"

Your PHP should now be working fine.

Files to help: My "configure" command:
‘./configure’
‘–prefix=/usr/local/apache2’
‘–includedir=/space/app/oracle/product/10.2.0/Db_1/rdbms/public’
‘–oldincludedir=/space/app/oracle/product/10.2.0/Db_1/rdbms/public’
‘–libdir=/space/app/oracle/product/10.2.0/Db_1/lib32’
‘–with-apxs2=/usr/local/apache2/bin/apxs’
‘–with-oci8=/u01/app/oracle/product/10.2.0/Db_1’

Diff of the configure script to the regular one supplied with PHP 5.0.5
#->diff php-5.0.5/configure php-5.0.5-working/configure                           6:39AM
64367a64368,64369
>   OCI8_SHARED_LIBADD="-L$OCI8_DIR/lib32"
>   LIBS="$LIBS -L$OCI8_DIR/lib32"
64660c64662
<   elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then

>   elif test -f $OCI8_DIR/lib32/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then
64977,64978c64979,64980
<   if test -z "$OCI8_DIR/lib" || echo "$OCI8_DIR/lib" | grep ‘^/’ >/dev/null ; then
<     ai_p=$OCI8_DIR/lib

>   if test -z "$OCI8_DIR/lib32" || echo "$OCI8_DIR/lib32" | grep ‘^/’ >/dev/null ; then
>     ai_p=$OCI8_DIR/lib32
69133a69136,69137
>   elif test -f $ORACLE_DIR/lib32/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then
>     ORACLE_VERSION=10.1

Note to PHP developers if they read this – this patch is not one that can be dropped into the regular build – it will only help people who have difficulty installing PHP with OCI8/Oracle10 on Solaris10.

I hope this proves useful to others – it took me >24 hours work to get to this point.

Buy the Whitehouse, get an SQL injection attack

The Internet casino and poker house GoldenPalace.com bought up the only known deed for The White House as reported by The Inquirer.

Except that the link that the inq uses to get to the page telling the story at casinocitytimes.com revealed a little more information than they should have.   Because the URL on the inq was mistyped – they tried to make two links but only made one broken one.

When I clicked on the link: http://www.casinocitytimes.com/news/article.cfm?contentID=153470%5D %20and%20here%20[http://realtytimes.com/rtcpages/20050831_titleinsurance.htm I received an error page that was obviously the result of an unchecked contentID being passed right from the url into the SQL.

This is a classic case of unchecked user supplied data being trusted which leads to a compromise in security and some very red faces when some naughty people get hold of it.

I hope they fix it soon.

PHP: HTTP Authentication via PHP

When combining sessions with HTTP Auth in order to maintain state. The difficulty surrounding HTTP Auth is that even after you "logout", the browser will continue to send the correct username and password with each request. Thus immediately logging you back in again – unless you use the states to keep track carefully.

In this example we will use two session variables to maintain state and we tell the page that we want to login our logout via an argument in the query string, e.g. ?login ?logout

The two state variables are:

    * LOGGEDIN – Very simple state – either you are logged in or not
    * LOGGEDOUT – Will be TRUE if we have logged out. It’s primary purpose is to scupper the browser provided password and prevent the authentication routines from running. It gets reset to FALSE when we want to login

Additional benefits to this method are that we only need to authenticate upon login once. Normal code implemented HTTP Auth routines authenticate with every page request

Source code: Example page protected with PHP HTTP Auth

Source code: PHP HTTP Auth include file

In order to use this to protect any page you need to copy the auth.inc.php file to your server and then simply include or require it in any page.
You may wish to set the variable $HTTP_AUTH_REALM to a string before including this as this will change the Basic Realm information in the auth dialog box to a string of your choice.

You should also look at the checkpw() function and replace that with something that will check your user credentials correctly. Input is username, password and it should return TRUE or FALSE if the credentials supplied are OK or not.

Finally, on any page to effect a change of state from logged in to logged out or vice-versa, you simply have to make a link to a page with "login" or "logout" in the url’s Query String (that is the bit after the ?), e.g. page.php?login

A working example is provided over in my projects section, the default username is "paul" and password is "gregg"

I hope this code serves as useful learning material. Good luck.

Freedom of Information, Request #1, The reply.

It was remiss of me not to follow up on my earlier FOI post (thanks Tony for the prompt).  Rather than just post the reply as a comment to that post (it’ll never be seen), I will post it here.

Basically they decided to withhold the information as it pertains to current policy discussion.

Here is a GIF of the response (resized):

Full size version can be found here

Shame really.

All content © Paul Gregg, 1994 - 2024
This site http://pgregg.com has been online since 5th October 2000
Previous websites live at various URLs since 1994