Ein ganz besonderes Jahr für SUSE
2020 war für SUSE ein ganz besonderes Jahr – und zwar nicht wegen der Corona-Pandemie und den damit einhergehenden Herausforderungen wie Home-Office-Regelungen und auch nicht wegen der OpenVPN-Server-Migrationen während des Lockdowns. Die entscheidende Veränderung war die Unabhängigkeit SUSEs vom Mutterkonzern, die viele Freiheiten, aber auch neue Verantwortlichkeiten mit sich brachte. So war es an SUSE und SUSEs Entwickler-Team im Besonderen, neue Abteilungen aufzubauen, neue Infrastrukturen zu schaffen und neue IT-Services, die vorher beim Mutterkonzern lagen, zu installieren und einzurichten. Die Migration dieser Dienste, die Erweiterung des IT-Stacks und die Einführung eines neues Identity Management Systems (IDMs) waren wegbereitend für die technische Unabhängigkeit SUSEs vom Mutterkonzern.
Univention Corporate Server (UCS) als neues IDM für die Community-Account-Verwaltung
Für die Verwaltung der Benutzerkonten in den ca. 50 verwendeten Dienste wie dem Bugtracking-System Bugzilla für die Einreichung und Bearbeitung von Fehlerreports oder dem Open Build Service (OBS) für das Hochladen und Kompilieren von Quellcode benötigte SUSE ein neues IDM. Dabei fiel die Wahl auf die Open-Source-Lösung Univention Corporate Server (UCS) von Univention, da diese alle Anforderungen SUSEs an ein neues IDM erfüllte.
Nach einer ersten groben Abschätzung ging man zunächst von bis zu 87.000 Benutzerkonten aus, die sich auf SUSE-Mitarbeiter*innen (1.800), Partner (5.000) und die openSUSE Community (80.000) verteilten. Stattdessen fand das Entwickler-Team von SUSE in den Daten des alten Systems vom Mutterkonzern dann aber 2,1 Millionen Benutzerkonten vor. Welche dieser Konten aktiv und welche inaktiv waren, in welchen Konten also Daten in die Systeme eingepflegt worden waren, konnte das alte IDM jedoch nicht erkennen. Dadurch wurde dem Entwickler-Team von SUSE die Optimierung und Filterung der Benutzerkonten im Vorfeld der Migration erschwert. „Eine schöne Herausforderung”, fasst Daniel Schmidt die Ausgangslage vor der Migration zusammen.
Herausforderung Migration von Benutzerkonten
Die größten Herausforderungen bei der Migration der Benutzerkonten lagen in der schieren Anzahl der Konten sowie den hohen Anforderungen an die Migration. Diese sollte innerhalb von nur sechs Wochen im Produktivbetrieb, möglichst ohne Downtime, vom Novell AccessManager hin zu UCS, einem Common Criteria zertifizierbaren System, umgesetzt werden. Dabei sollte in den Rechenzentren vor Ort (Nürnberg, Prag, Provo und Beijing) jeweils ein Replica Directory Node-Paar stehen, damit die Dienste aus den jeweils anderen Regionen dagegen authentifizieren konnten und ein Hochverfügbarkeitssystem entstehen konnte.
In Nürnberg sollte zusätzlich der Primary Directory Node sowie ein Backup Directory Node stehen, der in ein weiteres Rechenzentrum in Prag repliziert werden sollte. Hinzu kommt, dass Passwort-Hashes aus datenschutzrechtlichen Gründen nicht übertragen werden durften und es sich bei dem Novell AccessManager um ein Produkt handelt, das zu diesem Zeitpunkt nicht mehr existierte.
UCS-Architektur mit zwei zusätzlichen Replicas in der DMZ
Vor der eigentlichen Migration nahmen die Entwickler*innen einige Optimierungen im bestehenden System sowie eine anschließende Filterung der Benutzerkonten vor. So wurde die Anzahl der Benutzerkonten von 2,1 Millionen auf 200.000 reduziert, denn nur so viele Benutzer hatten auch Daten, Quellcode und Beiträge in SUSEs Systeme eingepflegt. Obwohl nur etwa 1/8 (25.000) der 200.000 Benutzer regelmäßig aktiv sind, musste ein „Take-over” der gefilterten Benutzer, d. h. die Übernahme von Logins inaktiver Benutzer durch neue Benutzer, unbedingt verhindert werden. Sonst hätten diese neuen Benutzer Zugriff auf fremde Beiträge ehemaliger Benutzer erhalten.
Dafür nutzte SUSE selbst geschriebene Tools, mit denen die Entwickler*innen prüfen konnten, in welchen Diensten welche Benutzer welche Daten hinterlegt hatten. Darüber hinaus wurde ein eigenes Python-Tool für den schrittweisen Import von Nutzer*innen in UCS sowie ein Migrations-Proxy entwickelt, der sich am alten Novell Access Manager und am neuen Univention Server anmelden konnte.
Für die Migration selbst wurde das LDAP-Schema des Novell Access Managers nachgebildet, um Zeit einzusparen, denn so musste keine Datenkonvertierung durchgeführt und nur minimale Anpassungen in den Systemen vorgenommen werden. Schließlich wurde ein Vorab-Import der 200.000 Benutzerkonten im inaktiven Zustand implementiert. Bei der anschließenden Migration wurde das entsprechende Benutzerkonto dann aktiviert.