Werde Teil unseres Teams und sorge für mehr Digitale Souveränität!
- Teamleiter IT – Kundenprojekte (m/w/d)
- IT Consultant (m/w/d)
- Senior Backend / Software Developer Python (m/w/d)
- u.v.m.

Ein Schuljahreswechsel ist für viele Beteiligte in den Schulen und auch bei den Schulträgern ein sehr aufwendiger Prozess – zum neuen Schuljahr verlassen viele Schüler*innen eine Schule und ein neuer Jahrgang kommt hinzu. Dementsprechend viele Benutzerkonten für die Schüler*innen müssen gelöscht und ganz neue Konten müssen angelegt werden. Gleichzeitig wechseln die allermeisten Schüler*innen die Klassenstufe und benötigen neue Gruppenzugehörigkeiten und Berechtigungen. Um diese Aufwände für die beteiligten IT-Administratoren und das Verwaltungspersonal in den Schulen so gering wie möglich zu halten, versuchen wir, in UCS@school die dafür nötigen Prozesse so einfach wie möglich zu halten. Im folgenden möchte ich kurz darstellen, welche Möglichkeiten es gibt und zwei Varianten vorstellen, die beide ihre Vor- und Nachteile haben:
Das führende IT-System in dem gesamten Prozess sollte immer die Schulverwaltungssoftware sein. Nachdem dort alle für den Schuljahreswechsel nötigen Anpassungen durchgeführt wurden, exportieren Sie als Administrator aus dem System, wie gewohnt mit UCS@school, alle Daten der Benutzer*innen (Lehrpersonen, Schüler*innen und Mitarbeiter*innen) und importieren diese über den Import-Mechanismus in UCS@School bzw. das OpenLDAP-Verzeichnis, ganz genau wie Sie es unterjährig vermutlich auch machen.
Der Import-Mechanismus wird dann den Soll-Zustand auch in UCS@school abbilden: Ein Schüler ist jetzt in der 6a und nicht mehr in der 5a? Dann wird der Import-Mechanismus die Gruppenzugehörigkeit von 5a auf 6a ändern. Eine Schülerin hat ihre Schullaufbahn beendet und ist nicht mehr im Export der Schulverwaltungssoftware enthalten? Dann wird ihr Benutzerkonto je nach Konfiguration gelöscht oder deaktiviert.
Im Gegensatz zu einem „regulären“ Import sind es im Falle des Schuljahreswechsels einfach nur deutlich mehr Änderungen. Bis sich diese Menge an Änderungen auf alle UCS-Systeme repliziert hat, kann es eine Weile dauern, weswegen wir empfehlen, den Schuljahreswechsel noch in den Ferien oder am Abend oder am Wochenende durchzuführen, um den regulären Betrieb nicht zu beeinträchtigen.
Einen Stolperstein hat diese Methode: Die Klassenfreigaben werden bei diesem Vorgehen nicht umbenannt oder angepasst. Dadurch erhalten versetzte Schüler*innen Zugriff auf die Klassenfreigabe ihres Vorgängerjahrgangs. Hier muss im Vorfeld abgeklärt werden, ob und durch wen die Inhalte der Klassenfreigabe umgezogen werden (bspw. von der Klassenfreigabe der 5a zur Klassenfreigabe der 6a) oder ob man die Sommerferien nicht gleich zum Aufräumen nutzt und die Inhalte des alten Jahrgangs in den Klassenfreigaben zu einem Stichtag löscht.
UCS@school bringt auch das Skript „/usr/share/ucs-school-import/scripts/rename_class“ mit, das optional zum Umbenennen der Klassen inkl. Klassenfreigaben genutzt werden kann. Damit umgeht man den Stolperstein von Variante 1, muss allerdings auch etwas mehr Aufwand betreiben. Der Ablauf ist wie folgt, die Reihenfolge muss dabei eingehalten werden:
gymmitte-6a gymmitte-7a
gymmitte-5a gymmitte-6a
Die 6a wird also zur 7a umbenannt, dann die 5a zur neuen 6a. Die Reihenfolge der Umbenennung ist wichtig, da die Umbenennung sequentiell erfolgt und der Zielname nicht existieren darf.
Die Änderungen an Benutzerkonten erfolgt anschließend wie unter Variante 1 beschrieben.
Mit dieser Variante können Klassen inkl. ihrer Klassenfreigaben mit den Jahrgangsstufen „umziehen“, jedoch steigt der Vorbereitungsaufwand je nach Schul- und Klassenanzahl schnell stark an.
Durch beide Varianten kann UCS@school deutlich die Aufwände verringern, die bei den Anpassungen der Identitäten, Gruppenzugehörigkeiten und Zugriffsrechten zum Schuljahreswechsel entstehen.
Hinterlassen Sie gerne einen Kommentar, wenn Sie Fragen oder Anregungen zu dem Thema haben.
Open Source Software Consultant im Professional Service Team bei Univention.