“A nearly impenetrable thicket of geekitude…”

Man with hat.

Hi. My name is Ian Young, and this is my web site. Look around; make yourself at home. You can find out more about me or about the site, read my blog, look at some of my photography and greetings cards, or some of the software I’ve written; whatever takes your fancy.

Static Site Performance

It has been a month now since I finished my Nanoc conversion work, and it’s pretty obvious from the chart below that the performance improvements I expected from converting to a static site are real, and are here to stay.

chart of access times

The chart is from Google’s search crawler, so it doesn’t represent real human usage, but the dramatic lowering of the access times since the beginning of February is undeniable. Previously, if you got unlucky, you might have waited more than a second for even one of my pearls of wisdom. Now the most banal observations might be available in mere milliseconds.


Overlays with rsync

I’ve been using rsync to build my site as a combination of a base layer held in git plus an overlay generated using Nanoc. Here’s how.


Always HTTPS

This site is going all-HTTPS, all the time. Read on for background and details.

[2018-03-11: HSTS implemented with max-age=1800, i.e., 30 minutes.]


I have completed the migration work started back in December. As a result, this site is now entirely constructed using the Nanoc static-site generator, and the Drupal content management system has been retired.

If you’re reading this through a feed reader like Feedly, please drop me a line to let me know that the new feeds are working.

Continue reading for some thoughts on the process and on the results.


Cleaner URLs

One thing I’ve wanted to do for a long time is move this site further towards the use of clean URLs. I am currently migrating to a static-site generator and that seemed like the ideal time. Here are a couple of tricks I’ve used to get clean URLs for my older content without breaking bookmarks.


Drupal and Nanoc

I started using Drupal to manage most of this site a little under six years ago. That wasn’t a mistake — it solved the problems I wanted to solve at the time — but it hasn’t been an unqualified success either. It’s time to move on to the next thing, which for me looks like Nanoc, a static-site generator written in Ruby.


REEP Key Ceremony

The key ceremony for the REEP service took place on 2014-05-18 after the REFEDS meeting in Dublin, Ireland.

I witnessed this ceremony and was convinced that the key attached to this post as a self-signed X.509 certificate was generated during the ceremony within the hardware security module in Sweden that will be used by the REEP service to sign metadata served by it. To certify this, I have generated a detached signature file for reep.pem using my PGP key.

To the extent that you trust me to have taken care while witnessing the ceremony, you may find that validating my signature on reep.pem gives you some comfort that metadata documents signed by the private key associated with reep.pem are, indeed, legitimate outputs of the REEP service.

As an aside about the ceremony itself, proof that a particular computational event has occurred in a particular way is almost impossible in a world of networking and virtual machines. We’ve known this for a long time: the paranoia goes back at least as far as Ken Thomson’s Reflections on Trusting Trust. We’re not quite living in The Matrix, but the evidence of ones senses doesn’t really go very far towards absolute proof. So what the other witnesses and I did during the ceremony — all we could do, really — was gain confidence by asking questions, taking photographs of the steps and trying to think of ways to validate them. For example, I was later able to verify that the pkcs11-tool command being used was indeed the one which would be installed on a system running 64-bit Ubuntu 12.04. Unless, of course, Leif foresaw that trick and subverted the md5sum command as well. It’s turtles all the way down.

UK federation Metadata Aggregation

One of the systems I work on is the back end of the UK federation’s metadata system. Although I’ve talked about this in several presentations, the bare structural diagram isn’t very informative on its own. Here, I present a snapshot of the architecture, and go into a lot more depth on the what, how and why than you’d get from just the slide on its own (click on the image to get a larger version).

I hope that this article can perform double duty as a case study for the Shibboleth metadata aggregator tool, which acts as the engine behind the metadata system and to which I also contribute as a developer.