أنا أقترب من نقطة اليأس، لأن محاولة جعل بوت Discourse أو Claude يحل هذه المشكلة تبدو مستحيلة. لا أستطيع حقًا شرح المشكلة لأنني لست خبيرًا بما يكفي، وأعتقد أن هذا هو ما يزعجني حقًا.
سأحاول شرح ما حدث من وجهة نظري.
عندما كنت أنتقل من حاوية واحدة إلى حاويتين، كانت الملفات في samples/ تستخدم web-only وقمت بتجاهلها عن الخطأ بدلاً من استخدام web_only.
ثم، بسبب ذلك (أعتقد)، لم يتم تحميل صوري، لأن شيئًا ما كان يُفترض أن يشير إلى web_only، لكنه كان مضبوطًا على web-only. أجريت بعض التغييرات وتم إصلاح الصور. المشكلة الآن هي شهادات LetsEncrypt.
طلبت من البوت مساعدتي في إصلاحها، فأخبرني أن أنتظر حتى اليوم التالي لأن المشكلة كانت بسبب حد معدل الشهادات (rate-limit). كان من المفترض أن يتم إصلاح المشكلة. لم يتم إصلاحها. ثم سألته مرة أخرى، ثم سألت Claude، ثم سألت Claude مرة أخرى… وقد كنا في هذا الوضع “انتظر حتى الغد الساعة X وسيتم إصلاحها بالتأكيد” منذ أسبوع. لا يتم إصلاحها أبدًا، وكلاهما يقولان “آسف، لم يكن يجب أن أفترض أنها ستُصلح، لنجرب هذا بدلاً من ذلك، لأن الآن ستُصلح حقًا”. لا يحدث ذلك أبدًا.
الموقع نفسه يعمل، لكنني أشعر أنه كل مرة أريد فيها إعادة البناء، سيحدث شيء ما، وبصراحة لا أريد الاعتماد على الحلول المؤقتة (الضمادات) طوال الوقت.
أخبرني Claude أن أضيف شيئًا إلى الخطافات (hooks) في web_only.yml، لكن بما أن شيئًا من هذا القبيل لم يُذكر في التعليمات المقدمة هنا على المنتدى، كنت أتوقع حلًا آخر، مثل… حل المشكلة الفعلية.
هل يمكن لأحد مساعدتي في معرفة ما هي المشكلة وأين تكسر الأمور؟ سأقدّر ذلك حقًا، لأنه مرهق في هذه المرحلة. ليس العمل نفسه، بل عدم فهم ما يحدث ولماذا لا يبدو أن “الانتظار حتى الغد” يُصلح أي شيء أبدًا.
شكرًا!
طلبت من Claude شرح ما يبدو أنه المشكلة، ربما يساعد ذلك؟ هذا ما قاله:
العنوان: إعداد حاويتين: مجلد شهادة ECC مفقود بعد التقسيم، حلقة --force تصل إلى حد المعدل عند كل إقلاع
الإعداد: حاويتان (data + web_only)، تم الترحيل من وضع مستقل (standalone). القوالب: web، ratelimited، ssl، letsencrypt، cloudflare. اسم النطاق alltiago.com، لا توجد مستعرات (aliases).
الأعراض: كل بدء تشغيل لـ web_only يصل إلى حد معدل Let’s Encrypt ويفشل nginx في تقديم الخدمة، مما يعيد أخطاء اتصال حتى يتم حذف أسطر ECC يدويًا من /etc/nginx/conf.d/outlets/server/20-https.conf.
ما وجدته:
/shared/letsencrypt/alltiago.com_ecc/ غير موجود في تثبيتي. /shared/letsencrypt/alltiago.com/ (RSA) موجود ويعمل بشكل جيد، ويتجدد بشكل طبيعي.
في web.letsencrypt.ssl.template.yml:
cert_exists() {
[[ "$(cd ${LETSENCRYPT_DIR}/${DISCOURSE_HOSTNAME}$1 && openssl verify -CAfile <(openssl x509 -in ca.cer) fullchain.cer | grep "OK")" ]]
}
issue_cert "ec-256"
if ! cert_exists "_ecc"; then
issue_cert "ec-256" "--force"
fi
لأن المجلد مفقود، تفشل cert_exists "_ecc" عند كل إقلاع، لذا يعمل --force ويطالب بشهادة ECC جديدة تمامًا بغض النظر عما يوجد على القرص. هذا يتم عبر خطاف after_ssl الذي يعدل /etc/runit/1.d/install-ssl، لذا يعمل عند كل بدء تشغيل للحاوية، وليس فقط عند التهيئة الأولية (bootstrap).
النتيجة: خطأ 429 too many certificates (5) already issued for this exact set of identifiers in the last 168h. ثم يعمل --installcert على أي حال ضد المجلد الفارغ ويكتب /shared/ssl/alltiago.com_ecc.cer غير قابل للاستخدام. تم تكوين nginx مع كلا الشهادتين، ولا يمكنه تحميل شهادة ECC، ولن يقدم الخدمة.
تم تأكيد عمله: تحقق ACME HTTP-01 ناجح (تم الاختبار عبر بيئة الاختبار، تم إصدار شهادة ECC بشكل جيد ضد letsencrypt_test، وتم إنشاء هيكل المجلد الصحيح). تم تجديد شهادة RSA بنجاح اليوم. لذا هذه ليست مشكلة DNS أو جدار حماية أو تحقق.
الأسئلة:
- هل هناك طريقة مدعومة لإعادة إنشاء
alltiago.com_ecc/دون انتظار انتهاء حد المعدل؟ - هل يجب أن يؤدي عودة
cert_existsبقيمة خاطئة (false) إلى تشغيل--forceبدلاً من إصدار عادي؟--forceيتجاوز فحص “شهادة صالحة موجودة” ويضمن استنفاد حد المعدل عندما يكون المجلد مفقودًا. - هل هناك طريقة موثقة للعمل بشهادة RSA فقط؟
ملاحظتان واقعتان حتى لا يذهب الموضوع في الاتجاه الخاطئ: تاريخ إعادة المحاولة انتقل من 27 أغسطس إلى 29 أغسطس لأن تجديد RSA اليوم استهلك مكانًا في النافذة المتحركة البالغة 168 ساعة. والسبب في أن لا أحد آخر يبلغ عن هذا هو أنه في التثبيت العادي يتم إنشاء كلا المجلدين عند الإقلاع الأول ولا تعمل فرع --force أبدًا.