tesm/README.md

TESM (TimEShepManager)

Webbasierte Verwaltung und Monitoring von PoE-Devices und Aruba-Switchen — funktionales Rebuild von Aruba-PoE mit komplett neuem, modernem Frontend und einem granularen Rechtesystem.

Das Projekt ist ausschließlich für Linux ausgelegt (Zielsystem: eine Linux-VM). Entwickelt wird unter WSL2 (Ubuntu) unter Windows — siehe Entwicklung unter WSL weiter unten.

Die App ermöglicht:

• Öffentliches Kachel-Dashboard ohne Login — zeigt nur aktive (nicht deaktivierte) Geräte, nur Online/Offline/Gesamt-Statistik; volle Verwaltung, Aktivieren/Deaktivieren und PoE-Neustart bleiben hinter dem Login. Eingeloggt sind zusätzlich deaktivierte Geräte sichtbar (eigene Kachel-Sektion). Alle Kacheln sind durchsuchbar und in drei Abschnitten sortiert: Offline, Online, Deaktiviert — jeweils alphabetisch. Die vier Stat-Kacheln oben (Online/ Offline/Deaktiviert/Gesamt) sind klickbare Filter — ein Klick blendet alle anderen Abschnitte aus, „Gesamt“ oder ein erneuter Klick auf die aktive Kachel hebt den Filter wieder auf. Jeder Abschnitt lässt sich unabhängig davon per Klick auf seinen Titel ein-/ausklappen (z.B. um eine lange Offline-Liste vorübergehend zu verstecken, ohne den Filter zu nutzen) — beide Zustände bleiben über die automatischen Live-Updates hinweg erhalten. Abmelden führt zurück auf dieses (auch ohne Login einsehbare) Dashboard statt auf die Login-Seite
• Der Hauptinhaltsbereich nutzt die volle verfügbare Breite (kein Bootstrap-typisches, festes max-width mehr) — nur Modals/Dialoge behalten bewusst ihre kompakte, feste Breite
• Verwaltung von Devices und Switches
• Zugangsdaten als eigene, wiederverwendbare Entität: SSH-Logins werden einmal angelegt und können mehreren Switchen zugeordnet werden; beim Anlegen eines Switches lassen sich bestehende Zugangsdaten auswählen oder direkt neue hinterlegen, ohne vorher zu „Zugangsdaten“ wechseln zu müssen
• Browser-SSH-Terminal beim Anlegen/Bearbeiten eines Switches, um den Host-Key zu bestätigen und die Zugangsdaten direkt zu prüfen, bevor der Switch gespeichert wird — funktioniert auf jedem Betriebssystem, die SSH-Verbindung wird dabei immer vom PoE-Server aus aufgebaut
• Manueller PoE-Neustart einzelner Geräte per Klick — ausschließlich über den zugeordneten Switch (poe.sh); der Button erscheint im Detail-Popup nur, wenn dem Gerät tatsächlich Switch und Port zugeordnet sind (sonst wäre kein PoE-Reset möglich), und ist immer der am weitesten links stehende Aktions-Button — „Schließen“ steht unabhängig davon immer ganz rechts. Bei deaktivierten Geräten bietet das Detail-Popup stattdessen direkt eine Aktivieren-Option
• SSH-basierte Wartung für Linux-Clients (eigene Seite „Wartung“, getrennt vom PoE-Neustart oben): Bulk-Update (apt update && apt upgrade) und Neustart per SSH direkt auf dem Gerät, unabhängig von jeder Switch-Zuordnung (siehe Wartung)
• Optionale LDAP/Active-Directory-Anmeldung mit dem Domänen-Passwort, zusätzlich zu lokalen Konten — automatische Konto-Anlage beim ersten Login (siehe LDAP / Active Directory)
• Einstellbares Prüfintervall (steuert den Hintergrund-Check-Dienst) — der Countdown „Nächste Prüfung“ wird aus dem tatsächlichen letzten Log-Eintrag berechnet, nicht bei jedem Seitenaufruf neu gestartet, und läuft global in der Topbar auf jeder Seite (nicht nur im Dashboard)
• Live-Log-Ansicht mit farblicher Hervorhebung (online/offline/Neustart); Dashboard und Live-Log aktualisieren sich automatisch im Hintergrund (per AJAX, ohne vollen Seiten-Reload). Ein „Jetzt prüfen"-Icon neben dem Timer (nur Admins) startet manuell einen sofortigen Prüf-Durchlauf — der Countdown setzt sich dabei auf den manuell ausgelösten Zeitpunkt zurück
• Einheitliches Seiten-Layout: die Topbar zeigt rechts ausschließlich den „Nächste Prüfung“-Timer; Anlegen-Buttons und eine kurze Beschreibung sitzen stattdessen direkt über der jeweiligen Tabelle. Die Listen (Geräte, Switche, Zugangsdaten, Benutzer, Gruppen) sind per Klick auf die Spaltenüberschrift sortierbar
• Rechtesystem mit Gruppen: Admins dürfen immer alles (als Gruppe „Admin“ überall mit aufgeführt); normalen Benutzern lassen sich über Gruppen einzelne Verwaltungsrechte gezielt zuweisen, inkl. reiner Ansichtsrechte (siehe Rechtesystem)
• Einklappbare Sidebar (Desktop: dauerhaft, über Neuladen hinweg gemerkt; mobil: temporäres Überlagern)
• Änderungslog: jede Anlage/Bearbeitung/Löschung sowie Aktivieren/ Deaktivieren von Geräten, Switchen, Zugangsdaten, Benutzern und Gruppen wird protokolliert (wer, wann, was) — einsehbar unter „Logs → Änderungslog“; Geräte und Switche merken sich zusätzlich direkt am Datensatz, wer sie zuletzt geändert hat. PoE-Neustarts werden bewusst nicht geloggt (siehe Änderungslog)
• Verschlüsselter Import/Export: Geräte, Switche und Zugangsdaten lassen sich unter „Einstellungen → Im-/Export" als ein mit selbstgewählter Passphrase verschlüsseltes Bundle exportieren und auf einer neuen Umgebung wieder importieren (siehe Import/Export)
• Eigenes Konto: das Zahnrad-Symbol neben dem eigenen Namen unten in der Sidebar führt zu „Mein Konto“ — Vor-/Nachname, eigenes Passwort und Profilbild pflegen (siehe Eigenes Konto)
• Anpassbare Navigation: Admins legen dort zusätzlich die Reihenfolge der Sidebar-Hauptpunkte per Auf-/Ab-Buttons fest; jeder Benutzer sieht davon ohnehin nur, wofür er berechtigt ist — auch pro Unterpunkt innerhalb einer Gruppe (siehe Navigation anpassen)

Was ist neu gegenüber dem Original?

