Uebergabe fuer die naechste Session
Einstieg ist die Passwort-Rotation Etappe 2: Nautobot und die vier HA-mikrotik-Integrationen auf die gestern angelegten Service-Accounts umhaengen, dann erst admin rotieren. Die Vorarbeit steht komplett, und das admin-Passwort ist zweimal in ein Transkript geraten -- derselbe Wert, da alle vier Geraete ihn teilen. Festgehalten sind ausserdem die beiden Messungen, die vorherige Annahmen widerlegen (eco_mode hebt die Sendeleistung nicht an; restart_required auf 14 Geraeten war ein Fehlalarm), der Grund fuer das Verwerfen von TP17.1, und die Fallen, die man sonst neu erhebt -- darunter die abweichende s-Nummerierung zwischen HA und Repo, der stale VLAN1-Sweep in migrate.py und die Regel, nach jedem Shelly-Firmwarewechsel den AP zu pruefen. teilprojekte.md zeigt im Ist-Stand jetzt auf diese Uebergabe. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
146
docs/handoff-20260824-session.md
Normal file
146
docs/handoff-20260824-session.md
Normal file
@@ -0,0 +1,146 @@
|
||||
# Übergabe — Session 2026-08-23 (bis in den 24. hinein)
|
||||
|
||||
> **Einstieg:** diese Datei, dann [`teilprojekte.md`](teilprojekte.md).
|
||||
> **Zustand am Netz: stabil und aufgeräumt.** Nichts steht halb offen, keine Config-Transaktion
|
||||
> gelaufen, `s9` ist vollständig zurückgebaut, alle Shellys erreichbar.
|
||||
|
||||
## Was diese Session war
|
||||
|
||||
Begonnen mit TP17.3 (der Shelly-Regression), geendet bei einer Umstrukturierung der Router-Konten.
|
||||
Fünf Commits: `d245d10`, `e8f7f80`, `0a7f2e2`, `2f18319`, `e9a5b36`.
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| ✅ **TP17.3 gelöst** | Ursache **`eco_mode`** bewiesen, `s23` (Dimmer-Flackern) und `s26` (Doppeldruck) repariert. |
|
||||
| ✅ **`eco_mode` flottenweit aus** | 13 Geräte umgestellt, null Fehler. **22/22 erreichbare Shellys auf `false`.** |
|
||||
| ❌ **TP17.1 verworfen** | Der Zigbee-Weg wurde **vollständig bewiesen** — und damit auch, dass das Ziel mit ihm nicht erreichbar ist. |
|
||||
| ✅ **Passwort-Rotation Etappe 1** | Dedizierte Service-Accounts `ha` + `nautobot` auf allen vier MikroTik. |
|
||||
|
||||
---
|
||||
|
||||
## 🔴 Womit die nächste Session anfangen sollte
|
||||
|
||||
**Passwort-Rotation, Etappe 2.** Die Vorarbeit steht komplett, der Rest ist die einzige Sache mit
|
||||
echter Dringlichkeit — das `admin`-Passwort ist zweimal in ein Transkript geraten (22.08. und, durch
|
||||
meinen eigenen Enumerationsfehler, nochmal am 23.08.; **derselbe Wert**, da alle vier Geräte ihn teilen).
|
||||
|
||||
**Was Etappe 2 verlangt, in dieser Reihenfolge:**
|
||||
1. **Nautobot** auf den `nautobot`-User umstellen — `NAUTOBOT_ROUTEROS_USERNAME/PASSWORD` im Stack
|
||||
`docs/nas-vlan20/stacks/210-nautobot.yml` (gitignored), dann **Portainer-Redeploy** auf der DS923.
|
||||
⚠️ Beim Redeploy die Healthcheck-/`mem_limit`-Zeilen nicht verlieren — siehe CLAUDE.md-Gotcha,
|
||||
der Stack hat am 17.08. zweimal die DS923 abgeräumt.
|
||||
**Abnahme:** ein GC-Backup-Lauf, der durchgeht.
|
||||
2. **HA**: die vier `mikrotik`-Integrationen (`.99.1`, `.99.2`, `.99.11`, `.99.12`) auf `ha` bringen.
|
||||
🔴 **`supports_reconfigure: false` — nicht skriptbar.** Entfernen-und-neu-Anlegen *wäre* skriptbar
|
||||
(`ha_set_integration domain="mikrotik"`), riskiert aber die **40 `device_tracker`-Entities**.
|
||||
Sie heißen nach MAC (`device_tracker.10_20_ba_fa_f5_40`), kämen also identisch zurück — **aber nur,
|
||||
wenn die alten Registry-Einträge vorher weg sind**, sonst hängt HA ein `_2` an. Dieselbe Falle wie
|
||||
beim Shelly-Rename.
|
||||
3. **Erst danach `admin` rotieren.** Dann berührt es nur noch `~/.secrets/credentials.env` und
|
||||
`~/.claude.json` (+ MikroMCP-Neustart) — die Repo-Skripte ziehen automatisch nach.
|
||||
|
||||
### Was dafür schon fertig ist
|
||||
Auf **allen vier** Geräten angelegt und abgenommen (vorher existierte dort **nur** `admin`/`full`):
|
||||
|
||||
| Gruppe | Policy | User |
|
||||
|---|---|---|
|
||||
| `grp-ha` | `read,api,rest-api,test` | `ha` |
|
||||
| `grp-nautobot` | `ssh,read,write,test,sensitive` | `nautobot` |
|
||||
|
||||
Passwörter: `MIKROTIK_HA_PASS` / `MIKROTIK_NAUTOBOT_PASS` in `~/.secrets/credentials.env`.
|
||||
🎯 **Der Export von `nautobot` ist byte-identisch zu dem von `admin`** (391/56/87/87 Zeilen) —
|
||||
**die GC-Compliance driftet beim Umstellen nicht.** Das war das Hauptrisiko und ist geprüft.
|
||||
`/user` wird von keiner ComplianceRule abgedeckt, die Konten erzeugen selbst keinen Drift.
|
||||
|
||||
---
|
||||
|
||||
## Danach, mit Vorsicht
|
||||
|
||||
- **C2 — IoT-PSK rotieren.** Der Hebel ist `/interface wifi security multi-passphrase`
|
||||
(`group`/`passphrase`/`vlan-id`/`expires`), auf dem Core verifiziert vorhanden, Tabelle noch leer.
|
||||
🔴 **Zuerst `multi-passphrase` gegen WPA3/SAE testen — auf einer Wegwerf-SSID, nie an
|
||||
`dirtyvader-iot`.** `sec-iot` fährt `wpa2-psk,wpa3-psk`; trägt multi-passphrase SAE nicht, sperrt
|
||||
man **26 IoT-Geräte auf einmal** aus, inklusive Nuki und NSPanel.
|
||||
Danach: 23 Shellys per Skript (der erprobte Anker-Pfad in `migrate.py._migrate_one`), **3 Geräte von
|
||||
Hand** — `.249` SONOFF NSPanel Pro (Touchscreen), `.244` Nuki Bridge (App), `.227` SwitchBot Floor
|
||||
Lamp (App). ⚠️ `s1`/`s2`/`s3` sind ausgesteckt und kommen im Dezember mit dem **alten** PSK zurück.
|
||||
⚠️ CAPsMAN: eine Profiländerung wirkt erst nach `remote-cap provision` für **beide** APs.
|
||||
- **D — TP17.2 Shelly-Gerätepasswort**, an C2 gekoppelt (ein Reboot statt zwei). Werkzeug ist fertig
|
||||
(`migrate.py cmd_auth`, Digest-Fallback in `_rpc`). 🔴 **Der Aufwand ist HA, nicht `SetAuth`:** je
|
||||
Gerät ein Re-Auth-Flow, 23-mal. **Erst an EINEM Gerät messen** (Vorschlag `s15 technik_pve`, −36 dBm).
|
||||
- **TP25 Fund F** (5:05-Takt IoT) und die Entscheidung **5 GHz auf 20 MHz**.
|
||||
- **5-GHz-Umfeldscan** vor dem Einbau der zwei neuen APs.
|
||||
|
||||
---
|
||||
|
||||
## Die Entscheidung des Tages: warum TP17.1 gestorben ist
|
||||
|
||||
Der Pilot hat den Zigbee-Weg **technisch vollständig bewiesen** — `s9` lief auf `PowerStripZB`, trat
|
||||
ZHA bei, ein Zigbee-Befehl schaltete das physische Relais, kein Broadcast-Sturm.
|
||||
|
||||
Christophs Einwand hat ihn trotzdem gekippt: *„zigbee sollte die antwort auf die vielen radios auf
|
||||
-iot geben. nutzt aber wenig wenn man das wifi nicht abdrehen kann bzw. es nicht mehr aktivieren kann
|
||||
ohne reset."* Und die Messung stützt ihn:
|
||||
|
||||
- **Das Gerät bleibt WLAN-Client** — Zigbee kommt *zusätzlich*, nicht *statt*.
|
||||
- **Der Funkgewinn ist klein:** die 12 Gen4 sind 12 von 26 IoT-Clients, bewegen aber je nur
|
||||
~150–200 KB rx / 0,6–3 MB tx in sechs Stunden.
|
||||
- **Der Preis wäre dauerhaft:** die Zigbee-Firmware hat **keinen AP**, Shelly macht **kein Zigbee-OTA**,
|
||||
`Shelly.InstallAlt` braucht IP. WLAN aus = nie wieder Update, kein Rückweg, bei 10 Unterputz-Modulen.
|
||||
|
||||
**Der Weg ist nicht gescheitert, das Ziel war mit ihm nicht erreichbar.** Das Runbook bleibt als
|
||||
Wissensspeicher; einziger Restposten ist der **Frühindikator** (`Shelly.CheckForUpdate` auf einen
|
||||
`…MT`/Thread-`alt`-Eintrag beobachten).
|
||||
|
||||
---
|
||||
|
||||
## Zwei Messungen, die vorherige Annahmen widerlegen
|
||||
|
||||
**1. `eco_mode` aus hebt die Sendeleistung NICHT an.** Ich hatte das als Airtime-Risiko notiert, das
|
||||
TP25 berührt. Gemessen am Manager, vorher/nachher: **13 geänderte Geräte im Mittel −0,9 dB**, bei einer
|
||||
**Kontrollgruppe von 13 unveränderten mit +0,0 dB** und derselben Streuung (±2 dB). Rauschen.
|
||||
⇒ Die TP17-Aussage, `eco_mode` senke „den CPU-Takt **und** die WLAN-Sendeleistung", stimmt nur zur
|
||||
Hälfte. Der Takt-Teil ist durch das Dimmer-Flackern bewiesen; der Rest ist nicht messbar.
|
||||
|
||||
**2. `restart_required` auf 14 Shellys war ein Fehlalarm.** Der Reboot von `s26` mit Config-Vergleich
|
||||
davor/danach ergab **identische Configs**. Das Bit ist *sticky* und stand für keine abweichende
|
||||
Konfiguration. **Nicht erneut untersuchen** — drei Wege (169 RPC-Methoden, Config-Diff über die
|
||||
Gruppengrenze, Gerätelog) sind zu Ende gegangen, alle negativ.
|
||||
|
||||
---
|
||||
|
||||
## Zahlen und Fallen, die man nicht neu erheben muss
|
||||
|
||||
- **`dirtyvader-iot`: 26–27 Clients, alle auf EINEM VAP** (`cap-wifi4-virtual1`, ap1). Davon 23 Shellys
|
||||
und **3 Fremde**: `.249` NSPanel Pro, `.244` Nuki Bridge, `.227` SwitchBot Floor Lamp.
|
||||
- **`s4 kueche_mikrowelle` ist wieder online** (war den ganzen Tag als offline geführt) — und ist
|
||||
**Gen3**, war also nie TP17.1-Kandidat. Bleibt der Härtefall bei −96 dBm (Geräte-Sicht).
|
||||
- 🔴 **HA- und Repo-Nummerierung der Shellys weichen ab** — HA: `s10 = schlafzi/teststecker`,
|
||||
Inventory: `s10 = bad_sonos`; ebenso `s17`. **Immer über MAC/IP zuordnen, nie über die s-Nummer.**
|
||||
- 🔴 **`migrate.py _resolve` fällt ohne Argument auf den alten VLAN1-Sweep `10.40.41.180-250` zurück.**
|
||||
Explizite Bereiche übergeben oder `SHELLY_SWEEP` setzen.
|
||||
- 🔵 **`inventory/bf.csv` führt `s12` noch auf `10.40.41.219`** (live `10.40.30.219`).
|
||||
- ⚠️ **Nach jedem Shelly-Firmwarewechsel den AP prüfen** — der Rückflash von `s9` zog einen **offenen**
|
||||
AP hoch (`ap.enable=true, is_open=true`). Abgeschaltet und mit dem IoT-PSK abgesichert.
|
||||
- 🔒 **`wifi-security` ist als ComplianceRule grün, aber NICHT deploybar** — die Passphrasen stehen als
|
||||
`<<REDACTED>>` im Template. Ist-Stand immer per REST vom Gerät lesen
|
||||
(`GET http://10.40.99.1/rest/interface/wifi/security`), **nie** aus `wlan-psks.env`.
|
||||
|
||||
### Der Firmware-Mechanismus der Shelly Gen4 (falls er je wieder gebraucht wird)
|
||||
Zwei-Slot-Modell über drei **undokumentierte** RPCs, aus dem UI-JavaScript des Geräts extrahiert:
|
||||
`Shelly.InstallAlt {app, stage}` lädt in den inaktiven Slot und rebootet hinein · `Shelly.SetAlternative
|
||||
{name}` schaltet um (auf unseren Modellen **nicht vorhanden**) · `Shelly.ListAlternatives` (404 auf
|
||||
beiden Builds). Die Shelly-Support-Seite beschreibt einen **Modus-Umschalter mit 5-Sekunden-Knopf** —
|
||||
**das gilt für unsere Modelle nicht.**
|
||||
|
||||
---
|
||||
|
||||
## Neue und geänderte Dokumente
|
||||
|
||||
- [`tp17.1-shelly-gen4-funkmigration-runbook.md`](tp17.1-shelly-gen4-funkmigration-runbook.md) —
|
||||
Kopf trägt jetzt „VERWORFEN"; enthält den kartierten Mechanismus, das 2,4-GHz-Bild und die
|
||||
ZHA-Sturmzähler mit Baseline
|
||||
- [`teilprojekte.md`](teilprojekte.md) — TP17.1 verworfen, TP17.2 aktiviert, TP17.3 erledigt,
|
||||
PSK-Follow-up um Radius-Befund und Etappe 1 ergänzt
|
||||
- `CLAUDE.md` — 🔴 empfahl bis gestern aktiv `sshpass -p` als Reboot-Weg, jetzt `sshpass -e`
|
||||
- `mcp/shelly/migrate.py` — neues `eco`-Kommando (mit Retry je Gerät und Fehlerliste)
|
||||
@@ -92,7 +92,10 @@ ab jetzt bei jeder Änderung mitgezogen, nicht nur die TP-Abschnitte.)*
|
||||
> `s23` + `s26` repariert; **`eco_mode` flottenweit aus**, 22/22 außer `s24`) ·
|
||||
> 🔜 **TP17.2 aktiviert** (Shelly-Gerätepasswort, an die PSK-Rotation gekoppelt) ·
|
||||
> 🔑 **Rotation des MikroTik-Admin-Passworts** — seit 08-23 bewusst **hinter** TP17.1 eingereiht.
|
||||
> Zugeschnittene Sitzungsvorschläge: [`handoff-20260822-naechste-schritte.md`](handoff-20260822-naechste-schritte.md).
|
||||
> 📌 **Einstieg für die nächste Session: [`handoff-20260824-session.md`](handoff-20260824-session.md)**
|
||||
> — Start bei der **Passwort-Rotation Etappe 2** (Nautobot + HA auf die neuen Service-Accounts
|
||||
> umhängen, dann `admin` rotieren). Ältere Sitzungsvorschläge:
|
||||
> [`handoff-20260822-naechste-schritte.md`](handoff-20260822-naechste-schritte.md).
|
||||
> ✅ **`crs326-core` ist transaktionsfrei** (seit 2026-08-22, geprüft): ein gemeldeter Drift ist ab
|
||||
> jetzt **echt**, nicht beabsichtigt — `python3 nautobot/gc-transaktion.py status`.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user