sjat/MakerFLOSS_Troubleshooting
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
MakerFLOSS_Troubleshooting/incidents/2026-07-17-srv07-access.md
sjat 2194a26970 access: rewrite for the ubongo era; srv07 incident; refresh network map 
fisi is decommissioned and boma retired Netbird (ADR-036), so the old
Claude-on-fisi/Netbird access doctrine is gone. New order: VPS bastion
ProxyJump onto wg1 (primary, isolation-clean), via mamba over the boma hub
when on-site. Netbird control plane kept but demoted to legacy (operator
decision, not an access path). Network map refreshed from live probing
2026-07-17: rack LAN is 10.0.0.0/24, wifi 172.17.3.0/24 does not route to
it, 10.2.30.0/24 likely gone. Incident log covers the srv07/mf04 identity
fix and re-established access.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-17 17:23:18 +02:00

3.1 KiB
Raw Blame History

2026-07-17 — srv07 (ex-mf04) unreachable by every path; identity settled; access re-established

Symptom

Session goal: conclude an SSH access path to the testmachine ("mf04, now srv07 — we think"). Every documented path was dead: old LAN IPs (10.0.0.183/.184, 10.2.30.61) unreachable, wg1 peer 10.13.0.3 had no handshake and the VPS had no route to it, the fisi/Netbird path no longer exists (fisi decommissioned, ubongo has no Netbird agent — boma ADR-036). Also unclear: whether the box is srv05 or srv07 — the naming-scheme migration table said mf04 → srv05, the physical sticker said srv07.

Root cause

Two physical-layer facts, no software fault:

  1. The box's network path was unplugged. pp02:8 (srv07 eth0) had lost its rear patch when sw01:7 was repurposed as the sw06 uplink — already recorded in MakerFLOSS/docs/hardware/pp02.md, but not connected to "that's why nothing answers." The machine itself had been up 9+ days.
  2. The naming table was wrong. The physical box wearing the srv07 sticker is the Ansible/OS host mf04 (i3-4360T/16 GB/500 GB HDD — matches neither srv04's nor srv05's recorded i5-3570K specs). mf04 → srv05 was a mis-mapping made when the placeholder pages were renamed.

What was done (operator on-site with mamba; Claude from ubongo via the boma hub → mamba)

  • Operator re-plugged the box and wired mamba into the rack switching; the box immediately took its old lease (10.0.0.183) and its wg1 tunnel re-handshook.
  • Renamed the host live to match the sticker: hostname mf04 → srv07, /etc/hosts, wg unit makerfloss-mf04 → mf-srv07. Gotcha: wg-quick interface names are capped at 15 chars (IFNAMSIZ) — makerfloss-srv07 (16) fails with a misleading does not exist; hence mf-srv07.
  • AnsibleBaobabV4 0bce3a1: host_vars/mf04.yml → srv07.yml; ansible_host re-pinned from the Netbird IP to wg1 10.13.0.3 + ProxyJump via the VPS (mirrors mf01); inventory + hub peer entry renamed. Vault keys keep the historical mf04 name (same keypair).
  • MakerFLOSS docs f047332: srv07 real specs, dated correction of the naming-table row, pp02 note (path restored, new patching unrecorded).
  • This repo: access.md rewritten for the ubongo era, network-map.md refreshed from live probing.
  • Netbird: kept (control plane + srv07 agent), operator decision — no longer an access path, not removed yet.

Verification

  • ssh -J sjat@makerfloss.eu:7576 -p 7576 sjat@10.13.0.3 → hostname srv07 (roaming path, end-to-end).
  • ssh -p 7576 sjat@10.0.0.183 from wired mamba → works (on-site path).
  • wg-quick@mf-srv07 active + enabled; hub handshake fresh after rename.

Follow-ups

  • Record srv07's actual rear patch / switch port (pp02.md + sw01.md).
  • Identify the rack-LAN Debian trio .10/.11/.12 and .158/.165/.209.
  • Find/verify makerfloss1 (LAN and wg1 both dark).
  • Ansible play against srv07 not yet re-run — first run after the rename should be watched (wg config name change: the play must not resurrect a makerfloss-srv07/makerfloss-mf04 config; host_vars now says mf-srv07).
  • Eventual Netbird retirement decision (logged in access.md §D).