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.

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.