أنا أستعد لترحيل بعض نسخ Discourse إلى استضافة جديدة. الخطة هي جعل الموقع القديم للقراءة فقط، ثم أخذ نسخة احتياطية، ونقلها إلى الاستضافة الجديدة واستعادتها مع تحديث إعدادات DNS (مع وقت حياة TTL قصير). هذه العملية مأخوذة بالكامل من أدلة هنا وفي أماكن أخرى.
لقد قمت ببعض المحاولات التجريبية باستخدام حيلة في ملف /etc/hosts لمحاكاة تحديث DNS (مع تعطيل DNS عبر HTTPS في المتصفح أيضًا). حتى الآن كل شيء على ما يرام.
ومع ذلك، وعلى الرغم من أنني كنت حريصًا على إغلاق المتصفح في موقع ‘المصدر’، ثم فتحه فقط بعد اكتمال الترحيل في موقع ‘الوجهة’، فإنه ينسى أنه كان مسجّل الدخول.
من الواضح أنني لا أريد أن يتم تسجيل جميع أعضاء الموقع خارجًا أثناء عملية الترحيل. أين يجب أن أبحث أو ما الذي أفتقده هنا؟
المستخدم الذي أختبره حاليًا لديه صلاحيات مسؤول ويستخدم المصادقة الثنائية (2FA)، كما أن حاويات Discourse خلف Nginx الذي ينهي SSL، هل قد يكون لهذا تأثير على المشكلة؟
أعتقد أنني سأحاول إنشاء بعض حسابات الاختبار بدون المصادقة الثنائية (2FA) في حال كان لذلك أي علاقة بالمشكلة - فقليل جدًا من أعضاء الموقع يستخدمون المصادقة الثنائية، لذا قد يكون ذلك مقبولًا إذا كانت المشكلة تقتصر على فقدان تلك الجلسات فقط.
كما سأتحقق من أن خوادم المصدر والوجهة متزامنة مع بروتوكول وقت الشبكة (NTP)، رغم أنني أعتقد أن الفرق بينهما لا يتجاوز بضع ثوانٍ الآن.
بغض النظر عن ذلك، أعتقد أنه لا يزال بإمكاننا مراجعة الكود المصدري لمحاولة فهم ما يدخل في رمز المصادقة وما قد يسبب المشكلة…
كيف تتأثر ملفات تعريف الارتباط للجلسة بـ “التوقيعات” الخاصة بـ SSL (خاصة في حالتي، حيث تستخدم المضيفات الجديدة والقديمة نفس ملفات شهادة SSL، ونفس اسم النطاق)؟
بينما لا أمانع في الاعتذار للأعضاء ()، إلا أنني أود حقًا تجنب هذا السيناريو لأنني أستطيع رؤية بعض الآثار الجانبية غير المفضلة:
قد لا يسجل الأعضاء الدخول مرة أخرى، ويصبحون أقل احتمالًا للمشاركة في المنتدى في المستقبل.
قد ينسى الأعضاء كلمات مرورهم ويحتاجون إلى مساعدة لاستعادتها.
قد ينسى الأعضاء كلمات مرورهم وينشئون حسابات جديدة، مما يترك العديد من “الحسابات الميتة” على المنتدى، ويفقد هويات مكررة ومربكة دون ملاحظات مستخدم أو سجل منشورات، إلخ…
يعمل جزء SSL بشكل صحيح تمامًا أمام Discourse (حتى مع خدعة ملف المضيفين)، وهو ما يجب أن يكون الحال؛ وإلا فإن موازنات التحميل ستواجه مشاكل. وعلى حد علمي، لا يعرف Discourse حتى عن SSL لأن إنهاء الاتصال يتم على Nginx في هذا الإعداد.
أعتقد أن سؤالًا مختلفًا هو: “هل من الممكن نقل خادم Discourse إلى عنوان IP جديد دون تسجيل خروج الجميع؟” لقد افترضت أن هذا ممكن، لكن ربما كان هذا الافتراض خاطئًا…
يتم تشفير ملفات تعريف الارتباط للجلسة باستخدام مفتاح سري يتم إنشاؤه عشوائيًا، والذي يتم تخزينه افتراضيًا في Redis. لا يتم تضمين بيانات Redis في النسخ الاحتياطي، لذا يتم إعادة إنشاء مفتاح سري جديد عند استعادة الموقع على خادم جديد.
يمكنك تعيين المفتاح السري يدويًا باستخدام متغير بيئة DISCOURSE_SECRET_KEY_BASE في ملف app.yml الخاص بك. لذا، يمكنك تجربة شيء مثل هذا للحفاظ على الجلسات:
على الخادم الحالي، أدخل وحدة التحكم وابحث عن المفتاح السري من Redis
أضف DISCOURSE_SECRET_KEY_BASE إلى قسم env: في ملف app.yml على الخادم القديم، باستخدام القيمة التي وجدتها في (1)، ثم أعد بناء التطبيق. نظريًا، إذا سار كل شيء على ما يرام، يجب أن يستخدم Discourse الآن القيمة من ملف app.yml، وستستمر جلسات المستخدمين. يمكنك التحقق من استخدام متغير البيئة بتشغيل
GlobalSetting.secret_key_base
تأكد من أن ملف app.yml على الخادم الجديد يحتوي على نفس SECRET_KEY_BASE. عند استعادة النسخة الاحتياطية، يجب أن تستمر جلسات المستخدمين.
لم أقوم باختبار هذه العملية، لذا إذا كنت تخطط لاستخدامها في منتدى إنتاجي، فتأكد من تجربتها أولاً!
ملاحظة جانبية: يجب ألا تشارك المفتاح السري بين مثيلات Discourse متعددة. فامتلاك المفتاح السري قد يسمح لشخص ما بفك تشفير وتعديل ملف تعريف الارتباط للجلسة على موقع ما، مما قد يؤدي إلى عواقب أمنية سيئة للغاية.
ممتاز - سأقوم بتجربة هذا على نسخة تجريبية. وسأرى ما إذا كان بإمكاني إخباركم عما إذا كان يعمل أم لا
فهمت ذلك. أفكر الآن فيما إذا كان ينبغي تقديم طلب ميزة لإضافة خيار لتصدير هذا المفتاح في النسخ الاحتياطية؟ فبالنسبة لي، يبدو أن فقدان جميع جلسات الموقع أمرًا «سيئًا جدًا» لأن هناك آلاف الحسابات على الموقع. وقد أظهرت ممارسة عملية الهجرة هذه المشكلة، لكنني أعتقد أنه إذا ضاعت الآلة أو مثيل Docker لسبب ما، فسيُفقد المفتاح أيضًا وسنواجه نفس فقدان الجلسات.
في الوقت الحالي، إذا تمكن شخص ما من سرقة نسخة احتياطية من نظام Discourse، فسيكون لديه جميع بيانات المنتدى. لكنه لن يكون قادرًا على تسجيل الدخول إلى المنتدى المباشر. فكلمات المرور مشفرة، ومفاتيح واجهة برمجة التطبيقات مشفرة، وملفات تعريف الارتباط للجلسات مشفرة.
إذا قمنا بتضمين المفتاح السري داخل النسخة الاحتياطية، فإن أي شخص يمتلك نسخة احتياطية يمكنه الحصول على الوصول إلى المنتدى المباشر، والقيام بعمليات التصيد الاحتيالي/الاحتيال/إلخ.
ممتاز! نحن منفتحون تمامًا على إنشاء موضوع هنا في قسم Meta يشرح كيفية الترحيل من مفتاح سري لـ Redis إلى مفتاح سري لملف app.yml. ويمكن ربطه من موضوع ‘الانتقال إلى خادم مختلف’.
في رأيي المتواضع، يجب أيضًا تحسين أمان النسخ الاحتياطية الافتراضية. فبينما قد تكون كلمات المرور وجلسات المستخدمين مشفرة ومحمية، قد تحتوي الرسائل الخاصة وغيرها من البيانات على معلومات حساسة يجب أن تظل سرية. تجدر الإشارة بشكل خاص إلى أننا في منتدى مجتمعنا نشجع المستخدمين على استخدام الرسائل الخاصة لتبادل تفاصيل الاتصال وترتيب عمليات البيع أو الاستلام، بدلاً من وضع أرقام الهواتف والعناوين في أماكن عامة.
النهج الذي أعتمده للنسخ الاحتياطي هو الدخول إلى النسخة، إنشاء نسخة احتياطية، ثم تشفيرها فورًا باستخدام مفتاح عام عبر أداة gpg. وهذا يجعل النسخة الاحتياطية غير مجدية لأي شخص لا يملك المفتاح الخاص المقابل، والذي أحفظه بعيدًا عن الخادم ومحميًا بكلمة مرور.
مع ذلك، إذا لم يتغير المفتاح السري للجلسات، فستكون هناك حاجة إلى نسخه احتياطيًا مرة واحدة فقط، لذا فإن إجراء بسيط لذلك هو كل ما يلزم - ونأمل أن يكون هذا ما أشرتم إليه أعلاه.
سأجرب الأمر وأرى ما إذا كان بإمكاني إنشاء ذلك الموضوع لك
نقطة جيدة. لكن هذا لا يغير حقيقة أن الأعضاء قد يستخدمون الرسائل الخاصة لتبادل تفاصيل شخصية أو أشياء لا يرغبون في أن تكون في المجال العام. لذلك، من المهم حماية هذه البيانات بقدر ما هو معقول.
هذا خارج عن الموضوع قليلاً… لكن قد تود الاطلاع على Discourse Encrypt (deprecated) للحصول على رسائل «خاصة» حقًا. لن يتمكن المهاجم من قراءة النسخ الاحتياطية المسربة أو المسروقة للرسائل الخاصة المشفرة.
(ومع ذلك، وكما ذكرت، لا يزال هناك افتراض بأن المسؤولين موثوق بهم)
@david - من فضلك، هل يمكنك التحقق من المنشور التالي ونقله إلى قسم howto إذا كان ذلك مناسبًا؟ (لا يمكنني إنشاء موضوع هناك، وأيضًا قام Akismet بإخفاء المنشور، لذا يجب إصلاح ذلك أيضًا )
@david - شكرًا جزيلًا لك على حل هذه المشكلة وتقديم النصيحة، آمل أن تفيد الآخرين أيضًا - إنه بالتأكيد راحة كبيرة لنا أن نتمكن من الهجرة والحفاظ على جلساتنا
)، إلا أنني أود حقًا تجنب هذا السيناريو لأنني أستطيع رؤية بعض الآثار الجانبية غير المفضلة:
)