Skip to main content


After starting to run a Tor node, the Hulu GeoFilter thinks I'm trying to access their content from outside the U.S. As their GeoFilter issues form was having difficulties finding out where I was connecting from, they advised to send an email to, but I've haven't heard back from them ever since. That's a pity, now I can't watch their shows any more. Also, they've taken the Daily Show off their program, which is basically the only show I've watched over there. So, it's off to Bittorrent-World for me now; maybe we meet again when you fix your GeoFilter?


It's 2010 and I can't even print a "blank line" in Windows without looking up the manual:

To echo a blank line on the screen, type:

Why can't they just include this remark into "help echo", hm?

Verizon Internet Services

Last night I was trying to contact Verizon to report an abuse case:

$ whois | egrep 'Name:|Email'
OrgName:    Verizon Internet Services Inc. 
NetName:    VIS-BLOCK
OrgAbuseName:   VIS Abuse 
OrgTechName:   Verizon Internet Services 
Today, I see that the OrgAbuseEmail has been changed to and when Cc'ing my MTA returns:
 > The message has not yet been delivered to the following addresses:
 > host[]:
 > connection to mail exchanger failed with timeout
 > host[]:
 > connection to mail exchanger failed with timeout
Oh well....

$ date
Thu Mar 11 04:46:26 CET 2010
$ whois | grep OrgAbuseEmail
OrgAbuseEmail: Are they changing their abuse contact every day now?

rename %ProgramFiles%

Wow, another entry covering some Windows oddity. One might think this OS is full of oddities :-) This time I tried to rename c:\program files because I wanted to mount another disk to c:\program files. Sure, lots of programs might be running from c:\program files, but when I stop all these programs, WindowsXP should still be able to boot and even start RDP to let me login, right? And so it did, with a few preparations made:

  • C:\Program Files cannot just be renamed - WindowsXP won't let you, it's some kind of magic special folde^Wdirectory. We'll use regedit to modify two keys:

    Set HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir to something else, e.g. "C:\Program Files2" While this gets exported as "%ProgramFiles%" via "ProgramFilesPath", we have to edit another key:

    Set HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CommonFilesDir to something else, e.g. "C:\Program Files2\Common Files". We have to reboot to apply these changes, of course :-)

  • After the reboot, we should be able to rename c:\program files to something else. You might notice that our interim %ProgramFiles% directory got filled with a few directories - just ignore them. With our original c:\program files our of the way, we create an empty c:\program files, where we can now mount the other disk. Once this is done, we can start moving the our original c:\program files content (that we just moved out of the way) into our new c:\program files directory. While it's moving, we can set the registry keys we changed (see above) back to its original values.
Now reboot to get the registry settings applied and all should be well again - except that our c:\program files has now plenty of space :-)

Extended Attributes and ACLs

Often enough I confuse them myself, so here's a little cheatsheet for you^Wme to remember:


ACLs are extending the traditional permission model with a more fine-grained one.
  • - getfacl, setfacl - filesystem independen access control list manipulation
  • - chacl - an IRIX-compatibility command
$ chacl u::rw-,g::r--,o::r--,u:dummy:--x,m::r-x file.txt
$ chacl -l file.txt 
file.txt [u::rw-,u:dummy:--x,g::r--,m::r-x,o::r--]
$ su -c "cat ./file.txt" dummy 
cat: ./file.txt: Permission denied

$ setfacl -m u::rw-,g::---,o::---,u:dummy:r--,m::r-x file.txt
$ getfacl file.txt 
# file: file.txt
# owner: root
# group: root


Extended attributes are arbitrary name/value pairs which are associated with files or directories.
  • setfattr, getfattr - filesystem independent extended attribute manipulation
  • attr - aimed specifically at users of the XFS filesystem
$ attr -q -s foo -V 42 file.txt 
$ attr -g foo file.txt 
Attribute "foo" had a 3 byte value for file.txt:
$ setfattr -n -v 23 file.txt
$ getfattr -n file.txt
# file: file.txt"23"

file attributes

These "file attributes" look like they were meant to be supported by the ext2/3/4 filesystems only. However, Btrfs, JFS and XFS support them as well, ReiserFS and Reiser4 do not. In fact, I haven't found a mount option for Reiser4 yet to support ACLs and EAs either :-\
# chattr +i file.txt 
# lsattr file.txt
----i-------------- file.txt
# rm -f file.txt 
rm: cannot remove `file.txt': Operation not permitted

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? :-)