dnsmasq: pass the DNSSEC bit down from the validating upstreams

A program that checks its resolver validates — Mailu's admin does, at start — could not use the mesh's resolver, and the one it ships instead knows no mesh name (novox/hq issue 171). proxy-dnssec copies the AD bit from 1.1.1.1 and 8.8.8.8, both of which validate.
Merge pull request 'mailu: admin asks the machine's resolver, not Mailu's own' (#178 ) from fix/mailu-admin-asks-the-machines-resolver into main
2026-09-30 15:17:34 +02:00 · 2026-09-30 13:13:29 +00:00 · 2026-09-30 15:13:25 +02:00 · 2026-09-30 12:31:30 +00:00 · 2026-09-30 14:31:26 +02:00 · 2026-09-30 12:22:10 +00:00
4 changed files with 25 additions and 22 deletions
@@ -120,7 +120,7 @@
      "port": 7080,
      "protocol": "tcp",
      "from": "mesh",
-      "why": "the web front over http; only the ACME HTTP-01 passthrough is routed here \u2014 everything else 301s to https and would loop a proxy"
+      "why": "the web front over http; only the ACME HTTP-01 passthrough is routed here — everything else 301s to https and would loop a proxy"
    },
    {
      "name": "web-tls",
@@ -315,10 +315,7 @@
        "${dir:data-data}:/data",
        "${dir:data-dkim}:/dkim"
      ],
-      "secrets-in-environment": "mailu-admin honours SECRET_KEY_FILE, DB_PW_FILE and API_TOKEN_FILE (configuration.py) but INITIAL_ADMIN_PW is env-only (start.py); the remaining containers' need for SECRET_KEY is unverified",
-      "dns": [
-        "192.168.203.254"
-      ]
+      "secrets-in-environment": "mailu-admin honours SECRET_KEY_FILE, DB_PW_FILE and API_TOKEN_FILE (configuration.py) but INITIAL_ADMIN_PW is env-only (start.py); the remaining containers' need for SECRET_KEY is unverified"
    },
    {
      "id": "imap",
@@ -28,15 +28,10 @@
      "path": "/var/lib/mesh/ombi",
      "mode": "0700"
    },
-    {
-      "id": "state",
-      "type": "directory",
-      "mode": "0700",
-      "place": "."
-    },
    {
      "id": "config",
      "type": "directory",
+      "path": "/services/ombi/config",
      "mode": "0700",
      "owner": "1000:1000"
    },
@@ -44,7 +39,7 @@
      "id": "server",
      "type": "container",
      "name": "ombi",
