LTSP-Server in Lehrerzimmer

[bau]

Die abgebauten Klassenzimmerserver sollen im Lehrerzimmmer die Windows-Maschinen ersetzen. Das kann nun in Angriff genommen werden, da wir das Problem mit den sich abschaltenden Servern seit einiger Zeit nicht mehr beobachtet haben. Zunächst sollen mal zwei der PC ersetzt werden, um zu prüfen, wie die Kollegen reagieren. Es können dann auch weitere Clients in den Tischgruppen und am Fenster installiert werden. Am Platz von Rüdiger wird ein Client für jedes Netz vorgesehen, ein digitaler Tastatur/Maus/VGA-Umschalter wird installiert.

Subnetz

Im Lehrernetz (grau) haben wir nur eine begrenzte Anzahl an IP (ein halbes Klasse-C-Netz: 10.16.209.X / 255.255.255.128 siehe auch ​http://paedml.kg-fds.de/trac/wiki/AdminIp). Ich würde daher auf dem Nameserver (db.kg-fds.de) den dnsmasq installieren, der bekannten Clients eine IP in einem weiteren Subnetz verpasst und per Firewall-Forward-Regel (NAT/Gateway) diese Clients ins große BelWUE-Netz weiterleitet. [Ich glaube, das brauchen wir dann für local-apps, alles andere sollte doch vom LTSP-Server aus losgeschickt werden?]

Anpassungen

Auf den LTSP-Servern müssen einige Kleinigkeiten angepasst werden, da die Umgebung sich doch recht heftig vom Schülernetz unterscheidet. Das wären die IP's der LTSP zu vergeben (diese müssen nicht in der Firewall der paedml freigegeben werden, da im grauen Netz keine Beschränkungen eingetragen sind), die IP's müssen für NFS freigeschaltet werden. Drucken können die LTSP auf alle Lehrerdrucker direkt, auf die Drucker im Schülernetz über die paedml. Damit haben wir ja umgekehrt bereits Erfahrungen.
Das virtuelle Windows muss mit einem InfoSys versehen werden, die Routine zum automatischen Login muss eventuell angepasst werden, da diese prüft, ob eine bestehende, gültige Samba-Verbindung zum paedml unter dem Benutzername besteht, das könnte schiefgehen. Es benötigt natürlcih noch die Druckertreiber von Kopierer und LZ-Druckern.

Spannende Sache - pack mer's

[Rüdiger Kupper]

Welche IP soll der neue LZ-Server bekommen?

[bau]

Die IP's für das Lehrernetz werden auf dem db-Server verwaltet (bind). Ich habe dort freie IP ab 10.16.209.44. Nennen wir die LTSP ltspl1 ...?

[Rüdiger Kupper]

oder "lzltsp1 ..." oder "ltsplz1 ..."

[Rüdiger Kupper]

So, wir haben jetzt einen achten LtspServer im Schülernetz (derzeit noch). Ich darf vorstellen: ltsp8, IP 10.32.2.8.

Ich habe den neuen Server erst einmal wie gewohnt im Schülernetz aufgesetzt, weil ich nicht wusste, wie ich die anderen ltsp aus dem Lehrernetz heraus erreiche (gar nicht, oder?). Daher musste ich zum Klonen eh ins Schülernetz. Da schien es mir das einfachste, das Skript wie gewohnt durchlaufen zu lassen.

Der Server läuft und man kann sich lokal einloggen (bin ich gerade). dnsmasq beschwert sich beim Hochfahren, dass es keine ltsp8.conf gibt, aber sonst tut alles.

Den können wir uns jetzt vornehmen und für's Lehrernetz anpassen. Aber für heute reicht's ;-).

[Rüdiger Kupper]

Was derzeit nicht geht:

• ltsp8 hat noch keinen DNS-Eintrag
• ein ssh auf 10.32.2.8 schlägt fehl mit "Connection reset by peer". Woran liegt das?

[bau]

