JP2003099145A - インストーラ及びコンピュータ - Google Patents

Abstract

(57)【要約】 【課題】システム内のオープンソース・ソフトウェアの
実行状況を収集し、システム管理者が容易に実行状況の
把握を行えるようにする。 【解決手段】通常のオープンソース・ソフトウエアでは
当該ソフトウエアの機能を実現するためのロード・モジ
ュールとそれを起動するサービス起動シェルとで構成さ
れるが、本発明では、オープンソース・ソフトウエアの
実行状況を通知するための付加モジュール14と、当該付
加モジュール14及びロード・モジュール106を起動し、
通常のオープンソース・ソフトウエアの起動シェルと同
名のサービス起動モジュール12とをインストールする。
これにより、もし異なるバージョンを勝手にインストー
ルした場合には、サービス起動シェル12が上書きされ、
付加モジュール14が起動されなくなるため、実行状況が
通知されなくなり、システム管理者は問題発生を把握す
ることができるようになる。

Description

【発明の詳細な説明】

【０００１】

【発明が属する技術分野】本発明は、プログラムの実行
状況を監視するための技術に関する。

【０００２】

【従来の技術】近年、システム構築においてオープンソ
ース・ソフトウェアを用いる事例が多くなっている。こ
れは、オープンソース・ソフトウェアを用いることによ
り安価なシステム構築が可能であること、また、リナッ
クス（Linux）を代表とするＯＳ（Operating Syste
m）、アプリケーション・プログラム群の充実が理由で
あると考えられる。

【０００３】このようにオープンソース・ソフトウェア
は便利である反面、頻繁なバージョンアップ、セキュリ
ティホールへの対処、他のオープンソース・ソフトウェ
アとの整合性など、運用時における管理の負荷が大き
く、実際に活用するためには様々なノウハウが必要であ
る。また、オープンソース・ソフトウエアは、一般に販
売されているパッケージ・ソフトウエア等とは異なり入
手が容易であるため、システム内のオープンソース・ソ
フトウエアのバージョンアップのため、利用者が勝手に
インストールを行うような場合も生じ得る。

【０００４】このためシステム管理者は、例えば遠隔地
にあるシステム内のオープンソース・ソフトウエア等の
実行状況等を管理しておき、安定したシステム運用を行
う必要がある。例えばオープンソース・ソフトウェアに
関するセキュリティ情報が公表された場合、従来ではシ
ステム管理者は、（ａ）管理台帳を基に対応するオープ
ンソース・ソフトウェアのバージョンを確認するか、
（ｂ）実際にオープンソース・ソフトウェアが実行され
ているコンピュータにログインし、実行状況を確認のう
え対策を施す必要があった。

【０００５】

【発明が解決しようとする課題】しかし、従来の方法で
は、以下に示す問題点があり、正確かつ迅速な処置を実
施することが困難であった。例えば（ａ）の場合、シス
テム管理者以外がオープンソース・ソフトウェアをイン
ストールを実施した場合は、管理台帳との不整合が生
じ、適切な対応が行なえない可能性がある。また、
（ｂ）の場合、ファイアウォール（Firewall）等により
ネットワーク経由でログインできないときは、コンピュ
ータが稼働している場所に移動し、オープンソース・ソ
フトウェアの実行状態を確認する必要がある。

【０００６】従って、本発明の目的は、これらの問題解
決することであって、システム内のオープンソース・ソ
フトウェアの実行状況を収集し、システム管理者が容易
に実行状況の把握を行えるようにするための技術を提供
することである。

【０００７】

