SLESでZypperリポジトリの更新に失敗したエラー500を修正する

具体例を挙げると、 SLES管理者のMayaがsudo zypper refresh定期メンテナンス後に作業を開始したとします。あるリポジトリは「エラー500：内部サーバーエラー」を返しましたが、他のリポジトリは正常に更新されました。Mayaの例は架空のものですが、重要な診断ポイントを示しています。HTTP 500はサーバーまたはプロキシなどの仲介者からの応答であり、Zypperのローカルメタデータキャッシュが破損している証拠ではありません。

SUSE Linux Enterprise Server (SLES) で Zypper リポジトリの更新エラーを解決するには、まずエラーが発生したリポジトリと URL を特定し、次にその応答が SUSE Customer Center (SCC)、内部リポジトリミラーリングツール (RMT) サーバー、またはネットワークプロキシのいずれから来ているかを判断します。エンドポイントを確認した後でのみ、メタデータの強制更新を再試行してください。証拠がないままマシンを再登録したり、リポジトリ構成を削除したりすると、問題の診断が困難になる場合があります。

更新中にHTTP 500エラーが発生した場合、何がわかるのか

Zypperがリポジトリを更新する際、設定されたURIからリポジトリのメタデータをダウンロードします。HTTP 500応答は、そのリクエストを処理するHTTPサーバーが内部エラーを報告したことを意味します。サーバーは、リポジトリホスト、組織のミラーサーバー、またはSLESマシンとリポジトリの間にあるプロキシサーバーである可能性があります。このコードだけでは、どのサーバーが失敗したのかを特定できず、SUSEのサービスが停止していることも証明できません。

現在のSUSE管理ガイドでは、zypper refreshリポジトリの変更を取得する通常の方法として、zypper refresh -fdb更新でリポジトリのメタデータの問題が解決しない場合の推奨手順が説明されています。後者の手順では、完全な更新が強制され、生のメタデータの強制ダウンロードを含むパッケージデータベースが再構築されます。古いローカルメタデータを修復することはできますが、HTTP 500エラーを返し続けるサーバーを修復することはできません。SUSEのSLES 15 SP7管理ガイドを参照してください。

1. リポジトリを特定し、正確な障害情報を取得する

Mayaの例では、更新出力でエラーを報告する前にリポジトリのエイリアスが1つ表示されます。まず、コマンドを1回繰り返し、エイリアス、リクエストURLホスト、および他のリポジトリが正常に処理されたかどうかをメモしてください。

sudo zypper refresh

次に、リポジトリのエイリアスとその設定済みURLを一覧表示します。

zypper lr -u

更新出力で失敗したエイリアスを、このリストにあるURIと照合してください。組織のRMTまたは別のプライベートミラーでホストされているURIについては、そのサーバーの管理者に確認してください。パブリックSUSEサービスを指すURIについては、影響を受けているネットワークから確認し、可能であれば別のネットワークまたは別のSLESクライアントからも確認してください。

リポジトリのURLには、アクセス情報や署名付きクエリパラメータが含まれている場合があります。編集されていないコマンド出力、サポートバンドル、またはURLを公開フォーラムに公開しないでください。リポジトリのエイリアス、ホスト名、タイムスタンプ、SLESサービスパック、および応答コードは保持し、認証情報とトークンは編集してください。

2. エラーがローカル、共有、または上流のいずれに起因するものかを確認します。

設定を変更する前に、簡単な比較を行ってください。1台のサーバーで1つのリポジトリのみが失敗する場合は、そのリポジトリのURLとサービスを確認してください。同じネットワーク上の複数のクライアントで同じリポジトリが失敗する場合は、共有プロキシ、ファイアウォール、またはミラーを調査してください。異なるネットワーク上の多数のクライアントが同じSUSEエンドポイントで失敗する場合は、一時的な上流の問題である可能性が高くなります。これらのパターンは手がかりであり、証明ではありません。サービス所有者または組織のサポートチャネルに確認してください。

