square.gif GroundWork ネットワーク管理スイート(NMS)

Topic Home Print Page Send Comments

NMS NEDI

目次 表示

NeDi について

NeDiはスイッチやルータのようなネットワークを構成するデバイスを管理するためのオープンソースツールキットで、GroundWork Network Management Suite(NMS)のオプションコンポーネントとしてGroundWork Monitorに統合されてます。GroundWorkのNMS NeDiパッケージがインストールされると、”NeDi”のメニューがメインのドロップダウンメニューに現れます。

簡単に言うと、NeDiはルータやスイッチのような構成デバイスを管理するための統合されたツールキットです。GroundWork Monitor内のほとんどのコンポーネントがネットワーク上のデバイスを監視(ホスト上の利用可能なリソースを計測し、条件を満たせばアラームを生成する、といったような)する目的でデザインされていますが、NeDiは管理者が特定の構成デバイスを管理すること(ネットワークトポロジへの検出や監視の変更、ネットワーク上のスイッチとルー他の構成設定の操作など)をサポートするためにデザインされています。

より具体的に言うと、NeDiはネットワーク上の構成デバイスの場所を特定するために、色々な検出技術を使用し、プローブするために別の技術を使用して詳細を得るために検出したデバイスに問い合わせを行い、最終的にはダイナミックデータベースに検出したデータを保存します。そこから、管理者はネットワークデバイスとそれぞれの関係についての情報の表示、基本的な管理タスクのいくつかの実行、そしてネットワーク上の予期しない変更に対するアラートなどを行うためにNeDiのWebインタフェースを使用することができます。NeDiはまた設定のバックアップと編集ツール、デバイス管理機能セットをより特化したインベントリの管理機能を提供します。

このドキュメントは基本設定とNeDiの操作について述べています。より詳しい情報については オンラインの NeDi セットアップドキュメントオンラインの NeDi GUI ドキュメント.を参照します。

Configuring the NeDi パッケージの設定

GroundWork NMS NeDi パッケージは、GroundWork Monitor 、他のアプリケーションから独立してインストールされ、また固有の構成設定プロセスも持っています。

NeDiの起動と停止

NeDiとNMSアプリケーションのほとんどはGroundWork Monitorによって使用されるサーバとは別に特化したアパッチサーバを使用するWebベースのアプリケーションとして組み込まれています。そのApcheサーバはNeDiのWebページにアクセスする前に起動する必要があります。Apacheサーバは /etc/init.d/nms-httpd を使用して、起動・停止が行われます。初期設定ではこのスクリプトはシステムの起動時に自動的に実行されます。

NMSに特化したApacheサーバを手動で停止するにはルート権限を持つユーザでログインし、以下のコマンドを実行します:

/etc/init.d/nms-httpd stop

NMSに特化したApacheサーバを手動で停止するにはルート権限を持つユーザでログインし、以下のコマンドを実行します:

/etc/init.d/nms-httpd start

NMSに特化したApacheサーバが自動的に起動するのを防ぐ場合はルート権限を持つユーザでログインし、以下のコマンドを実行します:

chkconfig --del nms-httpd

スクリプトを再度有効にするには、ルート権限を持つユーザでログインし、以下のコマンドを実行します:

chkconfig --add nms-htppd

ユーザアクセスの管理

NeDiのWebのフロントエンドはGroundWork Guavaの使用によってGroundWork Monitorに統合されていますがNeDiのWebページはNMS特化のApacheのインスタンスによって提供されます。つまり、NeDiにアクセスできるパーミッションを持つ適切なロールを持つユーザはGoundWork Monitorにログインし、アプリケーションランチャーからNeDiを選択することでNeDiにアクセスすることができます。

しかしながら、NeDiは独自のユーザアカウントとアクセスコントロールを持ち、それはGroundWorkのコントロールから独立しています。具体的に言うとNediはユーザネーム”admin”、パスワード”admin”という設定墨の管理者アカウントのみ持っています。それ以上に、ビルドインのWebページのほとんどは無制限であり、認証を必要とされません。NeDiのWebサーバや他のページへのアクセスを制限したい場合はNeDi内で適切なユーザコントロールとアクセスコントロールを作成する必要があります。

