Technik

Jeder, der sich schon mal mit mir über das Thema Weblogs unterhalten hat, kennt meinen Erzfeind: Wordpress.

Ich kann diese Software nicht ausstehen, denn der absolut größte Teil der Probleme im Support dreht sich um diese Software. In letzter Zeit wesentlich mehr als früher. Da ich mich Kunden gegenüber aber mindestens neutral verhalten muss und ein "Läuft bei uns halt nicht" für mich selten in die Tüte kommt, so muss ich diesen ganzen Frust in mich rein fressen.

Mir musste auffallen, dass sich Speicherprobleme bei Wordpress sehr oft im Package "pomo" ereignen. Der Name hat mich gleich an das GNU gettext-Projekt erinnert, da dort mit .po-Dateien in .mo-Dateien kompiliert werden um Anwendungen quasi eine Datenbank zur Lokalisierung (bzw. Übersetzung) von Texten bereit zu stellen. Bei Wordpress verhält es sich genau so: "pomo" ist dazu da um Wordpress vom Englischen her in andere Sprachen zu übersetzen.

Auf wordpress.org kann man ebenfalls nachlesen, dass man sich für die Lokalisierung mittels gettext entschieden hat. Sehr schön bis hier hin! Auch wir setzen in unseren Projekten auf diese quasi als Standard etablierte Technik ein - auch wenn ich zugegebener Maßen selbst oft das Rad neu erfinden will. Nur eifert Wordpress mir in dieser Sache etwas hinterher: "pomo" ist eine komplett eigenständige Implementierung, die .mo-Dateien auf dem Server parsed und entsprechend übersetzt - in PHP geschrieben. Ich habe es nun nicht geprüft, aber ich wette nahezu, dass der Code etwas ineffizient ist (warum? Mehr dazu später)

Heute morgen hatte ich irgendwie die Faxen dicke. Es kann doch nicht sein, dass so schöne Grundlagen geschaffen werden aber zum Schluss hin dann nur halbherzig umgesetzt werden. Also habe ich mir ein deutsches Wordpress heruntergeladen und auf einem normalen 64-Bit-System mit PHP (5.3.3) über FastCGI und mit einem Speicherlimit von 28 MB installiert - ein ganz normaler Kundenaccount der Größe "Starter" also - und ich hatte von vorne herein Probleme. Als "jemand vom Fach" für mich eigentlich nur kaum nachvollziehbar und als ich den "pomo"-Teil von Wordpress deaktiviert habe auch sofort weg.

Nun ist das Abschalten sämtlicher Übersetzungsfunktionen keine Lösung. Deswegen habe ich einen kleinen Patch für die Datei wp-include/l10n.php geschrieben und die .mo-Dateien von Wordpress in einer mit gettext kompatiblen Verzeichnis-Struktur abgelegt (Siehe Skript).

Mit dem Patch nutzt Wordpress nun (sofern Verfügbar) die native gettext-Erweiterung von PHP. Und siehe da: Mein Test-Blog ist in deutscher Sprache verfügbar und ich konnte das Speicher-Limit von PHP sogar testweise auf 6 MB herabsetzen (mehr habe ich mich nicht getraut).

Das muss man sich mal vorstellen: Mit einer kleinen Änderung von ca. 30 Minuten habe ich den Speicherbedarf von Wordpress um weit mehr als 75% gesenkt. Wobei man hier zugegeben muss: Ich habe nur auf einem Test-Blog gearbeitet. Folglich funktioniert der Patch nachweislich für eine Standard-Installation - mit einem anderen Theme oder einer Reihe von Plugins habe ich es nicht getestet. Wenn diese aber den etablierten gettext-Richtlinien folgen, sollte das eigentlich kein Problem sein.

Alle Dateien meiner kleinen Wordpress-Exkursion gibt es hier: http://oss.tiggerswelt.net/wordpress/
Ich für meinen Teil bleibe bei Serendipity - damit gab es noch nie Probleme

Nachtrag (17:57):
Habe den Patch etwas angepasst. "build-lang.php" wird nun nicht mehr benötigt, die von mir gepatchte "l10n.php" installiert sich die .mo-files nun nach Bedarf unterhalb der richtigen Text-Domain (sofern die entsprechenden Berechtigungen bestehen, mit unserem Webhosting tut es in der Regel recht gut )

Es hätte so schön sein können: APC und XCache lassen sich problemlos statisch in PHP einkompilieren. Einzeln.

eAccelerator mochte das auf Anhieb nicht so gerne, hätte sich aber bestimmt noch dazu überreden lassen. So weit kamen wir jedoch gar nicht, denn zunächst wagten wir ein Build von PHP mit den beiden zuerst genannten Cachern/Optimizern. PHP baute sich auch wunderschön zusammen, verweigerte danach jedoch komplett den Start, da APC und XCache sich wohl duellierten.

