MoodleMU: Die Erste…

Ein ganz simp­le Metho­de, um meh­re­re Mood­le­sys­te­me mit einer ein­zi­gen Code­ba­sis auf dem glei­chen Web­space zu betrei­ben, führt über eine dyna­mi­sche config.php. Vor­aus­set­zung ist, dass die Mood­le­da­tei­en in einem Ver­zeich­nis auf dem Ser­ver lie­gen, das ich ein­fach ein­mal „foo“ nen­ne. Auf die­ses Ver­zeich­nis müs­sen meh­re­re Sub­do­mains zei­gen, wie sie in fast jedem Web­space­pa­ket inklu­diert sind z.B.

http://heim.domain.tld

http://schu­le.domain.tld

Jetzt wird die config.php so modi­fi­ziert, dass sie in Abhän­gig­keit von der auf­ge­ru­fe­nen Sub­do­main die für Mood­le essen­ti­el­len Varia­blen anders setzt. Hier ist das voll­stän­di­ge Code­bei­spiel, was bit­te als Denk­an­stoß ver­stan­den wer­den soll, auch wenn es viel­leicht sogar so läuft:

Wei­ter­le­sen

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 Update­funk­ti­on in Word­Press – per Klick realisieren.

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 integriert:

  • 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 Backup)
  • Sperren/Entsperren eines Moodle
  • Update eines Moodlesystems

Man könn­te sowas z.B. als Debi­an­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­set­ups. 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 Plug­in- und The­me­ver­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 irgendwo…

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. Irgendwann.