JPH01197859A - 分散式監視サブシステム - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明は一般にデータ処理に関し、さらに具体的には、
データ処理システム用の安全保護監視機構の提供に・関
するものである。

Ｂ、従来技術 多くのデータ処理アプリケーションは、財務アプリケー
ジ日ン、国家安全保障アプリケージ騨ン等の高度な機密
情報を含み、それらのアプリケ−シロンでは、多数のユ
ーザ端末が、端末制御装置を介して分散処理ネットワー
ク中に相互接続された複数のデータ・プロセッサの１つ
に接続されている。データ・ファイルは、ネットワーク
に接続された複数のデータ・プロセッサ及び端末から共
通にアクセスできる記憶装置に記憶することができる。

ネットワーク全体に記憶された種々のデータ・ファイル
にアクセスを行なうことが可能なノードの種類が様々で
あるため、高度の機密メツセージ及びファイルがシステ
ム内で伝送され記憶されるという、安全保護上重大な問
題がある。従来技術は、分散処理ネットワークを介して
伝送され、共通にアクセス可能な記憶装置に記憶される
機密データを、未許可の人物またはプログラムが読み取
るのを防ぐための有効な機構を提供してこなかった。従
来技術のデータ処理システムでは、通信経路及びデータ
・アクセス・ノードは、未許可の人物またはプログラム
の侵入を受け、これらの人物またはプログラムは、ネッ
トワーク内で伝送され記憶される機密情報を流用、複写
またはその他の方法でその安全保護を破壊する。

国家安全保障アプリケ−シロンについて、米国政府は、
データ処理システムの安全保護を評価する基準を確立し
、この基準は「トラステッド・コンピュータ・システム
評価基準（↑ｒｕｓｔｅｄ　ＣｏｍｐｕｔｅｒＳｙｓｔ
ｅｍ　Ｅｖａｌｕａｔｉｏｎ　Ｃｒ１ｔｅｒｉａ）　Ｊ
　１米国防総省１１９８５年１２月、ＤｏＤ刊行物番号
５２００゜２８−８ＴＤ　（本明細書ではＤｏＤ基準と
呼ぶ）に公表されている。ＤｏＤ基準では、トラステッ
ド・コンビエータ・システムは、十分なハードウェア及
びソフトウェアの保全性対策を用いて、一連の機密情報
を同時に処理するために使用できるシステム管理員と定
義されている。トラステラｙ計算ベース（ＴＣＢ）は、
全体として安全保護策を実施するハードウェア、ファー
ムウェア及びソフトウェアを含む、コンピュータ・シス
テム内の保護機構の総体であると定義される。ＴＣＢは
、プロダクトまたはシステムに関する統一された安全保
護策を全体として実施する、１つまたは複数の構成要素
から成る。ＴＣＢが安全保護策を正し〈実施できるかど
うかは、ＴＣＢ内の機構と、ユーザの許可等、安全保護
策に関連するパラメータをシステム管理員が正しく入力
したかどうかだけによって決まる。トラステッド経路は
、ＤｏＤ基準では、端末にいる人物がトラステッド計算
ベースと直接通信できるようにする機構であると定義さ
れる。トラステッド経路機構は、その人物またはトラス
テッド計算ベースのみが活動化でき、非トラステッド・
ソフトウェアがそれを模倣することはできない。トラス
テッド・ソフトウェアは、トラステッド計算ベースのソ
フトウェア部分であると定義される。

ＤｏＤ基準で定められているように、適正に許可された
個人または処理のみが、情報を読み、書き、作成または
削除するためにアクセスできるように、安全なコンピュ
ータ・システムは情報に対するアクセスを制御する。Ｄ
ｏＤ基準は、情報に対するアクセスを制御するため、及
び、このことがトラステッド・コンピュータ・システム
で実現されたという信用できる保証をどのように得るこ
とができるかに対処するための６つの基本要件を定めて
いる。安全なコンピュータ・システムに対する第１の要
件は、システムが、機密情報を扱うためのアクセス規則
を効果的に実施することができる必須の安全保護策を実
施しなければならないということである。それらの規則
には、適切な要員の安全保護許可を持たない人物は機密
情報に対するアクセスを得ることができず、さらに、選
択されたユーザまたはユーザのグループのみが、たとえ
ば、知る必要のあるたびにデータに対するアクセスを得
ることができるという要件が含まれる。

安全なコンビエータ・システムに対する第２の要件は、
アクセス制御ラベルを、安全に保つべき情報と関連づけ
なければならないということである。

安全なコンビエータ・システムに対する第３の要件は、
誰が情報にアクセスしているか、及び彼等はどのような
種類の情報を扱うことを許可されているかに基づいて、
情報に対するアクセスを逐一許可しなければならないと
いうことである。安全なコンピュータに対する第４の要
件は、安全＆７：護に影響を及ぼす動作を行なったユー
ザを突きとめることができるように、監視情報番選択的
に保持し、保護しなければならないということである。

トラステッド・システムは、安全保護に関連する事象の
発生を監視ログに記録することができなければならない
。監視の費用を最小限にし、効率的な解析を可能にする
ため、記録される監視事象を選択する能力が必要である
。安全保護違反の発見及び追跡調査が可能になるように
、監視データを変更及び無許可の破壊から保護しなけれ
ばならない。安全なコンピュータ・システムに対する第
５の要件は、システムが最初の４つの要件を実施すると
いう十分な保証を与えるため、システムが、独立に評価
できるハードウェア及びソフトウェア機構を含まなけれ
ばならないということである。

安全なコンピュータ・システムに対する第８の要件は、
これらの基本要件を実施するトラステッド・機構を不正
操作及び無許可の変更から常に保護しなければならない
ということである。

ＤｏＤ基準で定義された安全なコンピュータ・システム
を維持する問題は、多数のユーザを収容するシステムで
は一層難しくなる。ＤｏＤ基準で定義される安全なコン
ピュータ・システムを確立するための効果的な機構を提
供しなかった従来技術の複数ユーザ・オペレーティング
・システムの例には、ＵＮＩＸ（ＵＮＩＸはＡＴ＆Ｔベ
ル研究所（Ｂｅｌｌ　Ｌａｂｏｒａｔｏｒｉｅｓ）の商
標）、ＸＥＮＩＸ（ＸＥＮＩＸはマイクロソフト（Ｍｉ
ｃｒｏｓｏｆｔ）社の商標）及びＡＩＸ（ＡｒＸはＩＢ
Ｍ社の商標）が含まれる。ＵＮＩＸは、広範囲なミニコ
ンピユータ及びマイクロコンピュータ用のオペレーティ
ング・システムとしてＡＴ＆Ｔにより開発サレ、ライセ
ンス許諾されている。ＵＮＩＸオペレーティング・シス
テムに関するより詳しい情報については、ｒＵＮＩＸ　
（ＴＭ）システム、ユーザ・マニュアル、システムＶ　
（ＩＩＮＩＸ　（ＴＭ）　Ｓｙｓｔｅｍ、［Ｊｓｅｒｓ
Ｍａｎｕａｌ、　Ｓｙｓｔｅｍ　Ｖ）　Ｊ　、ウェスタ
ン・エレクトリック（すｅｓｔｅｒｎ　Ｅｌｅｃｔｒｉ
ｃ　Ｃｏ、　）社、１９８３年１月刊を参照されたい。

ＵＮＩＸオペレーティング・システムのすぐれた概説が
、プライアン　Ｗ、力−ニハン（Ｂｒｉａｎ　ＩＪ、に
ｅｒｎｉｇｈａｎ）著、ｒＵＮＩＸプログラミング環境
（Ｔｈｅ　ＬＩＮＩＸ　ＰｒｏｇｒａｍｍｉｎｇＥｎｖ
ｉｒｏｎｎ＋ｅｎｔ）　ｊ　％プレンティス・ホール（
Ｐｒｅｎｔ　１ｃｅ−Ｈａ　１１　）、１９８４年刊に
出ている。

ＵＮＩＸオペレーティング・システムの設計についての
さらに詳細な説明は、モーリス　Ｊ、バラ／’　（Ｍａ
ｕｒｉｃｅ　Ｊ、　Ｂａｃｈ）著、ｒＵＮＩＸオペレー
ティング・システムの設計（Ｄｅｓｉｇｎ　ｏｆ　ｔｈ
ｅ　ＵＮＩＸＯｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）　Ｊ
　Ｎプレンティス・ホール、１９８６年刊に記載されて
いる。

ＡＴ＆Ｔベル研究所は、ＵＮＩＸオペレーティング拳シ
スナシステム使用センスを多数の団体ニ与えており、現
在、幾つかのバージロンがある。

ＡＴ＆Ｔの最新バージロンはバージ日ソ５．２である。

ＵＮＩＸオペレーティング・システムのバークレー・バ
ージロンと呼ばれるもう１つのバージョンが、カリフォ
ルニア大学バークレー校で開発された。マイクロソフト
社はＸＥＮＩＸの商標で知られているバージョンを有す
る。

１９８５年にＩＢＭ　ＲＴ　　ＰＣ（ＲＴ及びＲＴｐｃ
はＩＢＭ社の商標）（ＲＩＳＣ（縮小命令セット・コン
ピュータ）技術によるパーソナル・コンピュータ）の発
表により、ＩＢＭ社は、ＡＩＸと呼ばれる新しいオペレ
ーティング・システムを発表した。ＡＩＸは、アプリケ
ーション・インターフェース・レベルでＡＴ＆ＴのＵＮ
ＩＸオペレーティング・システム、バージａン５．２と
互換性があり、ＵＮＩＸオペレーティング・システム、
バージョン５．２に対する拡張を含む。ＡＩＸオペレー
ティング・システムに関するより詳しい説明については
、ｒＡＩＸオペレーティング・システム技術解説書（Ａ
ＩＸ　Ｏｐｅｒａｔｉｎｇ　ＳｙｓｔｅｍＴｅｃｈｎｉ
ｃａｌ　Ｒｅｆ’ｅｒｅｎｃｅ）　Ｊ　、第２版、ＩＢ
Ｍ社、１９８６年９月刊を参照されたい。

本明細書で開示され、特許請求されている発明は特に、
安全保護に影響を及ぼす動作の責任を負うべきユーザを
突きとめることができるように、安全な分散データ処理
システム内で選択的に保持し、保護しなければならない
情報を監視するための機構を提供することに関する。こ
の機構は、ＵＮ　Ｉ　Ｘ、　ＸＥＮ　Ｉ　Ｘ＊タハＡ　
Ｉ　Ｘ等の複数ユーザ・オペレーティング・システムの
一部となり、安全なコンピュータ・システムを確立する
ことができる。本明細書で開示する本発明の特定の実施
例は、ＡＩＸオペレーティング・システムに適用される
。

本願と同日に出願され、１８Ｍ社に譲渡された、「オペ
レーティング・システムのためのトラステッド経路機構
（Ａ　Ｔｒｕｓｔｅｄ　Ｐａｔｈ　Ｍｅｃｈａｎｉｓｍ
　ｆ’ｏｒ　ａｎＯｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）
　Ｊと題するアブハイ・ジロリ（Ａｂｈａｉ　Ｊｏｈｒ
ｉ）等の関連米国特許出願第１４９４４６号に記載され
ている説明を参照されたい。

ジロリ等の米国特許出願の説明は、ＡＩＸオペレーティ
ング・システムの動作原理の考察を含み、本明細書で開
示され、特許請求されている発明を理解する上で助けと
なる。ＡＩＸオペレーティング・システムに関するさら
に詳しい情報については、上記のＩＢＭ社刊行物ｒＡ　
Ｉ　Ｘオペレーティング・システム技術解説書」を参照
されたい。

ＡＩＸオペレーティング・システム及びＵＮＩＸに類似
した他のオペレーティング・システムは特殊な用語を使
用するので、それらの用語の一部について以下の定義を
示す。

プロセス：コマンドの入力、シェル・プログラムの実行
、または別のプロセスによって始動されることによりシ
ステム内で開始される活動等、所期の結果をもたらすた
めに必要な一連の動作。

パスワード：ユーザ識別記号と共に入力されたとき、オ
ペレータがシステムにサイン・オンすることを可能にす
る文字ストリング。

オペレーティング・システム：プログラムの実行を制御
するソフトウェア。さらに、オペレーティング・システ
ムは資源の割振り、スケジューリング、入出力制御、及
びデータ管理等のサービスを提供することができる。

カーネル：ＵＮＩＸと類似したオペレーティング・シス
テムでは、カーネルがシステム・コール・インターフェ
ースを実現する。

１ｎｉｔ　：　カーネルは、初期設定の基本プロセスを
完了した後、システム内の他のすべてのプロセスの先祖
となるプロセスを開始する。このプロセスは１ｎｉｔプ
ロセスと呼ばれる。１ｎｉｔプロセスは、システムが稼
働する状態（通常は、保守モードまたはｉ数ユーザ・モ
ードのいずれか）を制御するプログラムである。

ｇｅｔｔｙ　：　１ｎｆｔプロセスは、システムに対す
る各ポートについてｇｅｔｔｙ　’コマンドを実行する
。その主要機能は、指定されたポートの特性をセットす
ることである。

ｌｏｇｉｎ　：　ｌｏｇｉｎプログラムはユーザをシス
テムにログオンし、ユーザのパスワードの有効性を検査
し、当該のログ項目を作成し、処理環境をセットアツプ
し、パスワード・ファイルで指定されたコマンド解釈プ
ログラム、通常はシェル（ＳＨ）プログラムを実行する
。

シェル（ＳＨ）ニジエル・コマンドはシステム・コマン
ド解釈プログラム及びプログラミング言語である。キー
ボードから入力されたコマンドを読み取り、その実行の
準備をするのは通常のユーザ・プログラムである。

ｆｏｒｋ　：　ｆｏｒｋ　システム・コールは、子プロ
セスと呼ばれる新しいプロセスを作成する。子プロセス
は呼出し側プロセス（親プロセス）の正確なコピーであ
る。作成された子プロセスは親プロセスの属性の大部分
を受は継ぐ。

ｅｘｅｃ　：　ｅｘｅｃ　システム−コールは、呼出し
プロセス中に新しいプログラムを実行する。ｅＸｅｅは
新しいプログラムを作成しないが、現在のプログラムを
新しいプログラムでオーバーレイし、これは新しいプロ
セス・イメージと呼ばれる。新しいプロセス・イメージ
・ファイルは実行可能２進ファイル、シェル手順を含む
実行可能テキスト・ファイル、あるいは実行可能２進フ
ァイルまたは実行すべきシェル手順を指定するファイル
でよい。

シグナル：シグナルは活動状態のプロセスに対する通信
を行ない、現在のプロセス環境が保管され新しいプロセ
ス環境が生成される１組の事象を強制する。シグナルと
は、プロセスの通常の実行を中断し、シグナルが発生す
るときに呼び出せるシグナル処理サブルーチンを指定す
ることができる事象である。

スーパーユーザ（ＳＵ）　：データの消失またはシステ
ムの損傷を防ぐように意図された規制なしに動作するこ
とができるユーザ（ユーザＩＤ０）。

ルート：スーパーユーザに対してときどき使用される別
名。

ルート・ディレクトリ：トリー構造ディレクトリ−シス
テムの最高レベル。

デーモン・プロセス二カーネルまたはルート・シェルに
よって開始され、スーパーユーザによってのみ停止させ
ることができるプロセス。デーモン・プロセスは、一般
に印刷装置にデータを送る等、常時使用可能なサービス
を提供する。

マウント：ファイル・システムをアクセス可能にする。

端末：キーボード及び表示装置または印刷装置を含む入
出力装置。端末は通常、コンピュータに接続され、人間
がコンピュータと対話することを可能にする。　　　　
・ 本発明を適用できる分散ネットワークの一例は、１９８
７年２月１３日に出願され、Ｉ’　Ｂ　Ｍ社に譲渡され
た「分散ネットワーク環境で遠隔ファイルにアクセスす
るためのシステム及び方法（ＡＳｙｓｔｅｍ　　ａｎｄ
　　Ｍｅｔｈｏｄ　　ｆｏｒ　　Ａｃｃｅｓｓｉｎｇ　
　Ｒｅｍｏｔｅ　　Ｆｉｌｅｓｉｎ　ａ　Ｄｉｓｔｒｉ
ｂｕｔｅｄ　Ｈｅｔｗｏｒｋｉｎｇ　Ｅｎｖｆｒｏｎｍ
ｅｎｔ）　Ｊと題するＧ、Ｈ，ノイマン（Ｈｅｕｍａｎ
　）等の関連米国特許出願第０１４８９７号に記載され
ている。

ノイマン等の特許出願に記載されているように、分散環
境では、複数のデータ処理システムがネットワーク・シ
ステムを介して相互接続されている。

ネットワーク・システム上に設置された分散サービス・
プログラムは、データ・ファイルがネットワーク内のど
こに゛あろうと、ネットワークの種々のノードにわたっ
て分散されたデータ・ファイルにプロセッサがアクセス
することを可能にする。

他のノードにあるファイルがアクセスされるときのネッ
トワークのトラフィック・オーバーヘッドを減少させ、
ファイル・システムのセマン、ティックス、すなわちフ
ァイルの保全性を維持するため、ノイマン等は、種々の
ファイルに対するアクセスをファイル同期ノードで管理
することを開示している。読取りまたは書込みアクセス
゛のために１つのノードのみでファイルがオープンされ
る場合は、そのファイルに第１の同期モードが与えられ
る。

ファイルが任意のノードで読取り専用アクセスのために
オープンされる場合は、そのファイルに第２の同期モー
ドが与えられる。ファイルが複数のノードの読取りアク
セスのた”めにオープンされ、゛　少なくとも１つのノ
ードが書込みアクセスのためにファイルをオープンした
場合は、そのファイルに第３の同期モードが与えられる
。

ファイルが第１または第２の同期モードにある場合、そ
のファイルにアクセスするノードであるクライアント・
ノードがそのオペレーティング・システム内のクライア
ント・キャッシュを使′ってそのファイルを記憶するこ
とをノイマン等は開示している。次いで、すべての読取
り及び書込みがこのキャッシュに送られる。

ファイルが第３のモードにある場合、すべての読取り及
び書込み要求が、ファイルのあるサーバ・ノードに進ま
ねばならないことをノイマン等は開示している。そのフ
ァイルにアクセスするノードは、この第３のモードの間
にファイル・データにアクセスするのに、そのオペレー
ティング・システム内のキャッシュを使用しない。

ノイマン等は、すべての読取り及び書込み要求が第１及
び第２の同期モードでクライアント・キャッシユにアク
セスするようにクライアント・キャッシュが管理される
ことを開示している。第３の同期モードでは、クライア
ント・キャッシュは使用されない。このようにして、フ
ァイルの保全性を犠牲にすることなく、全体的なシステ
ムの能力が向上する。

Ｃ０発明が解決しようとする課題 したがって、本発明の目的は、改善された安全なコンピ
ュータ・システムを提供することである。

本発明のもう１つの目的は、ＤｏＤ基準丑合致する、改
善された安全なコンピュータ・システムを提供すること
である。

本発明のさらに他の目的は、システムの安全保護に影響
を及ぼす動作の原因となったユーザを突きとめることが
できるように監視情報を選択的に保持し、保護すること
ができる、改善された安全な分散データ処理システムを
提供することである。

本発明のさらに他の目的は、システムの安全保護に影響
を及ぼす動作の原因となったユーザを突きとめることが
できるように監視情報を選択的に保持し、保護すること
ができる、ＵＮＩＸオペレーティング・システムを使用
する、改善された安全な分散データ処理システムを提供
することである。

