Bei aller Kürze sehr anschaulich dargestellt ist dies in Andreas Drägesteins Screencast, den ich auf Macmagazin.de gefunden habe:

Geschick im Unglück war, dass direkt nebenan ein Apple-Service-Partner seinen Laden hat. So schlang ich mein Getränk und meinen Kuchen herunter und trug meine tote Technik zur Reparaturannahme. Es stellte sich heraus, dass zum zweiten Mal im Leben des MBP das Logic Board gestorben war und nach drei Tagen Wartezeit hatte ich meinen Laptop funktionsfähig wieder.

Dank AppleCare musste ich für die Reparatur lediglich Geduld aufbringen. Dennoch gab es eine Sache, die mir unangenehm war, und das war die Frage des Servicemitarbeiters nach dem Administrator-Passwort. Ich verstehe natürlich, dass für Reparatur und Test ein Admin-Zugang nötig ist, aber dieses Passwort halte ich sogar vor meiner Freundin geheim, der ich sonst alles anvertraue. Mit diesem Passwort steht schließlich auch meine Dropbox und meine Keychain und damit ein Universum persönlicher Informationen und Kontakte offen.

Um diese Situation in Zukunft zu vermeiden, habe ich jetzt ein Service-Benutzerkonto eingerichtet, dessen Passwort ich ohne schlechtes Gefühl weitergeben kann. Keine bahnbrechende Idee, aber der Clou daran ist, sie umzusetzen, solange der Rechner noch ansprechbar ist!

1. Wer das Dock nicht grundsätzlich ausblenden lässt, kann es bei Bedarf verstecken: Durch Betätigen der Tastenkombination “Command-Option-D” lässt man das Dock wechselweise verschwinden und wieder auftauchen. Mir hilft diese Funktion oft, wenn ein Fenster ins Dock hineinragt und ich deshalb nicht an den Anfasser für die Fenstergröße komme.

2. Wenn der Desktop schon voller Fenster und beim Start einer neuen Anwendung zu befürchten ist, dass nun alles im Chaos versinkt, kann man beim Klick auf das Icon des Programms die Tasten “Command” und “Option” festhalten. Daraufhin wird die Anwendung gestartet, vorher aber noch werden alle bereits angezeigten Fenster versteckt.

Hier ist die Folge im Original:

Warum das ganze eigentlich?
Ziel der Veranstaltung ist, mit beliebigem Hardwaresetup die TimeCapsule-Funktionalität nachzubilden. Und da ich sicher nicht der einzige bin der sich die “warum geht das nicht auch mit der Hardware die ich schon habe”-Frage gestellt hat kommt das ganze nun hier zusammengefasst an die öffentlichkeit.

Ich habs nicht eingesehen für 500GB Fesplattenplatz an nem W-Lan Router 300€ auszugeben.
Ergo hab ich das nun bei mir mit einer ganz normalen Fritzbox Fon und einer daran angeschlossenen USB-Platte nachgebaut, da ja nun aber nicht jeder dieses Setup fahren möchte ist die Anleitung frei von Hardwarespezifika.

Entsprechend sind auch die Voraussetzungen recht generisch:
- W-Lan (Duuh!)
- ein existierendes SMB-/AFS-Share (wie man zu so einem Share kommt werde ich hier nicht beleuchten, google ist da aber wie immer euer Freund)

Einige Worte der Vorbereitung und Warnung:

Wer TimeCapsule-ähnliche Performance erwartet sollte sich bewusst sein, dass die TimeCapsule auf dem IEEE 802.11n Standard aufsetzt der ca. 4 – 6 mal schnellere Datenübertragungsraten ermöglicht als der de facto Standard 802.11g (mit dem auch ich zuhaus noch vorlieb nehmen muss).
Daher die Empfehlung für 802.11g-User: selbst wenn das Ziel ist am Ende ausschliesslich über WLan zu backupen empfehle ich das Initialbackup NICHT über WLan sondern über Kabel zu machen, sonst ist das Backup veraltet bevors (ne Woche später) fertig ist. Folgt dafür einfach der Anleitung von A bis Z und ersetzt für das Initialbackup das W-Lan Kabel mit nem normalen, nachdem das Initialbackup durch ist wird der Tausch halt wieder rückgängig gemacht.

So, genug einleitende Worte, rein ins vergnügen.

Schritt 1:
Damit wir überhaupt die Möglichkeit haben, auf ein Netzlaufwerk zu TimeMachinen muss erst einmal dieser altbekannte Befehl im Terminal (benötigt nur normale Benutzerrechte) abgesetzt werden:

mbnight:~ nightshade$ defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

Das wärs eigentlich schon gewesen, hätte Herr Apple nicht in Leopard 10.5.2 irgendeinen Quatsch gemacht der dafür sorgt, dass das backupen auf Netzlaufwerke nicht mehr funktioniert.
Aber dies wär nicht das Internet dass wir alle kennen und lieben wenns nicht auch dafür schon wieder ein Workaround geben würde..