このプロセスはGroundWork Monitorのメインメニュー内にあるどのユーザがNeDiにアクセスさせるかを決めるプロセスとは別のものです。NeDiのメインメニューへのユーザアクセスの設定についての情報は管理者ドキュメントの”ロールの設定”セクションを参照します。

ユーザアカウントの管理

GroundWork NMSのNeDiパッケージはユーザがGroundWork Monitorを通じて最初にNeDiにアクセスすると自動的にNeDiにユーザアカウントを作成する技術を含んでいます。つまり、ユーザが他のページへアクセスするためにNeDi内でユーザを明示的に作成する必要はありません。しかし、時々ユーザアカウントを直接管理する必要があります。

NeDiのユーザカウントを管理するには管理者権限でNeDiにログインし、画面上の”User”メニューにマウスを移動し、”Accounts”メニューアイテムでクリックをします。すると、以下のように現在定義されているユーザアカウントがリストアップされた画面が表示されます:

NeDi User List

新しいユーザアカウントを追加する場合は右上にある”User”のボックスに希望するユーザ名を入力して、その隣にある”Add”ボタンをクリックします。新規ユーザがリストの下にある状態で現在の画面がリロードされます。

一度、ユーザアカウントが作成されると”Groups”カラムにある小さなアイコンをクリックすることで、そのアカウントは定義されたNeDiグループに関連さえることができます。NeDiグループについての詳細な情報は下のアクセスコントロールの管理セクションを参照します。

希望するアカウントの右にある鍵のアイコンをクリックすることでユーザのパスワードをリセットすることも可能です。これはユーザの現在のパスワードを削除し、該当のユーザアカウントによってリセットされるまで空の状態になります。

パスワードやフルネームといったユーザ固有の詳細を変更する場合はそのユーザアカウントでGroundWork Monitorへログインし、メインメニューからNeDiへ移動して画面上の”User”メニューを選択し”Profile”メニューをクリックします。すると以下と同じような現在のユーザのアカウントの詳細についての画面が表示されます:

Modify User Details

E-mailと電話番号のフィールドはアラートオペレーションの際に使用され、NeDiのアラートをユーザが受け取る場合は定義される必要があります。このユーザをそれらのアクティビティからはずしたい場合は関連するグループから削除するか連絡先データを削除する必要があります。

ユーザアカウントを削除するにはメインのユーザアカウントページに戻り、削除を希望するアカウントの右にある赤い”X”のアイコンをクリックします。削除の確認が表示されます。

アクセスコントロールの管理 

NeDiのアクセスコントロールは基本的にグループベースのアクティビティフィルターでフィルターされます。特定のグループに属するユーザは自動的にそのグループに関連するWebページへのアクセスが許可され、そのグループと自動的につながるタスクのいくつかにも関連します。例えば、NeDiはクリティカルなイベントが検出されると、監視部ループのメンバーにe-mailとSMSメッセージを送るデバイス監視スクリプトを提供します。

定義済みのNeDiのグループは以下です:

アカウントのグループメンバーシップを編集するには画面上の”User”にマウスを移動し、”Accounts”をクリックします。現在定義されたユーザアカウントが表示されたら、アカウントを有効/無効にするために”Groups”カラムにある適切な小さなアイコンをクリックします。マウスのそのグループのヘルプ情報をえるためにカーソルをアイコンの上に持っていくこともできることに注意します。

あるグループに特定のモジュールが使えるよう変更をしたい場合は、後で紹介されるnedi.confファイルを編集することによって可能になります。

検出方法の設定

先に述べたようにNeDiはネットワーク上の構成デバイスの位置を特定するために色々な検出技術を使用します。一般的にはNeDiはまず、1つ以上のスタートデバイスの位置の特定を試み、その後近隣のデバイスを特定するためにある検出方法を使用します。このアプローチはNeDiが立ち上がりと起動をすばやく行うと同時にネットワークの総合的なマップを作成することが可能になります。

検出プロセス自身はスクリプトへのコマンドラインパラメータとして特定される検出技術とともに   /usr/local/groundwork/nms/applications/nedi/seedlist perl スクリプトによって実行されます。

NeDiによってサポートされる検出技術は以下のとおりです:

もし、あるデバイスが上述の検出方法で検出がされない場合、それがシードリストにリストされていない限り検出されません。例えばCDPやLLDP対応ではない小さなルータで初期のOUI検出にも一致しない場合、検出される必要があればシードリストファイルで特定する必要があります。

