Satellitenserver 3.10

Satellitenserver aktualisieren

Den Satellitenserver können Sie wie gewohnt per Skript aktualisieren ⇒ Satellitenserver aktualisieren.

Alternativ steht auch ein frisches OVF basierend auf Debian 11 zur Verfügung, falls Sie von einer sauberen Basis neustarten wollen (Sat 3.10). Die alte Konfiguration können Sie natürlich über die Weboberfläche exportieren bzw. importieren. Falls Sie Ihren alten Sat per dist-upgrade händisch auf Debian 11 aktualisieren wollen, ist auch das möglich. Falls anschließend Fehler auftreten sollten, einfach nochmal das Sat-Updateskript einspielen.

Bitte prüfen Sie nach dem Update unbedingt, ob Sie eventuell alte generische Module einsetzen und diese noch benötigt werden. Unter Umständen überschreiben Sie damit aktualisierte Systemdateien. Wir haben uns bemüht, alle Ihre gemeldeten Fehler und Probleme zu beheben, so dass von uns bereitgestellte Fixes als generisches Modul nicht mehr notwendig sein und entfernt werden sollten.

Denken Sie wie üblich daran, zur Sicherheit vor dem Update einen Snapshot anzulegen und evtl. die Konfiguration über das Webinterface zu sichern, für den Fall, dass irgendetwas schiefgehen sollte.

Die Changelogs finden Sie unter Changelogs.

Neuerungen

Neben den unten genannten neuen Funktionen wurden wieder viele kleine und größere Fehler oder Unstimmigkeiten in der Weboberfläche sowie im Linux-Grundsystem behoben. Im Folgenden werden daher nur die größten Änderungen kurz beschrieben.

Lokales Caching

bwLehrpool-Clients können nun VMs auf der lokalen Festplatte cachen. Erneute Starts der gleichen VM sind anschließend in den meisten Fällen schneller und belasten das Netzwerk deutlich weniger. Erste Tests haben jedoch gezeigt, dass eine Verbesserung der Bootgeschwindigkeit nur bei Clients mit SSDs zu beobachten ist.

Damit das lokale Caching aktiviert wird, müssen verschiedene Voraussetzungen erfüllt sein. Für weitere Informationen lesen Sie bitte den entsprechenden Wiki-Artikel: Lokales Caching

Netboot Grundsystem

bwLehrpool Clients booten bisher ein minimales Linux-Grundsystem (MiniLinux) auf dem anschließend Virtuelle Maschinen gestartet werden. Dieses MiniLinux wird auch noch einige Zeit parallel gewartet und weiterbetrieben. Auf lange Sicht wird es jedoch vom neuen MaxiLinux abgelöst werden. Dieses bietet ein vollwertiges Linux-System mit zusätzlichen Tools und Xfce4 als Desktopumgebung. In der Weboberfläche wurde der Punkt „bwLehrpool MiniLinux“ folgerichtig in „Netboot Grundsystem“ umbenannt. Dort können Sie die zur Verfügung stehenden Mini-/MaxiLinux Versionen auf Ihren Satellitenserver herunterladen. Über das Flaggen-Symbol definieren Sie den globalen Standard. Falls bestimmte Rechner oder Räume andere Versionen booten sollen, können Sie dies einfach über Menüeinträge (siehe unten Neuer Menüeintrag - "Netboot Grundsystem") steuern.

Im Gegensatz zum MiniLinux, welches während des Bootvorgangs komplett über HTTP auf die Clients heruntergeladen wurde, wird das MaxiLinux on-demand über DNBD3 gestreamt und damit auch von verfügbaren DNBD3-Proxyservern verteilt. Benötigte Daten werden bei Bedarf einfach nachgeladen. Dadurch verändert sich die Bootzeit mit dem neuen MaxiLinux kaum, obwohl das Grundsystem von ~400MB auf über 2GB wächst. Der modernisierte Unterbau bietet viele neue Möglichkeiten. Studierende, die einfach nur kurz im Web recherchieren oder Drucken möchten, müssen keine VM mehr starten, sondern können die Aufgabe direkt im Linux-Grundsystem erledigen. Für Administratoren wird das Debugging leichter, weil im Grundsystem nun auch Tools wie z.B. iperf, wireshark, htop, manpages usw. zur Verfügung stehen oder kurzfristig nachinstalliert werden können. Die Infoscreens können nun Chromium zur Anzeige nutzen und müssen nicht mehr auf den minimalen slxbrowser ausweichen. Außerdem sind Docker und Singularity enthalten um containerbasierte Anwendungen auszuführen. Das ist insbesondere insofern interessant, als dass Docker-Container inzwischen auch nativ auf die Grafikkarte zugreifen können. Dies macht neuartige Anwendungsfälle wie beispielsweise im KI/ML-Bereich möglich. Dadurch, dass Daten nur bei Bedarf geladen werden, muss nicht mehr so stark auf ein möglichst schlankes Grundsystem geachtet werden und es können einfacher neue Tools integriert werden.

