riecken.de

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 »

Nachdem es sehr viele verschiedene Ansätze dazu im Netz gibt, noch einmal mein Senf dazu. Ich komme auf diese Art und Weise sehr schnell durch meine Chemiearbeiten und aufwändige Nachkorrekturen durch formale Fehler entfallen dadurch fast vollständig, da die Tabellenkalkulation die Erbsen zählt.  Mir ist es immer sehr wichtig, weitgehend dynamisch korrigieren zu können, d.h. ich möchte mir auch Wege offenhalten, besondere Lösungsansätze auch im Rahmen meines Erwartungshorizonts zu würdigen. Außerdem möchte ich auf Schluss einfach nur noch drucken und unterschreiben. Mein Tabellenblatt weist folgende Struktur auf:

Den ganzen Beitrag lesen »

Dabei hilft die Funktion SVERWEIS(). Dazu braucht es erstmal eine Matrix (also einen Teil einer Tabelle in einer beliebigen Tabellenkalkulation), die wie folgt aussehen könnte:

Über die Zuordnung von Prozentbereichen zu Noten sprechen wir jetzt nicht – das ist von Fach zu Fach / Stufe zu Stufe  eh individuell unterschiedlich. Wichtig ist, dass die Noten aufsteigend angeordnet sind. Ferner sei angenommen, dass das Feld D42 (Per Anhalter durch die Galaxis) den Prozentwert der vom Schüler erreichten Punktzahl enthält.  Die Syntax von SVERWEIS() sieht erstmal so aus:

SVERWEIS(Suchkriterium; Matrix; Index; Sortierreihenfolge)

Unser Suchkriterium ist der Prozentwert der erreichten Punktzahl, also D42. Die Funktion sucht nun innerhalb eines Datenbereichs (einer Matrix), nach einem Wert, der mit unserem Suchkriterium in der gleichen Zeile (Index) steht.  Die Matrix ist hier der Bereich A2 bis C7, oder besser gesperrt $A$2 bis $C$7, da die Funktion ja an verschiedenen Stellen der Tabelle zum Einsatz kommt und hineinkopiert werden wird – es gibt ja nicht nur eine Schülerarbeit zu benoten. Index gibt die Spalte an, in der der Wert steht, der der Prozentzahl zugeordnet werden soll. Die Sortierreihenfolge  1 bzw. wahr gibt an, dass die Werte aufsteigend sortiert sind.

Will ich den Prozentwert in eine Note umrechnen, gilt für unser Beispiel:

SVERWEIS(D42;$A$2:$C$7; 2; 1)

Übersetzt:

Suche im Datenbereich A2 bis C7 in der zweiten Spalte (Index) nach einem Wert (“mache einen Verweis”), der zum Wert von D42 passt und schreibe ihn in Zelle. Er passt so lange, wie er den nächstfolgenden Wert nicht überschreitet (aufsteigende Sortierung).

Will ich den Prozentwert in eine verbale Note “umrechnen”, gilt für unser Beispiel entsprechend:

SVERWEIS(D42;$A$2:$C$7; 3; 1)

Nicht dass das nötig wäre: Man kann so nachträglich in der Matrix Prozentgrenzen ändern und im ganzen Tabellenblatt passen sich dann die Noten von Geisterhand an.

Wie so ein Tabellenblatt bei mir aussieht (das bekommen die SuS als unterschriebenen Ausdruck), zeige ich nochmal bei Gelegenheit. Auf diese Weise kann ich mich nicht mehr verzählen und bei den Noten vertun – praktisch und zeitsparend, denn die Tabellenkalkulation arbeitet für mich und ich muss  nur den jeweiligen Einzelaspekt im Auge haben. Ich finde es faszinierend, dass ab einer gewissen Punktzahl einfach ein Wort “umspringt” – das hat etwas von Levels in einem Jump&Run-Spiel und mitfiebern tue ich dabei auch gelegentlich. Man muss übrigens keine Prozentwerte nehmen – das klappt auch bei Punktegrenzen und natürlich im Punktesystem der Oberstufe bei entsprechender Erweiterung der Matrix.

Und ja – ich stehe auf farbige Kreide…

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 »