Rainer's Blog

Finally, I got OpenVPN to work on my server. A particularly cool feature  is the possibility of sharing a port with Apache – this should make it harder for censors to filter OpenVPN packages.

“Sharing” is, however, a bit misleading, since no two applications can listen to the same port at the same time. For instance, to share Port 443, one has to make Apache listen on a different port. I made Apache listen on Port 8443, so I edited the ports.conf file to say:

Listen 80
Listen 8443

Now that Port 443 is not taken anymore by another application, we can make OpenVPN listen there. Any non-OpenVPN traffic that goes to this port has to be forwarded to Apache by OpenVPN. After all, we want to still talk to Apache by using Port 443, as one usually would.

This can be accomplished by putting these lines into openvpn.conf:

proto tcp
port 443
port-share 127.0.0.1 8443

Explanation: this cool feature only works with TCP, hence the “proto tcp” line. Only OpenVPN listens on Port 443. However, any non-OpenVPN packets will be forwarded by OpenVPN to Apache, which runs on the same server and listens on Port 8443. So, from the outside world, it looks as if Apache and OpenVPN were both listening to Port 443, and whoever you intend to talk to will answer.

IPv4 addresses are going to run out soon, so I decided to add IPv6 to my Debian (Lenny) servers running OpenVZ instances. The server and containers are now still reachable under their old IP4 addresses, but in addition also under IPv6. I am using the “venet” setup, not “bridged”.

Just a few steps are necessary:

1. add this to /etc/sysctl.conf:

   net.ipv6.conf.default.forwarding = 1

   net.ipv6.conf.all.forwarding = 1

   net.ipv6.conf.default.proxy_ndp = 1

   net.ipv6.conf.all.proxy_ndp = 1

2. add this to /etc/network/interfaces (in addition to whatever it says with regard to “iface eth0 inet static”); note that I am using two different prefixes, one for the gateway (2a01:xxx0) and one for the main server (2a01:xxx1). You’ll have to replace those prefixes such that they match your own gateway and server addresses.
   

   iface eth0 inet6 static

    # Haupt-IPv6-Adresse des Servers

    address 2a01:xxx1::2

    netmask 64

    # Default Route

    gateway 2a01:xxx0::1

   pre-up modprobe ipv6

   pre-up echo 0 > /proc/sys/net/ipv6/conf/eth0/autoconf

   pre-up echo 0 > /proc/sys/net/ipv6/conf/eth0/accept_ra

   pre-up echo 0 > /proc/sys/net/ipv6/conf/eth0/accept_ra_defrtr

   pre-up echo 0 > /proc/sys/net/ipv6/conf/eth0/accept_ra_pinfo

   pre-up echo 0 > /proc/sys/net/ipv6/conf/eth0/accept_ra_rtr_pref

    # Host-Route, da das Gateway ausserhalb des eigenen /64 Blocks liegt

    pre-up ip -6 route add 2a01:xxx0::1 dev eth0

   post-up /sbin/sysctl -p
   # one address for each container:
   

   post-up ip -6 neigh add proxy 2a01:xxx1::89 dev eth0

   post-up ip -6 neigh add proxy 2a01:xxx1::90 dev eth0

   post-up ip -6 neigh add proxy 2a01:xxx1::91 dev eth0

   post-up ip -6 neigh add proxy 2a01:xxx1::92 dev eth0

   post-up ip -6 neigh add proxy 2a01:xxx1::93 dev eth0

3. in /etc/vz/vz.conf, set

   IPV6="yes"

4. Reboot. Now you should be able to “ping6 ipv6.google.com” from the main server and containers.
5. If you don’t want mail originating from servers with IPv6 addresses to be rejected, add a reverse DNS entry for every server which is newly equipped with an IPv6 address, as well as a corresponding AAAA DNS record. Make sure this name is not already used for an IPv4 address.

Ubuntu by default comes with a neutered, useless version of the mail notifier. Luckily, Glyphobet posted the following script.

I found that the script would not run on my Ubuntu machine, so I went through it step by step manually (by entering line by line). This taught me that this script will only work if you have previously installed the package devscripts.

