كما هو موضح في العنوان، قمت بتشغيل الأمر sudo apt install apache2.
الخادم لن يبدأ، وهذه هي الرسالة الخطأ:
(98)Address already in use: AH00072: make_sock: could not bind to address [::]:80
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
AH00015: Unable to open logs
Action 'start' failed.
The Apache error log may have more information.
pam_unix(sudo:session): session closed for user root
Control process exited, code=exited status=1
apache2.service: Failed with result 'exit-code'.
Failed to start The Apache HTTP Server.
كيف يمكنني حل هذه المشكلة؟ شكرًا لكم جميعًا مقدمًا.
من قبل، يبدو أنك كنت تشغل عددًا من المواقع باستخدام Apache. كان Apache يستمع إلى المنافذ 80 و443 ثم “يُوجّه” (يعيد توجيه) الطلبات كـ “مضيفات افتراضية” (virtual hosts)، مما يسمح لك بتشغيل العديد من المواقع على نفس الخادم مع الاستماع لنفس المنافذ (80 و443). كان هذا هو “أساسيات LAMP 101”… طريقة المضيفات الافتراضية.
الآن، لنفترض أنك قمت بتثبيت Discourse بالطريقة الرسمية الموصى بها (OOTB). سيقوم Discourse (في حالته الافتراضية) بمحاولة الارتباط بنفس المنافذ وفشل ذلك لأن Apache يستخدمها بالفعل (مرتبط بها). لديك خيارات:
تشغيل Discourse على مقبس نطاق يونكس (unix domain socket) وإعداد Apache ليعمل كوكيل عكسي (reverse proxy) لتطبيق Discourse كمضيف افتراضي.
ملاحظة: لقد اختبرت هذا وهو يعمل؛ لكن هذا غير مدعوم رسميًا (أو حتى غير رسمي) من قبل Discourse.
الانتقال من Apache إلى nginx وتشغيل جميع خوادم الويب الخاصة بك عبر nginx، بالإضافة إلى عمل وكيل عكسي لتطبيق Discourse كمضيف افتراضي، باستخدام مقبس نطاق يونكس لتطبيق Discourse-docker المنتج.
ملاحظة: هذا أيضًا غير مدعوم رسميًا من قبل Discourse؛ ومعظم الأشخاص الذين يشغلون مواقع Apache سيجدون أنه أمر شاق (“دب”) لنقل كل محتوى mod_rewrite و geo-ip المشفر في Apache2 إلى nginx؛ لكن ذلك ممكن بالطبع، خاصة إذا كانت تطبيقاتك مبنية لكل من nginx و Apache2 (وهذا أسهل، لكنه لا يزال غير مدعوم رسميًا).
تعريض حاوية Docker الخاصة بـ Discourse على منافذ أخرى غير 80 و443.
ملاحظة: هذا غير موصى به (حقًا) أيضًا (لكنه مدعوم رسميًا كما أتذكر). ومع ذلك، لا يريد معظم الأشخاص الوصول إلى تطبيق ويب عن طريق كتابة أرقام المنافذ مثل https://my-great-discourse-app.org:3334، لذا لا يفعل معظم الناس ذلك في بيئة الإنتاج. القصة مختلفة في بيئة التطوير.
توصيتي “دون معرفة جميع تفاصيلك”، بصفتي شخصًا لديه خبرة كبيرة في LAMP والآن المزيد والمزيد من Discourse، هي تشغيلهما على خوادم منفصلة (وهذا مدعوم رسميًا من قبل Discourse)؛ ولكن إذا كنت مقيدًا بشدة بالميزانية ويجب تشغيلهما على نفس الخادم (أو كنت تحب ببساطة وجود خادم واحد كبير ومعقد)، فستحتاج إلى تعلم كيفية إعداد Apache2 ليعمل كوكيل عكسي لمقبس نطاق يونكس من وإلى تطبيق Discourse.
لقد اختبرت هذا، ومن الممكن إعداد Apache2 ليعمل كوكيل عكسي لـ Discourse باستخدام مقبس نطاق يونكس؛ لكن هذا الحل غير مدعوم رسميًا (على الإطلاق).
ملاحظة: الرابط الخاص بإعداد Apache2 مع HAProxy كان حلًا لم أستطع جعله يعمل بسهولة؛ لذا تخليت عنه (لا حاجة لاستخدام HAProxy فقط، فهناك “طرق أقدم” للقيام بذلك). ومع ذلك، قد يكون من الأفضل لك ببساطة اتباع هذا الدليل الخاص بـ Discourse:
النشر على منافذ غير قياسية غير مدعوم بنسبة 100%. لقد رأيتُ بعض المواضيع حيث قام مالكو المواقع بتغيير المنافذ بدلاً من الربط بمقبس (socket)، واستخدموا وكيلًا عكسيًا (reverse proxy) لإعادة التوجيه إلى 80/443، ولكن إذا كانت النتيجة النهائية تتطلب :port، فإن ذلك غير قابل للدعم.