Controllo del tuo nome di dominio . . .
ATTENZIONE: La porta 443 del computer non sembra essere accessibile utilizzando il nome host: ***.com.
ATTENZIONE: Anche la connessione a http://shoutam.com (porta 80) non riesce.
Questo suggerisce che ***.com si risolve in un indirizzo IP che non raggiunge questa
macchina su cui stai installando discourse.
La prima cosa da fare è confermare che ***.com si risolva nell’indirizzo IP di questo server.
Di solito lo fai nello stesso posto in cui hai acquistato il dominio.
Se sei sicuro che l’indirizzo IP si risolva correttamente, potrebbe essere un problema di firewall.
Una ricerca sul web per “aprire porte IL TUO SERVIZIO CLOUD” potrebbe aiutarti.
Questo strumento è progettato solo per le installazioni più standard. Se non riesci a risolvere
il problema sopra descritto, dovrai modificare tu stesso containers/app.yml e poi digitare
./launcher rebuild app
Qualcuno può aiutarmi a risolvere questo problema? Sto usando Cloudflare.
[quote=“Bhanu Sharma, post:2, topic:281990, username:itsbhanusharma”]dovrai configurare discourse per utilizzare il modello cloudflare.
[/quote]
Ma non sarai comunque in grado di installare, poiché Let’s Encrypt richiede l’accesso diretto alle porte 80 e 443 per emettere un certificato.
Dopo aver ottenuto il tuo certificato e aver installato Discourse, puoi cercare argomenti su come farlo funzionare con cloudflare in mezzo (che include l’utilizzo del modello cloudflare).
Ottima osservazione, non si tratta di Let’s Encrypt ma del client acme.sh utilizzato in Discourse che necessita di accesso diretto (certbot ha plugin DNS che richiedono lavoro aggiuntivo ma eliminano questo requisito). Non ci ho pensato perché praticamente ogni installazione di Discourse che ho distribuito negli anni ha richiesto l’uso di un reverse proxy, da qui il template SSL interno disabilitato in anticipo.
Non sono sicuro di cosa intendi con rimosso, ma di solito ci vogliono un paio d’ore perché il DNS si propaghi. Potrebbe valere la pena aspettare un po’ e poi riprovare.
Mancano parecchie informazioni qui per poterti offrire un maggiore aiuto.
Oggigiorno Cloudflare non fallisce in modalità proxy (nuvola arancione) finché HTTPS non è impostato su strict, poiché sia :80 (HTTP) che :443 (HTTPS) vengono passati direttamente al server.
Strict forza il traffico su :80 a essere reindirizzato a SSL, e quindi la sfida fallirebbe.
È molto probabile che tu abbia trascurato uno o più dei fondamenti, ma senza dirci dove si trova il VPS e cosa hai configurato all’interno del DNS, al massimo potremo fare delle ipotesi su cosa sta succedendo qui.
Alcuni provider richiedono che vengano impostati degli ACL tra il loro VPS e il mondo esterno: hai verificato che queste porte siano aperte esternamente? Sei sicuro che il record ‘a’ che hai aggiunto al DNS sia all’indirizzo IP pubblico che è stato allocato? Ci sono firewall presenti?
È vero con alcuni provider DNS, certo, ma Cloudflare impone una TTL di 300 secondi su qualsiasi indirizzo che proxy. Ciò significa che i server DNS upstream avranno scaduto i vecchi record entro cinque minuti dalla modifica.
Tutto ciò che fa il template è garantire che vengano estratti i corretti IP client dalle informazioni aggiuntive dell’header che Cloudflare aggiunge quando la modalità proxy è abilitata, non è realmente rilevante per il processo di installazione.
Se hai eseguito una ricostruzione alcune volte con la nuvola arancione, allora probabilmente hai raggiunto i limiti di frequenza con Let’s Encrypt. Le soluzioni semplici sono usare un sottodominio diverso o aspettare una settimana.
Funzionerà se distruggo il droplet e ne creo uno nuovo?
Nota che ho installato correttamente discourse prima di questo problema, ma ho distrutto quel droplet perché c’era un errore nell’email dell’amministratore. Ora non riesco a installare discourse usando lo stesso processo che ho usato prima.
Riporto in vita questa discussione sperando che gli esperti commentatori possano aiutarmi anche me.
Sto riscontrando lo stesso errore dell’OP originale.
Attualmente utilizzo Unraid e ho un container che esegue Nginix Proxy Manager. Le porte del firewall sono configurate per inviare tutto il traffico delle porte 80/443 al mio container NPM. Ho configurato con successo molti container Docker con il mio container NPM e tutto ha funzionato bene.
Ho installato una VM UbuntuServer, ho seguito la configurazione iniziale, ho impostato un IP statico per la VM, ho installato Docker, quindi ho scaricato Discourse, ma ho riscontrato un errore nello script di configurazione proprio come l’OP.
Se vuoi usare Nginx Proxy Manager dovrai configurare il tuo app.yml manualmente. Puoi disattivare il tuo proxy abbastanza a lungo da far eseguire discourse-setup la prima volta (dovrai comunque cambiare alcune cose manualmente) oppure copiare da samples/standalone.yml.
Sì, per quanto ne so, i file yml si popolano dopo l’esecuzione e il completamento di discourse-setup. Per ottenere questo, forse posso indirizzare il traffico WAN sul mio firewall alla mia UbuntuVM su cui sto installando discourse, quindi dopo la sua configurazione, riportare il mio traffico al reverse proxy e quindi configurare il mio file app.yml.
Ho dimenticato questo. Puoi usare l’opzione --skip-connection-test per saltare quel test ed eseguirlo. Dovrai comunque modificare le porte manualmente, ma ti permetterà di usare lo script per creare il file e inserire le tue credenziali SMTP.