Szenarien zum Einsatz von UCS@school

Organisation und Aufbau zentral verwalteter IT-Infrastrukturen für Schulen


Inhaltsverzeichnis

1. Verwendung dieses Dokuments
2. Szenarien
2.1. Servicestufen: UCS@school
2.2. Szenario 1: Bildungscloud
2.3. Szenario 2: Zentrales schulisches WLAN
2.4. Szenario 3: Zentral verwaltete schulische IT-Infrastruktur
2.5. Szenario 4: Schulische IT-Infrastruktur ohne dezentrale Schulserver
3. Checklisten: organisatorisch und technisch
3.1. Organisation
3.2. Zentral bereitgestellte IT-Angebote
3.3. Dezentral an den Schulen bereitgestellte IT-Angebote
3.4. WLAN und BYOD
4. Vorbereitende Maßnahmen
4.1. Initialer Workshop
4.2. Informationsveranstaltung für die Schulen
4.3. Planung des Rollout
4.4. Schulung der Lehrkräfte
5. Konzeptionelle Voraussetzungen
5.1. Netzkonzept
5.1.1. Beispiele für Subnetzkonzepte
5.1.2. Beispiel Subnetz Grundschule
5.1.3. Beispiel Subnetz Berufsschule
5.2. Konzept zur Benennung von Objekten
5.2.1. Name der Domäne
5.2.2. Zentrale Server
5.2.3. Rechner und Schulserver
5.2.4. Benutzernamen und Klassenbezeichnungen
5.2.5. Allgemeine Konventionen
5.3. Monitoring
5.4. Datensicherung und Wiederherstellung
5.5. Support-Kanäle
6. Netzinfrastruktur- und Hardware-Voraussetzungen
6.1. Zentrale Server
6.1.1. Identity Management
6.1.2. RADIUS
6.1.3. Monitoring
6.1.4. IT-Angebote, wie Groupware und Lernplattformen
6.2. Dezentrale Systeme
6.2.1. Schulserver
6.3. Netzinfrastruktur
6.3.1. Strukturierte Verkabelung
6.3.2. WLAN-Infrastruktur
6.3.3. Internetzugang
6.3.4. Internetzugang: Schulserver im Rechenzentrum
6.3.5. Verbindung zur Zentrale
7. Installation
7.1. Installation des Domänencontroller Master
7.2. Installation eines Domänencontroller Backup
7.3. Installation eines Domänencontroller Slave als Schulserver
7.4. Installation eines Domänencontroller Slave für RADIUS, Groupware, Collaboration, Lernplattformen usw.
7.5. Installation eines Memberserver für Monitoring
8. Basiskonfiguration
8.1. Zustellung von Systemmails
8.2. Globale Univention Configuration Registry-Richtlinie
8.3. Zentrale Univention Configuration Registry-Richtlinie
9. Datenimport
9.1. Schulen
9.2. Netze
9.3. Rechner
9.4. Drucker
9.5. Benutzer / Klassen

§Kapitel 1. Verwendung dieses Dokuments

UCS@school bietet die ideale Lösung, um eine zentral verwaltete IT-Infrastruktur mit einem einheitlichen Identity-Management aufzubauen. Weitere IT-Dienste können integriert und anschließend zentral über das UCS Management verwaltet und schulübergreifend für den Zugriff über unterschiedlichste Geräte zur Verfügung gestellt werden. Damit werden Schulträger und Ministerien in die Lage versetzt, aktuelle Anforderungen aus Medienentwicklungsplänen und von Schulen effizient und sicher zu erfüllen.

Mit diesem Whitepaper möchten wir Ihnen eine Anleitung an die Hand geben, um typische Szenarien für den Einsatz von UCS@school effizient aufzubauen. Wir greifen dabei auf langjährige Erfahrungen zurück, die Univention in diversen Projekten mit Schulträgern beim erfolgreichen Einsatz von UCS@school gewonnen hat.

Mit diesem Dokument möchten wir Ihnen einen kurzen Überblick über vier typische IT-Szenarien für Bundesländer, Schulträger und Schulen geben:

  • Bildungsclouds

  • Zentrales schulisches WLAN

  • Zentral verwaltete schulische IT-Infrastruktur

  • Schulische IT-Infrastruktur ohne dezentrale Schulserver

Außerdem finden Sie einige Tipps, welche Punkte nach unserer Erfahrung Schlüsselfaktoren für eine erfolgreiche Projektabwicklung, Rollout und Betrieb einer Infrastruktur in Schulen darstellen. Und wir haben eine Checkliste mit wichtigen Fragen zusammengestellt, mit denen Sie sich vor dem Projektbeginn beschäftigen sollten.

Für den Einstieg in das Dokument sind Kapitel 2 und Kapitel 3 vorgesehen. Die Kapitel geben einen Überblick zu den üblichen Einsatzszenarien und bieten Checklisten mit Fragen, deren Beantwortung die Einführung von UCS@school erleichtert. Die Checklisten verweisen darüberhinaus auf die weiterführenden technischen Themen in diesem Dokument, die erprobte Lösungen aus der Praxis aufzeigen.

Die Kapitel 2 und 3 geben einen Überblick zu üblichen Einsatzszenarien von UCS@school (Bildungscloud, Zentrales schulisches WLAN, zentrales Management, schulische IT-Infrastruktur ohne Schulserver) und bieten Checklisten mit Fragen, anhand derer Sie einfach überprüfen können, ob Sie bereits die notwendigen Voraussetzungen für die Einführung von UCS@school erfüllen oder ob Sie in bestimmten Bereichen noch Bedingungen erfüllen müssen. Die Checklisten verweisen darüber hinaus auch auf weiterführende technische Themen, die in diesem Dokument vorgestellt werden und die erprobte Lösungen aus der Praxis aufzeigen.

§Kapitel 2. Szenarien

In diesem Kapitel beschreiben wir Ihnen Szenarien, in denen UCS@school häufig eingesetzt wird. In diesem Dokument sind diese Szenarien in ihrem Umfang klar voneinander abgegrenzt. In der Praxis ist diese strikte Trennung nur selten der Fall und es treten in der Regel gemischte Formen auf . Die Umsetzung eines bestimmten in diesem Papier beschriebenen Szenarios schließt somit nicht aus, dass Sie im Laufe der Zeit weitere Szenarien auf Basis der bestehenden Umgebung umsetzen können.

§2.1. Servicestufen: UCS@school

Univention bietet für die Szenarien 1 bis 4 unterschiedliche Servicestufen für die Unterstützung in Projekten an. Kunden entscheiden beim Kauf von UCS@school welche Servicestufe für Sie in der aktuellen Situation am passendsten ist. Ein Wechsel auf eine andere Servicestufe ist jederzeit möglich. Voraussetzung in allen Servicestufen ist das Vorhandensein eines User Helpdesks, der die Supportanfragen aus den Schulen entgegen nimmt und die weitere Bearbeitung einleitet.

Welche Servicestufen gibt es?

  1. Software und Support: Univention liefert Software und Support, der Kunde kümmert sich selbst um Betrieb, Updates und Backup.

  2. Betrieb im Rechenzentrum des Kunden: Univention liefert Software und Support und übernimmt Betrieb, Updates und Backup im Rechenzentrum des Kunden.

  3. UCS@school as a Service: Univention liefert Software und Support und übernimmt Betrieb, Updates und Backup im eigenen Rechenzentrum. Kunden können sofort starten, ohne Investitionen in Hardware oder Software tätigen zu müssen.

§

Abbildung 2.1. Servicestufen: UCS@school

Servicestufen: UCS@school

§2.2. Szenario 1: Bildungscloud

Dieses Szenario ermöglicht es Schulträgern und Ministerien, eine effiziente Bildungscloud für ihre Schulen aufzubauen. Die Instanzen von Univention Corporate Server werden zentral in einem Rechenzentrum betrieben und stellen das Identity- und Access-Management zur Verfügung. An dieses werden unterschiedliche IT-Angebote angebunden, die von den Schulen benötigt werden. Zum Beispiel E-Mail und Groupware-Lösungen oder Lernmanagement-Systeme. Lehrkräfte und Schüler können alle angeschlossenen Angebote mit einem einzigen persönlichen Benutzerkonto und Passwort nutzen. Die Angebote können dabei sowohl vor Ort in den Schulen als auch von unterwegs oder von zu Hause genutzte werden.

Merkmale:

  • Unabhängigkeit von der jeweiligen IT-Ausstattung der Schulen

  • Bereitstellung orts- und zeitunabhängiger IT-Angebote für Lehrkräfte und Schüler

  • Effizienter Betrieb durch zentrale Administration

  • Integration beliebiger IT-Angebote oder vorkonfigurierter Angebote aus dem Univention App Center

  • Senkung des Aufkommens im Helpdesk durch Self-Service für vergessene Passwörter

§

Abbildung 2.2. Zentrales Identity-Management mit integrierten IT-Angeboten

Zentrales Identity-Management mit integrierten IT-Angeboten

§2.3. Szenario 2: Zentrales schulisches WLAN

Dieses Szenario ermöglicht es Schulträgern, den Zugang zum WLAN in ihren Schulen zentral zu steuern und den Zugang nur bekannten Lehrkräften und Schülern zu gewähren. Dazu wird Univention Corporate Server zentral in einem Rechenzentrum betrieben und dient als Identity- und Access-Management. Die Schulen sind mit diesem Rechenzentrum beispielsweise mittels eines VPN-Zugangs verbunden. In den Schulen werden WLAN Access Points installiert, die RADIUS unterstützen (WPA2-Enterprise / IEEE 802.1X). Ergänzend können auch wie in Szenario 1 weitere IT-Angebote an die zentralen Systeme angebunden werden.

