Geräteinitiative und Linux

Anfang Februar wurden endlich die Refurbed-Geräte an die Schulen geliefert, die für Herbst 2022 versprochen wurden. Sollte es die Geräteinitiative weiterhin geben, so hoffen wir, dass künftig die Auslieferung aller Geräte bis Oktober abgeschlossen ist.

Bei den diesjährigen Geräten handelt es sich um HP Elitebook 840 G4 der Firma AfB (Arbeit für Behinderte) mit ganz guter technischer Spezifikation.

Auch wir haben 142 Stück bekommen und bereits eine Woche nach Zustellung konnten wir die Geräte an die SuS. verteilen. Zwei große Kartons auf Euro-Paletten enthielten jeweils 71 Geräte inklusive Netzteil. Ein großer Vorteil gegenüber allen anderen Geräten ist, dass wenig Verpackung anfällt und ein klassisches Auspacken und Entsorgen von Karton somit entfällt.

Image

Schon lange bevor die Geräte geliefert wurden, haben wir ein entsprechendes Image vorbereitet. Das beinhaltet folgende Schritte.

1. Einen Rechner oder eine VM mit Ubuntu 22.04 installieren. Dort wird dann noch OpenSSH installiert, damit Ansible auf dem Rechner ausgeführt werden kann.
2. Das Ansible-Skript laptops.yml wird ausgeführt. Dieses Skript befindet sich in diesem Repository.
3. Abschließend ziehen wir noch ein Image mit Hilfe von FOG.

Details

Was macht das Ansible Skript konkret? Wir sind von unserer Desktop-Musterlösung ausgegangen und installieren den PC im Grunde so, wie unsere Geräte im EDV-Saal. Konkret heißt das, dass die IP-Adresse des Rechners in der hosts-Datei im Abschnitt EDV1 eingetragen wird.

Die Datei laptop.yml im Ordner vars wird entsprechend angepasst. Aus meiner Sicht ist hier das wichtigste die ansible_pull_repo_url und register_serial_url

ansible-pull holt Playbooks aus einem VCS-Repository (git) und führt sie auf dem lokalen Host aus. Damit können wir das verpflichtende MDM umsetzen, weil es damit einfach möglich wird auf den Geräten Software zu jeder Zeit (nach-)zuinstallieren. Bei jedem Neustart wird ansible-pull ausgeführt, wenn es Änderungen im Repository gibt. Weitere Details zu ansible-pull gibt es in diesem Beitrag.

Das laptops.yml Skript erledigt dann den Rest. Es löscht ein paar Einstellungen, die wir auf den Geräten im EDV-Saal brauchen (z.B. automatisches Herunterfahren zu bestimmten Uhrzeiten via cron, diverse Skripts in /usr/local/bin…), aber auf den Laptops der SuS. nicht. Mit Hilfe der Kommentare im laptops.yml sollte es durchaus für alle verständlich sein. Die Transaprenz gegenüber den SuS./Eltern ist hier ein weiterer großer Vorteil von Open Source Software, im Vergleich zum MDM der kommerziellen Hersteller. Da bekommen die Eigentümer der Geräte nie Einblick, was wirklich auf den Geräten geschieht.

Mit Hilfe der register_serial_url können wir die Seriennummer und den Name des SuS. in eine Datenbank schreiben, die wir später dann in die Verwaltungsapp der Geräte hochladen müssen. Aufgerufen wird die URL vom Programm create_Account.sh, das beim ersten Start ausgeführt wird.

Sind alle Anpassungen in der hosts– sowie laptop.yml-Datei erledigt, kann Ansible ausgeführt werden.

ansible-playbook laptops.yml --ask-pass --ask-become-pass --extra-vars "@vars/laptop.yml"

Ist das Skript durch, kann das Image via FOG gezogen werden.

Software-Deployment

