Problèmes avec Discourse 3.5.0.beta2-dev - SMTP et tâches en arrière-plan

Le rapport suivant a été préparé pour moi par ChatGPT, basé sur mon expérience réelle d’installation de Discourse (n’étant pas très calé en technologie, je me suis appuyé sur l’IA pour m’aider dans les tâches qui me sont difficiles). Je n’ai pas besoin d’aide pour le moment, mais j’espère que le rapport pourra servir de retour d’information utile sur la version 3.5.0.beta2-dev.

==================

Chère équipe Discourse,

Je souhaite partager quelques détails de dépannage concernant les problèmes d’e-mail que j’ai rencontrés lors de l’exécution de Discourse 3.5.0.beta2-dev. Je n’ai pas besoin d’assistance directe car j’ai décidé de revenir à la version 3.4.0.beta4-dev, mais j’espère que ce rapport sera utile pour identifier les problèmes potentiels avec la dernière version de développement.


1. Résumé du problème

J’ai effectué une installation propre de Discourse sur une nouvelle instance Vultr, en utilisant le service SMTP de 20i (smtp.stackmail.com). Cependant, les e-mails n’ont jamais été livrés, malgré :

  • Un test de connectivité SMTP réussi (openssl s_client -connect smtp.stackmail.com:587 -starttls smtp).
  • Aucune erreur n’apparaissant dans les journaux de messagerie de 20i (suggérant que Discourse n’envoyait pas réellement d’e-mails).
  • Sidekiq échouant à traiter les tâches d’e-mail.

C’était inattendu car il y a quelques semaines, j’avais installé avec succès Discourse 3.4.0.beta4-dev sur une instance identique sans aucun problème d’e-mail.

Après un débogage approfondi, j’ai découvert que mon installation actuelle avait installé de manière inattendue Discourse 3.5.0.beta2-dev, ce qui a probablement contribué aux problèmes.


2. Problèmes clés identifiés

A. Les e-mails n’étaient pas livrés

  • Les paramètres SMTP étaient corrects, vérifiés par des tests manuels (tests swaks et openssl réussis).
  • Les e-mails étaient mis en file d’attente dans Sidekiq mais jamais reçus.
  • Les journaux de messagerie de 20i n’ont montré aucun rejet ni tentative de livraison (suggérant que les messages n’ont jamais quitté Discourse).
  • Aucune erreur liée aux e-mails n’est apparue dans production.log (grep "smtp" n’a rien retourné).

B. Problèmes Sidekiq et Redis

  • Initialement, Sidekiq ne fonctionnait pas (Sidekiq::Workers.new.size retournait 0).
  • Le redémarrage manuel de Sidekiq (sv restart sidekiq) a échoué car Sidekiq était manquant en tant que service.
  • Redis fonctionnait (redis-cli ping retournait PONG), mais les journaux Discourse affichaient toujours des erreurs de connexion Redis (Errno::ECONNREFUSED).
  • Les journaux Sidekiq indiquaient des échecs de tâches dus à des problèmes de connexion Redis, même si Redis était confirmé comme étant actif.
  • Le démarrage manuel de Sidekiq (bundle exec sidekiq) permettait le traitement des tâches, mais les e-mails n’étaient toujours pas envoyés.

C. Incohérence de version entre les installations

  • Mon installation précédente (qui fonctionnait) était sur 3.4.0.beta4-dev.
  • Mon installation actuelle a installé de manière inattendue 3.5.0.beta2-dev, malgré l’utilisation de la même méthode d’installation.
  • Étant donné que les e-mails fonctionnaient parfaitement dans 3.4.0.beta4-dev, je suspecte une régression ou un changement majeur dans la version 3.5.

3. Actions entreprises (toutes échouées)

Nous avons systématiquement essayé les solutions suivantes :

:white_check_mark: Connectivité SMTP confirmée avec :

openssl s_client -connect smtp.stackmail.com:587 -starttls smtp  # Succès
swaks --to my-email --server smtp.stackmail.com --port 587 --auth LOGIN  # Succès

:white_check_mark: Vérification que les e-mails étaient mis en file d’attente :

Jobs.enqueue(:user_email, type: :test_message, to_address: 'masden@kumagaku.ac.jp')  # Retourne un ID de tâche
Sidekiq::Queue.new("default").size  # Retourne 0 (indiquant que la tâche a été traitée)

:white_check_mark: Vérification des journaux Discourse :

grep "smtp" /shared/log/rails/production.log  # Aucune erreur liée au SMTP
  • Échecs de connexion Redis (Errno::ECONNREFUSED dans production.log).

:white_check_mark: Redémarrage et déclenchement manuel des services :

sv restart sidekiq  # Échec, service manquant
redis-cli ping  # Confirmation du fonctionnement
bundle exec sidekiq  # Tâches traitées mais aucun e-mail envoyé

:white_check_mark: Vérification si les e-mails étaient bloqués par 20i :

  • Aucun rejet ni tentative de livraison dans les journaux de messagerie de 20i.
  • Si les e-mails étaient rejetés, il devrait y avoir une entrée de journal, mais rien n’est apparu.

4. Conclusion : Retour à la version 3.4.0.beta4-dev

Après un dépannage approfondi, j’ai décidé de supprimer l’installation et de réinstaller la version 3.4.0.beta4-dev, car mon installation précédente avait fonctionné sans problème avec cette version.

Bien que je n’aie pas besoin d’aide directe, je voulais signaler ces problèmes car :

  • La gestion des e-mails a peut-être changé dans la version 3.5, empêchant la transmission SMTP.
  • Le service Sidekiq manquant et les erreurs Redis suggèrent des problèmes de traitement des tâches en arrière-plan dans la version 3.5.
  • Étant donné que j’ai pu installer 3.4.0.beta4-dev sans problème, cela suggère une possible régression dans la version 3.5.

J’espère que ce rapport sera utile pour identifier les problèmes potentiels dans Discourse 3.5.0.beta2-dev.

Cordialement,
Kirk

2 « J'aime »

C’était attendu, car c’est la version actuelle.
Beaucoup utilisent la même dernière version, et sidekiq fonctionne, et donc les e-mails aussi.
Vous pourriez donc avoir besoin d’aide, car vous ne pourrez pas non plus reconstruire.
Et une bien meilleure connaissance pourrait prendre en charge ce sujet, mais je dirais que nous avons ici des sujets sur l’arrêt de sidekiq. La recherche peut aider.

4 « J'aime »

Je continue d’avoir des difficultés à installer Discourse. Voici un autre rapport compilé par ChatGPT. Je pense qu’il représente fidèlement mon expérience.


Rapport : Problèmes d’installation de Discourse et service Sidekiq manquant

Contexte :
Nous avons tenté une nouvelle installation de Discourse sur une instance Vultr, dans le but de mettre en place un déploiement stable et fonctionnel. Cependant, nous avons rencontré des problèmes importants, notamment avec des services manquants tels que Sidekiq, ce qui a empêché la livraison des e-mails et le traitement des tâches en arrière-plan.


Résumé des problèmes rencontrés

  1. Version inattendue installée
    • Au lieu de la version attendue v3.4.0.beta4-dev, l’installation a par défaut utilisé tests-passed, téléchargeant une version potentiellement instable.
    • Le fichier VERSION était manquant, rendant difficile de savoir quelle version exacte était installée.
  2. Service Sidekiq manquant
    • Le répertoire /etc/service/sidekiq était absent à l’intérieur du conteneur Discourse.
    • Cela a empêché l’exécution de toutes les tâches en arrière-plan (e-mails, notifications, tâches planifiées).
  3. Problèmes avec le dépôt Git de Discourse
    • L’exécution de git rev-parse --abbrev-ref HEAD à l’intérieur du conteneur a renvoyé tests-passed, confirmant qu’une version non intentionnelle avait été installée.
    • Git a renvoyé une erreur « propriété douteuse détectée » (detected dubious ownership), nécessitant une intervention manuelle (git config --global --add safe.directory /var/www/discourse).
  4. Problèmes potentiels de dépendances
    • Même si une ancienne version de Discourse est extraite, il y a une préoccupation que des dépendances plus récentes (Ruby, Redis, Sidekiq) puissent être téléchargées pendant l’installation, causant potentiellement des problèmes de compatibilité.
    • Si les dépendances de Discourse ne sont pas correctement épinglées, l’installation peut se comporter de manière incohérente entre les environnements.
  5. Limitation du taux de certificats SSL
    • Une tentative d’obtention d’un nouveau certificat SSL Let’s Encrypt a échoué en raison du dépassement de la limite de taux.
    • Cela a empêché le démarrage de Nginx, car il ne pouvait pas charger le fichier de certificat attendu.

Prochaines étapes prévues

  1. Effectuer un nettoyage complet et une réinstallation
    • Supprimer entièrement /var/discourse et cloner à nouveau le dépôt.
    • Extraire manuellement une version stable (par exemple, v3.4.1) avant d’exécuter l’installation.
    • Utiliser ./discourse-setup au lieu de se fier aux valeurs par défaut pour garantir des paramètres corrects.
  2. S’assurer que Sidekiq est installé
    • Avant la reconstruction, vérifier que le service sidekiq est correctement inclus dans le processus de construction.
    • Si Sidekiq est manquant après la reconstruction, vérifier manuellement son installation via bundle list | grep sidekiq.
  3. Épingler les dépendances à des versions stables
    • Éviter les problèmes liés aux dépendances en utilisant explicitement une image Docker Discourse connue pour être stable (par exemple, discourse/discourse:2.0.20240101).
    • Verrouiller les versions des gems à l’intérieur du conteneur (bundle install --deployment --without test development).
  4. Réessayer l’émission du certificat SSL
    • Attendre la réinitialisation de la limite de taux de Let’s Encrypt et retenter la génération du certificat SSL.
    • Si les problèmes persistent, envisager d’utiliser temporairement un certificat auto-signé pour le dépannage.

Demande de commentaires

Compte tenu de ces défis, nous apprécierions les commentaires de l’équipe et de la communauté Discourse concernant :

  • Sidekiq manquant dans /etc/service/ lors d’une nouvelle installation – Quelqu’un d’autre a-t-il rencontré ce problème ?
  • Meilleures pratiques pour assurer la stabilité des dépendances – Existe-t-il une méthode recommandée pour épingler les versions des dépendances pour les installations Discourse ?
  • Problèmes potentiels avec tests-passed installé par défaut – Pourrait-il y avoir un problème avec la manière dont les versions sont récupérées ?

Toute information serait utile avant que nous ne procédions à la réinstallation. Merci d’avance !

Ce n’est pas vraiment instable. C’est la valeur par défaut pour tous les forums maintenant. Discourse ne mettra pas une branche instable par défaut.

Hmm… que voyez-vous lorsque vous allez sur /sidekiq sur votre forum ?

Quelle branche avez-vous l’intention d’installer ? Peut-être que ce guide vous aidera ?

3 « J'aime »

Je pense que ce dont vous avez peut-être besoin, ce sont des détails sur la configuration de votre VPS. CPU, RAM, espace disque et taille du disque, c’est-à-dire Ubuntu LTS 24.

Quand vous dites que vous avez testé le mail, avez-vous utilisé le test de Discourse et reçu un email ?

Dans mon XP dans votre fichier app.yml, vous devriez avoir 3 lignes de configuration principale pour le SMTP.

  • Nom d’utilisateur :
  • Mot de passe
  • PORT

D’après ce que vous avez dit, vous aviez cela fonctionne dans une précédente installation de Discourse ?

Comme mentionné, “Tests-Passed” est la version recommandée à installer. Stable, d’après ce que je comprends, est plus destiné aux personnes avec des plugins et thèmes personnalisés – ce qui pourrait nécessiter des mises à jour plus fréquentes pour éviter la rupture.

Pouvez-vous partager un journal de reconstruction avec des erreurs ? N’oubliez pas de faire défiler vers le haut lors de la capture du journal, car la dernière erreur est simplement un résultat échoué. Vous pouvez toujours masquer des données sensibles comme l’utilisateur SMTP et les détails du mot de passe.

Il y a aussi quelques sujets sur les problèmes SMTP de messagerie qui pourraient avoir des solutions.

1 « J'aime »

Désolé pour ma réponse tardive. Comme je l’ai écrit en réponse à un autre commentaire, je ne suis pas en mesure de fournir des détails sur ma dernière tentative échouée car j’ai effacé une grande partie du logiciel afin de réessayer. Je vous ferai un compte-rendu dès que possible.

