In einer Standard-UCS-Installation sind alle Benutzerkonten vom selben Typ und unterscheiden sich nur anhand ihrer Gruppenmitgliedschaften. In einer UCS@school-Umgebung ist jeder Benutzer einer Rolle zugeordnet, aus der sich Berechtigungen in der UCS@school-Verwaltung ergeben:

Überschneidungen der Benutzertypen Lehrer, Mitarbeiter und Schuladministrator sind möglich. So können z.B. Benutzerkonten erstellt werden, die eine Nutzung des Kontos als Lehrer und Mitarbeiter ermöglichen.

Für die Pflege der Benutzerkonten stehen mehrere Möglichkeiten zur Verfügung. Die Bearbeitung von Benutzerkonten kann über die Univention Management Console erfolgen. Darüber hinaus bringt UCS@school flexible Importskripte mit. Sie lesen Tabulator-getrennte Importdateien oder CSV-Dateien ein, die üblicherweise aus vorhandenen Schulverwaltungssystemen extrahiert werden können und so einen automatisierten Abgleich ermöglichen.

Für den Betrieb von UCS@school an einer einzelnen Schule reicht ein Serversystem aus (dieses wird dann in der UCS-Systemrolle Domänencontroller Master installiert). Ein solches Szenario wird nachfolgend auch als Single-Server-Umgebung bezeichnet.

Für Schulträger oder große Schulen mit mehreren Standorten oder mit einer großen Anzahl an Clients, kann die UCS@school-Installation auf mehrere Server verteilt werden (Multi-Server-Umgebung). Dabei wird ein Domänencontroller Master als der primäre Server zur Datenverwaltung genutzt. Für jeden Schul-Standort wird dann ein Domänencontroller Slave installiert, nachfolgend als Schulserver bezeichnet.

Die Netze für den edukativen Bereich und für die Schulverwaltung müssen aus organisatorischen oder rechtlichen Gründen in der Regel logisch und/oder physikalisch getrennt werden. In UCS@school kann daher zusätzlich zur Unterteilung in Organisationseinheiten (OU) noch eine Unterteilung der OU in Verwaltungsnetz und Edukativnetz erfolgen.

Diese optionale Unterteilung findet auf Ebene der Serversysteme bzw. der Netzwerksegmente statt und sieht vor, dass in einer Schule ein Schulserver für das edukative Netz und ein Schulserver für das Verwaltungsnetz betrieben wird. Diese Server verwenden für ihre Client-Systeme (Schülerrechner bzw. Rechner der Verwaltung) jeweils ein eigenes IP-Subnetz.

Auch bei der Unterteilung in Verwaltungsnetz und Edukativnetz findet eine selektive Replikation statt, wie sie in Abschnitt 2.2.1 beschrieben wird. Zusätzlich wird jedoch bei der Replikation der Benutzerkonten anhand ihrer Benutzerrolle(n) unterschieden. Auf den Schulserver des edukativen Netzes werden die Benutzerkonten mit den Benutzerrollen Schüler, Lehrer, Schuladministrator und System-Administrator repliziert. Auf den Schulserver der Verwaltung werden die Benutzerkonten mit den Benutzerrollen Mitarbeiter, Schuladministrator und System-Administrator repliziert. Die gemeinsame Verwendung der Benutzerrollen Lehrer und Mitarbeiter für ein Benutzerkonto ist möglich, z.B. für Benutzerkonten der Schulleitung, die neben ihrer Verwaltungstätigkeit auch lehrend tätig sind.

UCS@school erstellt zur Verwaltung der schulspezifischen Erweiterungen zusätzliche Strukturen im LDAP-Verzeichnisdienst. Im Folgenden werden einige Funktionen dieser Container und Objekte genauer vorgestellt.

Wie bereits im Abschnitt 2.2.1 beschrieben wurde, wird für jede Schule direkt unterhalb der LDAP-Basis eine eigene Organisationseinheit (OU) angelegt. Unterhalb dieser OU werden Container für Benutzerobjekte, Gruppen und weitere UCS@school-relevante Objekte erstellt. Darüber hinaus werden einige neue Objekte in den bereits bestehenden UCS-Strukturen des LDAP-Verzeichnisses angelegt.

Das Konzept der Multi-Server-Umgebung von UCS@school sieht zentrale Server für Cloud-Dienste wie Portal, Mail, Kalender, Dateiablage usw. kombiniert mit lokalen Schulservern für Anmeldedienste, IT-Infrastruktur und pädagogischen Funktionen vor. Eine Übersicht an möglichen Szenarien wird im Dokument [ucs-school-scenario] dargestellt. Der Installationsprozess für die unterschiedlichen Rechnerrollen in der UCS@school-Domäne wird in den nachfolgenden Abschnitten genauer beschrieben.

§3.2.1. Installation des DC Master

Zunächst muss ein UCS System mit der Systemrolle Domänencontroller Master (kurz: DC Master) installiert werden. Die Installation ist im UCS-Handbuch[ucs-handbuch] beschrieben. Sofern der Domänencontroller Master als Active Directory-kompatibler Domänencontroller genutzt werden soll, so kann die Software bereits während der UCS-Installation ausgewählt werden.

Nach der erfolgreichen UCS-Installation muss die UCS@school App installiert werden. Jedes UCS System bietet ein webbasiertes Konfigurationsinterface an, Univention Management Console, kurz UMC. Dies ist via Webbrowser erreichbar, dazu kann einfach der Name oder die IP-Adresse des Servers in die Adresszeile des Webbrowsers eingegeben werden. Es erscheint eine Kachel mit der Bezeichnung System- und Domäneneinstellungen. Nach einem Klick auf die Kachel wird eine Anmeldemaske angezeigt. Dort erfolgt die Anmeldung mit dem Benutzer Administrator und dem während der UCS-Installation vergebenen Passwort für den Benutzer root.

Nun kann die Kachel App Center geöffnet und dort die Applikation UCS@school installiert werden. Für die Installation ist den Anweisungen zu folgen, bspw. kann eine Lizenzaktivierung notwendig sein. Details dazu sind im UCS-Handbuch[ucs-handbuch] zu finden.

§

Abbildung 3.5. Installation von UCS@school über das Univention App Center

Nach dem Abschluss der Installation über das App Center erfolgt die Konfiguration von UCS@school. Diese wird mit dem UCS@school-Konfigurationsassistenten durchgeführt. Dieser ist in UMC über den Bereich Schul-Administration erreichbar.

§

Abbildung 3.6. Starten des UCS@school-Konfigurationsassistenten

Auf der ersten Seite fragt der Konfigurationsassistent nach dem Installationsszenario. Hier ist die Multi-Server-Umgebung auszuwählen.

§

Abbildung 3.7. Multi-Server-Umgebung

Nach der abschließenden Bestätigung startet die Konfiguration von UCS@school. Dabei werden diverse Pakete installiert und konfiguriert. Die Dauer schwankt je nach Internetgeschwindigkeit und Serverausstattung.

Installation und Konfiguration von UCS@school sollten mit einem Neustart des Systems abgeschlossen werden.

Achtung

Nach Abschluss der Installation auf dem Domänencontroller Master sollte auf allen anderen gejointen Systemen der Domäne der Befehl univention-run-join-scripts ausgeführt werden, damit der installierte UCS@school-Join-Hook benötigte Konfigurationspakete auf den Systemen nachinstallieren kann. Dieser Vorgang kann je nach Rolle und Systemperformance mehrere Minuten dauern und darf nicht unterbrochen werden.

UCS@school-Umgebungen, die als Single-Server-Umgebung installiert/eingerichtet wurden, können bei Bedarf nachträglich in eine Multi-Server-Umgebung umgewandelt werden. Die Umwandlung ermöglicht die Aufnahme von Schulservern in die Domäne.

Für die Umwandlung sind einige Befehle auf der Kommandozeile des DC Masters auszuführen, die einen Austausch des UCS@school-Metapakets sowie eine Konfigurationsänderung durchführen (Bitte das Minuszeichen hinter dem zweiten Paketnamen am Ende der ersten Zeile beachten!):

univention-install ucs-school-master ucs-school-singlemaster-
ucr unset ucsschool/singlemaster

Durch die beiden Befehle wird das Meta-Paket ucs-school-singlemaster deinstalliert und im gleichen Zug das Paket ucs-school-master installiert. Mit der Deinstallation des Pakets ucs-school-singlemaster werden die nachfolgenden UCS@school-spezifischen Pakete (z.B. UMC-Module), die normalerweise nicht auf einem DC Master der Multi-Server-Umgebung installiert sind, automatisch zur Löschung vorgesehen. Die eigentliche Löschung der betroffenen Pakete findet während des nächsten Updates oder durch den manuellen Aufruf von apt-get autoremove statt. Dabei ist zu beachten, dass neben den genannten Paketen ggf. auch ungenutzte Paketabhängigkeiten entfernt werden.

