غير مرجح. إنه نوع الشيء الذي ستقوم به مرة واحدة بالضبط، وستقوم به عندما تكون بالفعل في خضم التعامل مع app.yml.
سأرى ما إذا كان بإمكاني تقديم طلب سحب (PR) لإضافته إلى standalone.yml، مع ذلك.
ومع وضع هذا في مكانه، يصبح الأمر أبسط بكثير!
4 إعجابات
شكرا جزيلا على هذا، لقد كنت أقوم بتعديل templates/web.letsencrypt.ssl.template.yml محليًا ولكن هذا يجعل حياتي أسهل بكثير!
إعجاب واحد (1)
هل نحتاج إلى تضمين اسم المضيف (الأصلي) في هذا، أم الأسماء البديلة فقط؟
فقط الأسماء المستعارة. اسم المضيف هو اسم المضيف.
إعجاب واحد (1)
إذن هكذا إذن؟
env:
DISCOURSE_HOSTNAME: domain.com
DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org
إعجاب واحد (1)
أتصارع فلسفياً مع معنى ‘الاسم المستعار’، وأدرجت كلا العنوانين اللذين أريد أن يؤديا إلى موقعي: nzarchitecure.net.nz و www.nzarchitecture.net.nz دون أي آثار سلبية واضحة (وبافتراض عدم وجود فائدة أيضًا).
إعجاب واحد (1)
هل يمكن تعديل standalone.yml بواسطة إعدادات المسؤول ضمن نسخة Discourse قيد التشغيل أو تكليفها بقراءتها؟
إذا كان الأمر كذلك، فسيكون ذلك مفيدًا جدًا للمستخدمين الجدد وأولئك الذين يتطلعون إلى ترحيل النطاقات أو إضافة أسماء مستعارة - مما يقلل من الصداع الذي يجب البحث عنه واستكشاف الأخطاء وإصلاحها.
لا. سيكون من السيئ جدًا أن تتمكن الوظائف التي تعمل في الحاوية من تغيير أشياء مثل app.yml. في الواقع، من ممارسات الأمان الجيدة وضع أشياء مثل مفاتيح S3 في ملف yml بحيث تكون مخفية عن واجهة Discourse.
مرة أخرى، من النادر جدًا إجراء تغييرات مثل تلك التي تحتاج إلى إعادة توجيه النطاقات، وهي تتطلب أشياء أخرى، مثل إعدادات DNS. الوقت المناسب للقيام بذلك هو عند إعداد Discourse، وعند إعداد Discourse، فإنك تعبث بملف yml.
إعجاب واحد (1)
لقد طُرح هذا السؤال وتمت الإجابة عليه، ولكن يبدو أن DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com مطلوب وليس مجرد الاسم المستعار كما في DISCOURSE_HOSTNAME_ALIASES: other.domain.com
هل يمكن لأحد أن يؤكد من فضلك؟
أيضًا، يبدو أن طلب السحب (PR) من @pfaffman لم يتم دمجه، لذا تحتاج قوالب العينات إلى تغيير يدوي، أليس كذلك؟
إعجاب واحد (1)
لا. المثال مربك. تحتاج فقط الأسماء الإضافية إلى أن تكون في DISCOURSE_HOSTNAME_ALIASES.
لست بحاجة إلى DISCOURSE_HOSTNAME_ALIASES على الإطلاق ما لم تكن بحاجة إلى أن يكون لموقعك شهادة لاسم آخر (مثل الأمس عندما نقلت شخصًا من forum.example.com إلى fancyword.example.com).
لذا فعلت
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: forum.example.com
وقمت بعمل نسخة احتياطية للمنتدى قبل إجراء التغييرات، وأجريت التغييرات، وأعدت البناء، واستعدت النسخة الاحتياطية (المستعيد يعالج إصلاح مراجع اسم المضيف) والآن إذا ذهبت إلى forum.example.com ستحصل على شهادة صالحة ويتم إعادة توجيهك إلى النطاق الفرعي الجديد.
نعم، يبدو أن لا أحد لاحظ طلب السحب (PR). يجب علي دائمًا البحث عن هذا. بالتأكيد، DISCOURSE_HOSTNAME_ALIASES هو “واضح” ولكن فقط عندما أنظر إليه. 
إعجابَين (2)
شكرًا لك على ذلك @pfaffman
في حالتي أحتاج هذا لكي يعمل تكامل AWS CDN و AWS S3 CDN بشكل صحيح مع التخزين المؤقت
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: cloudfront.example.com
إن إنشاء شهادات متعددة هو بالضبط ما كنا نحتاجه/ للأسف، لقد أرهقنا الحساب بـ certbot عددًا كبيرًا جدًا من المرات بالأمس، لذا حان وقت الحبس لهذا الموقع. سأحاول بموقع مختلف بعد أن أكدت الاستخدام الصحيح لـ DISCOURSE_HOSTNAME_ALIASES
إعجاب واحد (1)
إذًا، تحتاج إلى القيام بذلك في AWS.
إذا أضفت اسمًا مستعارًا آخر، فسيسمح لك ذلك بطلب شهادة جديدة (ما لم تفعل شيئًا لحظر النطاق بأكمله).
إعجابَين (2)
يبدو أن هذا قد لا يكون ضروريًا بعد كل شيء. يبدو أن التخزين المؤقت يعمل. سأقوم بالتحديث بالتفاصيل على Issues with AWS CDN and S3
إعجاب واحد (1)