Vor etwa einem Monat berichtete ein Freund und ehemaliger Studienkollege in einem Jitsi-Online-Meeting enttäuscht von der „do-release-upgrade„-Funktion unter Ubuntu Linux. Er klagte über ein kläglich gescheitertes Release-Upgrade, das aufgrund zahlreicher Fehler abbrach, die vorgenommenen Änderungen teilweise rückgängig machte, jedoch ein beschädigtes und nicht mehr funktionstüchtiges System hinterließ.

Ein anderer Freund und Admin wollte daraufhin meine Meinung als langjähriger „Linux-Experte“ hören. Ich sehe mich zwar nicht als den Linux-Experten, aber ich sammle seit 1998 (begonnen mit Corel Linux) Erfahrungen im Umgang mit Linux-Systemen. Seit meiner ersten Begegnung mit Ubuntu Linux 4.10 LTS (etwa 2004 oder 2005) war ich begeistert. Im Vergleich zu anderen Distributionen wie SuSE (6.3), Mandrake, Red Hat oder Debian erkannte Ubuntu die Hürden, mit denen selbst IT-Fachleute und Informatikstudierende zu kämpfen hatten: aufwändige Installationen, komplexe Konfigurationen, zeitraubende Problemlösungen.

Ubuntu stellte nicht nur ISO-Images kostenlos online zur Verfügung, sondern versendete auch gratis CDs in 10er-Packs – nicht nur für Studierende. Die Installation war intuitiv, verständlich und angenehm vertraut – ähnlich wie Windoof von Mircosaft. Bereits während der Installation wurden angeschlossene Peripheriegeräte meist automatisch erkannt, die passenden Kernel-Module installiert, und das System war nach der Installation einsatzbereit: mit OpenOffice (dem Vorgänger von LibreOffice), Firefox und weiteren Anwendungen für Büro- und Multimedia-Zwecke.

Aktuelle System- und Softwareupdates konnten optional schon während der Installation mitinstalliert werden, sodass man sofort ein vollständig aktualisiertes System nutzen konnte. Auch spätere Updates ließen sich unkompliziert finden und installieren – sofern man keine exotische oder besonders individuelle Hardware benutzte.

Kurz gesagt: Man installierte Ubuntu und konnte anschließend direkt produktiv arbeiten – ganz im Gegensatz zu vielen anderen Linux-Distributionen, die ihre Nutzer regelmäßig zur manuellen Nacharbeit zwangen.

Randnotiz: Meine frühere Lieblingsdistribution war Mandrake Linux (heute Mandriva), die mit KDE als grafischer Oberfläche geliefert wurde und die meisten Peripheriegeräte sowie Anwendungen direkt einsatzfähig mitbrachte. Zuvor hatte ich SuSE Linux (ab Version 6.3) verwendet, mich jedoch aus Frust mit Version 8.x oder 9.x davon verabschiedet. Einziger Vorteil damals: gute deutsche Dokumentation und umfangreiche Hardwareunterstützung, etwa für Wacom-Tablets, HP-Drucker und Scanner.

Gestern wagte ich auf einem wichtigen Ubuntu-Server den Befehl „do-release-upgrade“ – und wurde enttäuscht. Der Upgrade-Prozess erkannte zahlreiche Probleme und versuchte, das System in den Ursprungszustand zurückzusetzen. Trotzdem zeigte das System nach Abschluss an, dass es auf die neueste Version aktualisiert sei. Wie kann das sein? Nur der Kernel, einige Dienste und wenige Anwendungen wurden aktualisiert – eine vollständige Rücksetzung fand offenbar nicht statt.

Ich war gezwungen, das gesamte System manuell zu prüfen: Funktionieren alle Dienste? Wurden durch Up-/Downgrades Sicherheitslücken erzeugt? Das kostete mich mehrere Stunden.

Offenbar folgt auch Ubuntu inzwischen dem Prinzip „Tippen first, Bedenken second!“ – ganz wie die Kollegen bei Mircosaft in Redmond, wo Copy-and-Paste-Entwicklung per Google oder ChatGPT zur Praxis geworden zu sein scheint.

Als ehemaliger Verantwortlicher für die Update-Entwicklung von über 16.000 einarmigen Banditen (Spielautomaten) und 4.500 Point-of-Sale-Systemen weiß ich, wie herausfordernd robuste Update-Routinen sind – insbesondere bei heterogener Hardware und Software für verschiedene Kunden. Zum Glück war unsere Umgebung überschaubar: vier Betriebssysteme (Windows NT 4, 2000, XP und DOS 7.x), bekannte Hardwarekonstellationen.

Ein Ausfall konnte teure Folgen haben: Im September 2007 hatten zwei Geräte in einem Londoner Shop innerhalb einer Woche rund eine Viertelmillion Pfund umgesetzt – doch die verschlüsselten Logdateien wurden nicht automatisch zur Zentrale übertragen. Mit einem speziellen Update konnte ich die Übertragung erzwingen – das war mein erster bewusster Kontakt mit wirtschaftlich relevanter Zahlen und Fakten. Fun Fact: Im August 2007 tauschte ich am Flughafen Heathrow Euros in Pfund – für 1 € bekam ich 1,47 £!

Die Strategie:

Damals entwickelte ich eine Update-Strategie, die ich wie folgt zusammenfassen kann:

