I, [2022-09-01T00:37:48.192311 #1] INFO -- : cd /var/www/discourse & sudo -E -u discourse bundle exec rake s3:upload_assets
rake aborted!
Aws::S3::Errors::BadRequest: An error occurred when parsing the HTTP request PUT at '/'
جميع النطاقات لديها بيانات اعتماد مناسبة وتحاول الاتصال بالحساب باستخدام Cyberduck باستخدام s3.example.com أو bucket.s3.example.com متاح لتحميل وتنزيل الملفات.
لقد بحثت عن المشكلات ذات الصلة ولم أتمكن من حلها، فهي تعمل بشكل جيد عند استخدام خدمة التخزين السحابي من vultr. لذا، هل هناك مشكلة في توافق minio و discourse، ولكني رأيت أشخاصًا يستخدمون minio بنجاح. أطلب من الجميع، أعتقد أن هذه المشكلة سيتم حلها قريبًا.
لم يتم حل المشكلة، ما يزعجني هو أن الاتصال بحساب minio باستخدام بروتوكول نقل amazon s3 الخاص بـ Cyberduck متاح وأعتقد أن إعدادات minio الخاصة بي تبدو جيدة
هل أكدت أن إعدادات MinIO لديك تعمل بشكل عام مع آليات أخرى مثل عميل MinIO أو؟ وأنك تستخدم عناوين URL والإعدادات الصحيحة مقابل MinIO؟
اقتراحي هو التأكد من أن كل شيء متوافق مع عملاء سطر الأوامر MinIO و s3cmd أولاً - لم أسمع أبدًا عن عميل “Cyberduck” هذا (لسبب وجيه: إنه لنظامي التشغيل Windows و Mac، وأنا من مستخدمي Linux)، ولا يمكنني التأكد من أنه متوافق مع MinIO وأشياء أخرى لأنه يقول “AWS S3” على واجهته ومن المحتمل أنه مصمم لواجهة برمجة تطبيقات S3 الكاملة في Amazon، وليس العناصر المتوافقة مع S3. قم بإعداد عميل minio (mcli) على سطر الأوامر في أو بالقرب من الصندوق الذي تحاول العمل معه ثم حاول دفع ملف يدويًا إلى حاوياتك.
بالإضافة إلى ذلك، ضع في اعتبارك أن DISCOURSE_S3_BACKUP_BUCKET مع MinIO مصمم ليكون حاوية خاصة به، وليس مسارًا فرعيًا داخل حاوية موجودة (على حد علمي). من الممكن أن يؤدي ذلك إلى تعطل الأشياء في الإعداد الحالي أيضًا، ولهذا السبب المثال الذي كتبته والرابط إلى “كيفية” الذي قدمته يحتوي على حاوية منفصلة.
ما لا أملكه هنا هو معلومات حول الطلب المحدد الذي تم تقديمه بالفعل - مسار عنوان URL، وما إلى ذلك، الذي استخدمه النظام عند إجراء هذا الاستعلام مع BadRequest. يبدو أن هذا لأنه مجرد تسجيل بمستوى INFO. لا توجد طريقة للحصول على مستوى تصحيح الأخطاء للتسجيل أثناء عملية rake، أليس كذلك @pfaffman (أو الآخرين الأكثر دراية بجانب Discourse)؟
أيضًا، تأكد من تمرير DISCOURSE_S3_INSTALL_CORS_RULE: false لتكوين Discourse الخاص بك - إذا حاول مُعيد بناء/مُخبز التطبيق دفع قواعد CORS، فسيؤدي ذلك إلى ظهور رسالة خطأ.
أرى الملف المرسل في الدلو، هل هذا يعني أنني قمت بتثبيت minio بالخطوات الصحيحة، لقد قمت بتثبيت minio باستخدام docker compose وملف docker-compose.yml الخاص بي
إعادة توجيه أي منافذ؟ 80/443 حتى يعمل http/https؟ هذا كل ما يحتاجه، يجب ألا تحتاج أبدًا إلى تكوين المنفذ 9000 على منفذ منفصل. سيكون للمجلد المنفصل نفس نقطة النهاية مثل s3.example.com - إنه ليس شيئًا منفصلاً، لذا فأنت تقوم بتكوين ذلك بشكل خاطئ. لا تنس أيضًا أنه في مصطلحات MinIO، إذا كنت تستخدم مصادقة المسار، فستنتهي بـ s3.example.com/BUCKETNAME أو مع مصادقة DNS كما يجب أن تستخدم BUCKET.s3.example.com لنقاط نهاية URL التي تحتاج إلى قبولها على جانب nginx وإعادة توجيهها إلى المنفذ الداخلي 9000. لا تحتاج إلى تكوين ذلك من جانبك، بل يجب تكوينه من جانب MinIO.
يدعم عميل MinIO كلاً من إعدادات نمط path و dns. على حد علمي، يستخدم Discourse آلية قائمة على URL لتحديد المجلد، وليس إعدادات نمط المسار (لا تتردد في تصحيحي يا مطوري Discourse). لذلك، فإن السلوك “الافتراضي” الذي تقوم بتكوينه غير صحيح.
الآن، MinIO الخاص بي ليس dockerized، ولكن للامتثال هنا مع Discourse، تحتاج إلى استخدام مسارات نمط DNS، أي أنك بحاجة إلى إضافة متغير البيئة MINIO_DOMAIN=BASEDOMAINHERE حتى يعمل مسار نمط DNS الذي يريده Discourse. في مثالك سيكون MINIO_DOMAIN=s3.example.com ثم تحتاج إلى تكوين NGINX الخاص بك لتمرير رأس المضيف إلى الواجهة الخلفية على المنفذ 9000 أو أينما تعمل مكونات الخادم الأساسية غير المستندة إلى وحدة التحكم. ثم تحتاج إلى التأكد من أن NGINX يقبل *.s3.example.com ويعيد توجيهه بشكل صحيح إلى حاوية MinIO. هذا جزء من إعداد MinIO Federation، ولكن بالنسبة للحالات ذات العقدة الواحدة مع أسماء مجلدات متعددة على عنوان URL أساسي، تحتاج إلى التأكد من تكوينه بشكل صحيح على أي حال إذا كنت تريد أن يعمل مع Discourse.
للأسف، هنا عليك البدء في التعمق في تكوينات MinIO. وأحد المتطلبات التي أحددها في المستند هو أن لديك مثيل MinIO يعمل بالكامل ومُكوَّن بشكل صحيح وهو أبعد من نطاق موقع Discourse. أعتقد أن MinIO الخاص بك غير مُكوَّن بشكل صحيح لحل المجلد بنمط DNS كما يفعل AWS S3 (bucket.s3.example.com على سبيل المثال) وبالتالي لا يعمل.
لاحظ أنني أقوم بتشغيل مثيل Discourse لمشروع Lubuntu (lubuntu.me) (وهو نوع من Ubuntu يستخدم LXQt) باستخدام MinIO مع حل عناوين URL للمجلد بنمط DNS لجعله يعمل بشكل صحيح مع Discourse، وإلا فإن طلبًا لـ BUCKET.basedomain.example.com سيفشل.
حقيقة ممتعة، أذكر حتى أنك بحاجة إلى تكوين MinIO الخاص بك بشكل صحيح لمسارات نمط DNS، إذا لم تقم بتضمين MINIO_DOMAIN أثناء إعداد MinIO فلن يقوم بمسارات نمط DNS. وهو ما يحتاجه هنا لـ Discourse، وفقًا للبند 3 في قسم التحذيرات الذي كتبته:
مرحباً يا صديقي، إعداد MINIO_DOMAIN يزيل الأخطاء المذكورة أعلاه، لكن تظهر أخطاء جديدة
Aws::S3::Errors::MalformedXML: لم يكن تنسيق XML الذي قدمته صحيحًا أو لم يتحقق مقابل المخطط المنشور لدينا.
أشعر أنني على وشك النجاح، لأن discourse يمكنه الوصول إلى minio الخاص بي بشكل صحيح، أحاول حذف جميع حاويات minio، وإعادة بناء discourse، سيظهر خطأ بأن الحاوية المحددة غير موجودة
يتم حل المشكلة عن طريق عدم إضافة متغيرات تخزين الكائنات عبر app.yml. وإلا فسيحدث خطأ MalformedXML، فقط أضف المعلمة s3 إلى الإعدادات. يجب إضافة المتغير MINIO_DOMAIN عند تثبيت minio (أنا أستخدم نشر العقدة الواحدة).
شكراً @teward على مساعدتك
الآن يمكنني تحميل الملفات والنسخ الاحتياطي باستخدام minio
لا، لا يدعم MinIO PutObjectAcl. إنه يدعم الأذونات على مستوى الحاوية ولكن ليس قوائم التحكم في الوصول على مستوى الكائن بهذا الشكل من واجهة برمجة التطبيقات.
لا يدعم MinIO واجهة برمجة تطبيقات AWS بالكامل. راجع AIStor Object Store Documentation لمجموعة واجهات برمجة التطبيقات المدعومة بالكامل.
يجب إضافة MINIO_DOMAIN لحدوث الحاويات بأسلوب DNS، وهذا هو سبب حدوث PUT غير الصالح. بمجرد أن نتقدم أكثر، نرى حالات الفشل في XML مقابل ما هو مسموح به في المخططات. تأكد من عدم وضع أي سياسة تحتوي على متغيرات غير مدعومة في المجموعة المدعومة التي يدعمها MinIO بالفعل.
تذكر: متوافق مع S3 لا يعني أنه مطابق بنسبة 100٪ لجميع متغيرات/نقاط نهاية/قيم واجهة برمجة تطبيقات AWS S3 المدعومة.
