Schlagwort-Archive: dokuwiki

Greebo und syntax_plugin_cryptor

Vor einer gefühlten Ewigkeit hab ich das Plugin crypto für ein DokuWiki installiert und damit einigen Text auch „verschlüsselt“ (das Plugin macht aus dem eingegebenen Text auf der Basis einer Passphrase mit einem in JavaScript implementierten AES256 Algorithmus Buchstaben- und Zahlensalat). Das Ding warf nun nach dem Update auf Greebo und PHP7 das hier in die Logs:

Ich hab da nun so lange – und ehrlich gesagt: frei von PHP-Kenntnissen – mit Hilfe von Anleitungen zur Plugin-Erstellung auf dokwiki.org sowie Forenbeiträgen und Bugfixes auf Github zu anderen Dokuwiki-Plugins dran rumgefummelt, bis meine Logs keine Fehlermeldungen mehr zeigen und das Plugin trotzdem funktioniert.

Aus meiner Sicht haben sich seit der Erstellung dieses Plugins nur die Bezeichnungen der Funktionsaufrufe in Dokuwiki geändert. Ein echtes PHP5 – PHP7 Problem lag vermutlich nicht vor.

Wer da mal reingucken und selbst testen will sei mir herzlich willkommen:

2018-06-03-cryptor-php7-greebo [ZIP] [21 kb]

Release upgrade auf Ubuntu 16.04.1

Eine Sammlung an Notizen zum release upgrade von 14.04 LTS auf 16.04.1 LTS oder: Was alles zerbrach, wie es zu heilen war und was noch ungelöst verbleibt.

phpMyAdmin

Schon während des Upgrades konnte das Paket phpmyadmin für Xenial nicht konfiguriert werden. Die angezeigten Fehlermeldungen verwiesen auf dieses Problem, das sich allerdings im Zuge des Upgrades nicht rund umsetzen ließen. Also blieb phpmyadmin unkonfiguriert.

Unter Xenial habe ich mir mit apt-get purge phpmyadmin ; apt-get install phpmyadmin das Paket frisch an Bord geholt.

Begrüßt wurde ich dann von einer schier unendlichen Anzahl von Deprecation Notices nach dem Muster

Weder gettext noch mbstring (wie in einigen Threads zum Problem behauptet) lösten das Problem. Dieser Hinweis war für mich der richtige:

Pydio

Pydio meinte, es hätte unter Xenial keine MySQL Verbindung mehr. Das Problem ist wohl bekannt, die Lösung sieht bei mir so in der $PYDIOINSTALLDIR/data/plugins/boot.conf/bootstrap.json aus:

Danach läuft auch ein Update auf die nächste Pydio-Version reibungslos durch.

ownCloud

ownCloud startete nicht mehr, weil einerseits memcache nicht funktionierte (unter php7 eigentlich nicht verwunderlich) und weil die PHP Module php-zip, php-memcached, php-redis und php-curl fehlten. Die waren zwar unter Trusty schon einmal an Bord, aber gingen im Laufe des Upgrades wohl verloren. Ich sollte an dieser Stelle wohl eh umsteigen auf APCu.

DokuWiki

Viele Plugins von Dokuwiki werfen mit Fehlermeldungen im Muster

nach dem Apachen. Hier half es, alle Plugins neu zu installieren, auch wenn diese nicht als mögliches Update von DokuWiki angezeigt wurden.

opendkim

Die Rechte auf /etc/postfix/dkim.key lagen bei root.root und verhinderten den Start von opendkim. Ein chown opendkim dkim.key stellt das richtig.

fail2ban

Die jail.local musste ich komplett überarbeiten. Der Hintergrund scheint zu sein, dass die Pfade für die Logs der einzelnen Dienste aus der jail.local bei Trusty unter Xenial nicht mehr stimmten: Einige nutzen jetzt systemd, andere schreiben weiterhin in ihren herkömmlichen Logpfad.

Außerdem zeigten sich die von mir aktivierten Apache jails extrem empfindlich gegenüber Arbeiten im Backend von DokuWiki, so lange dieses Fehlermeldungen rund um PHP7 wirft. Nach nur wenigen Klicks sperrte mich mein Server komplett aus und am Ende des Tages (und auf Grund einer von mir einst hoch festgelegten bantime) half nur der Boot mit einem über die Hetznerkonsole gestarteten Notfalllinux.

 

