upgrade.sh und update.sh genuegen als einzelne Datei

Auf einer 1.2.8 liegt nichts von dieser Fassung -- upgrade.sh verlangte aber
ein install.sh daneben und brach sonst ab. Das war die falsche Voraussetzung
fuer genau den Fall, fuer den das Skript gedacht ist. Beide Skripte holen sich
das Release jetzt selbst:

    curl -fsSLO .../raw/branch/main/deploy/upgrade.sh
    sudo bash upgrade.sh --app tesm

Liegt das Skript in einem entpackten Release, wird dessen install.sh benutzt
statt eines Downloads: wer ein Paket ausgepackt hat, will nicht, dass ungefragt
ein anderes geladen wird. Mit --tag laesst sich eine Version festlegen.

Der Bootstrap steht wortgleich in beiden Dateien -- zwei eigenstaendige
Skripte koennen sich keine Datei teilen, und beide sollen allein genuegen. Ein
Hygienetest vergleicht die Bloecke, ein zweiter prueft, dass upgrade.sh kein
entpacktes Release mehr verlangt, ein dritter fuehrt den Block mit leerem PATH
aus und erwartet, dass er das fehlende Werkzeug benennt.

update.sh ruft install.sh nicht mehr per exec auf: dadurch lief die
Aufraeumfalle nie, und jedes Update liess ein entpacktes Release unter /tmp
liegen.

Ausserdem "opus" aus allen Beispielen genommen. Das war der Name der
Testinstanz neben der Fassung 1.x; seit dem Umbenennen heissen die
Installationen wie ihre Anwendung, und in einer Hilfe, die jemand anders liest,
ist "opus" ein Raetsel. In BETRIEB.md stand dabei zweimal /opt statt /srv.

Geprueft am System, nicht behauptet: die einzelne upgrade.sh hat eine echte
1.2.8 (Kopie des Archivs) **in dasselbe Verzeichnis** auf 2.0.8 gebracht --
Release geladen, 4 Clients, 2 Zugangsdaten und die DHCP-Konfiguration
uebernommen, Dienst laeuft, /login 200. Die Sicherung enthaelt die 1.2.8 samt
sqlite.db und fernet.key (Verzeichnis 0700, Passphrase 0600), und /tmp bleibt
leer. Danach dieselbe Probe mit der einzelnen update.sh.

Version 2.0.9.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/BETRIEB.md

@@ -105,19 +105,26 @@ Eine bereits eingerichtete HTTPS-Konfiguration bleibt erhalten, auch ohne
 
 ### Ohne Quellbaum: `update.sh`
 
-Liegt kein entpacktes Release vor, holt `update.sh` es selbst -- es lädt das
-Release-Asset, entpackt es und ruft dessen `install.sh` auf:
+`update.sh` genügt als **einzelne Datei**. Auf einem System, auf dem noch nichts
+von diesem Projekt liegt:
 
 ```bash
-sudo bash /opt/tesm/deploy/update.sh tesm
-sudo bash /opt/tesm-license/deploy/update.sh tesm-license
+curl -fsSLO https://gitea.int.eertmoed.net/alientim/tesm/raw/branch/main/deploy/update.sh
+sudo bash update.sh tesm
+```
+
+Auf einer bestehenden Installation liegt sie schon bereit:
+
+```bash
+sudo bash /srv/tesm/deploy/update.sh tesm
+sudo bash /srv/tesm-license/deploy/update.sh tesm-license
 ```
 
 Alles nach dem Tag geht unverändert an `install.sh` weiter -- das ist der Weg,
 eine **benannte Instanz** zu aktualisieren:
 
 ```bash
-sudo bash /opt/tesm-opus/deploy/update.sh tesm latest --instance opus
+sudo bash /srv/tesm/deploy/update.sh tesm
 ```
 
 Ohne `--instance` entstünde daneben eine zweite Installation namens `tesm`, mit
@@ -147,11 +154,26 @@ Ein eigenes Skript, weil dabei mehr passiert als ein Dateiabgleich: die alte
 Fassung hat ein anderes Schema, andere Rechteschlüssel und ein anderes
 Exportformat.
 
+Auch `upgrade.sh` genügt als **einzelne Datei** -- und das ist hier der
+Regelfall: auf einer 1.2.8 liegt nichts von dieser Fassung.
+
+```bash
+curl -fsSLO https://gitea.int.eertmoed.net/alientim/tesm/raw/branch/main/deploy/upgrade.sh
+sudo bash upgrade.sh --app tesm
+```
+
+Sie lädt das aktuelle Release, entpackt es und benutzt dessen `install.sh`.
+Liegt das Skript in einem entpackten Release, wird dieses benutzt statt eines
+Downloads -- wer ein Paket ausgepackt hat, will nicht, dass ungefragt ein
+anderes geladen wird:
+
 ```bash
 sudo bash deploy/upgrade.sh --app tesm
 sudo bash deploy/upgrade.sh --app tesm-license
 ```
 
+Eine bestimmte Version statt `latest`: `--tag v2.0.8`.
+
 Ohne `--source` wird die alte Fassung an zwei Stellen gesucht: unter
 `/srv/<app>` und unter `/srv/<app>-sonnet5`. Der zweite Ort ist der, an den
 `rename.sh` sie verschiebt, sobald der Hauptname für die neue Installation
@@ -184,7 +206,7 @@ Export des Vorgängers und taugt deshalb auch als Rückweg.
 und die alte bleibt vollständig liegen:
 
 ```bash
-sudo bash deploy/upgrade.sh --app tesm --instance opus      --keep-old-running --port 5100 --http-port 8080
+sudo bash deploy/upgrade.sh --app tesm --instance test      --keep-old-running --port 5100 --http-port 8080
 ```
 
 **Was nicht mitkommt** -- und warum:
@@ -280,7 +302,7 @@ die niemand mehr füllte.
 Von Hand prüfen:
 
 ```bash
-sudo /usr/local/lib/tesm/tesm-motd --app tesm --root /srv/tesm-opus
+sudo /usr/local/lib/tesm/tesm-motd --app tesm --root /srv/tesm-test
 ```
 
 Der Aufruf im Banner ist mit `timeout 3` und `|| true` abgesichert: ein
@@ -295,8 +317,8 @@ entfernt -- nur dieses, nichts anderes in dem Verzeichnis.
 Aus einer Instanz die Hauptinstallation machen (oder umgekehrt):
 
 ```bash
-sudo bash deploy/rename.sh --app tesm --from tesm-opus --to tesm
-sudo bash deploy/rename.sh --app tesm-license --from tesm-license-opus --to tesm-license
+sudo bash deploy/rename.sh --app tesm --from tesm-test --to tesm
+sudo bash deploy/rename.sh --app tesm-license --from tesm-license-test --to tesm-license
 ```
 
 Der Name steckt an mehr Stellen als im Verzeichnisnamen, und drei davon sind