alientimandClaude Opus 5
160675e368
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>
5.8 KiB
TESM
Verwaltung von PoE-Geräten und Aruba-Switchen: Inventar, Zustandsüberwachung, Portsteuerung, Neustart (PoE, SSH, RPC), DHCP über Kea, Dateifreigaben, Wartung über SSH, Protokolle, Papierkorb, verschlüsselte Ein- und Ausfuhr und ein SSH-Terminal im Browser.
Dieses Repository enthält genau das, was zum Installieren und Betreiben von TESM gebraucht wird -- nichts darüber hinaus:
apps/tesm die Anwendung
packages/tesm-core gemeinsamer Kern (Anmeldung, Rechte, Sicherung, nginx, ...)
packages/tesm-licensing Lizenzprotokoll, Clientseite
deploy/ install.sh, update.sh, release.sh, systemd, privilegierter Helfer
docs/ Betrieb und Sicherheit
Die Serverhälfte des Lizenzprotokolls (tesm-licensing-server: ausstellen,
erneuern, Antworten signieren) liegt nicht hier. TESM verifiziert Lizenzen
und stellt Anfragen; den Code zum Ausstellen soll ein Client nicht einmal
mitbringen.
| Wo sonst noch | |
|---|---|
| alientim/tesm-license | der Lizenzserver |
| alientim/TESM-DEV | Entwicklung: beide Anwendungen, Tests, Architekturdoku |
Zweige
| Zweig | Inhalt |
|---|---|
main |
dieser Neubau (Version 2.0.0) |
SONNET5 |
der Stand davor, unverändert aufbewahrt |
Installation
sudo bash deploy/install.sh --app tesm --https
sudo -u tesm tesm-admin create-admin
Danach https://<host>/. Ohne --domain entsteht ein selbstsigniertes
Zertifikat; der Browser warnt einmal, die Verbindung ist verschlüsselt.
Mit öffentlichem Namen und Let's Encrypt stattdessen:
sudo bash deploy/install.sh --app tesm --https --domain tesm.firma.de --acme-email it@firma.de
Zielzustand: Port 443 mit TLS, Port 80 leitet dorthin um -- ausser dem ACME-Pfad, der erreichbar bleiben muss, sonst kann Let's Encrypt nie erneuern.
Sitzt ein eigener Reverse Proxy davor, der TLS beendet, läuft TESM ohne
--https schlicht auf Port 80.
Eine zweite Installation zum Testen stört die laufende nicht:
sudo bash deploy/install.sh --app tesm --instance test --port 5100 --http-port 8080
Jede Instanz bekommt eigene Datenbank, eigene Schlüssel, eigene nginx-Site und ein eigenes Sitzungscookie.
Aktualisieren
sudo bash deploy/update.sh --app tesm
Das lädt ein Release, entpackt es und ruft dessen install.sh auf. Vor jedem
Update entsteht ein vollständiges Backup -- unabhängig davon, ob sich das
Schema geändert hat -- und danach läuft ein Health-Check mit automatischem
Rollback.
Betrieb von der Kommandozeile
sudo -u tesm tesm-admin status # Zustand der Installation
sudo -u tesm tesm-admin create-admin # Konto anlegen oder zurücksetzen
sudo -u tesm tesm-admin check-now # Überwachungsdurchlauf sofort
sudo -u tesm tesm-admin housekeeping # Sitzungen und Protokolle aufräumen
sudo -u tesm tesm-admin web-setup --https # nginx und TLS einrichten
Umzug aus dem alten TESM
Ein Export des Vorgängers lässt sich übersetzen und dann über den normalen Import einlesen -- Clients, Switche, Zugangsdaten und die DHCP-Konfiguration:
sudo -u tesm tesm-admin convert-legacy tesm_export_20260813_195455.json --dry-run
--dry-run zeigt nur den Bericht. Ohne die Option entsteht eine Datei im
neuen Format, die unter Verwaltung -> Sicherung eingelesen wird. Der Bericht
nennt ausdrücklich, was nicht übersetzt werden kann (lokale Konten,
Rechte, Verzeichnisdienst, Webserver) -- das ist von Hand nachzuziehen.
Die Passphrase gehört an die verdeckte Eingabeaufforderung. --passphrase
existiert nur für Automatisierung: es schreibt sie in Shell-Historie und
Prozessliste.
Release bauen
git tag -a v2.0.0 -m "TESM 2.0.0" && git push origin v2.0.0
bash deploy/release.sh v2.0.0
Heraus kommt tesm-v2.0.0.tar.gz samt SHA-256. Der Name kommt aus dem
Repository, nicht aus einer festen Zeichenkette.
Dokumentation
| docs/BETRIEB.md | Installation, Update, HTTPS, Sicherung, Fehlersuche |
| docs/SICHERHEIT.md | Anmeldung, Sitzungen, CSRF, Geheimnisse, Rechtetrennung |
Aufbau und Entwurfsentscheidungen stehen in docs/ARCHITEKTUR.md im
Entwicklungsrepository, ebenso die Tests.
Was diese Fassung anders macht
Ein Neubau. Die Fehler des Vorgängers sind bekannt; an den Stellen, an denen sie entstanden sind, steht jetzt ein Kommentar, der erklärt, warum es hier anders gelöst ist. Die wichtigsten:
- Kein root für die Anwendung. Ein einziger allowlisted Helfer mit
Argumentprüfung statt eines Webprozesses als
root. - CSRF-Schutz überhaupt. Der Vorgänger hatte keinen.
- Rechte werden serverseitig geprüft, nicht nur im Template ausgeblendet.
- Die nginx-Site wird bei jedem Lauf inhaltlich verglichen und erneuert. Ein
falscher
alias-Pfad überlebte im Vorgänger jahrelang jedes Update. - Jede erzeugte Konfiguration wird vor dem Übernehmen geprüft -- nginx wie Kea. Eine fehlerhafte Datei fällt beim Schreiben auf, nicht erst beim nächsten Start des Dienstes.
- Kein Hostname im Lizenz-Fingerabdruck. Umbenennen brach die Bindung.
- Zwei Installationen stören sich nicht -- eigener
SITE_KEYfür nginx-Site, netplan, logrotate, Zertifikate und Sitzungscookie. - Verschachtelte Datenbankverbindungen sind ein Fehler, kein Deadlock.
Von einer Installation der Fassung 1.x
Eine einzelne Datei genügt -- sie lädt das Release selbst:
curl -fsSLO https://gitea.int.eertmoed.net/alientim/tesm/raw/branch/main/deploy/upgrade.sh
sudo bash upgrade.sh --app tesm
Sichert die alte Installation, schaltet sie ab, installiert diese Fassung und übernimmt die Daten. Einzelheiten und was nicht mitkommt: docs/BETRIEB.md.