upgrade.sh findet die Fassung 1.x auch im Archiv
Nach einem Umbenennen liegt unter /srv/<app> die laufende Installation und die Fassung 1.x unter /srv/<app>-sonnet5 -- dorthin verschiebt rename.sh sie. Die Vorgabe von upgrade.sh zeigte danach auf die neue Installation und brach ab (sauber, aber unbrauchbar). Gesucht wird jetzt an beiden Orten; erkannt wird eine 1.x an der sqlite.db im Wurzelverzeichnis. Den Weg selbst habe ich gegen die echten Altdaten geprueft, nicht behauptet: aus /srv/tesm-sonnet5 (Version 1.2.8) kamen 4 Clients, 2 Zugangsdaten und die DHCP-Konfiguration in eine Probeinstanz, aus /srv/tesm-license-sonnet5 (Version 1.2.7) 2 Kunden, 2 Tickets und 2 neu signierte Lizenzen samt uebernommenem Signaturschluessel und Anbieterblock. Die laufenden Installationen blieben unberuehrt, die Probeinstanzen sind abgeraeumt. Zwei Tests halten die beiden Skripte zusammen: derselbe Namenszusatz, und die Suche laeuft ueber die echten Zeilen aus upgrade.sh. Version 2.0.8. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -152,6 +152,13 @@ sudo bash deploy/upgrade.sh --app tesm
|
||||
sudo bash deploy/upgrade.sh --app tesm-license
|
||||
```
|
||||
|
||||
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
|
||||
gebraucht wird -- danach liegt unter `/srv/<app>` die **laufende** Installation.
|
||||
Erkannt wird eine 1.x an der `sqlite.db` im Wurzelverzeichnis; die neue Fassung
|
||||
legt ihre Datenbank unter `data/app.db` ab.
|
||||
|
||||
Der Ablauf ist die Vorgabe und braucht keine Schalter:
|
||||
|
||||
| | |
|
||||
|
||||
Reference in New Issue
Block a user