Incompatibilité du certificat de l'hôte de messagerie provoquant une surcharge de la file d'attente sidekiq, une instabilité grave du site

J’héberge Discourse moi-même depuis de nombreuses années, et j’ai eu plusieurs instances configurées et fonctionnant correctement sur une machine assez puissante.

Aujourd’hui, j’ai remarqué que l’un de mes forums était hors service. Le coupable initial semblait être un manque d’espace disque, que j’ai résolu. J’ai ensuite redémarré l’instance Discourse.

Cependant, elle continue de tomber en panne régulièrement depuis. Chaque fois que je la démarre, je vois immédiatement sidekiq s’emballer et un grand nombre de tâches d’e-mail échouées, ce qui provoque également le stockage d’une quantité massive d’état par redis, ce qui, je pense, était la cause réelle du problème d’espace disque. (Je vais faire un flush la prochaine fois que je pourrai démarrer la machine, car sinon je serai rapidement à court d’espace sur cette machine et je ne pourrai même pas démarrer Discourse pour le vider. Mais le flush ne semble pas réduire beaucoup l’utilisation de l’espace disque de redis.)

Le message d’erreur indique quelque chose concernant une incompatibilité de nom de certificat, ce que je trouve un peu surprenant car le serveur de messagerie que j’utilise est interne et ne nécessite ni TLS ni authentification. J’ai pu vérifier sur une de mes autres instances (utilisant la même configuration d’e-mail) que les e-mails avaient cessé de fonctionner. Tout ce que je vois dans les journaux de production principaux est une erreur 422, mais lorsque j’envoie quelque chose comme une réinitialisation de mot de passe, je vois une erreur similaire dans les journaux de sidekiq :

Jobs::HandledExceptionWrapper: Wrapped OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)

J’ai pu vérifier que je peux envoyer des e-mails via la ligne de commande, donc cela ne semble pas être un problème avec le serveur de messagerie lui-même, juste quelque chose qui ne fonctionne pas avec la configuration de Discourse.

Voici la configuration d’e-mail d’origine qui fonctionnait jusqu’à récemment :

DISCOURSE_SMTP_ADDRESS: outbound-relays.techservices.illinois.edu
DISCOURSE_SMTP_PORT: 25
DISCOURSE_SMTP_ENABLE_START_TLS: false

Encore une fois, ce serveur de messagerie est interne et ne nécessite ni nom d’utilisateur ni mot de passe, et ces paramètres fonctionnaient jusqu’à récemment. J’ai expérimenté avec DISCOURSE_SMTP_OPENSSL_VERIFY_MODE, mais je ne peux pas dire s’il est encore pris en charge. Quoi qu’il en soit, cela ne semble pas aider. J’ai remarqué quelques nouveaux paramètres d’e-mail qui ont été ajoutés depuis que j’ai configuré ces forums, mais ils ne semblent pas nécessaires étant donné la configuration de ce serveur de messagerie.

Toute aide serait appréciée ! À ce stade, j’ai honnêtement même du mal à être sûr de ce qui ne va pas ou à itérer, car la reconstruction du conteneur prend du temps et le message d’erreur dans les journaux de production n’a que l’erreur 422 et je n’arrive pas à trouver où chercher la cause réelle. (Elle doit être quelque part, n’est-ce pas ? Je suis sûr que je la rate juste.)

1 « J'aime »

Pour information, suite aux conseils d’un autre fil de discussion, cette commande envoie correctement des e-mails depuis l’intérieur du conteneur Docker :

echo message | s-nail -r "noreply@myforum.com" -s testing -S "smtp=same.email-service.com:25" my@address.com

Ce qui correspond à la configuration de messagerie que j’utilisais lorsque ce problème a commencé. Notez que j’ai également effectué une mise à niveau vers la dernière version de Discourse via une commande de récupération en ligne de commande (requise) vendredi, ce qui me fait me demander si un commit récent n’a pas introduit ce problème.

2 « J'aime »

Quand avez-vous reconstruit le conteneur pour la dernière fois ?

Avez-vous également vidé la file d’attente Redis ?

2 « J'aime »

Vendredi matin, je crois. Une mise à jour normale via l’interface utilisateur a déclenché la nécessité d’une reconstruction de l'application lanceur. Lorsque j’ai examiné les journaux de sidekiq plus tard, il semblait que la file d’attente ait commencé au moment où le conteneur a été reconstruit, mais il a fallu environ 24 heures pour que les journaux Redis consomment tout l’espace de stockage disponible sur l’hôte et provoquent effectivement une interruption. Cependant, le forum était probablement lent avant cela, étant donné que sidekiq essayait désespérément de renvoyer un nombre croissant de tâches d’e-mails échouées avec une utilisation du CPU à 100 %.

Oui.

Cependant, cela m’inquiète que cela n’ait pas semblé réduire l’utilisation du disque par Redis. J’ai un dossier redis_data qui fait actuellement 29 Go, même après le vidage. Peut-être que Redis est comme MongoDB, où il peut être difficile de lui faire retourner les allocations de disque ? Étant donné que cela représente 1/3 du disque disponible sur la machine, cela deviendra un problème, mais je vais reporter cela pour l’instant afin de simplement rétablir le fonctionnement des e-mails.

