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.

Create the webapp directory

Since the configuration files have to be modified an exploded WAR has to be used. The webapp directory has to be created and the WAR will be extracted inside of it.

mkdir xwiki && cd xwiki
unzip ../xwiki.war
rm ../xwiki.war

Create and configure a database

Create a database including a dedicated database user. Open the file WEB-INF/hibernate.cfg.xml and uncomment the MySQL block. Modify the following properties:

• connection.username
• connection.password
• connection.url

Important: Don’t forget to add the MySQL JDBC driver to your classpath (e.g. WEB-INF/lib).

Note: It is of course also possible to use a container managed DataSource via JNDI.

Configure Logfile

Since the security manager restricts file IO to the webapp directory the logging has to be reconfigured. To do so the log4.properties file has to be copied from xwiki-core-2.0-milestone-4.jar to the WEB-INF/classes directory. After this the property log4j.appender.file.File has to be modified to point to a writeable path.

Add the context file to Tomcat

Add a file name ${context}.xml to the /conf/Catalina/localhost” directory of $CATALINA_HOME (the Tomcat instance) and put the following content into it:

<Context path="${contextPath}" docBase="${pathToWebapp}" ></Context>

Eventually put in references to resources like DataSource’s etc.

Create the proxy settings in Apache HTTPD

You can use any proxy settings. I’m currently using a very simple setup:

<Proxy ajp://localhost:10709*>
  Allow from all
</Proxy>

RewriteEngine On
RewriteRule ^/$ /xwiki/ [R=301,L]

ProxyPass        /      ajp://localhost:10709/
ProxyPassReverse /      ajp://localhost:10709/

Note: xwiki is the contextPath

Test the installation

Surf to http://www.yourdomain.com/. An empty XWiki page should be displayed. The first step should always be to register a user so the administration area is accessible. The default content can be imported by using the page /${contextPath}/bin/import/XWiki/XWikiPreferences.

I’ll probably blog more about XWiki and how to customize it in the future.

Prerequisites

• OpenCms 7 (already installed)
• Apache HTTPD 2.2 with mod_proxy_ajp
• Apache Tomcat 5.5+

Goal of the setup

• Dynamic content served from http://www.yourdomain.com/
• Static content served from http://www.yourdomain.com/opencms/export/

Steps to perform

Configure Tomcat

As described in the Howto you have to add the emptySessionPath=”true” attribute to the Tomcat AJP Connector in the server.xml:

<Connector emptySessionPath="true" port="8009" protocol="AJP/1.3" />

Configure OpenCms

You have to modify the opencms-importexport.xml configuration file. But beware the <rfs-prefix> doesn’t need changing anymore. In fact: Things won’t work if you change it the old way. These are the settings you want.

       <rfs-prefix>${CONTEXT_NAME}/export</rfs-prefix>
       <vfs-prefix></vfs-prefix>

Don’t forget to restart OpenCms.

Configure Apache HTTPD

Since the AJP Connector is now integrated in mod_proxy you don’t need the (stupid) rewrite rules anymore. I also got rid of the fact that static content is served from Apache. This has several reasons:

1. The new Tomcat is fast enough to serve static content itself. Espcecially with the NIO / APR Connector.
2. If you ever want to move the Tomcat to a different machine and use Apache HTTPD as a simple load balancer things get a lot easier if Apache doesn’t need access to the web application files.

Here’s an example virtual host:

<VirtualHost *:80>

  ServerName yourdomain.com
  DocumentRoot /some/directory

  <Proxy ajp://localhost:8009*>
     Allow from all
  </Proxy>

  ProxyPass        /opencms/   ajp://localhost:8009/opencms/
  ProxyPassReverse /opencms/   ajp://localhost:8009/opencms/

  ProxyPass /          ajp://localhost:8009/opencms/opencms/
  ProxyPassReverse /   ajp://localhost:8009/opencms/opencms/

</VirtualHost>

This is it. Don’t hesitate to ask questions.