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>
22 lines
820 B
Markdown
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.
|