Archiv der Kategorie: Linux

Alles rund um die Pinguine – auf dem Desktop und dem Server

Falsches Userhome im LDAP

Nach Beendigung des Klassenarbeitsmodus auf einer LD vergisst diese gelegentlich, die richtigen Pfade zurück in den LDAP Baum zu schreiben. Meldet sich der Benutzer danach an, erhält er ein Homeverzeichnis, das dem aus dem Klassenarbeitsmodus entspricht

homeDirectory: /home/dynamic/Benutzer/lehrer/_Klassenarbeiten_/InfKA2

und kommt an seine eigenen Dateien nicht mehr ran. Außerdem hat er keinen Zugriff auf die Tauschverzeichnisse.

Einfachster Weg: Den LDAP Baum in eine Datei kippen

ldapsearch -U admin > ldap-tree

Den Dump dann mit grep und Freunden nach „Klassenarbeit“ durchsuchen und die Fundstellen zusammen mit den betroffenen Benutzern inklusive username notieren.

Auf einem Client jxplorer installieren (der sich in den Ubuntu Repos befindet) und sich mit diesem mit dem LDAP auf dem Server verbinden. Der anzugebende LDAP Server ist hierbei die IP des Schulservers / LD-Servers (also z.B. 10.16.1.1), als Benutzer nehmen wir den ldap-admin, dessen genaue Bezeichnung / DN wir aus dem gerade exportierten LDAP Baum nehmen können

cn=ldap-admin,dc=kvfg,dc=tue,dc=schule-bw,dc=de

Verwendet man für diesen das Passwort des admin (Administrator), dann erhält man nur lesenden Zugriff. Schreibenden Zugriff bekommt man mit dem Passwort, das in

/etc/ldap.secret

liegt.  Hier dann im Bäumchen users unter

homeDirectory: /home/dynamic/Benutzer/benutzername

eintragen – und nicht den Eintrag aus ldRealHomeDirectory übernehmen, der nur den Serverpfad enthält. Auf dem LD-Server ist der Pfad oben ein Symlink.

Am Ende des Prozesses noch durch die Homeverzeichnisse – auch den ver-symlinkten Teil unterhalb von /home/dynamic – durchsehen und nach evtl. noch bestehenden Symlinks auf das ehemalige Klassenarbeitsverzeichnis suchen. Diese löschen.

A Time Tracker

Ich nutze seit dem 01.08.2016 A Time Tracker (bei FDroid zu haben) als Zeiterfassungssoftware auf dem Smartphone – und das für mich überraschend diszipliniert und an vielen Stellen evtl. auch übergenau. Verlasse ich den Schreibtisch oder die SItzung etc., stoppe ich die Zeiterfassung.

Da das RP wie jedes Jahr um Pfingsten meinen Tätigkeitsbericht haben wollte, wollte ich mir die Arbeit nun erleichtern und zum ersten Mal einen echten Stundenzettel einreichen. Das klappte nur bedingt. Einerseits ist das RP-Formular dafür nicht gemacht, weil es sich nicht interessiert, wie viel man gearbeitet hat, sondern nur dafür, wie viele Stunden Unterricht ausgefallen sind, während man als Landesbeamter andere Dienstaufträge erfüllte.

Andererseits ging ich zuerst den falschen Weg und exportierte mir die SQLite Datenbank aus A Time Tracker (Mehr – Auf Speicher sichern). Mit der konnte ich lokal auf dem Rechner aber wenig anfangen: die Zeiten sind als Unix timestamps abgelegt, müssen also zuerst konvertiert werden und auch die Zuordnung von IDs zu den Tätigkeitsbezeichnungen ist derart auf einzelne Tabellen verteilt, dass das Zusammenführen viel zu viel Mühe macht.

Eine Übersicht über die eigene Arbeitszeit lässt sich aus dem CSV Export viel zügiger erstellen:

  1. Mehr – Zeitbereich ändern – Alle
  2. Mehr – Ansicht nach CSV exportieren

A Time Tracker legt die timetracker.db wie auch die all.csv auf der obersten Ebene des Nutzerverzeichnisses auf dem Smartphone ab – hier ist das /storage/emulated/0/.

