Die kostenpflichtige RemoteCalendar-Application (im AppStore) schließt diese Lücke. Damit kann man Kalender, die auf CalDAV-Servern wie Google oder eben Chandler gehostet werden, über die Luftschnittstelle synchronisieren. Damit die Anwendung wirklich benutzbar wird, fehlen noch ein paar Kleinigkeiten. So ist es momentan etwa noch nich möglich, neue Termine am iPhone einzugeben. Schade eigentlich.

Ich musste also meine MySQL-Datenbank mit den Datendateien aus dem Klon starten. Es war mir aber zu riskant, die aktuellen Datendateien mit den Dateien aus dem Klon zu überschreiben. Stattdessen wollte ich in einer Kopie arbeiten. Ich kann mich erinnern, folgende Schritte durchlaufen zu haben (alle Befehle habe ich im Mac OS X Terminal eingegeben, da es sich um die Datenbank handelte, die ich lokal zum Entwickeln nutze). Die verwendete Datenbank ist MySQL 5.1.22-rc, die ich damals mit dem Package-Installer von mysql.org installiert hatte. Die Datenbank liegt in diesem Fall üblicherweise in /usr/local/mysql. Meine Backup-Festplatte war unter /Volumes/Backup eingehängt. Zuerst musste ich mit

sudo tar cv /Volumes/Backup/usr/local/mysql/ | tar x -C /Users/dh/Desktop/mysql

eine 1:1-Kopie der gesamten Datenbankinstallation aus dem Backup ziehen und auf meinem Desktop ablegen. Das tar-Kommando hat im Gegensatz zu cp den Vorteil, dass alle Berechtigungen beim Kopieren erhalten bleiben. Um Probleme mit Zugriffsrechten zu umgehen habe ich mit

sudo chown -R dh /Users/dh/Desktop/mysql

erst einmal alle Dateien in der Kopie meinem Benutzer (dh) übereignet. Nun musste ich dem MySQL-Server mitteilen, dass er die Datendateien aus /Users/dh/Desktop/mysql/data und nicht aus /usr/local/mysql/data verwenden sollte. Dazu muss man bei meiner Installation die Datei /private/etc/my.cnf editieren (Quelle):

[mysqld]
#altes tmpdir:
#tmpdir=/usr/local/mysql/tmp
#neues tmpdir
tmpdir=/Users/dh/Desktop/mysql/tmp
#neues datadir
datadir=/Users/dh/Desktop/mysql/data

Den MySQL-Server kann man dann aus dem Terminal mit dem Aufruf mysqld starten. Aus den Log-Meldungen auf der Konsole sollte man entnehmen können, dass er das richtige Data-Directory verwendet. Das hat bei mir jedoch noch nicht gereicht. Der Server hat die Tabelle (system_settings), die ich restaurieren wollte, nicht gefunden. Dann bin ich auf einen Hinweis gestoßen, wie MySQL zwingen kann, die InnoDB-Datendateien (ibdata und ib_logfile0, ib_logfile1) direkt auszulesen, um an die verlorenen Daten zu kommen:Man muss die Größe der Log-Dateien ermitteln und dann im folgenden Kommando angeben:

 mysqld –innodb_log_file_size=5242880 –innodb_force_recovery=6

Mit dieser Methode konnte ich den Server starten und dann mit mysqldump in Ruhe alle fehlenden Records aus der Datenbank extrahieren. Cool!

Am Ende hat sich der SuperDuper-Klon also doch noch einmal bewährt! Meine redundante Sicherungsstrategie werde ich auch in Zukunft beibehalten. Die gesamte Ausfallzeit betrug dadurch nur etwa 2,5 Stunden. Wenn der SuperDuper-Klon nun auch noch bootfähig gewesen wäre, hätte ich sogar komplett ohne Ausfallzeit weiterarbeiten können.

Diese Arbeit wäre nun verloren, wenn ich ausschließlich eine Time-Machine-Sicherung gemacht hätte!

