مرحباً،
لقد قمت للتو بتثبيت Discourse و Cloudflared على جهاز R-Pi 4 الخاص بي، ولقد اتبعت التعليمات الموجودة في المنشور الأصلي، ولكني لست متأكداً مما يجب وضعه كمضيف لـ Discourse، هل يجب أن أضع localhost فقط بما أن نفق cloudflared سيقوم بإعادة توجيهه؟
ربما يمكن لـ @Falco المساعدة؟
بالمناسبة، آسف على رفع الموضوع.
لا يزال يتعين عليك امتلاك نطاق لهذا الدليل، لذا ستكون قيمة المضيف إما قمة النطاق أو النطاق الفرعي الذي قمت بتكوينه لـ Discourse وللأنفاق.
إذًا، يجب أن تكون قيمة المضيف هي النطاق الفرعي الذي أريده لـ Discourse فيه؟
نعم، يجب أن يكون عنوان URL حيث تريد أن يكون Discourse.
هل أنت متأكد؟
إذا فعلت ذلك، فسيظهر لي هذا الخطأ:
لقد قمت بتعيين اسم مضيف Discourse إلى النطاق الفرعي الدقيق الذي أريد أن يكون Discourse عليه.
لقد قمت بتثبيت Cloudflared على R-Pi4 من سطر الأوامر (كما هو مكتوب هنا: Set up your first tunnel · Cloudflare One docs) وأقوم بتشغيله كخدمة.
وقمت بتثبيت Discourse كما هو مذكور في مشاركتك الأصلية، أنا متأكد جدًا.
هل يمكنك مشاركة النطاق؟
هل يمكنني إرسالها لك عبر الرسائل الخاصة؟ لا أريد حقًا أن يراها أشخاص عشوائيون.
هل يعمل الآن بعد أن قمت بوضع النطاق الصحيح؟
نعم! لقد قمت بتشغيله للتو! شكراً لمساعدتك! لدي مشكلة فقط مع MailJet (مزود البريد الإلكتروني الذي أستخدمه لـ STMP)، والذي يستمتع بحظر رسائل البريد الإلكتروني الخاصة بالتحقق الخاصة بي مسبقًا..
تم دمج منشور في موضوع موجود: أي بدائل لـ MailJet؟
مرحباً، لقد تمكنت من تثبيت يعمل! لدي سؤال صغير، ما مقدار النشاط/الأعضاء الذي تعتقد أن جهاز R-Pi 4 Model B بذاكرة وصول عشوائي (RAM) بسعة 4 جيجابايت يمكنه التعامل معه؟
هذا سؤال رائع. نظرًا لصعوبة إجراء ارتباط مباشر بين عدد المستخدمين وحمل الخادم في نظام معقد مثل Discourse، فمن العدل الاعتراف بأن عنق الزجاجة الرئيسي في نظام RaspberryPi هو عمليات الإدخال/الإخراج للتخزين (storage IOPS).
لذلك، طالما أن معظم الموارد التي تحتاجها موجودة في ذاكرة الوصول العشوائي (RAM)، بين عمليات RSS والتخزين المؤقت لنظام Linux، يجب أن تحصل على تجربة سلسة. حقيقة أن Cloudflare تعمل كشبكة توصيل محتوى (CDN) للتخزين المؤقت ستساعد أيضًا بشكل كبير، ويمكنك حتى تمديد العمر الافتراضي لإعداد Pi باستخدام استخدام التخزين للكائنات للملفات المحملة (S3 والنسخ المتماثلة) بعد فترة.
لقد واجهت هذا الخطأ في أجزاء من Docker
FAILED
--------------------
Pups::ExecError: /usr/local/bin/ruby -e 'if ENV["DISCOURSE_HOSTNAME"] == "discourse.example.com"; puts "Aborting! Domain is not configured!"; exit 1; end' failed with return #<Process::Status: pid 115 exit 1>
Location of failure: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params "/usr/local/bin/ruby -e 'if ENV[\"DISCOURSE_HOSTNAME\"] == \"discourse.example.com\"; puts \"Aborting! Domain is not configured!\"; exit 1; end'"
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
9ba0db264ae559f3f748cc1e42a8683ea0b4e355b0d45da0f472afea7ff7c472
هذا يعني أنك لم تقم بتكوين نطاقك بشكل صحيح. أنت بحاجة إلى نطاق صالح لكي يعمل هذا. قم بتشغيل ./discourse-setup مرة أخرى أو قم بتحرير ملف app.yml لإصلاحه.
شكرا على الرد
لقد نجحت في نشره على RockPi4 
مرحباً @Falco،
أنا متأكد من أنني قمت بإعداده تمامًا مثل دليلك، ولكني ألاحظ شيئًا غريبًا.
في إعداد الحاوية، لا أقوم بتحميل قوالب SSL، ولدي متغير البيئة DISCOURSE_FORCE_HTTPS مضبوطًا على true. لست متأكدًا مما يفعله ذلك، ولكني أفترض أنه يضبط SiteSetting.force_https على true ثم يخفيه في لوحة تحكم المسؤول لمنع تعطيله.
إعداد نفق CF الخاص بي يبدو كالتالي:
ingress:
- hostname: dc.example.com
service: http://dc:80 # dc هو اسم حاوية تطبيق Discourse المستقل الخاص بي
المشكلة هي أنني أستطيع زيارة http://dc.example.com، ولا تتم إعادة توجيهي إلى https. هل هذا هو السلوك المتوقع؟
هل يمكنك إعادة إنتاج هذا؟ أتساءل عما إذا كانت هذه مشكلة.
إعداداتي ذات الصلة في CF هي:
أعلم أنه يمكنني جعل CF يقوم بإعادة التوجيه (إما باستخدام Always Use HTTPS أو قاعدة إعادة توجيه جماعية)، ولكني كنت سأفترض أن Discourse سيتعامل مع ذلك ويعيد توجيه جميع عناوين URI الداخلية إذا كان force_https مضبوطًا على true. ما رأيك؟
بغض النظر عن مشكلة إعادة التوجيه، فإن تصفح https://dc.example.com يعمل بشكل جيد بغض النظر عن قيمة DISCOURSE_FORCE_HTTPS أو SiteSetting.force_https.
تعديل: على الرغم من عدم فهمي لما يفعله force_https بالضبط (ربما لا يفعل شيئًا إذا لم يتم تضمين قوالب SSL؟)، فقد خطر ببالي للتو أن إعداد النفق ربما لن يعمل كما هو إذا كان Discourse يعيد توجيه كل شيء باستخدام HTTPS. إذا فعل ذلك، فلن يتمكن Argotunnel من الوصول إلى Discourse باستخدام HTTP (مثل service: http://dc:80)، لذا ربما يجب علي:
service: https://dc:443)على أي حال، ربما يمكن تحديث دليل Argotunnel الخاص بك ليشمل هذا؟
أنت على حق. لم ألاحظ ذلك، نطاقي التجريبي .dev يتطلب HTTPS فقط:
لقد قمت بتحديث الدليل لإخبار الأشخاص باستخدام قاعدة صفحة لهذا الغرض، شكرًا على التقرير!
ولكن لدي سؤال..
أرى عددًا كبيرًا من المشاهدات المجهولة في Consolidated Pageviews، أعتقد أن ذلك بسبب هجمات DDoS لأن وحدة المعالجة المركزية للخادم وصلت إلى 60٪ والزاحف قليل جدًا.. ولكن ماذا عن الحماية من هجمات DDoS.. شكرًا مقدمًا على الإجابة.
إذا كنت تستخدم Cloudflare كخادم وكيل عكسي (شيء منفصل عن cloudflared/argotunnel)، فيجب أن تحصل على بعض الحماية من هجمات DDoS بشكل افتراضي. قم بتمكينها باستخدام “السحابة البرتقالية” على سجل (سجلات) DNS الخاص بك.