Il rebuild non ha fatto nulla, continua a rifiutare HTTPS e, in più, sono tornato alla pagina di benvenuto di NGINX su HTTP.
Di sicuro hai nginx installato.
Hai provato
apt purge nginx
o
dpkg -l |grep nginx
?
Dopo aver interrotto nginx, cosa dice ./discourse-doctor?
Restituito: nginx non installato
Restituito: Nothing
Tutti gli input (come Email, indirizzo web) sono vuoti
E ci sono 2 container in esecuzione sulle porte: 80 → 80, 443 → 443 e 2222 → 22
Dice che l’app del container Discourse è in esecuzione
E dice che la versione di Discourse NON È TROVATA
Ops, non ho scrollato giù, lasciami leggere il testo di output e vedere cosa dice.
EDIT: Dice la stessa cosa
Hai avviato questo forum eseguendo ./discourse-setup?
Di cosa si tratta?
Intendi se ho seguito il processo di configurazione (cosa che ho fatto), o se non ho eseguito ./discourse-doctor, che è invece ciò che ho fatto.
Mi sono sbagliato, ce n’era solo uno, ed è 4efab95a60b8
Ora la pagina HTTP dice solo che non sono stati inviati dati, quindi ora non c’è nemmeno la pagina NGINX.
EDIT: Siamo tornati alla pagina nginx.
EDIT2: Dimenticate, non siamo più lì.
Cosa mostra docker ps?
Esattamente lo stesso contenitore del file di testo.
Forse un reverse proxy con caddy sarebbe meglio in questo scenario?
Volevo sapere il nome di cosa fosse. Il numero qui è senza significato.
In passato ho avuto successo con Caddy. Probabilmente avrà lo stesso problema, però.
Ecco un suggerimento.
Iscriviti al droplet da $5 su DigitalOcean. Segui alla lettera la guida all’installazione, senza copiare certificati aggiuntivi o altro.
I droplet di DO sono proporzionati al tempo d’uso: se segui la guida (che richiede 30 minuti o meno), il costo per verificare l’installazione è di 0,02 $. Se non desideri mantenere l’istanza, basta premere il pulsante di distruzione.
Se il problema persiste, potremo iniziare a diagnosticarlo.
Se invece funziona, dimostra che non si tratta di un problema di Discourse. Se scegli di utilizzare un ambiente più complesso, purtroppo accetti anche la responsabilità delle sfide aggiuntive che comporta. L’installazione standard è stata verificata sull’immagine Ubuntu su DO e la loro politica di rete non causa problemi con Let’s Encrypt (anche se a volte richiede un intervento moderato per l’invio di email).
Tieni presente che se hai richiesto e ripetuto più volte lo stesso nome di certificato, è possibile che Let’s Encrypt abbia messo quel particolare FQDN in periodo di raffreddamento.
Beh, alla fine ce l’ho fatta. Ecco cosa ho fatto. Ho installato Caddy e configurato un proxy per reindirizzare tutte le connessioni dall’URL a localhost:444, ma non era quello. Sono andato nel file app.yml e ho modificato la Porta in questo modo:
- "81:80" - HTTP spostato sulla porta 81 per riservarla a Caddy
- "444:443" - Caddy gestirà HTTPS
Poi, quando vado sul sito web, si carica e non nega più la connessione HTTPS!
Grazie a tutti coloro che hanno aiutato e lasciato suggerimenti!
Lo farò sicuramente, se dovrò reinstallare Discourse.