Tuesday, 31 May 2011

FIX: 404 Errors Using apt-cacher-ng

I recently upgraded my Ubuntu server to Debian Squeeze, but not without difficulties.

The first problem was with apt-cacher-ng. Well, actually it was two problems. The first involves an apparent difference between how Ubuntu and Debian configure their apt clients to use a proxy.

On Ubuntu I have always used /etc/apt/apt.conf with a single line pointing to my proxy like so;

Acquire::http { Proxy "http://apt:3142"; };

This didn't seem to work with Debian clients, the fix is to put the same line into a file at /etc/apt/apt.conf.d/01proxy.

Actually you can call the file anything you like, even "apt.conf" but naming the file like this fits in with normal Debian conventions better, which can't be a bad thing.

The second issue I had was with Ubuntu clients using the apt-cacher-ng proxy installed on a Debian server.

I kept getting "404 Not Found" errors every time I did an apt-get update on the (lucid) clients.

Google was no help. There were a few people who were having the same problem but no answers.

Eventually I found the issue myself. There is a file in the apt-cacher-ng directory that has an error. To fix the problem you edit this file;

vi /etc/apt-cacher-ng/backends_ubuntu

and change the line so it says something like this;


Of course you should change it to something more local to where you are. The key here is that on my system the trailing /ubuntu/ was missing and this was causing the 404 errors.

Monday, 30 May 2011

HOWTO: Relocate LVM to a New Server

The main storage on my home server is on 2 x 2TB hard disk drives which are configured as an LVM volume.

(For a guide on configuring LVM from scratch see this article.)

My server currently runs Ubuntu 10.04 but I've decided to bite the bullet and swap it over to Debian Squeeze.

I've never moved an LVM volume to another server / OS installation so it's time to learn how to do it, I guess.

It should be obvious but I will nevertheless say it here anyway. Mucking about with file-systems is a dangerous thing to do and any misstep can lead to disastrous, catastrophic and permanent DATA LOSS! Ensure that you have adequate backups before attempting this procedure. You have been warned!

First, you need to login as root.

sudo -i

Get the details for your current LVM Volume Group(s);

--- Volume group ---
VG Name store
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 6
VG Access read/write
VG Status resizable
Cur LV 1
Open LV 0
Max PV 0
Cur PV 2
Act PV 2
VG Size 3.64 TiB
PE Size 4.00 MiB
Total PE 953862
Alloc PE / Size 953862 / 3.64 TiB
Free PE / Size 0 / 0
VG UUID 9zwhOn-3Qs6-aPTo-kqQ4-RL4p-ICTA-l56Dsz

As you can see, I have a single volume group called "store".

Let's see what Logical Volumes are in the Volume Group;
--- Logical volume ---
LV Name /dev/store/archive
VG Name store
LV UUID 80eFYi-n0Z7-9br1-bbfg-1GQ6-Orxf-0wENTU
LV Write Access read/write
LV Status available
# open 1
LV Size 3.64 TiB
Current LE 953862
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:0

We can see that there is a single volume 'archive' in the group.

Check your fstab for the line pertaining to your LVM volume;

cat /etc/fstab

The relevant line in my case is this;

UUID=057272e5-8b66-461a-ad18-c1c198c8dcdd /store/archive ext3 errors=remount-ro 0 1

Make sure you keep this info at hand for later on.

It so happens that I am sharing this volume using NFS so I need to stop my NFS server;

service nfs-kernel-server stop

so that I can unmount it.

umount /store/archive/

Now I need to mark the VG as inactive;
vgchange -an store
0 logical volume(s) in volume group "store" now active

Next I prepare the volume group to be moved by "exporting" it;
vgexport store
Volume group "store" successfully exported

Let's take another look at the volume group details;
Volume group store is exported
--- Volume group ---
VG Name store
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 5
VG Access read/write
VG Status exported/resizable
Cur LV 1
Open LV 0
Max PV 0
Cur PV 2
Act PV 2
VG Size 3.64 TiB
PE Size 4.00 MiB
Total PE 953862
Alloc PE / Size 953862 / 3.64 TiB
Free PE / Size 0 / 0
VG UUID 9zwhOn-3Qs6-aPTo-kqQ4-RL4p-ICTA-l56Dsz

