Comme vous pouvez le voir sur la capture d’écran, j’ai réussi à “installer” Discourse. Mais je n’arrive pas à attribuer un certificat SSL valide.
Pour information, je fais passer cela par mon NAS Synology avec un proxy inverse qui élève le port 89 au port 443 avec websocket et les ports 89 et 449 (mappés respectivement aux ports 80 et 443 dans app.yml).
Pour autant que je sache, j’ai fait tout ce qui était nécessaire pour tout configurer.
J’ai un certificat pointant vers subdomain.domain.com mais il résout toujours vers domain.com.
Je ne comprends pas tout à fait votre situation actuelle, utilisez-vous Discourse derrière un proxy ? Si oui, vous n’avez probablement qu’à exposer le port 80 et laisser votre serveur proxy gérer le https/ssl.
Cela signifie-t-il que vous déployez Discourse dans un cloud privé/sur site ? Si la réponse est oui, alors un problème courant est d’essayer d’accéder au site sur le réseau local (LAN) par rapport au réseau étendu (WAN). Si c’est votre cas et que l’accès au site depuis un autre réseau semble fonctionner c’est-à-dire essayez simplement d’accéder au site depuis votre réseau mobile, alors consultez ceci ref.
Comment est-il configuré, par Discourse ? Si ce n’est pas par Discourse, alors vous n’avez probablement qu’à exposer le port 80.
Je m’excuse de ne pas avoir apporté les précisions nécessaires.
J’utilise un proxy inverse pour rediriger l’adresse IP 192.168.1.XXX vers un sous-domaine, c’est-à-dire discourse.mydomain.com, donc en bref, oui, c’est sur site.
Il est actuellement inaccessible via le réseau local ou externe (mobile).
Après avoir exécuté sudo netstat -tlnp | grep LISTEN, je vois les ports 89 et 449 listés, mais accéder à l’IP locale, par exemple 192.168.1.XXX:449 (ou 89), ne fonctionne pas.
Et bien sûr, le proxy inverse (depuis le NAS Synology) n’aide pas, donc le sous-domaine que j’ai configuré est une impasse.
Pour une clarification totale, la machine sur laquelle j’essaie d’héberger Discourse est une VM hébergée sur une machine avec XCPNG. Le système d’exploitation de la VM est la dernière version d’Ubuntu Server (CLIN).
Hmm, si je comprends bien, 192.168.1.XXX est votre adresse IP privée sur le réseau local, et vous avez probablement une adresse IP publique que votre FAI vous donne. Donc, pour être clair, dans votre enregistrement DNS, vous devriez avoir votre adresse IP publique pointant vers votre sous-domaine, pas votre adresse IP privée (sur le réseau local), et deuxièmement, votre routeur pourrait avoir besoin d’être configuré pour autoriser le trafic entrant et le router vers votre IP privée 192.168.1.XXX. Et votre FAI devrait autoriser le trafic entrant.
Alternativement, vous pouvez simplement tunneliser votre trafic local vers un serveur distant afin de ne pas avoir à modifier les paramètres de votre routeur ou à vous demander si votre FAI autorise le trafic entrant.
Alors, quel est votre cas, tunnelisation du trafic, ou autorisation du trafic entrant via NAT ou DMZ ?
Je ne suis pas arrivé jusque-là. J’ai rencontré une série d’autres erreurs qui m’ont empêché d’effectuer une bonne installation, je n’ai donc pas pu activer « force_https ».
Je vais devoir passer par une autre voie. Désolé de vous avoir dérangé.
