alientim/tesm
0
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases 41 Wiki Activity
41 Commits 3 Branches 43 Tags
49634da0d9b4238e3bf76bfe450d1c74b9da7168
Commit Graph
11 Commits
Author SHA1 Message Date
alientimandClaude Sonnet 5 49634da0d9 Aufräumen: totes/unbenutztes entfernt, Beispiele verallgemeinert 
- create_user.py entfernt: legte nur Nicht-Admin-Benutzer per CLI an,
  vollständig durch die Web-UI (Einstellungen -> Benutzer, unterstützt
  zusätzlich Vor-/Nachname und Gruppenzuordnung) abgedeckt und von
  nirgends (install.sh, README, systemd-Units) referenziert
- Ungenutzten Flask-Import send_from_directory entfernt (nie
  aufgerufen)
- Drei ungenutzte CSS-Regeln entfernt (in keinem Template/JS mehr
  referenziert): .btn-ghost, .dc-status (Karten-Layout hat kein
  .dc-status-Element mehr), .nav-divider
- Platzhalter für die manuelle DHCP-Reservierung nutzte als einziger
  im ganzen Projekt "192.168.80.x" statt der überall sonst
  verwendeten generischen Beispiel-Range "192.168.1.x" -- war ein
  Rest aus dem Testen gegen die konkrete Test-VM, jetzt vereinheitlicht
- Zwei nicht versionierte, lokale Log-Dateien (mini.log, server.log)
  aus dem Projektverzeichnis entfernt

Systematisch geprüft und dabei nichts Weiteres gefunden: alle 16
Templates werden tatsächlich gerendert, alle Imports (bis auf den
einen oben) werden verwendet, keine toten Hilfsfunktionen in app.py
(die drei Kandidaten aus einer AST-Analyse -- __getattr__,
avatar_url, display_name -- sind über Jinja-Attributzugriff bzw. als
Python-Dunder-Methode tatsächlich in Gebrauch), requirements.txt
enthält nur echte direkte + transitive Abhängigkeiten.

Live verifiziert: alle 14 Hauptseiten liefern nach dem Deploy weiterhin
HTTP 200, keine Fehler im journalctl-Log.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-08-12 13:50:22 +02:00
alientim 255308f81b App-weite Warnung bei ungespeicherten Aenderungen + Options-UI-Fix + Cache-Busting 
1. Generischer Ja/Nein-Dialog bei ungespeicherten Aenderungen (kein Opt-in
   pro Seite noetig): initUnsavedChangesGuard() erkennt automatisch jedes
   Formular mit echten Eingabefeldern, das seit dem Laden der Seite
   veraendert wurde, und fragt beim Klick auf einen Link (z.B. Sidebar-
   Navigation), ob zuerst gespeichert werden soll -- eigener Dialog
   (confirmSaveDiscard) statt des bestehenden confirmAction (dort ist
   "Abbrechen" = Bleiben, hier gibt es bewusst nur die zwei angefragten
   Optionen: speichern oder verwerfen, beide verlassen die Seite).
   "Ja, speichern" sendet das Formular ganz normal ab (echter POST) und
   merkt sich das eigentliche Ziel in sessionStorage, um danach automatisch
   dorthin weiterzuleiten.

   Nachtrag noch in dieser Session gefixt: ein normales Speichern ueber den
   Seiten-eigenen Button loeste zusaetzlich die native Browser-Warnung
   (beforeunload) aus, obwohl die Aenderung bereits gespeichert wurde --
   navigatingAway-Flag wird jetzt bei jedem Submit eines beobachteten
   Formulars (eigener Button ODER eigener Ja/Nein-Dialog) gesetzt, die
   generische Browser-Warnung erscheint dadurch nur noch bei tatsaechlich
   ungefragter Navigation (Tab schliessen, Reload, Adresszeile). Live per
   Playwright in drei Szenarien verifiziert (direktes Speichern, Ja via
   eigenem Dialog, Nein via eigenem Dialog) -- kein Browser-Popup in den
   ersten beiden Faellen, korrektes Redirect zum urspruenglichen Ziel nach
   "Ja".

