Quelltext-Huerde wieder entfernt (auf Wunsch) - siehe vorherigen Commit,
hier nur der Revert von initSourceProtection() und der README-Erwaehnung.
SSH-Terminal-Login war komplett kaputt (von dir gemeldet + Screenshot):
- Root Cause: das Init-Payload vom Browser enthielt nie ein Passwort,
SSHClient.connect() bekam also weder Passwort noch Key noch Agent und
scheiterte sofort mit "No authentication methods available" - noch
bevor ueberhaupt eine interaktive Passwortabfrage moeglich gewesen
waere (die High-Level-API erledigt Host-Key-Pruefung UND
Authentifizierung in einem blockierenden Aufruf).
- Fix: Umstieg auf die Low-Level paramiko.Transport-API. Nach
Host-Key-Bestaetigung wird aktiv erfragt, welche Auth-Methoden der
Server anbietet (auth_none), und bei Bedarf interaktiv ueber das
Browser-Terminal nach Passwort/keyboard-interactive-Prompts gefragt
-- genau das Verhalten, das der bestehende Hinweistext im Modal schon
immer versprach, aber nie tatsaechlich implementiert war.
Host-Key-Verifikation dabei manuell nachgebaut (_verify_host_key_interactive)
inkl. hartem Ablehnen bei GEAENDERTEM (nicht nur unbekanntem) Host-Key,
wie ein echtes ssh-CLI bei einer moeglichen MITM-Situation.
- Waehrend der Live-Verifikation gegen ein echtes Geraet zwei weitere
Bugs gefunden und gefixt: ws.receive() wirft in diesem Setup
ConnectionClosed statt None zurueckzugeben (crashte
_terminal_read_line unbehandelt -> "Invalid frame header" beim
Client); _send_and_close() crashte ebenso, wenn der Client bereits weg
war. Beide jetzt defensiv abgefangen.
- Live gegen ein echtes Zielgeraet verifiziert (Host-Key-Bestaetigung,
Passwort-Prompt, erfolgreicher Login) sowie manuell von dir bestaetigt.
Kaputtes DOM in zwei Bearbeiten-Modals (von dir gemeldet: "Verbindung
testen" oeffnete beim Switch bearbeiten kein Fenster, obwohl es beim
Neuanlegen funktionierte):
- Root Cause: <div class="modal-overlay">...</div> stand direkt in
<tbody> (nur <tr> ist dort gueltig). Browser "foster-parenten"
ungueltigen Tbody-Inhalt aus der Tabelle heraus und zerreissen dabei
teils die Eltern-Kind-Beziehung zwischen <form> und seinen Buttons --
this.closest("form") lieferte dadurch null statt des Formulars.
Betroffen: editSwitchModal (switches.html), deviceOptionsModal
(settings_dhcp.html). Fix: beide Modal-Bloecke aus der Tabelle heraus
in eine eigene Schleife direkt danach verschoben (gleiches Muster wie
die bereits korrekten Neuanlegen-Modals).
- Per DOM-Inspektion verifiziert: this.closest("form") lieferte vorher
null, danach das korrekte Formular fuer alle Zeilen; End-to-End-Test
bestaetigt, dass sich das Terminal-Modal jetzt oeffnet.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Hostname (Systemeinstellungen, neben Pruefintervall):
- hostnamectl set-hostname ueber die App, Validierung (RFC-1123-artiges
Label), kein Revert-Timer noetig (kappt die Erreichbarkeit nicht wie
eine IP-Aenderung). Live getestet inkl. Validierung und Revert.
DHCP: Range ist jetzt Pflicht, kein geratener Default mehr:
- dhcp_range_start/end/dns starten leer (Platzhaltertext statt fake-
echt aussehendem Default) - ein Zufalls-Range haette den Dienst sonst
unbemerkt mit einer zum echten Netz nicht passenden Konfiguration
starten lassen koennen.
- write_dhcp_file und dhcp_service_action=enable_restart verweigern sich
ohne eingetragene Range; _render_kea_config laesst "pools" ohne Range
komplett weg statt einen kaputten Pool-String zu erzeugen.
- Neues, separates dhcp_gateway-Feld (optional) fuer einen vom
automatisch erkannten Gateway abweichenden Router fuer die Clients.
Topbar-Ampel fuer den Kea-Dienst:
- Gruener/roter Punkt neben dem Pruefintervall-Timer, nur sichtbar mit
settings_dhcp.view (ein einzelner, kurzer systemctl-Aufruf pro Request,
nicht die volle Status-Erkennung). Live verifiziert (rot wenn gestoppt,
gruen wenn gestartet).
Reservierungstabelle zeigt jetzt pro Client, welche eigene DHCP-Option
greift (global oder Client-Override, mit Wert im Tooltip).
Text-Straffung: die laengsten Hint-Texte und Code-Kommentare in
Templates/app.py gekuerzt (u.a. groups.html, settings_dhcp.html,
account.html, devices/switches/users/credentials.html, zwei grosse
Migrations-/DHCP-Kommentarbloecke in app.py) - Kernaussagen erhalten,
Redundanz entfernt.
Quelltext-Huerde (KEINE echte Sicherheit, nur Abschreckung): Rechtsklick
und DevTools-/Quelltext-Shortcuts per JS blockiert. Klar dokumentiert
in Kommentar + README, dass der Browser HTML/CSS/JS immer vollstaendig
ausliefert und das in Sekunden umgehbar ist - echte Absicherung bleiben
ausschliesslich die serverseitigen Rechteprüfungen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- addGroupModal, addCredentialModal, addOptionModal (DHCP), addSwitchModal,
deviceModal (Gerät anlegen), userModal (Benutzer anlegen) — bisher
unterschiedliche/keine explizite Breite, jetzt einheitlich 1000px für
ein konsistentes Erscheinungsbild. Bearbeiten-/Zuweisen-Modals bleiben
bei ihrer bisherigen (kleineren) Breite, da dort keine so breite
Rechtetabelle wie bei Neue Gruppe eingebettet ist.
- Live verifiziert: Modal-Breite tatsächlich 1000px (vorher lieferte ein
vergessener Flask-Neustart fälschlich 900px trotz bereits geänderter
Vorlage — Erinnerung: Template-Änderungen brauchen ohne
TEMPLATES_AUTO_RELOAD einen Neustart, anders als CSS/JS).
- Gruppen-Rechtetabelle bei 1440px (typische Breite dieser App) identisch
zum Neue-Gruppe-Modal nebeneinander, ohne Umbruch.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Neue Helfer _list_network_interfaces() (echte Interfaces aus
/sys/class/net) und _detect_interface_network() (IPv4/Prefix per
"ip addr show", Gateway per "ip route show default") — Subnet/
Netzmaske/Router werden dadurch bei jeder Anzeige/Generierung live vom
System gelesen statt manuell gepflegt zu werden.
- dhcp_subnet/dhcp_netmask als manuelle Settings entfernt; Interface ist
jetzt ein Dropdown mit den tatsächlich vorhandenen Interfaces statt
Freitext, serverseitig zusätzlich gegen die echte Liste validiert.
- _dhcp_reservation_candidates()/_render_kea_config() nehmen jetzt das
erkannte Netz (ipaddress.IPv4Network) bzw. net_info entgegen statt
Subnet/Netzmaske aus der Konfiguration zu lesen; Router kommt vom
erkannten Gateway (Fallback: erster DNS-Eintrag, wie zuvor).
- UI zeigt das erkannte Netz (IP/Prefix, Subnet, Gateway) read-only an;
Schreiben/Vorschau werden blockiert bzw. liefern eine leere
Reservierungsliste, wenn die Erkennung fehlschlägt, statt eine mit
Sicherheit falsche Konfiguration zu erzeugen.
- Live getestet: Erkennung liefert korrekt das tatsächliche WSL-NAT-Netz
(172.25.64.0/20) samt Gateway; generierte Config besteht kea-dhcp4 -t;
ein Testgerät mit IP im erkannten Netz erscheint korrekt als
Reservierung, Geräte außerhalb werden weiterhin sauber übersprungen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Backend-Wechsel von isc-dhcp-server (seit 2022 EOL) auf Kea DHCP
(kea-dhcp4-server) — aktiv weiterentwickelt, bildet "globaler Wert, pro
Client überschreibbar" nativ über Kea-Reservation-Option-Data ab.
- Neue Tabellen dhcp_option_defs/dhcp_option_values: eigene/herstellerspezifische
Options mit Code/Name/Typ/Beschreibung, Wert global sowie optional pro
Client (device_mac="" für global, siehe Kommentar zur SQLite-NULL-
UNIQUE-Falle). UI dafür: Optionen-Tabelle + "Neue Option"-Modal +
Pro-Client-Overrides-Modal je Reservierung.
- Kea-JSON-Generator (_render_kea_config): option-def für jede eigene
Option, globale Werte im Top-Level option-data, Client-Overrides im
option-data der jeweiligen Reservierung.
- Reservierungen werden jetzt zusätzlich auf Zugehörigkeit zum
konfigurierten Subnet gefiltert (_dhcp_reservation_candidates) — beim
Live-Test gegen echtes Kea gefunden: Kea lehnt Reservierungen außerhalb
ihres Subnets als Konfigurationsfehler ab, das muss also schon bei der
Generierung berücksichtigt werden statt erst beim Laden zu crashen.
- Neue, einzeln bestätigte Aktionen: "kea-dhcp4-server installieren"
(apt-get), "Aktivieren & (neu) starten" sowie "Stoppen"
(systemctl) — bewusst getrennt von "Konfiguration speichern"/"In
Datei schreiben".
- Live gegen eine echte, frisch installierte Kea-3.0.3-Instanz verifiziert:
Installation erfolgreich, generierte Config besteht "kea-dhcp4 -t",
Dienst übernimmt sie beim Neustart fehlerfrei (DHCP4_CONFIG_COMPLETE),
globaler Options-Wert und Client-Override erscheinen korrekt getrennt.
Danach wieder gestoppt; Paket bleibt installiert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Neue Unterseite unter Einstellungen (eigenes Rechtepaar
settings_dhcp.view/settings_dhcp.edit, in PERMISSIONS/NAV_ITEMS/
_nav_key_visible integriert, Kill-Switch über settings_group.view
greift wie bei den anderen Einstellungen-Unterpunkten).
- Rein lesende Installations-/Status-Erkennung (shutil.which("dhcpd"),
systemctl is-active isc-dhcp-server) — die App installiert/startet nie
selbst einen DHCP-Dienst, sondern zeigt bei fehlender Installation den
passenden manuellen Befehl an.
- Konfigurierbare Netzwerkparameter (Interface/Subnet/Netzmaske/Range/
DNS/Domain/Lease-Zeiten/Ausgabepfad), gespeichert als dhcp_*-Schlüssel
in der bestehenden settings-Tabelle.
- Reservierungen werden aus aktiven Geräten mit gültiger MAC+IP generiert
(Hostname aus Gerätename abgeleitet, Kollisionen automatisch
durchnummeriert, Geräte ohne MAC/IP werden übersprungen).
- "In Datei schreiben" (nur mit settings_dhcp.edit) schreibt eine
separate Include-Datei statt der aktiven dhcpd.conf; kein automatischer
Dienst-Reload/-Restart durch die App.
- Live getestet: Status-Erkennung, Config speichern, Reservierungs-
Generierung inkl. Namenskollisionen, Datei-Schreiben in sicheren
Testpfad, View-only-Gating (Formular ausgeblendet, POST blockiert),
Kill-Switch über settings_group.view.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
alientimandClaude Sonnet 5