【課題を解決するための手段】通常のオープンソース・
ソフトウエアでは当該ソフトウエアの機能を実現するた
めのロード・モジュールと当該ロード・モジュールを起
動する起動モジュール（例えば実施の形態におけるサー
ビス起動シェル）とで構成されるが、本発明では、当該
オープンソース・ソフトウエアの実行状況を通知するた
めの通知モジュール（例えば実施の形態における付加モ
ジュール）と、ロードモジュールと、当該通知モジュー
ル及びロード・モジュールを起動し、通常のオープンソ
ース・ソフトウエアの起動モジュールと同名の起動モジ
ュールとをインストールする。それにより、もし利用者
が、インストールされたオープンソース・ソフトウエア
とは異なるバージョンのオープンソース・ソフトウエア
を勝手にインストールした場合には、起動モジュールが
上書きされ、通知モジュールが起動されなくなるため、
実行状況が通知されなくなって、システム管理者は問題
発生を把握することができるようになる。

【０００８】本発明の第１の態様に係るインストーラ
は、プログラムの機能を実現するためのロード・モジュ
ールと、プログラムの実行状況に関する情報を管理用コ
ンピュータに送信する通知モジュールとを起動するため
の起動モジュールを、ロード・モジュールのみを起動す
るための第２の起動モジュールに付された名称をもっ
て、指定のコンピュータの記憶装置にインストールする
ためのインストーラである。

【０００９】これによりシステム管理者は、管理対象コ
ンピュータに実行状況を通知させる仕組みを整えること
ができるようになる。

【００１０】すなわち、管理対象コンピュータでは、プ
ログラムの機能を実現するためのロード・モジュール
と、プログラムの実行状況に関する情報を管理用コンピ
ュータに送信する通知モジュールと、ロード・モジュー
ルと通知モジュールとを起動するための起動モジュール
であって、前記ロード・モジュールのみを起動するため
の第２の起動モジュールと同一の名称を有する起動モジ
ュールとを有する。

【００１１】また、ロード・モジュールと、通知モジュ
ールと、起動モジュールと、上で述べたインストーラと
が格納された記録媒体として実現される場合もある。

【００１２】なお、記録媒体は、例えばフレキシブルデ
ィスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモ
リ、ハードディスク等の記憶媒体又は記憶装置である。
また、インストーラ等はネットワークなどを介して配布
される場合もある。尚、中間的な処理結果はメモリに一
時保管される。

【００１３】

【発明の実施の形態】図１に従来の管理対象サーバ１０
０の構成を示す。従来の管理対象サーバ１００には、シ
ェル名がstart.shというサービス起動シェル１０２と、
ロードモジュール名がserviceであり且つオープンソー
ス・ソフトウエアとしての機能を実現するための１又は
複数のロードモジュール１０６を含むオープンソース・
ソフトウエア１０４とがインストールされており、サー
ビス起動シェル１０２によりオープンソース・ソフトウ
エア１０４のロードモジュール１０６が起動されてい
た。

【００１４】これに対して図２に本発明の一実施の形態
における管理対象サーバ１０の構成を示す。管理対象サ
ーバ１０には、ロードモジュール１０６のみを起動する
サービス起動シェル１０２と同じstart.shを名称とし且
つオープンソース・ソフトウエア１０４のロードモジュ
ール１０６及び付加モジュール１４の起動を行うための
サービス起動シェル１２と、メール送付モジュール１４
０と管理ＩＤファイル生成モジュール１４２とを含む付
加モジュール１４と、１又は複数のロード・モジュール
１０６を含み且つ名称がserviceであるオープンソース
・ソフトウエア１０４とがインストールされている。サ
ービス起動シェル１２により付加モジュール１４とロー
ドモジュール１０６とが起動されると、ロードモジュー
ル１０６によりオープンソース・ソフトウエア１０４の
本来の機能が達成され、また付加モジュール１４の管理
ＩＤファイル生成モジュール１４２により生成される、
オープンソース・ソフトウエア１０４の実行状況に関す
る情報がメール送付モジュール１４０により例えば定期
的に監視メールとして、管理用サーバに送信される。こ
れにより、本実施の形態における管理対象サーバ１０の
管理がシステム管理者により行われるようになる。

