Some may argue well, that’s the way it is, Apple decided this is the best way of doing things, you need to accept it and move on. Why do that, when fixing it the way you want it is a couple of seconds away?

If you want to be able to right-click a file in Finder in order to add it as an attachment, this is what you need to do:

1. Start Automator
2. Choose the Service template
3. In the dropdown boxes that appear choose “files or folders” and “Finder”
4. Click the Mail application in the Library tree
5. Drag the “New Mail Message” to the workflow area
6. Save the new service (the name of the workflow will appear in the context-menu)

That’s it! The new action should appear at the bottom when you right-click a file in Finder.

Finding a storage service provider

First off I needed to find someplace where I could upload my files. The most obvious choices were Dropbox, SpiderOak or one of the alternatives found here: http://alternativeto.net/desktop/dropbox/. Even though some of the clients were possible to setup without a GUI and provided Linux clients, they did so for the x86 or x86_64 architecture. The problem is that the Bubba|Two runs Debian on a PPC architecture which I couldn’t find any single client for. Needing a proprietary client was kind of annoying anyway so I started looking for alternative solutions such as backing up over Rsync, Scp, Ftp or WebDav. I finally found two providers allowing me to connect to my storage area using WebDav: Humyo and BingoDisk. During my, not that scientific tests, I had better luck with performance on Humyo and as they were the (minimally) cheaper alternative I opened a trial account there.

Setting up the storage access

In order to access the storage using webdav we need a webdav client. Preferably the client should allow for easy mirroring of an entire directory of files. The natural choice would be the webdav FUSE filesystem davfs2. FUSE stands for file system in user space and allows developers to implement file systems that can be accessed from userspace with FUSE rather than being implemented in the Linux kernel. There are today several great FUSE filesystems such as davfs2, sshfs, ftpfs, encfs and many many more. Once the file system is mounted it appears as any other file system. FUSE also allows for file system chaining so that encfs can run on top of eg. davfs2 to provide file encryption on top of a remote WebDav file system.

The davfs2 package exists in both Debian and in Ubuntu but unfortunately with old versions which I had some trouble getting to work with Humyo. The problem I was experiencing was that all uploaded files would be of zero size and empty. This was solved as soon as I installed a more current version (1.4.1). As the upcoming Ubuntu Karmic release ships with this version I used the package source to build a new package for my Bubba|Two which worked out great. This is what I did:

Preparing the build environment

First off I needed a compiler and build environment to build from source, I installed it by issuing the following command:

sudo apt-get install build-essential make gcc

Then the davfs2 package requires libneon to build. In order to install this I did:

sudo apt-get install libneo26-gnutls-dev

Downloading the source code

Once these prerequisites were in place I downloaded the source code, decompressed it and patched it using the following:

mkdir $HOME/src
cd $HOME/src
wget http://archive.ubuntu.com/ubuntu/pool/universe/d/davfs2/davfs2_1.4.1.orig.tar.gz
wget http://archive.ubuntu.com/ubuntu/pool/universe/d/davfs2/davfs2_1.4.1-1.diff.gz
tar xvzf davfs2_1.4.1.orig.tar.gz
zcat davfs2_1.4.1-1.diff.gz | patch -p0

Building the package from source

Now we can start to build the package by issuing:

cd $HOME/src/davfs2-1.4.1
chmod +x debian/rules
sudo debian/rules binary

This should give us a complete deb package in the parent directory ($HOME/src). The name of this package depends on the architecture which it was built for, in my case the name was: davfs2_1.4.1-1_powerpc.deb

Installing the package

The package can be installed by issuing the following command:

sudo dpkg -i $HOME/src davfs2_1.4.1-1_powerpc.deb

Setting up davfs2 to access Humyo

With the davfs2 package installed we now have to do some minor changes to a couple of files in order to mount the file system without the need for root access and prompting for credentials. Also as Humyo doesn’t seem to support file locking, we need to disable this to in order to avoid a warning each time we mount a file system.

Adding your Humyo username and password to davfs2

In order to add our credentials to davfs2 we need to add the following file to the /etc/davfs2/secrets file:

https://dav.humyo.com        ” ”

So if your username is foo@bar.com and your password is foobar the line should look like this:

https://dav.humyo.com    foo@bar.com    ”foobar”

Don’t forget that the server should be accessed over SSL, hence the https://dav.humyo.com

