Im Rahmen von sogenannten Sprints, wichtiger Bestandteil der agilen Entwicklungsmethode „Scrum“, veröffentlicht das UCS@school-Team in zweiwöchentlichem Turnus regelmäßig Aktualisierungen für UCS@school, die Sie per Update für Ihre bestehende UCS@school Umgebung einspielen können.
Neben der finalen Implementierung von Veyon als neues Computerraum-Modul Backend wird mit dem neuen „Consistency Check“ Diagnosemodul eine Funktion eingeführt, die einen weiteren Baustein des reibungslosen Betriebs ihrer UCS@school-Umgebung darstellt. Die Features und Fixes rund um UCS@school Version 4.4 v9 und einen kleinen Ausblick auf die gerade in der Produktentwicklung anstehenden Themen stelle ich Ihnen in diesem Artikel vor.
Veyon-Umstellung
Mit dem Release UCS@school 4.4 v9 wurden die Vorbereitungen für die Umstellung auf das neue Computerraum-Modul Backend „Veyon“ abgeschlossen, das die nicht mehr weiterentwickelte Lösung iTALC ablöst. Details dazu finden sich im entsprechenden, noch folgenden Blogartikel. Ebenfalls existiert ein Artikel im help-Forum für die Migration existierender iTALC-Räume auf das neue Veyon-Backend.
Um eine reibungslose Migration zu ermöglichen, wird ein Mischbetrieb aus iTALC und Veyon-Räumen bis zum Release von UCS@school 5.0, das für Anfang August geplant ist, möglich sein. Nach diesem Upgrade wird es nicht mehr möglich sein, iTALC als Backend für das Computerraum-Modul einzurichten.
Diagnosemodul UCS@school Consistency Check
Ebenfalls frisch ins Produkt gekommen ist das neue Diagnosemodul „UCS@school Consistency Check“. Das Modul erweitert die für UCS@school 4.4 v8 bereits implementierte Protokollierung inkonsistenter Objekte in einem UCS@school LDAP-Verzeichnis. Das Logging dieser Inkonsistenzen ist über das Setzen der UCR-Variable ucsschool/validation/logging/enabled ein- und abschaltbar.
Das Modul analysiert mithilfe verschiedener Skripte die Objekte im Verzeichnis und prüft diese auf Vollständigkeit und Korrektheit. Inkonsistenzen und Warnungen, die bei dieser Prüfung aufgezeigt werden, führen nicht zwangsläufig dazu, dass ein UCS@school-System nicht mehr benutzbar ist. Sie deuten viel eher auf potenzielle Probleme hin, die mit den aktuellen Objekten im Verzeichnis auftreten könnten. Beispiele für Inkonsistenzen, die das Modul aufdeckt, sind Benutzer, bei denen Gruppen, Container und/oder Rollen unvollständig oder logisch inkonsistent konfiguriert sind.
Es existieren dazu bereits verschiedene Artikel im help-Forum, die beschreiben, wie ein korrektes UCS@school-Benutzerobjekt aussieht, und was es mit group shares, work groups und Klassen im Speziellen auf sich hat:
