Archive: Month 4, Year 2014

PHP-FPM chroot + Zend OpCache = Problem

22.04.2014 yahe administration legacy linux security

Ich habe testweise einmal den Zend OpCache ausprobiert, der seit PHP 5.5.0 direkt enthalten ist und war eigentlich ziemlich zufrieden. Der Speicherverbrauch bei der Ausführung von WordPress war auf 1/5 geschrumpft. Allerdings haben sich Probleme gezeigt, bei denen ich noch nicht genau weiß, wie ich sie beheben soll.

So kam es vor, dass ich im Adminbereich von calc.pw eine Einstellung tätigen wollte und plötzlich auf der Loginseite des WeizenSpr.eu Adminbereichs landete oder dass mir im Browserfenster von WeizenSpr.eu per Popup das Loginfenster angeboten wurde, weil angeblich meine Session abgelaufen war. Anfangs ging ich davon aus, dass evtl. Safari Probleme mit der Verwaltung der Cookies haben könnte, deshalb verwendete ich anschließend verschiedene Browser für beide Seiten, einmal Safari und einmal Firefox. Doch auch dieses Vorgehen half nicht. Erschwerend kam hinzu, dass calc.pw sporadisch gar nicht laden wollte und stattdessen eine leere Seite anzeigte, ohne auffällige Einträge im Errorlog.

Erst langsam kam mir der Gedanke, dass es am Zend OpCache liegen könnte. Die grundlegenden Einstellungen von WordPress (z.B. Datenbank-Zugänge, Session-Cookie-Schlüssel, korrekte URL der Webseite, etc.) lagern in der PHP-Konfigurationsdatei "wp-config.php". Offenbar verwendete der Zend OpCache mal die richtige Datei und mal die völlig falsche Datei, was die kaputten Sessions und auch die Redirects zur anderen Webseite erklären würde.

Es kam mir der Gedanke, dass das Problem in der chroot-Funktion von PHP-FPM liegen könnte. Offenbar hat der Zend OpCache in dieser Konstellation Probleme damit, die Dateien zu unterscheiden, denn relativ vom chroot-Heimverzeichnis aus gesehen sind die WordPress-Pfade natürlich komplett identisch. Nach dem Deaktivieren des Caches und dem Neustarten von PHP-FPM funktionierten beide Seiten problemlos. Die Sessions gingen nicht kaputt, ich erhielt keine fehlerhaften Redirects mehr und auch die sporadischen Totalausfälle von calc.pw verschwanden.

Die Frage, die sich jetzt nur stellt, ist, wann wohl jemand von PHP dieses Problem beheben wird. Solange das Problem nicht gelöst ist, werde ich den Cache nicht weiter einsetzen können.


Wikipad: Etherpad-Lite mit DokuWiki synchronisieren

17.04.2014 yahe code legacy linux

Vor einiger Zeit habe ich mir ein Etherpad-Lite installiert, um verteilt und auch unterwegs Texte verfassen zu können, die ich anschließend veröffentliche oder anderweitig nutze. Das ist soweit toll, doch die Veröffentlichung war in meinen Augen unpraktischer, als sie sein müsste, da ich den Text kopieren, irgendwo anders einfügen und neu formatieren musste. Meine Idee war es deshalb, die Veröffentlichung direkt aus dem Etherpad-Lite heraus erledigen zu können, zum Beispiel bei kleineren Texten, die ich anderen zur Verfügung stellen möchte. Die Frage war nur, über welche Plattform die Veröffentlichung stattfinden sollte.

Anfangs dachte ich daran, eine eigene Oberfläche zu entwickeln, allerdings wäre die nicht sonderlich hübsch geworden. Vor kurzem bin ich nun auf DokuWiki gestoßen, das perfekt zu sein scheint. Das besondere an DokuWiki ist, dass keine Datenbank verwendet wird, sondern alle Inhalte in einfachen *.txt-Dateien abgelegt werden. Ich könnte also einfach Pads exportieren, als Textdatei ablegen und wäre fertig. Die Idee zu Wikipad war geboren.

Texterstellung in Etherpad-Lite

Implementiert habe ich die Synchronisation in PHP. Es gibt einen Pad-Präfix und einen Wiki-Präfix. Alle Pads, deren Name den Pad-Präfix ("<Pad-Präfix>!<Name>") beinhalten, werden in einen Namespace des Wikis überführt ("<Wiki-Präfix>:<Name>"). Man kann die Präfixe auch weglassen, dann werden diese ignoriert und ohne Präfixe gearbeitet. In meinem Fall verwende ich z.B. den Pad-Präfix "wiki!" und einen leeren Wiki-Präfix.

Als erstes lasse ich aus der Etherpad-Lite Datenbank auslesen, welche Pads es mit dem Pad-Präfix gibt. Anschließend wird geprüft, wieviele Revisionen es von diesem Pad gibt. Hat sich seit der letzten Synchronisation die Anzahl der Revisionen geändert, so wird das Pad exportiert und in den data-Ordner des DokuWikis geschrieben.

Veröffentlichung in DokuWiki

Neben den Präfixen habe ich noch ein paar weitere Steuerungsmechanismen implementiert. So werden Pads nicht synchronisiert, wenn sie direkt nach dem Präfix einen Punkt im Namen haben (z.B. "wiki!.beispiel"). Zudem ist es möglich, inline (das heißt im Content des jeweiligen Pads) die Synchronisation eines Pads zu beeinflussen. Damit ein Pad aus dem Wiki gelöscht wird, muss der Padinhalt mit dem Text "[.remove]" beginnen. Möchte man stattdessen ein Pad bearbeiten, ohne, dass die aktuell gültige Fassung im Wiki gleich ersetzt wird, so muss der Padinhalt mit dem Text "[.ignore]" beginnen. In diesem Fall bleibt die aktuelle Seite im Wiki erhalten, wird jedoch nicht mit der neusten Revision des Pads überschrieben.

Update

In Etherpad Lite Version 1.5.0 wurde der DokuWiki-Export entfernt. Wikipad wurde nun so angepasst, dass es trotzdem noch verwendet werden kann. Leider kann man nun nicht mehr die WYSIWYG-Formatierung von Etherpad Lite nutzen, sondern muss die DokuWiki-Stylingsyntax verwenden.


Search

Links

RSS feed

Categories

administration (40)
arduino (12)
calcpw (2)
code (33)
hardware (16)
java (2)
legacy (113)
linux (27)
publicity (6)
review (2)
security (58)
thoughts (21)
windows (17)
wordpress (19)