Archiv der Kategorie: 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:

[Sun Jun 03 13:55:36.724556 2018] [:error] [pid 14354] [client 11.111.111.111:62116] PHP Warning:  Declaration of action_plugin_cryptor::register($control
ler) should be compatible with DokuWiki_Action_Plugin::register(Doku_Event_Handler $controller) in /pfad/lib/plugins/cryptor/action.php on lin
e 0, referer: https://sub.domain.tld/dokuwikipfad/doku.php?id=start

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]

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:

#<?php die() ?>
# PHP include hack

#
# Use this file to setup the document to text converter.
#
# The plugin trys to convert every media document to a text file. On this
# progress it uses a given set of external tools to convert it.
# This tools are defined per file extension.
#
# The config stores one extension and it's tool per line.
# You can use %in% and %out% for the input and output file.
#
pdf     /usr/bin/java -jar /opt/tika/tika-app-1.13.jar -t -eUTF-8 -r %in% > %out%
doc     /usr/bin/java -jar /opt/tika/tika-app-1.13.jar -t -eUTF-8 -r %in% > %out%
odt     /usr/bin/java -jar /opt/tika/tika-app-1.13.jar -t -eUTF-8 -r %in% > %out%
docx    /usr/bin/java -jar /opt/tika/tika-app-1.13.jar -t -eUTF-8 -r %in% > %out%
ppt     /usr/bin/java -jar /opt/tika/tika-app-1.13.jar -t -eUTF-8 -r %in% > %out%
odp     /usr/bin/java -jar /opt/tika/tika-app-1.13.jar -t -eUTF-8 -r %in% > %out%
pptx    /usr/bin/java -jar /opt/tika/tika-app-1.13.jar -t -eUTF-8 -r %in% > %out%
rtf     /usr/bin/java -jar /opt/tika/tika-app-1.13.jar -t -eUTF-8 -r %in% > %out%
xls     /usr/bin/java -jar /opt/tika/tika-app-1.13.jar -t -eUTF-8 -r %in% > %out%
ods     /usr/bin/java -jar /opt/tika/tika-app-1.13.jar -t -eUTF-8 -r %in% > %out%
xlsx    /usr/bin/java -jar /opt/tika/tika-app-1.13.jar -t -eUTF-8 -r %in% > %out%

Dann einen Testlauf starten und die Fehler einsammeln:

sudo -u www-data php /var/www/dokuwiki/lib/plugins/docsearch/cron.php

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

touch /var/www/.pdfbox.cache
chown www-data.www-data /var/www/.pdfbox.cache
chmod 750 /var/www/.pdfbox.cache

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

23 1     * * *  www-data /usr/bin/php /var/www/dokuwiki/lib/plugins/docsearch/cron.php > /var/log/tika.log

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.

LDAPs von DokuWiki auf LD-Server

In unser Portfolio sollen nur die Kolleg/innen reinkommen und nicht die Schüler/innen. Also authentifizierte dieses zunächst nur gegenüber dem Lehrermoodle – seit ein paar Tagen jedoch auch gegenüber dem hausinternen LDAP-Server über eine verschlüsselte Verbindung.

DokuWiki, die Basis für das Portfoliosystem, erlaubt hierbei jegliche Mischung aus Authentifizierungsverfahren, sofern man das Plugin AuthChained installiert hat. In unserem Fall lege ich die Administratoren und Redakteure händisch in der DokuWiki eigenen Datenbank an – die nur lesenden Benutzer/innen dürfen über LDAPs kommen. Sie sollen in der Default-Gruppe visitor landen, die im Backend von Dokuwiki so eingerichtet wurde, dass sie nur lesenden Zugriff auf die Portfolio-Seiten erhalten.

Dann wurde die dokuwiki/config/local.php umgestaltet. Hier die Variablen, die am Ende des Config-Marathons endlich die intendierte Wirkung hatten:

$conf['authtype'] = ‘authchained';
$conf['defaultgroup'] = ‘visitor';
$conf['disableactions'] = ‘register';
$conf['plugin']['authldap']['server'] = ‘ldaps://ip.des.servers.tld:636?;
$conf['plugin']['authldap']['port'] = 636;
$conf['plugin']['authldap']['usertree'] = ‘dc=schule,dc=ort,dc=schule-bw,dc=de';
$conf['plugin']['authldap']['userfilter'] = ‘(&(uid=%{user})(objectClass=ldUserAccount)(ldRole=teacher))';
$conf['plugin']['authldap']['version'] = 3;
$conf['plugin']['authchained']['authtypes'] = ‘authldap:authplain';
$conf['plugin']['authchained']['usermanager_authtype'] = ‘authplain';
$conf['auth']['chained']['authtypes'] = ‘ldap,plain';
$conf['auth']['chained']['usermanager_authtype'] = ‘plain';
$conf['auth']['chained']['find_auth_by_password'] = ‘false';
$conf['auth']['ldap']['version'] = ‘3’;

ldUserAccount und ldRole sind spezifisch für MySHN bzw. LogoDidact Systeme. Andere Schulserver-Lösungen haben sicherlich andere Bezeichnungen. Die Einträge in den LDAP von LMN sind in deren Wiki hervorragend dokumentiert und lieferten auch für obige LD-Lösung viele Ideen:

http://www.linuxmuster.net/wiki/anwenderwiki:webapps:portfolio#anpassen_der_grundkonfiguration_des_osp

Anmeldeversuche von SuS werden nun mit der Fehlermeldung “Benutzername und / oder Passwort unbekannt” abgewiesen. Dokuwiki sucht schließlich nicht im LDAP-Baum nach allen Menschen auf ServerG, sondern nur noch nach LuL. Vermutlich ist das overkill, denn im Userfilter steht ja ebenfalls drin, dass nur LuL reindürfen. Aber es funktioniert und scheint mir sicherer zu sein.

Da der schulische LD-Server für LDAPs nur ein self-signed Zertifikat ausliefert kommt noch ein Eintrag in die /etc/ldap/ldap.conf auf dem Dokuwiki-Server

TLS_REQCERT allow

OO2dokuwiki

Frank hat einen OpenOffice zu DokuWiki Konverter als OOo Makro gebastelt und bietet diesen auf den openschulportfolio Seiten zum Download an:

http://www.openschulportfolio.de/hilfe/konvertieren

Komplexere Tabellenlayouts verdaut das Makro nicht – aber für den schulischen Alltag (und damit vor allem das Ablegen von Protokollen und Verfahrensbeschreibungen etc.) reicht es allemal.

Eine Anleitung für die Integration des Makros in OOo sowie in die Symbolleisten ist ebenfalls auf den Seiten oben zu finden.

DokuWiki on a stick

Mein DokuWiki on a Stick warf mir auf meinem Lucid heute Morgen die folgende Meldung entgegen:

[error] [client ::1] client denied by server configuration: /media/truecrypt1/DokuWiki/dokuwiki/doku.php

Offensichtlich will der Microapache in seiner httpd.conf den Eintrag 127.0.0.1 nicht mehr fressen.

<Location />
Order Deny,Allow
Deny from all
Allow from localhost
</Location>

Wenn dann allerdings die Konfiguration auf localhost umgestellt wird, dann lässt er mich wieder rein.

DokuWiki Blog zickt

Bei mir zickt das DokuWiki Blog Plugin bei der Installation. Ich trage den Pfad zum Archiv auf der Admin Plugin Seite ein, drücke Enter und die Seite wird weiß. Im Error Log des Apachen steht dann:

?PHP Fatal error:  Cannot redeclare class action_plugin_blog in /var/www/dokuwiki/lib/plugins/blog/action.php on line 215, referer: https://my.dokuwiki.site/doku.php?do=admin&page=plugin

Das Problem ist, dass sich das Archiv mit einem falschen Dateinamen entpackt:

dokufreaks-plugin-blog-a32b5ed

Deswegen hilft ein

mv dokufreaks-plugin-blog-a32b5ed/ blog

in

dokuwiki/lib/plugins

und alles tut wieder.

DokuWiki und Google

Obwohl eine DokuWiki Seite von mir schon längere Zeit online war, wurde diese scheinbar nicht von Google gefunden. Also setzte ich die Google Webmastertools ein, um die Indexierung etwas zu beschleunigen.

Um die Webmastertools nutzen zu können, muss in die jeweilige Seite im Kopf ein Eintrag gesetzt werden, der Google versichert, dass man selbst Besitzer der Seite ist:

<meta name="google-site-verification" content="C8uYblaehfAseLMurksblablaRN8INewX" />

Dieser Eintrag gehört in

lib/tpl/themename/main.php

In diesem Zusammenhang fiel mir dann auf, dass DokuWiki im Seitenheader ein noindex und nofollow stehen hat und sich so doch sehr verschlossen zeigt. Ein Artikel zu diesem Thema brachte mich auf die richtige Spur.

In der Datei conf/local.php können einige Anpassungen von Hand vorgenommen werden, die DokuWiki für Suchmaschinen besonders attraktiv macht:

$conf['userewrite'] = 2;
$conf['useslash'] = 1;

Eine tiefer gehende Beschreibung ist hier zu finden.

Allerdings schoss mir diese Einstellung – im Zusammenhang mit weiteren, die ich gleich nennen werde – jedoch das Blogsystem von DokuWiki kaputt, das nicht alle Umstellungen gut verkraftet. Dies gilt zumindest dann, wenn das Blog wie auf http://www.kvfg.info auf der Startseite eingebunden wird.

Über /Admin /Konfiguration lassen sich die wichtigsten Einstellungen auch ohne direkten Eingriff in die conf/local.php setzen:

Dies – und die Webmastertools selbst – sorgen nun für suchmaschinenverträglichere Einträge im Header der Site. Ein

http://dokuwikiseite.domain/lib/exe/indexer.php?debug=1

prüft, ob die Sitemap erzeugt werden kann. Will das nicht gleich klappen, dann sollte diese mit

touch sitemap.xml.gz

im Webroot von DokuWiki so angelegt werden, dass der Webserver schreiben kann. Ob alles geklappt hat, kann dann mit

http://dokuwikiseite.domain/sitemap.xml.gz

überprüft werden: DokuWiki müsste die Datei zum Download anbieten. Hat alles funktioniert, dann macht man diese Datei nun wiederum den Webmastertools bekannt, die sofort Erfolg oder Misserfolg zurückmelden.