OPNexus/CHANGELOG.md

Changelog

Alle nennenswerten Änderungen an OPNexus, mit Version und Datum. Für die vollständige Feature-Beschreibung (Screenshots, Verifikationsnachweise, v1-Scope-Grenzen) siehe die datierten Abschnitte in Handbuch — dieses Dokument ist die kurze Versions-/Namens-Übersicht, nicht der Ersatz dafür.

Versionierung

OPNexus folgt Semantic Versioning (MAJOR.MINOR.PATCH):

• MAJOR — Breaking Changes (z.B. inkompatible API-/Schema-Änderungen, entfernte Features).
• MINOR — neue Features, rückwärtskompatibel (der Regelfall bei einem Projekt, das noch aktiv wächst).
• PATCH — Bugfixes und kleine Korrekturen ohne neues Feature.

Zusätzlich bekommt jede MINOR- und MAJOR-Version einen Codenamen — Raubvögel, alphabetisch aufsteigend über die Releases hinweg (ähnliches Prinzip wie Ubuntus alliterierende Tier-Codenamen, nur ohne den doppelten Anfangsbuchstaben-Zwang). Ein PATCH-Release behält den Codenamen seiner MINOR-Version. Die aktuelle Version steht in frontend/lib/version.ts (APP_VERSION/APP_CODENAME) und backend/app/version.py — beide von Hand gepflegt, keine Build-Pipeline/kein Git-Hash-Tagging, bewusst analog zur bisherigen Konvention (siehe Handbuch, "Login-Infos" 2026-09-09). Sichtbar in der App auf der Login-Seite, im Footer jeder Seite, auf /about und in den Einstellungen.

Nächste Codenamen (der Reihe nach, wenn die jeweils nächste MINOR-Version ansteht): Merlin …

[1.23.11] "Harrier" — 2026-10-20

• Updates per Klick prüfen jetzt ebenfalls die Signatur: Der Updater-Container enthält cosign (feste Version, Prüfsumme beim Bau geprüft) und verifiziert die neuen Images vor dem Wechsel, wenn cosign.pub im Projektverzeichnis liegt. Das Image wird dadurch größer (rund 266 statt 123 MB).

[1.23.10] "Harrier" — 2026-10-20

• Signierte Release-Images: Die Images (backend, frontend, proxy, updater) werden mit cosign signiert, beginnend mit 1.23.9. Der öffentliche Schlüssel liegt als cosign.pub im Repository und im Release-Bundle. opnexus update prüft die Signaturen vor dem Wechsel, wenn cosign installiert ist. Anleitung: Handbuch, „Images prüfen“.

[1.23.9] "Harrier" — 2026-10-20

• Update-Karte: Der Hinweis für Installationen ohne Release-Images nennt jetzt die tatsächliche Ursache („OPNEXUS_IMAGE_REPO ist nicht gesetzt“) statt „baut aus dem Quellcode“.
• cosign.pub: öffentlicher Schlüssel für die Signaturen der Release-Images (das Release-Skript kann Images jetzt signieren).

[1.23.8] "Harrier" — 2026-10-20

• Einstellungen › OPNexus aktualisieren: Auf einer Installation, die aus dem Quellcode gebaut wird (kein OPNEXUS_IMAGE_REPO), erscheint nicht mehr die Anleitung zum Aktivieren des Updaters – Updates per Klick gibt es dort ohnehin nicht –, sondern nur der Hinweis auf git pull und docker compose up -d --build. Das Backend erkennt den Modus jetzt selbst (neue Umgebungsvariable im Compose-File).

[1.23.7] "Harrier" — 2026-10-20

• Hinweistext der Versionsprüfung verweist auf den Schalter „oben“ statt „unten“.

[1.23.6] "Harrier" — 2026-10-20

• Versionsprüfung im Webinterface: Unter Einstellungen › OPNexus aktualisieren lässt sich die Prüfung auf neue Versionen jetzt per Schalter und Feed-Adresse einstellen – kein Eingriff in die .env mehr nötig (Migration 0019). Standardmäßig bleibt sie aus. Ein gesetztes UPDATE_CHECK_URL in der .env hat weiter Vorrang und sperrt den Schalter (mit Hinweis).

[1.23.5] "Harrier" — 2026-10-20

• Fix (Ursache des Vorfalls vom 20.10. in 1.23.4): OPNsense merkt ein CARP-VIP zum Löschen vor, wenn eine Änderung kein interface mitschickt, und der anschließende „Anwenden“-Schritt entfernt es dann live, ohne es wieder anzulegen. OPNexus schickt bei jeder VIP-Änderung jetzt die bisherige Schnittstelle mit (wie schon die Adresse). Auf dem Test-Cluster mit echten Firewalls nachgestellt und bestätigt.
• Einstellungen › OPNexus aktualisieren: Die Anleitung zum Aktivieren nennt jetzt alles Nötige in einem Block (auch UPDATE_CHECK_URL) und weist darauf hin, dass Updates per Klick Release-Images brauchen; wer aus dem Quellcode baut, aktualisiert mit git pull und docker compose up -d --build.

[1.23.4] "Harrier" — 2026-10-20

• Fix (Produktiv-Vorfall 2026-10-20): Das Ändern der Beschreibung eines CARP-VIP wendete das VIP neu an und ließ es auf beiden Firewalls im Zustand INIT hängen – OPNexus zeigte trotzdem „alles in Ordnung“. Nur die Beschreibung zu ändern, wendet jetzt nichts mehr an. Nach jeder anderen CARP-VIP-Änderung prüft OPNexus den Live-Zustand (MASTER/BACKUP), wendet bei Bedarf einmal erneut an und meldet sonst „Angewendet, Prüfung weicht ab“.
• CARP-Überwachung je VHID: Neue Warnungen vip_down (ein VIP ist auf einem Node nicht aktiv) und role_mismatch (ein Node ist nur für einen Teil der VIPs MASTER). Bisher zählte der Host schon als MASTER, sobald ein einziges VIP MASTER war.

[1.23.3] "Harrier" — 2026-10-20

• SSO: Liefert der Anbieter preferred_username/email nicht im ID-Token (Authelia), fragt OPNexus sie beim Userinfo-Endpunkt ab; der neue Benutzer heißt dann alice statt wie die kryptische Benutzerkennung des Anbieters. Geprüft gegen Keycloak 26 und Authelia 4.39; S3-Offsite gegen Garage, MinIO, RustFS und Versity S3 Gateway.

[1.23.2] "Harrier" — 2026-10-20

• SSO-Fix (gefunden beim Test gegen ein echtes Keycloak): Die Standard-Scopes enthalten nicht mehr groups – Keycloak und Entra ID lehnten die Anmeldung damit mit invalid_scope ab. Bestehende Einstellungen mit dem alten Standardwert werden umgestellt (Migration 0018); Anbieter wie Okta tragen groups bei Bedarf selbst ein (Hinweis in den Einstellungen).

[1.23.1] "Harrier" — 2026-10-20

• Sicherheit (Ergebnis eines unabhängigen Reviews der Versionen 1.18–1.23):
  • Aufgabentrennung: Mit „nur Admins rollen aus“ ist jetzt auch das Löschen verwalteter Objekte (entfernt sie von den Firewalls), Zertifikat-/ACME-Push, Dienste starten/stoppen und „Reihenfolge erneut durchsetzen“ den Admins vorbehalten, nicht nur /deploy.
  • Backup-Änderungsansicht: weitere Geheimnis-Felder (otp_seed, pass, pwd, …) werden ausgeblendet, die Platzhalter sind pro Abruf gesalzen (kein Wörterbuchabgleich, kein Vergleich über Abrufe/Firewalls).
  • SSO: der Anmeldeversuch ist per Cookie an den Browser gebunden (kein Login-CSRF, abgefangene Code/State-Paare sind nutzlos); SSO-Sitzungen dauern 12 Stunden statt 30 Tage; Gruppen-Strings werden nur an Komma/Zeilenumbruch getrennt (Gruppen mit Leerzeichen); Fehlertext des Anbieters wird für das Log bereinigt.
  • Das Ändern des eigenen Passworts widerruft jetzt auch die eigenen API-Tokens.
  • Management-Tunnel: der Hub routet nicht mehr zwischen Firewalls oder ins Compose-Netz (FORWARD verworfen, ip_forward=0); loopback-/link-local-Netze sind als Tunnel-Netz nicht erlaubt.
  • Sicherheitslage: eine defekte config.xml stoppt die Prüfung der übrigen Firewalls nicht mehr; die Auswertung läuft außerhalb der Ereignisschleife.
  • Behoben: S3-Offsite mit Port 443 im Endpunkt (Signatur passte nicht); Variablenwerte mit angehängtem Zeilenumbruch werden abgelehnt.