Die Konvertierung von Unix timestamps ins Format YYYY-MM-DD HH-MM-SS wird von der App vorgenommen. Der Import nach LibreOffice gelingt ohne Mühe.

Formatiert man die Zellen für die Summen im Format [HH]:MM:SS, unterlässt LibreOffice jegliche Umrechnungen und addiert schlicht die Zeiten in Richtung Stunden. Entscheidend ist die eckige Klammer um das HH!

Man kann dann mit dem üblichen =SUMME(FeldA:FeldZ) rechnen, statt sich permanent zu wundern, was LibreOffice da gerade macht, und die Daten auch grafisch darstellen etc. pp.

Ganz hübsch erhellend für mich war, dass ich schon vor Monaten meine vorgesehene Jahresarbeitszeit „durch“ hatte. Dabei ist das Schuljahr noch nicht einmal zu Ende. Auch erhellend war die Verteilung meiner Stunden auf die von mir in A Time Tracker angelegten Kategorien. Ich weiß nun, wo ich mehr darauf achten muss, mich nicht zu sehr vereinnahmen zu lassen. Ich muss „Nein“ noch üben.

Proxmox mit LXC bei Hetzner

Xen? KVM? LXC? Oder gar systemd-nspawn? In der Schule drehen wir uns bezüglich der Virtualisierungsbasis für unsere Cloud hübsch im Kreis. Aktuell neige ich LXC zu, musste aber bei meinen ersten Gehversuchen einige Schläge einstecken: Restricted Container zickten, Debian Jessie Container auf Ubuntu 16.04 als Wirt ebenfalls, das Netzwerk-Setup war fummelig und die Namensauflösung in den Containern selbst immer wieder „einfach weg“ …

Also das schlechte Wetter heute mal sinnvoll genutzt und einen ganz anderen Weg beschritten: nicht wie sonst per Shell gearbeitet, sondern heute mal per Oberfläche gefummelt und mir Proxmox näher angesehen. Geht flott und funktioniert zügig. Hier eine kurze Doku.

Im Hetzner installimage das aktuelle Debian auswählen – hier: Jessie. Setup durchführen, Updates installieren, neu booten und dann an die Arbeit.

Hinweis für die Partitionierung: Die LXC-VMs werden später unter /var – genauer: /var/lib/vz/images – liegen.

echo "deb http://download.proxmox.com/debian jessie pve-no-subscription" >> /etc/apt/sources.list
wget -O - http://download.proxmox.com/debian/key.asc | apt-key add -
apt-get update
apt-get upgrade
apt-get dist-upgrade
uname -a
reboot

Ich habe mir dann „die volle Packung Proxmox“ installiert:

apt-get install proxmox-ve ssh postfix ksm-control-daemon open-iscsi systemd-sysv mailutils

Nach einem erneuten Reboot zeigte ein uname -a nun

Linux hostname 4.4.59-1-pve #1 SMP PVE 4.4.59-87 (Tue, 25 Apr 2017 09:01:58 +0200) x86_64 GNU/Linux

Also frisch in Proxmox unter https://server.domain:8006 mit dem PAM Account für root angemeldet und dort eine neue VMBR0 angelegt, die erst einmal unkonfiguriert blieb.

Reboot. Proxmox übernimmt sonst die Änderungen nicht.

Dann das restlichen Netzwerk-Setup von Hand erledigt.

Die Basis-IP des Server war

78.78.78.82

Dazu kamen zwei über den Robot zusätzlich bestellte IPs

78.78.78.86
78.78.78.90

Es ergab sich damit für /etc/network/interfaces diese Konfiguration:

auto lo
iface lo inet loopback
iface lo inet6 loopback

# ETH0
auto eth0
iface eth0 inet static
  address 78.78.78.82 # Server Basis IP
  netmask 255.255.255.255 # Netzmaske neu gesetzt
  gateway  78.78.78.65 # wird von Hetzner mitgeteilt
  pointopoint 78.78.78.65 # PTP auf das Gateway

# VMBR0

