return to OCLUG Web Site
A Django site.
September 16, 2010

Bart Trojanowski
Bart's Blog
» distributing DNS list through radvd

If you have an IPv6 Linux network at home, you probably have a Linux host on the perimeter that's running radvd -- this is the server that responds to IPv6 neighbour discovery (ND) requests, distributes the default route to all your hosts, and tells your hosts how to auto configure themselves.

All these tasks were handled by the DHCP server, albeit a lot differently, in the good old days. The one other thing that dhcpd did for us was to tell all the hosts where the DNS servers were.

So, do I need to run the IPv6 version of dhcpd AND radvd?

[Read More]

September 8, 2010

Bart Trojanowski
Bart's Blog
» Canadian ipv6 drought

Apparently there is a huge shortage of Canadian registrars that can provide full ipv6 support. The only one I was able to find is, which despite it's TLD operates out of Victoria, BC. I haven't switched yet, because while they support ipv6 glue records for .ca, they don't for .net yet.

Here is the discussion on where it was mentioned.

October 16, 2009

» Blogrotate #2: The Weekly Roundup of News for System Administrators

Welcome to week 2 of Blogrotate. It was a short week due to Thanksgiving (Canada) and Columbus Day (US), but the world of IT is always buzzing. So as they say at the race track, pitter-patter, let’s get at ‘er.


Have you ever wondered how much trouble can be caused by a single typo? This week a single typo in a script to update all zone files for the .se (sweden) TLD (top level domain), dropping the entire .se domain off the internet for almost 2 hours. Royal Pingdom has the full story in “Sweden’s Internet broken by DNS mistake”. This is why we need tight controls on change management. It’s called testing guys. Sweden. Give me a call.

Facebook now has 30,000 servers and produces 25TB (that’s tera-byte kids) of log data per day. The Data Center Knowledge site has some interesting details in “Facebook now has 3000 Servers”.


Lot’s of buzz this week about T-Mobile’s service disruption and subsequent loss of users data. Discussion over whether the problem was a cloud failure or not was one hot topic. Data Center Knowledge discussed it here in “The Sidekick Failure and Cloud Culpability”. Ars Technica had some more on the cloud debate with “T-Mobile and Microsoft/Danger data loss is bad for the cloud”. It looks like most or all users will have lost their data due to the lack of backups, see “Some Sidekick Users May Recover Data” for more. I am sure there will be more fallout from this one.

Enterprise Storage Forum has an interesting evaluation of the limitations of cloud computing for corporations, specifically due to bandwidth limitations and hardware error rates. See Henry Newman’s article titled “Why Cloud Storage Use Could Be Limited in Enterprises”.

Nate Anderson over at Ars Technica has an interesting read about fear mongers who say our beloved intertubes are going to die in “The Internet is about to die. Literally die!”.

Operating Systems

IT Wire claims “Microsoft teams up with Family Guy to sell Windows 7″. That’s just sad. If they are going to glorify Windows then I really can’t see how they can funny it up. I am guessing Seth will get to pan Microsoft just to spread word that Windows 7 is coming.

VMWare has announced that their new “VMware Fusion will support Windows 7 in more Mac-like way” says IT Wire. This “Unity” feature looks a lot like VirtualBox’s “seamless” mode. Check out the You Tube video “Unity in VMware Fusion for Mac OS X” to see it in action.

Jim Zemlin, the executive director of the Linux Foundation gave the keynote address at the Maemo Summit and said that he thinks Linux could be the dominant OS for mobile phones and devices. Ars Technica has more in “Will Linux be the dominant OS for consumer electronics?”.

And from the wicked cool idea department

An interesting study from McCormick University on using your PC’s existing hardware as a sort of sonar to detect when you are there. See “Research Group Uses Sonar for Computer Power Management”. They plan to use this as a method of detecting if you are close to your computer and to turn off your screen if you are not, then turn back on again when you return. The group is currently looking for guinea pigs testers to evaluate if there is any real world power savings. The link to the software is in the article. Hey, if my TV remote control can do it, why not a laptop?

That’s all we’ll have time for this week. Come back again next week for more Blogrotate and, as always, feel free to speak your mind or post your interesting stories in the comments.

June 18, 2009

» Ubuntu 9.04 (Jaunty Jackalope), vpnc, and resolvconf

The environment

  • Ubuntu 9.04 Jaunty Jackalope
  • vpnc 0.5.3
  • resolvconf 1.43

The problem

Connecting to a cisco vpn device with vpnc on jaunty. If you use vpnc and vpnc-disconnect to bring the connection up and down, all works fine. If you leave the connection idle too long and are disconnected from the other end, the resolv.conf is not always updated. This is a problem because, when you do a DNS lookup in a browser you’ll experience delays, the DNS servers from your vpn connection are no longer available.

The easiest way to check this is to login to your vpn and check the contents of /etc/resolv.conf. For example, before you log in, your resolv.conf may look something like this (only the IPs have been changed to protect the innocent).

# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)

After connecting, you’ll see a different resolv.conf.

# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)


