مرحبًا! لقد راجعت المنشورات القديمة التي تتعلق بمشكلتي، لكنني لم أجد الحل، لذا ها أنا ذا.
لدي موقع ووردبريس (مُستضاف على الخادم أ) متصل بمناقشة ديسكورس (على الخادم ب) ويعمل كمزود مصادقة موحدة (SSO) لتلك المناقشة.
لقد قمت مؤخرًا بتغيير استضافة ووردبريس (إلى الخادم ج — شركة استضافة جديدة) ومزود خدمة أسماء النطاقات (DNS) بالكامل، من غوغل إلى غاندي، مع إعادة إنشاء إعدادات أسماء النطاقات بدقة (@ على عنوان IP الجديد، وwww كسجل CNAME، وforum على عنوان IP الثابت الخاص به)، بينما بقيت المناقشة على الخادم ب.
الآن، يشير ووردبريس إلى أن الاتصال معطل، وأحصل على خطأ curl 6 (تعذر حل اسم المضيف؛ خطأ غير معروف) عند محاولة النشر (كما أرى رسالة “لا يوجد مدير بعنوان xyz@mydomain.net”، لكنني أفترض أن هذا أمر طبيعي إذا لم يكن الاتصال نشطًا).
هل لديك أي فكرة أو مقترح حول أين يمكنني البحث؟ لقد تواصلت بالفعل مع المزود الجديد للتحقق من إعدادات جدار الحماية، لكنهم قالوا إن كل شيء واضح، وربما يجب عليّ التواصل مع مطوري الإضافة.
للأسف والعكس؟ لست خبيرًا في SSO، لكنني أعتقد أن الخادم B يحتاج إلى إجراء استدعاء عادي (callback) إلى الخادم C؟ إذا كان لا يزال يحتوي على عنوان IP الخاص بالخادم A في مكان ما، فقد يفشل ذلك.
السبب الذي دفعنا مؤخرًا إلى إضافة بنية تسجيل الأحداث إلى الإضافة هو تشخيص مثل هذه المشكلات مباشرة. سنقوم قريبًا بإضافة وظائف التسجيل إلى ميزة الاتصال، لكن في الوقت الحالي، لا تعمل إلا ضمن ميزة النشر.
من غير المرجح أن تُخبرنا أي مشكلة اتصال في سجلات النشر بأي معلومات مفيدة. ومع ذلك، بما أنك ذكرت محاولة نشر، يرجى أولًا التحقق من لوحة تحكم “السجلات” في إضافة WP Discourse. يمكنك مشاركة سطر محدد من السجل، أو مشاركة السجل كاملاً معي عبر الرسائل الخاصة. كما أني أنصحك بإصدار بيانات اعتماد API جديدة في منصة Discourse الخاصة بك وتطبيقها في الإضافة للتأكد من أن هذه ليست هي المشكلة.
بصرف النظر عن ذلك، ورغم أنني لا أرغب في تحويل هذا الأمر إلى مواجهة مع مزود الاستضافة الخاص بك، فإن عدم القدرة على تنفيذ أمر cURL لنطاق معين يشير إلى مشكلة بيئية وليس مشكلة في الإضافة. إذا بحثت عن أخطاء مماثلة هنا، ستجد أن المستخدم @simon ساعد طوعًا العديد من الأشخاص في تشخيص ما يُعد في جوهره مشكلات بيئية. على سبيل المثال (بما في ذلك بعض أدوات التشخيص المحتملة)، راجع:
أنصحك بالضغط على مزود الاستضافة الخاص بك قليلاً أكثر، وسؤالهم عن سبب عدم القدرة على إرسال طلب cURL إلى نطاق معين. إذا كان لديهم سبب أكثر تحديدًا للاعتقاد بأن المشكلة تتعلق بإضافة WP Discourse، وليس، على سبيل المثال، بإصدار cURL غير صحيح على الخادم (وهو ما يبدو أكثر احتمالاً للوهلة الأولى)، فمرحبًا بهم في النشر هنا، أو حتى مراسلتي عبر الرسائل الخاصة، وسأكون سعيدًا بالبحث في الأمر معهم بشكل أعمق.
ومع ذلك، بما أن إجابة شركة الاستضافة بخصوص تحديث curl هي: "إصدار cURL المثبت هنا هو أحدث إصدار رسمي في مستودع CentOS. لهذا السبب نستخدم هذا الإصدار وليس الأحدث المتاح على موقع المطور الرسمي.
تكون CentOS حذرة جدًا من دفع إصدارات جديدة إلى المستودع الرسمي لأنها تجري العديد من الاختبارات على البرنامج قبل إصداره للتأكد من استقراره في جميع الحالات. بمجرد إصدار الإصدار الجديد في مستودع CentOS الرسمي، سيتم تحديثه لدينا أيضًا."، أعتقد أن هذا لن يفضي إلى أي نتيجة، وسأضطر إلى تغيير المضيف مرة أخرى.
قبل إجراء التبديل، ربما يُستحسن أن توضح لهم أن عدم دعم TLS 1.2 سيسبب مشاكل في دعم بعض إضافات WordPress، كما أنه ينطوي على بعض المشكلات الأمنية بحد ذاته. ومع ذلك، قد لا يزال من الجيد متابعة الأمر قليلاً.
سأحاول لأنني “لا أستطيع تحمل عدم المحاولة” (مايكل جوردان، الفيلسوف ؛)) لكن يبدو أن آراءهم قد حُسمت في هذه المسألة.
المضيف القديم يستخدم الإصدار 7.68 على أوبونتو.
)