auto vmbr0
iface vmbr0 inet static
  address 78.78.78.82 # Server Basis IP
  netmask 255.255.255.255 # Netzmaske neu gesetzt
  bridge_ports none
  bridge_stp off
  bridge_fd 0
    up ip route add 78.78.78.86/32 dev vmbr0 # erste VM mit erster Zusatz-IP
    up ip route add 78.78.78.90/32 dev vmbr0 # zweite VM mit zweiter Zusatz-IP

# IPv6 Config 

iface eth0 inet6 static
        address  121:121:121:121::2
        netmask  128
        gateway  fe80::1
        up ip -6 route add default via fe80::1 dev eth0
        up sysctl -p

iface vmbr0 inet6 static
        address 121:121:121:121::2
        netmask 64

Für jede weitere IP, die im vorliegenden Fall noch kommen mag, muss man für die VMBR0 eine Zeile ergänzen. Ich denke, das Schema ist nachvollziehbar. Die restliche IP-Konfiguration läuft über Proxmox direkt (siehe unten).

Es folgt die Anpassung von /etc/sysctl.conf 

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
net.ipv6.conf.all.forwarding=1

Reboot.

Und ab jetzt geht es klickend in Proxmox weiter. Zuerst zieht man sich die benötigten Templates (hier: für Ubuntu und Debian). Dann legt ein Klick auf das entsprechende Icon die erste VM als LXC an. Der erste Container erhält als IP im hier vorliegenden Fall

78.78.78.86/32

und für seine Gateway-Adresse die Basis-IP des Servers:

78.78.78.82

Der Rest – also die Ressourcenzuteilung usw – war für die Testmaschinen dann eine Geschmacksfrage.

Die Verwaltung (Softwareinstallation etc.) der einzelnen VMs nahm ich lieber direkt auf dem Wirt vor. Da reagiert die Shell einfach zügiger als jedes Frontend. Ein

lxc-attach -n 100

bindet den zuerst erzeugten LXC an die Rootshell.

Ein internes Netzwerk, über das die VMs untereinander sprechen können, ist auch schnell eingerichtet: Auf dem Host oder auch über Proxmox in die /etc/network/interfaces

auto vmbr1
iface vmbr1 inet static
        address  10.16.1.0
        netmask  255.255.0.0
        bridge_ports none
        bridge_stp off
        bridge_fd 0

Reboot und in Proxmox dann der jeweiligen Maschine eine neue Netzwerkkarte (eth1) geben, die an die vmbr1 gebunden wird, passende IP und Netzmaske setzen – voila.

Erste Messungen mit iperf geben so um die 55 Gbit/sec.

Erstes Ergebnis:

  • Netzwerksetup, Einrichtung, Verwaltung laufen rund und zügig ab
  • Die Templates für Proxmox kommen ziemlich „dick“ mit Software ausgestattet daher. So würde ich diese ungern als Basis für eigene VMs nutzen

CODE versus OO

Die Installation von Collabora (CODE) in nextCloud hinter einem HTTPS-Apache-Proxy verläuft ohne Zicken. Einfach die Anleitung nachturnen und es funktioniert. Aber es funktioniert zäh und das auch bei 32GB RAM auf einem (etwas in die Jahre geratenen aber durchaus noch webtauglichen) Dell Poweredge T710 mit zwei Xeon Prozessoren. Zumindest im Vergleich zu einem OnlyOffice (OO).

OnlyOffice bringt viel mehr Funktionen mit, lässt sich flutschiger bedienen und sieht darüber hinaus auch noch schicker aus. Im Vergleich dazu fällt Collabora sehr weit zurück: zähe, zickige und schnarchige Bedienung und gerade mal ein paar Basisfunktionen an Bord. Hat man einmal mit OO gespielt, will man nicht mehr zu CODE zurück. Dafür würde ich sogar hinnehmen, dass OO alles ins OOXML Format konvertieren will.

Jedoch: OnlyOffice in ownCloud hinter einem HTTPS-Apache-Proxy warf sich mir mit weitaus mehr Problemen bei der Installation in den Weg als CODE. Aktuell habe ich noch nicht alle im Griff – es funktioniert erst im Prinzip. Und zwar hiermit:

docker pull onlyoffice/documentserver

Die Virtualhost für den Apache anpassen:

<VirtualHost *:443>
     ServerName onlyoffice.domain.tld:443

     SSLEngine on
     ServerSignature On
     SSLHonorCipherOrder on

     SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

     SSLCertificateFile /etc/letsencrypt/live/onlyoffice.domain.tld/fullchain.pem
     SSLCertificateKeyFile /etc/letsencrypt/live/onlyoffice.domain.tld/privkey.pem

     LogLevel warn
     CustomLog ${APACHE_LOG_DIR}/access.log combined
     ErrorLog ${APACHE_LOG_DIR}/error.log

# Just in case - see below
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off

# contra mixed content warnings
RequestHeader set X-Forwarded-Proto "https"

# basic proxy settings
ProxyRequests off

        ProxyPass / http://127.0.0.3:9090/
        <Location />
                ProxyPassReverse /
        </Location>
</VirtualHost>

Den OO Container starten:

docker run -i -t -d -p 127.0.0.3:9090:80 --restart always  onlyoffice/documentserver

die ownCloud App für OO installieren und die Kiste läuft. Im Prinzip.

Textverarbeitung funktioniert.

Präsentationssoftware funktioniert.

Tabellenkalkulation funktioniert.

Aber: Es funktioniert eben nur im Prinzip.

Denn man muss damit leben, dass einem der Firefox weiterhin in der Debug-Console Meldungen entgegen wirft:

Firefox kann keine Verbindung zu dem Server unter wss://onlyoffice.domain.tld/2017-02-17-15-53/doc/271488117372/c/493/1niaepga/websocket aufbauen.  sockjs.min.js:3:4835

Ich fummel mir hier nun seit Tagen einen ab, um diese Meldungen los zu werden. In der VHost Konfiguration des Apachen oben sind ja noch Reste davon zu sehen.

Für diese Versuche startete ich den docker container so, dass dessen Port 443 zum Wirt auf Port 9091 weiter gereicht wird

docker run -i -t -d -p 127.0.0.3:9090:80 -p 127.0.0.3:9091:443 onlyoffice/documentserver

und stellte dann Versuche in der VHost Config des Apachen nach dem Schema (!)

ProxyPassMatch "/(.*)/websocket"  wss://127.0.0.3:9091/$1/websocket

an. Erfolglos. Auch meine Versuche mit ProxyPass, ProxyPassReverse oder ReWrite Regeln scheiterten bisher.

Ich glaube, ich habe nun alle Anleitungen und Tutorials rund um Websockets mit HTTPs und Apache Proxy durch – ich fahr da noch immer vor die Wand. Und vor allem: Ich hab keine blassen Dunst, was ich eigentlich genau verzocke.

Drängen tut das Problem nicht. Ich roll weder OO noch CODE zum aktuellen Zeitpunkt aus. Denn ich vertraue weder dem auf einer eigenen Subdomain laufende OO Documentserver noch dem CODE Container. Zwar können Besucher theoretisch nur in den docker container reinfummeln und wohl nicht aus diesem oder dem Apache Proxy ausbrechen, aber schon dass finde ich irritierend.

Schlimmer ist vielmehr, dass ich den Websocket nicht an den Apache HTTPS Proxy so dran bekomme, dass der Firefox endlich Ruhe gibt. Falls da einer ne Idee hat … ich hab ein offenes Ohr. Vielleicht ist ja was dabei, was ich noch nicht probiert habe.

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

Deprecation Notice in ./../php/php-gettext/streams.php#48
Methods with the same name as their class will not be constructors in a future version of PHP; StringReader has a deprecated constructor

Backtrace

./../php/php-gettext/gettext.inc#41: require()
./libraries/select_lang.lib.php#477: require_once(./../php/php-gettext/gettext.inc)
./libraries/common.inc.php#569: require(./libraries/select_lang.lib.php)
./phpmyadmin.css.php#14: require_once(./libraries/common.inc.php)

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

error_reporting = E_ALL & ~E_DEPRECATED

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:

    "DIBI_PRECONFIGURATION":{
      "mysql_username":"pydiodbuser",
      "mysql_password":"pydiodbpasswort",
      "mysql_host":"localhost",
      "mysql_driver":"mysql",
      "mysql_database":"pydiodbname",
      "group_switch_value":"mysql",
      "mysql_use_mysqli":"true"
    }

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

