RSS

rsync über FTP mit fuse

2. April 2010 – 02:36

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.




Von AS | Abgelegt unter Allgemeines, Hosting & Cloud Computing, Systemadministration | Mit Schlagworten , , , , | Kommentare (0)

OpenVPN mit Mac OS – Viscosity oder Tunnelblick

30. Januar 2010 – 16:13

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.




Von AS | Abgelegt unter Off-topic: Apple/Mac & iPhone, Software, Systemadministration | Mit Schlagworten , , , , , | Kommentare (0)

Kurznotiz: XSL Cache leeren

27. Januar 2010 – 22:40

Bei Projekten mit intensiver Nutzung von XSL bzw. XSLT macht die Verwendung des XSL Bytecode Caches sehr viel Sinn, siehe dazu auch diese sehr umfassende Erklärung meines Kollegen Max.

Wichtig ist aber auch, wie sich der Cache hier verhält – und das ist bei der NY Times, welche die Extension “XSLCache” entwickelt hat, nachzulesen:

Neulich hatten wir die Aufgabe, in einem Projekt den XSL Cache zu “refreshen” – ohne jedoch die Webserver neu starten zu wollen. Es gibt da eine sehr simple und schnelle Lösung (Doku hier bei der NY Times):

The XSL cache uses the modification time (mtime) attribute of stylesheets to figure out if a file is newer than the cached version and needs to be updated. There are several cases where a file might change but the modification time remains old that you should avoid if you want the XSL cache to reload changed stylesheets correctly:

tar and rsync/scp can sometimes preserve the modification time of the archived/copied file. You must be careful about the following:

  • tar, use the -m flag
  • rsync, avoid using the -t/–times flag
  • scp, avoid using the -p flag
  • Be careful about radically adjusting the system clock and modifying XSL files. Similarly, clock skew between web servers and NFS shares may create issues.
  • If all else fails, use touch to clear a stylesheet from the cache, by resetting its last modified timestamp.

In addition, this early release of XSL Cache does not use shared memory, so each PHP process/thread will have its own copy of the stylesheet. Although this is admittedly wasteful, the memory cost does not seem to be costly. However, if you use the cachesheet argument to clear a cached stylesheet from one web server process, it may still be cached in other processes.

(Quelle: http://code.nytimes.com/projects/xslcache/wiki/StaleCaches)




Von AS | Abgelegt unter CMS / Content Management Systeme, Development, Performance, Systemadministration | Mit Schlagworten , , , | Kommentare (0)

Notiz: in .procmailrc mehrere Regeln gleichzeitig nutzen

5. Januar 2010 – 10:53

Nachdem ich das immer wieder suchen muss…

Bekanntlich ist .procmailrc ein irrsinnig mächtiges Tool zur Filterung von E-Mails. Die Syntax einer Regel sieht im groben so aus:

Filtern nach Mailadresse

:0
* ^To:.*mailadresse@domain.tld
$MAILDIR/unterpfad/zielordner

Ebenfalls filtern nach Mailadresse, allerdings verschiedene Regeln mit “ODER”-Verknüpfung

:0
* ^To:.*mailadresse@domain.tld|To:.*mailadresse2@domain.tld
$MAILDIR/unterpfad/zielordner

Und was ich immer vergesse: Die “UND”-Verknüpfung

(hier: “To” Adresse und “Delivered-To” Adresse müssen treffen)

:0
* ^To:.*mailadresse@domain.tld
* ^Delivered-To:.*mailadresse2@domain.tld
$MAILDIR/unterpfad/zielordner




Von AS | Abgelegt unter Allgemeines, Systemadministration | Mit Schlagworten , , | Kommentare (1)

Kurzmitteilung: Eigene IP-Adresse in Spamlisten bzw. Spamblock-Listen prüfen

14. August 2009 – 10:53

Um nachzuprüfen, ob ein Mailserver in gängigen Antispam- bzw. Spamblocklisten enthalten ist, habe ich bisher immer direkt die in Frage kommenden Anbieter aufgesucht und dort jeweils nach der IP-Adresse gesucht.

Ich bin gerade über dieses sehr coole Frontend bei heise.de gestolpert – das ist nicht nur praktisch (weil eine gleichzeitige Anfrage an verschiedene Dienste möglich ist, also eine Metasuche), sondern sehr praktisch (weil es einen Link gibt, mit dem man sich die Suche gleich als Suchdienst in Firefox einrichten kann) :-)

Eigene IP-Adresse in Spamlisten prüfen

Weitere Apps aus dem Bereich “Netze” bei Heise




Von AS | Abgelegt unter Development, Hosting & Cloud Computing, Systemadministration | Mit Schlagworten , , , , , , | Kommentare (0)