أولاً، التقدير حيث يستحق: المثبت الجديد هو تحسين كبير. عندما يعمل، وهو ما يحدث في معظم الأحيان، فهو مسار أكثر ودية من التدفق اليدوي الأقدم، وأنا قادر على الحصول على تنصيبات نظيفة من خلاله. قم بتشغيل المثبت، أكمل التسجيل/التفعيل كما هو معتاد، ثم ابدأ في تعديل app.yml حسب مواصفاتاتي. سهل جداً. شكراً جزيلاً لـ @Falco والفريق! ما الفرق الهائل عن أيام التنصيب القديمة لـ Discourse.
أنا أنشر هذا لأنني أيضاً واجهت اسم مضيف واحد تسبب لي في ضياع، وأعتقد أن التجربة قد تشير إلى بعض الأماكن حيث يمكن للمثبت أن يظهر معلومات أوضح لمضيفي أنفسهم.
ما نجح
قمت بتنصيب Discourse بنجاح على خادم جديد باستخدام:
- نطاق خاص: نعم
- SMTP: نعم
- تدفق المثبت الحالي
وصل التنصيب إلى:
Tallyho!
تهانينا، لقد قمت بتنصيب Discourse!
سجل حساباً جديداً للبدء.
لذا فإن هذا ليس منشوراً عن “المثبت الجديد معطل”. يمكن للمثبت أن يعمل بشكل جيد جداً.
اسم المضيف الصعب
في تنصيب آخر، باستخدام المسار العام نفسه، كان اسم المضيف المستهدف:
forum.domain.tld
كان أمر المثبت:
wget -qO- https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse | sudo bash
كانت الخيارات تقريباً:
- إنشاء ملف تبديل بحجم 2 جيجابايت: نعم
- استخدام نطاق خاص بي: نعم
- اسم المضيف:
forum.domain.tld - تكوين SMTP: نعم
- مزود SMTP: SendGrid
- منفذ SMTP: 587
وصل المثبت إلى:
[4/5] التحقق من تكوين النطاق
? جاري التحقق من اسم النطاق الخاص بك...
? نجحت الاتصال بـ forum.domain.tld.
ثم كتب التكوين وأعاد بناء التطبيق.
ولكن لم يظهر الموقع بشكل نظيف في المتصفح. أصبحت الأعراض في النهاية:
forum.domain.tld رفض الاتصال
لم تفلح محاولات إعادة البناء/الإعادة المتكررة في حل المشكلة.
نتيجة Discourse Doctor
وجد ./discourse-doctor حاوية التطبيق وقيم التكوين المتوقعة. كانت الحاوية تعمل وتبدو المنافذ 80/443 مربوطة.
ولكن أبلغ عن:
إصدار Discourse في forum.domain.tld: غير موجود
وبعد ذلك:
إصدار Discourse في localhost: غير موجود
جعلت هذه المشكلة تبدو مختلفة عن انتشار DNS العام العادي وحده.
حد معدل ACME
في وقت سابق من مسار استكشاف الأخطاء وإصلاحها، حاولت أيضاً التنصيب باستخدام مسارات Discourse المدعومة من الخدمة:
- DiscourseID
- تدفق
yoursite.discourse.diy
هذا هو المكان الذي حدث فيه سلوك النقر المتكرر/الإعادة على الخادم، حيث أظهر سجل ACME حد معدل من Let’s Encrypt:
النوع: urn:ietf:params:acme:error:rateLimited
الحالة: 429
التفاصيل: تم إصدار شهادات كثيرة جداً (5) بالفعل لهذا المجموعة الدقيقة من المعرفات...
كان مسار السجل المفيد:
/shared/letsencrypt/acme.sh.log
كان هذا درساً كبيراً. من المتصفح، بدا الفشل وكأنه مشكلة وصول عامة. ولكن الحاجز الحقيقي في ذلك الوقت كان إصدار الشهادة.
كان الجزء الأكثر إرباكاً هو أن كتلة الحالة النهائية/اكتمال التنصيب لم تظهر هذا كخطأ قابل للتنفيذ. كانت الأعراض النهائية التي يواجهها المستخدم هي أن الموقع رفض اتصال المتصفح.
أظهر الفحص اللاحق سلسلة الفشل بوضوح أكبر:
حد معدل ACME 429
-> ملفات .cer بحجم صفر تحت /shared/ssl
-> يحاول nginx تحميل الشهادة ذات الحجم الصفري
-> يفشل nginx في البدء
-> ترفض المنافذ 80/443
-> يقول المتصفح إن الاتصال مرفوض
طلب ميزة مدفون في التجربة:
سيكون من المفيد جداً إذا قام المثبت/إعادة البناء بفحص /shared/letsencrypt/acme.sh.log بعد خطوة الشهادة وعرض أخطاء حد المعدل مثل:
rateLimited
شهادات كثيرة جداً
الحالة: 429
على سبيل المثال:
تم الوصول إلى حد معدل Let's Encrypt لهذا اسم المضيف.
انتظر حتى وقت إعادة المحاولة المعروض في /shared/letsencrypt/acme.sh.log قبل إعادة المحاولة.
قد لا تساعد إعادة البناء المتكرر.
هذا سيوفر على المستخدمين مطاردة DNS، SMTP، اقتباس app.yml، Docker، أو مشاكل جدار الحماية عندما تكون المشكلة الفعلية هي ACME.
بعد زوال حد المعدل
بعد زوال نافذة حد معدل Let’s Encrypt، لا زلت أرى حالة التحقق من النطاق مربكة.
أبلغ المثبت:
[4/5] التحقق من تكوين النطاق
? جاري التحقق من اسم النطاق الخاص بك...
? نجحت الاتصال بـ forum.domain.tld.
ولكن لا يزال البحث المحلي عن DNS يظهر:
Resolve-DnsName -Name "forum.domain.tld"
مع:
Resolve-DnsName: forum.domain.tld : اسم DNS غير موجود.
كيف يمكن لهذين الأمرين أن يتعايشا؟
يمكنني تخيل عدة احتمالات:
- كان الخادم ومحطة العمل تستخدمان محللات تكرارية مختلفة
- كان أحد المحللات يحتوي على NXDOMAIN قديم مخزن مؤقتاً
- كان انتشار DNS جزئياً في ذلك الوقت
- يتحقق المثبت من شيء آخر غير البحث العادي عن DNS
- كان المثبت أو خدمة ذات صلة تحتوي على حالة تحقق مخزنة مؤقتاً
لا أزعم أي واحد منها صحيح. أنا ألاحظ بشكل أساسي أنه من مقعد المستخدم، يمكن أن يجعل قول المثبت “نجح الاتصال” أخطاء DNS أو الوصول اللاحقة أكثر صعوبة في التفسير.
فحص عزل DNS
لاختبار ما إذا كان هذا مجرد انتشار بطيء لـ Cloudflare، أضفت سجلاً آخر في نفس المنطقة:
test.domain.tld
خلال لحظات قليلة، كانت نتائج فحص DNS العام خضراء.
هذا جعلني أقل ثقة في أن انتشار Cloudflare العام كان المشكلة بأكملها. بدا الأمر وكأن المشكلة كانت خاصة بـ forum.domain.tld.
تنصيبات مقارنة
كان لدي أيضاً تنصيب ناجح على اسم مضيف آخر:
discourse.domain2.tld
باستخدام مسار المثبت العام نفسه.
كان اسم مضيف اختباري آخر، لتشخيصات DNS:
forum.domain3.tld
التنصيبات المقارنة هي ما دفعني بعيداً عن “المثبت الجديد معطل” نحو “حدث شيء خاص باسم المضيف هنا.”
النظرية الحالية
نظرية الحالية، غير مثبتة، هي أن forum.domain.tld قد كان لديه بعض الحالة المخزنة/المحتجزة/المخزنة الخاصة باسم المضيف في مكان ما خارج الخادم نفسه.
الأماكن التي تساءلت عنها:
- DiscourseID
- تدفق
yoursite.discourse.diy - التحقق من النطاق من جانب المثبت
- بعض العلاقة المخزنة بين محاولة إعداد سابقة واسم المضيف
السبب في تساؤلي حول مسارات الخدمة المدعومة هذه هو أنني حاولت سابقاً استخدامها مع اسم المضيف المشكلة نفسه، وكان هذا أيضاً المسار حيث وصلت المحاولات المتكررة في النهاية إلى حد معدل Let’s Encrypt.
مرة أخرى، هذه فرضية، وليس استنتاجاً.
أسئلة
- هل يتصل المثبت الجديد بخدمة يسيطر عليها Discourse أثناء تنصيب النطاق الخاص؟
- هل يحجز DiscourseID أو تدفق
discourse.diyأسماء المضيفين، يتذكرها، أو يخزنها مؤقتاً؟ - هل هناك أي مسار إطلاق/إعادة تعيين لاسم مضيف كان مستخدماً أو حاول أثناء الإعداد سابقاً؟
- ما الذي يتحقق منه
[4/5] التحقق من تكوين النطاقبالضبط؟ - هل يمكن للمثبت أن يعرض فشل حد معدل ACME بوضوح أكبر قبل كتلة الحالة/النتيجة النهائية؟
ما كان سيساعد
ثلاث أشياء كانت ستجعل مسار استكشاف الأخطاء وإصلاحها أوضح بكثير:
- تحذير واضح من المثبت عندما يحتوي
/shared/letsencrypt/acme.sh.logعلى فشل حد المعدل. - شرح قصير عما يتحقق منه خطوة التحقق من النطاق فعلياً.
- إذا كان هناك أي ذاكرة مخزنة أو حجز لاسم المضيف من جانب DiscourseID /
discourse.diy/ المثبت، طريقة مرئية لفحص أو إطلاق هذه الحالة.
شكراً مرة أخرى على العمل على المثبت الجديد. إنه حقاً يشعر وكأنه الاتجاه الصحيح. أنا أنشر هذا بهذا الروح: عمل بشكل جميل عندما عمل، والحافة الخشنة هنا تبدو وكأنها النوع من الأشياء التي يمكن أن تجعل رسائل المثبت الأفضل تشخيصها أسهل بكثير.
كتب بإدخالاتي من قبل صديقي الجديد Codex.