• Fertiges Grafana-Dashboard (docs/grafana-opnexus.json) für die Prometheus-Metriken von OPNexus.

[1.23.0] "Harrier" — 2026-10-20

• Sicherheitslage im Alltag: Dashboard-Karte mit den Firewalls mit dem niedrigsten Wert; Benachrichtigung bei kritischen und hohen Befunden (je Firewall und Prüfung, mit „behoben“-Meldung; standardmäßig aus; Migration 0017); druckbarer Sicherheitsbericht (Knopf „Bericht“, Drucken/PDF über den Browser).

[1.22.0] "Peregrine" — 2026-10-20

• Standort-Variablen: {{NAME}}-Platzhalter in Regeln, Aliasen, Portweiterleitungen, 1:1- und Outbound-NAT, je Host mit eigenem Wert (Host-Seite › Standort-Variablen, listet die verwendeten Platzhalter automatisch). Je Host aufgelöst in Vorschau, Ausrollen, Zählern und Audit; fehlt ein Wert, wird nichts gesendet (Vorschau „Variable fehlt“, Ausrollen wird vor jedem Schreiben abgelehnt, zusätzlich eine Sperre im API-Client). Neue Tabelle host_variables (Migration 0016).

[1.21.0] "Osprey" — 2026-10-20

• Management-Tunnel (System › Management-Tunnel): Firewalls hinter NAT/CGNAT verwalten. Ein optionaler WireGuard-Hub auf dem OPNexus-Server (Compose-Profil overlay, Container wg-hub aus dem Backend-Image mit NET_ADMIN) nimmt die Firewalls entgegen, die sich nach außen einwählen; OPNexus erreicht deren API über einen kleinen CONNECT-Proxy des Hubs, der nur ins Tunnel-Netz verbindet. Je Firewall eine Tunnel-Adresse und ein eigener Pre-Shared Key, Anleitung mit kopierbaren Werten, Live-Status (Handshake, Datenmenge). Der Hub nimmt keine neuen Verbindungen aus dem Tunnel an. Ende-zu-Ende gegen eine echte OPNsense 26.7 geprüft (Handshake, API, Zertifikat festsetzen). Neue Tabellen overlay_settings, overlay_peers (Migration 0015); das Backend-Image enthält jetzt wireguard-tools, iproute2, iptables.

[1.20.0] "Lilli" — 2026-10-20

• Single Sign-on (OIDC): Anmeldung über Authentik, Keycloak, Entra ID, Google u. a. (Authorization Code mit PKCE). Die Rolle kommt bei jeder Anmeldung aus den Gruppen des Anbieters, ohne zugeordnete Gruppe kommt niemand hinein; SSO-Konten werden nie mit lokalen Konten verknüpft; lokale Anmeldung bleibt als Notzugang. ID-Token werden streng geprüft (Signatur nur asymmetrisch, Aussteller, Zielgruppe, Ablauf, Nonce, einmaliger State), gegen einen nachgebauten Anbieter getestet (inkl. Fälschungsversuche). Neue Tabellen oidc_settings, oidc_login_states, Spalten admin_users.auth_source/oidc_subject (Migration 0013). Neue Abhängigkeit: PyJWT.
• Behoben: opnexus backup --full und opnexus restore (Vollsicherung, in 1.19.0 beschrieben) fehlten im 1.19.0-Bundle und -Updater-Image, weil die Änderung am Skript nicht mit eingecheckt war; sie sind erst ab dieser Version enthalten.
• Aufgabentrennung: Schalter, mit dem nur Admins ausrollen dürfen, Operatoren aber vorbereiten (Migration 0014).

[1.19.0] "Lanner" — 2026-10-20

Backups, Governance, Regelnutzung. Auf einem Test-Stack mit drei Test-Firewalls geprüft; die Vollsicherung Ende-zu-Ende (sichern, Schaden anrichten, zurückspielen), siehe Handbuch „Konfigurationssicherungen“, „Sichern und Wiederherstellen“.

• Rolle „Operator“: rollt aus und betreibt (Regeln, NAT, VPN, Wartung, Sicherungen), verwaltet aber keine Benutzer, Einstellungen oder Hosts und lädt keine Roh-Backups herunter. Abgelehnte Versuche stehen im Audit. Tokens eines Operators gehen bis zum Bereich „Ausrollen“.
• Audit-Export (Einstellungen): Syslog (RFC 5424, UDP/TCP/TLS) und/oder signierter Webhook, mindestens einmal zugestellt, ohne Objektinhalte. Neue Tabelle audit_export_settings (Migration 0010).
• Geplante Backups mit Aufbewahrung, verschlüsseltem Offsite-Ziel (S3-kompatibel, AES-256-GCM, Passphrase bleibt auf dem Server), Benachrichtigungen bei Problemen und einer Änderungsansicht zwischen zwei Sicherungen (Geheimnisse nur als Hash). Neue Tabellen backup_settings, backup_uploads, Spalte notification_settings.backup_failed_enabled (Migration 0011). Die S3-Signatur ist gegen die offiziellen AWS-Beispiele geprüft; ein Lauf gegen einen echten Anbieter steht noch aus.
• Vollsicherung opnexus backup --full und opnexus restore: Datenbank und alle Geheimnis-Volumes in einer verschlüsselten Datei; Ende-zu-Ende auf dem Test-Stack geprüft (Sichern, Schaden anrichten, Zurückspielen).
• Regelnutzung: wann hat jede Regel zuletzt etwas getroffen (aus den pf-Zählern, überlebt Neuladen und Neustart); Befund „Regeln in Benutzung“ in der Sicherheitslage nach 30 Tagen ohne Treffer. Neue Tabelle rule_hits (Migration 0012).
• Änderungen an Einstellungen (/api/settings/…) und das Auslösen von Sicherungen stehen jetzt im Audit.

[1.18.0] "Kestrel" — 2026-10-19

Automatisierung und Sicherheitslage. Ende-zu-Ende gegen einen Test-Stack und drei Test-Firewalls geprüft, siehe Handbuch „Sicherheitslage“ und „Automatisierung“.

