Nick Andrew News

You can obtain IPv6 connectivity in Australia using the AARNet IPv6 Migration Broker if your ISP does not already provide IPv6. As at August 2008, only Internode is known to provide consumer level IPv6 access.

For Australian users who cannot obtain IPv6 through your ISP, the AARNet IPv6 tunnel is probably the next lowest latency choice. These instructions describe setting up IPv6 with linux over a consumer DSL connection with a dynamic IPv4 address (i.e. every time you connect you get a different IP address) and NAT (Network Address Translation) on the DSL modem.

With IPv6 you can get a static address (well, 2^64 or more static addresses) and it's quite useful if you run a home network and want to provide access to devices within the network, from outside. That is, so long as the outside client has IPv6 (the chicken-and-egg problem).

Certain assumptions are made in this document - like installed software or an IPv6 enabled kernel. If these instructions don't work for you, drop me an email at nick at nick-andrew.net.

Preparation - Kernel and Software

Make sure your kernel has IPv6 support. Do "ifconfig eth0" and check for a line like this in the output:

          inet6 addr: fe80::212:34ff:fe56:789a/64 Scope:Link

You may need to load the "ipv6" module.

Check that you have the commands "ip6tables" and "ip".

Preparation - Firewall

It's good for security to setup the IPv6 firewall before you even start configuring it. Although you may have an IPv4 firewall already in place, that won't stop any IPv6 packets. I'll assume you want to make connections out, but block all connections in, which is the standard functionality you get with NAT, and useful for a client. For a server you will need to allow connections in for the server ports.

ip6tables setup

I use a shell script with a function alias, to set the firewall.

#!/bin/bash
#    Simple IPv6 firewall rules

doCmd6() {
        /sbin/ip6tables $*
        rc=$?
        if [ $rc != 0 ] ; then
                echo Error $rc doing ip6tables $*
        fi
}

doCmd6 -P INPUT DROP
doCmd6 -P FORWARD DROP

doCmd6 -F
doCmd6 -X

doCmd6 -N 6_log_drop
doCmd6 -N 6_icmp
doCmd6 -N 6_tcp

doCmd6 -A 6_log_drop -j LOG --log-prefix "ipv6:"
doCmd6 -A 6_log_drop -j DROP

#enable ssh in   doCmd6 -A 6_tcp -p tcp -d ::/0 --dport 22 -j ACCEPT
doCmd6 -A 6_tcp -j 6_log_drop

doCmd6 -F 6_icmp
doCmd6 -A 6_icmp -j ACCEPT


doCmd6 -A INPUT -i lo -j ACCEPT
doCmd6 -A INPUT -p ALL -m state --state ESTABLISHED,RELATED -j ACCEPT
doCmd6 -A INPUT -p icmpv6 -j 6_icmp
doCmd6 -A INPUT -p tcp -j 6_tcp
doCmd6 -A INPUT -j 6_log_drop

This set of rules will allow you to make outbound IPv6 connections and will block inbound except for ICMP (your address can be pinged) and you can uncomment a line to enable ssh connections in.

Preparation - DSL modem

Assuming your DSL modem has a firewall, you will need to enable two things:

• Outbound UDP connections to port 3653
• Protocol 41 inbound/outbound

UDP port 3653 is used by the AARNet tunnel broker. Protocol 41 is used by 6to4 tunneling, which I will describe now.

Alternate access - 6to4 tunnel

Although this document is about obtaining IPv6 through AARNet's migration broker, there's a quicker way to get started on IPv6 using your dynamic IPv4 address. You will need the "curl" command installed. Run this script:

#!/bin/bash
#  Sets up an ipv6 tunnel through the nearest public gateway.
#  Automatically learns current ipv4 address.

