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.

Asus Eee PC mit Ubuntu 10.10 (Maverick Meerkat)

Auch wenn mein Apple MacBook Pro (13.3 Zoll) ja schon recht handlich ist, so wäre als Reisebegleiter weniger Gewicht und weniger Größe durchaus nett – ich teste daher gerade einen Asus Eee PC (danke an die Kollegen von make.tv für die Leihgabe!).

An Windows mag ich mich aber nicht gewöhnen müssen. Als erstes wurde daher ein Image der bestehenden Platte gemacht und das installierte Windows XP durch ein Ubuntu 10.10 (Maverick Meerkat) ersetzt.

In Ermangelung eines internen CD-/DVD-Laufwerks wollte ich vom USB Stick booten, dies schlug aber fehl. Trotz verschiedener USB Sticks, trotz der Erstellung des bootfähigen Images unter Linux und Mac OS hat der Eee PC partout nicht vom USB Device booten wollen. Mit einem externen USB CD-Laufwerk hingegen klappte die Installation ohne Probleme – bis auf eine Kleinigkeit, die aber schnell zu beheben war:

Displayhelligkeit

Das Display gibt erst einmal ein enttäuschendes Bild ab: Es ist nach der Installation dunkler als beim vorher installierten Windows und läßt sich über die Einstelldialoge von Ubuntu ebenso wenig gut einstellen wie über die Funktionstasten: Die Helligkeit „springt“ zwischen den Stufen stark hin und her – und bei Einstellungen über 79% Bildschirmhelligkeit wird es wieder dunkler (!).

Die Lösung hierfür ist schnell und einfach, gefunden im Blog von Tom Schimana:

Datei „/etc/default/grub“ editieren:

vi /etc/default/grub

Dort zur Zeile GRUB_CMDLINE_LINUX_DEFAULT navigieren und hier folgende Änderung vornehmen bzw. die Zeile durch diesen Text ersetzen:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi=Linux"

Mit sudo update-grub2 die Änderungen speichern bzw. die Grub Konfiguration erzeugen, reboot und schon ist das Problem gelöst…

Zwischenfazit

Nachdem nun der Monitor hell strahlt, bin ich mit dem ersten Eindruck sehr zufrieden. Natürlich ist so ein Asus Eee PC kein Ersatz für mein Apple MacBook Pro, aber mit ca. 250.- Ladenpreis kostet das Netbook schließlich auch nur ca. ein Drittel…

Ich nutze den Rechner jetzt ein paar Tage zu Hause und entscheide, ob ich damit in unserer Ferienwohnung im Urlaub für ein paar Stunden arbeiten kann. In dem Falle bleibt der Apple zu Hause – das Asus Gerät ist leichter, kleiner und im Falle eines Diebstahls eher zu verschmerzen 😉


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/

VirtualBox Images kopieren; Netzwerkinterfaces eth0, eth1, eth2…; Netzwerk funktioniert nicht?

Kopiert man VirtualBox Images mit Linux-Systemen als Gast (zumindest Ubuntu und Debian, ggf. weitere), funktionieren oftmals die Netzwerkeinstellungen nicht mehr.

Dies liegt daran, dass bei VirtualBox i.d. Regel nur das Festplatten-Image, nicht jedoch die Konfiguration der virtuellen Hardware kopiert wird (wie das z.B. bei vmWare der Fall ist). Vergleichbar ist dies also mit dem Einbau der Festplatte in eine andere Rechner-Hardware.

Um zu verhindern, dass Netzwerkkonfigurationen z.B. durch den Einbau neuer Hardware ungültig werden, werden die Konfigurationen (z.B. für das Device eth0) an die Hardwareadresse (MAC-Adresse) der jeweiligen Netzwerkkarte gebunden.

Das heisst also:

  • bei der Neuinstallation eines Linux-Systems befindet sich eine Netzwerkkarte im Rechner
  • diese wird als eth0, also als erstes Netzwerkdevice am Bus identifiziert
  • das Betriebssystem speichert in der Datei /etc/udev/rules.d/70-persistent-net.rules die Zuordnung dieser Netzwerkkarte (über die MAC-Adresse) zum Devicenamen „eth0“
  • die Netzwerkkarte bzw. das Netzwerk wird konfiguriert (feste IP-Adresse vs. DHCP etc.) in der Datei /etc/network/interfaces

Der Eintrag in o.g. /etc/udev/rules.d/70-persistent-net.rules sieht ungefähr wie folgt aus:

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="6c:62:6d:0d:9c:93", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Wird nun das Festplattenimage auf einen anderen Rechner kopiert, so wird i.d. Regel eine neue virtuelle Maschine angelegt, wobei VirtualBox automatisch eine zufällige MAC-Adresse für die virtuelle Netzwerkkarte erzeugt.

