Salut, j’essaie d’installer Discourse sur une VM Ubuntu 20.04 fraîche de test (j’ai aussi essayé CentOS Stream 9, Ubuntu 22.04 et openSUSE MicroOS). J’ai une certaine expérience avec Discourse depuis les débuts du projet, et je l’évalue actuellement pour une migration. Dans ce cas, ce serait vers mydomain.tld (le domaine de production n’est qu’un forum et contient “forum” dans son nom et est bien connu comme tel, donc je ne veux absolument pas de discourse.mydomain.tld). Toutes mes tentatives récentes d’installation de Discourse sans sous-domaine ont échoué. Je sais que c’était possible car j’ai exécuté un forum Discourse de cette manière il y a environ 6 ans sans sous-domaine. Maintenant, l’installation semble se terminer avec succès, mais le site ne se charge pas. Sous Ubuntu, il passe automatiquement à https:// même lorsque j’ai explicitement mis http://, et il ne se charge pas du tout. Et sous CentOS et MicroOS, il charge la page d’accueil Nginx http://, et rien ne se charge avec https://.
Toutes mes tentatives sur les systèmes d’exploitation ci-dessus dans la même VM fonctionnent bien lorsque Discourse est installé sur un sous-domaine à discourse.mydomain.tld, y compris la configuration automatique de Let’s Encrypt. Pour autant que je puisse en juger, mes enregistrements DNS sont corrects chez le registraire de domaine et j’ai une résolution rDNS appropriée. Le nom d’hôte du serveur dans /etc/hosts affiche 127.0.1.1 mydomain.tld mydomain et le script discourse-install réussit la vérification de la résolution du nom de domaine.
Voici la sortie de discourse-doctor, j’ai aussi le journal complet de discourse-install si quelqu’un le souhaite :
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! ====================
Difficile d’aider sans connaître le domaine. Que se passe-t-il lorsque vous essayez un curl verbeux depuis une autre machine sur Internet vers votre domaine.tld ?
Salut, merci pour la réponse. OK, c’est une bonne idée, il semble qu’elle n’accepte pas la connexion :
$ 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
Est-ce que cela pourrait être dû à une limitation dans la logique de configuration de Discourse où il s’attend à ce que .tld soit quelque chose de commun comme .com ou .org ? Le mien est juste un domaine $5 en .tech que j’ai créé pour tester.
Où est hébergé le serveur ? Qu’est-ce qui se trouve entre lui et le client ?
Nous fournir le FQDN nous aide à résoudre le problème. Tel quel, vous nous demandez de l’aide pour diagnostiquer cela tout en étant bandés, donc cela peut prendre un certain temps pour le déterminer.
J’ai utilisé discourse-setup. Oui, les ports sont ouverts. L’installation sur un sous-domaine fonctionne bien, et j’ai également configuré une installation Docker d’un serveur de messagerie avec une interface web sur cette même VM (mais je l’ai ensuite reformatée).
Hmm non. Le registraire est Hover, ils sont normalement assez bons. C’est bizarre, en 20 ans de configuration de serveurs, je n’ai jamais eu de problèmes avec des sites Web à la racine d’un domaine…
Vous pourriez essayer d’échanger votre NS vers CloudFlare et tester si le problème vient du DNS à partir de là, sans frais.
Désolé pour la question stupide, voulez-vous dire configurer mon serveur DNS local sur Cloudflare ? (J’utilise actuellement 8.8.8.8) Ou utiliser un service DNS différent pour mon domaine ?
J’ai interrogé Hover à ce sujet, et ils m’ont dirigé vers ceci :
Ce que vous pourriez faire, c’est essayer d’utiliser un enregistrement Glue. Cela fera de votre serveur le gestionnaire DNS et dirigera le nom de domaine vers un serveur de noms que vous pouvez configurer à l’aide d’enregistrements Glue. Essentiellement, votre serveur devient le serveur de noms.
Cela me semble toujours être une fausse piste. Je ne comprends pas pourquoi Discourse ne fonctionnerait pas à la racine du domaine dans la même situation où Wordpress ou Drupal fonctionneraient ?
Non, je veux dire que vous n’avez pas besoin de déplacer votre domaine entre les bureaux d’enregistrement, mais vous devrez mettre à jour les enregistrements NS chez Hover pour que votre domaine pointe vers le DNS d’un autre fournisseur afin de tester cette théorie. Actuellement, ils sont définis sur ns1.hover.com et ns2.hover.com
C’est un processus très rapide et assez indolore. Si vous vous inscrivez à CloudFlare, puis essayez d’y ajouter le domaine, ils vous donneront deux nouveaux serveurs de noms qui devront être saisis chez Hover. Il y a un guide pour le côté Hover ici :
Cela fait un moment que je n’ai pas utilisé l’apex avec autre chose que CloudFlare. Je vais tester cela moi-même dans un instant pour voir si je peux repérer d’autres pièges. La plupart des problèmes avec l’apex s’appliquent aux cnames, mais je vois maintenant que vous utilisez un enregistrement a.
Ma meilleure supposition est que vous avez effectué un certain nombre de reconstructions avec une mauvaise configuration et que maintenant Let’s Encrypt ne délivrera pas de certificat en raison de limitations de débit.
Si c’est le cas, vous pouvez attendre une semaine ou essayer d’utiliser www comme sous-domaine, ce qui est vraiment une bonne idée de nos jours de toute façon.
Vous pouvez consulter les journaux dans /var/discourse/shared/log/var-log/nginx/access.log ou peut-être
docker logs app
Je m’attends à ce que vous constatiez des problèmes avec le certificat inexistant ou invalide.
Pour l’instant, j’ai désactivé le SSL dans app.yml et j’ai reconstruit, et Discourse se charge maintenant sur le port 80 sans sous-domaine.
J’utilise également maintenant Hetzner DNS comme autorité. Je ne suis pas sûr si cela a fait la différence ou si c’était le problème de certificat Let’s Encrypt échoué. Je ferai un nouveau rapport après une autre reconstruction une fois que je pourrai recréer des certificats Let’s Encrypt et réactiver le SSL.
Si vous avez essayé de reconstruire plus de deux fois, vous êtes probablement limité par letsencrypt. Vous pouvez contourner ce problème en ajoutant un autre nom d’hôte à votre certificat.
Oui, mais je pense que ces instructions ne fonctionnent plus.
La raison pour laquelle vous ne vous connectez pas au port 443 est que le certificat est défectueux et provoque une erreur dans nginx.
Merci à tous pour vos réponses rapides. Il semble que ce n’était effectivement qu’une question de limite de débit de Let’s Encrypt. J’ai créé un nouveau domaine sur Hover et cette fois, l’installation de Discourse a fonctionné correctement sans sous-domaine.
Salut @pfaffman ou à toute autre personne, question stupide : le certificat Let’s Encrypt est-il mis à jour à chaque fois que j’exécute ./launcher rebuild app ? En d’autres termes, vais-je rencontrer d’autres limitations de débit si je fais quelques essais et erreurs et que je reconstruis (mais sans repartir complètement de zéro) mon instance Discourse plusieurs fois de suite ? Merci beaucoup.