０１課題を解決するための手段 本発明の上記及びその他の目的、特徴及び利点は、本明
細書に開示されている分散監視サブシステムにより実現
される。分散監視サブシステムの発明は、階層的ファイ
ル・システムを備えたＵＮＩＸ類似のオペレーティング
・システムで稼働する。本発明は、それが保護し、維持
する対象物に対するアクセスの監視証跡を提供し、監視
証跡を変更、または無許可のアクセスまたは破壊から保
護する。本発明によって生成される監視データは保護さ
れ、それに対する読取りアクセスは、監視データに対し
て許可された者だけに制限される。

本発明は、識別及び確認機構の使用、ユーザのアドレス
空間へのオブジェクトの導入、そのようなオブジェクト
の削除、コンピュータ操作員及びシステム管理者、また
はシステム安全保護担当者が講じる処置、及びその他の
安全保護に関連する事象等、システムの安全保護の維持
に関連する事象の記録を可能にする。本発明は、記録さ
れた各事象について、事象の日時、ユーザ、事象の種類
、及び事象の成否を含む監視レコードを生成する。

本発明は、ＵＮＩＸ型デーモン・プロセスを使って監視
証跡ログ・ファイルのオンライン圧縮を行なう。監視デ
ーモン・プロセスは、ノード障害の後でこのプロセスが
回復することを可能にする再始動可能機構を有する。本
発明は、ネットワーク内の種々の記憶位置にファイルが
記憶されている分散処理システムに特に適している。そ
のような分散システムでは、本発明の監視プロセスを、
ネットワーク全体にわたって分散式に実行して、種々の
記憶位置にある監視ファイルを単一の監視証跡ログ・フ
ァイルに集中させることができる。

このようにして、ＤＯＤ基準に合致した安全なコンビ二
−タ嗜システムが実現され、このシステムは、分散デー
タ処理システムの安全保護に影響を及ぼす動作に関する
監視情報を発生、処理及びデータ圧縮することができる
。

本発明の上記及びその他の目的、特徴及び利点は添付の
図面を参照すればさらに十分に理解できるはずである。

Ｅ、実施例 一監視証跡（ａｕｄｉｔ　ｔｒａｉｌ）ファイルを圧縮
する機構を備えた単一データ・プロセッサ用の監視サブ
システムは、Ｊ、ピッチオツド（Ｐｉｃｃｉｏｔｔｏ　
）の論文「効果的な監視サブシステムの設計（ＴｈｅＤ
ｅｓｉｇｎ　ｏｆ　ａｎ　Ｅｆｆｅｃｔｉｖｅ　Ａｕｄ
ｉｔｉｎｇ　５ｕｂｓｙｓｔｅｓ＋）　Ｊｔ州オークラ
ンド、１９８７年４月、り１）、１３−２２に既に開示
されている。ピッチオツドは、圧縮を含むサブシステム
の設計のしかたについて論じている。しかし、ピッチオ
ツドは、分散サービスがある分散処理ネットワークで監
視サブシステムをどのようにして動作させるかについて
は扱っていない。

分散サービスの概念は、上記のＧ、Ｈ，／イ？ン等の特
許出願ではＵＮＩＸマシン（ノード）の集まりとして記
載されている。各ノードは、第４図に示すような、トリ
ーとして描くことができる階層的ファイル・システムを
有する。トリーのルートはスラッシュと呼ばれ、各スラ
ッシュの下にはディレクトリがあり、各ディレクトリに
は他のディレクトリまたはファイルがある。ＵＮＩＸデ
ィレクトリはファイル・ケースに似たものと考えること
ができる。ＵＮＩＸファイルはそのファイル・ケース内
のファイルに似ている。ＵＮＩＸでは、ディレクトリの
サブディレクトリを設は名ことができる。すなわち、経
路ディレクトリは子ディレクトリを有することができる
。第４図に、上端にルートがあり、階層的名前空間を表
わすブランチがそこから下がっているトリーが示しであ
る。スラッシュで表わされるルートが上端にあり、その
下に幾つかのサブディレクトリがある。ＵＮＩＸでは、
代表的なサブディレクトリの幾つかは／　ｂｉｎｘ　／
　ｅｔｃ１／　ｔｅｍｐ及び／　ｕｓｒであり、ときど
き／Ｕがあり、／　ｅｔｃ等のディレクトリの下に、た
とえば／　ｅｔｃ　／　ｒｅ　　等のファイル、または
ディレクトリがある。

本発明では、新しいディレクトリ／　ｅｔｃ　／５ｅｃ
ｕｒ　ｉｔｙ　を導入した。その下に、幾つかのテーブ
ルがある。／　ｅｔｃ　／　５ｅｃｕｒｉｔｙの下のテ
ーブルの１つは、／　ｅｔｃ　／　５ｅｃｕｒｉｔｙ　
／　ｓ　ｃｍｄと呼ばれるファイルである。これはＡ、
ジロリ等の上記特許出願に記載されるような、トラステ
ッド・シェル用のコマンド・テーブルを含むファイルの
名前である。さらに、ディレクトリ名／　ｅｔｃ／　５
ｅｃｕｒｔｔｙの下に／　ｅｔｃ　／　５ｅｃｕｒｉｔ
ｙ　／　ａｕｄｉｔと呼ばれるディレクトリを導入し、
このディレクトリの下に、ａ　ｅｖｅｎｔと呼ばれるフ
ァイルがある。

本発明によれば、事象テーブルはこの監視サブシステム
のためにシステム内の既知の事象を列挙する。事象には
、ベース事象と管理事象の２種のものがある。ベース事
象とは、カーネル内、またはコマンド中で生じる事象で
ある。ベース事象の一例は、ｅｘｅｃ　と呼ばれる事象
やｆｏｒｋ　と呼ばれる事象等、カーネル内の事象であ
る。コマンド中のベース事象の一例はｓ　ｌｏｇｉｎ　
と呼ばれるコマンド中の２つの事象ｌｏｇｉｎ　ｆａｉ
ｌ　とｌｏｇｉｎ　ｏｋである。

ｌｏｇｉｎ−ｆａｉｌ　またはｌｏｇｉｎ　ｏｋのいず
れかのシステム中の管理事象を定義し、この管理事象を
ｌｏｇｉｎと名付けたい場合には、事象テーブル／　ｅ
ｔｃ　／５ｅｃｕｒｉｔｙ　／　ａｕｄｉｔ　／　ａｎ
　ｅｖｅｎｔを調べ１テーブルを編集して、ｌｏｇｉｎ
：　ｌｏｇｉｎ　ｆａｉｌｌｌｏｇｉｎ　ｏｋ　という
行を追加すればよい。監視人がｒｌｏｇｉｎＪと呼ばれ
る監視事象をオンにしたい場合、それは既にテーブル中
で定義されている。管理事象は、新しい管理事象を含む
ようにこのファイルを編集または変更するために監視人
が使用できる便利なマクロである。本発明は、分散処理
ネットワーク内で複数の分散サービス（ＤＳ）にわたる
動作のために特に設計されている。

Ｇ、Ｈ，ノイマン等の上記特許出願に記載されるように
、ＤＳが何を行なうかを理解するため、階層的ＵＮＩＸ
ファイルーシステムについてここで若干考察−する。Ｕ
ＮＩＸシステムのネットワークがあり、各ＵＮＩＸシス
テム上に、ディレクトリ及びファイルを含む階層的名前
空間があるものと仮定する。すなわち、それは、第４図
に示すように、上端に「／」で表わされるルートがある
トリーであり、「／」の下にディレクトリ及びファイル
がある。ＵＮＩＸシステム上では、「／」の下にｂｉｎ
ｌｅｔＣｌｔｅｌｌｐｘ　ｕｓｒ等と呼ばれる幾つかの
周知のディレクトリがあり、それらの下に他の幾つかの
ディレクトリまたは他の幾つかのファイルがある。さら
に、この場合、従来のＵＮＩＸシステム上で名前空間を
調べるとき、これらのディレクトリ及びファイルは、す
べてその単一データ・プロセッサにとってローカルであ
り、いずれのファイルもリモートではない。

２つのＵＮＩＸシステムがあるものとする。第１のシス
テムをＡと呼び、第２のシステムをＢと呼ぶ。各ＵＮ　
Ｉ　Ｘシステムには、「／」及びその下に種々のファイ
ルを含むトリーを有する階層的名前空間がある。第１の
マシンＡにいて、第２のマシンＢ上のファイル及びディ
レクトリにアクセスしたいものとする。そのことを行な
うための１つの方法（実際には旧来の方法であり、依然
として使われている）は、Ａ上にいてＢに話しかけたい
場合に、ｒｔｅｌｎｅｔＪと呼ばれるコマンドまたはｒ
ｒｌｏｇｉｎＪ　　（ｒ　はリモートを表わす）と呼ば
れるコマンドを使ってＢにログインするものであり、実
際にはまずＡにログインして、Ｂに話しかけようとする
。したがって、Ｂに対してｔｅｌｎｅｔまたはｒｌｏｇ
ｉｎ　のいずれかを実行すると、Ｂの環境（Ｂの階層的
名前空間）に入り、Ｂ上で動作を実行することができる
。しかし、ＡとＢの間でファイルを移動させることは実
行できない。すなわち、ＡまたはＢのいずれかにいるが
、両方にいることはできない。

第１のマシン上にいてそこに留まりながら、第２のマシ
ンの階層的名前空間、すなわち、そのディレクトリまた
はそのファイルにアクセスすることが望ましい。実際に
は、Ａ上でＡのローカル・ファイルに作用し、かつＢ上
の任意のリモート・ファイルに作用するコマンドを持つ
ことが望ましい。

そのためには、リモート・ファイルに命名する方法が必
要である。既存のコードを使って実行できることが他に
も幾つかある。実行できることの１つは、Ａ上にいて、
ＡからＢまたはＢからＡにファイルを複写したい場合に
、それを行なうためのコマンドがあることで、このコマ
ンドはＦＴＰ　（ファイル転送プログラムの略）と呼ば
れる。ＡＩＸ上では、これはＸＦＴＰと呼ばれる。その
作用のしかたは、一方のマシン上にいて、ＸＦＴＰと指
定することで、基本的にｌｏｇｉｎに似ている。他方の
マシンにログインすると、ファイルを両方向に複写する
ことができ、ディレクトリを別のディレクトリに変更す
ることができる。ディレクトリの中に何があるか調べる
ために、リスト（ＬＳＴ）を実行することができ、かつ
それがしばらくの間受は入れられていたか、この方法は
どちらかというと面倒である。

実際には、Ａ上にいてＢからファイルを複写することが
望ましい。ＣＰ（コピーの略）と呼ばれる既存のコマン
ドがあり、このコピーで「ＣＰＸ　　ＹＪと指定する。

Ｘ及びＹはファイル名である。Ｘは既存ファイルの名前
であり、Ｙは作成したい新しいファイルの名前である。

実際には、Ｘのコピーを作成し、それをＹと呼んでいた
。通常は、Ｘ及びＹは共にローカルである。それらは同
一マシン上のファイルであるが、Ｘ及びＹがローカルで
あるのか、リモートであるのか、両方がローカルである
か、それとも両方がリモートで、別の１つがローカルで
あるか、ソフトウェアが気づかないことが望ましい。両
方のファイルがリモートである場合、両方がマシンＢ上
にある必要はないので、５つ以上の組合せがある。Ｘが
マシンＢ上にあり、ＹがマシンＣ上にあってもよい。Ｃ
Ｐを用いてファイルのコピーを作成するときは、ローカ
ルでない、すなわちリモートのファイルを複写するため
、ローカル・マシン上で以前に使用していたのと同じコ
マンドを使う。問題は、コピーＣＰのようにＡ上でロー
カルにのみ作用することが常であるコマンドを実行する
とき、扱っているファイルがローカルであるか、それと
もリモートでＢまたはＣ上にあるかにシステムが気づか
ない形で、上記のことを実行する、すなわちＡにログイ
ンし、Ａの階層の名前空間内で作用して、ＢやＣ等のネ
ットワーク上の他のマシンの階層的名前空間にアクセス
する簡単な方法があるかどうかである。具体的に言うと
、ファイルを明示的に両方向に移動するためにＸＦＴＰ
またはＦＴＰを使用する必要はなく、ファイルを移動し
て仕事を行なうため、ｔｅｌｎｅｔ　またはｒｌｏｇｉ
ｎ　を使って別のシステムに実際にログインする必要は
ない。ローカル・マシン上にいるままで、リモート・フ
ァイルに対してＬＡＮ　）ランスペアレット・アクセス
ヲ行ナウことができる。ＬＡＮとはローカル・エリア・
ネットワークである。トランスペアレントとは、ファイ
ルがローカルであるのか、リモートであるのかを我々ま
たはコードが気づかないという意味である。アクセスと
は、これらのファイルの読取り及び書込みを行なえると
いう意味である。

このことは実際は、ノイマン等の特許出願に記載されて
いるように、ＤＳが行なう。ローカルＵＮＩＸシステム
上では、ハード・ディスクがあり、ＵＮＩＸでいわゆる
ファイル・システムを定義する。ファイル・システムは
ハード・ディスク全体の空間、またはハード・ディスク
上の空間の一部分に対応する。たとえば、ＲＴの場合の
ように、１７０メガバイトのハード・ディスクがある場
合、そのために１つのＵＮＩＸファイル・システムを２
個または３個または４個のＵＮＩＸファイル・システム
に分割することができる。ハード・ディスク上で持つこ
とができるファイル・システムの数にはある限界がある
。ここでは１７０メガバイトのハード・ディスク上に２
つのファイル会システムがあると仮定する。ＵＮＩＸ内
では、「ルート」はディレクトリであるだけでなく、フ
ァイル・システムにもなる。ディスク上にある量の空間
があり、そのファイル・システム内にあるサブディレク
トリ、ディレクトリおよびファイルもこの空間に含まれ
る。ＵＮＩＸに２つのファイル・システムがある場合、
１つの階層的名前空間がある。

ファイル・システムのすべてを１つの階層的名前空間で
表わすことが望ましく、通常は、その名前空間中でディ
レクトリを定義する。それが「マウント・ポイント」ａ
である。マウント・ポイントａの上に別のファイル・シ
ステムを「マウント」する。この例では、マウント・ポ
イントａはたまたまルートのサブディレクトリである。

第４図では、Ｂ上のファイル・システムは、頂部に点す
を有する三角形として示されている。ＤＳは、システム
Ａ上のマウント・ポイントａとシステムＢの新しいファ
イル上の点すを論理的に一致させる。

実際にはＡの下に２つのディレクトリがある。Ａのルー
ト・ファイル・システム「／」中にディレクトリがあり
、マウント・ポイントにサブディレクトリａがある。シ
ステムＢ内にはディレクトリｂ１すなわちマウントされ
るファイル・システムのルートがある。マウント動作を
実行すると、すなわち既存のディレクトリの上にファイ
ル・システムをマウントすると、より多数のファイルと
より多数のディレクトリを含むように、システムＡの階
層的名前空間が根本的に拡大される。システムＡ内の経
路を「／」からマウント・ポイントａに下り、「ｂ」で
マウントされたディレクトリに入るとき、ディレクトリ
変更コマンドＣＤを実行して、拡張された領域に入る。

ＵＮＩＸ上でファイル・システムに分けて入れるのが厄
介な理由は、ファイル・ローリングである。すべてのデ
ータを１つのディスクの１つのファイル・システムに入
れることは望ましくない。１つのファイル・システムに
は大量の活動があるが、別のファイル・システムには大
量の活動がない場合、大量の活動がないファイル・シス
テムをあまり頻繁にバックアップしなくてすむように、
より小さなファイル・システムに分けて入れることが望
ましい。大量の活動があるファイル・システムを多くバ
ックアップすることが望ましい。すべてを常時バックア
ップするのでなく、ファイル・システム内のディスク空
間を分割して、一部のファイルをバックアップしやすく
する。そうすると、ディスクの一部に障害があった場合
、すべてが失われることはなく、そのファイル・システ
ムのみが失われる。ＵＮＩＸ上の記憶域をバックアップ
するときは、それをプロファイル・システムとしてバッ
クアップする。この場合、１台のＵＮＩＸマシンがあり
、その上に１枚または複数のディスクがあり、各ディス
クには１つまたは複数のＵＮＩＸファイル・システムが
含まれる。ＵＮＩＸシステムに複数のディスクがある場
合、各ディスクに１つまたは複数のファイル・システム
があり、ルート・ファイル・システムと呼ばれる特別の
ファイル・システムがあり、他のファイル・システムは
、このルート・ファイル・システムの種々のディレクト
リ上にマウントされるサブ・トリーである。

ローカル・マシンでは、このようにして階層的名前空間
を拡張する。

ＵＮＩＸはこの単一の階層的名前空間を宵することに多
くを依存しており、ファイルを編集するとき、またはフ
ァイルを複写するとき使用される大部分のコマンドでは
、経路名を指定する。経路名は絶対経路名または相対経
路名である。絶対経路名は「／」で始まり、この階層ト
リーのルートから始まる。相対経路名には、ファイル・
ケースのオープン等、ディレクトリを変更するためのコ
マンドがある。ＣＤ（ディレクトリ変更）を実行して別
の場所に進むとき、そのディレクトリに関連する経路名
を指定することができる。これで、分散サービスの原理
を紹介するために必要な階層的ＵＮＩＸファイル・シス
テムの基礎的考察を終わる。

第４図で、システムＡ及びＢに命名するが、ここで問題
とするＡ上のディレクトリをｒａＪと名付け、Ｂ上のデ
ィレクトリをｒｂＪと名付けることにする。ノイマン等
の特許出願に記載されている分散サービスにより、Ａ上
にいて、ディレクトリ及びその下にあるものすべてをマ
シンｒＢＪからマシンＡ上のディレクトリ「ａ」上にマ
ウントすることができる。そのためのもう１つの方法で
は、マシンＢに進むと、「ｂ」と名付けられたディレク
トリが見つかり、「ｂ」の下に三角形が見える。その三
角形をファイル・システムとは見ず、ｒｂＪの下にある
すべてのディレクトリ及びファイルであると見なす。実
際には、ハサミでｒｂＪの上を切り、それを移動し、「
ａ」の真上に置く。

そのためのもう１つの方法では、「ａ」からｒｂＪに点
線を引き、点線上のｒｂＪの近くに矢印を付ける。これ
とは、マシンＡ上にいて、マシンＢ上のファイルにアク
セスしようとして、マシンＡの「ａＪ上にリモート・デ
ィレクトリがマウントされた経路を下って進む場合、「
ａ」に至ると、分散システム（ＤＳ）は自動的に第１図
の点線を経て進み、「ｂ」の下のファイル及びディレク
トリにアクセスするという意味である。これで、ローカ
ル・ディレクトリの上にリモート・ディレクトリが「マ
ウント」されることになる。ＤＳは、リモート・ディレ
クトリをローカル・ディレクトリの上にマウントさせ、
またはリモート・ファイルをローカル・ファイルの上に
マウントさせる。ちなみに、ＤＳはまた任意のローカル
・ディレクトリを別のローカル・ディレクトリの上にマ
ウントさせ、または任意のローカル・ファイルを他の任
意のローカル・ファイルの上にマウントさせることもで
きる。

リモート・マウントを実行し、ＣＰコピー・コマンドを
使ってローカル・ファイルを、たとえば、／　ｔｅ＋＊
ｐ　／ｘ　（−時ディレクトリ中のＸと名付けられた一
時ファイル）に複写し、かつそれを７ｂ／にに複写しよ
うとする場合、リモート・マウントを実行した後で、ロ
ーカル・ファイルをリモート・ファイルに複写する。こ
うしたのは、既にリモート・マウントが実行済みだから
である。これが分散サービス、すなわち、リモート・マ
ウントである。別の言い方をすれば、仮想マウントであ
る。仮想とは、実際にマウントを行なわないが、マウン
トを行なったように見えるという意味である。その場合
、実際にはファイル・システムをマウントせず、ディレ
クトリまたはファイル（リモートでよい）をマウントす
る。