Disabling file locking

As Humyo doesn’t support file locking we need to disable this in order to remove the annoying warning each time a file system is mounted. This can be done either on a per-system, per-user level or in a custom configuration file. As I’m not running any other WebDav file system on the server I changed this in the global /etc/davfs2/davfs2.conf file. Consult the mount.davfs manual page (man mount.davfs) for information how this can be changed on a per-user or in a custom configuration file. To change it on a per-system level set the use_locks option to 0 (zero) in the /etc/davfs2/davfs2.conf file.

Importing the SSL certificate

We’re now almost all set to mount the remote WebDav file system. However, if you try to mount the file system now, you would most likely get the following message:

/sbin/mount.davfs: the server certificate is not trusted
issuer:      US, New Jersey, Jersey City, OptimumSSL CA, OptimumSSL CA
subject:     OptimumSSL Wildcard, Domain Control Validated, OptimumSSL Wildcard, Domain Control Validated, *.humyo.com
identity:    *.humyo.com
fingerprint: bf:28:74:8e:63:96:bf:07:9d:99:ed:f7:bf:44:cc:ad:f8:7b:c6:a7
You only should accept this certificate, if you can
verify the fingerprint! The server might be faked
or there might be a man-in-the-middle-attack.
Accept certificate for this session? [y,N]

The error occurs due to OpenSSL not being able to verify the SSL certificate chain. In order to get rid of this message we need to provide davfs2 with the root certificate. We do this by issuing the following command:

wget -O - "https://support.comodo.com/index.php?_m=downloads&_a=downloadfile&downloaditemid=10" | \
sudo tee /etc/davfs2/certs/addtrust_ab.pem

Then we need to instruct davfs2 to read this pem file when mounting our file system by adding the following line to /etc/davfs2/davfs2.conf:

servercert /etc/davfs2/certs/addtrust_ab.pem

So, now we should be all set!

Creating a mount point and adding it to fstab

We’re now ready to create a mount point. I chose to mount my Humyo storage to /mnt/humyo. In order to be able to do this I created the directory by issuing:

sudo mkdir /mnt/humyo

Once we have the mount point in place we can try to mount our file system by issuing the following command:

sudo mount -t davfs https://dav.humyo.com /mnt/humyo/

If all went well we should not have gotten any error messages and we can test whether it works by copying any file to /mnt/humyo. You can check whether the file actually made it to Humyo by checking their web interface. If it works your good to go, if not well, you need to start checking what went wrong.

Adding the mount point to fstab

The current setup only allows root to mount the file system and requires you to issue the above command to do so. In order to allow users to mount the file system you need to add a line into /etc/fstab.

https://dav.humyo.com    /mnt/humyo    davfs    user,noauto,rw    0    0

If you want the file system to be mounted at boot change the noauto to auto instead.

I got some creative suggestions such as: “Well, don’t use nano use vi/emacs/pico instead”. Those are all great suggestions but I still wanted to solve the problem with nano as it’s installed on all of my systems, and I find myself using it a lot.

Doing some Googling I came up with one solution, which I wasn’t entirely happy with as it involved changing the TERM settings on the remote computer. This isn’t all bad but I wanted to try to find a solution that actually just affects  nano rather than every other program that uses the TERM environment variable. For those of you that don’t consider this to be a problem you can simply place the following in your .bash_profile or equivalent file.

export TERM=xterm

By studying the /etc/nanorc I immediately found something interesting which turned out to be a better solution:

## Fix Backspace/Delete confusion problem.

set rebinddelete

In order to set this option for everyone on the system it needs to go in /etc/nanorc, however for me it’s sufficient to fix it for my own accounts. This can be done by issuing the following command:

echo "set rebinddelete" >> $HOME/.nanorc

Now, the next time you start nano the backspace should behave as backspace rather than delete. Delete still works by pressing fn+backspace as usual.

If this wasn’t bad enough you can simply boot the system using the installation DVD and reset any administrator password, login and have instant access to the system keychain. So, well, using the system keychain for passwords to encrypted disks is not a great idea.

I therefore removed the articles referring to how to setup TrueCrypt with the keychain.

In short when closing the lid the MacBook can either:

- Sleep and keep the RAM memory powered on
- Hibernate and write memory contents to disk and power down completely