Merkmale:

  • Unabhängigkeit von Schulserver-Lösungen in den Schulen

  • Geringe zusätzliche Anforderungen an die Bandbreite der Schule

  • Absicherung des WLAN-Zugangs durch Verwendung persönlicher Zugangsdaten für Lehrkräfte und Schüler

  • Effizienter Betrieb durch zentrale Administration

  • Integration beliebiger IT-Angebote oder vorkonfigurierter Angebote aus dem Univention App Center

§

Abbildung 2.3. Zentrales Identity-Management, WLAN und weitere IT-Angebote für Schulen

Zentrales Identity-Management, WLAN und weitere IT-Angebote für Schulen

§2.4. Szenario 3: Zentral verwaltete schulische IT-Infrastruktur

Dieses Szenario ermöglicht es Schulträgern, die gesamte IT-Infrastruktur ihrer Schulen zentral zu verwalten und pädagogische Funktionen dezentral in den Schulen bereitzustellen. Dazu ergänzt es die in Szenario 2 beschriebene WLAN Lösung um an den Schulen betriebene Schulserver. Diese stellen vor Ort die benötigten Infrastruktur-Dienste wie DHCP, DNS, Active Directory kompatible Domäne, Dateifreigaben, Proxy, aber auch pädagogische Funktionen wie Computerraumsteuerung, Klassenarbeitsmodus, Passwörter zurücksetzen und Softwareverteilung bereit.

Merkmale:

  • Vollständige Bereitstellung der IT-Infrastruktur in den Schulen

  • Unabhängigkeit der Schule gegenüber Ausfällen des Internetzugangs/VPNs

  • Effizienter Betrieb durch zentrale Administration

  • Integration beliebiger IT-Angebote oder vorkonfigurierter Angebote aus dem Univention App Center

§

Abbildung 2.4. Zentral verwaltete schulische IT-Infrastruktur mit Schulservern an den Schulen

Zentral verwaltete schulische IT-Infrastruktur mit Schulservern an den Schulen

§2.5. Szenario 4: Schulische IT-Infrastruktur ohne dezentrale Schulserver

Dieses Szenario ermöglicht es Schulträgern, die gesamte IT-Infrastruktur ihrer Schulen zentral zu verwalten, wie in Szenario 3 beschrieben, mit der Ergänzung, dass die Schulserver nicht in den Schulen, sondern im Rechenzentrum betrieben werden. Voraussetzung ist eine sehr gute und zuverlässige Anbindung der Schulen an dieses Rechenzentrum. Durch die Verlagerung der Schulserver ins Rechenzentrum können die Hardware-Ressourcen effizienter verwendet werden und gleichzeitig reduzieren sich die Kosten für die Wartung.

Merkmale:

  • Vollständige Bereitstellung der IT-Infrastruktur in den Schulen

  • Abhängigkeit der Schule gegenüber Ausfällen des Internetzugangs/VPNs

  • Effizienter Betrieb durch zentrale Administration und bessere Ressourcennutzung

  • Effiziente Wartung durch einfacheren Zugang zu den Systemen

  • Integration beliebiger IT-Angebote oder vorkonfigurierter Angebote aus dem Univention App Center

§

Abbildung 2.5. Zentral verwaltete schulische IT-Infrastruktur ohne dezentrale Schulserver

Zentral verwaltete schulische IT-Infrastruktur ohne dezentrale Schulserver

§Kapitel 3. Checklisten: organisatorisch und technisch

Im Folgenden haben wir einige Fragen zusammengestellt, über die Sie sich direkt am Anfang der Projektplanung Gedanken machen sollten.

§3.1. Organisation

  • Welches Szenario soll umgesetzt werden? Siehe Kapitel 2.

  • Wer ist Betreiber der Gesamtinfrastruktur?

  • Verfügt der Betreiber über das erforderliche Wissen? Siehe Abschnitt 4.1.

  • Wie werden Schulen über die Einführung der neuen IT-Infrastruktur informiert? Siehe Abschnitt 4.2.

  • Wer baut in den Schulen Server, Rechner und Drucker auf und tauscht diese im Fehlerfall aus?

  • In welcher Reihenfolge erfolgt der Rollout an den Schulen (nicht in allen Szenarien notwendig)? Siehe Abschnitt 4.3.

  • In welchem zeitlichen Rahmen soll der Rollout der Pilot-Installation und später der Gesamtinfrastruktur erfolgen?

  • Welche administrativen Aufgaben sollen durch die Schulen übernommen werden, zum Beispiel Passwörter zurücksetzen?

  • Wie werden Schulen mit den neuen Lösungen w.z.B. UCS@school vertraut gemacht? Siehe Abschnitt 4.4.

  • Wie und bei wem melden Schulen Probleme? Siehe Abschnitt 5.5.

  • Wie wird die Qualität des erbrachten IT-Angebots gemessen? Welches sind die entscheidenden Parameter, um dies zu messen?

  • Wie wird sichergestellt, dass die zukünftigen Anforderungen der Schulen erfasst und von der Gesamtinfrastruktur erfüllt werden?

  • Wer ist verantwortlich für die Pflege von Informationen in der Schulverwaltungssoftware und wie können diese Daten importiert werden?

§3.2. Zentral bereitgestellte IT-Angebote

  • Wo werden die zentralen Server betrieben? Siehe Abschnitt 6.1.

  • Nach welchen Konzepten wird die Gesamtinfrastruktur betrieben, insbesondere Netzkonzept, sowie Namenskonzepte für Benutzer und Rechner? Siehe Kapitel 5.

  • Wie wird die Aufrechterhaltung des Betriebs sichergestellt, zum Beispiel Monitoring, Datensicherung und Notfallpläne? Siehe Abschnitt 7.5 und Abschnitt 5.4.

  • Wer führt die initiale Installation und Einrichtung durch?

    • Installation der UCS-Server mit UCS@school App: Kapitel 7

    • Welche Basiskonfigurationen sollen vorgenommen werden? Siehe Kapitel 8

    • Wie erfolgt der Import von Benutzer-, Rechner- und Netzdaten: Kapitel 9

  • Welche VPN-Lösung wird eingesetzt (nicht in allen Szenarien notwendig)? Siehe Abschnitt 6.3.5

  • Welche über die Basis IT-Infrastruktur hinausgehenden Angebote und Einstellungen sollen angeboten werden?

    • Wie werden die über das Internet zugänglichen zentralen Angebote vor unerwünschtem Zugriff geschützt?

  • Soll die Schulen zukünftig über einen zentralen Proxy auf das Internet zugreifen?

§3.3. Dezentral an den Schulen bereitgestellte IT-Angebote

  • Wer ist lokaler Ansprechpartner für die IT-Infrastruktur in der Schule?

  • Setzt die Schule bereits eine Schulserver-Lösung ein?

    • Welche Funktionen sind der Schule wichtig?

  • Wie schnell und stabil ist der Internetzugang der Schule? Siehe Abschnitt 6.3.3.

  • Wer betreibt den Internetzugang und ist für die Entstörung zuständig?

  • Welche aktiven und passiven Netzkomponenten sind im Einsatz, zum Beispiel DSL-Router/Switches/Access Points, und wer kennt die Zugangsdaten?

  • Welches IP-Netz wird aktuell in der Schule verwendet?

    • Welche Komponenten müssen angepasst werden, um das Netzkonzept (siehe Abschnitt 3.2) umzusetzen?

  • Ist in der Schule strukturierte Verkabelung in allen Computerräumen vorhanden? Siehe Abschnitt 6.3.1

    • Wie sind die Patchfelder und Netzdosen belegt?

  • Welche Bauarbeiten und Beschaffungen müssen vorgenommen werden, um die Betriebsbereitschaft für die Schule herzustellen?

  • Kann mit dem verfügbaren Internetzugang ein VPN betrieben werden (nicht in allen Szenarien notwendig)? Siehe Abschnitt 6.3.5.

§3.4. WLAN und BYOD

  • Kann mit dem verfügbaren Internetzugang ein VPN betrieben werden?

  • Sind professionelle Access Points vorhanden, die VLANs und mehreren SSIDs unterstützen?

  • Wie können die Access Points zentral konfiguriert werden? Ist eine Management Software vorhanden?

  • Wo wird der RADIUS-Service betrieben?

  • Wie greifen die mobilen Geräte auf das Internet zu, zum Beispiel direkt oder über einen transparenten Proxy?

  • Wie hoch sind die notwendigen Investitionen, um die Betriebsbereitschaft für das WLAN herzustellen?

  • Welche IT-Angebote, zentral und dezentral, sollen von den Geräten im WLAN verwendet werden können?

§Kapitel 4. Vorbereitende Maßnahmen

für alle Szenarien

In vergangenen Projekten haben sich folgende Schritte bewährt:

§4.1. Initialer Workshop

Ziel des Workshops ist es die existierenden Konzepte auf die konkrete Umsetzung abzubilden. Dabei hat es sich bewährt, auf Erfahrungen und Vorgehensweisen aufzubauen, die unter anderem auch in diesem Dokument erfasst sind. Im Rahmen des Workshops sollten direkt die zentralen Systeme und eine Demo-Schule installiert werden, die in der folgenden Zeit als Referenz verwendet werden kann.

§4.2. Informationsveranstaltung für die Schulen

