fail2ban: restart when the log declaration changes

The file that says where fail2ban logs was not in restart-on, so a change to it would sit on disk with the running service unaware of it -- the same shape as any other jail file this module already restarts for.
Merge pull request 'fail2ban declares where it logs, so the recidive jail has a file to read' (#132 ) from fix/fail2ban-declares-where-it-logs into main
2026-09-28 20:42:42 +02:00 · 2026-09-28 18:41:16 +00:00 · 2026-09-28 20:41:09 +02:00 · 2026-09-28 14:08:48 +00:00 · 2026-09-28 16:08:46 +02:00 · 2026-09-28 13:40:30 +00:00
3 changed files with 24 additions and 3 deletions
@@ -28,6 +28,13 @@
      "path": "/etc/fail2ban/action.d",
      "mode": "0755"
    },
+    {
+      "id": "fail2ban-local",
+      "type": "file",
+      "path": "/etc/fail2ban/fail2ban.local",
+      "mode": "0644",
+      "content": "[Definition]\n\n# Where fail2ban writes its own log, declared rather than assumed. The recidive jail reads\n# this file to ban whoever keeps coming back, and the logrotate file this module ships\n# rotates it -- but nothing told fail2ban to write there. Where the package default stands,\n# fail2ban logs to the journal, the recidive jail finds no log file, and the whole service\n# refuses to start, taking the sshd jail with it.\n#\n# In .local, not in fail2ban.conf: that file belongs to the package.\nlogtarget = /var/log/fail2ban.log\n"
+    },
    {
      "id": "jail-local",
      "type": "file",
@@ -70,6 +77,7 @@
      "state": "running",
      "boot": "enabled",
      "restart-on": [
+        "fail2ban-local",
        "jail-local",
        "jail-sshd",
        "jail-recidive",
@@ -49,7 +49,15 @@ interface Built {
  replay?: boolean;
 }

-await on("mesh-build-machine.built", async (event) => {
+/**
+ * What a build means for the graph, wherever it came from.
+ *
+ * Two emitters say the same thing and neither is a mistake: the build machine says it as it happens,
+ * and the control plane says what it already held when this module asks what it missed
+ * (novox/hq ADR 0134). A replay is marked as one in its body, so nothing acts on a module that moved
+ * months ago — see `replay` above.
+ */
+const placeTheBuild = async (event: { body: unknown }): Promise<void> => {
  const body = event.body as Built;
  if (!body.module || !body.commit) {
    // Said rather than dropped: a build that announced itself without saying what it built is a
@@ -91,7 +99,11 @@ await on("mesh-build-machine.built", async (event) => {
      because: next.because,
    });
  }
-});
+};
+
+// As it happens, and what the mesh already held when this module asked what it missed.
+await on("mesh-build-machine.built", placeTheBuild);
+await on("mesh-controller.built-before", placeTheBuild);

 // **And ask for what was built before this catalogue existed** (novox/hq 04-ISSUES/050).
 //
@@ -29,7 +29,8 @@
    "broker": "/var/lib/mesh/mesh-catalog/broker"
  },
  "consumes": [
-    "mesh-build-machine.built"
+    "mesh-build-machine.built",
+    "mesh-controller.built-before"
  ],
  "emits": [
    "registered",
Author	SHA1	Message	Date
jschoubben	c5af8635c8	fail2ban: restart when the log declaration changes The file that says where fail2ban logs was not in restart-on, so a change to it would sit on disk with the running service unaware of it -- the same shape as any other jail file this module already restarts for.	2026-09-28 20:42:42 +02:00
mesh-admin	87366c5f36	Merge pull request 'fail2ban declares where it logs, so the recidive jail has a file to read' (#132 ) from fix/fail2ban-declares-where-it-logs into main	2026-09-28 18:41:16 +00:00
jschoubben	f8ca36aacf	fail2ban: declare where it logs, so the recidive jail has a file to read The recidive jail reads /var/log/fail2ban.log and this module ships the logrotate file for it, but nothing ever told fail2ban to write there. Where the package default stands, fail2ban logs to the journal, the recidive jail finds no log file, and the whole service refuses to start -- taking the sshd jail with it. Two machines assigned this module today came up failed; the two where it worked had /etc/fail2ban/fail2ban.conf edited by hand, which a package upgrade would have undone. Declared in fail2ban.local, because fail2ban.conf belongs to the package.	2026-09-28 20:41:09 +02:00
mesh-admin	812355bf31	Merge pull request 'The catalogue hears what it missed' (#131 ) from feat/the-catalogue-hears-what-it-missed into main	2026-09-28 14:08:48 +00:00
jschoubben	016ddb2b3a	The catalogue hears what it missed It asks what it missed on every start and the answer never arrived: the control plane replayed each build it held as a module's event from a module called "control-plane", which does not exist, so its own account refused the publish and the graph kept the gap. The control plane now states those under the seat it holds (novox/hq ADR 0134, mesh-controller #129), so this consumes that too — one handler, because what a build means for the graph is the same whether the build machine says it as it happens or the mesh says what it already held.	2026-09-28 16:08:46 +02:00
mesh-admin	ea17bf46d2	Merge pull request 'The catalogue prepares its own schema instead of migrating at start' (#130 ) from feat/the-catalogue-prepares-its-own-schema into main	2026-09-28 13:40:30 +00:00