TESM

Verwaltung von PoE-Geraeten und Aruba-Switchen: Inventar, Zustandsueberwachung, Portsteuerung, Neustart (PoE, SSH, RPC), DHCP ueber Kea, Dateifreigaben, Wartung ueber SSH, Protokolle, Papierkorb, verschluesselte Ein- und Ausfuhr und ein SSH-Terminal im Browser.

Dieses Repository enthaelt genau das, was zum Installieren und Betreiben von TESM gebraucht wird -- nichts darueber 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 Serverhaelfte 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, unveraendert 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 verschluesselt.

Mit oeffentlichem 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, laeuft TESM ohne --https schlicht auf Port 80.

Eine zweite Installation zum Testen stoert die laufende nicht:

sudo bash deploy/install.sh --app tesm --instance test --port 5100 --http-port 8080

Jede Instanz bekommt eigene Datenbank, eigene Schluessel, eigene nginx-Site und ein eigenes Sitzungscookie.

Aktualisieren

sudo bash deploy/update.sh --app tesm

Das laedt ein Release, entpackt es und ruft dessen install.sh auf. Vor jedem Update entsteht ein vollstaendiges Backup -- unabhaengig davon, ob sich das Schema geaendert hat -- und danach laeuft 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 zuruecksetzen
sudo -u tesm tesm-admin check-now           # Ueberwachungsdurchlauf sofort
sudo -u tesm tesm-admin housekeeping        # Sitzungen und Protokolle aufraeumen
sudo -u tesm tesm-admin web-setup --https   # nginx und TLS einrichten

Umzug aus dem alten TESM

Ein Export des Vorgaengers laesst sich uebersetzen und dann ueber 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 ausdruecklich, was nicht uebersetzt werden kann (lokale Konten, Rechte, Verzeichnisdienst, Webserver) -- das ist von Hand nachzuziehen.

Die Passphrase gehoert an die verdeckte Eingabeaufforderung. --passphrase existiert nur fuer 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 Vorgaengers sind bekannt; an den Stellen, an denen sie entstanden sind, steht jetzt ein Kommentar, der erklaert, warum es hier anders geloest ist. Die wichtigsten:

• Kein root fuer die Anwendung. Ein einziger allowlisted Helfer mit Argumentpruefung statt eines Webprozesses als root.
• CSRF-Schutz ueberhaupt. Der Vorgaenger hatte keinen.
• Rechte werden serverseitig geprueft, nicht nur im Template ausgeblendet.
• Die nginx-Site wird bei jedem Lauf inhaltlich verglichen und erneuert. Ein falscher alias-Pfad ueberlebte im Vorgaenger jahrelang jedes Update.
• Jede erzeugte Konfiguration wird vor dem Uebernehmen geprueft -- nginx wie Kea. Eine fehlerhafte Datei faellt beim Schreiben auf, nicht erst beim naechsten Start des Dienstes.
• Kein Hostname im Lizenz-Fingerabdruck. Umbenennen brach die Bindung.
• Zwei Installationen stoeren sich nicht -- eigener SITE_KEY fuer nginx-Site, netplan, logrotate, Zertifikate und Sitzungscookie.
• Verschachtelte Datenbankverbindungen sind ein Fehler, kein Deadlock.