Der Plan war eigentlich eine monolithische Version von PHP zu haben und den bevorzugten Optimizer per php.ini zu aktivieren. Nach dem Motto "Ganz oder gar nicht" haben wir das bisher statisch einkompilierte APC komplett rausgenommen und in den Modul-Build-Prozess neben eAccelerator und XCache integriert.

Die News, die sich hier heimlich eingeschlichen hat, ist eher dass wir nun auch XCache im Angebot haben und dementsprechend auf Kundenwunsch dort hin umschalten können.

Unser Monitoring kann manchmal echt ätzend sein...

Da will man mal ganz normal nachts den Webserver (bzw. httpd) neu starten. Und es schlägt fehl.

Aber warum? Ganz einfach: Nachdem der Webserver heruntergefahren war, hat das Monitoring den Webserver umgehend neu gestartet und war dabei schneller als der eigentliche Skript der die beiden Aufgaben des stoppens und starten ausgeführt hat.

Nun gut, nicht ganz ein Fehlschlag, dennoch gibt es mir zu denken, warum das Monitoring hier schneller war.

Am Wochenende habe ich mich eher in meiner Freizeit hingesetzt und kleinere Änderungen an unserem VPN Gateway vorgenommen.

"Er" weiß nun, dass es sowas wie IPv6 gibt. Das will heißen, dass ich ein /64er-Netz (das rein für Test-Zwecke und nicht für den produktiven Betrieb geeignet ist) bereitgestellt habe, dass der VPN Gateway bedient. "Er" weiß nun, wie es bei einem Neustart einzurichten ist und wie Routing-Regeln zu setzen sind, ein wenig mit der Firewall spielen kann er auch - zumindest soviel um eine generelle IPv6-Nutzung noch zu verbieten und die "Herkunft" eines IPv6-Paketes zu verifizieren (also ein Schutz vor Spoofing).

In meiner ersten Version unterteilt der VPN Gateway das /64er-Netz in 65536 /80er-Segmente, wovon er das erste für sich selbst beansprucht und den Rest theoretisch an Kunden weiterleitet. Nach einem manuellen Setup auf Client-Seite, hatte ich in windeseile (binnen 3 Befehlen) eine IPv6-Anbindung über den VPN-Gateway und hätte auch noch knapp 281.474.976.710.656 Geräte hinter meinem Laptop nativ adressieren können.

Wobei im "manuellen Setup" auch der aktuell technologische Knackpunkt liegt: Das von uns eingesetzte OpenVPN hat wenn man es genau nimmt keine Unterstützung für IPv6 an Bord. Es gibt ein paar Anstrengungen in diese Richtung, z.B. Patches in der Community, aber nichts was produktiv in der offiziellen Distribution verfügbar wäre und helfen würde.
Ich war schon relativ glücklich, dass wir (eigentlich um IPv4-Adressen zu sparen) schon von Anfang an Ethernet-Frames (tap-Device) anstelle von kleineren IP-Frames (tun-Device) übertragen und somit auf OSI-Ebene 3 schon relativ flexibel sind.

Mittlerweile geht der Trend etwas stärker in Richtung IPv6, sodass ich doch sehr hoffe, dass OpenVPN hier bald nachzieht.

Wie letzte Woche bereits angekündigt und in den Kommentaren erraten, haben wir ein wenig mehr Funktionalität in unser Backend bzw. auch ins Kundeninterface eingebaut.

Auf speziellen Wunsch, aus gegebenem Anlass und aufgrund meines unendlich großen Spieltriebes, können unsere Kunden nun auf unserem Mailserver eine eigene Blacklist verwalten. "Eigene" heißt in diesem Sinne natürlich, dass die Regeln nur für E-Mail-Adressen des Kunden selbst und nicht für die von anderen Kunden gelten, so kann es sein, dass eine E-Mail für Kunde A angenommen wird, wohingegen eine andere vom selben Server für Kunde B abgelehnt wird.

Der Regelsatz lässt momentan eine Identifizierung des Servers anhand seiner IP-Adresse, seiner HELO-Kennung und seinem RDNS-Namen zu. Die Regeln sind ähnlich einfach gehalten: Sofort Blacklisten, Nachrichten ab einer bestimmten Größe Blacklisten oder E-Mails einfach durchreichen, bzw. Whitelisten.

Über das Wochenende hat schon eine Hand voll Kunden das Feature eingeweiht und auch das Feedback, das ich primär aus dem professionellen Bereich erhalten habe, war durchweg positiv. Viel mehr erwarte ich schon gar nicht mehr - das ist jetzt keine bahnbrechende Neuerung, aber sicherlich eine, die recht gut in unseren Anspruch passt