1 « J'aime »

En tant que note de débogage : Existe-t-il un moyen d’envoyer un e-mail de test depuis la ligne de commande à l’intérieur du conteneur, en utilisant le même flux de code que celui utilisé par Discourse ? (C’est-à-dire, pas depuis la ligne de commande en utilisant un autre outil, ce que j’ai déjà vérifié fonctionner.) Cela serait utile pour le débogage, car actuellement, l’envoi d’un e-mail de test nécessite de manipuler l’interface utilisateur web, puis de chercher dans les journaux pour comprendre ce qui n’a pas fonctionné. (Et jusqu’à présent, je n’ai trouvé que les erreurs 422, et rien de plus utile, sauf dans les journaux sidekiq qui ne sont pas créés lors de l’utilisation du flux d’e-mail de test.) Ou peut-être que l’interface de test d’e-mail pourrait afficher plus d’informations de débogage ?

Dans l’ensemble, je soupçonne que la plupart des gens configurent Discourse et n’arrivent pas à ce stade sans que l’e-mail fonctionne, car il est nécessaire pour envoyer les invitations initiales, etc. Mais je trouve la débogabilité limitée dans le cas où l’e-mail fonctionnait et s’arrête soudainement. (De plus, la logique de nouvelle tentative pourrait nécessiter un réglage, car elle semble beaucoup trop rapide pour réessayer dans ce cas. Une erreur de certificat est probablement peu susceptible d’être corrigée quelques secondes après la tentative initiale…)

1 « J'aime »

Peut-être consulter Dépannage des e-mails sur une nouvelle installation de Discourse. Je pense que vous voulez

 rake emails:test[user@domain]
3 « J'aime »

Merci ! C’est utile. Voici le résultat :

Testing sending to user@domain using outbound-relays.techservices.illinois.edu:25, username: with plain auth.
======================================== ERROR ========================================
                                    UNEXPECTED ERROR

SSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)

====================================== SOLUTION ========================================
This is not a common error. No recommended solution exists!

Please report the exact error message above to https://meta.discourse.org/
(And a solution, if you find one!)
=======================================================================================

Je vais reconstruire le conteneur maintenant pour m’assurer qu’il et app.yml sont synchronisés. Mais dans l’ensemble, je suis un peu confus quant à la raison pour laquelle il indique qu’il utilise l’authentification simple, car ni le nom d’utilisateur ni le mot de passe ne sont fournis dans le fichier de configuration app.yml.

Vaut-il la peine de reclasser cela comme un bug ? J’étais hésitant au début, car il s’agit d’e-mails et il y a de nombreuses façons dont cela pourrait mal se comporter, dont beaucoup seraient une combinaison de ma faute / de changements externes. Mais AFAICT, cela représente une configuration qui a fonctionné pendant plusieurs années et qui s’est soudainement arrêtée lors d’une mise à niveau vers la dernière édition de discourse_docker. Est-il possible que quelque chose dans la façon dont les fichiers de configuration sont traités ait changé récemment ?

Concernant le message d’erreur lui-même, j’ai pu obtenir un certificat pour cette machine et, en effet, le certificat liste un autre nom d’hôte (un CNAME différent pour la même machine). Cependant, le certificat lui-même date de plusieurs années et a expiré il y a environ un an, mais il a commencé à générer cette erreur récemment. Cela me fait donc penser que ce n’est pas un changement de certificat qui cause le problème.

2 « J'aime »

Lorsque je me connecte à cet hôte et que je teste le STARTTLS, j’obtiens un certificat qui ne correspond pas au nom d’hôte :

Certificate chain
 0 s:/C=US/ST=California/L=Sunnyvale/O=Proofpoint, Inc./OU=ESP/CN=*.pphosted.com
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA

et il n’a pas encore expiré :

notBefore=Jun 12 00:00:00 2020 GMT
notAfter=Sep 14 12:00:00 2022 GMT

Une recherche directe et inversée montre que les serveurs de messagerie s’appellent en fait mx0a-00007101.pphosted.com et mx0b-00007101.pphosted.com

outbound-relays.techservices.illinois.edu. 22 IN A 148.163.139.28
outbound-relays.techservices.illinois.edu. 22 IN A 148.163.135.28

28.139.163.148.in-addr.arpa name = mx0b-00007101.pphosted.com.
28.135.163.148.in-addr.arpa name = mx0a-00007101.pphosted.com.

Essayez de changer le nom d’hôte auquel vous vous connectez pour l’un de ceux-là au lieu du nom .edu. Il n’est pas nécessaire de modifier le certificat, il pourrait s’agir d’une modification du nom d’hôte ou du code. Mais l’erreur est correcte : il y a bien une inadéquation entre le nom d’hôte et le certificat.

4 « J'aime »

Merci @RGJ ! Je vais essayer ça.