ucs-school-branding
ucs-school-umc-computerroom
ucs-school-umc-distribution
ucs-school-umc-exam
ucs-school-umc-helpdesk
ucs-school-umc-internetrules
ucs-school-umc-lessontimes
ucs-school-umc-printermoderation
ucs-school-netlogon
ucs-school-netlogon-user-logonscripts
ucs-school-old-homedirs
ucs-school-old-sharedirs
ucs-school-webproxy
univention-squid-kerberos

Um die Löschung einzelner Pakete zu vermeiden, kann der folgende Befehl verwendet werden, bei dem PAKETNAME durch den gewünschten Paketnamen auszutauschen ist:

apt-get unmarkautoPAKETNAME

Richtlinien, die (ggf. automatisch von UCS@school) an Container der Schul-OUs verknüpft wurden, sollten auf ihre Einstellungen hin überprüft werden. Dies betrifft unter anderem die DHCP-DNS-Einstellungen.

Nachdem die oben genannten Schritte ausgeführt wurden, sollte abschließend der UMC-Server auf dem DC Master neu gestartet werden:

service univention-management-console-server restart

Um die Self-Service App in einer UCS@school-Umgebung einzusetzen, wird empfohlen das Paket ucs-school-selfservice-support auf dem Domänencontroller Master und den Domänencontroller Backup zu installieren. Dies sorgt automatisch dafür, dass den Benutzern aller Schulen, die in den Gruppen Domain Users OUNAME Mitglied sind, die Benutzung des Self-Service Moduls erlaubt wird. Es wird automatisch die UCR-Variable umc/self-service/passwordreset/whitelist/groups beim Erstellen von neuen Schul-OUs aktuell gehalten.

Die Installation wird folgendermaßen durchgeführt:

univention-install ucs-school-selfservice-support

Die Daten einer Schule werden in einer Organisationseinheit (OU) - einem Teilbaum des LDAP-Verzeichnisdienstes - gespeichert (siehe auch Kapitel 2). Die Verwaltung der logischen Einheit Schule kann in der Univention Management Console über das Modul Schulen erfolgen, welches sich in der Modulgruppe Schul-Administration befindet. Es ermöglicht das Suchen nach, sowie das Anlegen, Bearbeiten und Löschen von Schulen in der UCS@school-Umgebung. Bevor ein neuer Schulserver der UCS@school-Domäne beitreten kann, muss die dazugehörige Schule angelegt werden.

cd /usr/share/ucs-school-import/scripts/
./create_ou gsmitte dcgymmitte admgymmitte

Für die manuelle Pflege von einzelnen Benutzerkonten wird auf dem Domänencontroller Master das UMC-Modul Benutzer (Schulen) bereitgestellt, welches sich in der UMC-Modulgruppe Schul-Administration befindet. Es ermöglicht das Suchen nach, sowie das Anlegen, Bearbeiten und Löschen von Schülern, Lehrern und Mitarbeitern in der UCS@school-Umgebung.

Auf dem Domaincontroller Master kann das Anlegen und Entfernen von Schulklassen über das UMC-Modul Klassen (Schulen) erfolgen. Das Anlegen einer Schulklasse ist erforderlich, bevor das erste Schüler-Benutzerkonto erstellt werden kann. Die eigentliche Zuordnung von Schülern zu einer Klasse erfolgt über das UMC-Modul Benutzer (Schulen) am Schüler-Benutzerobjekt oder während des CSV-Imports. Die Zuordnung von Lehrern zu Klassen erfolgt über das UMC-Modul Lehrer Klassen zuordnen.

Für die Anbindung von Arbeitsplatzrechnern in Form von z.B. Windows-Rechnern werden im Verzeichnisdienst Rechnerkonten benötigt. Rechnerkonten werden z.B. von Windows-Rechnern automatisch beim Domänenbeitritt angelegt. Sie können aber auch vor dem Domänenbeitritt manuell über das UMC-Modul Rechner (Schulen) eingepflegt werden. Dies ist unter anderem für IP-Managed-Clients wie z.B. Netzwerkdrucker notwendig.

Das Anlegen der Rechnerkonten vor der Inbetriebnahme bringt den Vorteil, dass z.B. die für DHCP notwendigen Informationen wie IP- und MAC-Adresse schon hinterlegt sind.

Die UCS@school Kelvin REST API App installiert eine REST Schnittstelle zur Verwaltung von UCS@school-Objekten wie zum Beispiel Schulen, Rollen, Klassen und Benutzern. Die Objekte können über die Schnittstelle gelesen und abgefragt, verändert und gelöscht werden. Die Schnittstelle dient dazu, den Verzeichnisdienst in UCS@school per Netzwerkschnittstelle anzusprechen, zum Beispiel von einer Schulverwaltungssoftware oder einem Bildungsangebot.

Weitere Informationen finden sich in der Entwicklerdokumentation der Schnittstelle .

Für UCS@school gibt es momentan mehrere Möglichkeiten Nutzer in das System zu importieren.

Die Konfiguration des kommandozeilenbasierten Benutzerimports ist im Handbuch Import Schnittstelle dokumentiert.

Die Dokumentation des alten Nutzerimports, welcher zuvor an dieser Stelle erläutert worden ist, wurde nach UCS@school Legacy Import ausgelagert. Von seiner Verwendung wird abgeraten, da er vom neuen Benutzer-Import abgelöst wird.

Beim Import schon Schulklassen ist zu beachten, dass die Klassennamen domänenweit eindeutig sein müssen. Das heißt, eine Klasse 1A kann nicht in mehreren OUs verwendet werden. Daher sollte jedem Klassennamen die OU und ein Bindestrich vorangestellt werden. Bei der Erstellung von Klassen über das UMC-Modul Klassen (Schulen) geschieht dies automatisch. Sprechende Namen, wie zum Beispiel Igel oder BiologieAG, sind für Klassennamen ebenso möglich wie Buchstaben-Ziffern-Kombinationen (10R). Beispiele für die Schule gym123:

gym123-1A
gym123-1B
gym123-2A
gym123-Igel

Der Import von Benutzern erfolgt über das Skript /usr/share/ucs-school-import/scripts/import_group, das auf dem Domänencontroller Master als Benutzer root gestartet werden muss. Es erwartet den Namen einer CSV-Datei als ersten Parameter. Das Dateiformat für die Gruppen-Importdatei ist wie folgt aufgebaut:

Ein Beispiel für eine Importdatei:

A	  g123m		g123m-1A		 Klaaassen 1A
A	  g123m		g123m-LK-Inf	 Leistungskurs Informatik
M	  g123m		g123m-1A		 Klasse 1A
D	  g123m		g123m-LK-Inf	 Leistungskurs Informatik
D	  g123m		g123m-R12		 Klasse R12

Zum Schuljahreswechsel stehen zahlreiche Änderungen in den Benutzerdaten an: Schüler werden in eine höhere Klasse versetzt, der Abschlussjahrgang verlässt die Schule und ein neuer Jahrgang wird eingeschult.

Ein Schuljahreswechsel erfolgt in vier Schritten:

Durch den Import von Netzwerken können IP-Subnetze im LDAP angelegt werden und diverse Voreinstellungen wie Adressen von Router, DNS-Server etc. für diese Subnetze konfiguriert werden. Darunter fällt z.B. auch ein Adressbereich aus dem für neuangelegte Systeme automatisch IP-Adressen vergeben werden können.

Das Importieren von Subnetzen empfiehlt sich in größeren UCS@school-Umgebungen. Kleinere Umgebungen können diesen Schritt häufig überspringen, da fehlende Netzwerke beim Import von Rechnerkonten automatisch angelegt werden.

Netzwerke können derzeit nur auf der Kommandozeile über das Skript /usr/share/ucs-school-import/scripts/import_networks importiert werden. Das Skript muss auf dem Domänencontroller Master als Benutzer root aufgerufen werden. In der Import-Datei sind die einzelnen Felder durch ein Tabulatorzeichen zu trennen. Das Format der Import-Datei ist wie folgt aufgebaut:

Beispiel für eine Importdatei:

g123m  10.0.5.0                          10.0.5.1  10.0.5.2  10.0.5.2
g123m  10.0.6.0/25  10.0.6.5-10.0.6.120  10.0.6.1  10.0.6.2  10.0.6.15

Wird für das Feld Netzwerk keine Netzmaske angegeben, so wird automatisch die Netzmaske 255.255.255.0 verwendet. Sollte der IP-Adressbereich nicht explizit angegeben worden sein, wird der Bereich X.Y.Z.20-X.Y.Z.250 verwendet.

