• Synchronization of the files on the different machines
• Securing your work so in case your laptop is stolen nothing is compromised (There are lot’s of high profile horror stories of stolen customer data)

The usual answer to problem 1. is a centra file server or NAS (Network Attached Storage) which you deploy in your intranet. If you want to work on the road you most likely have to throw some VPN or SSH-Tunnel at the problem.Problem 2 is usually solved by encryption of the hard drive or at least one partition.

My issues with solution 1 were twofold:  I wasn’t always-on and even if I was: Access through my wireless plan was pretty slow especially for many small files. I ended up copying files on my hard disk for faster access but this defeated the purpose of the central storage completely since I sometimes forgot to copy the file back. Atfer some back and forth I came up with the following two tools:

1. Unison for file synchronization
2. TrueCrypt for encryption

Unison allows synchronization of a set of files in two directions. I basically have a central server at home where all the clients synchronize with. You can think of Unison as a VCS (Version Control System) without the versioning. It does not store old copies of the resources. The synchronization is done using the Rsync algorithm which basically works like that:

1. The two parties exchange a list of files. This list can include timestamps, filesizes or even hash sums.
2. If two files differ and the filesize is over a certain thereshold both parties chunk the file and submit a list of hash sums of the chunks using a rolling checksum (You can find the details on the Rsync website)
3. The  missing chunks are then transferred over the wire

This allows me to sync even changes in large files quite quickly. Thanks to SSH the transfer is secure and doesn’t need special VPN software.

TrueCrypt allows me to create an encrypted partition. This partition holds all my work data and this is the data I regularly sync with my central server.

This way I always have all the important stuff with me without compromising security or access speed. So if you ever consider setting up a VPN I would strongly suggest to give my solution a try instead. It’s much easier to maintain and doesn’t suffer from the always-on syndrome.

List of resource type IDs

I have not included other Open Source modules or the OAMP suite. I may update this list later.

A short background on categories

Categories are a built-in content relation in OpenCms and allow files in the VFS to be assigned one or more topics/keywords/whatever. They can often be used as a replacement feature for siblings which are mostly misunderstood by users without a technical background. For example consider the typical example of a news site. You have a folder structure for your articles which could be the following way:

/articles/2008/12-24-merry-christmas.html
/articles/2009/09-01-new-site.html
/articles/2009/10-02-a-great-article.html

You now want to categorize the articles into topics so you would create another folder structure:

/topic/must-read
/topic/technical

The sibling-way would be to create a sibling (put simply: an automatically updating copy) of the articles in the desired topic folder. While this is a working solution it’s counterintuitive to most users. OpenCms 7 introduced the long awaited Content Relation Engine (CRE) including a default relation called categories. Similar to the sibling solution a category is effectively a folder but instead of creating it anywhere in the filesystem it’s created in the root site (“/”) under /system/categories/. Users can now assign categories to VFS files using the context-menu entry Relations -> Assign Categories. This is a much easier approach although it has one caveat: Categories are globally defined in the /system/ folder and can therefore only be created by users with access to the root site and can not be specified on a per site or even per folder basis. This can cause problems in multisite environments.

Decentralization to the rescue

With OpenCms 7.5 this limitation is finally gone. You can now define categories on a per-site and even per-folder basis. Simply create a folder named _categories in the folder where you want the categories to be available. Then create new folders inside this folder to define categories. The categories are available in the parent folder of the _categories-folder and all subfolders. They also cascade down. Example:

/de/_categories/
/de/_categories/hot-topic
/de/_categories/support
/de/news/_categories/
/de/news/_categories/marketing
/de/news/_categories/development

Inside the /de/ folder the categories hot-topic and support are available. Inside /de/news/ the categories hot-topic, support, marketing and development are available.

This feature should easily help you to get your content structured more nicely. Speaking from experience it is crucial to create an evolveable content structure upfront so your editors as well as visitors and search engines get the most out of your site.

See also:

• Presentation from Michael Moossen about the CRE at OpenCms Days 2008
• A guide to good URI design

Updating the SME in general is pretty straighforward but if the customer made modifications to the yum configuration it can quickly turn into a nightmare. Luckily there is a tutorial available in the SME Wiki which can help you to get started. Unfortunately the yum installation was completly broken so I had to update the packages by hand. I pulled the packages from the SME repository at and installed them via

export SME_MIRROR_URL="http://mirror.jvsnet.ro/sme/releases/7/smeos/i386/SME/RPMS"

wget $SME_MIRROR_URL/dialog-1.0.20040731-3.i386.rpm
wget $SME_MIRROR_URL/python-sqlite-1.1.7-1.2.1.i386.rpm
wget $SME_MIRROR_URL/yum-metadata-parser-1.0-8.el4.centos.i386.rpm
wget $SME_MIRROR_URL/e-smith-formmagick-2.0.0-1.el4.sme.noarch.rpm
wget $SME_MIRROR_URL/smeserver-yum-2.0.0-4.el4.sme.noarch.rpm
wget $SME_MIRROR_URL/yum-plugin-fastestmirror-0.2.4-3.c4.noarch.rpm
wget $SME_MIRROR_URL/e-smith-lib-2.0.0-1.el4.sme.noarch.rpm
wget $SME_MIRROR_URL/sqlite-3.3.6-2.i386.rpm
wget $SME_MIRROR_URL/yum-plugin-installonlyn-0.91-1.el4.sme.noarch.rpm
wget $SME_MIRROR_URL/perl-CGI-FormMagick-0.92-16.el4.sme.noarch.rpm
wget $SME_MIRROR_URL/yum-2.4.3-4.el4.centos.noarch.rpm

rpm -Uvh --nodeps --force *.rpm

You maybe have to adjust this mirror url. This is why I factored it out into a seperate variable.

After this you should reset your yum repositories and clean the yum cache.

cd /home/e-smith/db/
mv yum_repositories yum_repositories.po
/etc/e-smith/events/actions/initialize-default-databases
signal-event yum-modify
yum clean all

After doing so, issue the following commands to let SME rewrite it’s config.

signal-event post-upgrade; signal-event reboot

Now you can update yum through yum itself (I know this sounds strange but this second update helps to get all the GPG keys for the repositories right).

yum update yum
signal-event post-upgrade; signal-event reboot

Now you can proceed with a normal update to get the whole system up to 7.4. I had to do this following process twice because the updates seem to have pulled in some new dependencies which in turn have to get updated.

yum update yum
signal-event post-upgrade; signal-event reboot

That’s it. I’m sure there might be an easier way but at least these are the steps the helped me get the system up to date. If you have questions just leave me a comment.

Example: I want to login the user “foo” of the OU “/germany/marketing“. Simple specify the String “/germany/marketing/foo” as a username and you’re all set.

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.

I’m also working on some projects so stay tuned.

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.