Cependant, je suis un peu nerveux à l’idée d’utiliser ces noms, étant donné qu’ils pourraient être sujets à des changements à l’avenir et ne correspondent pas au nom d’hôte fourni pour une utilisation sur le campus à cette fin. Y a-t-il un moyen de désactiver cette erreur via les paramètres app.yml ou d’une autre manière ?

1 « J'aime »

Mon approche a été de remettre les choses en état de marche d’abord, puis de trouver comment l’améliorer.
Vous devriez pouvoir définir DISCOURSE_SMTP_OPENSSL_VERIFY_MODE sur false, mais vous avez dit que vous aviez déjà essayé cela.

5 « J'aime »

Oui, absolument ! C’est logique.

Je pense avoir essayé de définir cette valeur sur none, mais pas sur false. Je vais essayer false.

2 « J'aime »

OK, je confirme que false ne fonctionne pas. Je vais réessayer none.

1 « J'aime »

Peut également vérifier que none ne fonctionne pas.

Je suis un peu perplexe quant à savoir si ce comportement est raisonnable. DISCOURSE_SMTP_ENABLE_START_TLS est défini sur false, ce qui, du moins pour les non-experts en e-mail comme moi, rendrait confus qu’un certificat joue un rôle dans cet échec. Si la machine n’avait pas du tout de certificat, le même problème se produirait-il ? (Évidemment, je ne peux pas tester cela.) Si ce n’est pas le cas, cela semble encore plus étrange.

Quoi qu’il en soit, je vais opter pour la solution temporaire pour l’instant, mais quelque chose me semble étrange.

1 « J'aime »

Certainement. Je peux imaginer que si un serveur de messagerie exige starttls, il remplacera le paramètre starttls, mais DISCOURSE_SMTP_OPENSSL_VERIFY_MODE devrait toujours pouvoir empêcher une erreur.

Quelqu’un peut-il reproduire cela ?

2 « J'aime »

@Geoffrey_Challen comment as-tu résolu le problème ?

Aujourd’hui, j’ai mis à jour mon forum vers la version 2.9.0.beta4 (c99a6b10fb) et j’ai maintenant la même erreur, discourse ne peut pas envoyer d’e-mails :
SSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)

Je n’ai rien changé à la configuration du VPS et de l’e-mail !

Mon app.yml :

  DISCOURSE_SMTP_ADDRESS: smtp.mydomain.info
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_USER_NAME: info@mydomain.info
  DISCOURSE_SMTP_PASSWORD: "mypassword"
  DISCOURSE_SMTP_ENABLE_START_TLS: false           # (optionnel, par défaut true)
  DISCOURSE_SMTP_DOMAIN: mydomain.info             # (requis par certains fournisseurs)
  #DISCOURSE_NOTIFICATION_EMAIL: noreply@discourse.example.com    # (adresse d'envoi des notifications)

J’ai essayé et rien ne change…

S’il vous plaît, maintenant je ne peux plus envoyer d’e-mails et je ne peux pas utiliser TLS, que puis-je faire ?

2 « J'aime »

Émettez cette commande et voyez pour quel nom d’hôte le certificat est destiné

openssl s_client -connect  smtp.mydomain.info:25 -starttls smtp -showcerts 2>&1|grep "depth=0"

En remplaçant smtp.mydomain.info par l’adresse de votre serveur SMTP, bien sûr.

Essayez ensuite de voir si vous pouvez atteindre le serveur SMTP en utilisant ce nom d’hôte.

3 « J'aime »

Merci pour votre aide @RGJ

le nom d’hôte est CN = *.aruba.it, il est donc différent de mydomain.info et oui, je peux atteindre le serveur SMTP en utilisant le nom d’hôte et telnet.

Tout fonctionnait parfaitement avant ./launcher rebuild app

Mais… j’ai DISCOURSE_SMTP_ENABLE_START_TLS: false, pourquoi continue-t-il à rechercher le certificat ?

1 « J'aime »

Vous pouvez accéder à l’hôte en utilisant un nom qui correspond au certificat. Vous pouvez demander à l’administrateur du serveur d’ajouter le nom d’hôte que vous souhaitez au certificat.

C’est une bonne question, mais vous pouvez la rendre sans objet en suivant les conseils ci-dessus, du moins je le pense.

Une autre question, je pense, est de savoir pourquoi l’administrateur de messagerie vous a causé ce problème ?

Peut-être que ce paramètre fonctionnait auparavant et ne fonctionne plus maintenant. Il n’est pas clair s’il est plus facile de trouver ce bug ou de changer le nom d’hôte et de voir si cela résout votre problème.

1 « J'aime »

Personne n’a apporté de modifications, j’en suis sûr, j’ai juste fait ./launcher rebuild pour installer ce plugin.

Donc, je devrais changer le nom d’hôte du VPS en quelque chose qui se termine par .aruba.it ?

1 « J'aime »

C’est ce qu’il semble.

Il est possible qu’il y ait une régression qui ait causé le problème, mais je pense que vous pouvez résoudre votre problème immédiat en changeant le nom d’hôte.

2 « J'aime »