Keine Ahnung??? Irgendein Socket-Problem meldet der - ist die Netzkonfig korrekt?
Ich würde den LTSP nun, da er läuft an seinen Zielort, nämlich das Lehrernetz verfrachten.
dnsmasq wird dann entsprechend eine Config für ltspl1,... bekommen und dann halt einfach mal starten.
Für die

[Rüdiger Kupper]

ltspl1 hängt jetzt im Lehrernetz und läuft, IP 10.16.209.44.

@bau

• Bitte schau nochmal, ob ich die Netzkonfiguration in /etc/network/interfaces richtig habe. Sollen neben dem db noch weitere Nameserver eingetragen weden (auf AdminIp stehen noch die BelWUE-Server, ist das noch relevant?)
• Kannst Du Dich um den dnsmasq und den pxe-boot kümmern? Dann können wir dem neuen Server auch einen Client verpassen.

[Rüdiger Kupper]

Soll ich den Server statt eines Windows-Rechners an den Computertisch stellen? Lokal kann man darauf schon arbeiten.

[bau]

Ich habe die .ssh/config Dateien bei linadmin und root angepasst (wir sind jetzt im Lehrernetz, so dass Einträge für LTSP1-7 etc sinnlos sind. Die müssen in Zukunft getunnelt werden). Das Problem mit der komischen Fehlermeldung beim ssh-Login habe ich gelöst durch ein

  apt-get --reinstall install openssh-server

[bau]

Die Server im Lehrerzimmer laufen nicht mit einem RAID. Der mdadm läuft aber immernoch als Daemon und verschickt einmal täglich eMails, dass das Raid nicht funktionsfähig ist. Ich habe nun in der /etc/default/mdadm den Serverstart verhindert und den mdadm gestoppt, die Meldung sollte nun nicht mehr auftauchen!

Ich würde vorschlagen, dass wir zwei weitere LTSP-Server hochschaffen und gleich mal das Setup-Script auf diese loslassen. Dann würde ich zwei der Windows-Kisten ersetzen und mal schauen, was passiert.

[Rüdiger Kupper]

• das mdadm-Paket kann auch ganz entfernt werden
• Ich müsste das Setup-Skript ein wenig auf das Lehrernetz anpassen (z.B. andere IP des NFS-Servers, andere Proxyeinstellungen, andere Netzwerkconfig, etc.) Das müsste recht flott gehen, ich nehme den laufenden ltspl1 als Vorlage (dort scheint ja jetzt alles richtig konfiguriert zu sein).

[bau]

Es gnügt leider nicht, den mdadm in der /etc/default/mdadmd zu konfigurieren, der cron-daily-Job meckert trotzdem weiterhin rum. Ich musste nun den /etc/cron.daily/mdadmd entfernen.

[bau]

Aufgabe:

• Im virtuellen Windows des ltspl1 muss ein MSAccess samt InfoSys installiert werden.
• InfoSys prüft beim Starten bislang, ob das HomeVZ des Users nach H: verbunden ist, dieser SSO-Mechanismus muss auf die geänderte Umgebung angepasst werden - eventuell eine Sicheheitsdatei im HomeVZ, die geprüft werden kann und die der Virtualbox-Starter dann anlegt.
• Druckertreiber für die LZ-Drucker und den Kopierer installieren, damit auch ausgedruckt werden kann

[bau]

Aufgabe: DHCP im Lehrernetz umstellen:

• ISC-DHCP auf db.kg-fds.de deinstallieren
• ersetzen durch dnsmasq
• dnsmasq auf den ltsplX
• Config-Datei auf paedml erweitern um ltsplX
• dnsmasq auf db.kg-fds.de vergibt Adressen im Bereich 10.16.209.X/255.255.255.128 mit PXE-Bootmenu für alle Rembo-Clients und alle unbekannten (Gateway: 10.16.209.1 / wwwproxy.belwue.de)
• dnsmasq auf ltsplX vergibt Adressen an ihm bekannte Thin-Clients im Adressbereich 10.16.X.Y (Gateway: 10.16.X.1/255.255.0.0) (der ltsplX selbst, dort läuft ein NAT)

[bau]