【００１５】すなわち図３のようなシステムが構成され
るようになる。例えばインターネットやＬＡＮ（Local
Area Network）等であるネットワーク２０には、管理対
象サーバＡ（１０ａ）、管理対象サーバＢ（１０ｂ）、
管理対象サーバＣ（１０ｃ）、及び管理用サーバ２４が
接続されている。ここでは３台しか管理対象サーバを示
していないが、これは一例であって何台であってもよ
い。管理対象サーバＡ乃至Ｃ（１０ａ乃至１０ｃ）で
は、サービス起動シェル１２が、オープンソース・ソフ
トウエア１０４の付加モジュール１４をも起動するた
め、メール送付モジュール１４０が監視メール２２を、
管理用サーバ２４に例えば定期的に送付する。管理用サ
ーバ２４は、監視メール２２を受信し、後に述べる管理
対象サーバＡ乃至Ｃの監視のための処理を実施する監視
処理部２４１と、監視メールの統計処理などを実施する
統計処理部２４３とが設けられており、管理対象サーバ
Ａ乃至Ｃのオープンソース・ソフトウエア１０４の実行
状況を監視する。必要があれば、システム管理者に警告
を出力したり、監視状況を管理用サーバ２４に接続され
た別のコンピュータの表示装置に又は管理用サーバ２４
の表示装置に表示する。

【００１６】このような管理体制の下、管理対象サーバ
１０の利用者が、例えば勝手に同じロードモジュール名
servicveである別のバージョンのオープンソース・ソフ
トウエア１０４ａをインストールした場合を図４に示
す。なお、本実施の形態のような特別なサービス起動シ
ェルではなく通常のとおりにロードモジュールのみを起
動するサービス起動シェルと、利用者が指定したバージ
ョンのロードモジュールを含むオープンソース・ソフト
ウエアとがインストールされる。上で述べたような付加
モジュール１４はインストールされない。

【００１７】そうすると、名称start.shのサービス起動
シェル１２は上書きされて、別のサービス起動シェル１
２ａがインストールされる。このサービス起動シェル１
２ａは、本実施の形態に係る付加モジュール１４の存在
を前提としていないため、付加モジュール１４は起動さ
れなくなってしまう。すなわち、図４に示したように、
サービス起動シェル１２ａは、オープンソース・ソフト
ウエア１０４ａのロードモジュール１０６ａのみを起動
するようになり、インストールされている付加モジュー
ル１４のメール送付モジュール１４０も管理ＩＤファイ
ル生成モジュール１４２も起動されなくなってしまう。
そうすると、監視メール２２は管理用サーバ２４に送信
されなくなるので、管理用サーバ２４の監視処理部２４
１及び統計処理部２４３にて、管理対象サーバ１０に異
常が発生したことを検出することができるようになる。

【００１８】次に、管理対象サーバ１０において実施さ
れる処理内容を図５及び図６を用いて説明する。最初
に、図２に示すような管理対象サーバ１０を構成するた
めに、後に詳しく述べるような処理にてサービス起動シ
ェル１２、付加モジュール１４及びオープンソース・ソ
フトウエア１０４のインストールが実施される（ステッ
プＳ１）。すなわち、サービス起動シェル１２が、本実
施の形態ではなく通常のインストールにて設定されるサ
ービス起動シェルと同じ名称で、管理対象サーバ１０の
記憶装置に格納される。また、メール送付モジュール１
４０及び管理ＩＤファイル生成モジュール１４２を含む
付加モジュール１４も管理対象サーバ１０の記憶装置に
格納される。さらに、オープンソース・ソフトウエア１
０４も記憶装置に格納される。なお、後に述べるがオー
プンソース・ソフトウエア１０４には、ロードモジュー
ル１０６だけではなく、そのソースプログラムのファイ
ルや、マニュアルやヘルプのためのドキュメント・ファ
イルなどもインストールされる場合もある。なお、一般
的に新規にインストールが実施されると、コンピュータ
の再起動を実施し、新たにインストールされたロードモ
ジュールを有効にする。ここでもコンピュータの再起動
が実施されたものとする。

