Archiv der Kategorie: Moodle

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.

Moodle frisst Server

Eigentlich dumpe ich jede Nacht alle Datenbanken auf dem Server und verpacke diese zusammen mit den Webserververzeichnissen in Archive – bzw. backup2l macht das für mich. Diese Archivdateien rsynce ich am frühen Morgen auf meine lokale Platte bzw. auf meinen Backupserver in der Schule.

Jahrelang ging das glatt. Moodle 1.x.y legte brav nur die Dateien in die Unterverzeichnisse von /moodledata, die von den Nutzern hochgeladen wurden. Moodle 2 benimmt sich komplett anders – wie, genau, weiß ich noch nicht. Da komm ich gerade erst dahinter. Auf jeden Fall fressen die frisch installierten Moodle 2 langsam den Plattenplatz auf dem Server und auf den Backupservern auf, weil sich jede Nacht gleich pfundweise Dateien und Verzeichnisse innerhalb von /moodledata verändern und so die Archive aufblähen.

Nachdem in den Foren auf moodle.org zu dem geschilderten Problem keine Reaktion kam, trug ich einen bug report ein. Jetzt kommt Bewegung in die Sache … aber eine saubere Lösung steht wohl noch für einige Zeit aus.

Im Moment packt backup2l nur noch die WordPresse und DokuWikis sowie die Moodle 1.9.x Installation – nicht aber Verzeichnisse, die ein Moodle 2 enthalten – ein. Moodle 2 Backups gibt es nur noch ein paar mal im Monat – und da dann lediglich von den von Moodle 2 selbst angelegten Kursraumbackups.

Was für ein Gewürge.

Decaf

Das Moodle Theme decaf hat es mir angetan: Klar gegliedert und relativ einfach anzupassen. Das brauch ich auch. Ich hab fast 10 Moodle-Installation im Web zu betreuen, da will ich nicht jedes mal alles neu erfinden müssen, sondern möglichst mit einem Logo und der Veränderung von ein, zwei zentralen Farben des Themes so hinkommen, dass ein Unterschied zwischen den Seiten zu erkennen ist.

Eine Dokumentation der von mir vorgenommenen Anpassungen befindet sich im KvFG Wiki hier:

https://www.kvfg.net/wiki/doku.php?id=web:moodle:theme2

Dafür zu sorgen, dass versteckte Elemente sich von den nicht-versteckten Elementen im Kursraum sichtlich unterscheiden – das hat am längsten gedauert.

Sun Java 6 auf Hardy 64 Bit

Was hab ich mir nicht einen abgebrochen mit Symlinks nach irgendwelchen Anleitungen in Blogs und Foren zu setzen, um das Sun Java Firefox Plugin unter Ubuntu Hardy 64 Bit zum Laufen zu überreden.  Am Ende war es ganz einfach und klappte ohne Gefummel in den Untiefen des Systems durch den Rauswurf von IcedTea:

sudo apt-get remove –purge icedtea-gcjwebplugin

Dann wird Suns Java schlicht erneut installiert:

sudo apt-get reinstall sun-java6-bin sun-java6-fonts sun-java6-jre sun-java6-plugin

Fertig.

Keine Ahnung warum das nun will und früher nicht. Meiner Erinnerung nach hab ich IcedTea irgendwann installiert, um Java zum Laufen zu überreden – aber ich kann mich auch täuschen. Auf jeden Fall hab ich so kurz vor Erscheinen von Lucid ein rund um konfiguriertes 64 Bit System, in dem auch das Dragmath-Plugin für Moodle läuft.

Das brauch ich zwar nicht – aber nett ist es trotzdem 🙂

Bugtracker für Moodle

Das Moodle Bug Tracker Modul ist praktisch  – für Seiten, die nicht zu viele Ansprüche an eine derartige Software stellen, sondern wie ich in der Schule erfassen müssen, welcher PC welches Problem hat.

Leider fällt das Modul auf einem „deutschen Moodle“ auf die Nase, weil ihm eine Kleinigkeit fehlt: Das deutsche Sprachmodul.

Also wechselt man in das Verzeichnis des Trackers und dort in das Unterverzeichnis mails/. Auf vielen Systemen dürfte dies einem Pfad wie dem folgenden entsprechen:

…/moodle/mod/tracker/mails

Dort kopiert man nun das englische Verzeichnis schlicht unter einem neuen Namen durch Eingabe von:

cp -rp en_utf8/ de_utf8/

Jetzt klappt die Erfassung von neuen Meldungen – wenn auch nicht komplett auf Deutsch.

MRBS als Klassenarbeitsordner