検出プロセスをデバックする必要がある場合、nedi.plスクリプトを直接起動して、異なる検出方法の結果を確認します。しかしながら、スクリプトはファイルとデータベースのパーミッションが変更されていないことを確認するため、ユーザnagiosで実行される必要があります。したがって、GroundWorkサーバにターミナルでログインし、スクリプトを実行する前にユーザnagiosにスイッチするために”su nagios”を使用します。必要であれば、デバックと詳細なレスポンスを有効にするためにnedi.plスクリプトに-dや-vオプションをつけることも可能です。

GroundWork NMS NeDiのパッケージは自動的にnedi.plスクリプトにユーザアカウントnagiosのctontabファイルに追加し、それをCDP,LLDP,OUIによる検出方法が可能な状態で毎4時間ごとに起動するようスケジュールします。(別のcrontabが設定のバックカップを作成するために真夜中に起動し、以下の様に分かれてドキュメント化されます。)この動きを編集するために以下のステップを実行します:

  1. root権限でGroundWorkサーバにログインします。

  2. コマンドプロンプトからnagiosアカウントに関連するcrontabファイルを編集するために"crontab -u nagios -e"のコマンドを実行します。

  3. "nedi.pl -clo"のcrontabエントリの位置を特定し、必要であれば編集を行います。スケジューラーの時間の間隔を変更した場合はNeDiに新しい間隔を通知することでグラフが正しい時間で表示されます。これを行うためには、/usr/local/groundwork/nms/applications/nedi/nedi.conf ファイルをテキストエディタで開き、"rrdstep"の値を新しいものにセットし、ファイルをセーブします。

  4. Crontabファイルをセーブしてエディタを終了します。Cronデーモンは自動的に新しいパラメータを現在のスケジュールに組み込みます。

もし、シードデバイスを手動で定義したい場合は初期設定の/usr/local/groundwork/nms/applications/nedi/seedlist ファイルを使用するか、独自のシードリストファイルを定義してもかまいません。もし、独自で定義する場合はnedi.pl検出スクリプトに-uパラメータと上述の crontab エントリにファイルのパスを追加する必要があります。シードリスト内のエントリにはスタートデバイスのIPアドレスあるいはホスト名、あるいはSNMPのコミュニティストリングが入っている必要があります。SNMPのコミュニティが定義されていない場合は ned.conf からのSNMPコミュニティストリングは、/usr/local/groundwork/nms/applications/nedi/seedlistになります。

SNMPコミュニティストリングの初期設定

新しく検出されたデバイスをプローブするためにNeDiによって使用されたSNMPコミュニティストリングは、 /usr/local/groundwork/nms/applications/nedi/nedi.conf 設定ファイル内の”comm.”エントリによって定義されます。複数の”comm.”エントリは行ごとのエントリと値で定義され、それぞれは全ての検出されたデバイスに成功した順番で試みます。

By default, the GroundWork NMS NeDi package defines the single community string value of "public".

初期設定ではGroundWork NMS NeDiパッケージは”public”を単一のコミュニティストリングとして定義しています。

注意: nedi.confファイルはタブによって分けられたエントリと値で正確なシンタックスを使用します。Nefi.confファイルを編集する際、このシンタックスを使用する必要があります。

初期設定のCLI認証の初期設定

に述べたように、デバイスの構成設定ファイルのいくつかはそのデバイスにログインし、TELNETかSSHを通してコマンドを発行することで取得されます。NeDiがこのタスクを実行するためにはデバイスに対する認証に使用するログインの証明が提供される必要があります。

使用する認証の証明は、 /usr/local/groundwork/nms/applications/nedi/nedi.conf ファイル内の”usr”エントリで定義されます。それぞれの”usr”エントリは1つから3つのフィールドを含んでいます。:1つ目のフィールドはユーザ名を特定し、2つ目はアクセスパスワード、3つ目はCiscoのデバイスに追加のアクセスする際に使用される有効なパスワードを含んでいます。複数の”usr”エントリは行ごとのエントリで定義され、それぞれは全ての検出されたデバイスに成功した順番で試みます。

初期設定ではGroundWork NMS NeDiパッケージは”usr”エントリを定義しません。

