Warnzentrale

Warnzentrale

Aktueller Stand 16.10.2026

Verbindlich: main@8fb581b730f7a3833566c4bbb7c87875ad921e69; veröffentlicht bleibt v1.9.0. PR #74–#97 sind integriert. Deployment/Discovery, Imagebuilder, Pi-VPN und Syslog sind auf main, nicht mehr nur historische Vorschau. 26 reguläre Rollen einschließlich Deployment-VM; Provisioning ist optional zusätzlich.

Betreiberbestätigt: KDE-Boot, Rufe, SDS, Aufnahme/RF-Wiedergabe und WLAN am 13.10.; 28/28 Discovery-Agenten aktualisiert und keine ungeklärten Remote-Aufträge mehr am 15.10. Ein aktueller Backend-Gesamtrollout, NAS-Entlastung, SIP/Telegram, VPN-Wechsel und Dauerlauf bleiben separat offen. Vier alte Git-/Timeoutfehler bleiben Fehler.

Gesamtroadmap · Upstream-Vergleich · Roadmap und Releases. NETCORE-IAM-01 ist weiterhin Planung; AD-SSO-Pilot und Gruppenmapping sind konkretisiert, Produkt-/Betriebsentscheidung und Umsetzung offen.

Aktuelle Installation und Betrieb. Der frühere Dreier-Auditbefund ist keine aktuelle Fehlerliste: Der Quellen-/Konfigurationscheck vom 16.10. besteht mit 26 Rollen, aktuellem Generator und erfolgreichem Full-System-Audit. Versand und fachliche Zustellung müssen unabhängig von HTTP/CI abgenommen werden.

Historischer Seitenstand bis 07.10.2026

Die folgende frühere Fassung bleibt als datierte Historie erhalten. Frühere Dienstzahlen, Featurebranch-Aussagen, offene Tests und Prioritäten sind keine aktuelle Statusaussage; heutige Verfahren stehen oben beziehungsweise in den verlinkten kanonischen Docs.

Warnzentrale

Aktueller Quellenstand 07.10.2026: main 990bffb2; Release weiterhin v1.9.0. PR #59 mit Hell/Dunkel ist integriert, PR #60 ergänzt Projektarchive. Nur main ist als Branch vorhanden. Deployment/Discovery, Imagebuilder, Pi-VPN und neuere Syslog-Pipeline bleiben ausschließlich am historischen Featurecommit bbf0397 vorhanden. Keine neue Live-Abnahme. Roadmap und Releases · Upstream-Vergleich

Oberflächen auf main seit PR #59

26 TBS-Ansichten und 29 Dienst-WebUIs verwenden das gemeinsame Design mit Hell/Dunkel. Die Basisstation behält zusätzlich Blau. Die Auswahl gilt pro Browser-Origin; Host-/Portwechsel teilen sie nicht. Rust-Binaries sowie Python-/HTML-Bundles betten die Assets ein, ein Node-Dienst ist nicht nötig. Design aktiviert kein zentrales IAM. Roadmap und Releases

Nach dem Update Anmeldung, Theme nach Neuladen, Formulare/Tabellen/Dialoge, schmale Darstellung und vorhandene Fachaktionen prüfen. RF-Lücken bleiben fehlende Daten; DSP-Pegel ist keine kalibrierte Antennenleistung. Nachbarzellenanzeige ist keine Handovermessung. Bei alten Assets Browser hart neu laden.

Stand v1.9.0, main 086a81fa · Projektstand · Control-Room · SDS-and-U-STATUS

Die Warnzentrale alert-service liest NINA-/BBK-Warnungen einschließlich der Quelle KATWARN und verwaltet eigene Meldungen. Anhand aktueller Teilnehmer- und GPS-Lage erzeugt sie individuelle SDS an erreichbare Geräte im Warngebiet. Das ist keine gesonderte KATWARN-Partneranbindung und kein Nachweis einer behördlich freigegebenen Warninfrastruktur.

Dienst und Voraussetzungen

Merkmal	Aktuelle Vorlage
Beispieladresse	10.0.20.34:8310
Runtime	Python 3.11 oder neuer, Standardbibliothek
Unit und Benutzer	netcore-alert-service.service / netcore-alert
Konfiguration	/etc/netcore/alert-service.toml
Token-Umgebung	/etc/netcore/alert-service.env, NETCORE_ALERT_TOKEN
Persistenz	/var/lib/netcore-alert-service/alerts.sqlite3
Abhängigkeiten	Control Room und SDS Router
Ausgangszustand	delivery.enabled=false; allow_unauthenticated=false

Die Fach-API verlangt ein Bearer-Token. Health bleibt für Proben erreichbar. Token lokal erzeugen und weder in Wiki noch Git übernehmen. Die direkten HTTP-Ports bleiben im geschützten Managementnetz. Diese Authentisierung ist eine Ausnahme gegenüber vielen offenen Labordiensten.

Datenweg und Freigabe

Warnquelle/eigene Meldung → Warnzentrale → Teilnehmer/GPS aus Control Room → SDS Router → Node Gateway → aktuelle TBS → Gerät.

Ein Ziel benötigt Registrierung, frische GPS-Daten und eine verbundene, aktuelle TBS. Die Vorlage erlaubt GPS-Daten bis 3600 Sekunden und TBS-Lage bis 120 Sekunden Alter. Ohne diese Voraussetzungen wird ein Gerät mit Begründung ausgeschlossen.

