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.
Vorausgesetzt wird, dass Moodle auf dem gleichen Server wir der eingerichtete und mit Daten befüllte slapd läuft. Schematisch ist diese Anleitung ganz allgemein verwendbar, um Moodle ein einen openLDAP-Server zu koppeln. Die “Bulkuploadleute” brauchen diese Anleitung nicht…
Zunächst einmal müssen wir sicherstellen, dass die Authentifizierng über openLDAP überhaupt in Moodle aktiviert ist. Dazu klicken Sie im Administrationsmenu
Website-Administration => Nutzer/innen => Authentifizierung => Übersicht
auf das geschlossene Auge bei “LDAP-Server”, so es denn noch geschlossen ist. Durch das Aktivieren der LDAP-Aurhentifizierung bleiben übrigens alle übrigen Authentifizierungsmethoden funktionsfähig. Jetzt erscheint im Menu
Website-Administration => Authentifizierung
ein neuer Eintrag mit dem Namen “LDAP-Server“, den es anzuklicken gilt. Es folgt eine umfangreiche Konfigurationsseite. Ich hangle mich mich jetzt nur durch die Felder hindurch, die geändert oder mit Daten befüllt werden müssen. Alle anderen Felder bleiben jungfräulich. Es werden folgende Angaben aus dem vorherigen Schritt benötigt:
- Wert der Variablen $organisation (evaluation)
- Wert der Variablen $domain (schuldomain)
- Wert der Variablen $tld (tld)
Ich nenne zunächst das Konfigurationsfeld gefolgt von einem Pfeil (=>), hinter dem der einzutragende Inhalt steht.
Bilder von Schülerinnen und Schülern sind oft ein Problem – vor allem dann, wenn man sie veröffentlich und das vielleicht sogar noch so tut, dass Namen einem bestimmten Foto zugeordnet werden können. In einigen Bundesländern ist das sogar strikt verboten.
Auch hier kann LDAP abmildern: Man nutzt ein Schul-LDAP als “Zapfstelle” für eine HTTP-basierte Authentifizierung, die vielen bestimmt bekannt ist (.htaccess).
Mit meinem Lieblingswebserver (lighty) geht das sehr leicht – das auth-Modul muss allerdings aktiviert sein.
server.modules += ( “mod_auth” )
auth.backend = “ldap”
auth.backend.ldap.hostname = “127.0.0.1″
auth.backend.ldap.base-dn = “ou=ldapbaum,dc=foo,dc=tld”
auth.backend.ldap.filter = “(uid=$)”$HTTP["host"] == “subdomain.fuer.fotos” {
auth.require = ( “” => (
“method” => “basic”,
“realm” => “Anmeldung bitte mit Schulogin und -passwort fuer die Seite “,
“require” => “valid-user”
)
)
}
… und schon ist nach einem /etc/init.d/lighttpd force-reload der Zugriff auf die Seite http://subdomain.fuer.fotos mit allen Unterseiten nicht mehr ohne Anmeldung möglich, wenn lokal der LDAP-Server oder eine Kopie bzw. Replikation davon mitläuft. So kann sich der der potentielle Kinderschänder nicht mehr ohne Weiteres sein nächstes Opfer anhand des letzten Schwimmwettbewerbsbildes auswählen – es sei denn, er kommt selbst von der Schule (zugegebenermaßen eine sehr düstere Option). Ingesamt nett und simpel.
Wenn man das jetzt noch mit WebDAV und Moodle kombiniert, kann man sogar einzelnen Lehrkräften Schreibrechte in bestimmten Moodleordnern einräumen. Da Lighty reguläre Ausdrücke unterstützt, müsste das sogar recht schmerzfrei gehen. Aber das ist eine andere Geschichte…
… ist in meinen Augen so gar nicht gelungen, da immer wieder gleiche Probleme auftreten:
- Moodle aktzeptiert z.B. nur Datensätze, die eine – im Format gültige E-Mailadresse – enthalten. Nun besitzt nicht jeder Schüler oder jede Schülerin eine solche – von Lehrkräften einmal ganz zu schweigen. Das führt oft dazu, dass die Admins “Fantasieadressen” erfinden – im allerschlimmsten Fall mit einem gültigen Domainanteil – womit man mit seiner Server-IP schnell auf gängigen Blacklists landet und dann kaum Mails mehr verschickt werden können.
- Moodle loggt exzessiv Benutzeraktivitäten (eigentlich jeden Klick) – das Bewusstsein für Datenschutz scheint mir gerade in angloamerikanischen Kontexten nicht so sensibel entwickelt. In Deuschland gilt der Grundsatz der Datensparsamkeit. Man kann rechtlichen Problemen vorbeugen, indem man die Eltern entsprechende Einverständniserklärungen unterschreiben lässt, was einen erheblichen Aufwand bedeutet. Die Anzeige einer Information vor der erstmaligen Anmeldung, welche Daten in welchem Umfang erhoben werden, dürfte bei Minderjährigen rechtlich ins Leere laufen. Dieses Problem wird immer wieder gerne wegdiskutiert mit dem Argument, dass man sich zwischen dem pädagogisch Sinnvollen und der Gängelung durch rechtliche Kontexte kreativ bewegen muss. Fakt ist aber leider, dass Moodle nicht das Prinzip der Datensparsamkeit erfüllt.
- Interoperabilität zwischen verschiedenen Moodlesystemen (und dadurch zwischen Schulen) wird durch MNET – das Moodlenetwork möglich. Ich war bisher immer entschieden zu doof, das zu konfigurieren. Außerdem ist mir nie ganz klargeworden, welche Daten da tatsächlich ausgetauscht werden.
Es folgt eine kleine Spinnerei, wie derartige Probleme technisch gut in den Griff zu bekommen sind. Das erfordert jedoch einiges an Brain 2.0 – denn die Lösung heißt in meinen Augen LDAP.
Continue reading »
Arktur4 – softwaremäßig absolut veraltet und mit recht ungewisser Zukunft – ist in vielen Schulen immer noch ein solides Arbeitspferd und verwaltet dort ganze Netzwerke. Integrales Konzept ist die zentrale Authentifizierung via openLDAP, ein zur Zeit der Einführung bei Arktur aus meiner Sicht zukunftsweisendes Konzept. Arktur4 spuckt periodisch einen Export seines LDAP-Baumes aus: gesamt.ldif. Eigentlich als Sicherung für Notfälle gedacht, lässt sich damit allerhand Nützliches bewerkstelligen: Zum Beispiel kann man Applikationen wie Moodle, Drupal, Mediawiki, phpgroupware an openLDAP anbinden. Jeder Benutzer muss sich dann nur ein Passwort merken (und seine Daten nicht in jede dieser Applikationen eintragen – das macht dann openLDAP automatisch).
Letzte Kommentare