Trying to think of the simplest useful example I could of stringing together nifty Plan 9 features without writing any code. Simple as it gets: using the archival file system to present a browseable cache of the past of a living web site under active development.

I work on our corporate site in my Plan 9 home directory, located in the [locally] centralized, site-wide file system at /usr/josh/web/un. This location is available to a web browser at http://plan9.utopian.net/un/ (a URL visible only on our local network right now - sorry). That URL represents the current site - at most one development step ahead of what you see in production at Utopian.net.

The Plan 9 OS running on the machine imaginatively called plan9 makes an archive `copy’ of the entire file system each morning at 6. This archive is accessible, by convention, at /n/dump, organized beneath in directories named by date, like YYYY/MMDD. Each date contains the entire file system as it existed at that point in time.

When combined with Plan 9’s per-process name spaces, this affords a simple way to show the archive in a `live’ way in a web browser. (This post doesn’t touch on the system’s tools to automate archive audits, like history(1) and yesterday(1).)

Instead of keeping multiple copies of old versions of the site, all duplicated within the server’s document root, we can just bind(1) the relevant files from whatever desired date in the dump.

The file /lib/namespace.httpd contains the name space definition for the web server, httpd(8). I added:

   mount #s/boot /n/dump main/archive

to bind the dump filesystem into the web server’s name space, making files in the dump accessible to httpd. Then:

    bind /n/dump/2008/0201/usr/josh/web/un /usr/web/un/archive/2008/02
    bind /n/dump/2008/0301/usr/josh/web/un /usr/web/un/archive/2008/03
    bind /n/dump/2008/0401/usr/josh/web/un /usr/web/un/archive/2008/04
    bind -b /usr/josh/web/un /usr/web/un

The first line makes the Feb 1 backup snapshot of my /usr/josh/web/un development directory available to the httpd process at /usr/web/un/archive/2008/02. With the web server’s “document root” at /usr/web, this path becomes the URL: http://plan9.utopian.net/un/archive/2008/02/.

The last line makes the current version of the directory visible at http://plan9.utopian.net/un/. Passing the -b option to bind(1) makes the bound file appear before any files it duplicates in the union of files created at the mount point /usr/web/un.

While most of the mentioned URLs are only accessible on our local network, another thing the Plan 9 dump makes easy is grabbing a version of the site from any point in time. So you can visually diff the example I’ve put up here, say February 1’s version of /services against the live Utopian.net services page.

Inferno® is a language runtime-cum-operating system from Vita Nuova®. Inferno was originally developed at Bell Labs, and shares fundamental design concepts with Plan 9®. Namely: 1) files as a basic and consistent unit of naming; 2) a unified and unifying file-oriented network protocol, and 3) the ability to customize into a useful perspective files as per-process (in turn, per-user, per-machine, per-site…) name spaces.

Inferno novitiate via URL:

• Caerwyn’s Inferno Programmer’s Notebook is indispensable for the “So what can you do with it?” questions.
• The official site linked above has Inferno - The Manual.
• Brian Kernighan is unfailingly clear, concise, and revelatory. His paper takes an introductory Descent into Limbo, the native Inferno type-safe language.

WordPress uses a wad of apache rewrite rules to implement “pretty” URL permalinks, a synthetic hierarchical path interface to the blog. This set of near-equivalents for lighttpd url.rewrite makes WordPress URLs work as discernible paths like tag/lighttpd/, rather than revealing the underlying numerical arguments to index.php.

Replace the example’s /wplt/ with your WordPress base URL (often /):

# Wordpress rewrites transliterated for lighttpd
# tested 1.4.13(debian)
# In /wp-admin|Preferences|Permalinks set format string:
#    /%year%/%monthnum%/%day%/%postname%/
#
url.rewrite = (
"^/wplt/(wp-|images)/{0,1}(?!no.css)(.*)" => "$0",
"^/wplt/page/([0-9]+)/?$" => "/wplt/index.php?paged=$1" ,
"^/wplt/([0-9]+)/?([0-9]+)/?$" => "/wplt/index.php?m=$1$2" ,
"^/wplt/([0-9]+)/?([0-9]+)/?([0-9]+)/?$" => "/wplt/index.php?m=$1$2$3" ,
"^/wplt/([0-9]+)/?([0-9]+)/?([0-9]+)/?(.*)$" => "/wplt/index.php?m=$1$2$3$4" ,
"^/wplt/(.+)/([0-9]+)/[^/]+/?/feed/(feed|rdf|rss|rss2|atom)/?$" => "/wplt/index.php?category_name=$1&p=$2&feed=$3",
"^/wplt/(.+)/([0-9]+)/[^/]+/?/(feed|rdf|rss|rss2|atom)/?$" => "/wplt/index.php?category_name=$1&p=$2&feed=$3",
"^/wplt/(.+)/([0-9]+)/[^/]+/?/page/?([0-9]{1,})/?(.*)$" => "/wplt/index.php?category_name=$1&p=$2&paged=$3$4" ,
"^/wplt/(.+)/([0-9]+)/[^/]+/?([0-9]+)?/?$" => "/wplt/index.php?category_name=$1&p=$2&page=$3" ,
"^/wplt/(.+)/([0-9]+)/[^/]+/?/trackback/?$" => "/wplt/index.php?category_name=$1&p=$2&tb=1" ,
"^/wplt/feed/(feed|rdf|rss|rss2|atom)/?$" => "/wplt/index.php?feed=$1" ,
"^/wplt/(.+)/feed/(feed|rdf|rss|rss2|atom)/?$" => "/wplt/index.php?category_name=$1&feed=$2" ,
"^/wplt/(.+)/(feed|rdf|rss|rss2|atom)/?$" => "/wplt/index.php?category_name=$1&feed=$2" ,
"^/wplt/category/(.+)/?$" => "/wplt/index.php?category_name=$1" ,
"^/wplt/([_0-9a-zA-Z-]+)/?(.*)$" => "/wplt/index.php?page_id=$1$2" )

(Note that Labs/blogs is running apache httpd as of 2008/02/01, because I found it easier than creating something to generate lighttpd rewrites for wpmu blogs.)

When there’s work I want to do for no good reason, there’s nothing I like better than finding someone has already done it. With what I call the web shell, I read the incipient article well after it was written, and decided I wanted a command-style search-&-shortcuts page for my browser.

The lucky part: Russ Cox wrote just the thing about a year ago. That meant my contribution consisted of re-naming and merely customizing the javascript source.