In einigen Distributionen (z.b. CentOS 6 oder Ubuntu 12.04 LTS) wird derzeit als Paket noch immer nur Version 0.6.18 von Duplicity (für eine vereinfachte Konfiguration kann ich Duply empfehlen) ausgeliefert und das kann einen vor ein „größeres“ Problem stellen. Besagte Version kommt bei SSH-Verbindungen nur mit dem Standard-Port 22 klar und liefert leider auch nur eine etwas irreführende Fehlermeldung („BackendException: ssh connection to domain.com:1234 failed: Unknown server domain.com“). Sucht man nach besagter Fehlermeldung und durchstöbert die Mailinglisten und Forenbeiträge kann man das Problem eingrenzen (i.d.R. liegt es an einem fehlenden „known_hosts“-Eintrag oder eben an einer ignorierten Portangabe). Die Lösungsvorschläge sind:

1. Update
2. Patchen einer bzw. mehrerer Dateien
3. Ändern des Ports bzw. Verwendung einer anderen Verbindungsart

Auf die Schnelle konnte ich für CentOS leider keine aktualisierte Version von Duplicity als RPM finden und ein manuelles Update kam nicht in Frage (ich wollte auf dem Produktivsystem keine „unnötigen“ Pakete installieren). Das Patchen empfand ich auch als zu mühsam, zumal sich der eine oder andere Eintrag auch widersprach und ich keine Lust auf langwieriges „trial and error“ hatte. Eine Änderung des Ports auf dem anderen Server wollte ich eigentlich auch nicht machen und eine andere Verbindungsart stand auch nicht zur Debatte.

Da ich kurz zuvor auf einem anderen Server an der Firewall basteln musste, ist mir ein „einfacher“ Workaround eingefallen. Wie wärs mit dem „vortäuschen“ eines SSH-Servers auf dem Standardport durch eine entsprechenden „Firewall“-Regel auf dem Zielserver?

iptable -t nat -A PREROUTING -i eth0 --src 123.123.123.123/32 -p tcp --dport 22 -j REDIRECT --to-ports 1234

Ist sicherlich nicht die schönste Variante, in meinem Fall aber zum einen Möglich (wg. des entsprechenden Zugriffs auf dem Zielserver) und zum anderen auch ohne groß in die Systeme einzugreifen.

Leider bietet der Finder in OS X keine Möglichkeit des „integrierenden Kopierens“. Beim kopieren können – mir unverständlicherweise – nur Verzeichnisse ersetzt werden, nicht ab aber die Inhalte der Quelle in den Zielordner kopiert werden, ohne andere schon vorhandene Dateien zu löschen.

» weiterlesen…

Seit ein paar Stunden gibt es nun WordPress 2.9. Die wichtigsten Neuerungen sind im offiziellen Blog zu finden (Mülleimer, Bildeditor, Stapelupdate für Plugins und leichtere Einbindung vo Videos).

Entgegen den Problemen von manch Anderem, gab es bei mir im Blog – wie auch die letzten Male – keine Probleme beim Update (zumindest bin ich noch über keine gestolpert). Auch meine Plugins scheinen mit Version 2.9 von WordPress problemlos zusammenzuarbeiten.

Dennoch gibt es einen kleinen Punkt der mich stört, der Speicherverbrauch scheint wieder etwas gestiegen zu sein. Statt vorher 32,5MB braucht die Startseite nun 33MB (memory_get_peak_usage)…

Wie immer gilt, vor nem Update empfiehlt es sich ein Backup zu machen, falls doch einmal etwas schief geht :)

Vor kurzem hatte ich ja schon darüber berichtet, ich durfte einmal mehr einen Server durch einen neuen Server ersetzen (mod_fastcgi -> mod_fcgi). Eine weitere Änderung gab es nun beim Backup.

Für inkrementelle Backups auf unsichere Medien (FTP) setze ich schon seit langem auf Duplicity. Für die leichtere Konfiguration/Bedienung kam bei mir bisher Ftplicity zum Einsatz. Doch leider wurde dieses von heise.de entwickelte Skript nicht mehr gepflegt. Aber es gibt Ersatz: Duply. Duply kann alles was auch Ftplicity kann und noch ein paar Dinge mehr. Es wird auch (noch) aktiv weiterentwickelt (und insbesondere an aktuelle Versionen von Duplicity angepasst).

