I have recently moved my hosting to a couple of VPSes at ChicagoVPS and wanted to use IPv6 (via tunnelbroker.net)

ChicagoVPS uses OpenVZ which presents a couple of problems

$ ifconfig sit0
sit0: error fetching interface information: Device not found
$ sudo modprobe ipv6
FATAL: Module ipv6 not found.

It turns out, this is a fairly common problem though OpenVZ is supposed to support IPv6. Luckily, someone made a small userland program (tb-tun, which “tunnels” IPv6 tunnels through a TUN/TAP device.

First, it requires tun/tap device support to be enabled in the VPS, this is done in the control panel under settings

Control panel

Note! – Changing this setting will reboot your VPS without warning!

Next, make sure the build-essential package is installed (it’s included in the Ubuntu template at ChicagoVPS)

$ sudo apt-get install build-essential

Now, download and install the tb-tun program

$ mkdir tb-tun
$ cd tb-tun
$ wget https://tb-tun.googlecode.com/files/tb-tun_r18.tar.gz
$ tar zxvf tb-tun_r18.tar.gz
$ gcc tb_userspace.c -l pthread -o tb_userspace
$ sudo mv tb_userspace /usr/local/sbin

Before, continuing I recommend looking up the following information:

Server IPv4 Address - This is the IPv4 address of the Tunnelbroker gateway
Client IPv4 Address - This is the IPv4 address of your server
Client IPv6 Address - This is the IPv6 address of your server (for the tunnel end-point)
Routed /64 - This is your network

Next, you need to ensure your iptables configuration allows incoming encapsulated IPv6 traffic (protocol 41). Since ufw is a PITA to get to work on OpenVZ, I’m using iptables-persistant, which simply means adding one line to /etc/iptables-persistent/rules.v4

# IPv6 tunnel
-A INPUT -p 41 -s <Server IPv4 Address> -j ACCEPT

You also need to secure your server on IPv6, /etc/iptables-persistent/rules.v6

-A INPUT -i lo -j ACCEPT
# Allow ping
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

Apply the new rules

$ sudo service iptables-persistent reload

Finally, you are ready to set up your tunnel in /etc/network/interfaces

auto tb
iface tb inet6 manual
        pre-up  setsid /usr/local/sbin/tb_userspace tb <Server IPv4 address> <Client IPv4 address> sit > /dev/null &
        up      ifconfig tb up
        post-up ifconfig tb inet6 add <Client IPv6 address>/64
        post-up ifconfig tb inet6 add <Routed /64>:1/64
        post-up ifconfig tb mtu 1480
        post-up route -A inet6 add ::/0 dev tb
        post-up netstat -rn6 | grep -q venet0 && route -A inet6 del ::/0 dev venet0
        down    ifconfig tb down
        post-down       route -A inet6 del ::/0 dev tb
        post-down       killall tb_userspace

In my setup it looks like this:

auto tb
iface tb inet6 manual
        pre-up  setsid /usr/local/sbin/tb_userspace tb sit > /dev/null &
        up      ifconfig tb up
        post-up ifconfig tb inet6 add 2001:470:1f10:74b::2/64
        post-up ifconfig tb inet6 add 2001:470:1f11:74b::1:1/64
        post-up ifconfig tb mtu 1480
        post-up route -A inet6 add ::/0 dev tb
        post-up netstat -rn6 | grep -q venet0 && route -A inet6 del ::/0 dev venet0
        down    ifconfig tb down
        post-down       route -A inet6 del ::/0 dev tb
        post-down       killall tb_userspace

Now, I just have one question


(Actually I know, and understand, why. It’s still annoying though)

iptables is not always easy to deal with so I prefer to use Uncomplicated firewall (ufw) in Ubuntu, because it simplifies configuring and maintaining my firewall rules.

Unfortunately, ufw does not play nice with OpenVZ containers so I decided to find something else. In the end (after testing various things) I decided to install the package iptables-persistent which is not as sexy as ufw but gets the job done.

iptables-persistent uses two configuration files


both files can be generated during installation.

The a simple version of /etc/iptables-persistent/rules.v4 may look like this

#  Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -i ! lo -d -j DROP

# Allow all traffic from tun-devices (VPN)
-A INPUT -i tun+ -j ACCEPT

#  Accepts all established inbound connections

#  Allows all outbound traffic
#  You could modify this to only allow certain traffic
#  This is in addition to allowing established and related traffic as listed above

# Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

#  Allows SSH connections from trusted-host only - drop the rest
-A INPUT -p tcp --dport 22 -s -j ACCEPT

# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Drop all other inbound - default deny unless explicitly allowed policy (change to REJECT of you which to reject packets instead of dropping them)


After making changes to your rules files, apply them by running

$ sudo service iptables-persistent reload

If you have a computer on your local network you want to wake from the Internet and you have a TP-Link router (in this case a TL-WDR4300) you are in luck

First, create a “virtual server” (or port forwarding) in which we forward an arbitrary port to port 9 at the IP address of the machine you wish to turn on (Go to Forwarding → Add New):

Add virtual server

If you test as this point, it will work. But at a later point it will not. This is because the MAC address of the machine you wish wake will be flushed from the router’s ARP table.

The way to fix this is a bit illogical but it works. With the machine in questioned turned on, go to IP & MAC binding → ARP List, find the entry you need and click “Load”

Add ARP bind

Now, go to IP & MAC binding → Binding settings and tick of “Bind” for the entry of your machine (also make sure ARP binding is enabled) and then press save.

Create binding

You should now be able to wake your machine from anywhere in the world, using an online service or a client on your smartphone.

Wake on LAN from phone

I am aware of the potential problems of allowing this kind of traffic into my local network but since a malicious person would need to know both the external port and MAC address of the internal machine and is only able to start up my machine, I’m not too worried. If you worry, add a password to your wake on lan configuration.

First post in a long time – Don’t worry, I haven’t been abducted by aliens from Omicron Persei 8

So today, Felicia Day launched her new personal show called the The Flog. Since I enjoyed this first episode immensely I decided it was time to extend my use of Youtube and subscribe to the channel (user?) Geek & Sundry.

To the *sshats at Google: Why, oh why, do you punish me for using Google Apps?

What’s the problem, you ask? Well, the problem wasn’t like it used to be (where I simply couldn’t log on to Youtube, unlike other services it didn’t give me the opportunity to switch to my non-apps Google account. So I had to log out from Apps account. Log in to my Google account, do whatever on Youtube and the log back into my Apps account – After logging of the Google Account, otherwise Google services would choose that as default).

One does not simply log in to Youtube

No, I was presented with a message telling, Youtube access hadn’t been enabled by my administrator. Easy peasy. I would just go to the domain control panel in Google Apps and enable. Right?


After remembering where the services are (that’s “Organization & Users” -> “Services” for future reference) I couldn’t find any Youtube. Turns out, I’m in the wrong country.

This is the fix:

  • On the Dashboard, select “Try Google Apps for Business Free”
  • On the next page, select “Country/Region: United States” and click “Begin Free Trial”
  • Now, a checkout window appear. Simply close it
  • Go to “Organization & Users” -> “Services” in your Apps control panel
  • Enable Youtube services
  • Wait five minutes
  • Log on to Youtube using your Google Apps account

In the end, it all worked out. And who can stay mad after watching @feliciaday in “The Flog”; @wilw and @grantimihara battle for (Small) World domination in “Table Top” – And last but least, a new video from @TheGuild called “I’m The One That’s Cool”. Oh, and this tweet.

May you survive a new year

It’s A New Year, Baby!

Live long and prosper!

As always with a new Ubuntu release comes the problem of getting Cisco’s VPN client to install (and no, using vpnc instead is not really an option since the VPN concentrator doesn’t play nice and drops the connection from time to time)

The problem this time is the kernel version of Ubuntu 11.10 – The new 3.0 series kernel.

I’ve made a patch which will make the kernel module compile and install on the 3.0 kernel.

If you have the vanilla Linux client, you still need the patches hereIf the installation/compile fails, make sure you have installed all relevant patches as will as the packages needed to install (ia32-libs build-essential linux-headers-`uname -r`).

At some point Veritas has release the Cluster Manager (Java Console) for Linux. Of course, Linux means Red Hat (and other RPM based flavours). Luckily it isn’t too hard making it work on Ubuntu (and friends).

First, get the software – This requires a SymAccount. And no, I will not send you the software

Now, prepare your Ubuntu box

$ sudo apt-get install alien fakeroot

And finally convert and install the package

$ fakeroot alien -c VCS_Cluster_Manager_Java_Console_5.1_for_Linux.rpm
$ sudo dpkg -i vrtscscm_5.1.00.20-1_all.deb

Now, from a terminal or otherwise (ALT-F2 in various Ubuntus) run

$ /opt/VRTSvcs/bin/hagui

Or create a desktop entry for the Cluster Manager to put it in the menu

Create the file ~/.local/share/applications/hagui.desktop

[Desktop Entry]
Name=Veritas Cluster Manager
GenericName=Veritas Cluster Manager
Comment=Manage Veritas clusters

Copy ClusterManager.png to ~/.icons

The fix itself is the same as for Python 2.5 – only the line numbers have changed.

Open the file /usr/lib/python2.7/locale.py and find the line containing en_gb (line 921) and add these lines (this works for Danish locales):

    'en_dk':                                'en_DK.ISO8859-1',
    'en_dk.iso88591':                       'en_DK.ISO8859-1',
    '[email protected]':                           'en_DK.ISO8859-15',

In order to avoid this change getting overwritten by packages updates, I use dpkg-divert:

$ sudo dpkg-divert --add --rename --divert /usr/lib/python2.7/locale.py.real /usr/lib/python2.7/locale.py
$ sudo cp /usr/lib/python2.7/locale.py.real /usr/lib/python2.7/locale.py

If you wish to remove the diversion (if the package is fixed to support you locale at some point) simply run

$ sudo dpkg-divert --rename --remove /usr/lib/python2.7/locale.py

When I switched from Apache2 to nginx, the software used to run my pastebin needed to be changed (I used Perl NoPaste, which is CGI based and I didn’t feel like messing with FastCGI wrappers). Instead I chose LodgeIt.

LodgeIt is not just another pastebin, it features a clean user interface, different color schemes for sourcecode, reply to pastes, support for all languages Pygments supports, and XMLRPC support

LodgeIt spawns it’s own webserver, which I placed behind nginx.

  1. Install required packages
    sudo apt-get install python-imaging python-sqlalchemy python-jinja2 python-pybabel python-werkzeug python-simplejson mercurial python-pygments
  2. Go to the directory where you want LodgeIt to live and check out the Mercurial repository
    hg clone http://dev.pocoo.org/hg/lodgeit-main
  3. cd into lodgeit-main, open manage.py and change the lines
  4. Download the init script and place it in /etc/init.d and change the lines
  5. Configure autostart
    sudo update-rc.d lodgeit defaults
  6. Start the program
    sudo service lodgeit start

The init-script is also available for viewing

The nginx configuration is pretty easy – the only caveat is the fact that nginx does not support IPv6 for upstream servers, which is why lodgeit is configured to explicitly to listen on (and not localhost which on a IPv6-enabled host is ::1).

server {
                listen [::]:80;
                server_name my.server;

                access_log /var/log/nginx/my.server-access.log;
                error_log /var/log/nginx/my.server-error.log;

                location / {
                                proxy_pass http://localhost:20000/;

Nowhere.dk has been moved to nginx (with php5-fpm) and most things seem to be working.

There is one problem though.

It seem that some of the older articles are indexed as /articles/-title-/index.php (which is sort of wrong) and accessing that type of URI results in a blank page.

The problem seem to be that I’ve configured nginx to serve file in this order:

location / {
                        try_files $uri $uri/ @rewrites;

In theory it should then be a matter of defining the right rewrite

location @rewrites {
       rewrite ^/articles/(.*)/index.php$ /articles/$1 permanent;
       rewrite ^ /index.php last;

but – There’s also a location definition for all php “files” (locations ending in .php, not files mind you) and I believe that the .php locations are handed over to php5-fpm withouth nginx actually testing to see if it’s there.

Perhaps I can solve this – but it is a minor problem.