#!/bin/bash
# This script rebuilds the mail-notification package with
# –disable-ssl REMOVED so that mail-notification is ACTUALLY USEFUL.
if ls mail-notification* > /dev/null ; then
echo “This script will execute \`rm mail-notification*\` when it completes,”
echo “but there are mail-notification files in this directory already.”
echo “Please remove stale mail-notification package files and re-run this script.”
exit
fi
# Remember uninstalled build dependencies
BUILDDEPS=`apt-get build-dep mail-notification -s | grep “^ “`
# Get build dependencies
sudo apt-get -y build-dep mail-notification
# Get packages required to compile with SSL support
sudo aptitude install libssl-dev fakeroot
# Get package source
apt-get source mail-notification
# Get into the directory
cd mail-notification*/
# Remove STUPIDNESS
perl -i.bak -pe “s/ssl=no//” debian/rules
# Update the version so that the package manager doesn’t get its knickers in a twist
DEBEMAIL=”foo@bar.com” dch -i “removing line noise which prevented SSL support from being enabled.”
# Build package
dpkg-buildpackage -uc -us -rfakeroot
# Remove previously uninstalled build dependencies
sudo aptitude remove $BUILDDEPS
# Checking…
if ! ldd src/mail-notification | grep libssl ; then
echo “******** SOMETHING WENT WRONG! libssl support NOT ENABLED ********”
exit
fi
# Get out!
cd ..
# Install the living daylights out of the package
sudo dpkg -i mail-notification*.deb
# Clean up package rebuilding debris
rm -fr mail-notification*

Google announced that in their ranking algorithm, one of about 200 criteria will be the time it takes to load a page. So I tweaked my websites a bit, following Google’s and YSlow’s suggestions to gzip text files, combine CSS and JS files etc.

These two websites are especially useful for measuring website performance:

• Uptrends – nice, simple visualization for loading times as seen from different geographical locations.
• Webpagetest – shows times for first and for subsequent page loading actions. More details.

Two changes stood out because their effects were most noticeable in my case: using a Content Delivery Network (CDN) and paying more attention to the time it takes to resolve addresses (DNS).

Using Google’s Appspot as a CDN

For a long time, I thought that content delivery networks such as Akamai are only interesting for big corporations with correspondingly big spending power. But it turns out that Google’s application engine can be used as a reasonably powerful CDN that is either free (if the bandwidth is below 1 GB/day) or at least not too expensive (each GB above 1 GB costs just 12 cents). No programming whatsoever is required for using AppSpot as a CDN.

Documentation can be found here: http://code.google.com/appengine/docs/whatisgoogleappengine.html

Using an external DNS provider

So far I ran my own name servers. I liked having control over this, and I figured, since I already pay for servers anyways, why not also use them for DNS. The drawbacks of my approach were:

• DNS servers were in the same computer centers as the servers. Thus, if the whole computer center experiences a downtime, it is impossible to reroute the traffic elsewhere if the DNS servers are subject to the same problems.
• DNS requests do add load to the servers!
• From my own country, the speed was okay, but DNS resolution turned out to be a bit slow from other continents.

To address these issues, I tried two external providers: Zerigo and DNSmadeeasy. Both of them turned out to reduce the time it takes my visitors to resolve names, that is, both made my websites faster. This effect was stronger for countries that are further away from my servers. Individual strengths and weaknesses:

Zerigo

What I like about Zerigo: DNS servers not only in the US but also in London and Vienna. Nice user interface. Easy-to-use slave mode: I keep using my own DNS servers for the purpose of defining and managing zones. But I enter only Zerigo servers in the NS records and at the domain registrar. Therefore, all requests from the public can go to Zerigo’s fast and geographically dispersed servers, while the way I manage my domains on my own DNS servers does not need to change at all.

What I dislike about Zerigo: DNS requests are relatively expensive (1 million per month is included in their “small” account for $1.58 per month, but each additional million costs $3).

DNSmadeeasy

What I like about DNSmadeeasy: a “slave” setup similar to Zerigo is also possible. Instead of 1 million per month, 5 million requests per month are included (with the account that costs $29.95 per year, thus the price per million is only $0.50 as opposed to Zerigo’s $1.58).

What I dislike about DNSmadeeasy: The user interface is clunky and ugly, which makes managing, importing and exporting DNS records harder than at Zerigo. This is mainly an esthetic problem, though – the necessary functionality is still there.