I. Ganz oder gar nicht! Ein Update gilt nur als erfolgreich, wenn es am Ende vollständig abgeschlossen und das System funktionsfähig ist. Andernfalls wird alles rückgängig gemacht – inklusive aller Dateien und Konfigurationen. Axiom & Tipp: Was man nicht anfasst, muss man nicht rückgängig machen. Konkret bedeutet dieser Axiom: arbeite immer mit der Kopie oder Clone und nimals mit dem Original!

II. Nur ein Reboot! Maximal ein einziger Neustart ist erlaubt. Zwei sind bereits einer zu viel.

III. Aktivierung in Sekunden: Das eigentliche Aktivieren eines Updates muss innerhalb weniger Sekunden erfolgen (z. B. durch Verschieben ganzer Verzeichnisse statt Kopieren: move statt copy).

IV. Vorbereitung darf unterbrechbar sein: Bereits heruntergeladene oder kopierte Dateien dürfen nicht erneut übertragen werden müssen.

V. Alles zuerst vor Ort: Sämtliche Tools, Patches, Dateien und Konfigurationen müssen vorab vollständig und korrekt (via Checksummen) vorhanden sein.

VI. Bedingungen prüfen: Alle Vorbedingungen – Betriebssystemversion, Anwendungsversionen, Kundennummer usw. – müssen erfüllt sein, bevor überhaupt etwas passiert.

Rückwärts gelesen ergibt sich daraus diese logische Update-Reihenfolge:

1. Vorbedingungen prüfen
2. Dateien kopieren
3. Vorbereitung
4. Aktivierung
5. Reboot

Hinweis: Die Phase „Vorbereitung darf unterbrechbar sein“ ist in dieser Liste nicht als separater Schritt aufgeführt, da der jeweilige Zustand über Flags gespeichert wird. Damit kann ein Update beim letzten erfolgreichen Schritt fortgesetzt werden – besonders bei großen Dateien (> 2 MB), die ggf. in Chunks aufgeteilt werden müssen.

Seit dem September-Update-Project 2007 folgten alle meine Update-Prozesse konsequent dieser konfigurierbaren Struktur, die ich hier in einem „Pseudo Batch-Script“ versucht habe grob zu veranschaulichen:

:: Psudo batch script für DOS 7.x
:: Auf Schleifen wurde absichtlich verzichtet
:: damit der Code einfacher und verständlich bleibt
:: Es geht hier um das Konzept und weniger eleganter Code!

REM Phase und andere Parameter übernehmen
set Phase=%1
set Kunde=%2

:Label_Bedingungen
set Bedingung1=something
if not Bedingung1 (
	print log "Bedingung1 nicht erfüllt"
	exit
)
set Bedingung=someOtherThing
if not Bedingung2 (
	print log "Bedingung2 nicht erfüllt"
	exit
)
:: ... usw. usf.

if exist backup.flag do goto Label_Download

:Label_Backup
print log "Backup files..."
copy C:\x1\y1 C:\Updates\%updateName%\x1\y1
copy C:\x2\y2 C:\Updates\%updateName%\x2\y2
copy C:\x3\y3 C:\Updates\%updateName%\x3\y3
write %date% > backup.flag

:Label_Download
if not exist file1.flag (
	download file-part1.zip
	write %date% > file1.flag
)
if not exist file2.flag (
	download file-part2.zip
	write %date% > file2.flag
)
:: ... usw. usf.

if not %Phase%=Prepare do exit

:Label_Prepare
if not exist prepare0.flag (
	print log "Decompressing file0.part1.zip..."
	unzip file0.part1.zip to C:\Updates\%updateName%\app1\*.*
	write %date% > prepare0.flag
)
if not exist prepare1.flag (
	print log "Patching file blabla.dat..."
	copy %Programs%\acme\app1\app1.exe C:\Updates\%updateName%\app1\
	patch.exe diff=C:\Updates\%updateName%\app1\app1.diff target=C:\Updates\%updateName%\app1\app.exe
	write %date% > prepare0.flag
)
:: ... usw. usf.

if not %Phase%=Activate do exit

REM Ab hier gilt: sollte etwas bis hier schiefgelaufen sein, dann:
REM 1. wären wir gar nicht so weit gekommen (dank Flags)
REM 2. die Produktiv-Dateien wurden gar nicht angefasst (nur ins Upd. Verz. kopiert)
REM 3. Kann man im "Notfall" einfach Flags + Dateien im zugehörigen Update-Verz. löschen
REM 4. Der aktuelle Systemzustand ist immer noch vollfunktionstüchtig :-)

:Label_Activate
move -recursive -force -quiet C:\Updates\%updateName%\app1\ %Programs%\acme\app1\*
move -recursive -force -quiet C:\Updates\%updateName%\app2\ %Programs%\acme\app2\*
move -recursive -force -quiet C:\Updates\%updateName%\app3\ %Programs%\acme\app3\*
delete C:\irgend\wo\irgend\eine.datei

:Label_Reboot
print log "Rebooting..."
REM Sofortiges Reboot ohne Anwenderbenachrichtigung
REM ist nicht zu empfehlen, aber möglich.
shutdown -reboot -time 0

  

Egal wie gut und elegant der Algorithmus, Code oder die Konzepte und Paradigmen oder Strategien sind: ein Update MUSS IMMER GUT GESTESTET SEIN, BEVOR MAN ES IN DIE WELT AUF DIE LEUTE LOSLÄSST!