Bonjour,
Le script bash ./discourse-setup ne peuple pas DISCOURSE_SMTP_DOMAIN dans le fichier de configuration PUPS.
J’ai utilisé rake admin:create à l’intérieur du conteneur, pour trouver l’impact suivant sur l’interface graphique ;
Pendant un certain temps, il a été peuplé avec le nom d’hôte, j’en suis presque sûr. Mais aussi, dans la plupart des cas, cela n’a pas d’importance.
existe-t-il une expression régulière que nous pouvons utiliser pour extraire le domaine de l’e-mail après le @ dans DISCOURSE_NOTIFICATION_EMAIL
comprendre les cas de déploiement où le domaine de l’e-mail est différent du domaine web.
Quelque chose comme :
DISCOURSE_SMTP_DOMAIN=$(echo "$DISCOURSE_NOTIFICATION_EMAIL" | sed -E 's/^[^@]+@(.+)$/\\1/')
Cette variable définit le nom d’hôte EHLO utilisé par le client pendant la conversation SMTP.
Presque personne n’en a besoin et il est presque toujours sans importance à quelle valeur elle est définie.
(Je n’ai rencontré aucune situation où cela importe)
2 « J'aime »
c’était parce que DO bloquait le port 587, il aurait dû utiliser le 2525 - mais je ne suis pas sûr de la façon dont cela fonctionne avec Brevo
On pourrait arguer qu’il devrait utiliser par défaut le port 2525 ou suggérer aux gens que la plupart des machines virtuelles bloquent les ports SMTP et que la plupart des services SMTP autorisent le port 2525 (mais cela fait beaucoup de mots)
Le fait que Digital Ocean bloque le port 587 est une décision terrible et mal informée sans aucun fondement dans les bonnes pratiques.
Je suis surpris qu’ils n’aient pas commencé à bloquer le 2525 par défaut pour la même raison.
[quote=“supermathie, post:7, topic:390624”]Le fait que Digital Ocean bloque le port 587 est une décision terrible et mal informée sans aucun fondement dans les bonnes pratiques.
[/quote]
Je ne suis pas d’accord. Je suis presque certain qu’ils ne sont pas les seuls à le faire (mais j’ai du mal à le prouver). Ce qui est étrange, c’est qu’ils ont toujours fait cela d’une certaine manière, mais qu’ils l’ont ensuite imposé à tout le monde en avril dernier (?). Mais « tout le monde » signifie quelque chose de très proche de « tout le monde après leur prochain redémarrage » (cela pourrait dépendre d’autre chose qui nécessite un redémarrage), donc cela pourrait prendre des mois avant que vous ne redémarriez (ou redimensionniez votre droplet ou autre chose) et que cela commence à se produire.
Et ils n’offrent même pas de service SMTP, donc une fois qu’ils bloqueront le 2525, il n’y aura aucun moyen d’envoyer des e-mails. J’ai beaucoup de personnes sur DO car CDCK les recommande depuis le début (ou du moins depuis que j’ai commencé).
2 « J'aime »
Comment avez-vous découvert cela ? Avez-vous essayé la tâche Rake emails:test, et si oui, a-t-elle été utile ? Saviez-vous qu’elle existait ?
Merci, Michael - voici ce qui s’est réellement passé lors de l’installation d’aujourd’hui et comment j’ai découvert que le port 587 était la cause première.
Lorsque j’ai d’abord exécuté ./discourse-doctor à 50:30, il est apparu clairement que l’envoi SMTP sortant sur le port 587 échouait. Il n’y a eu aucun envoi d’e-mails de test réussi à aucun moment de cette partie du processus. Pour cette raison, à 51:38, j’ai changé le port SMTP pour 2525 et reconstruit le conteneur. Dès que l’application est revenue en ligne, le premier test d’e-mail à 57:46 a réussi immédiatement.
À 57:58, j’ai noté que mon compte Mailgun n’était toujours pas activé - donc le docteur avait raison de dire que l’échec SMTP n’était pas dû aux identifiants, mais au port bloqué par DigitalOcean.
Comme Brevo est plus rapide à mettre en service, j’ai changé de fournisseur : j’ai commencé la configuration à 58:40, sélectionné le forfait Gratuit à 1:01:12, échangé les enregistrements DNS à 1:02:29 et mis à jour les paramètres SMTP dans app.yml à 1:04:37. À 1:06:08, j’ai souligné que l’interface graphique affiche DISCOURSE_SMTP_DOMAIN même lorsque la variable n’est pas renseignée par ./discourse-setup, ce qui explique pourquoi le champ vide m’a initialement fait penser que quelque chose était mal configuré.
Après avoir terminé la configuration de Brevo, j’ai réexécuté ./discourse-doctor à 1:42:10, et à 1:42:25, il a confirmé un e-mail sortant réussi - utilisant à nouveau le port 2525.
Pour répondre à vos questions spécifiques :
- Comment ai-je découvert que DigitalOcean bloquait le port 587 ?
./discourse-doctor a signalé l’échec du port 587 immédiatement, et le passage au port 2525 l’a corrigé instantanément. La vidéo montre cette séquence clairement. - Ai-je utilisé rake emails:test ?
Pas à ce moment-là - je me fiais à ./discourse-doctor et au test d’e-mail de l’interface d’administration. Je n’ai réalisé que emails:test existait qu’après que vous l’ayez mentionné. Je l’utiliserai absolument à l’avenir car il fournit des diagnostics plus clairs dans le conteneur. - Le DISCOURSE_SMTP_DOMAIN manquant était-il lié ?
Non - le champ vide de l’interface graphique était un leurre. Le problème réel était que DigitalOcean bloquait le port 587 ; une fois que je suis passé au 2525, Mailgun (une fois activé) et Brevo ont fonctionné correctement.
Merci encore - votre explication de ce que DISCOURSE_SMTP_DOMAIN affecte réellement (EHLO uniquement) a permis d’éclaircir pourquoi la valeur manquante n’avait pas d’importance.