c4db0dc1e2bc6d17d1e501bccd1b54e767632006
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  2GT-RichandClaude Opus 5
|
273a0da737 |
fix(deploy): restore NetFlow to the published compose file, and generate it (v0.23.34-beta)
Closes #121. The Quick Deploy file was missing NETFLOW_BIND_PORT and the 2055/udp mapping, so the collector bound inside the container and nothing reached it. NetFlow did nothing, silently, with an empty traffic page and no error — for everyone following the path the README tells new users to take. The report was accurate and understated. docker-compose.ghcr.yml had drifted for seven weeks, and three closed issues had never reached it: * NETFLOW_BIND_PORT and the UDP port — as reported * all five POLLER_* tunables — #114, whose fix was "pass the tunables through" * the Redis memory ceiling and eviction policy — #116 * TZ on the postgres service, which nobody had noticed at all The middle one is the uncomfortable part. Four days ago #114 was closed by forwarding poller settings that were documented but inert, with a comment saying setting them "did precisely nothing". On Quick Deploy that remained true, because one compose file was fixed and the other was not — including the advice given to that reporter about which knob to turn. So patching the four gaps would have been treating the symptom. The two files describe the same system and differ only in where images come from; maintaining both by hand meant remembering every change twice, and the one forgotten was always the file no maintainer runs. docker-compose.ghcr.yml is now generated from docker-compose.yml by scripts/generate-ghcr-compose.mjs, which performs the two build-to-image swaps and nothing else. Substitution is textual rather than parse-and-reserialise so comments survive — the reasoning about Redis eviction is worth more than the two lines it explains. The file stays committed and browsable, because the README tells people to curl it directly. A --check mode runs as the first preflight gate and as its own CI job, both of which fail when the committed file does not match what the generator produces. Verified by deleting the NetFlow line and watching the guard reject it, with the reason and the fix in the failure message. Reported by @mamb1329, on their first issue. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
2GT-RichandClaude Opus 5
|
5071e1f512 |
chore(dev): seedable CAPsMAN fixture so managed-wireless paths can be tested (v0.23.8-beta)
Two bugs shipped in the last three releases because CAPsMAN code was written and
"verified" against a fleet that contains no CAPsMAN. Neither was reachable by unit
tests, because both lived in SQL: a join that could never match, and a WHERE clause
that filtered out every managed radio before the analysis ran. Both were found by
the reporter, in production, after release.
The fix is not another test of the pure functions — those were already right. It is
to stop the local environment from being unrepresentative.
scripts/seed-capsman-fixture.sql builds a deployment shaped like a real one:
- the controller is a ROUTER with no radios of its own, so anything keyed on
device_type = 'wireless_ap' misses it
- CAP interfaces carry NULL frequency, SSID and band, because the controller owns
the configuration — the exact condition that removed them from Channel Usage
- the controller mirrors every CAP interface locally, so a CAP's radio MAC
legitimately appears on two devices — the condition behind the misattribution
- channels exist only as "<freq>/<phy>/<control-positions>", never a plain number
- the radios are arranged to produce one partial overlap and one co-channel pair,
so interference classification has something real to get wrong
Running it against v0.23.7 confirms the fix shipped blind two commits ago actually
works: six managed radios now group under the controller, the controller appears in
the location selector, the standalone group holds only the genuinely standalone AP,
5680/ax/eCee/D resolves to 80 MHz, client counts come from the controller where the
CAP rows read zero, and the controller's mirror interfaces do not double-count.
Documented in docs/architecture.md, including the point that when a report arrives
with device output attached, that output is the most valuable thing in it and
belongs in the fixture.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
2GT-RichandClaude Opus 5
|
e10f7ba568 |
docs: split reference material into docs/, keeping the README a shop window (v0.23.4-beta)
Documentation only — no functional change.
The README was carrying two jobs for two different readers. Its Reference section was
the single largest block at 154 lines, and nobody deciding whether to try the project
reads an InfluxDB environment variable table — while the people who need it were
scrolling past the pitch to reach it.
Split along that seam: anything you would read before installing stays in the README,
anything you would read after installing moves to docs/.
README.md 430 lines sell, prove, install, feature overview
docs/change-guard.md 193 safety system, settings, guard states
docs/architecture.md 116 data stores, polling model, module layout
docs/capsman.md 84 role model, radio matching, current limits
docs/alerting.md 81 rules, channels, webhooks, maintenance windows
docs/api.md 77 scoped tokens, preflight, scripting
docs/configuration.md 76 environment, secrets, rotation, TLS
docs/sso-oidc.md 71 identity provider setup and behaviour
docs/README.md 20 index
In-repo rather than a documentation site, deliberately. A change to Change Guard's
semantics can edit its documentation in the same commit as the code — which, given how
often that behaviour has been refined recently, is the property that actually matters.
A static site generator can point at docs/ later without moving a file.
The Change Guard pitch stays on the front page: the problem framing, the verified
recovery timeline and the quoted prediction warning are what make someone care, and a
reference page is the wrong home for them.
Three sections are new rather than relocated, written because the split exposed the gaps:
- architecture.md did not exist. It now records why there are three data stores, the
polling cadences, and which modules are pure functions over a snapshot and why.
- Scoped API tokens shipped without usage documentation. api.md shows preflighting a
change from a script and reading the guard block afterwards.
- change-guard.md records why ip-on-bridge-port is informational rather than critical
on RouterOS 7 — reasoning that previously existed only in a commit message.
Every internal anchor and cross-file link verified to resolve, including anchors into
other documents. No content dropped, checked by keyword comparison against the previous
single file.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|