انتظر… أعتقد أنني فهمت الأمر… قمت بتعطيل الوكيل وأعدت البناء دون استخدام قالب Cloudflare. ثم فعلت الوكيل مرة أخرى، والآن يمكنني الوصول إلى WordPress والمنتدى مع تفعيل SSL الصارم!
سيتم تقييد معدل الطلبات لديك بسهولة إذا اخترت عدم استخدام قالب Cloudflare…
ستفترض منصة Discourse أن العديد من الأشخاص يسجلون من خلال نفس عنوان IP (وكيل Cloudflare) وتبدأ في تقييد معدل طلباتهم.
همم… إذن من الأفضل إعادة ذلك بدون بريد إلكتروني لـ Let’s Encrypt ولكن باستخدام قالب Cloudflare… هل تعرف ما إذا كان عليّ ترك الوكيل مفعلًا عند إعادة البناء باستخدام قالب Cloudflare؟
شكرًا جزيلاً لك على كل المساعدة… أنا في الواقع أكثر إبداعًا.
إنه مسجّلي، وليس DNS فقط… ولا أستطيع تحمل دفع المبلغ الضخم الذي يطلبونه مني لاستخدام DNS مختلف. لذا، أوبس.
لا يتطلب إعداد Discourse الآن عنوان بريد إلكتروني للتسجيل في الشهادات، ولم يكن كذلك منذ فترة. ما لم تقم بتعديل ملف yml لتعطيل SSL، فسيظل الافتراضي هو HTTPS دائمًا.
استخدام Cloudflare كـ DNS وتفعيل السحابة البرتقالية أمران مختلفان تمامًا. يُقصد بـ Cloudflare في السياق أعلاه وكيلها وتحسيناتها، والتي تسببت في مشاكل غريبة في الماضي. أما خدمة DNS الخاصة بهم فهي جيدة جدًا.
لا يحتاج تثبيت Discourse لديك إلى تغيير، فـ HTTPS يعمل بشكل صحيح وكل شيء هناك على ما يرام. إذا كان SSL يعمل وقالب CloudFlare مفعّلًا، فلا تلمس أي شيء.
يبدو أن المشكلة الآن في WordPress، كيف قمت بتثبيته؟ هل هو مجرد خادم VPS، أم أنك تستخدم استضافة WordPress من نوع ما؟
هذه إعدادات شائعة جدًا، وأنا واثق من أن إصلاحها سهل.
هذه فكرة سيئة جدًا. بمجرد أن يسجّل Discourse الشهادة من Let’s Encrypt، سيتم تجديد الشهادات بنجاح لأنها تحدث عبر آلية مختلفة. لا حاجة لتعطيل TLS بين الخادم وشبكة توصيل المحتوى (CDN).
لماذا تفعل ذلك في ضوء ما سبق؟ بالإضافة إلى زيادة الحمل المحلي لمعالجة قواعد UFW لجميع حركة المرور، فإنك تخاطر بأن تصبح قواعدها قديمة، وهي طريقة سريعة لحدوث مجموعة من أخطاء الشبكة. تقوم Cloudflare بتحديث نطاقات عناوين IP الخاصة بها دوريًا، وأول ما ستعرفه هو عندما لا يتمكن مستخدمو موقعك من الوصول إليه. دع الشهادة تُسجّل، وإذا كنت ترغب في استخدام CloudFlare، فقم فقط بضبط قاعدة صفحة وفقًا لذلك.
أستخدم كلاودفلير في وضع DNS فقط، وهو أمر مباشر. ما عليك سوى النقر وتعطيل “السحابة البرتقالية” في لوحة تحكم DNS الخاصة بك، بحيث تصبح السحابة رمادية بدلاً من ذلك. هذا كل ما تحتاج إلى فعله.
لم يعد هذا يعمل كما كان من قبل. إذا كنت لا تريد استخدام let’s encrypt، فيجب عليك التكوين يدويًا بدلاً من استخدام discourse-setup
إذن، ما نوع الشهادة التي سيحصل عليها discourse في حال عدم وجود بريد إلكتروني من Let’s Encrypt؟ هل ستكون شهادة مولَّدة ذاتيًا أم شهادة صادرة باستخدام بريد إلكتروني عشوائي؟
في كلتا الحالتين، يجب أن يعمل الأمر بشكل صحيح مع SSL الخاص بـ Cloudflare، حيث يسمح Cloudflare للمضيفين الذين لديهم شهادة صالحة في إعدادات SSL الكاملة وما فوق.
ستحتاج إلى التحقق من المصدر، لأنني لا أتذكر تمامًا. أعتقد أنه يستخدم البريد الإلكتروني للمدير. إذا فشل التحقق من توفر الخادم على المنفذ 443، سيرفض التثبيت.
قد أكون مخطئًا تمامًا هنا، لكن بناءً على هذا الكود:
read_config "LETSENCRYPT_ACCOUNT_EMAIL"
local letsencrypt_account_email=$read_config_result
if [ -z $letsencrypt_account_email ]
then
letsencrypt_account_email="me@example.com"
fi
if [ "$letsencrypt_account_email" = "me@example.com" ]
then
local letsencrypt_status="ENTER to skip"
else
local letsencrypt_status="Enter 'OFF' to disable."
fi
يبدو أن فحص الإعدادات الافتراضي يجب أن يتيح خيار إدخال “off” لتعطيل letsencrypt؟ ربما أكون مخطئًا تمامًا وأبحث في المكان الخطأ؟
تعطيل Let’s Encrypt ليس هو الحل.
في التثبيت القياسي، لا يكون كذلك. أما في التثبيت المتقدم (مثل استخدام شخص ما لوكيل عكسي)، فهو بالتأكيد إجابة.
هل يمكنك التوضيح لماذا؟
من السهل جعل سيناريو الشهادة يعمل. حتى لو كنت تشغل خادم ويب ثانٍ على نفس الخادم وتقوم بالوكلة محليًا، فمن السهل جعل الشهادة تعمل، فلماذا لا تفعل ذلك؟
لماذا أطلب شهادات متعددة؟
عندما يمكنني ببساطة طلب شهادة موحدة واحدة من Let’s Encrypt عبر وكيل العكسي (مثل nginx/caddy)، لماذا أريد شهادة ثانية داخل حاوية discourse عندما لن يتم استخدامها من قبل أي شيء؟
أعتقد أن الإجابة العامة هي تجنب تعقيدات الوكيل تمامًا، إذا كان ذلك ممكنًا 
لكن هذا أمر لا مفر منه بمجرد البدء في النظر في عملية نشر تتجاوز الإعداد القياسي المكون من حاوية واحدة أو اثنتين.
يجب أن يصبح منتداك كبيرًا جدًا حقًا لتحتاج إلى شيء مثل وكيل Cloudflare. إنه أمر يجب مراعاته عندما يبدأ منتداك في الشعور بالضغط. ما لم تكن تقوم بنقل منتدى كبير إلى Discourse، فلا ينبغي لأي شخص يقوم بتثبيت Discourse أن يفكر في ذلك.
أنا لا أتفق معك تمامًا، فالتعامل الصحيح مع HTTPS أمر بسيط. في هذه الحالة، يمتلك المستخدم موقعين على خادمين مختلفين تحت نطاق واحد.
لا يوجد سبب تقني يمنع كلا الموقعين من العمل عبر HTTPS بغض النظر عما إذا كان CloudFlare مفعّلًا أم لا. الأمر سهل التنفيذ بمجرد فهم طريقة التسجيل التي يستخدمها Let’s Encrypt وكيفية ضبط CloudFlare لمنصة Discourse. يوفر CloudFlare وضع HTTPS كاملًا، وهو مصمم خصيصًا لهذا النوع من السيناريوهات: تشفير TLS من الخادم إلى شبكتهم، وتشفير TLS من شبكتهم إلى العملاء، مع فك التشفير في المنتصف لتمكينهم من التخزين المؤقت و"التحسين"، على الرغم من أننا نعرف في حالة Discourse أن هذه الخطوة الأخيرة لا تعمل بكفاءة عالية.
هذا هو السبب الرئيسي، على الرغم من وجود فائدة واضحة في إنشاء قاعدة صفحة لتخزين /uploads/ مؤقتًا؛ فهذا سيساعد في تخفيف العبء لفترة من الوقت، وسيجعل خادم VPS منخفض المواصفات يعمل لفترة أطول قليلاً.