Zur Vereinfachung der Administration der Netzwerke steht zusätzlich das Skript import_router zur Verfügung, das nur den Default-Router für das angegebene Netzwerk neu setzt. Es verwendet das gleiche Format wie import_networks.

Rechnerkonten können entweder einzeln über ein spezielles UMC-Modul oder über ein spezielles Import-Skript als Massenimport angelegt werden. Die Rechnerkonten sollten vor dem Domänenbeitritt von z.B. Windows-PCs angelegt werden, da so sichergestellt wird, dass die für den Betrieb von UCS@school notwendigen Informationen im LDAP-Verzeichnis vorhanden sind und die Objekte an der korrekten Position im LDAP-Verzeichnis abgelegt wurden.

Nach dem Anlegen der Rechnerkonten können Windows-PCs über den im UCS-Handbuch beschriebenen Weg der Domäne beitreten.

ipmanagedclient  routerg123m-01   10:00:ee:ff:cc:02  g123m  10.0.5.1
windows          wing123m-01      10:00:ee:ff:cc:00  g123m  10.0.5.5
windows          wing123m-02      10:00:ee:ff:cc:01  g123m  10.0.5.6
macos            macg123m-01      10:00:ee:ff:cc:03  g123m  10.0.5.7
ipmanagedclient  printerg123m-01  10:00:ee:ff:cc:04  g123m  10.0.5.250

Der Import der Drucker kann skriptbasiert über das Skript /usr/share/ucs-school-import/scripts/import_printer erfolgen, das auf dem Domänencontroller Master als Benutzer root aufgerufen werden muss. Es erwartet den Namen einer CSV-Datei als ersten Parameter, die in folgender Syntax definiert wird. Die einzelnen Felder sind durch ein Tabulatorzeichen zu trennen.

Die Druckerwarteschlange wird beim Anlegen eines neuen Druckers auf dem im Feld Druckserver angegebenen Druckserver eingerichtet. Das URI-Format unterscheidet sich je nach angebundenem Drucker und ist im Druckdienste-Kapitel des UCS-Handbuchs beschrieben.

Um unnötige oder fehlerhafte Druckaufträge zu minimieren, bietet UCS@school den Lehrern die Möglichkeit, Druckaufträge zu moderieren. Dafür werden die Druckaufträge zunächst über einen speziellen PDF-Drucker (Druckerfreigabe PDFDrucker) auf dem Schüler-/Lehrerrechner gedruckt und anschließend durch den Lehrer im UMC-Modul Drucker moderieren betrachtet, verworfen oder für den Druck freigegeben.

In UCS@school gibt es vielfältige Möglichkeiten, die Druckmoderation zu konfigurieren und einzusetzen. Nachfolgend wird die Einrichtung eines einzelnen Szenarios beschrieben, welches leicht an die Bedürfnisse der eigenen Schulumgebung angepasst werden kann. In dem beschriebenen Szenario wird der Zugriff auf die physikalischen Drucker für alle Schüler gesperrt.

Für die Druckmoderation ist es erforderlich, dass zunächst wie in Abschnitt 5.6 beschrieben, Druckfreigaben für die zu verwendenden, physikalisch existierenden Drucker angelegt werden.

An den Druckerfreigabeobjekten (UMC-Modul Drucker) können spezielle Zugriffsrechte gesetzt werden. Dabei kann der Zugriff für einzelne Benutzer oder ganze Gruppen erlaubt bzw. gesperrt werden. Um den Schülern den Zugriff auf die physikalischen Drucker zu verbieten, muss an den Druckerfreigaben für diese Drucker der Zugriff durch Benutzer der OU-spezifischen Gruppe schueler-OU (z.B. schueler-gsmitte) verboten werden. Für den PDF-Drucker PDFDrucker sollten keine Einschränkungen gemacht werden.

Schüler haben damit nur noch die Möglichkeit Druckaufträge an den PDFDrucker zu senden. Im UMC-Modul Drucker moderieren können die Druckaufträge anschließend durch den Lehrer aufgelistet und in Form einer PDF-Datei betrachtet werden. Dafür ist ein geeignetes Programm zur Anzeige von PDF-Dateien auf den Lehrerrechnern erforderlich. Die Druckaufträge können dann durch den Lehrer an einen beliebigen physikalischen Drucker der Schule weitergeleitet oder auch verworfen werden.

Lehrer können in dem UMC-Modul grundsätzlich nur die Druckaufträge der Schüler oder ihre eigenen Druckaufträge betrachten. Druckaufträge von anderen Lehrern werden von dem UMC-Modul nicht angezeigt.

Um Ausnahmen von dieser strikte Regelung zu ermöglichen, kann der Lehrer im UMC-Modul Computerraum über den Punkt Einstellungen ändern den Druckmodus für einen einzelnen Computerraum beeinflussen. Die oben beschriebenen Einschränkungen für Schüler werden dabei als Standard (globale Einstellungen) beschrieben. Darüber hinaus kann auch der Druckmodus Drucken deaktiviert ausgewählt werden, der das Drucken von den Rechnern des Computerraums vollständig untersagt.

Neben den in Abschnitt 4.2 und Abschnitt 5.1 genannten Attributen für Benutzer werden beim Anlegen eines Benutzers auch automatisch einige Windows-spezifische Einstellungen vorgenommen:

Die meisten Freigaben in einer UCS@school-Umgebung werden automatisch erstellt; jede Klasse oder Arbeitsgemeinschaft verfügt über eine gemeinsame Freigabe. Weiterhin existiert mit der Marktplatz-Freigabe je Schule eine schulweite Freigabe. Das Erstellen der Marktplatzfreigabe beim Anlegen einer OU kann durch das Setzen der Univention Configuration Registry-Variable ucsschool/import/generate/marktplatz auf den Wert no verhindert werden.

Diese Freigaben müssen zwingend auf dem Schulserver bereitgestellt werden, um die von UCS@school bereitgestellten Funktionen nutzen zu können.

Weitere Freigaben werden, wie in einer Standard-UCS-Installation, über das UMC-Modul Freigaben auf dem Domänencontroller Master angelegt. Weiterführende Dokumentation findet sich im Freigaben-Kapitel des UCS-Handbuchs[ucs-handbuch].

Die Freigaben müssen unterhalb der OU der Schule angelegt werden. Die Auswahl findet mit der Option Container beim Anlegen einer Freigabe statt. Für die OU gym17 muss beispielsweise der Container gym17/shares ausgewählt werden.

Lehrern kann der Zugriff auf alle Heimatverzeichnisse von Schülern an einer Schule freigeschaltet werden. Dies geschieht durch Installation des Pakets ucs-school-roleshares auf dem jeweiligen Schulserver. Der Zugriff kann dann über eine spezielle Dateifreigabe erfolgen.

Das Paket installiert das Skript /usr/share/ucs-school-import/scripts/create_roleshares, welches über das Joinskript automatisch aufgerufen wird und später auch manuell aufgerufen werden kann. Mit der Standardoption --create student aufgerufen, legt es für alle Dateiserver des Schulstandorts jeweils eine Freigabe mit dem Namensschema schueler-<OU> an. Die Freigabe erlaubt der Gruppe lehrer-<OU> den administrativen Zugriff auf das Basisverzeichnis /home/<OU>/schueler.

Per Voreinstellung wird der Lehrergruppe Lesezugriff gewährt. Die Freigabe wird vom jeweiligen Dateiserver nicht explizit angezeigt. Eine an einem Windows-Arbeitsplatz angemeldete Lehrkraft sollte automatisch eine Verknüpfung zu dieser Freigabe angezeigt bekommen.

Die Freigabe-Einstellungen dieser Freigabe können wie üblich über die Univention Management Console auf dem Domänencontroller Master angepasst werden, z.B. um Lehrern auch Schreibzugriff zu gewähren.

Voraussetzung für diese Funktion ist, dass die Heimatverzeichnisse der Benutzerkonten in entsprechend strukturierten Unterverzeichnissen angelegt wurden. Dies geschieht in Domänen die mit UCS@school 3.2 R2 oder später installiert wurden automatisch. In älteren Umgebungen wird dies dadurch verhindert, dass dort Univention Configuration Registry-Variable ucsschool/import/roleshare automatisch auf no gesetzt wurde. Dies gewährleistet eine einheitliche Anlage der Heimatverzeichnisse und sollte erst nach einer manuellen Migration der Heimatverzeichnisse geändert werden.

Ab UCS@school 4.4 v8 können Benutzerkonten für Schuladministratoren direkt über das UCS@school-UMC-Modul angelegt werden. Diese Option ist standardmäßig abgeschaltet. Um das Verhalten zu aktivieren, muss schoolAdmin aus der Univention Configuration Registry-Variable ucsschool/wizards/schoolwizards/users/roles/disabled entfernt werden. Schuladministratoren, die mit dem UCS@school-UMC-Modul erstellt werden, besitzen nicht die Option UCS@school-Lehrer und befinden sich nicht in der Gruppe lehrer-OU.