As you can see, the VG Status has changed to "exported"

Now you can shutdown your system and relocate the drives or reinstall the OS. In my case my OS is installed on a removable Compact Flash card which I have already pre-installed Debian Squeeze. i.e. Here is one I prepared earlier!

OK, once our server has rebooted we need to install LVM and associated utils;

sudo apt-get install lvm2 dmsetup reiserfsprogs xfsprogs

We activate the volume group using the vgchange command again;
vgchange -a y
Volume group "store" is exported

Import the volume group into our new system with the 'vgimport' command;

vgimport store

Let's have a look at our logical volumes again;
--- Logical volume ---
LV Name /dev/store/archive
VG Name store
LV UUID 80eFYi-n0Z7-9br1-bbfg-1GQ6-Orxf-0wENTU
LV Write Access read/write
LV Status available
# open 0
LV Size 3.64 TiB
Current LE 953862
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:0

That looks good. It should be the same as it was in the old system and the LV status should be "available"

Take the line from the fstab file on the old server and add it to the new server;

vi /etc/fstab

Paste the line at the end;

UUID=057272e5-8b66-461a-ad18-c1c198c8dcdd /store/archive ext3 errors=remount-ro 0 1

Recreate the mountpoint if it doesn't already exist;

mkdir -p /store/archive

And finally we can mount the drive;

sudo mount /store/archive/

We can check that it is mounted OK with df;
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 7387992 930944 6081752 14% /
tmpfs 1025604 0 1025604 0% /lib/init/rw
udev 1020856 184 1020672 1% /dev
tmpfs 1025604 0 1025604 0% /dev/shm
3845710856 2358214040 1292145880 65% /store/archive

And that's it! Glad I didn't need to resort to my backups . . .

Wednesday, 25 May 2011

HOWTO: Basic Server Build with Debian

So, you want to turn that old unloved cast away PC you rescued from the garbage skip at work into a server and you were wondering how to go about it eh?

Well my friend, you have come to the right place, read on.

Hardware Requirements;

Any modest old cast aside hardware will do, something with a reasonable amount of RAM, Minimum 8GB hard disk and some manner of pentium processor will be fine. It is important that it is reliable of course.
Pro Tip: Using a plain old 8GB Compact Flash with a suitable adaptor such as this one can give you a router that is more reliable, a lot less noisy and with far lower power requirements than some old clunker hard disk drive you found in the back shed. However, it's also fun to reuse that old junk in a useful fashion thereby saving it from certain death at the local metal recyclers so go with whatever floats your boat.

I've been procrastinating for some time about shifting from a Ubuntu to a more vanilla debian focus and I have decided now is the time to bite the bullet and go ahead. Accordingly, I will log my steps as the first in what I hope will be a series of articles (or updates to my previous articles) that will guide you through building a server that is suitable for a typical SOHO or home user using Debian Linux.

This article will cover installation and basic configuration of a basic headless server with openssh and a static IP address along with a few other comforts that I generally add to all my installs.

OK, to start the process off we need to download an ISO image.

I am going to use Debian 6 so I have downloaded this ISO but if you don't want to use BitTorrent there are other options. The CD I am using is the AMD64 6.0.1 "netinst" CD. This is a minimal ISO that will download the majority of the packages we require during the install. Because we will be installing a very basic system to start off with this won't amount to a lot so it should be OK. With the additional installation of apt-cacher-ng that we will also do any packages installed later on will be cached locally and therefore downloaded only once. However, if you prefer to download a full set of the CD's or DVD's instead then of course you should go right ahead and do that instead.

OK, once you have downloaded an ISO and burnt it to CD, put it in the machine you intend to use as a server and boot it up. You may have to modify your system CMOS settings to allow this to happen. (Do I need to tell you this?)

Step 1: Installing the base system

At the boot menu choose "text install" because hey, this is a server and you don't even have a mouse connected right? Right?