• API-Tokens (System › API-Tokens): persönliche Tokens für Skripte, CI, Prometheus und KI-Assistenten, Bereiche Lesen, Ausrollen, Admin. Nur als Hash gespeichert, einmal angezeigt, widerrufbar, mit Ablaufdatum; Anlegen verlangt das Passwort. Ein Token überschreitet nie die Rechte seines Besitzers. Tokens verwalten und das eigene Konto geht nur in einer normalen Anmeldung. Geheimnisse (Roh-Backups, Benachrichtigungseinstellungen) liest nur der Bereich Admin. Das Audit nennt das Token. Neue Tabelle api_tokens (Migration 0008).
• Prometheus-Metriken unter GET /api/metrics (Host erreichbar, Last, Speicher, Platte, CARP-Rolle, offene Aktionen und Probleme, Sicherheitswert), nur aus der Datenbank, ohne Anfragen an die Firewalls.
• MCP-Endpunkt POST /api/mcp (nur lesend) für KI-Assistenten: Flottenübersicht, Hosts, Auslastung, CARP-Ereignisse, Audit, Suche und ein Leser für jeden GET-Endpunkt, mit den Rechten des Tokens.
• OpenAPI-Schema jetzt unter /api/openapi.json (bisher unter /openapi.json, vom Proxy nicht erreichbar); die Swagger-/ReDoc-Seiten entfallen (ihre CDN-Skripte verbietet die CSP).
• Sicherheitslage (Monitoring › Sicherheitslage): Härtungs- und Regel-Hygiene-Prüfungen je Firewall mit Wert 0–100: Allow-all am WAN, HTTPS, SSH, SNMP, verdeckte/doppelte/unbeschriftete Regeln, Zeitserver, externe Logs, Firmware, Backup-Alter. Liest die Konfiguration nur lesend, speichert sie nicht, alle 6 Stunden und auf Knopfdruck. Neue Tabelle compliance_results (Migration 0009).
• Behoben: Änderungen am Benutzer in einer Anfrage (z. B. 2FA aktivieren) gingen verloren, wenn die Middleware den Benutzer aus einer anderen Datenbank-Sitzung lieferte; er wird jetzt in der Sitzung der Anfrage neu geladen.

[1.17.0] "Imperial" — 2026-10-19

Geplante Wartung: Fehler zeigen sich sofort statt erst um 3 Uhr nachts, und der Master lässt sich unbeaufsichtigt aktualisieren. Auf einem Test-Cluster live geprüft (Neustart und ein echtes Update mit Umschaltung), siehe Handbuch „Geplante Wartung“.

• Rollenprüfung beim Einplanen: Ein Host, der in einem Cluster gerade CARP-MASTER ist, lässt sich nicht mehr einplanen (Neustart/Update/Major-Upgrade). Bisher wurde der Plan angenommen und scheiterte erst zur Uhrzeit. Der Planungsdialog zeigt den Grund an und sperrt den Button. Ist die Rolle nicht feststellbar (Host gerade nicht erreichbar), wird weiter angenommen; die volle Prüfung läuft wie bisher zum Zündzeitpunkt.
• Benachrichtigung „Geplante Wartung nicht ausgeführt“: Eine fehlgeschlagene geplante Wartung meldet sich per Webhook/E-Mail (einzeln schaltbar in den Einstellungen, standardmäßig an). Offen für drei Tage nach dem geplanten Zeitpunkt, dann ohne „behoben“-Meldung geschlossen. Neue Spalte notification_settings.scheduled_maintenance_failed_enabled (Migration 0006).
• Automatische CARP-Umschaltung (Option pro Plan, standardmäßig aus): Ein geplanter Neustart, Update oder Major-Upgrade auf dem MASTER schaltet vorher auf den Partner um, prüft die Übernahme, führt die Aktion aus, wartet auf die Rückkehr des Hosts und schaltet zurück. Fehler vor dem Start der Aktion stellen den Normalbetrieb wieder her; danach bleibt der Host bewusst im Wartungsmodus (Partner trägt den Verkehr) und es kommt eine Benachrichtigung. Der Ablauf steht in der Datenbank und überlebt einen Neustart des Backends. Neue Spalten an scheduled_maintenance (Migration 0007).
• Backup vor geplantem Update: Ein geplantes Update oder Major-Upgrade zieht unmittelbar vor dem Start selbst ein Konfigurationsbackup (nur lesend auf der Firewall). Bisher scheiterte jeder Plan, der mehr als 24 Stunden in der Zukunft lag, an der Backup-Aktualität. Schlägt das Backup fehl, wird nicht aktualisiert.

[1.16.0] "Hobby" — 2026-10-10

Erste Schritte nach der Installation. Ende-zu-Ende gegen einen isolierten Stack getestet, siehe Handbuch „Einrichtungsassistent und Passwort-Reset“:

• Einrichtungsassistent (/setup, System › Einrichtung): vier Schritte mit Erklärungen — Willkommen und Sprache, Konto (eigenes Passwort, Zwei-Faktor-Anmeldung), erste Firewall verbinden (inklusive Anleitung für den API-Key in OPNsense, Zertifikat festsetzen, Verbindungsstatus) und eine Übersicht, was als Nächstes sinnvoll ist. Auf einer frischen Installation ohne Hosts öffnet er sich nach der ersten Anmeldung von selbst; „Assistent überspringen“ merkt sich das pro Benutzer, erneut öffnen geht jederzeit über System › Einrichtung oder die Einstellungen. Nur für Admins. Neue Spalte user_preferences.setup_done (Migration 0005).
• opnexus password [NAME] setzt ein neues Zufallspasswort für den Admin und zeigt es an (--yes ohne Rückfrage; Rückfrage nur, wenn sich schon jemand angemeldet hat). Ersetzt das Suchen im Backend-Log nach dem beim ersten Start erzeugten Passwort und taugt zugleich für ein vergessenes Admin-Passwort. Alle Sitzungen des Kontos enden. Dahinter steht python -m app.reset_password. Die Meldung beim ersten Start verweist darauf.

[1.15.0] "Gyrfalcon" — 2026-10-10

Updates aus dem Webinterface. Auf Klick, mit Fortschritt und automatischem Rollback; ein eigener, optionaler Container erledigt die Arbeit. Ende-zu-Ende mit echten Images getestet, siehe Handbuch „Update aus dem Webinterface (optional)“:

• Updates aus dem Webinterface (optional): Einstellungen › „OPNexus aktualisieren“ zeigt die neueste Version samt Release-Notes und aktualisiert auf Klick — mit Fortschrittsanzeige, automatischem Rollback bei einem fehlgeschlagenen Update und „Auf Vorversion zurücksetzen“ (mit Hinweis, ob dabei Daten verloren gehen). Dahinter arbeitet ein eigener, kleiner Updater-Container (updater/, Compose-Profil updater, mit COMPOSE_PROFILES=updater in .env aktivieren), der dieselbe Logik wie opnexus update ausführt. Er ist standardmäßig aus und der einzige Container mit Docker-Socket; das Backend bekommt ihn nie. Der Updater hat keinen veröffentlichten Port, ist nur mit einem selbst erzeugten Token ansprechbar und kann ausschließlich „aktualisieren auf die vom Release-Feed gemeldete neueste stabile Version“, „zurückrollen“ und „Status“. Hauptversions-Sprünge bleiben der Kommandozeile vorbehalten. Anfragen stehen im Audit-Log (neuer Typ „OPNexus-System“). Gilt nur für Release-Images.
• opnexus (jetzt in updater/opnexus, scripts/opnexus ist ein Symlink): status --porcelain, Exit-Code 3 für „fehlgeschlagen und sauber zurückgerollt“. Release-Images und -Bundle enthalten zusätzlich opnexus-updater.
• Der Banner „Neue Version verfügbar“ verlinkt auf den neuen Abschnitt in den Einstellungen.

[1.14.0] "Eagle" — 2026-10-09

Diagnose von der Firewall aus sowie VXLAN und GIF. Gegen die OPNsense-Core-Quellen geprüft und live auf den Test-Firewalls getestet, siehe Handbuch „Erweiterung 1.14.0“:

• Host-System › Diagnose: Ping, Traceroute, Port-Prüfung und DNS-Abfrage, ausgeführt von der ausgewählten Firewall. Nur für Admins, strenge Eingabeprüfung, jeder Lauf im Audit-Log, Ping-Jobs werden immer wieder aufgeräumt, der Banner der Gegenstelle wird nicht weitergegeben. Packet-Capture gibt es bewusst nicht (Mitschnitte enthalten fremde Nutzdaten).
• Netzwerk › Geräte: VXLAN und GIF-Tunnel (anlegen, ändern, löschen) über dieselbe abgesicherte Engine wie die übrigen Geräte.
• Fehlerkorrektur: Auf den Host-System-Seiten war „Übersicht › Hosts“ markiert und der Seitentitel falsch, weil /hostsystem mit /hosts beginnt.

