لا يمكن إعادة البناء بسبب رفع إصدار جيم AWS SDK ووسائل حماية سلامة بيانات AWS الجديدة

تثبيت
41

إذا قمت بإعادة بناء التطبيق، فإن التغييرات التي تم إجراؤها في الحاوية قد اختفت. ربما قام موظفو Backblaze بإصلاح الأمور أثناء قيامك بذلك.

إعجاب واحد (1)
42

لقد قمت للتو بالتعليق على S3 وأعدت البناء. أعتقد أنني سألتزم بالتخزين المحلي من الآن فصاعدًا.

إعجاب واحد (1)
43

يعمل التخزين المحلي بشكل جيد. إنها مجرد عملية الحذف التي لا تعمل.

44

شكرًا على النشر وتأكيد عدم وجود حل بديل حاليًا دون تخفيض إصدارات حزم تطوير البرامج (SDKs) الخاصة بـ AWS. واجهت مشاكل مع واجهات برمجة التطبيقات S3 الخاصة بـ b2 من مشروع آخر يستخدم حزمة تطوير البرامج (SDK) الخاصة بـ AWS بلغة Golang، في محاولة لعمل نسخة احتياطية من قاعدة بيانات VictoriaMetrics.

هل لديك أي فكرة من فريق الهندسة لديك حول كيفية أو متى قد يختارون حل هذه المشكلة، أو هل لديك أي طريقة لتتبع/الحصول على تحديثات حول حل بديل مدعوم؟ أحاول أن أقرر ما إذا كان يجب عليّ إنشاء نسخة معدلة وإعادة تجميع مشروع بتغيير في الاعتمادية أو مجرد الانتظار لفترة قصيرة لتحديث!

شكرًا!

45

إليك الإجراء الذي نجح معي لإنزال إصدار AWS Gems:

 # للدخول إلى الحاوية:
./launcher enter app
# من الواضح أنه مطلوب لإلغاء تجميد ملف Gemfile.lock:
bundle config set frozen false
# تعيين إصدار أقدم من إضافة gem-s3:
sed -i 's/gem "aws-sdk-s3", require: false/gem "aws-sdk-s3", "1.177.0", require: false/' Gemfile
# إنزال إصدار أقدم من إضافة السمة aws-sdk-s3 ليطابق ما هو موجود الآن في ملف Gemfile:
bundle update aws-sdk-s3
# أيضًا إنزال إصدار أقدم من إضافة aws-sdk-core:
bundle add aws-sdk-core --version 3.215.

بعد إجراء هذه التغييرات، تمكنت من حفظ نسخة احتياطية بنجاح على B2. أنا متأكد أن هذا مجرد حيلة مؤقتة ستفقد مع التحديث القادم لـ Discourse، لذلك أتمنى أن يقدم فريق Backblaze و@PatPatterson إصلاح توافق دائم قريبًا.

إعجابَين (2)
46

نأمل ألا تحتاج إلى القيام بذلك، ولكن من الممكن وضع أمر sed هذا في app.yml بحيث يتم تنفيذه تلقائيًا عند إعادة البناء. أعتقد أن مجرد وضعه أسفل المكان الذي يتم فيه استنساخ المكونات الإضافية سيكون كافيًا. ولكن قد يكون الأمر أكثر تعقيدًا مما أعتقد.

إعجاب واحد (1)
47

مرحباً AntiMetaman،

لقد أمضيت الأسبوع الماضي في محاولة تشغيل النسخ الاحتياطي باستخدام تخزين S3، وأخيراً نجحت في تشغيل النسخ الاحتياطي باستخدام هذا الموضوع. بصراحة، لست متأكداً من الجزء الذي نجح.

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

not entitled /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.219.0/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call’ /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aw

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

48

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

هل من الممكن تقليل إصدار AWS-SDK حتى يمكن العثور على حل مؤقت لمشكلة backblaze ومزودين آخرين غير تابعين لـ AWS؟

49

لكنني فعلت ذلك لموقع يستخدم Backblaze. لقد أنشأت قالبًا وضعته في /root/aws-revert-template.yml مع هذا:

# هذا القالب يعيد إصدار aws-sdk-s3 إلى إصدار يعمل مع backblaze

params:
  home: /var/www/discourse

hooks:
  after_bundle_exec:
    - exec:
        cd: $home
        cmd:
          - bundle config set frozen false
          - "sed -i 's/gem \\\"aws-sdk-s3\\\", require: false/gem \\\"aws-sdk-s3\\\", \\\"1.177.0\\\", require: false/' Gemfile"
          - bundle update aws-sdk-s3
          - bundle add aws-sdk-core --version 3.215

ثم أضفته إلى app.yml الخاص بي هكذا:

# هام: قم بتعيين كلمة مرور سرية في Postgres لمستخدم Discourse
# TODO: قم بتغيير SOME_SECRET في هذا القالب

templates:
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
## قم بإلغاء التعليق على هذين السطرين إذا كنت ترغب في إضافة Lets Encrypt (https)
  - "templates/web.ssl.template.yml"
  - "templates/web.letsencrypt.ssl.template.yml"
  - "/root/aws-revert-template.yml"

وقمت بتشغيل ترقية إلى stable ويبدو أنها تعمل.
يمكنك أيضًا إضافة ما هو موجود في القالب إلى app.yml الخاص بك.

3 إعجابات
50

لوحظ أن هذه الصفحة - S3-Compatible API - لم تعد تسرد رؤوس checksum-* المختلفة على أنها غير مدعومة.

@PatPatterson لست متأكدًا مما إذا كنت لا تزال في هذا الموضوع أم لا - ولكن هل تمت إضافة دعم رسمي لتلك؟

إعجابَين (2)
51

هل يمكنك تأكيد أن خدمة Backblaze B2 لديك تعمل بدون الإصلاح الذي أقترحه؟

52

شكرًا على الرد السريع، وأعتذر - كان ينبغي أن أضيف المزيد من التفاصيل. في حزمة مفتوحة المصدر أخرى (Mastodon) انتهى بنا الأمر أيضًا بتثبيت جوهرة aws-sdk-core لتكون < 3.216.0 لمعالجة هذه المشكلة بالضبط للأشخاص الذين يستخدمون Backblaze (وأشك في آخرين، ولكن هذا هو المكان الذي ظهرت فيه).

ولكن في الأسابيع القليلة الماضية لاحظت:

  • لم تعد تلك الصفحة على موقع Backblaze تسرد تلك الرؤوس على أنها غير مدعومة
  • ذكر إصدار حديث لجوهرة AWS إصلاح المشكلة حيث لم يتم الالتزام بـ when_required بالكامل سابقًا

في الأبحاث السابقة، رأيت هذا الموضوع مع نفس المشكلة تقريبًا وحاولت فهم ما إذا كان يمكننا تحديث الجوهرة بأمان الآن إذا أضاف Backblaze هذا الدعم بالفعل، و/أو إذا كانت الجوهرة تعمل الآن بشكل كامل حول المشكلة.

إعجابَين (2)
53

مرحباً - نعم، أضاف Backblaze B2 دعمًا رسميًا لرؤوس المجموع الاختباري في وقت سابق من هذا العام.

إعجابَين (2)
54

ممتاز! شكراً للتأكيد.