Christoph Emsenhuber
49f2bfd98f
synopkg stop/start ContainerManager auf nas-bf. Alle 14 Container aus der Baseline sind zurueck, zusaetzlich kam hms-mqtt hoch (Restart-Policy, lief vorher nicht). Der Neustart hat den Haenger behoben: `docker system df` beendet sich wieder (vorher rc=124 nach Ausgabe der Tabelle). Er reicht aber nicht — der Aufruf bleibt mit 33s bis ueber 120s weit ueber dem pyportainer-Timeout, die HA-Integration bleibt auf setup_retry. Gemessen, wo die Zeit hingeht: images -q 84ms, ps -aq 95ms, volume ls 65ms, system df 33-92+s. Also vollstaendig in der Groessenberechnung (Durchlauf der overlay2-/Volume-Verzeichnisse auf NAS-Platten) — Plattformnachteil, kein Defekt. Aussichtsreichster Weg dokumentiert: eigener Portainer-Benutzer fuer HA ohne Zugriff auf ep14. Zwei widerlegte Zwischenthesen sind als solche festgehalten (odroid-m1 war es nicht; es ist kein Groessenproblem). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bf-network-r6
BF-Netzwerk-Migration (Variante R6+C2). 2× MikroTik hAP ax² + Core ALL-SG8316M.
SSOT & Übergabe: HANDOVER.md — kompletter Status, Architektur + Begründungen, Phasen, Gotchas, Zugänge.
Plan-Origin: ~/.claude/plans/welche-kosteng-nstigen-alternativen-zu-memoized-sparkle.md
Struktur:
docs/vlan-plan.md— VLAN-/Adressplan (final)docs/core-switch-prep.md— Core-Switch Status & Phasendocs/firmware-flash-runbook.md— FW-Flash Historieswitch/cli/CLI-REFERENCE.md— bestätigte CLI-Syntaxswitch/cli/*.cli/*.exp— reproduzierbare Konfig-Scriptsinventory/bf.csv/bf.md— IP-Doku (aus IPs.xlsx gespiegelt)inventory/bf-core-ports.csv/.md— Switch-Port-Map
Aktueller Stand (2026-06-09):
- Phase A (VLAN-Vorbereitung) ✅ abgeschlossen
- Phase B (hAP-Cutover) ⏳ wartet auf MikroTik-Lieferung
- Phase C (Firewall) + Phase D (Adress-Migration) ausstehend