Merci pour vos commentaires détaillés. Je m’excuse pour ma réponse tardive.

Je tente une autre installation avec des versions antérieures de divers logiciels. Cela me rend difficile de répondre à vos questions sur ma précédente tentative échouée. Dès que je pourrai terminer ma prochaine installation, je vous ferai un compte rendu.

1 « J'aime »

Quelque chose à considérer comme un test supplémentaire si nécessaire. Créez un compte gratuit sur \u003chttps://www.brevo.com\u003e ; ils ont un niveau de messagerie gratuit de 300 e-mails par jour. J’utilise celui-ci actuellement.

Si vous avez des problèmes pour envoyer des e-mails, cela pourrait aider à tester si cela pourrait être lié à votre fournisseur de messagerie.

2 « J'aime »

TL;DR ne vous fiez pas à ChatGPT, ce sont de fausses alertes.

C’est bien de demander de l’aide, c’est une mauvaise idée de s’y fier, comme je vais le montrer ci-dessous.
Merci de me rassurer que je ne serai pas bientôt au chômage à cause de ChatGPT. :wink:

beta4-dev est aussi potentiellement instable que tests-passed

Il n’y a pas un tel fichier.

Il ne devrait pas y avoir un tel répertoire.

J’en doute.

C’est attendu.

C’est un comportement normal si vous utilisez git sur un répertoire sans en être le propriétaire.

Cela n’a pas de sens. Et tests-passed est plus récent que ce que vous ‘attendiez’, pas plus ancien.

C’est parce que vous avez essayé trop de fois.

6 « J'aime »

Je tiens à souligner ceci.
La plupart du temps, si vous suggérez à ChatGPT qu’il y a des problèmes à trouver, il en trouvera, même s’il n’y en a pas. Il est également rapide à nous faire entrer dans une boucle infinie de « corrections » qu’il suggère continuellement.

5 « J'aime »

Merci beaucoup !

En ce qui concerne l’IA, il est clair que ChatGPT n’a pas été un guide fiable. D’un autre côté, j’ai trouvé le débogage difficile, donc la tentation d’y recourir est grande pour quelqu’un comme moi.

Je viens de terminer une installation réussie. ChatGPT (version payante) n’a pas pu m’amener au but, mais Claude d’Anthropic (également version payante ; j’utilise les deux) l’a finalement fait. Il m’a aidé à corriger des problèmes que ChatGPT avait introduits.

J’essaierai de revenir avec plus d’informations sur mon expérience plus tard. Merci pour tous vos commentaires utiles !

2 « J'aime »

Je suis d’accord. D’après mon utilisation, Claude est beaucoup plus à l’aise et donne généralement une réponse immédiate et correcte.

Je suis content que vous ayez réussi !

5 « J'aime »