Noch besser: Ich habe BelWUE gerade angefragt, ob wir auch einen größeren Adressraum bekommen können.

[Rüdiger Kupper]

Replying to bau:

Noch besser: Ich habe BelWUE gerade angefragt, ob wir auch einen größeren Adressraum bekommen können.

Das wäre natürlich die viel elegantere Lösung.

[Rüdiger Kupper]

Replying to bau:

• InfoSys prüft beim Starten bislang, ob das HomeVZ des Users nach H: verbunden ist, dieser SSO-Mechanismus muss auf die geänderte Umgebung angepasst werden

Bei unserem virtuellen Windows wird das Homeverzeichnis automatisch als "shared Folder" eingebunden. Es taucht momentan unter dem nächsten erreichbaren Laufwerksbuchstaben D: auf. Das "Eigene Dateien"-Symbol verweist ebenfalls dorthin, so dass die Nutzer Ihre Dateien wie gewohnt finden.

Ich hatte nicht herausgefunden, wie man beim automatischen Verbinden den Laufwerksbuchstaben vorgibt.

Frage: Kannst Du auch mit D: arbeiten? Sonst muss ich nochmal nachsehen.

[bau]

Kein Problem, D: ist auch OK.
Bislang war es nur so, dass hinter H:\ der Link
paedml\username zu finden war. Ich konnte also prüfen, ob das Share aktiv verbunden war oder nicht. das muss ich ändern.

[bau]

BelWUE hat uns heute ein größeres Subnetz auf den Router parallel zum alten aufgeschaltet. Ich werde das Netz baldmöglichst umstellen (siehe auch AdminIp):

Netz:                   10.16.112.0/23
Gateway (unser Router):	10.16.112.1
Subnetmask:		255.255.254.0

[bau]

auf dem db ist nun isc-dhcp ersetzt durch dnsmasq. Allen PXE-bootenden Maschinen wird nun ein Bootmenu gezeigt und man kann ltspl1 auswählen - funktioniert gut, ich bin grade in der Chemie an einem Client am Arbeiten!

[Rüdiger Kupper]

Super!
Theoretisch können die Kollegen, die ihren Laptop im LZ haben, diesen ja auch als Client verwenden oder?

[Rüdiger Kupper]

Ich arbeite gerade mit meinem Client an ltsp1. Alles funktioniert prächtig, es ist praktisch kein Unterschied zu den anderen Servern feststellbar. Lediglich mein Dropbox hat Schwierigkeiten, ins Netz zu kommen. (Obwohl dort "Proxy automatisch erkennen" eingestellt ist. Das müsste doch eigentlich gehen?)

[bau]

Ich habe nun die Virtualbox auf ltspl1 so eingerichtet, dass sie aus dem Speicherabbild innerhalb von wenigen Sekunden startet. Ich habe auf den Desktops der Kollegen einen Starter platziert (InfoSys benutzen) dieser geht aber nur vom Lehrerzimmer aus! Ich musste noch Drucker in die VM installieren, jetzt geht InfoSys!

[bau]

Es ist so geil: Ich habe grade meinen Laptop per PXE gegen den ltspl1 gestartet, mich eingelogged und eine VM gestartet und von dort aus InfoSys bedient :-)

[bau]

Es wird noch unglaublicher:
Ich habe in einer VirtualBox eine VM ohne Platte mit NIC an Brücke eingerichtet und diese beim Starten mit (l) PXE-gebootet. Sofort hatte ich einen funktionierenden Thinclient, nach dem einloggen konnte ich auf dem Server die VM starten und InfoSys benutzen. Ich glaube das ist es, was wir den Kollegen auf ihren privaten Laptops einrichten :-)

[bau]

Wenn wir mit Speicherabbildern arbeiten ist es übrigens so, dass wir das Abbild nach jeder Veränderung an der VM (als user linadmin) nochmals neu erzeugen müssen (als User bau oder kup). Das Abbild muss aus ~/Virtualbox VM/XP/Snapshots/ nach /usr/share/virtualbox-saved/Speicherabbild_XYZ.sav kopiert werden.

