Installieren und aktualisieren, ohne zu raten

Eine Anwendung, die nur auf dem Rechner ihres Entwicklers läuft, ist ein Prototyp. Damit GODAV Pro auf einem fremden Server läuft, braucht es zwei Dinge: einen Weg, es dort zum ersten Mal einzurichten, und einen Weg, es danach auf dem neuesten Stand zu halten. Beides steht auf der Roadmap für 1.0.0 als ein Punkt, und beides war mehr Arbeit, als der Name vermuten lässt.

Ein Installer, der vorher fragt

Der Installer ist ein Skript für das Linux-Terminal. Bevor er irgendetwas anlegt, prüft er, ob alles da ist, was GODAV braucht, und meldet jede Komponente einzeln mit „OK” oder „Fehler”. Erst wenn diese Prüfung durch ist, stellt er seine Fragen: wie die Anwendung erreichbar sein soll, ob mit HTTPS, ob Demodaten angelegt werden sollen. Am Ende prüft er, ob die Anwendung wirklich antwortet, und meldet erst dann Erfolg.

Der erste echte Test auf einem frischen Ubuntu-Server war lehrreich. Der Installer kam nie bis zum Dienst, und zwei weitere Fehler lagen auf demselben Weg. Noch unangenehmer waren zwei Fehler, die wie Erfolg aussahen: Die Anwendung lief, der Gesundheitscheck war grün, aber es gab kein Administratorkonto, mit dem man sich hätte anmelden können, und die Hilfe war leer. Seitdem baut ein eigenes Skript das Paket und prüft dabei auch die Teile des Installers, die vorher nie gelaufen waren.

Eine Entscheidung dabei betrifft die Demodaten. Die vierzig Demopersonen brauchen ein Passwort, weil in ihrem Namen Vorgänge und Kommentare entstehen. Ich hätte allen dasselbe bekannte Passwort geben können, das ist bequem. Auf einem Server, der im Netz erreichbar ist, wären das aber vierzig bekannte Zugänge. Deshalb bekommt jedes Demokonto ein eigenes Zufallspasswort, das nach dem Lauf niemand kennt. Der einzige Zugang, den der Installer nennt, ist der des Administrators, und der erscheint genau einmal auf dem Bildschirm.

Die Übersicht der Systemseite. Was die Installation betreiben darf, steht hier, die Angaben selbst sind verpixelt.

Pakete, die ihre Herkunft beweisen

Jedes Installationspaket ist signiert. Dabei unterschreibe ich nicht die fertige Zip-Datei, sondern eine Liste aller Dateien darin samt Prüfsumme. Ich hätte auch nur die Hülle signieren können, das ist der übliche Weg. Dann wüsste man aber nur, dass die Schachtel unberührt ist, nicht was darin liegt. So fällt jede einzelne ausgetauschte Datei auf, auch das Installationsskript selbst.

Wichtig ist auch, wer prüft. Der Prüfer kommt aus der bereits installierten Anwendung, nicht aus dem neuen Paket. Ein Paket, das seinen eigenen Prüfer mitbringt, beweist nichts.

Außerdem steht seitdem die Buildnummer im Dateinamen. Zwei Pakete derselben Version waren vorher im Downloadordner nicht auseinanderzuhalten.

Das Update über die Oberfläche

Zuerst lief jedes Update über das Terminal. Das setzt voraus, dass der Betreiber sich auf dem Server anmelden kann und dort Administratorrechte hat. Inzwischen geht es unter System › Update im Browser: Paket hineinziehen, Version und Build werden aus dem Archiv gelesen, „Update starten”, und das Protokoll läuft mit.

Auf dem Entwicklungsrechner bleibt die Ablagefläche gesperrt; hier gibt es keine installierte Instanz.

Der naheliegende Weg wäre gewesen, im Formular nach Benutzername und Passwort des Servers zu fragen und das Update direkt aus der Anwendung mit erhöhten Rechten zu starten. Ich habe mich dagegen entschieden. Die Anwendung läuft bewusst mit möglichst wenigen Rechten, und das ist die wichtigste Bremse, falls jemals eine Lücke darin gefunden wird. Diese Bremse für ein Update zu lösen, hieße, sie für alles zu lösen. Stattdessen legt die Anwendung nur das Paket und einen Auftrag ab. Ein getrennter Dienst des Betriebssystems bemerkt das und erledigt den Rest: Signatur prüfen, Datenbank sichern, dann installieren. Scheitert die Sicherung, ist noch nichts angefasst.

Am Ende braucht ein Update damit zweierlei: ein Paket, das ich signiert habe, und ein Administratorkonto in der Anwendung. Wer nur eines davon hat, kommt nicht weit.

Welcher Stand gerade läuft, zeigt das Info-Fenster in der Seitenleiste.

Außerdem

• Bei einer Aktualisierung bleibt eine vorhandene Konfiguration unangetastet.
• Ein Paket, das nicht neuer ist als der laufende Stand, braucht eine ausdrückliche Bestätigung.
• Nichts wird automatisch zurückgerollt. Der Lauf nennt die Sicherung, aus der sich der vorige Stand wiederherstellen lässt.
• Ein eigenes Skript entfernt eine Installation vollständig, mit Trockenlauf als Vorgabe.

Das allererste Update auf eine Installation, die den neuen Bereich noch nicht kennt, läuft noch einmal über das Terminal. Danach geht es nur noch über den Browser.