Now, I'm sure you don't need me to hand hold you through all the screens asking about where you are located, what language you speak and what to call the server. If you do then you probably should give up now because a headless server is not what you want to be playing with.

Just enter all the obvious answers, tailored to suit your specific locale and requirements of course. When asked for a domain, enter your domain name (if you have one) otherwise just make one up. Make sure it is clearly a fake domain such as "example.org" or "myhome.net" and not one that is used (aka owned) by somebody out on the Internet that you might want to connect to in future. Using google.com or debian.org is NOT recommended!

You will be asked to enter a root password. Make sure you don't forget it!

A word on disk partitioning. There are many ways to approach this. A lot of the time people just plonk everything in one big partition. They usually do this because that is how they do it in Windows. This is not the best way to partition a drive.

The best way is to separate (at least) your home directories (/home) from the root (/) partition. This will make things far easier for you down the track if you need to do upgrades, reinstall the OS or anything else where you want to keep your users homes intact.

In my example however, I am going break my own advice and choose the simplest option and just plonk everything into one big fat partition.

I'm doing it this way because I usually use a small disk for the root (/)partition (in this case an 8Gb CF card) and I am going to manually move my user homes to a separate (much larger) hard disk later on. This means that I am not too concerned with fancy partition schemes for the moment. I am also going to ignore LVM for the same reason.

So, with that in mind, when you are asked about partitioning choose "Guided - User entire disk" followed by "All files in one partition"

The only other bit of interest is the "Software Selection" screen.

Since we are setting up a server, we don't want a full blown GUI getting in the way and bogging things down so make sure you uncheck that option at the top of the list.

Finally answer "yes" to install the grub bootloader.

When the install process completes the machine will restart.

Step 2: Configure a basic server

Login as the root user using the password that you entered during the install process.

Assuming that you have a working DHCP server currently on your network the installer will have configured your server to use DHCP.

Let's check our network connectivity before we charge ahead.

Try pinging Google by name;