注意: nedi.confファイルはタブによって分けられたエントリと値で正確なシンタックスを使用します。nedi.conf ファイルを編集する際、このシンタックスを使用する必要があります。

IPアドレスによる検出の制限

NeDiがローカルの検出に使用する技術はネットワークの外側にあるデバイスも検出することができ、NeDiが強制的にあるネットワークからブロックされない限り、インターネット全体を検出しようとります。NeDiのIPアドレスによる検出の制限の主な方法は、/usr/local/groundwork/nms/applications/nedi/nedi.conf  ファイルにある”netfilter”エントリです。この値は検出されたIPアドレスと比較した正規表現であり、NeDiはその正規表現と一致しないIPアドレスを破棄します。

例えば、192.168.1.*のネットワークでNeDiにIPアドレスの制限をかけたい場合、netfilterエントリに"^192\.168\.1"の値を定義することができます。一方で例えば、192.168.1.*と10.*.*.*のネットワークでNeDiにIPアドレスの制限をかけたい場合"^192\.168\.1|^10\."の値をnetfilterエントリに定義することが可能です。Netfilterの値に一致しないアドレスが検出された場合は、破棄されます。

初期設定ではGroundWork NMS NeDiパッケージはアドレスフィルターを全てのIPが一致する”.”を定義しています。

注意: nedi.confファイルはタブによって分けられたエントリと値で正確なシンタックスを使用します。nedi.confファイルを編集する際、このシンタックスを使用する必要があります。

MACアドレスによる検出の制限

OUIによる検出を使用している場合、 /usr/local/groundwork/nms/applications/nedi/nedi.conf ファイル内の”ouidev”エントリを編集することでNeDiが使用するハードウェアアドレスに制限を変えることができます。このエントリの値は検出されたハードウェアアドレスの名前と比較される正規表現であり、NeDiはその正規表現と一致しないハードウェアアドレスを破棄します。親密性のあるハードウェアアドレスは、/usr/local/groundwork/nms/applications/nedi/inc/oui.txtファイルにリストアップされています。

初期設定ではGroundWork NMS Nediパッケージは"bay|nortel|netics|xylogics|foundry|XYLAN|Netgear|RUBY"のフィルターを定義しており、検出されない可能性があるプラットフォームよりはより一般的なものです。

注意: nedi.confファイルはタブによって分けられたエントリと値で正確なシンタックスを使用します。nedi.confファイルを編集する際、このシンタックスを使用する必要があります。

デバイスタイプによる検出の制限

NeDiがネットワークデバイスを検出する際に使用する技術は(プリンターなど)構成デバイスとは関連しないデバイス、無視したいデバイスも検出することもあります。NeDiのプラットフォームを制限する検出は/usr/local/groundwork/nms/applications/nedi/nedi.confファイルの”descfilter”にあります。このエントリの値は検出されたデバイスのSNMPストリングと比較される正規表現で、NeDiは正規表現と一致しないデバイスを破棄します。

初期設定ではGroundWork NMS Nediパッケージはプラットフォームフィルターを"LaserJet|JETDIRECT|HP-UX|Linux"と定義しており、それはほとんどのプリンターと、別途の構成デバイスとして検出されるかもしれないUnixプラットフォームと一致します。

多くの小さいルータがLinuxをOSとして使用しており、初期設定のフィルタストリングは検出から自動的にそれらのデバイスを除外します。検出プロセスにおいて検出されたいデバイスがある場合、ストリングから"|Linux"の部分を削除指定ください(デバイスを検出させるためにシードリストファイルにデバイスを加える必要があるかも知れません)。

注意: nedi.confファイルはタブによって分けられたエントリと値で正確なシンタックスを使用します。nedi.confファイルを編集する際、このシンタックスを使用する必要があります。

デバイスの定義管理

NeDiが検出した構成デバイスを持つと、そのデバイスについての追加情報を得るため色々な問い合わせを使用します(これはインストールされたモジュールや使用中のVLANなども含みます。)。しかし、ベンダは異なった位置にこの情報を保存しており、NeDiがこのデータの引き出し方を知るためには最初にデバイスのタイプを特定できなくてはなりません。

