5 Commits

Include renames

Author	SHA1	Message	Date
Johnathan Corgan	6c52b0e01e	Let the static test network float so concurrent CI runs cannot collide ... Two local CI runs on one host both asked docker for 172.20.0.0/24 and the second lost its whole static family to "Pool overlaps". Docker honours a fixed subnet request verbatim, so the only robust fix is to stop making one: fips-net now requests no subnet and docker assigns from its own pool, which cannot hand the same range to two runs. That means node addresses are not known before `up`, so peers address each other by container hostname instead. The generator emits node-<id>, or the topology's docker_host where the compose hostname differs — only the gateway profile, whose services are gw-*. External peers keep the address the topology gives them, since it is not ours to assign. The resolv.conf mount stays: dnsmasq is what forwards these names to docker's resolver and .fips to the daemon, so removing it would take out every .fips assertion. generated-configs is now per-run as well. A shared directory let two runs overwrite each other's node configs, which the subnet collision had been hiding by killing runs before that window opened. The generator, the compose bind mounts and env_file, the six scripts that read it, and teardown all follow FIPS_CI_NAME_SUFFIX; unset, every path renders as before. Teardown keeps the directory after a failed run, where it is the evidence of what the failing nodes were configured with. Three things this exposed that were wrong independently: admission-cap built its tcpdump patterns from the topology file's docker_ip literals. Floating the subnet makes those match nothing, which would have left its expect-zero "no Msg2 leaked" assertion passing because it could no longer see anything at all. It now reads addresses from the running containers. Restarting the denied peers together also made them swap addresses, so each peer's counts were really the pair's total; they are restarted one at a time now, and a check fails the suite outright if two denied peers ever share an address, because per-peer attribution is impossible once they do. Attribute lookups in the generator used a fixed ten-line window and read the next node's fields when a node omitted an attribute. An external node followed by an internal one was classified as internal, which under hostname peering would emit a name that resolves nowhere. Lookups are bounded to the node's own block; generated output is byte-identical for all eight topologies. The rekey outbound-only variant used to rewrite peer addresses to hostnames to set up its scenario. The generator now does that everywhere, so the rewrite matched nothing and was silently doing no work. It asserts the premise instead, and fails if a numeric address ever reappears. Verified by running three instances of this compose at once — tcp-chain plus two independent meshes — which drew 10.128.2/3/4.0/24 with no overlap while both meshes passed ping-test 20/20 over the real .fips path. tcp-chain is run by neither CI runner, so it was checked by hand: chain peer counts 1/2/1 and multi-hop .fips reachable both directions over TCP. gateway-lan still pins its own IPv4 and fd02:: ranges and is unchanged here, so the gateway profile is not yet concurrency-safe.	2026-07-23 02:05:56 +00:00
Johnathan Corgan	3ebb14eda4	Make the admission-cap final peer_count read tolerate a busy daemon ... The suite red-ed with an empty final peer_count while every substantive assertion passed: both denied peers showed inbound handshake attempts and zero outbound responses, which is the gate this suite exists to verify. Two pre-existing defects combined. The final count was sampled once, in the same second the load driver issues its last round of peer restarts, so the read can land on a daemon busy with those restarts and return nothing. And the fallback meant to cover that could never fire, because the shell applies it to the last stage of the pipeline, which succeeds on empty input - so an unanswered query was indistinguishable from a genuine zero, and reported as a cap violation. Poll the final read for a short window instead, and give the two cases distinct output. A real regression still fails, just after the retry window, since the loop exits early only on the expected value. Extract the read the two phases share rather than leaving them to drift.	2026-07-19 06:46:50 +00:00
Johnathan Corgan	e4a854f6b0	Stop concurrent local CI runs from clobbering each other's containers ... Two runs on one host destroyed each other's containers, producing mid-test "No such container" failures that look like real defects. The automated builder runs a full local CI on the same box every few minutes, so the machine is contended almost always and this has red-ed both a hand run and an automated gate. Two independent causes are fixed here. Container names were hardcoded, and docker names are global rather than scoped by compose project, so two runs collided on the same name; every name now takes an optional suffix that the harness sets from the run id. And the cleanup sweep matched a label shared by every run, so one run's teardown force-removed another's containers; resources now also carry a per-run label and the sweep can be narrowed to it. A third hazard turned up that was not in the original report: the sidecar suite passes explicit compose project names, which override the run-scoped project and put it outside the shared prefix entirely. Its project names, network, and derived container references are now scoped too. Both are default-off. With the suffix unset, names render exactly as they do today and a bare compose invocation is unchanged, which is what keeps the hosted CI and the documentation correct. A cleanup run with no run id still reaps everything, which is what a manual "clear the box" wants. The literal-name sweep was not sufficient: six scripts build container names dynamically from node labels, and two suites create their own containers outside compose. Those are handled at their construction sites. Verified: syntax check on all modified scripts; compose validation on every modified file with the suffix both set and unset; and a synthetic two-run reproduction that shows the old cleanup destroying a bystander run and the new one leaving it alone. Known gap: subnets are still hardcoded, so two concurrent full runs will still collide on address-pool overlap. That fix reaches into topology configs, chaos scenarios, diagrams and production source, so it is left for its own change rather than half-done here.	2026-07-19 06:41:25 +00:00
Johnathan Corgan	965de26239	testing: make ci-local.sh preemption-safe with per-run docker isolation ... A CI worker may preempt an in-flight ci-local.sh run (SIGTERM, then SIGKILL after a grace period) to restart on a newer commit. For that kill to be safe, the script must clean up after itself and never let a dying run collide with its restart. It previously had no signal handling, shared the default compose project name across runs, and tore down each suite only at the suite end. - Derive a per-run id (honoring FIPS_CI_RUN_ID, else short-sha+random) and namespace every docker resource to it: a fipsci_<run>_<suite> compose project per suite and per parallel chaos child, and per-run image tags (fips-test:<run>, fips-test-app:<run>) retagged to :latest only after both builds succeed so :latest never points at a half-built image. - Install a bounded, idempotent teardown trap on SIGTERM/SIGINT (+ EXIT): reap parallel chaos children, then force-remove this run's docker resources via the new ci-cleanup.sh, wrapped in timeout so a stuck down cannot wedge it. - Exit 143 (SIGTERM) / 130 (SIGINT), distinct from 0 (pass) / 1 (failed), so a preempting worker tells a cancelled run from a real failure. - Add ci-cleanup.sh (also ci-local.sh --reap): force-removes leftover CI resources by the com.corganlabs.fips-ci=1 label and the fipsci_ project prefix, robust to however a prior run died. - Label every per-suite docker resource so the label sweep reaps it after a SIGKILL regardless of network name: direct docker run/network resources, the sidecar compose services, and every per-suite compose network (acl-allowlist, boringtun, firewall, nat, static, both tor suites, and the chaos generator template). Parametrize the static/sidecar compose image refs so the per-run tags are honored. - Give each parallel chaos child a unique /24 from 10.30.x (a new --subnet override on the sim CLI, assigned per-child in ci-local.sh) so parallel children never collide on a shared docker subnet, and a chaos net can never span a fixed-subnet suite (sidecar/static in 172.20.x). 10.30.x sits outside docker's default-address-pool range, so an auto-assigned net cannot land on it either; node IPs derive from the subnet, so no scenario config changes.	2026-06-29 14:23:46 +00:00
Johnathan Corgan	d575c1f986	testing: add admission-cap integration suite for inbound silent-drop gate ... New integration scenario verifying the early-gate silent-drop behavior of the inbound max_peers admission check at sustained scale, using the existing 5-node mesh topology with one node's node.limits.max_peers lowered to 1. This forces 2 of the cap'd node's 3 configured peers into a sustained denied state, and asserts via tcpdump that no Msg2 responses go back to those denied peers across a 60s capture window. A background load-driver restarts the denied peer containers every 15s to reset their auto-reconnect exponential backoff (5s base / 300s cap), producing fresh Msg1 bursts each cycle. Without this loop the gate fires ~3-4 times per denied peer in a 60s window; with restarts the observed rate is 15 per denied peer (~30 total firings), high enough that any Msg2 leakage would be caught with strong statistical confidence. Local run on this branch: cap'd node-c converged to peer_count=1 with node-b admitted; nodes d and e sustained-retried as denied; tcpdump captured 30 inbound Msg1 (len 84) packets from the denied pair and 0 outbound Msg2 (len 104) packets, with final peer_count unchanged. Files: testing/static/scripts/admission-cap-test.sh — new test script with inject-config subcommand (sets node.limits.max_peers) and a 3-phase test driver (converge, capture-with-load, per-peer assert) testing/ci-local.sh — register admission-cap as a new suite category (ADMISSION_SUITES), wire run_admission_cap function, add to run_suite dispatch, list_suites, and the default integration sweep Together with the existing unit-level coverage in src/node/tests/unit.rs (handle_msg1_silent_drops_at_cap_for_new_peer with mock-transport Msg2 discriminator, and handle_msg1_admits_existing_peer_at_cap as the bypass regression guard), the gate's silent-drop behavior is now verified both at single-firing wire-observable resolution and at sustained multi-firing cross-process scale.	2026-05-26 20:34:42 +00:00