UCS@school in den Schulen der Stadt Frankfurt (Oder) – ein Bericht über zehn Jahre Erfahrung Teil 2

Projektbeginn

Im ersten Teil des Artikels haben wir darüber berichtet, vor welchen Herausforderungen die Schulen in Frankfurt Oder und wir als Schulträger vor einigen Jahren beim Aufbau einer modernen IT-Infrastruktur standen. Sie haben erfahren, wie wir die Schulen bei der Konzeptionierung und der Formulierung der Anforderungen an die neue IT beteiligt haben und sie durch größtmögliche Wahlfreiheit bei der Ausgestaltung der jeweiligen Schul-IT ins Boot geholt haben. Und Sie haben erfahren, welche Gründe dafür gesprochen haben, dass wir uns für UCS und UCS@school als Basis der neuen IT entschieden haben.

In diesem Artikel nun geht es um die konkrete Umsetzung des Projekts. Wir beschreiben, wie wir in einer Pilotphase ein virtuelles Serverkonzept mit VMware ESXi und einem zentralen Management getestet haben und die Monitoring Software Nagios implementiert haben. Und Sie erfahren, warum wir uns für die Eigenentwicklung eines Deployments für Linux Clients an den Schulen entschieden haben und worauf wir da technisch geachtet haben. Außerdem lesen Sie, wie wir ein Mobile Device Concept umgesetzt haben, um schuleigene Geräte und die Geräte von Schüler*innen und Lehrkräften mit unterschiedlichen Rollen und Rechten in die schuleigenen Netze eingebunden haben. Und zuletzt möchten wir Ihnen einige aus unserer Sicht grundsätzlichen Erfolgsfaktoren für ein so großes Projekt wie den Aufbau einer modernen, zentral konzipierten und erweiterbaren Schul-IT vorstellen.

Professionelle IT-Dienstleister sind gefragt

Nach erfolgreicher Ausschreibung und Zuschlagserteilung konnte der Dienstleister seine Arbeit aufnehmen. Neben der notwendigen Bestandsaufnahme wurde vor den ersten Rollouts eine sogenannte Masterumgebung implementiert. Hierzu haben wir einen dedizierten Server mit VMware ESXi in einem Rechenzentrum angemietet. Als zentraler Server für alle Schulen wurden ein UCS-Server in der Systemrolle Domänencontroller Master, ein weiterer UCS-Server in der Systemrolle Domänencontroller Backup, ein Ubuntu-Server zur zentralen Erfassung von Hard- und Software-Inventaren und ein Firewall Router (pfSense) als Firewall und zur Bereitstellung der VPN-Verbindungen (OpenVPN) zu den einzelnen Schulstandorten installiert. Alle genannten Systeme wurden als virtuelle Maschinen auf dem VMware ESXi Host installiert.

In den Schulstandorten haben wir ebenfalls ein VMware ESXi Server bereitgestellt, auf dem mindestens folgende virtuelle Maschinen installiert wurden: pfSense (Firewall Router), zwei DC Slaves (Domänencontroller Slave für das Edukativnetz und ein Domänencontroller Slave für das Schulverwaltungsnetz) darüber hinaus (optional) noch weitere VMs wie z. B. Terminalserver, Applikationsserver, Fileserver usw.

Schnell hat sich bestätigt, dass durch die Möglichkeit eines zentralen Managements der administrative Aufwand vor Ort stark reduziert werden konnte. Die serverseitigen Backups liefen automatisiert. Ein Backup der Endsysteme war nicht vorgesehen. Das vom UCS-Master bereits vorkonfigurierte Monitoring-System Nagios ermöglichte es „out of the box“ wichtige Parameter zu überwachen. Im Laufe des Projektes haben wir das Monitoring auf weitere aktive Komponenten wie die pfSense Firewall Router und die managebaren Switches ausgedehnt.

Deployment-Verfahren zum Ausrollen der Endsysteme

Seit der erfolgreichen Pilotierung war das Projektteam auf der Suche nach Lösungen für ein geeignetes Deployment-Verfahren zum Ausrollen der Endsysteme. Schnell verworfen haben wir ein Kloning-basiertes Verfahren, weil die Diversität der Endsysteme in den Schulen teilweise extrem war. Es hätte erhebliche Aufwände erfordert für jede Hardware-Variante ein entsprechendes Image bereitzustellen. Eine Reihe anderer Verfahren und Produkte kamen aus lizenzrechtlichen oder Kostengründen nicht in Frage. Darüber hinaus waren bei allen untersuchten Produkten manuelle Eingriffe an jedem ausgerollten System erforderlich (z. B. der Domänenbeitritt).