Änderung bei der Versionierung

Bisher markierte die höchste MiniLinux Version das zuletzt veröffentlichte, stabile Grundsystem. Version 1 dagegen war immer unsere Testversion, wenn wir etwas angepasst und zum Testen freigegeben hatten. Das funktionierte prinzipiell, hatte aber einen entscheidenden Nachteil: Wenn Version 1 verwendet wurde und diese Version anschließend erneut aktualisiert wurde, konnten sowohl Sie als auch die Entwickler keine Rückschlüsse mehr ziehen, welche „1er-Version“ derzeit genau genutzt wird. Zum Debuggen macht es aber einen großen Unterschied, ob Version 1 vom Mai oder vom Oktober verwendet wird.

Aus diesem Grund finden Sie in der Weboberfläche unter „Netboot Grundsystem“ jetzt unterschiedliche Branches. Als Branches wird es „MiniLinux“, „MiniLinux Beta“, „MaxiLinux“ und „MaxiLinux Beta“ geben. Darin werden die Versionsnummern jeweils unabhängig voneinander laufend erhöht. Somit können Sie auch zwischen den Testversionen (z.B. MiniLinux BETA) vor- und zurückwechseln. Das sollte es hoffentlich für alle Beteiligten einfacher und übersichtlicher machen.

Neuer Menüeintrag - "Netboot Grundsystem"

Im Modul „iPXE/Boot Menu“ finden Sie nun, wenn Sie einen neuen Menüeintrag hinzufügen, zusätzlich den Typ „Netboot Grundsystem“. Darin können Sie angeben, welches Mini-/MaxiLinux dieser Eintrag booten soll. Sie können sich damit beispielsweise ein Testmenü mit allen zur Verfügung stehenden Mini-/MaxiLinux Versionen zum Testen aufbauen und dieses Menü z.B. in Ihrem Hauptmenü als passwortgeschützten Unterpunkt verlinken. Oder Sie liefern an bestimmte Räume das MaxiLinux v2 und an andere Räume das MiniLinux v26 aus. Machen Sie sich in Ruhe mit den Optionen vertraut - der Freiheit sind hier wenig Grenzen gesetzt.

Multi-Monitor mit VirtualBox

Bis jetzt konnte innerhalb einer VM in bwLehrpool immer nur ein Monitor genutzt werden, auch wenn mehrere Anzeigegeräte an den Clientrechner angeschlossen sind. Bei der Verwendung von Beamern wird auf eine geklonte Ansicht umgestellt, sodass beide Anzeigen das gleiche Bild zeigen. Dies hat jedoch den Nachteil, dass sich damit z.B. der Präsentationsmodus von Powerpoint nicht nutzen lässt.

Leider bietet VMware keine programmatische Schnittstelle, um die Bildschirmausgabe zu steuern. Daher sehen wir hier im Moment keine Möglichkeit für eine Lösung.

VirtualBox verhält sich hierbei jedoch anders, so dass es nun eine erste Unterstützung für Dual-Monitor Betrieb in VirtualBox VMs gibt. Im Zusammenspiel mit Beamern und Veränderung der Einstellungen über die BeamerGUI (im VMchooser oder der PVS-Toolbar) können derzeit noch seltsame Verhaltensweisen auftreten. Die Funktion ist daher zunächst für Desktop-Sitzungen mit zwei Monitoren gedacht und als BETA-Funktion anzusehen.

Wenn Sie eine VirtualBox-VM auf einem Client mit mehreren Monitoren starten, sollte sich die Ansicht nach dem Boot automatisch auf beide Monitore strecken.

Infoscreen

URL-Panel