[1.13.0] "Buzzard" — 2026-10-09

Mehr Verwaltung pro Firewall und ein Abgleich der Cluster-Knoten. Alles über dieselbe abgesicherte Engine wie in 1.12.0 und live auf drei Test-Firewalls geprüft, siehe Handbuch „Erweiterung 1.13.0“:

• Netzwerk › Geräte: LAGG, Bridge, Loopback und GRE. Dazu Gateway-Gruppen, DNS-Weiterleitungen (Unbound) und DHCP-Bereiche (dnsmasq).
• Neue Gruppe „Host-System“: Tunables (immer mit Bestätigung, Vorgaben nur per „Überschreiben“), Cron, Syslog-Ziele und ZFS-Snapshots (anlegen und löschen; der aktive Snapshot ist geschützt, das Aktivieren bleibt OPNsense selbst überlassen).
• Netzwerk › Abgleich: zeigt Unterschiede in der Netzwerk-Konfiguration zwischen den Knoten eines Clusters. Neuer Alarm „Netzwerk-Abweichung im Cluster“ (Einstellungen › Benachrichtigungen, Migration 0004).
• Auf den Partner übertragen: Nach dem Anlegen eines Objekts lässt es sich mit einem Klick auch auf dem anderen Cluster-Knoten anlegen (eigene Vorschau, eigenes Backup).
• Kopfzeile: Mit acht Gruppen zeigt die Navigation die Namen ab 1150 px, darunter nur Icons, damit Suche und Abmelden in einer Zeile bleiben.

[1.12.0] "Condor" — 2026-10-09

Netzwerk-Verwaltung und Übernahme von Hand angelegter Regeln. Alles gegen die OPNsense-Core-Quellen geprüft und live auf drei Test-Firewalls (26.7.1 und 26.7.6) getestet, siehe Handbuch „Netzwerk, DNS und DHCP“:

• Neuer Bereich „Netzwerk“: Inventar je Firewall (Schnittstellen mit Adressen und CARP-Zustand, VLANs, virtuelle IPs, Gateways, Routen, DNS-Einträge, DHCP) und Änderungen daran: anlegen, bearbeiten, löschen für VLANs, virtuelle IPs, Gateways, statische Routen, Schnittstellen-Zuweisung samt IP-Konfiguration, Unbound-DNS-Einträge, dnsmasq-Hosts sowie Kea-Subnetze und -Reservierungen.
• Abgesichert: Jede Änderung läuft über eine Vorschau mit Diff und einem Token, der den Firewall-Stand erfasst. Vor dem Schreiben wird ein Konfig-Backup gespeichert (ohne Backup keine Änderung), danach angewendet und zurückgelesen. OPNexus erkennt, über welche Schnittstelle es die Firewall erreicht; Änderungen, die diese Verbindung kappen können (Verwaltungs-Schnittstelle, Standard-Gateway, Standardroute, Route über die Firewall-Adresse), brauchen eine ausdrückliche Bestätigung mit Eingabe des Firewall-Namens. Es gibt bewusst keinen automatischen Rollback: OPNexus kann eine Änderung nicht zurücknehmen, wenn sie seine eigene Verbindung trennt. Das Backup vor der Änderung ist der Rückweg.
• Schnittstellen-Löschen: OPNsense entfernt dabei selbst alle Regeln, die die Schnittstelle nutzen. Die Vorschau listet sie, die Bestätigung ist Pflicht. Bereits auf der Firewall vorgemerkte Änderungen blockieren eine neue Änderung.
• IP-Konfiguration per API gibt es erst ab OPNsense 26.7.6. Auf 26.7.1 ist die Zuweisungsliste nur lesbar; OPNexus erkennt das an den Daten und sperrt die Änderung mit Begründung.
• Von der Firewall übernehmen: Regeln, die direkt in OPNsense angelegt wurden, lassen sich in OPNexus übernehmen, bearbeiten und ausrollen. Die Übernahme schreibt nichts auf die Firewall. Regeln, die das Modell verfälschen würde (invertierte Quelle/Ziel, mehrere Schnittstellen, keine Quick-Regel, …), werden mit Grund abgelehnt. Neu: Regeln haben ein Protokollieren-Flag (log, Migration 0003), damit es beim Bearbeiten nicht still verloren geht; nicht modellierte Felder (Gateway, Zustandsoptionen, …) bleiben auf der Firewall unverändert.
• Geheimnisse: Das CARP-Passwort (liefert OPNsense im Klartext) und der Kea-DDNS-Schlüssel werden nie zurückgegeben, gespeichert oder auditiert.
• Host-Adresse änderbar: Hosts › Bearbeiten hat jetzt das Feld „Adresse“. Nach einer Änderung der Verwaltungs-IP muss der Host nicht mehr gelöscht und neu angelegt werden; Verlauf und Zuordnungen bleiben erhalten. Meldet eine Änderung „angewendet, aber nicht prüfbar“, weist die Oberfläche darauf hin.
• Fehler aus den Live-Tests, die Mocks nicht gezeigt haben: Jede Änderung einer virtuellen IP muss die Adresse (network) wiederholen, sonst leert OPNsense sie bzw. lehnt ab; die Prüfung nach dem Anwenden vergleicht jetzt den vollständigen Soll-Zustand statt nur der gesendeten Felder. Dazu: Gateway-Priorität als Zahl, Routen mit enabled statt disabled, Beschreibungsmuster der Schnittstellen, gesperrte Schnittstellen, Pflicht-Backup vor jeder Änderung.
• Hinweis zu den Versionen: Die IP-Konfiguration von Schnittstellen per API gibt es erst ab OPNsense 26.7.6. Mit 26.7.5 (die Prod-Firewalls) sind VLANs, virtuelle IPs, Gateways, Routen, DNS und DHCP verwaltbar, Schnittstellen nur lesbar.

[1.11.1] "Merlin" — 2026-10-09

Fehler aus dem ersten Live-Test der bisher nur gemockten Funktionen auf drei echten OPNsense-Firewalls (alle in den Tests mit Mocks unsichtbar geblieben). Live bestätigt sind jetzt auch das Major-Upgrade über den Update Center (25.7 → 26.1 → 26.7, je mit Backup und Abschluss-Bestätigung), WireGuard, OpenVPN, IPsec, Zertifikate, ACME (Staging), hierarchische Policies, Benachrichtigungen und der HA-Config-Sync:

• Zertifikate (Trust-Store) und ACME ließen sich nicht pushen: Die URLs endeten auf …Action (/trust/cert/addAction), OPNsense kennt aber nur /trust/cert/add, set, del bzw. /acmeclient/…/add, update, del (404). Die Mocks hatten denselben Tippfehler. Ein neuer Test prüft den Client-Quelltext gegen dieses Muster.

• OpenVPN-Deploy scheiterte immer: Die Firewall verlangt vpnid und vergibt es nicht selbst. OPNexus wählt jetzt die nächste freie. Außerdem erwarten cert/ca (OpenVPN) und caref (Zertifikat signieren) die refid der Trust-Store-Einträge, der Picker lieferte die Zeilen-UUID. Die Listen /hosts/{id}/certificates und /cas liefern jetzt refid; im Zertifikatsformular gibt es ein CA-Dropdown statt eines Freitextfelds.

• WireGuard meldete „Erfolg“ ohne laufenden Tunnel: Ist der globale Dienst (VPN › WireGuard › Allgemein) aus, entsteht trotz geschriebener Konfiguration kein Interface. Der Deploy schaltet den Dienst jetzt ein.

• Dienststeuerung: Das Backend prüfte weder, ob der Dienst existiert, noch ob er gesperrt ist (pf, webgui, routing …). Beides war nur in der UI gesperrt; unbekannte Namen meldete die Firewall trotzdem als „ok“. Jetzt 404 SERVICE_NOT_FOUND bzw. 409 SERVICE_LOCKED.

