عند ترحيل (عبر نسخة احتياطية) نظام Discourse من اسم نطاق (hostname) إلى آخر، قد يرغب المسؤول في الاحتفاظ باسم النطاق القديم ولكن إعادة توجيه طلبات خادم الويب لاستخدام الاسم الرسمي الجديد، على سبيل المثال:
للأسف، لا يكون ذلك سهلاً بمجرد تغيير سجل CNAME أو A في نظام أسماء النطاقات (DNS)؛ حيث سيُنتج عميل المتصفح خطأً أو تحذيرًا لأن اسم النطاق لا يطابق الشهادة المُنشأة من قبل تثبيت Discourse عبر Let’s Encrypt.
في حالة التثبيت اليدوي لخادم الويب، سأستخدم أداة certbot لـ إنشاء شهادة بأسماء متعددة تُعيّن لها. ومع ذلك، فإن إعدادات Discourse تُمرّر اسم نطاق Discourse (فقط) إلى Let’s Encrypt، ولا يوجد مفهوم واضح في إعدادات Discourse للأسماء البديلة (aliases).
هل قام أي شخص بإعداد مثل هذا الترتيب، أم لديه فكرة حول أفضل طريقة لتحقيق ذلك؟ أتخيل أن الأمر سيتضمن بعض التعديلات على قوالب SSL و Let’s Encrypt.
ليس مخصصًا لـ Discourse، ولكن عندما أحتاج إلى إعادة التوجيه عبر HTTPS، أقوم بإعادة توجيه كل شيء. وهذا يعني وجود خادم يقوم بإعادة التوجيه من العنوان القديم إلى العنوان الجديد. بعض خيارات الاستضافة تتولى هذا الأمر في الخلفية، ويُشار إليها أحيانًا بـ “إعادة توجيه النطاق” أو خدمة “التحويل”.
لم أعد أفكر في هذا الأمر بعد الآن، لأن كل محاولة أخرى كانت محفوفة بالمشاكل.
لن يستجيب Discourse إلا لاسم مضيف واحد. إذا كنت تريد أكثر من اسم مضيف — حيث أن حالتك الاستخدامية، المتمثلة في دعم اسم المضيف السابق، هي الأكثر شيوعًا — فستحتاج إلى إعادة توجيه أحدهما إلى الآخر.
أوصي بذلك خارج نطاق Discourse. فقط قم بإنشاء تكوين nginx سيحمل شهادة خاصة به، ويحتوي على server_name لاسم المضيف القديم، ويعيد توجيه كل شيء إلى اسم المضيف الجديد.
في الواقع، إذا كنت تستخدم تثبيتًا قائمًا على Docker بنسخة واحدة لكل خادم، فسيستجيب بشكل صحيح لأي عدد من إدخالات DNS (حيث يستمع nginx إلى المنفذ 80 والمنفذ 443 لجميع أسماء النطاقات)، ويعيد كتابة عنوان URL بشكل صحيح إلى اسم النطاق “الجديد” المعيارى دون مشاكل. هذا الجزء يعمل بشكل ممتاز وسلس. (يمكن للأشخاص الراغبين في تجربة ذلك إضافة اسم نطاق وهمي إلى ملف localhost على جهازهم وتوجيهه إلى عنوان IP لموقع Discourse المفضل لديهم.)
المشكلة الوحيدة التي أواجهها هي تحذير SSL لأن استجابة إعادة الكتابة من nginx تأتي من https://old.example.org/foo وترسل إعادة توجيه HTTP 302 إلى عنوان URL الجديد.
أفضل عدم الاضطرار إلى صيانة خادم ويب منفصل فقط لتنفيذ قاعدة إعادة كتابة، إذا أمكن.
تحديث: تم تكوين اسم النطاق الثانوي بنجاح في التثبيت المستقل، وتم إصدار شهادة Let’s Encrypt للتعامل مع الأسماء القديمة والجديدة.
المتطلبات المسبقة: لم أقوم بعد بتغيير إعدادات DNS لتوجيه المستخدمين إلى الموقع الجديد؛ أردت التأكد من عمل كل شيء مسبقًا. لذلك كنت أستخدم إدخال localhost على جهاز الاختبار الخاص بي. وهذا يعني أنني لم أستطع إجراء التحقق العادي من Let’s Encrypt، واضطررت لاستخدام طريقة “DNS” في acme.sh التي لا يُنصح بها عمومًا لأنها لا تدعم التجديد التلقائي. وهذا مقبول بالنسبة لي؛ لأنني سأقوم بالتبديل خلال مدة 30 يومًا لشهادة “الأولى” (الشهادة المصدرة حديثًا والتي تغطي اسمين).
في ملف web_only.yml (قد تستخدم app.yml) تحت قسم hooks:، وقبل الإضافات، أضف ما يلي:
في إعدادات DNS، أنشئ سجل TXT مؤقت/وهمي لـ _acme-challenge.old.example.org بمدة صلاحية (TTL) مدتها 5 دقائق (يمكنك جعلها أقصر إذا أردت)، وانتظر حتى يتم نشرها لتتمكن من إجراء التغيير بسرعة باستخدام مفتاح التحقق من acme.sh (Let’s Encrypt).
أوقف الموقع وقم بإجراء تحقق من التصحيح (اختباري) لجعل النظام يدرك أن الإدخال الجديد له مدة صلاحية قصيرة:
نعم، يمكن لوضع وكيل عكسي مثل كلاودفلر (أو أي وكيل عكسي تفضله أمام موقع ديسكورش) تجاوز المشكلة من خلال تطبيق قواعد إعادة الكتابة “على مستوى أعلى”. في هذه الحالة، لم تكن كلاودفلر خيارًا لأسباب أمنية وأخلاقية.
