Archiv des Autors: d.weller

HSK alpha I

Gestern zwängte ich mich also durch die erste Engstelle in den Teil der HSK, der ab jetzt Dachsschluf heißt. In der zweiten Ausbuchtung nach der zweiten Engstelle befand sich nämlich auf der linken Seite ein verlassenes Nest.

Die beiden anderen Fortsetzungen habe ich aufgegeben. Die sind schlicht zu eng.

Insgesamt eine ziemliche Quälerei, das Loch. Eindeutig Elsachbröllerfeeling – auch was die Zahl an Schürfungen und blauen Flecke heute angeht. Die im Dachschluf oft weniger als 30cm zwischen Boden und Decke werden durch Anhäufungen von Boden (immer noch Humus und Erde, aber zunehmend fest) in dem leicht ansteigenden Gang fast plombiert. Man muss sich also entscheiden, in welche Richtung man den Kopf gedreht haben will und kann diese Ausrichtung bis zur nächsten Kuhle in der Decke / im Boden nicht ändern. Rechts und links hat man ein wenig Platz, so dass keine Platzangst aufkommt, jedoch nicht so viel, dass man sich für den Rückweg drehen könnte. Also rückwärts wieder raus, was in der ersten Engstelle dann zu heftigen Flüchen führt, weil man auf dem Rückweg die Arme schon in der Engstelle verkeilt hat und sich trotzdem irgendwie „den Hang hoch“ schieben muss. Also windet man sich Zentimeter um Zentimeter der Eingangskammer entgegen.

Aber hinten geht es weiter. Der sich leicht nach links (?) wendende Gang wird dabei noch ein wenig flacher bzw. die Bodenwellen aus Erde nehmen an Häufigkeit zu, jedoch der leichte Luftzug bleibt.

Jetzt müssen die blauen Flecke abheilen – dann kommt der nächste Anlauf.

Haldenhofhöhlen

Für Bodman-Ludwigshafen sind in Openstreetmap Höhlen eingezeichnet.

https://www.openstreetmap.org/#map=18/47.82070/9.06226

Dort hat es keinen Kalk. Da ist alles Sandstein / Molasse. Da ich am Dienstag vor Ort war, ging ich nachsehen – im festen Glauben, da hat sich jemand eine Scherz erlaubt. Aber tatsächlich: Löcher im Fels!

Die Höhle auf der linken Seite nenne ich auf Grund ihrer Form mal „Haldenhofabri“, auch wenn es sich bei dieser um eine menschliche Grabung handeln dürfte.

Immerhin hat sie zwei kleine Fortsetzungen unbekannter Länge.

In Ermangelung der richtigen Ausrüstung bekroch ich nichts, sondern peilte nur einmal mit dem Disto in Richtung Berg.

Die im Plan bei OSM rechts gelegene „Höhle“ ist ein von Hand aus dem Fels gemeiselter Keller von gut über 20 Meter Länge.

Der kastenförmige Gang ist zu Beginn noch übermannshoch, wird dann aber, je weiter man dem Gefälle in den Berg hinein folgt, niedriger.

Der Gang biegt leicht nach links ab, nähert sich also dem Haldenhofabri und scheint in einem rechteckigen Kellerraum zu enden.

Da sich ungefähr an der Biegung Regenwasser zu einem mehr als knöcheltiefem See gesammelt hat und ich in normalen Schuhen und ohne Lampe unterwegs war, musste eine Peilung und die Handylampe reichen, um zu einer ersten groben Schätzung zu gelangen, wie es hier im Berg aussehen könnte.

Am Anfang des „Sees“ liegen noch Bretter im Wasser … weiter hinten liegen diese unter der Wasseroberfläche. Das nächste Mal habe ich meine Gummistiefel dabei – und Licht.

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.

Trocken

Ich wollte gestern den Schluf in meiner HSK erkunden gehen und musste feststellen, der Wald ist voller Menschen. Das gesamte Plateau zwischen Nebelhöhle und Goldloch – ein einziges Gewusel. Hab ich doch glatt das Nebelhöhlenfest vergessen.

Unter diesen Umständen also kurz am Föhner vorbei geschaut, in der Hoffnung, wenigstens dort etwas Sinniges tun zu können. Der war jedoch verwaist und trocken. Das Wasser kam geschätzte 15 Meter tiefer aus dem Lehmgrubenbröller.

HS-Kammer rev. pre alpha

Der erste Test des Disto X2 vor Ort war auch OK. Was bei mir jedoch noch überhaupt nicht läuft, ist das Denken in Plänen, wenn ich vor Ort bin. Die Planskizze oben ist demnach trotz Vermessung mit Disto schlicht Mist – oder „pre-alpha“ – weil ich immer erst am Rechner zu Hause feststelle, welche Splays geschickt gewesen wären. Auch meine händischen Skizzen taugen nicht viel: teilweise fehlen die entscheidenden Punkte, teilweise sind nicht darstellbare Details enthalten. Ich muss noch viel üben.

Was in mir gestern keimte, war der Verdacht, dass es sich bei der HSK nicht um eine klassische Sekundärhöhle handelt. Das könnte ein schlichter Überhang von ca. 10m Tiefe sein, der in den letzten hunderten von Jahren langsam von Unten her mit Humus aufgefüllt wurde … und ich quäle mich da nun der ehemaligen Decke entlang zur Rückwand desselben. Das am weitesten rechts stehende Fragezeichen muss aber zum Ausrufezeichen werden: ich will wissen, wo der leichte Luftzug herkommt.

Disto X2 toolchain

Bevor es dann Morgen mit dem frisch gelöteten Disto X2 und einem Schäufelchen bewaffnet in mein Kleinstloch geht, probierte ich meine Toolchain heute noch zu Hause aus:

Disto X2 per Bluetooth mit dem Handy koppeln, unter Qave die Daten erfassen und diese dann vom Handy über die ownCloud auf den Laptop schieben. Dort die Datensammlung mit CaverenderPro weiter verarbeiten.

Hat ganz ordentlich funktioniert. Ein Teil des Treppenhauses musste heute dazu herhalten und sieht nach vielen ziemlich sinnfreien Shots dann wie oben aus.

GIF anklicken, damit es sich dreht.

Disto X2

So alt wie heute kam ich mir selten vor: beim Umbau meines Distos wäre ich ohne Lupe und Daniels Fingerfertigkeit beim Umgang mit Lötkolben und vor allem auch den Flachbandkabeln nie fertig geworden. So war es eine Aktion von 2,5 Stunden … und jetzt stelle ich fest, dass mein Nexus 4 nicht richtig über TopoDroid unter Bluetooth mit dem Disto X2 reden will. Da wird hoffentlich ein Update von LOS helfen.

Auf Flo läuft alles wesentlich besser, so dass ich vermutlich mein Tablet für’s Kalibrieren nutzen werde.

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

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:

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.