name: bwa-pose-gate-zugang
description: bwa-pose-gate liegt im iMac-Container 10.42.0.52; Zugang + Push-Route
metadata:
node_type: memory
type: reference
originSessionId: ba887061-7d47-461f-9396-e7021e8cde82
modified: 2026-07-19T20:27:28.988Z

Repo bwa-pose-gate (Gitea: git.crumbforest.org/branko/BWA-pose-gate_v0) liegt auf dem
iMac-Container sysop@10.42.0.52:~/workspace/bwa-pose-gate — die Pose→MIDI/VJ-Pipeline
(Zosi-NVR 192.168.88.230, MediaPipe PoseLandmarker).

Zugang (nur über nullfeld/strato = 194.164.194.191, derselbe Host):
ProxyJump root@194.164.194.191 (Key ~/.ssh/id_ed25519_nullfeld) → dann
sysop@10.42.0.52 mit ~/.ssh/crumbforest_blackbox. Mein blackbox-Pubkey liegt in
sysops authorized_keys. Der Container selbst hat keine Gitea-Creds und kann das
private Repo weder fetchen noch pushen.

Push-Route: von diesem M4-Control-Node — der hat Gitea-Creds im osxkeychain
(host-weit für git.crumbforest.org). Also: Container-Repo per SSH-Proxy auf den M4 klonen
(GIT_SSH_COMMAND-Wrapper mit dem verschachtelten ProxyCommand), auf gitea/main rebasen,
von hier pushen. Container danach syncen: rebaste Historie als temp-Branch in den Container
pushen (push origin <sha>:refs/heads/x), dort git reset --hard x.

NVR 192.168.88.230 ist vom Container aus nicht erreichbar (anderes LAN) → Live-Frames
nicht lokal testbar, nur one-shot gegen Testbilder in ~/workspace/zosi_ch3_*.jpg.
Siehe [[snakeview-pose-pipeline]].

NetBox (SoT), seit 2026-07-19: NVR neu angelegt — waldmitte-nvr-01 (device id 22,
site roaming, Rolle surveillance-gatekeeper NEU, Type Zosi K8208-W NVR, primary_ip4
192.168.88.230/24, iface wan0). CAM4 = waldmitte-cam-04 (id 23, camera-node). Pipeline-
Fakten (Ports, active_channels [4], ROI, snapshot_chn 3 vs nvr_channel_port 4, target_midi
_channel 1) in local_context_data.bwa_pose_gate statt Custom-Fields. crew.md-MAC
98:FA:9B:DB:76:37 ist falsch (schon an enp0s31f6 eines anderen Geräts vergeben, Laptop-
NIC) → wan0 bewusst OHNE MAC gelassen; echte NVR-MAC ziehen wenn jetpack den NVR sieht.

NVR echte IP = 192.168.88.229 (NICHT .230 wie crew.md/README/Dev-Skripte sagen — da
ist nichts), MAC 9c:a3:a9:b2:ed:6c, admin/1234, snapshot.cgi?chn=3 = CAM4, 640x360.
NVR ist COLD beim ersten Snapshot (~8s), danach ~0.5s → http_timeout muss ≥10s, sonst
kriegt der Daemon nie einen Frame. NetBox auf .229+echte MAC korrigiert (2026-07-19).
Nur .1(Mikrotik SXE), .229(NVR), .234(nginx-Box, TRÄGT die falsche crew.md-MAC), .233 leben
auf 88/24. Kamera-VLAN nur vom iMac erreichbar (enp4s0f0=192.168.88.232, GW .1).

Live-Loop läuft — DEPLOYED auf dem iMac (2026-07-19): systemd --user Service
bwa-pose-gate.service (~/.config/systemd/user/), enabled + Linger=yes (bootfest ohne
root — sysop hat KEIN passwortloses sudo, root liegt hinter Passwort). Steuern:
XDG_RUNTIME_DIR=/run/user/$(id -u) systemctl --user status|restart bwa-pose-gate,
live: journalctl --user -u bwa-pose-gate -f. config.json (gitignored) dort: nvr_ip .229,
fps 2, http_timeout 12. Der iMac ist der pragmatische Host (am VLAN + py3.13).

jetpack (192.168.1.172, gpu-node, baumhaus) als Ziel = 2 Blocker: (1) kein Pfad zu
88/24 — jetpack nur über WG/nullfeld erreichbar, NVR hinter Mikrotik im Container →
bräuchte WG-Route 88/24 via iMac(10.42.0.52) + IP-Forwarding, ODER Snapshot vom iMac
proxien. (2) Python 3.6.9 (Ubuntu 18.04) → MediaPipe braucht ≥3.8 → Container (docker0 da).
Control-Node-M4 ist NICHT im VPN — alles per ProxyJump über nullfeld.