AdventureLog auf ZimaOS: Fehlerbehebungen für Compose und PostgreSQL

Der Quellthread von 2025 führte nie zu einer bestätigten funktionierenden AdventureLog-Installation. Das Frontend wurde geladen, aber die Registrierung schien nichts zu bewirken. Spätere Protokolle lieferten zwei deutlichere Hinweise: Das Frontend meldete wiederholt: fetch failed mit Verbindungs-Timeouts, während das Backend wiederholt meldete: PostgreSQL ist nicht verfügbar – Wartezeit. Der Datenbankcontainer selbst wurde schließlich initialisiert und lauschte normal.

Diese Hinweise deuten eher auf ein Problem bei der Konnektivität oder Konfiguration mehrerer Dienste hin als auf die einfache Schlussfolgerung „AdventureLog funktioniert nicht auf ZimaOS“. Auch die aktuelle Upstream-Bereitstellung von AdventureLog wurde geändert: Das gepflegte Compose verwendet inzwischen eine .env eine Datei, neueres PostGIS, aktuelle Frontend-/Backend-Images und ein dediziertes Installationsprogramm, das nach den externen Frontend- und Backend-URLs fragt.

Die Quelle verwendete einen Compose-Stack mit drei Diensten

Das Compose-Setup von 2025 enthielt:

ein SvelteKit-Frontend namens web;
einen Django-/Backend-Dienst namens server;
eine PostGIS-/PostgreSQL-Datenbank namens db.

Das Frontend stellte den Host-Port 8015 bereit, das Backend einen weiteren Host-Port, und benannte Docker-Volumes speicherten Datenbank- und Mediendaten.

Die Anwendung schien über die benutzerdefinierte App von ZimaOS erfolgreich installiert worden zu sein, aber der Benutzer konnte den Anmelde-/Registrierungsvorgang nicht abschließen. Ein solches Frontend-Symptom kann folgende Ursachen haben:

das Frontend, das das Backend nicht erreichen kann;
das Backend, das PostgreSQL nicht erreichen kann;
falsche Origin-/CSRF-URLs;
die Startreihenfolge oder den Bereitschaftszustand der Dienste;
einen Reverse-Proxy, der die tatsächlich verwendete externe URL ändert.

Die Quellprotokolle enthielten Belege für die ersten beiden Ebenen, belegten jedoch keine endgültige Grundursache.

Das Frontend lief beim Abrufen wiederholt in einen Timeout

Das Frontend-Protokoll meldete: TypeError: fetch failed und ETIMEDOUT. Das bedeutet, dass der Frontend-Prozess eine erwartete Netzwerkanfrage nicht erfolgreich abschließen konnte.

Das ursprüngliche Compose verwendete PUBLIC_SERVER_URL=http://server:8000, was für die Kommunikation zwischen Diensten innerhalb eines einzelnen Compose-Projekts konzeptionell korrekt ist. Das Ändern anderer URL-Variablen in LAN-Adressen oder Proxy-Domains kann jedoch weiterhin zu Abweichungen zwischen Origin sowie Browser und Backend führen.

Das Backend konnte PostgreSQL zunächst nicht erreichen

Das Backend-Protokoll gab wiederholt Folgendes aus: PostgreSQL ist nicht verfügbar – Wartezeit. Währenddessen zeigte das Datenbankprotokoll, dass PostGIS initialisiert wurde und schließlich bereit war.

Dies stimmt damit überein, dass das Backend gestartet wurde, bevor die Datenbank bereit war, eine falsche DB-Verbindungseinstellung verwendet wurde oder ein Dienstnetzwerkproblem vorlag. Die Quelle enthält nicht genügend Belege, um diese Möglichkeiten eindeutig zu unterscheiden.

Das Hinzufügen eines Cloudflare-Tunnels behob das eigentliche Problem nicht