• Fehlertexte der Firewall unleserlich: Die Redaktion maskierte jede Validierungsmeldung, deren Feldname cert, crt oder auth enthält („instance.cert: [redacted]“). In validations lösen diese drei Namen die Maskierung nicht mehr aus; echte Geheimnisfelder bleiben maskiert. Das Löschen eines benutzten Zertifikats nennt jetzt den Grund der Firewall („Item in use by OpenVPN …“) statt eines allgemeinen Fehlers.

• Drift-Alarme flackerten beim Neustart eines Cluster-Mitglieds: Mit nur einem erreichbaren Host gab es nichts zu vergleichen, offene Regel-/NAT-Drift- und Zertifikatsprobleme wurden „gelöst“ und danach neu geöffnet (je ein Meldungspaar pro Problem). Offene Probleme bleiben jetzt unverändert, solange sie nicht beurteilbar sind.

• IPsec lief nach dem Deploy nicht: Der globale IPsec-Schalter war aus, die Verbindungen wurden gespeichert, reconfigure antwortete „ok“, OPNexus meldete „Erfolg“ (gleiche Klasse wie bei WireGuard). Der Deploy schaltet ihn jetzt ein; zwischen zwei Test-FWs steht der Tunnel (Phase 1 verbunden).

• Löschen scheiterte ohne Grund: Wenn die Firewall ein Löschen ablehnt (Alias noch in einer Regel, Zertifikat in Benutzung), nennt die Meldung jetzt den Grund der Firewall (UPSTREAM_REJECTED) statt „Anfrage fehlgeschlagen“.

• Kaputte Eingaben: Ein NUL-Zeichen in einem Textfeld ergab einen 500er samt abgebrochener Verbindung, ebenso ein langes oder NUL-haltiges Pfadsegment (der Audit-Eintrag übernahm es ungeprüft in VARCHAR(36)). Jetzt 422 bzw. 404/422; ein Fuzz-Lauf über alle 188 Routen findet keine 5xx mehr.

• opnexus rollback landete auf der falschen Version: Zurückgesetzt wurde auf die vom Backend gemeldete Programmversion statt auf den vorher eingestellten Image-Tag. Bei Release-Candidates (rc1-Images melden schon 1.11.0) führte das auf das neuere Release. Jetzt wird der vorherige exakte Tag wiederhergestellt.

• Handy-Ansicht (375px) zoomte aus: Die ausgeblendete Überschrift der Aktionsspalte (sr-only, absolut positioniert) lag außerhalb der scrollbaren Tabellenkarte und machte die Seite bis zu doppelt so breit (Hosts, Benutzer, Host-Details). Scroll-Container sind jetzt der Bezugsrahmen.

• Überschriften-Reihenfolge: Kartentitel in den Listen (OpenVPN, IPsec, WireGuard, NAT) sind h2 statt h3, sichtbar erst mit Daten; axe meldet auf allen Seiten, hell und dunkel, nichts mehr.

• CARP-Wartungsfenster mit Auto-Revert: Nach dem automatischen Zurückschalten blieb die Aktion „CARP-Übergabe“ (carp_enter) offen. Sie ließ sich nicht mehr bestätigen (der Host ist ja nicht mehr im Wartungsmodus) und blockierte alle Deploys und Updates im Cluster (OPEN_HOST_MAINTENANCE_BLOCKS_DEPLOY), bis jemand sie von Hand abbrach. Der Auto-Revert schließt die Aktion jetzt selbst (Status „abgebrochen“, Audit-Eintrag). Schlägt das Zurückschalten fehl, bleibt sie bewusst offen. Gefunden beim Live-Test gegen zwei OPNsense-26.7-Firewalls.

• Update Center, Protokoll-Fenster: Nach einem Update mit Neustart ist das Protokoll der Firewall leer; angezeigt wurde dann nur das Wort „error“, obwohl das Update erfolgreich war. Jetzt steht dort ein erklärender Hinweis.

[1.11.0] "Merlin" — 2026-10-07

Sicherheitsüberprüfung vom 2026-10-07, umgesetzte Korrekturen. Verhaltensänderungen, die beim Update auffallen können:

• Backup-Rohdownload nur für Admins. Nur-Lese-Konten sehen weiter die Liste der Snapshots, bekommen die config.xml (enthält Passwort-Hashes, VPN-Schlüssel) aber nicht mehr; jeder Versuch steht im Audit-Verlauf (neuer Status „abgelehnt“).
• Passwortwechsel/-reset beendet alle Sitzungen des Kontos; ebenso 2FA-Reset durch einen Admin. 2FA aktivieren/deaktivieren beendet die anderen Sitzungen.
• SMTP über SSL/STARTTLS prüft Zertifikat und Hostname. Mailserver mit privater CA: SMTP_CA_FILE setzen. SMTP-Anmeldung ohne Verschlüsselung ist gesperrt (ALLOW_INSECURE_SMTP_AUTH=true hebt das bewusst auf).
• Firewalls nur noch per https:// — beim Anlegen und bei jeder Anfrage; ein vorhandener http://-Host zeigt „offline“, statt Zugangsdaten im Klartext zu senden (ALLOW_INSECURE_FIREWALL_URLS=true nur für Labor-Setups).
• VPN-Push (IPsec/OpenVPN/WireGuard) verlangt das Vorschau-Token und das Token ändert sich, sobald nur das Geheimnis (PSK/Schlüssel) rotiert wurde. Die Vorschau zeigt „unverändert“ jetzt korrekt, statt jeden Tunnel dauerhaft als geändert.
• Host löschen ist auch bei VPN-, Zertifikats- und ACME-Objekten auf der Firewall gesperrt, bis diese entfernt sind; Schlüsseldateien nie bereitgestellter Entwürfe werden mit entfernt.
• Benachrichtigungs-Geheimnisse liegen jetzt im Volume notification_secrets . Ohne lesbares Signatur-/SMTP-Geheimnis wird nichts mehr gesendet (vorher: unsigniert/ohne Login). Wer Geheimnisse gesetzt hat, muss sie nach dem Update einmal neu eingeben, falls der Container zwischenzeitlich ersetzt wurde.

Weitere Korrekturen:

• Oberfläche: Der „Bestätigen“-Button steht jetzt am Ende der Deploy-Ergebnis-Zeile statt in der Aktionszeile (Regeln, Aliase, Port-Forwards, 1:1-NAT, Outbound-NAT, Hierarchie-Regeln); die Aktionszeile springt nicht mehr, wenn ein Deployment offen wird.

• Deployments hinterlassen vor dem ersten Firewall-Aufruf eine dauerhafte Spur (gemeinsamer Ablauf deploy_flow.py für Regeln, Aliase, Port-Forwards, 1:1-NAT, Outbound-NAT und Hierarchie-Regeln): Bei Absturz, verlorener Antwort oder Timeout bleibt die Rollback-Frist erhalten und der Sweeper macht die Änderung rückgängig. Wo die Firewall eine neue Regel möglicherweise angelegt hat, ohne dass eine UUID bekannt ist, steht der Eintrag auf „Rollback fehlgeschlagen“ mit dem Hinweis „Ausgang unklar“ (blockiert erneutes Deployen, löst die Benachrichtigung aus); „Rollback wiederholen“ entfernt ihn. Von der Firewall beantwortete Ablehnungen und Verbindungsfehler bleiben einfache Fehler.

• TOTP- und Recovery-Codes sind auch bei gleichzeitigen Anfragen genau einmal verwendbar (Zeilensperre).

• Login-Sperre: begrenzter Speicher, Argon2 läuft außerhalb des Event-Loops mit Parallelitätsgrenze, 2FA-Einrichtung/-Aktivierung/-Deaktivierung und Passwortwechsel haben ein Versuchslimit; offene 2FA-Einrichtung läuft nach 15 Minuten ab; Proxy begrenzt API-Anfragen auf 2 MB.