[bau]

Zu Dropbox: Wir sind mal wieder im Lehrernetz . funktioniert das hier überhaupt?

[Rüdiger Kupper]

Die Dropbox-Entwickler sind sich völlig im Klaren darüber, dass ihre Software hinter der Firewall von Firmen betrieben wird. Daher verwenden sie ausdrücklich nur den HTTP- und HTTPS-Port zur Kommunikation [1]. Wenn ich nicht irre, müsste das aus dem Lehrernetz problemlos funktionieren?

Vgl. aber auch [2] (Dropbox unterbinden).

[1] ​https://www.dropbox.com/help/23/en
[2] ​http://security.stackexchange.com/questions/24714/best-practice-to-block-dropbox-usage

[Rüdiger Kupper]

Replying to bau:

Es wird noch unglaublicher:
Ich habe in einer VirtualBox eine VM ohne Platte mit NIC an Brücke eingerichtet und diese beim Starten mit (l) PXE-gebootet. Sofort hatte ich einen funktionierenden Thinclient, nach dem einloggen konnte ich auf dem Server die VM starten und InfoSys benutzen. Ich glaube das ist es, was wir den Kollegen auf ihren privaten Laptops einrichten :-)

Jawoll, das gibt's doch schon :-): siehe comment:4:ticket:1027.

[Rüdiger Kupper]

Replying to bau:

Ich habe in einer VirtualBox eine VM ohne Platte mit NIC an Brücke eingerichtet und diese beim Starten mit (l) PXE-gebootet. Sofort hatte ich einen funktionierenden Thinclient, nach dem einloggen konnte ich auf dem Server die VM starten und InfoSys benutzen. Ich glaube das ist es, was wir den Kollegen auf ihren privaten Laptops einrichten :-)

Wie gesagt, da fände ich es fast einfacher, den Kollegen im BIOS ihres PCs den PXE-Boot zu aktivieren und sie als Client ins Lehrernetz booten zu lassen. Dann können sie bequem Infosys verwenden.
Denn ehrlich: Du willst doch nicht jedem einzelnen Kollegen individuell auf seiner Maschine VirtualBox installieren und die VM einrichten. Da bist Du ja tagelang beschäftigt!

[Rüdiger Kupper]

Ich fände es überhaupt sehr charmant, wenn die Kollegen ihre eigenen Laptops als LtspClients verwenden würden. Dazu müssten wir ihnen nur einmal demonstrieren, wie sie in ihrem BIOS den PXE-Boot aktivieren. Danach könnten sie praktisch von jeder Neztwerkdose im Kepler-Gymnasium aus booten: Im LZ ins Lehrernetz, außerhalb automatisch ins Schülernetz.

[Rüdiger Kupper]

Replying to bau:

Ich habe nun die Virtualbox auf ltspl1 so eingerichtet, dass sie aus dem Speicherabbild innerhalb von wenigen Sekunden startet. Ich habe auf den Desktops der Kollegen einen Starter platziert (InfoSys benutzen) dieser geht aber nur vom Lehrerzimmer aus! Ich musste noch Drucker in die VM installieren, jetzt geht InfoSys!

Super! Ich würde dem Infosys-Starter einen eindeutigen Hinweis hinzufügen, etwa: "Infosys (funktioniert nur aus dem Lehrerzimmer)" oder so etwas, damit die Kollegen nicht frustriert aufgeben, wenn sie es aus den Klassenrämen versuchen.

Gute Arbeit :-) !

[Rüdiger Kupper]

Hinweis

Momentan sind die Clients im Lehrernetz und Schülernetz für die Nutzer praktisch nicht zu unterscheiden. Ich persönlich finde das toll, aber für die Kollegen ist der Unterschied vielleicht schwierig zu erfassen. Bisher sind mir nur wenige Stellen bewusst, wo der Unterschied tatsächlich ins Gewicht fällt:

• Infosys
• Zugang ins Netz, der nicht über http oder https erfolgt

Vorschlag