Merci ! C’est remarquable à quel point ils peuvent être différents pour certaines tâches – presque comme des personnes avec des personnalités différentes. Claude semble être plus « réfléchi » tandis que ChatGPT a tendance à tirer des conclusions hâtives et à s’emballer un peu plus. J’ai été dans des situations où ChatGPT était meilleur, cependant. J’espère qu’ils s’amélioreront TOUS LES DEUX. L’IA m’a aidé à écrire beaucoup de scripts qui fonctionnent réellement, même si je ne suis pas un auteur de scripts. Elle a le potentiel d’être un excellent outil pour les personnes peu douées en technologie comme moi, mais elle doit absolument s’améliorer. C’est vraiment frustrant d’être mené dans une impasse. : (

4 « J'aime »

Voici un bref rapport sur mon installation réussie avec une question sur la marche à suivre.

Je ne suis toujours pas sûr de la raison pour laquelle j’ai eu des problèmes avec le SMTP lors de mes récentes tentatives. En fait, ma première tentative il y a quelques semaines a été couronnée de succès, mais j’utilisais un serveur Vultr que j’ai décidé être plus grand que nécessaire et la seule façon de le réduire était d’obtenir un nouveau serveur plus petit, puis d’effacer le plus grand.

Selon un e-mail que j’ai reçu, la version de Discourse que j’ai installée il y a quelques semaines était la 3.4.0.beta4-dev. L’e-mail recommandait de passer à la version 3.4.0.beta4.

Comme j’ai eu des problèmes avec le SMTP dans la version 3.4.0.beta4-dev, j’ai pensé tenter d’installer une version stable antérieure de Discourse. En discussion avec ChatGPT (peu fiable, je sais), nous avons décidé d’essayer d’installer la version 3.4.1. Je pensais que cette version serait stable. Voici ce que nous avons fini par installer :

• Version de Discourse : 3.5.0.beta2-dev
• Version de Docker : 23.0.6
• sidekiq : 6.5.12
• Version de PostgreSQL : PostgreSQL 15.12 (Debian 15.12-1.pgdg120+1)
• Version de Redis : 7.0.15
• NGINX : 1.26.2
• Version d’Ubuntu : 22.04 LTS (Jammy Jellyfish)
• Version de Git : 2.39.5

Je pense que, indépendamment de notre intention (c’est-à-dire mon intention assistée par l’IA) d’installer des versions stables antérieures, nous avons fini par installer la version 3.5.0.beta2-dev de Discourse après tout.

Ce fut difficile (beaucoup de faux départs et l’utilisation de commandes données par l’IA pour réparer ce qui ne fonctionnait pas), mais mon Discourse est enfin opérationnel.

Voici quelques questions :

  1. Sauf erreur de ma part, les utilisateurs actuels ne sont pas encore encouragés à passer à la version 3.5.0, probablement parce qu’elle n’est pas encore entièrement testée. Si c’est le cas, pourquoi les nouveaux venus comme moi sont-ils plus ou moins obligés de l’installer ?

  2. Je pense que ma version de Docker est ancienne (obsolète). Dois-je simplement utiliser le terminal pour passer à la dernière version ? Discourse fonctionne maintenant et comme j’ai eu tellement de mal à en arriver là, je ne veux rien faire qui puisse tout gâcher.

  3. Je pense que les autres versions logicielles sont assez récentes. Si vous voyez quelque chose qui pourrait poser problème ou qui nécessite une mise à niveau, veuillez me le faire savoir.

  4. Existe-t-il une page ou une section de cette communauté qui aborde les questions techniques de « soins et maintenance » ? Je veux que ma communauté reste saine et fonctionnelle et être préparé avec des sauvegardes, etc. pour tout problème qui pourrait survenir.

2 « J'aime »

Je viens de terminer une restauration à partir d’une sauvegarde de la communauté Discourse précédente. Cela semble bien s’être passé et il se peut que cela ait également mis à jour Docker (problème mentionné ci-dessus) :

Je m’interroge sur ce message, que je reçois immédiatement après la restauration : « L’envoi d’e-mails a été désactivé pour les utilisateurs non administrateurs. »

En me référant à un autre fil de discussion ici :

J’ai trouvé où modifier le paramètre.

Donc, maintenant, je suppose que tout va bien, mais si possible, j’apprécierais une confirmation. « Non » est le bon réglage, n’est-ce pas ? Je pense que les utilisateurs réguliers doivent recevoir des notifications par e-mail, donc je suis un peu perplexe quant au réglage de désactivation. Je me demande dans quelles situations il serait nécessaire de désactiver les e-mails.

J’ai eu un problème similaire avec des e-mails qui n’étaient pas envoyés sur une toute nouvelle installation de Discourse, que j’ai détaillé ici :

Le problème était que l’adresse e-mail notifications dans app.yml n’avait pas été authentifiée auprès de mon fournisseur SMTP (SendGrid).

Rien n’est apparu dans les journaux principaux de Discourse, ni dans les journaux de SendGrid. L’erreur a été révélée lors de l’exécution de discourse-doctor :

Reason: 550 The from address does not match a verified Sender Identity.

Si vous ne l’avez pas déjà fait, je vous suggère d’exécuter discourse-doctor car cela pourrait vous donner un aperçu plus précis de la raison pour laquelle les e-mails ne sont pas envoyés.

2 « J'aime »

Merci beaucoup !!

Excellent conseil. Je n’étais pas au courant de Discourse-doctor mais je pense que cela m’a peut-être fait gagner beaucoup de temps.

Je le garderai à l’esprit si je rencontre d’autres problèmes. :slight_smile:

1 « J'aime »