Archiv der Kategorie: Moodle

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.

Moodle 2.9.x Teil I

Moodle 2.9.x braucht als DB-Engine zwingend InnoDB und läuft nicht mehr mit MyISAM. Im Verlauf des Updates meldet sich deswegen Moodle mit der Meldung

Erster Schritt ist die Kontrolle, ob die eigene mySQL DB InnoDB überhaupt unterstützt. Hierzu z.B. in phpmyadmin anmelden und dort auf dem Reiter SQL

absetzen [1]. Meist zeigt die Ausgabe das hier:

showengines

und alles ist gut. Wenn nicht, dann hat man richtig Arbeit an der Backe und muss zuerst die MySQL Installation auf Vordermann bringen.

Dann im Backend von Moodle (als Administrator) die URL wie folgt anpassen:

und der Migrationsprozess rattert los. Das kann dauern. Lange.

Moodle schimpft dann evtl. über Tabellen im Antelope Format, statt des gewünschten Barracuda:

Hier ist man nun auf die Shell gezwungen, wenn ich das richtig sehe. DB-Experten mögen mich korrigieren.

Erst einmal nachschauen, welche Tabellen überhaupt bearbeitet werden müssen. Das geht mit einem Script, das Moodle mitbringt und das über dem Moodle-Stammverzeichnis ausgeführt werden muss:

Bei mir ergab das

was sich mit Hilfe des oben genannten Scripts durch den Schalter –fix jedoch nicht reparieren lässt, weil man hierzu mehr Rechte innerhalb der MySQL-DB benötigt, als bei mir hier der Apache hat.

Moodle selbst läuft auch unter Version 2.9.x noch mit Antelope – das Upgrade kann also stattfinden. Da ich die Nebenwirkungen von Barracuda schlecht abschätzen kann, wenn ich mit der DB-Kompression spiele (da hängen auch noch WordPresse und Typos mit dran), bespreche ich mich mal lieber zuerst mit Frank. Mal sehen, was der meint – und dann geht es weiter.

 

 

Atto, TinyMCE und Moodle 2.7.x

Mit der Schule bin ich gestern erst auf die Moodle 2.7.2er Reihe von 2.6.5 aus umgestiegen. Da etwas länger zu warten bringt am Ende weniger Bugs und Ärger. Abgesehen von einer Anpassung der Aufgabenformate ist mir aufgefallen, dass nun Atto als Default-Editor keinen Schalter für Emoticons mehr zeigte. Dieser lässt sich aber nachrüsten:

atto1

Unter /Plugins /Texteditoren /Texteditor Atto /Einstellungen findet man eine Liste der Editorenfunktionen und darunter ein Feld, in das man seine Ergänzungen eintragen kann oder über das man die Reihenfolge der Knöpfe verändert.

atto2

Ein emoticon = emoticon fügt Atto den wichtigsten Knopf im System wieder hinzu.

editoreninmoodle

Will man lieber gleich zum mächtigeren TinyMCE wechseln, dann schiebt man diesen unter /Texteditoren /Übersicht über Atto.

tinymce

Da ist dann der Emoticon-Schalter gleich wieder mit dabei.

Nebenwirkungen

TinyMCE verwendet DragMath als Formeleditor. Das bedeutet Java Plugins müssen im Browser aktiviert werden können (IcedTea). Atto nutzt hierfür MathJAX. Das klappt zwar ohne Java – dafür lädt sich dieser Formeleditor Code aus den USA nach und was dabei in die andere Richtung über den Atlantik geht, weiß wieder keiner.

Man hat demnach die Wahl zwischen Java und NSA. Super.

Moodle Glossary Export

Schüler können aus dem Moodle Glossary in den Grundeinstellungen keine XML Dateien exportieren und das bedeutet, dass sie sich nicht das komplette Glossary besorgen können – nur immer einzelne Einträge. In den Rechteeinstellungen der Aktivität lässt sich dies durch setzen eines Häkchens für die Rolle „Teilnehmer/in“ jedoch erlauben (siehe Bild oben).

In der Seitenleiste „Einstellungen“ finden diese sodann einen Schalter „Exportieren der Einträge“ vor, der dann einem Download-Dialog „Exportiere in Datei“ enthält.

Wie dann mit der XML Datei weiter verfahren wird, mit der die meisten Schüler/innen ja ebenfalls überfordert sind, führe ich noch aus. Ein Konvertierungsscript nach HTML hat ein Schüler von mir schon geschrieben – nur ist dies noch nicht ausführlich getestet und noch nicht von ihm unter CC oder GPL gestellt worden.

Hoffnungsschimmer

Es besteht wieder Hoffnung: Der neueste Moodle 2 Build erstellt doch tatsächlich auch Backups. Daran war auf Grund meiner bisherigen Erfahrungen [1, 2] zu zweifeln gewesen. Noch werde ich meinen Bugreport nicht auf gelöst setzen – erst in ein paar Tagen.