Wir können die Server/Clients im Lehrernetz für die Kollegen einfach unterscheidbar machen, z.B., indem wir auf dem Servern/Clients im Lehrernetz einen speziellen Bildschirmhintergrund erzwingen. Wie das geht, habe ich während meiner Update-Orgie auf Raring herausgefunden. Dann wäre für jeden Nutzer sofort ersichtlich, dass er sich in einem speziellen Netzwerk mit speziellen Zugangsrechten befindet.

[bau]

Wie gesagt, da fände ich es fast einfacher, den Kollegen im BIOS ihres PCs den PXE-Boot zu aktivieren und sie als Client ins Lehrernetz booten zu lassen. Dann können sie bequem Infosys verwenden.
Denn ehrlich: Du willst doch nicht jedem einzelnen Kollegen individuell auf seiner Maschine VirtualBox installieren und die VM einrichten. Da bist Du ja tagelang beschäftigt!

Doch, das will ich, denn Virtualbox ist so schnell eingerichtet. Und es ist halt doch praktischer, ich kann ganz normal auf meinem Desktop weiterarbeiten und zusätzlich in einer VM einen Thinclient starten :-)

[bau]

Super! Ich würde dem Infosys-Starter einen eindeutigen Hinweis hinzufügen, etwa: "Infosys (funktioniert nur aus dem Lehrerzimmer)" oder so etwas, damit die Kollegen nicht frustriert aufgeben, wenn sie es aus den Klassenrämen versuchen.

Solch einen Namen hat er schon :-)
Ich denke mal, wir sollten den Kollegen in der GLK einen kurzen Hinweis geben.

[bau]

Vorschlag

Wir können die Server/Clients im Lehrernetz für die Kollegen einfach unterscheidbar machen, z.B., indem wir auf den Servern/Clients im Lehrernetz einen speziellen Bildschirmhintergrund erzwingen. Wie das geht, habe ich während meiner Update-Orgie auf Raring herausgefunden. Dann wäre für jeden Nutzer sofort ersichtlich, dass er sich in einem speziellen Netzwerk mit speziellen Zugangsrechten befindet.

Das fände ich doch sehr schade, denn ich finde es schön, wenn jeder Kollege sich seinen Desktop individuell gestalten kann (das ist bei Schülern das Erste, was die machen) - Was ich schonmal überlegt habe ist, ob man nicht irgendwo in der oberen Leiste den Rechnername/Server anzeigen lassen kann.
Auch schön wäre, wenn du das Logo auf dem LoginScreen mit dem Schriftzug Lehrernetz versehen würdest, dann ist der Unterschied offensichtlich - noch besser wäre ein eigenes Logo für jeden LTSP-Server, dann erkennt man bereits am Login, mit welchem Server man verbunden ist (wäre sehr praktisch!). Das können wir dann so lösen, dass es die Logos für alle Server gibt und beim Serverstart ein Script das korrekte Logo verlinkt.

[Rüdiger Kupper]

Replying to bau:

Was ich schonmal überlegt habe ist, ob man nicht irgendwo in der oberen Leiste den Rechnername/Server anzeigen lassen kann.

Gute Idee, mal suchen, ob es so etwas wie einen "hostname indicator" gibt:
​http://askubuntu.com/questions/30334/what-application-indicators-are-available

Auch schön wäre, wenn du das Logo auf dem LoginScreen mit dem Schriftzug Lehrernetz versehen würdest, dann ist der Unterschied offensichtlich - noch besser wäre ein eigenes Logo für jeden LTSP-Server, dann erkennt man bereits am Login, mit welchem Server man verbunden ist (wäre sehr praktisch!). Das können wir dann so lösen, dass es die Logos für alle Server gibt und beim Serverstart ein Script das korrekte Logo verlinkt.

So etwas hatte ich ohnehin vor. Mit hilfe von "image magick" müsste man eigentlich einen Schriftzug auf das png des Logos schreiben können. Das hab ich mir schon oft gewünscht, wenn ich im Computerraum schnell mal einen Client an einem bestimmten Server finden musste.

[Rüdiger Kupper]

Querverweis: #1047

[Rüdiger Kupper]

