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 zentralen Domänencontroller Slave für RADIUS, Groupware, Collaboration, Lernplattformen usw.
7.4. Installation eines zentralen Memberserver für Monitoring
7.5. Installation eines Domänencontroller Slave als Schulserver
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*innen 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*innen

  • 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üler*innen 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.4 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? Siehe 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?

  • Wie erfolgt der Zugriff auf zentral bereitgestellte Webdienste (Portal, Self-Service ...) aus dem Internet?

    • Stellt der Rechenzentrumsbetreiber Loadbalancer und Reverse-Proxy als Dienst bereit?

    • Welche externen Domänennamen sollen für den Zugriff auf die Webdienste verwendet werden?

    • Ist sichergestellt, dass zu den Domänennamen passende SSL/TLS-Zertifikate vorhanden sind und diese regelmäßig erneuert werden?

§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, mehrere SSIDs sowie RADIUS bzw. IEEE 802.1X unterstützen?

  • Wie können die Access Points zentral konfiguriert werden? Ist eine Management Software oder ein WLAN-Controller 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 und Test- bzw. Demo-Umgebung 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 Meilensteinen 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

  • Motivierte Schulleitung und IT-Verantwortliche an der Schule

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, den pädagogischen Funktionen und den weiteren Webdiensten 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. Nicht alle sind 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 Netzes 10.0.0.0/8. Dieses wird für die Schulen in viele Subnetze unterteilt. Für jede Schule wird ein /16-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 Endgeräten. Bei Bedarf können weitere Subnetze ergänzt werden, da das für die Schule reservierte /16-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.42.1.0/24-254Netz für Server und Netzgeräte, statische IP-Adressen
10.42.2.0/2410.42.2.10-10.42.2.250254Netz für Schulverwaltung, erweiterbar auf /23 (510 IP-Adressen)
10.42.4.0/2410.42.4.10-10.42.4.250254Netz für edukativen Bereich 1, erweiterbar auf /23 (510 IP-Adressen)
10.42.6.0/2410.42.6.10-10.42.6.250254Netz für edukativen Bereich 2, erweiterbar auf /23 (510 IP-Adressen)
10.42.8.0/2410.42.8.10-10.42.8.250254Netz für edukativen Bereich 3, erweiterbar auf /23 (510 IP-Adressen)
10.42.10.0/2410.42.10.10-10.42.10.250254Netz für edukativen Bereich 4, erweiterbar auf /23 (510 IP-Adressen)
10.42.128.0/2010.42.128.100-10.42.143.2504094Gäste WLAN / BYOD, erweiterbar auf /18 (16382 IP-Adressen)
10.42.192.0/2010.42.192.100-10.42.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.

In bisherigen Projekten hat es sich als sinnvoll erwiesen, einen bislang nicht verwendeten Domänennamen sowohl für den Zugriff aus dem Internet als auch für die Benennung der internen UCS-Domäne zu verwenden.

Wird beispielsweise example.org als Domänenname ausgewählt, muss auch Univention Corporate Server mit diesem Domänennamen installiert werden. Zudem muss sichergestellt sein, dass die öffentliche Internet-Domain example.org vom Betreiber bei einem Domain-Name-Registrar registriert wurde und dass weitere öffentliche Subdomains angelegt werden können.

Anmerkung

