Je fais cela pour configurer Discourse : ./discourse-setup, mais je rencontre l’erreur montrée dans l’image.
Comment puis-je corriger cette erreur ? J’utilise Ubuntu 18.04
Vous avez un caractère non imprimable dans le nom d’hôte que vous avez saisi :
Réessayez, mais assurez-vous de le saisir correctement. Si vous copiez-collez, vérifiez que la source est propre.
1 « J'aime »
Il semble que vous ayez déjà WordPress en cours d’exécution sur cette adresse IP.
Oui, WordPress est installé. Puis-je utiliser les deux sur le même serveur ?
C’est possible, mais pas facile. Vous ne pouvez pas utiliser discourse-setup. Je vous recommande de d’abord essayer sur un serveur qui ne fait pas tourner autre chose.
Exécuter d’autres sites web sur la même machine que Discourse.
1 « J'aime »
J’ai suivi ces étapes, mais je n’ai obtenu aucun résultat. Par ailleurs, j’utilise WEBMIN.
Quelqu’un a-t-il d’autres idées ?
Si les instructions du sujet que j’ai lié plus tôt ne fonctionnent pas pour vous, la solution la plus simple est d’exécuter Discourse sur un serveur dédié.
Il sera très difficile de le faire fonctionner avec Webmin.
Je sais que ce sera difficile, mais je ne me considère pas comme un amateur. J’ai essayé les instructions que vous avez liées. Y a-t-il d’autres liens que je devrais lire ?
Il y a quelques sujets howto sur la question.
1 « J'aime »
Salut @Murto,
À titre d’information, je trouve que Discourse, en tant qu’application Rails en backend, est beaucoup plus simple à configurer si vous paramétrez Rails pour utiliser un socket de domaine Unix plutôt qu’un port TCP/IP, et si vous placez l’application Discourse derrière un proxy inverse.
De cette façon, les ports TCP/IP sont exposés uniquement via le proxy inverse, tandis que l’application Discourse (et le conteneur) est exposée via un socket de domaine Unix ; vous pouvez ainsi exécuter autant d’instances de conteneurs Discourse que vous le souhaitez sans vous soucier de conflits de sockets TCP/IP. À mon avis, c’est une méthode très propre pour faire fonctionner Discourse.
Il existe de nombreux guides et tutoriels sur ce site pour vous aider à mettre cela en place si vous êtes bloqué et souhaitez changer légèrement d’approche. Il y a un modèle « socket » dans la distribution Discourse que vous pouvez utiliser pour configurer la « partie Discourse de la configuration » ; il ne vous reste plus qu’à configurer le proxy inverse (il existe d’innombrables tutoriels sur la façon de le faire) et « c’est parti ! ».
J’espère que cela vous aidera.
4 « J'aime »
Je n’ai toujours pas réussi à résoudre le problème. Y a-t-il quelqu’un qui puisse expliquer en détail ? 
Essayez ceci :
netstat -lnptu | grep :443
puis :
kill -9 PID (remplacez PID par le numéro affiché par la commande ci-dessus)
1 « J'aime »
Je vous conseille de placer un proxy inverse sur votre serveur exposé à Internet, et de configurer ce proxy pour rediriger vers WordPress ou Discourse selon le nom d’hôte.
Par exemple, exécutez un service Nginx utilisant les ports 80 et 443 sur l’hôte, et configurez-le pour faire proxy des requêtes vers blog.votredomaine vers le service WordPress (soit sur un port interne de votre hôte, si vous utilisez Apache + WordPress, auquel cas vous pouvez rediriger vers le port Apache, comme 8080, soit en utilisant FastCGI).
Ensuite, sur le même serveur, vous pouvez exécuter Discourse, en veillant à remplacer les ports dans app.yml par des ports inutilisés sur l’hôte, comme 8081, ou utiliser un socket Unix comme l’a suggéré @neounix, puis faire proxy des requêtes vers forum.votredomaine vers ce port ou vers le socket. Pour exécuter Discourse, vous devrez lancer ./launch rebuild app dans le répertoire de Discourse (qui devrait être /var/discourse).
Dans ce cas, vous n’exécuterez pas discourse-setup pour créer un fichier d’échange de 2 Go (principalement utilisé pour les mises à niveau, qui peuvent nécessiter plus de mémoire, bien que vous n’en ayez peut-être pas besoin si votre serveur dispose de beaucoup de mémoire) ni pour créer le fichier app.yml. À la place, vous devez le faire vous-même. Si vous ne savez pas quoi mettre dans le fichier app.yml, je vous recommande d’exécuter l’installation recommandée sur un serveur séparé, même si c’est uniquement pour vous familiariser davantage avec Discourse et pour voir le fichier app.yml généré, que vous pourrez utiliser sur votre serveur partagé (en n’oubliant pas de modifier les ports ou de les supprimer si vous utilisez l’approche par socket).
Je vous conseille de suivre l’un des sujets howto à ce sujet si vous ne parvenez pas à avancer.
2 « J'aime »
Pouvez-vous m’expliquer comment procéder à l’inversion du proxy ? J’ai appris quoi faire, mais je ne sais pas comment le faire.
Je n’ai pas d’exemple sous la main car je n’utilise pas de proxy devant, bien que je pense l’avoir mis en place il y a quelque temps. En tout cas, il n’y a pas de secret, cela devrait se faire comme pour les autres proxys inversés. Ce qui suit n’est qu’un aperçu de ce qui doit être fait en utilisant des ports (et non des sockets) :
-
Assurez-vous d’avoir un service WordPress en cours d’exécution sur un port autre que 80 et 443 (exemple : 8443) et fonctionnel. Vous pouvez d’abord essayer de l’exposer à Internet pour vérifier qu’il fonctionne.
-
Faites de même avec Discourse, en mappant sur des ports différents.
Changement :
expose:
- "80:80" # http
- "443:443" # https
Vers (par exemple) :
expose:
- "8081:80" # http
- "8444:443" # https
Dans votre fichier app.yml (si vous ne l’avez pas, je vous conseille d’exécuter Discourse sur une machine autonome en suivant le guide officiel juste pour voir comment cela fonctionne, et d’examiner le fichier app.yml généré dans /var/discourse/containers/). Voici un exemple de fichier app.yml : discourse_docker/samples/standalone.yml at master · discourse/discourse_docker · GitHub
- Installez nginx et, dans son fichier de configuration, ajoutez les directives de proxy. Elles devraient être similaires à l’extrait d’exemple suivant :
upstream blog {
server localhost:8080;
}
server {
server_name blog.barinaklar.com;
server_tokens off;
listen 80;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
return 301 https://blog.barinaklar.com$request_uri;
}
}
server {
server_name blog.barinaklar.com;
server_tokens off;
listen 443 ssl;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
proxy_pass http://blog;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
upstream forum {
server localhost:8081;
}
server {
server_name forum.barinaklar.com;
server_tokens off;
listen 80;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
return 301 https://forum.barinaklar.com$request_uri;
}
}
server {
server_name forum.barinaklar.com;
server_tokens off;
listen 443 ssl;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
proxy_pass http://forum;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Cela suppose que WordPress tourne sur le port 8080 et Discourse sur le port 8081. Assurez-vous de mettre en place un pare-feu pour bloquer l’accès à ces ports (les fournisseurs de cloud bloquent généralement tous les ports par défaut, sauf le 22, donc cela pourrait ne pas être nécessaire).
Dans ce cas, vous êtes responsable de la génération des certificats SSL/TLS (vous pouvez le faire avec certbot exécuté périodiquement dans une tâche cron, c’est pourquoi j’ai déjà inclus les chemins /.well-known/acme-challenge/ dans la configuration nginx).
Comme mentionné ci-dessus, il s’agit d’un simple aperçu et il se peut que j’aie oublié quelque chose. Vous devez porter une attention particulière à l’URL de base en raison du changement de ports (pour vérifier qu’il ne tente pas de rediriger l’utilisateur vers https://votredomaine:8081 au lieu de https://votredomaine, et apporter les modifications nécessaires si besoin).
Cela pourrait ne pas être nécessaire si WordPress s’exécute dans un conteneur avec le port 80 ou 443 à l’intérieur du conteneur. Avec Discourse, cela devrait aussi aller. Le problème qui pourrait survenir concerne https, il pourrait rediriger vers http car il utilise le port http dans le proxy, vous devrez donc vérifier si cela se produit et le corriger dans ce cas.
3 « J'aime »
Merci pour votre aide. Je vais faire la demande et vous tenir informé des transactions.