【００１９】コンピュータの再起動が実施されると、サ
ービス起動シェル１２により、メール送付モジュール１
４０及び管理ＩＤファイル生成モジュール１４２を含む
付加モジュール１４とロードモジュール１０６を起動す
る（ステップＳ３）。本実施の形態では、付加モジュー
ル１４が起動されると、管理ＩＤファイル生成モジュー
ル１４２が、例えば図６のようなデータを含むファイル
を生成し、当該ファイルの内容を含む監視メール２２を
ファイル送付モジュール１４０が管理用サーバ２４に送
信する（ステップＳ５）。起動後直ぐに監視メール２２
を送信する必要は必ずしもないが、後のメール送信タイ
ミングで何らかの理由により監視メールを送信できない
状態になるかもしれないため、ここでは直ぐに送信する
ものとする。図６の例では、管理ＩＤファイル生成モジ
ュール１４２により生成されるファイルに格納される情
報には、オープンソース・ソフトウエアの名称、オープ
ンソース・ソフトウエアのバージョン、管理対象サーバ
名、管理用サーバ名、管理番号（例えばメール送信シリ
アル番号など）、稼動状態（起動／停止の別など）、監
視メール送信日時、管理対象サーバ１０のＩＰアドレス
等が含まれる。

【００２０】この付加モジュール１４による監視メール
送信の処理（ステップＳ５）を、送信タイミング毎に
（ステップＳ７）、処理終了とされるまで（ステップＳ
９）実施する。例えば一日一回監視メール２２を送信す
る。すなわち、ステップＳ７において監視メールの送信
タイミングである判断されればステップＳ５に戻り、送
信タイミングではない場合には、処理終了か否かを判断
して（ステップＳ９）、処理終了ではないと判断されれ
ばステップＳ７に戻る。処理終了と判断されれば、その
時点で処理を終了する。

【００２１】次に、管理用サーバ２４の監視処理部２４
１の処理について図７を用いて説明する。なお、図７は
一つの管理対象オープンソース・ソフトウエアについて
の処理である。監視処理部２４１は、最初、監視メール
の受信待ち状態にある（ステップＳ１１）。そして、こ
の監視メール受信待ち状態においてメール受信を受信し
たかを判断する（ステップＳ１３）。もし、監視メール
を受信した場合には特に問題は生じていないので、メー
ル送信タイミング以降であってメールを受信すると想定
されるメール受信時刻になると（ステップＳ１７：Ｙｅ
ｓルート）、メール受信待ちのステップＳ１１に戻る。
一方、メール受信待ち状態においてメールを受信しない
と、例えば３回連続して監視メールを受信できなかった
というような所定の基準を超えたかを判断する（ステッ
プＳ１５）。例えば、ネットワーク２０がインターネッ
トである場合には、何らかの理由で監視メールが不達と
なることもあるためである。また、管理対象サーバ１０
が何らかの理由でシャットダウンされている場合もある
ためである。

【００２２】もしステップＳ１５で所定の基準を超えて
いないと判断された場合にはステップＳ１７に移行す
る。一方、所定の基準を超えていると判断された場合に
は、システム管理者に例えばメールを送信したり、表示
装置に警告を表示させる（ステップＳ２０）。

【００２３】もしステップＳ１７において想定されるメ
ール受信時刻ではないと判断された場合には、処理終了
であるか判断する（ステップＳ１９）。処理終了でなけ
ればステップＳ１７に戻り、処理終了である場合には、
そのまま処理を終了する。

【００２４】図７は、上でも述べたが一つの管理対象オ
ープンソース・ソフトウエアについての処理である。通
常管理用サーバ２４では多くの管理対象サーバ１０にイ
ンストールされている多くのオープンソース・ソフトウ
エアの管理を実施する。従って、管理用サーバ２４にお
いて統計処理が必要になる場合もある。この統計処理は
統計処理部２４３が実施し、例えば図８に示すようなデ
ータを生成して、システム管理者に提示する。