Moodle Backupproblem ungelöst

Da verwurstet moodle.org seine Zeit damit, für mobile Endgeräte eine automatische Erkennung zu basteln, damit diesen gesonderte Themes angeboten werden können, aber das wirklich kritische Problem, dass Moodle einem jede Nacht mitteilt, das Backup sei ohne Fehler durchgelaufen während nichts (im Sinne von gar nichts) gesichert wurde … darum kümmern sie sich nicht. Moodle kotzt mich gerade an.

Sachlicher ausgedrückt: Meine Backupprobleme bleiben auch bei Moodle 2.1 bestehen. Das ist ein Blocker! Wer kann, sollte bei Moodle 1.9.x bleiben.

Moodle 2 Backup kaputt

Jeden Tag schickt mir mein Moodle brav eine Mail, in der steht, dass alle Kurse erfolgreich gesichert worden seien:

Beschreibung
==================================================
Kurse: 178
OK: 178
Übersprungen: 0
Fehler: 0
Noch nicht abgeschlossen: 0

Sicherung erfolgreich abgeschlossen

Leider eine glatte Lüge. Das dumme Ding sichert überhaupt nicht, sondern wirft nur mit Fehlermeldungen um sich, die es dann aber nicht verschickt, sondern nach

/moodledata/temp/backup

wirft, damit auch ja niemand drauf kommt, dass überhaupt was schief geht.

In diesem Verzeichnis finden sich nun aberhunderte von Logs mit dem schlichten Inhalt

[warn] backup_auto_failed_on_course coursename

und das für jeden Kursraum. Ergo: Mal wieder einen Bugreport losgetreten.

Moodle 2 Backupeinstellungen

Die Grundeinstellungen von Moodle2 erlauben es einem Trainer (editingteacher) nicht, dass dieser Nutzerdaten sichert, was dazu führt, dass in den exportierten Kursräumen immer nur Teile des Raumes enthalten sind … was dann wiederum dazu führt, dass der Administrator der Moodle2-Installation das leidige Backupgeschäft nicht an die Trainer in den Kursräumen delegieren kann.

Es reicht leider nicht, als Administrator die Backupeinstellungen vernünftig zu wählen – z.B. wie im Bild oben – so dass diese dem Datenschutz ja durchaus gerecht werden, weil ein Export von Nutzerdaten nur anonymisiert möglich ist und der Export von Logdaten überhaupt nicht. Die Trainerrolle selbst muss angepasst werden.

Dazu als Administrator an der Moodle2-Installation anmelden und im Bereich /Website-Administration /Nutzer/innen /Rechte /Rollen verwalten auf den Eintrag für die Trainer klicken.

Im Bereich „Kurs“ sind auf dieser Einstellungsseite zwei Checkboxen auf „Erlauben“ zu setzen – was in Kombination mit den globalen Einstellungen für die Kursraumsicherung dazu führt, dass nun der komplette Kursraum vom Trainer gesichert werden kann, ohne dass der Datenschutz über die Wupper geht.

Die Nutzerdateien können nun Teil des Kursraumexportes sein und dieser ist damit so umfänglich sicherbar, dass eine Delegation des Backupgeschäftes und vor allem der Backupverantwortung an Trainer OK erscheint.

Meinen Bug-report hab ich einstampfen dürfen.

Dumbobackup

Da meine Moodle 2 Installationen im Moment noch nicht vollständig in backup2l integriert werden können, darf ich die Kursräume händisch sichern. Das nervt, wenn man das nicht automatisieren kann.

Auf dem Server schreibt das in Moodle 2 integrierte Backup die Kursräume jede Nacht in das Verzeichnis

/server/dir/mdlbckp/

Aus diesem Verzeichnis sollen dann die Kursraumbackups (im Moodle 2 üblichen mbz Format) auf die lokale Platte in das Verzeichnis

/localpath/bckp_tagmonatjahr/dir1

wandern, wobei dieses Verzeichnis einen „Datumsstempel“ im Pfadnamen tragen soll.

Ich hab das mal so gelöst:

#!/bin/bash
# Datum in Variable schreiben
d=$(date +%d%m%Y)
# Lokales Verzeichnis mit Zeitstempel anlegen
mkdir -p /localpath/bckp_$d/dir1
# Moodle Kursraumbackups vom Server holen
scp -r user@server.de:/server/dir/mdlbckp/* /localpath/bckp_$d/dir1

Für jedes zu sichernde Moodle 2 auf dem Server wird das Skript dann um einen mkdir -p Aufruf und den entsprechenden scp -r Befehl ergänzt.

Wenn scp Dank public key Verfahren auf den Server zugreifen darf, dann ist das Skriptchen – über einen cronjob aufgerufen – nun wenigstens ein workaround.