第２図のマシンＡ上にいて、マシンＢにあるすべてのフ
ァイルにアクセスしようとしているものとする。３台の
マシンＡ、Ｂ及びＣがあり、Ａ上では通常はＡファイル
にしかアクセスできず、Ｂ上ではＢファイルにしかアク
セスできず、同様に、Ｃ上にいるときは、Ｃファイルに
しかアクセスできない。Ａ上にいて、すべてのＢファイ
ルにアクセスしたいものと仮定する。そのための１つの
方法では、Ａのルートのサブディレクトリを作成してそ
れをＢと名付け、したがって、マシンＡ上に他方のマシ
ンのディレクトリの名前であるＢと名付けたディレクト
リを設ける。ＢのルートをＡのディレクトリ／Ｂの上に
マウントする。第２図で、／ＢをＡ上にマウントするこ
とは、／ＢからＢのルートに至る破線で表わされ、矢印
がＢのルートの近くに付いている。／Ｂの下にある三角
形はＢの階層的名前空間である。リモート・マウントｒ
ｒｍｏｕｎｔＪまたはｒｖｍｏｕｎｔＪの結果、Ａ上に
いてＢ上の任意のファイル名を指定したい場合は、その
前に／Ｂを付けるだけでよい。同様に、Ａ上にいてシス
テムＣ上の任意のファイル名を指定したい場合は、Ｃと
いう名前のＡのルートのサブディレクトリを作成し、Ｃ
のルートを／Ｃという名のＡのディレクトリの上にｒｖ
ｍｏｕｎｔＪ　　（仮想マウント）する。このことは、
第２図で／ＣからＣのルートに至る破線で表わされる。

任意のマシン、たとえば、Ａ上にいる場合、ＤＳのリモ
ート・マウント機能により、他の任意のマシンにある任
意のファイルの名前を指定することができる。これが、
ＤＳ機構の１つの使い方である。それを実行すると、す
べてのファイルにアクセスすることができる。

これはＤＳの１つの使い方であり、他にも有用な機能が
ある。

ＵＮ　Ｉ　Ｘは、通常は／　ｕｓｒ　／　ｍａｎ　と呼
ばれるファイルにオンライン・マニュアルが入っており
、その下に通常は大きなディレクトリがある。あるコマ
ンドのマニュアル・ページを画面に表示したい場合、コ
マンド名ｒｍａｎＪ　　（マニュアルの略）を使用し、
そのコマンド名を入力する。たとえば、問題のコマン°
ドがＣＰ（コピーの略）という名のコマンドであり、Ｃ
Ｐのマニュアル・ページをマシン上で見たい場合は、「
層ａｎＣＰＪと入力すると、画面上にＣＰのマニュアル
・ページが表示される。

オンライン・マニュアル・ページは／　ｕｓｒ　／　ｍ
ａｎに記憶され、５ないし１０メガバイトの資料である
。ローカル・エリア・ネットワーク上に、少数のディス
クを備えたマシンと多数のディスクを備えたマシンがあ
るものとする。多数のディスクを備えたマシンを、ファ
イル・サーバと呼ぶ。他のマシンは余り大きなディスク
空間を持たない。オンライン・マニュアルをすべての単
一システムに記憶する必要はなく、１つの場所に記憶す
るだけでよい。ファイル・サーバ・マシン上で、オンラ
イン・マニュアルを／　ｕｓｒ　／　＠ａｎの下に置く
。

オンライン・マニュアルを記憶するマシンをサーバと呼
び、オンライン・マニュアルを記憶しないマシンはクラ
イアントと呼ぶ。第３図に示すように、クライアント・
マシン上には、ル−トすなわちスラッシュで始まる階層
的名前空間があり、その下にｒｕｓｒＪと呼ばれるサブ
ディレクトリがあり、ｒｕｓｒＪの下にｒｍａｎＪと呼
ばれるサブディレクトリがあり、「■ａｎＪＯ下には何
もない。ｒｍａｎＪはクライアント・マシン上のディレ
クトリであるが、その下には何もない。実際のマニュア
ルにアクセスするには、マニュアルを含むディレクトリ
をサーバからクライアントにｒｖｍｏｕｎｔＪまたはｒ
ｒｍｏｕｎｔＪする。コマンドｒｖｍｏｕｎｔ　Ｊでは
２つの経路名を指定する。第３図で、クライアント・マ
シン上でスタブ・ディレクトリ／　ｕｓｒ　／ｍａｎか
ら破線が引かれている。サーバ・マシン上にも同じディ
レクトリ／　ｕｓｒ　／　ｍａｎがあるが、／　ｕｓｒ
　／ｍａｎの下にさらにマニュアル（三角形で表わされ
ている）がある。ｒｖｍｏｕｎｔ　Ｊはクライアントの
ｒ　ａ＋ａｎ　ＪからサーバのｒｍａｎＪに至る破線で
表わされる。クライアント・マシン上にいて、やはりｒ
ｍａｎＪという名のコマンドを実行することをｒｍａｎ
　ＣＰＪと言う。すると、実際のマニュアル・ページは
ローカルではなくリモートなので、ＤＳは移動して、サ
ーバからそれらのファイルにアクセスし、ファイルがロ
ーカルである場合と同様にファイルを得ることができる
。すなわち、リモート・ファイルに対するトランスペア
レント・アクセスを行なったことになる。

上記の考察では、ＤＳの２つの異なる使い方を示した。

すなわち、ユーザは、自分のローカル・エリア・ネット
ワーク内にある任意のマシン上の任意の階層的名前空間
に任意の名前のファイルを作成することができる。ユー
ザはまた、自分がそのための空間を持たないファイルを
遠隔的に記憶し、ポインタでそれに遠隔的にアクセスで
きるように、自分の名前空間をカストマイズすることが
できる。このことはオンライン・マニュアルのようなも
のにとって特に有用である。ソフトウェアの開発を行な
う場合、または、ローカル・エリア・ネットワーク中の
ように多数の人々が共通データ・ベースを共用し、各人
は同一のローカル・マシン上にすべてを記憶する必要が
ない場合にも有用である。それがローカルである場合と
同様にそれにアクセスすることができる。これで分散シ
ステムの簡単な説明を終了する。以下では本発明に対象
を絞って説明する。

本発明は、ＤＳと互換性がある監視及び監視証跡圧縮を
ネットワーク全体にわたって実行するものである。ＤＳ
環境では、監視証跡はローカルでもリモートでもよい。

本発明は多数のマシンを含むＬＡＮで使用するこきがで
き、同じ監視証跡ファイルに監視証跡レコードを付加す
るマシンが複数台存在することができる。同一ファイル
に監視証跡レコードを追加するマシンが多数あってもよ
い。

そのような監視システムでは、監視証跡レコードは非常
に速く累積し、ディスク空間を一杯にする傾向がある。

大きなディスク空間を持たない小型の作業端末を持つ場
合は、そこで監視証跡ファイルを定義することはできる
が、ディスク空間はすぐに一杯になり、ディスク空間を
毎日または毎週やり繰りしなければならない。監視証跡
サーバと名付ける１台のマシンをネットワーク内に設け
ることが好ましい。サーバ・マシンは大きなディスク空
間を有する。たとえば、５００メガバイトを保持できる
大容量ビデオ・ディスクをサーバ上で使用することがで
きる。その１つを監視証跡サーバとして指定し、ネット
ワークのすべてのフライアン）−ノードに監視証跡デー
タをサーバに供給させる。ビデオ・ディスクの特性の１
つは、１回書込み媒体であることである。すなわち、デ
ィスク上に一度書き込むことはできるが、書直しするこ
とはできない。ファイルに新しいデータを付加し続ける
が、このことは、たとえば、監視で監視証跡ファイルと
して使うことと矛盾しない。

本発明の特徴の１つとして、ファイル位置についてトラ
ンスペアレントであることが含まれる。

監視されるファイル名またはディレクトリ名は、ローカ
ルでもリモートでもよい。さらに、本発明では、多数の
ノードが１つの監視証跡ファイルに監視レコードを付加
するのに対応できる。さらに、本発明では、監視体系で
圧縮を行なうとき、レコードを監視証跡ファイルに載せ
る前に、レコードを圧縮する。本発明では一時に１つの
レコードを圧縮するのではなく、小さなレコード・ビン
を一杯にする。各ビン（ｂｉｎ）に収容できるバイト数
には上限があり、たとえば開示された実施例では２ｏｏ
ｏｏバイトである。ビンが一杯になると、ビン全体に対
して圧縮を行ない、次に、圧縮されたビンを監視証跡フ
ァイルに付加する。本発明では、監視証跡は一連のビン
から成る。ここで使用する圧縮技術は、ＵＮＩＸオペレ
ーティング・システムで使用可能なＰＡＣＫと呼ばれる
コマンドである。本発明の監視サブシステムは、ＤｏＤ
オレンジ・ブックのクラスＣ２ないしＡ１に対する要件
を滴定する。本発明では、システム１台当り１回の監視
デーモン・プロセスを使って監視証跡ログのオンライン
圧縮を実行する。

次に、本発明の監視がどのように働くかの一例を示す。

この例では、第１図に示すように、３つのノードがある
。ノードとはマシンであり、各ノードをＡｌＢ及びＣと
名付ける。それらのノードは第１図で左から右に示され
ている。ＡｌＢ及びＣと呼ばれる各ノードにノードＩ　
Ｄ　（ｎｉｄ）が関連づけられているものとする。Ａの
ｎｉｄは番号であり、この例では、それを２２２とする
。この例のＢのｎｉｄは３３３であり、Ｃのｎｉｄは４
４４である。ＩＢＭ　ＲＴ　　ＰＣでは、ｎｉｄはたと
えば３２ビツトの整数である。第１図に、Ａ上のファイ
ル・システム名前空間の階層的名前空間が示されている
。ここではＡ上の４つのファイルだけについて問題にす
るが、それらは長い経路名を持つ。

ここで問題とするＡの第１のファイルは実際にはＡの事
象テーブルの名前である。Ａの事象テーブルはこの場合
／　ｅｔｃ　／　５ｅｃｕｒｉｔｙ　／　ａｕｄｉｔ　
／Ｂ　ｅｖｅｎｔである。マシン上で、必要な場合、マ
シンごとの事象を指定できることが望ましいので、各マ
シンにそれ自体の事象テーブルを設けである。

もう１つの方法は、すべてのマシンで同じ事象セットを
使用できるようにすることであり、１台のマシンを実際
の事象テーブルを記憶する監視サーバまたはファイル・
サーバを含むマシンとして指定し、その事象テーブルを
各クライアント・マシンにｖｍｏｕｎｔする０ 他のマシンからアクセスされることが望ましくないもう
１組の経路名がローカル・マシン上にある。これらのフ
ァイルはローカ゛ルのみである。すなわち、これらのフ
ァイルを参照するとき、それらがローカル・マシン上に
記憶されているかどうか、あるいはローカル・マシンに
記憶されている場合、それがそれらのファイルのＡ上の
コピーであるかどうかを確認することが望ましい。マシ
ンＡにいるユーザは、他のマシン（ＢまたはＣ）が特定
のローカル・ファイルにアクセスできることを望まない
。それらを入れる場所は、／　１ｏｃａｌ　　と呼ばれ
るＡ上のディレクトリ中にある。「ローカル」という語
はここでは、Ａにとってそれらのファイルのノードに特
宵なコピーがあることを意味する。同様に、マシンＢ上
で、ユーザは／　１ｏｃａｌデイレクトリを持つことが
でき、その下のファイルはＢに対してノード特をである
。

Ａ　／　１ｏｃａｌ　の下に％　／　１ｏｃａｌ　／　
ｅｔｃ　／　５ｅｃｕｒｉｔｙ／　ａｕｄｉｔがある。

／　ａｕｄｉｔはここではディレクトリであり、／　ａ
ｕｄｉｔの下に３つのファイルがある。ａ　５ｔａｔｅ
が第一のファイルであり、オンになった１組の事象を含
む。この／　ａｕｄｉｔの下の第２のファイルはａ　ｔ
ｒａｉｌ　であり、これは現在の監視証跡の名前を含み
、さらに、監視が他方の証跡に対してオンになったとき
のタイムスタンプの名前を含む。第３のファイルはａ　
ｔｒａｉｌ、ｐａｓｔであり、ノードＡに対する監視証
跡ファイルの活動記録、及び対応する開始及び終了タイ
ムスタンプを含む。そこに他の情報が含まれることもあ
る。

同様に、ノードＢ上にも、同種のディレクトリ構造があ
る。このディレクトリ構造には／　ｅｔｃ　／５ｅｃｕ
ｒｉｔｙ　／　ａｕｄｉｔ　／　ａ　ｅｖｅｎｔの下に
テーブルがあり、３つのファイルがあるｏ　　／　１ｏ
ｃａｌ　／　ｅｔｃ　／５ｅｃｕｒｉｔｙ　／　ｅｖｅ
ｎｔ　／　ａｕｄｉｔの下のノードに特有なファイルで
ある、５ｔａｔｅファイルとｔｒａ　ｉ　１　ファイル
とｔｒａｉｌ、ｐａｓｔ　ファイルである。

この例では、マシンＡ及びＢで監視をオンにし、監視証
跡ファイルをマシンＣ上に置く。この例では、マシンＣ
からの監視レコードはないが、必要な場合、マシンＣ上
で監視をオンにし、同じ監視証跡ファイルを指定するこ
とができる。Ｃ上に階層的名前空間があるものと仮定す
る、そこでは、スラッシュがルートであり、その下に／
　ａｕｄｉｔという名のディレクトリがあり、さらにそ
の下にＸという名のファイルがある。Ｘというファイル
名が監視証跡フ、アイルの名前になる。Ａ上で監視をオ
ンにし、監視証跡ファイルがＣ上で／　ａｕｄｉｔ／Ｘ
という名のファイルになるように指定する。

同様に、マシンＢ上で監視をオンにするときは、監視証
跡ファイルがマシンＣ上で／　ａｕｄｉｔ　／　ｘとい
う名のファイルになるように指定し、Ｃ上で監視をオン
にする場合は、監視証跡ファイルが／　ａｕｄｉｔ　／
　ｘとなるように指定することができる。

このことを実行する方法は次の通りである。

マシンＡ上で、／ａｕｄｉｔという名のルートのサブデ
ィレクトリを定義する。同様に、Ｂ上で／ａｕｄｉｔ　
という名のルートのサブディレクトリを定義する。マシ
ンＣ上の／　ａｕｄｉｔ　という名のディレクトリをＡ
及びＢ上のそれらのローカル・ディレクトリ・スタブの
上にｖｍｏｕｎｔする。第１図で、Ａ上に／　ａｕｄｉ
ｔがあり、Ａ上のその／　ａｕｄｉｔからＣ上の／　ａ
ｕｄｉｔに至る破線が引かれている。

同様にマシンＢ上で、Ｂ　／　ａｕｄｉｔの上にＣ／ａ
ｕｄｉｔをｖｍｏｕｎｔする場合、ＢからＣに至る点線
が引かれ、Ｃの下の／　ａｕｄｉｔ上に矢印がついてい
る。マシンＡ上では、／　ａｕｄｉｔはリモート・ディ
レクトリである。本発明では、監視証跡はローカルでも
リモートでもよい。この例の監視証跡は／ａｕｄｉｔ　
／　ｘである。そのファイルがリモートであっても、ま
たは、そのファイルを含むディレクトリがリモートであ
っても構わない。

本発明では、監視証跡レコードを圧縮する。監視証跡レ
コードをビンに書き込むが、ビンが一杯になるか、また
は−杯に近づいたとき、別のビンに移り、次にそれを溝
たし始める。これらのビンに名前を付けなければならな
い。これらのビンは階層的名前空間内のファイルなので
、それらのための場所を選択しなければならない。さら
に、各マシンＡ、Ｂ及びＣ上で、監視デーモンと呼ばれ
るもう１つのプロセスが実行される。ビンを実際に圧縮
し、圧縮されたビンを監視証跡ファイルに付加するのは
監視デーモンである。監視証跡ファイルは、第５図では
水平線でフレームに分割された長い柱状体で示されてい
る。−容土の行は、それがバイト０ファイルであること
を示している。

これらのフレームはそれぞれ圧縮されたビンを含む。監
視デーモンは一時に１つのレコードヲ圧縮せず、レコー
ドのビン全体を受は取り、ビンを圧縮し、圧縮された監
視レコードのビンをこの監視　゛証跡ファイルに付加す
る。監視証跡ファイル内の各フレームは、圧縮されたビ
ンに加えて、小さなヘッダ及び小さなトレーラ（テール
）を含む。小さなヘッダは一定の形式を有し、小さなト
レーラは同じサイズで別の一定の形式を有する。ビン・
ヘッダは、圧縮されたビン中にどれだけ多くのバイトが
あるか、及びそのビンの出所のｎｉｄを示す。

フレーム上のヘッダは圧縮されていないので、特定のノ
ードまたはｎｉｄからのレコードを探して監視証跡を順
方向に走査する場合、問題とするノードからのレコード
の圧縮されたビンかそうではないのか、ファイルの始め
にある現在のヘッダを調べるだけでよい。そうである場
合は、その内容を読み取る際に行なわなければならない
ことをすべて行なう。問題のノードでない場合は、次の
圧縮されたビンに進むのに何バイト飛び越せばよいかを
正確に知る。次の圧縮されたビンも同様のヘッダを有す
る。

これらの各ビンにトレーラを設ける理由は、監視ファイ
ルを逆方向に読むのに役立つからである。

このファイルを逆方向に読む理由は回復時にある。

監視を行なっていてマシンの１台が故障するかまたは監
視証跡を含むマシンが故障した場合、最終的にマシンを
再ブートするかまたはマシンを再び稼働させるときに、
圧縮を行なうデーモンは、自分がどの状態にあるかを判
定して動作を再開しなければならない。このことを行な
うため、デーモンは、どのビンを終了し、どのビンを次
に取り上げるかを判定しなければならない。その情報の
一部を、デーモンは監視証跡ファイルを逆方向に読み取
って判定する。

第１図では、マシンＡの下に問題とするファイル用の階
層的名前空間がある。Ｂ及びＣについても同様である。

Ｃの下にあるものはわずかに異なっている。ＡとＢは同
じであるが、Ｃは異なる。Ａのｎｉｄは２２２であり、
Ｂのｎｉｄは３Ｂ３であったことを思い起こされたい。

マシンＣ上では次のようにする。監視証跡が／　ａｕｄ
ｉｔ　／　ｘであると指定した場合、Ｘが実際の監視証
跡ファイルになり、これは、最終的に圧縮されたビンの
シーケンスを含むことになるファイルである。各ビンは
異なるノードからのものでよく、これらのビンを監視証
跡ファイルに付加するとき、ＵＮＩＸ上で原子的にそう
することができる。すなわち、書込みを行なうとき、同
時に１つまたは２つの監視デーモンが２つのプロセスに
書き込もうとする場合、ＵＮＩＸ上ではこれらの書込み
が直列化されるのに、衝突はない。したがって、一方の
ビンが最初に入り、他方が次に入る。

しかし、監視動作を実行するマシン２台以上ある場合は
、それらは互いのビン・ファイル上に書込みを行なわな
いので、ビンにどう名前を付けるかという問題が残る。

