Skip to content

What's new in v1.17.3

Released on 11 September 2026.

The focus is the HAProxy return paths on installations whose HAProxy loads a conf.d that only root may write to: dicom-router-haproxy-sync gains the new staged mode for this. On top of that, smaller fixes and cleanups in messages, the start script and the configuration example.

Before the update

bin/start.sh checks more — and only warns

Besides the permissions of config/dicom-router.env, the start script now also warns when the file belongs neither to the router user nor to root, when config/ is group- or world-writable or belongs to another user, and when config/logback.xml is writable beyond its owner or belongs to another user. Every warning names the matching chmod/chown. The start is never blocked. The intended state is described in the deployment documentation.

dicom-router.env: KEY=VALUE only

Lines that are not of the form KEY=VALUE — say export KEY=VALUE, KEY = VALUE or a key without = — are now ignored by bin/start.sh with a warning that names the line number (never the content, the file holds JDBC_PASSWORD). Previously a key without = was exported with its own name as the value. A key starting with a digit is skipped the same way — previously reading stopped at such a line and the lines after it were missing from a manual start without any hint. If such a warning appears after the update, check the line it names. systemd reads the env file with its own, more lenient parser; a line reported here can still take effect under the unit.

Messages without issue numbers

Log and validation messages no longer contain internal issue numbers. The abort messages of the P-DATA assembly name the responsible config key instead (router.max-pending-assemblies, router.assembly-idle-timeout, router.max-object-bytes), and the management-token warnings point to the management documentation. Log-based alerting that matched the old wording (such as the text in parentheses) needs adjusting.

dicom-router-haproxy-sync unchanged unless reconfigured

Unless the new mode is configured, the script behaves exactly as before (mode direct).

HAProxy return paths

staged mode

The existing mode requires the ssh user to be able to write to the load directory, and it checks the new file only together with /etc/haproxy/haproxy.cfg. If the HAProxy unit loads a directory, further files or variables from an env file, that is not the real load context.

In staged mode (DICOM_ROUTER_HAPROXY_MODE=staged) the script uploads the file outside the load directory and does the rest in a single privileged step via sudo:

  • Preflight against exactly what the unit loads: the unit's env file, all neighbouring files in conf.d, with the old version of the target file replaced by the new one.
  • Own check for duplicate listeners: haproxy -c does not detect two listeners on the same address; the script checks for this itself beforehand — across every file of the load path, with or without quotes around parts of the address, IPv6 hosts with or without brackets.
  • Installation only when the content changed, atomically as root:root 0644, followed by the reload. The load directory has to be owned by root (or the executing user) and must not be group- or world-writable; otherwise the apply step refuses and leaves the target untouched.

Nothing needs to be installed on the HAProxy host; the helper script is sent along over ssh. As a prerequisite, sudo -n needs either a NOPASSWD rule or Defaults noninteractive_auth — variants and examples are in the deployment documentation. The scope of that rule is unrestricted root (sudo -n sh -s): the router user's ssh key thereby becomes root-equivalent on every HAProxy host — unlike the existing mode, where sudo can be limited to the reload command.

Settings in config/haproxy-sync.env

Mode, load path, env file, escalation and reload command now live in a dedicated file config/haproxy-sync.env (template: share/haproxy-sync.env.example). An operator or a deployment tool therefore no longer has to pass the environment variables on every call; an environment variable that is set still takes precedence.

More accurate rollout hints and a validation warning

If a destination was renamed while its return-port lies outside the port-range, the rollout hints now recognise the return path by its bind address. The script therefore no longer advises removing a return path that is still in use.

--validate-config now warns when a return-port lies outside the port-range. Such destinations are not rendered and need a hand-maintained listen block — previously a typo in the port only showed up once the return path was missing. The warning does not change the exit code. Details in the management documentation.

Further fixes

  • Database error messages in the audit status no longer reveal the offending value on H2 either.
  • An audit event that arrives during shutdown after the queue was drained for the last time is counted in audit-dropped instead of being lost silently.
  • The configuration example no longer points to documentation that is not shipped.