كنا سابقًا نقوم بتشغيل إعداد Discourse متعدد المواقع بحوالي 22 منتدى مختلفًا. مؤخرًا، قررنا إزالة تكوين المواقع المتعددة والاحتفاظ بالموقع الافتراضي فقط:
الموقع الافتراضي الآن:forum.mamapedia.com تمت إزالة نطاق المواقع المتعددة القديم:forum.employ.com (و 21 نطاقًا آخر)
المشكلة:
حتى بعد تعطيل إعداد المواقع المتعددة، لا تزال نطاقات المواقع المتعددة القديمة قادرة على تقديم المنتدى الافتراضي (forum.mamapedia.com). على سبيل المثال:
زيارة forum.mamapedia.com تعمل كما هو متوقع
ولكن زيارة forum.employ.com لا تزال تقوم بتحميل منتدى Mamapedia
كنا نتوقع أن النطاقات القديمة مثل forum.employ.com إما:
ستعرض خطأ (نظرًا لعدم تكوينها بعد الآن)
ستعيد التوجيه بشكل صحيح أو تكون غير نشطة تمامًا
ملاحظات الإعداد:
نحن نستخدم شهادات SSL من Cloudflare مع تمكين خيار الوكيل (لا يمر المرور عبر خادمنا مباشرة).
يمكننا إزالة سجلات A للنطاقات القديمة، ولكننا نريد حقًا تحديد السبب الجذري وإصلاحه بدلاً من الاعتماد على حل بديل يعتمد على DNS.
الخطوات المتخذة حتى الآن:
تمت إزالة إعدادات المواقع المتعددة من discourse.conf وقاعدة البيانات
تمت إعادة تشغيل Discourse وتم التحقق من إعدادات app.yml
تم مسح ذاكرة التخزين المؤقت والاختبار في وضع التصفح المتخفي
السلوك المتوقع:
يجب أن يستمر forum.mamapedia.com في العمل
يجب ألا يقوم forum.employ.com والنطاقات القديمة الأخرى بتقديم منتدى Mamapedia
أسئلة:
كيف يمكننا إزالة النطاقات القديمة بشكل صحيح بحيث لا تقدم المنتدى الافتراضي؟
هل نحتاج إلى تعديل إعدادات Nginx/Traefik، أو إعدادات Cloudflare، أم أن هناك تكوينًا خاصًا بـ Discourse فاتنا؟
السبب في حدوث ذلك بسيط. ستختار Multisite منتدى بناءً على اسم المضيف. تثبيت غير متعدد المواقع سيقبل بكل سرور أي اسم مضيف توجهه إليه. طالما قمت بتوجيه جميع أسماء المضيفين القديمة إلى ذلك التثبيت، فسوف يخدم الموقع المتبقي على جميع تلك الأسماء المضيفة.
وجود السجلات القديمة توجه إلى موقعك، هو السبب الجذري.
تنظيف إعداداتك القديمة ليس حلاً مؤقتًا، بل هو الحل.
OMG. لا أتذكر آخر مرة اختلفت معك فيها في مسألة واقعية. كقاعدة عامة، عندما أرى صورتك الرمزية في موضوع علقت عليه، أعرف أنني سأتعلم شيئًا!
هذا صحيح. يدعون، مع ذلك، أنهم تحولوا إلى تثبيت قياسي. لا أصدقهم.
لعدة سنوات الآن (ولكن أعتقد منذ أن أصبح شهادة Let’s Encrypt متاحة)، في تثبيت قياسي إذا قمت بالوصول إليه عبر أي اسم مضيف آخر، فسيقوم بإعادة توجيه (يمكنك التحقق بسهولة عن طريق استخدام رقم IP وقمت للتو بإجراء آخر عن طريق تعيين forum.bigmouth.bass في /etc/hosts إلى تثبيت قياسي وتمت إعادة توجيهه كما هو متوقع. إذا قمت بالوصول إليه عبر https، وهو ما تفعله معظم المتصفحات افتراضيًا الآن، فستحصل على خطأ في الشهادة.
إذا كان كل ما هو مطلوب للوصول إلى موقعك عبر اسم مضيف آخر هو DNS، فيمكن لأي شخص اختطاف موقعك عن طريق إنشاء سجل DNS يشير إلى موقعك.
أعتقد أن هذا هو السحر:
تخميني هو أن app.yml لا يزال يحتوي على شيء مثل هذا:
حققنا من ملف app.yml، ولا توجد إعدادات لإعادة التوجيه المخصصة أو تجاوزات. ومع ذلك، لا تزال حالتنا لا تقوم بإعادة توجيه أسماء المضيف غير المعروفة إلى النطاق الرئيسي.
إعداد Nginx: هل هناك طريقة للتحقق مما إذا كانت منطق إعادة التوجيه من templates/web.ssl.template.yml يُطبّق بالفعل؟ هل يتعين علينا فحص إعداد Nginx المُولد يدويًا داخل الحاوية؟
تصحيح أخطاء Discourse: هل هناك سجلات أو أوامر يمكننا تشغيلها داخل الحاوية للتأكد من أن Discourse يتعامل مع أسماء المضيف بشكل صحيح؟
أسباب محتملة أخرى: إذا كان ملف app.yml نظيفًا، فما الذي قد يمنع سلوك إعادة التوجيه المتوقع؟ هل يمكن أن يكون Cloudflare أو إعداد آخر يتداخل؟
سنكون ممتنين لأي مؤشرات تساعدنا على البحث بشكل أعمق في هذه المشكلة!
هل تم تفعيل السحابة البرتقالية لجميع النطاقات القديمة؟ هل يؤدي إيقاف تشغيل السحابة البرتقالية إلى حل المشكلة؟ إذا كان الأمر كذلك، فكما توقعت طوال الوقت، ريتشارد على حق وتحتاج إلى تنظيف إعداداتك.
ولكن إذا كان استخدام Cloudflare يسمح لطرف خبيث (أنت في هذه الحالة) بتقديم موقع شخص آخر على نطاقه، فهذا يبدو مشكلة.
لقد قمنا بالفعل بإزالة النطاقات القديمة ولكن نعم، كان لديهم زر برتقالي ممكّن، والمشكلة الآن هي إذا حصل أي شخص على عنوان IP الخاص بخادمنا وسجل هناك مع تمكين خيار الوكيل، فسوف يخدم موقعنا بنطاقهم.
يجب عليك تشغيل discourse-setup للتأكد من أن لديك تثبيتًا قياسيًا بالفعل. إذا قمت بلصق app.yml القديم الخاص بك، فقد يكون لديك شيء بداخله لا ينتمي. ما زلت لست مقتنعًا تمامًا بأن لديك إعدادًا قياسيًا.
ما زلت لست مقتنعًا بأن هذا هو الحال، ولكن إذا كان الأمر كذلك، فلا يمكنك فعل شيء حيال ذلك.
Hmm. حسنًا، لو كان الموقع الرئيسي، لتوقعت أن يكون هذا المسار هو https://forum.mamapedia.com/user_avatar/forum.mamapedia.com/jakeatgetit/24/5872_2.png، ولكن هذا لا يعمل أيضًا.
إذا كان لا يزال لديك الموقع القديم، فسأقوم بعمل نسخة احتياطية من هذا الموقع واستعادتها على الموقع الجديد.
شكراً @pfaffman ، ما قمت به حتى الآن يبدو أنه يعمل.
لقد دخلت إلى الخادم القديم ونقلت البيانات من /var/discourse/shared/standalone/uploads/default إلى نفس المسار على الخادم الجديد وعادت جميع صور المستخدمين والمشاركات.
المشكلة الجديدة هي أن العلامة التجارية للموقع لا تعمل حتى لو حاولت تحديثها.
بالعودة إلى هنا لمعرفة ما إذا كان لدى أي شخص أي أفكار. نحن قريبون جدًا من إغلاق هذا من جانبنا، ونحتاج فقط إلى بعض المساعدة في استكشاف مشكلة حفظ ‘غير الشعار’ وإصلاحها. شكرًا مقدمًا على أي أفكار لحلها!
