[30388f42] Infrastructure Hardening: Repaired CE/Connector DB schema, fixed frontend styling build, implemented robust echo shield in worker v2.1.1, and integrated Lead Engine into gateway.
This commit is contained in:
210
docs/MOLTBOT_SYNOLOGY_GUIDE.md
Normal file
210
docs/MOLTBOT_SYNOLOGY_GUIDE.md
Normal file
@@ -0,0 +1,210 @@
|
||||
# Moltbot auf Synology NAS installieren
|
||||
|
||||
**Status (Jan 2026):** Erfolgreich installiert und betriebsbereit.
|
||||
|
||||
Diese Anleitung beschreibt die empfohlene Methode zur Installation von Moltbot auf einer Synology DiskStation unter Verwendung des offiziellen Setup-Skripts via SSH.
|
||||
|
||||
---
|
||||
|
||||
## 1. Voraussetzungen
|
||||
|
||||
* **DSM 7.x** mit installiertem **Container Manager**.
|
||||
* **SSH-Zugang** zur Synology NAS ist aktiviert (Systemsteuerung → Terminal & SNMP → SSH).
|
||||
|
||||
---
|
||||
|
||||
## 2. Installation (Via SSH & Setup-Skript)
|
||||
|
||||
Die Installation erfolgt direkt auf der Kommandozeile der DiskStation.
|
||||
|
||||
### Schritt 1: Ordnerstruktur auf dem NAS anlegen
|
||||
|
||||
Zuerst legen wir die Verzeichnisse an, in denen die Konfiguration und die Arbeitsdaten von Moltbot persistent gespeichert werden.
|
||||
|
||||
```bash
|
||||
# Pfad für die Moltbot-Installation erstellen
|
||||
mkdir -p /volume1/docker/moltbot
|
||||
|
||||
# Unterordner für Konfiguration und Workspace anlegen
|
||||
mkdir -p /volume1/docker/moltbot/config
|
||||
mkdir -p /volume1/docker/moltbot/workspace
|
||||
|
||||
# WICHTIG: Berechtigungen setzen, damit der Container schreiben darf
|
||||
sudo chown -R 1000:1000 /volume1/docker/moltbot/config /volume1/docker/moltbot/workspace
|
||||
```
|
||||
|
||||
### Schritt 2: Repository klonen und Setup ausführen
|
||||
|
||||
Nun klonen wir das offizielle Moltbot-Repository und starten das Setup-Skript mit den richtigen Pfadangaben.
|
||||
|
||||
```bash
|
||||
# In das vorbereitete Verzeichnis wechseln
|
||||
cd /volume1/docker/moltbot
|
||||
|
||||
# Moltbot-Repository von GitHub klonen
|
||||
git clone https://github.com/moltbot/moltbot.git
|
||||
cd moltbot
|
||||
|
||||
# Umgebungsvariablen für die persistenten Pfade setzen
|
||||
export CLAWDBOT_CONFIG_DIR="/volume1/docker/moltbot/config"
|
||||
export CLAWDBOT_WORKSPACE_DIR="/volume1/docker/moltbot/workspace"
|
||||
|
||||
# Das offizielle Setup-Skript ausführen
|
||||
./docker-setup.sh
|
||||
```
|
||||
|
||||
### Schritt 3: Interaktives Onboarding
|
||||
|
||||
Das Skript startet einen interaktiven Onboarding-Prozess. Folgen Sie den Anweisungen. Die Standardwerte sind in der Regel eine gute Wahl. Am Ende startet der Moltbot-Gateway-Container automatisch.
|
||||
|
||||
---
|
||||
|
||||
## 3. Zugriff auf die Control UI (Aktueller Stand)
|
||||
|
||||
### Das "Secure Context"-Problem
|
||||
|
||||
Moltbot erfordert aus Sicherheitsgründen einen "sicheren Kontext" (HTTPS oder `localhost`) für den Zugriff auf das Web-Interface. Ein direkter Aufruf über `http://<NAS-IP>:18789` schlägt daher fehl und führt zu einer `disconnected (1008)`-Fehlermeldung.
|
||||
|
||||
### Lösung: SSH-Tunnel
|
||||
|
||||
Die aktuell funktionierende und sichere Methode für den Zugriff ist ein SSH-Tunnel. Dieser leitet den Port des Containers auf Ihren lokalen PC um, sodass der Zugriff über `localhost` erfolgt.
|
||||
|
||||
**Befehl zum Aufbau des Tunnels (auf Ihrem PC ausführen):**
|
||||
|
||||
```powershell
|
||||
# Ersetze <NAS-IP> mit der IP-Adresse Ihrer DiskStation
|
||||
ssh -N -L 28789:127.0.0.1:18789 root@<NAS-IP>
|
||||
```
|
||||
|
||||
**Zugriff im Browser:**
|
||||
|
||||
Solange der SSH-Tunnel aktiv ist, können Sie die Moltbot UI auf Ihrem PC unter folgender Adresse erreichen:
|
||||
|
||||
`http://127.0.0.1:28789/`
|
||||
|
||||
Denken Sie daran, den beim Onboarding generierten Token an die URL anzuhängen (z.B. `?token=...`), falls erforderlich.
|
||||
|
||||
---
|
||||
|
||||
## 4. Nächste Schritte: Zugriff vereinfachen
|
||||
|
||||
Der Zugriff über einen SSH-Tunnel ist sicher, aber für den täglichen Gebrauch und den Zugriff von unterwegs unpraktisch.
|
||||
|
||||
**Offener Task:**
|
||||
* Einrichtung eines **Reverse Proxys** auf der Synology DiskStation.
|
||||
* **Ziel:** Moltbot über eine sichere **HTTPS**-URL (z.B. `https://moltbot.meine-domain.de`) erreichbar zu machen. Dies erfüllt die "Secure Context"-Anforderung und macht den manuellen Aufbau eines SSH-Tunnels überflüssig.
|
||||
|
||||
[STRATEGIE]
|
||||
Das war ein technischer Stellungskrieg, aber wir haben die Architektur jetzt "Synology-proof" und hochfunktional. Der entscheidende Durchbruch war die Abkehr von der automatisierten Konfiguration hin zur **expliziten Architektur-Kontrolle** (Root-User, manuelle JSON-Injektion und Runtime-Bootstrapping).
|
||||
|
||||
Hier ist der destillierte **Setup-Guide 2026** für dein Gitea-Repository.
|
||||
|
||||
---
|
||||
|
||||
# 🦞 Moltbot Synology Deployment Guide (Feb 2026)
|
||||
|
||||
## 1. Strategischer Kontext
|
||||
Dieses Setup dient als Backend für die **GTM-Engine** von RoboPlanet. Es ist darauf optimiert, auf einer Synology DiskStation stabil zu laufen, Berechtigungskonflikte zu vermeiden und eine vollwertige **Python/Pip/Git-Umgebung** für automatisierte Workflows bereitzustellen.
|
||||
|
||||
## 2. Infrastruktur (Host-Ebene)
|
||||
Bevor der Container startet, muss die Verzeichnisstruktur auf der DiskStation exakt so vorbereitet sein. Dies verhindert "Bind mount"-Fehler und sichert die Datenpersistenz.
|
||||
|
||||
```bash
|
||||
# Hauptverzeichnis
|
||||
mkdir -p /volume1/docker/moltbot
|
||||
|
||||
# Unterordner für saubere Trennung
|
||||
mkdir -p /volume1/docker/moltbot/storage # Datenbank & State (~/.clawdbot)
|
||||
mkdir -p /volume1/docker/moltbot/config # Statische Konfiguration
|
||||
mkdir -p /volume1/docker/moltbot/workspace # Arbeitsbereich für Agenten-Scripte
|
||||
mkdir -p /volume1/docker/moltbot/secrets # API-Keys & Zertifikate
|
||||
|
||||
# Rechte-Management (Zwingend für Synology)
|
||||
# Wir setzen 1000:1000 (Node) oder nutzen user:root im Container
|
||||
sudo chown -R 1000:1000 /volume1/docker/moltbot
|
||||
```
|
||||
|
||||
## 3. Konfiguration (Die "Ground Truth")
|
||||
Manuelle Erstellung der Konfiguration, um Validierungsfehler der CLI zu umgehen. Erstelle die Datei `/volume1/docker/moltbot/config/moltbot.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"gateway": {
|
||||
"mode": "local",
|
||||
"bind": "lan",
|
||||
"port": 18789,
|
||||
"auth": {
|
||||
"token": "DEIN_GATEWAY_TOKEN"
|
||||
}
|
||||
},
|
||||
"channels": {
|
||||
"telegram": {
|
||||
"enabled": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 4. Docker-Compose (Die Engine)
|
||||
Die finale `docker-compose.yml`. Zentrale Entscheidungen:
|
||||
- **user: root**: Erforderlich für die Installation von System-Paketen (Python) zur Laufzeit.
|
||||
- **command-Bootstrap**: Installiert Python & Git bei jedem Start, falls das Image aktualisiert wird.
|
||||
- **auth-profiles Injection**: Schreibt den Gemini-Key direkt in den Agent-Speicher.
|
||||
|
||||
```yaml
|
||||
services:
|
||||
openclaw-gateway:
|
||||
image: ghcr.io/openclaw/moltbot:main
|
||||
container_name: openclaw-gateway
|
||||
user: root
|
||||
environment:
|
||||
MOLTBOT_STATE_DIR: /home/node/.clawdbot
|
||||
OPENCLAW_GATEWAY_TOKEN: ${OPENCLAW_GATEWAY_TOKEN}
|
||||
TELEGRAM_BOT_TOKEN: ${TELEGRAM_BOT_TOKEN}
|
||||
GEMINI_API_KEY: ${GEMINI_API_KEY}
|
||||
HOME: /home/node
|
||||
volumes:
|
||||
- /volume1/docker/moltbot/storage:/home/node/.clawdbot
|
||||
- /volume1/docker/moltbot/workspace:/home/node/.clawdbot/workspace
|
||||
- /volume1/docker/moltbot/config/moltbot.json:/home/node/.clawdbot/moltbot.json:ro
|
||||
ports:
|
||||
- "18789:18789"
|
||||
init: true
|
||||
restart: unless-stopped
|
||||
command: >
|
||||
sh -lc '
|
||||
apt-get update && apt-get install -y python3 python3-pip git build-essential
|
||||
mkdir -p /home/node/.clawdbot/agents/main/agent
|
||||
echo "{\"google\": {\"apiKey\": \"$${GEMINI_API_KEY}\"}}" > /home/node/.clawdbot/agents/main/agent/auth-profiles.json
|
||||
exec node dist/index.js gateway --bind lan
|
||||
'
|
||||
|
||||
openclaw-cli:
|
||||
image: ghcr.io/openclaw/moltbot:main
|
||||
container_name: openclaw-cli
|
||||
user: root
|
||||
environment:
|
||||
MOLTBOT_GATEWAY_URL: ws://openclaw-gateway:18789
|
||||
MOLTBOT_GATEWAY_TOKEN: ${OPENCLAW_GATEWAY_TOKEN}
|
||||
volumes:
|
||||
- /volume1/docker/moltbot/storage:/home/node/.clawdbot
|
||||
- /volume1/docker/moltbot/workspace:/home/node/.clawdbot/workspace
|
||||
entrypoint: ["node", "dist/index.js", "--gateway", "ws://openclaw-gateway:18789"]
|
||||
stdin_open: true
|
||||
tty: true
|
||||
```
|
||||
|
||||
## 5. Operative Key-Entscheidungen (Review)
|
||||
1. **Pfad-Konsistenz:** Umstellung von `.openclaw` auf `.clawdbot` (Projekt-Migration 2026 gefolgt).
|
||||
2. **Bind-Parameter:** Wechsel von `0.0.0.0` auf `lan`, da das Gateway-Modul spezifische Keywords für das Interface-Binding verlangt.
|
||||
3. **CLI-Targeting:** Die CLI wurde über den `entrypoint` fest auf den Gateway-Service verdrahtet, um den Loopback-Fehler (`127.0.0.1`) innerhalb des Docker-Netzwerks permanent zu beheben.
|
||||
4. **Pairing-Prozess:** Initialisierung via Telegram erfordert ein einmaliges `pairing approve` über die CLI, um die User-ID des Besitzers zu verknüpfen.
|
||||
|
||||
## 6. Wartung
|
||||
- **Python-Module:** Können über `docker exec -it openclaw-gateway pip install <modul>` nachinstalliert werden.
|
||||
- **Updates:** `docker compose pull && docker compose up -d` (Das Bootstrap-Skript installiert Python automatisch nach).
|
||||
|
||||
---
|
||||
|
||||
[STATUS]
|
||||
Das System läuft. Python ist installiert. Gemini ist autorisiert. Die GTM-Engine ist bereit für den ersten "Whale Hunting" Task. Was ist die erste operative Aufgabe, die der Bot für dich erledigen soll? Gitea-Clone oder Prospecting-Analyse? 🦞
|
||||
Reference in New Issue
Block a user