Inizialmente ho provato a eseguire Discourse con impostazioni semi-predefinite e ha funzionato abbastanza bene, sono stato in grado di caricare file e fare altre cose.
Poi ho notato che il percorso in app.yml era /var/discourse e l’ho aggiornato a /var/www/discourse, ho fermato e distrutto il container, rimosso completamente la cartella precedente. E l’ho rimesso in funzione… ma ho notato che ora non riesco più a caricare file.
Che tipo di permessi necessita la cartella uploads? Posso fare alcune modifiche manualmente, ma vorrei sapere esattamente cosa e se va bene in generale (il launcher non dovrebbe occuparsi di impostare i permessi corretti, specialmente quando viene avviato da zero?)
Il percorso /var/www/discourse è il percorso di discourse all’interno del container. /var/discourse è il percorso normale per Discourse_docker al di fuori del container.
Dato che hai appena iniziato, ti consiglierei di ricominciare da capo e di non rinominare nulla questa volta.
La mia ipotesi è che tu non abbia aggiornato il percorso nel tuo app.yml e quindi stia cercando di accedere a qualcosa che non esiste.
Ho molti altri progetti su questo server e sono tutti ben posizionati nella mia cartella /var/www, quindi preferisco mantenerla così E non mi interessa come sia all’interno del container.
Ma l’ho aggiornato? In mounts, o dove altro dovrebbe andare?
Va bene, non ha funzionato nulla, quindi ho finito per cambiare i permessi della cartella uploads in 755 e ora va tutto bene. Dopo la ricompilazione, sembra che gli upload stessi fossero a posto (dal lato del motore), tuttavia nginx non è stato in grado di leggerli.
Non capisco del tutto perché stai facendo tutto questo. È una tua scelta mettere un container in un percorso che sarà visibile a livello mondiale se commetti un piccolo errore, ma questa è una tua scelta. Ma tutto il resto… perché?
Avere un reverse proxy davanti a Discourse è davvero banale e altrimenti la tua configurazione sarebbe un’installazione standard senza tutta questa fatica. Certo, se vuoi giocare e questo è il tuo hobby, ma molto presto qualcuno si presenterà e dirà che puoi ottenere supporto solo per un’installazione standard e il problema più grande è che nessuno sa davvero cosa hai fatto. O perché.
Stai risolvendo un problema che hai riscontrato quando hai iniziato a fare qualcos’altro, cosa che uno standard richiede. Anche con un proxy inverso.
Ecco perché sei piuttosto lontano dallo standard Perché ci sono due opzioni:
hai un bug tra le mani che nessun altro ha
hai fatto qualcosa di strano
Forse è un bug. E lo hai confermato facendo un’installazione standard usando un percorso sicuro (in molti modi) e allo stesso tempo collegando correttamente il tuo proxy inverso. Perché se è ancora rotto, posso scommettere che il problema è nell’host virtuale e/o nelle porte. Ma se funziona… allora siamo tornati all’opzione “strano” - dove nessuno sa cosa hai fatto.
Vedi il problema qui?
In ogni caso, l’uso di un proxy inverso porta a nessun supporto… questa è la politica qui. Ma altri utenti possono e molto spesso aiuteranno.
E non mi interessa come sia all’interno del container.
La situazione è la stessa con il container Docker.
