Archiv der Kategorie: Schule

WebUntis Scraper

Der Stundeplanrechner wirft die WebUntis HTML Dateien in ein WebDAVs Share. Dieses ist auf dem Moodle Server per Symlink in das Arbeitsverzeichnis des folgenden untisparser Skriptes eingebunden. Von dort wird das Ergebnis in ein File Repository des Lehrermoodles geschrieben und aus dem Kursraum „Schwarzes Brett“ (die Kommunikationsplattform der Schule) verlinkt. Das stellt sicher, dass nur Menschen, die a) am Moodle angemeldet und b) Mitglied des entsprechenden Kursraumes sind den Inhalt (hier: Vertretungsplan) einsehen können.

Mit geschlossenem Accordion

Accordion offen

Das muss leider so umständlich sein, weil ich keinen Weg gefunden habe, den WebDavs Ordner als solchen navigierbar im Kursraum so einzubinden, dass man diesen nicht auch von außerhalb des Moodles aufrufen könnte. Mir bleibt (sofern ich richtig liege) nix anderes über, als aus den X html Dateien, die WebUntis mir hinwirft, eine einzige zu bauen, die ich klar benamen und dann „verlinken“ kann. Dazu muss ich die vielen WebUntis HTML Dateien in ihre Bestandteile zerlegen. Ich brauche: Die Tabellen und die Zeitangaben.

Im Prinzip geht das mit beautifulsoup und Python. Meine Python-Kenntnisse sind jedoch leider noch rudimentärer als meine Bash-Kenntnisse … also muss  ein bash Skript her. Und HTML mit Bash nativ parsen  – nun: ich weiß, dass das Probleme macht. Das will man nicht.

Die Lösung ist pup, das ich in ein Bash-Skript einbinde.

Zur Information die Struktur der WebUntis Dateien in ihren Ordnern / Unterordnern:

Die zu erzeugende Output-Datei soll HTML sein und braucht dazu einen Kopf:

Siehe zum Code für das Accordion im Kopf und im „Kleister“: https://www.w3schools.com/howto/howto_js_accordion.asp  Leider hat das aber nicht gereicht. Zuerst muss gewartet werden, bis die gesamte Seite geladen ist, dann erst darf die for-Schleife beginnen. Also wird das Skript in den Footer gelegt oder gekapselt in:

Was einen Kopf hat, braucht auch einen Fuß:

Und dann braucht es den „Kleister“, der die Arbeit macht und alles zusammenpackt. Nennen wir es untisparser.sh und legen es in das passende Verzeichnis auf dem Server:

Cron ruft das Skript alle 20 Minuten auf. Schöner wäre natürlich, wenn das Skript nur liefe, wenn sich was ändert im WebDavs Share. Aber inotify und Freunde sind auch nicht ohne. So ist es simpel und scheint zu funktionieren, ohne viel Ressourcen zu fressen.

Update 23.08

Einige Fehler im Skript (meist die vergessenenen \ vor den „) behoben und mit Hilfe von JavaScript mehr Übersichtlichkeit im Output erzeugt.

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:

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]

Etherpad auf 16.04

Ein Update zu der etwas in die Jahre gekommenen Anleitung zur Installation von Etherpad Lite auf Ubuntu, auch wenn sich viele Dinge nicht wirklich grundlegend geändert haben.

Erst einmal versorgen wir unseren Server mit einem aktuellen NodeJ.js sowie NPM. Die Anleitung hierzu: https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions

Dieser wird gefolgt, bis mit

nicht nur NodeJS, sondern auch NPM an Bord ist.

Es folgen die Vorbereitungen für die lokale Installation von EP:

Dazu gehört ein Benutzerkonto etherpad:

In dessen Kontext dann gewechselt wird, um EP zu installieren:

Der erste Start installiert die Abhängigkeiten und sollte es danach ermöglichen, die Etherpad Installation unter http://example.org:9001 aufzurufen. Gelingt dies, dann brechen wir EP mit STRG C ab, um in Ruhe die Datei settings.json in /opt/etherpad/etherpad-lite sowie den Web- und DB-Server anzupassen.

Da wir nun immer wieder EP neu starten (als user etherpad) und außerdem als root weitere Pakete nachinstallieren sowie Anpassungen vornehmen müssen macht eine zweite Shell zum Server Sinn.

Nach der Installation von Apache2 und der Einrichtung von SSL-Zertifikaten folgt die Aktivierung der entsprechenden Module im Apachen:

Ich folge hier im Wesentlichen der Anleitung hier: https://github.com/ether/etherpad-lite/wiki/How-to-put-Etherpad-Lite-behind-a-reverse-Proxy und erhalte am Ende eine VirtualHost Definition, die so aussieht:

Nach einem Neustart des Apachen und einem erneuten Start von EP lite (aus dem Konto von etherpad heraus) sollte EP über https abgerufen werden können.

Hinweis zu den geladenen Apache-Modulen: wstunnel beseitigte bei mir Fehlermeldungen wie die diese:

Wir können EP nun wieder mit STRG C anhalten und eine Datenbank für EP einrichten. Dazu benötigen wir einen MySQL-Server sowie, bei Bedarf, phpMyAdmin für die einfachere Verwaltung. Weiter sollte auch abiword mit an Bord geholt werden, damit Pads exportiert werden können.

Sind diese Schritte vollbracht, wird die settings.json überarbeitet:

Viel angepasst habe ich nicht: Die Datenbankverbindung, den einführenden Text in jedes Pad mit einem Verweis auf die Benutzerordnung und das Passwort für den administrativen Benutzer.

Ob die Datenbankverbindung glückt, wird erneut aus dem Kontext des Benutzers etherpad geprüft. Danach wird Etherpad als Service eingerichtet.

Dazu erstellt man sich eine Datei /etc/systemd/system/etherpad.service mit folgendem Inhalt:

Das entspricht bis auf die Pfade der Anleitung hier: https://github.com/ether/etherpad-lite/wiki/How-to-deploy-Etherpad-Lite-as-a-service 

Gelingt der Start mit service etherpad start kann man mit ufw den Port 9001 zu machen und in den Betrieb übergehen. Wer will kann etherpad auch automatisch starten lassen: systemctl enable etherpad

Der Login-Screen von Etherpad kann in /opt/etherpad/etherpad-lite/src/templates/index.html an die eigenen Wünsche angepasst und z.B. um Links zum Impressum und zur Benutzerordnung erweitert werden.

Nur noch ein Punkt: Das Plugin, das man als schulischer Admin unbedingt haben will, ist das hier: https://www.npmjs.com/package/ep_adminpads

VM Transfer

EIne VM braucht so seine Zeit bis sie eingerichtet ist. Wenn nur das Netz im Hause lahmt, dann kann man diese zu Hetzner umziehen. Ich hab das mal mit Proxmox (Hetzner) und VirtualBox (im Haus) getestet.

Hier die /etc/network/interfaces des Rootservers bei Hetzner mit den Routing für die VMs:

Man erstellt sich in Proxmox eine KVM VM (hier mit der IP 99.99.99.83) mit ausreichend HDD-Platz, um den zu Hause liegenden Server aufzunehmen. Dabei achtet man in der Proxmox-GUI darauf, dass die Einstellungen möglichst genau denen der zu übetragenden VM in VBox entsprechen – z.B. virtio für die Netzwerkkarten.

Dann zieht man sich ein Live-Medium als ISO (bei Hetzner mit wget -4 weil die IPv6 Namensauflösung länger dauert als der Download) auf dem Proxmox-Server nach /var/lib/vz/template/iso und bindet dieses in der KVM-VM in Proxmox ein. Davon dann booten.

Die Wahl des Tastatur-Layouts gelang VNC in Proxmox bei Ubuntu ISOs hierbei nicht immer, weswegen man auch gleich bei US bleiben kann. Bessere Erfahrungen machte ich mit Lubuntu ISOs.

Ist das Live-Medium gebootet, müssen dessen Netzwerkeinstellungen händisch vorgenommen werden. Dabei können IP und Gateway noch über die grafische Oberfläche festgelegt (meist handelt es sich bei den Live-Medien um den Network-Manager) werden. Als DNS kann man z.B. den von Google (8.8.8.8) nutzen. Das Feld für Gateway bleibt leer. Denn: Die Routen für die KVM-VM müssen händisch mit ip route add gesetzt werden.

Meist muss für eth0 noch der Name des Interfaces an den der KVM-VM angepasst werden. Wie das Interface sich im gegebenen Fall nennt, zeigt ein ifconfig.

Netzwerkverbindung testen.

In der KVM-VM wird zu einer root shell gewechselt und für root ein Passwort vergeben

Dann einen openssh-server installieren und dessen Konfiguration so anpassen, dass sich root über SSH mit Passwort einloggen darf. Den SSH Server neu starten.

Jetzt kann man schon ausprobieren, ob man sich von der lokalen VBox VM auf dem Live-Medium bei Hetzner einloggen kann.

Klappt das, dann kann es mit dem Transfer der lokalen VBox VM losgehen.

Dazu legt man auf der HDD der KVM-VM zuerst ein Dateisystem an. Im Live-Medium kann man hierzu sogar Gparted nutzen.

Dann mounted man die root Partition (müsste /dev/sda1 sein) der KVM-VM nach /mnt und der eigentliche Transfer erfolgt nun in mindestens zwei Schritten, will man die downtime des lokalen Servers klein halten: Einmal einen rsync aus dem laufenden System heraus. Ein zweites mal, nachdem das lokale System ebenfalls mit einem Live-Medium gebootet wurde, um die Veränderungen auch noch zu übertragen. Ist einem die downtime egal, dann nutzt man am besten gleich lokal ein Live-Medium.

