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.

Since 1und1 puts every server behind a dedicated firewall the setup is not as easy as you think. I’ll document it here because It may be useful for other people and certainly for myself after a couple of months.

Configure a static IP address

Open the file /etc/sysconfig/network-scripts/ifcfg-eth0 and edit it to look like the following:

DEVICE=eth0
BOOTPROTO=none
TYPE=Ethernet
ONBOOT=yes
HWADDR=$YOURMACADDRESS
NETMASK=255.255.255.255
IPADDR=$YOURIP
GATEWAY=10.255.255.1

Save the file.

Configure static routes

This is the tricky part. Configuring a default gateway using the GATEWAY= setting is not enough. You have to setup the routes yourself. To do so create a new file /etc/sysconfig/network-scripts/route-eth0 with the following contents:

10.255.255.1 dev eth0
default via 10.255.255.1 dev eth0

Now you only have to reload the networking configuration via

service network reload

and you are done!

This post helped me a lot with the solution.

I must admit that I always had some kind of a love-hate relationship with Tomcat. The classloader had some bad issues when reloading a webapplication too often and often killed the complete server. Taking down all of the other webapplications too. Although this has gotten a lot better recently it’s still bothering me a bit.

Since I had some time after my last project I started investigating other open source alternatives. I often heard of Jetty, praised for it’s speed and simplicity, it seemed like a great alternative and I played around with it a bit. I really liked it since it was simple to use and easy to deploy but as I started to google for things like performance measurements or how to use it with a security manager I didn’t really found a lot of documentation (compared to Tomcat) and the performance doesn’t really doesn’t seem to differ from Tomcats.

So I’m once again going the Tomcat route. It has a big community and is even used in military and government organizations. It’s really not a technology decision (although I think Tomcat is solid) but more political thinking.

It will also save me some time which I can invest in trying out other technologies. Meow…

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