Schritt 2:
Man mounte sein zukünftiges Backuplaufwerk das mit jedem beliebiegen OS X-lesbaren Dateisystem formatiert ist erst einmal ganz normal (Finder öffnen, “cmd”+”K” drücken (oder Gehe Zu -> Mit Server verbinden), zu mountendes Laufwerk angeben, “Verbinden” drücken).

Nun kommt der lustige Part.

Nehmen wir mal an wir haben ein 500GB FAT32 Share herangezogen. An sich kann OS X da ja fröhlich drauf schreiben, TimeMachine allerdings will ausschliesslich auf HFS+J schreiben. Zicke.

Bleibt also nichts anderes übrig als die 500GB zu HFS+J zu formatieren und ab dem Zeitpunkt den überschüssigen Platz auf dem Share nicht mehr von anderen Systemen aus nutzen zu können, oder aber man erstellt einfach eine HFS+J Image innerhalb des FAT32 Shares das mit der Größe des Backups in einem Definierten Rahmen wächst. Find ich besser, machen wir doch das.

Bevor wir das allerdings tun können brauchen wir noch eine kleine Info: Die MAC-Adresse der Netzwerkkarte (bei mir wurde lustigerweise NICHT die des WLAN-Interfaces benötigt sondern die der klassischen Netzwerkkarte “mit Kabel dran”, warum das so ist hab ich noch nicht ganz rausfinden können).

Schritt 3:
Terminal öffnen und den Befehl

mbnight:~ nightshade$ ifconfig en0

eingeben, aus dem Ergebniss die Zeile die mit “ether” beginnt herauskopieren und irgendwo zwischenspeichern.
Sieht dann so ähnlich aus:

ether 00:1b:64:ac:9b:f0

So, nun haben wir endlich alles was wir brauchen um unser zukünftiges Backuplaufwerk TimeMachinefähig zu machen in dem wir das oben erwähnt HFS+J-Image erstellen.

Schritt 4:
Im Terminal den Befehl
hdiutil create -size IMAGESIZE -fs HFS+J -type SPARSEBUNDLE HOSTNAME_MACADDR.sparsebundle” eingeben.

Haben wir IMAGESIZE (die zukünftige Maximalgröße des Backups), HOSTNAME (der Rechnername) und MACADDR (die oben aus “ifconfig eth0″ herauskopierte MAC-Adresse) mit den korrekten Werten ersetzt sieht in unserem Bespiel dann so aus:

mbnight:~ nightshade$ hdiutil create -size 480G -fs HFS+J -type SPARSEBUNDLE “mbnight_001b64ac9bf0.sparsebundle”

Dies erzeugt lokal die HFS+J-Image-Datei, die in diesem Falle initial knapp 200 MB gross ist und maximal 480GB Daten halten kann.

Schritt 5:
Diese Datei wird nun nur noch auf unser zukünftiges Backuplaufwerk kopiert, TimeMachine gestartet und unter “Volume Wechseln” unser frisch geimpftes Backuplaufwerk ausgewählt.

120 Sekunden später beginnt vollautomatisch unser erstes TimeMachine-Backup über WLan – unsre TimeCapsule für arme ist fertig.

Oder doch nicht? Für die komplettisten unter uns hätte ich noch

Schritt 6:

Da ich MarcoPolo benutze, möchte ich eigentlich auch dass, wenn ich nach Hause komme, das Laufwerk automatisch gemountet wird. MarcoPolo kommt allerdings nicht wirklich mit Netzlaufwerken klar, kann aber z.B. AppleScript ausführen.

Machen wir uns also 2 kleine Scripte mit denen das mounten und unmounten der Laufwerke automatisch passiert.
Diese scripte funktionieren, ob sie die Höhe der Scriptschöpfung sind ist etwas ganz anders. Für Vorschläge bin ich immer offen.
Wir öffnen also das Tool “Skripteditor” und basteln das erste Script:

try
tell application “Finder”
mount volume “smb://MeinServer/MeinShare”
end tell
end try

Speichern das ganze wos uns beliebt und zwar als “Programm”, nicht als “Script” und lassen MarcoPolo dieses “Programm Öffnen bei Ankunft in Home”.

Dann noch das unmount-Script:

tell application “Finder”
if exists “MeinShare” then
eject disk “MeinShare”
end if
end tell

Speichern das ganze ebenso als “Programm” und lassen Marco Polo dieses “Programm Öffnen beim verlassen von Home”.

Die korrekte benutzung von MarcoPolo ist noch einmal eine kleine Wissenschaft für sich und vllt. das Thema für einen anderen Artikel, solang aber die Regeln schon korrekt bestehen wird das genau das tun was in der Werbung versprochen wurde, nämlich das Backuplaufwerk mounten wenn man zuhaus ist und es unmounten wenn man wieder geht.

Ich für meinen Teil bin mit dieser Lösung ziemlich glücklich, das einzige was mir persönlich noch fehlt ist der 802.11n-Standard damit ich mehr als nur die lumpigen 10GB pro nacht gebackuped bekomme und auch das Initialbackup über W-Lan erträglich wird.