これはデバイスの”System Object ID”についてSNMPによる問い合わせを行い、結果をデバイスの定義ファイルと一致させることでなされます。基本的にデバイスの定義ファイルは特定のデバイス上の利用可能な機能についてのもので、そのデータに対してNeDiが問い合わせる必要のある情報をNeDiに提供します。これはデバイスのアイコンとOSのような高度なデータ、CPUとメモリ稼働率についてSNMPのOIDへの問い合わせのような管理データ、そしてインタフェースの詳細のVLANの識別についてSNMPのOIDへの問い合わせのような別々のデータを含みます。

GroundWork NMS Nediパッケージではデバイスの定義ファイルは、 /usr/local/groundwork/nms/applications/nedi/sysobj/ ディレクトリに保存されています。それぞれの聞き定義は既知のSNMP OIDの値で別のファイルで管理されます。NeDiでは150以上の聞き定義ファイルが提供されていますが、これは全てのデバイスの完全なコレクションではなく、古い、あるいは無名のデバイスと統合するためには独自の定義ファイルを作成する必要があるかも知れません。

独自のデバイス定義ファイルを作成したい場合、そのデバイスに良く似た既存の定義をコピーして、編集するか(同じHP ProCurveスイッチの定義をコピーして異なったSNMP OIDのファイル名にする)Webベースの”Defgen”ツールを使用してスクラッチから新しいファイルを作成するかのどちらかです。

Defgenツールを使用するには画面上部に”Other”にマウスを移動し、”Defgen”をクリックします。 フォームが埋められたら、あたらいいデバイス定義ファイルを自動的に作成するために”Write”ボタンをクリックします。

Defgenによって作成されたファイルは自動的に、 /usr/local/groundwork/nms/applications/nedi/html/log/ ディレクトリに保存され、ファイルはnedi.plスクリプトに使用される前に /usr/local/groundwork/nms/applications/nedi/sysobj/ ディレクトリへコピーされる必要があります。Nedi.pl検出スクリプトは検出プロセスが起動するたびにデバイスの定義ファイルを読み込むので、なされた変更はデバイスが検出された自動的に次回更新されます。動作を適切に行うために、このディレクトリにあるファイルはnagiosのユーザアカウントによって読み込みが可能である必要があります。

一般的なNeDiのタスクの実行

イントロダクションで記述したように、NeDiはネットワーク上の構成デバイスの位置を特定するために色々な検出方法を使用し、検出したデバイスの追加情報をプローブし問い合わせるために別の方法を使用し、そしてNeDiのWebインタフェースを通じて管理者に利用できるダイナミックデータベースの中に検出したデータを保存します。

もっとも多く使用されているWebページの簡単な記述がこのセクションの残りで提供されます。より詳しい情報については、オンライン NeDi ドキュメント オンラインのNeDiドキュメントを参照します。NeDiのWebページのそれぞれがページの右上にある救命具のアイコンをクリックすることでアクセスが可能なヘルプを提供します。

検索と表示フィルターの使用

リストビューを提供する全てのNeDiのWebページは最初にユーザがリスト結果で戻ってくるデータ量を制限することが可能なサーチフィルタダイアログが表示され、それはサーチ結果に含みたいフィールドを特定することが可能になります。特定のサーチフィルタはそれぞれのフィールドに対して別のものですが、一般的に以下と同じようなものです:

NeDi Search Filter

期設定のサーチフィルタは何もフィルターしないので、サーチ結果を制限したくない場合は単純にダイアログの右にある”Show”ボタンを押下すると現在のリソースタイプの既知のエントリが表示されます。

結果をフィルターしたい場合、サーチフィルタダイアログは二つの異なったフィルターを定義することが可能です(上にあるような”Condition A”と”Conditon B”です)。それはまた、ある方法で統合することが可能です(これは”Combination”インプットで管理されます)。初期設定では”Condition A”のフィルターは空で(つまり全てのエントリに一致します)、”Condition B”のフィルタは完全に無視されます(これは”Condition A”のみ表示している”Combination”のインプットで示されています)。

サーチフィルタのクライテリアとは別にダイアログボックスは現在のリソースタイプのための既知のデータベースフィールドのリスとボックスを持っており、ユーザが戻ってくるフィールドを決定することが可能です。フィールドの初期の設定はそれぞれのリソースタイプによって異なります(例えば、構成デバイスの検索はVLAN検索とは違うフィールドが戻ってきます)。

