مرحباً،
برنامج النصوص النصي ./discourse-setup لا يقوم بملء DISCOURSE_SMTP_DOMAIN في ملف إعدادات PUPS.
لقد استخدمت rake admin:create داخل الحاوية، لأجد التأثير التالي على واجهة المستخدم الرسومية؛
لفترة من الوقت، امتلأ باسم المضيف، أنا متأكد من ذلك. ولكن في معظم الحالات، لا يهم.
هل هناك تعبير نمطي (regex) يمكننا استخدامه لاستخراج نطاق البريد الإلكتروني من بعد علامة @ في DISCOURSE_NOTIFICATION_EMAIL
لفهم حالات النشر حيث يختلف نطاق البريد الإلكتروني عن نطاق الويب.
شيء مثل:
DISCOURSE_SMTP_DOMAIN=$(echo "$DISCOURSE_NOTIFICATION_EMAIL" | sed -E 's/^[^@]+@(.+)$/\\1/')
يحدد هذا المتغير اسم المضيف EHLO الذي يستخدمه العميل أثناء محادثة SMTP.
لا يحتاجه أحد تقريبًا ولا يهم أبدًا ما تم تعيينه عليه.
(لم أواجه أي مواقف يكون فيها مهمًا)
إعجابَين (2)
كان هذا بسبب أن DO قام بحظر المنفذ 587، وكان ينبغي استخدام 2525 - ولكن لست متأكدًا كيف يعمل هذا مع Brevo
من الممكن القول بأنه يجب أن يكون المنفذ الافتراضي هو 2525 أو اقتراح أن معظم الأجهزة الافتراضية تحظر منافذ SMTP ومعظم خدمات SMTP تسمح بالاتصال عبر المنفذ 2525 (ولكن هذا سيصبح الكثير من الكلمات)
حقيقة أن Digital Ocean تحظر المنفذ 587 هو قرار فظيع وغير مستنير وليس له أساس في الممارسات الجيدة.
أنا مندهش لأنهم لم يبدأوا في حظر 2525 افتراضيًا لنفس السبب.
أنا لا أختلف. أنا متأكد من أنهم ليسوا الوحيدين الذين يفعلون ذلك (لكنني أواجه صعوبة في إثبات ذلك). الغريب هو أنهم كانوا يفعلون ذلك دائمًا تقريبًا، ولكن بعد ذلك في أبريل الماضي (؟) فرضوه على الجميع. لكن “الجميع” يعني شيئًا يشبه إلى حد كبير “الجميع بعد إعادة تشغيلهم في المرة التالية” (قد يعتمد على شيء آخر يتطلب إعادة تشغيل)، لذلك قد يستغرق الأمر شهورًا قبل أن تقوم بإعادة التشغيل (أو تغيير حجم القطرة الخاصة بك أو شيء من هذا القبيل) ثم يبدأ حدوث ذلك.
وهم لا يقدمون خدمة SMTP، لذلك بمجرد حظرهم للمنفذ 2525، لن تكون هناك طريقة لإرسال البريد. لدي الكثير من الأشخاص على DO لأن CDCK أوصت بهم منذ البداية (أو على الأقل عندما بدأت).
إعجابَين (2)
كيف اكتشفت ذلك؟ هل جربت مهمة emails:test في rake، وإذا فعلت، فهل كانت مفيدة؟ هل كنت تعلم بوجودها؟
شكرًا لك يا مايكل - إليك ما حدث بالفعل في تثبيت اليوم وكيف اكتشفت أن المنفذ 587 كان السبب الجذري.
عندما قمت بتشغيل ./discourse-doctor لأول مرة عند 50:30، أظهر بوضوح أن إرسال SMTP الصادر على المنفذ 587 كان يفشل. لم تكن هناك رسائل بريد إلكتروني تجريبية ناجحة في أي مكان في ذلك الجزء من العملية. وبسبب ذلك، عند 51:38 قمت بتغيير منفذ SMTP إلى 2525 وأعدت بناء الحاوية. بمجرد عودة التطبيق للعمل، نجح أول اختبار للبريد عند 57:46 على الفور.
عند 57:58 لاحظت أن حساب Mailgun الخاص بي لم يكن قد تم تفعيله بعد - لذلك كان الطبيب (doctor) محقًا في أن فشل SMTP لم يكن بسبب بيانات الاعتماد، ولكن بسبب حظر المنفذ بواسطة DigitalOcean.
نظرًا لأن Brevo أسرع في التشغيل، قمت بتغيير المزود: بدأت الإعداد عند 58:40، واخترت الخطة المجانية عند 1:01:12، وقمت بتبديل سجلات DNS عند 1:02:29، وقمت بتحديث إعدادات SMTP في app.yml عند 1:04:37. عند 1:06:08 أشرت إلى أن واجهة المستخدم الرسومية (GUI) تعرض DISCOURSE_SMTP_DOMAIN حتى عندما لا يتم ملء المتغير بواسطة ./discourse-setup، وهذا هو السبب في أن الحقل الفارغ جعلني أعتقد في البداية أن هناك شيئًا ما تم تكوينه بشكل خاطئ.
بعد الانتهاء من تكوين Brevo، أعدت تشغيل ./discourse-doctor عند 1:42:10، وعند 1:42:25 أكد نجاح إرسال البريد الإلكتروني الصادر - مرة أخرى باستخدام المنفذ 2525.
للإجابة على أسئلتك المحددة:
- كيف اكتشفت أن DigitalOcean كانت تحظر المنفذ 587؟
أبلغ./discourse-doctorعن فشل المنفذ 587 على الفور، والتبديل إلى 2525 أصلح المشكلة على الفور. يوضح الفيديو هذا التسلسل بوضوح. - هل استخدمت
rake emails:test؟
ليس في ذلك الوقت - كنت أعتمد على./discourse-doctorواختبار البريد الإلكتروني في واجهة المسؤول. لم أكن أعرف بوجودemails:testحتى ذكرته. سأستخدمه بالتأكيد في المستقبل لأنه يوفر تشخيصات أوضح داخل الحاوية. - هل كان متغير
DISCOURSE_SMTP_DOMAINالمفقود مرتبطًا بالمشكلة؟
لا - كان الحقل الفارغ في واجهة المستخدم الرسومية مضللاً. كانت المشكلة الفعلية هي حظر DigitalOcean للمنفذ 587؛ بمجرد انتقالي إلى 2525، عمل كل من Mailgun (بمجرد تفعيله) و Brevo بشكل جيد.
شكرًا لك مرة أخرى - لقد ساعد شرحك لما يؤثر عليه DISCOURSE_SMTP_DOMAIN بالفعل (EHLO فقط) في توضيح سبب عدم أهمية القيمة المفقودة.