Tag Archives: PHP

Fixing PHP-FPM’s SCRIPT_NAME Bug The Brute Force Way

It’s not really news that PHP in it’s CGI or FPM flavor has slight to modest problems getting it’s environment right when using Apache as the front end web server, especially the $_SERVER[‘SCRIPT_NAME’] variable many scripts rely on to determine their true location on the hard drive. This erratic behavior is heavily documented in bug reports 51983 and 55208. As is common practice for the PHP-FPM team, their approach is to sit still and wait until this bug goes away on it’s own. This approach, proven to work for many politicians, may however not work for those folks, that need a solution to the problem at hand. A quite simple solution that unfortunately requires to recompile PHP is the following brute force patch for PHP 5.3.8:

--- php-5.3.8/sapi/fpm/fpm/fpm_main.c.org   2011-07-18 23:03:44.000000000 +0200
+++ php-5.3.8/sapi/fpm/fpm/fpm_main.c.  2011-11-24 18:29:37.000000000 +0100
@@ -1084,6 +1084,7 @@
 {
    char *env_script_filename = sapi_cgibin_getenv("SCRIPT_FILENAME", sizeof("SCRIPT_FILENAME") - 1 TSRMLS_CC);
    char *env_path_translated = sapi_cgibin_getenv("PATH_TRANSLATED", sizeof("PATH_TRANSLATED") - 1 TSRMLS_CC);
+   char *env_redirect_url = sapi_cgibin_getenv("REDIRECT_URL", sizeof("REDIRECT_URL") - 1 TSRMLS_CC);
    char *script_path_translated = env_script_filename;
    char *ini;
    int apache_was_here = 0;
@@ -1118,6 +1119,16 @@
 
        /* Hack for buggy IIS that sets incorrect PATH_INFO */
        char *env_server_software = sapi_cgibin_getenv("SERVER_SOFTWARE", sizeof("SERVER_SOFTWARE") - 1 TSRMLS_CC);
+                if (env_redirect_url &&
+                        strncmp(env_server_software, "Apache", sizeof("Apache")-1) == 0) {
+                        /*
+                         * If we have an env_redirect_url and the web server is Apache
+                         * it's very likely that env_redirect_url is the one we really
+                         * want
+                         */
+                        env_script_name = _sapi_cgibin_putenv("SCRIPT_NAME", env_redirect_url TSRMLS_CC);
+                }
+
        if (env_server_software &&
            env_script_name &&
            env_path_info &&
@@ -1159,7 +1170,7 @@
        if (CGIG(fix_pathinfo)) {
            struct stat st;
            char *real_path = NULL;
-           char *env_redirect_url = sapi_cgibin_getenv("REDIRECT_URL", sizeof("REDIRECT_URL") - 1 TSRMLS_CC);
+           // char *env_redirect_url = sapi_cgibin_getenv("REDIRECT_URL", sizeof("REDIRECT_URL") - 1 TSRMLS_CC);
            char *env_document_root = sapi_cgibin_getenv("DOCUMENT_ROOT", sizeof("DOCUMENT_ROOT") - 1 TSRMLS_CC);
            char *orig_path_translated = env_path_translated;
            char *orig_path_info = env_path_info;

WebSVN 2.3.1 for ReadyNAS (Sparc & Intel)

Since I was already updating the SVN stuff for the ReadyNAS line I thought I might as well upgrade the WebSVN add-on. So here we go:

ReadyNAS NV(+)/Duo/1100/X6: WebSVN_2.3.1-readynas-1.0.0.bin
ReadyNAS Pro/NVX/2100/3200: WebSVN_2.3.1-readypro-1.0.0.bin

Continue reading

MySQL Tuning: The PHP Auto-Reconnect Patch

Now this would be really funny if it weren’t so sad in so many aspects: I know of more than one company running MySQL. Ok, no news there. But the MySQL servers of said companies are dropping connections. Not twice a week or once a day but two or three times every bloody second. Investigation of the cause is underway but obviously that doesn’t help to fix the problem at hand.
Since the major platform in said companies is PHP, there’s another problem: Tests have shown that if a connection failed a subsequent connection request will go through just fine. While not ideal, the best solution for the moment would therefor be to enable the auto-reconnect feature built into every MySQL client. But for PHP, there is no option to do just that.

That’s because even while PHP is using the

mysql_option()

function – which is needed to enable auto-reconnect – internally, nobody cared to make it available as part of PHP’s language. Maybe it would be easy to do just that, but I found it easier to patch PHP directly to enable auto-reconnect by default. You want to know how? Read on.

Continue reading

Speed up WordPress with memcache

We all love WordPress. But, honestly, it’s everything but fast. An easy way to speed it up a good deal is to make it use memcached for storing some of it’s data. And doing this is actually easier than one might think. There are some pre-requisites:

  1. Download and install libevent
  2. Download and install memcached
  3. Download and install the memcache extension for PHP

The first two follow the standard

"./configure; make; make install

route. For the third I suggest using

/path/to/your/php-install/phpize
./configure --enable-memcache
make
make install

Take note where the extension is intalled and have PHP load it by adding

extension=memcache.so

to your php.ini. There’s a chance you’ll have to edit the line

extension_dir=...

, too, to reflect the actual path where the extensions can be found. After restarting PHP you should see the

memcache

extension in the output of phpinfo.

If everything is fine, we can add memcache support to our WordPress installation:

Continue reading

No IonCube Loader for PHP 5.3.0 – for now ;)

This is what I received today after offering a Solaris build environment to the guys from IonCube so they could build a version of their loader for my preferred web server OS:

Continue reading

URL file access is disabled in server configuration

Once in a while you’ll see the error message “URL file access is disabled in server configuration” when opening an external URL using PHP. In general, this means that the HP setting

allow_url_fopen

is set to false. Today I ran into this problem but

allow_url_fopen was set to <em>true</em>. As it turned out the culprit was
allow_url_include

this time.

{openx:6}

So either set in php.ini

allow_url_fopen = On
allow_url_include = On

or use this in your PHP code:

<?php
ini_set('allow_url_fopen', 'on');
ini_set('allow_url_include', 'on');
...
?>

I should probably add that both settings default to ‘Off’ for a reason. Both are the major entry gates for malicious code when used without proper care.

PEAR broken in PHP 5.2.10

While trying to upgrade a customers installation to PHP 5.2.10 I learned that hard way that PEAR is broken in this release. This isn’t specific to any OS as the bug reports show but rather seems to be a general problem that slipped Q&A (who is laughing there?). All you’ll get is

"Cannot use a scalar value as an array in
phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391"

when trying to install PEAR.
So, for the time being, better not upgrade to PHP 5.2.10 if you need to use PEAR.

{openx:6}

FastCGIExternalServer demystified

Separating Apache and PHP has some advantages. Faster delivery of non-PHP content, lesser load on the servers to name just the most obvious ones. That’s why you can find this kind of setups mostly at smaller ISPs. To really benefit from the separation of Apache and PHP, however, you’d need to move PHP to completely seperate servers.

That’s where

FastCGIExternalServer

comes into play. In theory this Apache configuration directive allows you to specify an external server where all requests for PHP scripts (or any other resources you define) will be sent to. But where you’ll find plenty of documentation about how to install a FastCGI server on the local machine, the documentation about how to use an external server is almost non-existant. And the official documentation doesn’t really help and neither does the FAQ. Or would you find this helpful:

What is the path used with FastCGIExternalServer?

Since all FastCGI directives are global (they are not configured in a server context), all FastCGI paths map to the filesystem. In the case of external servers, this path does not have anything to do with the file system; it is a virtual file system path. Since the connection between mod_fastcgi and the FastCGI app is by a socket (unix or tcp), mod_fastcgi does not care where the program is (it could be on a completely different machine). However, mod_fastcgi needs to know when a hit is calling for an external app, so it uses this path as if it were a local filesystem path. Apache translates a request URI to a filesystem path.

Most ironcally, it’s exactly the path mentioned above that causes most users to give up on

FastCGIExternalServer

. Ok, so let’s get our hands dirty. Follow me into the abyss of weird logic and software bugs to finally get your external PHP server up and running. On the way you’ll learn that nothing is as it seems and that the FAQ entry quoted above is misleading at best.

[ Continue reading » ]

{openx:6}

Eclipse 3.5 Galileo released

eclipsegalileo
By far the largest Eclipse release ’til now. And what’s most important for me: Updated PDT versions are also available right at launch.

{openx:6}
[ More » ]

PHP: Fix For The Empty $_POST Array

One of the reasons I “love” PHP so much is that it sometimes poses problems the solution of which makes you scratch your head in wonder. Take for example the spurious “empty $_POST array” problem. It is easy to recognize for what happens is that parameters passed to a PHP script via a POST request won’t show up in the $_POST superglobal array.
To fix this, first make sure that you really pass the parameters. This can be easily checked:

Continue reading

ReadyNAS Package PHP5-IMAP: Dependency Hell

I just uploaded the PHP5-IMAP package to ReadyNASFreeware.org. This was harder than expected because of some really ugly dependency problems introduced with RAIDiator 4.1.5.

Continue reading

How to compile Oracle support (Oci8) for PHP on Solaris

Ok, we all know that this should be a trivial task. And it really is. Just a few steps to complete:

  • Go to Oracle’s download page
  • Search for the real download link
  • Choose your favorite platform there
  • Click on desired file
  • Click ok on popup reminder that you have to agree to the Download Licence Agreement
  • Click “Accept Download Licence Agreement”
  • Click on desired file (again)
  • Press ok on Popup window telling you to register
  • Go to register page, fill in registration data
  • Click “Continue”
  • Read error message
  • Go back to registration and sign up for one of the mandatory newsletters
  • Go back to download site (You *did* bookmark it, did you?)
  • Click on desired file (again)
  • Click on desired file (again)
  • Find out that the download has already started in the background
  • Delete superfluous copies of the file you downloaded
  • unZIP (as we all know, ZIP *is* the packer of choice on *nix alike platforms)
  • Download OCI8 support from pecl.php.net
  • Unpack
  • Start configure
  • Learn that the Oracle Instant Client doesn’t contain the header files
  • Go back to Oracle Download Page (you’d *really* better bookmark that page, dude)
  • Click on … download … unzip
  • Try to configure Oci8 again (will fail anyway)
  • Go to unpacked Oracle SDK dir
  • Create ./lib directory
  • Move files from Base Client directory to newly created lib dir
  • Go back to Oci8
  • Try to configure (will work this time)
  • Make (will fail)
  • Patch Makefile for Oci8 (hint: Add library pathes for Oracle Client)
  • Configure (will fail, even if you patched correctly)
  • Go back to Oracle Client SDK lib dir
  • Create symlink for libclntsh.so
  • Go back to Oci8 dir
  • Make (will work, really)
  • Make install
Guys, that’s really like software installation should work in 2008. Not.

Using Zend Debugger with your custom built PHP – on an Intel Mac with Leopard

Maybe you’ve had your go at this problem already: Trying to make ZendDebugger work with a custom built PHP on a Mac. I’ve been hammering at this problem for some days now – just to find out that the problem is a trivial one. For some reason unknown to me Zend choose to build the ZendDebugger.so as a 32 bit module. If, however, you compile and run software on an Intel-Mac using Mac OS X 10.5 Leopard, the software will automagically run in 64 bit mode. And that’s why Apache+libphp5.so and also the CLI version of PHP won’t run the ZendDebugger.

So, the easy solution would be to just create 32 bit executables when building Apache/PHP. Did I just say “easy”? How is one to build a 32 bit application in the Mac you might ask yourself. Well, again, that’s easy. You’d just have to pass “-arch i386” to gcc when compiling the app. But how to do that, now?

As luck has it, most Open Source applications by now know about the Mac platform. Thus, they handle it within their configure scripts. A commonly used compiler option that gets set on the Mac is “-no-cpp-precomp”. So basically all you have to do is:

  • get the archive of the app you want to build
  • untar
  • do a ‘grep -R “-no-cpp-precomp” *’
  • take note of all the files the above command finds
  • use the script below
  • configure and compile as usual

The script I mentioned above is quite short:

#!/bin/bash
for FILE in $*; do
    sed -e “s/-no-cpp-precomp/-no-cpp-precomp -arch i386/g” $FILE > tmpfile
    mv tmpfile $FILE
done

I called mine “macify” and put it in /usr/local. The script will add the compile flag needed for generating 32 bit executables/libraries to the files you pass it one the command line. For PHP the command would be “macify configure configure.in”, for apache it would be “macify srclib/apr/configure srclib/apr/build/apr_hints.m4”.

By the way: you don’t have to do this for all apps and libraries you need in the process of building the final app. Since the gcc version used on Mac OS X will generate “universal” binaries and libraries, you just have to modify the final app like that while you can compile all supporting libraries without any modifications.

Would be nicer, though, if Zend could come up with a 64 bit version of the ZendDebugger.