MakerFLOSS_Troubleshooting/runbooks/README.md
sjat 9ff12700ae Initial troubleshooting workspace: access, network map, runbooks
Scaffold for troubleshooting MakerFLOSS hosts at the makerspace.
Reference + thin runbooks model — authoritative data stays in the
source repos (AnsibleBaobabV4, MakerFLOSS_Mikrotik, MakerFLOSS).

- access.md: reach paths for mamba-on-LAN and fisi-tunneling-in
  (netbird on-demand, VPS bastion, ProxyJump via kuku->mamba),
  with the isolation rule.
- network-map.md: subnet pointers + open question on makerspace
  addressing (10.2.30/172.17.3/10.0.0).
- runbooks/switch-crs310.md: CRS310 connectivity + lockout recovery.
- incidents/: dated log scaffold.
- CLAUDE.md: operating rules for this repo.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-09 13:24:26 +02:00

22 lines
820 B
Markdown

# Runbooks
Task-focused troubleshooting guides. Thin — they point at the source repos for
authoritative config and commands rather than duplicating them.
## Index
| Runbook | Covers |
|---------|--------|
| [switch-crs310.md](switch-crs310.md) | The MikroTik CRS310 switch — connectivity, VLANs, mgmt-plane lockout recovery, Ansible reconfig. |
## Adding a runbook
Keep it lean. Good structure:
1. **Symptom** — what you observe.
2. **Reach** — which [access.md](../access.md) path applies.
3. **Diagnose** — concrete checks (commands, what good/bad looks like).
4. **Fix** — where the change lands (source repo + file), and the safety rules
for applying it to live infra.
5. **Verify** — how you confirm it's actually fixed (evidence, not assertion).
6. **Links** — source-repo specs/runbooks.