@Falco - قد يكون من الجيد إضافة تحذير لـ Scaleway، بأنها تدعم 1000 جزء فقط للتحميل متعدد الأجزاء، بينما تدعم AWS 10,000. هذه ليست مشكلة للتحميلات العادية، ولكنها مشكلة لتحميلات النسخ الاحتياطي التي تتجاوز حجمًا معينًا حيث سيستخدم S3 SDK 10,000 جزء ما لم يتم تعديله يدويًا وسيفشل.
4 إعجابات
اكتشاف رائع! يرجى إضافته إلى ويكي OP إذا استطعت.
4 إعجابات
شكراً لك، أود أيضاً أن أضيف أنه يمكنك استخدام أي من هذه الأدوات للنسخ من سحابة إلى أخرى، وخاصة من وإلى التخزين الكائني المتوافق مع S3، على سبيل المثال، Rclone و Shargate و Gs Richcopy360 و GoodSync. كل هذه متوافقة مع السحب المماثلة.
إعجاب واحد (1)
لقد اكتشفنا مشكلة للتو، لا تسمح Cloudflare R2 بالقراءة العامة من عنوان URL لنقطة نهاية S3، بل فقط النطاق المخصص أو نطاق r2.dev عشوائي.
(التنزيلات الموقعة مسبقًا تعمل، فقط لا يوجد وصول عام مباشر مدعوم.)
لكن discourse يستخدم عنوان URL لشبكة توصيل المحتوى (CDN) فقط للصور المضمنة، وليس للتنزيلات المباشرة، التي تستخدم عنوان URL لنقطة نهاية S3.
هل هناك طريقة لجعله يستخدم عنوان URL لشبكة توصيل المحتوى (CDN) لجميع الملفات، أو فرض استخدام عنوان URL موقع مسبقًا؟
ذات صلة:
الحل البديل المذكور في هذا المنشور يعمل، إضافة ?dl=1 يصلح الأمر، لأنه يجبر discourse على استخدام عنوان URL موقع مسبقًا لـ S3.
إعجاب واحد (1)
Fixed in 2023-03-16 now R2 working with Discourse like charm with free plan
3 إعجابات
أرى هذا أيضًا مع بعض التردد (كل بضعة أشهر) على الرغم من أن Discourse الخاص بي يعمل في AWS Lightsail وأقوم بالتحميل إلى AWS S3. لذلك لست متأكدًا من أن خطأ wasabi هو السبب.
هل سيكون من الممكن اكتشاف هذا الخطأ وتنبيه المسؤول؟ أنا أتحقق من مساحة القرص وأزيل النسخ الاحتياطية القديمة عند الترقية ولكن في بعض الأحيان يكون ذلك متأخرًا جدًا ويتعطل المنتدى بسبب عدم وجود مساحة قرص.
إعجاب واحد (1)
أنا متأكد تمامًا من أن المشكلة كانت تحدث بسبب إعادة تشغيل نظام التشغيل التلقائية للتحديثات الأمنية أثناء تشغيل النسخ الاحتياطي. تأكد من جدولة عمليات إعادة تشغيل نظام التشغيل والنسخ الاحتياطي في أوقات مختلفة. كان ذلك بعد أن نقلت هذا الموقع من wasabi عندما توصلت إلى هذا التفسير، لكنني متأكد تمامًا من أن هذا هو السبب.
إعجابَين (2)
uptime يقول إنه يعمل منذ 300 يومًا، لذلك لا أعتقد أن هذه هي المشكلة. ولكن على نفس المنوال، كان لدي نسخ احتياطية من Discourse مجدولة في الساعة 2:00 صباحًا ولقطات Lightsail في الساعة 2:30 صباحًا، لذلك ربما لم يكتمل التحميل في بعض الأحيان وتتسبب اللقطة في حدوث مشكلة. لقد فصلت العمليتين بساعة - سنرى ما إذا كان ذلك سيحدث فرقًا.
بغض النظر، أعتقد أنه من المعقول تحذير المسؤولين إذا فشل التحميل، لأي سبب كان.
إعجابَين (2)
أعتقد أن الوقت قد حان لإجراء ترقيات للنواة وإعادة التشغيل. 
هل يمكن أن تكون ذاكرة الوصول العشوائي لديك تنفد؟
بعد تطبيق النسخ الاحتياطي عن بُعد لـ Backblaze، أرى هذا الخطأ في لوحة التحكم الخاصة بي:
تم تكوين الخادم لتحميل الملفات إلى S3، ولكن لم يتم تكوين S3 CDN. يمكن أن يؤدي هذا إلى تكاليف S3 باهظة وأداء أبطأ للموقع. راجع “استخدام تخزين الكائنات للتحميلات” لمعرفة المزيد.
لم أقم بتكوين تحميل الملفات، بل قمت فقط بتكوين النسخ الاحتياطي عبر هذا الإعداد:
DISCOURSE_S3_REGION: "s3.us-west-00X"
DISCOURSE_S3_INSTALL_CORS_RULE: false
DISCOURSE_S3_ENDPOINT: https://s3.us-west-00X.backblazeb2.com
DISCOURSE_S3_ACCESS_KEY_ID: mykeyid
DISCOURSE_S3_SECRET_ACCESS_KEY: myaccesskey
DISCOURSE_S3_BUCKET: community-forum
DISCOURSE_S3_BACKUP_BUCKET: community-forum/backups
DISCOURSE_BACKUP_LOCATION: s3
هل فعلت شيئًا خاطئًا؟
يبدو أن هناك خطأ في التكوين، لاحظت عند محاولة تحميل ملف إلى منشور، تلقيت هذا الخطأ:
قيمة غير مدعومة لـ canned acl ‘public-read’
سأكون ممتنًا لأي مساعدة.
إعجابَين (2)
قم بإزالة هذا إذا كنت لا تريد تحميل الملفات إلى S3.
4 إعجابات
لقد أنقذت الموقف يا أخي. 
شكراً جزيلاً!
إعجابَين (2)
هل نجح ذلك؟
إعجاب واحد (1)
لقد حدث ذلك مرة واحدة في الشهر الماضي منذ أن فصلت العمليتين بساعة ، لذلك لم “يصلحه” ، ولا يحدث كثيرًا لأقول ما إذا كان قد ساعد.
على الجانب المشرق ، لاحظت وجود قسم لحالة النسخ الاحتياطي في صفحة المسؤول يعرض مساحة القرص المتاحة ، مما يوفر عليّ فتح طرفية باستمرار وإجراء أمر df فقط للتحقق من النسخ الاحتياطي العالقة. قمت بتخصيص النص لتذكير نفسي بأنني أتوقع حوالي 80 جيجابايت مجانًا.
إعجاب واحد (1)
هذه فكرة جيدة.
لقد رأيت الصورة قبل أن أقرأ أنك قمت بتخصيص النص وتساءلت عن المنطق الذي كان يلعب دورًا لتحديد أن هذا كان “جيدًا”!
إعجاب واحد (1)
لم أتمكن من تشغيل هذا مع Scaleway باستخدام صورة Bitnami Discourse.\nتم تعيين متغيرات البيئة ولكن من الواضح أنه لم يتم قراءتها/تطبيقها بشكل صحيح (أو على الإطلاق؟).\n\nلذلك قمت بتعيين متغيرات S3 في لوحة الإدارة وتعيين المنطقة مباشرة في وحدة تحكم rails (لا يزال الأمل في أن يصبح هذا مجرد حقل نصي):\nSiteSetting.s3_region=\"fr-par\"\n\nلقد أعطاني خطأ في التحقق، لكنني علقت فحص التحقق قبل تحديث الإعداد، ثم أعدته مرة أخرى.
إعجاب واحد (1)
صورة Bitnami ليست مُعبأة من قِبلنا ولا تتبع توصياتنا. كل ما هو موثق هنا تم اختباره فقط مقابل التثبيت الرسمي.
4 إعجابات
تم حل هذه المشكلة عن طريق تمكين “s3 use cdn url for all uploads”، وهو خيار أضافه discourse مؤخرًا.
نظرًا لأننا كنا نستخدم R2 من قبل، احتجنا إلى استخدام discourse remap لاستبدال الروابط المعطلة يدويًا، وقمنا بمزامنة ملفات s3 للتأكد، ثم أعدنا خبز جميع المنشورات.
إعجاب واحد (1)
أحاول إعداد هذا مع idrive e2، وهو متوافق مع s3. ومع ذلك، أحصل على خطأ/تتبع مكدس غير مفيد للغاية في نهاية ./launcher rebuild app:
I, [2023-10-14T15:08:08.026184 #1] INFO -- : cd /var/www/discourse & sudo -E -u discourse bundle exec rake s3:upload_assets
rake aborted!
Aws::S3::Errors::InternalError: We encountered an internal error, please try again.
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/dualstack.rb:27:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/accelerate.rb:56:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/checksum_algorithm.rb:111:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:22:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/idempotency_token.rb:19:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/param_converter.rb:26:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/request_callback.rb:71:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/response_paging.rb:12:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/response_target.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/request.rb:72:in `send_request'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/client.rb:12369:in `put_object'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/object.rb:1472:in `put'
/var/www/discourse/lib/s3_helper.rb:78:in `upload'
/var/www/discourse/lib/tasks/s3.rake:41:in `block in upload'
/var/www/discourse/lib/tasks/s3.rake:41:in `open'
/var/www/discourse/lib/tasks/s3.rake:41:in `upload'
/var/www/discourse/lib/tasks/s3.rake:197:in `block (2 levels) in <main>'
/var/www/discourse/lib/tasks/s3.rake:197:in `each'
/var/www/discourse/lib/tasks/s3.rake:197:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => s3:upload_assets
(See full trace by running task with --trace)
I, [2023-10-14T15:08:16.413098 #1] INFO -- : Installing CORS rules...
skipping
Uploading: assets/admin-2ebebf57104b0beb47a1c82fe5a8c6decd07f60a706640345fed296a094d1536.js
هذا هو الإعداد الذي كنت أستخدمه، ولكني جربته أيضًا مع DISCOURSE_S3_CONFIGURE_TOMBSTONE_POLICY و DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: Dallas
DISCOURSE_S3_ENDPOINT: https://y0o9.tx21.idrivee2-4.com
DISCOURSE_S3_ACCESS_KEY_ID: <snip>
DISCOURSE_S3_SECRET_ACCESS_KEY: <snip>
DISCOURSE_S3_BUCKET: discourse
DISCOURSE_S3_INSTALL_CORS_RULE: false
لاحظ أنني لا أستخدمه للنسخ الاحتياطي (تم إعداده بالفعل في واجهة المستخدم مع backblaze) ولا لـ DISCOURSE_CDN_URL لأنني لست متأكدًا مما إذا كان idrive يدعم ذلك - كنت أخطط للتجربة مع ذلك بمجرد حصولي على بعض الملفات الفعلية في الحاوية.
إعجاب واحد (1)
يبدو أنه غير متوافق بما فيه الكفاية مع S3 لاحتياجات Discourse.
إذا كنت ترغب في التعمق أكثر، فإن الخطوة التالية ستكون تكرار ذلك في تثبيت تطوير والحصول على استدعاء API الدقيق الذي يفشل.
إعجابَين (2)