How to setup encrypted Time Machine Backups from Falko Zurell on Vimeo.

vertical text selection in TextMate and VIM from Falko Zurell on Vimeo.

Ich habe mal wieder versucht FileVault zu aktivieren um zu schauen, wie weit die Entwicklung bei Apple in Sachen Verschlüsselung vorangeschritten ist.

FileVault Verschlüsselung kann pro Benutzer auf dem System aktiviert werden. Dabei wird das komplette Home-Verzeichnis des Benutzers verschlüsselt. Dafür wird ein spezielles File-Bundle angelegt, welches das Verschlüsselte Home-Verzeichnis enthält. Ist der Benuzter eingeloggt, so ist diese Bundle im Homeverzeichnis des Benutzers gemounted. Gegenüber MacOS 10.4 (Tiger) welches für FileVault ein “Sparse Image” (eine große Datei) benutzte ist die aktuelle Implementierung schon deutlich effizienter da mehrere kleinere Dateien zur Verschlüsselung benutzt werden.

Allerdings wird man schon bei der Aktivierung der FileVault-Verschlüsselung darauf hingewiesen, daß die Aktivierung Auswirkungen auf die Time Machine Backups haben.

Ist FileVault aktiviert, so kann das Home Verzeichnis des Benutzers nicht mehr gesichert werden, wenn er eingeloggt ist. Es wird nur noch gesichert, wenn der User ausgeloggt und somit sein Home Verzeichnis nicht gemounted ist. Dabei wird dann das komplette verschlüsselte File Bundle gesichert. Einzelne Dateien sind über die normale Time Machine Oberfläche nicht mehr wieder herstellbar.

Für den normalen Laptop-Gebraucht macht FileVault das Time Machine Backup praktisch nutzlos. Die überwiegende Mehrheit der Laptops dürften nur von einem einzigen Benutzer genutzt werden. Dieser Benutzer hat normalerweise keine Veranlassung sich an seinem Rechner auszuloggen und einzuloggen. Apple hat einen ja seit langem damit Verwöhnt, daß man seinen Rechner einfach nur zuklappen muß und dann später an genau der gleichen Stelle weitermachen kann. Mit FileVault müßte man sich nun regelmäßig ausloggen, den Rechner aber eingeschaltet lassen um zu Warten, daß Time Machine ein Backup des verschlüsselten Home Verzeichnisses macht. Was ist das bitte für ein abstruser “Use Case”?

Praktisch ist Time Machine mit FileVault damit nutzlos. Man kann nun zwischen Pest oder Cholera wählen. Entweder kein Backup oder keine Verschlüsselung.

Natürlich gibt es für dieses Problem work arounds (z.B. TrueCrypt). Doch diese sind allenfalls Krücken gegenüber den geschmeidigen Einzelprodukten.

Ich werde erstmal FileVault wieder abschalten und mich nach anderen Verschlüsselungslösungen umschauen.

[Update:]

Jagge hat in den Kommentaren einen guten Hinweis gegeben wie man das FileVault-Problem in den Griff bekommen kann. Wie immer ist etwas “Bastelarbeit” erforderlich, aber es läßt sich zum Glück mit Boardmitteln lösen.

Sehr interessant fand ich auch den Link zu einem Artikel der beschreibt, wie man sein TimeMaschine Backup verschlüsselt ablegen kann. Ebenfalls mit Boardmitteln.

Wenn ich in letzter Zeit einen Rechtsklick auf eine Datei machte, dann hat sich PathFinder aufgehangen. Zuerst nur für ca. 1-2 Minuten, dann öffnete sich das Kontextmenü schließlich doch noch. Doch beim Zugriff auf das “Öffnen mit…” Untermenü hängt sich PathFinder dann völlig auf und ist nur noch gewaltsam zu beenden.

Daraufhin habe ich im Support-Forum von Cocoatech nach diesem Fehler gesucht und bin fündig geworden. Mindestens noch ein anderer Nutzer hatte auch dieses Problem. Ein Mitarbeiter von Cocoatech nahm dann über das Forum mit mir Kontakt auf und empfahl mir eine ein spezielle Debug-Version von PathFinder zu installieren und beim Hang Up dann einen Bericht der “Aktivitäts Anzeige” zu erstellen und einzuschicken.

Der Support fand dann heraus, daß diese Hang Ups von DropBox verursacht werden und wiesen mich auf eine Beta-Version von DropBox hin, welche dieses Problem behebt.

Das hat in der Tat geholfen. Mir ist dann auch aufgefallen, daß ich diese Rechtsklicks in den allermeisten Fällen wirkliche auf Dateien in meinem DropBox-Verzeichnis gemacht habe.

Markus hat mich in den Kommentaren zu einem Beitrag hier im Blog auf einen Artikel bei AppleInsider hingewiesen. Dort werden noch einmal die Hintergründe und die Tragweite vom Schritt zum 64bit MacOS X Snow Leopard erläutert.

Ich fasse das hier mal in Deutsch zusammen:

1.) Der Kernel

Der Kernel von MacOS X Snow Leopard ist der innere Kern des Betriebssystems. Er kümmert sich um die Kommunikation zwischen den Anwendungsprogrammen und der Hardware (grob gesagt). Er liegt jetzt in einer 32bit und einer 64bit Version vor. Der größte Vorteil des 64bit Kernels ist, daß er direkt mehr als 4GB RAM ansteuern kann. Abgesehen von einigen Sicherheitserweiterungen.