2. DHCP-Options-Dropdown (Reservierungs-Dialog) verschiebt ein neu
   ausgewaehltes Options-Feld jetzt direkt unter das Dropdown (in einen
   .poe-added-options-Container) statt es nur an seiner urspruenglichen
   Stelle in der bis zu 57 Eintraege langen Liste einzublenden -- lag dort
   oft ausserhalb des sichtbaren Modal-Ausschnitts und wirkte, als waere
   nichts passiert. Bereits gesetzte Overrides stehen von Anfang an im
   selben Container, weitere haengen sich beim Auswaehlen unten an.

3. Cache-Busting fuer app.js/style.css (asset_url()-Helper, haengt die
   Aenderungszeit der Datei als ?v=... an) -- ein im Browser gecachtes,
   veraltetes app.js konnte nach einem Update sonst den Eindruck erwecken,
   eine neue Funktion wuerde "nicht funktionieren", obwohl der Code auf dem
   Server laengst aktuell war.

Alle drei live auf der Test-VM deployt und per Playwright verifiziert,
keine Fehler im journalctl-Log. (Testartefakt aufgeraeumt: der echte
Host-Hostname wurde durch die Playwright-Tests versehentlich auf
"directsave-test"/"navsave-test" geaendert und wieder auf POETEST
zurueckgesetzt.)
 2026-08-11 16:39:03 +02:00
alientim 1a0b55ed44 DHCP: manuelle Reservierungen, Options-Schutz+Dropdown-UI, Lease-Countdown-Fix 
1. Manuelle Reservierungen (dhcp_manual_reservations) fuer Geraete, die
   nicht als Client in dieser App gepflegt werden -- bewusst eine eigene,
   explizite Aktion (MAC/IP/Name), damit kein externes Geraet unueberwacht
   automatisch eine feste IP bekommt. _dhcp_reservation_candidates fuehrt
   automatische (aus devices) und manuelle Reservierungen jetzt zusammen,
   case-insensitiv nach MAC dedupliziert (automatisch gewinnt bei Konflikt).
   Automatische Reservierungen sind in der Tabelle nicht loeschbar
   (Schloss-Symbol statt Button, sie entstehen/verschwinden mit den
   Client-Stammdaten), manuelle schon. Live verifiziert: Hinzufuegen,
   doppelte MAC ablehnen, ungueltige MAC ablehnen, generierte Kea-Config
   mit gemischten Auto-/manuellen Reservierungen besteht kea-dhcp4 -t.

2. Standard-DHCP-Optionen um 10 weitere verifizierte Optionen erweitert
   (u.a. host-name/12 -- Kea-Name mit Bindestrich, NICHT "hostname", live
   gegen echtes Kea geprueft) -- jetzt 57 insgesamt. Standard-Optionen sind
   nicht mehr loeschbar (Backend lehnt es ab, UI zeigt ein Schloss-Symbol
   statt Loeschen-Button) -- vorher liess sich eine vorbefuellte Options-
   Definition versehentlich entfernen.

3. Options-Tabellen (global UND pro Reservierung) zeigen jetzt nur noch
   tatsaechlich genutzte Options -- eigene immer, Standard-Optionen nur mit
   gesetztem Wert. Weitere Standard-Optionen kommen ueber ein Dropdown
   "+ Option hinzufuegen" dazu statt permanent alle 57 als leere Felder zu
   zeigen. Das neu eingeblendete Feld wird automatisch in den sichtbaren
   Bereich gescrollt und fokussiert (bei bis zu 57 moeglichen Optionen kann
   das Feld sonst weit unterhalb des sichtbaren Modal-Ausschnitts liegen
   und es wirkt so, als waere nichts passiert).

4. Lease-Countdown-Fix: die Ablaufzeit wird jetzt explizit als UTC
   ausgewiesen (Kea arbeitet intern in UTC-Epoch) und zusaetzlich als live
   tickender Countdown angezeigt (gleiches Prinzip wie der bestehende
   "Naechste Pruefung"-Timer). Vorher wirkte eine reine Absolutzeit auf der
   nicht selbst aktualisierenden Seite bei den kurzen Standard-Lease-Zeiten
   (600s) schnell "schon abgelaufen", sobald etwas Zeit vergangen war, bis
   man tatsaechlich hinschaut -- live im echten Betrieb genau als dieses
   Missverstaendnis beobachtet und anhand der rohen Kea-CSV verifiziert,
   dass die richtige Spalte (expire) korrekt gelesen wird.

