SLES 15 上で RMT を使用してローカル SUSE アップデート サーバーを構築する

新しいローカルSUSEサブスクリプションおよびアップデートサーバーを構築するには、サポートされているSLES 15ホストにRepository Mirroring Tool（RMT）をインストールし、YaSTで設定を行い、組織で使用する製品を有効にして、それらのリポジトリをミラーリングします。本番システムをサーバーに接続する前に、サーバーのHTTPS URL経由でテストクライアントを登録してください。RMTはSLES 15のSMTに代わるものであり、従来のSMTインストールは新しいデプロイメントの適切な出発点ではありません。

この設計は、1台のサーバーがSUSEカスタマーセンター（SCC）に接続し、他のSUSEシステムがローカルエンドポイント経由で登録情報とパッケージを受信する環境に適しています。外部からのダウンロード回数を減らすことができますが、サブスクリプションの権利は提供されません。有効な組織サブスクリプションとSCCミラーリング認証情報は引き続き必要です。

プラットフォームを確認し、サーバーを計画する

SLES 15 SP7 リポジトリミラーリングツールガイドによると、RMT は SLES 12 以降のクライアントをサポートしていますが、SLES 11 以前のクライアントはサポートしていません。また、RMT はステージングやレポートなどの機能において SMT とは異なります。移行はインプレースパッケージ更新ではなく、サービス変更として扱う必要があります。SUSE は、SMT から移行する場合は、新しい SLES 15 ホストに RMT をインストールすることを推奨しています。

安定した完全修飾ドメイン名 (FQDN) (例: )rmt.example.comと静的アドレスを割り当ててください。DNS が常に正しく解決され、ホストが送信ポート 80 と 443 経由で SCC および SUSE アップデート サービスにアクセスできることを確認してください。クライアントは HTTPS 経由で RMT サービスにネットワークアクセスする必要があります。クライアント URL とサーバー証明書には同じ FQDN を使用してください。

ミラーリングするリリース、アーキテクチャ、製品、リポジトリに基づいてストレージを計画します。SUSE の SP7 ガイドでは、一般的な見積もりとして、有効化されたリポジトリの合計サイズの約 1.5 倍、拡張機能を含めて SLES リリースごとに約 200 GB を示しています。これは見積もりであり、容量の保証ではありません。現在のリポジトリのサイズを確認し、拡張のための余裕を持たせてください。RMT は大きな一時ファイルも に書き込む/tmpため、ファイルシステムに十分な空き容量があることを確認してください。同じホストを SLES インストール サーバーとして構成しないでください。RMT はポート 80 で NGINX を構成しますが、インストール サーバーの役割ではそのポートで Apache を構成します。

RMTパッケージをインストールし、YaSTを設定します。

更新され登録済みのSLES 15サーバーにRMTをインストールします。

sudo zypper patch
sudo zypper in rmt-server

パッケージの変更点を確認し、インストールを完了してください。初期設定を開始します。

sudo yast2 rmt

リポジトリミラーリングに使用する SCC 組織の認証情報を入力します。これは、クライアント登録コードではなく、SUSE Customer Center の組織のプロキシ認証情報です。ウィザードで要求された MariaDB データベースとユーザーを作成します。証明書の共通名をサーバーの FQDN に設定し、クライアントが代替名として使用するその他の名前を追加します。firewalld が有効になっている場合は、必要な RMT ルールを選択し、可能な場合はサーバーの関連するネットワーク インターフェイスにスコープを設定します。ウィザードを完了すると、YaST が必要なサービスとタイマーを有効にして起動します。

YaST は RMT CA 証明書を に/etc/rmt/ssl/rmt-ca.crt、サーバー証明書と秘密鍵を に保存します/etc/rmt/ssl/。秘密鍵を保護してください。承認済みのプロセスを使用して CA の信頼を分散してください。HTTPS で応答するサーバーでも、証明書名が要求されたホスト名と一致しない場合、または CA が信頼されていない場合は、クライアント登録に失敗する可能性があります。

