Concordo, il launcher potrebbe essere modificato per avvisare di questo problema o bloccarlo la prossima settimana @falco?
Anche io ho lo stesso problema; puoi chiarire esattamente come rinominare il file .yml?
È necessario includere il TLD e il sottodominio come parte del nome del file yml? Per questo sito sarebbe meta.discourse.org.yml?
Rinominalo in meta_discourse_org.yml.
L’unico punto . nel nome del file deve precedere l’estensione.
Grazie per aver chiarito. Ho modificato il nome del file e ricompilato, ma non vedo ancora alcuna lightbox o effetto hover per mostrare la didascalia su nessuna immagine.
Di quale file di log si tratta? Sto cercando di confermare se si tratta dello stesso problema.
Ho anche attivato l’opzione “Forza l’uso di HTTPS solo per il tuo sito” e bloccato la porta 80 sul firewall.
cd /var/discourse
./launcher enter app
tail -f /shared/log/rails/production.log
Vedi anche questo articolo relativo ai log di Discourse.
Se ciò accade solo ai post esistenti, ma le immagini pubblicate di recente sono corrette, allora per me ha aiutato eseguire
rake uploads:recover_from_tombstone
rake posts:rebake
Vedi anche lì.
Tutto molto utile, grazie.
Sembra che io abbia lo stesso problema con l’errore can't reach '/uploads/default...
La riga successiva del mio file di log è
Started GET "/posts/950" for 127.0.0.1 at 2020-07-07 08:24:05 +0000
Qualche idea sul perché il mio sistema stia provando attraverso l’IP di loopback e non attraverso il contenitore appena rinominato o l’IP locale del contenitore?
Questo sembra essere specifico per installazioni non standard che contemporaneamente:
-
Non hanno utilizzato
./discourse-setupe hanno creato manualmente un file yml -
Stanno utilizzando un reverse proxy
-
Questo reverse proxy è configurato magicamente utilizzando un nome di container Docker
Sconsiglio di modificare il nome deterministico corrente del container per tutti per risolvere questo caso limite, a meno che non possa verificarsi anche semplicemente aggiungendo un punto in più al nome del file yml.
In realtà l’ho usato, ma ho rinominato il file in seguito, poiché ho due istanze di Discourse in esecuzione e, altrimenti, entrambe sarebbero state chiamate “app” nella stessa istanza Docker.
Ho ritenuto ragionevole rinominare il file in base al dominio utilizzato.
Probabilmente è piuttosto comune per le comunità più piccole eseguire più siti su un singolo server.
Non è stato il reverse proxy a causare il problema del nome, ma Docker stesso, poiché aggiunge automaticamente il nome del contenitore al proprio DNS interno. Il problema era che il nome del contenitore Discourse in Docker era lo stesso del nome DNS esterno (ad esempio app.yml → meta.discourse.org.yml).
Propongo di mostrare almeno un avviso forte se il nome del file corrisponde al nome di dominio fornito nel file .yml.
Sto ancora riscontrando lo stesso problema: non riesco ad accedere all’immagine per ottenere le dimensioni.
Impossibile accedere a ‘/uploads/default/original/1X/9385b0977b09b0f2239c287de980b6fc238d0da0.png’ per ottenerne le dimensioni.
Questo accade con un’installazione completamente standard eseguita tramite ./discourse-setup
Avete altre idee su come risolvere il problema?
Cosa succede se provi a scaricare l’immagine all’interno della tua applicazione Discourse?
./launcher enter app
wget https://yourdomain.com/uploads/default/original/1X/9385b0977b09b0f2239c287de980b6fc238d0da0.png
La risoluzione del nome punta al corretto indirizzo IP?
apt-get update
apt-get install inetutils-ping
ping yourdiscoursedomain.com
o
apt-get update
apt-get install dnsutils
nslookup yourdiscoursedomain.com
Grazie ancora per il tuo aiuto, Michael, è molto apprezzato.
Posso fare il ping del dominio con successo, ma sembra che wget stia cercando di passare attraverso un proxy web.
Ho seguito questa guida e aggiunto la variabile no-proxy in tutti i punti rilevanti.
Sto dimenticando qualcosa? Come configuro il contenitore per non utilizzare il proxy web del server? Devo aggiungere una regola no-proxy in app.yml?
Ho aggiunto il mio dominio al parametro no-proxy nel file app.yml e ho eseguito la ricostruzione: ora il proxy viene ignorato come richiesto.
Sto ancora riscontrando errori quando eseguo wget all’interno dell’app:
ATTENZIONE: Il certificato di ‘MYDOMAIN.com’ non è attendibile.
ATTENZIONE: Il certificato di ‘MYDOMAIN.com’ non ha un’autorità di certificazione nota.
Questo perché il mio certificato SSL proviene da una CA interna. Quando eseguo lo stesso comando wget con l’opzione --no-check-certificate, funziona correttamente.
Come posso aggiungere il certificato per renderlo attendibile o aggiungere l’opzione per non effettuare il controllo?
@Michael_Uray sai dove devo aggiungere la CA radice per consentire al contenitore Discourse di fidarsi del certificato SSL?
Ho seguito questa guida, ma penso che si applichi al server stesso e non al contenitore in cui viene eseguito Discourse.
Se non utilizzi un reverse proxy, devi assolutamente entrare nel contenitore e aggiungerlo lì, ma credo che in questo modo non rimarrà persistente. Immagino che tu debba aggiungerlo in qualche modo all’app.yml oppure rendere persistente il percorso CA corrispondente all’interno del contenitore tramite l’app.yml.