Je suis d’accord. Le lanceur pourrait-il être modifié pour avertir de ce problème ou le bloquer la semaine prochaine, @falco ?
Je rencontre le même problème. Pourriez-vous préciser exactement comment il faut renommer le fichier .yml ?
Faut-il inclure le TLD et le sous-domaine dans le nom du fichier yml ? Pour ce site, serait-ce meta.discourse.org.yml ?
Renommez-le en meta_discourse_org.yml.
Le seul . dans le nom de votre fichier doit précéder l’extension.
Merci pour les précisions. J’ai modifié le nom du fichier et reconstruit, mais je ne vois toujours aucune lightbox ni aucun survol pour afficher la légende sur les images.
De quel fichier de journal s’agit-il ? Je tente de confirmer s’il s’agit du même problème.
J’ai également l’option « Forcer votre site à utiliser uniquement HTTPS » activée et le port 80 bloqué sur le pare-feu.
cd /var/discourse
./launcher enter app
tail -f /shared/log/rails/production.log
Voir également cet article concernant les journaux Discourse.
Si cela ne concerne que les publications existantes, mais que les images nouvellement publiées sont correctes, alors il m’a été utile d’exécuter :
rake uploads:recover_from_tombstone
rake posts:rebake
Veuillez également consulter cela.
Tout cela est vraiment utile, merci.
Il semble que je rencontre le même problème avec l’erreur impossible d'accéder à '/uploads/default...
La ligne suivante de mon fichier de journal est
Démarrage de GET "/posts/950" pour 127.0.0.1 le 2020-07-07 08:24:05 +0000
Avez-vous des idées sur la raison pour laquelle le mien essaie via l’adresse IP de boucle locale et non via le conteneur nouvellement nommé ou l’adresse IP locale du conteneur ?
Cela semble spécifique aux installations non standard qui, simultanément :
-
N’ont pas utilisé
./discourse-setupet ont créé un fichier yml manuellement -
Utilisent un proxy inverse
-
Ce proxy inverse est configuré de manière magique en utilisant un nom de conteneur Docker
Je déconseille de modifier le nom de conteneur déterministe actuel pour tout le monde afin de résoudre ce cas particulier, sauf si cela peut également se produire en ajoutant simplement un point supplémentaire au nom du fichier yml.
Je l’ai en fait utilisé, mais j’ai renommé le fichier plus tard car j’exécute deux instances de Discourse et, autrement, les deux seraient appelées app dans la même instance Docker.
Je pense qu’il est raisonnable de renommer le fichier comme le domaine utilisé.
C’est probablement assez courant pour les petites communautés d’exécuter plusieurs sites sur un seul serveur.
C’était le proxy inverse qui a causé le problème de nom. C’était Docker lui-même car il ajoute automatiquement le nom du conteneur à son DNS interne. Le problème était que le nom du conteneur Discourse dans Docker était le même que son nom DNS externe (par exemple app.yml → meta.discourse.org.yml).
Je propose d’afficher au moins un avertissement fort si le nom du fichier correspond au nom de domaine donné dans le fichier .yml.
Je rencontre toujours le même problème : je ne parviens pas à accéder à l’image pour obtenir ses dimensions.
Impossible d’accéder à ‘/uploads/default/original/1X/9385b0977b09b0f2239c287de980b6fc238d0da0.png’ pour obtenir ses dimensions.
Cela se produit avec une installation entièrement standard utilisant ./discourse-setup
Avez-vous d’autres idées pour résoudre ce problème ?
Que se passe-t-il si vous essayez de télécharger l’image dans votre application Discourse ?
./launcher enter app
wget https://yourdomain.com/uploads/default/original/1X/9385b0977b09b0f2239c287de980b6fc238d0da0.png
La résolution de nom pointe-t-elle vers la bonne adresse IP ?
apt-get update
apt-get install inetutils-ping
ping yourdiscoursedomain.com
ou
apt-get update
apt-get install dnsutils
nslookup yourdiscoursedomain.com
Encore merci pour ton aide, Michael, c’est très apprécié.
Je parviens à faire un ping sur le domaine, mais il semble que wget tente de passer par un proxy web.
J’ai suivi ce guide et ajouté la variable no-proxy à tous les endroits pertinents.
Est-ce que j’aurais oublié quelque chose ? Comment configurer le conteneur pour qu’il n’utilise pas le proxy web du serveur ? Dois-je ajouter une exception no-proxy dans app.yml ?
J’ai ajouté mon domaine au paramètre no-proxy dans le fichier app.yml et reconstruit l’application ; cela ignore désormais le proxy comme requis.
Je rencontre toujours des erreurs lorsque j’exécute wget depuis l’application :
ATTENTION : Le certificat de ‘MYDOMAIN.com’ n’est pas approuvé.
ATTENTION : Le certificat de ‘MYDOMAIN.com’ n’a pas d’émetteur connu.
Cela est dû au fait que mon certificat SSL provient d’une autorité de certification interne. Lorsque j’exécute la même commande wget avec l’option --no-check-certificate, cela fonctionne correctement.
Comment puis-je soit ajouter le certificat pour qu’il soit approuvé, soit ajouter l’option pour désactiver la vérification ?
@Michael_Uray sais-tu où je dois ajouter l’AC racine pour permettre au conteneur Discourse de faire confiance au certificat SSL ?
J’ai suivi ce guide (https://www.techrepublic.com/article/how-to-install-ca-certificates-in-ubuntu-server/), mais je pense qu’il s’applique au serveur lui-même et non au conteneur exécutant Discourse.
Vous devez absolument entrer dans le conteneur et l’ajouter manuellement si vous n’utilisez pas de proxy inverse, mais je pense que cela ne sera pas persistant de cette manière. Je suppose que vous devez l’ajouter d’une manière ou d’une autre au fichier app.yml ou rendre persistant le chemin CA correspondant dans le conteneur via app.yml.