1. SDS Router auf v1.9.0 aktualisieren und ready/status prüfen.
2. Control Room aktualisieren und den lesenden Gateway-Kanal einrichten.
3. Warn-LXC installieren, Token, URLs und DNS prüfen.
4. Betroffene TBS aktualisieren: CMCE muss DeliverSds und SendStatus verarbeiten.
5. Neue Anmeldung/GPS-Meldung beobachten; der Gateway liefert beim Erstverbinden keinen vollständigen alten GPS-Snapshot.
6. Mit deaktiviertem Versand prüfen; danach kontrollierten Funkversuch durchführen und Versand bewusst aktivieren.

Eine bereits funktionierende Warnanlage braucht für reine Warn-WebUI-Erweiterungen nur das Warn-LXC-Update. SDS-Router-, Call-Control- und TBS-Reparaturen entsprechend dem jeweiligen Fehlerbild getrennt ausrollen. Für den Warnpfad ist kein zusätzlicher Node-Gateway-Funktionspatch nötig.

Vollständige Installations- und Updatebefehle: KATWARN/NINA-Runbook.

Control-Room-Telemetrie

Der neue Block in der Control-Room-TOML lautet in der Vorlage:

[node_gateway]
enabled = false
url = "ws://node-gateway:8080/ws/backend"
reconnect_secs = 3
timeout_secs = 10
stale_after_secs = 30

Adresse auf denselben Gateway wie beim SDS Router setzen und erst dann aktivieren. Dieser lesende Backend-Kanal ist vom TBS-Kanal /ws/node zu unterscheiden. Den tatsächlichen Config-Pfad der Unit prüfen: Das Inventory-Ziel /etc/netcore/control-room.toml und die eingecheckte Unit mit /etc/netcore-control-room/control-room.toml weichen voneinander ab.

Quellen und eigene Meldungen

Die Vorlage ruft https://warnung.bund.de/api31 mit mowas, katwarn, biwapp, dwd und lhp ab. Abrufintervall 60 Sekunden, maximale Veraltung 300 Sekunden. NetCore-Lage wird alle 5 Sekunden abgefragt. Standardwerte der Zustellung: 300 Sekunden TTL und 120 Zeichen Text.

Eigene Meldungen enthalten Titel, Text, Schweregrad, Mittelpunkt, Radius von 50 Metern bis 200 Kilometern und eine Laufzeit von höchstens 366 Tagen. Die WebUI bietet Suche sowie alle, aktive und beendete Meldungen. Löschen beendet künftige Aussendungen und erhält die Historie. Bereits gesendete SDS können nicht zurückgerufen werden; es entsteht keine zusätzliche Entwarnungs-SDS.

Zustellsemantik und Geräteanzeige

Warnung plus ISSI werden persistent reserviert. Der Router verwendet idempotency_key, at_most_once=true und eine absolute Ablaufzeit. Bei unklarer Übergabe wird nicht blind wiederholt. Damit hat Duplikatvermeidung Vorrang vor einem erneuten Versuch.

accepted bedeutet: Die TBS hat den Auftrag zum Senden angenommen. Es ist keine Empfangs- oder Lesebestätigung des Funkgeräts. Die allgemeine Store-and-forward-Politik anderer SDS wird dadurch nicht pauschal ersetzt.

Die kompakte Liste devices enthält nutzbare Geräte; device_overview zeigt auch ausgeschlossene Geräte mit Grund. area_status unterscheidet affected, outside, no_alerts und unknown. „Prüfung nötig“ kann zusätzlich Versandprobleme enthalten und ist nicht immer gleich dem Blockiert-Zähler.

Tokenpflichtige API	Zweck
GET /api/v1/status	Gesamtzustand und Geräteübersicht
GET /api/v1/alerts	Meldungen lesen
POST /api/v1/alerts	Eigene Meldung anlegen
DELETE /api/v1/alerts/{id}	Künftigen Versand beenden
GET /api/v1/devices	Geräteinformationen
GET /api/v1/deliveries	Versandhistorie

Sicherung und Fehlersuche

Warn-SQLite, SDS-Router-Persistenz, Konfiguration und Releasekennung gemeinsam sichern. Für SQLite ein konsistentes Backupverfahren verwenden oder den Dienst für eine Kopie geordnet anhalten. Die Datenbanken bei Reparatur/Rollback nicht löschen: Sonst könnten behandelte Warnungen erneut versendet werden. Datenschema und älteres Binary müssen zusammenpassen.

• Gerät fehlt: Registrierung, GPS-Alter, TBS-Verbindung und device_overview prüfen.
• HTTP 401: Token und Authorization-Header prüfen.
• Keine GPS-Lage: Gateway-Kanal aktivieren und neue GPS-Meldung verfolgen.
• live=200, aber ready/status brechen ab: SDS-Router-Journal auf index out of bounds und PoisonError prüfen; Kurzstatus-Reparatur. Neustart allein behebt die alte Ursache nicht.
• Langsame Readiness/Fallback: SDS-/Call-Control-Persistenzreparatur.

Der aktuelle Full-System-Audit erwartet noch 24 Dienste und die bei alert-service fehlenden /metrics- und /openapi.json-Marker. Zusammen mit der Gateway-Hostabweichung bleibt der Audit rot. Das ist getrennt von der erfolgreichen 25-Dienst-Inventory-Validierung zu behandeln. Projektstand · Backup-and-Fallback