Il thread della fonte del 2025 non è mai arrivato a una conferma di installazione funzionante di AdventureLog. Il frontend si caricava, ma la registrazione sembrava non fare nulla. I log successivi mostravano due indizi più significativi: il frontend riportava ripetutamente: fetch failed con timeout di connessione, mentre il backend ripeteva PostgreSQL non è disponibile: attesa. Il container del database alla fine si è inizializzato e ascoltava normalmente.
Questi elementi indicano un problema di connettività/configurazione tra più servizi, non una semplice conclusione del tipo «AdventureLog non funziona su ZimaOS». Anche la distribuzione upstream attuale di AdventureLog è cambiata: il Compose mantenuto ora utilizza un .env file, PostGIS più recente, immagini frontend/backend aggiornate e un installer dedicato che richiede gli URL esterni del frontend e del backend.
La fonte utilizzava uno stack Compose a tre servizi
Il Compose del 2025 conteneva:
- un frontend SvelteKit chiamato
web; - un servizio Django/backend chiamato
server; - un database PostGIS/PostgreSQL chiamato
db.
Il frontend esponeva la porta host 8015, il backend esponeva un'altra porta host e i volumi Docker denominati memorizzavano i dati del database e dei file multimediali.
Il sintomo visibile era una schermata di registrazione che non faceva nulla
L'applicazione sembrava installarsi correttamente da App personalizzata di ZimaOS, ma l'utente non riusciva a superare la schermata di accesso/registrazione. Questo tipo di sintomo frontend può essere causato da:
- il frontend che non riusciva a raggiungere il backend;
- il backend che non riusciva a raggiungere PostgreSQL;
- URL di origine/CSRF errati;
- l'ordine di avvio o lo stato di salute dei servizi;
- un reverse proxy che modificava l'URL esterno effettivo;
I log della fonte contenevano elementi a supporto dei primi due livelli, ma non stabilivano una causa principale definitiva.
Il frontend continuava ad andare in timeout durante il recupero
Il log del frontend riportava TypeError: fetch failed e ETIMEDOUT. Ciò significa che il processo frontend non riusciva a completare una richiesta di rete che avrebbe dovuto andare a buon fine.
Il Compose originale utilizzava PUBLIC_SERVER_URL=http://server:8000, cosa concettualmente corretta per la comunicazione tra servizi all'interno dello stesso progetto Compose. Tuttavia, modificare altre variabili URL usando indirizzi LAN o domini proxy può comunque creare discrepanze tra origine e browser/backend.
Inizialmente il backend non riusciva a raggiungere PostgreSQL
Il log del backend stampava ripetutamente PostgreSQL non è disponibile: attesa. Nel frattempo, il log del database mostrava l'inizializzazione di PostGIS, che alla fine risultava pronto.
Ciò è compatibile con un backend avviato prima che il database fosse pronto, un'impostazione di connessione al DB errata o un problema di rete tra i servizi. La fonte non contiene elementi sufficienti per distinguere con certezza queste possibilità.
L'aggiunta di un Cloudflare Tunnel non ha risolto il problema all'origine
L'utente ha provato un Cloudflare Tunnel dopo il primo tentativo di installazione non riuscito, ma l'applicazione continuava a non funzionare. È normale se il percorso frontend ↔ backend ↔ database sottostante è interrotto: un tunnel pubblico può esporre un servizio, ma non ripara la rete interna di Compose.
AdventureLog utilizza una struttura Compose gestita più semplice e attuale
L'attuale configurazione Compose upstream di AdventureLog ora utilizza:
-
ghcr.io/seanmorley15/adventurelog-frontend:latest; -
ghcr.io/seanmorley15/adventurelog-backend:latest; -
postgis/postgis:16-3.5; - un
.envfile per la configurazione dei servizi; - persistenti
postgres_dataeadventurelog_mediavolumi.
Consulta la definizione Compose corrente di AdventureLog invece di copiare alla lettera il file YAML del forum del 2025.
Configura deliberatamente gli URL del frontend e del backend
L'installer corrente di AdventureLog richiede l'URL del frontend e l'URL del backend e ricava da questi la configurazione delle porte. Questo è un forte segnale che i valori URL/origine fanno parte del contratto dell'applicazione, non sono semplici etichette.
Per una configurazione limitata alla LAN, usa l'IP o il nome host effettivo di ZimaOS e le porte scelte in modo coerente. Per un proxy inverso, configura in modo coerente gli URL HTTPS pubblici ed evita di mescolare localhost, gli indirizzi LAN e i domini pubblici senza capire quale processo visualizza ciascun valore.
Non mantenere le password di origine e SECRET_KEY
La configurazione Compose del forum includeva valori segnaposto come changeme123 per i segreti di PostgreSQL e Django. Sono esempi, non credenziali sicure per la produzione.
Genera credenziali univoche per il database e un segreto applicativo robusto. Se un segreto reale è mai stato pubblicato, sostituiscilo.
Mantieni il database e i contenuti multimediali prima di risolvere i problemi delle reinstallazioni
Disinstallare e reinstallare ripetutamente lo stack può creare uno stato difficile da interpretare se i volumi denominati persistono o vengono eliminati inaspettatamente. Decidi se l'obiettivo è:
- riutilizzare il database e i contenuti multimediali esistenti;
- inizia con un'istanza di test completamente pulita.
Esegui un backup di tutto ciò che è importante prima di eliminare i volumi Docker.
ZimaOS corrente gestisce Compose standard in modo più diretto
L'App Store 2.0 corrente di ZimaOS e i flussi delle app personalizzate si basano su Docker Compose standard più i metadati ZimaOS. Il comportamento dell'applicazione in esecuzione—dipendenze, variabili d'ambiente, porte, volumi, stato di salute e reti—rimane definito in Compose.
Usa il modello Compose corrente di ZimaOS quando adatti AdventureLog.
Domande frequenti su AdventureLog su ZimaOS
La discussione originale del 2025 ha confermato una soluzione funzionante?
No. La discussione si è conclusa dopo che l’utente ha pubblicato i log del frontend, del backend e del database.
Quali erano gli indizi più significativi nella fonte?
Timeout durante le richieste del frontend e un backend che continua ad attendere PostgreSQL.
È opportuno riutilizzare invariata la vecchia configurazione Compose del 2025?
No. La configurazione Compose gestita di AdventureLog, le immagini, la versione di PostGIS e il modello di configurazione sono cambiati.
