XEN 3.4 with ipv6 routing

Yes, there are a few postings out there about getting ipv6 routing running with XEN. But I’ll throw this online anyway since there are a few changes I had to make for it to work on my server. This text is intended for people who know their way around Linux and XEN so it will be a bit technical and won’t spell out every single step you have to make.

Most of the changes are based off scripts and information from BenV and wnagele (latter is interesting for me since I am also running XEN on a hetzner server). Have a look at the two links if anything is unclear. Now let’s start the fun 🙂

First of all we need IPv6 up and running on the host (dom0). Add the IP and gateway to your /etc/network/interfaces
This is what mine looks like:
iface eth0 inet6 static
address 2a01:4f8:100:1123::2
netmask 64
gateway 2a01:4f8:100:1120::1
pre-up ip -6 route add 2a01:4f8:100:1120::1 dev eth0

Check if the IP address is responding to the outside world (e.g. with wiberg.nu/iptools.php), if everything looks ok, proceed …
Now we need to enable a few things to get routing and neighbor discovery running on the host (dom0). Edit your /etc/sysctl.conf and add/change these 2 entries (and while you are at it, set them with “sysctl -w” too):
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.proxy_ndp=1

So, your host should by now be online with ipv6 and soon be able to route packets to it’s guests. By default XEN will only take care of IPv4 when a guest is created, so here is a small patchfile that adds support for IPv6: xen-ipv6-vif-route.patch. The patch changes vif-route and vif-common.sh, while these files may be in different places depending on your distribution, /etc/xen/scripts/ is where they can commonly be found. Download the patch to the directory with the scripts to be changed and execute a “patch -p0 < xen-ipv6-vif-route.patch” (vif-common.sh gets a few new IPv6 functions, and iptables now won’t try to change stuff for IPv6 IPs. vif-route changes are: ndp is enabled for the vif device and the route/neighbor IPv6 settings are set)

So, now that the scripts know how to setup all our IPv6 needs, we need to add the IPv6 IP to our guest settings (.cfg file typically found in /etc/xen/). What we want to change is the “vif” setting. Add the IPv6 IP of the guest to the IPv4 IP (just the IP without the trailing /network, space separated form the IPv4 IP):
vif = [ 'mac=B1:A3:3F:25:11:B8, ip=2a01:4f8:100:1123::5 188.40.34.101' ]

Now you can create the guest(domU) and add the IPv6 IP to the /etc/network/interfaces of the guest if you haven’t so already (it uses the host (dom0) as the gateway).

iface eth0 inet6 static
address 2a01:4f8:100:1123::5
netmask 64
gateway 2a01:4f8:100:1123::2

Restart the networking on the guest (or reboot it) and you should now be able to ping the guest from the internet. See, easy wasn’t it 🙂

Script of the day – clean up stale .ssh/known_hosts

This little script takes an IP or hostname as a parameter, and if there is an offending key in the .ssh/known_hosts it removes it and replaces it with the current valid one useful if you are moving/reinstalling a large amount of servers …

Checking a list of IPs against RBL

This is more a reminder to myself than anything else … this is small snippet that takes a list of IPs and does a whois on all that aren’t in a RBL

Lets say we have al list of IPs in a file “iplist.txt”:
12.172.121.171
24.149.208.68
38.105.100.9
58.185.207.86
61.201.51.66
64.78.164.169

Snippet that checks the IPs (can of course be easily changed to check IPs that are IN a RBL)

bash: using the content of a variable as variable name

Since the implementation of Arrays in Bash is somewhat lacking compared to higher level programming languages (only one-dimensional), and hash lists require a bit of work to set up, you may run into a situation where you have a small list of key/value pairs that are both variable and you need to store.
There are various solutions for the problem, e.g. creating two arrays (one for the keys, one for the values, and combining them by using the same index values for the entries), or using the functions from the link above to build a hash list. For me the easiest way to solve the problem, if I only have a few variables and don’t want to bloat the code, is to (mis)use declare. declare is intended for setting the type of a variable (constant, array, integer,…), but has the nice side affect that you can use variables in the key name, and you can set the value of the variable.

usage:
declare ${Key}=${Value}

Example:
$File_Config is variable holding the name of a configfile, the content of the file could look like this:
foo:one
bar:three
foobar:bignumber

Snippet:

after the snippet has read the configfile, you can use $Configuration_foo, $Configuration_bar and $Configuration_foobar in your script. The keynames could also have came from a mysql query, array, command line args, …

Mythtv and IR Blaster

We use a set-top-box as the video source for mythtv. And while this works perfectly fine, we have to manually make sure the right channel is set for what mythtv wants to record. This can turn out to being a pain at time, especially when multiple things are planned to be recorded on different channels. So I went and ordered a IR transmitter from irblaster.info to give mythtv the possibility to change channels itself.

Since a bunch of the infos I found online were a bit out dated, here are a few tips for anyone using current versions of the software (I’ve got mythtv-backend 0.22 and lirc 0.8.4a running on a mythbuntu based system when I wrote this)

Hardware is easy to set up, just plug it into a free serial port.
1st we will head over to http://lirc.sourceforge.net/remotes/ and grab the file for our reciever set-top-box if we don’t already have them.
Then go edit /etc/lirc/hardware.conf and add the transmitter settings, these were mine:
TRANSMITTER="Skymaster_XL10"
TRANSMITTER_MODULES="lirc_dev lirc_serial"
TRANSMITTER_DRIVER=""
TRANSMITTER_DEVICE="/dev/lirc1"
TRANSMITTER_LIRCD_CONF="skymaster/XL10"
TRANSMITTER_LIRCD_ARGS=""

now include the reciever settings to /etc/lirc/lircd.conf
I edited my /etc/init.d/lirc to execute the following line before starting the daemon (was needed to ensure the lirc_serial module can be loaded):
/bin/setserial /dev/ttyS0 uart none
Restart lircd and you can then start testing if transmitting codes work with irsend works. here is a little wrapper script I wrote around irsend for mythtv to use. You may have to twiddle around with the sleeps and change the $Remote to your reciever. If the sleeps are too long (-> the script takes to long to finish switching channels), then mythtv will timeout and not display live tv.

If everything is working fine, then go ahead and tell mythtv to use the script to change channels. This is done in the tuner card setup of mythtv-backend (mythtv-setup).