Apple-spezifische Dateien wie .AppleDouble, .DS_Store etc. löschen (mittels find)

Wie im etwas längeren Artikel zu den Mac-spezifischen Dateien (.AppleDouble, .DS_Store etc.) und Veto Files angekündigt:

Haben sich einmal Mac-User mit dem Server verbunden, bevor deren Rechner oder der Server richtig konfiguriert worden sind, hat man den Salat: Alle Verzeichnisse sind voll mit den lustigen Finder-Metadaten.

Diese kann man finden mittels…

find \( -name ".AppleDouble" -or -name ".DS_Store" -or -name ".Trashes" -or -name "._*" -or -name ".TemporaryItems" \)

…und löschen mittels…

find \( -name ".AppleDouble" -or -name ".DS_Store" -or -name ".Trashes" -or -name "._*" -or -name ".TemporaryItems" \) -execdir rm -Rv {} \;

SSH Agent Key forwarding auf Mac OS X Systemen

SSH Agent Key Forwarding ist toll, wenn man mit vielen Hosts hantiert. In meinem konkreten Anwendungsfall will ich mich mit meinem SSH Key auf dem Server eines Kunden authentifizieren, wenn ich Daten von einem unserer Server auf das Kundensystem synchronisere.

Der Key wird also in diesem Use Case durchgereicht (mein Rechner –> interner Server –> externer Server), sodass ich sicher auf den externen Server zugreifen kann, ohne Passwörter zu verwenden oder meinen Key auf den internen Server legen zu müssen.

Sehr praktisch – wenn es denn funktioniert. Auf meinem Mac tat es das nie, obwohl ich mittels ssh -A $servername um das Key Forwarding bat. Auch eine Unterstreichung der Bitte über den Eintrag ForwardAgent yes in der SSH-Konfiguration (/etc/ssh_config) brachte leider nicht das erwünschte Ergebnis.

Ich habe mir dann immer damit abgeholfen, dass ich mich stets über ein Linux System eingeloggt habe, wo der Key auch hinterlegt war.

Anscheinend habe ich aber bei der heutigen erneuten Recherche geeignetere Suchbegriffe gewählt und endlich den passenden Hinweis gefunden:

Man muss unter OSX erstmal dem SSH-Agent die RSA- oder DSA-Identität (den Key) manuell bekannt machen.

Dies passiert einfach mittels ssh-add.

Was dann passiert beschreibt die Manpage mit…

ssh-add adds RSA or DSA identities to the authentication agent, ssh-agent(1). When run without arguments, it adds the files ~/.ssh/id_rsa, ~/.ssh/id_dsa and ~/.ssh/identity. After loading a private key, ssh-add will try to load corresponding certificate information from the filename obtained by appending -cert.pub to the name of the private key file.

…und das war es auch schon – der Key wird forgewarded und das Login auf dem externen Server klappt.

rsync zwischen MacOS (HFS+) und Linux (ext3) – und defekte Dateinamen

Bei umfangreicheren rsync-Läufen hier im lokalen Netz (ging um ca. 4 TB die von einem Ubuntu Server mit ext3 auf einen Mac mit HFS+ gehen sollten) stellten sich 2 Probleme heraus, die beim Sync zwischen Linux Maschinen nicht auftraten:

  • Ein großer Teil der Daten (und zwar alle mit Leerzeichen oder Umlauten im Dateinamen) wurde bei jedem rsync Aufruf neu übertragen, obwohl die Dateien sich nicht geändert hatten.
  • Umlaute waren z.T. defekt.

Eine längere Herleitung spare ich mir hier mal – statt dessen nur das Ergebnis der Recherchen, da das ggf. noch für jemanden nützlich sein könnte:

Das Problem entstand durch unterschiedliche Charsets auf beiden Maschinen:

Something else that can trip up rsync is a filesystem changeing the filename behind the scenes. This can happen when a filesystem changes an all-uppercase name into lowercase, or when it decomposes UTF-8 behind your back.

