Bug der alten Python-Version beim Ersetzen eines Containers mit Volume: get_container_data_volumes liest image_config['ContainerConfig'], das neuere Docker-Versionen nicht mehr schreiben. Fix: 'docker compose' (v2) nutzen oder den alten Container vorher mit 'rm -sf' entfernen (dann greift der create- statt recreate-Pfad). Trat schon beim frueheren Satelliten-Build auf — jetzt dokumentiert. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
120 lines
5.2 KiB
Markdown
120 lines
5.2 KiB
Markdown
# ARIA Satellit 🛰️
|
|
|
|
Ein eigenständiger **Außenposten-Container** für ein fremdes Netz (Büro, Werkstatt,
|
|
Ferienwohnung …). Er verbindet sich als RVS-Client in Stefans Raum und gibt ARIA
|
|
**Augen und Hände in genau diesem Netz** — ohne dass der Haupt-Stack dort stehen muss.
|
|
|
|
- **Augen (Info):** entdeckt Geräte via **mDNS/Zeroconf** (Chromecast, AirPlay, Sonos,
|
|
Drucker, NAS …), **SSDP/UPnP + DIAL** (Smart-TVs, Fire TV) und der **ARP-Tabelle**
|
|
(rohe Hosts). Meldet ARIA ein Live-Inventar.
|
|
- **Hände (Steuerung):** **DIAL-App-Launch** (z.B. YouTube-Video auf dem Fire TV),
|
|
**Wake-on-LAN**, generisches **HTTP**. Nur wenn freigeschaltet (siehe Sicherheit).
|
|
|
|
## ⚠️ Wichtig: der Satellit MUSS im echten Ziel-LAN laufen
|
|
|
|
Discovery (mDNS/SSDP-Multicast + ARP) funktioniert **nur**, wenn der Prozess
|
|
tatsächlich im selben LAN wie die Geräte hängt — z.B. `192.168.0.0/24`, wo der
|
|
Fire TV steht.
|
|
|
|
**Docker Desktop (Mac/Windows) geht NICHT.** Dort ist `network_mode: host` das Netz
|
|
der Docker-Linux-VM (NAT, `192.168.65.x` / `172.x`), **nicht** dein echtes LAN.
|
|
Der Satellit sieht dann nur Docker-Container statt der echten Geräte. (Der Satellit
|
|
erkennt das selbst und meldet eine ⚠-Warnung im Diagnostic + Log.)
|
|
|
|
Richtig deployen — zwei Wege:
|
|
|
|
**A) Linux-Box im Ziel-LAN mit Docker Engine** (empfohlen, z.B. Raspberry Pi / NUC im Büro):
|
|
```bash
|
|
cd satellite
|
|
cp .env.example .env # RVS-Zugang + SATELLITE_LOCATION
|
|
docker compose up -d --build
|
|
docker compose logs -f # "Netz: primary_ip=192.168.0.x" + "[scan] N Geraete"
|
|
```
|
|
`network_mode: host` (schon gesetzt) gibt hier echtes LAN + Multicast.
|
|
|
|
> **Fehler `KeyError: 'ContainerConfig'` beim Neubauen?**
|
|
> Das ist ein **Bug im alten `docker-compose` 1.29.2** (Python-Version), nicht im
|
|
> Satelliten: Beim *Ersetzen* eines bestehenden Containers mit Volume liest es ein
|
|
> Feld aus dem Image, das neuere Docker-Versionen nicht mehr schreiben. Zwei Fixes:
|
|
> ```bash
|
|
> docker compose up -d --build # v2 (mit LEERZEICHEN) — falls vorhanden
|
|
> # oder mit der alten Version: alten Container erst weg, dann neu anlegen
|
|
> docker-compose rm -sf satellite && docker-compose up -d --build
|
|
> ```
|
|
> Der `./data`-Ordner (Credentials, ADB-Schlüssel, APK-Cache) bleibt dabei erhalten —
|
|
> er ist ein Bind-Mount, kein Container-Volume.
|
|
|
|
**B) Nativ als Python-Prozess** (für Mac/Windows-Test oder ohne Docker) — läuft direkt
|
|
auf einer Maschine im Ziel-LAN. Das Script lädt die `.env` **selbst** (muss im
|
|
`satellite/`-Ordner liegen):
|
|
```bash
|
|
cd satellite
|
|
cp .env.example .env # RVS-Zugang + SATELLITE_LOCATION eintragen
|
|
pip install -r requirements.txt
|
|
python satellite.py # liest .env automatisch
|
|
```
|
|
(Echte Umgebungsvariablen haben Vorrang — `export RVS_TOKEN=...` überschreibt die
|
|
`.env`, falls du das lieber magst.)
|
|
|
|
`RVS_HOST/PORT/TLS/TOKEN` **identisch** zum Haupt-Stack (gleicher Raum, damit ARIA
|
|
den Satelliten erreicht). `SATELLITE_LOCATION` ist der Name, über den ARIA das Netz
|
|
anspricht („Büro").
|
|
|
|
**Satellit im selben Netz wie der RVS** (z.B. Rechenzentrum, direkt auf die
|
|
interne IP statt NAT-Hairpin): `RVS_HOST=<interne-ip>` + **`RVS_SNI=<zert-name>`**
|
|
(der Name, für den das Caddy-Zertifikat gilt). Ohne das scheitert TLS an
|
|
`tlsv1 alert internal error`. Zuhause / normal: `RVS_SNI` leer lassen.
|
|
|
|
**Kontrolle:** im Log/Diagnostic muss `primary_ip` im Ziel-LAN liegen
|
|
(`192.168.0.x`) — steht da `192.168.65.x` oder `172.x`, sitzt der Satellit im
|
|
falschen (Docker-)Netz.
|
|
|
|
## Als Dienst installieren (Autostart, ohne Docker)
|
|
|
|
Legt automatisch ein `.venv` an, installiert die Requirements und richtet einen
|
|
Dienst ein, der bei Boot startet und bei Absturz neu hochkommt. `.env` vorher
|
|
anlegen.
|
|
|
|
**Linux (systemd) / macOS (launchd):**
|
|
```bash
|
|
cd satellite
|
|
bash install.sh # installieren + starten
|
|
bash install.sh uninstall # entfernen
|
|
```
|
|
- Linux-Logs: `journalctl -u aria-satellite -f`
|
|
- macOS-Logs: `tail -f satellite.log` (evtl. „Lokales Netzwerk"-Zugriff erlauben)
|
|
|
|
**Windows (Scheduled Task) — PowerShell als Administrator:**
|
|
```powershell
|
|
cd satellite
|
|
powershell -ExecutionPolicy Bypass -File install.ps1 # installieren + starten
|
|
powershell -ExecutionPolicy Bypass -File install.ps1 -Uninstall # entfernen
|
|
```
|
|
- Log: `Get-Content -Wait satellite.log`
|
|
|
|
## So nutzt ARIA es
|
|
|
|
ARIA hat drei Brain-Tools:
|
|
- `satellite_list` — welche Netze/Satelliten sind online + was können sie.
|
|
- `satellite_devices(satellite)` — Inventar eines Netzes.
|
|
- `satellite_command(satellite, device, action, params)` — Aktion ausführen.
|
|
|
|
Beispiel „YouTube-Video auf dem Büro-Stick":
|
|
```
|
|
satellite_command(satellite="Büro", device="Fire TV",
|
|
action="dial.launch", params={"app":"YouTube","v":"<videoId>"})
|
|
```
|
|
|
|
## Sicherheit
|
|
|
|
Der Satellit scannt ein Netz **und** ist über einen Cloud-Relay erreichbar — deshalb:
|
|
|
|
- Reagiert **nur** auf den eigenen RVS-Raum (Token).
|
|
- **`CONTROL_ENABLED=false`** = reiner Info-Satellit (steuert nichts). Standard-sicher.
|
|
- Bei `true`: nur Aktionen aus **`CONTROL_ALLOWLIST`**, alles andere wird abgelehnt.
|
|
- Jede ausgeführte Aktion wird **geloggt**.
|
|
- Keine offenen Ports — reiner Client.
|
|
|
|
Empfehlung: in vertrauenswürdigen Netzen `CONTROL_ENABLED=true` mit enger Allowlist;
|
|
sonst `false` und nur beobachten.
|