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­thread 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 Sub­do­mains:

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 Sub­do­main
$domain_parts=explode(„.”, $_SERVER[‚HTTP_HOST’]);
$instance=$domain_parts[0];
$instan­ce = preg_replace(„/\W/”, „”, $instan­ce);

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 =  fal­se;
$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 Webspace, 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 fast­C­GI.

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!

WordPress MU — Moodle MU?

Word­Press MU ist ein span­nen­des Kon­zept zur Ver­wal­tung belie­big vie­ler Word­Press­in­stal­la­tio­nen. Die Idee dabei ist, dass eine Instal­la­ti­on von allen Blogs genutzt wird und nur dyna­mi­sche Daten in Extra­ver­zeich­nis­sen und Extra­da­ten­ban­ken lan­den. Der Vor­teil liegt in einer immens ver­ein­fach­ten Wart­bar­keit des Sys­tems: Bei einem Update muss nur die­se zen­tra­le Instal­la­ti­on aktua­li­siert wer­den, um alle Blogs auf einen aktu­el­len Soft­ware­stand zu brin­gen. Das lässt sich auf via Brow­ser — so wie die Updatefunk­ti­on in Word­Press — per Klick rea­li­sie­ren.

Ich hat­te die­ses Kon­zept im Prin­zip schon auf Mood­le über­tra­gen — aller­dings han­del­te es sich dabei um eine Samm­lung von Kom­man­do­zei­len­scrip­ten mit einer Dia­log-Ober­flä­che — immer­hin schon mit Func­tions und einem Kon­fi­gu­ra­ti­ons­teil, wobei sich die Scrip­ten auch per exec();-Funktion mit PHP über den Brow­ser ansto­ßen lie­ßen. Fol­gen­de Fea­tures waren inte­griert:

  • Siche­rung der Mood­les (Daten­bank­dump + /moodledata)
  • Anle­gen eines Mood­le­sys­tem mit allen not­wen­di­gen Web­ser­ver­ope­ra­tio­nen (ligh­ty kann z.B. auch Script­aus­ga­ben(!) von stdin als Kon­fig­da­tei lesen…)
  • Löschen einer Instal­la­ti­on (mit vor­he­ri­gem Back­up)
  • Sperren/Entsperren eines Mood­le
  • Update eines Mood­le­sys­tems

Man könn­te sowas z.B. als Debian­pa­ket anbie­ten, des­sen Instal­ler alle not­wen­di­gen Kon­fi­gu­ra­tio­nen im Sys­tem vor­nimmt — inkl. des sehr schwie­ri­gen Mail­ser­ver­setups. oder eines Reverse­pro­xy davor — das spart Last… Auf die­se Wei­se könn­te Regio­nen sehr schnell lauf­fä­hi­ge Mul­ti­mood­le­sys­te­me erstel­len und sehr res­sour­cen­scho­nend bequem war­ten. Auch eine Plugin- und The­mever­wal­tung ist prin­zi­pi­ell denk- und inte­grier­bar. Ich hat­te „damals” die wei­te­re Ent­wick­lung aus per­sön­li­chen Grün­den ein­ge­stellt. Die Scrip­ten lie­gen hier aber noch irgend­wo…

Bezahlt mir irgend­wer ein Jah­res­ge­halt für die Ent­wick­lung? Ach­ja: Der Kopp­lungs­pro­zess zwi­schen Mood­le und Maha­ra wäre auch „scrip­ti­sier­bar” und eine gemein­sa­me Code­ba­sis für alle Maha­ras… Ein Tag hat 24 Stun­den und geschla­fen wird nachts… Viel­leicht ver­öf­fent­li­che ich mal die Scrip­ten mit einer Anlei­tung für den Anfang. Irgend­wann.