Schließlich haben wir uns entschieden, eine eigene Lösung auf Grundlage vorhandener Open Source Software für Linux Clients zu entwickeln. Die Voraussetzungen dafür waren gut. Neben erfahrenen Linux-Administratoren mit LPIC-II-Zertifikat gab es einen Kollegen, der einige Jahre größere Projekte als Consultant und Projektleiter betreut bzw. geleitet hat. Und tatsächlich konnte nach etwa sechs Monaten der Installationsserver für die Rollouts von Linux Clients produktiv eingesetzt werden.

Die Eigenentwicklung des Installationsverfahrens schloss nicht nur das Betriebssystem und die im Repository des Herstellers vorhandene Anwendungssoftware sondern auch Fremdsoftware und den automatischen Domänenbeitritt ein. Zur Realisierung dieser Anforderungen kamen zwei Konfigurationsdateien – global_params und local_params – zur Anwendung. Darin sind die Informationen für den Inhalt des Warenkorbes, die Netzwerkinformationen, die Domäneninformationen sowie die Zuordnung und Konfiguration der möglichen Netzwerkdrucker usw. hinterlegt.

Während des Installationsprozesses werden die Informationen aus den beiden Parameter-Dateien ausgewertet. Dadurch wird die Konfiguration des Endsystems vollständig und automatisch ermöglicht. Nach der Installation ist das jeweilige Endsystem in der Domäne integriert und kann sofort ohne weitere manuelle Eingriffe betrieben werden. Da das Kickstart-Verfahren während des Installationsprozesses eine automatische Hardware-Erkennung ausführt und die notwendige Treibersoftware für die erkannte Hardware automatisch installiert wird, können beim gleichen Rollout durchaus Geräte mit unterschiedlicher Hardware (verschiedene Prozessoren, Netzwerkkarten, Soundkarten etc.) ausgestattet sein, ohne dass hierfür spezielle Images erforderlich wären.

Der automatisierte Installationsprozess der Linux-Endsysteme war ein wichtiger Erfolgsfaktor des Projektes, weil damit sehr große manuelle Aufwände beim Rollout vermieden wurden. Außerdem wurde dadurch auch der Service beim Betrieb stark vereinfacht, weil eine (automatisierte) Neuinstallation in vielen Fällen weniger Aufwand als eine Fehleranalyse mit anschließender „Reparatur“ verursacht.

Inzwischen haben wir ein ähnliches Verfahren auch für das Microsoft-Betriebssystem Windows 10 Professional entwickelt, das ebenfalls eine vollautomatische Installation inkl. Warenkorb und Domänenbeitritt ermöglicht. Auch hier haben wir aus ähnlichen Gründen wie schon bei Linux auf Kloningtechniken bewusst verzichtet und ein wirkliches Setup implementiert.

Weiterentwicklungen – Unterstützung diverser Mobilgeräte-Typen

Die Entwicklung des Gesamtkonzeptes ist seit dem Projektstart ein fortlaufender Prozess, da die modulare Struktur hinreichend Spielraum für Erweiterungen ermöglicht. So wurden Erweiterungen entwickelt, um die Unterstützung verschiedener Geräteklassen und Nutzungscharakteristika von Mobilgeräten zu ermöglichen. Dafür unterscheiden wir zwischen drei verschiedenen Varianten der WLAN-Implementierung:

1. Bei schuleigenen Laptops und Tablets erfolgt der Zugriff über Benutzername und Passwort entsprechend dem Account in der Domäne im Edukativnetz und das Rechtesystem der Domäne ist hinsichtlich Zugriffsrechte auf das Dateisystem der Server und Drucker wirksam.
2. Bei schuleigenen Geräten und Tablets erfolgt der Zugriff über Benutzername und Passwort entsprechend dem Account in der Domäne im Schulverwaltungsnetz. Das Rechtesystem der Domäne ist hinsichtlich Zugriffsrechte auf das Dateisystem, der Server und Drucker wirksam.
3. Bei Geräten von Schüler*innen (BYOD) ist der Zugriff über Benutzername und Passwort entsprechend dem Account in der Domäne im Gästenetz möglich. Das Rechtesystem der Domäne hinsichtlich Zugriffsrechte auf das Dateisystem der Server und Drucker ist nicht wirksam. Und es erfolgen Jugendschutzmaßnahmen entsprechend der gesetzlichen Vorgaben.

