مشاكل في الاتصال أثناء التثبيت

جارٍ التحقق من اسم النطاق الخاص بك . . .
تحذير: يبدو أن المنفذ 443 للكمبيوتر غير قابل للوصول باستخدام اسم المضيف: ***.com.
تحذير: فشل الاتصال بـ http://shoutam.com (المنفذ 80) أيضًا.

يشير هذا إلى أن ***.com يحل إلى عنوان IP لا يصل إلى هذا الجهاز حيث تقوم بتثبيت discourse.

أول شيء يجب القيام به هو التأكد من أن ***.com يحل إلى عنوان IP الخاص بهذا الخادم.
عادةً ما تفعل هذا في نفس المكان الذي اشتريت منه النطاق.

إذا كنت متأكدًا من أن عنوان IP يحل بشكل صحيح، فقد تكون هناك مشكلة في جدار الحماية.
قد يساعد البحث على الويب عن “فتح المنافذ خدمة السحابة الخاصة بك” (open ports YOUR CLOUD SERVICE).

هذه الأداة مصممة فقط للتثبيتات الأكثر شيوعًا. إذا لم تتمكن من حل المشكلة المذكورة أعلاه، فستحتاج إلى تحرير containers/app.yml بنفسك ثم كتابة

./launcher rebuild app

هل يمكن لأحد مساعدتي في حل هذه المشكلة؟ أنا أستخدم Cloudflare.

إما قم بإيقاف تشغيل Cloudflare أو سيتعين عليك تكوين Discourse لاستخدام قالب Cloudflare.

إعجابَين (2)

لكنك لن تتمكن من التثبيت، حيث يتطلب Let’s Encrypt وصولاً مباشرًا إلى المنافذ 80 و 443 لإصدار شهادة.

بعد الحصول على شهادتك وتثبيت Discourse، يمكنك البحث عن مواضيع حول كيفية جعله يعمل مع Cloudflare في المنتصف (والتي تتضمن استخدام قالب Cloudflare).

إعجاب واحد (1)

صيد جيد، هذا ليس Let’s Encrypt بل عميل acme.sh المستخدم في Discourse والذي يحتاج إلى وصول مباشر (لدى Certbot ملحقات DNS التي تتطلب عملًا إضافيًا ولكنها تزيل هذا المتطلب)، لم أفكر في ذلك لأن كل تثبيت Discourse نشرته في السنوات الأخيرة تطلب استخدام وكيل عكسي، ومن ثم تم تعطيل قالب SSL الداخلي بشكل استباقي.

لقد قمت بإزالة الموقع من CLoudflare، ومع ذلك ما زلت أواجه نفس المشكلة. ماذا يمكنني أن أفعل أيضًا من فضلك؟

لست متأكدًا مما تقصده بـ تمت الإزالة ولكن عادةً ما يستغرق انتشار نظام أسماء النطاقات (DNS) بضع ساعات. قد يكون من المفيد الانتظار بعض الوقت ثم المحاولة مرة أخرى.

هناك الكثير من المعلومات المفقودة هنا حتى نتمكن من تقديم المزيد من المساعدة حقًا.

في هذه الأيام، لن تفشل Cloudflare في وضع الوكيل (السحابة البرتقالية) طالما أن HTTPS غير مضبوط على صارم، حيث يتم تمرير كل من :80 (HTTP) و :443 (HTTPS) مباشرة إلى الخادم.

يجبر الوضع الصارم حركة المرور على المنفذ :80 على إعادة التوجيه إلى SSL، وبالتالي سيفشل التحدي.

من المحتمل جدًا أنك قد فاتتك واحدة أو أكثر من الأساسيات، ولكن بدون إخبارنا بمكان وجود VPS وما قمت بتكوينه داخل DNS، سنكون نخمن في أفضل الأحوال بشأن ما يحدث هنا.

تتطلب بعض المزودين تعيين قوائم التحكم في الوصول (ACLs) بين VPS الخاص بهم والعالم الخارجي - هل تحققت من أن هذه المنافذ مفتوحة خارجيًا؟ هل أنت متأكد من أن السجل ‘a’ الذي أضفته إلى DNS يشير إلى عنوان IP العام الذي تم تخصيصه؟ هل توجد أي جدران حماية؟