ipv4=$(curl -s http://www.whatismyip.com/automation/n09230945.asp)
ipv6=$(printf "2002:%02x%02x:%02x%02x::1" $(echo $ipv4 | tr "." " " ) )

echo ipv4 is $ipv4 and ipv6 is $ipv6

ifconfig sit0 up
ifconfig sit0 add $ipv6/16
route -A inet6 add 2000::/3 gw ::192.88.99.1 dev sit0

192.88.99.1 is an address which routes to the nearest public IPv6 gateway. Unfortunately for us Australians, that's probably in the USA. But it's easy to setup, as you can see.

This technique has some advantages and disadvantages. On the positive side, you have 2^80 addresses to use. That should be enough for anyone. On the negative side, these addresses are as dynamic as your IPv4 address because they are derived from it. Also, you may be able to make outbound connections but not accept inbound connections, depending on what functionality your DSL modem provides. My DSL modem allows me to open up protocol 41 traffic, but it doesn't provide a configuration option to forward all incoming protocol 41 connections to my linux box. So my box can only accept inbound connections while there's a working outbound connection (this is standard NAT functionality).

So 6to4 is a good technique to get started with IPv6 if you want to, say, browse ipv6 websites. But it's not so useful for servers.

Testing - IPv6 using commands

"ping6" and "telnet" are your friends.

$ ping6 ipv6.l.google.com
PING ipv6.l.google.com(2001:4860:0:2001::68) 56 data bytes
64 bytes from 2001:4860:0:2001::68: icmp_seq=1 ttl=52 time=308 ms
64 bytes from 2001:4860:0:2001::68: icmp_seq=2 ttl=52 time=335 ms
64 bytes from 2001:4860:0:2001::68: icmp_seq=3 ttl=52 time=321 ms

$ telnet luyer.net 80
Trying 2001:470:1f05:14d::1...
Connected to luyer.net.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 25 Aug 2008 00:38:50 GMT
Server: Apache/2.2.3 (Debian) PHP/4.4.4-8+etch6 mod_ssl/2.2.3
OpenSSL/0.9.8c
[ ... etc ... ]

You can also install the netcat6 package (the command is "nc6") to connect out or listen for incoming connections. To test if your web browser is using IPv6 correctly, try these sites:

• www.kame.net - on IPv6 you will see a swimming turtle, on IPv4 the turtle will not move
• luyer.net and it will tell you if you connected through IPv4 or IPv6
• www.sixxs.net will show your originating address and protocol at the bottom of the page.

Registering with AARNet

You'll need to create a username on the AARNet IPv6 Migration Broker and then associate that username with a tunnel.

1. Create User Account
2. Request Tunnel

The "Request Tunnel" CGI hangs for me, I don't know why. I assume it created a tunnel correctly because I'm getting one.

Installation of TSPC

Install the "tspc" package. I'm using Debian, so it's just "apt-get install tspc".

When Debian installs tspc, it automatically configures it to obtain an anonymous IPv6 tunnel from freenet6.net. Although that's great and easy, it's not what we need in Australia. So after installation, stop the daemon with "/etc/init.d/tspc stop".

Configuring the AARNet tunnel broker

To be continued ... no time to write the rest of the document today.

In brief, you need to use the v6udpv4 method and all traffic will be tunneled through a UDP connection. 30 second keepalive messages (I believe it's an ipv6 ping?) will keep NAT working. Your config file should look like this:

auth_method=any
userid=YOURUSERID
passwd=YOURPASSWORD

server=broker.aarnet.net.au
tunnel_mode=v6udpv4
host_type=router
prefixlen=64

client_v4=auto
if_prefix=eth0
if_tunnel_v6udpv4=tun
if_tunnel_v6v4=sit1

keepalive_interval=30
keepalive=yes

proxy_client=no
retry_delay=30
template=setup

Note that AARNet assigns a /56 even though this config asks for a /64.

Monitoring the IPv6 tunnel

AARNet's broker seems a bit flaky. It sometimes ignores the UDP packets so you may need to start the daemon a few times before it connects properly. As I mentioned, the CGI to request a tunnel hangs for me. If it doesn't hang, it may return a shell script, which you can ignore.

It's possible you don't even need to use the "Request Tunnel" CGI, maybe it will assign a permanent tunnel when tspc connects for the first time.

Also AARNet reboot the server at 03:00 every morning. The tspc daemon will try to reconnect if the tunnel fails, but perhaps not forever.

In any case, you want IPv6 to be always available, which means monitoring it. If the tspc daemon stops, you will need to restart it manually. I wrote this simple perl script which just logs whenever IPv6 stops working. It doesn't monitor the process or interface at all (you'd want to monitor the process itself if you change the script to restart a failed process).

#!/usr/bin/perl -w
#       @(#) $Id$
#       vim:sw=4:ts=4:

use Date::Format qw(time2str);
use Getopt::Std qw(getopts);

use vars qw($opt_h);

$| = 1;
getopts('h:');

$opt_h || die "Need option -h hostname";

# Initial and current state
my $state = 'down';

while (1) {
        my $now = time();
        my $newstate = getPingState($opt_h);

        if ($newstate ne $state) {
                open(OF, ">>ipv6-state.log");
                my $ts = time2str('%Y-%m-%d %T', $now);
                print OF "$ts $opt_h $newstate\n";
                close(OF);

                $state = $newstate;
        }

        my $to_wait = 60 - ($now % 60);
        print '.';
        sleep($to_wait);
}

# NOTREACHED
exit(0);

# ------------------------------------------------------------------------
# ping6 a host, and figure out if it is up
# ------------------------------------------------------------------------

sub getPingState {
        my $host = shift;

        my $rc = system("ping6 -c 2 -q -W 8 $host >/dev/null");
        if ($rc == 0) {
                return 'up';
        }

        return 'down';
}

I just run it like this: "check-ipv6.pl ipv6.l.google.com" and it pings once a minute (on the minute) and logs whenever the calculated state of the IPv6 connectivity changes.

For production use you'd want to change the 'sleep' to sleep(60) since it's not friendly to google for many sites to ping in synchronisation (i.e. always at :00). Of course you could always ping6 to broker.aarnet.net.au instead ...

64 bytes from 2001:388:1:5001:2a0:a5ff:fe4b:ae3: icmp_seq=1 ttl=64 time=52.8 ms
64 bytes from 2001:388:1:5001:2a0:a5ff:fe4b:ae3: icmp_seq=2 ttl=64 time=51.6 ms
64 bytes from 2001:388:1:5001:2a0:a5ff:fe4b:ae3: icmp_seq=3 ttl=64 time=51.1 ms

NFS servers don't play nice with iptables when the daemons use random port numbers (which is the default in debian).

To force consistent port numbers upon NFS (when using nfs-kernel-server), set the following in /etc/default/nfs-kernel-server. This will force mountd to use port 4002 for both TCP and UDP.

RPCMOUNTDOPTS="--port 4002"

For lockd, add the following into /etc/modules (you need to build lockd as a module for this) ...

lockd    nlm_udpport=33000 nlm_tcpport=42049

Next, you can force statd to use port 4000 and port 4001 by setting this in /etc/default/nfs-common:

STATDOPTS="--port 4000 --outgoing-port 4001"

Finally, add iptables rules:

iptables -F nfs_server
iptables -A nfs_server -p TCP --dport 2049 -j ACCEPT # nfs
iptables -A nfs_server -p TCP --dport 4000:4001 -j ACCEPT # statd
iptables -A nfs_server -p TCP --dport 4002 -j ACCEPT # mountd
iptables -A nfs_server -p UDP --destination-port 4002 -j ACCEPT # mountd
iptables -A nfs_server -p UDP --destination-port 33000 -j ACCEPT # lockd
iptables -A nfs_server -p TCP --dport 42049 -j ACCEPT # lockd

Be sure that only packets from client IP addresses are directed through the nfs_server table.

Have you seen this error?

[Wed Jul 16 10:18:17 2008] [warn] NameVirtualHost *:80 has no VirtualHosts

This is a particularly annoying message because there are many questions about it on many forums and no definitive answers.

Quoting from apache2 <perl> sections: "*:80 has no VirtualHosts" error ...

In short, the following is an example that will produce the error
message quoted above :
    NameVirtualHosts    *:80
    <VirtualHost foo:80>
    </VirtualHost>

In other words, if you have 'NameVirtualHosts BLAH' and you do not
have a '<VirtualHost BLAH>' directive, you get that error.

But that's not the end of the story. The following configuration also causes that error message (on "apache2 -f test.conf -S") ...

Listen 80
NameVirtualHost *:80


<VirtualHost *:80>
        ServerName      name1.tull.net
        DocumentRoot    /var/www/
</VirtualHost>


<VirtualHost *:80>
        ServerName      name2.tull.net
        DocumentRoot    /var/www/
</VirtualHost>


<VirtualHost *:80>
        ServerName      name4.tull.net
        DocumentRoot    /var/www/
</VirtualHost>


<VirtualHost *>
        ServerName      name4.tull.net
        DocumentRoot    var/www/
</VirtualHost>

The errors are:

[Wed Jul 16 10:24:47 2008] [warn] _default_ VirtualHost overlap on port 80, the first has precedence
[Wed Jul 16 10:24:47 2008] [warn] _default_ VirtualHost overlap on port 80, the first has precedence
[Wed Jul 16 10:24:47 2008] [warn] NameVirtualHost *:80 has no VirtualHosts
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:80                   name1.tull.net (/etc/apache2/strip.conf:4)
*:80                   name2.tull.net (/etc/apache2/strip.conf:10)
*:80                   name4.tull.net (/etc/apache2/strip.conf:16)
*:*                    name4.tull.net (/etc/apache2/strip.conf:21)

In this configuration there are corresponding "VirtualHost *:80" definitions. What's confusing apache2 is the last definition which is "VirtualHost *", and it's reporting a warning with the wrong directive (NameVirtualHost).

Furthermore, the "VirtualHost overlap on port 80" warnings are being generated for correct directives, and no warning about the incorrect directive.

So the fix, at least for this scenario, is to ensure that all "VirtualHost" directives use the same value as specified in "NameVirtualHost".

Update 2008-07-18 ... also you don't want to have two "NameVirtualHost *:80" directives in the configuration. Multiple directives with the same arguments are not treated as one!

Due to the recently exposed ssh key generation vulnerability, many ssh keys may need to be deleted and recreated. This tool may help with that.

What it does is find all the ssh keys existing on several hosts and where those keys appear in .ssh/authorized_keys files. It collates the results from all hosts and writes a directed graph for the 'graphviz' tool, which helps to visualise which keys are providing access to which users.

The scan tool works by connecting to each specified host using ssh and executing a host script. The host script examines the user's .ssh directory and sends a report to STDOUT, which is received by the scan tool. The host script can also iterate through /etc/passwd and examine every user's .ssh directory.

Use graphviz to visualise the graph. How to use: firstly make a file 'host-list' of all hosts you have access to, one line per hostname. Include any hosts you have root access to just as the hostname, and if you have only user access, use "user@hostname". You need to run the scan tool from a place which can ssh to all these hosts -- as root for all hostnames listed in your 'host-list' file which are not qualified with a username.

scan-ssh-keys.pl $(cat host-list) > output.dot
dot -Txlib output.dot

Use the mouse wheel to zoom in/out of the graph image. Use the mouse middle button to pan the image. You can also use 'dot' to write various output files such as JPEG or SVG.

Here is a sample graph produced by the scan tool. The graph resolution is deliberately reduced (to make the node labels unreadable) for security reasons. Also my full ssh key graph is somewhat larger than this :-)