Ziel der Informationsveranstaltung ist es, die Lehrkräfte in den Schulen mit in den Prozess der Einführung der neuen IT-Infrastruktur zu involvieren. Eine bereits installierte Demo-Schule kann dazu dienen, das System initial zu präsentieren. Es hat sich in vielen Projekten gezeigt, dass solche Informationsveranstaltungen auch nach dem Rollout regelmäßig stattfinden sollten, um neue Anforderungen und Feedback aufzunehmen.

§4.3. Planung des Rollout

Ziel ist es, den Rollout der IT-Infrastruktur mit erfolgreichen Projekten zu beginnen. Dafür gilt es, die am besten geeigneten Schulen zu identifizieren und diese als erste auszustatten. In vielen Projekten haben wir die Erfahrung gemacht, dass Schulen, die die folgenden Kriterien erfüllen, besonders gut für den Start geeignet sind:

  • Überschaubare, gut ausgebaute IT-Infrastruktur

  • Konkreter Bedarf nach einer Lösung

  • Geringer Migrationsaufwand von bestehenden Lösungen

  • Wenige Sonderfälle

Sind diese Schulen erfolgreich ausgestattet worden, so können sie als Referenz für anderen Schulen dienen. Schrittweise können nun komplexere Umgebungen ausgerollt werden.

§4.4. Schulung der Lehrkräfte

Die Lehrkräfte sollten im Umgang mit den Rechnern und den pädagogischen Funktionen der in der Schule genutzten Anwendungen geschult werden. Auch dazu sollten wiederkehrende Termine angeboten werden.

§Kapitel 5. Konzeptionelle Voraussetzungen

Die folgenden Empfehlungen bauen auf Erfahrungen auf, die sich in diversen Projekten bewährt haben. Sie sind jedoch nicht zwingend umzusetzen und Abweichungen sind jederzeit möglich.

§5.1. Netzkonzept

für Szenario 2, 3 und 4

In UCS@school wird für jede Schule mindestens ein Subnetz benötigt, sobald an den Schulen Endgeräte eingesetzt werden sollen. Abhängig vom Szenario kann eine einzelne Schule auch mehr als ein Subnetz erhalten.

Für den Aufbau einer Umgebung mit mehreren Schulen empfehlen wir die Verwendung des privaten Klasse-A Netzes, 10.0.0.0/8. Dieses wird für die Schulen in viele Subnetze unterteilt. Für jede Schule wird ein Klasse-B Netz reserviert, das Platz für 65.536 IP-Adressen bietet und nach Bedarf in weitere Subnetze unterteilt wird.

§

Tabelle 5.1. Zuteilung der Subnetze zu Schulen

Subnetz (CIDR)Schule
10.0.0.0/16Zentrale Systeme
10.1.0.0/161. Schule
10.2.0.0/162. Schule
10.3.0.0/163. Schule
10.4.0.0/164. Schule
10...../16Weitere Schulen


Voraussetzung für die Verwendung von Subnetzen ist, dass aus dem Netz, in dem die zentralen Systeme stehen, alle anderen Subnetze erreicht werden können. Dies kann beispielsweise über ein Site-to-Site VPN oder eine Standleitung realisiert werden. Eine Verbindung zwischen Schulen ist nicht notwendig und wird häufig auch nicht gewünscht.

Anmerkung

Bei mehr als 255 Schulen kann das vorgeschlagene Netzkonzept nicht verwendet werden.

§5.1.1. Beispiele für Subnetzkonzepte

Im Folgenden werden zwei Beispiele für die Schulnetze gezeigt. Das erste für ein Schulnetz für kleinere Schulen mit wenigen Endgeräten, zum Beispiel Grundschulen, das zweite für sehr große Schulen mit vielen Endgeräten und mehreren Subnetzen, zum Beispiel Berufsschulen. Vorweg erfolgt die Definition des Subnetzes für die zentralen Systeme.

Um die Subnetze in UCS@school bekannt zu machen, müssen diese importiert werden. In Abschnitt 9.2 ist beschrieben wie der Import vorzunehmen ist, welche Informationen anzugeben sind und welche Hilfsmittel dafür zur Verfügung stehen.

§

Tabelle 5.2. Zentrales Subnetz

Subnetz (CIDR)DHCP-AdressbereichAnzahl IP-AdressenVerwendung
10.0.0.0/24-254Subnetz für zentrale Systeme


Alle zentralen Instanzen von UCS@school werden in diesem Netz installiert. Auf eine Adressvergabe via DHCP wird verzichtet, alle Systeme erhalten eine statisch zugewiesene IP-Adresse. Weitere Subnetze, wie zum Beispiel eine Demilitarisierte Zone (DMZ), können bei Bedarf ergänzt werden.

§5.1.2. Beispiel Subnetz Grundschule

§

Tabelle 5.3. Netze für Beispiel-Grundschule

Subnetz (CIDR)DHCP-AdressbereichAnzahl IP-AdressenVerwendung
10.1.0.0/2410.1.0.1-10.1.0.254254Kleines Netz für eine Grundschule


In diesem Beispiel werden evtl. vorhandene Server und Endgeräte im selben Netz betrieben. Dieses Modell richtet sich an kleine Schulen mit wenigen Rechnern. Bei Bedarf können weitere Subnetze ergänzt werden, da das für die Schule reservierte Klasse-B Netz nur zu einem kleinen Teil ausgeschöpft wurde.

§5.1.3. Beispiel Subnetz Berufsschule

§

Tabelle 5.4. Netze für Beispiel-Berufsschule

Subnetz (CIDR)DHCP-AdressbereichAnzahl IP-AdressenVerwendung
10.2.1.0/24-254Netz für Server und Netzgeräte, statische IP-Adressen
10.2.2.0/2410.2.2.10-10.2.2.250254Netz für Schulverwaltung, erweiterbar auf /23 (510 IP-Adressen)
10.2.4.0/2410.2.4.10-10.2.4.250254Netz für edukativen Bereich 1, erweiterbar auf /23 (510 IP-Adressen)
10.2.6.0/2410.2.6.10-10.2.6.250254Netz für edukativen Bereich 2, erweiterbar auf /23 (510 IP-Adressen)
10.2.8.0/2410.2.8.10-10.2.8.250254Netz für edukativen Bereich 3, erweiterbar auf /23 (510 IP-Adressen)
10.2.10.0/2410.2.10.10-10.2.10.250254Netz für edukativen Bereich 4, erweiterbar auf /23 (510 IP-Adressen)
10.2.128.0/2010.2.128.100-10.2.143.2504094Gäste WLAN / BYOD, erweiterbar auf /18 (16382 IP-Adressen)
10.2.192.0/2010.2.192.100-10.2.207.2504094Schuleigenes WLAN mit RADIUS-Authentifizierung, erweiterbar auf /18 (16382 IP-Adressen)


In diesem Beispiel werden einzelne Subnetze für WLAN, Server, Verwaltung und edukativen Bereich betrieben. Dieses Modell richtet sich an große Schulen mit vielen Endgeräten. Die Subnetze sind so gewählt, dass sie sich Bedarf noch erweitern lassen. Die Unterteilung des edukativen Bereichs in einzelne Subnetze kann beispielsweise pro Gebäude, pro Etage oder sogar pro Computerraum erfolgen. Netzdrucker können in die Subnetze aufgenommen werden, in denen sich auch die zugehörigen Endgeräte befinden oder es wird ein eigenes Druckernetz hinzugefügt.

§5.2. Konzept zur Benennung von Objekten

In einer UCS@school-Domäne für ein oder mehrere Schulen gibt es viele Objekte, die eindeutige Namen benötigen, so brauchen zum Beispiel Benutzerkonten eindeutige Benutzernamen und E-Mail-Adressen, Schulklassen brauchen eindeutige Bezeichnungen, um sie von gleichnamigen Klassen in anderen Schulen zu unterscheiden, Rechnerobjekte benötigen Rechnernamen und Schulen benötigen eine Kurzbezeichnung für die Organisationseinheit im Verzeichnisdienst, in dem die zugehörigen Objekte gespeichert werden. Ein Konzept zur Benennung von Objekten verfolgt das Ziele, Eindeutigkeit herzustellen und gleichzeitig die Bedeutung und Zuordnung des jeweiligen Objekts offensichtlich zu machen. Im Folgenden zeigen wir Konzepte für unterschiedliche Objekttypen auf, die sich in der Praxis bewährt haben.

§5.2.1. Name der Domäne

für alle Szenarien

Der Name der Domäne definiert mehrere zugehörige Namen: LDAP-Basis des Verzeichnisdienstes, DNS-Domäne, Kerberos-Realm und Samba/Active Directory-Domäne. Die Wahl dieses Namens hat umfangreiche Auswirkungen auf die gesamte UCS@school-Installation und sollte entsprechend mit Bedacht gewählt werden, insbesondere weil eine nachträgliche Änderung nicht möglich ist.

Wird vom Betreiber (z.B. Stadt, Landkreis oder Bundesland) bereits eine DNS-Domäne verwendet (z.B. example.com), empfehlen wir, als Domänennamen für UCS@school eine Subdomäne zu verwenden:

Beispiel: schulen.example.com

