Kategorie: Datensicherung

Ein paar wissenswerte Anmerkungen zu IMAP mit PHP

Da ich kürzlich ein Hostingpaket eines Kunden von einem Hoster zum nächsten umziehen sollte, stellte sich das Problem der Postfach-Migration.

Da der Kunde alle E-Mails per IMAP abruft, waren alle Mails auf den Servern des Alt-Hosters gespeichert. Es handelte sich um eine hohe zweistellige Anzahl an Postfächern, von denen viele eine fünfstellige Anzahl an E-Mails beherbergten und Größen im zweistelligen GB-Bereich erreichten.

Früher hätte man das mit IMAPSize relativ einfach erledigen können, aber seit SSL üblich ist, funktioniert IMAPSize halt meist nicht mehr; so auch in diesem Fall. Thunderbird & Co. strecken bei solchen Postfächern ebenfalls meist die Hufe.

Eine Suche nach “IMAP Mail Migration / Umzug” brachte als brauchbare Lösung nur Mailstore Server zu Tage. Allerdings bei dieser Anzahl an Postfächern auch nicht direkt zu einem kleinen Kurs für einen kleineren Gewerbetreibenden.

Nun gut, dann halt per Script. Da gibt es ja bestimmt etwas brauchbares. In Perl gibt es tatsächlich etwas, aber Perl gehört nicht zu meinen üblichen Spielwiesen. Und es gibt auch etwas in PHP. Allerdings war das relativ grob zusammengeschustert und tat nur ansatzweise, was es sollte. Also blieb nur, die Anregungen aus den vorhandenen Scripten aufzunehmen und selbst etwas zu bauen.

Aufgrund der Größe der Postfächer war klar, dass es mit den begrenzten Scriptlaufzeiten auf dem Webserver sicherlich keinen Erfolg geben wird. Also muss man auf die Shell ausweichen.

Ohne zu sehr ins Detail gehen zu wollen, ergaben sich dabei ein paar interessante Probleme:

1. Die Message-IDs innerhalb einer Mailbox (nicht innerhalb des Postfachs) waren nicht eineindeutig, obwohl das so sein sollte.
Warum das wichtig ist, wenn man die Mails doch nur von einem Postfach ins andere Schaufeln möchte? Nun, der Umzug eines Hostingpakets hängt zeitlich von vielen Faktoren ab. Aufgrund der Größe der Postfächer wurden die Postfächer schon im Vorfeld kopiert. Anschließend sollten nur noch inkrementelle Updates gefahren werden.
Um inkrementelle Updates zu realisieren, muss man die E-Mails im alten und neuen Postfach jedoch eindeutig identifizieren können.
Na dann halt eine Kombination aus Message-ID und Zeitstempel im Header der E-Mail. Lustig, denn damit kommen wir zum zweiten Problem:

2. Nicht jede E-Mail hat einen Zeitstempel (Eigenschaft “Date / date” im Header).
Also war eine eindeutige Identifizierung über eine Kombination aus Message-ID und Zeitstempel auch nicht ohne weiteres möglich.
Glücklicherweise verhalten sich die Mail-Server verlässlicher als die absendenden Mail-Clients und -Generatoren. Sie legen tatsächlich im Header jeweils einen “Received”-Eintrag an. Leider geben die PHP-IMAP-Funktionen genau diesen Wert (bzw. diese Werte, da es mehrere Received-Einträge im Header gaben kann) nicht zurück. Es bleibt also nur der Weg, den Header selbst zu zerlegen und den letzten Received-Zeitpunkt zu extrahieren.
Nun kann man anhand der Message-ID und des Zeitstempels alle Mails im Ursprungs- und Ziel-Postfach eindeutig identifizieren und verhindern, dass E-Mails mehrfach übertragen werden.

