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.

Apple Mac OS X auf Standard PC Hardware (OSX86 / Hackintosh / HackMac) oder wie man günstig an einen Mac Pro kommt…

Schon seit ein paar Jahren kann ich ich ja privat und am Arbeitsplatzrechner auf umfangreiche Wartungsarbeiten verzichten – weil der Mac OS Rechner in der Tat wenig Ärger macht. Ich kann mich somit zumeist meiner Arbeit widmen, statt Unzulänglichkeiten des Betriebssystems auszubaden.

Als nun ein neuer Rechner für daheim anstand, war das bevorzugte OS also bereits entschieden. Man könnte annehmen, dies sei auch bereits eine Hardwareentscheidung – dem ist aber nicht so, schließlich läuft das Mac OS X auch ganz wunderbar auf normaler PC-Hardware, wenn man die richtigen (also unterstützten) Komponenten auswählt.

Klar, so einfach mit mit „echter Mac Hardware“ geht die Einrichtung natürlich nicht, aber es lohnt sich dennoch, weil…

  • so ein „Hack-Mac“ unterm Strich viel mehr Leistung fürs Geld bietet als echte Mac Hardware (die im folgenden näher beschriebene Konfiguration kostete z.B. insgesamt ca. 1.240 EUR netto, entsprechend ca. 1.470 EUR inkl. Mehrwertsteuer – was in Anbetracht der Leistung mehr als erschwinglich ist)
  • man unter dem Tisch nicht sieht, ob der Rechner in einem hübschen Apple Gehäuse steckt oder nicht
  • man kann sich etwas sehr nettes genau nach den eigenen Vorstellungen zusammenstellen, und bekommt den Rechner, den nicht wenige bei Apple vermissen: das Modell zwischen dem Apple iMac 27 Zollund dem Apple Mac Pro (siehe auch dieser Apple Mac Pro)

weiterlesen »

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 😉

OpenVPN mit Mac OS – Viscosity oder Tunnelblick

Tunnelblick-Logo-Big

In der Vergangenheit unterstützte der für Mac OS X (kompatibel zu 10.4, 10.5, 10.6 und wohl auch den Folgeversionen) verfügbare OpenVPN Client namens „Tunnelblick“ leider keine DNS Auflösung. Konkret hiess das, dass man zwar die VPN Verbindung problemlos herstellen konnte, aber alle im VPN liegenden Adressen (z.B. bei uns den Firmen Mailserver, das Intranet oder die Entwicklungsserver) z.B. in die lokale Hosts Datei schreiben musste – wenig komfortabel.

screenshot_ 2010-01-30 um 15.49.12Um den Pflegeaufwand zu minimieren, kam nun einige Monate auch Viscosity zum Einsatz, ein kommerzieller VPN Client für Apple Systeme (und mit 9 $ auch erschwinglich). Eigentlich ist das ein recht durchdachtes Tool: Es importiert bestehende Verbindungen (z.B. aus Tunnelblick) hat ein aufgeräumtes Interface und bot eben die beschriebene DNS Unterstützung.

Seltsamerweise wollte Viscosity aber ab heute auf 2 Rechnern sein Icon in der Menüleiste nicht mehr anzeigen – was es de facto unbenutzbar macht (der „Verbinden“-Button ist nur über die Menüleiste zu erreichen). Das Programm lief zwar stets im Hintergrund, aufgrund der Nichtzugänglichkeit war dies aber wertlos..

Es scheint auch ein Problem vorzuliegen – zumindest lesen sich die Logfiles so:

(...) 30.01.10 13:01:11 Viscosity[360] : invalid literal for int() with base 10: 'unknown'

30.01.10 13:07:18 [0x0-0x29029].com.viscosityvpn.Viscosity[360]

Sat Jan 30 13:07:18 computername.tld Viscosity[360] : kCGErrorIllegalArgument: CGSUnregisterWindowWithSystemStatusBar: Invalid window

30.01.10 13:07:18 [0x0-0x29029].com.viscosityvpn.Viscosity[360]

Sat Jan 30 13:07:18 computername.tld Viscosity[360] : kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.

30.01.10 13:09:19 Viscosity[242] : invalid literal for int() with base 10: 'unknown' (...)

Falls jemand das gleiche Problem haben sollte (hier aufgetreten mit Mac OS X 10.6.2), lohnt vielleicht ein Blick in das Supportforum, wo ich die Beschreibung auch erfasst habe. Vielleicht kommt hier ja ein Lösungsweg durch den/die Entwickler: http://www.viscosityvpn.com/forum/viewtopic.php?f=3&t=219

Tunnelblick-LogoAufgrund des Viscosity Problems habe ich soeben mal wieder Tunnelblick probiert und siehe da: Die DNS Auflösung klappt problemlos, somit ist Viscosity ab sofort ohnehin nicht mehr das bevorzugte Produkt 😉 (Viscosity ist ein kommerzielles Produkt unter proprietärer Lizenz; Tunnelblick ist ein Open Source Produkt unter der GPL…)

Sehr interessant an Tunnelblick ist aber noch etwas anderes:

Im Tunnelblick Wiki gibt es eine eine Dokumentation dazu, wie man ein Deployment einrichten kann (also z.B. die Software zentral für die User innerhalb eines Firmennetzwerkes installieren und einrichten).

Mehr Infos zu Tunnelblick und der Download sind verfügbar auf der Google Code Seite des Projekts.