alientimandClaude Opus 5 160675e368 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>
2026-09-03 16:18:52 +02:00
2026-09-02 18:00:06 +02:00

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_KEY fü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.

S
Description
Modernes UI-Rebuild des Aruba-PoE Managers (Dashboard, Rechtesystem, Browser-SSH-Terminal)
Readme
3.1 MiB
TESM 2.0.9
Latest
2026-09-03 16:18:53 +02:00
Languages
Python 65.7%
HTML 20.6%
Shell 6.5%
CSS 4.6%
JavaScript 2.6%