本発明によれば、ノードごとにビン・ファイルを分離す
る。それらを分離するための１つの場所は／　ａｕｄｉ
ｔの下である。１ａｕｄｉｔの下に単なるファイルを作
成する代わりに、／　ａｕｄｉｔの下に一部ビン・ファ
イルのディレクトリを作成し、それに、たとえばこれら
のビン・ファイルを作成するノード、たとえばノードＡ
１に対応するｎｉｄを名前として与える。さらに、マシ
ンＡに対応する／　ａｕｄｉｔのサブディレクトリの下
にビン・ファイルを置（。マシンＣ上に、１ａｕｄｉｔ
　／　２２２または／　ａｕｄｉｔ　／　、２２２と呼
ばれるディレクトリを設ける。ピリオド付きのファイル
名の名前が衝突する可能性は少ない。／　ａｕｄｉｔ　
／、２２２の下に、マシンＡに対する一部ビン・ファイ
ルを設ける。同様に、マシンＣ上のｎｆｄが３３３であ
るマシンＢに対しては、／　ａｕｄｉｔ　／　、３３３
という名のディレクトリを設け、その下にマシンＢに対
する一部ビンを置く。一連の番号、たとえば０から９９
９まで順次カウントする共通の接頭部及び接尾部を用い
てビン・ファイルを０名付けることができる。この例で
は、−時ビン・ファイル名の接頭部としてトレール・フ
ァイル名、たとえば、Ｘを使用する。−時ビン・ファイ
ル名の接尾部として、ピリオドが前についた３桁の１０
進数を使用する。これらの１０進数は０００から９９９
に進み、次に０００に戻る。各ディレクトリ・ファイル
には小さな制御ファイル（この例では、ｘ、ｃｔｌ　）
　、たとえば、／　ａｕｄｉｔ　／　、２２２　／　ｘ
、ｃｔｌ（このビン・セットに対する制御ファイル）も
含まれる。制御ファイルは、次に使用すべきビンは何か
についての情報を与える。一般に、監視デーモンがオン
であり、監視デーモンがビンを圧縮するときは、ビンが
一杯になってシステムが別のビンに移るまで、監視デー
モンは一般にビンを圧縮しないので、ビン・ファイル番
号が９９９から０００に戻る際に問題はない。監視デー
モンが一部ビン・ファイルを圧縮した場合、監視デーモ
ンは圧縮されたビンを／　ａｕｄｉｔ　／ｘ　という名
の実際の監視証跡ファイルに書き込み、次にそのビンを
たとえば／　ａｕｄｉｔ　／　、２２２　／　ｘ、１２
３から消去する。

監視デーモンはビンを順次調べる。監視デーモンが行な
うべき仕事がない場合、監視デーモンは休止する。監視
デーモンがビンを圧縮するとき、圧縮されたビンを実際
の監視証跡ファイル、この例では／　ａｕｄｉｔ　／　
ｘに付加する。このようにして、監視デーモンによる監
視を必要とする事象が発生している間に、未圧縮のビン
を、たとえば／　ａｕｄｉｔ／　、２２２の下に一時的
に記憶することができる。後に、事象が発生していない
ときに、監視デーモンは一部ビン・ファイルを圧縮し、
それらを実際の監視証跡ファイル／　ａｕｄｉｔ　／　
ｘに書き込むことができる。

ビンはマシンＣ上に記憶されているが、マシンＡのビン
に作用する監視デーモンは、実際にはマシンＡのデーモ
ンである。マシンＡのデーモンは特定の１組のビンにつ
いて知っており、ビンがローカルであるかそれともリモ
ートであるかを気にせずに、その仕事を実行する。この
例では、Ａのデーモンが、マシンＣの／　ａｕｄｆｔ　
／　、２２２の下に記憶されたビンに作用し、Ｂのデー
モンがマシンＣの／　ａｕｄｉｔ　／　、３３３　の下
に記憶されたビンに作用する。マシンＣに対する監視を
オンにした場合、そのデーモンはマシンＣ上の／　ａｕ
ｄｉｔ　／　、４４４という名のサブディレクトリの下
のビンに作用する。

これらのデーモンは異なる場所に作用する。デーモンが
実際の監視証跡ファイルに圧縮されたビンを付加しよう
とするとき、ＵＮＩＸでｒｗｒｉｔｅＪと呼ばれるシス
テム・コールを呼び出し、それを１回の原子的書込みで
書く。２つのデーモンが同時にその実際の監視証跡ファ
イルに書き込もうとする場合、それらは直列化される。

これで、本発明に従って２つまたは３つのシステムがリ
モート監視証跡ファイルに書き込む°例を終わる。

第７図は、クライアント・プロセッサＡ１クライアント
・プロセッサＢ及びサーバ・プロセッサＣを相互接続す
るネットワーク１を示す本発明の構成図である。第７図
かられかるように、クライアント・プロセッサＡは、た
とえば、ＵＮＩＸに類似のオペレーティング・システム
であるオペレーティング・システム４Ａのもとで実行さ
れるアプリケーション・プログラム２Ａを有する。クラ
イアント・プロセッサＡで稼働する分散サービスθＡは
、ノイマン等の上記の特許出願に記載されているように
、分散ネットワーク環境でリモート・ファイルにアクセ
スするためのシステム及び方法を提供する。クライアン
ト・プロセッサＡ内の監視デーモン８Ａは、事象テーブ
ルＩＯＡで定義された事象を使って、クライアント・プ
ロセッサＡで実行されている、監視しなければならない
動作を識別する。監視デーモン８Ａは監視レコードを発
生し、それらの監視レコードは、上述のように、分散サ
ービス６Ａの作用により、サーバ・プロセッサＣの一部
ビン・ファイル１２Ａに記憶される。

同様に、クライアント・プロセッサＢ内のアプリケ−シ
ロ７２Ｂ１オペレーテイング・システム４Ｂ１分散サー
ビス６Ｂも、クライアント・プロセッサＡの対応する部
分と同様の方式で動作する。クライアント・プロセッサ
Ｂ内の監視デーモン８Ｂは、事象テーブル１０Ｂで定義
された事象を使って、クライアント・プロセッサＢで実
行される動作を監視する。監視デーモン８Ｂによって発
生された監視レコードは、前述のように、分散サービス
８Ｂの作用により、サーバ・プロセッサＣの一部ビン・
ファイル１２Ｂに記憶される。サーバ・プロセッサＣ内
のアプリケージタン２Ｃ，オペレーティング・システム
４Ｃ１分散サービス６Ｃも、クライアント・プロセッサ
Ａの場合と同様な方式で動作する。監視デーモン８Ｃは
、事象テーブル１０Ｃで定義された事象を使って、サー
バ・プロセッサＣで実行される動作を監視する。監視デ
ーモン８Ｃは、サーバ・プロセッサＣ内での動作のため
に発生された監視レコードを、サーバ・プロセッサＣの
一部ビン・ファイル１２Ｃに記憶する。

前述したように、監視デーモン８Ａ及びクライアント・
プロセッサＡはサーバ・プロセッサＣ内の一部ビン・フ
ァイル１２Ａの内容を定期的に調べ、未圧縮の監視レコ
ードのビンがあるがどうか判定する。監視デーモン８Ａ
は次いでその圧縮動作に移り、−時ビン・ファイル１２
Ａ内の未圧縮のビンを選択し、それらのビンの内容を圧
縮し、次いで適当なヘッダ及びトレーラを付けた圧縮さ
れたビンを、前述のように分散サービス６Ａの作用によ
り、永久的なまたは実際の監視証跡ファイル１４に付加
する。同様にして、クライアント・プロセッサＢの監視
デーモン８Ｂは、サーバ・プロセッサＣの一部ビン・フ
ァイル１２Ｂの内容を定期的に調べて、クライアント・
プロセッサＢからの未圧縮の監視レコードのビンがある
かどうか判定する。−時ビン・ファイル１２Ｂ内に未圧
縮のビンが見つかると、監視デーモン８Ｂは、分散サー
ビス６Ｂの作用により、−時ビン・ファイルＢ内の選択
されたビンに対して圧縮動作を行ない、次いで圧縮され
たビンを適当なヘッダ及びトレーラ部分を付けてサーバ
・プロセッサＣ内の永久的または実際の監視証跡ファイ
ル１４に付加する。監視デーモン８Ｂは、前述したよう
に分散サービス６Ｂの作用により、このことを行なう。

監視デーモン８Ｃは同様にして、−時ビン・ファイル１
２Ｃの内容を定期的に調べて、圧縮し、適当なヘッダ及
びトレーラ部分と共に永久的監視証跡ファイル１４に付
加すべき未圧縮のビンがあるかどうが判定する。

本発明のＡＩＸ実施例の詳細な説明 ＵＮＩＸオペレーティング・システム（ＵＮ　ＩＸはＡ
Ｔ＆Ｔベル研究所の商標）及びＵＮＩＸに類似のオペレ
ーティング・システムは、ＤｏＤトラステッド・コンピ
ュータ・システム評価基準（「オレンジ・ブック」とも
呼ばれる）（１９８５年１２月）のクラスＣ２ないしＡ
１に対する監視要件を満足する監視サブシステムを必要
とする。

この監視サブシステムは、以下の設計要件及び特性をす
べて満足するものでなければならない。

（ａ）　　ソフトウェア環境要件 階層的ファイル・システム、及びｗｒｉｔｅ　（）シス
テム・コール等の原子書込み動作を含むＵＮＩＸ（また
はＡＩＸまたはＵＮＩＸ類似）オペレーティング・シス
テム環境で稼働し、かつ 「仮想マウント」または「リモート・マウント」に基づ
く機構（たとんば、ＩＢＭＲＴＰＣＡＩＸ分散サービス
（Ｄｓ））等、ローカル／リモート・ファイル／ディレ
クトリ位置についてトランスペアレントなオペレーティ
ング・システム環境で稼働する。

（ｂ）安全保護環境 オレンジ・ブックのクラスＣ２ないしＡ１に対する監視
要件を満足するのに役立つ監視フレームワークを提供す
る。

（ｃ）発明の特徴 システムごとに１つの監視デーモン・プロセスを使って
監視証跡ログ・ファイルのオンライン圧縮を実行し、ノ
ード故障後に回復する再始動可能監視デーモンを備え、
Ｄｓまたは類似の機構により、ファイル／ディレクトリ
位置についてトランスペアレントであす、ＤＳまたは類
似の機構により、多数のノードが監視レコードを１つの
監視証跡ログ・ファイルに付加するようにさせ、 ｌｏｇｉｎ−Ｌ−ザＩＤを捕捉し、擬似ユーサ類似ルー
トとしてｌｏｇｉｎすることを防止するが、ｓ　ｕ　（
ｒｓｕｂｓｔｉｔｕｔｅ　ｕｓｅｒＪコマンド）は擬似
ユーザ類似ルートに受は入れることができる。

（ｄ）その他の特性 監視証跡ログ・ファイルを１回書込み媒体に載せ、かつ
監視サブシステムのオペレーティング・システムのカー
ネル部分に周知のファイル名を持たず、さらに、対応す
るベース事象が使用可能になり、実行される場合は、シ
ステム・コールごとに丁度１つの監視証跡レコードをカ
ットする。

】」し邂え叫 本発明をＡＩＸオペレーティング・システムで実施する
場合について、本発明の説明を行なう。−ここではＡＩ
Ｘオペレーティング・システムの文脈で本発明を説明す
るが、本発明はどんなＵＮＩＸオペレーティング・シス
テムやＵＮＩＸ［ｔのオペレーティング・システムにも
適用される。

監視サブシステムのアーキテクチャ 本節では、監視サブシステムのアーキテクチャについて
説明する。「アーキテクチャ」とは、最も外側の（すな
わち、ＡＩＸシステム）モジュールに対するユーザ及び
プログラマ・インターフェースを意味する。このアーキ
テクチャを定義するため、■ＢＭＲＴ　ＰＣＡＩｘオペ
レーティング・システム・コマンド解説書、第２版、１
９８Ｅ！年、及びＩＢＭ　ＲＴ　ＰＣＡＩＸオペレーテ
ィング・システム　術解説　、第１版、１９８５年、か
ら監視サブシステム「マニュアル・ページ」を列挙して
再掲し、さらにＡＩＸ監視サブシステムの経路名を列挙
する。

且盈 下記に、ＡＩＸ監視サブシステムのアーキテクチャを定
義するＡＩＸｒマニュアル・ページ」名を列挙する。

コマンド： ａｕｄｉｔ　　　　　監視サブシステムを制御するａｕ
ｄｉｔｄ　　　　　監視データの圧縮を行なうａｕｄｉ
ｔｐｒ　　　　　ｒ濾過された」監視証跡ファイルを表
示する システムφコール： ａｕｄｉｔ　　　　　監視を使用可能及び使用禁止にす
る ａｕｄｉｔｅｖｅｎｔｓ　　システムの監視事象をゲッ
トし、セットする ａｕｄｉｔｌｏｇ　　　　監視レコードを監視証跡ファ
イルに付加する ａｕｄｉｔｐｒｏｃ　　　処理の監視状態をゲットし、
セットする ファイル形式： ａ　ｅｖｅｎｔ　　　　管理事象をベース事象と関連づ
ける ａ−ｓｔａｔｅ　　　　一般監視事象及び特殊監視事象
を記録する ａｕｄｉｔ　　　　　監視証跡ファイル形式を記述する
。

参照の便宜上、下記にＡＩＸ監視サブシステムにおける
経路名を列挙する。

監視ディレクトリ： ／ｅｔｃ／５ｅｃｕｒｉｔｙ／ａｕｄｉｔシステム監視
テーブル用（監 視証跡ファイル自体ではない） ／１ｏｃａｌ ノード特有のファイル用 監視テーブル： ／ｅｔｃ／５ｅｃｕｒｉｔｙ／ａｕｄｉｔ／ａ　ｅｖｅ
ｎｔ監視事象テーブル ／１ｏｃａｌ／ｅｔｃ／５ｅｃｕｒｉｔｙ／ａｕｄｉｔ
／ａ　５ｔａｔｅ監視状態 ／１ｏｃａｌ／ｅｔｃ／５ｅｃｕｒｉｔｙ／ａｕｄｉｔ
／ａ−ｔｒａｉｌ監視証跡名 ／１ｏｃａｌ／ｅｔｃ／５ｅｃｕｒｉｔｙ／ａｕｄｉｔ
／ａ　ｔｒａｉｌ、ｐａｓｔ監視証跡名の活動記録 監視ヘッダ・ファイル： ／ｕｓｒ／１ｎｃｌｕｄｅ／ｓｙｓ／ａｕｄｉｔ、ｈ監
視システム・コール用の定 義 ／ｕｓｒ／１ｎｃｌｕｄｅ／ｓｙｓ／ａｕｄｉｔｄ、ｈ
監視デーモン及びカーネル用 の定義 ／ｕｓｒ／　ｉｎｃ　１ｕｄｅ／ｓｙｓ／ａｕｄ　ｉｔ
ｋ　、　ｈカーネル内での監視用の定義 ／ｕｓｒ／　ｆｎｃ　１ｕｄｅ／ｓｙｓ／ａｕｄ　ｉｔ
　ｌｏｇ　、　ｈ監視ログ・レコード用ノ定義 監視コマンド： ／ｕｓｒ／ｂｉｎ／ａｕｄｉｔ 監視サブシステムを制御する ／ｕｓｒ／ｂｉｎ／ａｕｄｉｔｐｒ 監視証跡ファイルを書式化す る 監視デーモン： ／ｅｔｃ／ａｕｄｉｔｄ　　監視デーモン次に、上記リ
ストの用語を使って監視サブシステムを説明する。

監視コマンド及び監視テーブル 監視コマンドは監視サブシステムを制御する。

監視コマンドはスーパーユーザだけが呼び出すことがで
きる。監視コマンドは、監視を使用可能にし、監視証跡
ファイルを指定し、監視が既に使用可能になっていると
き監視証跡ファイルを切り換え、監視サブシステム全体
を使用禁止にし、一般クラス及び特別クラスのユーザに
対してどの（管理またはベース）事象が監視されるかを
指定し、一般クラスと特別クラスのユーザまたはグルー
プを区別し、監視サブシステムの状況を問い合わせ、監
視証跡ファイルの活動記録を問い合わせ、一般事象また
は特別事象、または特別ユーザまたは特別グループの組
をクリアする。

監視事象を指定し、２クラスのユーザを区別する目的は
、後で濾過（すなわち、選択的減少）しなければならな
い不要なレコードで監視証跡ログ・ファイルをあふれさ
せるのではなく、監視証跡ログ・ファイル・レコードを
事前に濾過（すなわち、選択的収集）するのを助けるこ
とである。

監視コマンドは以下のファイルを使用する。

／　ｅｔｃ　／　５ｅｃｕｒｉｔｙ　／　ａｕｄｉｔ　
／　ａ　ｅｖｅｎｔ／　ｅｔｃ　／　５ｅｃｕｒｉｔｙ
　／　ｓ　ｕｓｅｒ／　ｅｔｃ　／　５ｅｃｕｒｉｔｙ
　／　ｓ　ｇｒｏｕｐ／　　１ｏｃａｌ　／　ｅｔｃ　
／　５ｅｃｕｒｉｔｙ　／　ａ　５ｔａｔｅ／　　１ｏ
ｃａｌ　／　ｅｔｃ　／　５ｅｃｕｒｉｔｙ　／　ａ　
ｔｒａｉｌ／　１ｏｃａｌ　／　ｅｔｃ　／　５ｅｃｕ
ｒｉｔｙ　／　ａ　ｔｒａｉｌ、ｐａｓｔ事象テーブル
／　ｅｔｃ　／　５ｅｃｕｒｉｔｙ　／　ａｕｄｉｔ　
／ａ　ｅｖｅｎｔの各項目は管理事象を１組のベース事
象と関連づける。管理事象（たとえば、ｒｓｙｓｔｅｍ
−ｃａｌｌＪまたはｒｔｃｐｉｐ　ｅｖｅｎｔＪまたは
ｒｏｂｊｅｃｔ−ｃｒｅａｔｅＪ　）は、監視者にとっ
て便利なマクロであるが、１組の「原子的」ベース事象
または既に定義された管理事象あるいはその両方によっ
て定義サレル。ベース事象は、システム・コール名（り
とえば、ｒｆｏｒｋＪ　）またはトラステッド・プロセ
スにおける事象（たとえば、’ｌｏｇｉｎ　ｏｋＪ　）
またはカーネルにおける非システム・コール事象（たと
えば、ｒｄｓｒｐｃＪ　）のいずれかである。

ユーザ０テーブル／ｅｔｃ／５ｅｃｕｒｉｔｙ／ｓ　ｕ
ｓｅｒ　（及びグループ［相］テーブル／　ｅｔｃ　／
　５ｅｃｕｒｉｔｙ　／ｓ　ｇｒｏｕｐ）内の各項目は
、１つのフィールドを含み、このフィールドは、１のと
き特別な監視を識別し、０のとき一般的監視を識別する
。

監視状態ファイル／　１ｏｃａｌ　／　ｅｔｃ　／　５
ｅｃｕｒｉｔｙ／　ａｕｄｉｔ　／　ａ　５ｔａｔｅは
、事象状況の間合せに対する現在の一般事象と特別事象
の組を保持する。

本発明では、ディレクトリ／１ｏｃａｌ　はノードに特
有のファイルを含む。このディレクトリは、その名前と
は逆に、リモートとなることができる（　ｒｖｍｏｕｎ
ｔｅｄＪまたはｒｒｍｏｕｎｔｅｄＪ　）　ｏ　Ｌ／か
し１０−カルであれ、またはリモートであれ、このファ
イルはノードに特有でなければならない。

