كما قد تكونون على علم، قامت شركة Let’s Encrypt مؤخرًا بتغيير شهادة الجذر الخاصة بها. انتهت صلاحية شهادة الجذر القديمة اليوم، مما تسبّب في عدد من المشكلات لعملاء قديمين عبر الويب. جميع أنظمتنا في CDCK محدّثة، ولم تتأثر بانتهاء الصلاحية اليوم. للأسف، لم ننتبه بصورة عامة إلى صورة حاوية استلام البريد، التي لم يتم تحديثها منذ بضعة أشهر.
وهذا يعني أن تركيبات استلام البريد الحالية للمواقع المستضافة ذاتيًا لن تتمكن من تسليم البريد إلى المواقع المؤمنة بشهادات Let’s Encrypt.
لقد قمنا للتو بدفع إصدار محدّث إلى DockerHub، يتضمن شهادة الجذر الجديدة. بافتراض أنك اتبعت تعليمات التثبيت الرسمية، يمكنك تحديث تثبيتك بتشغيل:
docker pull discourse/mail-receiver:release
cd /var/discourse
./launcher rebuild mail-receiver
البريد الذي استلمته التركيبات المعطلة سيكون قد تم وضعه مؤقتًا في طابور على الخادم المرسل. يجب أن تحاول تلك الخوادم إعادة تسليم البريد دوريًا، لذا فإن أي رسائل بريد فائتة يجب أن تصل قريبًا بعد تحديث الصورة.
إذا كنت لا تزال تواجه مشكلات بعد اتباع هذه الخطوات، فتأكد من أنك تشغّل إصدار release من mail-receiver. يمكنك العثور على معلومات حول ذلك في هذا الموضوع.
نعتذر عن هذا الإزعاج! شكرًا كبيرًا إلى @wlandgraf على الإبلاغ الأولي عن المشكلة، ومساعدته في اختبار الإصلاح
شكرًا لك على الإصلاح! تعطلت عملية التحديث لدي مع رسالة الخطأ التالية. لم أقم بإجراء أي تغييرات على هذا القالب، لذا لا أعرف ما الذي يجب فعله؟
root@ba /var/discourse # ./launcher rebuild mail-receiver
Ensuring launcher is up to date
Fetching origin
Updating Launcher...
Updating 46d899f..990519e
error: Your local changes to the following files would be overwritten by merge:
templates/web.letsencrypt.ssl.template.yml
Please commit your changes or stash them before you merge.
Aborting
failed to update
@david، هل تمانع في إلقاء نظرة على المشكلات أدناه؟ فقد أزال أحدث تحديث لـ mail-receiver القدرة على تطبيق تدابير إضافية لمكافحة البريد العشوائي، والتي كانت فعالة للغاية في الإصدار السابق، مما جعل منتداي عرضة لضغط متزايد من البريد العشوائي مرة أخرى بسبب التغيير الأخير.
حاولت تحديد المشكلة الجذرية، لكنني لا أملك معرفة عميقة بـ postfix لتحديد ذلك. وجدت تقارير مشابهة (client=unknown حتى عند وجود سجل PTR في DNS) تتعلق بـ postfix في سجن chroot، لذا قد يكون لهذا علاقة بالموضوع. كما يبدو أن أدوات dnsutils مفقودة من صورة Debian الجديدة لـ mail-receiver، لكن تثبيتها لا يزال لا يحل المشكلة؟
أعتقد أن أي شيء لم يعد في قائمة الانتظار يجب أن يكون قد تم إرجاعه إلى المرسل. أخشى أنني لست متأكدًا مما إذا كان الحاوية تحتوي على أي سجلات يمكن أن تعود إلى ما أبعد مما وجدته.
هل سيؤدي مجرد إضافة pull_image بعد السطر 657 إلى حل الحاجة إلى سحب الصورة بشكل صريح قبل إعادة البناء؟ أي\n\n # إذا لم تكن الصورة التي يتم تهيئتها هي صورة Discourse الأساسية\n if [[ ! X\"\" = X\"$base_image\" ]]; then\n image=$base_image\n # محاولة تحديث الصورة\n pull_image\n fi\n\n\nسيؤدي هذا إلى حدوث docker pull $image دائمًا أثناء التهيئة/إعادة البناء لحاوية مع تعيين base_image في ملفها yml. لا أعتقد أن هذا يضر بـ mail-receiver إذا حدث أن كانت محدثة بالفعل، لكنني لست متأكدًا مما إذا كانت هناك مواقف أخرى يمكن أن تكون فيها مشكلة.
لقد نجحت في الترقية الآن، شكرًا لك!