PHP Warning:  Declaration of syntax_plugin_gcalendar::render($mode, &$renderer, $indata) should be compatible with DokuWiki_Syntax_Plugin::render($format, Doku_Renderer $renderer, $data) in /pfad/zu/dokuwiki/lib/plugins/gcalendar/syntax.php on line 0
PHP Warning:  Declaration of syntax_plugin_include_div::handle($match, $state, $pos, &$handler) should be compatible with DokuWiki_Syntax_Plugin::handle($match, $state, $pos, Doku_Handler $handler) in /pfad/zu/dokuwiki/lib/plugins/include/syntax/div.php on line 0, referer: https://www.domain.tld

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.

 

OMD auf Ubuntu 16.04 quick setup

Mein hausinterner Monitoring- und Nameserver wollte sich nicht ohne Zicken von 14.04 auf 16.04 schubsen lassen. Also setzte ich diesen neu auf und durfte dann OMD neu installieren. Meine Notizen:

wget https://mathias-kettner.de/support/1.2.8p15/check-mk-raw-1.2.8p15_0.xenial_amd64.deb
dpkg -i check-mk-raw-1.2.8p15_0.xenial_amd64.deb
apt-get install -f
service apache2 restart
omd create bdjlhome
su - bdjlhome

In /omd/sites/bdjlhome ist dessen Homeverzeichnis gelandet. Dort dann ausführen:

omd config
omd start
exit

Das OMD Config stellte ich auf Web GUI sowie Multisite und übernahm dort im Wesentlichen die vorhandenen Einstellungen:

Um den Monitoring-Server ebenfalls überwachen zu können folgte die Installation und Konfiguration (die dann auf allen zu überwachenden Clients ebenfalls durchgeführt werden muss):

apt-get install check-mk-agent xinetd nagios-plugins-basic
apt-get install -f

Die /etc/xinetd.d/check_mk sieht nach den nötigen Anpassungen wie folgt aus:

service check_mk
{
        type           = UNLISTED
        port           = 6556
        socket_type    = stream
        protocol       = tcp
        wait           = no
        user           = root
        server         = /usr/bin/check_mk_agent

        # If you use fully redundant monitoring and poll the client
        # from more then one monitoring servers in parallel you might
        # want to use the agent cache wrapper:
        # server         = /usr/bin/check_mk_caching_agent

        # configure the IP address(es) of your Nagios server here:
        only_from      = 127.0.0.1

        # Don't be too verbose. Don't log every check. This might be
        # commented out for debugging. If this option is commented out
        # the default options will be used for this service.
        log_on_success =

        disable        = no
}

Für die Clients muss dann bei only_from die IP des Monitoring-Servers eingetragen werden.

Weiter geht es für die mrpe.cfg:

mkdir /etc/check_mk
vi /etc/check_mk/mrpe.cfg

Hier schaltete ich APT und SSH Checks frei:

# APT Check
APT_CHECK /usr/lib/nagios/plugins/check_apt
# SSH Check
SSH_CHECK /usr/lib/nagios/plugins/check_ssh localhost

Fail2ban soll ebenfalls überwacht werden:

vi /opt/omd/sites/bdjlhome/local/share/check_mk/agents/plugins/fail2ban

In der Config für diesen Agent steht

#!/bin/sh
echo '<<<fail2ban>>>'
if [ -x /usr/bin/fail2ban-client ]; then
JAILS=`/usr/bin/fail2ban-client status | grep "Jail list" | tr -s [:blank:] | cut -f2- -d':' | sed -e 's/,/ /g'`
        echo "Detected jails: $JAILS"
        for jail in $JAILS
        do
                /usr/bin/fail2ban-client status $jail
        done
fi

und dann muss diese noch ausführbar sein:

chmod 755 /opt/omd/sites/bdjlhome/local/share/check_mk/agents/plugins/fail2ban

755 ist etwas arg dick aufgetragen, tut es aber für’s Heimnetz.

Dann den xinetd und den Apache neu starten:

service xinetd restart
service apache2 restart

