SLES Zypper HTTP 500: Найдите неисправный репозиторий

При zypper refreshвозникновении ошибки HTTP 500 в SLES сначала определите, какой URL-адрес репозитория её вернул. Ошибка HTTP 500 означает, что сервер, обрабатывающий запрос, столкнулся с непредвиденной ситуацией; ответчиком может быть хост репозитория, сервер RMT организации или HTTP-прокси. Изолируйте неисправный репозиторий и восстановите или сообщите об этой конечной точке, прежде чем очищать локальные метаданные. Принудительная перестройка кэша не сможет восстановить сервер, который по-прежнему возвращает ошибку 500.

В текущих руководствах SUSE по администрированию и обновлению SLES 15 SP7 описаны команды для получения списка репозиториев и обновления, в том числе zypper refresh -fdbдля перестроения локальных метаданных репозитория. В них не указан текущий инцидент HTTP 500 в масштабах всей системы SLES. Практическое решение зависит от того, принадлежит ли URL-адрес центру поддержки клиентов SUSE, внутреннему зеркалу или стороннему репозиторию.

Проблема затрагивает один репозиторий или несколько?

Для начала запишите псевдоним и URL-адрес репозитория. В SLES выполните следующую команду:

zypper repos -u

Эта -uопция отображает источник каждого настроенного репозитория. Обратите внимание, какие записи включены и настроены на обновление, затем сравните имена хостов неработающих URL-адресов. Если один сторонний репозиторий выходит из строя, в то время как источники обновлений SUSE обновляются успешно, выясните, кто является владельцем этого репозитория. Если несколько репозиториев указывают на один и тот же внутренний хост, и все они выходят из строя, более вероятной причиной будет использование общего зеркала, службы RMT, обратного прокси-сервера или его вышестоящего соединения.

Далее обновите только затронутый репозиторий по псевдониму:

sudo zypper refresh -f 'Vendor-App'

Замените Vendor-Appна точный псевдоним, указанный в zypper repos -u. Это позволит избежать отображения повторяющихся ошибок из несвязанных репозиториев и предоставит вам сфокусированный результат для передачи администратору. Если псевдоним содержит пробелы, сохраните одинарные кавычки. Сохраните точный URL-адрес и метку времени сбоя, но удалите любое встроенное имя пользователя, пароль, токен или другой секретный ключ перед отправкой журналов или скриншотов.

Возвращает ли сама конечная точка метаданных HTTP-код 500?

Прочитайте полное сообщение об ошибке Zypper и определите конкретный URL-адрес метаданных, указанный в нем, часто это файл в каталоге репозитория repodata. Если к конечной точке можно обратиться без учетных данных, сравните ее HTTP-ответ от хоста SLES:

curl -sS -D - -o /dev/null --max-time 20 "$METADATA_URL"

Укажите METADATA_URLточный URL-адрес метаданных, вызывающих ошибку, без указания учетных данных в URL-адресе или командной строке. Команда выводит заголовки ответа и отбрасывает тело ответа. Результат, подобный этому, HTTP/1.1 500подтверждает, что сервер в пути запроса возвращает ошибку; он не доказывает, был ли она сгенерирована источником или посредником. Curl также может использовать другие настройки аутентификации или прокси, чем Zypper, поэтому рассматривайте это как сравнение, а не как окончательное воспроизведение. Если доступ к репозиторию требует аутентификации, используйте утвержденный вашей организацией метод тестирования, а не раскрывайте учетные данные.

Ответ с кодом 500 отличается от проблемы локального кэша метаданных. Он также отличается от сбоев DNS, ошибок сертификатов TLS, таймаутов и ответов аутентификации, таких как 401 или 403. Эти сообщения требуют других проверок. Не следует отключать проверку TLS, изменять репозиторий на обычный HTTP или многократно удалять кэши, чтобы избавиться от ошибки 500. В семантике HTTP RFC 9110 определяет 500 как непредвиденное состояние сервера, которое помешало выполнению запроса.