Der Benutzer versuchte nach der ersten fehlgeschlagenen Installation einen Cloudflare-Tunnel, aber die Anwendung funktionierte weiterhin nicht. Das ist zu erwarten, wenn der zugrunde liegende Pfad zwischen Frontend, Backend und Datenbank unterbrochen ist: Ein öffentlicher Tunnel kann einen Dienst zugänglich machen, repariert jedoch nicht die interne Compose-Netzwerkverbindung.

Aktuelles AdventureLog verwendet ein einfacheres, gepflegtes Compose-Layout

AdventureLogs aktuelles Upstream-Compose verwendet jetzt:

ghcr.io/seanmorley15/adventurelog-frontend:latest;
ghcr.io/seanmorley15/adventurelog-backend:latest;
postgis/postgis:16-3.5;
eine gemeinsame .env Datei für die Dienstkonfiguration;
persistente postgres_data und adventurelog_media Volumes.

Prüfen Sie die aktuelle AdventureLog-Compose-Definition, statt die YAML-Datei aus dem Forum von 2025 unverändert zu kopieren.

Frontend- und Backend-URLs bewusst konfigurieren

Der aktuelle AdventureLog-Installer fragt nach der Frontend-URL und der Backend-URL und leitet daraus die Portkonfiguration ab. Das ist ein starkes Signal dafür, dass URL-/Origin-Werte Teil des Anwendungsvertrags und keine rein kosmetischen Bezeichnungen sind.

Verwenden Sie für eine reine LAN-Konfiguration die tatsächliche ZimaOS-IP-Adresse bzw. den Hostnamen und die gewählten Ports konsistent. Konfigurieren Sie bei einem Reverse-Proxy die öffentlichen HTTPS-URLs konsistent und vermeiden Sie die Vermischung von localhost, LAN-Adressen und öffentliche Domains, ohne zu verstehen, welcher Prozess welchen Wert sieht.

Die Quellpasswörter und den SECRET_KEY nicht beibehalten

Die Compose-Datei aus dem Forum enthielt Platzhalterwerte wie changeme123 für PostgreSQL- und Django-Geheimnisse. Dies sind Beispiele und keine sicheren Produktionszugangsdaten.

Erstellen Sie eindeutige Datenbankzugangsdaten und ein starkes Anwendungsgeheimnis. Wenn ein echtes Geheimnis jemals öffentlich veröffentlicht wurde, ändern Sie es.

Datenbank und Mediendateien vor der Fehlersuche bei Neuinstallationen bewahren

Durch wiederholtes Deinstallieren und Neuinstallieren des Stacks kann ein verwirrender Zustand entstehen, wenn benannte Volumes bestehen bleiben oder unerwartet gelöscht werden. Legen Sie fest, ob das Ziel darin besteht:

die vorhandene Datenbank und die Mediendateien wiederverwenden;
Beginnen Sie mit einer vollständig sauberen Testinstanz.

Sichern Sie alle wichtigen Daten, bevor Sie Docker-Volumes löschen.

Aktuelles ZimaOS verarbeitet Standard-Compose direkter

Der aktuelle ZimaOS App Store 2.0 und die Custom-App-Workflows basieren auf standardmäßigem Docker Compose plus ZimaOS-Metadaten. Das Laufzeitverhalten der Anwendung – Abhängigkeiten, Umgebungsvariablen, Ports, Volumes, Healthchecks und Netzwerke – gehört weiterhin in Compose.

Verwenden Sie das aktuelle ZimaOS-Compose-Modell, wenn Sie AdventureLog anpassen.

AdventureLog-FAQ für ZimaOS

Bestätigte der Quellthread von 2025 eine funktionierende Lösung?

Nein. Der Thread endete, nachdem der Benutzer Frontend-, Backend- und Datenbankprotokolle gepostet hatte.

Was waren die stärksten Hinweise aus den Quellen?

Timeouts beim Abruf durch das Frontend und ein Backend, das wiederholt auf PostgreSQL wartet.

Sollte die alte Compose-Datei von 2025 unverändert wiederverwendet werden?

Nein. AdventureLogs gepflegte Compose-Datei, Images, PostGIS-Version und Konfigurationsmodell haben sich geändert.