Benutzerkonten von Lehrern können durch eine zusätzliche Gruppenmitgliedschaft und das Einschalten einer Option zu Schuladministratoren umgewandelt werden.

Fungiert das Benutzerkonto nicht mehr als Lehrer, sondern nur noch als Schuladministrator, so kann im Reiter Optionen die Option UCS@school-Lehrer deaktiviert und dem Benutzer die Gruppe lehrer-OU entzogen werden.

Soll ein Schuladministrator auch als Lehrer tätig sein, muss zusätzlich die Gruppe lehrer-OU, also z.B. lehrer-gym17, hinzugefügt werden. Abschließend müssen die Angaben für Profilpfad und Heimatverzeichnispfad am Benutzerobjekt gesetzt werden, um das gleiche Verhalten wie bei Schüler- und Lehrerkonten zu erhalten (siehe dazu auch Abschnitt 6.2).

Über das Helpdesk-Modul können Lehrer per E-Mail Kontakt zum Helpdesk-Team einer Schule aufnehmen. Damit dieses Modul genutzt werden kann, muss auf dem jeweiligen Server die Univention Configuration Registry-Variable ucsschool/helpdesk/recipient auf die E-Mail-Adresse des zuständigen Helpdesk-Teams gesetzt werden.

Im UMC-Modul Computerraum kann z.B. über die Funktion Beobachten eine verkleinerte Desktop-Ansicht der aufgelisteten Windows-Rechner angezeigt werden. Dabei ist es möglich, die Desktops bestimmter Benutzergruppen von dieser Anzeige auszuschließen. In der Standardkonfiguration ist dies die Gruppe Domain Admins.

Über die Univention Configuration Registry-Variable ucsschool/umc/computerroom/hide_screenshots/groups kann eine abweichende kommaseparierte Liste mit Gruppennamen konfiguriert werden, z.B. Domain Admins,Helpdesk. Da UCS@school für jede Schule für die dort agierenden Lehrer eine eigene Benutzergruppe anlegt, wurde zur Vereinfachung eine weitere Univention Configuration Registry-Variable ucsschool/umc/computerroom/hide_screenshots/teachers eingeführt. Wird in dieser Variable der Wert true hinterlegt, ist das Betrachten der Desktop-Ansicht von Rechnern, an denen Lehrer angemeldet sind, nicht mehr möglich.

Über die Aktion Computer einschalten können WakeOnLAN-Pakete an die betreffenden Rechner verschickt werden, um diese einzuschalten. Ab UCS@school 4.4v4 werden diese WakeOnLAN-Pakete über alle Netzwerkschnittstellen des UCS@school-Systems verschickt. Falls die Pakete auf bestimmten Netzwerkschnittstellen nicht verschickt werden sollen, können diese Schnittstellen über die UCR-Variablen ucsschool/umc/computerroom/wakeonlan/blacklisted/interfaces und ucsschool/umc/computerroom/wakeonlan/blacklisted/interface_prefixes festgelegt werden. Dabei sind die einzelnen Werte durch Leerzeichen zu trennen, z.B. tun docker. Wenn sich die Zielrechner in einem anderen Netzwerk befinden, können über die UCR-Variable ucsschool/umc/computerroom/wakeonlan/target_nets die Subnetze angepasst werden, an die Pakete gesendet werden. Dabei sind die einzelnen Werte durch Leerzeichen zu trennen, z.B. 255.255.255.255 10.200.18.255.

Ab Version 4.4v4 prüft das Computerraum-Modul von UCS@school in der Standardeinstellung regelmäßig, ob alle gesperrten Rechner weiterhin noch gesperrt sind, um z.B. Rechner nach deren Neustart wieder in den gesperrten Zustand zu versetzen. Das Intervall, in dem die Überprüfung läuft, kann durch die Univention Configuration Registry-Variable ucsschool/umc/computerroom/screenlock/interval konfiguriert werden. In der Standardkonfiguration wird die Prüfung alle 5 Sekunden durchgeführt. Wird der Wert der Variable auf 0 gesetzt, wird die Prüfung abgeschaltet.

