Preparation

To make the approach more modular we will use an environment variable pointing to our htdocs directory. I will call this variable $HTDOCS.

export HTDOCS=/kunden/homepages/.../htdocs

We can check if everything is correct by changing into the htdocs directory.

cd $HTDOCS

We will now create two directories:

• $HTDOCS/linux-src: To hold all the data we need to compile the extensionn
• $HTDOCS/linux: To hold all the compiled data

This setup allows us to delete the linux-src directory after we finished compiling the extension and save some diskspace.

mkdir -p $HTDOCS/linux-src
mkdir -p $HTDOCS/linux

Now we will download the required sourcecode into our working directory:

mkdir -p $HTDOCS/linux-src/download
cd $HTDOCS/linux-src/download
wget ftp://ftp.imagemagick.org/pub/ImageMagick/ImageMagick.tar.gz
wget http://pecl.php.net/get/imagick-2.3.0.tgz
wget ftp://ftp.remotesensing.org/pub/libtiff/tiff-3.8.2.tar.gz
wget http://us3.php.net/get/php-5.2.10.tar.gz/from/us.php.net/mirror

Note: The URLs to the latest versions may change over time. You will have to adjust them and also watch for changed file names in the following steps. Also be sure to use the PHP version currently active on your managed server.

Extracting the sourcecode

Now create a folder for the extracted sourcecode and extract the source archives:

mkdir -p $HTDOCS/linux-src/extracted/imagick
mkdir -p $HTDOCS/linux-src/extracted/php-imagick
mkdir -p $HTDOCS/linux-src/extracted/libtiff
mkdir -p $HTDOCS/linux-src/extracted/php5

cd $HTDOCS/linux-src/extracted/imagick && tar xfz $HTDOCS/linux-src/download/ImageMagick.tar.gz
cd $HTDOCS/linux-src/extracted/php-imagick && tar xfz $HTDOCS/linux-src/download/imagick-2.3.0.tgz
cd $HTDOCS/linux-src/extracted/libtiff && tar xfz $HTDOCS/linux-src/download/tiff-3.8.2.tar.gz
cd $HTDOCS/linux-src/extracted/php5 && tar xfz $HTDOCS/linux-src/download/php-5.2.10.tar.gz

Building delegate libraries

ImageMagick uses different delegate libraries for certain formats. We have to build these first so they can be incorporated into our ImageMagick build. In this case we will only use libtiff to allow the usage of the TIFF image format.

Building libtiff from source

Building libtiff is pretty straightforward. Simply use the following commands inside the extracted source archive:

./configure --prefix=$HTDOCS/linux/
make
make install

Building ImageMagick from source

Change into the extracted source directory and type in the following:

./configure --without-perl --prefix=$HTDOCS/linux \
  CPPFLAGS="-I$HTDOCS/linux/include" LDFLAGS="-L$HTDOCS/linux/lib/"
make
make install

You can type the following command to test the compiled ImageMagick.

make check

After ImageMagick is built we can now go on and create the PHP extension.

Building the ImageMagick PHP extenstion

To compile the extension we have to have a PHP development environment in place. To create one we’ll simply compile and install PHP (this sounds more scary than it is).

Building PHP from source

Change into the extracted PHP archive and type in the following:

./configure --prefix=$HTDOCS/linux
make
make test
make install

The make test target will run the PHP test suite. You can expect some tests to fail but if the number of failing tests is overwhelming you should get suspicious.

Building the ImageMagick PECL extension

Change into the extracted source archive and type in the following:

phpize --clean
phpize
./configure --prefix=$HTDOCS/linux --with-php-config=/usr/bin/php-config5 --with-imagick=$HTDOCS/linux

The configure script should go through. Unfortunately it seems that the prefix and paths will not be set correctly in the Makefile. We will have to adjust this and replace the /usr/local paths with the path to our $HTDOCS/linux

echo "$HTDOCS/linux" | sed -e 's/\//\\\//g' > htdocs_pattern && \
  export HTDOCS_PATTERN=`cat htdocs_pattern` && rm htdocs_pattern
perl -pi -e "s/\/usr\/local/$HTDOCS_PATTERN/g" Makefile

Note: The above command looks a bit freaky and is a bit of a quick hack. What it basically does it is escaping the slashes (/) in the $HTDOCS path and writing this to a file. Then exporting the content of the file to an environment variable and deleting the file. After this PERL is used to replace all /usr/local paths in the Makefile to $HTDOCS/linux

After that we are good to go and can build the extension:

./configure --prefix=$HTDOCS/linux
make
make install