Bei der Wahl des Domänennamens sind einige Punkte zu beachten:

  • Es ist wichtig, dass die DNS-Domäne vom Betreiber verwaltet wird. Es muss unter allen Umständen sichergestellt werden, dass der gewählte Domänenname für UCS@school im öffentlichen Internet noch nicht verwendet wurde oder zukünftig wird.

  • Wenn die Verwendung einer öffentlichen DNS-Domäne nicht möglich ist und stattdessen eine selbst gewählter Name verwendet wird, so sind folgende Regeln zu beachten:

    • Offizielle DNS-Domänen sollten nicht verwendet werden, wenn sie nicht unter eigener Kontrolle stehen, z.B. deutschland.de.

    • Inoffiziell verwendete Top-Level-Domänen sollten nicht verwendet werden, zum Beispiel .corp oder .lan. Bei ihnen besteht die Gefahr, dass es zu späteren Namenskollisionen kommt.

    • .local sollte nicht als Top-Level-Domäne gewählt werden. Die Endung ist offiziell für mDNS (Multicast DNS) vorgesehen und führt bei einer Verwendung zu Problemen mit macOS, Windows und Linux-Betriebssystemen.

  • Dem Domänennamen für UCS@school werden die Namen der Rechner und Server vorangestellt, um für diese Systeme einen voll qualifizierten DNS-Namen (FQDN) zu bilden. Zum Beispiel ist der Rechner ucsma-01 somit unter dem FQDN ucsma-01.schulen.example.com zu erreichen.

Es besteht die Möglichkeit den Namen der Samba-/Active Directory-Domäne unabhängig von dem eigentlichen Domänennamen zu definieren. Dies ermöglicht es, dass Benutzer eine andere Domäne bei Anmeldung an Windows Rechnern verwenden können, zum Beispiel wird statt SCHULEN\benutzername nun SCHULTRÄGER\benutzername verwendet. Um dies zu erreichen, ist auf dem UCS@school-Server vor der Installation von UCS@school der gewünschte NetBIOS-Domänenname in der Univention Configuration Registry-Variablen windows/domain zu setzen.

§5.2.2. Zentrale Server

für alle Szenarien

Zentrale Server:

  • Schema: [Rollenbezeichnung]-[Laufnummer]

  • Beispiele:

    • Domänencontroller Master: ucsma-01

    • Domänencontroller Backup: ucsba-02, ucsba-03

    • Domänencontroller Slave: ucssl-04

    • Memberserver: ucsme-05

§5.2.3. Rechner und Schulserver

für Szenario 3 und 4

Rechner:

  • Schema: [Kurzbezeichnung Schule][Betriebssystem][Gebäude/Etage/Raum][Laufnummer]

  • Beispiele: 042win033-001, 042win033-002, 011mac001-011

Netzgeräte, wie Router, Switches, USV, Drucker:

  • Schema: [Kurzbezeichnung Schule][Gerätetyp][Gebäude/Etage/Raum]-[Laufnummer]

  • Beispiele: 042rou001-001, 042swi002-003, 011usv000-001, 012dru002-012

Schulserver:

  • Schema: [Rollenbezeichnung][Kurzbezeichnung Schule]-[Laufnummer]

  • Beispiele:

    • Edukativer Schulserver: sedu042-01

    • Schulserver Schulverwaltung: sadm042-01

§5.2.4. Benutzernamen und Klassenbezeichnungen

für alle Szenarien

Benutzerkonten und Klassen hängen in UCS@school sehr eng zusammen. So werden beim Import von Benutzerkonten ebenfalls die Klassen angegeben, zu denen die jeweiligen Konten gehören. Das heißt sowohl beim Import von Klassen, also auch beim Import von Benutzerkonten müssen die gleichen Bezeichnungen für Klassen verwendet werden und es ist deshalb hilfreich, ein einheitliches Schema zu spezifizieren.

Bei Benutzerkonten ergibt sich darüber hinaus die Herausforderung, dass sich die Benutzernamen ggf. ändern, zum Beispiel aufgrund der Behebung von Tippfehlern, Heirat oder Scheidung. In der Praxis hat sich nicht bewährt, unveränderliche Daten, wie Personal- oder Schülernummern als Benutzernamen zu verwenden, da diese unpersönlich und schwer zu merken sind.

Die Änderung von Benutzernamen stellt eine große Herausforderung im Betrieb dar, weil die an UCS@school angeschlossenen Subsysteme ggf. den Benutzernamen als identifizierendes Merkmal (also zur Zuordnung von Daten zu Benutzerkonten) verwenden. Beispiele für Subsysteme sind E-Maildienste, Dateifreigaben und -tauschsysteme oder Lernplattformen. Ändert sich der Benutzername, müssen in den Subsystemen ggf. aufwendig Daten dem neuen Benutzernamen zugeordnet werden. Dieses Problem kann umgangen werden, wenn frühzeitig, vor der Einführung eines neuen Subsystems darauf geachtet wird, dass die Zuordnung von Daten zu Benutzerkonten über ein unveränderliches Merkmal geschieht, zum Beispiel die Personalnummer. Gleichzeitig muss sichergestellt werden, dass die Anmeldung am Subsystem jedoch über den einfach zu merkenden Benutzernamen erfolgt.

Schüler:

  • Schema: [Vorname][1. Buchstabe Nachname][Laufnummer]

  • Beispiel: Mary Selig → marys

  • Beispiel Namenskonflikt: Mary Sandermarys2

Lehrkräfte und Mitarbeiter:

  • Schema: [1. Buchstabe Vorname][Nachname][Laufnummer]

  • Beispiel: Mareike Müllermmueller

  • Beispiel Namenskonflikt: Martina Müllermmueller2

Für Benutzerkonten kann das gewünschte Schema im Importmechanismus hinterlegt werden, siehe UCS@school-Handbuch zur CLI-Import-Schnittstelle.

Klassenname müssen mit der Kurzbezeichnung der Schule als Präfix beginnen:

  • Schema: [Kurzbezeichnung Schule]-[Klasse]

  • Beispiele: 042-1a, 042-5a, 011-5a, 011-5b

§5.2.5. Allgemeine Konventionen

für alle Szenarien

Folgende Konventionen haben sich in allen Szenarien bewährt:

  • Alle Objektnamen sollten durchgängig Kleinbuchstaben verwenden.

  • Die Länge von Objektnamen sollte 15 Zeichen nicht überschreiten. Dies ist insbesondere wichtig für Benutzernamen.

§5.3. Monitoring

für alle Szenarien

Die rechtzeitige Erkennung von Fehlern und möglichen Anzeichen ist ein elementarer Bestandteil des professionellen IT-Betriebs. Univention Corporate Server hat deshalb die Monitoring-Software Nagios fest integriert und für viele relevante Parameter vorkonfiguriert. Nagios selbst dient zum Monitoring des aktuellen Zustands.

Das Monitoring erfolgt für UCS@school immer aus der Zentrale heraus. Entsprechend ist ein Server-System für den Betrieb des Monitoring-Dienstes vorzusehen, siehe Abschnitt 7.5.

Nagios selbst ist nicht darauf ausgelegt, Informationen darüber zu liefern, in welche Richtung sich eine Umgebung entwickelt, da keine Langzeitinformationen gespeichert werden. Ein Beispiel ist die Entwicklung der Belegung des Festplattenplatzes. Solche Informationen sind für den Betrieb einer umfangreichen IT-Infrastruktur erforderlich. Um diese Informationen zu erfassen, kann zum Beispiel Munin verwendet werden, dessen Einrichtung für Univention Corporate Server dokumentiert ist.

§5.4. Datensicherung und Wiederherstellung

für alle Szenarien

Eine zentral mit UCS@school verwaltete Umgebung stellt üblicherweise Dienste für tausende Personen zur Verfügung. Mit der zunehmenden Anforderung nach orts- und zeitunabhängiger Verfügbarkeit muss sichergestellt werden, dass nicht nur die Dienste, sondern auch die Daten den Anforderungen entsprechend zur Verfügung gestellt werden. Dreierlei Daten sind dabei zu unterscheiden:

  • Konfigurationen und Einstellungen, die Administratoren vorgenommen haben

  • Steuerinformationen, zum Beispiel die Daten im Identitätsmanagement

  • Von Personen erzeugte Daten, zum Beispiel E-Mails

Die Sicherung der Daten muss gewährleistet sein, um im Fehlerfall die Funktionsfähigkeit wiederherzustellen. Als Minimalumfang muss eine Datei-basierte Sicherung, zum Beispiel mit Hilfe des Befehls rsync erfolgen. Folgende Daten sollten in der Sicherung berücksichtigt werden:

Zentrale Server:

  • /var/univention-backup: Nächtliche Sicherung der Univention Configuration Registry-, OpenLDAP- und Samba-Datenbank sowie der Inhalte der SYSVOL-Freigabe

  • /etc/univention/ssl auf dem Domänencontroller Master und den Domänencontroller Backup-Servern: Beinhaltet das Root-Zertifikat der internen Zertifizierungsstelle und alle Rechner-Zertifikate

Schulserver, sofern vorhanden:

  • /var/univention-backup: Nächtliche Sicherung der Univention Configuration Registry. Die Sicherung der OpenLDAP- und Samba-Datenbanken braucht normalerweise nicht gesichert zu werden, da diese beim erneuten Domänenbeitritt des Schulservers vom Domänencontroller Master oder Domänencontroller Backup repliziert werden

  • /home: Beinhaltet die Benutzerprofile und die Heimatlaufwerke der Benutzer, sowie die Freigaben der Klassen und Arbeitsgruppen

Folgende Punkte haben sich als allgemein bewährtes Vorgehen herauskristallisiert:

  • Die Datensicherung sollte auf ein vom Univention Corporate Server-System physikalisch getrenntes Gerät erfolgen, zum Beispiel ein Network Attached Storage (NAS).

  • Die Datensicherung sollte überwacht werden, zum Beispiel durch ein Plugin im Monitoring-Dienst, das bei Misserfolg warnt.

  • Die Wiederherstellung sollte in regelmäßigen Abständen getestet werden.

