HS Höhle und HS Kammer

Der Winter hat ziemlich gewütet in der Nähe meines Übungsobjektes bei der Nebelhöhle. Der Fels hat einen Geröllheimer stattlichen Ausmaßes verloren und ein weiteres Stück wird wohl im nächsten Winter nachfolgen, so instabil wie der Fels auf der rechten Seite im Bild inzwischen aussieht.

Tewje hat inzwischen recherchiert: Der Stein liegt da wohl schon ein paar Jahre. War mir vorher nicht aufgefallen.

Ich bin dann kurz in die HS-Höhle bis zum – vor ein paar Jahren von einer Höfo-Gruppe inklusive Tewje – ergrabenen Endpunkt gekrochen. Bei meinem ersten Besuch im letzten Herbst war ich hierfür nicht richtig angezogen. Hübsches Stück, das die Gruppe da erarbeitet hat. Ich schätze mal 10 Meter werden es auf jeden Fall sein. Überhaupt: ein hübsches Loch. Ein wenig Sinter ist ebenfalls vorhanden und auch die Hoffnung, dass erneutes Graben keine dumme Idee sein könnte.

Nicht weit davon ist mein Übungsobjekt zu finden – Arbeitsname „HS-Kammer“. Ein Kleinstloch mit 3 potentiellen Fortsetzungen, die alle in die ungefähr gleiche Richtung zu laufen scheinen. Ein Luftzug ist in allen drei zu spüren, in der mittleren aber am deutlichsten. Befahren habe ich diesen Schluf nicht: die Angst, stecken zu bleiben, war heute noch zu groß. Schließlich weiß kaum einer, wo das Objekt ist und die der Familie hinterlassenen Erklärungen wollte ich nicht gleich beim ersten Besuch testen.

Also lediglich eine erste Orientierung: Nur mit Papier, Bleistift und einem Maßband bewaffnet hab ich heute einige Notizen und Eindrücke gesammelt.

Nach einem kurzen Eingangsschluf gelangte ich in eine kleine Kammer, die an einer hangparallel verlaufenden Abrisskluft entlang gebildet scheint. Es geht etwa 1,7m nach oben. Platz zum Hocken war auf Grund der Form für mich jedoch nicht. Die Kluft selbst reicht bis zur Erdoberfläche und weist an zwei Stellen kleine (Kinderfaustgröße) Oberlichter rechts vom Eingang auf. Nach links geht es in einem sehr schmalen Schluf etwa einen Meter abwärts und danach vermutlich nach rechts. Schlufbar sah der für mich ebenso wenig aus wie der Schluf ganz rechts in der Kammer, der sich nach einem kurzen Stück ebenfalls bergwärts zu orientieren scheint.

Interessanter ist der mittlere Schluf am rechten Ende der Kammer. Man kann ca. 5 bis 6 Meter weit in den Berg blicken. Es geht relativ eben weiter, am Ende des sichtbaren Bereichs scheint der Schluf nach Unten und rechts zu laufen. Ein Luftzug ist, wie bereits geschrieben, ebenfalls zu spüren. Eng ist der Schluf. Ziemlich eng. Aber der Boden ist nicht aus Kalk, sondern zu großen Teilen aus losem Erdmaterial, so dass man sich evtl. etwas zusätzlichen Raum verschaffen kann, ohne gleich professionell graben zu müssen.

Der Anfang wäre gemacht.

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:

Die Virtualhost für den Apache anpassen:

Den OO Container starten:

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:

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

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

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.

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:

… 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

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.

 

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:

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

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):

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

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

Weiter geht es für die mrpe.cfg:

Hier schaltete ich APT und SSH Checks frei:

Fail2ban soll ebenfalls überwacht werden:

In der Config für diesen Agent steht

und dann muss diese noch ausführbar sein:

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

Dann den xinetd und den Apache neu starten:

Ob überhaupt Daten ankommen ist zu prüfen:

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.

Bilder umbenennen

Ich vergesse es immer und immer wieder, wie einfach das doch geht, alle Bilder in einem Ordner so umzubenennen, dass ich am Dateinamen schon erkennen kann, wann ich das Bild gemacht habe. Ergo: Heute wird das aufgeschrieben!

Weitere Informationen hier: https://linux.die.net/man/1/exiv2

Kürbehöhle II


Größere Karte anzeigen

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:

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.