It would be easier to see with real IPs, but the vpnc daemon adds two more servers, and sometimes changes or adds the search domain. This is great—the first DNS servers you will lookup against on your vpn connection are those for the vpn, which makes it easier to resolve IPs on the corporate network.

The trouble begins when the connection times out. vpnc is very good about cleaning up its routing tables, but for some reason it does not always fix the resolv.conf as it should. This is because vpnc is not telling the resolvconf package to remove the config for the tunnel device.

Interlude: resolvconf

resolvconf is a package used primarily by the system to manage the name server information in /etc/resolv.conf dynamically. It replaces the old static resolv.conf file. Before moving to jaunty, I was using 8.04 Hardy Heron, and still do at work. The addition of resolvconf seems to coincide with the rise of network-manager for managing network interfaces in Linux. They work great when they work, but when problems arose, the old methods were much less confusing.

Networking utilities wishing to make use of resolvconf will drop a file into the /etc/resolvconf/run/interfaces directory. resolvconf will then combine this with other base files (located in /etc/resolvconf/resolv.conf.d) to create /etc/resolvconf/run/resolv.conf. This file is symbolically linked to /etc/resolv.conf.

So to make things clear, resolvconf will:

  • Take the base config files from /etc/resolvconf/resolv.conf.d:
    # ls -al
    total 16
    drwxr-xr-x 2 root root 4096 Apr 26 23:18 .
    drwxr-xr-x 6 root root 4096 Apr 26 23:18 ..
    -rw-r--r-- 1 root root    0 Aug  9  2006 base
    -rw-r--r-- 1 root root  151 Aug  9  2006 head
    -rw-r--r-- 1 root root  116 Apr 26 22:06 original
    -rw-r--r-- 1 root root    0 Apr 26 23:18 tail
  • Combine them with the information for each interface in /etc/resolvconf/run/interface;
    # ls -al
    total 16
    drwxr-xr-x 2 root root 4096 Jun 15 22:10 .
    drwxr-xr-x 3 root root 4096 Jun 15 22:48 ..
    -rw-r--r-- 1 root root   87 Jun 10 23:04 NetworkManager
    -rw-r--r-- 1 root root   91 May 23 21:41 eth0
  • Output one happy DNS configuration in /etc/resolvconf/run . . . 
    # cat resolv.conf
    # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  •  . . . which is a symbolic link to /etc/resolv.conf
    # ls -al /etc/resolv.conf
    lrwxrwxrwx 1 root root 31 Apr 29 16:06 /etc/resolv.conf -> /etc/resolvconf/run/resolv.conf

There you go—clear as mud.

End Interlude

So you have been disconnected from the vpn. If you look in /etc/resolvconf/run/interface, you will see a file left around from the session. For example, if your vpn connection is interface tun0 (which mine always is), there will be this file.

ls -al /etc/resolvconf/run/interface
-rw-r--r-- 1 root root   91 Jun 15 21:41 tun0

All this information just to get to . . . 

The workaround

The workaround for this is simple. resolvconf can be used from the command line to add, remove, or update this information, on the fly. In this case, we want to remove an interface. You’ll need to know what the interface for your vpn tunnel is. tun0 is the most common with vpnc, but if you are not sure, you can consult the /etc/resolvconf/run/interface directory as shown above and check the file name. Once you have that, the solution is simple.

# sudo /sbin/resolvconf -d tun0

Replace tun0 with your interface if it’s different.

Scheduled workaround

It occurred to me that if I need to do this, it’s annoying to do it by hand every time. Since vpnc is not cleaning up after itself, it makes sense to do the cleanup automatically. We can do this using a cron job. For ease of use, I will add this to /etc/crontab file as root, because the vpnc scripts need to be run as root to work.

sudo vi /etc/crontab

Note: As we all know I prefer vi from the command line, but you can use any old editor that you want, providing you are running it with root credentials so that you can write to the crontab file.

Now you need to add this line at the bottom of the file (allowances must be made here for paths, this works on my Ubuntu system). For the sake or argument, we’ll run this every 10 minutes.

*/10 * * * * root if [ -e /etc/resolvconf/run/interface/tun0 -a "`pidof vpnc`" == "" ] ; then /sbin/resolvconf -d tun0; fi

What this does, is checks to see if the tun0 file exists, and if it does, it will run the command to remove it, which will then regenerate the resolv.conf and remove the bad DNS information.


I know this was a lot of ’splaining for a simple one-line fix, but having worked through this from scratch, I thought it might interest someone to see the process.

There is an open bug on this issue, and you can find it here: “vpnc does not always call resolvconf -d on termination. This bug has been around for a couple of versions now. The vpnc project home page also states in its known bug list, “vpnc looses [sic] connection with some targets, even before the rekey-timer expires most probably due bugs with keepalive, dead-peer-detection or something else,” which may be the cause of this issue, because if the session does not die cleanly, it may also not clean up properly.

I have downloaded the source and straced my last session, so I may try my hand at fixing it myself. An initial look at it yielded no results, but I have not worked with C in many, many years, so it will take time. If you would like to help fix this bug check the bug report or contact the maintainer.

Till next time.