5. UI-Feinschliff: "In Datei schreiben" bei den Reservierungen heisst jetzt
   "Speichern" und ist der primaere (orange) Button, "Reservierung
   hinzufuegen" sekundaer -- das Hinzufuegen legt nur einen Datensatz an,
   erst "Speichern" schreibt die tatsaechlich wirksame Kea-Config.

Alles live auf der Test-VM deployt und verifiziert (Playwright fuer die
Dropdown-Sichtbarkeit/Fokus-Interaktion, curl fuer die Backend-Validierung,
kea-dhcp4 -t fuer die generierte Konfiguration), keine Fehler im
journalctl-Log.
 2026-08-11 15:52:52 +02:00
alientim 9885a579ea DHCP: Subnetze deaktivierbar + 47 verifizierte Standard-Optionen 
1. Subnetze koennen einzeln deaktiviert werden (enabled-Spalte), ohne sie
   loeschen zu muessen -- werden dann bei "In Datei schreiben" und
   "Aktivieren & (neu) starten" komplett uebersprungen. Bewusst nicht als
   "ungueltig" gewertet (kein Fehler/keine Warnung), da eine deaktivierte
   Zeile absichtlich kein echtes Netz braucht. Toggle-Button in der
   Subnetz-Tabelle, deaktivierte Zeilen abgeblendet mit "Deaktiviert"-Pill.

2. 47 kuratierte Standard-DHCP-Optionen vorbefuellt (analog den
   "Predefined Options" eines Windows-DHCP-Servers) -- Router/DNS-Server/
   Domain-Name/Lease-Zeiten ausgenommen, dafuer gibt es bereits eigene
   Felder. Alle Namen live gegen eine echte Kea-2.4.1-Instanz verifiziert:
   jede der 49 Kandidaten-Optionen einzeln per kea-dhcp4 -t getestet, 47
   akzeptiert (2 falsch geratene Namen verworfen: nis-domain-name statt
   nis-domain, nisplus-domain statt nisplus-domain-name).

   Wichtig fuer Kea-Kompatibilitaet: Standard-Optionen bekommen KEIN
   eigenes option-def in der generierten Konfiguration (neue is_standard-
   Spalte in dhcp_option_defs) -- Kea kennt sie bereits nativ, eine
   Neudefinition haette die eingebaute dupliziert. Nur echte eigene/
   herstellerspezifische Options bekommen weiterhin ein option-def.
   Live verifiziert: option-def bleibt bei gesetztem Standard-Options-Wert
   leer, option-data enthaelt den Wert korrekt, kea-dhcp4 -t besteht,
   echter Dienstneustart mit der Config erfolgreich.

   Einmalige Migration (Guard wie bei den anderen Schema-Migrationen) --
   ein vom Admin bewusst geloeschter Standard-Eintrag wird nach einem
   Neustart nicht stillschweigend wieder angelegt.

Ausserdem in dieser Session zuvor gefixt (siehe vorherige Commits): der
falsche Kea-Schluessel lease-file->name, der jeden Dienststart blockierte,
sowie der 'Jetzt pruefen'-Button, der den Topbar-Countdown nur auf dem
Dashboard aktualisierte.
 2026-08-11 15:06:55 +02:00