ping -c 4 www.google.com
PING www.l.google.com ( 56(84) bytes of data.
64 bytes from icmp_req=1 ttl=53 time=16.5 ms
64 bytes from icmp_req=2 ttl=54 time=16.2 ms
64 bytes from icmp_req=3 ttl=54 time=16.2 ms
64 bytes from icmp_req=4 ttl=54 time=16.7 ms

--- www.l.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 15639ms
rtt min/avg/max/mdev = 16.213/16.448/16.705/0.226 ms

You should see ping responses as per above otherwise you will need to resolve this issue before you continue.

We are going to install some extra packages now. If you are intending on using more than one debian PC on your network then it is a good idea to cache those packages so you don't need to keep downloading them over and over again on every PC you build.

We do that by installing apt-cacher-ng;

apt-get install apt-cacher-ng

We need to tell the system to download packages through apt-cacher-ng instead of directly.

Create a file "apt.conf"

vi /etc/apt/apt.conf

Add the following line;

Acquire::http: { Proxy "http://localhost:3142"; };

Update aptitude;

apt-get update

This should complete without errors otherwise you will need to resolve this issue before you continue.

Now, if you are like me you will prefer to login to this server via SSH rather than camping in front of a text console. Also, having used Ubuntu for quite some time I have become accustomed to sudo. I also prefer vim, so I add that as well.

Install openssh server, sudo and vim;

apt-get install sudo openssh-server vim

To allow a user to use sudo, add them to the sudo group;

usermod -a -G sudo brettg

That's it for our base system, but we have one more thing to do.

Step 3 : Setting a static IP address

Because this will be a server (and possibly a router), we really don't want to be using a DHCP provided address. Static address's are where all the server action is at.

Before we change stuff, we need to gather a bit of information about our current network.

Query your network interface (assuming eth0);
ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:0c:29:f4:88:50
inet addr: Bcast: Mask:
inet6 addr: fe80::20c:29ff:fef4:8850/64 Scope:Link
RX packets:19022 errors:0 dropped:0 overruns:0 frame:0
TX packets:4389 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9278651 (8.8 MiB) TX bytes:395157 (385.8 KiB)

Take note of the Mask and Bcast details.

Query our routing table;
netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface U 0 0 0 eth0 UG 0 0 0 eth0

Take note of your default route (ie Destination, which in this case is and the network address which in this example is

This is all we need to configure a static address.

You should use an IP address that is not part of the existing DHCP pool. Check your current router and determine the pool that is in use. When I configure a small network I generally set my pool to be .100 thru 199 which leaves everything under 100 and over 199 available for static use. I will be using here which is, of course, outside my DHCP pool.

To change your network interface edit your "interfaces" file;

vi /etc/network/interfaces

This should currently have a section like this;
allow-hotplug eth0
iface eth0 inet dhcp

We want to change it so that it looks like this;
allow-hotplug eth0 eth0
iface eth0 inet static

Note: On Ubuntu you will have auto eth0 not allow-hotplug eth0

When the changes are made you should reboot your server. You should confirm that the eth0 interface has an address of using the ifconfig eth0 command and also check that you have name resolution and Internet access by pinging www.google.com.

Step 4 : Modifying our system for CF users (optional)

If, like me, you are using a (non-SSD) Flash RAM based drive then you might want to make a few adjustments to your system to compensate for the lack of wear leveling in the drive.

Follow this guide to extend the lifespan of your Flash drive now.

So, assuming you have an IP address and your pings respond as expected then congratulations, you have built yourself the basis of a handy little debian server!

The next step you take should be to configure your server as a router

Adjust Your File System To Accomodate Flash Drives

I am using a Compact Flash card for my root partition on a small Atom based server at home. I find this to be a good way to build an inexpensive, quiet, low powered server however it does introduce a few special problems due to the absence of any wear leveling logic as used by proper SSD hard drives.

I use a slot loaded CF card which makes it easy for me to pull the card to make an image (using dd) or swap over to another OS without unscrewing the case. However using Compact Flash or a plain old USB thumb drive might be cheap and handy but it also brings to head some issues related to how the system reads and writes to the card.
Flash memory is not happy about writing to the same memory cell over and over and over so consequently any cell that is treated in this manner will eventually die. Proper SSD's work around this by incorporating special logic that shifts sectors around automatically so that all the memory cell's do roughly the same amount of work. This is called "wear leveling". Dumb old Compact Flash cards don't do wear leveling but there are some steps we can take to ameliorate this problem to some degree.

These days most Linux systems use EXT3 or EXT4 file systems which are both journaling file systems. This means that every time a file is accessed the journal is updated to record that action. This makes it easier for the file-system to keep track of reads and writes and detect when an error may have occurred. Unfortunately it also means lots of writing (to the journal) which means a premature death for our CF card.

The older EXT2 FS does not do journaling which means we will have less protection but seeing that we are not using the CF to store data (just for the OS) I consider it an acceptable "risk".

To use EXT2 edit your fstab file;

vi /etc/fstab

On the line pertaining to your root (/) file-system change the "ext3" to "ext2", it's that simple.

Another thing that a normal system does is update each file every time it is read with a time-stamp. That's another thing we want to stop happening.

On the same line, find where it says errors=remount-ro and append to that column ,noatime.

Here is an example line;
UUID=68a316e0-8071-47e3-b31d-718a7be2e498 / ext2 errors=remount-ro,noatime 0 1

Another area that gets written to quite a bit is the /tmp directory.

We can move that off the Flash drive and into RAM using tmpfs. This has the bonus of improving overall system performance by a small amount.

Add this line to your fstab;
tmpfs /tmp tmpfs  size=256000m,exec,nosuid 0 0

You can tweak the amount of RAM to use but I wouldn't go below 128Mb personally.

And finally, once you install a normal hard disk to your server you should relocate your swap file over to a partition located on it. For now I am simply going to disable swap altogether. To do that just stick a comment "#" at the start of the relevant line.

And that's it, these changes should allow your "dumb" Flash drive based OS installation to live a reasonably long and happy life. My current server has been going strong for about 2 years now, fingers crossed!

FIX: ALT+PrtScn Not Working

In the latest version(s) of Ubuntu there is a stupid bug where ALT+PrtScn no long works

The fix is simple, in a console enter the following code;

sudo sysctl -w kernel.sysrq=0

This will disable the "SysRq" key, which apparently is interfering with Alt+PrtScn.

Just another reason to switch over to vanilla Debian

Modify The System-Wide PATH

For years, when I wanted to add a directory to the system path I have been adding something like PATH=$PATH:/new/path to the end of /etc/profile.

This is because this is the "answer" that many people provide when you do a Google search on how to do it.

However, in Ubuntu the default path is not set in this file so I have always had the feeling that this is not the "right" way to do this. There must be somewhere else that holds this info?

Well I just discovered it.

The system path is set in /etc/environment.

Here is the default path;

brettg@jupiter:~$ cat /etc/environment

To add a path simply stick a colon at the end followed by your new path;


Easy peasy! (When you know how)

This does not apply to debian (squeeze), the system path is set in /etc/profile same as other systems.

Saturday, 21 May 2011

HOWTO: The Five Minute VPN Guide

UPDATE: 05-06-2012, latest version: VPN v1.03

I posted some time ago a guide for setting up a PPP over SSH vpn but it was a bit clunky and I was never fully happy with it.

So, I have spent some time adding all of the hard work to a fully interactive script that has the following features;

* Automatically configure your client details in a "vpn.conf" file.

* Bi-directional routing between the server and all remote nodes is automatically configured.

* Interactive functions to stop and start the VPN

* Function to check the VPN status, attempts restart if down

* Send email to a specified administrator when the state of the VPN changes.

* Automatic setup of keys for passwordless connections.

* Zero scripting skills required

Network admins who want to connect two or more offices using an encrypted, secure VPN over the public Internet. Clients at remote sites will access the Internet directly through their local gateway while all internal traffic is automatically routed via encrypted VPN links back to the central site.

Two debian or ubuntu servers configured as routers, designated as SERVER and CLIENT. Both must be connected to the internet and the SERVER should have a FQDN of some sort (see www.dyndns.com if you don't have your own domain). Assuming you are running a firewall on the server you must poke a hole in it to allow SSH connections from the internet.
Authors Note:
This script started out as a simple clean up of the old one but of course that quickly blew out to a full on rewrite until I ended up with an all singing, all dancing mega-vpn management utility that I reckon is the easiest way to setup a VPN ever. Not one line of the original script remains intact!

Anyway, enough of the chest beating, let's get on with the show!

Step 1: Setting up the Server

Clients connecting to the server will do so using a local account on the server that is specifically used for this purpose.

Create a user called "vpn"

sudo adduser --system --group vpn

The --system parameter has set the vpn users shell to be /bin/false. However, because the vpn user needs to be able to log in via ssh, we must change this to /bin/bash in the /etc/passwd file.

Edit the passwd file;

sudo vi /etc/passwd

Modify the line for the vpn user so that it ends with /bin/bash;


We also need to set a password for the "vpn" account;

sudo passwd vpn

The vpn account password will only be used while doing the initial configuration of your VPN clients. You should choose a reasonably complex (secure) password and not be concerned about making it easy to type or remember.

The vpn user needs to be able to bring the ppp connection up and down as well as modify the system routing table. We will configure sudo to allow access to those commands.

Edit your sudoers file;

sudo visudo

Append these lines to the end of the file;

vpn ALL=NOPASSWD: /usr/sbin/pppd
vpn ALL=NOPASSWD: /sbin/route

Finally, we need to log in as the vpn and set up a few bits in its home folder.

Change to the vpn user;

sudo su vpn

Create an ssh directory;

mkdir .ssh

We need to seed an "active_networks" file with the subnet(s) that the VPN clients should be able to route to (usually the local LAN subnet that your VPN server is on but if you have a more elaborate network there may be multiple subnets. Simply add all the ones that you need remote hosts to route to). The "active_networks" file should be located in the vpn user's home folder (and owned by the vpn user)

Create an active_networks file;

vi ~/active_networks

Add a line for the servers local subnet followed by a hash and the server name.

Example: # vpn-server

If you have more than one subnet then you can add them too (on separate lines)

The active_routes file holds a record of all the remote subnets (VPN network nodes) that the server is connected to. As each client gateway connects to the server it adds it's own LAN subnet to the file. If new routes are added later you can do a "vpn check" on the client gateway which will automatically update the local routing table with any new routes for any other nodes that may have been recently added to your network.

And that's all there is for the server part of this howto!

Yes, seriously.

Step 2: Configuring a Client

Configuring the client is even easier than the server, we just need to download and run my new VPN script.

On the client host, download my vpn client script

Put the vpn script file somewhere in your system path or make a link to wherever you decide to put it.

E.g. sudo ln -s /store/scripts/vpn /usr/sbin/vpn

Install dependencies;

sudo apt-get install ipcalc ppp

And finally, execute the script with the "setup" directive;

sudo ./vpn setup

This will create a default config for your VPN. If this will be the first or only client node to be connected to your VPN server then the only required value is the SERVER_HOSTNAME for the VPN server. This should be a FQDN that is pingable from the Internet. For 99% of scenarios the rest of the default settings will work perfectly fine.

Once you have finished the setup, you can start the vpn;
sudo ./vpn start
Starting vpn to vpn.tuxnetworks.net on port 22 - Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
Deflate (15) compression enabled
local  IP address
remote IP address
Setting static routes
Added route to
Added route to

Check the status of your VPN connection;
sudo ./vpn status
Local network : [eth0]
Connected to  : vpn.tuxnetworks.net
Remote IP     :
Local IP      :
PID           : 25493

To have your client check whether the VPN is up (and automatically restart it if it's not) add an entry to your system crontab;

sudo vi /etc/crontab

Add a line like so;
*  *    * * *   root    vpn check >> /dev/null 2>&1

This will run every minute, check the vpn status as well as update any new routes to new nodes that have been added since the last time it was run.

Of course the vpn script file will need to be in your system path for this cronjob to execute. (See above)

If you also configure an administrator email address (and your system is able to send emails of course) then it will email the administrator every time the VPN link goes down, and again when it comes back up.

I've tried to make the script as simple as possible to use and I hope I have covered all the possible failure scenarios gracefully.

Give it a go and let me know in the comments or send me an email to the address contained in the script header and tell me what you think.

Any and all feedback is welcome.


Wednesday, 4 May 2011

Getting Up To Speed With IPv6: Basic IPv6 Setup

This is the third in a series of articles that I hope will get you on the road to IPv6 in a relatively painless fashion.

If you arrived here from a search query, you may be interested in reading the Introduction and Setting The Stage articles first.

In order to use IPv6 our router requires a globally routable IP address. This means we cannot use one of the ubiquitous "home network gateways" in it's normal mode of operation as a NAT router as they do not offer native support for IPv6 and we cannot do IPv6 over NAT.

Fortunately, most of these devices can be configured in "bridge" mode which will allow a Debian/Ubuntu server to take over the role of our main Internet router thereby paving the way to IPv6 goodness.

Step 1: Configure A Server As An IPv4 Internet Gateway

Follow the IPv4 router guide found here to prepare your router for IPv6. Come back here when you are finished.

OK, once you have your IPv4 router setup and running we can start adding IPv6 support.

Step 2: Basic IPv6 Functionality

Creating an account with a Tunnel Broker:
The first thing you need to do is visit Hurricane Electric's Tunnel Broker page and sign up for an IPv6 tunnel account.

Once you have created your account we need to configure the tunnel on our router.

Creating an IPv6 tunnel:
Login to your tunnel account and click on "Create Regular Tunnel"

Enter the public IP address of your server in the text field called "IPv4 Endpoint (Your side): (ie: The IP address of your ppp0 adapter)

Choose a tunnel server that is closest to where you are (you can use traceroute to find one with the lowest number of hops or simply go by geographical location). Going with the default server offered is probably the best bet though.

Click on "Create Tunnel"

You should now see something like this;

And that's it, your tunnel has been created!

Configuring Your Tunnel

Now we need to configure our router to use our new tunnel.

As root, edit your interfaces file;

sudo vi /etc/network/interfaces

Add the following lines replacing the parts in [italics] with the address details as provided on your Tunnel Details Page;

auto ip6tunnel
iface ip6tunnel inet6 v4tunnel
address [Client IPv6 Address]
netmask 64
ttl 64
gateway [Server IPv6 Address]
endpoint [Server IPv4 Address]
local [Client IPv4 Address]

Note: When entering addresses, don't include the /n at the end as this is the netmask and is not part of the address. It is worth noting that, unlike IPv4, IPv6 supports only CIDR notation (bitwise) netmasks, decimal netmasks are not supported.

Once that is done, save the file and restart your router, I'll wait here until that's finished.

OK, now let's have a look around and do some tests.

In a shell console, enter;

ifconfig ip6tunnel

ip6tunnel Link encap:IPv6-in-IPv4
inet6 addr: fe80::7b02:25c5/128 Scope:Link
inet6 addr: 2001:470:c:2345::2/64 Scope:Global
RX packets:170953 errors:0 dropped:0 overruns:0 frame:0
TX packets:168578 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:140703681 (140.7 MB) TX bytes:20945209 (20.9 MB)

Hopefully you will see similar output to above.

Let's try and ping the Hurricane Electric IPv6 DNS servers. The address for this server can be found on the tunnel details page.

IPv6 uses the ping6 command but it works exactly like "normal" ping;
ping6 -c 4 2001:470:20::2
PING 2001:470:20::2(2001:470:20::2) 56 data bytes
64 bytes from 2001:470:20::2: icmp_seq=1 ttl=64 time=437 ms
64 bytes from 2001:470:20::2: icmp_seq=2 ttl=64 time=474 ms
64 bytes from 2001:470:20::2: icmp_seq=3 ttl=64 time=441 ms
64 bytes from 2001:470:20::2: icmp_seq=4 ttl=64 time=510 ms

--- 2001:470:20::2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 437.905/465.959/510.010/29.213 ms

Awesome. Right now you are probably thinking "I can't believe it was that easy!". Well, hold on there cowboy, it's not over yet. Right now our gateway is the only host on our network that can use IPv6, and it can't even resolve names to IPv6 yet.

We can fix name resolution very easily for now by simply adding an entry for HE's IPv6 DNS server to our resolv.conf file;

sudo vi /etc/resolv.conf

Add an extra nameserver line like so;

nameserver 2001:470:d:1018::1

Let's try pinging a name this time;

ping -c 4 ipv6.tuxnetworks.com
ping: unknown host ipv6.tuxnetworks.com

Oops, don't forget we need to use ping6 instead! Let's try it again;

ping6 -c 4 ipv6.tuxnetworks.com
PING ipv6.tuxnetworks.com(2001:470:c:1004::2) 56 data bytes
64 bytes from 2001:470:c:1004::2: icmp_seq=1 ttl=63 time=227 ms
64 bytes from 2001:470:c:1004::2: icmp_seq=2 ttl=63 time=332 ms
64 bytes from 2001:470:c:1004::2: icmp_seq=3 ttl=63 time=230 ms
64 bytes from 2001:470:c:1004::2: icmp_seq=4 ttl=63 time=227 ms

--- ipv6.tuxnetworks.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms

That's a whole lot better but there are still some things to be done. We will cover those in the next article.

Continue on to Step 3: LAN access and autoconfiguration

P.S. Don't forget that June 8 is IPv6 Day!

Getting Up To Speed With IPv6: Setting The Stage

This is the second article in my series on getting up to speed with IPv6. For the first article look here.

Ideally, to use IPv6 on your network your ISP will simply provide you with an IPv6 address and you will be good to go automagically. In practice, virtually no ISP's at this point are enlightened enough to do this which means we must go out of our way before we can reach the state of IPv6 Nirvana that we so desire.

Here is a list of ISP's that currently support IPv6.

The odds are that your ISP is not on that list.

As a first step, let's check our current IPv6 readiness using the online tool at http://test-ipv6.com/

Your test result will most likely look something like this;

That's OK though, we expected that.

Let's start by summarising the steps we must take to get IPv6 up and running on our networks (assuming our ISP does not provide it for us already).

1) A debian/ubuntu server operating as a IPv4 router.

2) Deployment of an IPv6 tunnel on our router.

3) Configure IPv6 network services for clients

And that is it, really. The first step will require a "non-routing" adsl or cable modem. If you have a typical modem+router[1] device it will need to be configured in "bridged" mode[2]. This can be done in various ways depending on what type of device you have[3]. For obvious reasons I will not be able to provide step by step instructions on how to go about this for every make and model router available, but I will give an example using the Netgear DG834G I use on my own network.

Once this is done, step two will prove to be surprisingly simple. There are numerous free and commercial "IPv6 tunnel brokers" to choose from out there however we are going to use the free service from Hurricane Electric[4].

The third step involves configuring multiple services to make your IPv6 network usable by hosts on your LAN. It will actually be a series of articles for different services.

Continue on to Step 1: Basic IPv6 Setup

P.S. Don't forget that June 8 is IPv6 Day!

[1] It is most likely that your current home network uses a cheap consumer grade "router" which is more accurately described as a "NAT gateway" as it does not do true routing.

[2] You cannot use IPv6 over IPv4 NAT.

[3] Alternately, if you are so inclined, you could also choose to hack the firmware on your existing "router" to use the open source "openwrt" Linux distribution which includes IPv6 support by default. I will not be describing this procedure in this series.

[4] Registration required.

Getting Up To Speed With IPv6: Introduction

With all the news about ipv4 address exhaustion going around not to mention that IPv6 Day is just around the corner I thought it was time that I investigate IPv4's successor, IPv6.

(If you are wondering whatever happened to IPv5 then look here)

The good old IPv4 address that we all currently know and love (and understand, I hope) is basically a 32 bit number divided into four 8 bit "octets".

That gives us a theoretical address space of 2^32 (4.3 billion) addresses.

On the other hand, IPv6 uses 128 bit address's represented as eight groups of four hexadecimal digits, each group representing 16 bits (two octets)

This new address space supports 2^128 (340 undecillion) addresses which is more than we will ever conceivably require on Planet Earth.

Right now you are probably thinking "Yeah, I've heard that before about 640K RAM and we all know how that one worked out" so to put the sheer size of the IPv6 address space into perspective let me quote an excellent IPv6 primer over at Ars Technica, "there are currently 130 million people born each year. If this number of births remains the same until the sun goes dark in 5 billion years, and all of these people live to be 72 years old, they can all have 53 times the address space of the IPv4 Internet for every second of their lives."

Now, I'm sure you'll agree, that is a lot of addresses.

For a good overview of how IPv6 addressing works, I recommend this article.

After reading up a bit about IPv6 you could be excused for concluding that the whole idea of IPv6 is quite daunting and then push the whole damned thing into the "too hard" basket. This is what most people and organisations have been doing up to this point and explains why adoption rates are currently so low.

ISP's in particular are putting off the inevitable by hoarding blocks of the remaining IPv4 space.

Don't be put off by the apparent complexity of IPv6 though!

In practice it is in fact not that hard to get up and running, even if you don't completely understand how it all hangs together at first. I still haven't figured it out properly, but soldier on I will!

As they say, practice makes perfect and this is the intention of the series of articles I will be posting on getting up to speed with IPv6.

Note: A word of warning, these articles are intended to be used for educational purposes only. Because we cannot use an IPv6 address range of our own we are going to be obtaining one through what is known as an "IPv6 Tunnel Broker". This is of course not an ideal situation because we are going to be relying on that broker for all of our IPv6 addresses and routing. I do not advise that you configure a production network for IPv6 connectivity using this guide as you will surely face performance penalties, possible reliability issues, and (most importantly) future migration issues when your ISP eventually starts providing you IPv6 directly. If you are intending to roll out IPv6 in a production scenario I suggest that you choose an ISP that is already providing native IPv6 to their customers.

Next up, Setting The Stage