فشل إعادة البناء لخادم غير مُحَافَظ عليه بشكل جيد ومشكلة ملكية - أبحث عن مساعدة

حدث خطأ أثناء التحديث الخاص بي

api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })

يرجى مساعدتي في إصلاحه.

إذا كانت النسخ الاحتياطي تذهب إلى هناك، فلديك وصول إليها. ونعم، وكذلك أي شخص يمتلك تلك الحاوية.

لا تتردد في فتح موضوع في Marketplace إذا كنت ترغب في استكشاف خدمات طرف ثالث مدفوعة.

هذا موقف صعب - أتعاطف معك.

شخصيًا، سأرغب بشدة في الحصول على نسخة احتياطية قبل محاولة إعادة البناء. إذا لم تكن عملية النسخ الاحتياطي المنتظمة مفيدة لك (لأنها ترسل النسخ الاحتياطية إلى مكان غير متاح)، فسأحاول بطريقة ما الحصول على نسخة احتياطية من قاعدة البيانات باستخدام سطر الأوامر، لكنني لست متأكدًا تمامًا من كيفية القيام بذلك. ربما pg_dump داخل docker؟

أو ربما يمكنك استخدام وصولك إلى سطر الأوامر لإعادة توجيه النسخ الاحتياطية إلى القرص المحلي بدلاً من S3.

ولكن في كلتا الحالتين ستحتاج إلى مساحة قرص محلية كافية.

تعديل: تم النشر بالتزامن مع جاي.

شكرًا لك - فكرتي العامة إذا كان بإمكاننا إجراء نسخة احتياطية هي بالفعل إعادة توجيه النسخة الاحتياطية إلى قرص محلي بدلاً من S3 وسيكون لدينا مساحة لها.

إنه خطئي لأنني لم أكتشف النسخة الاحتياطية المحلية الليلة الماضية بدلاً من إعادة البناء - البصيرة بأثر رجعي واضحة تمامًا في هذا الشأن. لقد قللت من تقدير تأثير إعادة البناء.

هل يمكنك مساعدتي في فهم هذا؟ هل تقصد أن بيانات الاعتماد يجب أن تكون موجودة إذا تم توجيه النسخ الاحتياطية إلى هناك؟ (لقد أكدنا ظهور نسخة جديدة في لوحة تحكم Discourse الخاصة بنا)

المشكلة هي، إذا كنا بحاجة إلى بيانات الاعتماد للوصول إلى النسخة الاحتياطية، فأنا لا أعتقد أن أي شخص لديه تلك البيانات باستثناء الشخص الذي اختفى.

هل يمكن لـ literatecomputing الحصول على نسخة احتياطية محلية واستعادة موقعنا الحالي إلى خادم جديد مُدار إذا تولوا العمل؟

إذا كان S3 bucket يحتوي على نسخ احتياطية حديثة مثل الأسبوع الماضي، فإن Discourse لديه بيانات الاعتماد الخاصة بالـ bucket. من المحتمل أن تكون في app.yml أو في إعدادات الموقع.

ولكن، لست بحاجة إلى الوصول إلى S3 bucket بنفسك، يجب أن تكون قادرًا على تنزيل النسخة الاحتياطية من خلال Discourse.

هل ترى النسخ الاحتياطية في /admin/backups؟
إذا كان الأمر كذلك، فماذا يحدث عندما تحاول تنزيلها؟

يمكنك أيضًا تغيير إعدادات الموقع - النسخ الاحتياطية - موقع النسخ الاحتياطي إلى “التخزين المحلي”.

نعم. إذا كنت تقوم بالنسخ الاحتياطي إلى S3، فإن بيانات الاعتماد موجودة في قاعدة البيانات الخاصة بك أو في ملف yml.

نعم. إما في SiteSettings أو في ملف yml يوجد الإعداد backup_location. إذا كان في SiteSettings وليس في قاعدة البيانات، فسيكون الأمر أصعب، ولكنه ليس مستحيلاً التغيير.

أنا مجرد مبتدئ ولكن هل يمكن أن يكون

من الموضوع الأخير الذي تم الإبلاغ عنه عن مشكلة ملكية ملف عند إعادة البناء

إذا كان لديك وصول سطر الأوامر، فلماذا لا تقوم بعمل نسخة احتياطية من سطر الأوامر؟