So, ich hoffe dass diese Anleitung hilfreich ist, und euch allen erfolg beschert wird, sollte es Probleme geben – ich guck regelmässig in die Comments-Section und schau mal dass ich alle glücklich machen kann.

bye
/night

Meist wird an dieser Stelle der Tipp gegeben, einfach eine Kopie der betreffenden Applikation zu erstellen. Gerade Eclipse ist aber ein gutes Beispiel dafür, dass dabei haufenweise Plattenplatz draufgeht.

Bevor ich dazu kam, meine Vermutung zu prüfen, dass das open-Kommando eine bessere Alternative sein könnte, hat sie MacOSXHints in “An easy way to run multiple instances of any program” schon bestätigt: die Option -n erlaubt das parallele Betreiben der selben Applikation.

Ein kurzes Shellscript kann hier also helfen. Es reicht, den folgenden Zweizeiler in TextEdit an das gewünschte Programm anzupassen und im Programme-Ordner (/Applications) abzulegen.

#!/bin/sh
open -n /Applications/MeineAnwendung

Anschließend muss es noch durch den Terminal-Befehl chmod +x /Applications/MeinScriptName ausführbar gemacht werden; ein schönes Icon verschönert zusätzlich die Optik.

Anstatt Plattenplatz zu verschwenden einfach die Bordmittel nutzen — Merkmale einer schönen Lösung.

Von den drei zu hackenden Laptops ist als Erstes das MacBook Air mit Mac OS X 10.5.2 den Knackversuchen der Teilnehmer des “PWN to OWN”-Wettbewerbs auf der CanSecWest zum Opfer gefallen. Die Laptops mit Windows Vista SP1 und Ubuntu 7.10 blieben bislang unkompromittiert.

Und leider war dies nicht das erste schwache Abschneiden der Apple-Plattform:

Bereits vergangenes Jahr gelang es Hackern, ein vollständig gepatchtes MacBook Pro mit Mac OS X 10.4.9 zu knacken.

Es mag tatsächlich sein, dass die Motivation, das “Opfer” mitnehmen zu dürfen, dem Macbook Air mit zum Verhängnis wurde. Apple wird sich aber auf jeden Fall (weiter) anstrengen müssen, wenn der Sicherheitsaspekt die Vorteile seiner Rechner nicht nivellieren soll.

Noch leichter ist es mit der Freeware Desktop 2 Login, die (im Gegensatz zu mir) den genauen Pfad zu diesem Bild auswendig kennt und einfach das aktuelle Desktop-Hintergrundbild übernimmt.

Ich werde mich mal weiter auf die Suche nach Änderungen machen.

Unter Tiger setzte ich dafür Groupcal ein. Schon damals funktionierte das nur eher schlecht als recht. Spätestens jedoch für die Terminvereinbarung mit Kollegen musste ich wieder auf den Windows-Terminalserver zurückgreifen, denn das wollte so gar nicht klappen. Mit dem Upgrade auf Mac OS X 10.5 stellte Groupcal seine Funktion nun ganz ein und der Hersteller Snerdware macht lediglich die vage Versprechung, im ersten Quartal eine Leopard-Version bereitzustellen.

Meine Versuche mit Entourage sind momentan auch nur halb zufriedenstellend. Was ich aber definitiv geschafft habe, ist es, durch meine Versuche die SyncServices ordentlich durcheinander zu bringen. Dieses Stellwerk zwischen Handy, .Mac, iGTD, iCal und Adressbuch zeigt sich immer wieder verwirrt, was denn nun wohin soll.

Eine Möglichkeit, Probleme mit den SyncServices zu beheben, beschreibt Carsten Dobschat: Mit dem folgenden Kommando kann ein Reset der Synchronisation durchgeführt werden:

/System/Library/Frameworks/SyncServices.framework/Versions/A/Resources/resetsync.pl full

Wenn das nicht hilft, gibt es noch die Rosskur: Dafür ist jeder iCal-Kalender zu exportieren, alle Daten von iCal und SyncServices werden vernichtet, um dann nach einem System-Neustart mit einem Reimport neu zu beginnen. Das folgende Terminal-Kommando (im eigenen Homeverzeichnis auszuführen) löscht alle relevanten Dateien:

  rm -r ~/Library/Application\ Support/SyncServices/* \
  ~/Library/Application\ Support/iSync/* \
  ~/Library/Calendars/* \
  ~/Library/Preferences/com.apple.isync*plist \
  ~/Library/Preferences/com.apple.iCal*plist \
  ~/Library/Application\ Support/iCal/* \
  ~/Library/Caches/com.apple.iCal/*

Beide Methoden brachten bei mir eine Verbesserung, aber noch immer nicht die optimale, fehlerfreie Synchronisation. Sieht so aus, als sei dieses Problem wirklich eine harte Nuss. Ich werde also weiter forschen und meine Erkenntnisse bloggen.

Ein MUSS für Umsteiger.