Files

T

duffyduckandClaude Opus 4.8 2cac1cad0a feat(host-agent): Docker-loser Native-Build + Live-ISO-Hinweis

Docker-Build scheitert auf Live-ISOs (overlayfs-Root -> overlay2 kann kein
Overlay-auf-Overlay stapeln: 'failed to mount ... invalid argument'). Ergaenzt:
- build-native.sh: PyInstaller in einem venv, ohne Docker (Warnung: linkt gegen
  lokales glibc).
- README: Live-ISO-Ursache erklaert + zwei Auswege (Binary woanders bauen und
  kopieren [empfohlen, portabel] oder nativ bauen).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-09-24 16:42:39 +02:00

3.1 KiB

Raw Blame History

ARIA Host-Agent

Ein schlanker Agent, der direkt auf einem Rechner läuft und ARIA erlaubt, diesen Rechner zu steuern — auch wenn er sonst aus dem Netz nicht erreichbar ist (hinter NAT/Firewall, kein offener Port). Der Agent verbindet sich ausgehend zum RVS (gleicher Token wie der Rest von ARIA).

Unterschied zum Satelliten: der Satellit entdeckt und steuert andere Geräte in einem LAN; der Host-Agent steuert den Rechner, auf dem er läuft.

Fähigkeiten

Aktion	Was
`exec`	Shell-Kommando ausführen (optional `sudo`), stdout/stderr/exit
`read`	Datei lesen (Base64, mit Offset/Limit)
`write`	Datei schreiben/anhängen (Base64 oder Text)
`info`	OS, CPU/RAM/Disk-Auslastung, Uptime, IP
`screenshot`	Bildschirmfoto (X11: scrot/maim · Wayland: grim)

ARIA nutzt diese über die Brain-Tools host_list / host_exec / host_read / host_write / host_info / host_screenshot.

Bauen (portable Binary)

./build.sh          # braucht Docker; erzeugt dist/aria-host-agent (~15 MB)

Gebaut wird in einem bullseye-Container (altes glibc), damit die Binary auf möglichst vielen Distributionen läuft.

Docker scheitert? (Live-ISO / overlayfs-Root)

Wenn build.sh mit failed to mount … overlayfs … invalid argument abbricht, läufst du wahrscheinlich auf einem Live-System (Live-ISO). Dessen Root ist selbst ein overlayfs, und Dockers overlay2-Treiber kann kein Overlay-auf- Overlay stapeln. Zwei Auswege:

Empfohlen: Binary auf einem normal installierten Linux bauen (./build.sh) und nur die fertige dist/aria-host-agent aufs Live-System kopieren. Die Binary ist portabel — Ziel braucht weder Docker noch Python.
Nativ bauen (ohne Docker):
```
sudo apt install -y python3-pip python3-venv
./build-native.sh
```
Achtung: nativ gebaut linkt die Binary gegen das glibc dieser Maschine — sie läuft dann nur auf Systemen mit gleichem oder neuerem glibc.

Installieren

dist/aria-host-agent auf den Ziel-Rechner kopieren.
.env.example → .env daneben, RVS-Zugang + CONTROL_ENABLED=true eintragen.
Starten: chmod +x aria-host-agent && ./aria-host-agent — oder als Dienst: siehe aria-host-agent.service.

sudo

Vier Fälle, der Agent wählt automatisch:

Agent läuft als root (z.B. systemd User=root) → volle Rechte, kein sudo nötig.
SUDO_PASSWORD=… in der .env → sudo -S mit Passwort.
SUDO_NOPASSWD=true → sudo -n (Live-ISO / passwortloses sudo, z.B. Linux Mint vom Stick).
sonst → sudo-Kommandos scheitern mit klarer Meldung.

Sicherheit

Reagiert nur auf den eigenen RVS-Raum (Token) und nur, wenn CONTROL_ENABLED=true.
Keine offenen Ports (reiner ausgehender Client).
Alle Kommandos werden geloggt.
Der Agent gibt vollen Zugriff auf den Rechner — nur auf Maschinen einsetzen, denen du ARIA anvertraust.

Hinweis Screenshot

Als Systemdienst fehlt die grafische Session. Für screenshot den Agent in der Desktop-Session starten (Autostart) oder DISPLAY/XAUTHORITY in der Unit setzen.

3.1 KiB Raw Blame History