§5.5. Support-Kanäle

für alle Szenarien

Für den erfolgreichen Betrieb von UCS@school ist es erforderlich, dass ein Helpdesk aufgebaut wird, der Fragen aus den Schulen direkt annehmen kann. Abhängig von der gewünschten Servicestufe kann es darüber hinaus notwendig sein, ein Team von technischen Mitarbeitern zu schulen, die den Betrieb der Umgebung durchführen.

Neben passenden Werkzeugen zur Kommunikation und Fernwartung, zum Beispiel ein Ticket-System wie KIX aus dem Univention App Center, müssen auch die Support- und Eskalationswege definiert und abgestimmt werden. Im Folgenden ein Beispiel für Eskalationswege:

  • IT-Verantwortliche an den Schulen kontaktieren den Helpdesk über das Helpdesk-Modul in UCS@school oder direkt per E-Mail an das Ticketsystem. In dringenden Fällen steht eine Hotline zur Verfügung, die telefonisch erreicht werden kann.

  • Der Helpdesk übernimmt den First- und Second-Level-Support, ggf. in Zusammenarbeit mit einem lokalen Dienstleister.

  • In weitergehenden Fällen unterstützt Univention mit Third-Level-Support.

§Kapitel 6. Netzinfrastruktur- und Hardware-Voraussetzungen

Im Folgenden werden die Netzinfrastruktur- und Hardware-Voraussetzungen für den Einsatz von UCS@school beschrieben. Die beschriebenen Voraussetzungen sind Richtwerte, die wir ermittelt haben. Im Einzelfall ist jedoch genau zu prüfen, ob die Voraussetzungen mit den gestellten Anforderungen übereinstimmen.

Allgemein hat sich für den Betrieb von Univention Corporate Server bewährt, eine Virtualisierungslösung einzusetzen. Die Dimensionierung der Virtualisierungsserver muss sich dabei an den Anforderungen der virtualisierten Systeme richten und dabei noch genügend Möglichkeiten zur nachträglichen Erweiterung bereithalten. Eine Zuweisung von mehr als den vorhandenen Ressourcen (Überprovisionierung) wird abgeraten. Für den Speicherplatz sollten mindestens SAS-Festplatten mit 10.000 Umdrehungen pro Minute zum Einsatz kommen.

Die genannten Werte sind die Minimalanforderungen für die oben beschriebenen Szenarien. Abhängig von der Größe der Umgebung und Anzahl der aktiven Geräte und Personen können die Anforderungen höher liegen. Die tatsächliche Auslastung der einzelnen Systeme sollte fortlaufend durch das Monitoring überwacht werden, um Engpässe zu vermeiden. Im Folgenden werden die Server, ihre Funktionen und die jeweiligen Anforderungen beschrieben.

§6.1. Zentrale Server

§6.1.1. Identity Management

für alle Szenarien

Systeme vom Typ Domänencontroller Master und Domänencontroller Backup stellen das Identitätsmanagement mit der zugrunde liegenden LDAP-Datenbank zur Verfügung.

Minimale Systemvoraussetzungen:

  • 4 CPU-Kerne

  • 8 GB RAM

  • 100 GB Speicherplatz

Die primären Lastszenarien des Domänencontroller Master sind:

  • Viele lesende Zugriffe auf die LDAP-Datenbank, da neben der Administration alle weiteren Systeme regelmäßig Information abfragen.

  • Schreibende Zugriffe auf die LDAP-Datenbank, sobald Änderungen vorgenommen werden. Insbesondere beim initialen Import und beim Schuljahreswechsel wird die LDAP-Datenbank stark belastet.

Die I/O-Performance der Festplatten dieser Server ist besonders wichtig, zusammen mit ausreichend Arbeitsspeicher, der insbesondere beim initialen Import und beim Schuljahreswechsel notwendig ist.

Domänencontroller Backup dienen der Lastverteilung und Ausfallsicherheit. Es sollte immer mindestens ein Domänencontroller Backup in der Domäne vorhanden sein. Darüber hinaus können bei Bedarf weitere Domänencontroller Backup-Systeme hinzugefügt werden.

Sollte der Domänencontroller Master durch einen irreparablen Schaden ausfallen, kann ein Domänencontroller Backup-System zum Domänencontroller Master hochgestuft werden. Dieser Vorgang ist nicht umkehrbar, daher sollte die Position der Domänencontroller Backup-Systeme innerhalb der Netzinfrastruktur entsprechend gewählt werden, damit jedes einzelne System im Extremfall alle Aufgaben des Domänencontroller Master übernehmen kann.

§6.1.2. RADIUS

für Szenario 2, 3 und 4

Minimale Systemvoraussetzungen:

  • 2 CPU-Kerne

  • 4 GB RAM

  • 50 GB Speicherplatz

§6.1.3. Monitoring

für alle Szenarien

Minimale Systemvoraussetzungen:

  • 2 CPU-Kerne

  • 4 GB RAM

  • 50 GB Speicherplatz

§6.1.4. IT-Angebote, wie Groupware und Lernplattformen

für alle Szenarien

Für weitere IT-Angebote können keine Minimalanforderungen genannt werden, da diese sowohl von der Anzahl der parallelen Benutzer als auch von dem IT-Angebot selbst abhängig sind. Eine Abstimmung mit dem Hersteller ist insbesondere bei Angeboten notwendig, die von allen Personen, die ein Benutzerkonto in der Umgebung haben, genutzt werden.

§6.2. Dezentrale Systeme

§6.2.1. Schulserver

für Szenario 3 und 4

Minimale Systemvoraussetzungen für kleine Schulen (z.B. Grundschulen) (25 Computer, 25 Tablets, 150 Benutzerkonten):

  • 2 CPU-Kerne

  • 4 GB RAM

  • 100 GB Speicherplatz für das System selbst

  • bis zu 100 GB Speicherplatz für Benutzerdaten

Minimale Systemvoraussetzungen für mittelgroße Schulen (100 Computer, 100 Tablets, 600 Benutzerkonten):

  • 4 CPU-Kerne

  • 16 GB RAM

  • 100 GB Speicherplatz für das System selbst

  • ab 400 GB Speicherplatz für Benutzerdaten

Minimale Systemvoraussetzungen für große Schule (z.B. Berufsschulen) (300 Computer, 200 Tablets, 1500 Benutzerkonten):

  • 8 CPU-Kerne

  • 32 GB RAM

  • 100 GB Speicherplatz für das System selbst

  • ab 1.000 GB Speicherplatz für Benutzerdaten

§6.3. Netzinfrastruktur

§6.3.1. Strukturierte Verkabelung

für Szenario 2, 3 und 4

Die Schulen sollten über eine strukturierte Verkabelung im Schulgebäude verfügen. Dies schließt ein, dass möglichst nur Switches und Netzkomponenten mit Management-Funktion verwendet werden. Damit werden Probleme vermieden, die durch fehlerhafte Verkabelung entstehen und es wird möglich, die Qualität der erbrachten Leistung bis auf Ebene des Netzes zu messen. Darüber hinaus können Sicherheitsmechanismen implementiert werden, die bei zunehmender Verwendung der IT-Infrastruktur immer wichtiger werden.

§6.3.2. WLAN-Infrastruktur

für Szenario 2, 3 und 4

Für die Einführung von WLAN in Schulen gehen wir hier davon aus, dass die gesamte Schule mit WLAN ausgestattet werden soll und alle Schüler mit mindestens einem mobilen Endgerät im WLAN aktiv sein werden, auch wenn dies nicht sofort realisiert werden kann.

Um dieses Ziel zu erreichen, ist eine strukturierte Verkabelung Grundvoraussetzung. Darüber hinaus werden professionelle Access Points benötigt, die mehr als 40 parallel eingebuchte mobile Geräte unterstützen, ohne dass der Access Point z.B. aufgrund von Speichermangel abstürzt. Mit professionellen Access Points lassen sich darüber hinaus auch weitere Sicherheits- und Administrationsmechanismen, wie VLAN, realisieren.

§6.3.3. Internetzugang

für Szenario 2 und 3

Die Schulen sollten über zuverlässige Internetzugänge verfügen, die maximal 1x pro Nacht getrennt werden. Die Geschwindigkeit des Zugangs sollte mindestens 6 MBit/s betragen. Ausschlaggebend für die notwendige Geschwindigkeit ist die Anzahl der gleichzeitig aktiven Endgeräte. Als Richtwert kann von einem Bedarf von mindestens 0,3 MBit/s pro aktivem Gerät ausgegangen werden. Dies ist insbesondere bei der Einführung von WLAN und Bring Your Own Device (BYOD) zu beachten, da Lehrkräfte und Schüler ggf. mehr als ein Gerät pro Person mitbringen werden.

§6.3.4. Internetzugang: Schulserver im Rechenzentrum

für Szenario 4

Die folgende Schätzung der Bandbreite gilt ausschließlich für Szenario 4, in dem alle Schulserver aus den Schulen in ein zentrales Rechenzentrum überführt werden. In den Schulen verbleiben nur die Endgeräte, die zur Nutzung der IT notwendig sind. Die Anforderungen der anderen Szenarien sind in Abschnitt 6.3.3 beschrieben.

Die nötigen Bandbreiten im lokalen Schulnetz können je nach Anwendungsfall stark schwanken. Die folgende Tabelle gibt einen groben Überblick über Richtwerte nach Schultyp. Die benötigte Bandbreite liegt zwischen 1-3 MBit/s für schuleigene Geräte. Dabei ist zu beachten, dass z.B. zum Schulstundenbeginn oder zum Pausenbeginn mit Lastspitzen zu rechnen ist.

