bf9b816fa24eca69415e62cab7a41291e00e0a34
7
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 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.
|
||
 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>
|
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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>
|