Sonntag, 25. Mai 2014
Ergänzungen meiner IT-Installation machten es kürzlich nötig, dass ich neu auch unter Mac OS X curlftpfs einsetze, um per FTP von bestimmten Web-Sites Sicherheitskopien anzufertigen (Stichwort: Vagrant und puPHPet, dank an Christian für die „Erleuchtung“!)
Entweder hat sich curlftpfs in der Zwischenzeit weiterentwickelt, oder unter Mac OS X läuft der „Karren“ etwas anders. Auf jeden Fall habe ich bei der Adaptierung meiner Linux-Scripte unter Mac OS X folgendes gelernt:
MacPorts
curlftpfs installiert man sich folgendermassen:
# port install curlftpfs
Wenn man curlftpfs dann zum ersten Mal ausführt, warnt einem Mac OS X (hier: 10.9 Mavericks), dass man eine Kernelextension aktiviert, welche von einem unbekannte Entwickler kompiliert wurde. Henusode … (NSA lässt grüssen). Die Warnung ist seither nie mehr aufgetaucht; ich hoffe, dass dies auch nach einem Reboot so bleibt.
Geduldiges mounten
In Tests hat sich herausgestellt, das das Mounten von FTP-Volumen längert dauert als unter Linux. Meinem Script habe ich deshalb folgendermassen Geduld beigebracht:
...
MAXIMUMITERATIONS=5000
...
TIME=$(date +%H:%M:%S)
echo -n "Checking whether mountpoint is populated ($TIME): "
COUNTER=0
while [ ! -d "$SOURCE" ]
do
let COUNTER=COUNTER+1
echo -n "."
if [ "$COUNTER" -eq "$MAXIMUMITERATIONS" ]
then
echo "Mountpoint still not available after $COUNTER iterations. Aborting."
exit 1
fi
done
...
In der Variable $SOURCE ist der Pfad zu einem auf dem FTP-Server vorhandenen Unterordner gespeichert. Sobald bash meldet, dass dieser nun verfügbar ist, kann ich mit den Kopieraktionen beginnen.
Zugriff verweigert
Bei den Tests traf ich auch auf ein Berechtigungsproblem: Manchmal wurde rsync beim Traversieren von FTP-Ordnerstrukturen der Zugriff verweigert. Nach einigem Pröbeln realisierte ich, dass einige Ordner auf den FTP-Servern das Execution-Bit nur für den Owner gesetzt hatten, nicht aber für die Gruppe oder gar Dritte. In einem Fall passte ich die Berechtigungen über den FTP-Client meiner Wahl an, in einem anderen Fall war ich mir todsicher, dass ich allen Serverbenutzern definitiv keine Berechtigung zum Lesen aller meiner Dateien geben wollte. Was nun?
Folgende Option verhindert, dass curlftpfs respektive FUSE bei FTP-Verbindungen Berechtigungschecks durchführen (dies ist hier Aufgabe des FTP-Servers — gibt dieser Zugriff auf eine Datei, hat definitiv schon eine zuverlässige Authentifizierung und Authorisierung stattgefunden):
$ curlftpfs -o defer_permissions ...
Zeichensalat
In meinem älteren Blog-Artikel zu curlftpfs habe ich gezeigt, wie der Zeichensatzproblematik unter Linux begegnen kann. Unter Mac OS X klappt dies so nicht. Stattdessen sind folgende Werte an curlftpfs zu übergeben:
$ curlftpfs -o modules=iconv,from_code=latin1
Quelle: International characters (e.g. Swedish åäö) in remote file system folder names makes Finder hang #71
Den Ausgabezeichensatz finden FUSE respektive curlftpfs offenbar selber heraus.
Dem Parameter from_code ist natürlich der Zeichensatz des FTP-Servers mitzugeben. Es sind alle iconv bekannten Zeichensätze konfigurierbar:
$ iconv -l
In Verbindung mit rsync führt dies aber zum unerwünschten Verhalten, dass Verzeichnisse und Dateien mit Umlauten im Namen bei jeder Synchronisation erneut heruntergeladen werden (ich bin unschuldig, das war ein anderer Benutzer des Servers!).
