D’accord ! J’ai bêtement appliqué la configuration de la page mentionnée ci-dessus, comparé à d’autres fichiers de configuration nginx et je n’arrivais pas à comprendre pourquoi le proxy n’écoutait pas sur 80:443 pour discourse…
Voici ce à quoi je m’attendais :
server {
listen 80;
server_name discourse.mydomain.com;
return 301 https://$host$request_uri; # routage vers https
}
server {
listen 443 ssl
listen [::]:443 ssl;
server_name discourse.mydomain.com;
ssl_certificate /etc/letsencrypt/live/discourse.mydomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/discourse.mydomain.com/privkey.pem;
root /var/www/html;
# Ajoutez index.php à la liste si vous utilisez PHP
index index.html index.htm index.nginx-debian.html;
location / {
proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:; # utilisation du socket
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
}
Pour référence, npm et le nginx proxy manager sont des choses différentes. Vous confondez votre terminologie, et donc les personnes qui essaient de vous aider.
Désolé Stephen pour la confusion, j’ai juste utilisé le nom de l’outil qui est référencé dans l’article. Je comprends que NPM et nginx (en tant que) proxy manager sont des choses différentes, c’est pourquoi j’ai utilisé des majuscules…
C’est exactement ce que j’essaie de faire et je comprends que vous ne puissiez pas m’aider davantage. Cependant, toute indication / lien serait apprécié !
Je ne peux tout simplement pas, Jay : j’essaie d’aider un ami à déployer l’application et je ne peux pas modifier la configuration de son serveur. C’est pourquoi je dois résoudre le problème nginx…
Soit dit en passant, voici ce que je comprends :
Discourse écoute sur les ports 80/443.
nginx joue le rôle de commutateur, acheminant les requêtes vers différentes applications en fonction de leur nom de domaine :
netxcloud.mydomain.com essayant d’atteindre le port 80 → la requête est acheminée vers server_IP:8000
crm.mydomain.com essayant d’atteindre le port 80 → la requête est acheminée vers server_IP:9000
discourse.mydomain.com essayant d’atteindre le port 80 → la requête est acheminée vers http://unix:/var/discourse/shared/standalone/nginx.http.sock: (j’espère que le deux-points final n’est pas une faute de frappe) car le script de configuration a configuré Discourse pour qu’il écoute sur cette socket.
J’essaierai de reconfigurer nginx cet après-midi. Quelqu’un peut-il confirmer la syntaxe exacte pour le socket : http://unix:/var/discourse/shared/standalone/nginx.http.sock: ? Je veux m’assurer que le deux-points final n’est pas une faute de frappe…
En effet… J’ai appliqué dans discourse.conf les modifications que je proposais vendredi dernier et Discourse fonctionne maintenant correctement ! Au moins, je peux accéder à la page d’accueil mais je ne reçois pas le mail d’activation, ce qui n’est pas lié à Discourse (je soupçonne que mon ami n’a pas créé le compte mail demandé ).
Je vous dois un grand merci pour l’aide que vous m’avez apportée et j’espère ne pas revenir sur ce forum trop tôt !
La première chose que je vérifierai est si forums@mydomain.com a été configuré pour envoyer au nom de noreply-forums@mydomain.com, cela doit être vérifié auprès de votre fournisseur de messagerie.
========================================
Discourse 2.9.0.beta9
Discourse version at forums.mydomain.com: Discourse 2.9.0.beta9
Discourse version at localhost: NOT FOUND
==================== DNS PROBLEM ====================
This server reports NOT FOUND, but forums.mydomain.com reports Discourse 2.9.0.beta9 .
This suggests that you have a DNS problem or that an intermediate proxy is to blame.
[... ]
Testing sending to myprivatemail@yahoo.fr using ssl0.ovh.net:465, username:forums@mydomain.com with plain auth.
======================================== ERROR ========================================
UNEXPECTED ERROR
Net::ReadTimeout
====================================== SOLUTION =======================================
Le problème de messagerie pourrait-il être lié au prétendu problème de DNS ? Je n’ai pas de « proxy intermédiaire », j’utilise juste nginx comme serveur proxy web…
C’est probablement votre problème. Pouvez-vous essayer un port différent ? J’ai obtenu les meilleurs résultats avec le port 587 s’il est pris en charge par votre fournisseur de messagerie.
Vous devrez commenter cette ligne ou la définir sur true si vous changez le port pour 587.
Non, mon fournisseur de messagerie (qui est aussi mon fournisseur d’hébergement) n’autorise que le port 465. D’ailleurs, j’ai lu qu’il fallait configurer les enregistrements SPF et DKIM pour le domaine (est-ce un sous-domaine ?) et je n’ai encore rien configuré : cela pourrait-il avoir un impact ?
Je navigue sur le post mais j’ai oublié certaines informations :
Le DNS est géré par notre hébergeur (pour certains services), disons sur ServerA.
Discourse fonctionne sur un autre serveur (ServerB) qui est hébergé par un fournisseur différent.
Ma compréhension est donc la suivante : Discourse sur ServerB se connecte au serveur de messagerie sur ServerA, s’authentifiant avec un email/mot de passe pour utiliser le service SMTP fourni par l’hébergeur de ServerA.
Est-ce une configuration anormale ou puis-je toujours utiliser la configuration email normale de app.yml ici ?
).
