Skip to content

ZFS adventures

For some time now I'm running MacOS X 10.6.2 with a 64-bit kernel and MacFUSE installed. However, after one of the last updates this setup stopped working - well, it shouldn't have worked anyway. Which is a pity, because now the TrueCrypt layer on top of MacFUSE doesn't work, which means ZFS cannot access its volume.
So, what now? Hacking MacFUSE would be the Right Thing to do, something I won't be able to deliver. So I went on to set up a much more fancy installation:
  • install VirtualBox and attach the disk as a raw blockdevice
  • within VirtualBox, install TrueCrypt and zfs-fuse
  • once the VM has access to data, export it via Samba, so that the host machine can access it

We start by registering our MacOS data partition to VirtualBox. We're setting the disk immutable for now as we don't want to let our guest VM to make any changes to it. And we're also chmod'ing the disk to 0644, so that we're able to read it (and thus use it in Virtualbox). Mode 0640 and a dedicated group would be more elegant, yes.
$ sudo VBoxManage internalcommands createrawvmdk -filename disk02-raw.vmdk \
          -rawdisk /dev/disk0s5 -register
$ VBoxManage modifyhd -type immutable disk02-raw.vmdk
$ sudo chmod 0644 /dev/disk0s5
We're using a Debian/testing (amd64) as a guest VM and we'll compile TrueCrypt (with wxWidgets as a dependency):
$ apt-get install libfuse-dev fuse-utils dmsetup pkg-config samba git-core scons\
   libaio-dev libattr1-dev libacl1-dev libz-dev libz-dev libfuse-dev libssl-dev bzip2

$ wget \
   -O - | tar -C /usr/local/src -xjf -
$ cd /usr/local/src/wxWidgets-2.8.10
$ ./configure --prefix=/opt/wxWidgets && make && make install

$ mkdir /usr/local/include/pkcs11
$ cd /usr/local/include/pkcs11
$ for i in pkcs11 pkcs11f.h pkcs11t.h; do
$ cd /usr/local/src/truecrypt-6.3a-source
$ make NOGUI=1 WX_ROOT=/usr/local/src/wxWidgets-2.8.10 wxbuild
$ PKCS11_INC=/usr/local/include/pkcs11 make NOGUI=1 WXSTATIC=1
$ mv Main/truecrypt /usr/local/sbin/
Now we should be able to access our Truecryt volume:
$ truecrypt --text --filesystem=none /dev/hdc
$ file -s /dev/mapper/truecrypt1
/dev/mapper/truecrypt1: Macintosh HFS Extended version [...]
We can set up ZFS now:
$ git clone
$ cd zfs/src && scons && scons install install_dir=/opt/zfs-fuse-rainemu
$ export PATH=$PATH:/opt/zfs-fuse-rainemu
$ zfs-fuse --pidfile /var/run/
$ zpool import -d /dev/mapper -a -f

$ zfs list
tank0   135G  16.4G   135G  /tank0
Now we will be able to export /tank0 via Samba (or NFS, if needed) and can access it from our host machine as well. While surely not as speedy as local HFS+ (although I haven't actually measured yet), it's enough for watching movies or storing pictures. And apparently ZFS on Linux is much more stable and tested than on MacOS X. Well, to be honest, with this setup I could now even replace Truecrypt with dm-crypt and zfs with a stable filesystem, but that wouldn't be so much fun, eh? :-)


Today I found out that I have 3 leftover realmedia files in my archive. Sure, VLC can play this, but why not just converting them to something more useful? I haven't used mplayer in a while and I still did not find a way to redirect its output to stdout (no, file=/dev/stdout did not work either). Using a FIFO was the way to go here:
$ mkfifo foo
$ oggenc -q 6 foo -o file.ogg &
$ mplayer file.rm -vc null -vo null -ao pcm:fast:file=$HOME/foo

munin: add timezone to timestamp on html pages

That's what I was looking for. Until our distribution of choice includes this fix, we can use:
--- /usr/share/munin/munin-html.orig    2010-01-26 19:22:09.000000000 +0100
+++ /usr/share/munin/munin-html 2010-01-26 19:26:59.000000000 +0100
@@ -311,7 +311,7 @@ foreach my $file( (@files) ) {
 #make domain list
 my @domainlist = map { { DOMAIN => $_ } } @domainorder;
-my $timestamp = strftime("%Y-%m-%d T %T", localtime);
+my $timestamp = strftime("%Y-%m-%d T %T %z", localtime);
 for my $domain (@domainorder) {
     logger("processing domain: $domain");
     my %domain;


Whadayaknow, our shell of choice still has its limits:
# echo $((2**63-1))

# echo $((2**63))

# file $SHELL
/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) [...]
Zsh seems to have the same limit; ksh93 does:
ksh93$ echo $((2**1023))

ksh93$ echo $((2**1024))
And csh seems to need some magic to do exponentiation at all.

Security theater has come to town!

I always wondered what the blogosphere was babbling about regarding the shiny new security measures recommended by the TSA. Well, now I know what Security theater feels like: half-assed "everything must be checked" searches for everyone boarding a plane to the US.

So there are two security checks at LHR now: the first one is the usual metal detector and hand-baggage scanning, with random individual checks which takes about a minute per person. The other one is *at the gate*, starts at boarding time (expect major delays!) and takes 3-5min per person. Yes, these are made-up numbers, since TSA's Wait Time Calculator is out of order at this time, probably due to unforseen security checks. And "half-assed", because the search drones are trying so hard to do as instructed in their classroom, that they're looking diligently at laptops and little baby-bottles, as if they could spot "dangerous looking items" with their bare eyes.

And even if they found something: will the security guys from the first checkpoint be fired then? Why not? FYI, neither of them found the matches in my hand luggage - and yes, I must've left them there by accident, I did not study their Airport Screening Manual that was leaked some time ago :-)

Welcome to the future!

Oh, what a nice way to begin the new year: apparently, all incoming mails are tagged with FH_DATE_PAST_20XX, meaning:
  The rule matches the year (a string of four numbers) in the Date header,
  and checks if it is between 2010 and 2099. 
...which is a silly thing to do in 2010 :-) This has been fixed upstream a few months ago, our distribution of choice is already on it.