مرحباً،
يبدو أن هذا سؤال مكرر، وأعتذر مقدماً إذا كان كذلك: يبدو أنني لم أبحث جيداً 
كيف يمكنني كتابة سكريبت يقوم بنفس عمل المعالج بدلاً من ذلك عبر واجهة الويب؟
سيبدأ بشيء يشبه تثبيت Fabricate (المسؤول) من اختبارات المواصفات. وربما يتم استدعاؤه من القسم المخصص للحاوية.
شكراً مقدماً على مساعدتكم!
يجمع Wizard بين إعدادات الموقع وطلبات واجهة برمجة التطبيقات (API) بنصف ونصف.
بالنسبة لطلبات واجهة برمجة التطبيقات، يمكنك قراءة كيفية هندسة واجهة برمجة تطبيقات Discourse عكسيًا، وبالنسبة لإعدادات الموقع، اتبع المثال هنا:
لكن… ربما يكون هذا هو المكان الذي أتيه فيه: لكي أستدعي واجهة برمجة التطبيقات (API)، أحتاج إلى مفتاح واجهة برمجة التطبيقات. وبالتالي إلى مستخدم مسؤول… وهو ما لا أملكه (بعد). هل من الممكن استدعاء واجهة برمجة التطبيقات دون مفتاح؟ أم الحصول على مفتاح غير مرتبط بمستخدم ويتمتع ببيانات اعتماد المسؤول؟
يبدو أنه يجب علي استخدام rake:admin لإنشاء مستخدم المسؤول. بل أعتقد أن مستخدم المسؤول قد تم إنشاؤه بالفعل ولكنه غير معتمد، لذا سأحتاج إلى تغييره ليصبح معتمدًا.
أو ربما يمكنني إنشاء مفتاح API باستخدام api_key:create_master واستخدامه لإنشاء مستخدم المسؤول؟
root@forum:/var/www/discourse# RAILS_DB=secondsite rake 'api_key:create_master[MASTERKEY]'
ad676e7413778aaaaa5d315c35f188591ef0edb4a4d4b2d644b9247a88421cfa
لكن يبدو أنني لا أفهم تمامًا كيفية استخدام هذا المفتاح الرئيسي لأن هذا لا يعمل:
# curl -X GET "https://forum2/categories" -H "Accept: application/json" -H "Api-Key: ad676e7413778aa3a5d315c35f91ef0edb4a4d4b2d644b924b7a88421cfa"
{"errors":["You are not permitted to view the requested resource. The API username or key is invalid."],"error_type":"invalid_access"}
ومع ذلك، إذا قمت بإنشاء مستخدم مسؤول:
root@forum:/var/www/discourse# RAILS_DB=secondsite rake 'admin:create'
Email: loic@dachary.org
Password:
Repeat password:
Ensuring account is active!
Account created successfully with username loic
Do you want to grant Admin privileges to this account? (Y/n) Y
Your account now has Admin privileges!
ثم استخدمت نفس المفتاح الرئيسي مع تحديد المستخدم الذي تم إنشاؤه حديثًا، فقد عمل الأمر:
curl -X GET "https://forum2/categories" -H "Accept: application/json" -H "Api-Key: ad676e7413778aa3a5d315c358591ef0edb4a4d4b2d644b924b7a88421cfa" -H "Api-Username: loic"
{"category_list":{"can...
ويتمتع بصلاحيات المسؤول لأنه يمكنه أيضًا الوصول إلى /admin/site_settings/category/branding
ما الذي تحاول تحقيقه بالضبط؟ هل تريد أتمتة إنشاء مستخدم مسؤول وتعيين بعض الإعدادات؟
نعم، تمامًا. أود إنشاء منتدى جديد من الصفر وتعبئته بالمستخدمين والفئات والمواضيع عبر سكريبت لا يتطلب أي تفاعل مع المتصفح.
ربما فقط قم بإنشاء قاعدة البيانات هذه أولاً واستعد جزءًا منها كجزء من عملية التثبيت؟
لا أملك قاعدة بيانات: سيتم إنشاء المستخدمين والفئات والمواضيع باستخدام البيانات من Mailman2.
إذا كنت ترغب في استيراد البيانات، فافعل ذلك كعملية منفصلة.
إذا كان ذلك حدثًا لمرة واحدة، لكان ذلك مقبولاً. لكنني أريد أن أتمكن من اختبار سكريبت الاستيراد. ولتنفيذ الاختبار، يجب أولاً إنشاء نظام Discourse من الصفر. دون الحاجة إلى أي تدخل يدوي في منتصف الاختبار الآلي 
للتوضيح، هذا جزء من العمل الذي أقوم به لاستيراد mailman2 إلى discourse. سيتم تشغيل الاختبار من خلال tox الذي سيقوم بـ:
في حالة تثبيت متعدد المواقع، يمكن إنشاء مستخدم مدير معتمد ومفتاح واجهة برمجة تطبيقات (API) للمدير باستخدام الأوامر التالية:
docker exec app env RAILS_DB=secondsite rake 'api_key:create_master[MYKEY]'( echo user1@example.com ; echo $pass ; echo $pass ; echo ) | docker exec -i app env RAILS_DB=secondsite rake 'admin:create'ملاحظة: إذا لم تكن في تثبيت متعدد المواقع، فقم ببساطة بحذف env RAILS_DB=secondsite.
ثم تحقق من أن الأمر يعمل باستخدام:
curl -X GET https://forum2/admin/backups -H "Accept: application/json" -H "Api-Key: 886171a73dd12759b5d6c1915b0f0d4475e8b3fff3d97954b95171200b6" -H "Api-Username: user1"
[]
(شكر خاص لـ Jay Pfaffman على الإلهام)
بعد الانتهاء من ذلك، لم يعد discourse يتطلب تشغيل المعالج التوجيهي (Wizard)، على الرغم من أنه يظهر أنه يجب تشغيله.
أعتمد بشكل كبير في معيشتي على الاستيراد. وأنا متأكد إلى حد كبير أن ما سأصفه أدناه هو الطريقة التي يتبعها تقريبًا كل من يعمل بالاستيراد بانتظام.
ما أنصح به هو:
تختلف مهمة الهجرة تمامًا عن مهمة إعداد خادم الإنتاج، ولهما متطلبات مختلفة. عادةً ما تتطلب مهمة الهجرة أدوات لا يحتاجها خادم الإنتاج (لكنني أعتقد أن أداة استيراد Mailmain استثناء).
يبدو أن تشغيل عملية هجرة على خادم متعدد المواقع أمر غير حكيم بشكل خاص.
شكرًا لك على النصيحة، سأتبع هذه العملية. هناك أكثر من 100 جيجابايت من أرشيفات mbox، وسيحتاج الأمر إلى بضع اختبارات على الأقل.
بخصوص ذلك… يبدو أن مستورد mbox ينشئ دائمًا فئة جديدة ولا يستطيع استخدام فئة موجودة. هل لديك أي معلومات حول هذا؟
لم أكن أعرف معنى foolhardy: أعجبني وسأستخدمه مجددًا 
هذا سبب إضافي يجعل إعادة تشغيل الاستيراد من البداية فكرة سيئة. فمن المرجح أن يستغرق الأمر أسابيع. عند إعادة تشغيل أداة الاستيراد، فإنها تستورد فقط البيانات الجديدة (وغالبًا ما أقوم بتعديلها لتتخطى البيانات القديمة تمامًا).
يمكنك على الأرجح تعديل السكربت لاستخدام فئة موجودة عن طريق إنشاء حقل مخصص للفئة (CategoryCustomField). أنصحك بالبدء بقاعدة بيانات فارغة والسماح للسكربت بإنشائها، ثم يمكنك تخصيصها كما تشاء. وعند إعادة تشغيل السكربت، سيستمر في استخدامها.
الخطر الحقيقي في استيرادك هو أنه من المرجح أن توجد اختلافات في البيانات عبر السنوات، لذا فإن ما يعمل مع بيانات عمرها 10 سنوات قد لا يعمل مع بيانات عمرها 5 سنوات وهكذا. لكن ربما تحالف معك الحظ.
لا أدري ما إذا كان ذلك يُعتبر مديحًا
أنا دائمًا أستخدم النظام متعدد المواقع للاستيراد. فهو يسمح بوجود منتديات متعددة جنبًا إلى جنب: واحد أقوم بتعديلاته بينما يمكن للعميل مراجعة عملية الاستيراد في المنتدى المجاور. كما أنه من السهل نسخ قاعدة البيانات للبدء من نقطة معينة مرة أخرى.
انتظر… ماذا!؟
حسنًا، لقد صدمتني تمامًا! أنت تقريبًا الشخص الوحيد على كوكب الأرض الذي لا يعمل لدى CDCK والذي أعتقد أنه يعرف أكثر عني حول الاستيرادات، وإذا كنت تستخدم النظام متعدد المواقع للاستيرادات، حسنًا، سأفكر في فعل الشيء نفسه. أنا عادةً أطلق حاويات منفصلة على نفس المضيف مع traefik في المقدمة، لذا أعتقد أن الأمر مشابه إلى حد ما، لكن ليس تمامًا.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