Writing memory to disk is considered safer as even if your battery runs out of juice memory contents are still preserved and the OS can bring you back to where you were. This of course comes with a time penalty. The following article explains everything in more detail and also provides information on how to change between different sleep and hibernation modes:
http://www.macworld.com/article/53471/2006/10/sleepmode.html

I changed my settings from hibernation to sleep and went from 22 seconds to 1 second of wait when closing the lid.

Unfortunately licensing issues prevent me from publishing my pre-compiled versions of TrueCrypt. So the next best thing I can do until there’s a new version of TrueCrypt that supports Snow Leopard, is to publish a “simple” do it your self guide.

In order to compile TrueCrypt for Mac OS X Snow Leopard you need the following:

1. XCode (it’s under the Optional folder on the Snow Leopard Install DVD)
2. macFUSE
3. TrueCrypt and wxWidgets source code
4. Header files from the RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki) 2.20.
5. pkg-config
6. A patch that modifies the source code so it compiles under Snow Leopard.

Installing XCode

Install XCode from the Snow Leopard installation DVD. This should be pretty straight forward and hopefully does not need any further explanation.

Installing macFUSE

Download and install macFUSE from here: http://code.google.com/p/macfuse

Installing pkg-config

pkg-config can be installed either through MacPorts or through Fink. The difference is that MacPorts requires you to compile the source and Fink installs the binary version. I personally prefer Fink as it uses the debian package installer. Below you will find instructions for installing either through MacPorts. OR Fink. Don’t do both!

Installing pkg-config through Fink

1. Get and install Fink 0.9 from here: http://www.finkproject.org/download/index.php?phpLang=en
2. Install pkgconfig by issuing the following command:
   
   sudo apt-get update && sudo apt-get install pkgconfig

Installing pkg-config through MacPorts

1. Get and install MacPorts from here: http://www.macports.org/install.php
2. Install pkgconfig by issuing the following command:

   sudo port install pkgconfig

3. Restart the Terminal application

Getting the TrueCrypt and wxWidgets source code

Download the TrueCrypt source code (preferably the tar.gz version) from here: http://www.truecrypt.org/downloads2

Open up a new Terminal window and create a new directory from where you will build TrueCrypt eg. $HOME/src:

mkdir $HOME/src

Uncompress the downloaded file into the new directory:

cd $HOME/src; tar xvzf $HOME/Downloads/TrueCrypt\ 6.2a\ Source.tar.gz

TrueCrypt uses the wxWidgets cross platform GUI library and therefore needs it to compile. Get it here:
http://prdownloads.sourceforge.net/wxwindows/wxMac-2.8.10.tar.gz

Uncompress the wxMac-2.8.10.tar.gz file into the $HOME/src directory using the following command:

cd $HOME/src; tar xvzf $HOME/Downloads/wxMac-2.8.10.tar.gz

You should now have two directories in the $HOME/src directory truecrypt-6.2a-source and wxMac-2.8.10. You can verify this by running the following command:

ls $HOME/src

In order to compile TrueCrypt for Snow Leopard the source code has to be patched slightly. I have prepared a patch file that can be applied to the code automatically using the patch utility. Download the patch from here: http://patrik.cqure.net/files/truecrypt-snow-leopard.patch

Apply the patch by running the following command:

cd $HOME/src; patch -p0 < $HOME/Downloads/truecrypt-snow-leopard.patch

You should see the following output:

patching file truecrypt-6.2a-source/Main/FatalErrorHandler.cpp
patching file truecrypt-6.2a-source/Main/StringFormatter.h
patching file truecrypt-6.2a-source/Makefile
Hunk #1 succeeded at 145 with fuzz 2.

TrueCrypt also uses a number of header files from RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki) 2.20. These have to be downloaded manually from here: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20. The files needed are pkcs11.h, pkcs11f.h and pkcs11t.h. They need to go into the directory $HOME/src/pkcs11. If your lazy you can run the following, which does this for you:

mkdir $HOME/src/pkcs11; cd $HOME/src/pkcs11; \
for f in pkcs11.h pkcs11f.h pkcs11t.h; do \
curl --no-epsv --ftp-pasv "ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/${f}" > ${f}; \
done

Ok, so now we are all set with the source code and can begin compiling.

Compiling TrueCrypt

