Die Vorbereitungen
Die Migration begann genau genommen schon lange vor der Migration: nach Vertragsabschluss gab es die ersten Gespräche mit den Technikern von Univention. Wir hatten einen direkten Ansprechpartner, der sich als ungemein kompetent entpuppte und so schnell einen guten Draht zu unseren Systemadministratoren aufbauen konnte. Schnell erkannten alle Beteiligten, dass die technische Basis unseres System gar nicht so weit von der von UCS entfernt war. Basierend auf der Erkenntnis konnte recht zügig ein Plan für die Migration erstellt werden.
Der in UCS verwendete Notifier-Listener-Mechanismus würde von nun an die Replikationen der Benutzerdaten in die einzelnen Dienste übernehmen. Im Gegensatz zu bisher sollten die zentralen Dienste wie LDAP, DNS, DHCP, aber auch die Samba basierten Active Directory Windows-Dienste redundant ausgestaltet werden, um Ausfallsicherheit zu gewährleisten. Das bot sich an, da das UCS-Domänenkonzept, das auf einem Multiserveransatz basiert, von vorneherein die technische Basis für verteilte Dienste und redundante Dienste mitbringt.
Einer der Dienste, den wir weiterhin nutzen wollten, war die OX App Suite. Sie lief bisher auf einem Dovecot Server und sollte auf UCS umgezogen werden, auch weil die Notifier-/Listener- basierte Benutzerverwaltung, z. B. das Umbenennen oder Löschen von Mailboxen, damit funktioniert. Die vorhandene OX App Suite sollte von nun an über den UCS OX Connector provisioniert werden. Dieser ermöglicht es, auch eine nicht auf einem UCS-System laufende OX App Suite zu nutzen und Benutzer und Gruppen zwischen beiden Diensten zu synchronisieren.
Eine direkte Migration aller Funktionen wäre doch sehr komplex geworden. Daher haben wir uns gemeinsam mit Univention dafür entschieden, die Informationen über Nutzer, Gruppen und Computer aus dem existierenden Samba AD in UCS zu übernehmen und dafür den Active Directory Takeover von UCS zu verwenden. Der wurde eigentlich dafür gebaut, ein auf Windows basierendes System zu migrieren, war aber für unsere Anforderungen mit kleineren Anpassungen geeignet. Vorteil des Takeovers: Alle bestehenden 500 Client-Computer, in unserem Fall sind das Linux Clients, funktionieren ohne weitere Änderungen auch mit dem neuen System. Eine Voraussetzung, um die Migration in der geplanten kurzen Zeit schaffen zu können. Und ein weiterer positiver Nebeneffekt: Die Benutzer würden von der Umstellung kaum etwas mitbekommen und sich nach erfolgreichem Abschluss einfach mit ihrem bisherigen Benutzernamen und Kennwort anmelden und alle angebundenen Dienste weiter nutzen können.
Um die Migration vorab zu üben, wurde eine komplette Testinstallation erstellt, in welcher sowohl ein digitaler Zwilling unseres aktuellen Systems als auch ein UCS installiert wurde. So konnten wir gemeinsam mit Univention die Migration vorab durchspielen. Hier zeigte sich wieder einmal der inzwischen altbekannte Vorteil virtualisierter Umgebungen: nicht nur konnte schnell die Testumgebung aufgesetzt werden, dann Snapshots und Clones konnte sie auch jederzeit einfach kopiert bzw. in alte Zustände zurückgesetzt werden. Für die Jüngeren unter uns klingt das sicher alltäglich, wer sich wie ich noch an die Zeiten vor der Virtualisierung erinnert, wird meine immer noch vorhandene Begeisterung sicher gut nachvollziehen können.
Durch die diversen Tests konnten wir unseren Datenbestand bereinigen (was sich als Hauptquelle von Fehlern bei den Test-Migrationen herausstellte) und Univention bereitete entsprechende Skripte vor, um die eigentliche Migration später möglichst stark zu automatisieren. Zuvor hatten wir in dem alten Verwaltungssystem gespeicherte Daten identifiziert und beschlossen, welche Informationen noch benötigt werden und in welcher Form sie in das neue System migriert werden sollten.
Ein Beispiel dafür: In unserem alten System gab es für einen Anmeldeprozess eine 2-Faktor-Authentifzierung, bei der über eine SMS-Nachricht ein Anmeldetoken versendet wurde. Die dafür im System gespeicherten Mobilnummern sollten auch weiterhin zur Verfügung stehen und konnten über die UCS-Standardfunktion „extended Attributes“ problemlos in das neue System übertragen werden. So können wir bewährte individuelle Dienste und dafür benötigte Daten auf das neue Standardsystem übertragen.
Mit diesen Vorbereitungen und den Erfahrungen aus den Test-Migrationen konnten wir nun einen Zeitplan für die echte Migration ableiten: knapp zwei Tage würden wir brauchen. Da IT-Projekte ab einer gewissen Komplexität stets anders als geplant laufen, haben wir noch einen Puffer dazu gepackt und den Start für Freitagmittag angesetzt. Die Anwender wurden lange vorher informiert und regelmäßig erinnert – während der Migration ist keine Anmeldung am System, also praktisch kein Arbeiten, möglich.
Die Migration – Zeitspiel
Bis Samstagmittag lief alles nach Plan. Für den Abend sollte es in Schwäbisch Hall ein großes Sommerfest geben, es sah alles danach aus, dass wir dort den erfolgreichen Abschluss des Projektes feiern können. Und dann kamen die ersten Probleme: wir hatten einfach einige sehr spezielle Anwendungsfälle übersehen. Hier rächte es sich, dass unser IT-Team sehr jung (an Dienstjahren) ist, zum Zeitpunkt der Migration waren alle Beteiligten weniger als 1 Jahr bei uns. Das Problem war aber schon viel älter, daher hatte es (noch) niemand gesehen.
Als Glücksfall erwies sich, dass der Univention-Techniker, mit dem wir im Vorfeld schon alles geplant hatten, während der Migration bei uns vor Ort war. Darauf hatten wir bestanden. Vermutlich hätte alles auch remote funktioniert, aber so war es doch einfacher. Letztlich verloren wir Dank seines Fachwissens nicht einmal eine Stunde, bis wir die Lösung hatten. Kurz kam noch der Gedanke an ein Rollback auf (diese Hintertür hatten wir so lange wie möglich offen gelassen), mit der Lösung vor Augen waren wir uns aber alle einig, weiter machen zu wollen. Das war dann praktisch der legendäre Point-of-no-return: aber jetzt hätten wir nicht mehr genug Zeit für ein Rollback gehabt.
Die Umsetzung der gefundenen Lösung erwies sich dann als sehr zeitraubend: mangels Vorbereitung konnten wir hier nicht automatisieren, sondern mussten einige Anpassungen an vielen dutzend Stellen manuell nachziehen. Gegen Abend war allen Beteiligten anzumerken, dass die Konzentration nachließ. Weiterarbeiten machte so keinen Sinn, also entschieden wir (was den Leser jetzt eventuell überraschen wird) – auf das Sommerfest zu gehen. Eine gute Entscheidung, der Stress fiel merklich ab. Natürlich war der Abend nicht wirklich lang, tat aber gut und am Sonntagmorgen standen alle wieder ausgeschlafen und motiviert auf der Matte. Knapp zwei Stunden später war klar, dass wir gut durchkommen würden, gegen Mittag war alles erledigt und der Nachmittag verging in schon deutlich entspannter Stimmung mit dem Testen der erledigten und dem Aufschreiben der offenen Punkte (jeder, der ein Projekt dieser Größenordnung schon einmal durchgeführt hat, weiß, dass man nie bei 100 Prozent landet).
Klassenzimmer mit moderner Medientechnik