DOCX

Wir haben am LFB gerade das unschöne Problem, dass wir beim Öffnen von DOCX Dokumenten Bilder sehen, die MS Word nicht anzeigt und nicht druckt.

Packt man die DOCX mit unzip aus und durchsucht dann die Verzeichnisstruktur sieht man das Bild ebenfalls. Es ist eindeutig da. Das Problem ist demnach, dass MS Word Bilder beim Löschen durch den Anwender nicht immer löscht … sondern stellenweise und aus für uns nicht nachvollziehbaren Gründen im Dokument belässt. Pech gehabt.

LibreOffice z.B. bringt das dann an den Tag – oder, wie wir feststellen konnten, die Webansicht von MS Word.

Die potentiellen Katastrophen, die sich aus diesem Verhalten von MS Word ergeben, sind Legion: Von Abmahnungen bei Internetveröffentlichungen angefangen über die Weitergabe von geheim zu haltenden Informationen bis hin zu persönlichen Peinlichkeiten … MS macht’s möglich.

Das ist professionelle Software.

Ihre Meinung zur Digitalisierung

Ja wenn das Ländle doch schon eine tolle Bürgerbeteiligungsplattform hat, dann will man da ja auch … sich beteiligen. Nur blöd, wenn der eigene, mühsam und möglichst auch sachlich verfasste Post dann vor die Wand läuft.

Ich hab dann gleich die technische Elite meines Bundeslandes, die Damen und Herren im Innenministerium, per Mail angeschrieben und diesen das Folgende mitgeteilt:

Sehr geehrte Damen und Herren,

ich habe es mir ja schon fast gedacht, als ich meinen Kommentar zur
Digitalisierungsstrategie verfasste und hab diesen deswegen vor meinem
Klick auf den roten Button kopiert. Denn: Klick ich den roten Button an,
dann bekomme ich das hier zu sehen:

We're sorry, but something went wrong.

Das ist nicht schwäbisch. Das ist auch nicht sehr erhellend auf
Englisch. "Something"?

Ich fühle mich in meinem Beitrag damit inhaltlich voll bestätigt:
Zentrale Dienste in einem freien Land - ein Widerspruch in sich selbst.

Hier der Kommentar, den ich eigentlich absetzen wollte:

<comment>

Subsidiarität muss Vorrang haben

Es gibt sicherlich Institutionen, die auf eine zentral zur Verfügung
gestellte Infrastruktur des Landes bei der Bereitstellung von
innovativen Dienstleistungen (wie auch immer das von wem auch immer dann
definiert sein mag) angewiesen sind. Aber es gibt eben auch
Institutionen, die es selbst besser können - schneller auf die bei ihnen
entstandenen Bedürfnisse reagieren und Lösungen bereitstellen, die der
Kultur der Institution und den Wünschen der Menschen in dieser besser
entsprechen, als "Einheitsbrei von oben".  Dazu kommt, dass in der
Vielfalt und auch Konkurrenz innovative Ideen wachsen - und nicht im
Kontext zentraler staatlicher Planung. Und: Vielfalt, lokale Lösungen
ohne zentrale Datenbevorratung ist auch ein Element des
Grundrechteschutzes im Kontext des Rechts auf informationelle
Selbstbestimmung!

Sie kennen die Argumentationsstruktur: Es ist die gleiche, wie sie die
Gemeinden gegenüber dem Land und die Bundesländer gegenüber dem Bund
vertreten - oder der Bund gegenüber der EU. Es ist ein Prinzip aus der
katholischen Soziallehre: Subsidiarität!

Aus meiner Sicht: Es ist unbedingt darauf zu achten, dass dieses Prinzip
bewahrt, geschützt und gefördert wird.

Bei technischen Dienstleistungen kommt noch ein der Biologie
entstammendes Argument hinzu, das ebenfalls spontan einsichtig sein
dürfte: Die Monokultur aus MS Windows im Land macht Angriffe leichter
und erzeugt Abhängigkeiten. Die vielfältigen proprietären "Lösungen" auf
den Rechnern des Landes (z.B. viel zu viel Pirobase auf den Servern -
viel zu viel MS Windows in allen Verwaltungen auf den Clients) sind aus
prinzipiellen Gründen intransparent, unkontrollierbar und vor allem
auch: auf Dauer viel teurer.

