IServ-Linux-Client per LTSP an festplattenlose Rechner ausliefern

In diesem Blog-Artikel werde ich erläutern, wie man einen zuvor in VirtualBox über die IServ-Softwareverteilung installierten Linux-Client über einen LTSP an festplattenlose Clients ausliefert, sodass man in einem PC-Raum dann nur noch das VirtualBox-Image pflegen muss und mit den Clients keinerlei Aufwand mehr hat.

Dieser Artikel setzt voraus, dass ein LTSP mit zwei Netzwerkkarten, so wie in diesem Beitrag beschrieben, vorhanden ist.

Prinzipielle Netzwerktopologie mit einem LTSP und einem IServ-Schulserver

Diese LTSP-Installation muss man nun verändern, damit man das in VirtualBox installierte IServ-Client-Image verwenden kann. Die LTSP-Standardinstallation geht davon aus, dass die Nutzer auf dem LTSP-Server vorhanden sind und dass deren user homes über sshfs vom Server auf die Clients eingebunden werden. Das ist bei uns nicht der Fall, da die user homes auf dem IServ liegen. Aus diesem Grund muss diese Funktion des LTSP-Servers (pamltsp) deaktiviert werden. Dieses geschieht, indem man folgende leere Datei anlegt (die Ordner client und init müssen dabei erst noch manuell mit mkdir angelegt werden) und danach ltsp initrd aufruft (beides als root).

nano /etc/ltsp/client/init/54-pam.sh
ltsp initrd

Jetzt muss noch der Export der user homes über sshfs deaktiviert werden:

ltsp nfs -h1

Jetzt ist der Server vorbereitet, um unser IServ-Linux-Image auszuliefern. Es ist an der Zeit, in VirtualBox ein solches zu erstellen. Dabei ist wichtig, dass man als Festplattentyp VMDK mit fester Größe (10 GB reichen) wählt. Zudem muss man in den Netzwerkeinstellungen auswählen, dass eine Netzwerkbrücke verwendet werden soll. Die dort angezeigte MAC-Adresse kann man dann in die IServ-Geräteverwaltung eintragen und dort auswählen, dass auf dem Client Ubuntu installiert werden soll. Beim Start der virtuellen Maschine muss dann F12 gedrückt werden, um auswählen zu können, dass diese über das Netzwerk booten soll. Hat man das gemacht, so startet automatisch die Installation des Linux-Clients.

Nach der erfolgreichen Installation des Clients in VirtualBox müssen wir diesen nun noch etwas bearbeiten, damit wir ihn über unseren LTSP ausliefern können. Wenn der Client nun von einem festplattenlosen Rechner vom LTSP gestartet wird, gibt der LTSP dem Client einen neuen Hostnamen, der auf der IP-Adresse basiert, den der festplattenlose Rechner vom LTSP bekommt. Nun muss dieser Rechner beim Hochfahren mit dem jeweiligen Hostnamen der IServ-Domäne beitreten, andernfalls ist er nicht nutzbar und man kann sich nicht anmelden. Diesen Domänenbeitritt beim Hochfahren habe ich über eine systemd service unit mit dem Namen „join.service“ realisiert (als root ausführen):

nano /etc/systemd/system/join.service
[Unit]
Description=Join Domain
After=network-online.target winbind.service

[Service]
Type=simple
ExecStart=/usr/local/bin/join-domain.sh

[Install]
WantedBy=multi-user.target

Korrekte Berechtigungen setzen:

chmod 755 /etc/systemd/system/join.service

Dann muss die Unit aktiviert werden:

systemctl enable join.service 

Jetzt muss das eigentliche Skript angelegt werden, was den Domänenbeitritt bewerkstelligt:

nano /usr/local/bin/join-domain.sh
#!/bin/sh
echo -n 'passwd' | net rpc join -U administrator

Dieses Skript enthält das Passwort eines IServ-Domänen-Administrators im Klartext, was natürlich unschön ist. Leider habe ich noch keine andere Möglichkeit gefunden, um diesen Domänenbeitritt anders zu bewerkstelligen. „administrator“ ist hier durch den Benutzernamen eines IServ-Domänen-Administrators zu ersetzen. Da dieses Skript das Passwort des Domänen-Administrators enthält, ist es um so wichtiger, die Berechtigungen so zu setzen, dass nur root dieses Skript lesen kann:

chmod 700 /usr/local/bin/join-domain.sh

Normale Nutzer können das Skript nicht lesen oder ausführen. Ferner ist es nur im VirtualBox-Client-Image vorhanden, was auf dem Server liegt. Ein Angriffsszenario, bei dem beispielsweise Linux im Single User Mode gestartet wird, ist auch nicht möglich, da die Clients keine Festplatten haben.

Jetzt ist die virtuelle Maschine fertig vorbereitet und sie kann heruntergefahren und auf den LTSP kopiert werden (z. B. per scp). Nach dem Kopieren der Datei „TestClient5-flat.vmdk“ auf den LTSP muss man folgende Befehle ausführen:

ln -s "/home/user/TestClient5-flat.vmdk" /srv/ltsp/TestClient5.img
ltsp image TestClient5
ltsp ipxe
ltsp initrd

