Curtis Summers

A couple of weeks ago I was installing a development environment at work on CentOS with Apache 2, PHP, and the oci8 module. All configured, make’d, and installed, I was up and running with Apache, PHP, and the Oracle Client tools (sqlplus, etc.) in short order. Everything worked except the oci8 php library functions–they couldn’t find my Oracle instances to connect.

I had covered all of the bases:

• I could connect with sqlplus to my instance, so the Oracle client worked
• I had set the ORACLE_HOME with SetEnv in Apache’s configuration file and in bash’s system profile
• phpinfo() showed the oci8 module as installed and the ORACLE_HOME environment variable as set

This problem had me stumped a good part of an afternoon until I attempted to start Apache directly with apachectl instead of through the ‘service’ command used in CentOS. Suddenly, it worked!

A quick shuffle through the service script and I found that it was restricting the environment before calling the service like so:

env -i LANG=$LANG PATH=$PATH TERM=$TERM "${SERVICEDIR}/${SERVICE}"

Hmm. So, only LANG, PATH, and TERM are passed into any service environment: ORACLE_HOME is left out in the cold. And, even though I set it in the httpd.conf file, this is apparently too late for it to make a difference in the php oci8 module. A quick fix in the service script adds the requisite ORACLE_HOME:

env -i ORACLE_HOME=$ORACLE_HOME LANG=$LANG PATH=$PATH TERM=$TERM "${SERVICEDIR}/${SERVICE}"

The line above occurs a few times, so add to each occurance. Voila! It works.

I’m content with this solution for now, but I don’t particularly like having to change the service script, so is there any other way to do this?

Update:This is apparently a common issue: Debian mailing list comment, Gentoo bug, which is fixed with a white list of environment variables in a separate file. I couldn’t find a similar RedHat/CentOS bug. And, the SetEnv in the httpd.conf file is only effective for CGI PHP, which does not work for me because I’m using mod_php

For about a week now Windows Update on my work machine has failed to download or install the latest security patches. I’ve tried Automatic Updates and going directly to the windowsupdate.microsoft.com site, but both methods start to download and then fail with no error messages. Perfect.

So, I did some digging and found that the update log lives here (in default XP Pro): C:\Windows\SoftwareDistribution\ReportingEvents.log

Scrolling down through this text file I find the 9th column over to show the error number: 80264005

Google then brings up Ali’s helpful blog entry: Windows update gives a 80246005 error

Basic rundown: Stop the Automatic Updates service, delete the contents of C:\Windows\SoftwareDistribution\DataStore, restart the Automatic Update service and try the download/install of updates again.

Worked for me. Thanks, Ali.