alientim bf9b816fa2 DHCP: Mehrfach-Subnetze, aktive Leases-Anzeige, Reboot-Persistenz 
1. Mehrere gleichzeitige DHCP-Subnetze statt einer einzelnen globalen Range
   -- ein Host kann mehrere IPs/Interfaces mit jeweils eigenem Netz haben,
   fuer die alle DHCP angeboten werden soll:
   - Neue Tabelle dhcp_subnets (interface, range_start/end, optionales
     gateway/dns je Zeile) statt der bisherigen dhcp_interface/_range_*/
     _gateway/_dns-Settings-Keys. Domain, Lease-Zeiten und Ausgabepfad
     bleiben global (Kea-weit gueltig).
   - Einmalige Migration: eine bestehende globale Einzel-Range wird beim
     ersten Start automatisch in eine erste Subnetz-Zeile ueberfuehrt,
     statt eine funktionierende Konfiguration beim Upgrade zu verlieren
     (live verifiziert: bestehende 192.168.80.220-230-Range korrekt
     uebernommen).
   - Neue Routen add/edit/delete_dhcp_subnet, jede mit derselben
     Sicherheitsregel wie zuvor: es muss eine physische IP im gewuenschten
     Bereich vorhanden sein (_dhcp_matching_network je Subnetz-Zeile),
     sonst wird die Aktion abgelehnt. _detect_interface_network wurde dafuer
     in eine neue _detect_interface_networks (alle IPv4-Adressen eines
     Interfaces, nicht nur die erste -- ein Interface kann mehrere IPs
     tragen) plus einen duennen Wrapper fuer die primaere Adresse aufgeteilt.
   - _render_kea_config generiert jetzt einen eigenen subnet4-Block je
     Subnetz (eigenes Gateway/DNS-option-data), _dhcp_reservation_candidates
     ordnet jedes Geraet anhand seiner IP dem richtigen Subnetz zu.
   - "In Datei schreiben" ueberspringt inzwischen ungueltig gewordene
     Subnetze einzeln (mit Warnung, welche) statt die ganze Aktion
     abzubrechen; "Aktivieren & (neu) starten" verweigert den Start, falls
     kein einziges gueltiges Subnetz mehr existiert.
   - Live auf der Test-VM verifiziert: Anlegen/Bearbeiten/Loeschen inkl.
     Ablehnung ungueltiger Ranges, generierte Kea-Config mit zwei
     subnet4-Bloecken korrekt (Interface, Subnet-CIDR, Pools je Zeile).

2. Aktive Leases direkt aus Kea sichtbar (settings_dhcp.html, neue Karte)
   -- macht Clients OHNE eigene Reservierung sichtbar, die sich einfach
   eine freie IP aus dem Pool genommen haben, statt nur die (unvollstaendige)
   Reservierungsliste zu zeigen. Liest die memfile-Lease-CSV direkt
   (kein Kea-Control-Agent noetig), reserved-Flag durch Abgleich mit den
   bekannten Reservierungs-MACs. Live gegen eine echte (leere)
   kea-leases4.csv verifiziert.

3. DHCP-Dienst uebersteht einen Host-Neustart jetzt korrekt im zuletzt
   bewusst gewaehlten Zustand: "Stoppen" deaktiviert den Dienst zusaetzlich
   (nicht nur systemctl stop), sonst wuerde systemd ihn nach einem Neustart
   automatisch wieder hochfahren, obwohl der Admin ihn bewusst abgeschaltet
   hat. Dieselbe Ergaenzung im automatischen Netzwerkaenderungs-Stop (siehe
   vorheriger Commit) -- sonst koennte ein Host-Neustart vor der
   Range-Pruefung den Dienst trotzdem mit einer ggf. falschen Konfiguration
   wieder starten.
 2026-08-11 14:42:27 +02:00
alientimandClaude Sonnet 5 4d7433e832 Fix: SSH-Terminal-Login (No auth methods), kaputtes DOM in Bearbeiten-Modals 
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>
 2026-08-11 12:00:22 +02:00
alientimandClaude Sonnet 5 6803929140 Hostname-Einstellung, DHCP-Range-Pflicht, Topbar-Ampel, Text-Straffung, Quelltext-Huerde 
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>
 2026-08-11 11:28:29 +02:00
alientimandClaude Sonnet 5 3d17728e75 Alle Anlegen-Modals einheitlich auf max-width:1000px 
- 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>
 2026-08-11 10:05:58 +02:00
alientimandClaude Sonnet 5 8e4a874943 DHCP: Subnet/Netzmaske/Gateway immer aus System-Netzwerkkonfiguration ableiten 
- 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>
 2026-08-11 08:28:11 +02:00
alientimandClaude Sonnet 5 c3d69a9870 DHCP: Backend auf Kea umgestellt, eigene Options (global + pro Client), echte Install-/Dienststeuerung 
- 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>
 2026-08-10 21:47:54 +02:00
alientimandClaude Sonnet 5 9eb9cfdda6 Neu: DHCP-Reservierungen aus Client-Stammdaten (Systemeinstellungen -> DHCP) 
- 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>
 2026-08-10 21:10:05 +02:00