§

Tabelle 6.1. Grobe Richtwerte für die Anbindung nach Schultyp

SchultypTypische Anzahl ClientsTypische NetznutzungNötige Bandbreite
Grundschulen~20 ClientsGeringe Netznutzung (~1 MBit/s)20 MBit/s
Weiterführende Schulen~90 ClientsMittlere Netznutzung (~2 MBit/s)180 MBit/s
Berufsschulen~300 ClientsHohe Netznutzung (>3 MBit/s)1 GBit/s


§6.3.5. Verbindung zur Zentrale

für Szenario 2, 3 und 4

Die Schulen müssen an die zentralen Systeme angebunden werden, damit eine Steuerung der Netze, Endgeräte und ggf. Server von zentraler Stelle möglich wird. Um die Verbindung aufzubauen, können VPN-Technologien, Standleitungen oder private Netze verwendet werden.

Die Bandbreite der verfügbaren Anbindung beeinflusst entscheidend die möglichen Szenarien. Szenario 4 ist zum Beispiel nur bei einer sehr guten Anbindung im Bereich von 1 GBit/s oder mehr sinnvoll möglich. Bei VPN über handelsübliche DSL-Leitungen empfiehlt sich stattdessen die Umsetzung von Szenario 3.

§Kapitel 7. Installation

Die Installation von UCS@school ist grundlegend im Handbuch zu Univention Corporate Server und im UCS@school Handbuch für Administratoren beschrieben. In diesem Abschnitt geben wir zusätzliche Hinweise zur Installation, insbesondere im Hinblick auf die Umsetzung der definierten Konzepte.

  • Zur Installation sollte das aktuellste Univention Corporate Server Installationsmedium verwendet werden.

  • Der Pfad /var/log sollte auf eine eigene Partition gelegt werden, damit bei erhöhten Aufkommen an Log-Informationen nicht die Systempartition voll läuft und in der Folge die Funktionsfähigkeit des Gesamtsystems zusammenbricht.

  • Je nach System und verwendeten Diensten sollte die Auslagerung auf einem eigenen Dateisystem auch für den Pfad /home erfolgen.

§7.1. Installation des Domänencontroller Master

für alle Szenarien

  • Die IP-Adresskonfiguration erfolgt entsprechend dem Netzkonzept.

  • Als Externer DNS-Server bzw. DNS-Forwarder ist die IP-Adresse des DNS-Servers des Internetproviders einzutragen.

  • Die folgende Option ist auszuwählen, um den Domänencontroller Master zu installieren: Erstellen einer neuen Univention Corporate Server-Domäne

  • Nach der Eingabe des Domänennamen wird automatisch eine LDAP-Basis vorgeschlagen. Diese sollte nur in Ausnahmefällen geändert werden.

  • für Szenario 3 und 4

    Um Gruppenrichtlinien für alle Schulen über eine zentrale Stelle verwalten zu können, ist die Software-Komponente Active Directory kompatibler Domänen-Controller bei der Installation auszuwählen. Sollen in der UCS@school-Domäne mehr als 50.000 Benutzer verwaltet werden, setzen Sie sich bitte vorab mit Univention in Verbindung, um Möglichkeiten zur Performanceoptimierung zu besprechen.

  • Das installierte System ist abschließend bis zum letzten verfügbaren Errata-Update zu aktualisieren.

  • Nach Abschluss der Installation ist über das Univention App Center die App UCS@school zu installieren.

  • Im Anschluss an die Installation der UCS@school App ist in der Univention Management Console in der Kategorie Schuladministration der UCS@school Einrichtungsassistent zu starten und die Option "Multi-Server Umgebung" zu wählen und der Assistent bis zum Ende auszuführen.

  • Abschließend ist zu prüfen, ob alle Joinskripte erfolgreich ausgeführt wurden. Dies kann in der Univention Management Console in der Kategorie Domäne mit dem Modul Domänenbeitritt geprüft werden.

§7.2. Installation eines Domänencontroller Backup

für alle Szenarien

Zur Lastverteilung bei der LDAP-Replikation können neben dem ersten, unbedingt notwendigen Domänencontroller Backup Server zusätzlich noch weitere Domänencontroller Backup Systeme aufgesetzt werden.

  • Es ist sicherzustellen, dass zuvor auf dem Domänencontroller Master alle verfügbaren Updates installiert wurden.

  • Die IP-Adresskonfiguration erfolgt entsprechend des Netzkonzepts.

  • Als DNS-Server ist die IP-Adresse des Domänencontroller Master einzutragen. Der DNS-Forwarder wird beim Domänenbeitritt automatisch vom Domänencontroller Master übernommen und braucht somit nicht eingetragen zu werden.

  • Die folgende Option ist auszuwählen, um den Domänencontroller Backup als Mitglied der Domäne zu installieren: Einer bestehenden Univention Corporate Server-Domäne beitreten. Anschließend ist die Rolle Domänencontroller Backup auszuwählen.

  • Das installierte System ist abschließend bis zum letzten verfügbaren Errata-Update zu aktualisieren. Anschließend ist der Domänenbeitritt zu starten.

  • Nach Abschluss der Installation ist über das Univention App Center die UCS@school App zu installieren.

  • Im Anschluss an die Installation der UCS@school App ist in der Univention Management Console in der Kategorie Schuladministration der UCS@school Einrichtungsassistent zu starten und der Assistent bis zum Ende auszuführen.

  • Abschließend ist zu prüfen, ob alle Joinskripte erfolgreich ausgeführt wurden. Dies kann in der Univention Management Console in der Kategorie Domäne mit dem Modul Domänenbeitritt geprüft werden.

§7.3. Installation eines Domänencontroller Slave als Schulserver

für Szenario 3

  • Es ist sicherzustellen, dass zuvor auf dem Domänencontroller Master alle verfügbaren Updates installiert wurden.

  • Bei der Partitionierung sollte darauf geachtet werden, dass der Pfad /home auf einem eigenen Dateisystem abgelegt wird, damit aufgrund von übermäßig viele Benutzerdaten die Systempartition nicht voll läuft.

  • Die IP-Adresskonfiguration erfolgt entsprechend des Netzkonzepts.

  • Als DNS-Server sind die IP-Adressen des Domänencontroller Master und des Domänencontroller Backup einzutragen. Der DNS-Forwarder wird beim Domänenbeitritt automatisch vom Domänencontroller Master übernommen und braucht somit nicht eingetragen zu werden.

  • Die folgende Option ist auszuwählen, um den Domänencontroller Slave als Mitglied der Domäne zu installieren: Einer bestehenden Univention Corporate Server-Domäne beitreten. Anschließend ist die Rolle Domänencontroller Slave auszuwählen.

  • Das installierte System ist abschließend bis zum letzten verfügbaren Errata-Update zu aktualisieren. Anschließend ist der Domänenbeitritt zu starten.

  • Nach Abschluss der Installation ist über das Univention App Center die App UCS@school zu installieren.

  • Im Anschluss an die Installation der UCS@school App ist in der Univention Management Console in der Kategorie Schuladministration der UCS@school Einrichtungsassistent zu starten und der Assistent bis zum Ende auszuführen.

  • Abschließend ist zu prüfen, ob alle Joinskripte erfolgreich ausgeführt wurden. Dies kann in der Univention Management Console in der Kategorie Domäne mit dem Modul Domänenbeitritt geprüft werden.

Weitere Hinweise zur Installation eines Schulservers und zum UCS@school Einrichtungsassistent finden sich auch im UCS@school Handbuch für Administratoren.

§7.4. Installation eines Domänencontroller Slave für RADIUS, Groupware, Collaboration, Lernplattformen usw.

für alle Szenarien

Nach Möglichkeit sollte für jeden Dienst ein separater Server mit der Rolle Domänencontroller Slave verwendet werden.

  • Es ist sicherzustellen, dass zuvor auf dem Domänencontroller Master alle verfügbaren Updates installiert wurden.

  • Die IP-Adresskonfiguration erfolgt entsprechend des Netzkonzepts.

  • Als DNS-Server sind die IP-Adressen des Domänencontroller Master und des Domänencontroller Backup einzutragen. Der DNS-Forwarder wird beim Domänenbeitritt automatisch vom Domänencontroller Master übernommen und braucht somit nicht eingetragen zu werden.

  • Die folgende Option ist auszuwählen, um den Domänencontroller Slave als Mitglied der Domäne zu installieren: Einer bestehenden Univention Corporate Server-Domäne beitreten. Anschließend ist die Rolle Domänencontroller Slave auszuwählen.

  • Das installierte System ist abschließend bis zum letzten verfügbaren Errata-Update zu aktualisieren. Anschließend ist der Domänenbeitritt zu starten.

  • Nach Abschluss der Installation ist über das Univention App Center die gewünschte App, zum Beispiel RADIUS, zu installieren.

  • Die App UCS@school darf nicht installiert werden!

  • Abschließend ist zu prüfen, ob alle Joinskripte erfolgreich ausgeführt wurden. Dies kann in der Univention Management Console in der Kategorie Domäne mit dem Modul Domänenbeitritt geprüft werden.

§7.5. Installation eines Memberserver für Monitoring