ｒｌｏｃａｌＪという名前は、これらのファイルをロー
カルまたは論理的にローカルと考えることができること
を意味する。この設計では、ディレクトリ／　ｅｔｃ　
／　５ｅｃｕｒｉｔｙ　／　ａｕｄｉｔまたは／　ｅｔ
ｃ　／５ｅｃｕｒｉｔｙ１またはそれらに含まれるファ
イルがローカルでもリモートでもよい。

監視証跡名ファイル／　１ｏｃａｌ　／　ｅｔｃ　／　
５ｅｃｕｒｉｔｙ／　ａｕｄｉｔ　／　ａ　ｔｒａｉｌ
及び監視証跡名活動記録ファイル／　１ｏｃａｌ　／　
ｅｔｃ　／　５ｅｃｕｒｉｔｙ　／　ａｕｄｉｔ　／ａ
　ｔｒａｉｌ、ｐａｓｔは、状況の問合せが使用し回復
のために監視デーモンが使用する、監視証跡ファイル名
及び（開始及び停止）タイムスタンプを含む。

監視証跡ファイルを保持するため、ファイル・システム
全体を作成して、証跡、すなわち／　ａｕｄｉｔの保持
専用にすることを推奨する。監視証跡ファイルがリモー
トの場合、ＤＳ等の機構により、その証跡に対する監視
サーバ・ディレクトリをローカルの／ａｕｄｉｔ　スタ
ブ・ディレクトリ上にｒｖｍｏｕｎｔＪすることができ
る。

監視デーモン及び監視証　ファイル形式監視デーモン／
　ｅｔｃ　／　ａｕｄｉｔｄは背景プロセス（通常／　
ｅｔｃ　／　ｒｅコマンド・ファイルから開始される）
であり、カーネルによって生成される監視レコードのビ
ンをパック（または圧縮）シ、パックされたビンを監視
証跡ファイルに書き込む。

本発明では、カーネルは監視証跡ファイルに監視レコー
ドを直接書き込まない。その代わりに、監視レコードの
書込みを緩衝記憶させる。カーネルは、それぞれ現設計
で最大寸法を有するユーザ・レベル・ファイルである一
連のビンに監視レコードを書き込み、監視デーモンはビ
ン・ファイルを−度に１つずつ読み取って、圧縮された
ビンを監視証跡ファイルに付加する。

監視証跡ファイルは−続きの３部分（ヘッド・ボデー、
テール）から成り、ボデーは、多分パックされたビン（
すなわち、特定のノードに対する一連の監視レコード）
から成り、ヘッド及びテールは以下の構造を有する。

５ｔｒｕｃｔ　　ｘ ［ ｕｓｈｏｒｔ　ｉｄ；　　　／”　ヘッド＝ＯｘｆＯｆ
Ｏ，テール＝ＯｘＯｆＯｆ零／ ｕｓｈｏｒｔ　ｂｉｎ；　　／”　　ビンｌ　’／ｕｓ
ｈｏｒｔ　ｂｅｆｏｒｅ：／”　アンパックされたボデ
ー長６／ ｕｓｈｏｒｔ　ａｒｔｅｒ；　／”パックされた（現在
の）ボデー長宰／ ｎｉｄ　ｔ　ｎｉｄ；　　　／’　ノード識別子＊／１
： フレームのヘッドとテールはｉｄ　フィールド以外は同
じであり、監視証跡を順方向及び逆方向に走査させるこ
とができる。（ａｆｔｅｒ　＝＝　ｂｅｒｏｒｅ）のと
きは、ボデーはアンパックされ、そうでない（ａｆｔｅ
ｒ　＜　ｂｅｆｏｒｅ）場合は、ボデーはパックされる
。バッキング及びアンバッキングには、コマンド・パッ
クで使用されるようなハフマン（Ｉｌｕｆｆｍａｎ）符
合化アルゴリズムを使用する。

ボデーでは、アンパックされた各監視レコード自体がヘ
ッド及び任意選択のテールを有する。ファイル／ｕｓｒ
／１ｎｃｌｕｄｅ／ｓｙｓ／ａｕｄｉｔｌｏｇ、ｈはＣ
構造を用いて監視証跡レコードのヘッドを定義する。

１ｏｉｎユーザＩＤ 本発明の重要な特徴は、本発明がオレンジ・ブックの監
視要件、たとえばクラスＣ２の個々の責任特性を満足す
ることである。Ｃ２ＡＩＸの場合は、システム導入時に
そのように構成することが可能であり、ｌｏｇｉｎはル
ートまたは他の擬似ユーザ（たとえば、ビン）として受
は入れられないが、ｓ　ｕ　（ｒｓｕｂｓｔｉｔｕｔｅ
　ｕｓｅｒＪコマンド）は擬似ユーザ擬似ルートに受は
入れられる。さらに、この設計では、「Ｕ」ブロック内
に新しい構成要素ｕ　１ｕｉｄをもつプロセスのｌ□ｇ
ｉｎ：Ｌ−ザＩＤをカーネル内に記憶しており、それを
他のユーザＩＤ（すなわち、実ＩＤ及び有効ＩＤ）と共
に各監視レコード上に記入するので、ａｕｄｉｔｐｒ　
コマンドにより、ｌｏｇｉｎ　ユーザＩＤに基づいて監
視証跡レコードを事後選択することができる。

ｌｏｇｉｎ　ユーザＩＤはログイン時にセットされ、ｌ
ｏｇｉｎセツション中には変更できない。これはシステ
ム・コールによって直接セットされない。その代わり、
ｌｏｇｉｎプロセスによってｌｏｇｉｎセツシＰン中に
初めてルートから離れた５ｅｔｕｉｄに対して呼出しが
あったときにだけシステム・コール５ｅｔｕ　ｉｄの副
作用としてセットされる。

擬似ユーザ、すなわち、偽ユーザは実際の人物ではなく
役割である。通常は、実ユーザのグループは擬似ユーザ
のパスワードを知っている。ユーザ名ルートが擬似ユー
ザである。

ＡＩＸ上では、ユーザ・テーブル／　ｅｔｃ　／５ｅｃ
ｕｒｉｔｙ　／　５−ｕｓｅｒ　はｒｌｏｇｉｎＪフィ
ールドを含み、このフィールドは、ユーザごとに１のと
きｌｏｇｉｎを可能にし、Ｏのときｌｏｇｉｎを禁止す
る。

Ｃ２ＡＩＸシステムではｓ　　（ｌｏｇｉｎは許されな
いので）ルートを含む各擬似ユーザのｒ　ｌｏｇｉｎ　
Ｊフィールド値はＯである。管理者は実ユーザを擬似ユ
ーザから区別できるはずなので、コマンドａｄｄｕｓｅ
ｒでｒｌｏｇｉｎＪフィールドをセットすることができ
る。

ａｄｄｕｓｅｒ　コマンドでユーザを無効にすることは
そのユーザにｌｏｇｉｎを禁止するのと同じではない。

ユーザが無効にされたときは、暗号化されたパスワード
が０で置き換えられており、′に対する明示検査がある
ので、パスワード検査はそのユーザについては効果がな
い。無効にされたユーザは、ｌｏｇｉｎすることができ
ず、さらに、無効にされたユーザに対して直接ＳＵを行
なうこともできない。あるユーザに対するｒｌｏｇｉｎ
ＪフィールドがＯである場合、そのユーザはｌｏｇｉｎ
することはできないが、そのユーザに対して直接ＳＵを
行なうことはできる。もちろん、ルート・パスワードを
有するシステム管理者はルートに対してＳＵを行なうこ
とができ、次いで、無効にされたユーザを含めて、どの
ユーザに対してもＳＵを行なうことができる。

たとえば、システム管理者として、たとえば、ユーザｍ
ａｔｔｈｅｖとしてｌｏｇｉｎを行ない、次にルートに
対してＳＵを行なって、Ｃ２ＡＩＸシステム上で種々の
管理タスクを実行することになる。監視サブシステムは
実ユーザＩＤ及び有効ユーザＩＤの他にｌｏｇｉｎユー
ザＩＤを知っている。言い換えれば、監視システムにと
って、ユーザはルートとしてのｍａｔｔｈｅｗであるか
、または単にｍａｔｔｈｅｗであるかのいずれかである
。

監視印刷コマンド 監視印刷コマンドＢｕｄｉｔｐｒは、その特定の経路ア
ーギュメントによって定義される監視証跡を読み取り、
報告を「属性ファイル形式Ｊ（ＩＢＭＲＴ　　ＰＣＡＩ
Ｘオペレーティング・システム技術解説書、第４章の属
性ファイル形式のためのＡＩＸマニュアル・ページ参照
）で標準出力装置上に印刷する。

オプションなしで呼び出されたとき、コマンドａｕｄｉ
ｔｐｒは監視証跡ファイル経路からすべての監視レコー
ドを印刷する。オプション付きテ呼ヒ出されたときは、
コマンドａｕｄｉｔｐｒはそれらのオプシゴンをフィル
タとして使って、監視証跡ファイル経路からのオプショ
ン付択された監視レコードのみを印刷する。多数の異な
るオプション（たとえば、−ｕ　ｊｏｈｎ　−ｇ　シス
テム）がこのフィルタ中で互いにＡＮＤ演算される。−
Ａまたは−Ｂ以外の各オプションについては、１つの名
前、またはコマンドで分離された複数の名前（空白を含
まない）のいずれかを使用することができる（たとえば
、−ｇ　システム、ビン、スタッフ）。

いずれかのａｕｄｉｔｐｒ　コマンド・オプションを使
用する場合、その結果得られる属性ファイルは、オプシ
ョンを識別する省略時スタンザを有し、単一値を有する
それらの名前値対が、後続のレコードから取り出される
。多数の値をもつオプションは、省略時スタンザ中に注
釈が付いた、コンマで区切られた値として現われる。レ
コード・スタンザ名は「ｒ」　（レコードの略）で始ま
り、１から始まる、経路パラメータからの相対レコード
番号がその後に続く。ｊｔｌ＊＊Ｊを含む注釈行が監視
レコード・ヘッドと監視レコード・テールの間に入る。

監視サブシステムが使用可能になった場合、ファイル／
　１ｏｃａｌ　／　ｅｔｃ　／　５ｅｃｕｒｉｔｙ　／
　ａｕｄｉｔ　／ａ　ｔｒａｉｌは現監視証跡ファイル
の名前と使用可能時間を含む。ファイル／　１ｏｃａｌ
　／　ｅｔｃ　／５ｅｃｕｒｉｔｙ　／　ａｕｄｉｔ　
／　ａ　ｔｒａｉｌ、ｐａｓｔは監視証跡ファイルの名
前及び使用可能／禁止時間の活動記録を含む。

監視システム・コール この監視サブシステム設計は４つのシステム・コールを
有し、それらの各々について、呼出し側プロセスの有効
ユーザＩＤは、監視システム・コールを使用するた・め
のスーパーユーザでなければならない。（ちなみに、こ
れらのシステム・コールの集合的機能は、システム・コ
ールの正確な数またはどのようなアーギュメント順序よ
りも重要である。） システム・コール監視は監視サブシステムを使用可能（
オン）にし、監視証跡ファイルを指定し、監視が既に使
用可能になっているときは監視証跡ファイルを切り換え
、監視サブシステムを使用禁止（オフ）にし、すべての
監視事象をクリアし、監視サブシステムのオン／オフ状
況を照合することができる。

システム・コールａｕｄｉｔｅｖｅｎｔｓは、システム
が監視する事象をゲットし、セットする。ＡＩＸは２種
類の事象、すなわち、一般事象と特別事象を区別し、各
々の事象と事象セットを関連づけるが、この区別は本発
明にとって余り重要でない。

システム・コールａｕｄｉｔｌｏｇは監視証跡ファイル
の終わりに「ユーザ・レベル・ベース事象」監視レコー
ドを付加する。

システム・コールａｕｄｉｔｐｒｏｃはプロセスの監視
状態をゲットし、セットする。システム・コールａｕｄ
ｉｔｐｒｏｃは、１つの例外はあるが、現在のプロセス
に対する監視を中断しく一時的に使用禁止にし）、次に
、再開（使用可能に）することができる。このプロセス
の監視の中断によって通常の監視は使用禁止になるが、
プロセスが監視システム・コールａｕｄｉｔｌｏｇを呼
び出してレコードを監視証跡に付加することは可能であ
る。中断／再開状態も照会することができる。さらに、
システム・コールａｕｄｉｔｐｒｏｃはプロセスの一般
／特別クラス状況をセットし、その状況を照会すること
ができる。システム・コールａｕｄｉｔｐｒｏｃの一般
／特別コマンドはｌｏｇｉｎ時に呼び出されるようにな
っている。一般／特別監視状況はｌｏｇｉｎセツション
を通じて不変であるはずであるが、不変である必要はな
い。

既に明らかなはずであるが、コマンドａｕｄｉｔは、シ
ステム・コールａｕｄｉｔ及びａｕｄｉｔｅｖｅｎｔｓ
を呼び出す便利な「ウィンドウ・ドレッシング」であり
、種々の監視ファイルを使用する。

ｌｏｇｉｎ等のトラステッド・プロセスは以下のように
システム争コールａｕｄｉｔｐｒｏｃ及びａｕｄｉｔｌ
ｏｇを使用することができる。トラステッド・プロセス
は、ａｕｄｉｔｌｏｇを呼び出してそのプロセスに対す
る監視をオフにすることができ、次に、選択的な場所で
２．３回ａｕｄｉｔｌｏｇを呼び出して少数の監視レコ
ードのみを切り取ることができる。このようにａｕｄ　
１ｔｐｒｏｃ及びａｕｄｉｔｌｏｇを使用すると、比較
的記述的なレコードを記録し、不必要なレコードで監視
証跡があふれるのを回避することにより、監視証跡を事
前に濾過するのに役立つ。

監　サブシステムのカーネル部分 本節では監視サブシステムのカーネル部分の幾つかの重
要な特性について説明する。

ローカル・システム・コール１回当＋１）１つの監視レ
コード。監視者がシステム・コール事象を選択するとき
、及びそのローカル・システム・コールが呼び出される
とき、この設計では厳密に１つの監視証跡レコードを監
視証跡ログ・ファイルに付加する。このことを行なうた
め、カーネルは情報をプロセスのｒｕＪブロックに記憶
する。これとは対照的に、安全Ｘｅｎ１ｘ　（グリゴル
（Ｇｌｉｇｏｒ）等「安全Ｘｅｎ１ｘの設計及び実施（
Ｄｅｓｉｇｎ　ａｎｄＩｍｐｌｅ＋ａｅｎｔａｔｉｏｎ
　ｏｆ　５ｅｃｕｒｅ　Ｘｅｎ１ｘ）　Ｊ　ｓソフトウ
ェア技術に関するＩ　ＥＥＥ概要、Ｖｏｌ、５Ｅ−１３
、Ｎｏ、２、ｐｐ、２０８−２２１　（１９８７年２月
）、及びピチオットの論文（Ｊ、　ピチオット「効果的
な監視サブシステムの設計（ＴｈｅＤｅｓｉｇｎ　ｏｆ
　ａｎ　Ｅｆｆｅｃｔｉｖｅ　Ａｕｄｉｔｉｎｇ　Ｓｕ
ｂｓｙｓｔｅｍ）Ｊ　ｓクランド、ｐｐ、１３−２２　
（１９８７年４月）の１計では、システム・コール１回
当り多数の監視レコードを切り取る。

「監視」事象の監視。システム・コールａｕｄｉｔに対
して監視が使用可能／使用禁止にされるとき、ｒａｕｄ
ｉｔオン」及びｒａｕｄｉｔオフ」事象に対する監視レ
コードを切り取るために注意が払われる。

この項目は読者には明らかであるが、ちょっとした特別
な吟味を必要とする。

カーネルが監視レコードを書き込めないとき。

この設計では、カーネルがレコードを監視証跡ファイル
にうまく書き込むことができないとき、カーネルはメツ
セージを操作卓に書き込み、停止する（すなわち、カー
ネルはパニック状態になる）。

この事象は、以下のことを含めて幾つかの理由で生じる
可能性がある。すなわち、監視証跡ファイルがその最大
サイズに達した、または監視証跡を含むファイル・シス
テムが一杯である、または監視証跡がリモートで、かつ
リモート・ノードが故障したかまたは通信接続が故障し
たかのいずれかである。

この設計は高度な監視サブシステムの問題を扱っていな
い。独立した各サブシステムに高い可用度を組み込むの
ではなく、サブシステムがそれをトランスペアレントに
、またはサブシステムの設計変更なしに使用することが
できるように、高い可用度を得るための一般的機構（す
なわち、ファイル・システムの構成可能属性）を設ける
べきであると設計者は考える。

監視証跡の圧縮 本節では、上記のピチオットの論文における監視証跡圧
縮のための設計に基づくオンライン監視証跡圧縮のため
の設計について説明する。重要な相違点を以下に指摘す
る。

監視証跡圧縮のためのピチオットの設計ピチオットの監
視証跡圧縮方式は次のように働く。カーネルは監視証跡
ファイルに（生の圧縮されていない）監視レコードを直
接書き込まず、それぞれ同じ一定のサイズをもつ一連の
一部ビン・ファイルに書き込む。ユーザｅレベルのデー
モン・プロセスは背景で実行され、圧縮されていない監
視レコードをビンから一度に１つのビンずつ読み取り、
圧縮された監視レコードを監視証跡ファイルに書き込む
。ビン・ファイルの処理後、デーモンはビン・ファイル
を除去する。

ピチオットの設計はカーネル変数Ｂ　Ｉ　ＮＮＵＭを維
持し、これは、監視レコードを含む次のビンの識別を指
定するのに役立つ。Ｂ　ＩＮＮＵＭは、ブート時または
循環時に０にリセットされる３２ビツトの符号なしの整
数である。監視サブシステムが初めにオンになるとき、
カーネルは、カーネル中で周知の経路名であるａｕｄｉ
ｔ、ｂｉｎ　という名の制御ビン・ファイルを作成し、
このファイルにＢ　ＩＮＮＵＭの値を書き込む。ａｕｄ
ｉｔ、ｂｉｎ　ファイルを作成しＢ　ＩＮＮＵＭを書き
込んだ後、カーネルはａｕｄｉｔ、ｂｉｎを閉じ、ａｕ
ｄｉｔ、ｂｉｎＸを作成する。

ＸはＢＩＮＮＵＭの１０進表示である。たとえば、ａｕ
ｄｉｔ、ｂｉｎ中の７は、次のビンがａｕｄｉｔ、ｂｉ
ｎ　７であることを示す。ａｕｄｉｔ、ｂｉｎＸ中の最
初のレコードは監視証跡ファイル名を含む特別なレコー
ドである。監視ビンは長さ３００００バイトである（コ
ンパイル時定数）。カーネルは１つのビンに３００００
バイトを書き込んだとき、ビン終了レコードを書き、そ
のビンを閉じ、ＢＩＮＮＵＭを増分し、次の新しいビン
を開く。

システムがブートされると、監視圧縮デーモンａｕｄｃ
ｏｍｐがローカル・デーモンの１つとして開始される。

監視圧縮デーモンは直ちに、１つのオンーオフ監視セッ
シ１ンの圧縮を担当する子プロセスａｕｄｃｏｍｐ　ｃ
を分岐（ｆｏｒｋ）する。各セツションの後で、子プロ
セスは消滅し、ａｕｄｃｏｍｐは新しい子プロセスを分
岐（ｆｏｒｋ）する。ａｕｄｄｃｏｍｐ　ｃ処理は、ａ
ｕｄｉｔ、ｂｉｎ　ファイルを見つけるまで待つ。この
ファイルを見つけると、それからＢ　Ｉ　ＮＮＵＭを読
み取り、次にａｕｄｉｔ、ｂｉｎを削除する。