Now the extension should be build successfully and is placed in the directory $HTDOCS/linux/somepath (the make install will tell you the extact path) . The last thing we have to do is activating the extension.

Activating the extension

To activate the extension for a certain folder, create a file named php.ini (for example in the $HTDOCS directory) with the following content inside the folder:

extension_dir=$HTDOCS/linux/somepath
extension=imagick.so

Also don’t forget to activate PHP 5 with using a .htaccess file:

AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php

That’s all. If you have any questions feel free to comment. I hope this helps some of you.

The Problem

One problem with the current Plesk version (as with most Plesk versions :/) is that it has some nasty bugs. For example mod_rewrite doesn’t work with the FastCGI configuration. The problem is that the generated virtual host configuration has a small but important problem. The generated host looks something like this:

<VirtualHost 88.198.164.10:80>
  ServerName   playground.himberger.de:80
  ServerAlias  www.playground.himberger.de

  <IfModule mod_fcgid.c>
    <Files ~ (\.php)>
      SetHandler fcgid-script
      FCGIWrapper /usr/bin/php5-cgi .php
      Options ExecCGI
      allow from all
    </Files>
  </IfModule>
</VirtualHost>

The issue with this configuration is the line “Options ExecCGI“. This line enables the execution of CGI scripts for this particular directory but overrides all the Options set earlier. These are in parts needed for mod_rewrite. To fix this the line should be “Options +ExecCGI“. Sadly changing the configuration doesn’t help because at the next opportunity Plesk will regenerate the config file and your change is gone.

Luckily there is a way around this…

Enable mod_rewrite (the solution)

Luckily Plesk allows you to append a custom configuration to the virtual host by creating a file vhost.conf in the ${yourvhost}/conf directory. By putting the following config in your vhost.conf you can take back the overwritten Options (don’t forget to restart the Apache HTTPD).

<Directory "/var/www/vhosts/${yourvhost}/httpdocs">
  <Files ~ (\.php)>
    Options All
  </Files>
</Directory>

You have to be very specific (using the enclosing Directory directive) to cause the current setting to be overridden.

With this knowledge at hand we can do some other nice tricks.

Using a custom php.ini with fastcgi

Since we are now able to override the Plesk generated configuration we can also alter the fastcgi command and for example specify a custom php.ini:

<Directory "/var/www/vhosts/${yourvhost}/httpdocs">
  <Files ~ (\.php)>
    FCGIWrapper "/usr/bin/php5-cgi -c /etc/phpconfigs/${yourvhost}"  .php
    Options All
  </Files>
</Directory>

The FCGIWrapper command will use the directory specified with the -c parameter for it’s php configuration. Simply put your php.ini in this directory and it will automatically be picked up. This way you can easily use a per customer PHP configuration with fastcgi and Plesk.

“Enterprise software just means that it’s targeted at customers who can afford the guy who restarts the application server every few hours.”

I had to laugh because while the quote is clearly cynical it has a true core. Especially if you compare languages like Java and PHP it’s true that PHP doesn’t have these kind problems. This is mostly because of the throw-away-the-state nature of PHP. After every served request PHP forgets what it’s done before and has to completely rebuild the working environment at the next request. Java in contrast is able to remember things between requests. Which makes it more powerful but also harder to maintain (more state, more problems). I’m really not sure if I’m buying into this enterprise-thing anymore. Especially if you need scalability you definitely want to keep application state at a minimum and without state you don’t really need those big interconnected clusters of application servers any more.

Here is a nice talk about scalability and serious (speak enterprise) languages I found recently. It’s from Cal Henderson a software development guy at Flickr. It’s really worth watching. Even if you’re not into Python and Django.