-      "image": "lscr.io/linuxserver/ombi@sha256:22d6ebadbaaa728571353e74dc2173719e0fb02d4eaec551a7e9d2ee99ef68ac",
+      "image": "lscr.io/linuxserver/ombi@sha256:a6f76ac521ba01eee2e9f0c23a3fed22e56630d97a04d5eeaeaa36c1e681640d",
      "env": {
        "PUID": "1000",
        "PGID": "1000",
@@ -54,7 +49,7 @@
        "3579"
      ],
      "volumes": [
-        "${dir:config}:/config"
+        "/services/ombi/config:/config"
      ]
    },
    {
@@ -73,13 +68,15 @@
      "volumes": [
        "/var/lib/mesh/ombi/broker:/run/secrets/broker:ro",
        "/var/lib/mesh/ombi/api-key:/run/secrets/api-key:ro",
-        "/var/lib/mesh/ombi/config.json:/run/config/config.json:ro"
+        "/var/lib/mesh/ombi/config.json:/run/config/config.json:ro",
+        "/services/ombi/config:/var/lib/ombi/config:ro"
      ],
      "env": {
        "MESH_BROKER_FILE": "/run/secrets/broker",
-        "MESH_OMBI_URL": "http://127.0.0.1:${port:3579}",
+        "MESH_OMBI_URL": "http://127.0.0.1:3579",
        "MESH_OMBI_API_KEY_FILE": "/run/secrets/api-key",
-        "MESH_OMBI_CONFIG_FILE": "/run/config/config.json"
+        "MESH_OMBI_CONFIG_FILE": "/run/config/config.json",
+        "MESH_OMBI_CONFIG_DIR": "/var/lib/ombi/config"
      },
      "restart-on": [
        "runtime-config"
@@ -97,7 +94,7 @@
    }
  },
  "binds": {
-    "route": "${dir:state}/route.json"
+    "route": "/var/lib/mesh/ombi/route.json"
  },
  "build": {
    "on": [
@@ -105,7 +105,7 @@
        "/var/lib/postgres/superuser.secret:/run/secrets/superuser:ro"
      ],
      "env": {
-        "MESH_PROVISION_POSTGRES": "postgres://postgres@127.0.0.1:5432/postgres?sslmode=disable",
+        "MESH_PROVISION_POSTGRES": "postgres://postgres@127.0.0.1:${port:5432}/postgres?sslmode=disable",
        "MESH_PROVISION_POSTGRES_PORT": "${seat:mesh-store:5432}",
        "MESH_PROVISION_PASSWORD_FILE": "/run/secrets/superuser",
        "MESH_BROKER_FILE": "/run/secrets/broker",
Author	SHA1	Message	Date
jschoubben	9523105df4	dnsmasq: pass the DNSSEC bit down from the validating upstreams A program that checks its resolver validates — Mailu's admin does, at start — could not use the mesh's resolver, and the one it ships instead knows no mesh name (novox/hq issue 171). proxy-dnssec copies the AD bit from 1.1.1.1 and 8.8.8.8, both of which validate.	2026-09-30 15:17:34 +02:00
jschoubben	4449f44cf1	Merge pull request 'mailu: admin asks the machine's resolver, not Mailu's own' (#178 ) from fix/mailu-admin-asks-the-machines-resolver into main	2026-09-30 13:13:29 +00:00
jschoubben	47f6e7d78b	mailu: admin asks the machine's resolver, not Mailu's own admin is the one container here that reaches something by a mesh name: the database, bound in database.env. A mesh name is answered by the machine's resolver, which the runtime hands every container that does not name its own (novox/hq ADR 0148); Mailu's unbound knows no mesh name, and since the mesh stopped copying names into containers admin could not find its database. The others keep unbound — rspamd needs a validating resolver for DNSBL lookups and asks for no mesh name.	2026-09-30 15:13:25 +02:00
jschoubben	7ab522ba31	Merge pull request 'dnsmasq: answer a container's query, which arrives on the runtime's bridge' (#176 ) from fix/110-the-resolver-answers-a-container into main	2026-09-30 12:31:30 +00:00
jschoubben	204bfbbaf9	dnsmasq: answer a container's query, which arrives on the runtime's bridge dnsmasq admits a query by the interface it arrives on when told interface=, and by the address it is sent to when told listen-address=. A container's query is sent to the machine's private address but arrives on docker0, so interface=mesh0 dropped it silently on every machine (novox/hq issue 110). Name the address, not the interface.	2026-09-30 14:31:26 +02:00
jschoubben	e0c09f46b6	Merge pull request 'dnsmasq: the runtime is reloaded when its dns file changes, and may then be restarted safely' (#175 ) from fix/110-the-runtime-reads-its-dns into main	2026-09-30 12:22:10 +00:00
jschoubben	e0faf012be	dnsmasq: the runtime is reloaded when its dns file changes, and may then be restarted safely novox/hq 04-ISSUES/110. The module writes the runtime's `dns` key and deliberately ordered no restart, because a restart stops every container. It also ordered no reload, and the key holds only for containers created after the runtime next starts. On two of four machines the runtime predated the file — one since August — so every container there was handed a public resolver and no mesh name resolved, while everything read as fine. The third machine works only because its runtime happened to restart later. The file now also sets live-restore, which the runtime reads on a reload, and the module declares the runtime reloaded when the file changes (ADR 0102: reload, don't restart). A reload still does not make `dns` take effect; what it does is make the one restart that key needs keep every container running. That restart stays the operator's, once per machine, and is harmless from the second time on. The mesh restarts nothing here. Undeclared, the runtime's unit goes back to the state it was found in (ADR 0118).	2026-09-30 14:22:03 +02:00
mesh-admin	1b19c79d63	Merge pull request 'postgres: the provisioner dials the port the mesh gave the store' (#174 ) from fix/postgres-provisioner-dials-the-port-it-was-given into main	2026-09-30 12:06:25 +00:00
jschoubben	4ec2ae1f7f	postgres: the provisioner dials the port the mesh gave the store MESH_PROVISION_POSTGRES named 127.0.0.1:5432 literally; the seat twin (${seat:mesh-store:5432}) corrected it only on the machine holding the mesh-store seat. On any other machine — ace, where the module provides postgres-database without the seat — the twin is empty and the sidecar would have dialled whatever else holds 5432 (HAL's postgres). ${port:5432} is the machine port on every node; on novox the twin still says the same 6852, so nothing moves there.	2026-09-30 14:01:53 +02:00