Ab UCS@school 4.4v9 wird das Computerraum Backend Veyon mit ausgeliefert, welches iTALC ablösen wird. Da ggf. eine Migration von iTALC zu Veyon auf den Windows Clients vorgenommen werden muss (siehe https://help.univention.com/t/migration-of-the-computer-room-backend-italc-to-veyon/16937 und Abschnitt 7.4), können Computerräume, die iTALC als Backend verwenden, weiter verwendet werden. Als Standard ist iTALC gesetzt. Wenn für einen Computerraum Veyon verwendet werden soll, muss im UMC-Modul Computerraum das Computerraum Backend Veyon ausgewählt werden.

Ab UCS@school 4.4v8 werden Rechner mit mehreren IP-Adressen unterstützt. Die IP-Adressen des jeweiligen Rechners werden durchlaufen und die erste verwendet, die erreicht werden kann. Dies kann zu längeren Wartezeiten führen, wenn Rechner innerhalb des Computerraums ausgeschaltet sind oder eine Firewall den Befehl blockiert. Das Verhalten ist standardmäßig deaktiviert und kann durch Setzen der Univention Configuration Registry-Variable ucsschool/umc/computerroom/ping-client-ip-addresses aktiviert werden.

Über das UMC-Modul Klassenlisten können Listen mit Schülerdaten einer ausgewählten Klasse exportiert werden. In der Standardkonfiguration werden die UDM Attribute firstname, lastname, username sowie die ausgewählte Klasse angezeigt. Mit der Univention Configuration Registry-Variable ucsschool/umc/lists/class/attributes können die angezeigten Attribute angepasst werden. Die Variable beschreibt eine Zuordnung der anzuzeigenden UDM Attribute zu den angezeigten Spaltennamen. Dabei sind die Zuordnung durch Kommata zu trennen, z.B. firstname Vorname,lastname Nachname,Class Klasse,username Username. Für Class wird dabei die ausgewählte Klasse eingesetzt.

Ab UCS@school 4.4v7 ist es möglich die Aktivierung von Email-Adressen für Arbeitsgruppen über das Modul Arbeitsgruppen verwalten zu erlauben. Um dieses Feature zu aktivieren, muss die Univention Configuration Registry-Variable ucsschool/workgroups/mailaddress gesetzt werden. Der eingetragene Wert bestimmt das Muster, nach dem die Email-Adresse einer Arbeitsgruppe berechnet wird. Es stehen zwei Platzhalter-Werte zur Verfügung: {ou} und {name}. Ist der Wert der Univention Configuration Registry-Variable beispielsweise {ou}-{name}@schule-univention.de, so wird für eine Arbeitsgruppe mit dem Namen AG1 an der Schule DEMOSCHOOL die Email-Adresse DEMOSCHOOL-AG1@schule-univention.de berechnet.

Die Apple School Manager Connector App für UCS@school synchronisiert automatisch Benutzer zu Apple School Manager (ASM). Das UCS@school Identity Management übernimmt die Rolle des Studierendeninformationssystems und verwendet die SFTP-Schnittstelle, wie sie von Apple bereit gestellt wird.

UCS@school integriert Samba 4. Die Unterstützung von Domänen-, Verzeichnis- und Authentifizierungsdiensten, die kompatibel zu Microsoft Active Directory sind, erlauben den Aufbau von Active Directory-kompatiblen Windows-Domänen. Diese ermöglichen u.a. die Verwendung der von Microsoft bereit gestellten Werkzeuge beispielsweise für die Verwaltung von Benutzern oder Gruppenrichtlinien (GPOs). Univention hat die benötigten Komponenten für die Bereitstellung von Active Directory kompatiblen Domänendiensten mit Samba 4 getestet und in enger Zusammenarbeit mit dem Samba-Team in UCS integriert. Parallel dazu wurde für UCS Samba 3 mit Samba 4 integriert. Somit werden auch bei Verwendung der Active Directory kompatiblen Domänendienste die erprobten Datei- und Druckdienste aus Samba 3 verwendet.

ucr set ucsschool/import/generate/policy/dhcp/dns/set_per_ou=false

Bei Neuinstallationen von UCS@school wird standardmäßig Samba 4 installiert. Umgebungen, die von einer Vorversion aktualisiert werden, müssen von Samba 3 auf Samba 4 migriert werden. Das dafür notwendige Vorgehen ist unter der folgenden URI dokumentiert:

http://wiki.univention.de/index.php?title=UCS%40school_Samba_3_to_Samba_4_Migration

Weiterführende Hinweise zur Konfiguration von Samba finden sich im UCS-Handbuch [ucs-handbuch].

Beim Anlegen einer neuen Klasse bzw. eines Benutzers wird automatisch eine Klassenfreigabe für die Klasse bzw. eine Heimatverzeichnisfreigabe für den Benutzer eingerichtet. Der für die Einrichtung der Freigabe notwendige Dateiserver wird in den meisten Fällen ohne manuellen Eingriff bestimmt. Dazu wird am Schul-OU-Objekt bei der Registrierung einer Schule automatisch der in der Univention Management Console angegebene Schulserver als Dateiserver jeweils für Klassen- und Benutzerfreigaben hinterlegt.

Die an der Schul-OU hinterlegte Angabe bezieht sich ausschließlich auf neue Klassen- und Benutzerobjekte und hat keinen Einfluss auf bestehende Objekte im LDAP-Verzeichnis. Durch das Bearbeiten der entsprechenden Schul-OU im UMC-Modul LDAP-Verzeichnis können die Standarddateiserver für die geöffnete Schul-OU nachträglich modifiziert werden.

Es ist zu beachten, dass die an der Schul-OU hinterlegten Dateiserver nur in einer Multi-Server-Umgebung ausgewertet werden. In einer Single-Server-Umgebung wird für beide Freigabetypen beim Anlegen neuer Objekte immer der Domänencontroller Master als Dateiserver konfiguriert.

In UCS-Umgebungen mit mehreren Samba4-Domänencontrollern werden in der Standardeinstellung alle Dateien der NETLOGON-Dateifreigabe automatisch (durch die SYSVOL-Replikation) zwischen allen Samba4-Domänencontrollern repliziert. Beim Einsatz von UCS@school kann es bei der Verwendung von domänenweiten Benutzerkonten und benutzerspezifischen Netlogon-Skripten zu Synchronisationskonflikten kommen. Konflikte können ebenfalls bei eigenen, standortbezogenen Netlogon-Skripten auftreten.

In diesen Fällen ist es ratsam, die Synchronisation der NETLOGON-Freigabe zu unterbinden, indem ein abweichendes Verzeichnis für die NETLOGON-Freigabe definiert wird. Das Verzeichnis darf dabei nicht unterhalb der SYSVOL-Dateifreigabe (/var/lib/samba/sysvol/REALM/) liegen.

Das folgende Beispiel setzt das Verzeichnis der NETLOGON-Freigabe auf /var/lib/samba/netlogon/ und passt ebenfalls das Verzeichnis für die automatisch generierten Benutzer-NETLOGON-Skripte an:

ucr set samba/share/netlogon/path=/var/lib/samba/netlogon
ucr set ucsschool/userlogon/netlogon/path=/var/lib/samba/netlogon/user

Die zwei UCR-Variablen müssen auf allen Samba4-Domänencontrollern gesetzt werden. Dies kann z.B. in der UMC über eine UCR-Richtlinien global definiert werden. Nach der Änderung müssen die Dienste samba und univention-directory-listener neu gestartet werden:

service samba restart
service univention-directory-listener restart

Für die Kontrolle und Steuerung der Schüler-PCs integriert UCS@school optional die Software Veyon. Dieses Kapitel beschreibt die Installation von Veyon auf den Schüler-PCs. Die Administration durch die Lehrkräfte ist in der UCS@school-Lehrerdokumentation [ucs-school-teacher] beschrieben.

Für die Nutzung der Rechnerüberwachungs- und Präsentationsfunktionen in der Computerraumverwaltung (siehe Abschnitt 8.1) wird vorausgesetzt, dass auf den Windows-Clients die Software Veyon installiert wurde und als Computerraum Backend des entsprechenden Computerraums Veyon gesetzt ist (siehe Abschnitt 6.7).

Seit UCS@school 4.4 v9 sind Windows-Binärpakete für die Open Source-Software Veyon in UCS@school enthalten. Die Binärpakete sind direkt über die Samba-Freigabe Veyon-Installation abruf- und installierbar. Die Installationsdatei der 64bit-Version von Veyon findet sich auf dem Schulserver im Verzeichnis /usr/share/ucs-school-veyon-windows/. Interoperabilitätstests zwischen UCS@school und Veyon wurden ausschließlich mit der von UCS@school mitgelieferten Veyon-Version unter Windows 7 und Windows 10 (64 Bit) durchgeführt.

§

Abbildung 7.1. Veyon-Installation: Auswahl der Komponenten

Veyon bringt ein Installationsprogramm mit, das durch alle notwendigen Schritte führt. Während der Installation sollte nur der Veyon Service sowie der Interception driver installiert werden. Der Veyon Master wird für die Funktion von UCS@school nicht benötigt.

§

Abbildung 7.2. Veyon-Konfiguration: Auswahl der Authentifizierungs-Methode

Nach der Installation von Veyon auf dem Windows-Client muss das Programm mit dem installierten Veyon Configurator für eine Schlüsseldatei-Authentifizierung konfiguriert werden. Zunächst muss im Veyon Configurator unter Allgemein -> Authentifizierung die Methode Schlüsseldatei-Authentifizierung ausgewählt werden.

§

Abbildung 7.3. Veyon-Konfiguration: Zugriffskontrolle

Anschließend muss unter Zugriffskontrolle die Checkbox Verwendung von Domaingruppen aktivieren aktiviert werden. Als Benutzergruppen-Backend wird der Standard Systembenutzergruppen verwendet.

§

Abbildung 7.4. Veyon-Konfiguration: Schlüsselimport

Schließlich muss der öffentliche Schlüssel importiert werden, damit der Schulserver Zugriff auf das installierte Veyon-Backend erhält. Der Import kann mit Authentifizierungsschlüssl -> Schlüssel importieren durchgeführt werden. Dort ist der Veyon-Schlüssel des Schulservers anzugeben. Der Schlüssel wird automatisch auf der SYSVOL-Freigabe des Schulservers unter dem Namen der Schuldomäne unter scripts/veyon-cert_SERVERNAME.pem abgelegt. (U.U. liegt dort zusätzlich eine Datei veyon-cert.pem ohne den Namen des Servers. Diese sollte nicht verwendet werden.) Im Dialog Authentifizierungsschlüsselname muss der Name teacher angegeben werden. Außer den beschriebenen Konfigurationen müssen keine weiteren Anpassungen vorgenommen werden.

Der Konfigurations-Test im Veyon Configurator unter Allgemein -> Authentifizierung -> Testen wird trotz korrekter Einrichtung fehlschlagen. Die korrekte Einrichtung kann im Computerraum Modul überprüft werden. Hier sollte sich der Punkt neben dem Namen des eingerichteten Windows Clients dunkelgrau färben.

Außerdem sollte auf den Windows-Clients sichergestellt werden, dass die installierte System-Firewall so konfiguriert ist, dass Port 11100 nicht blockiert wird. Dies ist Voraussetzung für eine funktionierende Umgebung, da Veyon diesen Port für die Kommunikation mit dem Schulserver bzw. anderen Computern verwendet.

UCS@school stellt eine Reihe von Modulen für die Univention Management Console bereit, die für den IT-gestützten Unterricht verwendet werden können.

Im folgenden werden die Module kurz beschrieben. Eine ausführliche Beschreibung der Verwendung der Module findet sich im separaten Handbuch für Lehrer [ucs-school-teacher].

Einige Module stehen Lehrern und Schuladministratoren zur Verfügung während andere Module nur Schuladministratoren vorbehalten sind:

Mit den Modulen Passwörter (Schüler), Passwörter (Lehrer) und Passwörter (Mitarbeiter) lassen sich Benutzerpasswörter zurücksetzen. Die Benutzeroberfläche der Module ist identisch. Es werden alle Schüler/Lehrer/Mitarbeiter der gewählten Schule angezeigt. Durch Auswahl einer Klasse oder Arbeitsgruppe und/oder Nutzung der Suchleiste lässt sich die Menge der angezeigten Nutzer weiter eingrenzen.

§

Abbildung 8.1. Zurücksetzen von Schülerpasswörtern

Durch Auswahl eines oder mehrerer Nutzer und Anklicken von PASSWORT ZURÜCKSETZEN, kann ein neues Passwort für die jeweiligen Nutzer festgelegt werden.

§

Abbildung 8.2. Festlegen eines neuen Passworts

Aus Sicherheitsgründen ist es vor dem Zurücksetzen des Passwortes erforderlich, dass der aktuell eingeloggte Nutzer sein Passwort erneut eingeben muss.

Die bestehenden Schüler-Passwörter können außerdem nicht ausgelesen werden; wenn Schüler ihr Passwort vergessen, muss ein neues Passwort vergeben werden. Schuladministratoren dürfen die Passwörter von Lehrern und Mitarbeitern zurücksetzen.

Neben dem Namen und Nutzernamen der angezeigten Nutzer wird außerdem gezeigt, bei wem eine Änderung des Passwortes bei der nächsten Anmeldung erforderlich ist. Die Passwortänderung ist dann erforderlich, wenn beim Zurücksetzen eines Passworts die Checkbox Benutzer muss das Passwort bei der nächsten Anmeldung ändern angewählt wurde. Das Verhalten dieser Checkbox lässt sich durch folgende UCR-Variablen ändern:

Der Proxy von UCS@school unterstützt (ab UCS@school 4.0 R2 und mindestens UCS 4.0 Erratum 163) die Einbindung von externen Blacklisten, welche als Textdateien vorliegen müssen.

Die Textdateien dürfen jeweils nur Domänennamen oder URLs enthalten. Pro Zeile darf nur ein Eintrag (Domänenname/URL) enthalten sein. Die Textdateien müssen unterhalb des Verzeichnisses /var/lib/ucs-school-webproxy/ abgelegt werden. Die Verwendung von weiteren Unterverzeichnissen ist möglich.

Eingebunden werden die Blacklisten über das Setzen von zwei UCR-Variablen: proxy/filter/global/blacklists/domains und proxy/filter/global/blacklists/urls. Diese Variablen enthalten die Dateinamen der Domänen-Blacklisten bzw. URL-Blacklisten. Die Dateinamen sind relativ zum Verzeichnis /var/lib/ucs-school-webproxy anzugeben und müssen durch Leerzeichen voneinander getrennt werden.

Die Einbindung der folgenden, exemplarischen Blacklist-Dateien

/var/lib/ucs-school-webproxy/extblacklist1/domains
/var/lib/ucs-school-webproxy/extblacklist1/urls
/var/lib/ucs-school-webproxy/bl2/list-domains
/var/lib/ucs-school-webproxy/bl2/list-urls
/var/lib/ucs-school-webproxy/bl3-dom
/var/lib/ucs-school-webproxy/bl3-urls

kann über die nachfolgenden ucr set-Befehle erreicht werden:

ucr set proxy/filter/global/blacklists/domains=\
     "extblacklist1/domains bl2/list-domains bl3-dom"
ucr set proxy/filter/global/blacklists/urls=\
     "extblacklist1/urls bl2/list-urls bl3-urls"

Die Blacklisten werden vom Proxy in der Standardeinstellung mit niedriger Priorität ausgewertet, d.h. (temporäre) Whitelisten von Schuladministratoren und Lehrern haben Vorrang. Um die globalen Blacklisten vorrangig auszuwerten, kann die UCR-Variable proxy/filter/global/blacklists/forced auf den Wert yes gesetzt werden. Die Blacklisten können anschließend nicht mehr durch Schuladministratoren oder Lehrer in der UMC umgangen bzw. zeitweilig deaktiviert werden.

Um RADIUS-Unterstützung einzurichten muss das Paket ucs-school-radius-802.1x auf dem Schulserver der Schule installiert werden, in der WLAN-Authentifizierung eingerichtet werden soll. Außerdem muss das Paket ucs-school-webproxy auf dem Schulserver installiert sein.

Beginnend mit UCS@school 4.4 wird während der Installation des Pakets ucs-school-radius-802.1x auch automatisch die UCS-App RADIUS mit seinen zusätzlichen Features installiert. Die entsprechenden RADIUS-Abschnitte des UCS-Handbuchs[ucs-handbuch] sind daher auch zu prüfen.

Nun müssen alle Access Points der Schule in der RADIUS-Konfiguration zusammen mit einem Passwort hinterlegt werden, um einen Vertrauenskontext zwischen Access Point und RADIUS-Server zu schaffen. Dies kann ab UCS 4.4 entweder in der Univention Management Console erfolgen, sofern für jeden Access Point ein Rechnerobjekt im LDAP-Verzeichnis hinterlegt wird, oder in der Konfigurationsdatei /etc/freeradius/3.0/clients.conf.

Pro Access Point sollte ein zufälliges Passwort erstellt werden. Dies kann z.B. mit dem Befehl makepasswd geschehen. Die Kurzbezeichnung ist frei wählbar. Ein Beispiel für einen solchen Eintrag:

client AP01 {
    secret = a9RPAeVG
    ipaddr = 192.168.100.101
}

Nun müssen die Access Points konfiguriert werden. Die dafür nötigen Schritte unterscheiden sich je nach Hardwaremodell, prinzipiell müssen die folgenden vier Optionen konfiguriert werden:

Der zugreifende Client muss zunächst das UCS-Wurzelzertifikat importieren. Es kann z.B. von der Startseite des Domänencontroller Master unter dem Link "Wurzelzertifikat" bezogen werden. Anschließend muss er eine Netzwerkverbindung mit den folgenden Parametern konfigurieren:

Die Konfiguration unterscheidet sich je nach Betriebssystem des Clients. Im Univention Wiki findet sich eine exemplarische Schritt-für-Schritt-Anleitung für die Einrichtung unter Windows 7, sowie für die Einrichtung unter Windows 10.

In der Grundeinstellung ist der WLAN-Zugriff nicht zugelassen. Um einzelnen Benutzergruppen WLAN-Zugriff zu gestatten, muss in der Univention Management Console im Modul Internetregeln definieren eine Regel hinzugefügt - oder eine bestehende editiert werden -, in der die Option WLAN-Authentifizierung aktiviert aktiviert ist.

Weiterführende Dokumentation zur Freigabe des WLAN-Zugriffs finden sich in der UCS@school-Lehrerdokumentation [ucs-school-teacher].

Im Fehlerfall sollte die Logdatei /var/log/freeradius/radius.log geprüft werden. Erfolgreiche Logins führen zu einem Logeintrag Auth: Login OK und eine fehlgeschlagene Authentifizierung beispielsweise zu Auth: Login incorrect. Weitere Informationen zur Fehlersuche sind im UCS-Handbuch[ucs-handbuch], im Kapitel Radius, beschrieben.

Zur Verwendung des Klassenarbeitsmodus sind folgende Voraussetzungen zu erfüllen:

Eine neue Klassenarbeit kann über das Modul Klassenarbeit starten begonnen werden. Beim Durchlaufen der einzelnen Schritte werden von der Lehrkraft ein Name für die Klassenarbeit und die teilnehmenden Klassen/Arbeitsgruppen ausgewählt. Zusätzlich können für die Arbeit notwendige Dateien hochgeladen sowie Computerraumeinstellungen ausgewählt werden.

Damit Schülern nicht die Möglichkeit gegeben wird, auf ihr bisheriges Heimatverzeichnis zuzugreifen, werden zum Zeitpunkt des Einrichtens der Klassenarbeit für die ausgewählten Schülerkonten spezielle Klassenarbeitskonten neu angelegt. Der Loginname für das Klassenarbeitskonto setzt sich aus einem festgelegten Präfix (standardmäßig exam-) und dem normalen Benutzernamen zusammen. Bspw. wird für den Benutzer anton123 das Klassenarbeitskonto exam-anton123 angelegt, mit dem er sich während der Klassenarbeit anmelden muss. Für das Klassenarbeitskonto wird ein neues Heimatverzeichnis erzeugt, Passwörter und andere Konteneinstellungen werden jedoch aus dem ursprünglichen Benutzerkonto direkt übernommen. Schüler können die Zugriffsberechtigungen ihrer Heimatverzeichnisse nicht verändern. Dadurch wird verhindert, dass ein Schüler sein Heimatverzeichnis für weitere Schüler freigegeben kann. Um Schülern den Zugriff auf andere Dienste (z.B. Mail oder Cloud) während einer Klassenarbeit zu verwehren, kann die UCR-Variable ucsschool/exam/user/disable aktiviert werden (siehe Abschnitt 11.2).

Für deaktivierte Nutzerkonten wird kein Klassenarbeitskonto angelegt. Diese werden beim Hinzufügen zur Klassenarbeit ignoriert. Soll ein Schüler an einer Klassenarbeit teilnehmen, muss dessen Nutzerkonto aktiviert sein. Wie Benutzer aktiviert/deaktiviert werden können, wird im UCS-Handbuch[ucs-handbuch] beschrieben.

Alle Klassenarbeitskonten der Schüler sowie alle Rechner des Computerraumes sind für den Zeitraum der Klassenarbeit Mitglieder der Gruppe OU<OU-Name>-Klassenarbeit. Durch diese Gruppe können spezifische Einschränkungen für Schüler und Rechner mit Hilfe von Windows-Gruppenrichtlinien vorgenommen werden (siehe Abschnitt 11.3).

Für die Konfiguration des Klassenarbeitsmodus gibt es eine Reihe von Univention Configuration Registry-Variablen. Diese werden im folgenden aufgelistet und kurz erläutert.

Die nachfolgenden Univention Configuration Registry-Variablen können geändert werden, um LDAP-Eigenschaften der Klassenarbeitskonten, -gruppen und -container anzupassen. Sofern diese Variablen manuell gesetzt werden, ist zu beachten, dass es sich dabei um globale Einstellungen handelt und diese Variablen sowohl auf dem Domänencontroller Master als auch auf den Schulservern identische Werte aufweisen müssen.

Das UMC-Modul zum Einrichten einer Klassenarbeit bietet die Möglichkeit bestimmte Standardwerte zu definieren, um das Starten einer Klassenarbeit zu vereinfachen; dazu gehören:

Mit UCS@school 4.4v3 gibt es die Möglichkeit in regelmäßigen Abständen Sicherungskopien aller Schülerdaten zu speichern, während sie sich in einer Klassenarbeit befinden. Diese Sicherungskopien werden in einem separaten Ordner im Heimatverzeichnis des Lehrers gespeichert, welcher die Klassenarbeit durchführt. Diese Funktionalität ist in dieser Version standardmäßig deaktiviert und kann über die folgenden Univention Configuration Registry-Variablen konfiguriert werden:

Gruppenrichtlinien werden von einem Windows System aus mit Hilfe der Gruppenrichtlinienverwaltung (GPMC) angelegt und bearbeitet. Im Folgenden ist die Konfiguration der Gruppenrichtlinien von einem Windows 7 System aus beschrieben auf dem dazu die Gruppenrichtlinienverwaltung (GPMC) aus den Remote System Administration Tools (RSAT) installiert sein muss.

Alle Gruppenrichtlinieneinstellungen können je nach Bedarf gesammelt über ein Gruppenrichtlinienobjekt vorgenommen werden oder auf separate Objekte verteilt werden. Um den Bezug zwischen einem ausgewählten Gruppenrichtlinienobjekt und Objekten im Samba-Verzeichnisdienst herzustellen, kann es mit einer Organisationseinheit (OU) verknüpft werden, z.B. der Schul-OU. Einige der hier beispielhaft beschriebenen Gruppenrichtlinieneinstellungen wirken sich nur auf Benutzer- und andere nur auf Computer-Konten aus. Da die Einstellungen eines Gruppenrichtlinienobjekts nur für Objekte ausgewertet werden, die unterhalb des speziellen Verzeichniszweigs liegen, mit dem es verknüpft wurde, ist es wichtig, dass das entsprechende Gruppenrichtlinienobjekt hinreichend hoch in der hierarchischen Objektordnung verknüpft wird.

Einige der genannten Gruppenrichtlinien-Einstellungen beziehen sich auf den Bereich der Computerkonfiguration und werden nur beim Systemstart korrekt von den entsprechenden Windows-Komponenten ausgewertet. Für solche Einstellungen ist daher ein Neustart der Windows-Arbeitsplatzsysteme nach Aktivierung des Klassenarbeitsmodus notwendig.

eval "$(ucr shell)"
/usr/share/univention-s4-connector/msgpo.py --write2ucs \
  --binddn "uid=Administrator,cn=users,$ldap_base" --bindpwd <password>

Eine weitere Funktion von den Hook-Skripten ist die Möglichkeit mit Erweiterungen in den Import-Dateien umzugehen, d.h. wenn in den Importdateien mehr Felder eingetragen sind, als durch die Import-Skripte selbst verarbeitet werden, so können die erweiterten Attribute in den Hook-Skripten ausgelesen und verarbeitet werden. Als Beispiel könnten bei den Benutzern Adressinformationen oder eine Abteilung gespeichert werden. Die zusätzlichen Felder werden in den Importdateien jeweils hinten an die Zeilen getrennt durch einen Tabulator angehängt. Da die Hook-Skripte die komplette Zeile übergeben bekommen, kann ein Post-Hook-Skript genutzt werden, um die neuen Felder auszulesen und die Informationen z.B. an dem gerade erzeugten Benutzer zu ergänzen.

Um den Austausch von Dokumenten zwischen Benutzern zu erleichtern, wird empfohlen, die Freigabe Marktplatz auf den jeweiligen Schul-DCs anzulegen, auf die alle Benutzer Zugriff erhalten.

Das Hook-Skript ou_create_post.d/52marktplatz_create wurde ab UCS@school für UCS 2.4 mitgeliefert und legte beim Aufruf von create_ou die Freigabe ``Marktplatz'' automatisch an. Seit UCS@school 4.4 v8 existiert der Hook nicht mehr als separate Datei, da er in den Kern von UCS@school übernommen wurde. Über die Univention Configuration Registry-Variable ucsschool/import/generate/share/marktplatz kann das Anlegen der Freigabe de-/aktiviert werden, indem der Variable der Wert no bzw. yes zugeordnet wird.

Über drei weitere Univention Configuration Registry-Variablen kann das Verhalten des Hooks gesteuert werden:

Auf den Schul-DCs wird ein abweichender Container für DHCP-Objekte verwendet, weshalb die Univention Configuration Registry-Variable dhcpd/ldap/base entsprechend gesetzt werden muss. Um das manuelle Setzen der UCR-Variable für jede neue OU bzw. jeden neuen Schul-DC zu vermeiden, wird automatisch beim Erstellen einer OU die UCR-Richtlinie ou-default-ucr-policy im Container cn=policies,ou=XXX,LDAPBASIS angelegt und anschließend mit dem OU-Objekt ou=XXX,LDAPBASIS verknüpft. Bis UCS@school 4.4 v8 tat dies der Hook ou_create_post.d/40dhcpsearchbase_create, mittlerweile ist diese Funktion im Kern. Über die Richtlinie wird die Univention Configuration Registry-Variable dhcpd/ldap/base entsprechend gesetzt. Dadurch wird sichergestellt, dass die in der Richtlinie gesetzten UCR-Variablen auf allen UCS-Systemen der OU automatisch übernommen werden.

Ab UCS@school 4.4 v9 kann vor und nach dem Anlegen, Ändern, Verschieben und Löschen von UCS@school Objekten Python-Code ausgeführt werden. Die im vorherigen Kapitel beschriebenen Hook-Skripte werden ab UCS@school 5.0 nicht mehr unterstützt.

Python-Hooks (im folgenden Abschnitt abgekürzt mit "Hooks") werden wesentlich schneller ausgeführt als Hook-Skripte, erlauben eine feingranulare Unterscheidung nach Objekttypen (z.B. Schulklasse und Arbeitsgruppe oder Schüler und Lehrer) und haben Zugriff auf alle Attribute der Objekte.

Die Hooks werden für alle Klassen, von denen Objekte erzeugt werden können und die von ucsschool.lib.models.base.UCSSchoolHelperAbstractClass ableiten, ausgeführt. Diese Klassen finden sich in im Python Paket ucsschool.lib.models (z.B. Student, SchoolClass, Workgroup).

Hooks für UCS@school Objekte ähneln den bekannten Hooks für den Benutzerimport (siehe [ucs-school-cli-import]), werden jedoch auch ohne den Import zu verwenden ausgeführt und haben einige andere Attribute.

Zur Nutzung der Hook-Funktionalität muss eine eigene Python-Klasse erstellt werden, die von ucsschool.lib.models.hook.Hook ableitet. In der Klasse können Methoden pre_create(), post_create(), etc. definiert werden, welche zum jeweiligen Zeitpunkt ausgeführt werden. Der Name der Datei mit der abgeleiteten Klasse muss auf .py enden und im Verzeichnis /var/lib/ucs-school-lib/hooks abgespeichert werden. Zwei Beispiele finden sich auf Servern der Rolle Primary Node (DC Master) in hook_example1.py und hook_example2.py unter /usr/share/doc/ucs-school-lib-common/ bzw. online auf https://github.com/.../hook_example1.py und https://github.com/.../hook_example2.py. Im Folgenden wird anhand des Beispiels in hook_example2.py erklärt, wie mit Hilfe eines Hooks jeder Schulklasse eine Email-Adresse zugeordnet werden kann.

Ein Python-Hook ist eine Klasse, die von ucsschool.lib.models.hook.Hook ableitet und einige Attribute und Methoden definiert.

from ucsschool.lib.models.group import SchoolClass
from ucsschool.lib.models.hook import Hook

class MailForSchoolClass(Hook):
    model = SchoolClass
    priority = {
        "post_create": 10,
        "post_modify": 10,
    }

    def post_create(self, obj):  # type: (SchoolClass) -> None
        ...

    def post_modify(self, obj):  # type: (SchoolClass) -> None
        ...

Das Klassenattribut model bestimmt, für welche Objekte welchen Typs der Hook ausgeführt wird. Der Hook wird auch für Objekte von Klassen ausgeführt, die von der angegebenen ableiten. Wäre model = Teacher (aus ucsschool.lib.models), so würde der Hook auch für Objekte der Klasse TeachersAndStaff ausgeführt, nicht aber für solche vom Typ Staff oder Student.

Das Klassenattribut priority bestimmt die Reihenfolge in der Methoden von Hooks des gleichen Typs (gleiches model) ausgeführt werden bzw. deaktiviert sie. Methoden mit höheren Zahlen werden zuerst ausgeführt. Ist der Wert None oder die Methode nicht aufgeführt, wird sie deaktiviert. Angenommen es gäbe eine weitere Klasse mit einem Hook mit model = SchoolClass und diese würde priority = {"post_create": 20} definieren, so würde deren post_create() Methode vor MailForSchoolClass.post_create() ausgeführt.

Alle Methoden der Klasse, z.B. pre_create() oder post_create(), empfangen ein Objekt vom Typ, bzw. des davon abgeleiteten Typs, der in model definiert wurde, als Argument obj und geben nichts zurück.

Die post_create() Methode sieht wie folgt aus:

def post_create(self, obj):  # type: (SchoolClass) -> None
"""
Create an email address for the new school class.

:param SchoolClass obj: the SchoolClass instance, that was just created.
:return: None
"""
    ml_name = self.name_for_mailinglist(obj)
    self.logger.info("Setting email address %r on school class %r...", ml_name, obj.name)
    udm_obj = obj.get_udm_object(self.lo)  # access the underlying UDM object
    udm_obj["mailAddress"] = ml_name
    udm_obj.modify()

Die Klasse SchoolClass bietet kein Attribut an, um eine Email-Adresse anzugeben. Die Klassen in ucsschool.lib.models sind jedoch tatsächlich eine Abstraktion regulärer Univention Directory Manager Objekte. Um auf auf die darunter liegenden Objekte zuzugreifen, wird die Methode get_udm_object() verwendet. Als Argument muss ihr ein sogenanntes LDAP Verbindungsobjekt (lo) mitgegeben werden.

Die Instanzvariablen self.lo, self.logger und self.ucr sind nach der Ausführung von __init__() verfügbar. Es handelt sich bei ihnen um die Instanz eines LDAP Verbindungsobjekts, einer Instanz von Python Logging und einer Instanz von Univention Configuration Registry. Soll eigener Code zur Initialisierung ausgeführt werden, so sollte __init__() folgendermaßen implementiert werden:

class MailForSchoolClass(Hook):
    def __init__(self, lo, *args, **kwargs):
        super(MailForSchoolClass, self).__init__(lo, *args, **kwargs)
        # From here on self.lo, self.logger and self.ucr are available.
        # You code here.

Zwei Funktionen helfen dabei, aus dem Namen der Schulklasse und einem Domänennamen, eine Email-Adresse zu erzeugen:

def name_for_mailinglist(self, obj):  # type: (SchoolClass) -> str
    return "{}@{}".format(obj.name, self.domainname).lower()

@property
def domainname(self):  # type: () -> str
    try:
        return self.ucr["mail/hosteddomains"].split()[0]
    except (AttributeError, IndexError):
        return self.ucr["domainname"]

Um Email-Adresse auch für umbenannte Schulklassen zu ändern, wird post_modify implementiert:

def post_modify(self, obj):  # type: (SchoolClass) -> None
    """
    Change the email address of an existing school class.

    :param SchoolClass obj: the SchoolClass instance, that was just modified.
    :return: None
    """
    udm_obj = obj.get_udm_object(self.lo)
    ml_name = self.name_for_mailinglist(obj)
    if udm_obj["mailAddress"] != ml_name:
        self.logger.info(
            "Changing the email address of school class %r from %r to %r...",
            obj.name,
            udm_obj["mailAddress"],
            ml_name,
        )
        udm_obj["mailAddress"] = ml_name
        udm_obj.modify()

Die Datei mit obigem Python Code kann nun im Verzeichnis /var/lib/ucs-school-lib/hooks abgespeichert werden. Soll der Hook von einem UMC-Modul verwendet werden, muss zuerst der UMC-Server neu gestartet werden:

service univention-management-console-server restart

Um den Hook zu testen, kann eine interaktive Python Shell verwendet werden. Einige Ausgaben wurden im folgenden Beispiel zur Verbesserung der Lesbarkeit gekürzt:

>>> import logging
>>> from ucsschool.lib.models.group import SchoolClass
>>> from univention.admin.uldap import getAdminConnection

>>> logging.basicConfig(level=logging.DEBUG, format="%(message)s", handlers=[logging.StreamHandler()])
>>> lo, _ = getAdminConnection()

>>> sc = SchoolClass(name="DEMOSCHOOL-igel", school="DEMOSCHOOL")
>>> sc.create(lo)

Starting SchoolClass.call_hooks('pre', 'create', lo('cn=admin,dc=exam,dc=ple')) for SchoolClass(
    name='DEMOSCHOOL-igel', school='DEMOSCHOOL', dn='cn=DEMOSCHOOL-igel,cn=klassen,cn=schueler,
    cn=groups,ou=DEMOSCHOOL,dc=exam,dc=ple').
Hook directory /usr/share/ucs-school-import/hooks/group_create_pre.d not found or empty.
Searching for hooks of type 'Hook' in: /var/lib/ucs-school-lib/hooks...
Found hook classes: MailForSchoolClass
Loaded hooks: {'post_modify': ['MailForSchoolClass.post_modify'], 'post_create': [
    'MailForSchoolClass.post_create']}.
Creating SchoolClass(name='DEMOSCHOOL-igel', school='DEMOSCHOOL', dn='...')
SchoolClass(name='DEMOSCHOOL-igel', school='DEMOSCHOOL', dn='...') successfully created
Starting SchoolClass.call_hooks('post', 'create', lo('cn=admin,dc=uni,dc=dtr')) for SchoolClass(
    name='DEMOSCHOOL-igel', school='DEMOSCHOOL', dn='...').
Hook directory /usr/share/ucs-school-import/hooks/group_create_post.d not found or empty.
Running post_create hook MailForSchoolClass.post_create for SchoolClass(name='DEMOSCHOOL-igel',
    school='DEMOSCHOOL', dn='...')...
Setting email address 'demoschool-igel@uni.dtr' on SchoolClass(name='DEMOSCHOOL-igel',
    school='DEMOSCHOOL', dn='...')...
True

>>> sc.name = "DEMOSCHOOL-hase"
>>> sc.modify(lo)

Starting SchoolClass.call_hooks('pre', 'modify', lo('cn=admin,dc=exam,dc=ple')) for SchoolClass(
    name='DEMOSCHOOL-hase', school='DEMOSCHOOL', dn='cn=DEMOSCHOOL-hase,...', old_dn='cn=DEMOSCHOOL-igel,...').
Hook directory /usr/share/ucs-school-import/hooks/group_modify_pre.d not found or empty.
Modifying SchoolClass(name='DEMOSCHOOL-hase', school='DEMOSCHOOL', dn='cn=DEMOSCHOOL-hase,...',
    old_dn='cn=DEMOSCHOOL-igel,...')
SchoolClass(name='DEMOSCHOOL-hase', school='DEMOSCHOOL', dn='cn=DEMOSCHOOL-hase,...') successfully modified
Starting SchoolClass.call_hooks('post', 'modify', lo('cn=admin,dc=exam,dc=ple')) for SchoolClass(
    name='DEMOSCHOOL-hase', school='DEMOSCHOOL', dn='cn=DEMOSCHOOL-hase,...').
Hook directory /usr/share/ucs-school-import/hooks/group_modify_post.d not found or empty.
Running post_modify hook MailForSchoolClass.post_modify for SchoolClass(name='DEMOSCHOOL-hase',
    school='DEMOSCHOOL', dn='cn=DEMOSCHOOL-hase,...')...
Changing the email address of SchoolClass(name='DEMOSCHOOL-hase', school='DEMOSCHOOL', ...)
    from 'demoschool-igel@example.com' to 'demoschool-hase@example.com'...
True

Vor dem Anlegen des Objekts wird in /usr/share/ucs-school-import/hooks/group_create_pre.d/ nach den Hook-Skripte gesucht, welche ab UCS@school 5.0 nicht mehr unterstützt werden. Anschließend wird in /var/lib/ucs-school-lib/hooks/ nach Python-Hooks gesucht und die Klasse MailForSchoolClass gefunden. Nach dem Laden aller Hooks wird angezeigt, in welcher Reihenfolge welche Methoden für welche Phase ausgeführt werden. Da es keine pre-create Hooks gibt, wird nun das Objekt angelegt. Anschließend werden post-create Hooks ausgeführt. Erneut wird zuerst nach Hook-Skripten gesucht. Anschließend wird MailForSchoolClass.post_create() ausgeführt. Beim sc.modify(lo) passiert das Gleiche.