هذا صحيح مع بعض مزودي DNS، بالتأكيد، ولكن Cloudflare تفرض قيمة TTL تبلغ 300 ثانية على أي عنوان تقوم بتوكيله. هذا يعني أن خوادم DNS الأولية ستكون قد انتهت صلاحية السجلات القديمة في غضون خمس دقائق من التغيير.

كل ما يفعله القالب هو التأكد من استخراج عناوين IP الصحيحة للعملاء من معلومات الرأس الإضافية التي تضيفها Cloudflare عند تمكين وضع الوكيل، وهو ليس ذا صلة بعملية التثبيت حقًا.

إعجابَين (2)

إذا قمت بإعادة بناء عدة مرات باستخدام السحابة البرتقالية، فمن المحتمل أنك وصلت إلى حدود المعدل مع Let’s Encrypt. الحلول السهلة هي استخدام مجال فرعي مختلف أو الانتظار لمدة أسبوع.

هل سيعمل الأمر إذا قمت بتدمير القطرة وإنشاء واحدة جديدة؟

يرجى ملاحظة أنني قمت بتثبيت discourse بنجاح قبل هذه المشكلة ولكنني قمت بتدمير تلك القطرة بسبب وجود خطأ في البريد الإلكتروني للمسؤول. الآن لا يمكنني تثبيت discourse باستخدام نفس العملية التي استخدمتها من قبل.

هذا يشير إلى أن شرحي هو السبب المحتمل.

إعجاب واحد (1)

إحياء هذا الموضوع على أمل أن يتمكن المعلقون ذوو المعرفة من مساعدتي أيضًا.
أواجه نفس الخطأ الذي واجهه صاحب الموضوع الأصلي.
أعمل حاليًا على Unraid ولدي حاوية تعمل بـ Nginix Proxy Manager. تم تكوين منافذ جدار الحماية لإرسال كل حركة المرور على المنفذين 80/443 إلى حاوية NPM الخاصة بي. لقد قمت بإعداد العديد من حاويات Docker بنجاح باستخدام حاوية NPM الخاصة بي وكل شيء سار على ما يرام.

لقد قمت بتثبيت جهاز افتراضي UbuntuServer، ومررت بالإعداد الأولي، وقمت بإعداد عنوان IP ثابت للجهاز الافتراضي، وقمت بتثبيت Docker، ثم قمت بتنزيل Discourse، ولكنه فشل في نص الإعداد تمامًا كما فعل صاحب الموضوع الأصلي.

لقد نشرت المزيد من المعلومات في الموضوع التالي: Discourse installed in UNRAID Ubuntu Server VM behind NPM reverse proxy not resolving hostname

أشعر أنه قد أصبح راكدًا، أو على الأقل لم يتم التوصل إلى حل حقيقي. أي مساعدة ستكون محل تقدير كبير.

إذا كنت ترغب في استخدام Nginx Proxy Manager، فستحتاج إلى تكوين ملف app.yml الخاص بك يدويًا. يمكنك إما إيقاف تشغيل الوكيل الخاص بك لفترة كافية للسماح بتشغيل discourse-setup في المرة الأولى (ستظل بحاجة إلى تغيير بعض الأشياء يدويًا) أو النسخ من samples/standalone.yml.

نعم، حسب فهمي، يتم ملء ملفات yml بعد تشغيل discourse-setup واكتماله. لتحقيق ذلك، ربما يمكنني توجيه حركة مرور WAN على جدار الحماية الخاص بي إلى UbuntuVM الذي أقوم بتثبيت discourse عليه، ثم بعد اكتمال الإعداد، أعيد توجيه حركة المرور الخاصة بي إلى الوكيل العكسي ثم أقوم بتكوين ملف app.yml الخاص بي.

لقد نسيت هذا. يمكنك استخدام المفتاح --skip-connection-test لتجاوز هذا الاختبار وتشغيله. ستحتاج بعد ذلك إلى تعديل المنافذ يدويًا، ولكنه سيسمح لك باستخدام البرنامج النصي لإنشاء الملف وإدخال بيانات اعتماد SMTP الخاصة بك.

إعجابَين (2)

هذه المعلومات ذهبية. سأجرب هذا وإذا سار كل شيء على ما يرام فسأعود إلى هذا الموضوع! شكراً مرة أخرى!

إعجاب واحد (1)