Im Zuge der Umstellung habe ich nun auch die bisherige „ich sichere einfach alles in einem Backup-Strategie“ gesplittet in System- und „Webseiten“-Backups (inkl. DB). Warum? Änderungen am System sind seltener (und bei grösseren Änderungen kann man ja noch schnell ein manuelles Backup machen) und ein Backup einmal die Woche sollte dafür eigentlich ausreichend sein. Bei Webseiten/DB sieht es allerdings anders aus, hier sind möglichste aktuelle Backups interessant (wenn auch hoffentlich weiterhin nicht wirklich notwendig) und so sollte dies mind. einmal am Tag stattfinden.

Ein kurze Anleitung zur Verwendung von Duplicity + Duply für Backups unter Debian Lenny gibts hier.

Frei nach „Murphy’s Law“: Wenn etwas schiefgeht, dann so richtig. Und so in etwa war mein gestriger Tag. Angefangen hat es damit, das ich wiedereinmal vergeblich auf eine S-Bahn warten durfte. Ansagen kommen i.d.R. erst weit nach der eigentlichen Abfahrtszeit (wenn überhaupt) und somit zu spät um auf Alternativen umzusteigen. Nunja, wie auch immer… bei der Rückfahrt wieder das gleiche Spiel. Grund für die Ausfälle, eine völlig überraschende Weichenstörung die schon seit mind. 24h bestand (aber so schnell kann man darauf ja nicht reagieren). In der Zwischenzeit wurde nun bekannt gegeben, dass die Störung noch bis mind. 16. August besteht (super, bis gestern Abend hoffte man noch, die Störung schnellst möglich beheben zu können).

Aber der Tag war lange nicht um, kaum wieder zuhause erreichte mich die Nachricht, „Der Mailserver geht nicht“. Jegliche Versuche von mir remote darauf zuzugreifen schlugen fehl. Der Server (n Dual Opteron mit 16GB Ram und entsprechend einigen XEN DomU’s) verweigerte jegliche (Mit)Arbeit. Selbst ein (mehrfacher) Reboot brachte keinen Erfolg (auch der RAID-Kontroller meldete keine Probleme). Glücklicherweise liess der Server sich nach einigen Versuchen überreden, Knoppix von CD zu booten (was anderes war gerade nicht vor Ort). Ergo kam ich an die Platten und damit an die aktuellen Daten heran. Beim Packen/Kopieren der Daten hatte ich bei tar dummerweise nicht aufgepasst (ich hatte –numeric-owner vergessen) und somit liessen sich die DomU’s auf einer Ersatzmaschine zwar starten, aber so wirklich ihren Dienst wollten sie nicht verrichten (es stimmten die Datei/Verzeichnissbesitzer einfach nicht mehr). Wie auch immer, auch der Misserfolg (dummerweise dauert das Packen/Kopieren von >50GB doch ein bischen mehr Zeit) konnte mich nicht davon abbringen die 2 wichtigsten DomU’s auf der Erstazmaschine schlussendlich zum Laufen zu bekommen. Alles toll? Denkste, nun wurde der ursprüngliche Server nochmals rebootet und siehe da, er lief wieder ohne Probleme *narf* und ich hatte mir die Mühe gemacht, alles umzuziehen… Zum Glück hatte ich die restlichen DomU’s noch nicht auf dem Ersatzserver eingerichtet. Momentan laufen also 2 DomU’s auf dem Ersatzserver und der Rest noch auf dem eigentlichen Server. Viel Zeit für nichts? Wer weiss, der Server wird nun von mir erstmal noch genauer beobachtet :)

Vorgewarnt, hab ich dann gestern Abend nichts mehr wichtiges angefangen und bin schlafen gegangen.

Unglücklicherweise rechnet Murphy wohl aber nicht in Kalendertagen sondern in 24h Einheiten. Und so durfte ich heute Morgen im Monitoring auch gleich die 100% CPU-Auslastung eines Webservers zur Kenntnis nehmen. Top lieferte auch gleich den Schuldigen, MySQL krallte sich soviel CPU-Power wie nur möglich. Doch wer war der eigentliche Übeltäter. Dank der Einbindung von PHP via FastCGI wurde auch hier schnell ein Prozess ausgemacht. Und schwupps, kaum war die Webseite vom Netz, war auf dem Server wieder alles ruhig. Die Analyse der Logfiles brachte dann dann einen Angriff auf die Webseite über eine IP aus dem lateinamerikanischen Raum zu Tage. Achja, vll. sollte ich noch erwähnen, der Angriff war (zum Glück) eher erfolglos, ausser das der Server über Minuten hinweg mit der 100%-tiger CPU-Last zu kämpfen hatte, ist nichts kaputt gegangen…

Fazit: Die 24h sind nun endlich rum, und ich genehmige mir nun erstmal mein Frühstück :)