Red Hat Subscription Management の通知およびレポートの使用

Red Hat Subscription Management 1

システム通知、インフラストラクチャーレポート、およびその他のサブスクリプション情報を表示し、対応するために。

Red Hat Subscription Management Documentation Team

October 1, 2013

概要

Red Hat のサブスクリプション管理ツールおよびアプリケーションは、システムレベルおよび組織レベルの通知およびステータスを表示し、変化するサブスクリプションのニーズに応える方法を複数提供します。本書では、複数のレポートおよび通知メカニズムと、サブスクリプションが不十分な場合や有効期限が切れた場合に修正する方法を詳しく説明します。

1. サブスクリプションステータス、通知、およびコンプライアンスの理解

IT ハードウェアは管理や明確なインベントリー管理も必要で、それらのマシンにインストールされたソフトウェアも管理と明確なインベントリー管理が必要になります。インベントリー とは、単に どの ソフトウェアが どこに インストールされており、いくつの コピーが実際に使用されているかを追跡することを意味します。
IT 管理者はますます、ソフトウェアに関して会計報告を正確に行うプレッシャーに直面しています。また、米国のサーベンス・オクスリー法のような政府による規制だけでなく、PCI-DSS (Payment Card Industry Data Security Standard) や SAS-70 などの重要な業界標準の証明書を取得するプレッシャーにも直面しています。一般に、このソフトウェア資産の会計報告は、ソフトウェアライセンス管理 と呼ばれています。これは、Red Hat のサブスクリプションモデルでは サブスクリプション管理 と呼ばれています。
サブスクリプションの効果的な管理は、企業が以下にあげる 4 つの主要目標を達成するのに役立ちます。
  • ソフトウェアが割り当てられたサブスクリプションおよび有効期限の追跡による 規制に対するコンプライアンスの確保
  • IT 監査の簡略化
  • サブスクリプションとシステムの関係を明確にすることで、より効果的なサブスクリプションの割り当て
  • コストの削減と調達の効率化。システムに対してサブスクリプションが 不十分 な場合は、規制に抵触する可能性があり、逆にサブスクリプションを 過剰 に使用していると、IT の予算に大きな影響を及ぼす恐れがあります。
サブスクリプション管理は、ご使用の IT 環境のシステムと Red Hat を通じて入手できるソフトウェア製品との間の関係を特定し、構築する手段です。
サブスクリプションは、設定されたライフサイクルに従います。
  1. アカウントは、製品 に対する サブスクリプション を購入します。これにより、Red Hat の コンテンツ配信ネットワーク (CDN)、エラータ、パッチ、アップグレード、およびサポートをご利用いただくことができます。
    サブスクリプションは、設定された時間内で使用可能であるか、または 有効 であり、ある一定の回数 (数量) を使用することができます。
  2. サーバーは、サブスクリプション管理サービスの インベントリー に追加または 登録 されます。システムが追加されると、システムに関する属性を定義する情報の一覧と、インストール済みの製品およびそのバージョンを一覧にしたプロファイルが表示されます。
  3. サブスクリプションはシステムに アタッチ し、システムが、その製品のサポートサービスおよびコンテンツを利用できるようになります。
    サブスクリプションは、管理者によって手動で割り当てられます。あるいは、システムの属性およびインストール済みの製品にとって、どのサブスクリプションが最適であるかに基づいたサブスクリプションのプロセスにより、自動アタッチされます。
  4. サブスクリプションの有効期間が終了するか、新規の製品が追加された場合は、維持管理ができるように新しいサブスクリプションをシステムにアタッチする必要があります。

1.1. サブスクリプションとシステムの関係

1.1.1. サブスクリプション、製品、システムの相互作用

システム上の製品間には、関係性、依存性、そして競合性が存在します。同様に、サブスクリプション間にも関係があり、これは、サブスクリプションに対応するソフトウェアの関係に相当します。サブスクリプションの中には、仮想ゲストを許可するもの、他のサブスクリプションを必要とするもの、他のサブスクリプションと競合するものがあります。
サブスクリプションは、インストール済みの製品、その製品間、そしてこれらの製品がインストールされているシステムとの関係を定義します。同様に、サブスクリプションは、システム間の関係のほか、環境内でのシステム間の相互作用の方法についても定義できます。これは、特に仮想環境において明らかです。仮想環境では、サブスクリプションは物理ホストおよび仮想ゲストに対して様々な関係を定義できます。しかし、システム間の相互作用には他の方法もあります。たとえば、データセンターやクラウドインフラストラクチャーなどです。サブスクリプションは、これらのメタ関係の一部になります。
このような関係を定義するのにサブスクリプションを使用すると、製品やシステムの相互作用の方法に幅広い柔軟性が追加されます。
  • 1 つの製品を 1 つのシステムに関連付けます (これは、最も一般的な関係になります)。
  • 1 つの製品を制限し、これが特定の異なる製品と同じシステムにインストールできないようにします。
  • システムを一貫性のあるサービスレベルに維持します。各サブスクリプションには、製品のサービスレベル (例: 標準またはプレミアム) に関する定義が含まれています。サブスクリプションのクライアントはまず、同じサービスレベルのサブスクリプションの割り当てを試みます (適用可能)。これは、システムのサポートレベルの一貫性を保持することが目的です。
  • 仮想マシンが、ホストからサブスクリプションを継承できます。
  • ホストが、データセンターデプロイメントにゲストを無制限に持てます。
  • 1 つの「サブスクリプション」を複数のシステムに渡って使用することを許可します。これは、Red Hat Cloud Infrastructure などで利用できます。この場合、サブスクリプションを 1 つ購入すると、Red Hat Enterprise Linux、Red Hat OpenStack、Red Hat Virtualization、および Satellite 6 の 4 つの製品をカバーできます。そして、これらの各製品には独自のサブスクリプションがあり、スタックを作成するために様々なシステムで利用できます。
  • 同じタイプのサブスクリプションをスタックまたは組み合わせて、システムを網羅します。

1.1.2. サブスクリプションの数

サブスクリプションサービスのインベントリーの一環として、サブスクリプションの追跡があります。つまり、どのサブスクリプションが購入されたかだけでなく、これらのサブスクリプションのうち利用可能な数はどれくらいかを追跡します。
初めてサブスクリプションを購入した際に、そのサブスクリプションを使用できる時間を定義します。サブスクリプションの数は、基本となるシステムの特定の要素をベースとしています。最も一般的なのは、ソケット数です (ただし、特定のサブスクリプションによっては、コア数など、ソケット数以外のものもあり得ます)。サブスクリプションによって直接カバーされるシステムまたはソフトウェアの要素は、インスタンスと呼ばれます。
たとえば、2 ソケットの Red Hat Enterprise Linux のサブスクリプションの場合は、製品が Red Hat Enterprise Linux で、属性は物理ソケットペアになります。ソケットのペアがはインスタンスです。
1 つのサブスクリプションには通常、1 つのソケット数 (または他の属性) が必要です。したがって、8 つのソケットのシステムの場合は、ソケット数をカバーするために 4 つのソケットのシステムよりもサブスクリプションの数が必要となります (これをスタッキングと呼びます)。
ただし、このような単純なアレンジメントが、すべてのサブスクリプションに適用されるわけではありません。
2013 年 10 月以降、Red Hat は、以下のようなサブスクリプション関係の導入を開始しました。
  • 1 つのサブスクリプションを使用する複数の製品 (Red Hat Cloud Infrastructure)
  • 継承可能なサブスクリプション
  • 仮想ゲストを無制限に許可するデータセンターサブスクリプション (ホストにのみ特定のサブスクリプションが必要)
また、2013 年のサブスクリプション変更により、サブスクリプションでの仮想ゲストの処理方法が変更になりました。以前は、物理システムに対するサブスクリプションと、仮想ゲストに対するサブスクリプションが別になっていました。現在のサブスクリプションモデルでは、物理システムと仮想システムの両方に同じサブスクリプションが使用されます。ただし、物理システムと仮想システムでは、使用される数量が異なります。
前述したように、物理システムでは、1 つのサブスクリプションの数は、ソケットのペアごとに使用されます。仮想ゲストは、ソケットのペアではなく 1 つのソケットとしてカウントします。つまり、仮想ゲストは基本的にサブスクリプションの数の半分になります。仮想ゲストがインベントリーに追加されると、利用可能なサブスクリプション数の合計に 2 を掛けます (インスタンスの乗数)。これにより、仮想ゲストの利用数が「半分」だけでも、サブスクリプションのカウントは整数のままで良いことになります。
ただし、一部のサブスクリプション数に 2 を掛けても、データセンターの仮想ゲストは、個々のサブスクリプションを使用しません。複数の製品に関する一部のサブスクリプション (Cloud Infrastructure) は、別のシステムにインストールされます。さらに、2013 年以前のサブスクリプションはすべて同じ環境にインストールされます。サブスクリプションの使用状況ページまたはサブスクリプション管理ツールに一覧表示された実際の数は、コントラクトで購入した数量を反映しない可能性があります。基本的な数は同じです。異なる点は、主に、全体の数を維持するか、より柔軟なサブスクリプションタイプを維持するために変更を反映しているという点です。

1.2. ステータス: 有効期限と有効範囲

サブスクリプションは、有効期間 と呼ばれる期間にのみアクティブとなります。サブスクリプションを購入すると、そのコントラクトの開始日と終了日が設定されます。
システムには、複数のサブスクリプションをアタッチすることが可能です。製品にはそれ自体のサブスクリプションが必要です。さらに、一部の製品では、完全にカバーされた状態にするために、複数のサブスクリプションが必要になる場合があります。たとえば、ソケット数が 16 のマシンでは、ソケット数に対応するため、ソケット数 4 のオペレーティングシステムのサブスクリプションを 4 つ必要とします。
自分のインストール済みソフトウェア タブには、システム全体のサブスクリプションステータスが表示されます。また、有効な製品サブスクリプションが無効になる (有効期限が切れる) 最初の日付も表示されます。
有効期限

図1 有効期限

たとえば、4 月 17 日に有効期限が切れる Load Balancer サブスクリプションがあり、その他すべての製品のサブスクリプションは 10 月 1 日まで有効な場合、証明書のステータス のサマリーでは、有効期限が最も近い 4 月 17 日を証明書の有効期限として表示します。
複数のサブスクリプションをキューでまとめることができます。たとえば、ソケット数が 4 つのシステムに、ソケット数 2 つのサブスクリプションを 2 つ使用してソケット数に対応するとします。しかし、実際のところ、このシステムには以下の 3 つのサブスクリプションがアタッチされています。
  • ソケット数が 2 つのサブスクリプション A の有効期限は、2012 年 4 月 1 日です。
  • ソケット数が 2 つのサブスクリプション B の有効期限は、2013 年 7 月 31 日です。
  • ソケット数が 2 つのサブスクリプション C の開始日は 2012 年 3 月 1 日で、有効期限は 2014 年 4 月 1 日です。
このシステムは、2013 年 7 月 31 日まで有効です。なぜなら、サブスクリプション C は、サブスクリプション A の有効期限後に置き換えられるよう、すでにキューで待機中だからです。

1.3. 様々なサブスクリプションの状態