First of all we need to point out where our RSA Security pkcs stuff is located. You do this by issuing the following command in the Terminal:

export PKCS11_INC=$HOME/src/pkcs11

Once this is done we can start to compile the wxWidgets by issuing the following command:

cd $HOME/src/truecrypt-6.2a-source; make WX_ROOT=$HOME/src/wxMac-2.8.10 wxbuild

Compilation will take time and at times look as if it has stopped. Be patient and disregard any WARNINGS or error messages that you may see (there may be quite a few with different information!) If all went well you should now have a directory called $HOME/src/truecrypt-6.2a-source/wxrelease with 355 items in it. You can verify this by issuing the following command:

ls $HOME/src/truecrypt-6.2a-source/wxrelease | wc -l

With the wxWidgets compiled we can now start compiling TrueCrypt by issuing the following command:

cd $HOME/src/truecrypt-6.2a-source; make WXSTATIC=1

Again, compiling TrueCrypt will take some time but it should not return any errors. If all goes well, which it should if you have followed the guide properly, you should end up with a TrueCrypt.app folder under the Main directory. You can test whether the application works or not by running the following command:

open $HOME/src/truecrypt-6.2a-source/Main/TrueCrypt.app/

If it starts, you’re all set and simply need to copy or move the application into /Applications as usual. From the Terminal you can do this by issuing the following command:

cp -R $HOME/src/truecrypt-6.2a-source/Main/TrueCrypt.app /Applications

Good luck!

However, in the configuration file all looked fine and dandy: create mode, directory mode and inherit permissions were all still set. To make really sure I added some of the force options as well. Still, all folders were created with 0755 (drwxr-xr-x) permissions (I had it setup and expected 0750). I thought I was going nuts until I found some other articles outlining the exact same problems and pointing their finger at Mac OS X.

http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg657971.html
http://lists.samba.org/archive/samba/2009-June/148518.html

Apparently the servers incorrect setting of ACLs on the directories was due to the umask value on Mac OS X. Going through the article, I found that the following suggested settings fixed the problem for me.

unix extensions = no
force directory security mode = 0770

Once setting unix extensions to no, I had to disconnect and re-connect to the server in order to access my files and from then all directories were created with the correct permissions.

Some other cool features also made it into the release such as:

• OVF (Open Virtualization Format) appliance import and export
• OpenGL 3D acceleration for Linux and Solaris guests

The complete Changelog is here http://www.virtualbox.org/wiki/Changelog

Copying the lot from Linux to Mac simply broke the whole VirtualBox installation which failed to start at all once the files were in place. I had expected some errors, however not total breakage. Simply creating new machine configurations and re-attaching the disks was out of the questions as most of my machines had several snapshots which I didn’t manage to reconnect to the new machine configuration. So I started to look for trouble in the old configuration files.

For starters several configuration files had absolute paths to disk files, dvd/cd images, snapshots etc. As my files now resided in different folders this had to be changed. I started modyfying the VirtualBox.xml by hand and finally made som quick search and replaces. I also took the chance to remove some older dvd/cd images which were no longer on the system. Oh and then there was the version attribute of the VirtualBox element that had to be changed from 1.6-linux to 1.6-macosx.

Then for each VirtualBox machine I had to open the Machines/<machine name>/<machine name>.xml file and first correct the version stuff from 1.6-linux to 1.6 macosx.  Ones this was done I needed to remove any cd/dvd images no longer accessible by the machine such as the installation dvd for the guest additions which was “left in the drive” for most machines. This was a matter of simply deleting the Image element between each DVDDrive element. Now the configuration was correct and the Machine could be loaded by the interface. For every machine that was in their saved state I hade to discard the state as the CPU did not match the one under which the image was saved. Once discarded the Machine could be opened by the VirtualBox interface where it was a matter of clicking through all the options to make sure they were correct. One option that needed to be changed for each machine was the audio configuration. In linux it was set to Pulse audio and in Mac OS X it needed to be CoreAudio. Also any old network interfaces no longer available, such as host interfaces pointing at interface names such as eth0, eth1 or any tun interface not present in the new system had to be corrected.

So with the configuration all changed both manually and in the GUI the Machine was good to go. Once corrected and started it all worked great and I was very happy with VirtualBox! It even works better than it did in Linux as so far I have had a lot less problems with machines in their saved state breaking and refusing to start because of image inconsistencies.