Come puoi vedere dallo screenshot, sono riuscito a far “installare” Discourse. Ma non riesco ad assegnare un certificato SSL valido.
Per la cronaca, sto instradando questo attraverso il mio Synology NAS con un proxy inverso che eleva la porta 89 a 443 con websocket e la porta 89 e 449 (mappate rispettivamente a 80 e 443 in app.yml)
Per quanto ne so, ho fatto tutto quello che dovevo fare per configurarlo.
Ho un certificato puntato a subdomain.domain.com ma si risolve ancora in domain.com,
Non capisco appieno la tua situazione attuale, stai eseguendo Discourse dietro un proxy? Se sì, allora probabilmente devi solo esporre la porta 80 e lasciare che il tuo server proxy gestisca https/ssl.
Ciò significa che stai distribuendo Discourse su cloud privato/on-premise? Se la risposta è sì, allora un problema comune è cercare di accedere al sito su LAN vs WAN, se questa è la tua causa e accedere al sito da un’altra rete sembra funzionare cioè prova solo ad accedere al sito dalla tua rete mobile allora controlla questo ref .
Come è configurato, da Discourse? Se non da Discourse, allora probabilmente devi solo esporre la porta 80.
Sto utilizzando un reverse proxy per instradare l’indirizzo IP 192.168.1.XXX a un sottodominio, ad esempio discourse.mydomain.com, quindi in breve sì, è on-premise.
Attualmente è inaccessibile tramite LAN o WAN (mobile).
Dopo aver eseguito sudo netstat -tlnp | grep LISTEN, vedo le porte 89 e 449 elencate, ma recarsi all’IP locale, ad esempio 192.168.1.XXX:449 (o 89), non funziona.
E naturalmente il reverse proxy (dal Synology NAS) non aiuta, quindi il sottodominio che ho configurato è un vicolo cieco.
Per totale chiarezza, la macchina su cui sto tentando di ospitare Discourse è una VM ospitata su una macchina con XCPNG. Il sistema operativo della VM è l’ultima versione di Ubuntu Server (CLIN).
Hmm, se ho capito bene, 192.168.1.XXX è il tuo indirizzo IP privato in LAN e probabilmente hai un indirizzo IP pubblico, che ti fornisce il tuo ISP. Quindi, solo per essere chiari, nel tuo record DNS dovresti avere il tuo indirizzo IP pubblico impostato per puntare al tuo sottodominio, non al tuo indirizzo IP privato (in LAN), e secondariamente il tuo router potrebbe dover essere configurato per consentire il traffico in entrata e instradarlo al tuo IP privato 192.168.1.XXX. E il tuo ISP dovrebbe consentire il traffico in entrata.
In alternativa, puoi semplicemente creare un tunnel per il tuo traffico locale verso un server remoto in modo da non dover modificare le impostazioni del tuo router o preoccuparti se il tuo ISP consente il traffico in entrata.
Quindi, qual è il tuo caso, tunnel di traffico o consentire il traffico in entrata tramite NAT o DMZ?
Non sono arrivato così lontano. Ho riscontrato una serie di altri errori che mi hanno impedito di effettuare una buona installazione, quindi non sono stato in grado di attivare “force_https”.
Dovrò trovare un’altra strada. Mi dispiace disturbare.