Beim Start erkennt das Linux-System dann ein neues Interface und trägt dieses in der Datei /etc/udev/rules.d/70-persistent-net.rules ein. Da die bisher verwendete ID (in unserem Beispiel eth0) ja bereits vergeben ist, wird entsprechend hochgezählt: Die neue virtuelle Karte erhielte dann z.B. eth1.

Da in /etc/network/interfaces die Konfiguration jeweils für das spezifische Device definiert wird (z.B. eth0), greift sie entsprechend für eth1, eth2, eth3 etc. nicht – das Netzwerk funktioniert also nicht, da das in der VM verfügbare Netzwerkdevice noch unkonfiguriert ist.

Es muss also vor dem Start des Gastes manuell eingegriffen werden. Hierfür kommen 3 Optionen in Betracht:
weiterlesen »

rsync über FTP mit fuse

Es ist schon spät, daher eine eher Staccato-artige Zusammenfassung in der Hoffnung, dass das noch für andere hilfreich sein könnte:

Problem:

Man will Daten von Server A (unter Linux, voller Zugriff) auf oder von Server B (nur FTP, kein anderer Zugriff) kopieren bzw. mit diesem Server abgleichen (Konkreter Anwendungsfall: Man will verschiedene WordPress Installationen nebst Plugins automatisiert von einem zentralen Server updaten).

Normalerweise nähme man rsync – hätte man weiter reichenden Zugriff auf Server B als eben FTP:

Lösung:

Die benötigten Pakete installieren mit dem $Installer-Deiner-Wahl, hier z.B. mit apt:

apt-get install curlftpfs

Abhängigkeiten sollten dann (wenn man etwas taugliches nutzt) automatisch aufgelöst werden, das Paket curlftpfs hängt natürlich vom fuse ab. Falls das nicht automatisch passieren sollte, bitte manuell nachhelfen:

apt-get install fuse-utils libfuse2

Dann ein Verzeichnis anlegen, in das wir später das „FTP Laufwerk“ mounten wollen, z.B.

mkdir /home/www/mount/servername

Nun das FTP Share mounten:

curlftpfs USERNAME:PASSWORD@SERVER-ADRESSE /home/www/mount/servername/

Und vóila: Der FTP Server sollte nun über das lokale Dateisystem verfügbar sein und somit plötzlich auch für rsync.

Bei der rsync Anwendung sind aber ein paar Sachen zu beachten, da ansonsten stets Fehler auftreten (Dateien können nicht geschrieben werden etc.).

Man will z.B. die sonst sehr gern genommene Option „-a“ oder, mein Klassiker, „-avz“ nicht nutzen. Mit dieser Option wird u.a. versucht, den Eigentümer oder die Gruppe einer Datei zu setzen. Dies schlägt auf dem FTP Server im Zweifelsfalle fehl, wodurch der Vorgang nicht komplett abgeschlossen werden kann. Ferner versucht rsync stets, das TMP-Verzeichnis innerhalb der tranferierten Daten abzulegen – was wiederum zu Problemen führt.

All diese Probleme kann man wie folgt umschiffen:

rsync -rltv --temp-dir=/tmp/ --stats --progress /home/www/wordpress-update/ /home/www/mount/servername

Mein aktueller Anwendungsfall war ja das Updaten von WordPress Installationen – hierbei will man einige Dateien auf keinen Fall überschreiben (die Konfigurationsdatei, die XML-Sitemap des Google-Sitemaps-Plugins und die .htaccess). Da die Anzahl der auszuschließenden Dateien recht gering ist, kann man das noch prima mittels --exclude machen:

rsync -rltv --temp-dir=/tmp/ --stats --progress --exclude=wp-config.php --exclude=robots.txt --exclude=sitemap* --exclude=.htaccess --exclude=wp-content /home/www/wordpress/ /home/www/mount/servername

Weiteres und eine auführlichere Beschreibung vielleicht schon morgen, jetzt muss ich erstmal schlafen 😉

Danke für die Anregungen/Ideen an: blog.simlau.net, lieber-linux.de, stackoverflow.com, debiantutorials.net und commandlinefu.com.

Entscheiden Sie sich für WINDOWS, wenn Sie keine Erfahrung mit Computern haben

Sehr schön, was ich gerade bei Dell sehen durfte 🙂

Irgendwo hatte der Texter recht, irgendwo auch nicht: In der Tat würde wohl nur jemand, der keine Erfahrung mit Computern hat, Windows wählen – aber ist er/sie damit dann wirklich gut beraten? 😉