Paul's Weblog

— RFC1305

Whilst running the blog's Atom feed through a feed validator, I discovered that I may have been unwittingly causing people problems by … using sane XML for the feed.

Having dutifully associated the Atom namespace with the atom: prefix that all appropriate tags had been given, it turns out that this is more than many aggregators understand, despite being barely above entry-level XML syntax. So, I've moved to the alternative ‘switch default namespaces as necessary’ approach, which is a bit like moving to a friend's house just so that you can say ‘home’ rather than ‘your place’.

Fortunately other people also feel this is an unsatisfying state of affairs, and there's a project already in place that identifies the offenders (which sadly include Safari and Thunderbird) and the standards-compliant tools (such as Firefox and IE7).

If you've been having problems with the Atom feed for this blog in the past, hopefully all should now work. Why not drop a line to your aggregator's developers and see if you can't get it fixed for all the others too?

Quick post: how to set up local DNS caching under Ubuntu. I sometimes find that there's a long delay when launching applications. Often this is just the system working hard to start them, but sometimes there's no load being generated whilst everything sits there for a couple of seconds.

It occurred to me that this might be due to a network timeout or sluggish response of some kind, and a quick look at the output of tcpdump proved that there was indeed a DNS query going on every time I launched xterm.

Rather than sit and wait for the DNS server to get back to me, I decided to install a local DNS server to cache responses. These instructions are a bit basic, but they should show you what needs to be done. Good luck!

• Have a look at what DNS you're getting a the moment.

  root@box:~# dig google.com | grep -A 1 Query
  ;; Query time: 146 msec
  ;; SERVER: 10.0.0.254#53(10.0.0.254)          
  

• Install the package.

  root@box:~# aptitude install dnsmasq
  

• Edit the server config to enable local serving.

  root@box:~# vi /etc/dnsmasq.conf
    [look for a line starting '#listen-address=']
    [remove that initial '#' and add '127.0.0.1']
    [result should be 'listen-address=127.0.0.1']
    [save file and exit]
  

• Add 127.0.0.1 to your list of nameservers.

  root@box:~# vi /etc/resolv.conf
    [insert a new first line that reads 'nameserver 127.0.0.1']
    [save file and exit]
  

• Every time DHCP gets a new lease, resolv.conf will be re-written. Edit the DHCP configuration to always add the local DNS server entry that we added in the previous step. (You might want to check that the last step hasn't been re-written whilst you've been doing this one.)

  root@box:~# vi /etc/dhcp3/dhclient.conf
    [find the line starting '#prepend domain-name-severs']
    [remove the initial '#' character]
    [line should read 'prepend domain-name-servers 127.0.0.1;']
    [save file and exit]
  

• Launch the server.

  root@box:~# /etc/init.d/dnsmasq start
  

• Check the local server is being used, and see how much faster it is.

  root@box:~# dig google.com | grep -A 1 Query
  ;; Query time: 0 msec
  ;; SERVER: 127.0.0.1#53(127.0.0.1)
  

For some time I've been tripping over the need to generate unique identifiers for things. I've always managed to avoid actually having to do so one way or another, but (to make a cliched paraphrase) "with great blog engine comes great responsibility": in order to generate an Atom RSS feed, I need to generate identifiers for each posts.

So far I've been expecting this to involve generating 128-bit UUIDs (as described in RFC 4122) using one of several algorithms, none of which are simple, and all of which seem much too involved when I'm simply trying to stop a feed aggregator confusing my posts.

All of this might explain why I was so happy to find a page describing how to generate a tag URI. Especially so when I realised there was an RFC for the procedure. I won't try to cover all the details they give there, but in a nutshell the procedure is approximately this

• Start off with 'tag:' .
• Add your e-mail address, or domain name if you have one.
• Add a comma, and follow that by the date in 2007-01-01 format.
• Think of a name which hasn't already been used for that combination of address/domain and date, and separate it from what's gone before using a colon.
• The end result might look like this: tag:pdw.org.uk,2007-05-16:Example
• Profit!

Hopefully you might find it useful (or at least informative). I know I will!

For more details, see http://www.taguri.org.

Well, it's finally happened. I've been getting along reasonably well with Nanoblogger for some time now, but a couple of things started to put me off.

Firstly, it is very slow indeed. I've only got a few posts up here, and I was having to wait for well over a minute for it to generate the blog. It might have been about three, but it was some time ago so don't quote me on that. Delving into the code, it looked like there were just a couple of hot spots, but they were getting very hot indeed.

Secondly, support for images in posts was, for me, rather awkward. The only way to include images in a post was to point to them with an absolute URL. For most people I can imagine this isn't a problem, but as it happens I like to view my blog from two places: via my main blog URL (where you're probably reading this from now), and from a secondary URL which gives me the option of previewing things before I release them. Obviously having the same link at different URLs isn't going to be easy, and although I'd patched round it using symlinks it wasn't pretty.

So, I decided that I wanted to keep the other key features of Nanoblogger — static pages, categories, no software dependencies other than bash, and a simple interface — whilst improving on the speed and flexibility. Needless to say, I've written the new engine from scratch, in bash, and it's both fast and portable. In fact, all the internal links are relative, and there's facility for including user content alongside the posts.

Atom, or possibly RSS 2.0, support will be along shortly, once I've had chance to digest the specification documents. In the meantime, hopefully this will mean that posts are slightly less infrequent.