alientimandClaude Opus 5
4065b3586b
Drei Fehler, alle drei gemessen statt vermutet.
1. Freigaben wurden nie eingebunden ("mount error(1): Operation not
permitted"). Ursache war NICHT der Mount-Namensraum, sondern
SystemCallFilter=@system-service: darin fehlen mount/umount2, und
SystemCallErrorNumber=EPERM macht daraus genau diese Meldung. Nachgewiesen
in einem nachgebauten Sandkasten: mit "@mount" gelingt die Einbindung,
ohne nicht. Die Unit von TESM erlaubt jetzt "@system-service @mount"; alles
andere an der Haertung bleibt. Der zuvor eingebaute Umweg ueber nsenter ist
zurueckgenommen -- RestrictNamespaces=yes verbietet setns, er konnte nie
funktionieren.
Eingebunden wird damit im Namensraum des Webprozesses. Deshalb ist die
Aufraeumaufgabe fuer abgelaufene Einbindungen aus dem Ueberwachungsdienst in
den Webprozess gewandert: ein anderer Dienst sieht diese Einbindungen nicht
und haette Datenbankzeilen als geloest markiert, waehrend die Freigabe
eingebunden blieb.
2. apt-Installationen aus der Oberflaeche scheiterten mit "dpkg returned an
error code (1)". Der Sandkasten wird an dpkg und dessen Maintainer-Skripte
weitervererbt; mit ProtectKernelLogs=yes liefert "dmesg" ein EPERM und ein
Postinst-Skript bricht daran ab. apt laeuft jetzt ueber systemd-run, also
von PID 1 gestartet und damit ohne unsere Haertung.
3. Der RPC-Neustart loeste SSH aus. run_reboot entschied den Weg anhand von
device["category"] -- und dieser Schluessel bedeutet je Herkunft etwas
anderes: die Wartungsabfrage legt die Kategorie der *Zugangsdaten* darunter,
inventory.get_device die des *Geraets*. Ueber die Statusuebersicht kam ein
Windows-Geraet mit leerer Geraetekategorie an, wurde fuer Linux gehalten und
ueber SSH auf Port 22 angesprochen, bis das Zeitlimit griff. Der Weg wird
jetzt uebergeben -- entschieden wird er ohnehin schon vorher in
restart.resolve. Ausserdem zeigte die Neustart-Historie alles ausser "ssh"
als "PoE-Port"; RPC hat jetzt einen eigenen Eintrag.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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_KEYfuer nginx-Site, netplan, logrotate, Zertifikate und Sitzungscookie. - Verschachtelte Datenbankverbindungen sind ein Fehler, kein Deadlock.