【００２５】図８の例では、１日一回監視メールを送信
するようにメール送付モジュール１４０を設定した場合
であって、仮に一つの管理対象サーバ１０につき１つの
オープンソース・ソフトウエア１０４がインストールさ
れている場合の例を示す。図８（ａ）はテーブル形式で
各管理対象サーバ１０（図８ではシステムと呼んでい
る）からの監視メール到着数、最終メール送信時刻、管
理対象サーバの状態を示している。また、図８（ｂ）は
棒グラフにて監視メールの到着数を管理対象サーバ１０
毎に示している。これらのデータは、監視メールに含ま
れる管理対象サーバ名、メール送信日時データ、稼動状
態などを用いて作成することができる。図８（ａ）及び
（ｂ）から、システム管理者は、１週間のうちでｘｘシ
ステムは４通の監視メールしか送信しておらず、９月２
７日から監視メールを送信していないことから９月２７
日に異常が発生したと判定することができるようにな
る。

【００２６】なお、監視メールには管理対象サーバ１０
のＩＰアドレスも含まれているため、ＩＰアドレスのサ
ブネット単位に監視を行うことにより、異常が発生した
サブネットワークの検出も可能となる。

【００２７】次に図９乃至図１１を用いて、システム管
理者が図２に示すような管理対象サーバ１０を構築する
ために用いるインストーラ等について説明する。図９に
は、システム管理者がインストール用に用いる記録媒体
３００（例えば、ＣＤ−ＲＯＭ、フレキシブルディス
ク、ＤＶＤなど）の構成を示す。記録媒体３００には、
システム管理者用のインターフェースを提供するインタ
ーフェース部３０１と、インストールデータベース３０
３と、各オープンソース・ソフトウエアのインストール
に必要となるモジュール群３０５ａ乃至３０５ｃが記録
されている。インストールデータベース３０３には、オ
ープンソース・ソフトウエアの名称の欄と、サービス起
動シェル名の欄と、ロードモジュール名の欄と、バージ
ョンの欄が設けられている。例えば、各オープンソース
・ソフトウエアのインストールに必要となるモジュール
群３０５ａ乃至３０５ｃは、ロードモジュール名のディ
レクトリに格納されている。

【００２８】各オープンソース・ソフトウエアのインス
トールに必要となるモジュール群３０５ａ乃至３０５ｃ
の各々は、インストーラ３５０と、サービス起動シェル
３５２と、付加モジュール３５４と、オープンソース・
ソフトウエア本体部分３５６とを含む。付加モジュール
３５４には、メール送付モジュール３５４１と、メール
送付ソースプログラムのファイル３５４２と、管理ＩＤ
ファイル生成モジュール３５４３と、管理ＩＤファイル
生成ソースプログラムのファイル３５４４とを含む。ま
た、オープンソース・ソフトウエア本体部分３５６に
は、１又は複数のロードモジュール３５６５とそのソー
スプログラムの１又は複数のファイル３５６１と、これ
らのヘルプ情報等を含むドキュメントの１又は複数のフ
ァイル３５６３のファイルを含む。

【００２９】図１０を用いて図９に示した記録媒体を用
いたインストールの処理について説明する。なお、図５
のステップＳ１の処理でもある。システム管理者の指示
により、まずインターフェース部３０１が、インストー
ルデータベース３０３の情報を参照して、例えば図１１
に示すようなインストーラ画面を表示する（ステップＳ
２１）。図１０のインストーラ画面では、インストール
するオープンソース・ソフトウエアをプルダウンメニュ
ーから選択するようになっている。但し、プルダウンメ
ニューではなく、一覧表を表示して、例えばラジオボタ
ン等により選択させるような構成であってもよい。