ABER: Ich habe ja noch den Inhalt der Festplatte — praktisch direkt vor dem Unglück — mit SuperDuper auf eine Firewire-Platte geklont. Heute früh hatte ich mich unglaublich geärgert, dass diese Firewire-Platte nicht, wie von SuperDuper versprochen, bootfähig ist. Jetzt wird sie doch noch einmal wichtig. Ich habe nämlich heute früh — als sich der Rechner so komisch verhalten hat — den Mac neu gestartet (und nicht einfach knallhart ausgeschaltet). Die Datenbank sollte also ihren Inhalt aus dem RAM sauber in die Datendateien auf der Platte geschrieben haben. Aber Mist: Zu dem Zeitpunkt war das Backup ja schon durchgelaufen. Es blieb also zu hoffen, dass MySQL den RAM-Inhalt also bereits *vor* dem SuperDuper-Backup auf die Platte geschrieben hatte…

Das Restaurieren von der Firewire-Platte ist jedoch wesentlich aufwändiger als es klingt. Inzwischen habe ich es aber hinbekommen. Mehr dazu in einem eigenen Beitrag.

Alles scheint wieder zu funktionieren wie vorher. Auch die iCal-Kalender-Einträge sind noch alle da (damit gab es früher angeblich Probleme). Time Machine hat die Feuerprobe bestanden

TextMate Blog: Working with History in Bash

The Definite Guide to Bash Command Line History

In einigen Foren wird die Verwendung des Combo-Updates an Stelle des automatischen System-Updates empfohlen, um Probleme beim Update zu umgehen. In denselben Foren kann man auch so manche Schauergeschichte über ein missglücktes Update nachlesen. Naja, ich weiß ja nicht, was die Leute mit ihrem Rechner anstellen — bei mir hats jedenfalls geklappt.

Halt, ein kleines Problem gibts doch noch: zfoned, der zfone-Daemon kommt offenbar nicht mit dem Update zurecht; er braucht knapp 100% CPU-Last und musste daher gewaltsam beendet werden. Mal sehen, wie lange die zfone-Entwickler für eine neue Version brauchen.

Ich schau dann mal, ob noch weitere Probleme auftreten… 

Mac OS X – Resetting a Forgotten Account Password

Darüber hinaus gibt es noch den Single-User-Mode, den man beim Booten mit Apfel-S erreicht. Dann bekommt man eine root-Shell, in der man folgendermaßen das Passwort zurücksetzen kann.

• sh /etc/rc
• passwd yourusername
• reboot

Reset your Mac OS X passwort

Dieses Feature stellt natürlich eine gewisse Bedrohung dar, da es jedem Angreifer, der physischen Zugriff auf den Mac hat, ermöglicht, sich unbefugt Zugang zu verschaffen.

Als Abhilfe kann man ein Firmware-Passwort setzen. Anleitungen dazu findet man im Internet. Ich habe mich allerdings noch nicht getraut, das auszuprobieren.

Nein, ich habe nicht den Bilde-automatisch-den-Absolutbetrag-Modus aktiviert — den gibt es IMHO auch gar nicht.

Interessant: Im “Beleg”-Fenster steht korrekt -0,9 drin. Der Taschenrechner rechnet intern auch mit -0,9 weiter. Das bemerkt man spätestens, wenn man 1,3 — 2,2 + 0,9 ausrechnet. Dann zeigt er nämlich 0 an.

2,2 — 1,3 errechnet er korrekt zu 0,9. 1 — 2 ist korrekterweise –1. Ein wirklich interessanter Bug. Gibt es noch mehr Zahlenpaare, bei denen ein falsches Vorzeichen angezeigt wird? Vielleicht findet Ihr ja noch welche.

Jetzt muss ich mich noch für den reißerischen Beitragstitel entschuldigen. Der Taschenrechner rechnet richtig, zeigt aber ein falsches Ergebnis an. Also immer mitdenken beim Rechnen!

Nachtrag: Das Phänomen tritt offenbar nicht bei allen Apple-Rechnern auf.

Nachtrag 2: Hier geht es zu einem YouTube-Video, das den Fehler veranschaulicht (Dank an Stefan S.!)

Vorsicht: Das Mitschneiden ist nur erlaubt, wenn der Gesprächspartner eingewilligt hat!

Versteckte Features – Fritz!Box

CommandLine – spack.org/wiki