MoodleMU: Die Erste…

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:

<?php

# Pfad zum Verzeichnis, in dem alle Datenverzeichnisse der Moodleinstanzen liegen
$datadir_base=“/beispiel/pfad/zum/datenverzeichnis/“;

# Hier gewinnen wir den ersten Domainteil der Subdomain
$domain_parts=explode(„.“, $_SERVER[‚SERVER_NAME‘]);
$instance=$domain_parts[0];

# Zugangsdaten: $sql_user, $sql_pass, $sql_db

$moodlesystems = array(

„heim“  => array(„sql_db“=>“moodle01″,“sql_user“=>“user01″,“sql_passwd“=>“passwd01“),


„schule“ => array(„sql_db“=>“moodle02″,“sql_user“  => „user02″,“sql_passwd“ => „passwd02“),


);

if (!$moodlesystems[$instance][„sql_db“]) {

die(„Keine gültige Subdomain!“);

}

$sql_db = $moodlesystems[$instance][„sql_db“];
$sql_user = $moodlesystems[$instance][„sql_user“];
$sql_passwd = $moodlesystems[$instance][„sql_passwd“];
$datadir = $datadir_base.$instance;

unset($CFG);

$CFG->dbtype    = ‚mysql‘;
$CFG->dbhost    = ‚localhost‘;
$CFG->dbname    = $sql_db;
$CFG->dbuser    = $sql_user;
$CFG->dbpass    = $sql_passwd;
$CFG->dbpersist =  false;
$CFG->prefix    = ‚mdl_‘;

$CFG->wwwroot   = ‚http://‘.$instance.‘.domain.tld‘;
$CFG->dirroot   = ‚/pfad/zum/moodle/code/foo‘;
$CFG->dataroot  = $datadir;
$CFG->admin     = ‚admin‘;

$CFG->directorypermissions = 00777;  // try 02777 on a server in Safe Mode

require_once(„$CFG->dirroot/lib/setup.php“);
// MAKE SURE WHEN YOU EDIT THIS FILE THAT THERE ARE NO SPACES, BLANK LINES,
// RETURNS, OR ANYTHING ELSE AFTER THE TWO CHARACTERS ON THE NEXT LINE.
?>

Ein paar Erläuterungen:

Das Datenverzeichnis muss so heißen wie der oben rot markierte Domainanteil und im Pfad „/beispiel/pfad/zum/datenverzeichnis/“ liegen, also z.B. „/beispiel/pfad/zum/datenverzeichnis/heim“ bzw. „/beispiel/pfad/zum/datenverzeichnis/schule„.

Jetzt kann ich für jedes Moodle eine eigene Datenbank, einen eigenen Datenbankbenutzer und ein eigenes Datenbankpasswort festlegen. Das geschieht in einer solchen Zeile:

heim“  => array(„sql_db“=>“moodle01″,“sql_user“=>“user01″,“sql_passwd“=>“passwd01“),

Davon kann ich beliebig viele „stapeln“, d.h. so viele Zeilen, wie ich Subdomains und Datenbanken anlegen kann, was vom Webspace abhängig ist. Allein mit dieser Lösung muss ich dann nur noch eine Codebasis pflegen – es gibt aber auch Nachteile:

  1. Sämtliche SQL-Zugangsdaten stehen in einer einzigen Datei – das tun sie bei Moodle standardmäßig aber auch. Schöner wäre es, diese Daten von außerhalb des Webroots zu inkludieren oder verschlüsselt in eine MySQL-DB zu schreiben – dann steht der Schlüssel zwar immer noch in der config.php, aber nun denn…
  2. Man kann auf diese Weise nur Moodles unter einer Subdomain von einer Hauptdomain laufen lassen – möglich wäre mit marginalen Änderungen auch sowas wie http://www.domain.tld/heim. Aber das ist schon eine Einschränkung in der Namensgebung. Wenn man das Array noch weiter aufbohrt, sind aber auch völlig verschiedene Domains und Datenverzeichnisse denkbar.

Schön ist, das dieser Ansatz auf jedem stinknormalen Webspace läuft, wenn man mehrere MySQL-Datenbanken und die Möglichkeit zur Einrichtung von Subdomains hat. Ob Moodle auf so einem „stinknormalen“ Webspace dann performant läuft, ist noch eine andere Sache. Für den ambitionierten Lehrer, der nur mit einer kleineren Lerngruppe arbeitet und vielleicht nebenbei noch Referendare ausbildet und der dafür zwei getrennte Moodles haben will, sollte das schon so ganz gut hinhauen.

Diese Lösung sollte vom Ansatz her auch hervorragend auf managed Servern mit Plesk & Co. laufen, wenn es mehr und performantere Moodles sein dürfen. So können auch Klickibunti-Naturen viele Instanzen aktuell halten und die Backupproblematik über die eingebaute Funktionalität von z.B. Plesk lösen. Es gibt sehr gute und günstige (nicht „billige“)  mittelständische Anbieter in diesem Bereich, die auch gerne den Server für Moodle fit machen (inkl. z.B. TeX-Filter usw.). Ab ca. 150,- Euro/Monat bekommt man da schon was Anständiges und wenn 20 Schulen mitmachen…

Für den nächsten Artikel zu MoodleMU giere ich nach einem Onlineupdate für Moodle á la WordPress – klicken und gut.  Authentifizieren kann man ja trefflich gehen den Adminaccount von Moodle. Das wird schwierig, da der Download von moodle.org via PHP schon zu Timeouts führen kann (und die DB vorsichtshalber gesichert werden muss) – da gibt es aber bestimmt Tricks – bei WordPress klappt es ja auch irgendwie.

6-12-2010 – UPDATE1:

Out-of-the-Box läuft das Script so nicht, bzw. bisher suboptimal – zumindest hinter einem Reverse Proxy. Ich teste noch etwas herum – also: Erstmal nur ein Denkanstoß.

Facebook Like

2 Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.