لدي وصول جذري. لقد قمت بعمل نسخة احتياطية من سطر الأوامر، لكنها تم دفعها إلى S3. بفضل تعليقات @pfaffman، أدرك الآن أنه يمكنني محاولة سحب النسخة الاحتياطية من S3 إلى الجهاز المحلي - أحتاج فقط إلى الوقت لمحاولة ذلك.

هل ترى الإعداد backup_location في الإعدادات في واجهة المستخدم (أم أن الخادم معطل لذلك لا يمكنك الرؤية؟)

هل تقصد هذا التحذير؟

تحذير: الملف containers/app.yml قابل للقراءة من قبل الجميع. يمكنك تأمين هذا الملف عن طريق تشغيل: chmod o-rwx containers/app.yml

إنه تحذير. لسنوات عديدة، كان الإعداد الافتراضي هو جعل هذا الملف قابلاً للقراءة من قبل الجميع (بافتراض أن معظم المستضيفين الذاتيين سيسجلون الدخول كـ root ولن يكون لديهم مستخدمون آخرون)، ولكن في مرحلة ما تقرر أن وجود الأسرار في هذا الملف قابلة للقراءة من قبل الجميع ليس من أفضل الممارسات. نظرًا لأنك تقوم بتشغيل المشغل كـ root، سيتمكن root دائمًا من قراءة الملف.

لا أرى admin/backups أين هذا؟ المكان الوحيد الذي رأيت فيه backups هو /var/discourse/shared/standalone/backups/default، ولكن هذه كلها نسخ احتياطية محلية قديمة.

سأتابع موقف إعدادات الموقع لاحقًا عندما يستيقظ الشخص الذي يمكنه الوصول إليها (إنهم على التوقيت البريطاني). أفترض أنه ليس لديهم وصول لأن الموقع معطل.

لا أرى إعدادًا محددًا لـ backup_location في ملف app.yml.

أيضًا، الشريط الجانبي ولكني رأيت في قسم “نبذة عنا” في شركتك أنك مدرس سابق في مادة الحاسوب. هذه هي وظيفتي اليومية حاليًا :smiley:

ليس هذا. عندما تتاح لي الفرصة، سأنشر الخطأ المحدد، ولكنه كان من محاولة ترقية العقدة، كما قلت، وليس أثناء إعادة البناء.

أضف هذا إلى عنوان URL الخاص بالمنتديات لديك. يجب أن تكون قادرًا على رؤية النسخ الاحتياطية الخاصة بك في واجهة المستخدم.

أوه، فهمت. كنت أبحث عن هذا على الخادم نفسه. الموقع معطل تمامًا لذلك ليس لدي وصول إلى الصفحة.

مجرد سؤال عام. ما هي مواصفات الخادم؟ بما في ذلك إصدار نظام التشغيل.

هذه صورة قديمة [1] ومن المحتمل أن تكون مصدر هذه الأخطاء:

ربما تحتاج إلى git pull دليل discourse_docker (الدليل الذي تقوم منه بتشغيل launcher).

كالعادة، قم بعمل نسخة احتياطية للخادم أولاً لأنك في حالة متدهورة.


  1. في وقت الإنترنت ↩︎

تمكنا من الحصول على نسخة احتياطية محلية جديدة مرتبة اليوم، لذا أقوم بتنزيلها محليًا الآن.

إذًا، سأقوم فقط بـ pull في /var/discourse، ثم أحاول إعادة البناء للتحديث؟

Your branch and 'origin/main' have diverged,
and have 15 and 201 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

diverged هو بالفعل أقل من الواقع :smile:

أفترض أنك كنت تقوم بتثبيت تكوينات الحاوية الخاصة بك، لذا قد يؤدي git pull أو git pull --rebase إلى وصولك إلى ما تحتاجه، يمكنك تجربته :+1:

صديقي، ليس لدي أدنى فكرة عما كان يحدث، لكنني سأرى ما سنحصل عليه بسحب أو إعادة تأسيس إذا لزم الأمر. سأقوم بإنشاء نافذة صيانة جديدة لأنه، لسبب ما، عاد الموقع للعمل بالإصدار القديم. سأقوم بتحديثكم جميعًا بالنتائج.

أنا أقدر حقًا كل هذه الحكمة!