Zumindest bei E-Mails, die keinen Date-Eintrag im Header haben, sollte man dann beim Aufruf von “imap_append” den Zeitstempel mit übergeben. Interessanter Weise wird im RFC 3501 immer auf RFC 2822 verwiesen. Im Header sind alle Datumswerte auch ganz offensichtlich gemäß der PHP-Konstante DATE_RFC2822 formatiert. Wenn man nun versucht, imap_append mit einem Zeitstempel gemäß RFC 2822 zu füttern, bekommt man die höfliche Notiz, dass diese Angabe ungültig ist. Auch ein reiner Unix-Zeitstempel führt nicht zum Erfolg.
Stattdess muss es ein String gemäß dem Muster date( "d-M-Y H:i:s O", #Unix-Zeitstempel# ); sein. Falls das irgendwo brauchbar dokumentiert ist, war ich jedenfalls nicht in der Lage, es zu finden.

3. Ein weiterer Spaß ist die Kodierung und Struktur der Mailboxnamen (für gewöhnlich als Ordner wahrgenommen). Gemäß RFC 3501 wird eine spezielle Version von UTF-7 für die Kodierung verwendet. Das ist immer dann von Bedeutung, wenn auf dem Quellserver Umlaute für die Mailboxen verwendet werden. Im deutschsprachigen Raum ist das relativ häufig der Fall, da oftmals für die Standard-Mailbox “Drafts” das deutsche “Entwürfe” verwendet wird.
Auch der Delimiter (Hierarchie-Trenner) verdient Beachtung. Während bei der Anlage neuer Mailboxen grundsätzlicher der Slash “/” als Trenner verwendet werden kann, gilt dies auf dem Quellserver für den lesenden Zugriff nicht. Hier heißt es unbedingt mit “imap_getmailboxes” die Mailboxen abzufragen, wobei die Eigenschaft “delimiter” mit übergeben wird, welche man dann zwingend als Trenner auf dem Quellserver verwenden muss.

4. Die Funktion “imap_rfc822_parse_headers” schmiert sehr elegant mit einem “Fatal error” ab, wenn der Header einer E-Mail die Größe von 16 KB übersteigt. Üblicherweise sind Header eher um die 4 KB groß, aber ganz gelegentlich gibt es halt mal Ausreißer. Da hilft nur, den zu übergebenden Header abzuschneiden…

Nachdem alle diese Fallstricke umgangen waren, stand einer erfolgreichen Mail-Migration nichts mehr im Weg. ABER!

Tatsächlich war bei einigen E-Mails der Aufruf von imap_append nicht erfolgreich. Es gab die freundliche Warnung “Can’t save a zero byte message (0.001 + 0.000 secs)”. Zu Analysezwecken habe ich diese Mails dann in EML-Dateien geschrieben und näher angeschaut. Es handelte sich bei diesen E-Mails ausschließlich um Spam-Mails, die nicht wohlgeformt waren.
Damit der Kunde die Diskrepanz zwischen Quell- und Zielpostfach versteht, ließ ich also ein Logfile mitlaufen und exportierte nicht migrierbare in EML-Dateien, um diese zu übergeben.

Wie kann ich eine WordPress-Installation möglichst schnell und elegant umziehen?

Neben der “klassischen” Methode (Dateien einzeln per FTP herunterladen, DB-Backup per PHPMyAdmin erstellen) gibt es auch noch den etwas eleganteren Umweg über die Kommandozeile.

Oftmals hat man jedoch in einfacheren Hostingpaketen keinen Zugriff per Telnet oder SSH. Allerdings lassen sich fast immer trotzdem Systembefehle absetzen.

Diesen Umstand kann man sich für eine schnelle Erstellung von Backups von Code und DB zu nutze machen.

Backup DB:
system("mysqldump --opt -Q -h DB-ALT-HOST -u DB-ALT-USER -p DB-ALT-NAME --password=\"DB-ALT-PASSWORT\" > ./dbdump.sql",$ret);

Backup Code:
system("tar -zcf ./backup.tar.gz ./*",$ret);

Anschließend werden die beiden erzeugten Dateien per (S)FTP heruntergeladen und auf den neuen Server hochgeladen.

DB einspielen:
system("mysql -h DB-NEU-HOST -u DB-NEU-USER --password=\"DB-NEU-PASSWORT\" DB-NEU-NAME < ./dbdump.sql");

Code entpacken:
system("tar -xvzf ./backup.tar.gz ",$ret);

Anschließend müssen in der Datei “wp-config.php” noch die neuen DB-Daten eingetragen werden.

Hinter den DB-Daten müssen dann noch die beiden Zeilen für die neue Domain eingetragen werden:
define('WP_SITEURL', 'http://www.neue-adresse.de');
define('WP_HOME', 'http://www.neue-adresse.de');

Weiterhin sollte noch folgende Zeile eigefügt werden:
define('RELOCATE', true);

Anschließend muss die Login-Seite aufgerufen werden:
http://www.neue-adresse.de/wp-login.php

Diese Zeile wird noch vor dem Ausfüllen des Login-Formulars wieder entfernt.

Im Dashboard dann ein Plugin, z.B. “Better Search and Replace”, installieren und die alten URLs in der Datenbank durch die neuen URLs ersetzen.

WordPress zeigt nach dem Umzug keine Stylesheets oder Bilder an oder beim Versuch auf wp-admin zuzugreifen wirft der Server einen Fehler 403

Insbesondere beim Umzug zu einem neuen Hoster kann es vorkommen, dass beim Kopieren oder Entpacken der Dateien die Verzeichnisrechte nicht korrekt übernommen werden.

Dieses Problem lässt sich relativ leicht beheben, indem in einem FTP-Programm alle Verzeichnisse (rekursiv!) die Rechte 755 und alle Dateien die Rechte 644 zugewiesen bekommen.

Sollte man Zugriff auf die Serverkonsole, bspw. per SSH, haben, kann das Problem deutlich schneller gelöst werden, indem im WP-Stammverzeichnis folgende Befehle ausgeführt werden:
find ./ -type d -exec chmod 755 {} +
find ./ -type f -exec chmod 644 {} +

Kopieren / Clonen einer Festplatte mit defekten Sektoren (oder auch ohne)

Hardwarebetreuung – egal ob einzelene Rechner oder ganze Netzwerke – waren mein erstes Standbein. Irgendwann war ich aber genervt von den wiederkehrenden Problemen mit Netzwerkdruckern, nicht gepflegten Backups etc. Also habe ich diesen Zweig meiner Tätigkeiten ad acta gelegt.

Privat kommt man aber trotzdem nicht darum herum, sich gelegentlich mit defekten Festplatten & Co. auseinanderzusetzen. Aktuell hatte eine Freundin ein “kleines” Problem mit ihrem Laptop. Um es genau zu sagen, die Festplatte hatte diverse defekte Sektoren und das System (Windows 7) fuhr nur noch unter Protest und endlos langen Festplattenüberprüfungsvorgängen hoch. Immerhin!

Sie besorgte also auf meinen Rat hin eine neue 500 GB SSD von Samsung. Die Dinger laufen in mehreren meiner Rechner seit geraumer Zeit ohne zu mucken. Die von Samsung mitgeliefert Clone-Software funktioniert normaler Weise auch sehr zufriendstellend und kopiert selbst die Systempartition aus dem laufenden Betrieb heraus lauffähig auf die neue SSD. Leider verweigert sie den Dienst, wenn sie auf defekte Sektoren trifft.

Also musste eine andere Variante her. Ich probierte es mit der Live-CD von GParted, aber auch hier waren die defekten Sektoren der Knackpunkt.

Letztendlich landete ich bei Ubuntu Rescue Remix. Die aktuelle Version (zur Zeit 12.04) war schnell als ISO heruntergeladen, auf eine CD gebrannt und im Laptop gestartet.

Nach dem Hochfahren der Live-CD lässt man sich mit

die vorhandenen Festplatten anzeigen. In meinem Fall hatte das (leicht defekte) Quelllaufwerk die Bezeichnung /dev/sda und die neue SSD am USB-SATA-Adapter die Bezeichnung /dev/sdb.

Den ersten Kopierdurchgang startet man dann mit

-n (–no-split) sorgt dabei dafür, dass er sich nicht lange an defekten Dateien aufhält, sondern erstmal das rettet, was problemlos lesbar ist.

–force sorgt dafür, dass die neue SSD tatsächlich komplett überschrieben wird.

Nachdem dieser erste Kopiervorgang durchgelaufen ist, kann man dann, sofern es Probleme mit dem Quelllaufwerk gab, einen zweiten  Kopiervorgang starten:

-d (–direct) sorgt dafür, dass direkt auf die Festplatte zugegriffen wird.

-r3 (–max-retries=3) sorgt dafür, dass drei Mal versucht wird, defekte Sektoren einzulesen.