4. 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.
4.1. Netzkonzept#
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.
Subnetz (CIDR) |
Schule |
|---|---|
|
Zentrale Systeme |
|
|
|
|
|
|
|
|
|
Weitere 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.
Bemerkung
Bei mehr als 255 Schulen kann das vorgeschlagene Netzkonzept nicht verwendet werden.
4.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 Netze ist beschrieben wie der Import vorzunehmen ist, welche Informationen anzugeben sind und welche Hilfsmittel dafür zur Verfügung stehen.
Subnetz (CIDR) |
DHCP-Adressbereich |
Anzahl IP-Adressen |
Verwendung |
|---|---|---|---|
|
|
254 |
Subnetz 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.
4.1.2. Beispiel Subnetz Grundschule#
Subnetz (CIDR) |
DHCP-Adressbereich |
Anzahl IP-Adressen |
Verwendung |
|---|---|---|---|
|
|
254 |
Kleines Netz für eine Grundschule |
In diesem Beispiel werden eventuell 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.
4.1.3. Beispiel Subnetz Berufsschule#
Subnetz (CIDR) |
DHCP-Adressbereich |
Anzahl IP-Adressen |
Verwendung |
|---|---|---|---|
|
|
254 |
Netz für Server und Netzgeräte, statische IP-Adressen |
|
|
254 |
Netz für Schulverwaltung, erweiterbar auf |
|
|
254 |
Netz für edukativen Bereich 1, erweiterbar auf |
|
|
254 |
Netz für edukativen Bereich 2, erweiterbar auf |
|
|
254 |
Netz für edukativen Bereich 3, erweiterbar auf |
|
|
254 |
Netz für edukativen Bereich 4, erweiterbar auf |
|
|
4094 |
Gäste WLAN / BYOD, erweiterbar auf |
|
|
4094 |
Schuleigenes WLAN mit RADIUS-Authentifizierung, erweiterbar auf |
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 bei 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.
4.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 die 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.
4.2.1. Name der Domäne#
Gültigkeit
Für alle Szenarien.
Der Name der Domäne definiert mehrere zugehörige Namen:
LDAP-Basis des Verzeichnisdienstes
DNS-Domäne
Kerberos-Realm
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.
Bemerkung
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-Domäne):
example.orgBeispiel für das Portal (Zugriff von außen):
portal.example.orgBeispiel 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
.corpoder.lan. Bei ihnen besteht die Gefahr, dass es zu späteren Namenskollisionen kommt..localsollte 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
ucsrz01somit intern unter dem FQDNucsrz01.example.orgzu 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.orgals DNS-Domänenname würde automatischEXAMPLEals 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.deals DNS-Domänenname, würde der automatisch abgeleitete NetBIOS-DomänennameSCHULEN-MUSTERSlauten. Dieser Name ist beispielsweise beim Anmeldebildschirm an Windows-Clients der Domäne zu sehen. Möchte man nun lieberMUSTERSTADTals Anzeigename dort sehen, so ist auf dem UCS@school-Server bereits während der Installation der gewünschteNetBIOS-Domänennamezu setzen (siehe auch KB 6390 - How to define the NetBIOS name during installation).
4.2.2. Zentrale Server#
Gültigkeit
Für alle Szenarien.
Zentrale Server:
Schema:
[System][Standort][Laufnummer]Beispiel: System UCS, Standort Rechenzentrum, erstes System:
ucsrz01Weitere Beispiele:
Primary Directory Node:
ucsrz01Backup Directory Node:
ucsrz02,ucsrz03Replica Directory Node:
ucsrz04Managed Node:
ucsrz05
Der Name darf eine Länge von 13 Zeichen nicht überschreiten und sollte nicht mit einer Ziffer beginnen.
4.2.3. Rechner und Schulserver#
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-01Schulserver Schulverwaltung:
sadm-042-01
Der Name darf eine Länge von 13 Zeichen nicht überschreiten und sollte nicht mit einer Ziffer beginnen.
4.2.4. Benutzernamen und Klassenbezeichnungen#
Gültigkeit
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 Personenstandä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 →
marysBeispiel Namenskonflikt: Mary Sander →
marys2
Lehrkräfte und Mitarbeiter*innen:
Schema:
[1. Buchstabe Vorname][Nachname][Laufnummer]Beispiel: Mareike Müller →
mmuellerBeispiel Namenskonflikt: Martina Müller →
mmueller2
Für Benutzerkonten kann das gewünschte Schema im Importmechanismus hinterlegt werden, siehe UCS@school - Handbuch zur CLI-Import-Schnittstelle [1].
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
4.2.5. Allgemeine Konventionen#
Gültigkeit
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 wichtig für Benutzernamen, insbesondere von Schüler*innen.
4.3. Monitoring#
Gültigkeit
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 App UCS Dashboard fest integriert und für viele relevante Parameter vorkonfiguriert. UCS Dashboard überwacht den aktuellen Zustand der überwachten Systeme.
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 Installation eines zentralen Replica Directory Node für Monitoring.
UCS Dashboard speichert Langzeitinformationen, so dass Informationen darüber vorliegen, in welche Richtung sich eine Umgebung entwickelt. Ein Beispiel ist die Entwicklung der Belegung des Festplattenplatzes. Solche Informationen sind für den Betrieb einer umfangreichen IT-Infrastruktur erforderlich.
4.4. Datensicherung und Wiederherstellung#
Gültigkeit
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 dateibasierte 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/sslauf dem Primary Directory Node und den Backup Directory Node-Servern: Beinhaltet das Root-Zertifikat der internen Zertifizierungsstelle und alle Rechner-Zertifikate./etc/*.secretauf allen Systemen.
Schulserver, sofern vorhanden:
/var/univention-backup: Nächtliche Sicherung der Univention Configuration Registry. Die Sicherung der OpenLDAP- und Samba-Datenbanken braucht nicht gesichert werden, da diese beim erneuten Domänenbeitritt des Schulservers vom Primary Directory Node oder Backup Directory Node 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.
4.5. Support-Kanäle#
Gültigkeit
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.