Ob überhaupt Daten ankommen ist zu prüfen:

telnet localhost 6556

Die Anmeldung an OMD erfolgt im Browser an der lokalen IP (bei mir an dieser Stelle noch ohne Namensauflösung: https://10.16.X.X/bdjlhome) als omdadmin mit omd als Passwort, das nach dem ersten erfolgreichen Login geändert wird.

Im Main Menü unter Hosts wird dann der lokale Monitoring-Server eingerichtet. Rechts oben gibt es den Schalter New host. Diesem einen Namen und die passende IP (in diesem Fall 127.0.01) geben und über Save & go to Services speichern. Wenn alles klappt lässt sich hier gleich eine Service discovery durchführen und für diesen Host abspeichern.

Zurück im Main Menu: Wie üblich bei OMD müssen die Änderungen durch eine Reihe von Klicks auf farblich hervorgehobene Schalterchen erst aktiviert werden.

Ein Klick auf Hosts zeigt die Liste der schon eingetragenen Server an. Zur nachträglichen Service Discovery folgt der Klick auf das Icon „Notizbrett mit grünem Haken“ das im Overlay „Edit the services of this hosts, do a service discovery“ anzeigt.

… und nach ein wenig mehr Geklicke sind die lokalen Hosts eingetragen. Praktisch ist die Notification Funktion. Die warnt mich per Mail, wenn auf einem der Rechner etwas aus dem Lot gerät. In Ermangelung einer statischen IP verwende ich hierzu einen Postfix als Satellitensystem – aber das ist eine andere Geschichte.

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 MRBS 1.5 auf LD-Server

Ein auf einem externen Server (z.B. bei Hetzner) gehostetes MRBS kann mit den folgenden Einstellungen per LDAPs gegenüber dem internen SBE-Serverchen mit openLDAP authentifizieren:

$auth["type"] = "ldap";
unset($auth["admin"]);
$auth["admin"][] = "admin";

$ldap_host = "ldaps://123.123.123.123"; // IP des Schulservers
$ldap_port = 636;
$ldap_v3 = true;
$ldap_tls = true;
$ldap_base_dn = "ou=users;dc=schule,dc=ort,dc=schule-bw,dc=de";
$ldap_user_attrib = "uid";
$ldap_filter = "|(ldRole=teacher)(uid=admin)";
$ldap_disable_referrals = TRUE;

//$ldap_debug = TRUE; // Nur drin lassen wenn es nicht funzt

Die obigen Einträge beziehen sich auf die Datei config.inc.php im Verzeichnis /pfad/zu/mrbs/web. Debugmeldungen von MRBS (sofern oben einkommentiert) finden sich in der error.log des Apachen. Der Filter stellt hoffentlich sicher, dass nur Lehrer/innen sich anmelden können. Um MRBS zusätzlich gegenüber Einsichtnahmen durch Zweite abzusichern, muss der Login erzwungen werden. Dazu

// Datenschutz

 if( ! getAuthorised(1))
   {
    showAccessDenied($day,$month, $year, $area);
    exit();
   }

nach den Includes in alle nur erdenklichen und über Netz erreichbaren PHP Dateien (month.php, day.php, week.php, search.php, report.php usw) setzen.

Die anderen hier im Blog zu findenden Hinweise zur Konfiguration von LDAPs gegen einen SBE Server sollte man sich ebenfalls mal ansehen, wenn es mit den Einträgen oben nicht tun will. Es gibt einige Wände, vor die man laufen kann.

SORBS sucks

sorbssucks

Die haben echt ein Rad ab bei SORBS. Von einem Tag auf den anderen taucht in deren Datenbank eine meiner IPs auf, die ich seit nunmehr 3 Jahren nutze, weil von dieser im März 2012 SPAM versendet wurde?

Versucht man sich bei SORBS anzumelden, wird es wild. An manchen Tagen schwächeln deren Server so, dass man von einem Loginfeld zum nächsten geführt wird und schlicht keine Meldungen oder Delisting-Einträge anlegen kann. Super Service, Super Server, Super Admins.

Bei der Qualität hab ich SORBS aus allen meinen Datenbanken geworfen.