Ciao, sto cercando di installare Discourse su una VM Ubuntu 20.04 di test appena creata (ho provato anche CentOS Stream 9, Ubuntu 22.04 e openSUSE MicroOS). Ho una certa esperienza con Discourse fin dai primi tempi del progetto e lo sto valutando per una migrazione. In quel caso sarebbe su mydomain.tld (il dominio di produzione è solo un forum e ha “forum” nel nome ed è ben noto come tale, quindi non voglio assolutamente discourse.mydomain.tld). Tutti i miei recenti tentativi di installare Discourse senza un sottodominio sono falliti. So che una volta era possibile perché ho gestito un forum Discourse in quel modo circa 6 anni fa senza sottodominio. Ora l’installazione sembra completarsi con successo, ma il sito non si carica. Su Ubuntu passa automaticamente a https:// anche quando metto esplicitamente http://, e non si carica affatto. Su CentOS e MicroOS carica la pagina di benvenuto di Nginx http://, e nulla si carica con https://.
Tutti i miei tentativi sui sistemi operativi sopra menzionati nella stessa VM funzionano bene quando Discourse è installato su un sottodominio come discourse.mydomain.tld, inclusa la configurazione automatica di Let’s Encrypt. Per quanto ne so, i miei record DNS sono corretti presso il registrar del dominio e ho una corretta risoluzione rDNS. L’hostname del server in /etc/hosts mostra 127.0.1.1 mydomain.tld mydomain e lo script discourse-install ha successo con il controllo di risoluzione del nome di dominio.
Ecco l’output di discourse-doctor, ho anche il log completo di discourse-install se qualcuno lo desidera:
DISCOURSE DOCTOR Sun Oct 9 13:32:47 UTC 2022
OS: Linux mydomain 5.4.0-125-generic #141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Found containers/app.yml
==================== YML SETTINGS ====================
DISCOURSE_HOSTNAME=mydomain.tld
SMTP_ADDRESS=mail.mydomain.tld
DEVELOPER_EMAILS=REDACTED
SMTP_PASSWORD=REDACTED
SMTP_PORT=587
SMTP_USER_NAME=admin@mydomain.tld
LETSENCRYPT_ACCOUNT_EMAIL=REDACTED
==================== DOCKER INFO ====================
DOCKER VERSION: Docker version 20.10.12, build 20.10.12-0ubuntu2~20.04.1
DOCKER PROCESSES (docker ps -a)
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d6f7f53a81db local_discourse/app \"/sbin/boot\" 10 minutes ago Up 4 minutes 0.0.0.0:80-\u003e80/tcp, :::80-\u003e80/tcp, 0.0.0.0:443-\u003e443/tcp, :::443-\u003e443/tcp app
Discourse container app is running
==================== PLUGINS ====================
- git clone https://github.com/discourse/docker_manager.git
No non-official plugins detected.
See https://github.com/discourse/discourse/blob/main/lib/plugin/metadata.rb for the official list.
========================================
Discourse version at mydomain.tld: NOT FOUND
Discourse version at localhost: NOT FOUND
==================== MEMORY INFORMATION ====================
OS: Linux
RAM (MB): 2029
total used free shared buff/cache available
Mem: 1935 823 547 30 564 934
Swap: 2047 0 2047
==================== DISK SPACE CHECK ====================
---------- OS Disk Space ----------
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 38G 8.0G 28G 23% /
==================== DISK INFORMATION ====================
Disk /dev/sda: 38.15 GiB, 40961572864 bytes, 80003072 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6643DB1B-E542-4DE1-A04C-C8EB4DAAD77E
Device Start End Sectors Size Type
/dev/sda1 528384 80003038 79474655 37.9G Linux filesystem
/dev/sda14 2048 4095 2048 1M BIOS boot
/dev/sda15 4096 528383 524288 256M EFI System
Partition table entries are not in disk order.
==================== END DISK INFORMATION ====================
==================== MAIL TEST ====================
For a robust test, get an address from http://www.mail-tester.com/
Mail test skipped.
==================== DONE! ====================
Ciao, grazie per la risposta. OK, è una buona idea, sembra che non accetti la connessione:
$ curl -v mydomain.tld
* Trying 1.2.3.4:80...
* connect to 1.2.3.4 port 80 failed: Connection refused
* Failed to connect to mydomain.tld port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to mydomain.tld port 80: Connection refused
$ curl -v https://mydomain.tld
* Trying 1.2.3.4:443...
* connect to 1.2.3.4 port 443 failed: Connection refused
* Failed to connect to mydomain.tld port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to mydomain.tld port 443: Connection refused
È possibile che sia dovuto a qualche limitazione nella logica di configurazione di Discourse, dove si aspetta che .tld sia qualcosa di comune come .com o .org? Il mio è solo un dominio $5 .tech che ho creato per testare.
Dove è ospitato il server? Cosa si trova tra esso e il client?
Fornirci il FQDN ci aiuta a risolvere alcuni problemi. Così com’è, ci stai chiedendo di aiutarti a diagnosticare questo problema mentre siamo bendati, quindi potrebbe volerci un po’ per individuarlo.
Ho usato discourse-setup. Sì, le porte sono aperte. L’installazione su un sottodominio funziona bene, e ho anche configurato un’installazione Docker di un mailserver con un frontend web sulla stessa VM (ma l’ho poi riformattata).
Hmm no. Il registrar è Hover, di solito sono piuttosto bravi. È bizzarro, in 20 anni di configurazione di server non ho mai avuto problemi con siti web alla radice di un dominio…
Potresti provare a scambiare il tuo NS con Cloudflare e testare se il problema è il DNS da lì gratuitamente.
Scusa la domanda stupida, intendi impostare il mio DNS locale su Cloudflare? (Attualmente sto usando 8.8.8.8) O usare un servizio DNS diverso per il mio dominio?
Ho chiesto a Hover e mi hanno indirizzato a questo:
Quello che potresti fare è provare a usare un record Glue. Questo renderà il tuo server il gestore DNS e instraderà il nome di dominio a un nameserver che puoi configurare usando i record Glue. In pratica, il tuo server diventa il nameserver.
Questo mi sembra ancora un depistaggio. Non capisco perché Discourse non dovrebbe funzionare alla radice del dominio nella stessa situazione in cui Wordpress o Drupal funzionerebbero?
No, intendo che non devi spostare il tuo dominio tra i registrar, ma dovrai aggiornare i record NS su Hover per far puntare il tuo dominio al DNS di un provider diverso per testare questa teoria. Al momento sono impostati su ns1.hover.com e ns2.hover.com
È un processo molto rapido e piuttosto indolore. Se ti iscrivi a CloudFlare, prova ad aggiungere il dominio lì e ti forniranno due nuovi name server che dovranno essere inseriti su Hover. C’è una guida per il lato Hover qui:
È passato un po’ di tempo da quando ho usato l’apice con qualcosa di diverso da CloudFlare. Lo testerò tra poco per vedere se riesco a individuare altre insidie. La maggior parte dei problemi con l’apice si applicano ai cname, ma ora posso vedere che stai usando un record a.
La mia migliore ipotesi è che tu abbia eseguito una serie di ricompilazioni con qualcosa di configurato in modo errato e ora Let’s Encrypt non rilascerà un certificato a causa del limite di frequenza.
Se è così, puoi aspettare una settimana o provare a usare www come sottodominio, cosa che in realtà è una buona idea di questi tempi.
Puoi controllare i log in /var/discourse/shared/log/var-log/nginx/access.log o forse
docker logs app
Mi aspetto che tu veda problemi con il certificato non esistente o non valido.
Per ora ho disabilitato SSL in app.yml e ho eseguito una ricostruzione, e Discourse ora si sta caricando sulla porta 80 senza un sottodominio.
Sto anche usando ora Hetzner DNS come autorevole. Non sono sicuro se questo abbia fatto la differenza o se sia stato il problema del certificato Let’s Encrypt fallito. Riferirò di nuovo dopo un’altra ricostruzione una volta che sarò in grado di creare nuovamente certificati Let’s Encrypt e riabilitare SSL.
Se hai provato a ricostruire più di un paio di volte, probabilmente stai subendo un limite di frequenza da parte di Let’s Encrypt. Puoi aggirare questo problema aggiungendo un altro nome host al tuo certificato.
Sì, ma credo che quelle indicazioni non funzionino più.
Il motivo per cui non ti connetti alla porta 443 è che il certificato è danneggiato e causa un errore in nginx.
Grazie a tutti per le risposte rapide. Sembra che fosse solo una questione del limite di frequenza di Let’s Encrypt. Ho creato un nuovo dominio su Hover e questa volta l’installazione di Discourse ha funzionato bene senza un sottodominio.
Ciao di nuovo @pfaffman o chiunque altro, domanda stupida: il certificato Let’s Encrypt viene aggiornato ogni volta che eseguo ./launcher rebuild app? In altre parole, andrò incontro a ulteriori limitazioni di frequenza se faccio un po’ di tentativi ed errori e ricostruisco (ma non ricomincio completamente da zero) la mia istanza Discourse più volte di seguito? Grazie mille.