【００３０】次に、システム管理者から、インストール
対象オープンソース・ソフトウエアの選択指示を受け付
ける（ステップＳ２３）。そうすると、インストール対
象オープンソース・ソフトウエアとして指定されたオー
プンソース・ソフトウエア用のインストーラ３５０が、
インストールデータベース３０３を参照してサービス起
動シェル名を取得し、当該オープンソース・ソフトウエ
ア用のサービス起動シェル３５２を、取得したサービス
起動シェル名で管理対象サーバ１０にインストールする
（ステップＳ２５）。すなわち、サービス起動シェル３
５２を、取得したサービス起動シェル名で、管理対象サ
ーバ１０の記憶装置に書き込む。このサービス起動シェ
ル３５２は、付加モジュール及びロードモジュールの両
方を起動するように設定されている。

【００３１】そして、インストーラ３５０は、記録媒体
３００に格納された付加モジュール３５４及びロードモ
ジュール３５６５を含むオープンソース・ソフトウエア
本体部分３５６を、管理対象サーバ１０にインストール
する（ステップＳ２７）。すなわち、付加モジュール３
５４及びロードモジュール３５６５を含むオープンソー
ス・ソフトウエア本体部分３５６を、管理対象サーバの
記憶装置に格納する。なお、他にシステム上必要な設定
があれば、インストーラ３５０が設定を実行する。

【００３２】以上の処理が終了するとインストーラ３５
０は、システム管理者に管理対象サーバ１０の再起動を
要求する（ステップＳ２９）。通常は、再起動すること
によりインストールされた新たなモジュールが有効とな
るためである。なお、再起動する必要がない場合には、
再起動を要求しなくともよい。そして処理を終了する。

【００３３】このようにインストールすることにより、
図２に示すような管理対象サーバ１０の構成が完成し、
監視メール２２が管理用サーバ２４に例えば定期的に送
信されるようになる。

【００３４】以上本発明の一実施の形態を説明したが、
これは一例に過ぎない。例えば、上で述べた実施の形態
では、ＵＮＩＸ（登録商標）系のＯＳを前提として説明
したが、他のＯＳでも適用することができる。また、図
３における管理用サーバ２４は管理対象が多くなると負
荷重くなるため、１台のコンピュータではなく複数台の
コンピュータにて処理する場合もある。また、図６に示
した監視メールの内容も一例であって、例えば管理用サ
ーバ名や管理番号、ＩＰアドレス等がない場合であって
も、本発明の目的を達成することができる。また、図８
に示した統計処理結果の表示例は一例であって、棒グラ
フの代わりに折れ線グラフにしたり、他の表現形態にて
統計処理の結果を示すようにしてもよい。

【００３５】また、監視メールの送信タイミングは、定
期的である方が管理しやすいが、正確に定期的である必
要はない。例えば、１日に一回の場合であっても、１日
のうち定時に送信するのではなく、例えば管理対象サー
バ１０の処理負荷が低い状態を検出して送信するように
してもよい。また、常に監視メールを送信できるわけで
はない状態にあれば、送信できる状態を検出してその時
に送信するような構成であってもよい。

【００３６】さらに、図９の記録媒体３０の構成も一例
である。図９の例では、各オープンソース・ソフトウエ
アをインストールするためのモジュール群３０５ａ乃至
３０５ｃに、インストーラ３５０が含まれている例を示
したが、独立に１つのインストーラを設け、このインス
トーラが全ての種類のオープンソース・ソフトウエアを
インストールするような構成であってもよい。さらに、
図１０では、サービス起動モジュール、付加モジュール
及びオープンソース・ソフトウエアの順番でインストー
ルする例を示したが、逆であってもよい。また、図４に
利用者が勝手に異なるバージョンのオープンソース・ソ
フトウエアをインストールした場合の例を示したが、図
１のような状態、すなわち付加モジュール１４が削除さ
れてしまうような場合もありえる。

【００３７】（付記１）プログラムの機能を実現するた
めのロード・モジュールと、前記プログラムの実行状況
に関する情報を管理用コンピュータに送信する通知モジ
ュールとを起動するための起動モジュールを、前記ロー
ド・モジュールのみを起動するための第２の起動モジュ
ールに付された名称をもって、指定のコンピュータの記
憶装置にインストールするためのインストーラ。