(Watch it at: http://www.youtube.com/watch?v=i6Fr65PFqfk&feature=PlayList&p=D415FAF806EC47A1&index=10)

I recently discovered runkit for PHP and thought it could be a solution for a few problems I ran into during my work on various projects.

At heart runkit allows you do to stuff with PHP you shouldn’t, but eventually want to, do. In my case this is basically Sandboxing and redefining (even PHP-internal) functions. It really adds some cool stuff to your PHP toolbox. Have a look at the function reference for the complete list.

Sadly enough the runkit PECL package does not work on Debian Etch (because Etch uses PHP 5.2.0+) so I had to build the package myself. Read on to find out how to build and install runkit on Debian etch and things to keep in mind when using runkit.

Important: If you are unsure of using runkit have a look at The sections The Caveat and Final Remarks before you walk through the hassle of installing it.

Install & Configure runkit

Obtain the sources from the runkit CVS

Obtaining the sources is pretty easy. Just open a terminal and enter the following commands (leave the password empty when prompted for it)

cvs -d:pserver:cvsread@cvs.php.net:/repository login
cvs -d:pserver:cvsread@cvs.php.net:/repository co pecl/runkit

This will checkout the runkit codebase into your current working directory.

Building the Debian package from the PECL source

You need some tools for building the package so I installed them using aptitude.

sudo aptitude install dh-make-php php5-dev

Then I created a kind of fake PECL package from the CVS sources to use it with the dh-make-pecl tool. dh-make-pecl is a Debian tool which helps you building .deb from a PECL package. The PECL package is just a .tar.gz archive having the following structure:

The runkit PECL package structure

I assembled this package by using simple mv and mkdir inside the CVS then I used tar to create the archive. I called it runkit-cvs-<date>.tar.gz but the name is basically irrelevant.

mkdir -p package/runkit-0.9
mv pecl/runkit/package*xml package/
mv pecl/runkit/* package/runkit-0.9/
cd package/; tar cfz ../runkit-cvs-`date +%Y%m%d%H%M`.tar.gz *; cd ..

After I had the fake PECL package I could start creating the .deb from it. This was fairly simple.

dh-make-pecl --only 5 runkit-cvs*tar.gz
cd php-runkit-0.9
dpkg-buildpackage -rfakeroot

dpkg-buildpackage puts the created .deb parallel to the php-runkit-0.9 directory. The –only 5 parameter requests the dh-make-pecl command to only create a Debian source package for the PHP 5 module. Have a look at the manual for more information.

Installing the package

Installing runkit is now just a matter of typing sudo aptitude install php5-runkit_0.9-1_i386.deb and letting APT do it’s work. After that you have to create a configuration file under /etc/php5/apache2/conf.d called runkit.ini with the following contents:

extension=runkit.so

# comment out the following line to disable the overloading
# of PHP internal functions.
runkit.internal_override=1

After that restart your Apache server and you are done with the installation. You can check if runkit was installed sucessfull by just creating a phpinfo() file and look if runkit is listed in the modules section.

The runkit phpinfo() section

The Caveat (Renaming PHP internal functions)

I was quite happy to have all this stuff running but as we all know nothing is less predictable than solutions in information technology (apart from visiting relatives appearing out of nowhere). My first little project was to add some logging to the PHP built in mail() function. This may be useful to track down the spam sending contact form one of your customers build for his website on your server. I wrote a small script for testing purposes and just threw it in my public_html directory.

// Simple function to ouput a log message
function do_log($message) {
  echo 'LOG:'.$message;
}
// Wrapper for the PHP mail() function.
// Logs the mail parameters.
function logging_mail($to, $subject, $message, $headers = null, $params = null) {
  do_log('Sending mail to '.$to.' by '.__FILE__);
  php_mail($to, $subject, $message, $headers, $params);
}

// Interchange the built in function with my own
runkit_function_rename('mail','php_mail');
runkit_function_rename('logging_mail','mail');

mail('mymail@nodomain.xyz','Subject','message');

It all seemed nice and logical but when I first opened my webbrowser and accessed the page I got a blank screen. My Apache error log revealed a child pid 10051 exit signal Segmentation fault (11) and commenting out the mail() and a quick page refresh even added a Fatal error: Cannot redeclare do_log() to the table. This looks really bad. It seems that renaming PHP internal functions and replacing them doesn’t work with runkit and the resulting crash of the PHP interpreter left the library of this interpreter in a corrupted state (user-defined functions where not removed because the script didn’t exit properly).

So as always: The part of a library you really need has a nasty bug. Although renaming user defined functions works great with runkit the part I really wanted doesn’t work out of the box.

I already have a solution in mind but this will be the topic of another blog post.

Final remarks

Runkit in theory is really great stuff. The problem with this library in realty is that it’s still beta (even after several years) and doesn’t seem to be actively maintained. Just a short look at the CVS repository and the bugtracker revealed that there hasn’t been much activety in the last year or so. This is a pitty because having the additional flexibilty that runkit provides really would be a killer feature for PHP developers. Other scripting languages (Python, Groovy and more) already bring these features to the table natively which allows you to write extremly elegant code.

If you are willing to dig into this extension prepare to do some work and be eventually disappointed because the solution you had in mind won’t work because of bugs. If you are willing to take this risk and invest some time and energy go for it. Maybe future versions of PHP will make runkit obsolete or a good-willing developer will take care of the bugs. Till then runkit remains black magic, it can make you incredibly powerful but also is a serious risk for your mental stability.

More information

• http://gabriel.e-radical.ro/blog1.php/2008/09/25/runkit – An alternative way to build runkit
• http://en.php.net/runkit – The runkit function reference