Привет! Я просмотрел старые темы, связанные с моей проблемой, но не нашёл решения, поэтому обращаюсь сюда.
У меня есть сайт на WordPress (размещённый на сервере A), подключённый к форуму Discourse (на сервере B) и выступающий в роли провайдера SSO для этого форума.
Недавно я перенёс хостинг WordPress (теперь это сервер C — новый хостинг-провайдер) и полностью сменил регистратора доменов с Google на Gandi, тщательно воссоздав настройки DNS (@ на новом IP, www как CNAME и форум на его неизменном IP); при этом форум остался на сервере B.
Теперь WordPress сообщает, что соединение нарушено, и при попытке публикации возникает ошибка curl 6 (не удалось разрешить имя хоста; неизвестная ошибка). Также появляется сообщение «нет администратора с адресом xyz@mydomain.net», но я предполагаю, что это нормально, если соединение не установлено.
Есть ли какие-то идеи, куда стоит посмотреть? Я уже связался с новым провайдером, чтобы проверить настройки брандмауэра, но они говорят, что всё в порядке, и вероятно, стоит обратиться к разработчикам плагина.
Черт А обратное? Я не эксперт в SSO, но, насколько я понимаю, сервер B должен выполнить обратный вызов к серверу C? Если у него где-то ещё сохранён IP-адрес сервера A, это может привести к ошибке.
Мы недавно добавили инфраструктуру логирования в плагин, чтобы напрямую диагностировать подобные проблемы. Вскоре мы добавим логирование и для функционала подключения, но пока оно активно только в функционале публикации.
Проблемы с подключением в логах публикации вряд ли дадут нам какую-либо полезную информацию. Тем не менее, вы упомянули попытку публикации, поэтому сначала проверьте панель администратора «Логи» в плагине WP Discourse. Вы можете поделиться конкретной строкой из лога или отправить мне весь лог через личные сообщения. Также рекомендую сгенерировать новые учетные данные API в вашем Discourse и применить их в плагине, чтобы исключить эту причину.
Помимо этого, хотя я не хотел бы превращать это в перепалку с вашим хостинг-провайдером, невозможность выполнить cURL запрос к домену указывает на проблему окружения, а не на проблему плагина. Если вы поищете похожие ошибки здесь, то обнаружите, что @simon любезно помогает различным пользователям диагностировать проблемы, которые по сути являются проблемами окружения. Например (включая некоторые возможные инструменты диагностики) см.
Я рекомендую вам более настойчиво обратиться к вашему хостинг-провайдеру с вопросом, почему невозможно выполнить cURL запрос к домену. Если у них есть более конкретная причина полагать, что проблема в плагине WP Discourse, а не, скажем, в неверной версии cURL на сервере (что на первый взгляд более вероятно), они могут опубликовать сообщение здесь или даже написать мне в личные сообщения, и я с радостью помогу им разобраться в этом подробнее.
@jtbayly Я пробовал удалить и переустановить, но это не помогло.
@angus Возможно, вы правы. При установке плагина для тестирования TLS я получаю ошибку, которая указывает на то, что обновление curl могло бы стать решением.
Однако, учитывая ответ хостинг-провайдера по поводу обновления curl: «Версия cURL, установленная здесь, является последней официальной версией в репозитории CentOS. Именно поэтому мы используем эту версию, а не новейшую, доступную на официальном сайте разработчика.
CentOS очень осторожно подходит к выпуску новых версий в официальном репозитории, так как они проводят множество тестов программного обеспечения перед выпуском, чтобы убедиться в его стабильности во всех ситуациях. Как только новая версия будет выпущена в официальном репозитории CentOS, она будет обновлена и у нас.», я предполагаю, что дальше это не продвинется, и мне снова придётся менять хостинг-провайдера.
Прежде чем делать переключение, возможно, стоит указать им, что отсутствие поддержки TLS 1.2 вызовет проблемы с поддержкой некоторых плагинов WordPress и само по себе создает проблемы с безопасностью. Тем не менее, возможно, стоит немного глубже изучить этот вопрос.
Попробую, ведь «я не могу позволить себе не пытаться» (М. Джордан, философ ), но, похоже, их решение уже принято.
Старый хост использует версию 7.68 на Ubuntu.
А обратное? Я не эксперт в SSO, но, насколько я понимаю, сервер B должен выполнить обратный вызов к серверу C? Если у него где-то ещё сохранён IP-адрес сервера A, это может привести к ошибке.
), но, похоже, их решение уже принято.