-
TESM-Lizenzserver 2.0.9 Stable
released this
2026-09-03 16:18:55 +02:00 | 0 commits to main since this releaseEine Datei genügt
upgrade.shundupdate.shholen sich das Release jetzt selbst. Auf einem
System, auf dem noch nichts von dieser Fassung liegt -- und das ist bei einem
Upgrade von 1.2.8 der Regelfall:curl -fsSLO https://gitea.int.eertmoed.net/alientim/tesm-license/raw/branch/main/deploy/upgrade.sh sudo bash upgrade.sh --app tesm-licenseBisher verlangte
upgrade.shein entpacktes Release daneben und brach sonst ab
-- die falsche Voraussetzung für genau den Fall, für den es gedacht ist. Liegt
das Skript doch in einem entpackten Release, wird dieses benutzt statt
eines Downloads: wer ein Paket ausgepackt hat, will nicht, dass ungefragt ein
anderes geladen wird. Mit--tag v2.0.9lässt sich eine Version festlegen.Der Bootstrap steht wortgleich in beiden Skripten; zwei eigenständige Dateien
können sich keine dritte teilen. Drei Tests halten das zusammen: die Blöcke
müssen gleich sein,upgrade.shdarf kein Release daneben verlangen, und mit
leeremPATHmuss der Block das fehlende Werkzeug benennen.update.shruftinstall.shnicht mehr perexecauf -- dadurch lief die
Aufräumfalle nie, und jedes Update liess ein entpacktes Release unter/tmp
liegen.Geprüft, nicht behauptet
Die einzelne
upgrade.shhat eine echte 1.2.8 in dasselbe Verzeichnis auf
diese Fassung gebracht: Release geladen, Clients, Zugangsdaten und die
DHCP-Konfiguration übernommen, Dienst läuft. Die Sicherung enthält die alte
Installation samtsqlite.dbundfernet.key(Verzeichnis 0700, Passphrase
0600),/tmpbleibt leer.Kleinigkeit
opusist aus allen Beispielen verschwunden. Das war der Name einer
Testinstanz; seit die Installationen wie ihre Anwendung heissen, ist er in
einer Hilfe nur ein Rätsel. In der Betriebsdoku stand dabei zweimal/opt
statt/srv.Installation
sudo bash /srv/tesm-license/deploy/update.sh tesm-licenseDownloads