Management Module

Management Module

以降で述べるManagement／Provisioning／Monitoring Moduleは、Update Moduleとは異なり、Red Hat Enterprise Linuxのサブスクリプションに追加する形でサブスクリプション契約が必要となります。

Management Moduleによって提供される主な機能を表3に示します。

多数のシステムをグループ化して単一のシステムと同様に扱える

Linuxは他のOSと比べるとリモートでのメンテナンスが比較的容易ですが、それでも10台、20台とサーバ増えてくるとエラッタの適用だけでも かなりの作業を要します。実際の事例ですが、Red Hat Enterprise Linuxのアップデート（3〜6ヶ月ごとにリリースされ、通常200ぐらいのRPMパッケージで構成）時には、更新に3日もかかっているということで す。これだけの時間がかかるのには2つ理由があります。

まず第1にシステムを1台ずつ更新しているということ、第2にRPMパッケージをダウンロードするのに時間がかかっている（ネットワークの帯域を浪 費している）ということです。前者を解決するのがManagement Moduleで、後者を解決するのはRHN Satellite Server／Proxy Serverになります。

管理者に異なる権限やグループを割り当てる

システムの数が多くなってくると、一般に管理者も複数になります。しかし、すべての管理者が同様にシステム管理の全権限を持っているという状態は、 個人情報保護法などの法令や、法令に抵触しないまでもコーポレートガバナンスという観点から考えれば、望ましいものではありません。

Management Moduleでは、すべての操作が可能なorganization administratorよりも権限が制限された管理用アカウントを作成することが可能です。例えばチャンネルの操作だけが可能なchannel administratorや、設定ファイルが含まれるConfig Channelの操作だけが可能なconfiguration administratorなどです。

また、あるアカウントにはあるグループだけを管理させることも可能です。例えば、WebサーバグループはAさん、メールサーバグループはBさん、そ れらのサーバをすべて含むLinuxサーバグループはリーダであるCさんが管理するといった具合です。この場合、AさんからはBさんが管理するメールサー バは見えませんし、その逆も同じです。

RPMパッケージやシステム情報を元にシステムを検索可能

RHNへのシステムの登録時には、パッケージプロファイル（RPMパッケージの一覧）やシステムを構成するハードウェアの情報などが、ユーザのアカ ウント情報と共に暗号化されて送信されます。これらの情報はRHN上のデータベースに登録されており、検索の対象とすることが可能です（図3）。

図3：CPUが3,000MHz（3GHz）以下のシステムを検索した結果
（画像をクリックすると別ウィンドウに拡大図を表示します）

パッケージプロファイルを比較してシステムの違いを迅速に判別

インストール時にはまったく同じRPMパッケージ構成であったシステムが、長期の運用における複数回の更新によって、差異が発生することがありま す。しかし、up2dateコマンドでRPMパッケージを更新する際、あるいはrpmコマンドでRPMパッケージの操作を行った場合でも、 「up2date -p」コマンドを発行すればRHNのデータベース上のパッケージプロファイルは更新されます。

したがって、このデータベースを対象に比較を行えばシステムの差異を判別することは容易です（図4）。

図4：2つのシステムを比較した結果、nmapパッケージは1台にしかない
（画像をクリックすると別ウィンドウに拡大図を表示します）