サブスクリプション管理ツールのすべて (ローカルシステムの Red Hat Subscription Manager、オンプレミスサービスの Subscription Asset Manager、そしてホストサービスのカスタマーポータルのサブスクリプション管理) は、システムにインストール済みのあらゆる製品の有効な証明書になんらかの変更があったことを示すログおよび UI の一連のメッセージを提供します。
システムのサブスクリプションステータスは色分けされています。すべてのサブスクリプションがすべてのインストール済みの製品にアタッチされている場合は 緑色、一部の製品で、必要なサブスクリプションがすべてアタッチされていないが、更新がまだ有効な場合は 黄色、更新が無効な場合は 赤色 で表示されます。
色分けされたステータス表示

図2 色分けされたステータス表示

マシンのステータスは、コマンドラインツールでも表示されます。緑、黄、赤の色分けは、テキストのステータスメッセージではそれぞれ、subscribedpartially subscribedexpired/not subscribed と表示されます。
[root@server ~]# subscription-manager list
+-------------------------------------------+
    Installed Product Status
+-------------------------------------------+

ProductName:            Red Hat Enterprise Linux Server
Status: Not Subscribed
Expires:                                         
SerialNumber:                                    
ContractNumber:                                  
AccountNumber:

表1 ステータスのラベルとアイコン

アイコンメッセージ説明
  • 有効性
  • サブスクライブ済み
  • 十分
システム上のすべての製品には、有効なサブスクリプションがアタッチされていて、システムそのものは完全にカバーされています (コア、ソケット、または RAM の数に対し、適切なサブスクリプションがあります)。
  • 不十分
  • 一部サブスクライブ済み
一部の製品には、サブスクリプションがないか、または適切な数のサブスクリプションがアタッチされていません。更新およびサポートポリシーは、引き続き有効です。
  • 無効
  • サブスクライブなし
システムまたは製品にアタッチされたサブスクリプションはありません。更新は無効となり、サポートへの対応に影響が出る恐れがあります。

1.4. 通知およびメッセージ

ローカルシステムの Red Hat Subscription Manager の一部に、rhsmcertd プロセスがあります。このプロセスは、新規のサブスクリプションを確認するためのサブスクリプションサービスとの対話、ローカルシステムにアタッチされたサブスクリプションの有効期限の監視、必要なサブスクリプションのインストール済み製品の追跡を実行します。
rhsmcertd は、ローカルシステム上の有効期限が近いサブスクリプションまたは不十分なサブスクリプションに対して、警告を出すメカニズムを提供します。rhsmcertd は、(カスタマーポータルのサブスクリプション管理または Subscription Asset Manager などの) サブスクリプションサービスと対話することから、サブスクリプション管理アプリケーションダッシュボードにはビューもあります。これは、個々のシステムおよびインフラストラクチャー全体の総合的なステータスを示しています。
実際のところ、サブスクリプションのコンプライアンスは、システムレベルで管理されるため、Red Hat Subscription Manager のメッセージおよび通知は、システムに対応する上で非常に重要です。全体的なインフラストラクチャーの追跡、リソースプランニング、および規制または標準へのコンプライアンスに関して、カスタマーポータルのサブスクリプション管理または Subscription Asset Manager におけるハイレベルなオーバービューは、監査、購入、その他のプランニングアクティビティーにおいて非常に有用です。

1.5. コンプライアンス: 変化するサブスクリプションの状態を修正する方法

システムのサブスクリプションが不十分な場合や有効期限が切れた場合の修正方法は、システムのサブスクリプションを更新することです。更新は手動でできますが、最も効率的な管理方法は、システム上で 自動アタッチ を有効にすることです。これにより、システムのサブスクリプションステータスが変更されると、サブスクリプションは自動的にアタッチされたり、更新されたりします。
自動アタッチは、rhsmcert プロセスの一部です。rhsmcert プロセスは、(デフォルト設定で) 4時間ごとに、最新のインストール済み製品、アタッチされてアクティブな最新のサブスクリプション、サブスクリプションサービスで利用可能なサブスクリプションを確認します。自動アタッチが有効となれば、rhsmcert プロセスは自動的に最適のサブスクリプションを使用できます。
非同期の自動アタッチ操作の実行も可能です。ローカルシステムでは、Red Hat Subscription Manager ユーティリティーを使用してこれを実現できます。Subscription Asset Manager およびカスタマーポータルのサブスクリプション管理のどちらも、すべての登録済みシステムにおいて自動アタッチ操作を開始するオプションを提供します。

2. ステータスと通知の表示

2.1. Red Hat Subscription Manager: ステータスと通知

Red Hat Subscription Manager は、インストール済みの製品、(製品ごとの) サブスクリプションステータス、そして利用可能なサブスクリプションに関するシステムレベルの情報を提供します。

2.1.1. ステータス

Red Hat Subscription Manager は、システムにインストールされた製品の有効な証明書に対するあらゆる変更を示す一連のログと UI メッセージを提供します。Subscription Manager GUI では、システムのサブスクリプションステータスは色分けされています。すべてのサブスクリプションがすべてのインストール済みの製品にアタッチされている場合は 緑色、 一部の製品で、必要なサブスクリプションがすべてアタッチされていないが、更新がまだ有効な場合は 黄色、更新が無効な場合は 赤色 で表示されます。
色分けされたステータス表示

図3 色分けされたステータス表示

マシンのステータスは、コマンドラインツールでも表示されます。緑、黄、赤の色分けは、テキストのステータスメッセージではそれぞれ、subscribedpartially subscribedexpired/not subscribed と表示されます。
[root@server ~]# subscription-manager list
+-------------------------------------------+
    Installed Product Status
+-------------------------------------------+

ProductName:            Red Hat Enterprise Linux Server
Status: Not Subscribed
Expires:                                         
SerialNumber:                                    
ContractNumber:                                  
AccountNumber:

2.1.2. サブスクリプションの有効期限の通知

サブスクリプションの変更に関する警告がある時には、上部のメニューバーに燃料メーター状の小さなアイコンが表示されます。
サブスクリプション通知のアイコン

図4 サブスクリプション通知のアイコン

インストール済み製品のサブスクリプションの有効期限が近づくと、Subscription Manager デーモンは警告を発します。このメッセージは、システムに有効な証明書のない製品がある場合に表示されるメッセージに似ています。この警告は、製品に対応するサブスクリプションがアタッチされていないか、サブスクリプションの有効期限が切れた後も製品がインストールされていることを意味します。サブスクリプション通知のウィンドウにある 自分のサブスクリプションを管理 のボタンをクリックすると、Red Hat Subscription Manager GUI が開き、サブスクリプションの確認と更新ができます。
サブスクリプション警告のメッセージ

図5 サブスクリプション警告のメッセージ

2.2. ポータル: ステータスと使用状況

カスタマーポータルのサブスクリプション管理では、システムの全体的なサブスクリプションステータスを表示しますが、そのシステムで個別にインストールされた製品のサブスクリプションステータスは表示しません。
カスタマーポータルでは、ハイレベルの情報を提供します。たとえば、あるシステムのステータスの概要や、すべてのシステムの全体的なステータスなどを提供します。

2.2.1. ステータスの確認

カスタマーポータルでは、システムのサブスクリプションをすべて最新に保つことができます。システムの詳細ページには、証明書のステータス の概要があり、システムにインストールされているすべての製品に適切なサブスクリプションがアタッチされているかどうかを示しています。
サブスクリプションステータス

図6 サブスクリプションステータス

ステータスには、現在のサブスクリプションの有効期間およびサブスクリプション証明書が最後に更新された日時が表示されます。
システムサブスクリプションのステータスには、以下の色が付いています。
  • 緑色 は、すべての製品に有効なサブスクリプションがあることを意味します。
  • 黄色 は、更新は有効ですが、一部の製品にアクティブなサブスクリプションがない可能性があることを意味します。
  • 赤色 は、更新が無効であることを意味します。
システムのステータスは、システムファクト、インストール済み製品、ローカルのサブスクリプション証明書に基づき、ローカルシステムにより決定されます。この情報は、24 時間ごとに (デフォルト設定) サブスクリプションサービスと同期します。カスタマーポータルは、インストール済み製品の情報は格納せず、システム自体からの情報に依存しています。システムがオフラインでシステム情報を送信できない場合は、カスタマーポータルは不明のステータスを反映します。
不明なサブスクリプションステータス

図7 不明なサブスクリプションステータス

2.2.2. システムのサブスクリプションの表示

システムにサブスクリプションをアタッチすると、そのサブスクリプションは アタッチ済みのサブスクリプション タブに、コントラクト番号と終了日とともに表示されます。
サブスクリプションの詳細のリンク

図8 サブスクリプションの詳細のリンク

サブスクリプションの 表示 リンクをクリックすると、そのサブスクリプションに関するさらに詳しい内容が表示されます。これには、サブスクリプションが提供する製品の一覧、注文情報、その特定のサブスクリプションで使用可能なサブスクリプションの数量とタイプ、および証明書 (システムに再生成またはダウンロードして表示することが可能) が含まれます。
サブスクリプションの詳細

図9 サブスクリプションの詳細

2.2.3. サブスクリプションの使用

管理者は、サブスクリプションがインベントリー内の任意のシステムにインストールされている製品またはアーキテクチャーに一致しているかどうかにかかわらず、すべてのサブスクリプションを完全に把握している必要があります。カスタマーポータルは、若干異なる視点でサブスクリプションを確認する 3 つの方法を提供します。
  • アクティブかつアタッチ済みの全サブスクリプション (合計数)
  • カスタマーポータルのサブスクリプション管理のシステムが使用できる、利用可能なすべてのサブスクリプション
  • 特定のシステムのアーキテクチャー、ソケット数、インストール済み製品、もしくはその他の特性と一致するカスタマーポータルのサブスクリプション管理内のサブスクリプション
サブスクリプションの概要 ページには、使用状況サマリーへのリンクがあります。サブスクリプションの使用状況 ページには、RHN Classic またはカスタマーポータルのサブスクリプション管理のどちらで使用されるかに関わらず、アカウント全体で現在アクティブなサブスクリプションの 合計と、使用済みサブスクリプションの合計が表示されます。これらの数は、サブスクリプション管理サービスでサブスクリプション数が変更するたびに更新されます。
この合計は、最初にタイプ別に分けられ、続いてサブスクリプション管理サービス別にそのタイプのサブスクリプション数が表示されます。
全サブスクリプションサービスに対するサブスクリプションの合計

図10 全サブスクリプションサービスに対するサブスクリプションの合計

2.2.4. 期限が切れたサブスクリプション、および期限切れになるサブスクリプション

概要ページの上部には、サブスクリプションに関連するシンプルかつクリアな 3 つの数字が表示されています。これらは、アクティブなサブスクリプションの数、120 日以内に期限切れになるサブスクリプションの数、過去 30 日間で期限切れになった (更新可能な) サブスクリプションの数を示しています。
これらはアカウント全体の合計数です。アタッチされているサブスクリプションの数、システムの数、サブスクリプションがカスタマーポータルのサブスクリプション管理、RHN Classic またはサブスクリプション管理アプリケーションに登録されているかどうかは重要ではありません。
サブスクリプションの概要

図11 サブスクリプションの概要

任意の数字をクリックすると、該当するカテゴリのサブスクリプションインベントリーのタブが開きます。
  • アクティブなサブスクリプション をクリックすると、アクティブ タブに移動します。
  • 120 日以内に期限切れになるサブスクリプション をクリックすると、更新可能 タブに移動します。
  • 最近期限切れになったサブスクリプション をクリックすると、直近の期限切れ タブに移動します。