Zentrale Regeln zum WIE (im Sinne eines Qualitätsmanagements oder
Festlegung auf Protokolle, Datenschutzsstandards etc. pp.) schaden
nicht, sofern diese reflektiert gesetzt werden (z.B. keine proprietären
Ansätze) - aber eine zentrale Behörde für
Datenverarbeitungsdienstleistungen (wie im Ansatz BitBW) darf nicht der
richtige Weg sein. Er gefährdet zentrale Werte einer freien Gesellschaft!

D.h. nicht, dass BitBW überflüssig wäre - keineswegs! Es gibt bestimmt
mehr Institutionen, denen es an eigenem Know How fehlt, als
Institutionen, die technisch qualifiziert genug sind, um eigene Wege
gehen zu können. Für die zuerst Genannten sollte ein Angebot des Landes
unbedingt bereit stehen.

Aber genau darum geht es ja bei Subsidiarität: Die jeweils übergeordnete
Ebene greift erst ein, wenn es die Betroffenen nicht mehr selbst
hinbekommen - und vor allem auch erst dann, wenn diese den Wunsch
äußern, dass ihnen geholfen wird. Alles andere ist Paternalismus.

tldr: Für die Institutionen im Land - freie Wahl der technischen
Lösungen in freien Netzen!

</comment>

Ich bin diesen nun los. Aber: Keiner kann ihn lesen. Keiner kann darauf
reagieren. Ich kann Ihnen kaum sagen, wie begeistert ich von Ihrer
Plattform bin. Dann blogge ich eben meinen Beitrag - weil ich diesen
dann selbst unter Kontrolle habe. Weil ich es kann. Und vor allem: Weil
meine Dienste funktionieren!

Mit freundlichen Grüßen
Dirk Weller

… und auch gleich umgesetzt.

Update StM

Na hallo! Da bin ich doch noch am gleichen Tag direkt vom StM angeschrieben worden. Sie hatten wohl technischen Probleme heute. Jetzt ist der Comment doch an die „richtige“ Stelle gekommen.

Chromium 56

Chromium hat sich unterwegs die Option eingespart, auf einfach Art und Weise an die Zertifikatsansicht zu kommen. Ein Klick auf das grüne Schlosssymbol führt zu allen möglichen Angaben – aber nicht mehr zum Zertifikat selbst. Dazu benötigt man nun F12, um die Entwickleroptionen aufzurufen, und dort dann den Tab Security.

Sicherheit ist wichtig, also packen wir die Möglichkeit, die Sicherheit zu prüfen, möglichst weit weg, damit keiner der normalen User da auf einfache Art und Weise dran kommt? Ich versteh’s nicht.

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.

Kürbehöhle II

https://www.openstreetmap.org/#map=19/48.37250/9.22738

Beim zweiten Anlauf hat es dann funktioniert: Nach ein wenig im Wald herumlaufen befand sich die Kürbehöhle da, wo ich zuerst gesucht hatte.

kuerbefelsenband

Den auch in Openstreetmap eingezeichneten Waldweg hochlaufen (aktuell steht dieser voller Brennnesseln) bis zum hübsch verkarsteten Felsenband. Dann nach rechts (Süden) gehen.

kuerbeloch0

Am Ende des Felsenbandes hochsteigen auf die Fläche mit Birken und Buchen. Dabei kommt es dann auf den Blickwinkel an. Bei meiner ersten Runde habe ich den Eingangsschacht auf Grund der Farne komplett übersehen und stolperte dann eine Stunde durch den Wald.

Eingangsschacht Kürbehöhle

Bei der zweiten Runde kam ich ein Stück weiter Vorne den Abhang hoch und sah das Einstiegsloch sofort.

Kürbehöhle Schacht

Ich hab dann den Eingangsschacht nur runterfotografiert, weil ich weder Helm, Licht noch Seil dabei hatte. Ich schätze diesen auf 4m bis 5m Tiefe, Das Oval selbst dürfte ca. 50 bis 60 cm lang und 40 bis 50 cm breit sein. Griffe und Trittflächen sind vorhanden, eine dickere Birke zum Anbinden eines Seils auch … ich komme wieder.

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.

Steine

20160827_105645

Steinzeitliche Gräber gibt es auf der Insel viele und hinter Lancken-Granitz gleich eine Perlenkette davon.

20160827_110230

20160827_111513

20160827_111631

Eines der wenigen gut erhaltenen Gräber, das einen Blick …

20160827_111713

… in den Innenraum erlaubt.

20160827_114153

Ein wenig weiter im Wald: die Ziegensteine. Eine größere Grabanlage mit Bannkreis- und Wächtersteinen.

20160827_114545