Mit dem hier empfohlenen Vorgehen wird ein sog. Split-DNS-Szenario eingerichtet. Die von Univention Corporate Server für interne Funktionen bereitgestellten DNS-Dienste lösen Hostnamen auf internen IP-Adressen auf, während öffentliche DNS-Server die selben Hostnamen auf die öffentlichen IP-Adressen auflösen müssen.

  • Beispiel für die Hauptdomain (auch interne UCS-Domain): example.org

  • Beispiel für das Portal (Zugriff von außen): portal.example.org

  • Beispiel für eine Anwendung wie beispielsweise Webmail (Zugriff von außen): mail.example.org

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 sichergestellt werden, dass der gewählte Domänenname für UCS@school im öffentlichen Internet noch nicht verwendet wird.

  • Für den nicht empfohlenen Fall, dass die Verwendung einer öffentlichen DNS-Domäne nicht möglich ist und stattdessen ein selbst ausgewählter, interner DNS-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.

  • Im internen Netz werden dem Domänennamen für UCS@school 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 ucsrz01 somit intern unter dem FQDN ucsrz01.example.org zu erreichen.

  • In UCS@school werden mindestens im Falle der Schulserver auch Samba Active Directory Domaincontroller betrieben. Aus Gründen der Abwärtskompatibilität wird dabei auch immer ein NetBIOS- bzw. Legacy-Domänenname erstellt. Im Falle von example.org als DNS-Domänenname würde automatisch EXAMPLE als NetBIOS-Domänenname gesetzt sein. Der NetBIOS-Domänenname ist auf 15 Zeichen begrenzt. Dies kann zu Situationen führen, in denen der NetBIOS-Domänenname ungünstig abgeschnitten wird. Wählt man beispielsweise schulen-musterstadt.de als DNS-Domänenname, würde der automatisch abgeleitete NetBIOS-Domänenname SCHULEN-MUSTERS lauten. Dieser Name ist beispielsweise beim Anmeldebildschirm an Windows-Clients der Domäne zu sehen. Möchte man nun lieber MUSTERSTADT als Anzeigename dort sehen, so ist auf dem UCS@school-Server bereits während der Installation der gewünschte NetBIOS-Domänenname zu setzen (siehe auch How to define the NetBIOS name during installation).

§5.2.2. Zentrale Server

für alle Szenarien

Zentrale Server:

  • Schema: [System][Standort][Laufnummer]

  • Beispiel: System UCS, Standort Rechenzentrum, erstes System: ucsrz01

  • Weitere Beispiele:

    • Domänencontroller Master: ucsrz01

    • Domänencontroller Backup: ucsrz02, ucsrz03

    • Domänencontroller Slave: ucsrz04

    • Memberserver: ucsrz05

Der Name darf eine Länge von 13 Zeichen nicht überschreiten und sollte nicht mit einer Ziffer beginnen.

§5.2.3. Rechner und Schulserver

für Szenario 3 und 4

Rechner:

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

  • Beispiele: win-042-001, win-042-002, mac-042-001

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

  • Schema: [Gerätetyp]-[Kurzbezeichnung Schule]-[Laufnummer]

  • Beispiele: rou-042-001, swi-042-003, usv-042-001, dru-042-012

Schulserver:

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

  • Beispiele:

    • Edukativer Schulserver: sedu-042-01

    • Schulserver Schulverwaltung: sadm-042-01

Der Name darf eine Länge von 13 Zeichen nicht überschreiten und sollte nicht mit einer Ziffer beginnen.

§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 ändern können, zum Beispiel aufgrund von Heirat, Scheidung, im Rahmen einer Namens- oder Personenstandsänderung oder zur Behebung von Tippfehlern. 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 also eine 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*innen:

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

  • Beispiel: Mary Selig → marys

  • Beispiel Namenskonflikt: Mary Sandermarys2

Lehrkräfte und Mitarbeiter*innen:

  • 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.

Klassennamen müssen mit der Kurzbezeichnung der Schule (hier im Beispiel 042 und 011) 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.

  • Sofern nicht anders angegeben, sollte die Länge von Objektnamen 15 Zeichen nicht überschreiten. Dies ist insbesondere wichtig für Benutzernamen von Schüler*innen.