ａｕｄｃｏｍｐ　ｃは次にａｕｄｉｔ、ｂｉｎ−Ｘ　を
開いてレコードの読取りを開始し、それらのレコードを
圧縮して最初のレコードで指定された監視証跡ファイル
に書き込む。ＥＯＦで、ａｕｄｃｏ＋ａｐ　ｃは単にデ
ータをさらに読み取ろうと再試行するだけである。ＥＯ
Ｆは、消費者（ａｕｄｃｏｍｐ　ｃ）が生産者（カーネ
ル）よりも速いことを示す。ａｕｄｃｏｍｐ　ｃはビン
終了レコードを読み取るとき、まず現在のビンを閉じて
削除し、次のビン（ビン番号は順になっている）を開き
、さらに生の監視データを読み始める。

監視サブシステムがオフになると、カーネルはａｕｄｉ
ｔセッシ日ン終了レコードを現在のビンに書き込み、そ
のビンを閉じてＢ　ＩＮＮＵＭを増分する。

ａｕｄｃｏ■ｐ−ｃがセッシ１ン終了レコードに出合う
と、その入力ファイル及び出力ファイルを閉じ、前者を
削除して、消滅する。デーモンａｕｄｃｏｍｐは次に新
しい子プロセスを分岐（ｆｏｒｋ）　Ｌ、子ファイルは
ａｕｄｉｔ、ｂｉｎ制御ファイルの出現を待ち、次に圧
縮活動が継続する。

監視サブシステムが既にオンである間に監視証跡ファイ
ルが切り換えられるときは、カーネルは単に切換えファ
イル名レコードを現在のビンに書き込み、中断なしに継
続する。

本、［ｌの監視証　圧縮 本発明は、ピチオットの論文で扱われていない以下の特
性を溝たす。（１）ファイル／ディレクトリ位置トラン
スパレンシを存する。（２）多数のノードを１つの監視
証跡ファイルに監視レコードを付加することができる。

（３）圧縮デーモンは単一プロセス処理であり、圧縮中
にノード故障の後で再始動可能である。（４）監視証跡
ファイルは１回書込み多数回読取り媒体に載せることが
できる。（５）カーネル中に周知のファイル名がない。

さらに、システム・コール・インターフェースは圧縮に
ついて知らない。本発明の構成要素を以下に示した後で
、上記５つの特性のそれぞれについて考察し、各特性が
溝たされることを示す。

圧縮のためのカーネル・サポート。監視者が監視コマン
ドで監視をオンにすると、ａｕｄｉｔ　コマンドは監視
証跡ファイルの名前及び現在の時間をａ　ｔｒａｉｌ　
に保管する。ａｕｄｉｔ　コマンドは次に監視システム
・コールを呼び出して監視をオンにし、カーネルは、監
視証跡ファイルが新しいファイルかどうか検査する。

監視証跡ファイルが新しい場合、カーネルは新しい監視
証跡ファイルとｘ、ｃｔｌ　　という名の状況ファイル
を作成する。ただし、Ｘは監視証跡ファイルのファイル
名部分である。状況ファイル及びビンは監視証跡ファイ
ルと同じディレクトリ・トリー（以下に説明するのと同
じディレクトリではなく、ｎｉｄによって命名されるサ
ブ、ディレクトリ）中に作成される。ｎｉｄ　とはノー
ド（すなわち、システム・コンピュータ）識別子である
。カーネルは次に３つの数を状況ファイルに書き込み（
最初は１．０．０）、カーネル変数Ｂ　ＩＮＮＵＭをＯ
にセットする。状況ファイル中の３つの数はｎｅｘｔＢ
ｉｎＮｕｍｂｅｒ）１ｏｖＢｉｎＮｕｍｂｅｒｓ及びｃ
ｏｍｐｒｅｓｓｔｏｎＩｎＰｒｏｇｒｅｓｓである０フ
イールドｒｎｅｘｔＢ　ｉｎＨｕｍｂｅｒ　Ｊは、次に
使用されるビン番号であり、カーネルのみがこの値を書
き、監視デーモンは書けない。フィールドｒｌｏｖＢｉ
ｎＨｕ■ｂｅｒＪは、圧縮されていない最も低いビン・
ファイルのビン番号を含み％　　ｒｃｏｓｐｒｅｓｓｉ
ｏｎｌｎＰｒｏｇｒｅｓｓＪは１圧縮が進行中であるか
どうか示すフラグである。初期の作成を除いて、監視デ
ーモンのみがフィールド’ｌｏｗＢｉｎＨｕｍｂｅｒＪ
　及びｒｃｏｍｐｒｅｓ５ｉｏｎＩｎＰｒｏｇｒｅｓｓ
　Ｊを書く。したがって、最初、（１，０，０）は、１
が次に使用されるべきビン番号であり、０が圧縮されて
いない最も低いビンの番号であり、圧縮が進行中である
ことを意味する。ｌｏｖＢｆｎＨｕｍｂｅｒ及びｎｅｘ
ｔＢｉｎＮｕｍｂｅｒは０から９９９までカウントされ
、次いで再びＯにリセットされ、以下同様である。最大
１０００個のビンに対して３桁の数を使用すると、生産
者と消費者間（すなわち、カーネルとデーモン間）のど
のような速度の不一致をも相殺するのに十分な緩衝とな
ると考えられた。

ビット数（１００，１０００，２５Ｅ３、・・・）を選
択して、本発明の原理は変更されない。

監視証跡レコードが既に存在する場合、カーネルは既存
の監視状況ファイルからｎｅｘｔＢｆｎＨｕｍｂｅｒを
読み取り、そのＢ　ＩＮＮＵＭをｎｅ）（ｊ３ｉｎＨｕ
ｍｂｅｒにセットする。カーネルはまた状況ファイル内
のｎｅｘｔＢｉｎＮｕｍｂｅｒ　とｌｏｖＢｆｎＨｕｍ
ｂｅｒを比較する０２つの番号が等しい場合、圧縮デー
モンは以前に生成された監視ビン・ファイルを圧縮して
おらず、カーネルは、監視がこの監視証跡ファイルをオ
ンにすることを許さない。通常の場合、この状況は起こ
らないはずである。

Ｂ　ＩＮＮＵＭを決定した後、カーネルはｘ、　ｙとい
う名の一部ビン・ファイルを作成する。ただし、Ｘは前
と同じであり、ｙはＢ　ＩＮＮＵＭの３桁の１０進表示
である。ＡＩＸでのファイル名の最大の長さは現在１４
であるので、接尾部が４文字であると、接頭部は最大１
０文字となる。Ｘ。

ｙを作成した後で、カーネルは監視レコードをこのビン
に書き込む。このビンのサイズが所定の限界を超えたと
きは、カーネルはビン終了レコードを書いてビンを閉じ
、カーネル内のＢ　Ｉ　ＮＮＵＭと状況ファイル内のｎ
ｅｘｔＢｉｎＨｕｍｂｅｒを増分し、新しいビン・ファ
イルを作成し、次に、新しいビンの使用を開始する。こ
の場合も、圧縮デーモンにおけるエラーを防ぐため、カ
ーネルは、次のビン・ファイルを作成する前に、ＢＩＮ
ＮＵＭと１ｏｗＢｉｎＮｕｍｂｅｒ　が等しいかどうか
調べる。ＢＩＮＮＵＭと１ｏｖＢ　Ｅｎｃｕｍｂｅｒが
等しい場合、カーネルは警告メツセージを操作卓に書き
、以前のＢＩＮＮＵＭを復元し、ビン・ファイルを切り
換えない。

監視者がａｕｄｉｔ　コマンドで監視をオフにすると、
ａｕｄｉｔ　コマンドはａ　ｔｒａｉｌ　からレコード
を除去し、現在の時間をレコードの終わりに付加し、こ
の監視証跡がまだ圧縮されていないことを示すフラグを
セットし、レコード全体をａ　ｔｒａｉｌ、ｐａｓｔに
付加する。カーネルは監視をオフにするよう指令される
と、セツション終了レコードを現在のビン・ファイルに
書き込み、ファイルを閉じ、カーネルの監視をオフにす
る。

監視者が監視証跡ファイルを変更し、監視サブシステム
が既にオンであるとき、カーネルはセッシｅン終了レコ
ードをビンに書き込み、ビンを閉じ、監視がオンになっ
たときと同様に先に進む。

圧縮デーモン。監視圧縮デーモン／　ｅｔｃ　／ａｕｄ
ｉｔｄは、システムがブートされたとき開始される背景
プロセスである。監視デーモンは一時に１つの監視セツ
ションを圧縮し、古いものから順にセツションを圧縮す
る。監視デーモンはファイルａ　ｔｒａｉｌ、ｐａｓｔ
及びａｔｒａｉｌを使用する。ファイルａ　ｔｒａｉｌ
、ｐａｓｔは、セツションが圧縮されているか否かを含
めて、クローズされたすべてのセツションに関するデー
タを含む。ファイルａ　ｔｒａｉｌは既存のオープン・
セツションに関するデータがあれば、それを含む。

監視デーモンは次のように働く。まず監視デーモンは回
復を行なう。監視がオフであると仮定して、監視デーモ
ンはａ　ｔｒａｉｌ　を調べる。ａ　ｔｒａｉｌが空で
ない場合は、オーブン・セツション中に故障が起きてい
る。監視デーモンは状況ファイルからオーブン証跡を読
み取り、セツション終了レコードを最終のビン・ファイ
ルに付加し、ｅｎｄ−ｔｆｍｅ’ｄａ　ｔｒａｉ１項目
をａ　ｔｒａｉｌ、ｐａｓｔに付加し、ａ　ｔｒａｉｌ
を空にする。これらの動作によってａ　ｔｒａｉｌ、ｐ
ａｓｔ及びａ　ｔｒａｉｌ　の「不変特性」が再確立さ
れる。

第２に、監視デーモンは次のようにしてセツション圧縮
不変特性を再確立する。監視デーモンは監視証跡を順方
向に探索し、最も新しい未圧縮セツションを識別する。

そのような未圧縮セツションが存在する場合、監視デー
モンは最初のレコードについてこのｎｉｄで監視証跡を
逆方向に探索し、ビン番号を得るｏ　ｃｏｍｐｒｅｓｓ
ｉｏｎＩｎＰｒｏｇｒｅｓｓ　フラグが１の場合は、終
結処理が必要である。終結処理とはこの場合は、既に圧
縮されたビン・ファイルを除去し、次に状況ファイル内
のｌｏｗ旧ｎＮｕｍｂｅｒ及びｃｏｍｐｒｅｓｓｉｏｎ
ＩｎＰｒｏｇｒｅｓｓを更新することを意味する。第３
に、監視デーモンはプロセス・グループ及び制御端末か
ら離れ、子プロセスを作成（ｆｏｒｋ）シ、親プロセス
を終了（ｅｘｉｔ）する。第４に、監視デーモンはその
通常の圧縮モードを開始し、−時に１つのセツションを
圧縮し、古いものから順にセツションを圧縮する。

セツション圧縮にはパック・コマンド・アルゴリズム、
すなわち、ハフマン符号化アルゴリズムを使用する。こ
のアルゴリズムは、圧縮を開始する前にすべてのデータ
を読み取ることを必要とする。デーモンがＥＯＦに出合
った場合、このことは、消費者（デーモン）、が−生産
者（カーネル）よりも速いことを意味する。したがって
、ＥＯＦ時には、デーモンは待機し、後から読取りを試
みる。

ビンの真の終わりはビン終了レコードまたはビン切換レ
コードによって示される。ビンを圧縮するとき、デーモ
ンは状況ファイルに ｃｏｍｐｒｅｓｓ　ｉｏｎ　ＩｎＰｒｏｇｒｅｓｓを表
わす１を書き込み１ビンを圧縮して、３部分から成るフ
レームを１回の原子的書込みで監視証跡ファイルに書き
込み、ビン・ファイルを除去し、＋　＋　ｌｏｗＢｉｎ
Ｈｕｍｂｅｒ　とｃｏｍｐｒｅｓｓｉｏｎＩｎＰｒｏｇ
ｒｅｓｓ値Ｏを状況ファイルに書き込む。

３部分フレームは（ヘッド、ボデー、テール）から成り
、ヘッドとテールは同じでかつ一定のサイズであり、ボ
デーは圧縮されたビンから成る。

ヘッド（及びテール）部は、上記と同様に、（ｉｄ。

ｂｉｎＬ　ｂｅｆｏｒｅ　ｌｅｎｇｔｈｌａｆｔｅｒ　
ｌｅｎｇｔｈｌｎｉｄ）から成る。同じヘッドとテール
の対及びそれぞれの長さの値を有する３部分フレームに
より、監視証跡を順方向及び逆方向に読み取ることがで
きる。

ファイル／ディレクトリの位置トランスパレンシ。

本発明では１ａ　５ｔａｔｅｓ　ａ　ｔｒａｉｌ及びａ
　ｔｒａｉｌ。

ｐａｓｔはノードに特有なので、それらはデイレクト　
リ　／　　１ｏｃａｌ　　／　　ｅｔｃ　　／　　５ｅ
ｃｕｒｉｔｙ　　／　　ａｕｄｉｔ　　内の／１ｏｃａ
ｌ　の下に存在する。さらに、ビンもノードに特有であ
る。周知の経路名はカーネルに導入したくないので、カ
ーネルが監視オン時に決定する、監視証跡ファイルを含
むディレクトリの下のどこかにビンを作成することがで
きる。これらのビンを監視証跡と同じディレクトリ中に
作成し、かつそのディレクトリがリモートである場合は
、ビン名が衝突を起こす可能性がある。すなわち、２つ
以上のノードが同じビンに「入る」可能性がある。

この問題を回避するため、監視証跡ファイルを含むディ
レクトリのｎｉｄに特有な（すなわち、ｎｉｄによって
命名された）サブディレクトリ中にビンを作成すること
ができる。監視デーモン／　ｅｔｃ　／ａｕｄｉｔｄは
ａ　ｔｒａｉｌ　を読み取って、ビン及び監視証跡ファ
イルを見つける。ノードに特有な監視データは分離され
ているので、この設計は、監視証跡ファイル、及び監視
証跡ファイルを含むディレクトリの位置がローカルか、
それともリモートかにはこだわらない。

多数のノードが１つの監視証跡ファイルに供給すること
ができる。ＤＳのトランスバレンシを使用して、多数の
ノードから単一の監視証跡ファイルに監視レコードを書
き込む。ａｕｄｉｔｐｒ　コマンドが混乱しないことを
示す必要がある。ａｕｄｉｔｐｒ　コマンドは監視証跡
ファイルを明瞭に読み取ることができ、多数のソース・
ノードからの監視証跡レコードの圧縮を解除する。解決
すべき問題は、複数のノードからのインターリーブされ
た圧縮監視レコ゛−ドをどのように圧縮解除するかであ
る。１　　゛つのステップで各ビンを圧縮することによ
ってこの問題を解決し、圧縮されたビンの前に未圧縮チ
エツクポイント・ヘッダを付加し、圧縮されたビンの後
に未圧縮チエツクポイント・トレーラを付加し、（未圧
縮ヘッダ、圧縮されたビン、未圧縮テール）を１回の原
子書込みで監視証跡に付加する。まずレコードを一部フ
ァイルに書き込み、次に１回の読取りシステム・コール
により１ステツプでそれを読み取り、次に１回の書込み
システム・コールにより１ステツプでそれを付加するこ
とにより原子書込みを行なう。

監視証跡ファイル用の１回書込み多数回読取り媒体。書
込みの場合、付加専用アクセスのために監視証跡ファイ
ルを常に開き、レコードのフレーム（未圧縮チエツクポ
イント・ヘッド、圧縮すれたビン、未圧縮チエツクポイ
ント・テール）を１回の原子書込みで書き込、む。

カーネル内に周知の経路名がない。設計により、カーネ
ルは、知る必要のある経路名情報を監視システム・コー
ルの監視証跡名アーギエメントからゲットする。

圧縮デーモンの回復及び再始動可能性。次節でこのこと
を説明する。

、　監視デーモンの回′及び再始動可能性本節では監視
デーモンの回復及び再始動可能性にオブジェクトを絞っ
て説明する。「回復」とは、ノード故障の後でデーモン
が通常の動作を再開できることを意味する。「再始動可
能性」とは、コードの任意の「接頭部」を実行し、その
後ノード障Ｘ　　　害が発生した場合に、かまわずに始
めからコードを実行することができ、かつそれを何回で
も実行できることを意味する。

本発明の監視デーモンについての説明の助けとして、表
Ａに監視デーモン用の擬似コード（スケルトン、Ｃ類似
コード）を示す。第６図は表Ａの監視デーモン・コード
の流れ図である。このコードは２つの機能、すなわち、
ｍａｉｎ（）及びｓｅｓｓｉｏｎｃｏｍｐｒｅｓｓ（）
を有する＠機能ｍａｉｎ（）は２つの大きなステップ、
すなわち、回復不テップと通常動作ステップを存する。

機能 ｓｅｓｓｉｏｎｃｏｍｐｒｅｓｓ（）　は特定の監視セ
ッシｅン内のすべてのビンを圧縮する。監視セツション
は、ｏｎ−ｏｆｆまたはｏｎ−ｓｗｉｔｃｈまたはｓｗ
ｉｔｃｈ−ｓｗｉｔｃｈまたは５ｗ１ｔｃｈ−ｏｆｆま
たはｏｎ−ｆａｉｌｕｒｅまたは５ｗ１ｔｃｈ−ｆａｉ
ｌｕｒｅの各ノード事象の間の記録されたすべての監視
事象から成る。ただし、’ｆａｉｌｕｒｅＪはノード故
障を意味する。監視セツシヨンは開いているか、または
閉じている。閉じた監視セツションはセツション終了レ
コードで終わり、開いた監視セツションはそうではない
。監視サブシステムが使用可能であり、かつ通常動作中
の場合、または監視サブシステムが使用可能な間に故障
が発生した場合、セッジｅンを開くことができる。

本節は４つの部分、すなわち、不変特性、回復、通常動
作、及び再始動可能性に分かれる。ここでは、回復とは
単に設計の特定の不変断定を再確立することなので、回
復について考察する前にこれらの不変部について考察し
なければならない。

王聚豆豊 監視デーモン擬似コードを理解するには、ファイルａ　
ｔｒａｉ１１ファイルａ　ｔｒａｉｌ、ｐａｓｔ及び機
能ｓｅｓｓｉｏｎｃｏｍｐｒｅｓｓ　（）の不変特性を
理解する必要がある。

ａ　ｔｒａｉｌ　の不変特性とは、開かれた既存の監視
セツションに関するデータがあれば、それを含むことで
ある。開かれた既存の監視セツションがない場合、ファ
イルａ　ｔｒａｉｌ　は存在するが、空である。

ａ　ｔｒａｉｌ、ｐａｓｔの不変特性とは、すべての閉
じた監視セッシ１ンに関する開始時間別に分類されたデ
ータを含むことである。開始時間と停止時間及び圧縮完
了フラグがファイルａ　ｔｒａｆｌ、ｐａｓｔ内の閉じ
た各監視セツションと関連づけられる。

機能ｓｅｓｓｉｏｎｃｏｍｐｒｅｓｓ　（）　と関連す
る不変特性は、擬似コード中で定義される断定ａＯ（ラ
ベルａＯつき）である・機能５ｅｓｓｉｏｎｃｏ＋ａｐ
ｒｅｓｓ　（）は特定の監視セツション内のすべてのビ
ンを圧縮し、閉じたセツション、または開いたセツショ
ン内のビンを圧縮するのに使用することができる。