Ab jetzt sind wieder die im Vorteil, die viel Bandbreite im Upstream haben. In meinem Fall wird die Übertragung 33 Stunden dauern, was dazu führt, dass mir die Zwangstrennung der Internetverbindung die Übertragung in einem Rutsch vermasselt.

Literatur 1, 2, 3

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

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

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

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

liegt.  Hier dann im Bäumchen users unter

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.

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.

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:

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

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.

Writer2DokuWiki

Bisher nutzte ich für die Konvertierung von Texten für DokuWiki das Plugin Writer2Dokuwiki und hatte wenig Probleme. Das jetzt frisch verfügbare LibreOffce 5.1 schmiert mir hierbei jedoch kommentarlos ab, so dass ich auf die Schnelle eine andere Möglichkeit brauchte. Diese ist nun eine Kombination aus tidy und pandoc.

loexportformat

In LibreOffice wird das Exportformat für HTML Dateien zuerst unter /Extras /Optionen /Laden-Speichern /HTML-Kompatibilität auf UTF-8 umgeschaltet.

Über /Datei /Speichern unter wird nun das HTML-Format ausgewählt und die Datei gespeichert.

Hinweis: Der Exportdialog unter /Datei /Exportieren… erzeugt XHTML Dateien, die noch schwerer zu putzen sind. Also nutze ich diese Funktion nicht.

Der von LibreOffice erzeugte HTML-Code ist grauenhaft. Also muss dieser mit tidy geputzt werden. Die tidy.conf liegt hierbei in meinem Stammordner im dortigen ~/bin Verzeichnis:

Ein

wirfft weg, was wir nicht brauchen. Ein bischen class=western kann dabei übrig bleiben, tut aber nicht weiter weh.

Als nächstes kommt pandoc in einer Version größer gleich 1.13 zum Einsatz (unter Ubuntu 15.10 vorhanden):

Die TXT Datei dann mit einem Editor öffnen und den Inhalt in DokuWiki einfügen. Voila. Zusammen macht das dann

oder gleich als Skript verpackt:

Das klappte hier mit less und leafpad, das von mir sonst bevorzugte kate wollte nicht von stdin lesen. Da muss ich noch einmal nachsehen, woran das lag.

Man kann auch den Aufruf von LibreOffice und damit den ersten Schritt in das Skript integrieren, sofern die (angelieferten) Dokumente mit Formatvorlagen erstellt wurden. Das ist in meinem Kollegium hoffnungslos – aber im Prinzip ginge ein

Quellen: [1] [2]

Redis Server und HSTS für ownCloud

Im Backend vermeldete ownCloud schon längere Zeit, dass es einen funktionierenden PHP Memory Cache vermisse. Bisher war mir das relativ egal, weil ich nicht viele Dateien und auch nicht viele Nutzer/innen hatte. Das hatte sich in den letzten Wochen und Monaten aber gründlich geändert, so dass ich bei drei meiner oC Installationen tätig werden musste. Nach dem Update auf oC 8.2.2 und Dank etwas freier Zeit ging ich das Problem endlich an.

APC und APCu waren zwar bei allen Servern an Bord, aber unter Ubuntu 14.04 und PHP5 „zu alt“. Ich probierte es mit Redis. Hier ist das PHP5 Modul von Ubuntu 14.04 zwar ebenfalls zu alt, aber es gibt in den PECL Repositories einfach zu installierenden Ersatz.

Ein

klärt, ob ein solches PHP Modul installiert ist. Wenn ja, dann muss dieses zuerst runter vom Server. Danach kann der Redis Server an Bord:

Ein Blick in

sollte ergeben, dass Redis an 127.0.0.1 lauscht und somit nicht von außen zu erreichen ist. Wer sich nicht sicher ist, kann von außen mit telnet nachsehen. Weiter sollte ein

zeigen, dass der Redis-Server auch läuft.

Um PECL nutzen zu können benötigen wir noch die folgenden Pakete

Wer, wie ich hier, Horde5 über PEAR bezieht, hat die Pakete schon. Ein

bringt dann ein frischeres php Modul für Redis an Bord. Am Ende der Installation weißt PECL darauf hin, dass dieses Modul der vorhandenen PHP Umgebung bekannt gegeben werden muss. Da hilft

Dann wird der Memory Cache ownCloud in

bekannt gegeben, indem der folgenden Code ans Ende gehängt wird (vor die letzte schließende Klammer):

Im Backend von ownCloud herrscht nun etwas mehr Ruhe.

Was ownCloud leider nicht überprüft ist, ob es überhaupt über HTTP zu erreichen ist. Es schimpft immer über eine fehlende HSTS Konfiguration, bis eine solche eingerichtet ist.

Das ist mit

und dem Eintrag

für die ownCloud Domain dann nach einem Neustart des Apachen auch erledigt, hat aber Nebenwirkungen: HTTP Verbindungen sind hiermit für die gesamte Domain ab dem ersten Aufruf über HTTPS für den Client-Browser erledigt. Muss man wollen.

Geholfen beim Einrichten haben mir die folgenden empfehlenswerten Quellen: 1, 2, 3, 4