構成デバイスリスト

NeDiは検出した構成デバイスのシンプルなテーブル表示を提供し、ネットワーク構成をすばやく調査することができます。このデータを表示するには画面上の”Device”にマウスを移動し”List”をクリックします。検索と表示フィルターの使用セクションで記述されていたものと同じような検索画面が表示され、適用したフィルターに定義することが可能になります。検出された全ての構成デバイスを表示したい場合、単純に右にある”Show”ボタンをクリックすると、以下と同じようなサーチフィルターの下に新しいテーブル内にリストアップされた既知のデバイスを表示した画面がリロードされます:

NeDi Device List

初期設定ではNeDiは検出された構成デバイスに対して以下のデータを表示します:

希望があれば、検索フィルターダイアログぼっくの右側で”r;Display”フィルターのインプットで選択されたアイテムを編集することによって表示されたフィールドを変更することができます。

構成デバイス詳細データ

NeDiは検出された構成デバイスのそれぞれに対して詳細画面を提供し、デバイスの構成設定と利用可能な機能を確認することが可能になります。このデータを表示するために、デバイスリストのWebページ(先のセクションで説明した)にあるアイコンをクリックするか、画面上の”Device”にマウスを動かし”Status”でクリックしてそれから表示されたドロップダウンのリストからデバイスを選択してもどちらかが可能です:以下と同じような画面が選択されたデバイスの詳細情報とともに表示されます:

NeDi Device Detail

TNeDiのデバイスステータスページは選択したデバイスの異なったタイプのデータを持つテーブルのセットを表示します。テーブルのそれぞれはデバイスの拡張性と関連する定義ファイルにより変わります。表示されるテーブルは以下です:

Node リスト

NeDiは検出されたネットワークのノードの単純なテーブル表示を提供します。それは全体としてネットワークをすばやく確認することが可能です。このデータは構成デバイスに対しても提供されるので、他のノードと同じ方法で利用可能な特性を表示することが可能です。このデータを表示するには画面上の”Nodes”にマウスを移動し、”List”をクリックします。上述の検索と表示フィルターの使用セクションで述べたようなものと似た画面が表示され、適用したいフィルタを定義することができます。全ての検出されたネットワークノードを表示したい場合は、右側にある”Show”ボタンをクリックすると、以下と同じようにサーチフィルターの下にリストアップされた新しいテーブルの画面がリロードされます:

Node List

初期設定ではNeDiは検出したノードに対して以下のデータを表示します:

検索フィルタダイアログボックスの右にある”Display”フィルタのインプット内で選択されたアイテムを編集することで表示されているフィールドを変更することが可能です。

Nodeの詳細データ

NeDi は、管理者がノードの利用可能な機能を確認できるネットワークノードの詳細表示を提供します。このデータは構成デバイスに対しても提供されるので、他のノードと同じ方法でこれらのデバイスの利用可能な機能を表示することが可能です。このデータを表示するにはDevice List の Webページにあるデバイスのアイコンをクリックするか、画面上の”Nodes”にマウスを移動し、”Status”をクリックして、表示される編集フィールドにハードウェアアドレスを入力します。以下と同じような画面が選択したノードの詳細情報とともに表示されます:

Node Detail

NeDiのノードステータスのページはテーブルを表示します。それぞれのテーブルは選択したノードの異なる情報を含んでいます。このデータはほとんど構成デバイスから収集されたものですが、いくつかの部分はノード自身から収集しています。表示されるテーブルは以下のとおりです:

前述した様に、このデータは検出された構成デバイスに対しても利用が可能です。つまり、スイッチとルー他の情報を表示するためにノードの詳細ページを使用することも可能です。

GroundWork MonitorとNeDiのデータの統合

GroundWork NMSのNeDiパッケージは、管理者がホスト定義のデータをNediの外にエクスポート、それをGroundWork MonitorのConfigurationデータベースにインポートすることが可能な、スクリプトと自動化スキーマを提供します。このプロセスは管理者の好みで手動、あるいは自動で実行することが可能です。

NeDiからホスト定義をエクスポートする

