ローカルSUSE RMTサーバー（SMT代替）のセットアップ方法

最新の SUSE Linux Enterprise システム用にローカル サーバーをセットアップする場合は、新しい SMT インストールではなく、リポジトリ ミラーリング ツール (RMT) を使用してください。SUSE は、SLE 15 以降、サブスクリプション管理ツール (SMT) を RMT に置き換えました。RMT は、SUSE Customer Center (SCC) から製品情報とリポジトリ情報を同期し、選択したパッケージをミラーリングし、サポートされているクライアントがローカル サーバー経由で登録できるようにします。このガイドは、2026 年 10 月 6 日に確認された SUSE Linux Enterprise Server 15 SP7 RMT のドキュメントに基づいています。コマンドとパッケージの利用可能性は他のリリースでは異なる場合があるため、デプロイするサーバー バージョンのガイドを参照してください。

RMTを使うべきか、それともSMTを使い続けるべきか？

SLES 12以降のクライアント向けに、新しいローカル登録およびアップデートサービスとしてRMTを選択してください。RMTはSLESバージョン15以降に標準搭載されており、SUSEリポジトリとカスタムリポジトリの両方をミラーリングできます。これにより、ダウンロードの繰り返しを減らし、クライアントマシンがSCCに直接接続するのを防ぐことができます。

SMTは古い環境でも引き続き利用できますが、SUSEはSLE 12をSMTの最終コードストリームとしています。RMTはSLE 11以前のクライアントをサポートしておらず、SUSEはRMTが完全な機能の代替となるものではないと警告しています。例えば、移行ガイドでは、ステージングリポジトリ、SMTクライアント管理、レポート機能は、同じようには引き継がれない機能として挙げられています。SLE 11を使用している環境や、SMT専用のワークフローに依存している環境の場合は、直接的な代替が可能だと考えないでください。サービスを変更する前に、移行ガイドとSUSEのサポートオプションを確認してください。

RMTは、エアギャップされたパッケージリポジトリとも異なります。標準的なRMTサーバーは、メタデータとパッケージを同期するために、SCCおよびSUSEアップデートサービスへのアウトバウンドアクセスが必要です。オフライン展開では、別途エクスポート/インポートまたはオフラインミラーリングプロセスが必要になります。

インストール前に準備すべきことは何ですか？

• サポート対象のホスト： RMTサービス用にSLES 15サーバーを用意してください。SMTからの移行の場合、SUSEは新規インストールされたSLES 15ホストの使用を推奨します。
• SCC組織の認証情報： RMTは通常のクライアント登録コードではなく、組織のミラーリング認証情報を使用します。SCCで適切な組織を選択し、「プロキシ」を開いて認証情報を確認してください。
• 安定したDNS名とTLSプラン：クライアントが使用する完全修飾ドメイン名（FQDN）を選択します（例：）rmt.example.com。クライアントネットワークから名前解決でき、HTTPS証明書の名前と一致することを確認してください。
• リポジトリストレージ:ミラーリングする製品、モジュール、バージョン、アーキテクチャのストレージサイズを指定します。SUSE では、一般的な計画ガイドとして、有効なリポジトリサイズの合計の約 1.5 倍を推奨しており、これは拡張機能を含めて SLE リリースごとに約 200 GB に相当すると述べています。実際の要件は異なるため、空き容量、特に一時領域を監視してください/tmp。
• ネットワークアクセス: RMT ホストが、ご使用のリリースで必要とされる SUSE エンドポイントにアクセスできるようにします。SLES 15 SP7 ガイドにはscc.suse.com、ポート 80 および 443 を介してupdates.suse.com、、、およびinstaller-updates.suse.comがリストされています。RMT サービスへのクライアントアクセスを、それを必要とするネットワークに限定します。

SUSEの警告を確認せずに、RMTロールとSLESインストールサーバーロールを同じマシン上で組み合わせないでください。これら2つの構成はポート80で異なるWebサーバーを使用するため、同時に有効にするようには設計されていません。

RMTのインストールと設定方法を教えてください。

1. RMTパッケージをインストールします。

必要なリポジトリが利用可能な既存のSLES 15ホストに、サーバーパッケージをインストールし、最新のメンテナンスアップデートを適用します。