§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.4.

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 das UCS Dashboard verwendet werden, dessen Einrichtung im Univention Corporate Server Handbuch 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

  • /etc/*.secret auf allen Systemen

Schulserver, sofern vorhanden:

  • /var/univention-backup: Nächtliche Sicherung der Univention Configuration Registry. Die Sicherung der OpenLDAP- und Samba-Datenbanken muss nicht zwingend gesichert 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 Mitarbeiter*innen zu schulen, die den Betrieb der Umgebung durchführen.

Neben passenden Werkzeugen zur Kommunikation und Fernwartung, zum Beispiel ein Ticket-System, 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, idealerweise aber SSD-Festplatten (mindestens für die I/O-intensiven Dienste wie OpenLDAP und Samba unter /var/lib/.)

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 der Anwendung selbst abhängig sind. Eine Abstimmung mit dem jeweiligen Hersteller ist in aller Regel notwendig.

§6.2. Dezentrale Systeme

§6.2.1. Schulserver

für Szenario 3 und 4

Auch hier spielt vor allem die Anzahl gleichzeitig aktiver Benutzerkonten und Endgeräte eine Rolle.

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, das 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*innen 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 16 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*innen ggf. über mehr als ein Gerät pro Person verfügen 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 2-5 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. Minimalanforderungen für die Anbindung nach Schultyp

SchultypTypische Anzahl ClientsTypische NetznutzungMindestens nötige Bandbreite
Grundschulen~20 ClientsGeringe Netznutzung (~2 MBit/s)40 MBit/s
Weiterführende Schulen~90 ClientsMittlere Netznutzung (~3 MBit/s)270 MBit/s
Berufsschulen~300 ClientsHohe Netznutzung (>5 MBit/s)1,5 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.

  • Ist die Verfügbarkeit von performanten Festplatten (zum Beispiel SSDs) begrenzt und reicht nicht für das gesamte System aus, so sollte zumindest /var/lib als eigene Partition auf performanten Festplatten angelegt werden.

  • Je nach System und verwendeten Diensten (beispielsweise für Schulserver mit lokalen Benutzerdaten) 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 des Netzkonzepts.

  • Als Externer DNS-Server bzw. DNS-Forwarder ist die IP-Adresse des DNS-Servers des Internetproviders oder des Rechenzentrum-Betreibers 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 entsprechend des Namenskonzeptes angepasst werden.

  • 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.

  • für Szenario 3 und 4

    Um Gruppenrichtlinien für alle Schulen über eine zentrale Stelle verwalten zu können, muss zudem über das Univention App Center die App Active Directory kompatibler Domänen-Controller installiert werden. Soll der NetBIOS-Domänenname nicht automatisch erzeugt werden, ist dieser vor der Installation explizit zu konfigurieren (siehe auch Abschnitt 5.2.1). 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.

  • 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.

  • Während des Domänenbeitritts wird die UCS@school App automatisch installiert. Die ist über das Univention App Center zu prüfen.

  • Im Anschluss an die Installation der UCS@school App ist in der Univention Management Console in der Kategorie Schuladministration zu prüfen, dass der UCS@school Einrichtungsassistent erfolgreich abgeschlossen wurde.

  • 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 zentralen 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 und zu bestätigen, dass es sich um einen zentralen Domänencontroller Slave handelt und explizit nicht um einen Schulserver.

  • Das installierte System ist abschließend bis zum letzten verfügbaren Errata-Update zu aktualisieren. Falls noch nicht erfolgt, 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 soll hier 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.4. Installation eines zentralen 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 Nagios, 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 Nagios lauffähig ist, muss sichergestellt sein, dass die globale Univention Configuration Registry-Richtlinie ucsschool-ucr-settings auf alle anderen Systeme wirkt. Dies kann überprüft werden, indem der Wert der Univention Configuration Registry-Variable nagios/client/allowedhosts auf den anderen Servern abgerufen wird. Sollten trotzdem keine Statusinformationen über einen Server angezeigt werden, so müssen ggf. die Dienste univention-directory-listener und nagios-nrpe-server neu gestartet werden.

§7.5. Installation eines Domänencontroller Slave als Schulserver

für Szenario 3

Vor der Installation des Schulservers muss die zugehörige Schule mitsamt dem Namen für den Schulserver auf dem Domänencontroller Master angelegt werden. Es ist zudem absolut empfehlenswert auch die der Schule zugehörigen Netzwerke vorab zu importieren. Bitte fahren Sie zunächst mit dem Kapitel 9 fort, importieren mindestens Schulen und Netzwerke und kommen dann zu diesem Abschnitt für die Installation des Schulservers zurück.

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

  • Es ist sicherzustellen, dass zuvor die Schule mitsamt dem Namen für den Schulserver sowie die Netzwerke auf dem Domänencontroller Master entsprechend der Beschreibung in Abschnitt 9.1 angelegt bzw. importiert wurden.

  • Bei der Partitionierung sollte darauf geachtet werden, dass der Pfad /home auf einem eigenen Dateisystem abgelegt wird, damit aufgrund von übermäßig vielen 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.

  • Es ist darauf zu achten, dass der bei der Installation angegebene Rechnername mit dem Namen des Schulservers übereinstimmt, der beim Anlegen der Schule angegeben wurde. Dies muss der Fall sein, damit der Server im weiteren Verlauf als (edukativer) Schulserver eingerichtet werden kann und explizit nicht als zentraler Domänencontroller Slave.

  • Das installierte System automatisch bis zum letzten verfügbaren Errata-Update aktualisieren, den Domänenbeitritt starten und dabei die UCS@school App installieren.

  • 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.

  • Soll der Schulserver auch als DHCP-Server fungieren (empfohlen), muss noch die App "DHCP-Server" über das Univention App Center installiert werden.

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

§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@ucsrz01.example.org zu stellen. example.org 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.
ucsschool/assign-teachers/autosearchfalseDeaktiviert die automatische Suche nach allen Objekten beim Öffnen des UCS@school-Moduls zum Zuweisen von Lehrkräften. Dies beschleunigt das Arbeiten mit vielen LDAP-Objekten.
ucsschool/assign-classes/autosearchfalseDeaktiviert die automatische Suche nach allen Objekten beim Öffnen des UCS@school-Moduls zum Zuweisen von Klassen. Dies beschleunigt das Arbeiten mit vielen LDAP-Objekten.
ucsschool/workgroups/autosearchfalseDeaktiviert die automatische Suche nach allen Objekten beim Öffnen des UCS@school-Moduls zum Bearbeiten von Arbeitsgruppen. Dies beschleunigt das Arbeiten mit vielen LDAP-Objekten.
ucsschool/passwordreset/autosearchfalseDeaktiviert die automatische Suche nach allen Objekten beim Öffnen des UCS@school-Moduls zum Zurücksetzen von Passwörtern. Dies beschleunigt das Arbeiten mit vielen LDAP-Objekten.
ucsschool/passwordreset/autosearch_on_changefalseDeaktiviert die automatische Suche nach allen Objekten im UCS@school-Modul zum Zurücksetzen von Passwörtern nachdem der Suchfilter geändert wurde. Dies vereinheitlicht das Verhalten der UCS@school-Module, kann bei Bedarf aber auch auf dem Standardwert belassen bzw. nicht angepasst werden.
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.
samba4/sysvol/sync/from_upstream/deletetrueKonfiguriert 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, auf den NRPE-Dienst der übrigen Systeme.
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.

    Die Spalten für "Schulkürzel", "Schulname" und "Server Pädagogik" sind Pflichtfelder. Die Spalte "Server Verwaltung" ist optional und die Spalte "Server Fileshare" sollte nur in ganz bestimmten Fällen ausgefüllt werden und verbleibt in der Regel leer.

    §

    Abbildung 9.1. Tabelle: Schulen

    Tabelle: Schulen


  • Export der Tabelle ins CSV-Format mit Komma als Trennzeichen für Felder.

    §

    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/. Das Verzeichnis muss ggf. zuerst angelegt werden: mkdir -p /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

    Alternativ kann die Datei auf dem Domänencontroller Master mit dem Editor Vim geöffnet und dieser zum konvertieren verwendet werden:

    vim schulen.csv
    # In der Vim Befehlszeile:
    :set ff=unix
    :wq

  • 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

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

    /usr/share/ucs-school-import/scripts/create_ou --infile=/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. Es ist zu beachten, dass der Feldtrennzeichen in diesem Fall "Tabulator" sein muss. 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. Es ist zu beachten, dass der Feldtrennzeichen in diesem Fall "Tabulator" sein muss. 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. Es ist zu beachten, dass der Feldtrennzeichen 6in diesem Fall "Tabulator" sein muss. 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

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

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

Die Einrichtung und Verwendung des zugehörigen Univention Management Console Moduls ist im Handbuch grafischer Benutzer-Import nachzulesen.

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.