Later on I expect to enhance the scan tool to assist with adding and deleting ssh keys.

To download from my Mercurial repository, see: nick-src-regen-ssh-keys.

In From Win32 to Cocoa: a Windows user's conversion to Mac OS X—Part II, Peter Bright writes:

So Windows is just a disaster to write programs for. It's miserable. [...]

The code isn't just inconsistent and ugly on the outside; it's that way on the inside, too. There's a lot of software for Windows, a lot of business-critical software, that's not maintained any more. And that software is usually buggy. It passes bad parameters to API calls, uses memory that it has released, assumes that files live in particular hardcoded locations, all sorts of things that it shouldn't do. If the OS changes underneath—to prohibit the reuse of freed memory, to more aggressively validate parameters, to stick more closely to the documentation without making extra assumptions or causing special side-effects—then these programs break.

So Windows has all sorts of bits of code which are there to provide compatibility with these broken applications. It's hard for MS to maintain and fix this code, because it means the code no longer does what it's documented to do; it does that plus some other stuff. It's hard to test, because there's no knowing exactly what broken things programs are going to try to do. And it makes things more expensive; Microsoft has all sorts of special behaviours it needs to preserve. This means that not only can it not make the API better—it can't even easily make the API's implementation better. It's all too fragile.

It's nice to see confirmation of this from an experienced Windows programmer. Since I don't program for Windows at all, my opinions are based on what I see and read about Windows, rather than coal face development experience. The take-home message from this article is that mediocrity rules the Windows development ecosystem; although there are no doubt many developers who write high quality Windows applications, there are also many who do not, and Microsoft supports the latter to the detriment of the former.

