# Handoff 2026-10-03 — TP10: Mesh-DDNS für bf4.emsenhuber.net — Finalisierung

## Kontext / Auslöser
TP10 (Multi-Site VPN) war im Archiv als „KERN DURCH" mit offenem DDNS-Updater für `bf4.emsenhuber.net`.
Der A-Record wurde manuell gepflegt; bei Liwest-IP-Wechsel würden beide WG-Tunnel (fm/dw) sterben.

Neuer Befund 2026-10-03: CF_DNS_API_TOKEN lag bereits in `~/.secrets/credentials.env` — DNS-Schreiben
funktioniert, Token kann *keine* Tokens anlegen (eng gescoped: `Zone → DNS:Edit` nur `emsenhuber.net`).

## Stand (alles live auf crs326-core)

| Objekt | Status |
|---|---|
| **Skript** `tp10-ddns-bf4` | angelegt, `invalid=false` — liest WAN-IP aus DHCP-Lease `client1` (`vlan100`), Public-IPv4-Guard, `check-certificate=yes`, Idempotenz über globale Variable `CFWanIP4Cur` |
| **Globale Variable** `cfDdnsToken` | auf Core gesetzt (`len=53`), persistiert in `/system script environment` |
| **CF_DNS_API_TOKEN** | liegt in `~/.secrets/credentials.env` → `CF_DNS_API_TOKEN` — Scope: `Zone → DNS:Edit` nur `emsenhuber.net` (Record `bf4`, ID `dba9d9ec3b261fdb314c0f83e4e62f0d`) |
| **Handlauf 1 (Idempotenz-Beweis)** | **PENDING** — Skript-Variable `cfDdnsToken` ist im Skript-Kontext nicht sichtbar (`:global` im Skript vs. `/system script environment`) |

## Offener Kernpunkt: Global-Variable im Skript nicht sichtbar

- `/system script environment print` → `cfDdnsToken` vorhanden (`count=1`, `len=53`)
- CLI-Test: `:global cfDdnsToken; :put [:len $cfDdnsToken]` → `53` ✅
- **ABER** im Skript (`:global cfDdnsToken; :if ([:typeof $cfDdnsToken] = "nothing")`) → `nothing`
- **Ursache:** RouterOS-Global-Scope-Differenz zwischen CLI-Interaktion und Skript-Ausführung
- **Workaround noch nicht angewendet** (Probe-Skript `tp10-ddns-probe` angelegt, `:log`-Ausgabe nicht bestätigt)

## Abhängigkeiten (NEU: envs auf Geräten)

| Gerät | Variable | Ort | Rotation bei Änderung |
|---|---|---|---|
| **crs326-core** | `cfDdnsToken` (53 Zeichen, `CF_DNS_API_TOKEN`) | `/system script environment` — **nicht** im Skripttext | Token-Wechsel: Wert in `/system script environment` aktualisieren, Skript unverändert |

**Wichtig:** Das Token liegt **nicht** im Git, nicht im Skript, nicht in Nautobot — nur in:
1. `~/.secrets/credentials.env` → `CF_DNS_API_TOKEN` (SSoT)
2. `crs326-core` → `/system script environment cfDdnsToken` (Live)
3. `mcp/cloudflare/.env` → `CF_DNS_API_TOKEN` (MCP-Bereitstellung)

Bei Token-Rotation: alle drei Orte synchron ändern.

## Was noch fehlt (Restmetern)

1. **Global-Scope-Fix** — Skript muss die Variable lesen können.
   - Option A: Skript per `run_command` statt als benanntes Skript ausführen (CLI-Scope)
   - Option B: Variable per `:global cfDdnsToken` *im Skript* **vor** der Prüfung setzen (Dummy, dann überschreiben)
   - Option C: Skript via `run_command` als Inline-Befehl ausführen (CLI-Scope)

2. **Handlauf 1 (Idempotenz):** Skript einmal laufen lassen → `CFWanIP4Cur` wird gesetzt → Log `⚠ aktualisiert`
3. **Handlauf 2 (Idempotenz-Beweis):** Skript nochmal → Log `⚠ unverändert`
4. **Scheduler anlegen** — DHCP-Client-Trigger `client1` + stündlicher Scheduler als Netz
5. **Positiv-Test** — A-Record kurz auf falsche IP setzen, Scheduler-Lauf abwarten, `dig bf4.emsenhuber.net` prüfen
6. **TP10 #49 schließen** — Issue: beide Close-Bedingungen abhaken (DDNS-Updater steht, GC-konform), Label `status:done`
7. **Handoff löschen** — diese Datei gehört ins Archiv, kein Handoff mehr nötig

## Nächste Schritte (für die nächste Session)

```bash
# 1. Probe: CLI-Scope Test (läuft das Skript inline?)
/tool fetch ... (wie im Skript, aber inline auf CLI)

# 2. Falls Global-Scope im Skript unrettbar:
#    - Skript als Scheduler-Aufruf inline bauen (DHCP-Client script=tp10-ddns-bf4)
#    - ODER: Skript die Variable selbst setzen lassen (Dummy → überschreiben)

# 3. Handlauf 1+2, Scheduler, Positiv-Test, TP10 schließen
```

## Wichtige Dateien

| Datei | Zweck |
|---|---|
| `routeros/tp10-ddns-cf-updater.rsc` | Skript-Quelle (MIT, Copyright bajodel 2025) |
| `routeros/tp10-ddns-cf-updater.rsc` (lokal) | importiert als `tp10-ddns-bf4` |
| `docs/teilprojekte.md` → `### TP10` | Prosa mit Befund, Close-Bedingung |
| `docs/teilprojekte-archiv.md` → `### TP10` | Zeiger: `♻️ REOPENED 2026-10-03` |
| `~/.secrets/credentials.env` | `CF_DNS_API_TOKEN` (SSoT) |
| `mcp/cloudflare/.env` | `CF_DNS_API_TOKEN` (MCP) |

## Sicherheit / Governance

- Token `CF_DNS_API_TOKEN` ist **eng gescoped**: `Zone → DNS:Edit` nur `emsenhuber.net`, Record `bf4`
- **Kein** `Account → Account API Tokens:Edit` — Token kann keine neuen Tokens anlegen
- Token liegt **nicht** im Git, nicht im Skript, nicht in Nautobot
- Rotation: drei Orte (`credentials.env`, Core `script environment`, `mcp/cloudflare/.env`)

## Bekannte offene Punkte

- **Recovery-Lücke:** GC-Template rendert kein `/system script` / `/system scheduler` — Recovery von null hätte den Updater nicht. Im TP10-Issue als offener Punkt vermerkt, Entscheidung vertagt.
- **WAN-IP-Quelle:** DHCP-Lease (korrekt), **nicht** Echo-Dienste — Liwest ist Quelle, kein Cloudflare im Pfad.
- **Mesh-IP-Falle widerlegt:** Core holt via `api.ipify.org` korrekt `90.146.33.177` (WAN), nicht Mesh-IP `100.96.0.6`.

## Nächste Session: genau das

1. Global-Scope-Problem lösen (10 Min)
2. Handlauf 1+2 (5 Min)
3. Scheduler (DHCP-Trigger + stündlich) + Positiv-Test (15 Min)
4. TP10 #49 `status:done` + Prosa finalisieren (5 Min)
5. Handoff löschen, pushen

**Geschätzte Restzeit: ~45 Min**

---

*Erstellt 2026-10-03 — Session-Handoff für Finalisierung TP10 DDNS*