MoodleMU: Die Zweite (nun geht es definitiv)

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://moodle.riecken.de

http://testmoodle.riecken.de

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!

Facebook Like

2 Kommentare

  • Wolf-Dieter Rhein

    Guten Tag Herr Rieken,
    ich weiß nicht, ob Sie meien Frage bereits an manderer Stelle beantwortet haben. Wir setzten uns wiedereinmal mit der Nutzung von Moodle mit vielen Schulen auseinsander. Gibt es aus Ihrer Sicht Bechränkungen, wenn man Moodle (neueste Versionen z. B. 2.5) nur mit einer Codebasis betreibt (z. B. Mengen an Schulen mit sehr vielen Schülerzugriffen etc.)? Anders gefragt welche Vorteile hätte es, wenn jede Schule eine eigene Codebasis, bzw. ein eigenes Moodle nutzt.
    Über Ihre Antwort würde ich mich freuen.
    Herzlichen Dank!
    W.-D. Rhein

  • Ich sehe technisch keine Beschränkungen mit Ausnahme der Designs. In der bisherigen Lösung von oben müssen alle Designs immer allen Schulen zur Verfügung stehen, d.h. Schule A „sieht“ dann in Moodle auch das Design von Schule B, bzw. kann es dann auswählen – das macht zwar nicht viel Sinn, aber der eine oder andere mag darin ein Problem sehen. Durch weitere Modifikationen (dynamischer Designordner) lässt sich aber auch das lösen.

    Probleme können weiterhin entstehen durch die neue „Per-Click-Installation“ von Modulen und Updates in Moodle 2.5. Das müsste durch eine Rewrite-Regel unterbunden werden.

    Administrativ wird eine *getrennte* Codebasis gerade bei so einem Codemoloch wie Moodle schnell zu einer Katastrophe.

    Gruß,

    Maik

Schreibe einen Kommentar

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