An example of the latter can occur with HFS+ on Mac OS X: if you copy a directory with a file that has a UTF-8 character sequence in it, say a 2-byte umlaut-u (303274), the file will get that character stored by the filesystem using 3 bytes (165314210), and rsync will not know that these differing filenames are the same file (it will, in fact, remove a prior copy of the file if –delete is enabled, and then recreate it).

You can avoid a charset problem by passing an appropriate –iconv option to rsync that tells it what character-set the source files are, and what character-set the destination files get stored in. For instance, the above Mac OS X problem would be dealt with by using –iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac OS X iconv in which all characters are decomposed).

(Die Erklärung stammt aus der rsync FAQ.)

Dem geneigten Mac-User fällt aber leider schnell auf, dass das mitgelieferte rsync den Parameter --iconv leider nicht versteht. Hier empfiehlt sich das Updaten z.B. über Macports – dazu hatte ich hier gerade schon ein paar Zeilen geschrieben.

Lange Rede, kurzer Sinn – nach dem rsync Update und der Angabe der Parameter schaut das bisher sehr gut aus. Folgender Kommandozeilenaufruf wird dabei verwendet:

rsync -a --modify-window=1 --stats --progress --exclude "*.frk"' --delete --iconv=UTF8-MAC,UTF8 root@SERVERNAME:/pfad/zum/Quell-Verzeichnis/ /pfad/zum/Ziel-Verzeichnis/

Kurznotiz: Darwinports, Fink und Macports

Nachdem Stefan in seinem Blog kurz und eindringlich von Darwinports abriet und Fink mich vor einiger Zeit schon nicht begeistert hatte, habe ich heute mal Macports eine Chance gegeben.

Kurzfazit:

  • Installation über einen Mac Installer (!), entsprechend problemlos und schnell
  • Installation von Paketen sehr einfach, automatische Auflösung von Abhängigkeiten klappt gut
  • binnen 15 min. gewechselt vom unerträglich schlechten RSYNC auf dem Mac zu einer aktuellen Version (rsync  version 3.0.7  protocol version 30)

Tipp der Redaktion, sozusagen 😉

Neue MacBooks (MacBook Unibody Aluminium): Booten von USB

Heute sind die neuen MacBooks bei uns eingetroffen – die große Freude wich jedoch erst einmal der Ernüchterung.

Es war ja bekannt, dass die aus Aluminium gefrästen MacBook Versionen (auch Unibody genannt) keine Firewire Schnittstelle mehr besitzen. Da das Booten von USB Platten jedoch bei Intel Macs funktioniert, wollten wir die Images dann halt darüber einspielen.

Aus Zeitgründen erfasse ich hier mal nur das Fazit – das könnte ggf. für andere nützlich sein:

  • Starten/Booten von einer externen USB Festplatte (z.B. um dann mittels CarbonCopyCloner oder SuperDuper ein vorbereitetes Image einzuspielen) klappt generell bei Macs nicht mit jeder USB HDD. Ein Modell von LACIE tat an anderen Intel Macs jedoch problemlos seinen Dienst.
  • Auf dem Unibody MacBook klappte dies mit keiner angeschlossenen (eigentlich startfähigen) USB Festplatte.
  • Unsere Vermutung, die der Gravis Support bestätigte: Die neuen MacBook Laptops haben einen NVIDIA Chipsatz, der die vorher verbauten Intel Komponenten ablöste (vermutlich sind die spezifischen Treiber hierfür schlichtweg nicht per Softwareupdate verteilt worden). Ohne diese Treiber kann der Rechner jedoch nicht vom auf der externen Platte befindlichen Image starten 🙁
  • Wir hoffen, dass sich das Problem mit dem Update auf Mac OS 10.5.6 lösen wird.
  • Workaround: Glücklicherweise hat Apple den Migrationsassistenten erheblich verbessert, mit diesem konnten wir problemlos das auf einer externen Platte befindliche Image nebst aller Software übertragen.

Ich liefere noch mal einen Artikel nach, wenn aus den Vermutung hinsichtlich der Chipsatz-spezifischen Treiber Gewissheit geworden ist 😉