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.

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 first featured tool is the shoreline firewall or shorewall. You can find the project at: http://www.shorewall.net/

Shorewall basically is a set of nice configuration files for iptables. Another benefit of shorewall is that it has no runtime part. You just fire up the tool, it configures your iptables and quits. This reduces the load and increases security. Additionally to the technical features there is one thing that makes shorewall really stand out: It has extensive, well-written and understandable documentation. You rarely find a use-case which is not already described in the documentation.

Read on to find out how to set up shorewall in minutes.

Setting up shorewall

In this section I will describe how to secure a single server directly connected to the internet. There is no hardware firewall or DMZ involved.

First you have to install shorewall on your server. Since I use Ubuntu 8.04 there is already a prepackaged version in the repository.

aptitude install shorewall

Then you have to copy some of the example configuration files to your /etc/shorewall directory.

cp -prv /usr/share/doc/shorewall-common/default-config/rules /etc/shorewall
cp -prv /usr/share/doc/shorewall-common/default-config/zones /etc/shorewall
cp -prv /usr/share/doc/shorewall-common/default-config/modules /etc/shorewall
cp -prv /usr/share/doc/shorewall-common/default-config/interfaces /etc/shorewall
cp -prv /usr/share/doc/shorewall-common/default-config/policy /etc/shorewall

To understand the meaning I will first give a very short explanation of the shorewall terminology (the terms are pretty standard): Shorewall sees the network as a collection of zones (your local network, the internet, the firewall host itself, …). Network interfaces (eth0, eth1, …) are connected to the zones and allow traffic to move in and out. If traffic want’s to move between zones the firewall checks the configured rules wether there is a rule allowing or denying the traffic flow. If there is no rule for the specific case it applies a policy (default rule).

With this in mind the filenames should be straightforward to understand. The modules file loads shorewall specific modules (for example enables the ftp connection tracking). You don’t have to modify the modules file for a basic setup.

Lets first define the zones in the zones file.

###############################################################################
#ZONE   TYPE            OPTIONS         IN                      OUT
#                                       OPTIONS                 OPTIONS
fw      firewall
net     ipv4
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE

As you can see there are only two zones defined: The internet (net) and the server itself (fw).

We now connect the network interfaces to the zones using the interfaces file.

###############################################################################
#ZONE   INTERFACE       BROADCAST       OPTIONS
net     eth0            detect          norfc1918
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

That’s it. If you have more interfaces you of course have to connect these to the zones too. But if this is the case it’s very likely that you are striving for a more complex configuration anyway.

After defining the traffic sources we will now implement the default policy using the policy file.

###############################################################################
#SOURCE         DEST            POLICY          LOG             LIMIT:BURST
#                                               LEVEL
fw              net             ACCEPT
net             fw              DROP
all             all             DROP
#LAST LINE -- DO NOT REMOVE

This policy allows the firewall to access all internet services and drops all incoming connections silently. Since this is not very useful for a server we now allow public access to some specific services by defining some rules in the rules file.

#############################################################################
#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE
#                                                       PORT    PORT(S)
#SECTION ESTABLISHED
#SECTION RELATED
SECTION NEW
ACCEPT          net             fw              icmp    echo-request
ACCEPT          net             fw              tcp     22
ACCEPT          net             fw              tcp     80
ACCEPT          net             fw              tcp     443
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

As cou can see we allowed our server to reply to pings, incoming SSH connections and to serve up websites through HTTP and HTTPS.

In Ubuntu you now have to set the startup variable in /etc/default/shorewall to 1 and run /etc/init.d/shorewall start. Be sure to check that everything works as expected before you close your SSH session!.

That’s it. Visit the shorewall website for more information.

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