#864 — Docker no longer exposes the sensing API/stream unauthenticated:
- Add `require_ws_token` middleware gating `/ws/*` (sensing + introspection)
with the API token via `?token=` (browser) or `Authorization: Bearer`
(programmatic). Previously /ws/sensing was ungated even with a token set.
- docker-entrypoint.sh now fails closed: auto-generates a strong
RUVIEW_API_TOKEN when none is supplied and prints it; explicit
RUVIEW_ALLOW_UNAUTHENTICATED=1 restores the open LAN posture.
- compose/Dockerfile wire the env vars; startup logs + CI smoke test updated
to assert secure-by-default (401 with no token) and the opt-out path.
- 7 new bearer_auth unit tests (15 total pass).
#866 — CSI callbacks were starving (~3 in 70s, 0pps) under the MGMT-only
promiscuous filter:
- The documented "10 Hz probe injection" never existed — implement it for
real (csi_inject_probe_request + 10 Hz timer). Validated on ESP32-C6 (COM9):
probe TX succeeds at 10 Hz, but management-frame CSI stays sparse.
- Re-admit DATA frames (MGMT+DATA) now that the original wDev_ProcessFiq
SPI-cache crash is mitigated by WiFi RX/TX IRAM opts + the existing 50 Hz
rate gate. Kconfig CSI_PROMISC_MGMT_ONLY falls back if needed.
- Hardware-validated on COM9: yield 0 -> ~9pps avg (peak 19), presence/motion
sensing restored, 0 panics over 35s.
Co-Authored-By: claude-flow <ruv@ruv.net>
The HOMECORE native Rust port of Home Assistant landed in v0.10.0
(PR #800). The published Docker image now ships its binary alongside
sensing-server and cog-ha-matter so a single `docker run` brings up
the full RuView + HA-wire-compatible stack.
Dockerfile.rust:
- cargo build --release -p homecore-server in the build stage
- strip the new binary
- copy /app/homecore-server in the runtime stage
- sanity-check: image build now fails if /app/homecore-server isn't
executable (same guard pattern that already covers sensing-server
and cog-ha-matter)
- EXPOSE 8123 (HA-compat REST + WebSocket port — homecore-api
binds 0.0.0.0:8123 by default per its --bind CLI flag)
docker-entrypoint.sh:
- new dispatch keyword: `homecore` or `homecore-server`
Usage: docker run --network host ruvnet/wifi-densepose:latest homecore
Defaults --bind to 0.0.0.0:8123 (overridable via HOMECORE_BIND env)
The existing two dispatch paths (no arg → sensing-server, `cog-ha-matter`
→ HA + Matter cog) keep working unchanged. Three-binary image, one
entrypoint, operator picks the role at run time.
Triggers a workflow rebuild on push to main per the docker workflow's
path filter; the multi-arch (amd64 + arm64) image will be published
to Docker Hub as `ruvnet/wifi-densepose:latest` after CI green.
Refs ADRs 126-134, v0.10.0 release.
Co-Authored-By: claude-flow <ruv@ruv.net>
Three changes:
1. Dockerfile.rust now builds sensing-server with `--features mqtt`
(ADR-115 HA-DISCO publisher) and also builds + ships the
cog-ha-matter binary (ADR-116 Home Assistant + Matter cog with
mDNS, embedded broker, RuVector-backed thresholds, Ed25519 witness).
Adds EXPOSE 1883 for the embedded MQTT broker.
2. docker-entrypoint.sh routes `docker run <image> cog-ha-matter ...`
(or `ha-matter`) to /app/cog-ha-matter, defaulting --sensing-url to
http://127.0.0.1:3000 so a docker-compose deployment works out of
the box. The default entrypoint (no first arg) still launches
sensing-server unchanged.
3. Workflow path filter now also fires on changes to
v2/crates/wifi-densepose-bfld/** and v2/crates/cog-ha-matter/**
so future iteration on those crates rebuilds the image.
DOCKERHUB_TOKEN rotated separately (was expired since 2026-05-13,
which is why the last 5 workflow runs failed at the Docker Hub login
step and `latest` on Docker Hub has stayed amd64-only despite #631
being merged). With this commit + rotated token, the next CI run
should land a multi-arch `:latest` with HA-DISCO + cog-ha-matter +
BFLD support.
Reproduced kutayozdur's pull failure on ruv-mac-mini (Apple Silicon,
Darwin arm64) via Tailscale before fixing.
Refs #794, #631, ADR-115, ADR-116, ADR-118.
Co-Authored-By: claude-flow <ruv@ruv.net>
Fixes#384: docker run with --source/--tick-ms flags now works correctly.
Fixes#399: model files in mounted volumes are now discoverable via MODELS_DIR env var.
Root cause (issue #384):
The Dockerfile used ENTRYPOINT ["/bin/sh", "-c"] with a shell-form CMD.
When users passed flags like `--source wifi --tick-ms 500` as docker run
arguments, Docker replaced CMD entirely, resulting in
`/bin/sh -c "--source wifi --tick-ms 500"` which executes `--source` as
a shell command → `--source: not found`.
Root cause (issue #399):
Model directory was hardcoded to the relative path `data/models`. When Docker
users mounted models to `/app/models/`, the scan looked in the wrong place.
Changes:
1. docker/docker-entrypoint.sh (new):
- Proper entrypoint script that handles both env-var-based defaults and
user-passed CLI flags
- No arguments → starts server with CSI_SOURCE env var as --source
- Flag arguments (start with -) → prepends /app/sensing-server + defaults,
appends user flags (clap last-wins allows overrides)
- Non-flag first arg → exec passthrough (e.g., /bin/sh for debugging)
- Sets --bind-addr 0.0.0.0 (was 127.0.0.1 which blocks container access)
2. docker/Dockerfile.rust:
- Switch from ENTRYPOINT ["/bin/sh", "-c"] to exec-form entrypoint
- Add MODELS_DIR env var (default: data/models)
- COPY the entrypoint script into the image
3. docker/docker-compose.yml:
- Remove shell-form command (entrypoint handles defaults)
- Add MODELS_DIR env var
4. model_manager.rs + main.rs:
- Replace hardcoded `data/models` path with `effective_models_dir()`
/ `models_dir()` that reads MODELS_DIR env var at runtime
- Docker users can now: docker run -v /host/models:/app/models -e MODELS_DIR=/app/models
5. tests/test_docker_entrypoint.sh (new, 17 tests):
- Default CSI_SOURCE substitution (6 assertions)
- Custom CSI_SOURCE propagation
- User-passed flag arguments (--source, --tick-ms, --model)
- Unset CSI_SOURCE defaults to auto
- Explicit command passthrough
- MODELS_DIR env var propagation
ruv
voidborne-d