für alle Szenarien

  • Es ist sicherzustellen, dass zuvor auf dem Domänencontroller Master alle verfügbaren Updates installiert wurden.

  • Die IP-Adresskonfiguration erfolgt entsprechend des Netzkonzepts.

  • Als DNS-Server sind die IP-Adressen des Domänencontroller Master und des Domänencontroller Backup einzutragen. Der DNS-Forwarder wird beim Domänenbeitritt automatisch vom Domänencontroller Master übernommen und braucht somit nicht eingetragen zu werden.

  • Die folgende Option ist auszuwählen, um den Domänencontroller Slave als Mitglied der Domäne zu installieren: Einer bestehenden Univention Corporate Server-Domäne beitreten. Anschließend ist die Rolle Memberserver auszuwählen.

  • Es ist sicherzustellen, dass der Domänencontroller Master alle verfügbaren Updates installiert hat.

  • Das installierte System ist abschließend bis zum letzten verfügbaren Errata-Update zu aktualisieren. Anschließend ist der Domänenbeitritt zu starten.

  • Nach Abschluss der Installation ist über das Univention App Center die App Icinga, zu installieren.

  • Es ist empfohlen, das Monitoring des aktuellen Zustands der Umgebung um die Speicherung von Langzeitinformationen zu ergänzen. Weitere Informationen sind in Abschnitt 5.3 zu finden.

  • Die App UCS@school darf nicht installiert werden!

  • Abschließend ist zu prüfen, ob alle Joinskripte erfolgreich ausgeführt wurden. Dies kann in der Univention Management Console in der Kategorie Domäne mit dem Modul Domänenbeitritt geprüft werden.

  • Damit Icinga und Munin lauffähig sind, muss sichergestellt sein, dass die globale Univention Configuration Registry-Richtlinie ucsschool-ucr-settings auf alle anderen Systeme wirkt. Dies kann überprüft werden, in dem die Werte der Univention Configuration Registry-Variablen nagios/client/allowedhosts und munin/node/allowedhosts auf den anderen Servern gesetzt werden. Sollten trotzdem keine Statusinformationen über einen Server angezeigt werden, so müssen ggf. die Dienste univention-directory-listener, nagios-nrpe-server und munin-node neu gestartet werden.

§Kapitel 8. Basiskonfiguration

für alle Szenarien

Folgende Konfiguration müssen vor dem Anlegen der ersten Schulen umgesetzt werden:

§8.1. Zustellung von Systemmails

Univention Corporate Server verschickt regelmäßig E-Mails, um aktuelle Ereignisse aus dem Monitoring und Ergebnisse von Routineaufgaben zu kommunizieren. Diese E-Mails sind für den Betrieb von großer Wichtigkeit und müssen unbedingt beachtet werden. Damit diese E-Mail zugestellt werden können, ist der E-Mailversand wie folgt zu konfigurieren. Um eine einfache und homogene Konfiguration der Univention Configuration Registry-Variablen zu erreichen, sollten Univention Configuration Registry-Richtlinien verwendet werden.

  1. E-Mailalias für root auf ein System stellen/umleiten: Wenn zum Beispiel alle E-Mails an den Benutzer root an den Domänencontroller Master umgeleitet werden sollen, ist die Univention Configuration Registry-Variable mail/alias/root auf den Wert root@ucsma-01.schulen.example.com zu stellen. schulen.example.com muss durch den tatsächlichen Domänennamen ersetzt werden.

  2. Anschließend ist auf dem Zielsystem, in diesem Beispiel auf dem Domänencontroller Master, die Zieladresse für alle E-Mails an root zu hinterlegen. Die E-Mailadresse wird ebenfalls über Univention Configuration Registry-Variable mail/alias/root festgelegt, zum Beispiel admins@example.org.

  3. Damit das Zielsystem die E-Mail annehmen kann, ist auf dem Zielsystem die App Mailserver zu installieren. Außerdem ist der Zugang zu einem entfernten Mailserver zu konfigurieren, über den die E-Mails zugestellt werden können. Die Konfiguration dieses sogenannten Relayhosts ist im Univention Corporate Server-Handbuch beschrieben.

  4. Mit dieser Konfiguration werden alle E-Mails, die auf einem beliebigen Server an den Benutzer root geschickt werden, an die konfigurierte E-Mailadresse weitergeleitet. Es ist sinnvoll zu prüfen, ob es weitere lokale Konten von Systembenutzern gibt, die E-Mails erhalten. Diese sollte alle auf den Benutzer root umgeleitet werden. Insbesondere sind die Univention Configuration Registry-Variablen mail/alias/postmaster und mail/alias/webmaster auf den Wert root zu setzen.

§8.2. Globale Univention Configuration Registry-Richtlinie

Die globale Univention Configuration Registry-Richtlinie wird in der Univention Management Console über die Kategorie Domäne und das Modul Richtlinien bearbeitet. Die Richtlinie hat den Namen ucsschool-ucr-settings und ist vom Typ Univention Configuration Registry. Um folgende Einträge sollte die Richtlinie erweitert werden:

§

Tabelle 8.1. Zuteilung der Subnetze zu Schulen

Univention Configuration Registry-VariableWertBeschreibung
directory/manager/web/modules/autosearch0Deaktiviert die automatische Suche nach allen Objekten beim Öffnen der Univention Directory Manager-Module. Dies beschleunigt das Arbeiten mit vielen LDAP-Objekten.
ucsschool/wizards/autosearchfalseDeaktiviert die automatische Suche nach allen Objekten beim Öffnen der UCS@school-Module. Dies beschleunigt das Arbeiten mit vielen LDAP-Objekten.
samba4/sysvol/sync/from_downstreamfalseKonfiguriert die SYSVOL-Replikation unidirektional vom Domänencontroller Master zu den UCS@school Schulservern. Dies beugt Problemen mit der Replikation vor.
nagios/client/allowedhosts[IP-Adresse des Monitoring Servers, zum Beispiel 10.0.0.20]Erlaubt den Zugriff des Monitoring-Servers, Nagios oder Icinga, auf den NRPE-Dienst der übrigen Systeme.
munin/node/allowedhosts[IP-Adresse des Monitoring Servers, zum Beispiel 10.0.0.20/32]Erlaubt den Zugriff des Monitoring-Servers, Munin, auf die Munin Nodes der übrigen Systeme (Achtung CIDR Notation!).
ucsschool/helpdesk/recipient[E-Mailadresse des Helpdesks, zum Beispiel admins@example.org]Definiert die E-Mailadresse, an die Nachrichten vom UCS@school Helpdesk-Modul geschickt werden. Die Zustellung sollte unbedingt getestet werden! Siehe auch Abschnitt 8.1.
mail/alias/root[E-Mailadresse des Betreibers, zum Beispiel admins@example.org]Definiert die E-Mailadresse für Systemmails (Cron / Monitoring). Die Zustellung sollte unbedingt getestet werden! Siehe auch Abschnitt 8.1.
ucsschool/import/generate/policy/dhcp/dns/set_per_oufalseVerhindert das automatische Anlegen bestimmter DHCP-DNS-Richtlinien für den Edukativ-Bereich der Schulen. Bei der Verwendung des Verwaltungsnetzes ist dies hinderlich. Die notwendigen DHCP-Richtlinien werden später durch den Netzimport korrekt angelegt


§8.3. Zentrale Univention Configuration Registry-Richtlinie

Eine Univention Configuration Registry-Richtlinie für die zentralen Server wird benötigt, um sicherzustellen, dass die Konfigurationen der Server gleichartig sind. Dazu ist in der Univention Management Console über die Kategorie Domäne und das Modul Richtlinien zu öffnen und die zentrale Richtlinie anzulegen.

Dazu wird eine neue Richtlinie vom Typ Univention Configuration Registry im Container policies/config-registry erstellt. Die Richtlinie soll ucr_central heißen und folgende Einträge enthalten:

§

Tabelle 8.2. UCR-Variablen zur Zeitserver-Konfiguration

Univention Configuration Registry-VariableWertBeschreibung
timeserver[FQDN oder IP-Adresse des ersten externen Zeitservers] Zeitserver von dem die gesamte Domäne ihre Uhrzeit bezieht. Beispiele: ptbtime1.ptb.de oder 0.europe.pool.ntp.org.
timeserver2[FQDN oder IP-Adresse des zweiten externen Zeitservers] Zeitserver von dem die gesamte Domäne ihre Uhrzeit bezieht. Beispiele: ptbtime1.ptb.de oder 0.europe.pool.ntp.org.
timeserver3[FQDN oder IP-Adresse des dritten externen Zeitservers] Zeitserver von dem die gesamte Domäne ihre Uhrzeit bezieht. Beispiele: ptbtime1.ptb.de oder 0.europe.pool.ntp.org.


Anmerkung

Die UCS@school Schulserver setzen automatisch den Domänencontroller Master und die Domänencontroller Backup-Server als Zeitserver. Damit wird automatisch eine Kaskadierung erreicht.

Abschließend ist die Richtlinie mit den zentralen Servern zu verknüpfen. In der Univention Management Console ist dazu in der Kategorie Domäne das Modul LDAP-Verzeichnis auszuwählen und der Container computers zu öffnen. Nun ist mit der rechten Maustaste der Container anzuklicken und die Option Bearbeiten zu selektieren.

Auf Reiter Richtlinien ist nun der Punkt Richtlinie: Univention Configuration Registry zu öffnen und als dem Dropdown Richtlinien-Konfiguration die eben erstellte Richtlinie ucr_central auszuwählen.

Die Richtlinie wird nun auf alle Systeme unterhalb des Containers computer vererbt.

§Kapitel 9. Datenimport

Nach Abschluss der Installation der zentralen Systeme sind die Daten in das LDAP-Verzeichnis zu importieren, die für die Einrichtung und den Betrieb von Schulen benötigt werden. Dies sind Informationen über die Schulen, die IP-Netze, Benutzerkonten und weitere Objekte.