Das für Moodle ebenfalls erhältliche Zusatzmodul MRBS kann als Klassenarbeitsordner gebraucht werden, in den die Kolleg/innen Ihre Termine eintragen. Hierzu müssen aber ein paar Anpassungen gemacht werden.

Sprachliche Anpassungen

screenshot_001

Als Admin im Moodle anmelden und die Texte von MRBS bearbeiten.

screenshot_002

Dazu die Datei block_mrbs.php auswählen und dort alles was nach Raumbuchung klingt durch Klassenarbeitsordner ersetzen.

Ich habe hier die Raumkategorien (Bereiche) als Stufen angelegt und die Räume als Klassen. Außerdem hab ich „Klasse/Lehrer“ durch „Eintrag für Fach“ ersetzt.

Weitere Modulanpassungen

Weiter macht es Sinn, nicht Stunden eingetragen zu haben, sondern „Slots“ für Klassenarbeiten – sonst fangen die Kollegen an, parallel unterichtete Fächer wie Ethik, kath Rel und ev Rel (oder auch Spanisch, Französisch, NwT) an verschiedenen Tagen einzutragen, in der Annahmen, „Ihre Stunde“ sei schon besetzt. Das führt zu einer schnellen Verknappung an Tagen, die überhaupt für Klassenarbeiten zur Verfügung stehen.

Außerdem sollten die MRBS-Kategorien „Intern“ und „Extern“ durch „Klassenarbeit“ und „Test“ ersetzt werden. Ich hab noch zusätzlich die Kategorie „geblockt“ eingeführt – man weiß ja nie.

Alle diese Einträge finden sich im Moodle Administrationsmenü unter Module /Blöcke / MRBS, was einem Moodle-Admin durchaus bekannt sein dürfte.

Aufrufen des Berichts

screenshot_003

Aufgerufen wird der Klassenarbeitsordner für die Erstellung eines Aushangs dann durch Klick auf [Bericht] in der MRBS Oberfläche.

screenshot_004

Einzutragen ist bei „Suche Klasse“ die Klasse und auszuwählen ist „Test“ bzw. „Klassenarbeit“ als Kategorie. Ein Klick auf den Schalter [Bericht erstellen] wirft diesen aus.

Auf der Seite mit dem Bericht nun nach Unten scrollen und auf Druckansicht klicken, Seite ausdrucken und im Klassenzimmer aushängen. Fertig.

Anmerkungen: Ideal wäre es, den Klassenarbeitsordner den Schülern mit reinen Leserechten online zur Verfügung zu stellen, dann können die sich gleich im Moodle informieren. Das macht aber nicht jede Personalvertretung mit.

Weiter kann für jeden Raum (hier: Klasse) eine Mailadresse eingerichtet werden (Raumadministrator), die alle Einträge und Veränderungen zugeschickt bekommt. Wenn hier als Empfänger ein Listendaemon eintragen wird (Mailman), der die Mails an die Klassenmailingliste weiter verteilt, sind alle glücklich!

Anhübschen und Datensparsamkeit

Leider sieht der Bericht nun nicht hübsch aus, weil er viele Zusatzinfos mit sich bringt, die eine Klasse nicht haben muss (wer hat was wann eingetragen und verändert). Diese Informationen müssen auf Modulebene bearbeitet werden:

Dazu wurden die Zeilen 192-195 in der report.php auskommentiert, nachdem diese zuerst als report.php.bak gesichert wurde:

# Created by and last update timestamp:
 # echo "<tr><td class=\"BL\" colspan=2><small><b>".get_string('createdby','block_mrbs')."</b> " .
 # htmlspecialchars($row[6]) . ", <b>".get_string('lastmodified')."</b> " .
 # time_date_string($row[7]) . "</small></td></tr>\n";

Und jetzt funktioniert’s und sieht ordentlich aus.

Moodle, MRBS und force login

Ich will im nächsten Schuljahr den Block MRBS im Moodle meiner Schule als Klassenarbeitsordner zur Verfügung stellen. Dabei sollten die Schüler/innen nur sehen können, wann Sie eine KA schreiben und die Berichtsfunktion nutzen, die Lehrer/innen sollten diese eintragen können und die Eltern sollten möglichst ohne ihre Kinder nur lesenden Zugriff haben – nicht jedoch Zugriff auf die Berichtsfunktion.

Leider fehlt eine solche Funktion im Add-on Paket zu Moodle. Dabei ist diese leicht nachzurüsten:

Ich habe in der report.php nun das Folgende stehen (fett gedruckt sind meine Zugaben):