sudo zypper in rmt-server
sudo zypper patch

最小イメージやデプロイ方法によっては、パッケージセットが異なる場合があります。別のプラットフォームのコマンドをコピーするのではなく、選択したSLESリリースのインストール手順に従ってください。

2. YaST RMTの設定を実行します

設定モジュールを起動します。

sudo yast2 rmt

プロンプトが表示されたら、SCC組織のミラーリングユーザー名とパスワードを入力してください。YaSTは、MariaDBデータベースとユーザー、および証明書の共通名も要求します。共通名には、RMTサーバーのクライアント向けFQDNを使用してください。クライアントが実際に使用するその他の名前やIPアドレスを、証明書の代替名として追加してください。リストにない名前で接続するクライアントは、サービスにアクセス可能であっても、証明書の不一致を報告する可能性があります。

有効になっている場合はfirewalld、YaSTオプションを使用して必要なRMTポートを開きます。可能な場合は、アクセス範囲を適切なネットワークインターフェイスまたはゾーンに限定してください。ウィザードを完了し、概要を確認してください。SUSEによると、YaSTは必要なsystemdサービスとタイマーを有効にして起動します。

3. サーバー名、証明書、およびサービスを確認します。

クライアントネットワークから、選択した FQDN が RMT ホストに解決され、HTTPS がクライアントによって信頼された証明書を提示することを確認してください。RMT が生成した CA 証明書は に保存され/etc/rmt/ssl/rmt-ca.crt、サーバー証明書と秘密鍵は と に保存されます/etc/rmt/ssl/rmt-server.crt。/etc/rmt/ssl/rmt-server.key秘密鍵を保護し、CA 証明書はそれを信頼する必要のあるクライアントが利用できるように保管してください。登録には、サーバー証明書に表示される FQDN とまったく同じものを使用してください。

必要なリポジトリだけを選択してミラーリングするにはどうすればよいですか？

4. 製品とリポジトリのメタデータを同期する

セットアップ後、ローカルのRMTデータベースをSCCと同期します。

sudo rmt-cli sync

これは、RMT で利用可能な製品およびリポジトリ情報を更新するものであり、すべてのパッケージが既にダウンロードされていることを意味するものではありません。自動メタデータ同期は によって管理されますrmt-server-sync.timer。その状態は以下で確認できます。

systemctl status rmt-server-sync.timer

5. あなたの遺産の製品識別子を見つけてください

有効化する前に、利用可能な製品とリポジトリの一覧を表示します。

sudo rmt-cli products list --all
sudo rmt-cli repos list --all

ご自身のサーバーが報告するIDまたは製品文字列を使用してください。オンラインの例に示されているIDは、サブスクリプション、製品バージョン、アーキテクチャ、およびSCCから返されるメタデータによって利用可能性が異なるため、異なる場合があります。

6. 必要な製品を有効にする

クライアントが実際に使用する製品を有効にします。たとえば、出力に製品文字列が含まれていることを確認した後、次のコマンドを実行します。

sudo rmt-cli products enable SLES/15/x86_64

製品を有効にすると、プールリポジトリやアップデートリポジトリなど、関連するリポジトリも有効になります。システムで追加のモジュールや拡張機能を使用している場合は、それらの製品が利用可能であることを確認し、必要なものを有効にしてください。「念のため」すべての製品をミラーリングすることは避けてください。ストレージを消費し、同期時間が長くなります。

7. パッケージをミラーリングし、結果を確認する

スケジュールに頼る前に、最初のミラーリングを手動で開始して完了状況を確認し、トラブルシューティングを行ってください。

sudo rmt-cli mirror

RMT はデフォルトでミラーリングされたコンテンツを に保存します/var/lib/rmt/public/repo。利用可能なディスク容量を確認し、コマンドの出力を確認してください。毎日のミラーリングスケジュールは によって管理されますrmt-server-mirror.timer。そのステータスは次のように確認できます。

systemctl status rmt-server-mirror.timer

メタデータの同期が成功しただけでは、クライアントがアップデートをインストールできるという証明にはなりません。選択したリポジトリがミラーリングされていること、クライアントがサーバーに接続できること、そして組織に対して製品へのアクセス権が有効であることが必須条件です。