クエリを実行する権限のあるエンドポイントの場合、HTTPクライアントは応答ヘッダーと最終ステータスを表示できます。リポジトリのルートが同じ応答を返すと想定するのではなく、可能な限りリポジトリのメタデータURLを正確に使用してください。例：

curl -sS -L -D - -o /dev/null 'https://repository.example.invalid/path/to/metadata'

サンプルURLを影響を受けるエンドポイントに置き換えてください。共有するコマンドには、埋め込み認証情報やトークンを含めないでください。プロキシによって生成されたエラーページでもHTTP 500が表示される場合があるため、ネットワークポリシーで許可されている場合に限り、承認済みの直接パスまたは別のクライアントからの応答を比較してください。許可なく、必要な企業プロキシまたはセキュリティゲートウェイを迂回しないでください。

障害が発生したリポジトリがカスタムリポジトリの場合は、その管理者にサーバーログ、ストレージ容量、バックエンドの状態、およびリポジトリメタデータの公開状況を確認するよう依頼してください。URLがRMTを指している場合は、クライアントを繰り返し変更するのではなく、RMTのトラブルシューティングを行ってください。SUSEのRMTガイドでは、 RMTがSCCからリポジトリ製品データを同期し、独自のスケジュールでリポジトリパッケージをミラーリングすることが説明されています。

3. プロキシとネットワークの設定を確認する

ゲートウェイまたはプロキシは、アップストリームサービスが利用できない場合、アップストリームからの応答を処理できない場合、またはプロキシの設定が誤っている場合に、独自の500応答を返すことがあります。障害が発生しているマシンのネットワークパスを、正常に動作しているSLESホストと比較してください。オペレーティングシステムとZypperに設定されているプロキシ設定を確認し、リポジトリのホスト名が予期せずプロキシ経由で送信されているか、プロキシから除外されていないかを確認してください。

ユーザー名、パスワード、内部ホスト名を含むプロキシ設定を公開しないでください。プロキシを管理している場合は、管理者にリクエストのタイムスタンプとプロキシログを照合してもらい、500エラーがプロキシ側で発生したのか、それとも上流側で発生したのかを確認してください。直接アクセスが禁止されている場合は、承認されたプロキシパス内で調査を行ってください。

マヤの事例では、明確な分岐点が明らかになった。彼女の他のリポジトリは正常に動作しており、組織のミラーのみが複数のサーバーで失敗している。このパターンは、システム全体のSLES登録の問題ではなく、共有ミラーまたはプロキシチームに問題があることを示唆している。

4. SLES登録とリポジトリURLを確認する

SUSE登録を通じて提供されるリポジトリについては、システムの登録済み製品とモジュールを確認してください。

SUSEConnect -s
zypper lr -u

SUSEのドキュメントSUSEConnect -sでは、ローカルにインストールされている製品とそのステータスを確認したり、zypper lr -uリポジトリとそのソースURIを一覧表示したりできます。出力結果を、このマシンで使用する予定のSLESバージョンとモジュールと比較してください。URIが間違っているか古い場合、廃止されたエンドポイント、一致しないエンドポイント、または正しく構成されていないエンドポイントからエラーが返される可能性があります。

登録が完了していない場合、または必要なモジュールが登録されていない場合は、SLES のリリースとサブスクリプションに応じた製品登録手順に従ってください。SUSE の登録ガイドには、SLES の登録方法、モジュールおよび拡張機能の管理方法が記載されています。HTTP 500 エラーへの最初の対応として、本番環境のマシンを登録解除または再登録しないでください。SUSE は、登録解除によって製品のリポジトリが削除されるため、登録変更はシステム所有者と事前に計画する必要があると指摘しています。

自己管理型リポジトリの場合、設定されているベース URL がリポジトリ ベンダーの最新の指示、およびインストールされている SLES のリリースとアーキテクチャと一致していることを確認してください。サービス パック番号を変更してパスを推測しないでください。URI を修正する場合は、元の値を記録し、通常の構成管理プロセスを使用して影響を受けるリポジトリのみを変更してください。