• Fehlermeldungen der Firewall werden vor Speicherung/Anzeige von Geheimnissen bereinigt und gekürzt; Validierungsfehler (422) geben Eingaben nicht mehr zurück; Webhook-URLs (oft mit Token) sieht ein Nur-Lese-Konto nur noch als Host.

• Audit: MFA/Passwort, VPN, Zertifikate/ACME, Benachrichtigungen und Backup-Exporte werden aufgezeichnet, ebenso abgelehnte Schreibversuche von Nur-Lese-Konten.

• Same-Origin-Prüfung berücksichtigt das Schema bei COOKIE_SECURE=true; Warnung beim Start, wenn FRONTEND_ORIGIN https ist, das Cookie aber nicht Secure . Geheimnisdateien werden atomar mit Modus 0600 angelegt.

• Frontend-Abhängigkeiten (sharp, source-map-js, brace-expansion) aktualisiert. Offen: braces/postcss-selector-parser nur in Build-Werkzeugen (Tailwind 3 / ESLint), nicht im Laufzeit-Image; für braces gibt es keine gepatchte Version.

[1.10.1] "Lanner" — 2026-10-06

PATCH-Release (Bugfixes, Dokumentation, Lizenz/Repo-Umstellung) nach dem ersten Live-Test gegen frische OPNsense-26.7-Firewalls; löst die Release Candidates 1.10.0-rc1/-rc2 ab.

• Fehlerbehebung aus dem ersten Live-Test mit OPNsense 26.7:
  • Beschädigte HTTP-Antworten einer Firewall (bekannter kTLS-Fehler in OPNsense 26.x) werden als solche gemeldet, mit dem Workaround kern.ipc.tls.enable=0 im Log (vorher nur „Verbindung fehlgeschlagen“).
  • Die Log-Ingest-Warnung nennt den echten Grund statt pauschal „nicht erreichbar?“ – die Firewall war in diesem Fall erreichbar.
  • BACKEND_PORT/FRONTEND_PORT in der .env, damit eine zweite (Test-)Instanz auf demselben Rechner ohne Änderung am Compose-File läuft.
  • Neues Handbuch-Kapitel „Fehlerbehebung“ (kTLS, zweite Instanz, OUTBOUND_MODE_BLOCKS_PUSH, Erkennungstakt der CARP-Historie) und zwei Regressionstests.
