SLES Zypper HTTP 500: エラー発生リポジトリの特定

SLESでHTTP 500エラーが発生した場合はzypper refresh、まずどのリポジトリURLがエラーを返したかを特定してください。HTTP 500は、リクエストを処理するサーバーが予期しない状態に遭遇したことを意味します。応答元は、リポジトリホスト、組織のRMTサーバー、またはHTTPプロキシである可能性があります。ローカルメタデータをクリアする前に、障害が発生しているリポジトリを特定し、そのエンドポイントを修復または報告してください。強制キャッシュ再構築では、500エラーを返しているサーバーを修復することはできません。

SUSEの最新のSLES 15 SP7管理ガイドおよびアップグレードガイドには、リポジトリの一覧表示と更新コマンド（zypper refresh -fdbローカルリポジトリのメタデータ再構築コマンドを含む）が記載されています。しかし、SLES全体で発生しているHTTP 500エラーについては言及されていません。実際の解決策は、URLがSUSEカスタマーセンター、内部ミラー、またはサードパーティのリポジトリのいずれに属するかによって異なります。

1つのリポジトリが障害を起こしているのか、それとも複数のリポジトリが障害を起こしているのか？

まず、リポジトリのエイリアスとURLを記録します。SLESで、以下を実行します。

zypper repos -u

この-uオプションでは、設定済みの各リポジトリのオリジンが表示されます。有効化され、更新するように設定されているエントリを確認し、失敗したURLのホスト名を比較してください。SUSEの更新ソースが正常に更新される一方で、サードパーティのリポジトリが1つだけ失敗した場合は、そのリポジトリの所有者を調査してください。複数のリポジトリが同じ内部ホストを指していて、すべてが失敗した場合は、共有ミラー、RMTサービス、リバースプロキシ、またはそのアップストリーム接続に問題がある可能性が高いです。

次に、エイリアスを使用して影響を受けるリポジトリのみを更新します。

sudo zypper refresh -f 'Vendor-App'

Vendor-Appに表示されているエイリアスと完全に一致させてくださいzypper repos -u。これにより、無関係なリポジトリからのエラーが繰り返し表示されるのを防ぎ、管理者と共有できる絞り込まれた結果が得られます。エイリアスにスペースが含まれている場合は、シングルクォーテーションを残してください。ログやスクリーンショットを送信する前に、エラーが発生した正確なURLとタイムスタンプを保持し、埋め込まれたユーザー名、パスワード、トークン、その他の秘密情報を削除してください。

メタデータエンドポイント自体がHTTP 500エラーを返しますか？

Zypperのエラーメッセージ全文を読み、そこに記載されている特定のメタデータURL（多くの場合、リポジトリのrepodataディレクトリ内のファイル）を特定してください。エンドポイントに認証情報なしでクエリを実行できる場合は、SLESホストからのHTTPレスポンスと比較してください。

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 などの認証応答とも異なります。これらのメッセージには、それぞれ異なるチェックが必要です。500 を解消するために、TLS 検証を無効にしたり、リポジトリをプレーン HTTP に変更したり、キャッシュを繰り返し削除したりしないでください。HTTP のセマンティクスでは、RFC 9110 で 500 は、リクエストの処理を妨げた予期しないサーバー状態として定義されています。

修理はどこで行うべきですか？

• SUSEカスタマーセンターのリポジトリ：障害が一時的なものと思われる場合は、少し時間を置いてから再試行してください。同じSUSEホストのエンドポイントが引き続き500エラーを返す場合は、製品、サービスパック、アーキテクチャ、リポジトリのURL、および障害発生時刻を記録し、組織のSUSEサポート窓口に問い合わせてください。応答がライセンスまたはアクセスに関する問題を示している場合は、登録とサブスクリプションの詳細を確認してください。HTTP 500エラーのみでは、サブスクリプションが無効であるとは断定できません。
• RMT または別の内部ミラー:ミラー管理者に、記録された時刻のサーバーとリバースプロキシのログを検査し、要求されたリポジトリが有効になっていて同期されていることを確認し、メタデータファイルが指定されたパスに存在することを確認するよう依頼してください。SUSE では、SLES クライアントが SCC に直接接続する代わりにローカル サーバーからアップデートを取得する方法として RMT を文書化しています。
• サードパーティ製リポジトリ：ベンダーの最新のリポジトリ手順を確認し、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が有効なソースのエラーなく完了すれば、修正が成功したと判断できます。それでも1つのソースがエラーとなる場合は、正確なURL、ステータスコード、レスポンスヘッダー、および時刻を記録し、そのエンドポイントの所有者に伝えてください。

公式資料

• SUSE SLES 15 SP7 管理ガイド- リポジトリの管理と、ドキュメント化された強制メタデータ更新。
• SUSE SLES 15 SP7 アップグレードガイド- 登録済みリポジトリとそのソース URL の一覧。
• SUSE SLES 15 SP7 リポジトリミラーリングツールガイド- RMT を使用するためのクライアントの設定。
• IETF RFC 9110: HTTPセマンティクス— HTTPステータスコードの定義（500内部サーバーエラーを含む）。