هل هناك طريقة لـ “خفض إصدار” ديسكورس إلى إصدار سابق يعمل (مثل 2.8.0 مستقر أو 2.9.0 بيتا 3) حتى يتم حل هذه المشكلة؟
إعجاب واحد (1)
قررت قضاء نصف ساعة أخرى في البحث في هذا وأعتقد أنني وجدت السبب.
يبدو أن هذا يتعلق بالانتقال إلى Rails 7، والذي قام بتحديث net-smtp من 0.1.0 إلى 0.3.1، مما غيّر الإعدادات الافتراضية.
الطريقة التي يستدعي بها gem smtp net-smtp لا تعطّل enable_starttls_auto و openssl_verify_mode، بل تقوم بتمكينه فقط عند تمكينه.
10 إعجابات
عمل رائع يا ريتشارد! كان هذا سيستغرق مني ساعتين إن لم يكن ضعف ذلك. بالنسبة لي، من الأسهل الاستسلام للتعامل مع الإعدادات الافتراضية الجديدة.
آها. لذا كنت على حق إلى حد ما، فقط أنه قد لا يكون من الصعب جدًا تقديم طلب سحب لإصلاحه.
4 إعجابات
عمل رائع يا @RGJ!
بينما نتوقع حلاً، على سبيل المثال، سيكون من الجيد لو لم تسبب هذه المشكلة في سلسلة من المشاكل التي واجهتها، والتي كادت أن تدمر منتداي تمامًا. على وجه التحديد:
- يبدو أن فشل البريد الإلكتروني يتم إعادة محاولته بسرعة كبيرة، مما يتسبب في انفجار حجم قائمة انتظار sidekiq واستخدام وحدة المعالجة المركزية بنسبة ~100٪ بسبب هذه المهام
- بالإضافة إلى ذلك، كان هناك شيء ما (إما تعطل أو إعادة تشغيل) يتسبب في كتابة Redis لملفات مؤقتة ضخمة، أفترض أنها تحتوي على حالة قائمة انتظار sidekiq. بينما كان من الآمن إزالتها، إلا أنها ملأت القرص بسرعة، مما تسبب في المزيد من الأعطال، وهكذا. كان لدي بعض المساحة القرصية الأخرى التي تمكنت من تحريرها حتى أتمكن من إعادة تشغيل المنتدى ومعرفة ما كان يحدث، ولكن هذا قد لا يكون صحيحًا للجميع. (من الصعب أيضًا تأكيد أنه في هذه الحالة، ملفات Redis المؤقتة آمنة للحذف.)
تخميني هو أن الحل الأبسط هنا هو إبطاء إعادة المحاولة في وظائف البريد الإلكتروني الفاشلة - أو على الأقل في تلك التي لا تحتوي على قيود زمنية مثل إعادة تعيين كلمة المرور. وهو ما يبدو مناسبًا نظرًا لأن مشاكل البريد الإلكتروني من غير المرجح أن تُحل بسرعة، ومعظم / كل مرسلي البريد سيقومون بإعادة المحاولة الخاصة بهم بمجرد استلامهم رسالة.
8 إعجابات
في حالتي، عندما واجهت الفشل بعد الترقية، كان ذلك باستخدام TLS مع خادم طرف ثالث وكان الاسم الموجود على الشهادة مطابقًا لاسم خادم smtp. كان لدي فشل واحد فقط. لم أقم بإعادة التشغيل أو الترقية منذ ذلك الحين لتجنب المزيد من المشاكل. سأحاول التحديث بمجرد إصدار التصحيح وأرى كيف تسير الأمور.
إعجابَين (2)
سأبدأ بإنشاء موضوع في Bug ولكن نظرًا لأنه مشكلة فنية في جوهرة علوية، لست متأكدًا من مدى الأولوية التي سيحصل عليها هذا.
3 إعجابات
+1 
خطأ محبط حقًا
إعجاب واحد (1)
هل لا يمكن التراجع عن الجوهرة؟ سأكون متفاجئًا إذا لم تحصل على اهتمام نظرًا لأن هذه وظيفة “أساسية”، وهي القدرة على إرسال رسائل البريد الإلكتروني، وبالنسبة للبعض فإنها تسبب أيضًا انقطاعًا بسبب الملفات المؤقتة واستهلاك وحدة المعالجة المركزية للخادم. استقرار المنتدى الأساسي مضطرب هنا.
إعجابَين (2)
من فضلك لا تنس أن هذا يمكن حله بسهولة عن طريق تكوين خادم البريد الخاص بك بشكل صحيح أيضًا.
إعجاب واحد (1)
على حد علمي، تم تكوين الخادم الخاص بي بشكل صحيح. اسم الشهادة يطابق اسم مضيف smtp، STARTTLS على المنفذ 587. أتساءل لماذا واجهت المشكلة؟
شكرًا لفتح تذكرة جديدة. بالنظر إلى فهمك، هل يمكنك تسليط الضوء على مجموعات المتغيرين اللذين أشرت إليهما في ملف YML - كيف يجب استخدامهما لسيناريوهات مختلفة؟
DISCOURSE_SMTP_ENABLE_START_TLS: true
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
على سبيل المثال، لدي STARTTLS فقط على المنفذ 587 ولا توجد منافذ أخرى يستخدمها SMTP لأسباب أمنية. هل يجب تحديد كلا المتغيرين في ملف YML أم واحد فقط؟
إعجابَين (2)
هذا يعتمد.
إذا كان خادم SMTP الخاص بك مُعدًا بشكل صحيح، فلن تحتاج إلى أي منهما.
لكن المشكلة الآن هي أنهما لا يفعلان أي شيء على الإطلاق.
أرسل لي رسالة خاصة باسم خادم SMTP الخاص بك وسألقي نظرة وأرى ما إذا كان بإمكاني معرفة سبب عدم عمله لديك.
إعجابَين (2)
لدي خادم SMTP محلي بدون دعم TLS/SSL وعند استخدام StartTls=false لا يعمل 
إعجاب واحد (1)
[quote=“Richard - Communiteq, post:56, topic:225778, username:RGJ”]خادم البريد الخاص بك بشكل صحيح أيضًا.
[/quote]
نقطة عادلة، لكنه ليس دائمًا خادم البريد الخاص بنا. أنا أستخدم خادم بريد داخليًا تتم صيانته بواسطة مجموعة أخرى، ولذلك ليس لدي أي سيطرة على مشكلات الشهادة أو تكوين خادم البريد.
ومع ذلك، بالنسبة للآخرين الذين يعانون من هذا، قد يكون أحد الخيارات هو إعداد خادم البريد الخاص بك على localhost وجعله يقوم بإعادة توجيه البريد. بعد ذلك، لديك سيطرة على خادم البريد الذي يتحدث إليه Discourse، ويمكن تكوين خادم البريد الخاص بك على localhost للتعامل مع أي نوع من مشكلات المنبع التي قد تواجهها. لقد فعلت هذا سابقًا، ولكني أزلته في مرحلة ما نظرًا لأنه كان أبسط من مجرد جعل Discourse يتحدث مباشرة إلى خادم البريد المنبع. (عفوًا.)
إعجاب واحد (1)
لهذا السبب يوصي التثبيت القياسي (Standard Install) بموفري البريد الإلكتروني الخارجيين، بدلاً من محاولة استخدام حل موجود أو مستضاف ذاتيًا.
البريد الإلكتروني صعب لعدة أسباب، مجرد أن شيئًا ما يعمل اليوم لا يعني أنه تم تكوينه بشكل صحيح، بل يعني فقط أن التكوين الخاطئ لا يؤثر على الغرض الأصلي.
إعجاب واحد (1)
السبب الذي جعلني أختار ديسكورس هو أنه يفترض أن يكون سهل التثبيت والصيانة للنشر الذاتي الصغير.
إعجاب واحد (1)
وهو كذلك إذا اتبعت التوصيات.
إذا اخترت اتباع مسار مختلف، فليس من الممكن حقًا تقديم أي ضمانات.
إعجاب واحد (1)
إذًا، باختصار، هل تقول إنه مع ديسكورس لم يعد من الممكن استخدام خادم SMTP بدون TLS أو SSL أو StartTLS؟
إعجاب واحد (1)
لا أعتقد أن أحداً يقترح ذلك. هذا يتعلق فقط بكيفية حدوث المشكلة، واستغرق الأمر وقتًا للعثور على السبب الجذري.
السبب في أننا نرى عددًا قليلاً من الحالات هنا فقط هو العدد الصغير نسبيًا من التثبيتات مع الجيم المحدثة التي لا تقوم أيضًا بإعادة توجيه البريد عبر شكل من أشكال النقل الآمن.
لقد بدأ ريتشارد بالفعل موضوعًا حول الخطأ:
بالنسبة لأي شخص يحتاج إلى هذا العمل في وقت أقرب، يمكنه أيضًا تمكين TLS على خادم البريد الخاص به، أو التبديل مؤقتًا إلى مزود بريد يقدم نقلًا آمنًا.
إعجاب واحد (1)
لدي بالفعل تمكين TLS مع شهادة صالحة واسم مضيف مطابق منذ البداية ثم واجهت المشكلة بعد ترقية BETA 4 (461936f211) ونشرت السجلات في الموضوع أدناه. يواجه مستخدم آخر مشاكل أيضًا ووفقًا له فإن شهاداته في وضع جيد أيضًا:
إعجاب واحد (1)
هذا ما يبدو لي. كانت بعض التعليقات في هذا الموضوع مزعجة للغاية.
أقوم باستضافة Docker-Discourse بنفسي، وأستخدم مضيف Docker الخاص بي كخادم بريد إلكتروني. لقد جعلت Discourse يستخدم المنفذ 25، بدون TLS، لإرسال البريد عبر واجهة Docker الداخلية منذ البداية، قبل ست سنوات. هذا تكوين معقول تمامًا وآمن تمامًا. كانت المعاملات داخلية 100٪ على مضيفي الخاص. انظر أعلى الموضوع لمعرفة تكويني القديم.
بالنسبة لي، كانت الحل البديل هو القيام بما يلي:
أضف عنوان IP لواجهة Docker الداخلية للمضيف كمضيف صالح في ملف منطقة DNS لنطاقي. أي:
discourse-mail.jag-lovers.com A 172.17.0.1
يرجى ملاحظة: يمكنني إنشاء أي اسم مضيف في نطاق jag-lovers.com، نظرًا لأنني أستخدم شهادة wildcard (CN = *.jag-lovers.com). إذا لم يكن لديك شهادة wildcard، فتأكد من استخدام اسم مضيف يكون CN أو SAN صالحًا في شهادتك.
يرجى أيضًا ملاحظة: عنوان IP الذي استخدمته أعلاه هو عنوان IP الداخلي الذي يستخدمه مضيفي على واجهة Docker، للتحدث إلى حاوية Discourse-Docker. إنه عنوان IP خاص وغير قابل للتوجيه.
بعد ذلك، قم بتغيير تكوين Discourse app.yml للاتصال باسم المضيف الذي أنشأته للتو، لاستخدام TLS، للاتصال على المنفذ 587، واستخدام SASL لتسجيل الدخول إلى المضيف لكل معاملة بريد إلكتروني (لأنه بخلاف ذلك ستحصل على رسالة خطأ “relaying denied”).
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 # (اختياري، الافتراضي true)
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
DISCOURSE_SMTP_DOMAIN: jag-lovers.com
بعد ذلك، أعد بناء Discourse. هذا حل المشكلة بالنسبة لي.
إعجابَين (2)