Ошибка проверки интеграции с VersionOne Bugzilla

Я пытаюсь настроить инструмент интеграции VersionOne-Bugzilla (https://community.versionone.com/VersionOne_Connect/Supported_Integrations/VersionOne_Integration_for_Bugzilla_5.0_and_Above), и я столкнулся с одной проблемой при попытке настроить конфигурацию ServiceHost. На вкладке «Настройки службы Bugzilla» я не могу получить успешную проверку. Вот то, что я представляю, как выглядит мое сообщение об ошибке, и ниже это то, что я ввожу:

Ошибка проверки

URL-адрес Bugzilla: https://‹домен>:‹порт>/xmlrpc.cgi

Имя пользователя: ‹Подтвержденное имя пользователя (с правами администратора + разрешения на редактирование/просмотр ошибок)>

Пароль: ‹пароль>

Приведенный выше URL-адрес (без добавления xmlrpc) приводит меня к Bugzilla. Кстати, это не новая установка, мы использовали ее некоторое время. Я также использовал этот же формат с добавлением /rest для успешных вызовов REST API раньше. Я также проверил ручной вход в систему с этим пользователем и все в порядке. В документации пример URL-адреса показывает добавление «/rest» вместо «/xmlrpc.cgi», которое также не проверялось (с проверкой игнорирования сертификата или без нее). Только когда я загрузил последнюю версию 2 дня назад и попытался использовать обновленную версию, я увидел, что вместо нее добавляется «/xmlrpc.cgi». Увидев это в конфигурационном файле и увидев в документации, что инструмент требует настройки Bugzilla для RPC, я пошел по пути исследования и обнаружил, что мне не хватает некоторых модулей для RPC в Bugzilla. Я установил следующие четыре:

SOAP-Lite

XMLRPC-Lite

JSON-RPC

Тест-порча

Запуск checksetup.pl для Bugzilla показывает, что все 4 найдены. После этого я использовал этот инструмент здесь (https://docs.devzing.com/bugzilla-xml-rpc-client/) для проверки вызова версии, и я получил следующий результат:

Успешное возвращение Bugzilla XML-RPC

Теперь я в замешательстве. Я проверил, что пользователь может получить доступ к Bugzilla, и я установил дополнительные модули RPC + проверил, что XMLRPC-вызов Bugzilla работает, но инструмент ServiceHost по-прежнему не проходит проверку. Что я упускаю/делаю не так? Зарегистрирована ли эта попытка проверки для получения дополнительной информации? Спасибо!

Обновление: после попытки выполнить трассировку с помощью Fiddler я изменил настройки Fiddler для обработки HTTPS. Как только это было сделано, проверка прошла успешно всякий раз, когда Fiddler отслеживал трафик. Все, что меньше этих параметров, и проверка все равно не пройдет. В тот момент, когда я закрываю Fiddler и пытаюсь снова проверить, он терпит неудачу. Похоже, что есть некоторая проблема с обработкой HTTPS инструментом. Также обратите внимание, что я вернулся к использованию «/rest» в URL-адресе и «игнорировать сертификат», но сами по себе они не решили проблему, как я уже говорил ранее, что я уже пробовал их, и они не были единственным решением. Есть ли какие-то изменения, которые я могу внести в инструмент ServiceHost, чтобы он работал правильно без Fiddler?

Успех проверки


person pi905    schedule 01.05.2020    source источник


Ответы (2)


Если вы можете настроить интеграцию для работы с fiddler, используйте ее и сохраните конфигурацию. Инструмент, очевидно, неправильно обрабатывает вашу попытку подключиться к вашему экземпляру Bugzilla и дает ложные отрицательные результаты. Целью VersionOne.Servicehost.exe.config является просто XML-файл, содержащий конфигурацию, введенную в инструменте узла службы.

После настройки сохраните конфигурацию и попытайтесь запустить исполняемый файл servicehost, который считывает файл и пытается подключиться к вашему экземпляру Bugzilla. Он должен работать нормально. Следите за ошибками в файле журнала ошибок ( servicehost.log ) и в консоли. Чтобы получить подробное ведение журнала, откройте файл VersionOne.ServiceHost.exe.config, затем найдите и замените два экземпляра "‹"LogLevel>"Info" на "Debug". Вы редко будете использовать инструмент конфигурации. Если этого обходного пути недостаточно, код находится здесь

https://github.com/versionone/VersionOne.Integration.Bugzilla

Последнее замечание. ОСТЕРЕГАТЬСЯ! Сделайте резервную копию вашей рабочей конфигурации. Существуют сценарии, в которых использование инструмента servicehost после ручного взлома xml может перезаписать ваш контент.

person Mark Irvin    schedule 06.05.2020

Проблема оказалась в том, что OpenSSL устарел и его нужно было обновить с нашего старого выпуска 0.9.8 до 1.0.1+. В версии 1.0.1+ они добавили поддержку TLS v1.1 и v1.2.

Обновление прошло довольно гладко (обратите внимание, что это на Windows Server). Мне нужно было заменить 2 DLL: libeay32 и ssleay32, а также исполняемый файл openssl в папке bin Apache. Как сказал Марк Ирвин в своем ответе, убедитесь, что вы заранее создали резервную копию всего, что собираетесь изменить. Как только это было сделано, я столкнулся с одной ошибкой при попытке восстановить и запустить Apache/OpenSSL, и она заключалась в том, что мне не хватало новой требуемой DLL с новой версией OpenSSL. Как только я загрузил и установил его с сайта Microsoft, Apache снова заработал без сбоев, и теперь я могу выполнить подключение к Bugzilla в инструменте без Fiddler.

Вот причина, по которой Fiddler заставил это работать с telerik.com:

Запуск Fiddler решает такие проблемы, поскольку Fiddler по умолчанию использует только SSLv3.0 и TLSv1.0 при обмене данными с HTTPS-серверами, избегая проблем совместимости, наблюдаемых на устаревших серверах. Если на вашем компьютере установлена ​​.NET Framework v4.5, Fiddler v4 можно настроить на попытку использования TLS/1.1+, что приведет к тому же сбою подключения, что и при отсутствии Fiddler.

Чтобы решить эту проблему, либо отключите TLS/1.1+ на клиенте, либо, что еще лучше, попросите оператора сервера обновить свое программное обеспечение для поддержки стандарта TLS.

person pi905    schedule 08.05.2020