لقد كنت أستضيف Discourse بنفسي لسنوات عديدة، وكان لدي العديد من المثيلات تعمل بشكل جيد على جهاز قوي إلى حد ما.
اليوم لاحظت أن أحد منتدياتي قد توقف. كان السبب الأولي هو نقص مساحة القرص، والذي قمت بإصلاحه. ثم قمت بإعادة تشغيل مثيل Discourse.
ومع ذلك، فقد استمر في التوقف بانتظام منذ ذلك الحين. في كل مرة أقوم فيها بتشغيله، أرى فورًا أن sidekiq يعمل بجنون وعدد كبير من وظائف البريد الإلكتروني الفاشلة، والتي تتسبب أيضًا في تخزين redis لكمية هائلة من الحالة، والتي أعتقد أنها كانت السبب الفعلي لمشكلة مساحة القرص. (سأقوم بعمل مسح في المرة القادمة التي أتمكن فيها من تشغيل الجهاز، لأنه إذا لم أفعل ذلك، فسوف أنفد المساحة بسرعة على هذا الجهاز ولن أتمكن حتى من بدء تشغيل Discourse للمسح. ولكن المسح لا يبدو أنه يقلل من استخدام مساحة القرص لـ redis كثيرًا.)
تشير رسالة الخطأ إلى شيء يتعلق بعدم تطابق اسم الشهادة، وهو ما أجده مفاجئًا بعض الشيء نظرًا لأن خادم البريد الذي أستخدمه داخلي ولا يتطلب TLS أو المصادقة. تمكنت من التحقق في أحد مثيلاتي الأخرى (باستخدام نفس تكوين البريد الإلكتروني) من أن البريد قد توقف عن العمل. كل ما يمكنني رؤيته في سجلات الإنتاج الرئيسية هو خطأ 422، ولكن عندما أرسل شيئًا مثل إعادة تعيين كلمة المرور، أرى خطأً مشابهًا في سجلات sidekiq:
مرة أخرى، هذا الخادم البريدي داخلي ولا يتطلب اسم مستخدم أو كلمة مرور، وهذه الإعدادات كانت تعمل حتى وقت قريب. لقد كنت أجرب DISCOURSE_SMTP_OPENSSL_VERIFY_MODE، ولكن لا يمكنني معرفة ما إذا كان لا يزال مدعومًا. بغض النظر، لا يبدو أنه يساعد. لاحظت بعض إعدادات البريد الإلكتروني الجديدة التي تمت إضافتها منذ أن قمت بإعداد هذه المنتديات، ولكن لا يبدو أنها ضرورية نظرًا لتكوين خادم البريد هذا.
أي مساعدة ستكون موضع تقدير! في هذه المرحلة، أجد صعوبة في التأكد مما هو خاطئ أو في التكرار، حيث يستغرق إعادة بناء الحاوية وقتًا طويلاً ورسالة الخطأ في سجلات الإنتاج تحتوي فقط على خطأ 422 ولا يمكنني معرفة أين أبحث عن السبب الجذري الفعلي. (يجب أن يكون في مكان ما، أليس كذلك؟ أنا متأكد من أنني أفتقده فقط.)
وهذا يتوافق مع تكوين البريد الإلكتروني الذي كنت أستخدمه عندما بدأت هذه المشكلة. لاحظ أنني أجريت أيضًا ترقية إلى أحدث إصدار من Discourse عبر أمر سحب (مطلوب) من سطر الأوامر يوم الجمعة، مما يجعلني أتساءل عما إذا كان التزام حديث قد جلب هذه المشكلة.
أعتقد صباح الجمعة. أدى تحديث عادي عبر واجهة المستخدم إلى الحاجة إلى إعادة بناء تطبيق المشغل. عندما فحصت سجلات sidekiq لاحقًا، بدا أن قائمة الانتظار بدأت في الوقت الذي تم فيه إعادة بناء الحاوية، لكن الأمر استغرق حوالي 24 ساعة حتى تستهلك سجلات Redis كل مساحة التخزين المتاحة على المضيف وتتسبب فعليًا في توقف الخدمة. ومع ذلك، ربما كان المنتدى بطيئًا قبل تلك النقطة، نظرًا لأن sidekiq كان يحاول يائسًا إعادة إرسال عدد متزايد من مهام البريد الإلكتروني الفاشلة بنسبة 100٪ من استخدام وحدة المعالجة المركزية.
نعم.
ومع ذلك، يقلقني أن هذا لم يقلل من استخدام قرص Redis. لدي مجلد redis_data يبلغ حجمه حاليًا 29 جيجابايت، حتى بعد المسح. ربما يكون Redis مثل MongoDB في أنه قد يكون من الصعب جعله يعيد تخصيص مساحة القرص؟ نظرًا لأن هذا هو 1/3 من القرص المتاح على الجهاز، فسوف يصبح مشكلة، لكنني سأؤجل ذلك في الوقت الحالي لصالح استعادة عمل البريد الإلكتروني مرة أخرى.
كملاحظة تصحيح الأخطاء: هل هناك طريقة لإرسال بريد إلكتروني تجريبي من سطر الأوامر داخل الحاوية، باستخدام نفس تدفق التعليمات البرمجية الذي سيستخدمه Discourse؟ (بمعنى، ليس من سطر الأوامر باستخدام أداة أخرى، والتي لقد تحققت بالفعل أنها تعمل.) سيكون هذا مفيدًا لتصحيح الأخطاء، حيث أن إرسال بريد إلكتروني تجريبي حاليًا يتطلب العبث بواجهة المستخدم على الويب ثم البحث في السجلات لمعرفة ما حدث خطأ. (وحتى الآن لم أجد سوى أخطاء 422، وليس أي شيء أكثر فائدة، إلا في سجلات sidekiq التي لم يتم إنشاؤها عند استخدام تدفق البريد الإلكتروني التجريبي.) أو ربما يمكن لواجهة مستخدم البريد الإلكتروني التجريبي أن تعرض المزيد من معلومات تصحيح الأخطاء؟
بشكل عام، أشك في أن معظم الأشخاص يقومون بإعداد Discourse ولا يصلون إلى هذه النقطة بدون عمل البريد الإلكتروني، نظرًا لأنه مطلوب لإرسال الدعوات الأولية وما إلى ذلك. لكنني أجد أن قابلية تصحيح الأخطاء محدودة في الحالة التي كان فيها البريد الإلكتروني يعمل ويتوقف فجأة. (أيضًا، قد تحتاج منطق إعادة المحاولة إلى بعض الضبط، حيث يبدو سريعًا جدًا لإعادة المحاولة في هذه الحالة. من غير المحتمل أن يتم إصلاح خطأ الشهادة بعد ثوانٍ قليلة من المحاولة الأولية…)
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!)
=======================================================================================
سأقوم بإعادة بناء الحاوية الآن للتأكد من أنها و app.yml متزامنان. ولكن بشكل عام أنا مرتبك بعض الشيء لماذا يقول إنه يستخدم المصادقة العادية، نظرًا لأنه لم يتم توفير اسم مستخدم أو كلمة مرور في ملف تكوين app.yml.
هل يستحق إعادة تصنيف هذا كخطأ؟ ترددت في البداية، نظرًا لأنه بريد إلكتروني وهناك العديد من الطرق التي يمكن أن يساء بها هذا التصرف، وكثير منها سيكون مزيجًا من خطئي / تغييرات خارجية. ولكن بقدر ما أستطيع أن أرى، هذا يمثل تكوينًا كان يعمل لعدة سنوات ثم توقف فجأة عند الترقية إلى أحدث إصدار من discourse_docker. هل من الممكن أن يكون قد تغير شيء ما في كيفية معالجة ملفات التكوين مؤخرًا؟
فيما يتعلق برسالة الخطأ نفسها - تمكنت من سحب شهادة لهذا الجهاز، وبالفعل، تسرد الشهادة اسم مضيف آخر (CNAME مختلف لنفس الجهاز). ومع ذلك، فإن الشهادة نفسها قديمة ببضع سنوات، وانتهت صلاحيتها أيضًا منذ حوالي عام، ولكنها بدأت في إلقاء هذا الخطأ مؤخرًا. لذلك أعتقد أن التغيير في الشهادة ليس هو سبب المشكلة.
عند الاتصال بهذا المضيف واختبار STARTTLS، أحصل على شهادة لا تتطابق مع اسم المضيف:
سلسلة الشهادات
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
يُظهر البحث الأمامي والعكسي أن خوادم البريد تسمى فعليًا mx0a-00007101.pphosted.com و 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.
حاول تغيير اسم المضيف الذي تتصل به إلى أحد هذه الأسماء بدلاً من اسم .edu. لا يلزم إجراء تغيير على الشهادة، ربما كان هناك تغيير في اسم المضيف أو في الكود. لكن الخطأ صحيح: هناك بالفعل عدم تطابق في شهادة اسم المضيف.
ومع ذلك، أنا متوتر قليلاً بشأن استخدام هذه الأسماء، نظرًا لأنها قد تخضع للتغيير في المستقبل ولا تتطابق مع اسم المضيف المقدم للاستخدام داخل الحرم الجامعي لهذا الغرض. هل هناك أي طريقة لتعطيل هذا الخطأ عبر إعدادات app.yml أو بطريقة أخرى؟
كان منهجي هو إعادة الأمور للعمل أولاً، ثم معرفة كيفية تحسينها.
يجب أن تكون قادرًا على تعيين DISCOURSE_SMTP_OPENSSL_VERIFY_MODE إلى false، ولكنك قلت إنك جربت ذلك بالفعل.
أعتقد أنني عالق بعض الشيء هنا فيما يتعلق بما إذا كان هذا سلوكًا معقولًا. تم تعيين DISCOURSE_SMTP_ENABLE_START_TLS على false، مما قد يسبب ارتباكًا لغير الخبراء في البريد الإلكتروني مثلي بأن شهادة تلعب دورًا في هذا الفشل. إذا لم يكن لدى الجهاز شهادة على الإطلاق، فهل سيحدث نفس المشكلة؟ (من الواضح أنني لا أستطيع اختبار ذلك.) إذا لم يكن الأمر كذلك، فيبدو الأمر أكثر غرابة.
على أي حال، سأتبع الحل المؤقت في الوقت الحالي، ولكن هناك شيء ما يبدو غريبًا بالنسبة لي.
بالتأكيد. يمكنني أن أتخيل أنه إذا كان خادم البريد يتطلب starttls فإنه سيتجاوز إعداد starttls ولكن DISCOURSE_SMTP_OPENSSL_VERIFY_MODE يجب أن يظل قادرًا على منع حدوث خطأ.
اليوم قمت بتحديث منتداي إلى 2.9.0.beta4 (c99a6b10fb) والآن لدي نفس الخطأ، لا يمكن لـ discourse إرسال رسائل البريد الإلكتروني: SSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)
لم أقم بتغيير إعدادات VPS والبريد الإلكتروني!
ملفي 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 # (اختياري، الافتراضي true)
DISCOURSE_SMTP_DOMAIN: mydomain.info # (مطلوب من قبل بعض المزودين)
#DISCOURSE_NOTIFICATION_EMAIL: noreply@discourse.example.com # (العنوان الذي سيتم إرسال الإشعارات منه)
جربت ولم يتغير شيء …
من فضلك الآن لا يمكنني إرسال رسائل البريد الإلكتروني ولا يمكنني استخدام TLS، ماذا يمكنني أن أفعل؟