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

Tabellenkalkulation: Klassenarbeiten (fast) komplett in OpenOffice korrigieren

Nach­dem es sehr vie­le ver­schie­de­ne Ansät­ze dazu im Netz gibt, noch ein­mal mein Senf dazu. Ich kom­me auf die­se Art und Wei­se sehr schnell durch mei­ne Che­mie­ar­bei­ten und auf­wän­di­ge Nach­kor­rek­tu­ren durch for­ma­le Feh­ler ent­fal­len dadurch fast voll­stän­dig, da die Tabel­len­kal­ku­la­ti­on die Erb­sen zählt.  Mir ist es immer sehr wich­tig, weit­ge­hend dyna­misch kor­ri­gie­ren zu kön­nen, d.h. ich möch­te mir auch Wege offen­hal­ten, beson­de­re Lösungs­an­sät­ze auch im Rah­men mei­nes Erwar­tungs­ho­ri­zonts zu wür­di­gen. Außer­dem möch­te ich auf Schluss ein­fach nur noch dru­cken und unter­schrei­ben. Mein Tabel­len­blatt weist fol­gen­de Struk­tur auf:

Wei­ter­le­sen

Tabellenkalkulation: Aus Prozentwerten direkt Noten berechnen

Dabei hilft die Funk­ti­on SVERWEIS(). Dazu braucht es erst­mal eine Matrix (also einen Teil einer Tabel­le in einer belie­bi­gen Tabel­len­kal­ku­la­ti­on), die wie folgt aus­se­hen könnte:

A B C
1 Pro­zent­wert Note nume­risch Note ver­bal
2 0 6 unge­nü­gend
3 20 5 man­gel­haft
4 50 4 aus­rei­chend
5 64 3 befrie­di­gend
6 77 2 gut
7 90 1 sehr gut

Über die Zuord­nung von Pro­zent­be­rei­chen zu Noten spre­chen wir jetzt nicht – das ist von Fach zu Fach / Stu­fe zu Stu­fe  eh indi­vi­du­ell unter­schied­lich. Wich­tig ist, dass die Noten auf­stei­gend ange­ord­net sind. Fer­ner sei ange­nom­men, dass das Feld D42 (Per Anhal­ter durch die Gala­xis) den Pro­zent­wert der vom Schü­ler erreich­ten Punkt­zahl ent­hält.  Die Syn­tax von SVERWEIS() sieht erst­mal so aus:

SVERWEIS(Such­kri­te­ri­um; Matrix; Index; Sor­tier­rei­hen­fol­ge)

Unser Such­kri­te­ri­um ist der Pro­zent­wert der erreich­ten Punkt­zahl, also D42. Die Funk­ti­on sucht nun inner­halb eines Daten­be­reichs (einer Matrix), nach einem Wert, der mit unse­rem Such­kri­te­ri­um in der glei­chen Zei­le (Index) steht.  Die Matrix ist hier der Bereich A2 bis C7, oder bes­ser gesperrt $A$2 bis $C$7, da die Funk­ti­on ja an ver­schie­de­nen Stel­len der Tabel­le zum Ein­satz kommt und hin­ein­ko­piert wer­den wird – es gibt ja nicht nur eine Schü­ler­ar­beit zu beno­ten. Index gibt die Spal­te an, in der der Wert steht, der der Pro­zent­zahl zuge­ord­net wer­den soll. Die Sor­tier­rei­hen­fol­ge  1 bzw. wahr gibt an, dass die Wer­te auf­stei­gend sor­tiert sind.

Will ich den Pro­zent­wert in eine Note umrech­nen, gilt für unser Beispiel:

SVERWEIS(D42;$A$2:$C$7; 2; 1)

Über­setzt:

Suche im Daten­be­reich A2 bis C7 in der zwei­ten Spal­te (Index) nach einem Wert („mache einen Ver­weis“), der zum Wert von D42 passt und schrei­be ihn in Zel­le. Er passt so lan­ge, wie er den nächst­fol­gen­den Wert nicht über­schrei­tet (auf­stei­gen­de Sor­tie­rung).

Will ich den Pro­zent­wert in eine ver­ba­le Note „umrech­nen“, gilt für unser Bei­spiel entsprechend:

SVERWEIS(D42;$A$2:$C$7; 3; 1)

Nicht dass das nötig wäre: Man kann so nach­träg­lich in der Matrix Pro­zent­gren­zen ändern und im gan­zen Tabel­len­blatt pas­sen sich dann die Noten von Geis­ter­hand an.

