Aus dem IT-Nähkästchen: Und täglich grüßt das Update
25.10.2024Diese Woche habe ich damit zugebracht Keycloak auf die neueste Version zu bringen. Keycloak ist ein externes Programm, das die Benutzerverwaltung für todoListo erledigt. Es verwaltet Datenbankeinträge der Nutzenden und ihren Zugriffsrechten, es übernimmt den Registrierungs- und Login-Prozess in der Nutzeroberfläche und bietet zum Beispiel einen fertigen Workflow, wenn jemand sein Passwort vergessen hat.
Ohne Keycloak könnte ich überhaupt keine individuellen Nutzerkonten bei todoListo anbieten. Ich müsste nicht nur Spezialistin in Authentifizierungsprotokollen werden, sondern könnte den Umfang rein zeitlich nicht stemmen. Auch das Bundesamt für Sicherheit in der Informationstechnik empfiehlt die Nutzung von derartigen Werkzeugen, weil man als Einzelkämpfer (selbst als größere Firma) keine Chance hat, die Benutzerverwaltung sicher genug zu gestalten.
Das ist ja auch praktisch. Nur leider (oder eigentlich: zum Glück) entwickelt sich Keycloak weiter und zwar ziemlich schnell. Alle paar Monate kommt ein größeres Versionsupdate, bei dem breaking changes
möglich sind, also Änderungen in Keycloak, die die Funktionatität von todoListo lahmlegen können.
Wieso Updates Nerven kosten
Es gibt einfache und schwierige Updates. Wenn man Glück hat, ändert man einfach die Versionsnummer und alles läuft wie vorher. Es kann aber auch passieren, dass mehr zu tun ist.
Bei dem aktuellen Update von Keycloak gab es 41 größere Änderungen, die dankenswerterweise auf einer entsprechenden Webseite gelistet waren. Zunächst galt es also durch diese Liste zu gehen und herauszufinden, welche dieser Änderungen für mich relevant waren. Das waren dann noch etwa 5.
Besonders schmerzhaft, wie immer: das Update der Themes, d.h. die Darstellung von Seiten zum Login, Registrieren, Passwort-Änderung usw. Natürlich sollen diese Dinge visuell zum Programm passen und deshalb sieht Keycloak auch vor, dass man die Vorlagen anpassen kann. Nur wenn die Originalvorlagen geändert werden, muss man immer mal wieder ran und die eigenen Anpassungen nachziehen. Ich habe mir dafür einen eigenen Prozess entwickelt, bei dem ich
- prüfe ob sich von mir verwendete Vorlagen geändert haben,
- die Stellen mit spezifischen Kommentaren markiere, an denen ich Dinge angepasst habe, um sie leicht wiederzufinden,
- dokumentiere, warum die Anpassung nötig war.
Und ganz wichtig: nicht pingelig sein! Es gäbe einige Dinge, die ich anders darstellen würde als Keycloak das vorsieht und die ich auch in früheren Versionen geändert habe. Aber es gilt den Wartungsaufwand in Relation zu sehen und deshalb lautet das Ziel akzeptabel
statt perfekt
.
Anpassen ist die eine Sache, für mich persönlich schlimmer: das Testen. Selbst wenn es nicht danach aussieht als wäre man von Änderungen betroffen, passieren immer wieder Überraschungen. So entdeckte ich auch bei dieser Testrunde Fehlerchen, die beim letzten großen Test noch nicht da waren und sich bei irgendwelchen kleineren Updates oder Änderungen bei der Weiterentwicklung von todoListo eingeschlichen hatten.
Und Updates machen immer den Zeitplan kaputt. Genau wie beim Testen weiß man nie was kommt. Es kann in einer halben Stunde erledigt sein oder man sucht eine Woche lang die Nadel im Heuhaufen. Es ist ein bisschen wie die jährliche Autowartung: wenn man Glück hat ist alles ok und das war's; wenn man Pech hat, müssen Ersatzteile bestellt und ausgewechselt werden und das dauert dann entsprechend länger.
Wieso überhaupt Updates?
Das Update hat mich etwa zwei volle Arbeitstage gekostet. Es hat keine neue Funktionalität gebracht, NutzerInnen haben keinen sichtbaren Vorteil davon und nehmen die Funktionalität, die Keycloak bereitstellt, nicht einmal wahr (außer natürlich, wenn etwas nicht funktioniert). Und jedes Update ist ein Risiko: Dinge, die vorher funktioniert haben, tun das hinterher vielleicht nicht mehr, im schlimmsten Fall ohne dass ich es beim Testen bemerke.
Also wieso tue ich mir das jedes Mal an? In diesem Fall ist die Antwort einfach: Keycloak ist eine sicherheitskritische Komponente. Das Wettrüsten zwischen Angreifern und Entwicklern, wie denen von Keycloak, wird nie aufhören. Sei es dass durch höhere Rechenpower Parameter wie Schlüssellängen angepasst werden müssen, durch erkannte Sicherheitslücken Standardprotokolle geändert werden oder einfach auch Programmierfehler in Keycloak korrigiert werden. Wenn man nicht am Ball bleibt, setzt man sich dem Risiko eines Hackerangriffs aus. Allein der Respekt vor meinen Kunden und ihren Daten lässt mir keine andere Wahl als diese Komponente regelmäßig auf den neuesten Stand zu bringen, egal wie viel Plackerei es bedeutet.
Aber auch weniger kritische Fremdkomponenten sollten ihr regelmäßiges Update bekommen. Die Welt entwickelt sich weiter und man möchte schließlich auch von verbesserter Funktionalität und korrigierten Fehlern profitieren. Nach einem Update kann man manchmal sogar den eigenen Code oder die eigenen Anpassungen vereinfachen. So beim aktuellen Keycloak Update. Waren die Vorlagen für die Formulare in früheren Versionen nicht barrierefrei, konnte ich meine Nachbesserungen jetzt entfernen und habe beim nächsten Update weniger Aufwand.
Und jedes Update ist ein Grund zum Testen. Auch wenn ich persönlich nicht gern teste, kann man es eigentlich nie genug tun. Gerade die Funktionalität, die Keycloak bereitstellt, fällt nicht nebenbei
auf, wenn sie kaputt ist. Ich ändere nicht ständig mein Passwort oder registriere mich als neue Nutzerin. Trotzdem ist diese Funktionalität absolut geschäftskritisch, denn wenn da etwas schief geht, verliere ich NutzerInnen quasi direkt vor der Haustür.
Wie viel Update muss es sein?
Aber muss man denn immer sofort updaten? Kann man nicht mal eine oder zwei Versionen auslassen?
Wie bereits erwähnt, ist das bei sicherheitskritischen Updates keine gute Idee, denn Angreifer schlafen nicht. Bei weniger kritischen Komponenten muss man abwägen.
Diesmal musste ich mich durch 41 dokumentierte Änderungen kämpfen. Bei zwei größeren Versionssprüngen könnte ich mit einer Zahl um die 80 rechnen, und noch eine Version länger ausgesessen über 100. Da kann man dann schon mal einen Tag einplanen um überhaupt die relevanten Änderungen herauszuarbeiten und die Gefahr, etwas zu übersehen, steigt ebenfalls. Und genauso skalieren die Änderungen, die man vornehmen muss.
Das Testen nach dem Update fällt allerdings geringer aus, denn man testet nur einmal statt dreimal. Das ist einerseits weniger Aufwand, andererseits eine verpasste Gelegenheit eine Testrunde einzulegen. Hier kommt es darauf an, wie geschäftskritisch die jeweilige Funktionalität ist oder welche anderen Test- und Überwachungsmechanismen im Einsatz sind.
Außerdem kann es einfacher sein, Probleme beim Update zu beheben, wenn die neueste Version schon etwas länger in Gebrauch ist. Dann hat man bessere Chancen, dass andere dasselbe Problem schon hatten und in einem Diskussionforum eine Lösung bereitsteht.
Trotzdem sollte man Updates nicht zu lange verschlafen. Einerseits verpasst man technische Neuerungen, andererseits baut man sich immer mehr seine eigene kleine Welt, die immer unflexibler wird. Vor vielen Jahren habe ich für meine Forschung einen Simulator für Roboter in einer 3D-Welt genutzt. Meine DoktorandInnen und ich haben diesen Simulator immer mal wieder schnell an unsere spezifischen Bedürfnisse angepasst, was dazu geführt hat, dass ich immer dieselbe veraltete Version des Simulators verwenden musste. Dies hatte aber auch zur Folge, dass ich mein Betriebssytem nicht updaten konnte, weil die damit verbundenen Änderungen meinen Simulator lahm gelegt hätten. Irgendwann war die Langzeit-Support-Version des Betriebssystems abgelaufen und wenn ich meine Daten nicht frei für Angreifer zur Verfügung stellen wollte, musste ich das Betriebssystem updaten. Der Simulator war nicht mehr zu reparieren, ich habe mit einem neuen System komplett von vorn angefangen. Das ganze hat mich etwa ein Jahr Arbeitszeit gekostet, in der ich keine Experimente machen konnte und meine Zeit statt in die Forschung in den Aufbau der neuen Infrastruktur geflossen ist. Ob ich im Nachhinein Zeit gespart habe, bezweifle ich. Durch regelmäßige Erneuerung hätte sich der Schmerz nur gleichmäßiger verteilt.
Meine persönliche Update-Strategie ist, bei sicherheitskritischen Komponenten so schnell wie möglich bei jeder großen
Version ein Update durchzuführen. Um das nicht zu verpassen, registriere ich mich auf entsprechenden Mailinglisten oder sehe regelmäßig auf den Webseiten nach. Für alle anderen Komponenten gibt es zweimal im Jahr eine Update von allem was angefallen ist.
Mit Updates leben
Updates sind wie Zähneputzen: man sieht nicht jedes Mal einen riesigen Unterschied, aber auf lange Sicht ist es eine sinnvolle Zeitinvestition. Und wenn man es in die tägliche Routine einbaut, ist es auch kein ständiger Aufreger. Im Grunde ist das Thema auch gar nicht die Updates an sich, sondern das Management externer Komponenten. Mit diesen Tipps funktioniert es:
- Externe Komponenten vorsichtig einsetzen
Niemand kann mehr auf der grünen Wiese programmieren, externe Komponenten sind heutzutage unverzichtbar. Das heißt aber nicht, dass man sie leichtsinnig für jede Kleinigkeit einsetzen muss. Es ist immer eine Abwägung zwischen Aufwand und Kontrolle. Spannend ist dabei auch die Frage, wer überhaupt entscheidet, welche externen Komponenten eingesetzt werden. Dies sollte in jedem IT-Projekt explizit geklärt werden. - Standards akzeptieren
Jede externe Software baut auf spezifischen Annahmen und Techniken auf, die nicht unbedingt zum eigenen Code passen. Man ist schnell versucht, darum herumzuarbeiten und sich die externe Komponente untertan zu machen. Wie bei meinen Eingabemasken in Keycloak, bezahlt man jede Änderung beim nächsten Update. Deshalb ist immer genau zu prüfen, ob die Standardlösung aus der Komponente gut genug ist oder man eine andere Komponente sucht, die besser zum eigenen Projekt passt. - Zeit und Prozesse einplanen
Anders gesagt: sich geistig darauf einstellen, dass das Suchen von externen Komponenten, die Einarbeitung und vor allem die dauerhafte Pflege mit Updates notwendige Arbeitsschritte sind. Je mehr man diese als Teil der Softwareentwicklung versteht und wie andere Bestandteile (Konzeption, Programmieren, Testen) betrachtet, desto weniger regt man sich darüber auf.
Blogreihe Das IT-Nähkästchen
Das IT-Nähkästchen
Egal ob IT-ler, Nutzende oder Auftraggeber: wir sind immer wieder verwundert wie aufwendig und teuer Software-Entwicklung ist. Während man bei handgeschnitzten Figuren die Arbeitsleistung noch halbwegs erahnen kann, ist diese bei der Softwareerstellung von außen nicht zu erkennen. In dieser Serie zeige ich den Alltag der Software-Entwicklung hautnah und allgemein verständlich. Denn nur mit einem klaren Bewusstsein für die Details und die technischen wie organisatorischen Herausforderungen bei allen Beteiligten, können Software-Projekte und -Budgets realitisch geplant und ohne Frust zum Erfolg werden.