Replying to bau:

Ich habe auf den Desktops der Kollegen einen Starter platziert (InfoSys benutzen)

Ich habe keinen Starter auf meinem Desktop, ich vermute, Du hast sie nach "Desktop" kopiert, sie müssten aber nach "Arbeitsfläche".

-> Bitte den Starter auf dem paedml ins Verzeichnis /etc/skel-teachers-mandatory/Arbeitsfläche/ kopieren und ins svn einchecken. Dann wird er jede Nacht an alle Lehrer verteilt. So bekomen auch in Zukunft neu angelegte Nutzer den Starter.

[bau]

Ich habe ein kleines Script (PHP) geschrieben, um den Starter in die HomeVZ zu kopieren. Ich habe auch gleich damit das Logout-Workaround in die Lehrerverzeichnisse kopiert. Script liegt derzeit recht rudimentär im home von root auf dem ltspl1.

[Rüdiger Kupper]

Wie gesagt, für alles, was in die Himeverzeichnisse der Nutzer verteilt werden soll, bitte den Skelton-Mechanismus verwenden. Sonst haben wir mehrere Skripte am Start, die das selbe tun. Der Mechnismus unterscheidet zwischen Schüler und Lehrern, jeweils:

• erzwungene Kopie (Dateibaum "mandatory")
• Kopie nur bei Nichtexistieren (Dateibaum "default")
• Löschen einer Datei (Datei "delete")

(vgl. Skript deploy-skeleton. Dieses Skript läuft jede Nacht als Cronjob:)

root@paedml:~# deploy-skeleton --help

Usage: deploy-skeleton -h|--help
       deploy-skeleton [-s|--students] [-t|--teachers] [-v|--verbose] path
       deploy-skeleton [v-|--verbose] path uid

Deploy all or part of /etc/skel-{teachers|users}-{default|mandatory|delete}, either to all teachers' and students' homes,
or to the given user's home directory.

  Examples:
    Deploy for *one* teacher or student
    (script will determine if user is a teacher or a student):

       deploy-skeleton Desktop kup
       deploy-skeleton .dmrc   kup
       deploy-skeleton .       kup
  
    Deploy for *all* teachers and students:

       deploy-skeleton Desktop
       deploy-skeleton .dmrc
       deploy-skeleton .
}

[bau]

Ah gut!
Das Script hatte ich hauptsächlich für die Verbreitung der Datei .InfoSys im HomeVZ gebraucht - Mist, da wurde jetzt auch der Standard erzwungen. Ich packe die gleich mal von mandantory in default, denn in der Datei sollte schon der Benutzername drinstehen. Am Besten wäre es natürlich, das Script auch per cornjob mitlaufen zu lassen, damit auch neue Kollegen ohne Login an den VM auf ltspl1 eingelogged werden.

[Rüdiger Kupper]

Ah, daher hat mich das virtuelle Infosys gestern zweimal nach meinem Nutzernamen gefragt.

[Rüdiger Kupper]

LtspServer im LZ ist verfügbar. Clients booten erfolgreich, es müssen nur welche aufgestellt werden ;-).

[Rüdiger Kupper]

Die jeweils rechten Clients am Computertisch im LZ booten jetzt von ltspl2 (changeset:788/keplertools).
Entweder, die Kollegen werden bockig und beschweren sich, oder sie setzen sich einfach dran und loggen sich ganz normal ein. Meine Beobachtung, wenn ich testweise einen Client von ltspl2 gebootet hatte, war, dass er ganz normal genutzt wurde.

[Rüdiger Kupper]

Okay, ich habe (mit *erheblichem* Körpereinsatz und Ausflügen in den Keller) die Monitore an (proxmox)ltspl2 und dem Client links daneben vertauscht.

Ergebnis: An diesem Client hat man jetzt einen komfortablen Monitor, hervorragenden Sound (externe Boxen), zwei USB-Anschlüsse für USB-Laufwerke und den Multikartenleser. Ich wüsste nicht, was man sich noch wünschen könnte :-).

[jas]

Danke :-)