• Datenbank-Namen: Standard für Datenbank und Benutzer ist jetzt opnexus (POSTGRES_DB/POSTGRES_USER in der .env, auch von Backup-Dienst, opnexus-Kommando und CI gelesen). Ältere Installationen tragen ihre bisherigen Namen in der .env ein (Handbuch, „Datenbank-Namen“). Alte Projektnamen sind aus Quelltext, Handbuch und Changelog entfernt.
• Lizenzwechsel zur PolyForm Shield License 1.0.0 (siehe Handbuch, „Lizenz“): Download, Quellcode-Einsicht und eigener Einsatz bleiben kostenlos, der Weiterverkauf und konkurrierende Produkte durch Dritte sind ausgeschlossen. Bereits unter AGPL-3.0 veröffentlichte Stände bleiben unter der AGPL.
• Website: „Open Source“-Aussagen entfernt, Texte zur Lizenz angepasst.
• Öffentliches Repo git.opnexus.dev/opnexus/opnexus: pro Release ein sauberer Snapshot-Commit (scripts/publish_public.sh), Images in der Registry derselben Gitea (scripts/build_release_images.sh).
• Neue kurze README.md (Englisch) und README.de.md; die ausführliche Dokumentation ist jetzt das Handbuch docs/HANDBUCH.md. Dazu SECURITY.md.
• Update-Feed liegt unter website/latest.json (ausgeliefert als https://updates.opnexus.dev/latest.json); Website-Auslieferung über Cloudflare Pages (website/_headers).

[1.10.0] "Lanner" — 2026-10-05

Update-Fähigkeit, Teil 2: Release-Images (siehe Handbuch „Release-Images & CI“):

• CI-Workflows (.github/workflows/): Tests bei Push/PR; bei einem Tag vX.Y.Z baut der Release-Workflow Multi-Arch-Images (amd64/arm64) für Backend, Frontend und Proxy und pusht sie. Die Registry ist reine Repository-Konfiguration (GitHub oder Forgejo).
• docker-compose.yml: jeder Dienst hat build: und image: (OPNEXUS_IMAGE_REPO/OPNEXUS_VERSION, Image-Namen opnexus-backend/-frontend/-proxy); Update aus Release-Images ist docker compose pull && docker compose up -d --no-build.
• Proxy-Image mit eingebackener Caddyfile statt Bind-Mount.
• scripts/check_version.sh prüft Tag, Versionsdateien und CHANGELOG.

Update-Fähigkeit, Teil 3: Update-Werkzeug (siehe Handbuch „Update und Rollback mit opnexus“):

• scripts/opnexus mit status, update, rollback, backup: Pull vor dem Eingriff, Warten auf „gesund“, automatisches Zurückrollen, Rollback schließt die Datenbank-Wiederherstellung aus dem Pre-Upgrade-Backup ein.
• Behoben — Pre-Upgrade-Backup war nicht zurückspielbar: das Backend-Image hatte pg_dump 17 (Debian 13) gegen einen Postgres-16-Server, solche Dumps lassen sich dort nicht einspielen. Das Image installiert jetzt den Client 16 (backend/scripts/install_pg_client.sh); der Start bricht vor der Migration ab, wenn Client- und Server-Hauptversion nicht übereinstimmen. Ein neuer Test spielt das Backup tatsächlich zurück.
• PROXY_HTTPS_PORT und PROXY_HTTP_PORT machen die Proxy-Ports konfigurierbar.
• Compose getrennt: docker-compose.yml nur mit Images (= Release-Compose), docker-compose.override.yml mit den Build-Kontexten für den Repo-Checkout.
• scripts/make_release_bundle.sh erzeugt ein Release-Bundle (Compose mit eingebackener Registry/Version, .env.example, opnexus, Anleitung).
• ESLint ignoriert die generierte next-env.d.ts.

Update-Fähigkeit, Teil 4: Hinweis auf neue Versionen:

• „Neue Version verfügbar“-Banner für Administratoren. Quelle ist ein Release-Feed im Format von GitHub/Forgejo releases/latest (UPDATE_CHECK_URL); ohne URL ist die Funktion aus und OPNexus macht keine ausgehende Anfrage. Neuer Endpunkt GET /api/system/version-check (Ergebnis 12 Stunden gecacht, Fehler werden leise abgefangen und nicht sofort wiederholt, Vorabversionen werden nie angeboten, nur http(s)-Links werden weitergegeben). Pro Version wegklickbar. Aktualisiert wird nie automatisch, sondern mit opnexus update.

[1.9.0] "Kite" — 2026-10-04

Update-Fähigkeit, Teil 1: Schema-Migrationen (siehe Handbuch „Schema-Migrationen & Upgrade“):

• Alembic ersetzt schema_patches.py. Das Schema wird versioniert (backend/migrations/); app/migrate.py migriert beim Start unter einem Advisory-Lock und in einer Transaktion. Frische Installationen bauen das Schema aus der Baseline 0001 auf, Installationen bis 1.8.x werden einmalig überbrückt und gestempelt (0002 gleicht dabei fehlende Server-Defaults und einen fehlenden Index an).
• Automatisches Backup vor jeder Migration: pg_dump nach /backups/pre-upgrade-…dump; schlägt es fehl, wird nicht migriert.
• Eine Datenbank, die von einer neueren Version migriert wurde, wird nicht mehr stillschweigend weiterbenutzt — der Start bricht mit klarer Meldung ab.
• app/schema_patches.py ist jetzt app/legacy_schema_patches.py (eingefroren, nur noch die Brücke).
• Neue Tests (tests/test_migrations.py): Frisch-Aufbau gleicht den Modellen, Altinstallation behält ihre Daten, Backup-Pflicht, parallele Starts.
• Server-Defaults, die bisher nur auf gepatchten Installationen existierten, stehen jetzt auch in den Modellen.

[1.8.1] "Harris" — 2026-10-04

• Laufende Aktionen sind sichtbar: Während ein Push, Speichern oder eine andere Aktion läuft, zeigt der Button jetzt einen drehenden Spinner vor dem Text („Push läuft…“) statt nur den Text zu wechseln (neue Prop loading an Button, gesetzt in allen Review-Dialogen, Formularen und Bestätigungen). Lade-Hinweise („Wird geladen…“) nutzen die neue Komponente components/ui/Loading.tsx mit Spinner. Bei „Bewegung reduzieren“ im Betriebssystem bleibt der Spinner stehen.

[1.8.0] "Harris" — 2026-10-04

Barrierefreiheit (siehe Handbuch „Barrierefreiheit“):

• Kontrast: Die Grautöne für Nebentext (slate-400/slate-500) erfüllen im Hellmodus jetzt WCAG AA (4,5:1); Links in sky-700 statt sky-600; im Dunkelmodus war der aktive Menüpunkt hell auf hell (Kontrast 1,99) und ist behoben.
• Tastatur: sichtbarer Fokusring für alle Elemente, „Zum Inhalt springen“- Link, aria-current im Menü, Bereichsnavigation als eigene Landmarke, scrollbare Tabellenbereiche per Tab erreichbar.
• Screenreader: sprechende Seitentitel pro Seite („Regeln · OPNexus“), genau eine h1 je Seite (Login und Über-Seite hatten keine), korrekte Überschriftenreihenfolge in Regeln, Aliasen und Logs, Icons nur dekorativ, leere Tabellenköpfe tragen „Aktionen“, Host-Status wird jetzt übersetzt statt fest deutsch.
• Neues Prüfskript scripts/verify_a11y.mjs (axe-core, alle Seiten, Hell/ Dunkel/Mobil): 0 Verstöße.

[1.7.0] "Goshawk" — 2026-10-04

Sichere Übertragung (siehe Handbuch „Sichere Übertragung“):

• HTTPS-Proxy (Caddy) mit interner CA: Zertifikate auch für reine IPs, Zugriff per IP und Namen ohne DNS, CA-Download unter /opnexus-ca.crt. Backend/Frontend nur noch auf 127.0.0.1; API same-origin.
• Zertifikats-Pinning pro Firewall (Hosts → Bearbeiten, Fingerprint- Bestätigung); verify_tls=false ist nicht mehr nötig. Neue Spalte opnsense_hosts.tls_ca_pem, Endpunkt POST /api/hosts/tls-probe.
• Zwei-Faktor-Anmeldung (TOTP) optional pro Benutzer mit Wiederherstellungscodes, Replay-Schutz, Admin-Reset und Notfall-CLI python -m app.reset_2fa. Neue Spalten admin_users.totp_*.
• Origin-Prüfung gegen CSRF, Sicherheits-Header (HSTS, CSP, …), FRONTEND_ORIGIN akzeptiert mehrere Ursprünge, API-Antworten no-store.
• Login-Screen fragt bei aktivem 2FA den Code ab; Hosts zeigen ein Schild für den TLS-Status.
• Abhängigkeiten: PostCSS-Lücken per overrides behoben (npm audit: 0), pip-audit: keine bekannten Lücken; neue Abhängigkeiten cryptography (Backend) und qrcode (Frontend).
• Tests laufen unabhängig von den Transport-Einstellungen in .env.
• Fehler behoben: Kehrte ein bereits gelöstes Problem zurück (z. B. „Rollback fehlgeschlagen“), scheiterte die Benachrichtigungsprüfung an der Unique-Constraint, und der Alarm ging verloren. Die Zeile wird jetzt wiederverwendet (notification_dedup.py).

[1.6.0] "Peregrine" — 2026-10-04

Bedienbarkeit: Hinweise statt Textblöcke.

• Neue Tooltip-Komponente (components/ui/Tooltip.tsx): erscheint bei Hover, Tastaturfokus und Tippen, schließt mit Esc, wird nie von Karten oder Dialogen abgeschnitten und funktioniert auch auf deaktivierten Buttons.
• Update Center: Die großen Hinweis- und Sperrgrund-Kästen sind entfallen. Warum „Update vorbereiten“ gesperrt ist, steht jetzt im Tooltip des Buttons (mit Schloss-Symbol); Intro, Backup-Regel, Neustart- und CARP-Hinweise sind Tooltips bzw. kompakte Badges. Erfolgsmeldungen erscheinen als Toast. Die Bestätigungsdialoge (Hostname + Häkchen) bleiben unverändert, sind aber kürzer, fokussieren das Eingabefeld und sagen am deaktivierten Button, was noch fehlt.
• Dauerhafte Hinweisabsätze auf Audit, Einstellungen, Host-Wartung, Live-NAT, Review-Verläufen und in Formularen (Hierarchie, Private Key) sind zu Info-Tooltips geworden (FieldGroup hat dafür ein hint).
• Zeilenaktionen vereinheitlicht (Regeln, NAT, Aliase, VPN, Hosts, Benutzer): eine Hauptaktion („Prüfen & Push“), Bearbeiten als Outline-Button, Löschen dezent in Rot, Verlauf/Duplizieren als Icon mit Tooltip. Deploy-Ergebnisse stehen kompakt in einer Zeile.
• Seitenintros auf allen Seiten sind Info-Tooltips am Seitentitel; der Push-Hinweis (Bestätigungsfrist, automatischer Rollback) ist eine kurze Zeile mit Tooltip.
• Host-Detail: Live-Regeln und Live-Aliase sind einklappbar (mit Anzahl) und scrollen intern; die Seite ist von ~10.900 px auf ~2.300 px geschrumpft.
• Restore-Wizard: ein Schritt statt zwei, Warnung bleibt sichtbar, Übergabe nur nach Eingabe des Hostnamens.
• Dashboard-Aktivität zeigt lesbare Aktionsnamen („Update-Suche“ statt check-updates); große Zahlen in den Logs sind mit Tausendertrennung.
• Log-Erfassung: neues Größenlimit in GB (Einstellungen → Log-Erfassung, Standard 10 GB, 0 = unbegrenzt). Ist es erreicht, werden die ältesten Einträge gelöscht; die Einstellungen zeigen den belegten Speicher mit Balken. Neue Spalte log_settings.max_size_gb (per schema_patches.py). Beschriftungen klargestellt: „gespeichert“ (ganze Tabelle) in den Einstellungen, „Treffern“ (aktueller Filter) auf der Logs-Seite.
• UI-Korrekturen: Karten in Regel-/Alias-/NAT-Listen haben wieder Abstand (space-y wirkte nicht über fieldset.contents), Input/Select behalten ihre Standardstyles auch mit eigener className, alle Buttons sind gleich hoch, Einstellungen mit klaren Feldabständen.
• Dark Mode jetzt in neutralem Anthrazit statt Navy-Blau (Skala zentral in globals.css); Info-/Neutral-Badges, Toasts und der Sekundär-Button sind entsättigt, der Dialog-Hintergrund ist ein dunkler Schleier.
• Login-Screen: animierter Netzwerk-Hintergrund (Knoten, Verbindungen, wandernde Datenpakete – blau = erlaubt, gelegentlich orange = blockiert), gestaffelte Eingangsanimation, Schütteln bei falschen Zugangsdaten, Ausblenden nach erfolgreichem Login. Respektiert prefers-reduced-motion (dann statisch) und pausiert bei verstecktem Tab.
• Dialoge halten den Tastaturfokus (Tab-Falle) und geben ihn beim Schließen zurück; Login-Felder haben Autocomplete-Attribute.

[1.5.0] "Osprey" — 2026-09-19

Mehrsprachigkeit (Deutsch/Englisch) vollständig — siehe Handbuch, "Mehrsprachigkeit (Deutsch/Englisch)":

• Alle Seiten und Komponenten der Oberfläche sind auf Katalogschlüssel umgestellt (vorher nur Login, Navigation, Dashboard, Hosts und ein Teil der Regeln); Datums-/Zeitformate folgen der gewählten Sprache.
• API-Fehler bleiben sprachneutral (detail: {code, params}): die letzten rohen HTTPExceptions in services/ sowie die Middleware-Antworten (401 „nicht angemeldet“, 403 „Nur-Lese“) liefern jetzt ebenfalls Codes.
• Deutsche Fließtexte in Erfolgsantworten (Deploy-Vorschau-Warnungen, Wartungs-/Deploy-Meldungen, Revisionsnotizen, Validierungsfehler) werden im Client über frontend/lib/i18n/serverMessages.ts ins Englische übersetzt.
• Neu: scripts/check_i18n.py prüft Katalog-Parität, Platzhalter, ErrorCode-Abdeckung und referenzierte Schlüssel.
• tsconfig.json: target auf ES2018 (nur Typprüfung, noEmit) wegen benannter Regex-Gruppen.

378 Backend-Tests grün, tsc --noEmit/next build sauber.

[1.4.0] "Merlin" — 2026-09-17

Lizenz und dritte Härtungsrunde:

• AGPL-3.0 als Projektlizenz festgelegt — komplett kostenlos nutzbar, Netzwerk-Klausel verhindert unveränderten/leicht angepassten Weiterverkauf als proprietären Hosted-Dienst (siehe Handbuch, "Lizenz").
• /docs, /redoc, /openapi.json erfordern jetzt eine Anmeldung statt öffentlich erreichbar zu sein.
• Login-Sperrschutz kann jetzt optional (TRUST_PROXY_HEADERS) die echte Client-IP aus X-Forwarded-For lesen, für den Betrieb hinter einem Reverse-Proxy — standardmäßig aus, nur mit explizitem Vertrauen in den Proxy zu aktivieren.

378 Backend-Tests grün.

[1.3.0] "Kestrel" — 2026-09-17

Zweite Härtungsrunde, ausgelöst durch das Live-Rollout von 1.2.0 selbst (siehe Handbuch, "Zweite Härtungsrunde"):

• Keine rohen OPNsense-Fehlertexte mehr in 502-Antworten (Info-Leckage an read_only-Nutzer).
• Healthchecks für Backend/Frontend ergänzt; dabei einen echten Next.js- Bindungs-Bug gefunden und behoben (HOSTNAME=0.0.0.0).
• Nächtliches Backup der eigenen OPNexus-Datenbank (neuer postgres-backup-Service), plus Fix für zu kleines Postgres-/dev/shm.
• Log-Erfassungs-Einstellungen (Intervall/Aufbewahrung) erstmals über UI/API sicht- und editierbar; Default-Aufbewahrung 30→7 Tage.
• Realer Disk-Vorfall behoben: firewall_log_entries war bei den zwei echten Firewalls in 9 Tagen auf ~9,7GB angewachsen, hat zusammen mit Rebuilds zweimal kurz die Disk gefüllt — bereinigt, keine Datenverluste.

375 Backend-Tests grün, tsc --noEmit/next build sauber.

[1.2.0] "Harrier" — 2026-09-17

Sicherheits- und Stabilitäts-Härtung vor dem geplanten öffentlichen Release, aus einem vollständigen Audit (siehe Handbuch, "Sicherheits- und Stabilitäts-Härtung vor dem öffentlichen Release"):

• CORS-Default auf localhost/127.0.0.1 verengt, neue FRONTEND_ORIGIN- Variable für alle anderen Deployments.
• POSTGRES_PASSWORD ohne unsicheren Fallback — muss explizit gesetzt sein.
• Ports standardmäßig nur auf 127.0.0.1, steuerbar über neue BIND_ADDRESS-Variable statt manuellem Editieren von docker-compose.yml.
• TLS-/Reverse-Proxy-Betrieb dokumentiert (Caddy-Beispiel).
• Backend-Logging aktiviert (war zuvor komplett stumm) + Log-Rotation für alle Container.
• Neuer automatischer Schema-Patch-Mechanismus (app/schema_patches.py) ersetzt die bisherigen manuellen ALTER TABLE-Schritte bei jedem Start.
• Reproduzierbare Builds: Frontend-Lockfile committet (npm ci), Backend-Abhängigkeiten exakt gepinnt.

Live auf der Produktivinstanz ausgerollt und verifiziert, 371 Backend-Tests grün.

[1.1.0] "Goshawk" — 2026-09-17

Vier funktionale Lücken gegenüber DynFi Manager geschlossen (dem einzigen echten Software-Wettbewerber in der Nische zentrales OPNsense-Fleet- Management) — Multi-Tenancy/MSP-Betrieb bewusst ausgeklammert, Zielgruppe bleiben Privatleute/kleine Unternehmen mit eigener Firewall:

• Direct-View-Link: Ein-Klick-Button öffnet die native OPNsense-GUI eines Hosts in einem neuen Tab.
• Generische Dienst-Steuerung: Beliebigen von OPNsense gemeldeten Dienst direkt aus OPNexus starten/stoppen/neustarten.
• Resource-Monitoring: Kompakte 24h-Zeitverlaufs-Charts für CPU-Last, Speicher- und Plattenbelegung je Host, eigene minimale Inline-SVG-Sparkline-Komponente, live gegen die reale Flotte im Hintergrund alle 60s abgetastet.
• Geplante Wartung: Neustart/Update/Major-Upgrade auf einen zukünftigen Zeitpunkt statt sofort legen (einmalig, kein Recurring).

14 neue Backend-Tests (371 gesamt grün). Siehe Handbuch, "Direct-View-Link, Dienst-Steuerung, Resource-Monitoring, geplante Wartung".

[1.0.0] "Falcon" — 2026-09-17

Erstes Release unter dem neuen Versionsschema — markiert den aktuellen, bereits sehr ausgereiften Stand des Projekts (siehe Handbuch für die lange Vorgeschichte des Projekts). Fasst zwei zuvor unversionierte Arbeits-Batches zusammen, die mit diesem Release erstmals committet wurden:

• Fleet-Dashboard, neue UI-Bausteine, Konsistenz-Pass & Toast-Feedback (/dashboard als neue Startseite; Badge/Tabs/Table/EmptyState/ Toast-Primitives; CSS-Variablen-basierter Dark Mode für die Slate-Palette; Erfolgs-Toasts für praktisch alle schreibenden Aktionen inkl. aller Deploy-Push-Overlays). Siehe Handbuch, "Fleet-Dashboard, neue UI-Bausteine und Konsistenz-Pass".
• CARP/HA vertieft: Ereignis-Historie pro Cluster, Split-Brain-/ Kein-Master-Alarm, NAT-Drift-Erkennung (Port Forward/1:1/Outbound), optionaler Auto-Revert-Timer für den CARP-Wartungsmodus. Siehe Handbuch, "CARP/HA vertiefen".
• Versionierung & Update-System (dieses Release selbst): Semantic Versioning mit Raubvogel-Codenamen, CHANGELOG.md, Versionsanzeige an vier Stellen in der App (Login, Footer, /about, Einstellungen), Backend-FastAPI-App trägt dieselbe Version. Kleiner Nebenfund dabei behoben: Login leitete nach erfolgreicher Anmeldung noch auf /hosts weiter statt auf die seit dem Dashboard-Release neue Startseite /dashboard.

357 Backend-Tests grün, tsc --noEmit/next build sauber. Details, offene Punkte und Verifikationsstand: siehe docs/HANDBUCH.md.