機能ａｇａｉｎ　（）は、古いものから順にセツション
が圧縮されるように確保する。断定ａＯは、現在のビン
・ファイルｂについて、ビン圧縮が進行中ではな（、フ
ァイルｂが存在し、ｂがまだ監視証跡上にないことを示
す。言い換えると、ｓｅｓｓｉｏｎｃｏｍｐｒｅｓｓ　
（）は作動可能である◎旦１ 回復は、機能ｍａｉｎ　（）の最初の大きなステップで
あり１ａ　ｔｒａｉｌ　とａ　ｔｒａｉｌ、ｐａｓｔと
ｓｅｓｓｉｏｎｃｏｍｐｒｅｓｓ　（）に対する不変特
性が確立されていることを確認し、必要な場合には以下
のようにしてそれらを再確立する。

ａ　ｔｒａｉｌ　が空でない場合、開いた監視セツショ
ン中にノード故障が発生した。ａ　ｔｒｉａｌ及びａ　
ｔｒａｉｌ、ｐａｓｔの不変特性を再確立するには、ａ
　ｔｒａｉ１項目を読み取り、ｘ、ｃｔｌ　ファイルか
らＮｅｘｔ　（次に圧縮されるビン）を読み取り、セツ
ション終了レコードがまだない場合はビンＮｅｘｔ−１
の終わりにそれを付加し、ａ　ｔｒａｉｌ、ｐａｓｔの
最後のレコードがこのレコードでない場合は、ｅｎｄ−
ｔｉｍｅ’ｄａ−ｔｒａ　ｉ　１項目をａ　ｔｒａｉｌ
、ｐａｓｔに付加しｓ　ａ　ｔｒａｉｌを空にする。

ｓｅｓｓｉｏｎｃｏｍｐｒｅｓｓ　（）の不変特性を再
確立するには、ａ　ｔｒａｉｌ、ｐａｓｔを順方向に探
索して最も新しい未圧縮セツションを識別する。未圧縮
セツションが存在する場合は、断定ａｌ　−ａ５を詳し
く調べ１機能ｓｅｓｓｉｏｎｃｏｍｐｒｅｓｓ　（）の
下端でステップ５ｌ−ｓ４に介入し、簡単な事例解析を
使用することにより事態を解決する。ｍａｉｎ　（）内
のｓｅｓｓｉｏｎｃｏｍｐｒｅｓｓ　（）の不変特性を
再確立するたメツコードがビン・ファイルを除去するか
、ｘ、ｃｔｌファイルを書き直すか、あるいはその両方
を行なう６　ｓｅｓｓｉｏｎｃｏｍｐｒｅｓｓ　（）内
のフラグ変数は１ピンｂの圧縮が進行中のときは１であ
り、そうでない場合はＯである。このフラグの値は、ビ
ンｂの圧縮の状態を知るため回復に必要なとき、（シス
テム・コールｗｒｉｔｅ及びｒｓｙｎｃにより（後者は
ＡＩＸにおけるファイルごとの５ｙｎｃ）　）安定なデ
ィスク記憶装置に書き込まれる。

貞皇皇立 通常動作では、監視デーモンは一時に１つの監視セツシ
ョンを圧縮し、古いものから順にセツションを圧縮する
。最も古い未圧縮セツションを見つけるには、監視デー
モンはａ　ｔｒａｉｌ、ｐａｓｔを調べ、次にａ　ｔｒ
ａｉｌ　を調べ、セツション圧縮フラグが０である最も
古い項目を探す。そのような未圧縮セッシ１ンを見つけ
た場合、監視デーモンは機能ｓｅｓｓｉｏｎｃｏｍｐｒ
ｅｓｓ　（）を呼び出し１その後で１ａ　ｔｒａｉｌ、
ｐａｓｔで圧縮されたものとしてそのセッシ冒ンにマー
クを付ける。

機能ｓｅｓｓｉｏｎｃｏｍｐｒｅｓｓ　（ｔｒａｉｌ）
は特定の監視セツション内のすべてのビンを圧縮する。

ファイルｘ、ｃｔｌを使って、次に圧縮すべきビンを探
す。

次のビンが終了レコードまたはセツション終了レコード
を含まない場合ｓ　ｓｅｓｓｉｏｎｃｏｍｐｒｅｓｓ　
（）はしばらく休止してから、再び調べる。ビンが使用
可能なときはｓ　ｃｏ＋ｉｐｒｅｓｓｉｏｎＩｎＰｒｏ
ｇｒｅｓｓ　フラグを１にセットしてこれをファイルｘ
、ｃｔｌ　に書き込み、次いでビンを圧縮し、監視証跡
に３部分からなるフレームを付加し、次にビン・ファイ
ルを除去し１ｃｏｍｐｒｅｓｓｆｏｎＩｎＰｒｏｇｒｅ
ｓｓ　フラグを０にセットし、１ｏｗＢｉｎＨｕｉ＋ｂ
ｅｒ　を増分し、これら２つの値をファイルｘ、ｃｔｌ
に書き込む。セラシロン終了レコードが見つからない限
り、後続のビンをこのように圧縮し続ける。

旦亙■豆豊且 機能ｍａｉｎ　（）及び５ｅｓｓｉｏｎｃｏ園ｐｒｅｓ
ｓ　（）内のコードは再始動可能である。この擬似レコ
ードは、すべてのステップにとって、既に実行されたス
テップの故障とその後の再実行がまったく異ならないこ
とを示す。

１豆 以上、下記の要件及び特性を満足するコンピュータ監視
サブシステムについて説明した。

（ａ）　　ソフトウェア環境要件 階層ファイル・システム、及びｗｒｉｔｅ　（）システ
ム・コール等の原子書込み動作を含むＵＮＩＸ（または
ＡＩＸまたはＵＮＩＸ類似）オペレーティング・システ
ム環境でＩｉＬ、かつ 「仮想マウント」または「リモート・マウント」に基づ
（機構（たとえば、ＩＢＭ　　ＲＴＰＣＡＩＸ分散サー
ビス（ＤＳ））等、ローカル／リモート・ファイル／デ
ィレクトリ位置トランスパレンシを有するオペレーティ
ング・システム環境で稼働する。

（ｂ）安全保護要件 オレンジ・ブックのクラスＣ２ないしＡ１に対する監視
要件を満たすのに役立つ監視フレームワークを提供する
。

（ｃ）発明の特性 システムごとに１つの監視デーモン・プロセスを使って
監視証跡ログ・ファイルのオンライン圧縮を実行し、ノ
ード故障後に回復する再始動可能監視デーモンを存し、 ＤＳまたは類似の機構に対して、ファイル／ディレクト
リ位置トランスパレンシを存し、ＤＳまたは類似の機構
に対して、多数のノードに監視レコードを１つの監視証
跡ログ・ファイルに付加させ、ｌｏｇｉｎユーザＩＤを
捕捉し、擬似ユーザ類似ルートとしてｌｏｇｉｎするこ
とを防止するがｓ　８　ｕ　（ｒｓｕｂｓｔｉｔｕｔｅ
　ｕｓｅｒＪコマンド）は擬似ユーザ類似ルートに受は
入れることができる。

（ｄ）　　その他の特性 周知の監視証跡ログ・ファイルを１回書込み媒体に載せ
、かつ監視サブシステムのオペレーティング・システム
のカーネル部分に周知のファイル名を持たず、さらに、
対応するベース事象が使用可能になり、実行される場合
は、システム・コールごとに正確に１つの監視証跡レコ
ードをカットする。

この設計では、省略時ビン・サイズは２０４８０バイト
（２０ＫＢ＝＝１０ｘ２０４８、またはＡｌＸ１ｎｏｄ
ｅ構造中で１０個のｒｄｉｒｅｃｔＪ　）であり、平均
圧縮率は約５０パーセントである。

表Ｉ　　Ｂ　ｅｖｅｎｔ １１　＠（１）ａ　ｅｖｅｎｔ　７．２８７／１１１０
６１５：２９：０３２１　　Ａｕｄｉｔ　Ｅｖｅｎｔ　
Ｔａｂｌｅ３１　　ｆｏｒｍａｔ　ｆｏｒ　ａ　ｂａｓ
ｅ　ｅｖｅｎｔ　　ｉｓ：４　１　　　　　　　ｅｖｅ
ｎｔ、ｅＶｅｎｔ＋　　、、。

５　　＄１　　ｆｏｒｍａｔ　　ｆｏｒ　　ａｎ　　ａ
ｄｍｉｎｉｓｔｒａｔｉｖｅ　　ｅｖｅｎｔ　　ｉｓ：
６　ＩＩ　　　　　　ａｄｍｉｎｉｓｔｒａｔｉｖｅ−
ｅｖｅｎｔ：　　ｅｖｅｎｔ。

ｅｖｅｎＬ　　・＋− ７＋ｔ ８　襲　５ｙｓｔｅ＠ｃａｌｌ　　ｂａｓｅ　ｅｖｅｎ
ｔｓ９　　　　　　　　　ａｃｃｅｓｓ ｌｏ　　　　　　　ａｃｃｔ、　　ａｌａｒｍ、　　ａ
ｕｄｉｔ、　　ａｕｄｉｔｅｖｅｎｔｓ。

ａｕｄｉｔｌｏｇ、ａｕｄｉｔｐｒｏｃｌｌ　　　　　
　　　ｂｒｋ １２　　　　　　　　ｃｈｄｉｒ、ｃｈｍｏｄ、ｃｈｏ
ｖｎ＋　　ｃｈｏｗｎｘ。

ｃｈｒｏｏｔ、ｃｌｏｓｅ、ｃｒｅａｔ１３　　　　　
　　ｄｉｓｃｌａｉｍ、ｄｓｓｔａｔｅ、ｄｕｐ１４　
　　　　　　　　ｅｘｅｃ １５　　　　　　　　ｆｃｌｅａｒ、ｆｃｎｔｌ、ｆｆ
ｕｌｌｓｔａｔ、ｆｏｒｋ。

ｆｓｔａＬ　　ｆｓｙｎｃ、ｆｔｒｕｎｃａｔｅ＋ｆｕ
ｌｌｓｔａｔ １６　　　　　　　ｇｅｔｇｉｄ、ｇｅｊｇｒｏｕＰｓ
ｓ　　ｇｅｔｕｉｄ１７　　　　　　１ｏｃｔｌ、ｉｐ
ｌｖｍ１８　　　　　　　　ｋｉｌｌ １９　　　　　　１ｉｎｋ、　　１ｏａｄｔｂ１．　１
ｏｃｋ、　　１ｏｃｋｆ。

ｏｏｋｕｐ ２０　　　　　　　　　　ｎ＋ｋｄｉｒ、　　ｍｋｎｏ
ｄ、　　ｍｎｔｃｔｌ、　　ｍｏｕｎＬ５ｇ５ｙｓ ２１　　　　　　　　ｎ１ｃｅ ２２　　　　　　　ｏｐｅｎ ２３　　　　　　　ｐａｔｌＳｅｌ　　ｐｉｐｅ、　　
ｐｒｏｆｉｌ、　　ｐｔｒａｃｅ２４　　　　　　ｒｅ
ａｄ、　ｒｅｂｏｏｔ、　ｒｅｎａｌｌｅｌ　ｒｅｘｉ
ｔ。

ｍｄｉｒ ２５　　　　　　５ｅｅｋ、　　５ｅｌｅｃｔ、　　５
ｅｌｌＳｙＳ、　　ｓｅｔｇｉｄ。

ｓｅｔｇｒｏｕｐｓ、ｓｅｔｐｇｒｐ＋　　５ｅｔｕｉ
ｄ。

ｓｇｅｔｐｉｄ ２６　　　　　　　ｓｈｍｓｙｓ、　　ｓｉｇｂｌｏｃ
ｋ、　　ｓｉｇｃｌｅａｎｕｐ。

ｓｉｇｎａｌ、ｓｉｇｐａｕｓｅ＋　　ｓｉｇｓｅｔｍ
ａｓＬｓｉｇｓｔａｃｋ ２７　　　　　　　ｓｉｇｖｅｃ、５ｔａｔ、ｓｔｉｍ
ｅ、５ｙｎｃ２８　　　　　　　　ｔｉａ＋ｅ、ｔｉｍ
ｅｓ２９　　　　　　　ｕｌｉｍｆｔ、　　ｕｍａｓｋ
＊　　ｕ＋＊ｏｕｎＬ　　ｕｎａｌｌｅｌｕｎｌｉｎｋ
、ｕｓｒｉｎｆｏ＋　　ｕｔｉｍｅ、ｕｔｓｓｙｓ。

ｕｖ＋５ｏｕｎｔ ３０　　　　　　　ｖｈａｎｇｕｐ、ｖｍｏｕｎｔ３１
　　　　　　　ｗａｉｔ、　　ｗａｉｔｖｍ、’　ｗｒ
ｉｔｅ３２　　ｓｌ　　５ｏｃｋｅｔ　　ｅｖｅｎｔｓ
３３　　　　　　　ａｃｃｅｐｔ ４ｂｉｎｄ ３５　　　　　　　　ｃｏｉｎｅｃｔ ３６　　　　　　　　ｒｅｃｖ ３７　　　　　　　５ｅｎｄ ３８　　　　　　　５ｅｔｈｏｓｔｉｄ３９　　　　　
　　５ｅｔｈｏｓｔｎａｌｅ４０　　　　　　　　ｓｈ
ｕｔｄｏｗｎ４１　　ＩＩ　　ｏｔｈｅｒ　　ｂａｓｅ
　　ｅｖｅｎｔｓ４２　　　　　　　ａｄｄｕｓｅｒ　
ｆａｉ１４３　　　　　　　　ａｄｄｕｓｅｒ　　ｏｋ
４４　　　　　　　　ａｔ　　ｆａｉｌ４５　　　　　
　　ａｔ　ｏｋ ４６　　　　　　　ｃｈｐａｒｍ　ｏｋ４７　　　　　
　　　ｄｅｖｉｃｅ　　ｏｋ４８　　　　　　　ｄｓｉ
ｐｃ　ｆａｉ１４９　　　　　　　ｄｓｉｐｃ　ｏｋ ５０　　　　　　　ｄｓｋｐｒｏｃ　　＃　ｄｓ　５ｅ
ｒｖｅｒ　　ａｕｄｉｔ　ｅｖｅｎｔ５１　　　　　　
　ｄｓｒｐｃ　　　ｌ　ｄｓ　ｃｌｉｅｎｔ　ａｕｄｉ
ｔ　ｅｖｅｎｔ５２　　　　　　　ｅｒｒｓｔｏｐ　ｏ
ｋ５３　　　　　　　　ｅｘｉｔ　　　　＃　　１ｎｔ
ｅｒｎａｌ　　ｋｅｒｎｅｌ　　ｅｘｉｔｒｏｕｔｉｎ
ｅ ５４　　　　　　　ｆｓｃｋ　ｏｋ ５５　　　　　　１ｎｓｔａｌｌｐ　ｏｋ５６　　　　
　　　ｌｏｇｉｎ−ｆａｉｌｓｌ　　ｌｏｇｉｎ　　ｐ
ｒｏｃｅｓｓ　　ｆａｉｌｅｄ５７　　　　　　　ｌｏ
ｇｉｎ　ｏｋ ｓｌ　　ｌｏｇｉｎ、ｐｒｏｃｅｓｓ ｓｕｃｃｅｓｓｆｕｌｌｙ　　ｃｏｍｐｌｅｔｅｄ５８
　　　　　　１ｏｇｏｕｔ−ｏｋ ＃　　ｌｏｇ　　ｏｕｔ　　５ｕｃｃｅｓｓｆｕ１５９
　　　　　　　ｍｄｉｓｋ　ｏｋ ６０　　　　　　　　ｍｏｕｎｔ　　ｏｋ６１　　　　
　　　ｎｅｖｇｒｐ　ｆａｉ１６２　　　　　　　ｎｅ
ｖｇｒｐ　ｏｋ６３　　　　　　　ｐａｓｓｖｄ　ｆａ
ｉｌ終　ｃｈａｎｇｅ　　ｐａｓｓｗｏｒｄ　　ｆａｉ
ｌｅｄ６４　　　　　　　ｐａｓｓｗｄ　ｏｋ＃　　ｃ
ｈａｎｇｅ　　ｐａｓｓｗｏｒｄｃｏｍｐｌｅｔｅｄ ６５　　　　　　　ｐｄｅｌａｙ　ｏｋ６６　　　　　
　　ｐｄｉｓａｂｌｅ　ｏｋ（５７ｐｅｎａｂｌｅ　ｏ
ｋ ６８　　　　　　　ｐｈｏｌｄ　ｏｋ ６９　　　　　　　ｐｒｉｎｔ　ｃａｎｃｅ！７０　　
　　　　　ｐｒｉｎｔ　ｒｅｑｕｅｓｔ７１　　　　　
　　ｐｒｉｎｔ　５ｔａｒｔ７２　　　　　　　ｐｓｈ
ａｒｅ　ｏｋ７３　　　　　　　ｐｓｔａｒｔ　ｏｋ７
４　　　　　　　ｓｈｕｔｄｏｗｎ　ｏｋ７５　　　　
　　　５ｉｎｓｔａｌｌｃｋ７６　　　　　　　ｓｍ　
１ｎｉｔａｌｉａｓｅｓ１　　ｓｅｎｄｍａｉｌ ？７　　　　　　　ｓｍ−ｏｋ　　　１　ｓｅｎｄｍａ
ｆ１７８　　　　　　５ｕＪａｉ１ ７９　　　　　　５ｕ−ｏｋ ８０　　　　　　　　ｕｇｓｙｎｃ ８１　　　　　　　ｕｍｏｕｎｔ　ｆａｉ１８２　　　
　　　　　ｕｍｏｕｎｔ　　ｏｋｇ３　　　　　　　ｖ
ａｒｙｏｆｆ　ｏｋ８４　　　　　　　ｖａｒｙｏｎ−
ｏｋ８５　　ＩＩ　　ＴＣＰ／ＩＰ　　ｃｏｍｍａｎｄ
　ｅｖｅｎｔｓ８６　　　　　　　　　　ｈｏｓｔｎａ
ｍｅ　　５ｅｔ８７　　　　　　　ｎｅｔｃｏｎｆｉｇ
　ａｄｄ、　　ｎｅｔｃｏｎｆｆｇ　ｄｅ１８８　　　
　　　　ｒｏｕｔｅ　ａｄｄ、　　ｒｏｕｔｅ　ｄｅ１
８９　　　　　　　５ｅｔｃｌｏｃｋ　　５ｅｔ９０　
　　　　　　ｔｎｊｏｇｉｎ　ｆａｉｌ、　　ｔｎ−１
ｕｇｉｎ　ｏｋｇｌ　　　　　　　ｔｎｄ　　ｌｏｇｉ
ｎ　ｆａｉｌ、　　ｔｎｄ　　ｌｏｇｉｎ　ｏｋｇ２　
　　　　　　ｘｆｔｐｄ　ｌｏｇｉｎ−ｆａｉｌ、　　
ｘｆｔｐｄ　　ｌｏｇｉｎ　ｏｋｇ３　　　　　　　　
ｘｆｔｐ　二１ｏｇｉｎ　　ｆａｉｌ、ｘｆｔｐ　　ｌ
ｏｇｉｎ　　ｏｋｇ４　１　　ａｄｍｉｎｉｓｔｒ’ａ
ｔｉｖｅ　　ｅｖｅｎｔｓ９５　　　　　　　ｌｏｇｉ
ｎ：　　ｌｏｇｉｎ　ｆａｉｌ、　　ｌｏｇｉｎ　ｏｋ
。