タブは、サブスクリプション名、コントラクト番号、開始日、終了日を表示しているため、サブスクリプションの監視と管理を容易に行うことができます。
直近の期限切れのタブ

図12 直近の期限切れのタブ

更新可能 または 直近の期限切れ タブ内の任意のサブスクリプション名をクリックすると、そのコントラクトに関する詳細ページが更新情報とともに表示されます。サブスクリプションを Red Hat から直接購入した場合は、そのページから更新可能です。ベンダーから購入した場合は、連絡先と注文情報が表示されます。
(期限切れになった) 製品の更新情報

図13 (期限切れになった) 製品の更新情報

2.3. Subscription Asset Manager: システムレベルのサブスクリプションの情報

サブスクリプション管理の最終的な目標は、管理者が、システムとそのシステムが使用するサブスクリプションとの関係を特定できるようにすることです。これは、外部から潜在的なサブスクリプションを見るローカルシステムのビューと、システムと全サブスクリプションに関するインフラストラクチャーの全体図を見る組織 (トップレベルアカウント) のビューの 2 つの異なる視点から実行することができます。
Subscription Asset Manager は、サブスクリプションおよびシステムの情報を様々な方法で伝達します。たとえば、サブスクリプションが不十分な場合や有効期限が切れそうな場合の情報を伝達しますが、これらの情報は、管理者にとって、現在のサブスクリプションを維持する上で非常に重要です。

2.3.1. ダッシュボードにおけるハイレベルの情報

Subscription Asset Manager ダッシュボードには、その組織に登録された システム の総数および全体的なサブスクリプションステータスの一覧が表示されます。
Subscription Asset Manager ダッシュボード

図14 Subscription Asset Manager ダッシュボード

サブスクリプションステータス とは、システムにインストールされている全製品のすべてのサブスクリプションステータスのことを指します。たとえば、システムに Red Hat Enterprise Linux、OpenShift、および Directory Server のすべてがインストールされている場合、このシステムには、Red Hat Enterprise Linux、OpenShift、および Directory Server のサブスクリプションがアタッチされ、最新のステータスとなっているはずです。
サブスクリプションのステータスには、3 つのカテゴリーがあります。
  • 現在のサブスクリプション とは、システムにインストールされた全製品に適切な数のサブスクリプションがあることを意味します。
  • 無効なサブスクリプション とは、システムにインストールされた製品のうち、少なくとも 1 つの製品に対応するサブスクリプションがないことを意味します。
  • サブスクリプションが不十分 な状態は、少々複雑です。これは、インストールされている製品の少なくとも 1 つにサブスクリプションがいくつかあるが、それだけでは足りないことを意味します。各サブスクリプションは、適用される属性をいくつか提示します。たとえば、あるオペレーティングシステムのサブスクリプションは、特定のコア数または特定の RAM 容量を指定することができます。仮に、システムのコア数が 4 つで、サブスクリプションが対応するコア数は 2 つと指定されている場合、このシステムに必要なサブスクリプションは 2 つになります。アタッチされているサブスクリプションが 1 つだけの場合は、このシステムの状態は 不十分 となります。

2.3.2. システム通知の表示

新しいユーザーの追加、組織の設定の編集、マニフェストのインポート、またはレポートの実行など、Subscription Asset Manager で何らかのアクションがあるたびに、システム通知が記録されます。通知には、正常な場合のメッセージとエラーメッセージの両方があります。
最新の通知は、ダッシュボード タブの 最新の通知 エリアに表示されます。
ダッシュボードの通知

図15 ダッシュボードの通知

デフォルトで表示される最新の通知件数は 5 件ですが、ギアアイコンをクリックして、表示される通知件数を 15 件または 30 件へと変更することができます。
表示される通知件数の変更

図16 表示される通知件数の変更

通知の完全一覧は、ダッシュボード の通知の 詳細 リンクをクリックするか、Subscription Asset Manager UI の右上にある通知アイコンをクリックして開くことができます。
管理メニューの通知リンク

図17 管理メニューの通知リンク

ユーザー通知 のページには各通知の時間と日付、 通知のタイプ (success または error)、 通知の詳細などが表示されます。
通知の一覧

図18 通知の一覧

個々の通知は削除できませんが、すべて削除 のリンクをクリックして、すべての通知キューをクリアにすることは可能です。

2.3.3. 個別のシステムステータスの確認

ダッシュボード は、Subscription Asset Manager 組織内の全システムの追加的なサブスクリプションステータスの数を表示します。ただし、サブスクリプションの有効期限およびインストール済みの製品など、個々のシステムの情報を見ることは可能です。
最初に、システムエントリーを開きます。
  1. トップメニューで システム タブにカーソルを移動して、すべて の項目を選択します。
  2. システムの列の左側にある検索ボックスで、特定のシステムを検索します。
  3. 左側の列でシステム名をクリックします。
サーバーリストのエントリーそのものが、赤色 (無効)、黄色 (不十分)、または緑色 (現在) のアイコンを使用して、システムの全体的なサブスクリプションステータスを表示します。
システム一覧内のステータスアイコン

図19 システム一覧内のステータスアイコン

システムページの様々な場所で、サブスクリプションステータスの詳細が表示されています。
  • 詳細 タブはステータスを表示し、(ステータスが現在の場合は) サブスクリプションの有効期限も表示します。
    ステータスの詳細

    図20 ステータスの詳細

  • サブスクリプション タブもまた、ステータスを表示し、(サブスクリプションが現在の場合は) 有効期限も表示します。さらに、サブスクリプション タブには利用可能なアタッチされたサブスクリプションの一覧があり、これによりシステムのサブスクリプションは必要に応じて再度割り当てすることが可能です。
    ステータスおよびサブスクリプションの一覧

    図21 ステータスおよびサブスクリプションの一覧

2.4. Subscription Asset Manager: 組織の使用状況レポート (テクノロジープレビュー)

重要

Subscription Asset Manager の組織向けレポートの実行は、テクノロジープレビューです。
Subscription Asset Manager の組織は、別々で分離しています。ダッシュボード などのエリアにある追加的な情報は、表示のみの組織向けです。1 つの Subscription Asset Manager サーバーに複数の組織が設定されている場合でも、1 回につき 1 つの組織のみが表示されます。
規制およびポリシーのコンプライアンスを維持するため、サブスクリプションの割り当ておよびステータスに関して、組織をまたがるビューまたはディストリビューターをまたがるビューを持つことは、役に立つだけでなく必要でさえあります。Subscription Asset Manager レポートは、複数の組織に情報を返すために設定することができます。これにより、組織にまたがるデータのコンパイルが可能となります。

2.4.1. 前提条件

強化レポーティングを使用する際には、以下のシステム要件が追加で必要になります。
  • その他すべての Subscription Asset Manager のインストールの前提条件
  • cron サービスが実行中であること
  • レポーティングデータベース用として、追加の 4 GB ディスク領域
  • レポーティングサーバーの追加パッケージ
    • Splice
    • ruby193-rubygem-splice_reports
    • spacewalk-splice-tool

2.4.2. レポーティングの設定

Subscription Asset Manager レポーティングは、追加のパッケージのインストールが必要な追加のモジュールです。
Subscription Asset Manager インスタンスがすでに設定されている場合、追加のパッケージをプルインすることができます。たとえば、yum を使用して以下を実行します。
[root@server ~]# yum install splice ruby193-rubygem-splice_reports spacewalk-splice-tool
レポーティングパッケージがインストールされると、管理メニューに追加項目ができ、レポートの作成および実行ができます。
レポートのメニュー項目

図22 レポートのメニュー項目

2.4.3. レポートフィルターの作成

Subscription Asset Manager レポートは実際は、様々な組織にデータを収集して構成するフィルターのコレクションです。
過去 24 時間に渡り、すべてのステータス、すべての組織、すべての Satellite サーバー (設定済みの場合) のサブスクリプションを確認するデフォルトのレポートが 1 つあります。
しかし、レポートの形式に関しては、さらなる柔軟性が可能です。特に、3 つの多用途の設定があります。
  • レポートの確認が必要な組織
  • 含む必要があるサブスクリプションステータス
  • 確認が必要な日付範囲。日付範囲は、特定範囲内 にステータスがあったシステムを探します。これは、必ずしもシステムの現在のステータスとは限りません。

注記

以下は、インフラストラクチャーのステータスの追跡およびコンプライアンスの監査に適したレポートの一部です。
  • 過去 24 時間で (ステータスが) 無効から不十分へと変更された全システム。
  • 今後 3 カ月以内に、サブスクリプションが無効または不十分となる (つまり、既存のサブスクリプションが期限切れとなる) 全システム。
新規のレポートフィルターを作成するには、以下を実行します。
  1. 管理メニューの レポート 項目をクリックします。
  2. 左側の列で 新規フィルター リンクをクリックします。
  3. 組織、ステータス、日付範囲、およびアクティブな状態など、レポートに必要な情報を入力します。
  4. フィルターの保存 ボタンをクリックします。

注記

Subscription Asset Manager データベース内のデータには、サブスクリプションステータスの履歴が含まれます。これにより、現在の日付だけでなく、任意の時点でのサブスクリプションを追跡するレポートの生成が可能となります。
たとえば、7 月に購入する場合、4 月から 6 月にかけて不十分または無効なシステムを検索するようレポートを設定し、購入決定に影響を与えることができます。
サブスクリプションの問題を即座に特定し、修正できるように、タイムフィルターが提供する時間枠も、過去 24 時間または 48 時間と非常に短いです。

2.4.4. レポートの実行

  1. 管理メニューの レポート 項目をクリックします。
  2. 左の列で、レポートフィルターの名前をクリックして実行します。
  3. レポートページの下部にスクロールし、レポートの実行 ボタンをクリックします。
    別の方法として、レポートの結果を Subscription Asset Manager UI にレンダリングする代わりに、CSV ファイルにエクスポートすることができます。データをエクスポートするには、レポートのエクスポート ボタンをクリックします。
    データは CSV ファイルにエクスポートされます。オプションで、システムの詳細を含む JSON ファイルにもエクスポートされます。これらのファイルは、report-YEAR-MONTH-DAY-TIMESTAMPZ.zip という名称の ZIP アーカイブに格納されます。

    注記

    暗号化エクスポート のチェックボックスを選択すると、エクスポートされた CSV および JSON ファイルが暗号化され、アクセスできるのは Red Hat サポートが使用するプライベートキーだけとなります。

2.4.5. Subscription Asset Manager レポートの結果およびデータ

ダッシュボード と同様に、Subscription Asset Manager レポートは、選択された全組織の登録された全システムのチャートを返します。
レポートの結果

図23 レポートの結果

すべてを含むシステムの一覧もあります。一覧そのものには、システムが登録されている Subscription Asset Manager または Satellite サーバー、ステータス、組織、および最新のチェックインタイムなどのサマリー情報が含まれています。
任意のシステム名をクリックすると、そのシステムの詳細なサブスクリプションデータを引き出します。詳細ページには、特定のレポート期間におけるサブスクリプションステータス変更の履歴、インストール済みの製品一覧と各製品のサブスクリプション情報、およびシステムファクト (CPU、ソケット数、RAM、およびコアなどの物理マシンおよびオペレーティングシステムの属性) が含まれます。
レポートの結果: システムの詳細