I've become a recent convert to distributed SCM systems, particularly Mercurial and Git.

Use of a distributed SCM is a much more sensible way to release open source software than the traditional tarfile, or even having a public CVS or SVN repository. In particular:

• It makes it easy for users of the software to feed back their local changes, which encourages more participation and development of the code
• It helps users maintain their own local changes in an SCM
• It helps users upgrade to newer releases (without wiping out their local changes, for instance).

Having a public CVS or SVN repository solves only the problem of giving users quick access to the latest version of the software. CVS and SVN don't help with feedback or maintenance of local changes. They can help with upgrades - but it's of little practical benefit when local changes can't be committed into the repository.

I was in the process of converting my CVS repositories to SVN (it takes a long time) when I discovered the virtues of Distributed SCMs. I'm using both Git and Mercurial. Git is perhaps more powerful but Mercurial is more user-friendly. So I have halted all conversion to SVN and I'll be converting remaining repositories to Mercurial. I'll be converting most of my SVN repositories over to Mercurial too. Ultimately the only code/data remaining in SVN will be that which I particularly need to be centralised (it might end up being none at all).

I have started to put some repositories of my public source code online already. The full list is available at: http://www.nick-andrew.net/hg and individual repositories which are currently online are:

develooper.com-src-qpsmtpd	I use qpsmtpd on the mail servers here primarily for spam entrapment; for example to refuse emails addressed to nonexistent users at my domains. I get quite a lot of spam due to my long history with USENET. This repository contains the qpsmptd 0.26, 0.32 and 0.40 releases as downloaded from tarballs plus my local changes (mostly against 0.26 so far).
nick-pub-src-minix-ar	To extract my old stuff (circa 1990) successfully, I need a V7-compatible 'ar' program. This is the original 'ar' program from Minix 1.x, modified to work on a modern machine (32-bit, with prototypes, etc).
nick-src-apt-cacher	This is the original apt-cacher program (versions 0.1 through 0.4) before being picked up by Jon Oxer and packaged into Debian. Don't use this code; the repository is here merely for historical purposes.
nick-src-backup-cdr	I wrote this system to do encrypted incremental backups of modified files - first to CDR, then to DVD. I need something to do size limited incremental backups since the total amount of backup is many times the capacity of a DVD. This system regulates the quantity of backup per day.
nick-src-direct	This is a perl implementation of the 'direct' program I used in the TRS-80 days, to pack several files together into 2 (!) structured files, a 'DIR' and a 'DAT' file. Think of it as like a zipfile without any compression. Anyway when I restored my old TRS-80 software I needed to extract data from some of these structured file pairs so I wrote it in perl - a language which was not available back in the mid-1980s. It was trivial to do in perl, heh.
nick-src-distributed-filesystem	This repository contains my 2003 ruminations on distributed filesystems. Useful if nothing else for the pointers to various designs people may have implemented.
nick-src-incremental-tar	This C program replicates the function of Gnu TAR and optionally compresses its output on the fly. The point is that you can feed it with a (possibly infinite) list of files to be archived, and an output size limit, and it will ensure that its output size does not exceed the limit. It is useful for incremental backup - you give it a list of all your modified files, and a size (say 699 MBytes) and it will cram as many of those files in compressed form as can fit in 699 megs.
nick-src-misc-https-proxy	This perl program listens on localhost port 80 and when it receives a connection, makes an SSL connection to a specified server on port 443 and forwards the data in both directions. This allows logging or debugging of an HTTPS data stream by using HTTP at the browser end.
nick-src-misc-logrun	This cute little program reopens STDOUT and STDERR to files in a logging directory and runs the program. If the program exits with a non-zero code, the log files are moved to a 'bad' directory, otherwise they are moved to an 'ok' directory.
nick-src-misc-showdns	This program does several DNS lookups on a specified domain name, and possibly filters the output. The aim is to quickly find the nameservers, web servers etc for a domain name and particularly to find those which are _not_ served by a specified nameserver.
nick-src-trs80	This is all my old TRS-80 source code in a single repository, rather than having to download many tarfiles. Again, it's for historical purposes. Unless you like Z80 assembler a lot.