Der Kernel kann Module laden welche ihm Funktionen hinzufügen. Zum Beispiel um Hardware zu unterstützen die vom Kernel selbst noch nicht unterstützt wird. Diese Module müssen zum Kernel genau passen. Das heißt entweder 32bit oder 64bit unterstützen.

Apple hat sich entschieden auf seinen Rechnern standardmäßig den 32bit Kernel laufen zu lassen, auch wenn die Hardware den 64bit Kernel unterstützen würde (Intel Core2 Duo CPU + 64bit EFI). Das liegt daran, daß die meisten Hersteller von Kernel-Modulen (Treibern) ihre Module noch nicht auf 64bit umgestellt haben. So gewährleistet Apple, daß die bestehenden Kernel-Module weiterhin funktionieren.

2.) Die Anwendungen

Unabhängig vom verwendeten Kernel können auf Snow Leopard sowohl 32bit als auch 64bit Anwendungen laufen. Apple selbst hat fast alle seiner Standardanwendungen auf 64bit umgestellt. So laufen der Finder, Mail.app, Safari und die meisten Systemprozesse jetzt im 64bit Modus.

WindowsXP gibt es schon seit längerem in einer 64bit Variante. Allerdings ist diese nicht in der Lage sowohl 32bit als auch 64bit Anwendungen laufen zu lassen. Entscheidet man sich für die 64bit Version, so muss man alle Programm als 64bit Version laufen lassen. Das behindert die Verbreitung von 64bit Windows massiv, da viele Programm einfach noch nicht als 64bit Version verfügbar sind und so der Umstieg für die meisten Anwender schlicht nicht möglich ist.

Allerdings muss man hier zwingend 64bit Treiber einsetzen. Will man also 64bit Applikationen laufen lassen, muß man die 64bit Windows-Version wählen und damit auch zwingend 64bit Treiber einsetzen.

Apple geht hier einen viel eleganteren Weg mit Snow Leopard. Man kann seine 32bit Programm weiter benutzen und parallel dazu auch 64bit Software benutzen. Das ermöglicht einen hoffentlich viel schnelleren Umstieg zu 64bit Software.

Auch wer seinen Mac mit einem 64bit Kernel betreibt (ich tue das zeitweise schon zum Testen) kann weiterhin 32bit Applikationen laufen lassen.

[Update:] Der Windows-Admin wies mich darauf hin, daß ich hier was falsch formuliert habe. Auch die 64Bit Windows-Varianten sind in er Lage 32bit Programme auszuführen. Dafür gibts das sogenannte Windows-on-Windows64. Man muß allerdings bzgl. des Kernels sich für 64bit oder 32bit Windows entscheiden. Hab das oben geändert.

Modify Keyboard Shortcuts on MacOS X from Falko Zurell on Vimeo.

In fact most of the desktop Macs are running the 32bit kernel by default. Only the Apple Xserve with proper CPUs will run the 64bit kernel by default.

The cause of that seems to be the fact that a lot of the drivers were not finished as 64bit version when Snow Leopard was ready. So Apple decided to deliver both kernels and boot the 32bit by default on the desktops.

However you can explicitly choose the 64bit kernel during boot by pressing the keys “6″ and “4″. You can tell that you’re running the 64bit kernel by entering the following command in your Terminal:

uname -a


It should look like this:

Darwin voyager.alice-dsl.de 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:46:25 PDT 2009; root:xnu-1456.1.25~1/RELEASE_X86_64 x86_64


The important part is the “x86_64″. It would be “i386″ if it’s the 32bit kernel.

Everyone hates the time tracking for projects. But everyone also knows that it’s essential for good accounting an planning. The reasons for the dislike is mostly the ugly tools for this tasks. Most tools are good examples for complete lack of user friendlyness

But thanks to brave Julia Soergel & Sebastian Munz there is an alternative. The wrote there diploma thesis on mite – a web based time keeping tool – and released or continued it as a service on the web.

They used all the recent Web 2.0 techniques to create lean, smart and powerfull web application. But they didn’t stop there. They also implemented some additional tools like the Jabber bot and Twitter bot to interact with your mite account.

This makes time keeping really easy and almost a pleasure. So there are no more excuses.

Unfortunately there is no obvious way to tell TimeMachine to use an pre exisiting Backup. TimeMachine would simply start a new backup if you try to continously use the old Volume. The old Backup folder may be even moved to the Trash on that Volume. Obviously this is not what you want.

But when you try to move the original Backup out of Trash, you’ll notice that even the super user “root” doesn’t have the privileges to do that.

But don’t worry. You’re not all lost. What is causing you the trouble is the fact that the MAC address is somewhere tagged on the Backup folder and that Apple additionally uses ACLs (Access Control Lists) on the backup volume. These are basically some additional security settings which should prevent unauthorized or unwanted changes.

So the easiest way to get the Backup working again is to disable the ACLs on the volume, change the MAC address tag of the Backup folder and the re-enable the ACLs on the volume.

This can be done in the Terminal.app as superuser:

cd /Volumes/TimeMachineBackup
fsaclctl -p /Volumes/TimeMachineBackup -d
xattr -w com.apple.backupd.BackupMachineAddress 00:16:cb:90:62:0d `hostname`
fsaclctl -p /Volumes/TimeMachineBackup -e

After that your original Backup should be recognized by TimeMachine.

This tutorial was found here: CyberHQ NL