図24 レポートの結果: システムの詳細

レポートの結果がエクスポートされると、同じ情報がエクスポートファイルに保存されます。
CSV レポートの最初のページには、サマリー情報が記載されています。たとえば、組織、登録されたサブスクリプションサーバー、ホスト名、およびサブスクリプション状態などです。
_id, record, CHECK-IN TIME, STATUS, DB ID, SATELLITE SERVER, HOSTNAME, ORGANIZATION, LIFECYCLE STATE, 
{"ident"=>"072c8bdd-ca00-43d4-a000-0887c75b90c8"}, 522e0970af5d242094000002, 2013-09-09T14:23:27Z, "Current", "072c8bdd-ca00-43d4-a000-0887c75b90c8", "sam-server.example.com", "server.example.com", "ACME_Corporation", "Active",
(オプションの) JSON ファイルには、同じサマリー情報のほか、詳細ページに記載されたシステムファクトおよび製品情報の完全一覧も含まれます。
[{"_id":{"$oid":"522e0970af5d242094000002"},"_types":["MarketingProductUsage"],"instance_identifier":"072c8bdd-ca00-43d4-a000-0887c75b90c8","updated":"2013-09-09T17:46:24Z","splice_server":"sam13-dlackey-demo","name":"server.example.com","facts":{"memory_dot_memtotal":"3780964", ...

2.4.6. 強化レポーティングのログ

レポーティングのログサイズ

デフォルトにより、強化レポーティングはシステム上で最大 200 MB の追加的なログ領域を必要とします。ログ領域は、システムごとに毎月約 750 KB 増加します。

このログサイズを変更する必要がある場合は、/etc/splice/logging/basic.log のログ設定ファイルで編集できます。
同期ログ

同期ツールのすべてのエラー、メッセージ、および操作は、/var/log/splice/spacewalk_splice_tool.log の特定のツールログに記録されます。

2.5. Subscription Asset Manager: Satellite 5.6 使用状況レポート

Red Hat Satellite 5.6 には、システムインベントリー、組織と関連するサブスクリプション、エラータ、およびユーザーに関する情報をエクスポートするユーティリティー (spacewalk-reports) があります。
サブスクリプション管理は、システム、組織、およびサブスクリプションの間の関係を確立します。関係の種類やこれらの関係の説明方法は、Red Hat の新しいサブスクリプションサービスと比較すると、Satellite では少々異なります。(詳細は 『Subscriptions Concepts and Workflows』 のドキュメントを参照してください。) 新しいサブスクリプションサービスは、サブスクリプションとそれを適用するシステムとの間における直接的な関係を構築します。Satellite 5.x におけるチャンネルのコンセプトは、システムがコンテンツストリームへのアクセスを許可され、サブスクリプション全体は特定数のシステムのアクセスを許可したことを意味しましたが、サブスクリプションとシステムとの間に直接的な関連性はありませんでした。
Satellite 強化レポーティングにより、Satellite 5.6 サーバーはシステム、サブスクリプション、およびチャンネルデータを Subscription Asset Manager サーバーに同期することができます。続いて Subscription Asset Manager サーバーは、基本的なサブスクリプション情報を取得し、Red Hat サブスクリプション管理のルールを使用したレポートを生成して、Satellite のシステムとサブスクリプションとの関係を明らかにすることができます。
これにより Satellite 管理者は、Satellite のインベントリーにおけるシステムについてより詳細に知ることができ、かつ大幅に制御できるようになります。

2.5.1. Satellite 統合レポートについて

2.5.1.1. 強化レポーティングの利点
サブスクリプションは、ソケット数、RAM、CPU、およびコアなどの基本的な物理システムの属性に基づいていることが多いです。仮想システムでは、サブスクリプションはホスト/ゲストの関係のほか、継承または限定に基づくことができます。サブスクリプションは、システムにインストールされた 他の 製品にも関連付けることができます。
Satellite のレポーティングは、より限定されています。このレポーティングでは、システムおよびサブスクリプションの全体数を計算しますが、サブスクリプションとシステムを関連付けたり、システムの属性に基づいて必要なサブスクリプションを特定したりはしません。
強化レポーティングは、さらに詳細なレポートを 2 通り提供します。
  • システム属性、ホスト/ゲストの関係、およびインストール済みの製品に基づいて実際のサブスクリプションの使用状況を決定します。
  • 様々な時点におけるサブスクリプションのステータスに基づいて、サブスクリプションの使用状況の 履歴 を追跡します。

重要

Subscription Asset Manager の強化レポーティングは、Satellite 5.6 のシステムおよび組織に関するデータのみを表示します。Satellite 内のシステム、サブスクリプションの割り当て、または組織を変更、更新、または管理することはありません。
Satellite 5.6 のシステム管理およびサブスクリプション管理の両方は、Satellite 内で実行される必要があります。
Satellite レポートのように、すべての Subscription Asset Manager レポートデータは追加のデータ分析が実行できるように CSV にエクスポートできます。さらに、Subscription Asset Manager レポートは、JSON ファイルにエクスポートでき、素早く読んで解釈できるように Subscription Asset Manager UI で視覚的にレンダリングすることができます (システムレベルの詳細も含まれます) 。
2.5.1.2. サブスクリプションステータスにおける Satellite との違い
強化レポーティングは、システムに必要なサブスクリプションの計算に異なる基準のセット (チャンネルアクセスの代わりにシステムの属性) を使用することから、強化レポーティングがシステムのサブスクリプションステータスを報告する方法と、同じ情報が Satellite で報告される方法とでは、違いが出てくる可能性があります。
たとえば、Red Hat Enterprise Linux のサブスクリプションの多くは、ソケット数が 2 つのシステム用です。そうなると、ソケット数が 4 つのシステムは、すべてのソケット数に対応するためにサブスクリプションが 2 つ必要となります。そのシステムにアタッチされたサブスクリプションが 1 つだけの場合、そのシステムのステータスは不十分と Subscription Asset Manager レポートで報告されます。しかし、Satellite では、この同じシステムは、ソケット数に関係なく単一チャンネルのエンタイトルメントのみを使用します。
さらに、Satellite には 2 種類の異なるサブスクリプションがあります。1 つは、 (システムの登録が必要な) システムエンタイトルメント で、もう 1 つは (コンテンツへのアクセス、更新、およびサポートを実際に提供する) ソフトウェアチャンネルエンタイトルメント です。新しいサブスクリプションの構成 (つまり、Subscription Asset Manager) では、システムとチャンネルのエンタイトルメントは、チャンネルのエンタイトルメントに最も緊密に相互に関連のある単一の製品サブスクリプションに統合されます。
最後に、Satellite ではチャンネルのクローンが可能です。システムが、クローンされたチャンネルに登録されている場合、チャンネルのエンタイトルメントは使用されません。つまり、利用可能なエンタイトルメントプールからエンタイトルメントが減ることはありません。しかし、チャンネル情報が同期されると、クローンされたチャンネルはオリジナルの Red Hat チャンネルと関連付けられ、サブスクリプションがシステムに適切にアタッチされます (または、ステータスが無効もしくは不十分と表示されます)。
2.5.1.3. Satellite 5.6 から Subscription Asset Manager へデータを同期
スクリプトが定期的に実行され、Satellite 5.6 サーバーのデータを Subscription Asset Manager データベースに同期します。これにより Subscription Asset Manager レポートは、データにアクセス可能となります。以下に示すように、特定の Satellite 情報のみが同期されます。
  • ホスト名、ソケット数、ホスト/ゲストの関係、その他の関連する属性を含むシステム情報 (Subscription Asset Manager ではシステムファクトと呼ばれる)
  • Satellite の組織および関連するサブスクリプション
  • Satellite 管理者および組織管理者などのロールおよび管理者アカウントを含むユーザー情報
  • Satellite のクローンされたチャンネルおよび関連するオリジナルのチャンネル
同期は 2 段階で実行されます。最初に、spacewalk-splice-checkin プロセスを使用して、spacewalk-reports レポートとしてインベントリー情報が Satellite から引き出されます。続いて、情報は Subscription Asset Manager サーバーへ送信されます。デフォルトにより、この同期の手順は 4 時間ごとに実行されます。
Satellite 5.6 から Subscription Asset Manager への同期

図25 Satellite 5.6 から Subscription Asset Manager への同期

次に、Subscription Asset Manager から情報が収集されると、(通常の Subscription Asset Manager データベースとは別の) 専用のバックエンドデータベースに送信され、別のレポーティングサーバーに保存されます。この手順は 10 分ごとに実行されます。
Subscription Asset Manager からレポーティングサーバーへの同期

図26 Subscription Asset Manager からレポーティングサーバーへの同期

2 段階目の同期後に、レポーティングデータベースにデータが保存されると、取り込み済みのシステムデータを使用して強化レポートを実行できます。
2.5.1.4. Satellite 5.6 および Subscription Asset Manager のユーザー
「Satellite 5.6 から Subscription Asset Manager へデータを同期」 で述べたように、Satellite は Subscription Asset Manager に同期され、Subscription Asset Manager ユーザーとして追加されます。組織およびロールの割り当てはすべて保存されます。
Satellite 5.6 のパスワードは Subscription Asset Manager に同期されません。 Satellite ユーザーは、Satellite のユーザー名とデフォルトのパスワード (CHANGEME) でログインする必要があります。

注記

Satellite ユーザーは、Satellite サーバーに追加されると Subscription Asset Manager に追加されますが、Satellite サーバーから削除されても Subscription Asset Manager から削除されません。Satellite ユーザーが削除された場合、そのアカウントは Subscription Asset Manager 側で手動で削除しなければなりません。

2.5.2. 前提条件

強化レポーティングを使用する際には、以下のシステム要件が追加で必要になります。
  • Satellite レポーティングに特定した専用の Subscription Asset Manager インスタンス

    警告

    強化レポーティングに使用される Subscription Asset Manager インスタンスは、Satellite のレポーティングサーバーとして のみ 使用できます。システムを管理する通常の Subscription Asset Manager インスタンスとして使用することはできず、使用するとデータが失われることがあります。
  • crond サービスが実行中であること
  • レポーティングデータベースジャーナル用として、追加の 4 GB ディスク領域が利用可能であること
  • レポーティングサーバーの追加パッケージ
    • Splice
    • ruby193-rubygem-splice_reports
    • spacewalk-splice-tool

2.5.3. レポーティングの設定

  1. 追加パッケージを含む Subscription Asset Manager をインストールします。
    1. ホストシステムを登録します。--autoattach オプションを使用して、オペレーティングシステムに必要なサブスクリプションを直ちにアタッチします。
      [root@server ~]# subscription-manager register --autoattach
      Username: jsmith@example.com
      Password:
    2. 更新したコンテンツリポジトリーをシステム設定に追加するには数分かかります。
    3. [rhel-6-server-sam-rpms] リポジトリーを有効にします。
      [root@server ~]# yum-config-manager --enable rhel-6-server-sam-rpms
      Loaded plugins: product-id, refresh-packagekit
      ========================= repo: rhel-6-server-sam-rpms =========================
      [rhel-6-server-sam-rpms]
      bandwidth = 0
      base_persistdir = /var/lib/yum/repos/x86_64/6Server
      baseurl = https://cdn.redhat.com/content/dist/rhel/server/6/6Server/x86_64/subscription-asset-manager/1/os
      cache = 0
      cachedir = /var/cache/yum/x86_64/6Server/rhel-6-server-sam-rpms
      cost = 1000
      enabled = 1
      enablegroups = True
      exclude =
      failovermethod = priority
      ...
    4. yum install を使用して katello-headpin-all パッケージをインストールします。
      [root@server ~]# yum install -y katello-headpin-all splice ruby193-rubygem-splice_reports spacewalk-splice-tool
    --enhanced_reporting オプションを使用することで、ISO イメージからインストールする際にも実行できます。
    [root@server cdrom]# ./install_packages --enhanced_reporting
  2. レポーティングのデータベースは MongoDB データベースです。自動的に起動するようにシステム上で Mongo サービスを設定し、続いてサービスを起動します。
    [root@sam-server ~]# chkconfig mongod on 
    [root@sam-server ~]# service mongod start
  3. 設定スクリプトを実行し、Subscription Asset Manager サーバー、デフォルトの管理者ユーザー、および最初の組織を設定します。
    [root@server ~]# katello-configure --deployment=sam --org=Example_Org --user-name=samadmin --user-pass=secret
    Subscription Asset Manager 管理者ユーザーと Satellite 5.6 管理者ユーザーは、同一ではありません。
  4. Subscription Asset Manager マシン上で SSH キーを作成し、Satellite 5.6 マシンの認証用に使用します。
    [root@sam-server ~]# su - splice -s /bin/sh -c 'ssh-keygen -t rsa -f /var/lib/splice/id_rsa-sat -N ""'
    
    Generating public/private rsa key pair.
    Your identification has been saved in /var/lib/splice/id_rsa-sat.
    Your public key has been saved in /var/lib/splice/id_rsa-sat.pub.
    The key fingerprint is:
    78:fa:c9:68:71:a2:a7:c1:ec:35:e3:43:ce:27:b7:d8 splice@dhcp129-162.rdu.redhat.com
    
    The key's randomart image is:
    +--[ RSA 1024]----+
    |                 |
    |                 |
    |                 |
    |       .         |
    |      . S        |
    |   o  +o.        |
    |    +==+         |
    |   ..+BOo.       |
    |    o++=E.       |
    +-----------------+
  5. Satellite 5.6 マシンへ切り替えます。
  6. 必須の Satellite レポートを実行し、Subscription Asset Manager サーバーに送信できる新規ユーザーを作成します。
    [root@sat-server ~]# useradd swreport
  7. Subscription Asset Manager マシン上で作成されたキーファイルを、Satellite 5.6 マシン上の swreport ユーザー向けに authorized_keys ファイルに追加します。command= オプションにより、swreport ユーザーは、システム上で Satellite レポートのみを実行するよう限定されます。
    [root@sat-server ~]# vim /home/swreport/.ssh/authorized_keys
    	
    command="/usr/bin/spacewalk-report $SSH_ORIGINAL_COMMAND" \
    	ssh-rsa key_hash swreport@sat-server
    command ディレクティブはすべて、キーファイルの 1 つの行になければなりません。
  8. .ssh ディレクトリーおよび authorized_keys ファイルで、適切なパーミッションを設定します。
    [root@sat-server ~]# chown -R swreport:swreport /home/swreport/.ssh
    [root@sat-server ~]# chmod 700 /home/swreport/.ssh
    [root@sat-server ~]# chmod 600 /home/swreport/.ssh/authorized_keys
  9. データベースに接続できるように、swreports ユーザーを apache システムグループに追加します。
    [root@sat-server ~]# gpasswd -a swreport apache
  10. Subscription Asset Manager マシンへ戻ります。
  11. レポーティングサービスユーザー (splice) に切り替え、ユーザーが swreport キーを使用して Satellite マシンに SSH 接続できるかテストします。
    [root@sam-server ~]# su - splice -s /bin/bash
    [splice@sam-server ~]$ ssh -i /var/lib/splice/id_rsa-sat swreport@sat-server.example.com splice-export
    プロンプトが表示されたら、キーフィンガープリントを受け入れます。
  12. Satellite 5.6 サーバーを認識するように、レポーティング設定を編集します。
    [root@sam-server ~]# vim /etc/splice/checkin.conf
    
    [spacewalk]
    host=sat-server.example.com
    ssh_key_path=/var/lib/splice/id_rsa-sat
    login=swreport
  13. Subscription Asset Manager のセットアップ時に設定された Subscription Asset Manager の管理者パスワードを使用するよう、レポーティング設定を編集します。
    admin-pass=secret
  14. Subscription Asset Manager サーバー上で、Satellite 5.6 のデータを Subscription Asset Manager のデータベースに取り込むよう、同期ユーティリティーを実行します。
    [root@sam-server ~]# su - splice -s /bin/bash
    [splice@sam-server ~]$ spacewalk-splice-checkin

    注記

    初回の同期操作での実行には、長時間かかる可能性があります。
    ツールのパフォーマンスを改善するには、spacewalk-splice-tool プロセスで使用するスレッド数を設定します。使用頻度の少ないシステムでは、コア数 2 つに対してスレッド 1 つ、使用頻度の多いシステムでは、コア数 3 つに対してスレッド 1 つでなければなりません。
    以下に例を示します。
    [root@sam-server]# /etc/splice/checkin.conf
    
    num-threads=3
  15. カスタマーポータルで Satellite 5.6 マニフェストを取得します。
    1. カスタマーポータルにログインします。
    2. サブスクリプション タブを展開し、サブスクリプション管理 > サブスクリプション管理アプリケーション 項目を選択します。
    3. Satellite タブを開きます。
    4. ポータルエントリーがまだない場合は、Satellite 5.6 エントリーを作成し、必要なサブスクリプションをアタッチします。
      1. Satellite タブで Satellite の登録 リンクをクリックします。
      2. Satellite 5.6 インスタンスについて以下の必要な情報を入力します。
        • Satellite サーバーエントリーの名前
        • Satellite インスタンスのバージョンは 5.6 であること
      3. 登録 ボタンをクリックします。
      4. Satellite 5.6 サーバーの サブスクリプション タブで、追加するサブスクリプションを 利用可能なサブスクリプション エリアから選択します。
        選択した製品ごとに適切なサブスクリプション数を設定してください。数量は、子組織が利用できる、そのタイプのサブスクリプションの合計数です。
      5. 下にスクロールして、ウィンドウ下部にある アタッチ をクリックします。
        サブスクリプションをアタッチすると、自動的に子組織のマニフェストが更新されます。
    5. Satellite 5.6 サーバーのエントリーページで、マニフェストのダウンロード ボタンをクリックし、アーカイブファイルを保存します。
  16. Satellite の管理者として Subscription Asset Manager UI (https://sam-hostname/sam) にログインし、適切な Satellite 5.6 の組織に切り替えます。
  17. サブスクリプション > サブスクリプション タブを開き、マニフェストのインポート リンクをクリックします。
  18. インポートタブの中央にあるブラウズをクリックし、保存したマニフェストファイルへ移動します。
  19. アップロード ボタンをクリックします。

2.5.4. レポートの実行および結果

Subscription Asset Manager によって管理されている各組織および各状態にある各システムの情報を返すデフォルトのレポートが設定されます。
特定の情報のサブセットまたは特定期間の情報を返す追加的なレポートフィルターを作成することは可能です。これらのカスタムレポートは、使用状況およびコンプライアンスのトレンドを分析する上で非常に有用です。
しかし、レポートの形式に関しては、さらなる柔軟性が可能です。特に、3 つの多用途の設定があります。
  • レポートの確認が必要な組織
  • 含む必要があるサブスクリプションステータス
  • 確認が必要な日付範囲。日付範囲は、特定範囲内 にステータスがあったシステムを探します。これは、必ずしもシステムの現在のステータスとは限りません。

注記

Subscription Asset Manager データベース内のデータには、サブスクリプションステータスの履歴が含まれます。これにより、現在の日付だけでなく、任意の時点でのサブスクリプションを追跡するレポートの生成が可能となります。
たとえば、7 月に購入する場合、4 月から 6 月にかけて不十分または無効なシステムを検索するようレポートを設定し、購入決定に影響を与えることができます。
サブスクリプションの問題を即座に特定し、修正できるように、タイムフィルターが提供する時間枠も、過去 24 時間または 48 時間と非常に短いです。
2.5.4.1. レポートフィルターの作成
  1. 管理メニューの レポート 項目をクリックします。
  2. 左側の列で 新規フィルター リンクをクリックします。
  3. 組織、ステータス、日付範囲、およびアクティブな状態など、レポートに必要な情報を入力します。
  4. フィルターの保存 ボタンをクリックします。
2.5.4.2. レポートの実行
  1. 管理メニューの レポート 項目をクリックします。
  2. 左側の列で、レポートフィルターの名前をクリックして実行します。
  3. レポートページの下部にスクロールし、レポートの実行 ボタンをクリックします。
    別の方法として、レポートの結果を CSV ファイルにエクスポートすることができます。データをエクスポートするには、レポートのエクスポート ボタンをクリックします。
    データは CSV ファイルにエクスポートされます。オプションで、システムの詳細を含む JSON ファイルにもエクスポートされます。これらのファイルは、report-YEAR-MONTH-DAY-TIMESTAMPZ.zip という名称の ZIP アーカイブに格納されます。

    注記

    暗号化エクスポート のチェックボックスを選択すると、エクスポートされた CSV および JSON ファイルが暗号化され、アクセスできるのは Red Hat サポートが使用するプライベートキーだけとなります。
2.5.4.3. Subscription Asset Manager レポートの結果およびデータ
ダッシュボード と同様に、Subscription Asset Manager レポートは、選択された全組織の登録された全システムのチャートを返します。
レポートの結果

図27 レポートの結果

すべてを含むシステムの一覧もあります。一覧そのものには、システムが登録されている Subscription Asset Manager または Satellite サーバー、ステータス、組織、および最新のチェックインタイムなどのサマリー情報が含まれています。
任意のシステム名をクリックすると、そのシステムの詳細なサブスクリプションデータを引き出します。詳細ページには、特定のレポート期間におけるサブスクリプションステータス変更の履歴、インストール済みの製品一覧と各製品のサブスクリプション情報、およびシステムファクト (CPU、ソケット数、RAM、およびコアなどの物理マシンおよびオペレーティングシステムの属性) が含まれます。
レポートの結果: システムの詳細

図28 レポートの結果: システムの詳細

注記

Subscription Asset Manager UI で強化レポートを見ると、システムの詳細ページには最新の 250 のチェックインのみが表示されています。
レポートの結果がエクスポートされると、同じ情報がエクスポートファイルに保存されます。
CSV レポートの最初のページには、サマリー情報が記載されています。たとえば、組織、登録されたサブスクリプションサーバー、ホスト名、およびサブスクリプション状態などです。
_id, record, CHECK-IN TIME, STATUS, DB ID, SATELLITE SERVER, HOSTNAME, ORGANIZATION, LIFECYCLE STATE, 
{"ident"=>"072c8bdd-ca00-43d4-a000-0887c75b90c8"}, 522e0970af5d242094000002, 2013-09-09T14:23:27Z, "Current", "072c8bdd-ca00-43d4-a000-0887c75b90c8", "sam-server.example.com", "server.example.com", "ACME_Corporation", "Active",
(オプションの) JSON ファイルには、同じサマリー情報のほか、詳細ページに記載されたシステムファクトおよび製品情報の完全一覧も含まれます。
[{"_id":{"$oid":"522e0970af5d242094000002"},"_types":["MarketingProductUsage"],"instance_identifier":"072c8bdd-ca00-43d4-a000-0887c75b90c8","updated":"2013-09-09T17:46:24Z","splice_server":"sam13-dlackey-demo","name":"server.example.com","facts":{"memory_dot_memtotal":"3780964", ...

2.5.5. 強化レポートのトラブルシューティング

2.5.5.1. 強化レポーティングのログ
レポーティングのログサイズ

デフォルトにより、強化レポーティングはシステム上で最大 200 MB の追加的なログ領域を必要とします。ログ領域は、システムごとに毎月約 750 KB 増加します。

ログレベルを変更する必要がある場合は、/etc/splice/logging/basic.cfg のログ設定ファイルで編集できます。
同期ログ

同期ツールのエラー、メッセージ、および操作はすべて、特定のツールログで /var/log/splice/spacewalk_splice_tool.log に記録されます。

2.5.5.2. 一般的な問題
問: レポートにシステムが表示されないのはなぜですか?
問: すべてのシステムが無効としてマークされるのはなぜですか?
問: Subscription Asset Manager で、システムまたは Satellite サーバーのサブスクリプションを更新しましたが、その変更がレポートに反映されません。
問: レポート結果の Satellite 5.6 UI へのリンクが、HTTP 404 エラーを返します。
問:
レポートにシステムが表示されないのはなぜですか?
答:
最初に、特定のレポートフィルターと一致するシステムがあることを確認します。
フィルターがシステムをいくつか返さなければならないが、表示されるシステムがまだない場合、これは、レポーティングデータベースが情報を取得していないことを意味します。考えられる原因はいくつかあります。
  • Satellite サーバーから情報を取得できていない。
  • Subscription Asset Manager からレポーティングデータベースへの情報送信が適切に行われていない。
  • 情報がデータベースに適切に保存されていない。
  • Subscription Asset Manager に保存されている情報が古い。
はじめに、同期ツールのログ (/var/log/splice/spacewalk_splice_tool.log) の履歴で、同期スクリプトが実行していることを確認します。
次に、Mongo サービスが稼働しており、ポート 27017 をリッスンしていることを確認します。Mongo サービスが稼働していないと、Subscription Asset Manager サービスを起動することはできません。
[root@sam-server ~]# service mongod status
[root@sam-server ~]# telnet localhost 27017
サービスが稼働している場合は、Mongo データベースで同期エントリーを探します。以下は例となります。
[root@sam-server ~]# mongo checkin_service --eval "printjson(db.marketing_product_usage.count())"
問題が見つからない、または関連するエントリーが見つからない場合は、レポーティングデバッグスクリプトを実行します。
[root@sam-server ~]# /usr/bin/splice-debug
これにより、関連するすべての設定と、レポーティングサーバーのログファイルが収集され、/tmp ディレクトリー名 splice-debug-YYYY-MM-DD-TIME のファイル (例: /tmp/splice-debug-2013-06-14-T15-22-19) にデータをエクスポートします。
必要に応じて、このディレクトリーを zip で圧縮し、サポートチームに提出してください。
問:
すべてのシステムが無効としてマークされるのはなぜですか?
答:
マニフェストが Satellite サーバーの Subscription Asset Manager にインポートされていることを確認します。このマニフェストにより、Subscription Asset Manager は、Satellite サーバーがアタッチしたサブスクリプションを認識します。マニフェストがないと、レポーティング機能は、利用可能なサブスクリプションがないと考えます。
問:
Subscription Asset Manager で、システムまたは Satellite サーバーのサブスクリプションを更新しましたが、その変更がレポートに反映されません。
答:
同期スクリプトは 4 時間ごとに実行するため、変更が同期されていない可能性があります。次に予定されている同期まで待つか、手動でスクリプトを実行してください (終了するまで数分かかる場合があります)。
[root@sam-server ~]# su - splice -s /bin/bash
[splice@sam-server ~]$ spacewalk-splice-checkin
問:
レポート結果の Satellite 5.6 UI へのリンクが、HTTP 404 エラーを返します。
答:
Satellite 5.6 マシンで rhn-search プロセスが実行していることを確認します。
2.5.5.3. その他の既知の問題
これらは、強化レポーティングおよび Satellite で認識された他の問題の一部ですが、回避策はありません。
Satellite レポーティングと無関係の組織があること

強化レポーティングに使用される Subscription Asset Manager インスタンスに Satellite 以外の組織が追加された場合は、その組織が、同期プロセス時に Subscription Asset Manager データベースで上書きまたは削除される場合があります。

警告

強化レポーティングに使用される Subscription Asset Manager インスタンスは、Satellite のレポーティングサーバーとして のみ 使用できます。システムを管理する通常の Subscription Asset Manager インスタンスとして使用することはできず、使用するとデータが失われることがあります。

2.6. ポータル: RHN Classic とポータルの両方で使用されるサブスクリプション

システムが RHN Classic またはカスタマーポータルのサブスクリプション管理で管理されているかに関わらず、管理者はそのアカウントにアタッチされているすべてのサブスクリプションを把握している必要があります。カスタマーポータルは、アタッチ済みのサブスクリプションの合計を確認する手段を提供します。
サブスクリプションの概要 ページの上部にある サブスクリプションの使用状況 エリアには、RHN Classic またはカスタマーポータルのサブスクリプション管理のどちらで使用されるかに関わらず、アカウント全体で現在アクティブなサブスクリプションの 合計と、使用済みサブスクリプションの合計数が表示されます。これらの数は、サブスクリプションサーバー内でサブスクリプション数が変更するたびに更新されます。
全サブスクリプションサービスに対するサブスクリプションの合計

図29 全サブスクリプションサービスに対するサブスクリプションの合計

注記

RHN Classic は、レガシーシステム (Red Hat Enterprise Linux 6.0 または Red Hat Enterprise Linux 5.6 以前のリリース) に使用する目的で提供されています。Red Hat Enterprise Linux 6.1/5.7 以降のシステムでは、カスタマーポータルのサブスクリプション管理、Subscription Asset Manager、またはその他の証明書ベースのサブスクリプション管理サービスを使用することを強く推奨します。

3. 通知とステータス変更への応答

3.1. Red Hat Subscription Manager: サブスクリプションの自動アタッチと更新

サブスクリプションデーモンの rhsmcertd は、システムにアタッチされたサブスクリプションを監視し、有効期限が近づいた場合や、削除された場合に追跡します。
システムが、有効なサブスクリプションなしに製品をインストールした場合、Red Hat Subscription Manager はシステム上にインストールされた製品に対応するために最適のサブスクリプションを自動的にアタッチします。これは、概念的には、システムを登録する時にシステムを自動アタッチするのと同じプロセスです。しかし、これはすべて、管理者がスクリプトを実行することなく実施されます。このプロセスにより、動的環境においてさえも、サブスクリプションを更新した状態を維持することができます。
以下は、自動アタッチが役立ついくつかの一般的な事例です。
  • 新しい製品がインストールされた際
  • サブスクリプションの有効期限が切れた時
    サブスクリプションの期限が切れる 24 時間以内に、Subscription Manager により、サブスクリプションがシステムに自動的に再アタッチ
  • サブスクリプションが更新された時
  • サブスクリプション管理アプリケーションが、そのマニフェストに置き換えられた時
    (オリジナルのマニフェストをリフレッシュするのではなく) 新しいマニフェストがアップロードされた場合、古いマニフェストは削除されます。システムにアタッチしている古いマニフェストのサブスクリプションは、どれも自動的に削除されます。つまり、サブスクリプションのない製品が、システムには存在し得ることを意味します。システムの自動アタッチを有効にすることは、システムが新しいマニフェストのサブスクリプションを自動的に要求および適用できることを意味します。
システムの自動アタッチにより、アクティブかつ互換性のあるサブスクリプションが存在する限りは、システム内の製品がサブスクリプションなしの状態になることはありません。
自動アタッチは、システム上でデフォルトにより有効なため、サブスクリプションステータスを維持管理できます。自動アタッチは、特定のサブスクリプションサービス (カスタマーポータルまたは Subscription Asset Manager など) を通じて、無効/再度有効にすることができます。また、rhsmcertd により、自動アタッチをローカルで確認する方法も変更可能です。

3.1.1. システムの詳細設定

サブスクリプションの自動アタッチおよび更新は、システムにアタッチするサブスクリプションを選択します。これは、現在インストール済みの製品、ハードウェア、アーキテクチャーなどの各種基準に基づいて行われます。Subscription Manager が使用する詳細設定で以下の 2 つをさらに設定することが可能です。
  • サブスクリプションのサービスレベル
  • 使用するオペレーティングシステムのマイナーバージョン (X.Y)
これは自動修復で特に有用です。自動修復は、すべてのインストール済み製品と現在のサブスクリプションがアクティブとなっているように毎日実行されます。
3.1.1.1. UI での詳細設定
サービスレベルおよびオペレーティングシステムのリリースバージョンの詳細設定はどちらも、Subscription Manager の システムの設定 のダイアログボックスで行います。
  1. Subscription Manager を開きます。
  2. システム メニューを開きます。
  3. システムの設定 メニュー項目を選択します。
  4. ドロップダウンメニューから希望するサービスレベル同意書の設定を選択します。アクティブなサブスクリプションすべてに基づいて、Red Hat アカウントで利用可能なサービスレベルのみが表示されます。
  5. リリースバージョン ドロップダウンメニューでオペレーティングシステムのリリース設定を選択します。表示されるバージョンは、アカウントにアクティブなサブスクリプションがある Red Hat Enterprise Linux バージョンのみです。
  6. 設定が保存され、今後のサブスクリプションの操作に適用されます。閉じる をクリックしてダイアログを閉じます。
3.1.1.2. サービスレベルの設定について
特定のシステム上の製品のサービスレベルを認識することは、サブスクリプションの一部になります。Red Hat Subscription Manager のシステムに推奨されるサービスレベルを設定することは、Subscription Manager が、システムにサブスクリプションを自動的にアタッチするための基準の一部としてこの設定を使用することを意味します。これは、最初にサブスクリプションを適用する場合、またはサブスクリプションを自動修復する場合のいずれかに適用されます。
Red Hat のサービスレベルは、コントラクトで定義されています。製品サポートのサービスレベルの概要は、https://access.redhat.com/ja/support/offerings/production/sla に記載されています。
各サブスクリプションのサポート情報またはサービス情報は、サブスクリプションの詳細の一部になります。サブスクリプションごとに、サービスレベルおよびサービスタイプの 2 つの属性が表示されます。レベル は、ケースに対するサポートの保証の速さを定義します。タイプ は、通信方法を定義します。製品レベルのサポートでは、これは常に Web および電話となります。
サブスクリプションのサービスレベルの情報

図30 サブスクリプションのサービスレベルの情報

アカウントには複数のサポートレベルを設定できます。同じ製品に対しても可能です。特定のシステムに対するサポートレベルを設定して、適切なレベルのサポートを利用できるようにします。実稼働システムは業務に必須なシステムであるため、通常はプレミアムのサポートレベルを選択します。一方、開発用のシステムは標準レベルのサポートか、セルフサポートを選択できます。

注記

デフォルトでは、サブスクリプションおよびシステムに対して、利用可能なサポートレベルの中で最も高いレベルが選択されます。
3.1.1.3. コマンドラインを使用したサービスレベルの設定
システムの自動アタッチは、そのシステムのハードウェアとアーキテクチャー、オペレーティングシステム、そしてインストール済みの製品に基づき、最適なものを設定します。システムの自動アタッチには、サブスクリプションの選択プロセスでサービスレベルを含むというオプションがあります。たとえば、実稼働システムは、標準レベルよりも、プレミアムレベルのサブスクリプションを選択する可能性があります。
登録時またはサブスクリプションの選択時におけるサービスレベルの設定では、以下の 2 点を実行します。
  • 希望するサービスレベル (およびその他の基準) に最も一致したサブスクリプションを選択
  • システムの優先順位を指定のサービスレベルに設定

注記

登録時、サブスクリプションの選択時、または UI で優先順位が設定されると、この優先順位は、現在のサブスクリプションと、更新および自動修復されたサブスクリプションの両方に適用されます。
一般的なサービスレベルは、service-level --set コマンドを使用して設定できます。

例1 サービスレベル詳細の設定

まず、service-level コマンドを --list オプションで実行して、システムで利用可能なサービスレベルを表示します。
[root@server ~]# subscription-manager service-level --list
+-------------------------------------------+
          Available Service Levels
+-------------------------------------------+
Standard
None
Premium
Self-Support
次に、システムで希望するレベルを設定します。
[root@server ~]# subscription-manager service-level --set=self-support
Service level set to: self-support
ローカルシステムの現在の設定は、--show オプションで表示できます。
[root#server ~]# subscription-manager service-level --show
Current service level: self-support
サービスレベルの設定は、サブスクリプション動作 (システム登録や登録後のサブスクリプションのアタッチなど) の実行中に定義できます。これにより、システム設定の上書きが可能です。registerattach のコマンドでは、--servicelevel オプションで動作の詳細を設定できます。

例2 プレミアムサービスレベルでのサブスクリプションの自動アタッチ

[root#server ~]# subscription-manager attach --auto --servicelevel Premium
Service level set to: Premium
Installed Product Current Status:
ProductName:            RHEL 6 for Workstations
Status:                 Subscribed

注記

--servicelevel オプションには、--auto-attach オプション (登録用) または --auto オプション (アタッチ用) が必要です。特定のプールのアタッチや、サブスクリプションのインポートには使用できません。
3.1.1.4. コマンドラインでのサービスレベル設定の表示
システムには、利用可能なサービスレベルが複数あります。利用可能なレベルは、システムに対して、またはシステム上の製品に対して実際に有効なものではない場合があります。レベルは、サブスクリプションそのものによって決まります。
サービスレベルの情報は、service-level コマンドを使用して表示されます。これは情報コマンドです。このコマンドは、システムまたはアカウントのサービスレベルに関する現在の情報を返しますが、割り当てられたサービスレベルには一切変更を加えません。
システムの利用可能なサービスレベルを表示するには、--list オプションを使用します。利用可能なレベルを知っておくだけでも、優先順位の設定、自動アタッチ、またはサブスクリプションの購入において役に立ちます。
[root@server ~]# subscription-manager service-level --list
+-------------------------------------------+
          Available Service Levels
+-------------------------------------------+
Standard
None
Premium
デフォルトのサービスレベルの優先順位は、アカウントおよびローカルシステムに指定できます。これらの 2 つの設定は、同じものである必要はありません。
ローカルシステムの現在の設定は、--show オプションで表示できます。
[root#server ~]# subscription-manager service-level --show
Current service level: Premium
3.1.1.5. コマンドラインで希望するオペレーティングシステムのリリースバージョンの設定
IT 環境の多くは、一定のセキュリティーレベルか他の基準に合致していると認定されている必要があります。その場合、主要なアップグレードの計画と管理は注意して行う必要があります。管理者がただ yum update を実行して次のバージョンに移行できるものではありません。
リリースバージョンを指定すると、システムが、最新バージョンのリポジトリーを自動的に選択するようなことはせず、オペレーティングシステムのバージョンに関連したコンテンツリポジトリーにアクセスを制限します。
たとえば、指定したオペレーティングシステムバージョンが 6.3 の場合は、他のリポジトリーが利用可能であっても、システムにインストールされる製品およびアタッチされるサブスクリプションには、常に 6.3 のコンテンツリポジトリーが選ばれます。
その特定バージョンのパッケージ、更新、およびエラータだけがシステムに使用されます。

例3 登録時のオペレーティングシステムのリリースの設定

リリースバージョンの設定は、システムの登録時に register コマンドを --release オプションで実行することで設定できます。これによりこのリリース設定は、システム登録時に選択され自動アタッチされたサブスクリプションに適用されます。
--auto-attach オプションは、自動アタッチのサブスクリプションの選択に使用される基準の 1 つであるため、詳細設定時に必要となります。
[root#server ~]# subscription-manager register --auto-attach --release=6.4 --username=admin@example.com...

注記

リリース設定は、サービスレベルの設定とは異なり、登録時にのみ使用するか、詳細設定として設定できます。attach コマンドでは指定できません。

例4 オペレーティングシステムのリリース詳細設定

release コマンドは、アタッチされたサブスクリプションだけでなく、アカウントで利用可能な購入済みサブスクリプションに基づいて、利用可能なオペレーティングシステムのリリースを表示します。
[root#server ~]# subscription-manager release --list
+-------------------------------------------+
          Available Releases
+-------------------------------------------+
6.2
6.3
そして、--set で詳細設定を利用可能なリリースバージョンの 1 つに設定します。
[root#server ~]# subscription-manager release --set=6.3
Release version set to: 6.3
3.1.1.6. 設定の削除
コマンドラインから設定を削除するには、適切なコマンドとともに --unset を使用します。たとえば、リリースバージョンの設定を解除するには、以下を実行します。
[root#server ~]# subscription-manager release --unset
Release version set to:
UI の設定を削除または解除するには、以下を実行します。
  1. Subscription Manager を開きます。
  2. システム メニューを開きます。
  3. システムの設定 メニュー項目を選択します。
  4. 対応するドロップダウンメニューの空白の行にサービスレベルまたはリリースバージョンの値を設定します。
  5. 閉じる をクリックします。

3.1.2. 通知に対応した自動アタッチ

Subscription Manager UI を開くと (通知エリアから開いたか、通常の方法で開いたかに関わらず)、製品に有効な証明書が欠けているかどうかを示すアイコンが左上隅に表示されます。無効になった製品に適合するサブスクリプションをアタッチする最も簡単な方法は、自動アタッチ ボタンをクリックすることです。
自動アタッチボタン

図31 自動アタッチボタン

3.1.3. 登録時の自動アタッチ

register コマンドには --auto-attach というオプションがあります。このオプションを使用すれば、ワンステップでシステムをサブスクリプションサービスに登録し、そのシステムのアーキテクチャーに最適なサブスクリプションを即時にアタッチすることができます。
[root@server1 ~]# subscription-manager register --username admin-example --password secret --auto-attach

3.1.4. 登録後の自動アタッチ

attach--auto オプション (register コマンドの --auto-attach オプションに類似) は、現在インストールされている製品およびその他の基準をベースに、最適のサブスクリプションをシステムにアタッチします。
[root@server1 ~]# subscription-manager attach --auto
システムに Cluster Suite のようなアドオン製品か、または Red Hat Directory Server のような階層化製品がインストールされている場合、登録後にこれを実行すると、役立つ可能性があります。これらの製品はデフォルトでインストールされていないため、登録時の自動アタッチではマシンに適切なサブスクリプションを適用しないかもしれません。これらのインストール後に自動アタッチすると、適切なサブスクリプションのアタッチが簡単になる可能性があります。また、プール ID を探して選択する必要がないため、少し簡単になります。

3.2. ポータル: サブスクリプションの自動アタッチと更新

3.2.1. 推奨されるサービスレベルの設定

サブスクリプションの一部は、システム上の製品に対して定義されるサービスレベルです。Red Hat のサービスレベルは、コントラクトで定義されています。製造サポートサービスレベルの概要は、https://access.redhat.com/support/offerings/production/sla.html に記載されています。
サポートレベルには 3 つの基本的なレベルがあります。
  • プレミアム
  • 標準
  • なし (セルフサポート)
アカウントには複数のサポートレベルを設定できます。同じ製品に対しても可能です。ただし、IT 環境内のすべてシステムが同じ応答時間とサポートを必要とするわけではありません。たとえば、実稼働システムは業務に必須なシステムであるため、通常はプレミアムのサポートレベルを選択します。一方、開発用のシステムは標準レベルのサポートか、セルフサポートを選択できます。

注記

デフォルトでは、サブスクリプションおよびシステムに対して、利用可能なサポートレベルの中で最も高いレベルが選択されます。
システムの設定時に、推奨されるサービスレベルを割り当てることができます。サブスクリプションがシステムに自動アタッチし、推奨されるサービスレベルが利用可能な場合、その優先順位に合うサブスクリプションが使用されます (サブスクリプションを手動で選択してアタッチする場合は、サービスレベルの設定は評価および適用されません)。

注記

サービスレベルの設定は、最初に、登録時にクライアントでローカルで設定する必要があります。以下のように自動アタッチするか、後ほど設定を編集します。
[root#server ~]# subscription-manager attach --auto --servicelevel Premium
システムにサービスレベルの設定をセットすると、ポータルを通じてその設定を閲覧、編集することができます。
システムの詳細ページにサービスレベルの優先順位が設定されます。
サービスレベルの設定

図32 サービスレベルの設定

3.2.2. オペレーティングシステムのリリースバージョンの設定の表示

IT 環境の多くは、一定のセキュリティーレベルか他の基準に合致していると認定されている必要があります。その場合、主要なアップグレードの計画と管理は注意して行う必要があります。管理者がただ yum update を実行して次のバージョンに移行できるものではありません。
リリースバージョンを指定すると、システムが、最新バージョンのリポジトリーを自動的に選択するようなことはせず、オペレーティングシステムのバージョンに関連したコンテンツリポジトリーにアクセスを制限します。
たとえば、指定したオペレーティングシステムバージョンが 6.3 の場合は、他のリポジトリーが利用可能であっても、システムにインストールされる製品およびアタッチされるサブスクリプションには、常に 6.3 のコンテンツリポジトリーが選ばれます。
その特定バージョンのパッケージ、更新、およびエラータだけがシステムに使用されます。
リリースバージョンの設定は、ローカルの Red Hat Subscription Manager ツールを使用してのみセットできます。ただし、ローカルシステムにリリース設定を行った場合は、ポータル内のシステムでその設定を閲覧できます。
オペレーティングシステムのリリースバージョンの設定

図33 オペレーティングシステムのリリースバージョンの設定

3.2.3. サブスクリプションの自動アタッチ

サブスクリプションサービスは、システムにアタッチされたサブスクリプションを監視し、有効期限が近づく時を追跡します。サブスクリプションの期限が切れる 24 時間以内に、Subscription Manager により、適合する新しいサブスクリプションにシステムが自動的に再アタッチされます。 これにより、サブスクリプションステータスは緑色のままになります。
そのシステムに利用できるアクティブかつ互換性のあるサブスクリプションが存在する限りは、システムの自動アタッチにより、システム内の製品がサブスクリプションなしの状態になることはありません。
3.2.3.1. システムの自動アタッチを有効化
自動アタッチは、システムにおいてデフォルトで有効なため、サブスクリプションステータスを維持管理できます。自動アタッチを無効にして、再度有効にするには、システムの詳細ページにある 無効化/有効化 ボタンを切り替えます。
自動アタッチの切り替え

図34 自動アタッチの切り替え

3.2.3.2. すべてのシステムで自動アタッチ操作の開始
個々のシステムで自動アタッチが設定され、通常はローカル操作になります。ただし、新しいサブスクリプションセットを購入したり、新しいシステムを大量にプロビジョニングした時などに、システムで非同期の一括更新を開始することがより簡単でより有益な場合があります。
ユニット エリアの下部には、登録したすべてのシステムで自動アタッチ操作を実行するボタンがあります。これにより、利用可能なサブスクリプションが必要に応じてシステムに適用され、すべてのシステムを適切なステータス (緑色) にします。
すべてのシステムのアタッチ

図35 すべてのシステムのアタッチ

3.3. ポータル: サブスクリプションを過剰に使用している状態の解決

Red Hat はサブスクリプションのアタッチを制限しません。つまり、実際に購入した数より多くのサブスクリプションをアタッチしてしまうリスクがあります。

警告

過剰なサブスクライブは、サブスクリプションなしでシステムを実行することと同じです。
この状況は、サービス契約違反となる場合があるとともに、規制および業界標準 (Sarbanes-Oxley、PCI-DSS、SAS-70 など) に抵触する恐れもあります。これらには、IT インフラストラクチャーの全ソフトウェアに適切なライセンスが必要です。
過剰にサブスクリプションを使用している場合は、 概要 ページの 使用 エリアに、明るい黄色の警告が表示されます。使用 ページでは、サブスクリプションの数が種類別に表示され、過剰にサブスクリプションを使用している場合は明るい黄色のバーと、その種類の過剰分を示した負の数字が表示されます。
サブスクリプションの過剰な使用

図36 サブスクリプションの過剰な使用

自動修復機能はなく、Red Hat が変更すべきシステムやサブスクリプションについて憶測や規則をつくることもありません。これは完全に管理者の判断に委ねられています。合計 の値をクリックすると、登録されているシステムまたはユニットの一覧が開きます。ここで、管理者がシステムエントリーを手動で変更したり、サブスクリプションを手動でアタッチまたは削除したりできます。
システムの確認

図37 システムの確認

システムの名前をクリックすると詳細ページが表示され、そのシステムのサブスクリプションを変更できます。

注記

登録のレビュー ページを閲覧するには、組織の管理者パーミッションが必要です。そのパーミッションを持っていても、閲覧できるのはアクセス可能なシステムのみです。必ずしもアカウント内のすべてのシステムとは限りません。

3.4. Subscription Asset Manager: 自動アタッチおよび優先順位

3.4.1. システムの自動アタッチの優先順位を設定

サブスクリプションの自動アタッチおよび更新では、様々な基準を基にどのサブスクリプションをシステムにアタッチするか選択します。基準には、最新のインストール済み製品、ハードウェア、そしてアーキテクチャーが含まれます。最適なサブスクリプションを選択する上で使用される要素の大半は、システムの特性をベースとしていますが、サブスクリプションの特性を考慮に入れることも可能です。
サブスクリプションの一部は、特定のシステムにおける製品のサービスレベルを認識します。このサービスレベルは、システムにアタッチするサブスクリプションを選択する際の基準として使用することができます。
Red Hat のサービスレベルは、コントラクトで定義されています。製品サポートのサービスレベルの概要は、https://access.redhat.com/support/offerings/production/sla.html に記載されています。
アカウントでは、複数のサポートレベルを利用でき、これは同じ製品に対しても該当します。特定のシステムに対するサポートレベルは、適切なレベルのサポートが利用できるように設定可能です。実稼働システムは業務に必須なシステムであるため、通常はプレミアムのサポートレベルを選択します。一方、開発システムは標準レベルのサポートか、セルフサポートを選択します。
組織は、デフォルトのサービスレベルを設定することができます。これは、すべてのシステムがサブスクリプションを自動アタッチする際に使用するものです。必要に応じて、ローカルのシステムレベルの設定で、組織のデフォルト設定を上書きするように設定することもできます。

注記

デフォルトでは、サブスクリプションおよびシステムに対して、利用可能なサポートレベルの中で最も高いレベルが選択されます。
  1. トップメニューで システム タブにカーソルを移動して、すべて の項目を選択します。
  2. 左側の列からシステムの名前を選択します。
  3. サブスクリプション タブを開きます。
  4. 上部ボックス内の編集アイコンをクリックし、自動アタッチ設定を変更します。
  5. 適切な自動アタッチ設定を選択します。
    一覧のオプションは、組織のサブスクリプションにおける利用可能なサポートレベルに応じたものとなっています。以下は、レベルの高いものから順に表示したオプションになります。
    • 自動アタッチを有効にし、サポートレベルに対して特定のシステムレベル設定を使用します。
    • 自動アタッチを有効にし、組織に対してデフォルトのサポートレベル設定を使用します。
    • 自動アタッチを無効にし、サポートレベルの設定をシステムレベルの設定または組織に対してデフォルトに設定します。(どちらのケースにおいても、自動アタッチが無効となっているのでサポートレベルの設定は使用されません。)
  6. 保存 ボタンをクリックします。

3.4.2. 自動アタッチ操作を手動で実行する

ローカルシステムは 4 時間ごとにジョブを実行し、サブスクリプションを自動的に更新することができます。また、インストール済みの製品およびサブスクリプションのステータスに応じて、あらゆるサブスクリプションのアタッチおよび削除ができます。
システムのすべてのサブスクリプションを即座に更新するために、1 つのシステムまたは各システムで、非同期の自動アタッチ操作を実行することが可能です。
3.4.2.1. 全システムでの自動アタッチの実行
すべてのシステムのサブスクリプションを更新するには、以下を実行します。
  1. トップメニューで システム タブにカーソルを移動して、すべて の項目を選択します。
  2. システムのメインページで、すべてのシステムに利用可能なサブスクリプションを自動アタッチ ボタンをクリックします。
3.4.2.2. 1 つのシステムでの自動アタッチの実行
すべてのシステムのサブスクリプションを更新するには、以下を実行します。
  1. トップメニューで システム タブにカーソルを移動して、すべて の項目を選択します。
  2. システムの列の左側にある検索ボックスで、特定のシステムを検索します。
  3. 左側の列でシステム名をクリックします。
  4. システムの サブスクリプション タブをクリックします。
  5. サブスクリプションエリアの右上で、自動アタッチの実行 ボタンをクリックします。

4. エラータ通知の管理

4.1. ポータル: 登録したシステムのエラータ通知の管理

サブスクリプション管理の一環として、ソフトウェアの更新および新しいリリースの監視があります。利用可能な更新があるたびに (バグ修正後の新しいリリース)、通知の電子メールを管理者に送信することができます。
この通知が優れている点は、登録済み、かつアタッチされている製品用のサブスクリプションがあるシステムのみを対象として送信されることです。製品にアタッチされたサブスクリプションを持つシステムがない場合は、アカウントにサブスクリプションがあったとしても、通知は送られません。
エラータ通知は、個別のシステムではなく、ユーザーアカウント用の設定としてセットされます。そのため、エラータの更新を確認する場合は、サブスクリプション管理は固有のシステムではなくインベントリー全体を確認します。
登録している あらゆる システムに影響を及ぼす場合は、エラータ通知が送信されます。ただし、電子メールには、実際に影響を受けているシステムの一覧が記載されません。

注記

カスタマーポータルのサブスクリプション管理と RHN Classic は別々のインベントリーを持っているため、それぞれ独自のエラータ通知設定があります。エラータ通知がすでに RHN Classic に有効であっても、カスタマーポータルのサブスクリプション管理に対しても有効にする必要があります。そうしないと、カスタマーポータルのサブスクリプション管理のインベントリーで管理されるシステムに対するエラータ通知は送信されません。
ユーザーアカウントのエラータ通知を設定します。
  1. カスタマーポータルの右上隅にある、ログインユーザーの詳細を展開します。
  2. アカウント設定 リンクをクリックします。
  3. 設定のメインページで、Red Hat アカウント ボックスの中央にある アカウントの詳細 リンクをクリックします。
  4. 左側の 好みの設定 メニューにある、Errata Notifications リンクをクリックします。
  5. 更新を受け取るエラータタイプのチェックボックスを選択します。セキュリティーエラータは重大なセキュリティーの問題に関連し、バグ修正と機能強化の通知は製品への増分更新に関連します。
  6. エラータ通知を受け取る頻度を設定します。選択したすべてのタイプのエラータ通知に適用されます。
  7. 保存 ボタンをクリックします。

4.2. Red Hat Subscription Manager: ローカルシステムのパッケージプロファイルを表示

パッケージプロファイル とは、システム上にインストールされているパッケージの一覧です (サブスクリプションステータスは問いません)。システムが登録されると、rhsmcertd がシステムをポーリングしてインストール済みの製品を確認し、その情報をサブスクリプションサービスに転送します。パッケージリストは、更新、システム通知、およびエラータ通知の管理において不可欠な部分となっています。
Red Hat Subscription Manager は、インストール済みのパッケージのローカルリストを維持管理して、システムのサブスクリプションステータスを追跡します。このパッケージプロファイルには、リスト内の各パッケージに関する一般的な情報が記載されています。
  • パッケージ名
  • パッケージバージョン
  • エポック
  • 発行者
現在インストール済みのパッケージに関するそれらすべての情報は、rhsmcertd プロセスによってレギュラージョブで収集され、ユーザーログイン情報とともに登録しているサブスクリプションサービスに送信されます。
パッケージリストそのものは、システムの登録方法によって扱いが少々異なってきます。
  • ローカルの Subscription Manager を介してカスタマーポータルのサブスクリプション管理に登録済みのシステムでは、更新を確認するためにカスタマーポータルのサブスクリプション管理のホストサービスに、パッケージリストが定期的に送信されます。
    パッケージリストは、インストール済み製品 タブで、または list --installed コマンドを使用して表示できます。
  • インベントリーのエントリーが (Subscription Manager を使用せずに) カスタマーポータルで作成されたシステムでは、パッケージリストは rhsmcertd プロセスによって生成され、ユーザーログインとともにサブスクリプションサービスに送信された後、保存されます。
    パッケージリストは、システムエントリーに表示され、エラータ通知を生成する際に使用されます (通知そのものをやめることも可能ではあります)。

A. 改訂履歴

改訂履歴
改訂 1.3-7.1Tue Jul 3 2018Terry Chuang
翻訳ファイルを XML ソースバージョン 1.3-7 と同期
改訂 1.3-7April 13, 2014Ella Deon Ballard
インスタンスベースおよび仮想設定セクションの更新。
改訂 1.3-4October 1, 2013Deon Ballard
新規コンテンツおよび SAM 1.3 リリース用に再編成。

法律上の通知

Copyright © 2013 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.