Der Datenimport sollte erfolgen, bevor Schulserver und Rechner ausgerollt werden. Weiterhin sollten die unterschiedlichen Daten in der Reihenfolge importiert werden, wie sie in diesem Kapitel vorgegeben ist. Darüber hinaus sollten die Daten, die in CSV-Dateien gespeichert werden, für die spätere Analyse und Überarbeitung gesichert abgelegt werden.

§9.1. Schulen

für alle Szenarien

Im ersten Schritt werden die Schulen importiert. Durch den Datenimport wird im LDAP-Verzeichnis die Container-Struktur erstellt, die für die späteren Importe benötigt wird. Um alle Schulen in einem Schritt zu importieren, ist eine CSV-Datei zu erstellen.

Das Vorgehen zum Import ist wie folgt:

  • Vorlage für den Import öffnen und Tabelle Schulen ausfüllen.

    §

    Abbildung 9.1. Tabelle: Schulen

    Tabelle: Schulen


  • Export der Tabelle ins CSV-Format mit Tabulator als Trennzeichen für Felder und ohne Trennzeichen für Texte.

    §

    Abbildung 9.2. Kopie speichern als CSV-Datei

    Kopie speichern als CSV-Datei


    §

    Abbildung 9.3. Export Parameter

    Export Parameter


  • Die CSV-Datei schulen.csv ist auf dem Domänencontroller Master in folgendem Verzeichnis abzulegen: /usr/local/ucsschool/import_data/

  • Um die CSV-Datei weiterverarbeiten zu können, muss sie im Unix-Format vorliegen. Sollte sie auf unter Windows oder macOS gespeichert worden sein, so muss sie konvertiert werden. Dazu ist auf dem Domänencontroller Master der folgende Befehl auf die Datei anzuwenden:

    dos2unix schulen.csv

    Vorweg muss das Paket dos2unix installiert werden, indem das unmaintained-Repository aktiviert wird, siehe Konfiguration des Repository-Servers. Nach der Aktivierung des Repositories ist der folgende Befehl zu Installation des Pakets auszuführen:

    univention-install dos2unix

  • Die CSV-Datei aus der Vorlage enthält noch zwei Kopfzeilen, die mit dem Zeichen # beginnen, diese müssen vor der weiteren Verarbeitung entfernt werden:

    sed -i '1,2d' /usr/local/ucsschool/import_data/schulen.csv

  • Zum automatisierten Einlesen aller Schulen ist einmalig ein Skript zu erstellen. Dazu sind folgende Befehle auszuführen, um das Skript anzulegen:

    mkdir -p /usr/local/bin/ucsschool/helper_scripts/
    touch /usr/local/bin/ucsschool/helper_scripts/import_schools.sh
    chmod a+x /usr/local/bin/ucsschool/helper_scripts/import_schools.sh
    nano /usr/local/bin/ucsschool/helper_scripts/import_schools.sh

    Der folgende Programmtext ist zu kopieren und einzufügen. Abschließend ist mit den Tastenkürzeln Strg-O und Strg-X die Datei zu speichern.

    #!/bin/bash
    IFS=$'\t'
    while read schoolid fullname serveredu serveradm; do
    /usr/share/ucs-school-import/scripts/create_ou \
        --displayName="${fullname}" "${schoolid}" \
        "${serveredu}" "${serveradm}"
    done < "$1"

  • Der Import kann abschließend mit folgendem Befehl ausgeführt werden:

    /usr/local/bin/ucsschool/helper_scripts/import_schools.sh \
        /usr/local/ucsschool/import_data/schulen.csv

§9.2. Netze

für Szenario 2, 3 und 4

Der Import der Netze ist notwendig, um Rechner und Server in den Schulen einrichten zu können. Beim Import werden unter anderem passende Richtlinien für DHCP, DNS und Routing erstellt.

Die Netze sind entsprechend der Definition im Netzkonzept in eine CSV-Datei einzutragen. Im UCS@school-Handbuch ist das Datenformat für den Import beschrieben. In der Datei ucsschool-import-vorlagen.xlsx ist eine Vorlage in der Tabelle Netze vorhanden, die verwendet werden kann. Das weitere Vorgehen ist wie folgt:

  • Die CSV-Datei networks.csv ist auf dem Domänencontroller Master in folgendem Verzeichnis abzulegen: /usr/local/ucsschool/import_data/

  • Die CSV-Datei aus der Vorlage enthält noch zwei Kopfzeilen, die mit dem Zeichen # beginnen, diese müssen vor der weiteren Verarbeitung entfernt werden:

    sed -i '1,2d' /usr/local/ucsschool/import_data/networks.csv

  • Der Import kann abschließend mit folgendem Befehl ausgeführt werden:

    /usr/share/ucs-school-import/scripts/import_networks \
        /usr/local/ucsschool/import_data/networks.csv

§9.3. Rechner

für Szenario 2, 3 und 4

Der Import von Rechnern ist insbesondere notwendig, um die Rechner in den Schulen mit der richtigen MAC-Adresse in UCS@school zu hinterlegen, so dass diese über DHCP konfiguriert und in den UCS@school UMC-Modulen verwendet werden können. Weitere Dienste, wie Softwareverteilungslösungen verwenden diese Informationen ebenfalls weiter.

Das Datenformat der CSV-Datei ist im UCS@school-Handbuch beschrieben. Es sollte eine CSV-Datei je Schule erstellt werden, die alle Rechner der jeweiligen Schule entsprechend des Netz- und Namenskonzeptes enthält. In der Datei ucsschool-import-vorlagen.xlsx ist eine Vorlage in der Tabelle Rechner vorhanden, die verwendet werden kann. Das weitere Vorgehen ist wie folgt:

  • Die CSV-Datei computers_SCHULE.csv ist auf dem Domänencontroller Master in folgendem Verzeichnis abzulegen: /usr/local/ucsschool/import_data/

  • Die CSV-Datei aus der Vorlage enthält noch zwei Kopfzeilen, die mit dem Zeichen # beginnen, diese müssen vor der weiteren Verarbeitung entfernt werden:

    sed -i '1,2d' /usr/local/ucsschool/import_data/computers_SCHULE.csv

  • Der Import kann abschließend mit folgendem Befehl ausgeführt werden:

    /usr/share/ucs-school-import/scripts/import_computer \
         /usr/local/ucsschool/import_data/computers_SCHULE.csv

§9.4. Drucker

für Szenario 3 und 4

Der Import der Drucker ist notwendig, damit für diese automatisch eine entsprechende DNS- und DHCP-Konfiguration vorgenommen wird und die Drucker sofort in der Schule im Netz verfügbar sind.

Das Datenformat der CSV-Datei ist im UCS@school-Handbuch beschrieben. In der Datei ucsschool-import-vorlagen.xlsx ist eine Vorlage in der Tabelle Drucker vorhanden, die verwendet werden kann. Das weitere Vorgehen ist wie folgt:

  • > Die CSV-Datei printers.csv ist auf dem Domänencontroller Master in folgendem Verzeichnis abzulegen: /usr/local/ucsschool/import_data/

  • Die CSV-Datei aus der Vorlage enthält noch zwei Kopfzeilen, die mit dem Zeichen # beginnen, diese müssen vor der weiteren Verarbeitung entfernt werden:

    sed -i '1,2d' /usr/local/ucsschool/import_data/printers.csv

  • Der Import kann abschließend mit folgendem Befehl ausgeführt werden:

    /usr/share/ucs-school-import/scripts/import_printer \
         /usr/local/ucsschool/import_data/printers.csv

§9.5. Benutzer / Klassen

für alle Szenarien

Der Import von Benutzerkonten erleichtert die Pflege, insbesondere in sehr großen Umgebungen. Mit den bereitgestellten Importskripten kann ebenfalls der Schuljahreswechsel durchgeführt werden.

Das Datenformat der CSV-Datei ist im UCS@school-Handbuch beschrieben. Folgende Informationen müssen enthalten sein:

  • Vorname

  • Nachname

  • Schulen

  • Klassen

In der Datei ucsschool-import-vorlagen.xlsx sind Vorlagen in den Tabellen Benutzer und Klassen vorhanden. Das weitere Vorgehen ist wie folgt:

  • Die CSV-Datei students.csv ist auf dem Domänencontroller Master in folgendem Verzeichnis abzulegen: /usr/local/ucsschool/import_data/

  • Die CSV-Datei aus der Vorlage enthält noch zwei Kopfzeilen, die mit dem Zeichen # beginnen, diese müssen vor der weiteren Verarbeitung entfernt werden:

    sed -i '1,2d' /usr/local/ucsschool/import_data/students.csv

  • Der Import kann abschließend mit folgendem Befehl ausgeführt werden:

    /usr/share/ucs-school-import/scripts/import_user \
        /usr/local/ucsschool/import_data/students.csv

Beim Import von Klassen ist analog vorzugehen:

  • > Die CSV-Datei klassen.csv ist auf dem Domänencontroller Master in folgendem Verzeichnis abzulegen: /usr/local/ucsschool/import_data/

  • Die CSV-Datei aus der Vorlage enthält noch zwei Kopfzeilen, die mit dem Zeichen # beginnen, diese müssen vor der weiteren Verarbeitung entfernt werden:

    sed -i '1,2d' /usr/local/ucsschool/import_data/klassen.csv

  • Der Import kann abschließend mit folgendem Befehl ausgeführt werden:

    /usr/share/ucs-school-import/scripts/import_groups \
        /usr/local/ucsschool/import_data/klassen.csv