Где именно следует произвести ремонт?

• Репозитории SUSE Customer Center: Если сбой кажется временным, повторите попытку через короткий промежуток времени. Если та же конечная точка, размещенная на сервере SUSE, продолжает возвращать ошибку 500, запишите продукт, пакет обновлений, архитектуру, URL-адрес репозитория и время сбоя, а затем обратитесь в службу поддержки SUSE вашей организации. Подтвердите данные регистрации и подписки, если ответ указывает на проблему с правами доступа; сам по себе HTTP-код 500 не означает, что подписка недействительна.
• RMT или другое внутреннее зеркало: попросите администратора зеркала проверить журналы сервера и обратного прокси-сервера в указанное время, подтвердить, что запрошенный репозиторий включен и синхронизирован, а также проверить наличие файла метаданных по указанному пути. В документации SUSE RMT описывается как способ получения обновлений клиентами SLES с локального сервера вместо прямого обращения к SCC.
• Репозиторий стороннего поставщика: проверьте текущие инструкции по использованию репозитория и убедитесь, что URL-адрес соответствует установленной версии и архитектуре SLES. Если источник был перемещен, обновляйте его только до URL-адреса, опубликованного этим поставщиком. Отключайте репозиторий только после подтверждения того, что он является необязательным и больше не нужен; не оставляйте обязательный источник обновления SLES отключенным, чтобы скрыть ошибку.

Вы можете проверять и изменять состояние репозитория с помощью Zypper или YaST. Например, описанная в документации zypper modifyrepoкоманда может отключить репозиторий по псевдониму, но это временное решение, а не исправление неисправного необходимого источника. Избегайте редактирования сгенерированных URL-адресов репозиториев наугад, особенно после миграции пакетов обновлений, поскольку репозитории продуктов и обновлений используют пути, специфичные для каждой версии.

Когда следует перестраивать локальный кэш метаданных?

Повторную попытку подключения ко всем включенным репозиториям следует предпринимать только после того, как сервер или прокси-сервер вернет действительный ответ:

sudo zypper refresh -f

Если конечная точка теперь отвечает, но Zypper по-прежнему сообщает об устаревших или несогласованных данных локального репозитория, в разделе устранения неполадок SUSE SLES 15 SP7 рекомендуется выполнить полное обновление метаданных и перестроение базы данных с помощью следующих команд:

sudo zypper refresh -fdb

Это принудительно загружает необработанные метаданные и перестраивает локальную базу данных Zypper, в которой можно решить проблему. Это полезно при проблемах с локальными метаданными; это не решение проблемы с постоянно возникающим ответом 500. Не путайте обновление метаданных репозитория с установкой обновлений: запускайте обычную команду обновления или установки патчей только после успешного завершения обновления.

Как проверить правильность исправления?

Запустите программу zypper refresh -f 'ALIAS'для ранее неисправного источника, а затем sudo zypper refresh -fдля всех включенных репозиториев. Исправление подтверждается, когда метаданные затронутого репозитория загружаются без ошибки HTTP 500, и Zypper завершает работу без сбоев в работе включенных источников. Если один из источников по-прежнему выдает ошибку, сохраните точный URL-адрес, код состояния, заголовки ответа и время и передайте их владельцу этой конечной точки.

Официальные ссылки

• Руководство по администрированию SUSE SLES 15 SP7 — управление репозиториями и описанное в документации принудительное обновление метаданных.
• Руководство по обновлению до SUSE SLES 15 SP7 — список зарегистрированных репозиториев и их URL-адресов источников.
• Руководство по использованию инструмента зеркалирования репозиториев в SUSE SLES 15 SP7 — настройка клиентов для использования RMT.
• IETF RFC 9110: Семантика HTTP — определения кодов состояния HTTP, включая код ошибки 500 Internal Server Error.