لا أعتقد أن هذا هو الحال بعد الآن.
بالضبط @jomaxro. لهذا السبب قلت
أوه، عذرًا، لقد فاتني هذا التغيير.
إذن، إذا لم يحدد المستخدم عنوان بريد إلكتروني لإشعارات Let’s Encrypt، فإن discourse-setup يقوم الآن بتفعيل Let’s Encrypt بشكل أعمى دون التحقق من أن النطاق يحل إلى الخادم الحالي. أما إذا تم تقديم عنوان بريد إلكتروني، فإنه يقوم بإجراء الفحص. هذا لا يبدو فكرة جيدة.
لماذا إجبار استخدام HTTPS عندما لا يملكون اسم نطاق صالح؟ إذا كان المخطط هو إجبار الجميع على استخدام HTTPS طوال الوقت، فيجب أن نتحقق من صحة اسم النطاق ثم نرفض التشغيل بدلاً من منحهم تثبيتًا معطوبًا.
الطريقة التي تعمل بها الآن، إذا لم توفر عنوان بريد إلكتروني لـ Let’s Encrypt وكان النطاق لا يحل إلى الخادم، فإن discourse-setup يبدو وكأنه نجح، ويقوم بتشغيل خادم ويب لن يقبل الاتصالات لأن nginx لا يمكنه العثور على شهادة. أعتقد أن الشيء الأفضل هو عدم طلب عنوان بريد إلكتروني لـ Let’s Encrypt، واستخدام (أول؟) بريد المطور لـ Let’s Encrypt، مع الاستمرار في إجراء فحص DNS، لكن هذا لا ينتمي إلى هذا الموضوع الآن.
لا، هذا ليس كيف تعمل Let’s Encrypt. لا علاقة للبريد الإلكتروني بتحقق النطاق. يُستخدم لتنبيه المستخدم إذا كان شهادته على وشك الانتهاء ولا يمكن تجديدها. يتم التحقق دائمًا عبر DNS.
لا يمكن لـ Let’s Encrypt إصدار شهادة لعنوان لا يستوفي متطلبات التحقق. لو فعلت ذلك، لانهيار مخطط Let’s Encrypt بالكامل بين عشية وضحاها.
لا. هذا هو كيف يعمل discourse-setup، أو كان يعمل. كان يحمي المستخدمين من طلب شهادة عندما يكون متأكدًا تقريبًا من أن الطلب سيفشل. الآن، سيعمل ويطلب شهادة حتى عندما لا يكون من الممكن أن ينجح، ولن يكون لديه أي طريقة لإبلاغ المستخدم بأنه لم ينجح، لذا فإنه الآن يفشل بصمت دون أي تحذير.
مرة أخرى، لماذا قد يفشل ذلك؟ البريد الإلكتروني ليس شرطًا للتحقق من النطاق.
لم يتم إنشاء بريد إلكتروني أبدًا في حالة الفشل.
يُستخدم البريد الإلكتروني فقط لإبلاغ المستخدم لاحقًا إذا فشلت Let’s Encrypt في التجديد وكان من المقرر أن تنتهي صلاحية الشهادة. إذا تم تجديد الشهادة دون مشاكل، فلن يرى المستخدم أي بريد إلكتروني.
لا أعتقد أن هذا كان مقصود التغيير. كان القصد هو تمكين SSL بغض النظر عن ما إذا تم تقديم بريد إلكتروني. يجب أن نواصل التحقق من حل النطاق cc @Falco
سيفشل إذا لم يتم حل اسم النطاق إلى المضيف. لا يهم عنوان البريد الإلكتروني، ولكن إذا كان هناك واحد، سيحذر إعداد Discourse المستخدم إذا لم يتم حل العنوان.
يجب أن تمر عملية حل النطاق @falco، وإلا يجب إيقاف الإعداد.. هذا تغيير سيء.
لذلك قمت بإجراء بعض التغييرات في فرع. إليك كيف ستعمل العملية:
استخدام اسم مضيف خاطئ:
root@droplet:/var/discourse# ./discourse-setup
اسم المضيف لـ Discourse الخاص بك؟: bad-domain.com
التحقق من اسم النطاق الخاص بك . . .
تحذير: لا يبدو أن هذا الخادم يمكن الوصول إليه عند bad-domain.com:443.
يفشل الاتصال أيضًا بـ http://bad-domain.com (المنفذ 80).
يشير هذا إلى أن bad-domain.com يحل إلى عنوان IP خاطئ
أو أن حركة المرور لا تُوجّه إلى خادمك.
ابحث في Google: "فتح المنافذ خادمتك السحابية" للحصول على معلومات حول حل هذه المشكلة.
إذا كنت ترغب في المتابعة على أي حال، ستحتاج إلى تشغيل cp samples/standalone.yml containers/app.yml
وتعديل ملف containers/app.yml يدويًا.
استخدام اسم مضيف صحيح:
root@droplet:/var/discourse# ./discourse-setup
اسم المضيف لـ Discourse الخاص بك؟: good-domain.com
التحقق من اسم النطاق الخاص بك . . .
نجح الاتصال بـ good-domain.com.
عنوان البريد الإلكتروني لحسابات المسؤول؟ :
التغييرات قيد الانتظار في
هل يبدو الأمر جيدًا @pfaffman @codinghorror؟
تعليق على سبب الحاجة إلى هذا التغيير في المقام الأول
أولاً، أنا مندهش من أنه خلال الأشهر الثلاثة تقريبًا منذ أن أصبح الأمر بهذه الطريقة، لم تكن هناك شكاوى كثيرة، وحتى الموضوع الذي لفت انتباهي لم يكن يواجه مشاكل بسبب هذا التغيير، لذا ربما لا يكون الأمر مهمًا بقدر ما أعتقد.
أول شيء لا أفهمه حقًا هو: هل تريدون حقًا جعل من المستحيل إعداد موقع يعتمد فقط على بروتوكول HTTP باستخدام أداة discourse-setup؟ أفترض أنه يجب عليهم بالفعل القيام بعدد من إعدادات DNS لجعل البريد يعمل، لذا ربما لا يكون إنشاء سجل A أيضًا مشكلة كبيرة.
ملاحظات حول التغيير
ما لم تكن قد أجريت تغييرًا لم ألاحظه، فإن النص البرمجي ينشئ ملف app.yml قبل أن يبدأ في طرح الأسئلة، لذا يمكنكم فقط القول شيئًا مثل: “تركيب Discourse بدون إعدادات DNS غير مدعوم. للاستمرار بدون إعدادات DNS، قم بتعديل app.yml حسب احتياجاتك ثم شغّل ./launcher rebuild app” ثم الخروج دون إجراء عملية التمهيد.
أيضًا، إذا كنتم تنوون إلزام الجميع باستخدام Let’s Encrypt وHTTPS، فقد يكون من المنطقي تعديل standalone.yml وweb_only.yml وفقًا لذلك، وبذلك يمكن إزالة عبارات sed المعقدة تلك.
بعض الأفكار الإضافية
من قسم “هذا مشكلتي”: نصي البرمجي الحالي للتثبيت يعمل قبل أن يتمكن المستخدمون من إعداد DNS، حيث أقوم بإنشاء الـ droplet لهم، وإعداد Discourse، وإرسال بريد إلكتروني يحتوي على تعليمات DNS، ثم الانتظار حتى يتم إعداد DNS، وأخيرًا تعديل app.yml لتمكين القوالب وتحديد عنوان Let’s Encrypt. لكن أعتقد أن هذا مجرد سبب تاريخي؛ فالبديل الذي يجب أن أقوم به هو إنشاء الـ droplet، وتكوين Mailgun، والانتظار حتى يتم إعداد DNS، ثم إجراء التثبيت. هذا لا يزال يسمح لنصي البرمجي باستخدام discourse-setup، وهو ما أحب استخدامه كاختبار متكرر للتأكد من أنه لا يزال يعمل (لا أعتقد أنكم تقومون باختبار آلي لـ discourse-setup، أليس كذلك؟)
نعم.
لم أسمع أي شكاوى حول هذا التغيير، ومنذ إطلاقه لم ألاحظ وجود العديد من نسخ Discourse التي تعمل فقط عبر HTTP، لأنه عندما تُعتبر شيئًا ما اختياريًا، يتخطاه الجميع دون تفكير. هذا تغيير رائع في رأيي لضمان إعدادات افتراضية آمنة لـ Discourse، وهو ما نركز عليه في دليل الـ 30 دقيقة.
أوه، هذا أفضل حتى، نحتاج إلى تعليمات أقل!
أوه، الآن أفهم ردك القوي تجاه هذا التغيير لأنه كسر إعداداتك، آسف على ذلك.
أوصي بشدة باستخدام ملف yml المباشر لأي شيء آلي بدلاً من استهداف السكربت التفاعلي.
ملخص سريع: نعم، مع التعديل الطفيف على اللغة الذي أوصيت به، يبدو هذا جيدًا من جهتي.
أتفق معك. لا توجد شكاوى! يبدو هذا فوزًا.
لا! لم يكسرها (!). لقد لاحظت فقط بشكل غير واضح أن المواقع لم تكن تعمل قبل أن أكمل المرحلة الثانية من التثبيت التي تمكّن HTTPS. وإعداداتي ليست من مسؤوليتك. (آه، الآن سيكسر هذا سكريبتي، لكن عدم إجراء التثبيت قبل إعداد DNS سيكون أفضل على أي حال. لم أقم بتثبيت غير مؤمن بـ HTTPS منذ عام واحد على الأقل.)
السبب في أنني كنت أحب استخدام سكريبتي لـ discourse-setup هو أنه يضمن بشكل خاص أن عملاء التثبيت يحصلون على تثبيت قياسي، وأنه عندما يقول شخص ما “أجريت تثبيتًا ولم يعمل”، يمكنني تشغيل سكريبتي وإجراء نفس الخطوات التي كان يجب أن يقوموا بها، ثم أقول: “حسنًا، لقد أجريت تثبيتًا للتو وهو يعمل.” لكنني لا أعتقد أنني أتذكر مرة واحدة خلال السنوات الثلاث الماضية وجدت مشكلة، لذا ربما لا يفيد “اختباري” أي شخص.
رائع، شكرًا على التحليل والمراجعة!
تم دمج طلب السحب (PR) حتى نقوم دائمًا بالتحقق من DNS.