Dies ist eine alte Version des Dokuments!
Inhaltsverzeichnis
Satellitenserver 3.10
Der neue bwLehrpool-Satellitenserver 3.10 sowie Mini-/MaxiLinux 28 stehen zur Verfügung. Im Folgenden werden einige der Neuerungen ein wenig detailierter vorgestellt. Bei Fragen können Sie sich gerne direkt an uns wenden (⇒ support@bwlehrpool.de).
Die vollständigen Changelogs finden Sie unter: Changelogs
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, wobei wir eher empfehlen würden, in diesem Fall direkt das neue OVF zu nutzen. Falls nach erfolgreichem dist-upgrade Fehler auftreten sollten (z.B. Webserver startet nicht), einfach nochmal das Sat-Updateskript einspielen.
Bitte prüfen Sie nach Update des Satellitenservers und Mini-/MaxiLinux, ob Sie eventuell alte generische Module einsetzen und diese noch benötigt werden. Unter Umständen überschreiben Sie damit aktualisierte Systemdateien des Linux-Grundsystems. 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. Werfen Sie dazu auch einen Blick in die Changelogs.
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.
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 einige Änderungen kurz beschrieben.
Netboot Grundsystem
Derzeit stehen 4 verschiedene Grundsysteme bereit (2x Mini- und 2x MaxiLinux jeweils basierend auf Ubuntu 18.04 bzw. Ubuntu 20.04). Wir empfehlen die Nutzung von MaxiLinux 28 basierend auf Ubuntu 20.04 mit Kernel 5.10. Die anderen Systeme stehen derzeit noch als Fallback zur Verfügung, werden aber mittelfristig nicht weiter gepflegt.
Die Authentifizierung numerischer Nutzeraccounts in MaxiLinux 20.04 sollte nun out-of-the-box möglich sein.
Sie können Satellitenserver und Grundsystem unabhängig voneinander aktualisieren. Da jedoch manche Funktionen erst in der jeweils aktuellen Version aktiv sind, empfehlen wir ein Update beider Komponenten.
Lokales Caching des Grundsystems
bwLehrpool-Clients konnten bereits Virtuelle Maschinen lokal cachen, sofern eine ID45-Partition in entsprechender Größe angelegt und die Funktion über den Satellitenserver aktiviert wurde (Lokales Caching). Zusätzlich wird nun auch ein Teil des MaxiLinux gecachet. Dadurch reduziert sich die Netzwerklast beim Boot von Clients zusätzlich. Erste Tests zeigen Geschwindigkeitsvorteile beim Bootvorgang, wenn viele Clients zeitgleich starten und die Netzwerkverbindung limitiert und/oder SSDs im Client zum Einsatz kommen.
Neue Konfigurationsvariablen
Damit die neuen Konfigurationsvariablen aktiv werden, muss sowohl Satellitenserver als auch Linux-Grundsystem aktualisiert werden. Denken Sie auch daran, dass alle Konfigurationsvariablen global (für alle Rechner), für einzelne Räume oder sogar einzeln pro Client gesetzt werden können.
SLX_PRINT_REUSE_PASSWORD
Wenn aktiviert, und der Druckserver Nutzername/Passwort anfordert, wird das Login-Passwort des aktuell angemeldeten Nutzers verwendet, anstatt wie bisher erneut das Passwort per Dialog abzufragen.
SLX_TTY_SWITCH
Legt fest, ob der X-Server einen Wechsel zur Textkonsole mittels Strg-Alt-F1 etc. zulässt.
SLX_NTFSFREE
Bestimmt, ob freier Speicherplatz auf NTFS-Partitionen als temporärer Speicher, äquivalent zu einer ID44-Partition, genutzt werden soll. Dies kann sinnvoll sein, wenn Sie eine große bestehende Windows-Lokalinstallation haben und keine neue ID44-Partition einrichten können.
Diese Funktionalität steht nur bei Verwendung des MaxiLinux zur Verfügung. Eine NTFS-Partition kann nur dann verwendet werden, wenn sie zuvor sauber ausgehängt wurde, d.h. i.d.R., dass Windows ordnungsgemäß heruntergefahren wurde.
SLX_RESOLUTION_MAPPING
Hier können Sie eine statische Zuweisung von Bildschirmanschlüssen zu Auflösungen aus SLX_FORCE_RESOLUTION vornehmen. Das Format ist eine durch Leerzeichen getrennte Liste von OUTPUTNAME=Index, z.B.
HDMI1=0 HDMI2=0 HDMI3=1
Sofern die Variable SLX_FORCE_RESOLUTION den Wert 1024×768 800×600 hat, werden jetzt die Ausgänge HDMI1 und HDMI2 die Auflösung 1024×768 haben und den gleichen Inhalt zeigen („linker Bildschirm“), und HDMI3 wird die Auflösung 800×600 haben, und den Desktop nach rechts erweitern.
Die Verwendung dieser Konfigurationsoption sollte nur für ungewöhnliche Bildschirm-Setups notwendig sein.
bwLehrpool-Suite
Bisher war der Login auf Mitarbeiter (und ausgewählte Personen mit speziellem Entitlement) beschränkt. Es gab jedoch häufiger den Wunsch, dass Studierende zur Verfügung stehende VMs mittels bwLehrpool-Suite herunterladen können sollten. Dafür wurden nun die ersten Voraussetzungen geschaffen. Die Funktion müssen Sie im Satellitenserver ggf. selbst noch freigeben (Satellitenserver → bwLehrpool-Suite → Limits und Standardwerte → „Studenten den Download lizenzfreier VMs erlauben“ ).
Studierende können anschließend VMs ohne lizenzpflichtige Software herunterladen, jedoch weder Veranstaltungen noch VMs bearbeiten oder neue VMs erstellen. Damit eine VM heruntergeladen werden kann, muss beim Upload der Haken „VM enthält lizenzpflichtige Software“ entfernt werden. Dies ist nur bei nicht-Windows-VMs möglich und lässt sich derzeit auch nicht nachträglich verändern.
Die Funktion muss zusätzlich im Freiburger Masterserver freigegeben werden. Dies werden wir voraussichtlich in etwa einem Monat durchführen, wenn (hoffentlich) die meisten Satellitenserver aktualisiert wurden. Dies hat technische Gründe, da die Funktion u.U. Probleme im Betrieb mit alten Satellitenserver verursachen könnte. Wenn es soweit ist, geben wir nochmal Notiz über unsere Mailingliste.
Fernzugriff/Guacamole
Das auf dem Guacamole-Proxy befindliche Plugin zur Kommunikation mit dem Satellitenserver muss zwingend aktualisiert werden. Falls Sie noch Guacamole 1.2 einsetzen, benötigen Sie das Plugin 1.2.1. Falls Sie bereits Guacamole 1.3 verwenden, benötigen Sie analog das Plugin 1.3.1.
https://files.bwlp.ks.uni-freiburg.de/satellit/guacamole/
Falls notwendig, können Sie nun den Port der für die VNC Verbindung verwendet werden soll im Satellitenserver setzen (Mini-/MaxiLinux 28 vorausgesetzt). Dies kann beispielsweise notwendig sein, wenn auf Clients Intel AMT aktiviert ist. Dadurch kann teilweise der Standardport 5900 durch den VNC-Server von Intel AMT belegt sein und der von bwLehrpool gestartete eigene VNC-Server eingehende Verbindungen nicht annehmen. Generell empfehlen wir jedoch den Port auf der Standardeinstellung zu belassen.
~~DISCUSSION~~
Satellitenserver WS19/20
Es ist mal wieder soweit und wir geben die neue Hauptversion des bwLehrpool-Satellitenserver mit der Versionsnummer 3.9 frei. Die neuen Möglichkeiten und Funktionen wurden wie in den vorigen Jahren bereits auf unserem gemeinsamen Anwendertreffen - im Dezember 2019 an der Universität Mannheim - vorgestellt.
Damit Sie einen besseren Überblick über die Neuerungen haben und wissen, hinter welchem Bereich sich etwas Neues versteckt, stellen wir Ihnen diese im Folgenden nochmals vor. Bei Fragen können Sie sich wie immer gern direkt an uns wenden (⇒ support@bwlehrpool.de).
Satellitenserver aktualisieren
Die neue Version steht wie üblich als Updateskript zur Verfügung und kann auch über ältere Satellitenserver installiert werden. Bitte beachten Sie, dass auf dem Server jedoch mindestens Debian 9 vorausgesetzt wird. Falls Sie also noch einen sehr alten Satellitenserver einsetzen der unter Debian 8 läuft, müssen Sie diesen entweder händisch upgraden oder einen neuen Server mit dem letzten OVF (Sat 3.7) aufsetzen und anschließend das aktuelle Updateskript einspielen.
Ab der nächsten Version unterstützen wir nur noch Server, die unter 64 Bit laufen. Außerdem wird das alte pxelinux nicht mehr unterstützt, falls noch nicht geschehen wechseln Sie bitte auf den neuen iPXE-Ansatz.
Infos zum Einspielen des Updates finden Sie unter Satellitenserver aktualisieren. 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.
Kurze Zusammenfassung
MiniLinux | MaxiLinux | |
---|---|---|
Größe | ~ 400MB | ~ 2GB |
Übertragunsart | Wird immer komplett übertragen (HTTP) | Nur benötigte Daten werden übertragen (DNBD3) |
Software | Minimales Toolset | Natives Linuxsystem mit Systemtools und zusätzlichen Anwendungen wie z.B. Docker, Singularity, Chromium, PDF-Reader |
Wenn Sie ein neues MaxiLinux „herunterladen“, wird nur der Kernel und die Init sofort auf Ihren Satellitenserver übertragen. Das eigentliche Grundsystem wird erst vom Masterserver repliziert, wenn ein Client erstmals das System bootet. Die erstmalige Übertragung kann einige Zeit dauern - der erste Bootvorgang ist dementsprechend langsam.
Achtung: Die Übertragung des MaxiLinux vom Masterserver in Freiburg auf Ihren Satellitenserver läuft über DNBD3. Ggf. müssen Sie dazu Port tcp/5006 für den FR-Masterserver in Ihrer Firewall freigeben.
Ä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.
Audiowiedergabe/-aufnahme mit VirtualBox
Wenn Sie über ein per Klinkenstecker angeschlossenes Mikrofon oder Headset innerhalb der VirtualBox-VM Audiosignale aufnehmen oder ausgeben möchten, so müssen Sie zwangsläufig das MaxiLinux verwenden. In diesem wird das neuere Pulse-Backend genutzt - das im MiniLinux verwendete ältere ALSA-Backend dagegen erlaubt leider keinen Audio-Input/Output mit VirtualBox.
Scheinbar ist das Ganze aber teilweise auch von der Hardware bzw. den verwendeten Anschlussbuchsen abhängig. So funktioniert bei manchen kombinierten Buchsen (Headset) nur das Mikrofon, jedoch nicht der zeitgleiche Output über die Kopfhörer. Eventuell müssen Sie mit verschiedenen Buchsen oder Headsets (USB, kombinierte Klinkenstecker, zwei getrennte Klinkenstecker) ausprobieren . Wir suchen noch nach einer allgemeinen Lösung.
Unterstützung von USB-Geräten in VirtualBox
Lange Zeit wurden USB-Geräte nicht direkt an VirtualBox-VMs durchgereicht und erkannt. Mit den neuen Mini- bzw. MaxiLinux Versionen, die mit dem Sat-Update zur Verfügung stehen, sollte dieses Problem der Vergangenheit angehören.
News-Anzeige auf Loginscreen
Zusätzlich zum Hilfe- und Newstext im vmChooser kann nun ein zusätzlicher Text direkt auf der Loginmaske angezeigt werden. Dies kann beispielsweise sinnvoll sein bei wichtigen Informationen, die sonst häufig untergehen (z.B. Schließzeiten in den Semesterferien, Test der Brandmeldeanlage oder Ähnliches).
Rechtemanager - Standardrollen werden zurückgesetzt und gesperrt
Im Zuge des Updates kommen einige wenige neue Berechtigungen zum Rechtemanager innerhalb der Weboberfläche hinzu. Darüberhinaus werden die bisherigen Standardrollen (Admin, Lesezugriff, Prüfungsadmin, Super-Admin) auf von uns vorgegebene Standardwerte zurückgesetzt und für die zukünftige Bearbeitung gesperrt. Falls Sie an diesen Rollen bereits Änderungen vorgenommen haben, sind diese nach dem Update verloren und Sie müssen neue Rollen mit Ihren eigenen Vorgaben anlegen. Machen Sie daher vor dem Update ggf. einen Screenshot von Ihren angepassten Rollen.
Die Standardrollen können Sie nach dem Update weder bearbeiten noch löschen, jedoch einfach per Klick kopieren und die Kopie anschließend nach Ihren Bedürfnissen anpassen.
Infoscreen
URL-Panel
Der für URL-Panel bisher verwendete „slxbrowser“ basiert auf einem sehr rudimentären QT-Browser. Bei manchen Websites gab es damit u.U. Probleme. Außerdem steht beispielweise auch keine Navigationsleiste zur Verfügung.
Mit dem neuen MaxiLinux kann nun alternativ Chromium als Browser verwendet werden. Damit sollten alle modernen Websites problemlos verwendbar sein. Außerdem lassen sich Lesezeichen vorgeben.
Bisher wurde das URL-Panel hauptsächlich für die nicht-interaktive Anzeige (Bildschirm im Eingangsbereich o.Ä.) eingesetzt. Inzwischen wird es aber auch vermehrt z.B. als Rechercheterminal in der Bibliothek genutzt. Zusätzlich können Sie bei Bedarf jetzt den geteilten Login aktivieren. Damit können sich Gäste am System anmelden und landen direkt in der abgeschlossenen Browser-Sitzung. Nutzer mit einem Hochschul-Account können sich ganz normal anmelden und den Client auch anderweitig nutzen.
Falls das MiniLinux gebootet wird, findet in jedem Fall ein Fallback auf den alten „slxbrowser“ statt, da Chromium nur im neuen MaxiLinux enthalten ist.
Standard-Panel
Im Standard-Panel, welches bspw. angebundene Kalender (HISinOne, Exchange, Davinci) anzeigt, kann konfiguriert werden, mit welchem Wochentag die Anzeige starten soll. Bisher wurde immer der aktuelle Wochentag als erstes angezeigt. Außerdem kann angegeben werden, ob die Anzahl der Rechner im angezeigten Raum über die IP-Range oder den Raumplaner gezählt werden soll. Das kann nötig sein, falls weitere Rechner wie Druckstationen oder Ähnliches per IP-Range dem Raum zugehörig sind, jedoch nicht im Raumplan gesetzt wurden, damit diese nicht im PVS-manager angezeigt werden.
Wake on LAN (WOL)
Das Modul zum Herunterfahren und Neustarten von Clients über die Weboberfläche (bisher „Reboot Control“) wurde erweitert und entsprechend umbenannt („WakeOnLAN“). Clients lassen sich nun ganz einfach über die Client-Statistiken per WOL aufwecken, herunterfahren oder neustarten. Zusätzlich lässt sich auch in einer zunächst sehr einfachen Form ein Remote-Befehl ausführen.
Da WOL-Pakete in der Regel nicht über Subnetzgrenzen hinaus geroutet werden, müssen Router entweder entsprechend konfiguriert oder ein sogenannter Sprung-Host im Subnetz des Zielrechners aktiv sein. bwLehrpool-Clients fungieren automatisch als Spung-Host. Alternativ können Sie auch eigene Rechner angeben, die eine Weiterleitung des WOL-Befehls ermöglichen.
Konfigurationsvariablen pro Client
Seit einiger Zeit können Konfigurationsvariablen nicht nur global, sondern auch pro Raum/Ort gesetzt werden. Das geht jetzt auch spezifisch für einzelne Clients. Sie finden die Option in der Detailansicht eines Clients in den Client-Statistiken. Somit können Sie beispielsweise Dozierenden-PCs früher automatisch herunterfahren lassen oder die Zeit, bis der Bildschirm in den Energiesparmodus wechselt deaktivieren, weil dies bei Präsentationen störend sein kann.
Anpassbarer Bildschirmschoner/Sperrbildschirm
Die angezeigten Texte und Warnhinweise auf Bildschirmschoner und Sperrbildschirm sowie in eingeschränktem Maße das generelle Design kann nun angepasst werden. In der Systemkonfiguration finden Sie ein neues Modul namens „Bildschirmschoner“. Dort können Sie beispielswiese die Texte anpassen, die auf dem Bildschirmschoner angezeigt werden. Das Modul ist bisher noch in einer frühen Entwicklungsphase und wird noch verbessert.
Statistikauswertung mit Datumsbereich
Auf Nachfrage können Sie im Punkt Statistikauswertung nun einen Datumsbereich angeben, um beispielsweise nur die Daten eines bestimmten Monats anzuzeigen.
ID44 / ID45 Erkennung über GUID
Die für bwLehrpool notwendigen Spezialpartitionen (ID44 bzw. ID45) wurden bisher entweder über die ID oder ein Label erkannt. Leider gibt es Tools (z.B. diskpart), die bei GPT-Partitionen keine ID oder Partition-Label setzen können. Daher wurde die Erkennung um definierte GUIDs erweitert. Weitere Infos hierzu finden Sie im entsprechenden Wiki-Artikel: Spezialpartitionen
Zusätzliche Netzwerkkarten in VM
In bestimmten Fällen sollen zusätzliche Netzwerkkarten des Clients direkt an die VM durchgereicht/gebridged werden. Das ist derzeit mit dem MaxiLinux noch nicht möglich, steht aber in Kürze ebenfalls zur Verfügung.
~~DISCUSSION~~
Aus aktuellem Anlass: bwLehrpool und kritische Sicherheitslücken
Im Zuge der immer wiederkehrenden Diskussion um kritische Sicherheitslücken (aktuell u.a. Intel1), RDP, …) kommt regelmäßig die berechtigte Frage auf, welche Auswirkungen dies auf die mit bwLehrpool betriebenen PC-Pools hat. Aus diesem Grund möchten wir unsere Einschätzung basierend auf unseren bisherigen Erfahrungen dazu kurz vorstellen.
Sicherheitslücken, wie z.B. die oben genannten, können generell auf zwei Ebenen ein Problem darstellen: Zum einen auf der Ebene des Hostsystems, in dem der Hypervisor läuft, zum anderen auf der Ebene der genutzten virtuellen Lehr- und Arbeitsumgebung. Da beide Systeme grundsätzlich stateless (zustandslos) bereitgestellt werden, ist sowohl auf der Host-Plattform (Linux) als auch für die bereitgestellten virtuellen Maschinen das Problem relativ gering. Diese werden nach dem Ausschalten (Host) bzw. Logout/Abschalten der VM wieder ihren ursprünglichen Zustand2) einnehmen, und eine mögliche Kompromittierung der Maschine wäre damit wieder zurückgesetzt. Hierin liegt ein wesentlicher Vorteil des Konzepts. Aus diesem Grund sind uns keine relevanten Vorfälle aus den letzten Jahren3) bekannt (beispielsweise durch Meldungen angegriffener Systeme). Das bedeutet jedoch nicht, dass sie nicht vorgekommen sein könnten.
Die Aktualisierung der Systeme ist trotzdem immer eine gute Idee! Für das Hostsystem erfolgt dies durch das bwLehrpool-Team. Die Aufgabe, die jeweiligen VMs aktuell zu halten, unterliegt bis auf die Standard-Images und Vorlagen den jeweiligen Lehrenden. Das wird unterschiedlich intensiv wahrgenommen. Die gängigsten Standardangriffsvektoren lassen sich aber bereits durch zwei Maßnahmen erheblich reduzieren:
- Pool-Räume bzw. Pool-Clients sollten in einem internen Netz, also nicht mit einer aus dem Internet öffentlich erreichbaren IP laufen,
- alle VMs in bwLehrpool laufen standardmäßig hinter einer NAT, sind also auch aus dem internen-Netz nicht direkt erreichbar.
Das Basissystem (Linux) wird zentral gewartet und kann sehr schnell Updates einfahren, die sofort nach einem Neustart eines Clients aktiv sind. Zudem lässt sich die clientseitige Firewall zentral konfigurieren, so dass auch auf diesem Wege schon diverse Probleme abgewehrt werden konnten.
Potenzielle Bedrohungsszenarien
Einbruch in die lokale Maschine
Potenziell wäre es möglich, aus dem lokalen Hypervisor auszubrechen. Ebenso könnten Nutzer versuchen, auf dem Grundsystem eine Rechteeskalation zu erreichen. Um Nutzer in ihren VMs nicht zu gefährden, sind die Maschinen im Prinzip als Single-User-Systeme ausgelegt, da ein entfernter SSH-Login auf bwLehrpool-Clients nur einem kleinen Admin-Kreis vorbehalten ist. Eine lokale Rechte-Eskalation beschränkt sich daher typischerweise auf die einzelne Maschine, und eine Replikation auf weitere ist recht aufwändig. Durch den zustandslosen Charakter und das komplette Löschen der eingebundenen lokalen Festplatte (ID44) sind persistente Einbrüche stark erschwert.
Verteilung von Schadsoftware durch bwLehrpool-Clients
Im Prinzip könnten bwLehrpool-Rechner bzw. Images, die u.U. nicht regelmäßig aktualisiert werden, während des Betriebs, also so lange sie eingeschaltet sind, gekapert werden. Dann könnte versucht werden, Schadsoftware im internen-Netz zu verteilen.
Durch die Konstruktion des Gesamtsystems sind die Einfallsvektoren insgesamt jedoch deutlich eingeengt (USB-Stick, Side-Load im Browser, via Home eines Users). Ein weiterer Faktor ist die relativ kurze Laufzeit der einzelnen virtuellen Maschine. Anders als im klassischen Betrieb, in dem ein Rechner durchaus länger durchläuft und sich mehrere Nutzer an- und abmelden, ist in bwLehrpool bei jedem Login die ausgewählte VM wieder auf einen sauberen Anfangszustand zurückgesetzt. Nach erfolgtem Logout läuft keine VM mehr weiter. Das lässt das Zeitfenster für die Verbreitung von Schädlingen erheblich schrumpfen. Dadurch, dass virtuelle Maschinen sich nicht gegenseitig „sehen“ (NAT), ist eine Ausbreitung auf klassischem Weg über das Netz außerdem erheblich erschwert, auch wenn natürlich DoS-Attacken möglich sind. Bisher konnten wir jedoch keine Probleme beobachten, die auf solche Fälle zurückzuführen wären.
Mittelfristig können zusätzliche Netzsegmentierungen helfen, um auch hier auf der sicheren Seite zu sein. So kann man in weiteren Schritten dafür sorgen, dass potenziell auftretende Probleme sich nicht weiter ausbreiten. Hier muss dann ggf. geprüft werden, welche Dienste und Services am Campus genutzt und das Firewalling entspreched konfiguriert werden, damit diese aus den Pools weiterhin funktionieren. Nur sollte in der Regel z.B. niemand aus den Pools direkt auf Admin-Netze von Cloud, HPC oder ähnliche Dienste zugreifen müssen.
Krypto-Trojaner und Homeverzeichnisse
bwLehrpool-Clients und die darauf laufenden virtuellen Maschinen binden je nach Konfiguration das Homelaufwerk eines Nutzers oder weitere Netzlaufwerke ein. Damit könnte im Falle eines Befalls eine entsprechende Schadsoftware so lange Schaden auf diesen Netzlaufwerken anrichten, wie der Rechner bzw. die VM läuft. Hierzu könnte zählen, dass Inhalte verschlüsselt, virenbehaftete Dateien abgelegt, Dateien gelöscht werden usw.
Um darauf zu reagieren, empfehlen wir professionelle Fileserver, die beispielsweise mit Snapshots arbeiten und serverseitige Scans unterstützen. Snapshots sollten für Nutzer nur read-only erreichbar sein, damit es immer eine konfigurierbar lange Historie gibt, auf die gegebenenfalls zurückgegriffen werden kann. Auch hier möchten wir erwähnen, dass Verschlüsselungstrojaner schon an diversen Stellen (z.B. am Campus der Uni Freiburg) beobachtet wurden (mit teilweise erheblichem Schaden), bisher jedoch nicht im bwLehrpool-Kontext.
Ein weiterer Baustein, den wir seit längerem diskutieren ist, wie sich automatische Qualitätssicherungen nach dem Erstellen und Update von VMs für die Pools organisieren lassen, so dass in den Images keine Malware läuft. Der Aufwand hierfür ist jedoch vergleichsweise hoch und es entstehen Verzögerungen bei der Veröffentlichung der Lehrumgebungen. Da bisher noch kein kritischer Sicherheitsfall aufgetreten ist, wird dieser Pfad derzeit mit niedriger Priorität verfolgt und alle Nutzer, die Images updaten, dazu angehalten, einen finalen Sicherheitscheck durchzuführen.
Weitere Überlegungen
Systemupdates
Regelmäßige Systemupdates der eingesetzten Umgebungen sind natürlich in jedem Fall sinnvoll und zu empfehlen. Da automatische Updates in den VMs in der Regel bewusst deaktiviert sind, müssen diese ggf. vorher reaktiviert werden - anschließend für den Poolbetrieb bitte wieder deaktivieren! Eine Anleitung dazu findet sich hier im Wiki unter Virtuelle Maschinen anpassen.
Einsatz von Virenscannern
Vom bwLehrpool-Team bereitgestellte Vorlagen-VMs enthalten absichtlich keinen Virenscanner. Generell steht es natürlich jedem Nutzer frei, einen Virenscanner seiner Wahl, und für den eine entsprechende Lizenz vorliegt, in seine VM zu installieren.
Bedenken Sie jedoch folgende Punkte:
- In den (Vorlagen-)VMs sind Nutzer mit einem lokalen Benutzerkonto ohne Administrationsrechte angemeldet,
- VMs sind nicht-persistent, d.h.
- Virensignaturen und der Scanner selbst veralten relativ schnell. Während Signaturen bei jedem Start automatisch aktualisiert werden könnten, ist dies bei der Scanengine und weiteren Programmbestandteilen normalerweise nicht so einfach möglich,
- Viren, Trojaner und sonstige Schädlinge sind nach einem Neustart sowieso nicht mehr vorhanden4),
- Virenscanner haben mitunter einen nicht unerheblichen, negativen Einfluss auf die Geschwindigkeit des Gesamtsystems,
- Ursprünglich für die Zukunft, automatisch, geplante Voll-Scans werden u.U. bei jedem Start der VM ausgeführt, weil der geplante Ausführungszeitpunkt irgendwann in der Vergangenheit liegt und der Scanner versucht diesen nachzuholen.
Durch die beschriebenen Punkte (Nichtpersistenz, Abschottung des Netzwerkzugriffs über NAT, kurze Laufzeit, eingeschränktes Benutzerkonto, Beschränkung der Softwareausstattung auf das Wesentliche) und unserer bisherigen Erfahrungen halten wir den Einsatz von Virenscannern in bwLehrpool-VMs daher nicht für notwendig.
~~DISCUSSION~~
Satellitenserver WS18/19
Der neue Satellitenserver enthält eine Vielzahl neuer Funktionen, die die Arbeit der Adminstratoren und Dozierenden deutlich erleichtern und verbessern können. Außerdem haben wir uns bemüht, alle bekannten und von Ihnen gemeldeten Fehler und Probleme zu beseitigen.
Eine der größten Änderungen ist der Wechsel von PXE zu iPXE. Damit ist es nun erstmals möglich, Rechner die nur UEFI und kein Legacy-PXE unterstützen, mit bwLehrpool zu verwenden.
Beachten Sie jedoch unbedingt die Informationen aus dem Abschnitt iPXE, bevor Sie das Update einspielen.
Damit Sie einen besseren Überblick über die Neuerungen erhalten und wissen, hinter welchem Bereich sich etwas Neues versteckt, stellen wir Ihnen diese im Folgenden vor. Bei Fragen können Sie sich wie immer gern direkt an uns wenden .
Satellitenserver aktualisieren
Infos zum Einspielen des Updates finden Sie unter Satellitenserver aktualisieren.
bwLehrpool-Suite
Zeitnah zum neuen Satellitenserver wird auch eine neue Version der bwLehrpool-Suite zur Verfügung stehen. Beim Starten des Programms sollten Sie einen Hinweis erhalten, sobald das Update verfügbar ist. Im Zusammenspiel mit dem neuen Satellitenserver gibt es eine Reihe praktischer Funktionen, die das Leben der Nutzer deutlich erleichtern.
Vor allem kann nun eine Vielzahl an bereits aus der Suite bekannter Optionen (z.B. Netzwerkregeln) direkt über die Weboberfläche von einem Administrator vorangelegt werden. Nutzer der Suite können diese Vorlagen dann einfach der eigenen Veranstaltung per Klick hinzufügen, ohne sich um die Details Gedanken machen zu müssen.
Up-/Download von VMs beschleunigt
Ein Manko bei der Arbeit mit der bwLehrpool-Suite ist, dass der Up-/Download großer VMs teilweise sehr zeitaufwendig sein kann. Mit zwei neuen Ansätzen wird daher versucht, die Übertragung zu beschleunigen:
- Kompression
Up-/Downloads werden mittels LZ4 komprimiert übertragen. Dadurch kann teilweise 40-50% des Traffics eingespart werden. Temporär entsteht dadurch höhere Prozessorlast sowohl beim lokalen Rechner als auch beim Satellitenserver, der die Daten packen/entpacken muss. Der verwendete LZ4-Algorithmus bieten einen guten Mittelweg zwischen Kompressionsrate und Geschwindigkeit.
- Server-Side-Copy (SSC) bzw. Serverseitiges Kopieren
Der zweite Ansatz ist ein wenig komplizierter. Beim Upload von VMs werden diese wie bisher in 16MB-Blöcke zerlegt, Hashsummen über die Blöcke errechnet und dem Satellitenserver übermittelt. Damit wird u.a. sichergestellt, dass bei der Übertragung nichts schief läuft.
Mit der neuen Funktion werden Blöcke, die bereits in anderen VM-Abbildern vorhanden sind, nicht erneut vom Client hochgeladen, sondern durch den Satellitenserver vom verwendeten Fileserver gelesen und kopiert. Bei Upload identischer Versionen kann (theoretisch) die gesamte VM serverseitig kopiert werden. Abhängig von Netzwerkinfrastruktur und Hardwareausstattung des Fileservers kann dies den Uploadvorgang merklich beschleunigen. Da diese Funktion allerdings zusätzliche I/O-Last auf dem Fileserver erzeugt, ist ihre Verwendung u. U. nicht erwünscht. Sie sollten daher gerade in der Anfangszeit ein Auge auf der Auslastung Ihres Fileservers haben.
Sie können einstellen, ob SSC aktiviert, deaktiviert, vom Benutzer innerhalb der Suite zuschaltbar ist (es erscheint eine Checkbox während des Uploads) oder automatisch aktiviert werden soll, wenn die Uploadgeschwindigkeit unter 10MB/s liegt. Die Einstellung dazu finden Sie im Menüpunkt 'bwLehrpool-Suite' unter 'Limits und Standardwerte' .
VM-Versionen verlängern/reaktivieren
VMs tragen ein festes Ablaufdatum. Normale Nutzer können dieses nicht selbst verlängern. Damit soll erreicht werden, dass veraltete VMs mit der Zeit verschwinden oder wenigstens ab und zu aktualisiert werden. Die Gültigkeitsdauer lässt sich bereits seit der letzten Version über die Weboberfläche vorgeben (Standard 220 Tage).
Dennoch kommt es immer wieder vor, dass Dozierende das Ablaufdatum verpassen, obwohl die VM dringend noch einige Tage für laufende Kurse benötigt wird. Zu diesem Zweck kann ein bwLehrpool-Suite-'Superadmin' VM-Versionen tagesgenau verlängern - maximal kann eine Version um den unter Gültigkeitsdauer festgelegten Wert verlängert werden. Dazu die gewünschte VM in der Suite bearbeiten, auf den Reiter VM-Versionen wechseln und einen Rechtsklick auf die zu verlängernde Version ausführen. Dort finden Sie den Punkt 'Ablaufzeitpunkt verlängern'.
Netzlaufwerke
Ein großes Manko war lange Zeit die fehlende Möglichkeit, zusätzlich zum Home-Verzeichnis weitere Netzlaufwerke automatisch in der VM bereitzustellen. Seit einiger Zeit ist diese Funktionalität innerhalb der bwLehrpool-Suite vorhanden und wird immer häufiger genutzt. Allerdings kennen viele Anwender die UNC-Pfade zu den verschiedenen Verzeichnissen nicht und nutzen die Funktion daher nicht. Dabei kann es sehr praktisch sein, wenn in der VM ein zentrales Austausch- oder Vorlesungs-Laufwerk zur Verfügung steht.
Daher lassen sich zentrale Netzlaufwerke nun ganz einfach über die Weboberfläche vorgeben. Auch hier nochmal der wichtige Hinweis: Wenn Laufwerke mit 'Spezifischem User' angelegt werden, kann das zugehörige Passwort nicht verschlüsselt gespeichert werden und der Studierende kann darauf Zugriff erhalten. Wird zur Authentifizierung die Option mit 'Angemeldetem User' ausgewählt, ist das Passwort wie gewohnt sicher, da es über einen verschlüsselten Kanal aus dem MiniLinux übertragen wird.
Innerhalb der Suite müssen die Laufwerke einfach nur noch per Klick aktiviert werden und stehen anschließend im Poolbetrieb direkt zur Verfügung. Zusätzliche eigene Laufwerke können selbstverständlich nach wie vor individuell angegeben werden.
Drucker
Es war schon immer ein wenig aufwendiger, Drucker in einer bwLehrpool-VM zur Verfügung zu stellen (Drucken in bwLehrpool). Der große Vorteil ist jedoch, dass VMs dadurch austauschbar bleiben, allen VMs zur Verfügung stehen und diese nichts von der Druckumgebung am Standort wissen müssen. Wir raten daher nach wie vor dringend davon ab, Drucker(-treiber) per Hand lokal in der VM zu installieren.
Seit es die Möglichkeit gibt, auszuführende Startskripte in der bwLehrpool-Suite anzugeben, begannen einige Administratoren, Netzwerkdrucker per Skript einzubinden. Das war teilweise jedoch unschön und unnötig aufwändig.
Das ist nun nicht mehr notwendig, wenn Sie einen Windows-Druckserver verwenden. Wie im Screenshot bereits zu sehen können Sie einen Netzwerkpfad angeben und diesen als 'Drucker' markieren. Windows-VMs werden den Drucker anschließend automatisch einbinden. Da der angezeigte Name des Druckers vom Druckserver vorgegeben wird, wird der in der Suite eingegebene 'Anzeigename' ignoriert.
Möchten Sie, dass der Drucker als Standarddrucker eingerichtet wird, verwenden Sie als Anzeigename einfach @ .
Da Drucker als Netzlaufwerke behandelt werden, können diese ebenso über die Weboberfläche vorangelegt werden und müssen dann nur noch einer Veranstaltung hinzugefügt werden. Einfacher ist es fast nicht möglich :).
LDAP-Filter
Immer wieder gibt es den Wunsch, Veranstaltungen auf bestimmte Nutzergruppen einzuschränken. Dies ist nun mit Hilfe simpler Attribut-Wert-Filter für LDAP bzw AD möglich. Über die Weboberfläche kann ein Administrator beliebige Filter vordefinieren. Das Attribut muss natürlich im AD bzw. LDAP vorhanden sein. Meist wird man wahrscheinlich auf irgendwelche Gruppen, z.B. 'memberOf', filtern wollen.
Innerhalb der bwLehrpool-Suite können Dozierende diese Filter anschließend per Klick auswählen und ihrer Veranstaltung hinzufügen. Falls Dozierende selbst Kenntnis über vorhandene LDAP-Attribute haben, können sie natürlich zusätzlich auch eigene Filter direkt in der Suite einstellen. Beispielsweise lässt sich eine Veranstaltung leicht auf Mitarbeiter beschränken, um z.B. eine Prüfungs-VM testen zu könnnen, ohne dass Studierende Zugriff erhalten. Falls Ihr LDAP Informationen über den Studiengang enthält, wäre auch dafür eine Filterung möglich.
Da Attribut und Wert beliebig setzbar sind, ergeben sich dadurch extrem viele Möglichkeiten zur Filterung von Veranstaltungen.
Startskripte
Die Startskripte erfreuen sich immer größerer Beliebtheit, da damit kleine Aufgaben innerhalb der VM ausgeführt werden können, ohne die VM selbst erst bearbeiten und neu hochladen zu müssen. Das kann z.B. ein Autostart von Firefox mit spezifischer URL sein.
Es gibt jedoch auch Aufgaben, die zentral von einem Administrator angelegt werden sollen. Dies ist mit der neuen Version ebenfalls über die Weboberfläche möglich. Die angelegten Skripte können dann wieder innerhalb der bwLehrpool-Suite einer Veranstaltung hinzugefügt werden, ohne dass sich Dozierende mit Internas beschäftigen müssen.
Außerdem lässt sich festlegen, ob das Skript normal sichtbar, minimiert oder versteckt ausgeführt werden soll. Das sollte nicht dazu genutzt werden, um etwas vor Anwendern aktiv zu verstecken, da die Skripte im Plaintext in der virtuellen Diskette abgelegt und somit auch für Nutzer der VM einsehbar sind. Es kann aber durchaus helfen, unnötige Irritationen und unschön aufpoppende Skriptfenster zu vermeiden.
Innerhalb der Suite finden Sie im Reiter 'VM-Start' einer Veranstaltung den Button 'Vordefinierte Skripte'. Wählen Sie einfach die gewünschten Skripte aus und klicken auf 'Speichern'. Da derzeit der Inhalt der vordefinierten Skripte in der bwLehrpool-Suite nicht angezeigt wird, ist eine sinnvolle Bennenung der Skripte besonders wichtig.
Audioausgabe
Die Soundausgabe innerhalb bwLehpool gebooteter VMs wird durch die openslx.exe bzw. Linux-Skripte bisher beim Booten stummgeschaltet. Es ist in der Regel ziemlich störend und daher unerwünscht, dass beispielsweise die bekannte Anmeldemelodie von Windows oder Ubuntu abläuft oder sonstige Dialogtöne oder Ähnliches ertönen. Es gibt jedoch Fälle, in denen sich Dozierende wünschen, dass standardmäßig die Audioausgabe aktiviert ist. Das kann bei E-Prüfungen mit Videos der Fall sein, bei denen Kopfhörer verwendet werden. Natürlich kann die Audioausgabe jederzeit nachträglich innerhalb der VM aktiviert werden, jedoch kann das einzelne Studierende unter zusätzlichen Stress stellen.
Zu diesem Zweck kann ein Administrator über die Konfigurationsvariable 'SLX_VM_SOUND' das Standardverhalten (auch pro Raum) festlegen. Zusätzlich kann innerhalb der bwLehrpool-Suite pro Veranstaltung definiert werden, ob der Sound beim Start der VM aktiviert/deaktiviert sein soll oder die Standardeinstellung des Administrators gilt.
Netzwerkregeln
Auch Netzwerkregeln lassen sich schnell und einfach über die Weboberfläche anlegen und innerhalb der bwLehrpool-Suite per Klick hinzufügen. Das sollte es deutlich vereinfachen, auch komplexere Regeln umzusetzen und Nachfragen nach Serveradressen oder den Ports des verwendeten Lizenzservers zu vermeiden. Beispielsweise reicht es häufig nicht aus, nur die eigentliche Lernplattform freizugeben, sondern es müssen auch notwendige externe Dienste wie CDN oder weitere vertrauenswürdige Server die Inhalte bereitstellen. Da Dozierende davon häufig keine Kenntnis haben, kommt es immer wieder zu Problemen und unnötigen Nachfragen.
USB3
Bisher wurden hochgeladene VMs automatisch auf USB2 konfiguriert, da bei USB3 diverse Probleme auftreten konnten. Diese konnten nun nicht mehr reproduziert werden, weswegen diese Restriktion ab sofort wegfällt. Wird eine VM lokal mit USB3 konfiguriert und mittels bwLehrpool-Suite hochgeladen, so wird die VM auch im Poolraum mit USB3 starten. Bereits hochgeladene VMs können auch innerhalb der Suite angepasst und auf USB3 umgestellt werden (VMX bearbeiten).
Beachten Sie jedoch, dass nicht alle Rechner auch tatsächlich USB3 Ports zur Verfügung stellen.
iPXE
Die tiefgreifendste Änderung ist der Wechsel von PXE zu iPXE. Um genau zu sein: iPXE wird bereits seit längerem intern genutzt. Nun wurden aber auch die letzten Reste des alten Ansatzes entfernt.
Für bwLehrpool ergeben sich dadurch vor allem drei große Vorteile:
- Unterstützung reinen UEFI-Boots (sprich Rechner, die kein Legacy-PXE mehr unterstützen, wie z.B. der neueste bwPC)
- Bootmenüs können einfach über die Weboberfläche verwaltet und zusammengefügt werden
- Bootmenüs und die Standardbootoption können zusätzlich pro Raum überschrieben werden
Beim Update werden Sie gefragt, ob Sie auf den neuen iPXE Ansatz wechseln wollen oder noch beim alten PXE bleiben wollen. Sie können auch nachträglich noch wechseln - dies erfordert jedoch ein wenig Handarbeit. Lesen Sie sich vor dem Update daher bitte unbedingt den entsprechenden Wiki-Artikel zur Umstellung auf iPXE durch.
Client-Statistiken
Neustart/Herunterfahren
- Rechner können über die Client-Liste bzw. über die Detailansicht neugestartet oder heruntergefahren werden
- Reboot Control wandert in den Menüpunkt 'Weiteres'
Seit einiger Zeit gibt es das Modul 'Reboot Control', mit dem Sie Clients herunterfahren oder neustarten können. Dieses wandert in der Weboberfläche aus dem Bereich 'Beta' in den Bereich 'Weiteres'.
Zusätzlich können Sie diese Funktion nun direkt über die Client-Statistiken auswählen, entweder in der Detailansicht eines Clients oder für mehrere Rechner gleichzeitig per Listenansicht. Damit können Sie ganz einfach die bekannte Filterung verwenden und eine große Anzahl von Rechnern ansteuern.
Bei der Option 'Neustarten' können Sie einen ganz normalen Neustart auslösen oder einen 'Schnellen Reboot direkt in bwLehrpool'. Bei letzterem wird der DHCP umgangen und bwLehrpool direkt wieder gestartet. Das kann hilfreich sein, wenn Ihr Bootmenü sonst per Default ein lokales System starten würde und Sie nicht mehr, z.B. über SSH, zugreifen könnten.
Raumplan
Der Raumplan ist eine hübsche Möglichkeit, die räumliche Anordnung der Rechner in einem Raum zu visualisieren. Bisher werden diese Informationen von Infoscreen und PVS-Manager verwendet.
Nun kommen zwei weitere Bereiche hinzu:
- Der Erste ist als Hilfe für Sat-Admins gedacht. In der Detailansicht eines Clients, den Sie über die 'Client-Statistiken' auswählen, wird eine Voransicht des Raums gezeigt. Der ausgewählte Rechner ist farblich markiert. Mit einem Klick gelangen Sie direkt zum eigentlichen Raumplan.
- Der zweite Bereich ist ein rein optisches Gimmick: In der Anmeldesmaske eines bwLehrpool-Clients wird der Raumplan im Miniaturformat angezeigt. Dabei wird der Plan entsprechend der Ausrichtung des Rechnersymbols im Raumplan automatisch gedreht (vergleichen Sie die beiden Screenshots der Admin-Weboberfläche und Client-Loginmaske). Der verwendete Rechner ist farblich hervorgehoben. Dadurch lässt sich schnell und einfach die Anordnung der Rechner im Raumplan mit den realen Gegebenheiten abgleichen.
BIOS-Version
In der Detailansicht der Client-Statistiken finden Sie nun zusätzliche Informationen zur installierten BIOS-Version, Revision (in Klammern) sowie deren Veröffentlichungsdatum. Die Daten werden mittels dmidecode ermittelt.
Falls Sie Hardware einsetzen, die mit einer bestimmten Version Probleme mit bwLehrpool hat und diese mit einem aktualisierten BIOS nicht mehr auftauchen, geben Sie uns bitte Bescheid. Wir können diese Information dann nutzen um auch andere Anwender darüber zu informieren.
Client-Log
Falls Sie in den letzten Tagen bereits das neue MiniLinux 22 mit dem alten Satellitenserver verwendet haben, sind Ihnen wahrscheinlich bereits folgende drei Fehler/Warnungen aufgefallen:
- [root] Xreset: Could not source /etc/X11/Xreset.d/vmware.
- [$USER] Downloading MetaData failed
- [$USER] Could not add $USER to group 'fuse'
Diese sind unkritisch und teilweise Vorarbeiten im MiniLinux für die neue Sat-Version geschuldet. Sobald Sie den Satellitenserver aktualisiert haben, sollten diese Fehler nicht mehr auftauchen.
Clients melden ihren Status regelmäßig an den Satellitenserver (z.B. „idle“ oder „occupied“). Dazu gibt es neue Loggingeinträge im Client-Log, wenn sich ein Client plötzlich in einem anderen Zustand, als die letzte Zustandsmeldung erwarten lässt, meldet.
type = machine-mismatch-cron | Client timed out, last known state is IDLE. RAM: 2.61 GiB, Swap: 1.68 GiB, ID44: 0 MiB |
type= machine-mismatch-poweron | Poweron event, but previous known state is IDLE. RAM: 2.87 GiB, Swap: 23.1 GiB, ID44: 129 GiB |
Um den Anforderungen der DSGVO zu entsprechen können Sie nun einfach alle zu einem Nutzer gespeicherten Daten exportieren.
Infoscreen
Die Infoscreens erfreuen sich wachsender Beliebheit und werden immer häufiger zur Information in Eingangsbereichen, als Türschild oder als Rechercheterminal z.B. in Bibliotheken (Kiosk) verwendet. Da sich die Funktion bewährt hat, wandert der entsprechende Menüpunkt daher aus dem Bereich 'Beta' nach oben, in den Bereich 'Inhalt'.
Manchmal werden Rechner über die IP-Range einem angelegten Raum/Ort zugeordnet, obwohl diese physisch gar nicht in diesem Raum stehen. Das passiert z.B. bei Test-/Ersatzrechnern, die nicht im Poolraum, sondern im Rechenzentrum stehen. Dadurch stimmt die Zählung der freien/belegten Rechner im Infoscreen jedoch nicht mehr.
Für das Standard- und Übersichts-Panel gibt es daher die neue Option 'Rechner zählen'. Sie können zwischen Zählung per Raumplaner oder IP-Range wählen. Wenn 'über Raumplaner' ausgewählt ist, werden nur Rechner gezählt, die tatsächlich in dem Plan gesetzt wurden. Über IP-Range werden alle (in der Satellitenserver-Datenbank enthaltenen) Rechner, die in den Adressbereich des Raumes fallen berücksichtigt.
"Kein Homverzeichnis gefunden"-Warnung
Wenn in Windows-VMs das Homeverzeichnis des angemeldeten Nutzers nicht eingebunden werden konnte, poppt bisher immer eine Warnmeldung auf. Diese ist vor allem dazu gedacht die Nutzer zu sensibilisieren, dass alle Daten nach einem Neustart verloren sind, wenn diese nicht extern gespeichert wurden.
Falls Sie die Meldung stört, können Sie das Verhalten über das LDAP/AD-Modul beeinflussen, in dem Sie die entsprechende Einstellung auf „Niemals warnen“ ändern.
Diese Einstellung gilt derzeit jedoch nicht für den 'demo'-User. Wird dieser zur Anmeldung verwendet, taucht die Meldung nach wie vor auf.
News/Hilfe
Zusätzlich zu den News und Hilfetexten, die im vmChooser angezeigt werden, kann nun auch ein separater Text angelegt werden, der bereits auf der Loginmaske erscheint. Das können beispielsweise Hinweise sein, die unabhängig vom Login oder besonders wichtig sind, da die Textboxen im vmChooser ausgeblendet oder einfacher übersehen werden können.
Außerdem lassen sich Texte nun mit einem Ablaufdatum versehen. So können Sie beispielsweise temporäre Infomationen anzeigen. Nach Ablauf wird automatisch auf die letzt gültige News/Hilfe zurückumgestellt.
~~DISCUSSION~~