Wie so ein Tabel­len­blatt bei mir aus­sieht (das bekom­men die SuS als unter­schrie­be­nen Aus­druck), zei­ge ich noch­mal bei Gele­gen­heit. Auf die­se Wei­se kann ich mich nicht mehr ver­zäh­len und bei den Noten ver­tun – prak­tisch und zeit­spa­rend, denn die Tabel­len­kal­ku­la­ti­on arbei­tet für mich und ich muss  nur den jewei­li­gen Ein­zel­aspekt im Auge haben. Ich fin­de es fas­zi­nie­rend, dass ab einer gewis­sen Punkt­zahl ein­fach ein Wort „umspringt“ – das hat etwas von Levels in einem Jump&Run-Spiel und mit­fie­bern tue ich dabei auch gele­gent­lich. Man muss übri­gens kei­ne Pro­zent­wer­te neh­men – das klappt auch bei Punk­te­gren­zen und natür­lich im Punk­te­sys­tem der Ober­stu­fe bei ent­spre­chen­der Erwei­te­rung der Matrix.

Und ja – ich ste­he auf far­bi­ge Kreide…

Moodle und Reverse Proxies

Heu­te wird es sehr tech­nisch – aber wofür sind Feri­en denn da… Ich hat­te ein­mal meh­re­re Mood­le­sys­te­me hin­ter einem Rever­se Pro­xy lau­fen – das wird den meis­ten nicht viel sagen, daher eine kur­ze Erklärung.

Das Pro­blem

Mood­le ist extremst resour­cen­hung­rig und kann unter hoher Last einen schlecht kon­fi­gu­rier­ten Web­ser­ver in die Knie zwin­gen, beson­ders auf schwach­brüs­ti­gen Maschi­nen (die man pri­vat so finan­zie­ren kann). Da liegt dar­an, das für Mood­le vom Web­ser­ver ein soge­nann­ter PHP-Inter­pre­ter auf­ge­ru­fen wer­den muss, der dann aus zahl­rei­chen Script­vor­ga­ben eine stink­nor­ma­le HTML-Sei­te baut und über den Web­ser­ver an den Brow­ser des Benut­zers aus­lie­fert. Erschwe­rend kommt hin­zu, dass die Scrip­ten von Mood­le zusätz­lich vie­le Daten­bank­ab­fra­gen erzeu­gen und so durch den erfor­der­li­chen Daten­bank­ser­ver (meist MyS­QL) Last erzeu­gen. Ein gut kon­fi­gu­rier­ter Mood­le­ser­ver wird also dafür sor­gen, dass mög­lichst wenig Last beim PHP-Inter­pre­ter und bei der MyS­QL-Daten­bank ankommt – man sagt: Das Backend (PHP&MySQL) muss „geschützt“ werden.

Rever­se Pro­xy als Lösung

Dafür führt kein Weg an einem Rever­se Pro­xy vor­bei. Was macht die­ser genau? Der PHP-Inter­pre­ter und die Daten­bank bau­en ja eine stink­nor­ma­le HTML-Sei­te zusam­men – das kann z.B. die Start­sei­te eines Mood­le­kur­ses sein. Immer wenn der glei­che Nut­zer die glei­che Sei­te auf­ruft, muss die­se wie­der und wie­der gebaut wer­den. Ein Rever­se Pro­xy spei­chert die­se Sei­te im HTML-Code zwi­schen und lie­fert sie bei zwei­ten Auf­ruf direkt an den Brow­ser ohne den Web­ser­ver, den PHP-Inter­pre­ter oder die MyS­QL-Daten­bank zu bemü­hen. Ein Rever­se Pro­xy ist sehr schlank und braucht nur weni­ge Resour­cen. Selbst wenn ein Opcode-Cache wie eac­ce­le­ra­tor oder xcache die PHP-Sei­te direkt bedie­nen kann, sind vor­her zwei Instan­zen mit viel höhe­rem RAM-Ver­brauch betei­ligt (bei Apa­che ein kom­plet­ter Thread, bei ligh­ty der Web­ser­ver­pro­zess und ein fast­C­GI-Thread) – das ist in Last­si­tua­tio­nen nach mei­ner Erfah­rung immer sub­op­ti­ma­ler als gleich per Pro­xy aus­zu­lie­fern. Der Opcode-Cache ist trotz­dem eine wich­ti­ge zusätz­li­che Vor­keh­rung.  Der Rever­se Pro­xy löst gera­de bei meh­re­ren Mood­lein­stan­zen auf dem glei­chen Ser­ver noch eini­ge  wei­te­re Pro­ble­me, aber dazu wei­ter unten mehr.

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.

1 16 17 18 19 20 24