管理者はNeDiからデータをエクスポートする2つのオプションがあります。ひとつは特定のテーブルから全てのデータを持つテキストファイルを手動で作成するためにNeDiの”Export”Webページを使うことです。この方法を使用する場合、画面上の”Other”にマウスを移動し、”Export”をクリックします。ツールの詳しい使用方法については、画面右上にある救命具のアイコンをクリックします。

2つ目のエクスポート方法は(こちらを推奨します)
/usr/local/groundwork/nms/tools/automation/scripts/extract_nedi.pl を使用することです。GroundWork Monitor NMSのNeDiパッケージに含まれるPerlスクリプトは、NeDiのデバイスやノードテーブルからデータをエクスポートして /usr/local/groundwork/core/monarch/automation/data/nedi_data.txt テキストファイルにアウトプットを入力します。このスクリプトは以下のフィールドでファイルを生成し、それぞれのフィールドは一組のセミコロンによって分けられています(いくつかのフィールドはどのNeDiのテーブルが現在の行を定着させているかに基づき、複数の意味を重複しています。):

フィールド名

フィールドデータ

備考

Name

デバイス あるいはノード名

 構成デバイスあるいはノードの親密性のある名前

IP

デバイスあるいはデバイスのIPアドレス

 構成デバイスやノードに関連するプライマリIPアドレス

Description

デバイスの詳細

構成デバイスに関する記述

OS/OUI

デバイスの OS あるいはノードのOUI

構成デバイス上で使用しているOS、あるいはノードのハードウェアアドレスと関連しているベンダー名

Location

デバイスの位置

構成デバイスのSNMPのロケーション

Type

デバイスのタイプ

構成デバイスのモデル名

Contact

デバイスのコンタクト

構成デバイスのSNMPコンタクトストリング

Device

ノードの親デバイス

現在のノードに対する親機

Nedi.pl 検出スクリプトが実行された後(初期設定では4時間おき)9すぐにユーザ nagioscrontabの一部としてextract_nedi.pl Perlスクリプトは自動的に実行されます。それはアウトプットファイルが常に最新の検出データを含んでいることを確実にします。

ホスト定義をGroundWork Monitorへインポートする

GroundWork NMSのNeDiパッケージは、nedi_data.txt テキストファイルをGroundWork Monitorのコンフィグレーションにインポートするために、2つの異なるモデルを提供します。それぞれがGroundWork Monitorの自動検出サブシステムのスキーマテンプレートとして定義されています。

最初のモデルは、/usr/local/groundwork/core/monarch/automation/templates/schema-template-NeDi-host-import.xml スキーマテンプレートで定義されており、該当のデバイスやノードに対するホストエントリがコンフィグレーションデータベースに存在するかどうかにより新しいホストエントリを作成するか、既存のものを修正するかのどちらかによってNeDiのデバイスとノードをコンフィグレーションサブシステムに統合します。このスキーマテンプレートを使用したい場合は以下の手順を使用して適切なスキーマを作成する必要があります:

  1. GroundWork Monitorから自動検出アプリケーションを開います。

  2. トップのメニューバーから自動化スキーマ定義を管理する自動化をクリックします。

  3. 新しいスキーマ定義を作成するためにNew Schemaボタンを押下します。

  4. 新しいスキーマ定義に"NeDi-host-import"という名前をつけます。

  5. 下部のドロップダウンから"NeDi-host-import" テンプレートを選択します。

  6. 新しいスキーマ定義の作成を終了するために"Add" ボタンをクリックします。

  7. スキーマの編集画面から、"Data source"の行にある"View"ボタンをクリックしてデータファイルがNeDiのデータベーステーブルからのアウトプットを含んでいるかどうかを確認し、終了の際はポップアップウインドウをクローズします。

  8. レコードを処理したい場合は、スキーマ編集画面の上にある"Process Records"ボタンをクリックします。それ以外はスキーマ定義ウインドウに戻るために"Close"ボタンをクリックします。

GroundWork NMS NeDiパッケージはインポートプロセスを自動化するために使用される/usr/local/groundwork/nms/tools/automation/scripts/auto_import_nedi_sync.plPerl スクリプトを提供します。このスクリプトは"NeDi-host-import"の名前でスキーマ定義のエントリを探し、自動的にスキーマ定義を実行します。しかし、このスクリプトは自動的に変更をコンフィグレーションデータベースにコミットしないので、変更は手動でコミットされるまでは認識されません。