SSL/TLS (neue Seite Einstellungen -> SSL/TLS, eigenes Recht settings_ssl.view/.edit):
- Zertifikat+privater Schluessel per Upload hinterlegbar (PEM), Validierung
VOR dem Speichern: gueltiges Zertifikat, noch nicht abgelaufen, Schluessel
passt zum Zertifikat (Abgleich ueber die oeffentlichen Schluessel als
DER-Bytes -- funktioniert algorithmus-unabhaengig fuer RSA/EC/...).
Speicherort /etc/tesm/ssl (bewusst ausserhalb von /srv/tesm, damit
rsync --delete beim Update das Zertifikat nicht mitloescht), Key mit
chmod 600.
- HTTPS aktivieren schreibt/validiert (nginx -t) eine neue nginx-Konfiguration
und laedt erst danach neu; Port 80 leitet dann automatisch auf https weiter.
HSTS optional zuschaltbar, setzt aktives SSL voraus.
- Gleiches Sicherheitsnetz wie bei den Netzwerkeinstellungen: nach dem
Anwenden 45s Zeitfenster zum Bestaetigen, sonst automatischer Rueckroll
der nginx-Konfiguration UND der ssl_enabled/hsts_enabled-Einstellungen.
Beide Pfade (Timeout-Rollback und Bestaetigen-verhindert-Rollback) live
auf Testsystem-Update-Restart verifiziert, inklusive eines ECHTEN,
ungeplant ausgeloesten Rollbacks waehrend des Testens.
- Noch KEINE Let's-Encrypt-Automatisierung (siehe Kommentar im Code) --
alle bekannten Instanzen laufen intern ohne oeffentliche Domain, HTTP-01
wuerde dort nicht funktionieren; kann bei Bedarf separat ergaenzt werden.
install.sh: Update-Idempotenz ("nur anfassen, was sich geaendert hat"):
- install_if_changed()-Helfer: Custom-Skript/systemd-Units/MOTD-Banner
werden nur noch bei tatsaechlich geaendertem Inhalt neu geschrieben,
daemon-reload nur wenn sich mindestens eine Unit geaendert hat.
- nginx-Konfiguration wird nur noch bei einer Frischinstallation aus dem
Repo-Template geschrieben -- eine bereits vorhandene (egal ob unveraendert
oder von der App selbst um SSL erweitert) wird nie wieder ueberschrieben.
Voraussetzung dafuer, dass die neue SSL-Funktion ein Update ueberlebt.
update.sh: komplette Sonderbehandlung fuer die zwei TESM vorausgehenden
Generationen (rpi-check.service, poe_web.service/poe_manager) entfernt --
auf allen aktuellen Installationen laengst migriert. Deaktivierte
Unit-Dateien dieser Generationen wurden auf Testsystem-Update-Restart
zusaetzlich manuell endgueltig geloescht (waren dort seit einer Migration
im September 2025 nur deaktiviert, nicht entfernt).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
install.sh erkennt jetzt selbststaendig eine bestehende Installation
(an sqlite.db) und verhaelt sich entsprechend:
- Keine vorhandene Installation -> normale Frischinstallation (wie
bisher).
- Vorhanden, SCHEMA_VERSION unveraendert -> einfaches In-Place-Update,
kein Backup noetig (rsync schliesst sqlite.db ohnehin aus).
- Vorhanden, SCHEMA_VERSION unbekannt/abweichend -> Update MIT
Sicherheitsnetz: die KOMPLETTE bisherige Installation (Code, venv,
Datenbank, Schluessel) wird vorher 1:1 nach
/srv/tesm-backup-pre-migration-<timestamp> kopiert (bewusst nicht nur
die Datenbank -- ein reines DB-Rollback wuerde beim naechsten Start
mit dem NEUEN Code sofort denselben Migrationsfehler wiederholen).
Die eigentliche Schema-Migration uebernimmt danach die App selbst
beim Start (_ensure_schema() in app.py). Kommt der Dienst
anschliessend per HTTP-Check auf /login nachweislich NICHT gesund
hoch, wird automatisch die komplette Sicherung zurueckgespielt und
bleibt zur manuellen Pruefung erhalten. Kommt er gesund hoch, gilt
die Migration als erfolgreich und das Backup wird geloescht.
update.sh delegiert diese gesamte /srv/tesm-spezifische Logik jetzt an
install.sh und ist selbst nur noch fuer das Ablösen AELTERER, TESM
vorausgehender Installationsstufen zustaendig (PoE Manager unter
/srv/poe_manager, das urspruengliche reine Bash-Setup) -- bleibt aber
als bequemer Ein-Skript-Bootstrapper (Download + Entpacken + Aufruf von
install.sh) bestehen, wie gewuenscht. install.sh selbst ist dadurch
jetzt auch OHNE update.sh direkt aus einem entpackten Release-Paket
lauffaehig und erkennt ein Update trotzdem korrekt.
VERSION: 1.0.3 (SCHEMA_VERSION unveraendert, 1 -- keine echte Schema-
Aenderung in diesem Release, In-Place-Update-Pfad bleibt der Normalfall).
Neue Datei SCHEMA_VERSION (neben VERSION) markiert den DB-Schema-Stand.
update.sh laedt/entpackt das Release-Paket jetzt VOR der Bestaetigungs-
abfrage und vergleicht die SCHEMA_VERSION der bestehenden Installation
mit der des neuen Pakets:
- Stimmen beide ueberein (und existiert bereits eine sqlite.db) --
In-Place-Update: /srv/tesm bleibt bestehen, install.sh rsynct nur den
neuen Code darueber (sqlite.db/fernet.key/secret.key waren dort schon
immer von rsync ausgeschlossen). Geraete/Switche/Zugangsdaten/Benutzer/
Einstellungen bleiben vollstaendig erhalten, kein manuelles Neuanlegen
oder Re-Import noetig.
- Unterscheiden sie sich (oder ist eine der beiden Versionen unbekannt,
z.B. eine Installation von vor dieser Aenderung) -- weiterhin der
bisherige sichere Weg: /srv/tesm wird beiseite verschoben (nicht
geloescht) und komplett frisch installiert.
/srv/poe_manager (voellig andere App/Schema) wird davon unabhaengig
immer beiseite verschoben, nie in-place uebernommen.
create_db.py bekommt einen Hinweis-Kommentar, SCHEMA_VERSION bei jeder
Schema-Aenderung mit hochzuzaehlen.
Ergänzt die bereits behandelte ursprüngliche Bash-only-Generation
(WiS/Aruba-PoE: rpi-check.service + ips.list) um die dazwischenliegende
Generation -- die Flask-App "PoE Manager" unter /srv/poe_manager mit
poe_web.service, der Vorgänger von TESM in diesem Repo vor der Umbenennung.
update.sh erkennt und sichert jetzt beide möglichen alten Installationsorte
(/srv/tesm, /srv/poe_manager) unabhängig voneinander nach
<Verzeichnis>-backup-<Zeitstempel> und stoppt/deaktiviert alle drei
möglichen Dienst-Generationen. README entsprechend erweitert.
- update.sh lädt jetzt ein fertig gepacktes Gitea-Release-Asset
(tesm-<tag>.tar.gz, Default "latest") direkt per curl herunter und
entpackt es -- kein "git clone" bzw. Git auf dem Zielsystem mehr nötig.
- Stoppt/deaktiviert zusätzlich zu den aktuellen TESM-Diensten auch das
ursprüngliche, noch ältere reine Bash-Setup (rpi-check.service,
rpi-check-restart.service/.timer -- der Vorgänger von TESM ganz ohne
Datenbank/Web-UI, statische ips.list statt generate_ips.py), falls auf
dem Zielsystem noch vorhanden.
- README entsprechend aktualisiert, inkl. kurzer Anleitung zum Paketieren
eines neuen Release (versionierter Tag + bewegliches "latest"-Tag).
Ergänzt install.sh (das ein bestehendes Checkout voraussetzt) um einen Weg,
eine bisher ad-hoc gepflegte Installation (z.B. per manuellem Datei-Upload
während der Entwicklung) durch eine frische, aus einem Git-Tag geklonte
Installation zu ersetzen:
- Stoppt/deaktiviert tesm.service, tesm-check.service,
tesm-check-restart.timer.
- Verschiebt das bestehende /srv/tesm NICHT gelöscht, sondern nach
/srv/tesm-backup-<Zeitstempel> -- bleibt als Rückfalloption und
Datenquelle für einen späteren Export/Import vollständig erhalten.
- Klont den angegebenen Release-Tag frisch und führt darin install.sh aus.
- Weist sowohl vor dem Start als auch am Ende deutlich darauf hin, dass das
Ergebnis eine FRISCHE Installation ohne die Daten der alten Instanz ist --
vorher exportieren (Einstellungen -> Im-/Export) oder danach alles neu
einrichten.
README um den entsprechenden Abschnitt ergänzt.
alientimandClaude Sonnet 5