jschoubben
71bbc7dab0
A module's identity is the software it is (ADR 0040). Two were named after the job instead, and the job already had a name. firewall installs the nftables package and runs nftables.service. The seat it claims is the-packet-filter, which is correctly named for the role. Calling the module firewall named neither the software nor the provision, and promised that any firewall could sit there — the false genericity the naming rule forbids. registry runs Distribution, the OCI reference implementation, and provides artifact-store. So registry was a third name for a thing that already had two, which is how one word ended up meaning the module, the software and the concept in the same paragraph. The capability stays firewall, and correctly: a capability IS a functionality, so a node having one and fail2ban requiring one are both right. Only the module moves. Claude-Session: https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx
20 lines
802 B
TypeScript
20 lines
802 B
TypeScript
// firewall's tools — one, and the useful one: what is actually enforced. The rules are the mesh's,
|
|
// computed from every module's listens; this reads the live table so a declared scope can be checked
|
|
// against what the packet filter is really doing.
|
|
|
|
import { registerModuleTools, type ToolDefinition } from "@novox/mesh-sdk/tools";
|
|
import { FirewallClient } from "../client.js";
|
|
|
|
export function getFirewallTools(firewall: FirewallClient): ToolDefinition[] {
|
|
return [
|
|
{
|
|
name: "firewall_rules",
|
|
description: "The mesh's live nftables rules on this node — what is actually accepting and dropping.",
|
|
input: {},
|
|
run: async () => ({ ruleset: await firewall.ruleset() }),
|
|
},
|
|
];
|
|
}
|
|
|
|
registerModuleTools("firewall", () => getFirewallTools(FirewallClient.fromEnv()));
|