Zum Inhalt

Was ist neu in v1.17.3

Veröffentlicht am 11. September 2026.

Schwerpunkt sind die HAProxy-Rückwege auf Installationen, deren HAProxy ein nur für root beschreibbares conf.d lädt: dicom-router-haproxy-sync hat dafür den neuen Modus staged. Dazu kleinere Korrekturen und Aufräumarbeiten an Meldungen, Startskript und Konfigurationsbeispiel.

Vor dem Update

bin/start.sh prüft mehr — und warnt nur

Neben den Rechten von config/dicom-router.env warnt das Startskript jetzt auch, wenn die Datei weder dem Router-User noch root gehört, wenn config/ gruppen- oder weltschreibbar ist oder einem anderen Benutzer gehört, und wenn config/logback.xml über den Eigentümer hinaus schreibbar ist oder einem anderen Benutzer gehört. Jede Warnung nennt das passende chmod/chown. Der Start wird nie blockiert. Die Sollzustände stehen in der Deployment-Dokumentation.

dicom-router.env: nur noch KEY=VALUE

Zeilen, die nicht die Form KEY=VALUE haben — etwa export KEY=VALUE, KEY = VALUE oder ein Schlüssel ohne = —, ignoriert bin/start.sh jetzt mit einer Warnung, die die Zeilennummer nennt (nie den Inhalt, die Datei enthält JDBC_PASSWORD). Bisher wurde ein Schlüssel ohne = mit seinem eigenen Namen als Wert exportiert. Ein Schlüssel mit führender Ziffer wird ebenso übersprungen — bisher brach das Einlesen an einer solchen Zeile ab, und die Zeilen danach fehlten beim manuellen Start ohne Hinweis. Erscheint nach dem Update eine solche Warnung, die genannte Zeile prüfen. systemd liest das Env-File mit einem eigenen, toleranteren Parser; eine hier gemeldete Zeile kann unter der Unit trotzdem wirken.

Meldungen ohne Issue-Nummern

Log- und Validierungsmeldungen enthalten keine internen Issue-Nummern mehr. Die Abbruchmeldungen der P-DATA-Assembly nennen stattdessen den zuständigen Config-Schlüssel (router.max-pending-assemblies, router.assembly-idle-timeout, router.max-object-bytes), die Warnungen zum Management-Token verweisen auf die Management-Dokumentation. Ein logbasiertes Alerting, das auf den alten Wortlaut passte (etwa auf den Text in Klammern), ist anzupassen.

dicom-router-haproxy-sync ohne Umstellung unverändert

Ohne Konfiguration des neuen Modus verhält sich das Skript genau wie bisher (Modus direct).

HAProxy-Rückwege

Modus staged

Der bisherige Modus setzt voraus, dass der ssh-Benutzer ins Ladeverzeichnis schreiben darf, und prüft die neue Datei nur zusammen mit /etc/haproxy/haproxy.cfg. Lädt die HAProxy-Unit ein Verzeichnis, weitere Dateien oder Variablen aus einem env-file, ist das nicht der echte Ladekontext.

Im Modus staged (DICOM_ROUTER_HAPROXY_MODE=staged) lädt das Skript die Datei ausserhalb des Ladeverzeichnisses hoch und erledigt den Rest in einem einzigen privilegierten Schritt per sudo:

  • Preflight gegen genau das, was die Unit lädt: das env-file der Unit, alle Nachbardateien in conf.d, die alte Fassung der Zieldatei durch die neue ersetzt.
  • Eigene Prüfung auf doppelte Listener: zwei Listener auf derselben Adresse erkennt haproxy -c nicht; das Skript prüft das vorher selbst — über alle Dateien des Ladepfads, mit oder ohne Anführungszeichen um Teile der Adresse, IPv6-Hosts mit oder ohne eckige Klammern.
  • Installation nur bei geändertem Inhalt, atomar als root:root 0644, danach der Reload. Das Ladeverzeichnis muss root (oder dem ausführenden Benutzer) gehören und darf nicht gruppen- oder weltschreibbar sein; sonst lehnt der Apply-Schritt ab und lässt das Ziel unangetastet.

Auf dem HAProxy-Host muss nichts installiert werden; das Hilfsskript wird per ssh mitgeschickt. Als Voraussetzung braucht sudo -n entweder eine NOPASSWD-Regel oder Defaults noninteractive_auth — Varianten und Beispiele stehen in der Deployment-Dokumentation. Der Umfang dieser Regel ist root ohne Einschränkung (sudo -n sh -s): der ssh-Schlüssel des Router-Benutzers wird damit auf jedem HAProxy-Host root-äquivalent — anders als im bisherigen Modus, wo sich sudo auf das Reload-Kommando begrenzen lässt.

Einstellungen in config/haproxy-sync.env

Modus, Ladepfad, env-file, Eskalation und Reload-Kommando stehen jetzt in einer eigenen Datei config/haproxy-sync.env (Vorlage: share/haproxy-sync.env.example). Ein Betreiber oder ein Deployment-Werkzeug muss die Umgebungsvariablen damit nicht mehr bei jedem Aufruf mitgeben; eine gesetzte Umgebungsvariable hat weiterhin Vorrang.

Genauere Rollout-Hinweise und Warnung bei der Validierung

Wurde eine Destination umbenannt, während ihr return-port ausserhalb der port-range liegt, erkennen die Rollout-Hinweise den Rückweg jetzt an der Bind-Adresse wieder. Das Skript rät also nicht mehr dazu, einen weiterhin genutzten Rückweg zu entfernen.

--validate-config warnt jetzt, wenn ein return-port ausserhalb der port-range liegt. Solche Destinations werden nicht generiert und brauchen einen handgepflegten listen-Block — bisher fiel ein Tippfehler im Port erst auf, wenn der Rückweg fehlte. Die Warnung ändert den Exit-Code nicht. Details in der Management-Dokumentation.

Weitere Korrekturen

  • Datenbank-Fehlermeldungen im Audit-Status zeigen auch auf H2 den verletzenden Wert nicht mehr an.
  • Ein Audit-Ereignis, das beim Herunterfahren nach dem letzten Leeren der Warteschlange eintrifft, wird in audit-dropped gezählt, statt still verloren zu gehen.
  • Das Konfigurationsbeispiel verweist nicht mehr auf Dokumentation, die nicht mit ausgeliefert wird.