Installation von Ghost auf YunoHost-Systemen

🧩 Allgemeine Zusammenfassung der typischen Probleme bei einer Ghost‑Installation auf YunoHost per Docker‑Compose

Eine Ghost‑Installation, die unabhängig vom YunoHost‑App‑System per Docker‑Compose betrieben wird, stößt häufig auf mehrere strukturelle Konflikte. Diese entstehen nicht durch Ghost selbst, sondern durch die Architektur von YunoHost, die bestimmte Annahmen über Routing, Authentifizierung und Domain‑Verwaltung trifft. Die wichtigsten Problemfelder lassen sich wie folgt zusammenfassen:

🔐 1. Automatische Authentifizierungs‑ und SSO‑Mechanismen greifen global ein

YunoHost injiziert standardmäßig globale NGINX‑Fragmente für:

• Single‑Sign‑On
• Header‑Manipulation
• Zugriffskontrolle

Diese Regeln werden für alle Domains angewendet – auch für Dienste, die außerhalb des YunoHost‑App‑Systems laufen.
Ein extern gestarteter Ghost‑Container wird dadurch oft:

• falsch umgeleitet
• mit unerwarteten Auth‑Headern konfrontiert
• in seinem SPA‑Routing gestört

🌐 2. Domain‑ und Proxy‑Konfigurationen kollidieren

YunoHost verwaltet Domains zentral und erwartet, dass jede App:

• über das interne App‑System installiert wird
• eigene NGINX‑Snippets erhält
• sich an die YunoHost‑Struktur hält

Ein Docker‑Compose‑Stack, der selbstständig Ports und Routen definiert, kann dadurch:

• von YunoHost‑Regeln überschrieben werden
• unerwartete Redirects erzeugen
• falsche oder doppelte Proxy‑Layer erhalten

🧱 3. Ghosts Single‑Page‑Application‑Routing wird durch Fremdregeln gebrochen

Ghosts Admin‑Interface ist eine SPA und benötigt:

• unveränderte Header
• keine Auth‑Injection
• keine zusätzlichen Rewrite‑Regeln

YunoHost‑Fragmente können dieses Routing unabsichtlich beschädigen, was zu:

• weißen Seiten
• endlosen Redirect‑Loops
• nicht erreichbaren Admin‑Bereichen

führt.

🗄️ 4. Datenbank‑ und Dateipfade passen nicht zur YunoHost‑Struktur

YunoHost erwartet:

• systemweite Pfade
• App‑spezifische Rechte
• definierte Backup‑Strukturen

Ein Docker‑Compose‑Stack bringt dagegen:

• eigene Volumes
• eigene Datenbankcontainer
• eigene Backup‑Mechanismen

Diese beiden Welten harmonieren nicht automatisch.

🧩 5. YunoHost‑Apps und externe Docker‑Apps teilen sich denselben Reverse‑Proxy

Da YunoHost den Reverse‑Proxy kontrolliert, entstehen Konflikte, wenn:

• externe Dienste eigene NGINX‑Configs benötigen
• YunoHost globale Regeln überschreibt
• mehrere Dienste dieselbe Domainstruktur nutzen wollen

🧭 6. Fehlersuche wird erschwert, weil zwei Systeme gleichzeitig eingreifen

Bei Problemen ist oft unklar:

• ob Ghost selbst fehlschlägt
• ob Docker‑Compose falsch konfiguriert ist
• oder ob YunoHost‑Regeln den Dienst beeinflussen

Diese Überlagerung führt zu komplexen Fehlerbildern, die schwer zu isolieren sind.

🟢 Kurzfazit

Ghost läuft in Docker‑Compose grundsätzlich stabil – aber nicht in Kombination mit YunoHost‑Standardmechanismen, die global in Routing, Authentifizierung und Proxy‑Konfiguration eingreifen.
Die Probleme entstehen also nicht durch Ghost, sondern durch die gleichzeitige Nutzung zweier konkurrierender Verwaltungs‑ und Routing‑Systeme.