Wenn man jetzt einen Client, der mit der internen Netzwerkkarte des LTSP verbunden ist, über pxe-Boot startet, sollte man „TestClient5“ im pxe-Menü auswählen und den Client starten können. Jetzt hat man einen normalen IServ-Linux-Client, der per pxe-Boot über den LTSP ausgeliefert wird. Damit gehört das umständliche Installieren und Aktualisieren aller Clients der Vergangenheit an, da nur noch das VirtualBox-Image gepflegt werden muss. Nach jedem Update des Image muss dieses wieder auf den LTSP kopiert und „ltsp image TestClient5“ ausgeführt werden.

Das Ringen amerikanischer Großkonzerne um die Vorherrschaft im Klassenraum

Microsoft bietet sein Office-Paket „Office 365“ als Webversion für Schülerinnen und Schüler sowie für Lehrkräfte kostenlos an. Google stellt mit seiner Software „Google Classroom“ ebenfalls eine für Schulen kostenlose Internetplattform zur Erstellung von Dokumenten und zum gegenseitigen Austausch zur Verfügung. Apple versucht mit seinem vor wenigen Tagen vorgestellten neuen preiswerten 9,7″ iPad ebenfalls auf dem Bildungsmarkt Fuß zu fassen.

Diese amerikanischen Großkonzerne bieten mitnichten ihre Dienstleistungen aus reinem Interesse an digitaler Bildung kostenlos an, sondern sie sind in erster Linie darauf bedacht, möglichst früh neue Nutzerinnen und Nutzer zu gewinnen, die dann aus Bequemlichkeit der Software, mit der sie als erstes gearbeitet haben, ein Leben lang treu bleiben.

Die amerikanische Journalistin Natasha Singer bringt dieses in ihrem am 13. Mai 2017 in der New York Times erschienenen Artikel „How Google Took Over the Classroom“ pointiert auf den Punkt, in dem sie die Nutzung der Google Dienste mit folgenden Worten kommentiert:

„Schools may be giving Google more than they are getting: generations of future customers“.

In Deutschland ist die Nutzung von Google Classroom noch wenig verbreitet, dafür besteht, wie die ARD-Dokumentation „Das Microsoft-Dilemma“ (abrufbar bis zum 19.05.2018) hervorragend zeigt, eine große und einseitige Abhängigkeit von Microsoft.

Im Bereich des mobilen Lernens besteht derzeit die große Gefahr, dass sich Schulen in Deutschland in eine ähnliche Abhängigkeit von Apple begeben. Zumal Medienkompetenz vielfach in der Medienberichterstattung und bedauerlicherweise auch bei Schulträgern, Medienzentren und sogar an Schulen mit der Einführung von iPad-Klassen gleichgesetzt wird.

Wir sollten an unseren Schulen nicht das Ziel haben, unsere Schülerinnen und Schüler zu willfährigen künftigen Kunden von Microsoft, Google oder Apple zu erziehen, sondern wir sollten ihnen zeigen, dass mit Open-Source-Software eine Alternative zum herrschenden Softwareoligopol besteht. Ferner sollten wir es nicht zulassen, dass Google, Apple und Microsoft in den Schulen Daten über das Nutzungsverhalten unserer Schülerinnen und Schüler sammeln, mit denen sie dann Marketing betreiben können.

Unser „GBG-Linux“ sammelt keinerlei Daten und es stellt eine Alternative zu den Systemen von Google, Apple und Microsoft dar.

Anforderungen an Mobilgeräte im schulischen Umfeld

Auf Grundlage unseres schulischen Medienbildungskonzeptes lassen sich folgende Anforderungen an ein Mobilgerät im Schuleinsatz stellen:

  • Betriebssystem als freie Software
  • Gute Reparierbarkeit und lange Einsatzdauer der Geräte
  • Hohe Stabilität der Geräte
  • Keine dauerhafte Speicherung von Dateien auf den Geräten
  • Löschung aller personenbezogener Daten bei einem Neustart
  • Einfache Administration der Geräte
  • Schutz vor Softwaremanipulation durch Schülerinnen und Schüler („Das Gerät darf durch Schülerinnen und Schüler nicht ‚verstellt‘ werden können.“)
  • Handlich und leicht
  • Gute Tastatur für die Eingabe von längeren Texten
  • Kurze Zeitspanne zwischen Einschalten und betriebsbereitem Zustand
  • Austauschbarer Akku

Diese Anforderungen werden am besten von einem gebrauchten Business-Notebook erfüllt, da diese in der Regel über hochwertige und stabile Gehäuse verfügen und eine Ersatzteilversorgung ebenfalls gewährleistet ist. Zudem werden diese Geräte in der Regel so gestaltet, dass sie durch Fachhändler repariert werden können. Infrage kommen dabei zum Beispiel Geräte der ThinkPad-x230/240-Serien von Lenovo oder Dell Latitude E6230.

Die Aspekte der Reparierbarkeit sowie die Tatsache, dass der Akku austauschbar ist, spielt für unserer Schule auch vor dem Hintergrund einer neuerlichen Bewerbung um die Auszeichnung als „Umweltschule in Europa/Internationale Agenda 21-Schule“ eine besondere Rolle. Gerade Tablet-Lösungen mit fest verklebten Akkus sind nicht nachhaltig und stehen in direktem Widerspruch im Bemühen um umweltfreundliches Verhalten.

Softwareseitig lassen sich die Anforderungen durch Anpassen der GNU/Linux-Distribution Ubuntu erzielen. Wie sich dieses im Einzelnen konkret realisieren lässt, werde ich in einem folgenden Blogeintrag vorstellen.