Here's a patch which I believe solves the recent linux local root problems, for the latest stable OpenVZ kernel (2.6.18-028stab053).

To run linux guests I can highly recommend OpenVZ. It's a container system - you run only the host kernel which is modified to implement isolation between containers and each other, and the host. Processes in the containers run as processes on the host, with a container-specific root directory.

The upshot of all this is that overhead is almost zero; each guest runs at almost native speed. There are various other benefits too, such as:

• The guest root filesystem is a directory on the host, so the host has full visibility to the guest files. It isn't necessary to preallocate space to each guest, so there's no wasted space and each guest can grow dynamically.
• Resource utilisation limits are enforced and can be modified on the fly.
• Guests can be minimal because they don't have to support hardware. A typical guest, before installing additional software, may be running only these processes: init, syslogd, sshd and cron. 4 processes - and you don't even need cron.
• Networking is very easy to get going (unlike user-mode-linux).
• Using templates, you can have a new guest installed and running in under 2 minutes.

There are some caveats though:

• The host kernel is modified in many places. The latest stable patch is over 4M.
• Not every linux kernel version is supported. The latest stable, supported patch is against 2.6.18 or you can use a development level patch against 2.6.22
• You can see all the guest processes on the host; it can be tricky to know which guest a given process is running on.
• Some kernel functions are restricted, such as kernel-space NFS server (use the userspace one instead).