5. エンドポイントが正常になったら、強制的にリフレッシュして再試行します。

サーバーまたはプロキシの所有者がエンドポイントが正常に応答していることを確認したら、または検証済みのURLの問題を修正したら、リポジトリの更新を再試行してください。まず、通常の更新から始めます。

sudo zypper refresh

メタデータが依然として古い、または不完全な場合は、SUSE のドキュメントに記載されている完全更新手順を使用してください。

sudo zypper refresh -fdb

これにより、Zypperは生のメタデータをダウンロードし、ローカルの解決可能データベースを再構築します。これは、リモートエンドポイントが再び正常に動作した後の復旧手順として有効です。同じHTTP 500エラーが返された場合は、コマンドの繰り返しを停止し、エンドポイント、プロキシ、またはミラーの調査に戻ってください。ローカルキャッシュの再構築では、サーバー側の障害を解消することはできません。

6. 破損したオプションリポジトリを安全に処理する

サードパーティのリポジトリが1つでも利用できないことが確認され、メンテナンスを進める必要がある場合は、リポジトリを無効にする前に、リポジトリの所有者と変更ポリシーを確認してください。Zypperでは、エイリアスを使用してリポジトリを無効にすることができます。

sudo zypper modifyrepo --disable REPOSITORY_ALIAS

から正確なエイリアスを使用しzypper lr、変更内容を文書化してください。リポジトリを無効にすると、そこからインストールされたソフトウェアの更新ができなくなる場合があります。包括的な回避策としてコア SLES 更新リポジトリを無効にしたり、エラーを抑制するためだけにリポジトリ定義を削除したりしないでください。一時的に無効にしたリポジトリは、メンテナが復旧を確認した後で再度有効にしてください。

sudo zypper modifyrepo --enable REPOSITORY_ALIAS

SLES 管理ガイドでは、リポジトリの有効化と無効化について説明zypper modifyrepoしています。リポジトリの動作と利用可能なオプションは、インストールされている Zypper のバージョンによって異なる場合があります。zypper help modifyrepoオプションの構文が異なる場合は、ホストで確認してください。

修理内容を確認してください

最後にクリーンな更新を行い、どのリポジトリが有効になっていて、更新がスケジュールされているかを確認します。

sudo zypper refresh
zypper lr -u

正常に処理された場合、以前エラーが発生していたリポジトリのメタデータ更新がHTTP 500エラーなしで完了し、想定されるリポジトリが正しいURLで有効なままになります。リポジトリを無効化した後にのみ更新が成功した場合は、それは一時的な回避策であり、修復が完了したことを意味するものではありません。そのソースからのパッケージは、今後更新を受け取れなくなる可能性があります。

Mayaの例では、ミラー管理者がサーバー側の応答を修正します。その後、Mayaは通常の更新を実行し、-fdbローカルメタデータの再構築が必要な場合にのみ、ミラーエイリアスが更新されることを確認します。この結果は診断シーケンスの一例であり、実際のテスト結果ではありません。

エスカレーションすべきタイミング

複数のクライアントが内部エンドポイントから同じ応答を受け取った場合は、ミラーまたはプロキシチームに連絡してください。ローカルネットワークパスと登録を確認した後、公式のSUSEエンドポイントに対してエラーが再現する場合は、リポジトリの所有者またはSUSEサポートに連絡してください。SLESのリリースとサービスパック、リポジトリのエイリアス、ホスト名（機密性の高いパスの詳細は伏せ字にしてください）、タイムスタンプとタイムゾーン、他のリポジトリが更新されているかどうか、HTTPステータスまたはサニタイズされたエラー抜粋を含めてください。この情報は、サービス所有者が登録コードや認証情報を公開することなく、失敗したリクエストを追跡するのに役立ちます。