１ｕｇｏｕｔ　ｏｋ、　　ｓｕ　ｆａｉｌ。

ｓｕ　ｏｋ、　　＼ ９’６　　　　　　　　　　　ｔｈ−１ｕｇｉｎ−ｆａ
ｉｌ、　ｔｎ−１ｕｇｉｎ−ｏｋ、　　＼ ９７　　　　　　　　　　　ｔｎｄ　ｌｏｇｉｎ　ｆａ
ｉｌ、　ｔｎｄ−１ｕｇｉｎ　ｏｋ、　　＼ ９８　　　　　　　　　　ｘｆｔｐ　ｌｏｇｉｎ　ｆａ
目、　ｘｆｔｐ−１ｕｇｉｎ　ｏＬ　　＼ ９９　　　　　　　　　　　ｘｆｔｐｄ　ｌｏｇｉｎ−
ｆａｉｌ、　ｘｆｔｐｄ−１ｕｇｉｎ　ｏｋ １００　　　　　　　ｐｒｏｃ　ｃｒｅａｔｅ：　ｆｏ
ｒｋｌ　　ｐｒｏｅｅｓｓ　ｃｒｅａｔｅ　ｅｖｅｎｔ
ｌｏｌ　　　　　　ｐｒｏｃ　ｄｅｌｅｔｅ：　ｋｉｌ
ｌ、　ｒｅｘｉｔ、　ｅｘｉｔｎ　ｐｒｏｃｅｓｓ　ｄ
ｅｌｅｔｅ　ｅｖｅｎｔ１０２　　　　　　ｏｂｊ−ｃ
ｒｅａｔｅ：　ｃｒｅａｔ、　ｍｋｎｏｄ、　ｍｋｄｉ
ｒ。

ｈｄｉｒ ＩＩ　　ｏｂｊｅｃｔ　ｃｒｅａｔｅ　　ｅｖｅｎｔ１
０３　　　　　　ｏｂｊ　ｄｅｌｅｔｅ＋　ｕｎｌｉｎ
ｋ、　ｒｍｄｉｒｌ　ｏｂｊｅｃｔ　ｄｅｌｅｔｅ　ｅ
ｖｅｎｔ１０４　　　　　ｄｓ　ｃｌｉｅｎｔ：　”ｄ
ｓｒｐｃＩＩ　　ｄｓ　ｃｌｉｅｎｔ　ａｕｄｉｔ　ｅ
ｖｅｎｔ１０５　　　　　　ｄｓ　５ｅｒｖｅｒ：　ｄ
ｓｋｐｒｏｃ叢ｄｓ　５ｅｒｖｅｒ　ａｕｄｉｔ　ｅｖ
ｅｎｔ表Ａ　監視デーモンの擬似コード 春　監視デーモン擬似コード、／ｅｔｃ／ａｕｄｉｔｄ
”　　／ｅｔｃ／ｒｃ内、たとえば 傘　　鱒監視デーモンを実行する。

”　　　／ｅｔｃ／ａｕｄｉｔｄ　　ｌ　ｎｏ　＆＊１ ｍａｉｎ（） ／宰回復ステップを開始する６／ ／６その監視は回復ステップの間オフであるものとする
。′／ ａｓｓｅｒｔ（ａｕｄｉｔｉｎｇ　ｉｓ　ｏｆｆ）Ｓ／
＊ ネ最初に、ａ　ｔｒａｉｌ、ｐａｓｔ及びａ　ｔｒａｉ
ｌネの不変特性を再確立する。ただし、 傘　不変特性（ａ　ｔｒａｉｌ、ｐａｓｔ）　”　ｒす
＊　べての閉じたセラシロン上のデー ＊　　タ」 傘　不変特性（ａ　ｔｒａｉｌ）　：　ｒ既存の開いた
セラシロン上のデータ」 ＊／ ｉｆ　（ａ−ｔｒａｉ目ｓ　ｎｏｔ　ｅｍｐｔｙ）ａｓ
ｓｅｒｔ　（ｎｏｄｅ　ｆａｉｌｕｒｅ　ｏｃｃｕｒｒ
ｅｄｄｕｒｉｎｇ　ｏｐｅｎ　ａｕｄｉｔｉｎｇ　５ｅ
ｓｓｉｏｎ）Ｓｒｅａｄ　ａ−ｔｒａｉｌ　ｅｎｔｒｙ
　：　ｔｒａｉｌ、　ｂｅｇｉｎ−ｔｉ＋ａｅ； ｌｅｔ　ｘ　＝　ｂａｓｅｎａｍｅ　（ｔｒａｉｌ）：
／掌ファイルｘ、ｃｔｌ　は値Ｎｅｘｔ１Ｌｏｗ１及び
Ｆｌａｇを含む。′／ ｒｅａｄ　　Ｎｅｘｔ　　ｆｒｏｍ　　ｘ、ｃｔｌ　　
ｆｉｌｅ：ｆｆ　（ｅｎｄ　ｏｆ　５ｅｓｓｉｏｎ　ｒ
ｅｃｏｒｄ　ｎｏｔａｌｒｅａｄｙ　ａｔ　ｅｎｄ　ｏ
ｆ　ｂｉｎ　ｆｉｌｅ（Ｎｅｘｔ−１）　） ａｐｐｅｎｄ　ｅｎｄ　　ｏｆ　５ｅｓｓｉｏｎ　ｒｅ
ｃｏｒｄｔｏ　ｂｉｎ　ｆｉｌｅ　（Ｎｅｘｔ−１）；
ｔｆ　（ｂｅｇｉｎ　ｔｉｍｅ　ｏｆ　１ａｓｔ　ｒｅ
ｃｏｒｄ　ｉｎａ　ｔｒａｉｌ、ｐａｓｔ　！　＝　ｂ
ｅｇｉｎ　ｔｉｍｅ）ａｐｐｅｎｄ　　ｅｎｄ　　ｔｉ
ｍｅ’ｄ　　ａ　　ｔｒａｉｌ　　ｅｎｔｒｙｔｏ　　
ａ　　ｔｒａｉｌ、ｐａｓｔ：ｅｍｐｔｙ　ａ　ｔｒａ
ｉｌ； ａｓｓｅｒｔ　　（ｉｎｖａｒｉａｎｔｓ　　ｏｆ　　
ａ　　ｔｒａｉｌ″ｐａｓｔａｎｄ　ａ　ｔｒａｉｌ　
ｒｅｅｓｔａｂｌｉｓｈｅｄ）；１０第２に１ｓｅｓｓ
ｉｏｎＣｏｍｐｒｅｓｓｉｏｎ　Ｏの不変特性ａＯを再
確立する。。／ ５ｅａｒｃｈ　ａ　ｔｒａｉｌ、ｐａｓｔ　ｆｏｒｗａ
ｒｄｓ、　１ｄｅｎｔｉｆｙｔｈｅ　ｙｏｕｎｇｅｓｔ
　ｕｎｃｏｍｐｒｅｓｓｅｄ　５ｅｓｓｉｏｎ：ｉｆ　
（ａｎ　ｕｎｃｏｍｐｒｅｓｓｅｄ　５ｅｓｓｉｏｎ　
ｅｘｉｓｔｓ）”　Ｎ、Ｂ、　　このコードは機能５ｅ
ｓｓｉｏｎ＊　Ｃｏｍｐｒｅｓｓ　（）内の断定 ”　ａｏ−ａ５及び５ｌ−ｓ４の精密な解析中に基づく
。

＊／ ｌｅｔ　　Ｔｒａｉｌ　　＝　　ｉｔｓ　　ａｕｄｉｔ
　　ｔｒａｉｌ　　ｆｉｌｅ：ｌｅｔ　ｘ　＝　ｂａｓ
ｅｎａｍｅ　　（Ｔｒａｉｌ）；ｒｅａｄ　Ｌｏｗ　ａ
ｎｄ　Ｆｌａｇ　　ｆｒｏｍ　　ｘ、ｃｔ、ｌ　　ｆｉ
ｌｅ：ｉｆ　　（Ｆｌａｇ　”　１） ｓｅｒｃｈ　Ｔｒａｉｌ　　ｂａｃｋｗａｒｄｓ、ｆｏ
ｒ　　ｔｈｅｆｉｒｓｔ　　ｒｅｃｏｒｄ　　ｗｉｔｈ
　　ｔｈｉｓ　　ｎｉｄ、ａｎｄｇｅｔ　ｂｉｎ叢； Ｆｏｕｎｄ　＝　（Ｌｏｗ　＝＝　ｂｉｎｌｌ）；　／
”真または偽＊／ ｉｆ　（ｂｉｎ　ｆｉｌｅ　ｘ、Ｌｏｗ　ｅｘｉｓｔｓ
　＆＆Ｆｏｕｎｄ）　ｒｅｍｏｖｅ　ｆｉｌｅ　ｘ、Ｌ
ｏｖ；ｉｆ　（Ｆｏｕｎｄ）　＋＋Ｌｏｗ； Ｆｌａｇ　＝　Ｏ： ｗｒｉｔｅ　Ｌｏｗ　ａｎｄ　Ｆｌａｇ　ｔｏ　ｘ、ｃ
ｔｌ；ａｓｓｅｒｔ　（ｒｅｃｏｖｅｒｙ　ｄｏｎｅ）
；／＊回復ステップ終了＊／ ／”　ｆｏｒｋ　　ステップ開始＄７ ｆｏｒｋ　ａ　ｃｈｉｌｄ　ｆｏｒ　ｎｏｒｍａｌ　ｏ
ｐｅｒａｔｉｏｎ　ａｎｄｅｘｉｔ　　ｔｈｅ　ｐａｒ
ｅｎｔ　ｓｏ　ｔｈａｔ　／ｅｔｃ／ｒｅｃａｎ　ｃｏ
ｎｔｉｎｕｅ　ｗｉｔｈ　ｃｈｉｌｄ　ｆｎｂａｃｋｇ
ｒｏｕｎｄ： ／”　ｆｏｒｋ　　ステップ終了傘ｌ ｌ傘通常動作ステップ開始宰ｌ ／８ 宰−時に１つの監視セツションを圧縮 ＊する。

＄古いものから順にセツションを圧縮 ＊する。

＊１ ｆｏｒ　に；） ｅｘａｍｉｎｅ　ａ　ｔｒａｉｌ、ｐａｓｔ　ｔｈｅｎ
　ａ−ｔｒａｉｌｆｏｒ　ｏｌｄｅｓｔ　ｕｎｃｏｍｐ
ｒｅｓｓｅｄ　５ｅｓｓｉｏｎ；／幸セッシロンは、そ
のセツション圧 縮フラグが０のときは、圧縮され ていない。ｔノ ｉｆ　（ｓｏｍｅ　ｕｎｃｏｍｐｒｅｓｓｅｄ　５ｅｓ
ｓｉｏｎ）ｌｅｔ　ｔｒａＨ＝　ｔｈｅ　ａｕｄｉｔ　
ｔｒａｉｌ　ｆｉｌｅｎａｍｅ　　ｏｆ　　ｔｈｉｓ　
　５ｅｓｓｉｏｎ；ａｓｓｅｒｔ　（ｓｅｓｓｉｏｎ　
ｕｎｍａｒ−ｋｅｄ）：ｓｅｓｓｉｏｎｃｏｍｐｒｅｓ
ｓ　（ｔｒａｉｌ）：ａｓｓｅｒｔ　（ｓｅｓｓｉｏｎ
　ｃｏｍｐｒｅｓｓｅｄ　＆＆５ｅｓｓｉｏｎ　　ｕｎ
ｍａｒｋｅｄ）；ｍａｒｋ　ｔｈｅ　５ｅｓｓｉｏｎ　
ａｓ　ｃｏｍｐｒｅｓｓｅｃｌａｓｓｅｒｔ　　（ｓｅ
ｓｓｉｏｎ　　ｍａｒｋｅｄ）：１ｓｅ ｓｌｅｅｐ　ｆｏｒ　ａｗｈｉｌｅ ）　　／”　ｍａｉｎ　（）の最後の行。魯ｌｓｅｓｓ
ｉｏｎｃｏｍｐｒｅｓｓ　　（ｔｒａｉｌ）ｃｂａｒ　
”　ｔ−ｒａｎ：　／”監視証跡ファイル名：／ｄｉｒ
ｎａ　　ｍｅ／ｂａｓｅｎａｍｅ　　”／／９ 傘特定の監視セラシーン内のすべてのビン＊を圧縮する
。

”　（Ｌｏｗ　＝＝　Ｎｅｘｔ）の場合は、特定のセヅ
シｅ＊ンは既に圧縮されているが、そのように零印をつ
けられていないので、戻る。

６そうでもない場合、セラシロンはＬｏｗ＊で開始し、
最初のセッシ８ン終了しコー＊　ドで終了する。

ｌｅｔ　ｘ　＝　ｂａｓｅｎａｍｅ　（ｔｒａｉｌ）ｉ
ｒｅａｄ　Ｌｏｗ、　Ｎｅｘｔ、　ａｎｄ　Ｆｌａｇ　
ｔｒｏｔｓ　ｘ、ｃｔｌ　ｆｉｌｅｉｌｅｔ　ｂ　＝　
Ｌｏｗ：　／”　ｅｎｔｒｙ−ｖａｌｕｅ　ｏｆ　Ｌｏ
ｗ　”／ａｏ：ａｓｓｅｒｔ　（Ｆｌａｇ　＝＝　Ｏ＆
＆　ｆｉｌｅ　ｂ　ｅｘｉｓｔｓ　＆＆　ｂｎｏｔ　ｏ
ｎ　ｔｒａｍ）： ｉｆ　（Ｌｏｗ　＝＝　Ｎｅｘｔ） ｒｅｔｕｒｎ；　／傘このセラシロンは既に圧縮さてい
るが、そのようにマーク がつけられていない。＊／ ｄｏｎｅ　”　ＦＡＬＳＥ： ｖｈｆｌｅ　（！ｄ−ｏｎｅ） ／嘩最初に、ビンｂを読む。ビンが作動可能でない場合
信、Ｌばらく待っ。傘１ｆｏｒ　　（：：） ｒｅａｄ　ｂｉｎ　ｂ： ４ｆ　（ｂ　ｃｏｎｔａｆａｓ　ｅｎｄ−ｏｆ−ｂｉｎ
　ｏｒ　ｅｎｄ−ｏｒ−５ｅｓｓｉｏｎ　ｒｅｃｏｒｄ
）ｄｏｎｅ　＝　”−Ｍｎ　ｂ　ｃｏｒｔａ４ｎｓ　ｅ
ｎｄ−ｏｆ−ｓｅｓｓｆｏｎ　ｒｅｃｏｒｄ”； ｂｒｅａｋ： ５ｌｅｅｐ　ｆｏｒ　ａｗｈｉｌｅ； ／９第２に、圧１１１されたビンｂを証跡に付加し１フ
ァイルｂを除去する。傘ｌ ａｌ：　　　ａｓｓｅｒｔ　（Ｆｌａｇ　＝＝　Ｏ＆＆
　ｆｉｌｅ　ｂ　ｅｘｉｓｔｓ　＆＆　ｂ　ｎｏｔ　ｏ
ｎ　ｔｒａｉｌ）；ｓｌ：　　　Ｆｌａｇ　＝１：　ｗ
ｒｉｔｅ　Ｆｌａｇ　ｔｏ　ｘ、ｃｔｌ；ａ２：　　　
ａｓｓｅｒｔ　（Ｆｌａｇ　＝＝　１　＆＆　ｆｉｌｅ
　ｂ　ｅｘｉｓｔｓ　＆＆ｂ　ｎｏｔ　ＯＪＩ　ｔｒａ
ｍ）； ｓ２：　　ｃｏｍｐｒｅｓｓ　ｂｉｎ　ｂ；ａｐｐｅｎ
ｄ　ｔｈｅ　３−ｐａｒｔｒｅｃｏｒｄ　（ｈｅａｄ、
　ｂｏｄｙ、　ｔａｉｌ）　ｔｏ　ｔｒａｆｌ：ａ３：
　　ａｓｓｅｒｔ　（Ｆｌａｇ　：＝　１　＆＆　ｆｉ
ｌｅ　ｂ　ｅｘｉｓｔｓ　＆＆ｂ　　（ｏｎ　ｔｒａｉ
ｌ）： ｓ３：　　　ｒｅｍｏｖｅ　ｂｉｎ　ｆｉｌｅ　ｂ＝ａ
４：　　ａｓｓｅｒｔ　（ＦＪａｇ　＝＝　ｉ　＆＆　
ｎｏ　ｆｉｌｅ　ｂ　ｅｘｉｓｔｓ＆＆　ｂ　ｏｎ　ｔ
ｒａｉｌ）： ｓ４：　　　　Ｆｌａｇ　　＝　　０２　　＋＋Ｌｏｙ
：　　ｗｒｉｔｅ　　Ｆｌａｇ　　ａｎｄ　　Ｌｏｗｔ
ｏ　　ｘ、ｃｔｌ： ａ５：　　ａｓｓｅｒｔ　（Ｆｌａｇ　＝＝　Ｏ＆＆　
ｎｏ　ｆｉｌｅ　ｂ　ｅｘｉｓｔｓ＆＆　ｂ　ｏｎ　ｔ
ｒａｉｉ）： ）　　／ｌｐ　ｗｈｉｌｅ終了；ｌ ）　　／”　ｓｅｓｓｉｏｎｃｏｍｐｒｅｓｓ　（）の
最後の行６／

【図面の簡単な説明】

第１図は、分散処理システムで、監視証跡情報が複数の
ノードからどの、ように生成され圧縮されるかを示す図
である。 第２図は、システムＢ及びＣのディレクトリをどのよう
にしてシステムＡ上に遠隔的にマウントすることができ
るかを示す、第１図と同様な図である。 第３図は、クライアント・システムがどのようにしてサ
ーバ・システム上のファイルにアクセスすることができ
るかを示す、第１図と同様な図である。 第４図は、２つの階層的ファイル・システムを含むネッ
トワークの図である。 第５図は、実際の監視証跡ファイルの構造を示す図であ
る。 第６図は、監視デーモン・プロセスの流れ図である。 第７図は、本発明のアーキテクチャ・ダイヤグラムであ
る。 笛２回

Claims (1)

1. 【特許請求の範囲】 　クライアント・ノードのクライアント処理システムが
   サーバ・ノードのサーバ処理システム中のファイルにア
   クセスすることのできるシステムにおける、上記クライ
   アント処理システム中の事象のオンライン監視を行ない
   、かつ上記サーバ処理システム中の上記事象の監視情報
   のオンライン圧縮を行なう分散式監視サブシステムであ
   って、上記クライアント処理システム中の所定の事象の
   組の生起をモニタし、かつ上記事象の生起に応答して監
   視レコードを作成する、上記クライアント処理システム
   中の監視デーモンと、 上記クライアント処理システムに関連する一時的記録フ
   ァイルを含む上記サーバ処理システム中のディレクトリ
   の遠隔仮想マウントを行なう、上記クライアント処理シ
   ステム中の分散サービス手段とを備え、 上記クライアント処理システム中の上記監視デーモンが
   、上記サーバ処理システム中の上記遠隔マウントされた
   ディレクトリ中の上記一時的記録ファイルに上記監視レ
   コードを書き込む手段を有し、上記クライアント処理シ
   ステム中の上記監視デーモンが、上記監視レコードを含
   む上記一時的記録ファイル中の１つの記録に対して動作
   し選択された記録を圧縮し圧縮された記録を上記サーバ
   処理システム中の上記遠隔マウントされたディレクトリ
   中の永久的監視記録に書き込むデータ圧縮手段を有する
   、 分散式監視サブシステム。