<?php
# $Id: report.php,v 1.8 2008/08/17 23:07:29 arborrow Exp $
require_once(„../../../config.php“); //for Moodle integration
require_once „grab_globals.inc.php“;
include „config.inc.php“;
include „functions.php“;
include „$dbsys.php“;

require_login();
#if ($CFG->forcelogin) {
# require_login();
# }

[…]

Das scheint reibungslos zu funktionieren. Wenn jemand auf den Schalter „Bericht“ klickt, dann zwingt Moodle die Person zum Login. Da der Bericht die Funktion ist, mit der im MySQL Dummheiten gemacht werden könnten, bin ich damit wohl vorerst auf der sicheren Seite.

Dieser Zwang zum Login könnte auch Teil der index.php werden, wenn MRBS für Fremde komplett unlesbar sein soll.

<?php

# $Id: index.php,v 1.2 2007/12/28 05:53:06 arborrow Exp $

# Index is just a stub to redirect to the appropriate view
# as defined in config.inc.php using the variable $default_view
# If $default_room is defined in config.inc.php then this will
# be used to redirect to a particular room.
require_once(„../../../config.php“);; //for Moodle integration
require_once „grab_globals.inc.php“;
include(„config.inc.php“);
include(„$dbsys.php“);
require_login();

[…]

Noch was: Der Gastzugang muss dann ausgeschaltet sein – sonst können Gäste weiterhin den Bericht aufrufen, da diese dem System gegenüber keine Fremden mehr sind. Soll auch das verhindert werden, dann darf die Berichtsfunktion nur dem Admin allein zugeteilt werden.

In die report.php gehört für diesen Fall der folgende Code:

[…]

#check if user is admin
if( ! getAuthorised(2))
{
showAccessDenied($day, $month, $year, $area);
exit();
}

[…]

Selbstverständlich darf das […] in den Codeschnipseln jeweils NICHT mitkopiert werden – das steht hier nur, damit klar wird, dass die jeweilige Datei noch weitergeht.

Mehr war das nicht. Garantie für die Sicherheit und Funktionsfähigkeit von MRBS und Moodle nach der Anwendung dieser Hacks übernehme ich selbstverständlich keine, die Anwendung erfolgt auf eigenes Risiko. Bei mir läuft der Hack seit Juli 2009 ohne Probleme – bei über 700 Buchungen im Monat.

ewiki, moodle, openbase_dir

Mein / Unser neuer Server ist etwas abgesicherter als der alte Rechner, was vor allem an Frank liegt, der der festen Meinung ist, dass keine Paranoia zu haben nicht bedeutet, dass sie nicht doch hinter dir her sind.

Dumm nur, dass das Standard Wiki von Moodle (ewiki oder auch Erfurt Wiki) Zugriff auf die eine oder andere Datei außerhalb des eigentlichen Webserververzeichnisses will, um beim Speichern von Wikiseiten zu überprüfen, ob nicht noch jemand Veränderungen vorgenommen hat – openbase_dir weiß dies aber zu verhindern. Gleich nach dem Anlegen eines neuen Wikis bockt Moodle nun und zeigt die folgende Fehlermeldung:

Warning: is_executable() [function.is-executable]: open_basedir restriction in effect. File(/usr/bin/patch) is not within the allowed path(s)

Auf ewiki will ich aber nicht verzichten: dfwiki oder nwiki kann nämlich die schon vorhandenen Wikis meiner alten Moodleinstallation nicht fehlerfrei importieren.

Meine Lösung war nun: Ich habe in einem Verzeichnis "neben" /moodledata das Verzeichnis /bin angelegt und dort die beiden Dateien /usr/bin/diff und /usr/bin/patch hineinkopiert. Dann hab ich die Datei /moodle/mod/wiki/ewiki/plugins/patchsaving.php editiert:

define("EWIKI_BIN_DIFF", "/usr/bin/diff");
define("EWIKI_BIN_PATCH", "/usr/bin/patch");

In Zeile 12 und 13 von patchsaving.php stehen die Pfadangaben. Hier musste nun /usr/bin durch den von Apache lesbaren Pfad (das Verzeichnis /bin "neben" /moodledata) ersetzt werden – und jetzt klappt alles wie es soll.

Dateien zählen

Ich stand heute vor dem Problem, dass ich für den LFB angeben sollte, wie viele Dateien eines bestimmten Typs ich in einem Unterverzeichnis des Servers erstellt hatte. Nach ein wenig herumprobieren bin ich nun auf den folgenden Trick verfallen:

find /pfad/zum/ordner/ -type f -name „*.txt“ | wc -l

Die Zeile oben müsste für TXT Dateien dann die richtigen Zahlen liefern.