【００３８】（付記２）前記通知モジュールが、少なく
とも前記プログラム及び前記指定のコンピュータを識別
する情報を含む前記実行状況に関する情報を生成するモ
ジュールと、起動中には定期的に前記実行状況に関する
情報を前記管理用コンピュータに送信するモジュール
と、を含む付記１記載のインストーラ。

【００３９】（付記３）前記ロード・モジュールと、前
記通知モジュールと、前記起動モジュールと、付記１又
は２記載のインストーラとが格納された記録媒体。

【００４０】（付記４）プログラムの機能を実現するた
めのロード・モジュールと、前記プログラムの実行状況
に関する情報を管理用コンピュータに送信する通知モジ
ュールと、前記ロード・モジュールと前記通知モジュー
ルとを起動するための起動モジュールであって、前記ロ
ード・モジュールのみを起動するための第２の起動モジ
ュールと同一の名称を有する起動モジュールと、を有す
るコンピュータ。

【００４１】

【発明の効果】以上のように本発明によれば、システム
内のオープンソース・ソフトウェアの実行状況を収集
し、システム管理者が容易に実行状況の把握を行えるよ
うにするための技術を提供するができる。

【図面の簡単な説明】

【図１】従来の管理対象サーバの構成を示す図である。

【図２】本発明の一実施の形態に係る管理対象サーバの
構成を示す図である。

【図３】本発明の一実施の形態に係るシステム概要を示
す図である。

【図４】利用者が勝手にオープンソース・ソフトウエア
の異なるバージョンをインストールした場合における管
理対象サーバの状態を表す図である。

【図５】管理対象サーバにおける処理フローの一例を示
す図である。

【図６】監視メールの内容の一例を示す図である。

【図７】管理用サーバにおける処理フローの一例を示す
図である。

【図８】管理用サーバにおける表示内容の一例を示す図
である。

【図９】インストール用記録媒体の構成を示す図であ
る。

【図１０】インストールの処理フローの一例を示す図で
ある。

【図１１】インストール時における管理対象サーバの画
面例を示す図である。

【符号の説明】

１０ 管理対象サーバ １２ サービス起動シェル １４ 付加モジュール １０４ オープンソース・ソ
フトウエア １０６ ロードモジュール １４０ メール送付モジ
ュール １４２ 管理ＩＤファイル生成モジュール ２０ ネットワーク ２２ 監視メール ２４ 管
理用サーバ ３００ 記録媒体 ３０１ インターフェース部 ３０３ インストールデータベース ３０５ モジュ
ール群 ３５０ インストーラ ３５２ サービス起動シェル ３５４ 付加モジュール ３５６ オープンソース・ソフトウエア本体部分

Claims (3)

【特許請求の範囲】
1. 【請求項１】プログラムの機能を実現するためのロード
   ・モジュールと、前記プログラムの実行状況に関する情
   報を管理用コンピュータに送信する通知モジュールとを
   起動するための起動モジュールを、前記ロード・モジュ
   ールのみを起動するための第２の起動モジュールに付さ
   れた名称をもって、指定のコンピュータの記憶装置にイ
   ンストールするためのインストーラ。
2. 【請求項２】前記通知モジュールが、 少なくとも前記プログラム及び前記指定のコンピュータ
   を識別する情報を含む前記実行状況に関する情報を生成
   するモジュールと、 起動中には定期的に前記実行状況に関する情報を前記管
   理用コンピュータに送信するモジュールと、 を含む請求項１記載のインストーラ。
3. 【請求項３】プログラムの機能を実現するためのロード
   ・モジュールと、 前記プログラムの実行状況に関する情報を管理用コンピ
   ュータに送信する通知モジュールと、 前記ロード・モジュールと前記通知モジュールとを起動
   するための起動モジュールであって、前記ロード・モジ
   ュールのみを起動するための第２の起動モジュールと同
   一の名称を有する起動モジュールと、を有するコンピュ
   ータ。