riecken.de

Vor ca. zwei Wochen habe ich meinen Kurs zur Medienbildung vorgestellt. Wir setzen ihn in dieser Woche gerade bei uns in der Schule lerngruppenübergreifend ein, was insbesondere ein deutliches Plus für die integrierten Aktivitäten (Chat, Forum) ist. Hier kommt es sogar teilweise zu lerngruppenübergreifenden Diskussionen. Einige SuS nutzen den Kurs sogar in ihrer Freizeit, um weiterzudiskutieren – das Konzept funktioniert also prinzipiell. Desweiteren habe ich bei drei unterschiedlichen Klassen, die ich im PC-Raum erlebt habe, kaum wahrgenommen, dass etwas anderes als die Aufgaben während der 90-minütigen Doppelstunde bearbeitet worden ist. Der Einsatz von Film und Text bietet offenbar genügend Abwechslung für 7. Klassen.

Nicht überrascht hat mich, dass Jasper gerade bei den Mädchen am besten ankam, Die kreative Leistung von Fabsi wurde dagegen kaum gewürdigt. Nunja. Die Erfahrungen dieses Kurses sollen ja eh noch in einer nachfolgenden Stunde nachbereitet werden… Auch so manche Diskussionskultur.

Die Umfrage

Der erste Baustein enthält eine kleine, anonyme Umfrage – hier einige, m.E. bemerkenswerte Ergebnisse:

1. Durchschnittlich verbringen unsere SuS der 7. Klasse 1,85 Stunden täglich im Internet
2. 53% bereiten ihre Hausaufgaben mit Hilfe des Netzes vor
3. 73% haben schon einmal ein Foto von sich veröffentlicht, immerhin 28% schon ein Video
4. 23% haben schon schlechte Erfahrungen im Netz gemacht (Beleidigungen, Betrügereien etc.)
5. 45% geben an, dass sie bereits eigene Texte im Netz erstellt/veröffentlicht haben (inkl. Forenposts)

Wie schon etwas länger angekündigt, biete ich meinen Kurs mit Bausteinen und Ideen zum Thema Medienbildung jetzt zum freien Download an. Er kann auf jedem aktuellen Moodlesystem entpackt werden und enthält ausbaufähige Bausteine zu den Themen:

• Internetnutzung
• Chat & andere Plaudereien
• Netzpolitik und Internetzensur

“Ausbaufähig” bedeutet, dass er als Grundlage für Weiterentwicklungen dienen kann, jedoch auch jetzt schon einsetzbar ist. Anschauen kann man sich den Kurs hier (ACHTUNG: Aufgrund eines DNS-Updates kann der Kurs zeitweise nicht verfügbar sein!) und downloaden hier: Moodlekurs zur Medienbildung.

Der Kurs steht unter CC-Lizenz unter Ausschluss einer kommerziellen Nutzung. Er wird an unserer Schule mit als Grundlage im Rahmen unseres Präventionskonzeptes dienen und noch weiter ausgebaut entsprechend den Erfahrungen im Alltagsbetrieb.

Update von 6. März 2010:

Der Kurs wurde nochmals geprüft und der fehlerhafte Baustein 3 entfernt, da die verlinkten Videos nicht mehr frei verfügbar sind.

Warum es in diesem Artikel geht, erfahrt ihr hier. Dieser Code läuft, u.a. weil er von Martin Langhoff ist. Den Originalthread findet man hier – hätte ich man erst auf moodle.org gesucht… Ich habe die dort geposteten Dateien noch einmal tüchtig eingedampft.  Der Ausgangspunkt sind wieder zwei Subdomains:

http://heim.domain.tld

http://schule.domain.tld

Der Unterschied zu meiner ersten Lösung besteht darin, dass im Prinzip nun  jede Moodleinstallation ihre eigene config.php erhält – über eine dynamische scheint es nicht zu laufen. Dazu braucht es wiederum eine modifizierte config.php:

<?php
# Hier gewinnen wir den ersten Domainteil der Subdomain
$domain_parts=explode(“.”, $_SERVER['HTTP_HOST']);
$instance=$domain_parts[0];
$instance = preg_replace(“/\W/”, “”, $instance);

unset ($CFG);
$CFG->dirroot=’/pfad/zum/moodleverzeichnis’;

// Allow file overrides for our domain

if (file_exists(“$CFG->dirroot/config_”.$instance.”.php”))  {      // Do not edit

include_once(“$CFG->dirroot/config_”.$instance.”.php”);
$CFG->directorypermissions =00777;

} else {

die(‘Ungültige Subdomain’);

}

if (file_exists(“$CFG->dirroot/lib/setup.php”))  {      // Do not edit

include_once(“$CFG->dirroot/lib/setup.php”);

} else {

if ($CFG->dirroot == dirname(__FILE__)) {

echo “<p>Could not find this file: $CFG->dirroot/lib/setup.php</p>”;
echo “<p>Are you sure all your files have been uploaded?</p>”;

} else {

echo “<p>Error detected in config.php</p>”;
echo “<p>Error in: \$CFG->dirroot = ‘$CFG->dirroot’;</p>”;
echo “<p>Try this: \$CFG->dirroot = ‘”.dirname(__FILE__).”‘;</p>”;

}

die;

}

?>

Neu ist jetzt, dass im gleichen Verzeichnis wie die config.php jetzt für jedes Moodlesystem eine Extradatei liegt, in unserem Beispiel mit den Namen:

config_heim.php

config_schule.php

Der Inhalt von config_heim.php lautet dann z.B.:

<?php

unset($CFG);

$CFG->dbtype    = ‘mysql’;
$CFG->dbhost    = ‘localhost’;
$CFG->dbname    = ‘dbname’;
$CFG->dbuser    = ‘dbuser’;
$CFG->dbpass    = ‘dbpasswd;
$CFG->dbpersist =  false;
$CFG->prefix    = ‘mdl_’;
$CFG->wwwroot   = ‘http://heim.domain.tld’;
$CFG->dirroot   = ‘/pfad/zu/moodle’;
$CFG->dataroot  = ‘/pfad/zum/datenverzeichnis’;
$CFG->admin     = ‘admin’;

?>

Also einfach die obere config.php einsetzen und für jede Installation eine eigene config_name.php-Datei anlegen. Das läuft hinter einem Reverse Proxy, auf normalem Webspace, auf einem managed Server – wirklich.Eine Beispielinstallation (proof of concept) gibt es unter den Links:

http://heim.riecken.info

http://schule.riecken.info

Beide Systeme laufen unter der gleichen Codebasis hinter einem Reverse Proxy auf einem lighttpd-Webserver mit PHP als fastCGI.

Dort konnte ich die Codebasis unter /pfad/zu/moodle tatsächlich für beliebig viele Moodles nutzen und hatte völlig freie Wahl bei  z.B.  dem Pfad zum /moodledata-Verzeichnis oder beim Datenbanknamen – was zusätzlich einen kleinen Sicherheitsgewinn bedeutet. Meine vollständig dynamische Lösung aus dem vorherigen Artikel fand ich zwar eleganter, aber wenn Moodle das nicht will…

Viel Spaß damit!

Ein ganz simple Methode, um mehrere Moodlesysteme mit einer einzigen Codebasis auf dem gleichen Webspace zu betreiben, führt über eine dynamische config.php. Voraussetzung ist, dass die Moodledateien in einem Verzeichnis auf dem Server liegen, das ich einfach einmal “foo” nenne. Auf dieses Verzeichnis müssen mehrere Subdomains zeigen, wie sie in fast jedem Webspacepaket inkludiert sind z.B.

http://heim.domain.tld

http://schule.domain.tld

Jetzt wird die config.php so modifiziert, dass sie in Abhängigkeit von der aufgerufenen Subdomain die für Moodle essentiellen Variablen anders setzt. Hier ist das vollständige Codebeispiel, was bitte als Denkanstoß verstanden werden soll, auch wenn es vielleicht sogar so läuft:

Den ganzen Beitrag lesen »

Heute wird es sehr technisch – aber wofür sind Ferien denn da… Ich hatte einmal mehrere Moodlesysteme hinter einem Reverse Proxy laufen – das wird den meisten nicht viel sagen, daher eine kurze Erklärung.

Das Problem

Moodle ist extremst resourcenhungrig und kann unter hoher Last einen schlecht konfigurierten Webserver in die Knie zwingen, besonders auf schwachbrüstigen Maschinen (die man privat so finanzieren kann). Da liegt daran, das für Moodle vom Webserver ein sogenannter PHP-Interpreter aufgerufen werden muss, der dann aus zahlreichen Scriptvorgaben eine stinknormale HTML-Seite baut und über den Webserver an den Browser des Benutzers ausliefert. Erschwerend kommt hinzu, dass die Scripten von Moodle zusätzlich viele Datenbankabfragen erzeugen und so durch den erforderlichen Datenbankserver (meist MySQL) Last erzeugen. Ein gut konfigurierter Moodleserver wird also dafür sorgen, dass möglichst wenig Last beim PHP-Interpreter und bei der MySQL-Datenbank ankommt – man sagt: Das Backend (PHP&MySQL) muss “geschützt” werden.

Reverse Proxy als Lösung

Dafür führt kein Weg an einem Reverse Proxy vorbei. Was macht dieser genau? Der PHP-Interpreter und die Datenbank bauen ja eine stinknormale HTML-Seite zusammen – das kann z.B. die Startseite eines Moodlekurses sein. Immer wenn der gleiche Nutzer die gleiche Seite aufruft, muss diese wieder und wieder gebaut werden. Ein Reverse Proxy speichert diese Seite im HTML-Code zwischen und liefert sie bei zweiten Aufruf direkt an den Browser ohne den Webserver, den PHP-Interpreter oder die MySQL-Datenbank zu bemühen. Ein Reverse Proxy ist sehr schlank und braucht nur wenige Resourcen. Selbst wenn ein Opcode-Cache wie eaccelerator oder xcache die PHP-Seite direkt bedienen kann, sind vorher zwei Instanzen mit viel höherem RAM-Verbrauch beteiligt (bei Apache ein kompletter Thread, bei lighty der Webserverprozess und ein fastCGI-Thread) – das ist in Lastsituationen nach meiner Erfahrung immer suboptimaler als gleich per Proxy auszuliefern. Der Opcode-Cache ist trotzdem eine wichtige zusätzliche Vorkehrung.  Der Reverse Proxy löst gerade bei mehreren Moodleinstanzen auf dem gleichen Server noch einige  weitere Probleme, aber dazu weiter unten mehr.

Den ganzen Beitrag lesen »