Existe-t-il un moyen de « rétrograder » Discourse vers une ancienne version fonctionnelle (par exemple, 2.8.0 stable ou 2.9.0 beta3) en attendant que cela soit résolu ?
1 « J'aime »
J’ai décidé de passer encore une demi-heure à examiner cela et je pense avoir trouvé la cause.
Cela semble lié au passage à Rails 7, qui a mis à jour net-smtp de 0.1.0 à 0.3.1, ce qui a modifié les valeurs par défaut.
La façon dont la gem smtp appelle net-smtp ne désactive pas enable_starttls_auto et openssl_verify_mode, elle l’active uniquement lorsqu’il est activé.
10 « J'aime »
Beau travail, Richard ! Cela m’aurait pris deux heures, sinon le double. Pour moi, il est plus facile de me résigner à traiter les nouveaux paramètres par défaut.
Aha. J’avais donc plus ou moins raison, c’est juste que ce ne serait peut-être pas trop difficile pour une PR de le corriger.
4 « J'aime »
Excellent travail @RGJ !
En attendant un correctif, et à titre d’information, il serait bon que ce problème n’entraîne pas la cascade de problèmes que j’ai rencontrés, qui ont failli mettre mon forum hors service. Spécifiquement :
- Les échecs d’envoi d’e-mails semblent être retentés très rapidement, ce qui fait exploser la taille de la file d’attente sidekiq et provoque une utilisation du CPU à ~100 % due à ces tâches.
- De plus, quelque chose (soit des plantages, soit des redémarrages) provoquait l’écriture d’énormes fichiers temporaires par Redis, contenant je suppose l’état de la file d’attente sidekiq. Bien qu’il soit sûr de les supprimer, ils ont rapidement rempli le disque, ce qui a entraîné d’autres plantages, et ainsi de suite. J’avais d’autres espaces disque que j’ai pu libérer pour redémarrer le forum et comprendre ce qui se passait, mais ce ne sera peut-être pas le cas pour tout le monde. (Il est également quelque peu difficile de confirmer que, dans ce cas, les fichiers temporaires Redis sont bien sûrs à supprimer.)
Je suppose que la solution la plus simple ici est de ralentir la nouvelle tentative des travaux d’e-mail échoués, ou du moins de ceux qui n’ont pas de contraintes de temps comme les réinitialisations de mot de passe. Ce qui semble approprié étant donné que les problèmes d’e-mail ne se résolvent probablement pas rapidement, et que la plupart / tous les expéditeurs d’e-mails effectueront leurs propres nouvelles tentatives une fois qu’ils auront reçu un message.
8 « J'aime »
Dans mon cas, lorsque j’ai rencontré l’échec après la mise à niveau, il utilisait TLS avec un serveur tiers et le nom sur le certificat correspondait au nom du serveur smtp. J’ai cependant eu un seul échec. Je n’ai pas redémarré ni effectué de mise à niveau depuis pour éviter d’autres problèmes. J’essaierai une mise à jour une fois le correctif publié et je verrai comment cela se passe.
2 « J'aime »
Je commencerai par créer un sujet dans Bug, mais comme il s’agit techniquement d’un problème dans une gemme en amont, je ne suis pas sûr de la priorité qui lui sera accordée.
3 « J'aime »
+1 
bug vraiment frustrant
1 « J'aime »
La gemme ne peut-elle pas être annulée ? Je serais surpris qu’elle n’ait pas reçu d’attention, car il s’agit d’une fonctionnalité “de base”, la capacité d’envoyer des e-mails, et pour certains, elle provoque également une panne en raison de fichiers temporaires et du CPU qui surchargent le serveur. La stabilité de base du forum est perturbée ici.
2 « J'aime »
N’oubliez pas que cela peut également être facilement résolu en configurant correctement votre serveur de messagerie.
1 « J'aime »
D’après ce que je sais, mon serveur est correctement configuré. Le nom du certificat correspond au nom d’hôte smtp, STARTTLS sur le port 587. Je me demande pourquoi j’ai rencontré ce problème ?
Merci d’avoir ouvert un nouveau ticket. Compte tenu de votre compréhension, pourriez-vous éclairer les combinaisons des deux variables que vous avez mentionnées dans le fichier YML - comment devraient-elles être utilisées pour différents scénarios ?
DISCOURSE_SMTP_ENABLE_START_TLS: true
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
Par exemple, j’ai uniquement STARTTLS sur le port 587 et aucun autre port n’est utilisé par SMTP pour des raisons de sécurité. Les deux variables doivent-elles être spécifiées dans le fichier YML ou une seule ?
2 « J'aime »
Ça dépend.
Si votre serveur SMTP est correctement configuré, vous n’aurez besoin d’aucune des deux.
Mais le problème actuel est qu’elles ne font rien du tout.
Envoyez-moi un message privé avec le nom de votre serveur SMTP et je regarderai pour voir si je peux trouver pourquoi cela ne fonctionne pas pour vous.
2 « J'aime »
J’ai un serveur SMTP local sans prise en charge TLS/SSL et lorsque j’utilise StartTls=false, cela ne fonctionne pas 
1 « J'aime »
[quote=“Richard - Communiteq, post:56, topic:225778, username:RGJ”]votre serveur de messagerie correctement aussi.
[/quote]
Point juste, mais ce n’est pas toujours notre serveur de messagerie. J’utilise un serveur de messagerie interne qui est maintenu par un autre groupe, et je n’ai donc aucun contrôle sur les problèmes de certificat ou la configuration du serveur de messagerie.
Cela dit, pour d’autres qui luttent avec cela, une option peut être de configurer votre propre serveur de messagerie sur localhost et de le faire simplement transférer les e-mails. Ensuite, vous avez le contrôle du serveur de messagerie auquel Discourse parle, et votre serveur de messagerie sur localhost peut être configuré pour gérer les problèmes en amont que vous pourriez rencontrer. Je l’avais fait auparavant, mais je l’ai supprimé à un moment donné car il était plus simple de faire parler Discourse directement au serveur de messagerie en amont. (Oups.)
1 « J'aime »
C’est pourquoi l’installation standard recommande des fournisseurs de messagerie tiers, plutôt que d’essayer d’utiliser une solution existante ou auto-hébergée.
La messagerie est difficile pour une multitude de raisons, ce n’est pas parce que quelque chose fonctionne aujourd’hui que sa configuration est correcte, seulement que la mauvaise configuration n’a pas d’impact sur le but initial.
1 « J'aime »
La raison pour laquelle j’ai choisi Discourse est qu’il est censé être facile à installer et à maintenir pour de petits déploiements auto-hébergés.
1 « J'aime »
Et c’est le cas si vous suivez les recommandations.
Si vous choisissez de prendre un chemin différent, il n’est pas vraiment possible de faire des garanties.
1 « J'aime »
En résumé, vous dites donc qu’avec Discourse, il n’est plus possible d’utiliser un serveur SMTP sans TLS, SSL ou StartTLS ?
1 « J'aime »
Je ne pense pas que quiconque suggère cela. Cela ne concerne que la façon dont le problème est survenu et a mis du temps à trouver une cause profonde.
La raison pour laquelle nous ne voyons qu’une poignée de cas ici est due au nombre relativement faible d’installations avec le gem mis à jour qui ne relaient pas non plus le courrier via une forme de transport sécurisé.
Richard a déjà lancé un sujet sur le bug :
Pour ceux qui ont besoin que cela fonctionne plus rapidement, ils peuvent également activer TLS sur leur serveur de messagerie ou passer temporairement à un fournisseur de messagerie qui offre un transport sécurisé.
1 « J'aime »
J’ai bien TLS activé avec un certificat valide et un nom d’hôte correspondant depuis le début, puis j’ai rencontré le problème après la mise à niveau BETA 4 (461936f211) et j’ai posté les journaux dans le sujet ci-dessous. Un autre utilisateur rencontre également des problèmes et, selon lui, ses certificats sont également en ordre :
1 « J'aime »
C’est ce qu’il me semble. Certains commentaires dans ce fil ont été carrément exaspérants.
J’héberge moi-même Docker-Discourse, et j’utilise mon hôte Docker comme serveur de messagerie. J’ai fait en sorte que Discourse utilise le port 25, sans TLS, pour envoyer des e-mails via l’interface Docker interne depuis le début, il y a six ans. C’est une configuration parfaitement raisonnable et parfaitement sûre. Les transactions étaient 100% internes à mon propre hôte. Voir plus haut dans le fil pour mon ancienne configuration.
Pour moi, la solution de contournement a été de faire ce qui suit :
Ajouter l’adresse IP de l’interface Docker interne de l’hôte comme hôte valide dans le fichier de zone DNS de mon domaine. C’est-à-dire :
discourse-mail.jag-lovers.com A 172.17.0.1
Veuillez noter : Je pourrais inventer n’importe quel nom d’hôte dans le domaine jag-lovers.com, puisque j’utilise un certificat wildcard (CN = *.jag-lovers.com). Si vous n’avez pas de certificat wildcard, assurez-vous d’utiliser un nom d’hôte qui est un CN ou un SAN valide sur votre certificat.
Veuillez également noter : L’adresse IP que j’ai utilisée ci-dessus est l’adresse IP interne que mon hôte utilise sur l’interface Docker pour communiquer avec le conteneur Discourse-Docker. C’est une adresse IP privée, non routable.
Ensuite, modifiez la configuration de l’application Discourse (app.yml) pour vous connecter au nom d’hôte que je viens de créer, pour utiliser TLS, pour vous connecter sur le port 587 et pour utiliser SASL pour vous connecter à l’hôte pour chaque transaction d’e-mail (car sinon vous obtiendrez un message d’erreur de relais refusé).
DISCOURSE_SMTP_ADDRESS: discourse-mail.jag-lovers.com
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: REDACTED
DISCOURSE_SMTP_PASSWORD: "REDACTED"
DISCOURSE_SMTP_ENABLE_START_TLS: true # (optionnel, par défaut true)
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
DISCOURSE_SMTP_DOMAIN: jag-lovers.com
Ensuite, reconstruisez Discourse. Cela a résolu le problème pour moi.
2 « J'aime »