Was wird auf Twitter so geklickt?
Ausgewertet hierüber.
Ich habe nur Nerds und Lehrer in der Timeline – schnüff. Und jetzt: Korrekturen…
Gedanken zu Bildung, Lehre und Schule
Ausgewertet hierüber.
Ich habe nur Nerds und Lehrer in der Timeline – schnüff. Und jetzt: Korrekturen…
In den letzten beiden Wochen habe ich mich ein wenig in unser Schulnetzwerk eingegraben – als medienpädagogischer Berater kann man es ja nicht auf sich sitzen lassen, dass man anderswo nichts vorzustellen hat – zudem haben wir hier mittlerweile vor Ort so ausgezeichnete Bedingungen, dass sich bestimmt auch einmal eine Tagung organisieren lässt. Weil unser Schulträger zurzeit massiv in bauliche Maßnahmen investiert, ist man geneigt, sich bei der Beantragung von Mitteln für den Vermögenshaushalt eher zurückzuhalten oder eben noch etwas zu warten.
Bei uns mangelt es nicht an Kupfer, das im Gebäude verlegt ist – es gibt sogar Glasfaserstrecken zwischen den einzelnen Gebäudeteilen. Es gibt in den Naturwissenschaften und in einzelnen Gebäudeteilen auch WLAN, jedoch längst nicht flächendeckend. In den PC-Räumen werkeln noch P4‑2,8Mhz-Kisten mit 512MB RAM vor sich hin. Zur betreuenden Firma kann ich noch nicht viel sagen – so richtig habe ich noch nicht mit ihr zusammengearbeitet. Gut wäre auf lange Sicht sicher ein periodischer Termin zur Sichtung und Besprechung der anfallenden Aufgaben.
Ein wenig möchte ich das Netzwerk planen und seinen Aufbau koordinieren, werde in der Anfangszeit aber etwas selber zaubern müssen. Immer wieder mache ich die Erfahrung, dass sich dabei viel Gehirnschmalz und Arbeit am Anfang ungemein positiv für die langfristige Ausrichtung auswirken. Folgende Grundsätze halte ich für Schulnetzwerke mittlerweile für essentiell:
Momentan habe werden unsere Clients mit dem schon nicht mehr erhältlichem Microsoft Shared Computer Toolkit so verrammelt, dass Änderungen an der lokalen Installation auch ohne Zusatzhardware nicht möglich sind. Ein Schulserver regelt Freigaben via Samba und fungiert gleichzeitig als Netzfilter – über den Ansatz lässt sich trefflich streiten, aber er funktioniert. Leider bringt er diverse Nachteile mit sich, die die Punkte 4+5 meiner Liste betreffen.
Eine Software auf allen unseren Clients zu installieren, dauert ungefähr 20 Arbeitsstunden, da nicht nur die Software eingespielt werden will, sondern auch die Rechner immer wieder aus der Domäne fliegen usw.. Das geht so nicht. Deswegen Deployment (Punkt 3) – image- (fog) oder systemdienstbasiert (opsi). Das ist ein Muss – gerade auch in heterogenen Systemlandschaften mit verschiedenen Windowsversionen. Es gibt schicke Windowslösungen, z.B. RIS. Kostet. Summen.
Perspektivisch muss so oder so ein neuer Server her, der z.B. einem eventuellem Dienstleister die Grundlage für eine Wartungstätigkeit bietet. In Niedersachsen läuft das an vielen Schulen über iserv. Es ist die in meinen Augen zur Zeit ausgereifsteste Schulserverlösung überhaupt (neben paedML aus BW) – kostet aber. Bezeichnenderweise ist die Kiste an einer Schule entstanden, die Punkt 6 meiner Liste sehr ernst genommen hat. Dummerweise kann iserv von Hause aus keine Terminals bedienen – das hätte ich aber soooo gerne. Die Vorstellung, 0815-Hardware auch in öffentlichen Bereichen der Schule zur Verfügung stellen zu können, finde ich nett. Zudem können unsere bestehenden Clients PXE. Fürs Terminal reicht die Hardware dicke.
Wo will ich hin?
Technisch ist das alles möglich – heute, komplett mit OpenSource. Müsste das für unsere Schule umgesetzt werden, würde ich inkl. Migration bei einer fähigen Firma dafür drei Wochen mit ca. 120 Mannstunden ( 80,- Euro Stundensatz – soll ja eine fähige Firma sein) ansetzen. Dann wäre mit einem Kapitaleinsatz von ca. 20.000 Euro inkl. Hardware aber für einige Zeit Ruhe. Und: Man spart auf mittlere Sicht erheblich bei den Wartungskosten. Außerdem habe ich eigentlich das Unterrichten gelernt und sollte mich darauf konzentrieren. So – und jetzt Fundraising.
Wir überarbeiten nach den Ferien unsere komplette IT-Struktur. Ich habe in den letzten Tagen darüber viel nachgedacht und mit Virtualbox fleißig kleine, virtualisierte Netze gebaut. Ziel war es, etwas zu ersinnen, was einerseits technisch für eine Lehrkraft beherrschbar ist, anderseits möglichst viele didaktische Möglichkeiten eröffnet. Zudem spielen natürlich auch Wirtschaftlichkeitsüberlegungen und ökologische Aspekte eine Rolle (man muss es ja dem Schulträger auch vermitteln können). Herausgekommen ist das hier:
Kern ist das LTSP-Projekt. Ein schöner Einstig in das grundsätzliche Prinzip findet sich auf Wikipedia: Man degradiert sämtliche Schülerrechner zu reinen Anzeigegeräten. Festplatten und nicht erforderlichen RAM reißt man heraus, verrammelt das BIOS mit einem Passwort und lässt die Kisten per PXE vom LTSP-Server booten – das muss pro Tag einmal geschehen und dauert kürzer als ein WinXP-Start (Was nicht viel heißen will…).
Damit entfällt sämtliche Turnschuhadministration und auch die empfindlichsten Komponenten von PCs sind eliminiert. Software muss nur noch auf einem Gerät installiert werden und ist dann auf allen Clients verfügbar. Als Anzeigegerät ist ein Pentium I mit 133Mhz und halbwegs brauchbarer Grafikkarte ausreichend. Schön wären natürlich echte ThinClients, am besten in ein LCD-Panel integriert – so dürfte es leise und kühl im PC-Raum werden. Alle Anwendungen laufen auf einem zentralen Server, der natürlich ein Server und kein Spielzeug sein muss (Hexacore, 32GB RAM, RAID10, redundante Netzteile – die 4000-Euro-Klasse halt). Sound kann man bidirektional an die Clients weiterreichen, mit Video klappt es auch, wenn die Anbindung stimmt und man auf HD-Material verzichten mag.
Der Server kann allerdings nur Linux (Ubuntu). Damit kann man surfen, schreiben, Audio bearbeiten u.v.m. – das Wichtigste halt. Die meisten Dienste verlagern sich eh in die Cloud. Es ist nicht schwer, GNOME einen Windows7- oder XP-Look aufzuzwingen – aber das halte ich für eine Art Betrug. Die meisten „Windowsianer“ kommen mit meinem Netbook erstaunlich gut klar und den Desktop kann man ja vorstrukturieren mit netten, einfachen Icons. Mit WINE habe ich bisher zusätzlich fast alle Software zum Laufen gebracht, die auf unseren jetzigen WinXP-Clients vor sich hinvegetiert. Hier sind vor allem mit den Herstellern lizenzrechtliche Fragen zu klären, da es WINE recht egal ist, ob eine Word2010-Instanz 25x von verschiedenen Nutzern gestartet wird…
Dateien lassen sich auf USB-Medien speichern, die LTSP von den Clients durchgereicht bekommt, oder man nutzt NFS (ist bei LTSP leider so) mit festem Quota für jeden Nutzeraccount (gefühlt 1GB, dann würde bei uns noch die 2GB-Platte für die ganze Schulgemeinschaft bei Vollauslastung reichen).
Die Nutzerverwaltung mache ich traditionell über LDAP. Dann kann man den Proxy darüber mit Anmeldung laufen lassen. Außerdem lässt sich das Ding so schön per Skript mit einem kastrierten Export der Schülerdatenbank füttern (inkl. Ordnung nach Klassen) – das Skript gibt es schon für die Anbindung unseres Webangebots. Das ist übrigens der härteste Teil der Geschichte. LDAP hat dafür aber auch den Vorteil, dass es mit RADIUS spricht – ein nettes Spielzeug (man kann in LTSP auch die Clientkonfiguration darüber machen). So meldet man sich per WLAN in der Schule mit den gewohnten Netzwerk-Logindaten an, jeder WLAN-Router kriegt sein eigenes Netz, (dann gehen die IPs so schnell nicht aus) man kann festlegen, wer sich wann anmelden darf (abends braucht man kein Netz, oder?) usw.. Dann noch ein AdHoc-Netz, um das ganze Schulgelände zu bestrahlen… (träum…). Aber das wird eh die Zukunft – mehr als der persönliche Desktop auf dem Schulserver.
Einige Dinge gehen partout nicht unter Linux. Dafür würde ich gerne einen WindowsServer2008RC2 hinstellen, der über 25 Accounts verfügt. Bei der Anmeldung am LTSP kann man sich dann entscheiden, ob man Windows möchte oder nicht und sowohl der Server als auch die Softwarelizenzen sind bei 25 Clients noch überschaubar teuer. Ob man nun einen RDesktop oder die die Ausgabe eines XServers an die Clients weiterleitet, ist wohl egal. Vielleicht lässt sich der WindowsServer sogar virtualisieren, wenn man den LTSP-Server noch dicker… .
Das Schöne an diesem Konzept ist seine Modularität: Man kann klein anfangen und sich dann steigern – allein der LTSP-Server mit seiner Hardware, den braucht man schon. Die Clients sind ja schon da. Wenn man völlig bekloppt sein will, verlegt man alle jetzigen Clients in virtuelle Maschinen und nutzt deren Lizenzen weiter.
Was kostet das Ganze? Im Vollausbau schätze ich eine Summe von 10000,- Euro (ohne Clients und wenn man es selbst macht: LTSP ist in Ubuntu sehr gut vorkonfiguriert und recht schnell aufgesetzt). Wenn man 50 Clients erneuern oder durch Notebooks ersetzen möchte, darf jedes nur 200,- Euro kosten, damit es „billiger“ wird. Für den Anfang tut es auch nur der LTSP-Server und der VLAN-fähige Switch – dann kommt man wohl mit der Hälfte hin und hat recht aktuelle, leicht wartbare Systeme.
Markus erklärt in seinem Blog, warum es Sinn macht, einen eigenen URL-Shortener zu verwenden. Ich kann dem wenig hinzufügen und habe es ihm fast gleichgetan – allein für ein neues Multidomain-SSL-Zertifikat habe ich noch nicht die Muße gefunden. Für den eigenen URL-Shortener nehme man
lighttpd-User wie ich haben es nur unwesentlich schwerer, da die Rewrite-Engine etwas anders funktioniert. Für den entsprechenden vhost trägt man hier ein:
$HTTP["host"] == "domain.tld" { server.document-root = "/pfad/zu/yourls" url.rewrite-once = ( "^/([0-9A-Za-z]+)?$" => "/yourls-go.php?id=$1", "^/([0-9A-Za-z]+)?\+$" => "/yourls-infos.php?id=$1" ) }
… und schon hat man nach ein wenig Doku den eigenen Kurz-URL-Dienst (leider klappt der Aufruf der Hauptdomain so noch nicht). Meiner hört auf
http://www.m9r.de
und ist genau wie Markus‘ Installation nicht öffentlich zugänglich, um Ärger mit bestimmten Zeitgenossen zu vermeiden. Dass das klappt, lässt sich ganz gut mit meinem momentanen Lieblingsnachdenkartikel über Facebook zeigen: http://m9r.de/3 (mit Dank an Andreas Kalt).
Man handelt sich in der Grundversion wieder einige Datenschutzherausforderungen ein, die sich aber lösen lassen. Nebenbei weiß ich jetzt, wie oft meine Kurz-URLs auf Twitter tatsächlich geklickt wurden und es entsteht quasi nebenbei eine hübsche Linksammlung in der Datenbank. Jetzt noch ein paar Tags und schon braucht es obendrein auch kaum noch Bookmarks.
Müssen alle Online-Tests überwacht werden? (Nein) (!Ja) (!manche)
Findest du das Test-Interface von Moodle gut? (!Ja) (Nein)
Interessiert dich das Framework? (Ja) (!Nein)
Einleitung
Wenn ihr den oberen, natürlich per Quiz-Script erstellten Test bestanden habt oder auch nicht, dann ist vielleicht diese noch recht wenig bekannte Entwicklung von Felix Riesterer etwas für euch. Die Leute von zum.de haben die Möglichkeiten erkannt und das Quiz-Script mit in ihre Wiki-Plattformen integriert. Hier gibt es auch Anleitungen für den Einsatz. Die Anleitung zur Einbindung in Mediawiki ist in der dort skizzierten Form in meinen Augen allerdings unbrauchbar – daher unten meine Variante. Trotzdem bin ich darüber überhaupt erst auf die Idee gekommen.
Was ist das Quiz-Script-Framework?
Die Demoseite des Autors zeigt schonmal, was das Quiz-Script-Framework kann. Ich sehe den Einsatz vor in sprachlichen Fächern – endlich mal etwas für uns… Wer schon einmal mit Monolithen wie Moodle Tests erstellt und sich dabei totgeklickt hat, wird das Konzept begrüßen: Nicht der Webserver macht die Hauptarbeit, sondern der Browser, indem einfach im HEAD jeder beliebigen HTML-Datei drei einfache JavaScript-Aufrufe deklariert werden. Deswegen ist das Script prinzipiell auch in jeder Anwendung einsetzbar (z.B. in WordPress, s.o.), die euch ermöglicht, das Template (meist header.php) zu gestalten. Nicht geeignet ist es für den TinyMCE-Editor, da dessen Sicherheitsmechanismen auch im HTML-Modus die Tags zerhaseln, die das Script zum Erkennen einer Testsektion benötigt.
Beispiel – Einbindung in Mediawiki
Schritt 1:
Zunächst braucht ihr die Extension „Javascript“. Diese besteht nur aus einer einzigen Datei namens Javascript.php. Die legt ihr in einen neu erstellten Ordner mit dem Namen „Javascript“. Das muss ein Unterordner des Mediawiki-Ordners „extensions“ sein. Ihr könnt natürlich den Datei- und Ordnernamen klein schreiben.
Schritt 2:
In der Datei „LocalSettings.php“ im Stammverzeichnis der Mediawikiinstallation ergänzt ihr ganz unten die Zeile:
include("$IP/extensions/Javascript/Javascript.php");
Schritt 3:
Das Quiz-Script-Framework könnt ihr hier gezippt herunterladen. Nach dem Entpacken entsteht ein Ordner „quiz“. Den Inhalt des Ordners ladet ihr nun in das Verzeichnis /extensions/Javascript. Da war es schon.
Beispiel – Einbindung in andere Scripten:
Alle anderen sorgen einfach dafür, dass im HEAD-Bereich folgende Zeilen auftauchen:
<script src="pfad_zu/quiz/quiz.js" type="text/javascript"></script> <script src="pfad_zu/quiz/multilingual.js" type="text/javascript"></script> <script src="pfad_zu/quiz/utf8-normalizer.js" type="text/javascript"></script>
… und schon steht auch dort die Funktionalität des Quiz-Script Frameworks zur Verfügung.Natürlich klappt das auch auf jeder simplen HTML-Seite.
Ausblicke