Um das fertig erstellte Image auf die Geräte zu verteilen mussten ein paar Änderungen im Bios durchgeführt werden, damit die Laptops zum Beispiel via PXE vom Netzwerk booten können. FOG haben wir ebenfalls so konfiguriert, dass die Registrierung der Laptops und das Deployment ohne Benutzer-Interaktion möglich war. So konnten wir die 142 Laptops in ein paar Stunden relativ zügig neu aufsetzen. Auch hier zeigt sich der Vorteil einer Linux-Distribution. Das Image mit Betriebssystem und jeglicher Software hat unter 17GB. Ein „nacktes“ Windows 11, also ohne zusätzliche Software braucht mindestens 25GB (https://de.minitool.com/datenwiederherstellung/wie-viel-speicherplatz-nimmt-win11-ein.html)

Verteilung der Geräte

Wir haben die Geräte klassenweise ausgeteilt und auch die bürokratischen Aufgaben (div. Unterschriften, etc…) gleich miterledigt.

Die Kinder starten also ihr Gerät und werden dabei auch – wie im EDV-Saal – automatisch mit dem Benutzer „schule“ eingeloggt. Der erste Anblick präsentiert sich so.

Die SuS. werden beim ersten Login nach ihren Zugangsdaten gefragt. Mit diesen Daten wird dann lokal ein zusätzlicher Account, der auch Administrator-Rechte hat, erstellt.

Darüber hinaus wird der Login und die Seriennummer des Geräts an die „register_serial_url“ gesendet und in einer Datenbank gespeichert. Zum Auslesen der Seriennummer verwenden wir dmidecode, wie in diesem Beitrag schon einmal gezeigt wurde.

Das Skript auf Server-Seite [1] und die dazugehörige Datenbankstruktur [2] finden Sie am Ende des Beitrags.

Der vorinstallierte Account „schule“ ist „selbstheilend“, d.h. alle Änderungen die der Benutzer während des Arbeitens macht, egal ob erstellte Dokumente, Änderungen an der Auflösung/Hintergrundbild, Browser-Cookies… verschwinden nach einem Reboot, also alle Änderungen die innerhalb des Home-Verzeichnisses gemacht werden. Änderungen in anderen Bereichen sind nicht möglich, weil der Benutzer keine Administratorenrechte besitzt.
Möglich macht dies overlay-fs mit einem entsprechenden Eintrag in /etc/fstab, sowie das dazugehörige Skript /usr/local/bin/cleanup-students.sh, das via systemd nach jedem reboot aufgerufen wird. Genauers dazu gibt’s in diesem Blogbeitrag.

Das garantiert, dass jede Benutzerin/jeder Benutzer immer die gleiche Oberfläche/Struktur vorfindet. Folglich müssen die SuS. in der Schule z.B im Fach Digitale Grundbildung mit diesem Account arbeiten. Das hat auch den Vorteil, dass diverse Hinweise zu Programmen/Shortcuts,… für alle SuS. Gültigkeit haben.
Um es den SuS. leicht zu ermöglichen Daten zwischen dem Account „schueler“ und ihrem – mit dem Programm createAccount.sh angelegten Account – gibt es für beide Accounts den Ordner „GemeinsamerOrdner“ im jeweiligen /home-Verzeichnis. Egal welcher der beiden Benutzer auf die Dateien zugreift, sie sind immer im Besitz (owner) der Datein im „GemeinsamenOrdner“. Um das zu ermöglich wird am Ende des createAccounts.sh Skripts ein bindfs-Eintrag in der /etc/fstab gemacht. Siehe dazu auch https://linux-bildung.at/2022/09/rechte-fuer-gemeinsame-ordner/. Somit könen SuS. eine begonnene Aufgabe zuhause gerne auch unter dem eigenen Account fertigstellen. Darüberhinaus überleben alle Dateien in „/home/schule/GemeinsamerOrdner“ einen reboot, bleiben also erhalten.

Accounts – Zusammenfassung

Auf dem Gerät sind am Ende also 3 Accounts installiert.

1.) schule – dort sind alle Einstellungen für alle ident und ein reboot setzt ihn auch wieder auf diese Einstellungen zurück. Dateien, die im Ordner „GemeinsamerOrdner“ gespeichert werden bleiben nach einem Reboot erhalten. Dieser Ordner dient auch als Austauschordner für den SchülerAccount.

2.) SchülerAccount – Systemverwalter, bei dem die Einstellungen beliebig verändert werden können. Dieser Benutzer hat alle Rechte, kann beliebige Software installieren/deinstallieren,…

