MoodleMU: Die Zweite (nun geht es definitiv)

War­um es in die­sem Arti­kel geht, erfahrt ihr hier. Die­ser Code läuft, u.a. weil er von Mar­tin Lang­hoff ist. Den Ori­gi­nal­th­read fin­det man hier – hät­te ich man erst auf moodle.org gesucht… Ich habe die dort gepos­te­ten Datei­en noch ein­mal tüch­tig ein­ge­dampft.  Der Aus­gangs­punkt sind wie­der zwei Subdomains:

http://heim.domain.tld

http://schu­le.domain.tld

Der Unter­schied zu mei­ner ers­ten Lösung besteht dar­in, dass im Prin­zip nun  jede Mood­le­instal­la­ti­on ihre eige­ne config.php erhält – über eine dyna­mi­sche scheint es nicht zu lau­fen. Dazu braucht es wie­der­um eine modi­fi­zier­te config.php:

<?php
# Hier gewin­nen wir den ers­ten Domain­teil der Subdomain
$domain_parts=explode(„.“, $_SERVER[‚HTTP_HOST‘]);
$instance=$domain_parts[0];
$ins­tance = preg_replace(„/\W/“, „“, $ins­tance);

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

// Allow file over­ri­des 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 Sub­do­main‘);

}

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 detec­ted 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 glei­chen Ver­zeich­nis wie die config.php jetzt für jedes Mood­le­sys­tem eine Extra­da­tei liegt, in unse­rem Bei­spiel mit den Namen:

config_heim.php

config_schu­le.php

Der Inhalt von config_heim.php lau­tet dann z.B.:

<?php

unset($CFG);

$CFG->dbtype    = ‚mys­ql‘;
$CFG->dbhost    = ‚local­host‘;
$CFG->dbname    = ‚dbna­me‘;
$CFG->dbuser    = ‚dbu­ser‘;
$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 ein­fach die obe­re config.php ein­set­zen und für jede Instal­la­ti­on eine eige­ne config_name.php-Datei anle­gen. Das läuft hin­ter einem Rever­se Pro­xy, auf nor­ma­lem Web­space, auf einem mana­ged Ser­ver – wirklich.Eine Bei­spiel­in­stal­la­ti­on (pro­of of con­cept) gibt es unter den Links:

http://moodle.riecken.de

http://testmoodle.riecken.de

Bei­de Sys­te­me lau­fen unter der glei­chen Code­ba­sis hin­ter einem Rever­se Pro­xy auf einem lighttpd-Web­ser­ver mit PHP als fastCGI.

Dort konn­te ich die Code­ba­sis unter /pfad/zu/moodle tat­säch­lich für belie­big vie­le Mood­les nut­zen und hat­te völ­lig freie Wahl bei  z.B.  dem Pfad zum /mood­le­da­ta-Ver­zeich­nis oder beim Daten­bank­na­men – was zusätz­lich einen klei­nen Sicher­heits­ge­winn bedeu­tet. Mei­ne voll­stän­dig dyna­mi­sche Lösung aus dem vor­he­ri­gen Arti­kel fand ich zwar ele­gan­ter, aber wenn Mood­le das nicht will…

Viel Spaß damit!

Facebook Like

2 Kommentare

  • Wolf-Dieter Rhein

    Guten Tag Herr Rieken,
    ich weiß nicht, ob Sie mei­en Fra­ge bereits an man­de­rer Stel­le beant­wor­tet haben. Wir setz­ten uns wie­der­ein­mal mit der Nut­zung von Mood­le mit vie­len Schu­len aus­ein­san­der. Gibt es aus Ihrer Sicht Bech­rän­kun­gen, wenn man Mood­le (neu­es­te Ver­sio­nen z. B. 2.5) nur mit einer Code­ba­sis betreibt (z. B. Men­gen an Schu­len mit sehr vie­len Schü­ler­zu­grif­fen etc.)? Anders gefragt wel­che Vor­tei­le hät­te es, wenn jede Schu­le eine eige­ne Code­ba­sis, bzw. ein eige­nes Mood­le nutzt.
    Über Ihre Ant­wort wür­de ich mich freuen.
    Herz­li­chen Dank!
    W.-D. Rhein

  • Ich sehe tech­nisch kei­ne Beschrän­kun­gen mit Aus­nah­me der Designs. In der bis­he­ri­gen Lösung von oben müs­sen alle Designs immer allen Schu­len zur Ver­fü­gung ste­hen, d.h. Schu­le A „sieht“ dann in Mood­le auch das Design von Schu­le B, bzw. kann es dann aus­wäh­len – das macht zwar nicht viel Sinn, aber der eine oder ande­re mag dar­in ein Pro­blem sehen. Durch wei­te­re Modi­fi­ka­tio­nen (dyna­mi­scher Desi­gn­o­rd­ner) lässt sich aber auch das lösen. 

    Pro­ble­me kön­nen wei­ter­hin ent­ste­hen durch die neue „Per-Click-Instal­la­ti­on“ von Modu­len und Updates in Mood­le 2.5. Das müss­te durch eine Rewri­te-Regel unter­bun­den werden.

    Admi­nis­tra­tiv wird eine *getrenn­te* Code­ba­sis gera­de bei so einem Code­mo­loch wie Mood­le schnell zu einer Katastrophe. 

    Gruß,

    Maik

Schreibe einen Kommentar

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