إعادة البناء لم تُجدِ نفعًا، فلا يزال الرفض قائمًا لبروتوكول HTTPS، وعلاوة على ذلك، عدت إلى صفحة الترحيب الخاصة بـ NGINX عبر بروتوكول HTTP.
بالتأكيد لديك nginx مثبت.
هل جربت
apt purge nginx
أو
dpkg -l |grep nginx
؟
بعد إيقاف nginx، ماذا يقول ./discourse-doctor؟
تم الرد: nginx غير مُثبَّت
تم الرد: لا يوجد شيء
كل المدخلات (مثل البريد الإلكتروني، عنوان الويب) فارغة
وهناك حاويتان قيد التشغيل على المنافذ: 80 → 80، 443 → 443، و2222 → 22
يُظهر أن تطبيق حاوية discourse قيد التشغيل
ويُظهر أن إصدار Discourse غير موجود
أوبس، لم أزل للأسفل، دعني أقرأ النص الناتج وأرى ماذا يقول.
تعديل: يقول نفس الشيء
هل بدأت هذا العرض بتشغيل ./discourse-setup؟
ما هي؟
هل تقصد ما إذا كنت قد مررت بعملية الإعداد (وهو ما فعلته)، أم أنني لم أشغّل ./discourse-doctor وهو ما قمت بتشغيله فعليًا.
خطأ مني، كان هناك واحد فقط، وهو 4efab95a60b8
الآن، تظهر الصفحة الخاصة بـ HTTP رسالة تفيد بأنها لم ترسل أي بيانات، لذا لم تعد هناك حتى صفحة NGINX.
تحرير: عدنا إلى صفحة nginx.
تحرير 2: لا يهم، لم نعد إليها.
ما الذي يعرضه docker ps؟
نفس الحاوية تمامًا مثل ملف النص.
ربما يكون عكس الوكيل مع caddy أفضل في هذا السيناريو؟
كنت أرغب في معرفة اسم ما كان عليه. هذا الرقم بلا معنى.
لقد حققت نجاحًا مع Caddy في الماضي. ومع ذلك، من المرجح أن يواجه نفس المشكلة.
إليك اقتراح.
قم بالتسجيل للحصول على قطرة (Droplet) بقيمة 5 دولارات في DigitalOcean. اتبع دليل التثبيت حرفيًا، دون نسخ شهادات إضافية أو أي شيء آخر.
تُحسب تكلفة قطرات DigitalOcean بشكل نسبي؛ إذا اتبعت الدليل (والذي يستغرق 30 دقيقة أو أقل)، فإن تكلفة إثبات التثبيت تبلغ 0.02 دولار فقط. إذا لم ترغب في الاحتفاظ بالمثيل بعد ذلك، فما عليك سوى الضغط على زر التدمير.
إذا فشل الأمر لا يزال، فهناك ما يمكننا البدء في استكشافه وإصلاحه.
إذا نجح الأمر، فإن ذلك يثبت أن المشكلة ليست في Discourse. وإذا اخترت استخدام بيئة أكثر تعقيدًا، فإنك تقبل بحكم ذلك مسؤولية التحديات الإضافية التي تطرحها. فقد تم إثبات أن التثبيت القياسي يعمل على صورة Ubuntu في DigitalOcean، وسياسة الشبكة الخاصة بهم لا تسبب مشاكل مع Let’s Encrypt (رغم أنها قد تحتاج أحيانًا إلى إصلاحات متوسطة لإرسال البريد الإلكتروني).
لاحظ أنه إذا كنت تطلب نفس اسم الشهادة مرارًا وتكرارًا، فقد يكون Let’s Encrypt قد وضع اسم النطاق الكامل (FQDN) المحدد في فترة انتظار.
حسنًا، لقد نجحت في النهاية. إليك ما قمت به. قمت بتثبيت Caddy، وأعدت إعداد وكيل (proxy) لإعادة توجيه جميع الاتصالات من عنوان URL إلى localhost:444، لكن هذا لم يكن الحل. ثم انتقلت إلى ملف app.yml وقمت بتغيير المنفذ إلى ما يلي:
- "81:80" - تم نقل HTTP إلى المنفذ 81 ليُحتفظ به لـ Caddy
- "444:443" - سيتولى Caddy التعامل مع HTTPS
بعد ذلك، عندما أذهب إلى الموقع، يتم تحميله ولا يتم رفض الاتصال عبر HTTPS!
شكرًا جزيلًا للجميع الذين ساعدوا وقدموا اقتراحات!
سأقوم بذلك بالتأكيد، إذا اضطررت إلى تثبيت Discourse مرة أخرى.