Die zunehmende Anzahl der Mobilgeräte hat sich in letzter Zeit als eine nicht zu unterschätzende Herausforderung dargestellt.

Diese beginnt bei der Bereitstellung der notwendigen Infrastruktur über die Implementierung der Anforderungen zur leichten Administrierbarkeit bis hin zur Sicherstellung der Verfügbarkeit und des Mobile Device Management (MDM). Das hat auch Auswirkungen auf die Serviceprozesse und die personelle Struktur. Die 16 Schulen der Stadt Frankfurt (Oder) wurden bis Dezember 2018 von drei IT-Service-Mitarbeitern betreut. Ab Januar 2019 wurde die Anzahl der IT-Service-Mitarbeiter auf fünf erhöht.

Abschließende Bemerkungen: Was wir aus dem Projekt gelernt haben und Ihnen mitgeben möchten

Erfolg ist kein Zufall!

• Es ist wichtig die Anwender in das Projekt einzubeziehen, sie „mitzunehmen“. Die klare Kommunikation der Projektziele ist nicht optional sondern zwingend. Dabei muss unvoreingenommen zugehört werden, was die Anwender wollen und darüber nachgedacht werden, wie es umzusetzen ist statt darüber wie es zu verhindern ist.
• Die “Bestandsaufnahme“ sollte sich nicht nur auf vorhandene Hard- und Software beschränken. Auch das Geschehen im Unterricht, zum Beispiel wie mit modernen Medien gearbeitet wird ist von Bedeutung. So lässt sich zum Beispiel der Schulungsbedarf beim pädagogischen Personal abschätzen.
• Der Schulträger hat die Aufgabe, für einen „reibungslosen“ Betrieb der IT in den Schulen zu sorgen, nicht umgekehrt. Bemühungen vorhandene Verfahren und Methoden aus der Verwaltung auf Schulen zu „übertragen“ werden sehr wahrscheinlich scheitern.
• Ein Projekt dieser Größenordnung muss in überschaubare und erreichbare Arbeitspakete aufgeteilt und realistische Ziele gesetzt werden.

Den Einsatz von Open Source Software in Erwägung ziehen!

Eric S. Raymond hat in seinem Essay The Cathedral & the Bazaar sehr eindrucksvoll beschrieben dass Open Source Software in vielerlei Hinsicht eine Alternative zu proprietärer Software sein kann. Es handelt sich dabei nicht um Software, die einfach nur kostenlos ist (was oft nicht zutreffend ist), es handelt sich in erster Linie um Software, die quelloffen ist, so dass jeder, der es möchte, in den Source Code eines Programms oder eines Betriebssystems hineinschauen kann. Wir finden, dass man bei einem Projekt, in dem es um Bildung, Teilhabe und Medienkompetenz geht, derartige Überlegungen einbeziehen sollte. Noch immer vorhandene, längst widerlegte Vorurteile wie zum Beispiel „das kann nichts taugen, weil es nichts kostet“ oder „das ist nur etwas für Freaks“ usw. sollten Sie „über Bord“ werfen und die Diskussion über Open Source versachlichen.

Schulübergreifend denken!

Es macht Sinn, den Gedanken der Standardisierung und Zentralisierung bestimmter Komponenten der IT-Landschaft in den Schulen zu verfolgen und umzusetzen. Das muss nicht, wie mitunter argumentiert, mit Einschränkungen für die jeweilige Schule oder der Gefährdung der Individualität der einzelnen Schulen verbunden sein. Es braucht zum Beispiel nicht 16 Instanzen zur Benutzerverwaltung. Wenn man als Schulträger Verantwortung für 16 Schulen hat, ist eine richtig aufgesetzte zentrale Benutzerverwaltung genug. Das gilt ebenso für Netzwerke, Endsysteme, Drucker und Benutzergruppen. Es wird recht schnell das Potential der Einsparung von Manpower klar, wenn man sich intensiver dieser Idee des schulübergreifenden Denkens im Kontext des IT-Betriebes und der damit einhergehenden Kosten befasst.

Das System modular gestalten und neue Anforderungen zulassen!

Kaum eine Branche ist so agilen Änderungen unterworfen wie die IT. Bewährte Konzepte, Softwareprodukte, Verfahren aber auch Hardware sind im ständigen Wandel. Man sollte sich deshalb von dem Irrglauben verabschieden, dass alles in Stein gemeißelt ist. Es gilt mit Augenmaß auf neue Anforderungen zu reagieren und diese in das vorhandene System zu integrieren.