Setup a root server for Drupal hosting at Hetzner

After several years of web hosting at servage.net, I decided to move one step further and setup my own Drupal hosting solution on a Hetzner root server, using KVM virtualization and Aegir. This change has nothing to do with servage.net, their web hosting service is still perfect, cost and quality is OK. I just wanted to have something more to play.

I've taken the EX4 root server, the provisioning time was less then 24 hours, so I had an IP address and the full root access in one day. The network bandwidth from Hungary is also better then expected. The only issue I have is the 149€ setup cost. I've also ordered one additional public IP address. Their documentation in English is also acceptable, nevertheless some understanding in German definitively helps.

The first task to setup the server was to partition the disks and install the operation system via Hetzner's scripts. After some readings it was done in the second attempt. I have now a smaller root partition with RAID1, and few volume groups for the virtual machines and for the future. The server is running now on Ubuntu 11.10 64 bit, with the OpenSSH and Virtual Machine Host options.

Of course some configuration was necessary. I had to create a regular user with sudo rights, restrict the root access, check the firewall, ... Additionally, this regular user has to be added to the libvirtd group, in order to be able to manage KVM with that user, and logout/login afterward.

sudo adduser `id -un` libvirtd  

The complex part is the network setup for the KVM architecture in the particular Hetzner network infrastructure. We have two public IP addresses, and one public IP address (aaa.bbb.ccc.ddd) is used as a bridge for the virtual machines, while the second public IP (aaa.bbb.eee.fff) is routed through this bridge, and is assigned to one virtual machine. With this network setup the hosts has one public IP (aaa.bbb.ccc.ddd), as well as one virtual machine can be accessed from the Internet via the second public IP (aaa.bbb.eee.fff). Additionally, all the VMs will be NAT-ed, so can go out to the Internet, but are not accessible from the web. The most useful documentation for this was in a Hetzner wiki.

On the host I'm using this network setup in /etc/network/interfaces:

  • one public IP aaa.bbb.ccc.ddd
  • the gateway for the first IP is aaa.bbb.ccc.xxx
  • second public IP aaa.bbb.eee.fff
### Hetzner Online AG - installimage  
# Loopback device:  
auto lo  
iface lo inet loopback  

# device: eth0  
auto  eth0  
iface eth0 inet manual  

# bridge: br0  
auto  br0  
iface br0 inet static  
  address        aaa.bbb.ccc.ddd  
  netmask        255.255.255.255  
  gateway        aaa.bbb.ccc.xxx  
  pointopoint    aaa.bbb.ccc.xxx  
  bridge_ports   eth0  
  bridge_stp     off  
  bridge_fd      0  
  bridge_maxwait 0  
  # additional public IPs for VMs:  
  up route add -host aaa.bbb.eee.fff dev br0

Then two important change for the kernel in the /etc/sysctl.d/10-kvm-routed-setup.conf file:

# Do not send ICMP redirect messages to the VMs by the host
net.ipv4.conf.all.send_redirects=0  
#
# IP-Forwarding should be activated
net.ipv4.ip_forward=1  

And do not forget to check the firewall, it should accept forward packets:

sudo iptables -P FORWARD ACCEPT  

On the virtual machine, which will have the second public IP, change /etc/netwrok/interfaces as follows:

auto lo  
iface lo inet loopback

# The primary network interface, attached to vmbr1, NAT-ed  
auto eth0  
iface eth0 inet static  
  address 10.10.10.3
  network 10.10.10.0  
  netmask 255.255.255.0  
  broadcast 10.10.10.255  
  gateway 10.10.10.1

# Network interface for public IP, routed over host NIC  
auto eth1  
iface eth1 inet static  
  address aaa.bbb.eee.fff  
  netmask 255.255.255.255  
  pointopoint aaa.bbb.ccc.ddd  
  gateway aaa.bbb.ccc.ddd

The first network interface is attached to the default virtual network of the KVM, NAT-ed towards the Internet. The second netwrok interface has the second public IP, and uses the first public IP, as its gateway.

This VM with the second public IP can then be used as a load balancer or reverse proxy in front of several other VMs, without public IP.