DocSearch

Zum Thema Dokumentenindexierung in DokuWiki habe ich heute für meine Schule gebastelt. Hier der technischere Teil der Dokumentation dazu.

Nach der Installation des Plugins DocSearch in DokuWiki den Konverter Apache Tika als JAR Datei nach /opt/tika legen. Den Ordner /opt/tika an www-data rekursiv und mit den Rechten 750 übergeben. Evtl. openjdk JRE nachinstallieren. Die headless Version reicht aus.

Kontrollieren, ob PHP genug RAM erhält. Das memory_limit in /etc/php5/apache2/php.ini sollte über 256MB liegen.

Die /pfad/zu/dokuwiki/lib/plugins/docsearch/conf/converter.php.dist nach converter.php kopieren und anpassen. Meine sieht nun so aus:

Dann einen Testlauf starten und die Fehler einsammeln:

Evtl. sollte das Paket ttf-mscorefonts-installer nachinstalliert werden, um weniger Fontmeldungen um die Ohren gehauen zu bekommen. Ein

behebt noch ein paar Kleinigkeiten in der Fehlerausgabe.

Der Lauf frisst Zeit und Ressourcen. Der cronjob sollte dies berücksichtigen. Mein Eintrag in die /etc/crontab sieht so aus

läuft also nur einmal in der Nacht los.

Was nicht in den Griff zu bekommen sein wird, sind die vielfältigen Windows-only-Fonts, die in vielen Dokumenten verbaut sind. Da wird Tika auch in Zukunft maulen müssen. Das heißt konkret: www-data erhält E-Mails! Es empfiehlt sich deswegen einen Alias für www-data anzulegen und die Mails auf das eigene Konto zu lenken, will man nicht vom Mailserver mit Fehlern zu unzustellbaren E-Mails zugemüllt werden. Oder man lenkt die Ausgabe des Cronjobs nach /dev/null um, erfährt dann aber auch nix über reparable Fehler.

Writer2DokuWiki

Bisher nutzte ich für die Konvertierung von Texten für DokuWiki das Plugin Writer2Dokuwiki und hatte wenig Probleme. Das jetzt frisch verfügbare LibreOffce 5.1 schmiert mir hierbei jedoch kommentarlos ab, so dass ich auf die Schnelle eine andere Möglichkeit brauchte. Diese ist nun eine Kombination aus tidy und pandoc.

loexportformat

In LibreOffice wird das Exportformat für HTML Dateien zuerst unter /Extras /Optionen /Laden-Speichern /HTML-Kompatibilität auf UTF-8 umgeschaltet.

Über /Datei /Speichern unter wird nun das HTML-Format ausgewählt und die Datei gespeichert.

Hinweis: Der Exportdialog unter /Datei /Exportieren… erzeugt XHTML Dateien, die noch schwerer zu putzen sind. Also nutze ich diese Funktion nicht.

Der von LibreOffice erzeugte HTML-Code ist grauenhaft. Also muss dieser mit tidy geputzt werden. Die tidy.conf liegt hierbei in meinem Stammordner im dortigen ~/bin Verzeichnis:

Ein

wirfft weg, was wir nicht brauchen. Ein bischen class=western kann dabei übrig bleiben, tut aber nicht weiter weh.

Als nächstes kommt pandoc in einer Version größer gleich 1.13 zum Einsatz (unter Ubuntu 15.10 vorhanden):

Die TXT Datei dann mit einem Editor öffnen und den Inhalt in DokuWiki einfügen. Voila. Zusammen macht das dann

oder gleich als Skript verpackt:

Das klappte hier mit less und leafpad, das von mir sonst bevorzugte kate wollte nicht von stdin lesen. Da muss ich noch einmal nachsehen, woran das lag.

Man kann auch den Aufruf von LibreOffice und damit den ersten Schritt in das Skript integrieren, sofern die (angelieferten) Dokumente mit Formatvorlagen erstellt wurden. Das ist in meinem Kollegium hoffnungslos – aber im Prinzip ginge ein

Quellen: [1] [2]