ローカルサーバーに対してクライアントを登録するにはどうすればよいですか？

8. まずは1人のクライアントでテストする

サポートされているSLESクライアントで、RMTホスト名に関連付けて登録します。SUSEはこのコマンド形式についてドキュメントを書いています。

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

例のホストを、証明書でカバーされている FQDN に置き換えてください。クライアントは通常、SCC ミラーリング認証情報を必要としません。RMT ホストが組織に代わって同期を行う際にこれらの認証情報を使用します。RMT CA のインポートにサポートが必要なシステム向けに、SUSE はrmt-client-setupサーバーからスクリプトを提供しています。証明書を受け入れる前に、最新のクライアント ガイドを確認し、証明書のフィンガープリントまたは信頼チェーンを検証してください。

インストール時にブートパラメータを使用して登録を設定することも、YaSTの製品登録モジュールを使用してローカル登録サーバーを選択することもできますregurl=https://rmt.example.com。自動インストールの場合、SUSEはAutoYaSTオプションについてドキュメントで説明しています。システムのプロビジョニング方法に合った方法を選択してください。

9. 登録とパッケージへのアクセスを確認する

クライアント側で、登録が完了し、期待どおりの製品とリポジトリが表示され、リポジトリのメタデータを更新できることを確認してください。たとえば、リポジトリ定義を検査しzypper lr、で更新しますsudo zypper refresh。次に、メンテナンス期間中にパッケージのクエリまたは更新をテストします。モジュールが見つからない場合は、クライアント側のリポジトリファイルを変更する前に、そのモジュールが有効になっていて、RMT にミラーリングされているかどうかを確認してください。

大規模なシステム群にリダイレクトする前に、代表的なクライアント1台で通常の更新パスをテストしてください。テストが成功したら、プロビジョニングプロファイル、インストールブートパラメータ、または構成管理を更新して、新規システムと再構築システムで同じRMT URLが使用されるようにしてください。

何かが故障したとき、何をチェックすべきでしょうか？

SMTから移行する場合、どのような変更点がありますか？

移行は、パッケージのアップグレードではなく、データとワークフローの変更として扱います。SUSE は、新しい SLES 15 ホストを推奨しています。ドキュメントに記載されているエクスポート/インポートプロセスは、 RMT が SCC と同期した後、SMTsmt-data-exportとrmt-data-import新しいサーバーで使用されます。ステージングされたリポジトリ設定はエクスポートされず、ミラーリング用にマークされたリポジトリのみが引き継がれ、期限切れの製品は RMT で利用できません。SMT クライアント ジョブとパッチ ステータスはエクスポートされません。これらの機能に依存していた運用プロセスを再作成し、本番クライアントをリダイレクトする前に登録レコードを検証する計画を立ててください。

サポートおよびセキュリティポリシーで許可されている場合は、移行期間中も旧サービスを維持してください。まず少数のクライアントグループを移行し、登録、リポジトリ、証明書の信頼性、および更新動作を確認してから、対象を拡大してください。レガシークライアントおよびサポート対象外のワークフローの移行先が明確になるまでは、SMTホストを廃止しないでください。

セットアップが完了したことをどのように確認しますか？

• RMTのFQDNは正しく解決され、HTTPSはクライアントが信頼する証明書を使用します。
• RMTホストは、最新のSCCメタデータを同期し、パイロットクライアントが必要とするすべての製品リポジトリをミラーリングします。
• サポートされているクライアントはローカルURLに登録し、目的の製品リポジトリを参照します。
• クライアントはリポジトリのメタデータを更新し、制御されたパッケージ操作を完了できます。
• ディスク容量、一時領域、タイマー、ログ、バックアップ、証明書の更新には、それぞれ所有者と監視計画があります。

RMTは登録とパッケージ配信を一元化しますが、サブスクリプション、製品選択、クライアントライフサイクル、証明書の信頼性、バックアップ、およびアップデートテストの管理の必要性をなくすものではありません。正確な手順とリリース固有の相違点については、SUSEのSLES 15 SP7リポジトリミラーリングツールガイド、SMTからRMTへの移行の章、RMTクライアント構成の章、およびSUSEのリポジトリミラーリングの章を参照してください。