メタデータの同期、製品の有効化、ミラーリング

SCCからローカルカタログを更新し、利用可能な製品を確認してください。

sudo rmt-cli sync
sudo rmt-cli products list --all

出力に表示されているIDまたは製品文字列を使用して、製品を有効化してください。製品文字列はリリースやアーキテクチャによって異なるため、推測した識別子をコピーするのではなく、ご自身のサーバーの値を使用してください。

sudo rmt-cli products enable PRODUCT_STRING
sudo rmt-cli products list

製品を有効にすると、関連するリポジトリが選択されます。サポートするシステムのみを選択するようにしてください。リリースやアーキテクチャを追加するたびにストレージが消費され、同期作業が増加します。最初のパッケージのダウンロードは、以下から開始してください。

sudo rmt-cli mirror

最初のミラーリングにはかなりの時間がかかる場合があります。RMTは通常、systemdタイマーを使用してメタデータの同期とリポジトリのミラーリングをスケジュールします。両方のスケジュールがアクティブになっていることを確認してください。

systemctl status rmt-server-sync.timer
systemctl status rmt-server-mirror.timer

と を使用してrmt-cli products list、rmt-cli repos list目的のエントリが有効になっていることを確認し、最近のミラーアクティビティを表示します。リポジトリが見つからない場合は、/tmpサービスを繰り返し再起動する前に、SCC の認証情報、サブスクリプションの権限、送信接続、ディスク容量 (を含む)、およびコマンドの出力を確認してください。

テストクライアントを登録してアップデートを確認する

SLES 12以降のテストシステムでは、SUSEConnectをRMTサーバーに向けます。

sudo SUSEConnect --url https://rmt.example.com

実際のFQDNを置き換え、それが証明書に含まれていることを確認してください。クライアントがRMT CAを信頼するかどうかを尋ねてきた場合は、証明書を受け入れる前に、組織が承認したチャネルを通じて証明書を検証してください。証明書のチェックを無効にして名前の不一致を回避しないでください。次に、構成済みのリポジトリを検査し、メタデータを更新してください。

sudo zypper lr -u
sudo zypper refresh

正常に完了すると、RMT を基盤とするリポジトリが有効になり、メタデータの更新が完了していることが確認できます。サーバー上で、クライアントが に表示されていることを確認してくださいsudo rmt-cli systems list。登録が失敗した場合は、DNS とルーティング、HTTPS の到達可能性、証明書の信頼性とホスト名の一致、ファイアウォールのスコープ、および製品が有効でミラーリングされているかどうかを確認してください。共有構成を変更する前に、コマンド出力とサービスログを確認してください。

準備済みのSLES 15ホストにRMTパッケージをインストールします。

YaSTの設定を適用する前に、SCC、データベース、FQDN証明書、およびファイアウォールの設定を確認してください。

製品カタログを更新し、ミラーリング可能な製品文字列を確認してください。

リポジトリのミラーリングを開始し、サーバーのHTTPSホスト名を使用してテストクライアントを登録します。

限界を知り、必要に応じて別の道を選ぶ

RMT で提供されていない機能 (より広範なクライアント管理、レポート作成、段階的なコンテンツ ワークフローなど) が必要な場合は、SUSE Multi-Linux Manager またはサポートされている他のライフサイクル管理サービスを使用してください。SMT は、従来の SLES 11 クライアントまたは SMT 固有の動作が要件として残っている場合にのみ使用し、移行は別途テストしてください。エア ギャップ ネットワークではデータ転送ワークフローが必要です。SUSE では、リムーバブル ストレージを使用してリポジトリ データとメタデータを移動するための RMT エクスポートおよびインポート コマンドについて説明しています。RMT は、組織のサブスクリプションで利用可能な製品のみをミラーリングできます。

SLES 15 SP7 の公式ドキュメント: RMT のインストールと構成、リポジトリミラーリングツールガイド、SMT から RMT への移行。