Overall OpenVZ is very stable and functional. I haven't had any kernel crashes related to OpenVZ. I would like them to support newer kernels - specifically 2.6.23 and above, since there are features in 2.6.23 that I want to use. But the patch is quite extensive and so I can't really blame them for picking a version and sticking with it for a long time. OpenVZ patch developers have contributed many security and stability fixes back to Linus. One day, much of OpenVZ will be integrated into the mainline kernel. Already 2.6.24 supports PID namespaces (in which process IDs are unique to each guest, not the host) and further OpenVZ functionality will move into the mainline kernel over time.

Importing my bank account history today from a CSV file exported by the bank's website, as I do every month, and the import failed. The reason was that the bank changed the dates on several transactions made from December 2007 to as early as April 2006. The dates were changed from 17th or 16th to 15th in each case.

What is it about banks that they can arbitrarily change transaction dates, even 12+ months after the transaction occurs? This could have been legally problematic for me, say if I had to transfer money by a certain date (and did that) and sometime later the bank's "official" record of the transaction has changed.

What has happened is that my financial records now no longer agree with those of the bank, for no good reason, and I have to adjust mine accordingly, or else there will forever be a discrepancy.

Firmware for the LifeView TV Walker Twin (DVB-T USB digital TV receiver) can be found here at dvb-usb-tvwalkert.fw. Copy the file (without renaming it) into /usr/lib/hotplug/firmware/. This is needed to make the device work in linux.

I'm working on a driver and it will be merged into the linux-dvb project repository in a few days.