• Komplett neues Frontend: eigenes Design-System (kein Bootstrap mehr — der Hauptinhaltsbereich nutzt bewusst die volle verfügbare Breite statt eines festen, Bootstrap-typischen max-width; nur Modals/Dialoge behalten ihre kompakte, feste Breite), Logo mittig in der Topbar (auf jeder Seite, skaliert auf die Balkenhöhe), Sidebar-Navigation (nur für eingeloggte Nutzer sichtbar), Dark/Light-Umschalter, Karten-Dashboard mit Live-Zählern, moderne Modals/Toasts statt Browser-confirm() und Bootstrap-Alerts. Der Akzent-Ton (--accent in style.css) ist exakt das Orange aus dem WiS-Logo (#ff7100, per Pixel-Sampling aus logo.png ermittelt), nicht nur eine ähnliche, frei gewählte Nuance.
• Dashboard jetzt teilweise öffentlich: / ist ohne Login erreichbar und zeigt eine reduzierte Lese-Ansicht (Hostname, IP, Status, letzte Prüfung) mit Login-Button; alle Verwaltungsseiten und der PoE-Neustart bleiben @login_required und zusätzlich rechtebasiert (s.u.).
• Browser-SSH-Terminal für Switche, implementiert mit paramiko (reines Python) statt eines lokalen pty + System-ssh-Client — läuft dadurch plattformunabhängig. Die SSH-Verbindung zum Switch wird immer serverseitig (vom PoE-Server) aufgebaut, nie vom Browser/Client aus.
• Granulares Rechtesystem mit Gruppen (neu, siehe unten) statt der ursprünglichen reinen Admin/User-Unterscheidung.
• Gleiche Kernlogik: Datenbankschema (erweitert um Gruppen/Rechte) und Login sind ansonsten unverändert. Der PoE-Restart-Mechanismus selbst (poe.sh per SSH/expect auf die Aruba-Switche) wurde dagegen überarbeitet — parallele statt sequentielle Geräte-Prüfung und echte Erfolgskontrolle statt blind angenommenem Erfolg, siehe Geräte-Prüfung.
• Aufgeräumtes Backend: konsistente, konfigurierbare Pfade (TESM_DB_PATH, POE_SCRIPT, TESM_LOG_DIR, …) statt hart codierter/inkonsistenter Pfade; Secret-Key und Fernet-Key werden beim ersten Start automatisch generiert statt im Repo zu liegen.

⚠️ Sicherheitshinweis zum Original-Repo: Im Original sind sqlite.db (Nutzer-Passwort-Hashes, verschlüsselte Switch-Passwörter) und fernet.key (der zugehörige Schlüssel) mit im Git-Repo eingecheckt — die .gitignore dort schließt sie über die !-Regeln versehentlich wieder ein. In diesem Rebuild sind beide Dateien in .gitignore ausgeschlossen und werden beim ersten Start frisch erzeugt. Empfehlung fürs Original-Repo: beide Dateien aus der Git-Historie entfernen und Fernet-Key sowie alle Switch-/User- Passwörter rotieren.

Rechtesystem (Gruppen & Berechtigungen)

Admins dürfen immer alles. Zusätzlich gibt es Gruppen mit einem vollständig granularen, an der Navbar gespiegelten Rechtebaum — jeder Bereich der App (nicht nur Devices/Switches) lässt sich einzeln freischalten. Ein Benutzer kann mehreren Gruppen angehören, die Rechte addieren sich (Vereinigung, nicht Schnittmenge).

Zweistufiger Rechtebaum

Der Baum hat genau zwei Ebenen, exakt gespiegelt an den drei Rechte-Bereichen der Gruppen-Seite (Geräte/Logs/Einstellungen) — das ist unabhängig von der Sidebar-Gliederung: „Benutzer“ und „Gruppen“ stehen in der Sidebar zwar als eigene, flache Top-Level-Punkte (siehe Navigation anpassen), gehören rechtlich aber weiterhin zum Bereich „Einstellungen“. Auf der Gruppen-Seite stehen die drei Bereiche als drei kompakte Spalten nebeneinander, mit einer kurzen Legende direkt darüber. Jede Spalte ist eine kleine Tabelle: die Kopfzeile enthält in EINER Zeile sowohl den Bereichsnamen mit seinem Kästchen (dem Kill-Switch, dicht nebeneinander statt an den Rand gestellt) als auch die Buchstaben-Spalten R(ead/Lesen), W(rite/Schreiben, Anlegen), E(dit/Ändern) — nur die Rechte, die dieser Bereich tatsächlich nutzt. Darunter je eine eingerückte Zeile pro Unterpunkt. „Ändern“ deckt Löschen überall mit ab — es gibt bewusst kein eigenes Löschen-Recht (stattdessen landet ein gelöschter Eintrag im Papierkorb). Zwei Bereiche haben eine zusätzliche, bereichsspezifische vierte Spalte: D nur bei Geräte → Clients bedeutet nicht Löschen, sondern PoE-Neustart über das Dashboard-Popup auslösen (automatische Neustarts bei Ausfall über poe.sh sind davon komplett unabhängig und laufen immer); X nur bei Einstellungen → Im-/Export bedeutet Export ausführen — bewusst getrennt von E (Import), da die Export-Datei Passwörter im Klartext enthält (siehe Import/Export). Checken einer W/E/D/X-Zelle einer Zeile hakt automatisch auch deren R an, und Abwählen von R wählt automatisch auch die übrigen Spalten derselben Zeile ab (R ist logisch Voraussetzung für alles andere). Für Zeilen ohne passendes Recht (z.B. „D“ bei Switche/ Zugangsdaten/Benutzer/Gruppen, oder „X“ bei allem außer Im-/Export) wird eine ausgegraute, nicht anklickbare Checkbox angezeigt statt die Zelle wegzulassen:

☑ Geräte    R  W  E  D     ☑ Logs      R  W  E     ☑ Einstellungen  R  W  E  X
  Clients   ☑ ☑ ☑ ☑          Live      ☑ ☑ ☑         Benutzer       ☑ ☑ ☑ ▢
  Switche   ☑ ☑ ☑ ▢          Änderungen☑ ☑ ☑         Gruppen        ☑ ☑ ☑ ▢
  Zugangsd. ☑ ☑ ☑ ▢          Kea-DHCP  ☑ ☑ ☑         Systemeinst.   ☑ ▢ ☑ ▢
  Wartung   ☑ ▢ ☑ ▢                                  LDAP           ☑ ▢ ☑ ▢
                                                      DHCP           ☑ ▢ ☑ ▢
                                                      Im-/Export     ☑ ▢ ☑ ☑

Das jeweilige „Bereich sichtbar“-Recht (devices_group.view / logs_group.view / settings_group.view, das Kästchen in der Kopfzeile einer Spalte) wirkt als Kill-Switch: ist es für eine Gruppe nicht gesetzt, greift kein einziges Recht darunter mehr — selbst wenn z.B. devices.view einzeln noch angehakt ist. So lässt sich ein ganzer Bereich mit einem Klick sperren, ohne jedes Unterrecht einzeln zurücknehmen zu müssen (User.has_permission() in app.py). Auf der Gruppen-Seite sind die Unterpunkt-Zeilen einer Spalte per JavaScript so lange gesperrt UND sichtbar ausgegraut (nicht nur das dezente native disabled-Styling), bis das Kopfzeilen-Kästchen angehakt ist.

Systemgruppen

Zwei Gruppen sind fest und weder umbenennbar noch in ihren Rechten änderbar (auch nicht durch Admins über die UI) — Mitgliedschaft bleibt bei beiden frei verwaltbar:

• Admin — virtuell (kein echter groups-Datensatz), intern über den is_admin-Schalter der Benutzer gesteuert, immer alle Rechte. Mindestens ein Admin muss bestehen bleiben (serverseitig erzwungen).
• Benutzer — die Standardgruppe (is_system-Flag), der jeder neu angelegte Nicht-Admin automatisch zugeordnet wird. Fester Rechtesatz: Geräte-Bereich + Clients/Switche lesen, Logs-Bereich + Live-Log lesen.

Alle anderen Gruppen sind vom jeweiligen Rechteinhaber (groups.edit, das auch Anlegen und Löschen von Gruppen umfasst) frei konfigurierbar.

Eskalationsschutz

Da jetzt auch Benutzer- und Gruppenverwaltung delegierbar sind (z.B. eine Gruppe mit nur users.edit, ohne Admin zu sein), gelten zusätzlich zu den granularen Rechten diese fest einprogrammierten Schranken, unabhängig davon, was eine Gruppe an Rechten hat:

• Ein Benutzer als Admin anlegen/dazu machen (group_id=admin bei Anlegen/Zuweisen) bleibt echten Admins vorbehalten.
• Ein bestehendes Admin-Konto bearbeiten, löschen oder ihm die Gruppe ändern bleibt echten Admins vorbehalten.
• Wer Admin ist, wird ausschließlich über „Admin-Mitglieder verwalten“ auf der Gruppen-Seite gesteuert — bleibt admin-exklusiv, unabhängig von groups.edit.

Sowohl das Anzeigen jeder Seite als auch jede einzelne Aktion (Buttons, Formulare) ist an das jeweilige Recht gekoppelt — im Frontend ausgeblendet und im Backend serverseitig durchgesetzt, unabhängig vom Frontend.

Datenmodell: groups (inkl. is_default- und is_system-Flag), group_permissions (Gruppe → Recht), user_groups (Benutzer → Gruppe). Bestehende Datenbanken werden beim App-Start automatisch migriert (_ensure_schema() in app.py): devices.toggle → devices.edit, switches.* → gespiegelte credentials.*, nachträgliches Setzen der neuen Bereichs-Rechte für bereits vergebene Unterrechte, sowie (spätere Revision) sämtliche *.delete-Rechte → *.edit (Löschen wurde nachträglich überall in Ändern gefaltet). Jede dieser Migrationen läuft nur einmalig über einen eigenen Guard in der settings-Tabelle, damit z.B. ein bewusst deaktiviertes Bereichs-Recht nicht bei jedem Neustart automatisch wieder gesetzt wird.

LDAP / Active Directory (Same Sign-On)

Optionale Anmeldung mit dem Domänen-Passwort, zusätzlich zu lokalen Konten — auf der eigenen Seite Einstellungen → LDAP (Recht settings_ldap.view zum Ansehen, Speichern erfordert Admin).

Wichtige Begriffsklärung, direkt aus einer Nutzerfrage entstanden: das ist "Same Sign-On", kein automatisches, promptloses Single Sign-On. Der Benutzer tippt sein AD-Passwort weiterhin auf der normalen Login-Seite ein — es wird nur bei jedem Login live gegen Active Directory geprüft statt gegen ein lokal gespeichertes Passwort. Eine Passwortänderung in AD greift dadurch sofort, ohne dass irgendetwas synchronisiert werden müsste. Echtes, promptloses Single Sign-On (der Browser meldet automatisch den bereits an Windows angemeldeten Benutzer an) bräuchte zusätzlich:

• Kerberos/SPNEGO ("Integrated Windows Authentication"): ein SPN + Keytab vom AD-Admin, eine per DNS auflösbare Hostname für die App, und die Browser-Konfiguration der Clients (i.d.R. bereits Standard für die Intranet-Zone auf domänenbeigetretenen PCs) — oder
• SAML/OIDC über Entra ID (Azure AD), falls Microsoft 365/Entra vorhanden ist — oft der pragmatischere Weg zu echtem SSO als klassisches Kerberos.

Beides sind eigenständige, deutlich aufwändigere Ausbaustufen, die sich später auf die hier beschriebene LDAP-Anmeldung aufsetzen ließen, aber AD-seitige Vorarbeit (Keytab bzw. App-Registrierung) durch einen Domain-Admin voraussetzen.

Funktionsweise (Search+Bind)

Beim Login wird zunächst lokal gesucht — per exaktem Benutzernamen, per E-Mail-Adresse, oder (case-insensitiv, nur für auth_source='ldap'-Konten) per bereits bekanntem AD-Benutzernamen. Ist das gefundene (oder noch nicht existierende) Konto gesperrt (is_locked, siehe unten) oder im Papierkorb, wird der Login abgelehnt, ohne AD überhaupt zu kontaktieren. Existiert kein lokales Konto und ist LDAP aktiviert, prüft die App die eingegebene Kennung (sAMAccountName oder UPN, z.B. sowohl jdoe als auch jdoe@ad.eertmoed.net funktionieren) und das Passwort per Search+Bind gegen den konfigurierten Server:

1. Verbindung mit dem konfigurierten Service-Konto aufbauen (ein normales, unprivilegiertes Domänenkonto reicht — es braucht nur Lesezugriff auf das Verzeichnis, was jedes Domänenkonto in AD standardmäßig hat).
2. Den Benutzer per konfigurierbarem Attribut suchen (Standard sAMAccountName für Active Directory; für generisches LDAP z.B. uid).
3. Eine zweite, separate Verbindung mit der gefundenen DN des Benutzers und dem eingegebenen Passwort aufbauen, um es zu verifizieren — robuster als ein direktes UPN-Bind (user@domain), da es nicht voraussetzt, dass sAMAccountName und der UPN-Präfix übereinstimmen.
4. Zusätzlich wird das userAccountControl-Bit ACCOUNTDISABLE geprüft (auch wenn ein echter AD-DC den Bind eines deaktivierten Kontos i.d.R. ohnehin schon selbst ablehnt) — zusätzliche Absicherung.

Die Base-DN wird standardmäßig automatisch per RootDSE (defaultNamingContext) ermittelt, kann aber manuell überschrieben werden (z.B. bei mehreren Domänen in einer Gesamtstruktur).

Bei erfolgreichem erstem Login wird automatisch ein lokales Konto angelegt (auth_source='ldap', kein Admin). Das gespeicherte Passwort dieses Kontos ist nur ein nie geprüfter Platzhalter-Hash — bei jedem weiteren Login wird live gegen AD verifiziert, nie gegen die lokale DB. Benutzernamen werden dabei case-insensitiv abgeglichen (nur für auth_source='ldap'- Konten, wirkt sich nie auf lokale Konten aus), damit z.B. "JDoe" und "jdoe" nicht zwei verschiedene lokale Konten erzeugen.

Gruppen-Zuordnung (AD-Gruppe → App-Gruppe). Auf der LDAP-Einstellungsseite lässt sich jeder AD-Gruppe (per DN) genau eine App-Gruppe zuordnen. Ist der Benutzer beim Login Mitglied mehrerer zugeordneter AD-Gruppen, erhält er additiv die Rechte aller passenden App-Gruppen (dieselbe Vereinigungslogik wie bei mehrfacher lokaler Gruppenmitgliedschaft). Passt keine der konfigurierten Zuordnungen, greift ersatzweise eine konfigurierbare Standardgruppe (sonst die System-Standardgruppe „Benutzer“) — es sei denn, eine der AD-Gruppen ist explizit der internen Admin-Zuordnung zugewiesen, dann wird das Konto automatisch zum Admin. Die Zuordnung wird bei jedem Login neu ausgewertet, nicht nur beim ersten — Änderungen an AD-Gruppenmitgliedschaften wirken sich also ohne manuellen Eingriff auf die nächste Anmeldung aus.

Konten sperren. Ein Admin kann jedes Konto (lokal wie AD) in „Benutzer“ per Schalter sperren (is_locked) — ein gesperrtes Konto kann sich nicht mehr anmelden, unabhängig davon, ob das AD-Passwort weiterhin gültig ist. Nützlich, um jemandem ohne Eingriff in AD selbst kurzfristig den Zugriff auf die App zu entziehen.

Vorab-Anlage aus Active Directory („Benutzer" → „Aus Active Directory hinzufügen"): eine Live-Suche (Substring, ab 2 Zeichen) im Verzeichnis, gefiltert um bereits lokal bekannte Benutzernamen. So kann ein Admin einer Person schon vor ihrem ersten Login eine Gruppe zuweisen, statt sich auf die Standardgruppe zu verlassen — das Konto landet dabei sofort mit auth_source='ldap' und demselben Platzhalter-Passwort-Mechanismus in der DB, ganz so, als hätte die Person sich bereits einmal angemeldet.

Lokale Konten bleiben vollständig erhalten — der lokale Login-Pfad ist unverändert, LDAP kommt nur als zusätzlicher Weg für Benutzernamen ohne lokales Konto dazu. Wichtig als Fallback (Break-Glass-Zugang, falls AD/LDAP mal nicht erreichbar ist) und für den allerersten Admin-Bootstrap (create_admin.py).

Für AD-Konten wird die Passwort-Änderung sowohl unter „Mein Konto" als auch im Admin-Bereich „Benutzer" ausgeblendet bzw. serverseitig ignoriert (ein kleines "AD"-Symbol markiert sie in der Benutzerliste) — das Passwort wird ausschließlich in Active Directory verwaltet.

Löschen eines AD-Kontos in „Benutzer" entfernt nur das lokale Schatten-Konto — AD-Konten landen dabei bewusst NIE im Papierkorb (anders als lokale Konten, siehe Papierkorb), da sie sich bei jedem gültigen Login ohnehin automatisch wieder anlegen würden und ein "gelöscht, aber weiter nutzbar"-Zwischenzustand hier keinen Sinn ergibt. Meldet sich die Person danach erneut mit gültigen AD-Zugangsdaten an, wird automatisch wieder ein (neues, rechteloses) Konto angelegt. Um jemandem den Zugriff wirklich zu entziehen, sperrt man das Konto entweder direkt in der App (siehe oben) oder deaktiviert es in AD selbst (blockiert dann auch den LDAP-Bind). Aus demselben Grund werden AD-Konten beim Export grundsätzlich nie mit exportiert — nur lokale Konten landen in der Export-Datei.

Sicherheitshinweis: ohne LDAPS/StartTLS wird das Passwort unverschlüsselt über das Netzwerk übertragen — nur für interne Tests in einem vertrauenswürdigen Netz geeignet. Vor Produktivbetrieb sollte LDAPS auf dem Domain Controller eingerichtet und in den Einstellungen aktiviert werden (das Server-Zertifikat wird dafür noch nicht validiert — reine Transportverschlüsselung).

Live gegen einen echten Active-Directory-Domain-Controller verifiziert: automatische Base-DN-Ermittlung, "Verbindung testen", erfolgreicher Erst-Login mit automatischer Konto-Anlage und korrekter Standardgruppen-Zuweisung, Ablehnung bei falschem Passwort, erneuter Login verwendet das bereits angelegte Konto (keine Duplikate), unveränderter lokaler Admin-Login, sowie dass das Bind-Passwort nie im Klartext im gerenderten HTML landet.

Zugangsdaten (wiederverwendbare SSH-Logins)

Zugangsdaten (Username + verschlüsseltes Passwort) sind eine eigene Entität (credentials-Tabelle) statt direkt am Switch/Gerät zu hängen — mehrere Switche/Geräte mit demselben Login teilen sich einen Eintrag. Beim Anlegen/ Bearbeiten eines Switches oder Geräts lässt sich per Dropdown ein bestehender Eintrag auswählen oder über „+ Neue Zugangsdaten anlegen“ direkt im selben Formular ein neuer anlegen, ohne vorher zur eigenen Zugangsdaten-Seite wechseln zu müssen. Löschen ist nur möglich, wenn weder ein Switch noch ein Gerät mehr auf den Eintrag verweist. Bestehende Datenbanken aus einer älteren Version (Username/Passwort direkt am Switch) werden beim ersten Start automatisch migriert.

Jede Zugangsdaten-Zeile hat außerdem eine explizite Kategorie (Switch / Linux-Client / Windows-Client / Router-Sonstiges), vom Admin beim Anlegen gesetzt — bewusst nicht automatisch per Ping/TTL-Heuristik erkannt (zu unzuverlässig, siehe Diskussion in der Commit-Historie). Aktuell wertet nur die Kategorie Linux-Client etwas aus: nur Geräte mit einer so kategorisierten Zugangsdaten-Zuordnung erscheinen unter Wartung (siehe unten). Windows/PowerShell-Wartung ist als eigener, separater Schritt vorgesehen (kein Testsystem dafür verfügbar) — die Kategorie existiert bereits, die Aktion dahinter noch nicht.

Sowohl die Switche- als auch die Clients-Tabelle zeigen dieselbe „Zugangsdaten“-Spalte (Name + Username, oder „— keine —“), damit auf einen Blick erkennbar ist, welches Gerät bereits per SSH verwaltet werden kann, ohne extra zur Zugangsdaten-Seite wechseln zu müssen.

Jeder Switch kann außerdem einen individuellen SSH-Port hinterlegen (Feld „SSH-Port“ beim Anlegen/Bearbeiten) — bleibt er leer, wird überall automatisch Port 22 angenommen (SWITCH_DEFAULT_SSH_PORT in app.py). Der Port wird konsistent an allen drei Stellen verwendet, an denen die App sich per SSH mit einem Switch verbindet: dem Web-Terminal (Verbindungstest), generate_ips.py (liefert ihn als eigenes Feld an poe.sh) und den expect-Aufrufen in poe.sh selbst (ssh -p <port> ...) für automatische wie manuelle PoE-Neustarts.

Wartung (SSH-Bulk-Update & -Neustart)

Eigene Seite unter Geräte → Wartung (eigenes Rechtepaar maintenance.view/maintenance.edit), komplett getrennt vom PoE-Neustart auf dem Dashboard:

• Dashboard-Neustart = immer PoE-Reset über den Switch (poe.sh), funktioniert unabhängig davon, ob das Gerät SSH-Zugangsdaten hat.
• Wartung = immer eine direkte SSH-Verbindung zum Gerät selbst, funktioniert unabhängig davon, ob/an welchem Switch es hängt.

Nur Geräte mit hinterlegten SSH-Zugangsdaten der Kategorie Linux-Client (siehe oben) erscheinen in der Liste. Zwei Aktionen:

• Update (Mehrfachauswahl per Checkbox, ein Klick startet alle ausgewählten parallel als eigene Hintergrund-Threads): führt serverseitig env DEBIAN_FRONTEND=noninteractive apt-get update && env DEBIAN_FRONTEND=noninteractive apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" upgrade per SSH aus — nicht interaktiv (kein Terminal, keine Rückfragemöglichkeit), die Dpkg::Options-Flags verhindern, dass ein Paket-Postinst-Skript auf eine Config-Datei-Rückfrage wartet, die nie kommt und sonst bis zum Timeout hängen bliebe.
• Neustart (pro Gerät): sudo reboot per SSH, danach automatisch weiterverfolgt bis das Gerät wieder online ist — ohne das bliebe der Status für immer auf „Neustart ausgelöst“ stehen, obwohl der eigentlich interessante Zeitpunkt (kommt das Gerät zurück?) noch gar nicht erfasst wäre. Ablauf: das SSH-Neustart-Kommando selbst gilt als erfolgreich ausgelöst, sobald die Verbindung abbricht (erwartet — die Maschine fährt herunter, bevor sie noch antworten kann; nur ein Verbindungs-/Auth-Fehler vor dem Kommando ist ein echter Fehler). Danach wartet eine kurze Schonfrist (15s, damit ein zu früher Ping nicht noch die absterbende alte Instanz erreicht) und pingt anschließend alle 5s (ping -c 1 -W 2 — exakt dieselbe Invocation wie das bestehende Online/Offline-Monitoring in poe.sh), bis eine Antwort kommt oder ein Timeout von 5 Minuten erreicht ist; erst dann wechselt der Status auf „wieder online“ (Erfolg) bzw. auf einen Fehler, falls das Gerät nicht rechtzeitig zurückkommt.

Live-Status pro Gerät (läuft/erfolgreich/fehlgeschlagen inkl. Ausgabe der letzten Aktion, per Klick ein-/ausblendbar) wird per Polling (/maintenance/status, alle 2s solange etwas läuft, sonst alle 8s) aktualisiert, ohne die Seite neu zu laden. Der Job-Status lebt bewusst nur im Prozessspeicher (wie beim SSH-Terminal auch keine Sitzung persistiert wird) — ein Neustart von tesm.service verwirft nur die Anzeige, nicht die auf dem Zielgerät bereits laufende Aktion selbst. Ein abgeschlossener erfolgreicher Job wird zusätzlich bei jedem (erneuten) Laden der Seite zurückgesetzt (Status wieder „Noch keine Aktion“) — ein Erfolg ist nur so lange relevant, wie man ihn noch live mitverfolgt, ein späterer Seitenaufruf soll keine ggf. stunden-/tagealte Erfolgsmeldung dauerhaft zeigen. Fehlgeschlagene Aktionen bleiben dagegen bewusst sichtbar, bis eine neue Aktion sie überschreibt, um nicht durch einen einfachen Reload versehentlich übersehen zu werden.

Sicherheitsmodell: dieselbe known_hosts-Datei wie beim Browser-SSH-Terminal (SSH_KNOWN_HOSTS_PATH) — ein Host muss vorher mindestens einmal interaktiv über „Verbindung testen“ bestätigt worden sein. Anders als das interaktive Terminal (dort kann bei einem unbekannten Host-Key wie bei einem echten ssh-Client live nachgefragt werden) läuft hier nichts vor einem Menschen ab — ein unbekannter oder nicht vorher bestätigter Host-Key wird deshalb per paramiko.RejectPolicy hart abgelehnt statt automatisch akzeptiert, da ohne Rückfragemöglichkeit ein automatisches Akzeptieren ein MITM-Risiko ohne jede Prüfung wäre.

Live gegen ein dediziertes Testsystem verifiziert (separat vom gemeinsam genutzten App-Host, um dort kein echtes apt upgrade auszulösen): ein echtes apt update && apt upgrade (inkl. Kernel-/systemd-/netplan-Paketen) lief nicht-interaktiv vollständig durch (status: success, komplette apt-Ausgabe im Job-Verlauf sichtbar); der SSH-Neustart samt Online-Watchdog wurde zweimal gegen dasselbe Testsystem verifiziert — jeweils per uptime -s bestätigt, dass der Boot-Zeitpunkt exakt zum Auslöse-Zeitpunkt des jeweiligen Jobs passte (kein False-Positive-Ping gegen die noch nicht heruntergefahrene alte Instanz), und dass der Job-Status korrekt von „wartet auf Online“ auf „wieder online“ umgeschaltet hat. Das Zurücksetzen auf „Noch keine Aktion“ bei einem erneuten Seitenaufruf wurde ebenfalls live bestätigt (Status vor einem GET /maintenance noch sichtbar, danach wieder leer).

Windows-Clients/PowerShell-Wartung ist bewusst noch nicht umgesetzt (kein Testsystem verfügbar) — die Kategorie „Windows-Client“ existiert in den Zugangsdaten bereits als Vorbereitung für einen späteren, separaten Ausbauschritt.

DHCP-Reservierungen & eigene Options (Systemeinstellungen → DHCP)

Erzeugt aus den vorhandenen Client-Stammdaten (MAC + IP + Name) automatisch feste DHCP-Reservierungen inkl. eigener/herstellerspezifischer Options, ohne die Daten ein zweites Mal pflegen zu müssen. Eigenes Rechtepaar settings_dhcp.view/settings_dhcp.edit, gespiegelt in der Navbar unter Einstellungen.

Backend: Kea DHCP (kea-dhcp4-server), nicht das ältere isc-dhcp-server — ISC hat isc-dhcp-server 2022 als EOL erklärt, Kea ist der aktiv weiterentwickelte Nachfolger und bildet „globaler Wert, pro Client überschreibbar“ nativ ab (siehe unten).

• Status-Erkennung (rein lesend): shutil.which("kea-dhcp4") + systemctl is-active/is-enabled. Zeigt Version, Lauf- und Autostart-Status.
• Installation & Dienststeuerung: eigene, jeweils einzeln bestätigte Buttons — „kea-dhcp4-server installieren“ (apt-get install -y), „Aktivieren & (neu) starten“ (systemctl enable + restart) und „Stoppen“ (systemctl stop + disable, damit ein bewusst gestoppter Dienst nach einem Host-Neustart nicht trotzdem automatisch wieder hochfährt — ein Host-Neustart übernimmt so genau den zuletzt bewusst gewählten Zustand, an oder aus). Bewusst nicht automatisch an „Konfiguration speichern“ oder „In Datei schreiben“ gekoppelt — ein unerwartet aktiver oder fehlkonfigurierter DHCP-Server kann ein ganzes Netzsegment stören, jede dieser Aktionen soll ein bewusster, separater Klick bleiben.
• Mehrere Subnetze gleichzeitig: ein Host kann mehrere IPs/Interfaces mit jeweils eigenem Netz haben, für die alle DHCP angeboten werden soll (dhcp_subnets-Tabelle statt einer einzelnen globalen Range) — jedes Subnetz hat eigene Interface/Range sowie optional eigenes Gateway/DNS, generiert wird ein eigener subnet4-Block je Subnetz in der Kea-Config. Domain, Lease-Zeiten und Ausgabepfad bleiben global (Kea-weit gültig).
• Netzwerk-Kopplung: Subnet und Netzmaske werden nie manuell eingegeben, sondern bei jeder Anzeige/Generierung live aus der System-Netzwerkkonfiguration des jeweiligen Interfaces gelesen (_detect_interface_network()/_detect_interface_networks(): ip -4 addr show dev <iface> + ip route show default) — berücksichtigt dabei ALLE IPv4-Adressen eines Interfaces, nicht nur die erste (ein Interface kann mehrere IPs/Subnetze gleichzeitig tragen, z.B. Alias-IPs). Die generierte Kea-Konfiguration ist dadurch immer an das Netz gekoppelt, in dem der Host tatsächlich hängt, auch wenn sich dessen IP/Subnet mal ändert.
• Range ist Pflicht und muss zu einem echten Netz passen: kein vorausgefüllter Default für Range/DNS (nur Platzhaltertext) — ein Subnetz ohne zu einem tatsächlich vorhandenen Netz passende Range wird beim Anlegen/Bearbeiten abgelehnt (_dhcp_matching_network()), da Kea ohne eine echte, physisch vorhandene IP im gewünschten Bereich keine gültige Subnet-CIDR zugeordnet werden kann. Dieselbe Prüfung läuft zusätzlich bei „In Datei schreiben“ (Subnetze, die inzwischen zu keinem echten Netz mehr passen — z.B. nach einem Netzwechsel des Hosts — werden übersprungen und in der Erfolgsmeldung benannt, statt die ganze Aktion abzubrechen) und bei „Aktivieren & (neu) starten“ (verweigert den Start, falls kein einziges gültiges Subnetz mehr existiert). Live auf einer echten Fehlkonfiguration reproduziert und verifiziert.
• Subnetze einzeln deaktivierbar: ein Subnetz lässt sich ohne Löschen pausieren (enabled-Flag) — wird dann bei „In Datei schreiben“ und „Aktivieren & (neu) starten“ komplett ignoriert (kein Fehler, bewusst kein "ungültig", da das Fehlen des Netzes hier Absicht ist), statt es jedes Mal neu anlegen zu müssen.
• DHCP-Options (dhcp_option_defs/dhcp_option_values): eine kuratierte Auswahl an 56 Standard-Optionen (analog den „Vordefinierten Optionen“ eines Windows-DHCP-Servers — u.a. NTP-/WINS-/TFTP-/SMTP-Server, Boot-Datei, Domain-Search, IP-Forwarding) ist automatisch vorbefüllt und nicht löschbar (Backend lehnt es ab, UI zeigt statt eines Löschen-Buttons ein Schloss-Symbol) — Router/DNS-Server/Domain-Name/Lease-Zeiten sind bewusst ausgenommen, da dafür bereits eigene, dedizierte Felder existieren (Subnetze bzw. globale Einstellungen oben); ebenso client-/ protokollinterne Optionen (message-type, parameter-request-list, requested-address, ...), die serverseitig nicht sinnvoll setzbar sind. „host-name“ (12) ist ebenfalls bewusst nicht enthalten (war es zwischenzeitlich, wurde aber wieder entfernt): Kea beantwortet die Host-Name-Anfrage eines Clients bei einer Reservierung bereits automatisch über deren eigenes hostname-Feld (aus dem Namen der Reservierung abgeleitet) — ein zusätzlicher option-data-Override für dieselbe Option wäre laut Kea-Dokumentation eine Dopplung und Quelle für Widersprüche, live an einer echten Reservierung mit beiden gleichzeitig gesetzten Werten nachvollzogen. Alle verbleibenden Namen sind live gegen eine echte Kea-2.4.1-Instanz verifiziert (kea-dhcp4 -t, jede Option einzeln getestet). Standard-Optionen bekommen bewusst kein eigenes option-def in der generierten Konfiguration — Kea kennt sie bereits nativ, eine Neudefinition würde die eingebaute duplizieren; nur zusätzlich angelegte, wirklich eigene/herstellerspezifische Options (z.B. eine Terminal-Boot-URL) bekommen eines und bleiben frei löschbar. In der Tabelle sind grundsätzlich nur tatsächlich genutzte Options sichtbar (eigene immer, Standard-Optionen nur mit gesetztem globalen Wert) — weitere Standard-Optionen kommen über ein Dropdown „+ Standard-Option hinzufügen“ dazu, statt alle 56 dauerhaft als leere Zeilen anzuzeigen. Jede Option hat einen globalen Wert sowie optional einen Wert pro Client — ein Client-Override überschreibt den globalen Wert ausschließlich für dieses eine Gerät (technisch: globale Werte landen im Top-Level option-data, Overrides im option-data der jeweiligen Kea-Reservierung, was Kea automatisch pro Client Vorrang geben lässt). Im Reservierungs-Options-Dialog gilt dasselbe Prinzip: nur Options mit gesetztem Override sind sichtbar, weitere kommen über ein Dropdown dazu. Das ausgewählte Feld wird dabei direkt unter das Dropdown verschoben und fokussiert, statt an seiner ursprünglichen Stelle irgendwo in der u.U. langen Liste (bis zu 56 mögliche Options) zu erscheinen — sonst lag es oft außerhalb des sichtbaren Modal-Ausschnitts und wirkte, als wäre nichts passiert (live genau so reproduziert und behoben).
• Reservierungen aus zwei Quellen: automatisch für jedes aktive Gerät mit gültiger MAC + IP (Client-Stammdaten dieser App) sowie zusätzlich manuell anlegbar („Reservierung hinzufügen“, MAC/IP/Name) — für Geräte, die nicht als Client gepflegt werden (z.B. ein externes Gerät), sodass ihnen bewusst und mit voller Kontrolle eine feste IP gegeben werden kann, statt sie unüberwacht automatisch anzubinden. Automatische Reservierungen können in dieser Tabelle nicht gelöscht werden (Schloss-Symbol statt Button — sie entstehen/verschwinden mit den Client-Stammdaten), manuelle schon. Bei einer MAC in beiden Quellen gewinnt immer die automatische. Jede Reservierung wird ins passende Subnetz einsortiert (die IP entscheidet, zu welchem der ggf. mehreren konfigurierten Subnetze sie gehört); der Hostname wird aus dem Namen abgeleitet (nur a-z0-9-, Kollisionen innerhalb desselben Subnetzes bekommen automatisch ein -2/-3-Suffix). Einträge ohne MAC/IP oder mit einer IP außerhalb aller konfigurierten Subnetze werden mit Hinweis übersprungen — Kea lehnt eine Reservierung außerhalb ihres Subnets als Konfigurationsfehler ab (mit einer echten Kea-Instanz verifiziert, inkl. einer Mischung aus automatischer und manueller Reservierung im selben Subnetz).
• Aktive Leases: eigene Karte, liest die tatsächlich vergebenen Adressen direkt aus Keas Lease-Datenbank (kea-leases4.csv, memfile-Backend — kein Control-Agent nötig, reiner Lesezugriff auf die Datei). Zeigt damit auch Clients ohne eigene Reservierung, die sich einfach eine freie IP aus dem Pool genommen haben — deutlich als „Ohne Reservierung“ markiert, statt nur die (unvollständige) Reservierungsliste zu zeigen. Die Ablaufzeit wird explizit als UTC ausgewiesen (Kea arbeitet intern in UTC-Epoch) und zusätzlich als live tickender Countdown angezeigt — eine reine Absolutzeit auf einer nicht selbst aktualisierenden Seite wirkte bei den kurzen Standard-Lease-Zeiten (600s) schnell „schon abgelaufen“, sobald etwas Zeit vergangen war, bis man tatsächlich hinschaut (live auf der Test-VM als genau dieses Missverständnis reproduziert).
• Schreiben: „Speichern“ bei den Reservierungen (nur mit settings_dhcp.edit) schreibt die vollständige, generierte Kea-JSON- Konfiguration an den konfigurierten Ausgabepfad. Wirksam wird sie erst nach einem Dienst-Neustart über den separaten Button.
• Ampel im Topbar: neben dem Prüfintervall-Timer zeigt ein grüner/roter Punkt, ob der Kea-Dienst läuft — nur sichtbar mit settings_dhcp.view.
• Reservierungen mit aktiven eigenen Options zeigen in der Tabelle, welche Option greift (global oder Client-Override).

Live gegen eine echte, frisch installierte Kea-Instanz verifiziert: Installation, generierte Konfiguration besteht kea-dhcp4 -t, Dienststart übernimmt sie fehlerfrei (DHCP4_CONFIG_COMPLETE), globaler Options-Wert sowie Client-spezifischer Override erscheinen korrekt getrennt in der Konfiguration.

Die Mehrfach-Subnetz-Unterstützung selbst (Anlegen/Bearbeiten/Löschen samt Validierung, mehrere generierte subnet4-Blöcke mit korrekten Pools/ Interfaces, Migration einer bestehenden Einzel-Range) ist live auf einem echten Host verifiziert. Zwei tatsächlich unabhängige Netze (z.B. über zwei physische NICs) standen beim Test nicht zur Verfügung — verifiziert wurde daher zusätzlich zwei Ranges innerhalb desselben real vorhandenen Netzes (identischer subnet-CIDR, unterschiedliche Pools); ob Kea zwei subnet4-Blöcke mit identischem subnet-Wert akzeptiert oder als Fehler ablehnt, wurde nicht gegen eine echte Kea-Instanz geprüft — bei tatsächlich unterschiedlichen Netzen (der eigentliche Anwendungsfall) besteht dieses Risiko nicht. Die Leases-Anzeige wurde vollständig End-to-End im echten Betrieb bestätigt: ein tatsächlicher, unreservierter Client im Testnetz („shellyhtg3-...“) hat sich selbstständig eine IP aus dem Pool geholt und wurde korrekt mit der „Ohne Reservierung“-Markierung angezeigt.

Geräte-Prüfung (poe.sh)

Der Hintergrund-Check-Dienst (tesm-check.service, ruft poe.sh ohne Argument auf) prüft in einer Endlosschleife alle Geräte per Ping und startet bei Ausfall automatisch den PoE-Port neu, über den ein Gerät am zugeordneten Switch hängt (expect, siehe unten). Zwei Korrekturen nach einem echten Import mit deutlich mehr Geräten (46 statt einer Handvoll Testgeräte):

• Parallele statt sequentielle Prüfung: vorher wurde jedes Gerät strikt nacheinander in einer einzigen Schleife geprüft — ein einzelnes bereits ausgefallenes Gerät mit ebenfalls nicht erreichbarem Switch (jeder expect-Verbindungsschritt bis zu 5s Timeout) hat dadurch die Prüfung aller nachfolgenden Geräte in der Liste verzögert; bei vielen gleichzeitig ausgefallenen Geräten konnte ein Prüfdurchlauf so erheblich länger dauern als das eigentlich konfigurierte Intervall. Jetzt läuft jede Geräte-Prüfung (Ping + ggf. PoE-Neustart) als eigener Hintergrund-Job (& + wait am Ende des Durchlaufs, über Process Substitution statt einer Pipe, damit wait die Jobs auch tatsächlich erfasst) — mehrere Geräte, auch an unterschiedlichen Switchen, werden dadurch gleichzeitig geprüft statt einzeln nacheinander.
• Echte Erfolgskontrolle statt blind angenommenem Erfolg: disable_poe()/ enable_poe() haben vorher unabhängig vom tatsächlichen Ergebnis der SSH/expect-Sitzung immer wie ein Erfolg gewirkt — lief die Verbindung zum Switch in einen Timeout (Switch nicht erreichbar, falsche Zugangsdaten, falscher Port), endete das expect-Skript trotzdem mit Exit-Code 0, und poe.sh loggte fälschlich „PoE deaktiviert“/„PoE aktiviert", obwohl am Switch nichts passiert war. Jeder kritische expect-Schritt (Verbindungsaufbau, configure terminal-Prompt, Interface-Prompt, Bestätigung des power-over-ethernet-Kommandos) hat jetzt einen eigenen timeout-Zweig mit explizitem exit 1; poe.sh wertet diesen Rückgabewert aus und loggt bei einem nicht erreichbaren oder ablehnenden Switch stattdessen klar „Switch ... nicht erreichbar oder Kommando abgelehnt — PoE-Deaktivierung/-Reaktivierung fehlgeschlagen“, ohne einen Neustart vorzugaukeln, der nie stattgefunden hat. Gilt für die automatische Prüfschleife, den manuellen Neustart (poe.sh restart <mac>) und damit auch für den Dashboard-Neustart-Button.

Live nach einem echten Import (46 Geräte, 8 Switche aus dem Altsystem) verifiziert: alle 46 Geräte wurden innerhalb von ~2 Sekunden geprüft (statt sequentiell), und alle 43 als offline erkannten Geräte mit Switch-Zuordnung zeigten korrekt die neue Fehlermeldung, da die realen Switch-IPs (192.168.200.x) vom Test-Host aus nicht erreichbar sind — vorher hätte das fälschlich als 43× „PoE deaktiviert“/„PoE aktiviert“ geloggt.

Netzwerkeinstellungen des Hosts (Systemeinstellungen)

Eigene, klar getrennte Funktion von obigem DHCP-Server: hier geht es um die Netzwerkkonfiguration des Hosts, auf dem TESM selbst läuft (IP-Adresse, DNS-Server, DHCP-Client vs. statisch, Hostname) — nicht um Adressen, die er an andere Geräte vergibt. Der Hostname wird separat und risikolos über hostnamectl set-hostname gesetzt (kein Revert-Timer nötig, da eine Änderung nicht die Erreichbarkeit kappt).

• Backend-Erkennung: prüft, ob NetworkManager oder dhcpcd aktiv ist (systemctl is-active); ist keins von beiden aktiv, aber systemd-networkd aktiv und netplan installiert, wird netplan angenommen — der Standard auf einem frisch installierten Ubuntu (Server wie Cloud-Image). Ist keins der drei erkennbar, bleibt die Seite bewusst rein lesend (Status wird trotzdem angezeigt) — ohne zuverlässige Erkennung des Backends keine Änderung, um nicht ins Blaue zu raten.
• Anzeige: aktuelles Interface, IP/Prefix, Gateway, DNS-Server sowie Modus (DHCP/Statisch) — Modus wird backend-spezifisch ermittelt (nmcli ipv4.method, ein static ip_address=-Eintrag im betreffenden interface-Block von /etc/dhcpcd.conf, bzw. bei netplan am dynamic-Flag des Kernels auf der aktuellen Adresse — zuverlässiger als die u.U. mehreren überlagernden YAML-Dateien unter /etc/netplan/ selbst zu parsen). DNS-Server-Anzeige: nicht aus /etc/resolv.conf gelesen — unter systemd-resolved (Standard auf aktuellem Ubuntu) steht dort immer nur der lokale Stub-Resolver 127.0.0.53, nie die echten Upstream-Server (live genau so reproduziert). Stattdessen resolvectl dns <interface>, dessen mehrzeilige Ausgabe bei vielen Servern korrekt geparst wird (eine Fortsetzungszeile ohne Link N (iface):-Label trägt selbst Doppelpunkte — eine IPv6-Adresse — ein naives Aufteilen an jedem Doppelpunkt hätte sie sonst am Anfang abgeschnitten, live genau so reproduziert und gefixt). Zusätzlich auf IPv4 gefiltert, da diese Seite ausschließlich die IPv4-Konfiguration des Hosts verwaltet — von resolvectl ungefragt mitgelieferte, per IPv6-Router-Advertisement gelernte DNS-Server gehören nicht dazu und wären hier nur irreführend.
• Änderung: Interface, Modus (DHCP/Statisch), bei Statisch zusätzlich IP/Prefix/Gateway, sowie unabhängig davon eigene DNS-Server (funktioniert in beiden Modi — z.B. IP per DHCP, aber feste DNS-Server). Bei netplan landet die Änderung in einer eigenen, niedrig priorisierten Override-Datei (/etc/netplan/90-tesm.yaml) statt in der vom Distributor bzw. cloud-init mitgelieferten — netplan wendet Dateien alphabetisch an, spätere Werte gewinnen pro Schlüssel, damit bleibt die Original-Datei unangetastet.
• Sicherheitsnetz (wie netplan try): vor jeder Änderung wird die vorherige Konfiguration gesichert. Nach dem Anwenden läuft ein Hintergrund-Timer (Standard 45s) — wird die Änderung nicht explizit bestätigt (nur möglich, wenn die Seite über die neue Konfiguration noch erreichbar ist), rollt die App automatisch auf die gesicherte Konfiguration zurück. Verhindert, dass ein Tippfehler bei IP/Gateway den Host von der Web-UI/SSH abschneidet.
• DHCP-Server wird vorsorglich gestoppt UND deaktiviert: eine vorher passende Range (siehe DHCP-Konfiguration oben) kann nach einer IP-/Subnetzänderung plötzlich zum falschen Netz gehören. Läuft Kea beim Anwenden oder beim Auto-Rollback, wird der Dienst deshalb gestoppt und deaktiviert (nicht automatisch neu gestartet — die Range muss der Admin aktiv auf der DHCP-Seite prüfen und den Dienst dort bewusst wieder starten). Das zusätzliche Deaktivieren verhindert, dass ein Host-Neustart vor dieser Prüfung den Dienst trotzdem automatisch mit der ggf. falschen Range wieder hochfährt, statt dass die App mit einer möglicherweise falschen Konfiguration weiterläuft oder blind rät.
• Live gegen eine echte Ubuntu-24.04-VM verifiziert (Standard-Installation, Netz per DHCP über netplan/systemd-networkd bezogen) — sowohl die Erkennung/Statusanzeige als auch der komplette Anwenden-Pfad inkl. der eigenen Override-Datei. NetworkManager und dhcpcd sind zusätzlich per gemockten subprocess.run/Dateizugriffen verifiziert (inkl. eines echten dhcpcd.conf-Rewrites und eines vollständigen Anwenden-dann-Auto- Rollback-Durchlaufs), da in der WSL-Entwicklungsumgebung keins von beiden verfügbar ist.

Änderungslog

Jede Anlage, Bearbeitung, Löschung sowie jedes Aktivieren/Deaktivieren von Geräten, Switchen, Zugangsdaten, Benutzern und Gruppen wird in der Tabelle audit_log protokolliert (Zeitpunkt, Benutzer, Aktion, Ziel, Details) — einsehbar unter Logs → Änderungen (Recht logs_activity.view). Zusätzlich merken sich Geräte und Switche direkt am Datensatz (last_modified_by, last_modified_at), wer sie zuletzt geändert hat, damit man das nicht erst im Log nachschlagen muss. Jeder Eintrag wird zusätzlich in eine eigene Datei gespiegelt (siehe Logs & Log-Rotation) — die audit_log-Tabelle bleibt dabei die Quelle für diese durchsuchbare/ sortierbare Seite.

PoE-Neustarts werden bewusst nicht im Änderungslog erfasst — die stehen bereits im Live-Log von poe.sh. Eine Ausnahme ist die Änderung des Prüfintervalls selbst (eine Einstellungsänderung, kein Neustart), die wird mitprotokolliert.

Logs & Log-Rotation

Vier getrennte, eigene Log-Dateien statt allem in /var/log vermischt oder nur im journalctl-Output — jede mit derselben, unter Systemeinstellungen → Logs einstellbaren Rotation (Intervall täglich/wöchentlich/monatlich, Standard wöchentlich; Aufbewahrung als Anzahl Rotationen, Standard 4 ≈ 1 Monat Historie):

Log	Datei	Einsehbar unter
Live (Ping-Check/PoE-Neustart)	/var/log/tesm/live.log	Logs → Live
Änderungen (Audit-Trail)	/var/log/tesm/changes.log	Logs → Änderungen (aus der DB)
App (Fehler/Warnungen der Flask-App)	/var/log/tesm/app.log	nur Datei, keine eigene Seite
Kea-DHCP	/var/log/kea/kea-dhcp4.log	Logs → Kea-DHCP (Recht logs_kea.view)

• Live-Log ist jetzt eine einzige, durchgehend fortgeschriebene Datei statt vorher bei jedem (auch täglich per tesm-check-restart.timer automatisch ausgelösten) Dienst-Neustart ein neues rpi-<timestamp>.log — poe.sh räumt nicht mehr selbst nach 30 Tagen auf, das übernimmt jetzt zentral logrotate. Bestehende alte rpi-*.log-Dateien werden beim ersten Start dieser Version einmalig aufgeräumt (Migration).
• Kea-DHCP-Log liegt bewusst NICHT unter /var/log/tesm/: Keas AppArmor-Profil (/etc/apparmor.d/usr.sbin.kea-dhcp4) erlaubt Schreibzugriff exklusiv auf den Dateinamen /var/log/kea/kea-dhcp4.log (kein Verzeichnis-Wildcard) — ein anderer Pfad wird mit DENIED ... mknod ... .lock abgelehnt (live so reproduziert). Statt das AppArmor-Profil eines Systemdienstes aufzuweichen, nutzt die App Keas eigenen, bereits erlaubten Pfad; die logrotate-Konfiguration deckt trotzdem beide Verzeichnisse mit derselben Regel ab.
• copytruncate statt Signal-/Neustart-basierter Rotation: keiner der drei schreibenden Prozesse (poe.sh, Flask, kea-dhcp4-server) implementiert ein Log-Reopen-Signal (SIGHUP o.ä.) — copytruncate funktioniert ohne jede Kooperation des schreibenden Prozesses und läuft als root, ist also auch von Keas AppArmor-Profil nicht betroffen.
• App-Log (app.log) fängt Fehler/Warnungen der Flask-App ab (vorher nur im journalctl-Output von tesm.service sichtbar, ohne von der App selbst kontrollierbare Aufbewahrung) — bewusst nur WARNING und höher, kein Access-/Request-Rauschen.
• Zeitzone (Systemeinstellungen, zusammen mit dem Hostnamen in der Kachel „Host“): setzt die System-Zeitzone per timedatectl set-timezone, damit alle vier Logs sowie das Änderungslog die tatsächliche lokale Zeit statt UTC zeigen. Wirkt über time.tzset() sofort für die bereits laufende tesm.service-Instanz (kein Neustart nötig) — poe.sh/date liest die Zeitzone ohnehin bei jedem Prüf-Durchlauf frisch, da es ein neuer Prozess pro Durchlauf ist.
• Systemeinstellungen neu sortiert: Host (Hostname + Zeitzone in einer Kachel) und Netzwerkeinstellungen stehen als thematisch zusammengehörige Host-Konfiguration nebeneinander, gefolgt von Logs und Prüfintervall.

Live verifiziert: alle vier Log-Dateien werden geschrieben, die logrotate-Konfiguration korrekt generiert und bei einer Änderung der Einstellung neu geschrieben, ein Zeitzonenwechsel (UTC → Europe/Berlin) wirkte sofort — die Log-Zeile, die den Wechsel selbst protokolliert, trug bereits den neuen Zeitstempel.

Import/Export

Unter Einstellungen → Im-/Export lassen sich acht Kategorien einzeln auswählen und als ein JSON-Bundle exportieren: Geräte, Switche, Zugangsdaten (inkl. entschlüsselter Passwörter), Benutzer, Gruppen, LDAP-Einstellungen (inkl. Gruppenzuordnungen), DHCP-Konfiguration und Logs. AD/LDAP- Benutzerkonten werden dabei nie mitexportiert — nur lokale Konten landen in der Datei, siehe LDAP-Kapitel. Das Bundle wird mit einem aus einer selbstgewählten Passphrase abgeleiteten Schlüssel verschlüsselt (PBKDF2-HMAC-SHA256 + Fernet) — unabhängig vom fernet.key dieser Installation, damit die Datei auf einer komplett neuen Umgebung (mit eigenem, neu generiertem fernet.key) wieder eingelesen werden kann. Gedacht für einen Umzug auf einen neuen Server oder ein selektives Backup einzelner Kategorien.

Zweistufiger Import. Datei hochladen + Passphrase eingeben lädt das Bundle serverseitig nur kurzzeitig in den Speicher (Token-basiert, läuft nach einer Weile automatisch ab) und zeigt eine Vorschau: nur die Kategorien, die tatsächlich in der Datei enthalten sind, jeweils mit Anzahl der Einträge. Erst danach wählt man aus, welche der vorhandenen Kategorien tatsächlich übernommen werden sollen — ein Import kann also z.B. nur die Geräte aus einer Datei ziehen, ohne versehentlich auch Benutzer oder LDAP-Einstellungen zu überschreiben. Abgeglichen wird pro Kategorie nach dem jeweiligen natürlichen Schlüssel (Zugangsdaten nach Name, Switche nach Hostname, Geräte nach MAC-Adresse, Benutzer nach Benutzername, Gruppen nach Name) — bestehende Einträge werden aktualisiert, neue angelegt. Switche referenzieren ihre Zugangsdaten dabei über den Namen (nicht die interne ID), damit der Import auch bei abweichender ID-Vergabe auf dem Zielsystem korrekt verknüpft.

Berechtigungen. Die Im-/Export-Seite hat drei eigene Rechte: R (settings_importexport.view) zum Ansehen der Seite (Standardbedeutung wie überall), E (settings_importexport.edit) zum Ausführen eines Imports, und X (settings_importexport.export) — eine eigene, dedizierte Berechtigung nur zum Ausführen eines Exports, da die Export-Datei Passwörter im Klartext enthält (entschlüsselt vor der eigenen Passphrasen- Verschlüsselung) und deshalb bewusst nicht automatisch an jeden mit Änderungsrecht gekoppelt ist. Admins haben ohnehin immer alle drei; für andere Gruppen lassen sich Import und Export unabhängig voneinander vergeben. Zusätzlich sind die drei Kategorien Benutzer, Gruppen und LDAP unabhängig von R/E/X grundsätzlich Admins vorbehalten (sowohl beim Export als auch beim Import) — ein Nicht-Admin mit E/X sieht und nutzt dort nur die übrigen fünf Kategorien.

Papierkorb

Löschen ist für Geräte, Switche, Zugangsdaten, (lokale) Benutzer und (benutzerdefinierte) Gruppen ein Soft-Delete statt eines echten DELETE — der Eintrag bekommt nur einen Zeitstempel (deleted_at) und verschwindet dadurch aus allen normalen Listen, Dropdowns und Berechtigungsprüfungen, bleibt aber vollständig erhalten und wiederherstellbar. Erreichbar über einen eigenen Navigationspunkt „Papierkorb" direkt unterhalb von „Wartung" (sichtbar, sobald man für mindestens eine der fünf Kategorien Leserecht hat) — dort ist jede Kategorie als eigene, permissions- gegated Kachel mit „Wiederherstellen"- und „Endgültig löschen"-Aktion aufgeführt.

Ausnahmen: System-/Standardgruppen (aktuell nur „Benutzer") lassen sich grundsätzlich nicht löschen, landen also auch nie im Papierkorb — unverändert gegenüber vorher. AD/LDAP-Benutzerkonten landen ebenfalls nie im Papierkorb und werden bei „Löschen" weiterhin sofort endgültig entfernt, da sie sich bei jedem gültigen Login automatisch neu anlegen (siehe LDAP-Kapitel) — ein Papierkorb-Zwischenzustand wäre hier bedeutungslos.

Reservierter Schlüssel, solange etwas im Papierkorb liegt: MAC-Adresse, Hostname, Zugangsdaten-Name, Benutzername bzw. Gruppenname eines gelöschten Eintrags bleiben bewusst reserviert und blockieren die Neuanlage eines gleichnamigen Eintrags, bis der alte entweder wiederhergestellt oder endgültig gelöscht (purged) wird — der Fehlertext beim Anlegen weist entsprechend auf den Papierkorb hin. Kind-Datensätze (Gruppenmitgliedschaften, Gruppenrechte, DHCP-Werte pro Gerät) werden beim Soft-Delete bewusst nicht mit entfernt, damit eine Wiederherstellung exakt den vorherigen Zustand zurückbringt — aufgeräumt werden sie erst beim endgültigen Löschen (Purge).

Aufbewahrungsfrist: konfigurierbar unter Systemeinstellungen (trash_retention_days, Standard 30 Tage) — abgelaufene Einträge werden beim Aufruf der Papierkorb-Seite automatisch endgültig gelöscht (kein eigener Scheduler nötig), zusätzlich gibt es dort einen Button, um abgelaufene Einträge sofort manuell zu bereinigen.

Eigenes Konto & Profilbild

Das Zahnrad-Symbol neben dem eigenen Namen unten in der Sidebar führt zu „Mein Konto“ (/account): Vor-/Nachname ändern, ein Profilbild hochladen (PNG/JPG/GIF/WEBP) und das eigene Passwort ändern (erfordert Eingabe des aktuellen Passworts). Das ist bewusst getrennt vom Admin-Bereich „Benutzer“, der andere Konten verwaltet. Ist ein Profilbild hinterlegt, erscheint es statt der Initialen sowohl in der Sidebar als auch im Änderungslog neben dem Benutzernamen. Die Navbar-Reihenfolge (für Admins) liegt dagegen unter Systemeinstellungen, siehe Navigation anpassen.

Warnung bei ungespeicherten Änderungen

Generischer, app-weiter Mechanismus (kein Opt-in pro Seite nötig): erkennt automatisch, ob ein Formular mit echten Eingabefeldern (nicht nur versteckten Aktions-Feldern wie bei Löschen-/Toggle-Buttons) seit dem Laden der Seite verändert wurde, und fragt beim Verlassen (Klick auf einen Link, z.B. in der Navigation) per eigenem Ja/Nein-Dialog, ob zuerst gespeichert werden soll, statt Änderungen stillschweigend zu verwerfen:

• „Ja, speichern“: sendet das betroffene Formular ganz normal ab (echter POST, kein AJAX-Nachbau) und merkt sich das eigentliche Navigationsziel in sessionStorage, um nach dem Speichern automatisch dorthin weiterzuleiten — der Link muss dafür nicht ein zweites Mal angeklickt werden.
• „Nein, verwerfen“: verwirft die Änderungen und wechselt direkt zur Zielseite.
• Klickt man stattdessen auf das eigene „Speichern“/„Anlegen“ der Seite direkt (ohne über einen Link zu einer anderen Seite zu gehen), passiert nichts zusätzlich — kein Dialog, kein Browser-Popup, es wird einfach ganz normal gespeichert.
• Für Browser-eigene Navigation (Tab schließen, Neuladen, Adresszeile) gibt es zusätzlich beforeunload — dort erlaubt der Browser aus Sicherheitsgründen nur eine generische Warnung ohne eigene Buttons, kein Ja/Nein/Speichern-Dialog. Sie wird bewusst unterdrückt, sobald die Seite ohnehin schon bewusst verlassen wird (eigenes Speichern oder der Ja/Nein-Dialog) — sie soll ausschließlich bei tatsächlich ungefragter Navigation erscheinen, nicht zusätzlich bei einem ganz normalen Speichern (live als genau dieses Doppel-Popup reproduziert und behoben).
• Ausnahmen über data-no-unsaved-guard auf Formular oder Link (z.B. das Login-Formular — Zugangsdaten eintippen ist keine "Einstellung").

Live per Playwright auf mehreren Seiten (Systemeinstellungen, DHCP-Options, Gruppen anlegen) verifiziert: eigener Dialog erscheint nur bei tatsächlich ungespeicherten Änderungen, „Ja“ speichert und leitet danach automatisch zum ursprünglichen Ziel weiter, „Nein“ verwirft und wechselt direkt, ein normales Speichern über den Seiten-eigenen Button zeigt weder eigenen noch Browser-Dialog.

Nebenbei wurde ein generisches Cache-Busting für app.js/style.css ergänzt (asset_url()-Helper, hängt die Änderungszeit der Datei als ?v=... an) — vorher konnte ein bereits gecachtes, veraltetes app.js im Browser nach einem Update scheinbar "nicht funktionierende" neue Funktionen verursachen, obwohl der Code auf dem Server längst aktuell war.

Navigation anpassen

Die Sidebar besteht aus zwei aufklappbaren Gruppen und mehreren flachen Top-Level-Punkten dazwischen:

• Geräte (Gruppe) — Clients (die eigentlichen Devices), Switche, Zugangsdaten, Wartung (SSH-Bulk-Update/-Neustart), Papierkorb (direkt unterhalb von Wartung, siehe Papierkorb)
• Benutzer, Gruppen — eigene, flache Top-Level-Punkte direkt nach „Geräte“ (bewusst nicht in einer Untergruppe versteckt)
• Einstellungen (Gruppe) — Systemeinstellungen (Host/Prüfintervall/ Navbar-Reihenfolge/Papierkorb-Aufbewahrung), LDAP, DHCP, Im-/Export
• Logs (Gruppe) — Live, Änderungen, Kea-DHCP

Die Reihenfolge der Top-Level-Punkte und der Unterpunkte innerhalb jeder Gruppe ist für Admins unter Systemeinstellungen (eigene, nicht einklappbare Karte „Navbar-Reihenfolge") per Auf-/Ab-Buttons konfigurierbar (gespeichert als JSON unter settings.nav_order bzw. settings.nav_child_order) und gilt global für alle Benutzer. Unabhängig von der Reihenfolge sieht jeder Benutzer ohnehin nur, wofür er berechtigt ist — sowohl auf Gruppenebene als auch pro Unterpunkt: hat ein Benutzer z.B. nur devices.view, erscheint die Gruppe „Geräte“ nur mit dem Unterpunkt „Clients“ (ohne Switche/Zugangsdaten/Wartung/Papierkorb); eine Gruppe verschwindet komplett, wenn kein Unterpunkt sichtbar ist.

Entwicklung unter WSL

Da das Projekt ausschließlich für Linux gebaut ist, empfiehlt sich die Entwicklung direkt unter WSL2 (Ubuntu), auch wenn der Editor unter Windows läuft — das Projektverzeichnis liegt dabei ganz normal unter C:\...\aruba-poe-modern und wird aus WSL über /mnt/c/... erreicht:

wsl --install -d Ubuntu        # einmalig, falls noch nicht vorhanden
wsl -d Ubuntu
sudo apt update && sudo apt install -y python3 python3-venv python3-pip sqlite3 expect openssh-client
cd /mnt/c/Users/<dich>/aruba-poe-modern/srv/tesm
python3 -m venv venv
./venv/bin/pip install -r requirements.txt
./venv/bin/python create_db.py
./venv/bin/python create_admin.py
./venv/bin/python app.py         # http://localhost:5000 — via WSL2-Portweiterleitung
                                  # auch aus dem Windows-Browser erreichbar

Hinweis zu tesm-check.service: Der „Speichern & Service neustarten“-Button unter Systemeinstellungen sowie das „Jetzt prüfen“-Icon funktionieren nur, wenn tesm-check.service tatsächlich als echter systemd-Service läuft (viele aktuelle WSL2-Installationen unterstützen systemd, siehe wsl.conf [boot] systemd=true). Für lokale Tests reicht es, etc/systemd/system/ tesm-check.service sowie usr/local/bin/custom/poe.sh per Symlink an ihre Produktivpfade (/etc/systemd/system/, /usr/local/bin/custom/) zu legen und /srv/tesm auf den Checkout zu verlinken, dann systemctl daemon-reload && systemctl enable --now tesm-check.service. Ohne systemd (z.B. systemctl nicht vorhanden) scheitert der Neustart-Aufruf lautlos — das Intervall in der DB wird trotzdem aktualisiert, greift dann aber erst nach einem manuellen Neustart des Prozesses.

Lokal starten (Entwicklung)

cd srv/tesm
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

python create_db.py             # legt sqlite.db + Tabellen an
python create_admin.py          # legt ersten Admin-Benutzer an

python app.py                   # http://localhost:5000

Produktiv-Deployment (auf der Ziel-VM, App landet unter /srv/tesm)

Das Repo wird bewusst nicht direkt nach /srv/tesm geklont — install.sh kopiert (rsync) den Inhalt von srv/tesm/ aus dem Repo gezielt dorthin und lässt Quell-Checkout und Zielverzeichnis damit sauber getrennt (kein doppeltes /srv/tesm/srv/tesm/…):

sudo git clone <dieses-repo> /opt/aruba-poe-modern-src
cd /opt/aruba-poe-modern-src
sudo bash install.sh
sudo /srv/tesm/venv/bin/python3 /srv/tesm/create_admin.py

Nach der Installation liegt die laufende App vollständig unter /srv/tesm (so wie es tesm.service, tesm-check.service und POE_SCRIPT/TESM_DB_PATH als Default erwarten) — /opt/aruba-poe-modern-src wird nur als Checkout-Quelle für install.sh gebraucht und kann danach liegen bleiben (für spätere Updates: git pull dort, dann install.sh erneut ausführen) oder gelöscht werden.

install.sh installiert Systempakete, richtet die venv ein, initialisiert die Datenbank (falls nicht vorhanden), kopiert poe.sh nach /usr/local/bin/custom/, registriert die systemd-Units (tesm.service, tesm-check.service, tesm-check-restart.timer) und konfiguriert nginx als Reverse-Proxy auf Port 80.

Relevante Umgebungsvariablen (optional)

Variable	Zweck	Default
TESM_DB_PATH	Pfad zur SQLite-DB	<app-dir>/sqlite.db
POE_SCRIPT	Pfad zum PoE-Restart-Skript	/usr/local/bin/custom/poe.sh
TESM_LOG_DIR	Verzeichnis für live.log/changes.log/app.log	/var/log/tesm
TESM_FERNET_KEY	Pfad zum Fernet-Schlüssel	<app-dir>/fernet.key (auto-erzeugt)
TESM_KNOWN_HOSTS	Pfad zur SSH-known_hosts-Datei des Terminals	<app-dir>/known_hosts (auto-erzeugt)
TESM_SECRET_KEY	Flask Secret Key (überschreibt Datei)	zufällig, in secret.key gespeichert
PORT, FLASK_DEBUG	Flask-Serverport / Debug-Modus	5000 / aus

Browser-SSH-Terminal (Switch-Verbindungstest)

„Verbindung testen“ im Switch-Modal öffnet eine WebSocket-Verbindung zu /ws/ssh_terminal. Serverseitig baut paramiko eine echte SSH-Sitzung zum Switch auf (inkl. interaktiver Host-Key-Bestätigung beim Erstkontakt, danach dauerhaft in known_hosts gemerkt) und reicht eine interaktive Shell 1:1 an ein xterm.js-Terminal im Browser durch. Die Zugangsdaten aus dem Formular werden direkt für die SSH-Authentifizierung verwendet (nicht als Tastatureingabe in die Shell getippt) — Erfolg/Fehlschlag der Anmeldung wird sofort und eindeutig im Terminal angezeigt. Ein Klick auf „Passwort einfügen“ sendet den aktuell im Formular eingetragenen Wert zusätzlich als Tastatureingabe (z.B. für ein sudo-Passwort in der geöffneten Sitzung).

Voraussetzungen:

• Läuft auf jedem Betriebssystem (paramiko ist reines Python) — die SSH-Verbindung wird dabei immer vom PoE-Server aus aufgebaut, nie vom Browser/Client.
• Nur für eingeloggte Admins erreichbar.
• Der Flask-Entwicklungsserver muss mit threaded=True laufen (ist bereits so konfiguriert) — für einen echten Produktivbetrieb empfiehlt sich ohnehin ein WSGI-Server mit WebSocket-Unterstützung (z.B. Gunicorn mit gevent- oder eventlet-Worker) statt des eingebauten Dev-Servers.
• nginx muss den WebSocket-Upgrade für /ws/ durchreichen (Upgrade/ Connection-Header, siehe etc/nginx/sites-available/tesm) — ohne das lehnt Flask den Handshake mit 400 Bad Request ab und das Terminal bleibt leer auf „Getrennt“ hängen, obwohl derselbe Aufruf direkt gegen Port 5000 (an nginx vorbei) funktioniert. War auf einer frisch per install.sh aufgesetzten Ubuntu-VM live reproduzierbar, da alle bisherigen Terminal-Tests ausschließlich direkt gegen Flask liefen, nie durch nginx.
• Da tesm.service (wie im Original) als root läuft, kann über dieses Terminal im Prinzip jeder erreichbare Host per SSH kontaktiert werden — bewusst so gewählt, da Admins über die App ohnehin schon vollen Zugriff auf alle hinterlegten Switch-Zugangsdaten haben. Für eine strengere Trennung empfiehlt es sich, tesm.service künftig unter einem eigenen, unprivilegierten Systembenutzer laufen zu lassen (im Original wie auch hier aktuell root, um Änderungen am produktiven Setup nicht zu vergrößern).

Projektstruktur

srv/tesm/        Flask-App (Backend + Templates + Static-Assets)
usr/local/bin/custom/    poe.sh — Ping-Check & PoE-Restart per SSH (expect)
etc/systemd/system/      Service-/Timer-Units (Web-App + Check-Dienst)
etc/nginx/               Reverse-Proxy-Konfiguration
install.sh               Produktiv-Installer