3.) admin1 – Systemverwalter. Wird nur vom IT-Administrator gebraucht, falls ein SuS. mit dem Gerät kommt, auf das dieser keinen Zugriff mehr hat. (z.B.: Passwort vergessen)

Bürokratie

Das wichtigiste wäre jetzt erledigt. Jetzt müssen noch die bürokratischen Hürden genommen werden. Dazu wird überprüft, ob alle SuS. einer Klasse auch in unserer Datenbank gelandet sind. Ist dies der Fall, kann die Seriennummer und die dazugehörige SokratesID exportiert und in die vorgegeben Excel-Datei kopiert werden. Warum eigentlich ein Excel-Datei und keine universellere CSV-Datei? Microsoft-Zwang, den kennen wir schon. Nachdem die Datei aber keine ominösen Makros enthält, klappt das auch mit LibreOffice. Die Daten können dann in die Anwendung app.digitaleslernen.gv.at importiert werden. Jetzt können die Übergabedokumente und auch die Unterschriftenliste ausgedruckt und ausgehändigt werden.

Erfahrungen

Die ersten paar Wochen mit einer Linux-Distribution auf den Geräten der SuS. sind vorübergegangen. Um diverse Fragen zu Garantie, Versicherung, Support etc. abzufedern, haben wir einen Moodle-Kurs eingerichtet, der ein paar wichtige Hinweise gibt. Dieser wird auch bei Bedarf entsprechend erweitert. Auch die Geräte selbst sind sehr gut und wenn in der 1. Woche technische Problem auftreten, dann wird das SuS.-Gerät mit einem vorhandenen LuL.-Gerät getauscht – inklusive Änderung der Seriennummer in der App. Insgesamt musste ich vier Geräte einschicken, aber die AfB ist sehr bemüht und hat die defekte Tastatur,… rasch getauscht. Andere Lieferanten lassen sich da durchaus mehrere Wochen Zeit.

Restrisiko

Nach wie vor schafft es das BMBWF leider nicht, den Passus „Geräte sind linux-kompatibel“ mit in die Ausschreibung aufzunehmen. Von Beginn an haben wir das eingefordert und leider haben wir diesbezüglich auch noch immer keine fixe Zusage. „Man arbeite daran“ könnte man die Aussagen aus dem BMBWF diesbezüglich interpretieren. Es bleibt also immer ein kleines Restrisiko, dass auf den zur Verfügung gestellten Refurbed-Geräten, Debian/Red Hat/Suse oder Ubuntu nicht läuft. Somit ist bei der Geräteinitiative immer für Spannung gesorgt.

"[1] - register_serial_url Skript
<?php
    try {
    $dbSettings = parse_ini_file("DATABASESETTINGS");
    $dsn = 'mysql:host=' . $dbSettings['host'] . ';dbname=' . $dbSettings['dbname'] . ';charset=utf8';
    $pdo = new PDO($dsn, $dbSettings["user"], $dbSettings["password"], array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'utf8'"));
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
   $macL=$_GET['macL'];
   $macW=$_GET['macW'];
   $name=$_GET['name'];
   $serial=$_GET['serial'];
   $ip=$_SERVER['REMOTE_ADDR'];

   $sql = "delete from laptops where macLan = :macL";
   $q = $pdo->prepare($sql);
   $q->execute(array(':macL'=>$macL));
   $sql = "INSERT INTO laptops (macLan,macWLan,name,serialnumber, ip) VALUES (:macLan,:macWLan, :name, :serial, :ip)";
   $q = $pdo->prepare($sql);
   $q->execute(array(':macLan'=>$macL,':macWLan'=>$macW, ':name'=>$name, ':serial'=>$serial, ':ip'=>$ip));
   $pdo=null;
} catch (PDOException $e) {
   echo($e);
   die();
}
?>

[2]
CREATE TABLE `laptops` (
  `id` int(11) NOT NULL,
  `macLan` varchar(20) NOT NULL,
  `macWLan` varchar(20) DEFAULT NULL,
  `name` varchar(20) NOT NULL,
  `serialnumber` varchar(30) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4;