証明書の作成と分配 - Hewlett Packard Enterprise

HP OpenView Operations
HTTPS エージェント
コンセプトと設定ガイド
ソフトウェアバージョン : A.08.10
HP-UX および Sun Solaris 管理サーバー
Manufacturing Part Number : B7491-99039
2004 年 10 月
© Copyright 2004 Hewlett-Packard Development Company, L.P.
ご注意
1. 本書に記載した内容は、予告なしに変更することがあります。
2. 当社は、本書に関して特定目的の市場性と適合性に対する保証を含む一切の保証をいたしか
ねます。
3. 当社は、本書の記載事項の誤り、またはマテリアルの提供、性能、使用により発生した 損害
については責任を負いかねますのでご了承ください。
4. 本製品パッケージとして提供した本書、CD-ROM などの媒体は本製品用だけにお使いくださ
い。プログラムをコピーする場合はバックアップ用だけにしてください。プログラムをその
ままの形で、あるいは変更を加えて第三者に販売することは固く禁じられています。
本書には著作権によって保護される内容が含まれています。本書の内容の一部または全部を著作
者の許諾なしに複製、改変、および翻訳することは、著作権法下での許可事項を除き、禁止され
ています。
All rights are reserved.
Restricted Rights Legend.
Use, duplication or disclosure by the U.S. Government is subject to restrictions as set forth in
subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause in
DFARS 252.227-7013.
Hewlett-Packard Company
United States of America
Rights for non-DOD U.S. Government Departments and Agencies are as set forth in FAR
52.227-19(c)(1,2).
Copyright Notices
©Copyright 2004 Hewlett-Packard Development Company, L.P., all rights reserved.
No part of this document may be copied, reproduced, or translated to another language
without the prior written consent of Hewlett-Packard Company. The information contained in
this material is subject to change without notice.
Trademark Notices.
Adobe® は、Adobe Systems Incorporated ( アドビ システムズ社 ) の商標です。
Microsoft®、Windows®、MS Windows® は、米国 Microsoft Corporation の米国およびその他
の国における登録商標または商標です。
2
UNIX® は、The Open Group の登録商標です。
その他一般に各会社名、各製品名は各社の商号、商標または登録商標です。
3
4
目次
1. OVO HTTPS エージェントの概要
はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HP OpenView Operations の HTTPS エージェントアーキテクチャ . . . . . . . . . . . . . .
OVO 8.1 でサポートされている HTTPS エージェントプラットフォーム . . . . . . . . . . . .
OVO サーバーのコンポーネントとプロセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVO 管理サーバーの新しいプロセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HTTPS エージェントと DCE エージェントの比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
設定情報の配布 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
分配マネージャ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
複数の並列設定サーバー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
リソース要件の比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
エージェントのパフォーマンス比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
エージェント用に使うコマンドの比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
エージェントプロセスの比較. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
トラブルシューティングの比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVO 管理対象ノードの一般的なディレクトリ構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVO の HTTPS 通信管理コマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
29
30
31
31
33
33
34
34
34
35
35
36
37
38
39
2. HTTPS 通信の概念
OVO における HTTPS 通信 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
利点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ファイアウォールとの親和性. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
安全性. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
オープン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
スケーラブル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
45
45
46
47
48
3. セキュリティの概念
HTTPS ベースのセキュリティコンポーネント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
証明書. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HP OpenView 証明書サーバー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
認証局 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
証明書クライアント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ルート証明書の更新と分配. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
証明書サーバーが複数個ある環境. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 つの既存の MoM 環境の合併 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 番目の OVO 管理サーバーにおける証明書の取り扱い . . . . . . . . . . . . . . . . . . . . . . . .
MoM 環境での共有 CA の利用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
リモートアクションの許可 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
53
54
54
55
56
57
57
60
63
66
5
目次
リモートアクションを許可するためのサーバーの設定 . . . . . . . . . . . . . . . . . . . . . . . . .
代行ユーザーによるエージェントの実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVO エージェントを代行ユーザーで動作させる場合の制限 . . . . . . . . . . . . . . . . . . . .
代行ユーザーが実行するエージェントの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
システム環境の準備 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UNIX 管理対象ノード上の代行ユーザーを使ったエージェントのインストール . . .
代行ユーザーが実行するエージェントのための OVO 管理サーバーの設定 . . . . . . .
デフォルトポートの変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
エージェントプロファイル. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
代行ユーザーが実行するエージェントのアップグレードとパッチ . . . . . . . . . . . . . . . .
ノードにコピーした後、手作業でインストール . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UNIX エージェントでの sudo プログラムの使用方法. . . . . . . . . . . . . . . . . . . . . . . .
sudo プログラムのセットアップ方法. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DCE と HTTPS の代行ユーザーの概念の比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
71
72
73
73
74
76
77
78
80
80
81
82
83
4. HTTPS ノード管理の概念
HTTPS ノードの制御方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HTTPS ノードへの設定情報の配布 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ポリシー管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
インストルメンテーション管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
手作業によるポリシーとインストルメンテーションのインストール . . . . . . . . . . . . . .
HTTPS エージェント分配マネージャ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
設定のプッシュ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
差分分配 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
複数の並列設定サーバー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HTTPS ノードのハートビートポーリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ネットワークの負荷と CPU の負荷の軽減 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HTTPS ノードのリモート制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
89
90
90
91
92
93
94
94
96
96
98
5. HTTPS ノードでの作業
HTTPS ノードの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HTTPS ノードへの OVO ソフトウェアの自動インストール . . . . . . . . . . . . . . . . . . .
DCE エージェントから HTTPS エージェントへの移行 . . . . . . . . . . . . . . . . . . . . . . .
MoM 環境でのアップグレード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HTTPS エージェントの DCE エージェントへの移行. . . . . . . . . . . . . . . . . . . . . . . . .
手作業によるエージェントのインストール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
証明書をインストールするためのヒント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
エージェントをパッケージファイルから手作業でインストールする方法. . . . . . . .
6
100
101
110
112
114
116
116
117
目次
OVO に関連した変数の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
コピーイメージを使ったエージェントのインストール . . . . . . . . . . . . . . . . . . . . . . . .
ホスト名と IP アドレスの変更. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
手作業による管理対象ノードのホスト名または IP アドレスの変更 . . . . . . . . . . . .
管理対象ノードのホスト名または IP アドレスの自動的な変更. . . . . . . . . . . . . . . .
ノードの設定と名前解決の比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVO におけるプロキシ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
プロキシの構成. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
構文. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HTTP プロキシの背後で行う手作業のエージェントインストール . . . . . . . . . . . . .
管理対象ノードでのプロキシの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVO 管理サーバーでのプロキシの設定. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
エージェントの削除 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
エージェントの自動削除 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
手作業によるエージェントの削除 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
削除エラー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVO の仮想ノード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
仮想ノードの概念. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVO への仮想ノードの追加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
opcnode(1m) を使った仮想ノードの設定. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVO での仮想ノードの変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVO からの仮想ノードの削除. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVO の仮想ノードへのポリシーの割当て. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVO の仮想ノードからのポリシーの削除. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVO での仮想ノードへのポリシーの配布. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVO での仮想ノードに関するポリシーの構成の変更. . . . . . . . . . . . . . . . . . . . . . . . .
DHCP クライアントシステム上での HTTPS エージェントの管理 . . . . . . . . . . . . . . . .
OVO での DHCP の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP 用の変数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP 用の opcnode 変数. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
dhcp_postproc.sh を使った NNM の同期 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP クライアントでエージェントの管理を有効にする . . . . . . . . . . . . . . . . . . . .
証明書の作成と分配 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
証明書の自動分配. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HTTPS 管理対象ノードに対する証明書の管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
手作業の分配に使う証明書を作成する方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
122
124
126
126
130
131
133
135
137
138
138
139
140
140
140
140
141
141
141
142
143
143
144
144
145
146
146
147
148
148
148
149
149
149
150
153
156
159
7
目次
インストールキーを使って証明書を手作業で分配する方法 . . . . . . . . . . . . . . . . . . . .
複数の並列設定サーバー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
複数の設定サーバーのセットアップ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVO 7 と OVO 8 の相違と下位互換性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
163
164
166
173
A. HTTPS ベース通信のトラブルシューティング
トラブルシューティング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ツールを使ったトラブルシューティング. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HTTPS ベースのアプリケーションに対する ping の実行 . . . . . . . . . . . . . . . . . . . .
HTTPS ベースアプリケーションの現在のステータスの表示 . . . . . . . . . . . . . . . . .
通信ブローカに登録されているすべてのアプリケーションの表示 . . . . . . . . . . . . .
what 文字列 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HTTPS ノードにインストールされている全 OV ファイルセットの一覧表示. . . . .
標準の TCP/IP ツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
時間のかかる RPC コール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ロギング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
管理サーバーと HTTPS エージェントとの間で発生する通信の問題 . . . . . . . . . . . . .
基本ネットワークのトラブルシューティング . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
基本 HTTP 通信のトラブルシューティング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HTTP 通信における認証と証明書のトラブルシューティング . . . . . . . . . . . . . . . .
OVO 通信のトラブルシューティング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
証明書分配中に発生する問題. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVO 管理サーバー上の無効な OvCoreId . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OVO での証明書のバックアップと復元方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
証明書のバックアップを作成 / 使用する時期. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
176
176
176
177
177
178
178
180
180
181
183
183
185
192
197
201
202
205
206
B. HTTPS ベース通信の設定方法
通信の設定パラメータ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
HTTPS 通信の設定ファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
C. HTTPS 通信のアーキテクチャ
通信ブローカのアーキテクチャ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
D. ファイアウォールと HTTPS 通信
ファイアウォールの仕組み . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
イントラネットからインターネット上のアプリケーションへアクセスする － HTTP プ
ロキシを使う方法. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
イントラネットからインターネット上のアプリケーションへアクセスする － HTTP プ
8
目次
ロキシを使わない方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
インターネット上の OpenView アプリケーションからプライベートなイントラネット内
のアプリケーションへアクセスする . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
インターネット上の OpenView アプリケーションからプライベートなイントラネット内
のアプリケーションへアクセスする － HTTP プロキシを使わない方法 . . . . . . . . . . 225
E. OVO 8.1 クイックスタートガイド
OVO 7.x ユーザーのための OVO 8.1 クイックスタートガイド . . . . . . . . . . . . . . . . . . 228
索引 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
9
目次
10
原典
本書は『HP OpenView Operations HTTPS Agent Concepts and Configuration Guide』(HP
Part No. B7491-90044) を翻訳したものです。
注記
OS の種類によって OVO/Unix 8.1 英語版と日本語版でサポートされているエー
ジェントソフトウェアが異なります。詳細は OVO/Unix 8.1 Release Notes 日本
語版をご覧ください。
11
12
表記法
字体
『マニュアル』
説明
例
マニュアル名
詳細は、
『OVO システム管理リファレ
ンスガイド』を参照してください。
コマンドの入力時に指定する必要があ
る変数
プロンプトで、次のように入力しま
す。
rlogin your_name
このとき、your_name にはログイン
名を指定します。
関数のパラメータ
oper_name パラメータは整数が返さ
れます。
Bold、ゴシック体
用語
HTTPS エージェントは ... を監視し
ます。
入力
ユーザーが入力する必要があるテキス
ト
プロンプトで、次のように入力しま
す。ls -l
コンピュータ文字
コンピュータディスプレイの項目
次のシステムメッセージが表示さ
れます。
Italic
Are you sure you want to remove
current group?
強調
コマンド名
grep コマンドを使用して、...。
関数名
opc_connect() 関数を使用して、...
を接続します。
ファイル名とディレクトリ名
/opt/OV/bin/OpC/
プロセス名
opcmona が実行中かどうかチェック
します。
ウィンドウ / ダイアログボックス名
[ ログファイルの追加 ] ウィンドウで
...。
マンページ名やリファレンスページ名
詳細は、opc(1M) のマンページを参
照してください。
強調表示
次の手順に従う必要があります。
13
字体
説明
例
キーキャップ
キーボードキー
Return を押します。
[ ボタン ]
ユーザーインタフェースのボタン
[OK] をクリックします。
[ 適用 ] ボタンをクリックします。
[ メニュー項目 ]
メニュー名の後にコロン (:) が記載さ
れていることがあります。これは、
ユーザーがそのメニューを選択した
後、メニュー項目を選択することを示
しています。項目の後に矢印 (->) が記
載されている場合、カスケードメ
ニューが表示されます。
[ アクション : ユーティリティ -> レ
ポート ] を選択します。
14
OVO ドキュメントの使用方法
HP OpenView Operations (OVO) では、その使い方と概念を理解するために、マニュアルとオ
ンラインヘルプを用意しています。本項では、入手できる情報や情報の参照個所を説明します。
電子メディアのマニュアル
すべてのマニュアルは、OVO 製品 CD-ROM のドキュメント ディレクトリに Adobe Portable
Document Format (PDF) の形式で入っています。
『OVO ソフトウェアリリースノート』を除いて、他のマニュアルのすべてが次の OVO Web ペー
ジから入手できます。
http://<management_server>:3443/ITO_DOC/<lang>/manuals/*.pdf
この URL 内の <management_server> の部分は、使用している管理サーバーのホスト名の
FQDN ( 完全修飾ドメイン名 ) で、<lang> はシステムの言語 ( たとえば、英語環境の場合は C、
日本語環境の場合は japanese) です。
次の Web サイトからもマニュアルをダウンロードすることができます。
http://ovweb.external.hp.com/lpe/doc_serv ( 英語 )
http://www.jpn.hp.com/doc/manual/openview/index.html ( 日本語 )
この Web サイトにある『OVO Software Release Notes』(OVO ソフトウェアリリースノート ) の
最新版を定期的に調べてください。このリリースノートは 2 ～ 3ヶ月ごとにアップデートされ、
サポート対象として追加された OS バージョンや最新のパッチなど、最新の情報が得られます。
15
OVO のマニュアル
本項では、OVO のマニュアルとその内容について簡単に述べます。
マニュアル
説明
メディア
OVO 管理サーバー インス
管理サーバーに OVO ソフトウェアをインストールし、初
期設定を行う管理者向けのマニュアルです。
印刷製本
トールガイド
PDF
次の事項を説明しています。
OVO コンセプトガイド
•
ソフトウェア、ハードウェアの必要条件
•
ソフトウェアのインストール、削除手順
•
デフォルト値を用いた設定
OVO を理解するために使用者を 2 つのタイプに分けて説
明しています。
印刷製本
PDF
オペレータの場合には OVO の基本構造を理解できます。
管理者の場合には、現在の環境で OVO のセットアップと
設定ができるようになります。
OVO システム管理リファレ
ンスガイド
OVO を管理対象ノードにインストールし、OVO の管理と
トラブルシューティングを行う管理者向けのマニュアルで
す。
PDF のみ
OVO の DCE/NCS ベース管理対象ノードの一般的で概念
的な情報が記述されています。
OVO DCE エージェント コン
セプトと設定ガイド
DCE/NCS ベース管理対象ノードの各プラットフォームに
ついて、プラットフォーム固有の情報を提供しています。
PDF のみ
OVO HTTPS エージェント
コンセプトと設定ガイド
HTTPS ベース管理対象ノードの各プラットフォームにつ
いて、プラットフォーム固有の情報を提供しています。
PDF のみ
OVO Reporting and
Database Schema
OVO データベースから生成されるレポートの例に加え、
OVO のデータベースの表の詳細を説明しています。
PDF のみ
OVO Entity Relationship
Diagrams
表と OVO データベース間の関係の概要を説明していま
す。
PDF のみ
16
マニュアル
説明
メディア
OVO Java GUI オペレータガ
OVO の Java ベースのオペレータ GUI と Service
Navigator の詳細を説明しています。このマニュアルに
は、OVO オペレータ向けに、一般的な OVO および
Service Navigator の概念と作業についての詳細な情報を
説明しています。またリファレンス、およびトラブル
シューティングの情報もあります。
PDF のみ
HP OpenView Service Navigator のインストール、構成、
保守、トラブルシューティングを担当する管理者向けの情
報を提供しています。サービス管理の背景にある概念の概
要も記述しています。
印刷製本
新機能と以下のような有用な情報を記述しています。
PDF のみ
イド
Service Navigator コンセプ
トと設定ガイド
OVO ソフトウェアリリース
ノート
•
ソフトウェアの新旧バージョンの機能比較
•
システムとソフトウェアの互換性
•
既知の問題の解決法
PDF
HP OpenView ネットワーク
ノードマネージャ ネット
ワーク管理ガイド
管理者とオペレータ向けのマニュアルです。
印刷製本
OVO に組み込まれている HP OpenView ネットワーク
ノードマネージャの基本機能を説明しています。
PDF
OVO Database Tuning
このマニュアルは OVO 管理サーバーの次の場所にありま
す。
テキスト
/opt/OV/ReleaseNotes/opc_db.tuning
17
OVO 関連製品のマニュアル
ここでは、OVO 関連のマニュアルと内容の概要を説明します。
マニュアル
説明
メディア
HP OpenView Operations for UNIX Developer's Toolkit
HP OpenView Operations for UNIX Developer's Toolkit を購入すると、次のマニュアルと OVO の全ド
キュメント一式がついてきます。
OVO Application Integration
Guide
外部のアプリケーションを OVO に統合するいくつかの方
法を説明しています。
印刷製本
OVO Developer's Reference
利用できるアプリケーション プログラミング インタ
フェース (API) のすべての概要を記述しています。
印刷製本
PDF
PDF
HP OpenView Event Correlation Designer for NNM and OVO
HP OpenView Event Correlation Designer for NNM and OVO を購入すると次の追加のドキュメントが
ついてきます。HP OpenView Event Correlation Composer は、NNM と OVO の主要なコンポーネン
トです。OVO での OV Composer の使用方法は、OS-SPI のドキュメントで説明されています。
HP OpenView ECS
Configuring Circuits for
NNM and OVO
18
NNM と OVO 環境内での ECS Designer 製品の使用法を
説明しています。
印刷製本
PDF
OVO オンライン情報
次の情報がオンラインで利用できます。
オンライン情報
説明
HP OpenView Operations オ
ンラインヘルプ ( 管理者の作
業)
状況依存ヘルプシステムには、管理作業に必要な手順と、OVO 管理者
用の Motif GUI のウィンドウごとの詳細なヘルプが含まれています。
HP OpenView Operations オ
ンラインヘルプ ( オペレータ
の作業 )
状況依存ヘルプシステムにはオペレータ作業に必要な手順と、OVO オ
ペレータ用の Motif GUI のウィンドウごとの詳細なヘルプが含まれて
います。
OVO Java ベース GUI オン
ラインヘルプ
OVO の Java ベースのオペレータ GUI と Service Navigator の HTML
ベースのヘルプシステムです。このヘルプシステムには、OVO オペ
レータ向けに、一般的な OVO および Service Navigator の概念と作業
についての詳細な情報を説明しています。またリファレンス、およびト
ラブルシューティングの情報もあります。
HP OpenView Operations マ
ンページ
オンラインで利用できる OVO のマンページです。HTML 形式のものも
利用できます。
このページにアクセスするには、次の URL を Web ブラウザで開いて
ください。
http://<management_server>:3443/ITO_MAN
この URL の <management_server> には、使用している管理サーバー
の FQDN ( 完全修飾ドメイン名 ) を入力してください。OVO HTTPS
エージェント用のマンページは、各管理対象ノードにインストールされ
ています。
19
20
OVO オンラインヘルプについて
ここでは、HP OpenView Operations (OVO) でオペレータが使う Motif および Java のグラ
フィックユーザーインタフェース (GUI) について、そのオンラインドキュメンテーションを説明
します。
Motif GUI オンラインヘルプ
HP OpenView Operations (OVO) Motif グラフィックユーザーインタフェース (GUI) のオンライ
ン情報は、2 つの別々のボリューム ( オペレータ用と管理者用 ) から成ります。オペレータ用ボ
リュームには、オペレータ用の主なウィンドウについて説明した、HP OpenView OVO クイッ
クスタートがあります。
オンラインヘルプのタイプ
オペレータ用と管理者用ボリュームには、以下のようなオンラインヘルプのタイプがあります。
❏
タスクインフォメーション
作業の実行に必要な情報 ( オペレータまたは管理者用 )
❏
アイコンインフォメーション
ポップアップメニュー、OVO アイコンの説明 ( マウスポインターを対象とするものの上に移
動させて、マウスの右ボタンを押す )
❏
エラーインフォメーション
[OVO エラー情報 ] ウィンドウに表示されるエラーの説明。エラー発生時に、またはメッセー
ジ番号を使ってヘルプシステム内でキーワード検索で、ヘルプを参照できます。
❏
検索ユーティリティ
目的のトピックを直接表示 ( 索引検索ユーティリティ )
❏
用語集
OVO の用語集
❏
ヘルプ指示
オンラインヘルプを初めて使うユーザーのためのヘルプ
❏
印刷機能
21
ヘルプシステム内の一部またはすべてのトピックを印刷するための印刷機能 ( 図形を印刷す
るには、HP LaserJet プリンター、またはそれと互換性のあるプリンターデバイスが必要 )
オンラインヘルプにアクセスするには
ヘルプシステムにアクセスするには、次の方法があります。
❏
F1 キー
カーソルがアクティブなテキストフィールドまたはボタン上にあるときに、F1 キーを押す。
❏
ヘルプボタン
ウィンドウ下部の [ ヘルプ ] ボタンをクリックする。
❏
ヘルプメニュー
メニューバーから [ ヘルプ ] メニューを選択する。
❏
右クリック
シンボルをクリックして、マウスの右ボタンを押し、[ ヘルプ ] メニューにアクセスする。
次に、タスク項目リスト、またはウィンドウとフィールドのリストを選択します。どのヘルプ画
面からでも、ヘルプボリューム内のすべてのトピックにアクセスできます。他のヘルプトピック
をハイパーリンクで示しています。
[ メッセージブラウザ ] ウィンドウと、[ メッセージソースのテンプレート ] ウィンドウではコンテ
キストヘルプを表示できます。メニューバーから [ ヘルプ : コンテキストについて ] を選択する
と、カーソルが疑問符に変わるので、ヘルプを表示させたい箇所にカーソルを移動させます。そ
こでマウスボタンをクリックすると、その箇所のヘルプの説明がヘルプウィンドウに表示されま
す。
Java GUI と Service Navigator のオンラインヘルプ
Service Navigator を含む、HP OpenView Operations (OVO) Java グラフィックユーザーイン
タフェース (GUI) のオンラインヘルプは、オペレータが OVO 製品に慣れ親しむのや、使用する
のに役立ちます。
オンラインヘルプのタイプ
OVO Java GUI のオンラインヘルプには、次のような情報があります。
❏
タスク
手順ごとの説明
22
❏
概念
主要な概念と機能の紹介
❏
リファレンス
製品についての詳細な情報
❏
トラブルシューティング
製品の使用中に発生する共通の問題に対する解決策
❏
索引
必要な情報にすぐに簡単にアクセスできるトピックリスト
トピックの表示
トピックを表示するには、オンラインドキュメンテーションウィンドウの左側にあるフレームの
フォルダーを開き、トピックタイトルをクリックします。ハイパーリンクで、関連するヘルプト
ピックにアクセスできます。
オンラインヘルプにアクセスするには
ヘルプシステムにアクセスするには、Java GUI のメニューバーから [ ヘルプ : 目次 ] を選択し
ます。Web ブラウザが開き、ヘルプの目次が表示されます。
注記
ご使用の Web ブラウザを使って、Java GUI のオンラインヘルプにアクセスする
には、OVO の設定が必要です。詳細は『OVO 管理サーバーインストールガイド』
を参照してください。
23
24
1 OVO HTTPS エージェントの概要
第1章
25
OVO HTTPS エージェントの概要
はじめに
はじめに
OVO 8.1 から、新しい HTTPS エージェントソフトウェアが提供されるようになりました。この
ソフトウェアは、OVO 管理サーバーとその管理対象ノードとの間で安全性の高い通信を実現す
るためのものです。HTTPS エージェントは、通常、DCE ベースエージェントと同じように使
い、管理します。アプリケーションの起動方法は同じで、opcragt のようなコマンド行インタ
フェースも、すべての管理対象ノードに対して使うことができます。DCE ベースエージェント
で利用できるすべての機能は、明確に利用できないことが記述されていない限り HTTPS エー
ジェントでも利用できます。
DCE ベースエージェントの場合のテンプレートと同じように、HTTPS エージェントでもポリ
シーを作成し、割り当て、配布します。たとえば、ノードに対してハートビートのポーリングを
実行すると、似たタイプのメッセージが生成され、メッセージブラウザに同じような形式で表示
されます。図 1-1 に、HP OpenView Operations で管理する標準的な環境を示します。
しかしながら、HTTPS エージェントには DCE ベースエージェントよりも多くの利点がありま
す。これらの利点について、以下の章で説明していきます。
図 1-1
26
OVO の標準的な管理環境
第1章
OVO HTTPS エージェントの概要
はじめに
HTTPS ベースの通信を利用することで得られる主な利点は、次のとおりです。
•
管理対象ノードの多くのオペレーティングシステムに必要であった DCE-RPC テクノロジが
不要になります。
•
HTTPS ベースのオープンな通信技術を使った、設定可能な単一ポートによる安全な通信に
より、ファイアウォール越しの管理が簡単にできます。外部にアクセスできるポートを専用
の HTTP プロキシだけに限定し、その HTTP プロキシ上で通信を多重化することで、使用
するポートの数を減らすことができます。
•
認証用のサーバー証明書およびクライアント証明書と SSL/PKI 暗号化とを組み合わせること
により、安全で優れたインターネット通信を実現することができます。
•
現在、すべての環境で使用可能な標準の Web 技術 (HTTP、SOAP、プロキシ、SSL など ) が
通信に使われているので、すべての IT 管理者が簡単に理解することができます。
•
追加投資が不要です ( トレーニングや、DCE などの追加ソフトウェア )。
OVO 8.1 では、この他に次の長所があります。
•
OVO 管理サーバーでは、HTTPS 管理対象ノードシステムと OVO 7.x DCE 管理対象ノードシ
ステムを同時に管理できます。
•
HTTPS エージェントから OVO サーバーに送るメッセージ セキュリティに XML と SOAP を
ベースにした新しい OVO メッセージフォーマットを使用します。
•
IP からの独立性と動的 IP(DHCP)。管理対象ノードを一意の OvCoreID で識別できるので、IP
アドレスによる識別が必須ではありません。
•
HTTPS と DCE エージェントの両方で、IP を重複して使うことができるようになります。
•
OpenView での一貫性のある、制御方法と配布方法に関する新しい機構。
•
OpenView での一貫性のある新しいロギング機能。
•
OpenView での一貫性のある新しいトレース機能。
第1章
27
OVO HTTPS エージェントの概要
はじめに
図 1-2 に、OVO で処理可能な通信の例をいくつか示します。
図 1-2
28
HP OpenView Operations における通信の概要
第1章
OVO HTTPS エージェントの概要
はじめに
HP OpenView Operations の HTTPS エージェントアーキテクチャ
次の図に、OVO における HTTPS 通信のアーキテクチャを示します。
図 1-3
第1章
HTTPS エージェントのコンポーネントと役割
29
OVO HTTPS エージェントの概要
OVO 8.1 でサポートされている HTTPS エージェントプラットフォーム
OVO 8.1 でサポートされている HTTPS エージェントプラット
フォーム1
•
HP-UX 11.0、11.11、11.23
•
Solaris 7、8、9
•
Windows 2000、XP、2003
•
RedHat EL 2.1、EL 3.0、8.0、9.0
•
SuSE 8.0、8.1、8.2
•
Debian: 3.0
•
Turbolinux: 8.0
•
Tru64 5.1A、5.1B
•
AIX 5.1、5.2
1. サポートされている管理対象ノードのプラットフォームについては、『OVO リリース
ノート』の最新版に記載されている最新のリストを参照してください。リリースノー
トは、http://ovweb.external.hp.com/lpe/doc_serv/ の「operations for UNIX,
version 8.x」から入手できます (PDF 形式 )。この Web ページで管理サーバーのオペ
レーティングシステムを選択すれば、関連ドキュメントのリストがすべて表示されま
す。
30
第1章
OVO HTTPS エージェントの概要
OVO サーバーのコンポーネントとプロセス
OVO サーバーのコンポーネントとプロセス
OVO サーバーでは、次のコンポーネントが、RPC クライアントとして HTTPS エージェントと
通信します。
•
ovoareqsdr － アクションリクエストの送信とハートビートポーリングを実行します。
•
opcragt － リモート制御の実行と一次マネージャの切替えを実行します。
•
opcbbcdist － HTTPS ノードへの設定情報の配布を実行します。リモートエージェントを
インストールするときは、この配布機能が使われます。
また、次のコンポーネントが、RPC サーバーとして HTTPS ベースの通信を行います。
•
ovbbccb ( 通信ブローカ )
•
opcmsgrb (HTTPS エージェント用のメッセージレシーバ )
•
ovcs ( セキュリティ証明書サーバー )
OVO 管理サーバーの新しいプロセス
OVO 管理サーバーにはいくつかの新しいプロセスが導入されました。opcsv -status コマンド
を実行すると、Oracle と NNM のプロセスを除く OVO 関連のすべてのプロセスが表示されま
す。このコマンドによって表示される新しいプロセスは、以下のとおりです。
•
opcbbcdist － HTTPS ノードへ設定情報を配布します。DCE ノードの opcdistm に類似し
ています。両方のプロセスとも opcctlm によって制御されます。
•
opcmsgrb － HTTPS ノード用のメッセージレシーバです。DCE ノードの opcmsgrd に類似
しています。両方のプロセスとも ovoareqsdr によって制御されます。
•
ovcd － 制御デーモンです。自律的に動作します。
•
ovbbccb － 通信ブローカです。ovcd によって制御されます。
•
ovdepl － 設定と配布を実行するプロセスです。ovcd によって制御されます。
•
ovcs － 証明書リクエストを処理するためのサーバー拡張機能です。ovcd によって制御され
ます。
•
opccsad － OVO 証明書サーバーアダプタです。opcct(lm) によって制御されます。
•
TraceServer － OVO のトレースサーバーです。
第1章
31
OVO HTTPS エージェントの概要
OVO サーバーのコンポーネントとプロセス
ovstop ovoacomm を呼び出しても、OpenView のコアプロセスを停止することはできません。
ovcs サーバー拡張機能も同様です。OpenView のすべてのコアプロセスを停止するには、次の
コマンドを実行する必要があります。
ovstop ovctrl
OpenView のすべてのコアプロセスを終了させるには、次のコマンドを実行します。
ovc -kill
このコマンドを実行すると、管理サーバーノードの OVO エージェントも停止します。
32
第1章
OVO HTTPS エージェントの概要
HTTPS エージェントと DCE エージェントの比較
HTTPS エージェントと DCE エージェントの比較
設定情報の配布
HTTPS エージェントへ設定情報を配布する方法は、DCE ベースのノードの場合と少し違いま
す。その違いは、次のとおりです。
•
HTTPS エージェントではポリシーを使います。ポリシーは、DCE ベースエージェントで使
われていたテンプレートを改良し、置き換えるものです。
HTTPS エージェントのポリシーは OVO 管理サーバーがプッシュします。DCE エージェン
トのテンプレートは、OVO 分配エージェントがプルします。OVO の管理サーバーシステム
が高信頼性環境にある場合、ファイアウォールを通過するポリシーの配布は出力方向 ( ファ
イアウォールの内から外への方向 ) だけが可能です。
•
インストルメンテーションとは、HTTPS エージェントでアクション、コマンド、およびモ
ニターを総称して使う用語です。すべてのスクリプトとバイナリは、共通のインストルメン
テーション ディレクトリに格納されます。
•
HTTPS エージェントに対しては、nodeinfo ファイルと opcinfo ファイルに替わって、
HTTPS エージェント用の設定パラメータスキーマが使われます。このパラメータスキーマ
では、ポリシーのタイプが名前と値の対で定義されます。
•
HTTPS エージェント用の mgrconf ファイルは、役割モデルベースのセキュリティ認証メカニ
ズムを使って拡張されています。この拡張により、複数の OVO 管理サーバーからポリシー
とインストルメンテーションの配布ができるようになっています。
HTTPS エージェントの設定管理の詳細は、89 ページの「HTTPS ノードへの設定情報の配布」
を参照してください。
第1章
33
OVO HTTPS エージェントの概要
HTTPS エージェントと DCE エージェントの比較
分配マネージャ
opcbbcdist は、OVO 管理サーバーと HTTPS エージェントの間を結ぶ設定管理アダプタです。
その主な機能は、次のとおりです。
•
既存のテンプレートをポリシーに変換する
•
ECS テンプレートとその関連サーキットをポリシーに変換する
•
ノードのプロパティを、HTTPS ノードで使えるフォーマットに変換する。この機能で DCE
ノードの nodeinfo ファイルが置き換えられます。
opcbbcdist は OVO 管理サーバーから出されるリクエストだけを受け付けます。OVO 管理サー
バーと DCE エージェントの間にある設定管理アダプタ opcdistm は、DCE 管理対象ノードの分
配エージェント (opcdista) から出されるリクエストを受け付けます。
複数の並列設定サーバー
HTTPS ノードでは、ポリシー所有者という概念を使うことで、複数の並列設定サーバーがサ
ポートされています。
リソース要件の比較
表 1-1 OVO エージェントに必要なリソース
説明
HTTPS エージェント
DCE エージェント
RAM
☺
☺
CPU
☺
☺
ディスク
注記
34
☺
HTTPS エージェントに必要な管理対象ノードのリソース効率は、インストール
されている新しい OpenView 製品の数が多いほど高くなります。新しい
OpenView 製品は OV の基本インフラストラクチャを共有するように設計されて
いるので、インストールして実行する必要のあるソフトウェアは、従来の手法で
設計されたソフトウェアに比べると、非常に少なくて済みます。
第1章
OVO HTTPS エージェントの概要
HTTPS エージェントと DCE エージェントの比較
エージェントのパフォーマンス比較
表 1-2 OVO エージェントのパフォーマンス比較
説明
OVO エージェントバイナリ
のインストール
ポリシーとインストルメン
テーションの配布
HTTPS エージェント
DCE エージェント
フル -
フル - ☺
パッチ - ☺
パッチ -
フル -
フル - ☺
差分 - ☺
差分 ☺
OVO メッセージのスルー
プット
エージェント用に使うコマンドの比較
表 1-3 OVO エージェント用に使うコマンドの比較
説明
HTTPS エージェント
OVO エージェントの起動、
停止、ステータス確認、およ
び制御
ovc
ポリシー / テンプレート管理
ovpolicy
DCE エージェント
opcagt
opcagt ( ラッパー )
opctemplate
opctemplate ( ラッパー )
ローカル設定
OVO サーバーからのリモー
トエージェント制御
第1章
ovconfget
nodeinfo ファイル
ovconfchg
opcinfo ファイル
設定パラメータスキーマ
( 名前と値のペアでポリ
シータイプを定義 )
設定ファイル
opcragt
opcragt
ovconfget/set
35
OVO HTTPS エージェントの概要
HTTPS エージェントと DCE エージェントの比較
エージェントプロセスの比較
表 1-4 OVO エージェントプロセスの比較
説明
HTTPS エージェント
DCE エージェント
OVO エージェントの起動、
停止、および制御
ovcd
opcctla
ポリシーとインストルメン
テーションの配布
ovconfd
opcdista
通信
ovbbccb
llbserver
HTTPS-RPC サーバーで、
設定可能なポートを 1 つ使
用。デフォルトは 383。
固定ポート 135 上で dced、
rpcd、または llbd を使用
ovcs 証明書サーバー
該当なし
セキュリティ
opccsad 証明書アダプタ
ovcd 証明書クライアント
HTTPS エージェント設定ア
ダプタ
36
opcbbcdist
該当なし
第1章
OVO HTTPS エージェントの概要
HTTPS エージェントと DCE エージェントの比較
表 1-4 OVO エージェントプロセスの比較 ( 続き )
説明
HTTPS エージェント
DCE エージェント
メッセージエージェント
opcmsga
opcmsga
モニターエージェント
opcmona
opcmona
組み込みパフォーマンスコン
ポーネント
coda
coda
ログファイルエンキャプス
レータ
opcle
opcle
メッセージインターセプタ
opcmsgi
opcmsgi
SNMP トラップインターセ
プタ
opctrapi
opctrapi
opcevti (Windows)
イベント相関処理
opceca
opceca
ECS 注釈サーバー
opcecaas
opcecaas
トラブルシューティングの比較
表 1-5 OVO エージェントのトラブルシューティングの比較
説明
トレース
HTTPS エージェント
ovtrcadm1
trcmon
ovtrcadm
ovtrccfg
TraceServer
DCE エージェント
opcagt -trace
トレース機能はさらに強力
になりました。ただし機能
が増えた分、操作が複雑に
なっています。
1. HTTPS エージェントのトレース機能の詳細は、この機能に焦点を当てた『HP
OpenView Operations - Tracing Concepts and User's Guide』を参照してくださ
い。
第1章
37
OVO HTTPS エージェントの概要
OVO 管理対象ノードの一般的なディレクトリ構造
OVO 管理対象ノードの一般的なディレクトリ構造
HTTPS エージェントに関連するファイルは、次の 4 つのディレクトリに置かれています。
•
<OVInstallDir>
HP-UX、Solaris、Linux
/opt/OV
Tru64
/usr/opt/OV
AIX
/usr/lpp/OV
Windows
<ProgramFilesDir>¥HP OpenView
これらのディレクトリにあるファイルは、製品メディアからインストールされます。どの
ファイルも静的で、その内容が変更されることはありません。実行可能プログラムがその例
です。これらのファイルは変更されることがないため、高いセキュリティが必要な環境で
は、<OVInstallDir> を「読み取り専用」としてマウントすることもできます。また、これ
らのファイルは製品メディアから再インストールできるので、バックアップをとる必要はあ
りません。
これ以外のファイルは操作中に変更されるので、定期的にバックアップをとる必要がありま
す。
•
<OVDataDir>
HP-UX、Solaris、Linux、AIX
/var/opt/OV
Tru64
/usr/var/opt/OV
Windows
<ProgramFiles>¥HP OpenView¥data
これらのディレクトリには、ローカルシステムだけで使われるデータファイルが格納されます。
38
第1章
OVO HTTPS エージェントの概要
OVO の HTTPS 通信管理コマンド
OVO の HTTPS 通信管理コマンド
HTTPS による通信は、次のコマンドを使って制御できます。
OVO 管理サーバーと管理対象ノードで使えるコマンド
•
ovcoreid (OpenView の一意なシステム ID)
ovcoreid は、ローカルノードで既存の OvCoreId 値を表示したり、新しい OvCoreId を作
成または設定したりするためのコマンドです。
このツールの使用方法は、ovcoreid(1) のマンページを参照してください。
•
ovc (OpenView のプロセス制御 )
ovc では、OpenView 制御サービス ovcd に登録されているすべてのコンポーネントについ
て、起動 / 停止、イベント通知、およびステータスレポートを制御することができます。対
象にできるコンポーネントは、サーバープロセス、エージェント ( たとえば、Performance
Agent や Discovery Agent)、イベントインターセプタ、あるいは、システムインテグレータ
によって加えられたアプリケーションなどです。
このツールの使用方法は、ovc(1) のマンページを参照してください。
•
bbcutil
bbcutil は、OV 通信ブローカを制御するためのコマンドです。
このツールの構文と使用方法は、bbcutil(1) のマンページを参照してください。
•
ovconfget
インストールされている OpenView コンポーネントには対応する設定ファイルがあり、そこ
に、1 つまたは複数の名前空間が定義されています。設定ファイルはシステム全体、または
指定した高可用性リソースグループに適用されます。名前空間は、あるコンポーネントに属
するひとまとまりの設定を表します。設定ファイルに定義されている設定はすべて、
settings.dat 設定データベースにその複製が作成されます。
ovconfget は、指定したそれぞれの名前空間について、指定した属性の値を返すとともに、
それを stdout に書き出します。引き数を指定しないで ovconfget を実行すると、すべての
名前空間のすべての属性が stdout に書き出されます。
このツールの使用方法は、ovconfget(1) のマンページを参照してください。
•
ovconfchg
第1章
39
OVO HTTPS エージェントの概要
OVO の HTTPS 通信管理コマンド
インストールされている OpenView コンポーネントには対応する設定ファイルがあり、そこ
に 1 つまたは複数の名前空間が定義されています。名前空間は、あるコンポーネントに属す
るひとまとまりの設定を表します。
ovconfchg を使うことで、システム全体に適用する設定ファイルの操作、指定した高可用性
リソースグループに適用する設定ファイルの操作、設定データベースの更新、および通知ス
クリプトの起動を行うことができます。
このツールの使用方法は、ovconfchg(1) のマンページを参照してください。
•
ovpolicy
ovpolicy は、ローカルなポリシーやテンプレートを管理するためのコマンドです。ポリ
シーやテンプレートは、ネットワーク、システム、サービス、およびプロセスの管理を自動
化するために、その仕様や規則などの情報をまとめたものです。ポリシーやテンプレートを
すべての管理対象システムに配布することで、ネットワーク全体にわたって一貫性のある管
理を自動的に行うことができます。ポリシーやテンプレートは、カテゴリに分類してまとめ
ることができます。各カテゴリに 1 つまたは複数のポリシーを含ませることができます。ま
た、どのカテゴリにも、名前と値のペアで表す属性を複数個定義できます。
ovpolicy を使うことで、ローカルなポリシーやテンプレートのインストール、削除、有効
化、無効化が行えます。このツールの使用方法は、ovpolicy(1) のマンページを参照してく
ださい。
40
第1章
OVO HTTPS エージェントの概要
OVO の HTTPS 通信管理コマンド
管理対象ノードで使えるコマンド
•
ovcert
ovcert は、HTTPS ノード上で証明書クライアントを通して証明書の管理を行うためのコマ
ンドです。実行可能な管理は、証明書サーバーに対する新しい証明書リクエストの発行、
ノード証明書の追加と秘密鍵のインポート、信頼できるルート証明書への証明書の追加、証
明書のステータスチェックなどです。
このツールの使用方法は、ovcert(1) のマンページを参照してください。
OVO 管理サーバーで使えるコマンド
•
opccsacm ( 証明書サーバーアダプタ制御マネージャ )
opccsacm は、HP OpenView サーバー上で新しいノード証明書とインストールキーを手作
業で発行するためのコマンドです。また、このコマンドで OVO のデータベースを変更し、
証明書の管理操作で発生した変更点を反映することもできます。
このツールの使用方法は、opccsacm(1m) のマンページを参照してください。
•
opccsa ( 証明書サーバーアダプタ )
opccsa コマンドでは、保留されている証明書リクエストのリスト表示、証明書リクエスト
と OVO データベース内のターゲットノードとのマッピング、および指定された証明書リク
エストの承諾 / 拒否 / 削除を行うことができます。
このツールの使用方法は、opccsa(1m) のマンページを参照してください。
第1章
41
OVO HTTPS エージェントの概要
OVO の HTTPS 通信管理コマンド
42
第1章
2 HTTPS 通信の概念
第2章
43
HTTPS 通信の概念
OVO における HTTPS 通信
OVO における HTTPS 通信
HTTPS 1.1 をベースにした通信は、HP OpenView 製品で使用されている最新の通信技術であ
り、これを使えば、アプリケーションが異機種システム間でデータ交換を行うことが可能になり
ます。
HTTPS 通信が使われている OpenView 製品では、OpenView 製品相互だけでなく、他の業界標
準の製品とも簡単に通信できます。また、ネットワーク上の既存ソフトウェアと通信できる新し
いソフトウェアが作り易くなるとともに、使用中のファイアウォールや HTTP プロキシとも容
易に統合できます。図 2-1 に HTTPS 通信の例を示します。
図 2-1
44
HP OpenView Operations における通信の概要
第2章
HTTPS 通信の概念
利点
利点
HTTPS 通信には、次の大きな利点があります。
•
ファイアウォールとの親和性
•
安全性
•
オープン
•
スケーラブル
ファイアウォールとの親和性
近年、ファイアウォールを使った通信を安全で信頼性が高くしかも管理の容易な方法で実現した
いと望む組織が、ますます増えつつあります。そうした組織のほとんどでは、HTTP、HTTP プ
ロキシ、ファイアウォールといった技術がすでに当たり前の技術として使われており、身近なも
のとなっています。また、その IT 環境も、すでに HTTP プロキシとファイアウォールを通して
通信できるように構築されています。ほとんどの IT インフラストラクチャですでにその一部と
なっている技術を利用すれば、新しいトレーニングを行わなくても、さらに効率的で効果の高い
実装と運用が可能となります。その結果、サポートや保守に必要なコストが減るとともに、少な
い努力で安全性の高い環境を構築することができます。
第2章
45
HTTPS 通信の概念
利点
図 2-2 に、ファイアウォールを越えて HTTPS 通信が行われる様子を示します。
図 2-2
ファイアウォール経由の通信で HTTPS を使用する方法
安全性
HP OpenView の HTTPS 通信は、ネットワーキングの信頼性を高める業界標準の TCP/IP プロ
トコルをベースにしています。HTTPS 通信では、データにアクセスできる人を認証によって検
証するとともに、暗号化を行って安全なデータ交換を実現しますが、そのために SSL (Secure
Socket Layer) プロトコルを使います。ビジネス環境では、インターネットやプライベートなイ
ントラネットを経由したトランザクションの送受信が以前よりもはるかに増加しており、セキュ
リティと認証が非常に重要な役割を果たすようになってきています。
HP OpenView の HTTPS 通信では、実績のある業界標準を使うことでこの目標を達成してお
り、HTTP プロトコルと、SSL を使った暗号化と認証によって、データの整合性とプライバシ
を保証しています。また、データは特に指定しなくてもデフォルトで圧縮されます。そのため、
非 SSL 接続であっても、データがクリアテキスト形式のまま送信されるということはありませ
ん。
さらに、次の特長もあります。
•
リモートから到着するメッセージとリクエストは、すべてそのノードの通信ブローカを経由
します。つまり通信ブローカがノードのただ一つの入口となります。
•
ファイアウォールを設定するときに、バインドポートの範囲を制限することができます。
46
第2章
HTTPS 通信の概念
利点
•
1 つまたは複数の標準 HTTP プロキシを設定することで、メッセージ、ファイル、またはオブ
ジェクトをリモートシステムへ送信する際にファイアウォールを経由させることができま
す。
図 2-3 に、ファイアウォール経由の通信を標準的な HTTP プロキシを使って行う方法を示しま
す。
図 2-3
ファイアウォール経由の通信を外部の HTTP プロキシを使って行う
方法
HTTPS 通信とプロキシを使えるようにするためには、次の作業が必要です。
•
HTTP プロキシサーバーの設定
•
SSL による暗号化の実装
•
サーバー証明書を使うサーバー側認証環境の準備
•
クライアント証明書を使うクライアント側認証環境の準備
HP OpenView でこれらの作業を行う方法は、この後の章で説明します。
オープン
HP OpenView の HTTPS 通信は、業界標準の HTTP 1.1 プロトコルと SSL ソケットをベースに
実現されています。HP OpenView が、HTTP、SSL、SOAP といった標準にこだわるのは、既
存の HTTP インフラストラクチャを最大限利用できるようにするためです。たとえば、HTTP
第2章
47
HTTPS 通信の概念
利点
メッセージのコンテンツフィルタリング (SSL や圧縮機能を使わない ) を使うことでも、ファイ
アウォールを確実に構築することができます。セキュリティは、複数の場所でセキュリティ層を
実装することにより最適のものが実現できます。そのような特別なセキュリティ層の追加に利用
できる強力なツールが、コンテンツフィルタリングです。
HTTP プロキシは、現在のネットワークで広く使われています。HTTP プロキシを使うことでプ
ライベート ネットワークとインターネットとの接続の安全性が高まります。HTTP の使用に
よって HP OpenView の利用可能な範囲が広まり、既存のインフラストラクチャをさらに有効に
利用できるようになります
スケーラブル
HP OpenView の HTTPS 通信は、環境の規模や送受信するメッセージの数とは無関係に、適切
に機能するように設計されています。また、HP OpenView の HTTPS 通信は、動作環境に合わ
せて設定することができます。規模の大きいアプリケーションでは、最小限のリソースで多くの
接続を同時に処理できます。設定されている最大接続数を超過すると、ログファイルにその記述
が作成され、その情報をもとに警告メッセージが出力されます。
48
第2章
3 セキュリティの概念
第3章
49
セキュリティの概念
HTTPS ベースのセキュリティコンポーネント
HTTPS ベースのセキュリティコンポーネント
HP OpenView 管理サーバーとの間で通信する管理対象ノードには、HP OpenView 証明書サー
バーが発行する、業界標準の有効な X509 証明書が必要です。また、SSL (Secure Socket Layer)
プロトコルを使って管理する環境内では、ノードを識別するために、1024 ビットの鍵で署名さ
れた証明書が必要です。2 つのノード間で「SSL ハンドシェーク」が成功するのは、入力側ノー
ドの提示した証明書の発行局が、受信ノード側で信頼のおける発行局であると証明された場合に
限ります。証明書の作成と管理を担当する主要な通信セキュリティコンポーネントは、次のとお
りです。
•
HP OpenView 証明書サーバー
•
HP OpenView キーストア
•
HP OpenView 証明書クライアント
図 3-1 にこれらのコンポーネントを示します。
図 3-1
認証に関係する通信コンポーネント
HTTPS エージェントを置く各システムでは、そのシステムに HP OpenView ソフトウェアをイ
ンストールするときに一意な ID が作成され、パラメータ OvCoreId に割り当てられます。
50
第3章
セキュリティの概念
HTTPS ベースのセキュリティコンポーネント
注記
HTTPS 管理対象ノードに対して作成された OvCoreId は、DHCP などによって
システムのホスト名や IP アドレスが変更されても、変更されることはありませ
ん。
各 OpenView システム ( 管理対象ノードまたはサーバー ) の OvCoreId は、対応するノード証明
書に格納され、一意な ID として使われます。OvCoreId の値は、インストール中に割り当てら
れます。
図 3-2 に、認証された状態の通信環境を示します。
図 3-2
第3章
認証された状態の通信環境
51
セキュリティの概念
HTTPS ベースのセキュリティコンポーネント
1. サーバーシステムに証明書サーバーが置かれています。このシステムが認証局 (CA) の役割を
果たします。
2. 各システムに、証明書サーバーが認証局の秘密鍵を使って署名した証明書が置かれていま
す。
3. サーバーシステムにも、その身元を証明するための証明書が必要です。
4. 各システムに、信頼できるルート証明書のリストが置かれています。このリストには、少な
くとも 1 つのルート証明書が載っている必要があります。信頼できるルート (CA) 証明書は、
通信相手の ID を確認するために使います。つまり、通信相手から提示してきた証明書が、
信頼できる証明書のリストから確認できた場合に限って、その通信相手が信頼できる相手で
あると判定します。
証明書クライアントが複数の HP OpenView 管理サーバーから管理されている場合には、信
頼できるルート証明書のリストが必要です。たとえば、OVO HTTPS 管理対象ノードが複数
の OVO 管理サーバーから同時に管理されている場合などがこれに該当します。
52
第3章
セキュリティの概念
HTTPS ベースのセキュリティコンポーネント
証明書
証明書には次の 2 つの種類があります。
•
ルート証明書
•
ノード証明書
ルート証明書は自己署名のある証明書で、証明書サーバー内の認証局の身元を確認するための情
報が含まれています。ルート証明書に属する秘密鍵は証明書サーバーシステムで保管され、許可
のないアクセスから保護されています。認証局では、どの証明書の電子署名にもルート証明書を
使います。
管理されている環境では、すべての HTTPS ノードが、証明書サーバーの発行したノード証明書
と、それに対応してファイルシステムに格納された秘密鍵、およびその環境で有効なルート証明
書を受け取ります。この処理は、そのノードで動作している証明書クライアントが行います。
注記
ノード証明書には、一意な ID である OvCoreId が含まれています。OvCoreId の
例を、次に示します。
d498f286-aa97-4a31-b5c3-806e384fcf6e
各ノードは、ノード証明書を使うことで安全に認証できます。ノード証明書は同
じ環境内の他のすべてのノードでその信憑性を確認できる必要がありますが、そ
の確認は、ルート証明書を使った署名の確認で行います。
クライアントの認証とサーバーの認証を行う 2 つの HTTPS ノード間で SSL ベー
スの接続を確立する際は、このノード証明書を使います。SSL ベースの接続はす
べての通信を暗号化するように設定します。
証明書クライアントに用意されている ovcert ツールを使うことで、キーストアの内容をリスト
にして表示したり、インストールされている証明書に関する情報を表示したりできます。
ovcert ツールの説明は、ovcert のマンページを参照してください。
第3章
53
セキュリティの概念
HTTPS ベースのセキュリティコンポーネント
HP OpenView 証明書サーバー
証明書サーバーが担当する機能は、次のとおりです。
•
自己署名付きルート証明書の作成とインストール
•
ファイルシステムからの自己署名付きルート証明書のインポート
•
ルート証明書の秘密鍵の保管
•
証明書リクエストの承諾または拒否
•
新しい証明書とそれに対応する秘密鍵の作成、または、証明書を手作業でインストールする
ためのインストールキーの作成
•
信頼できるルート証明書をクライアントが自動検索できるようにするためのサービス
認証局
注記
すべての OVO 管理サーバーは、自動的に認証局として設定されます。各エー
ジェントに対する sec.cm.client:CERTIFICATE_SERVER のデフォルト設定は、
所属する OVO 管理サーバーです。
認証局は証明書サーバーを構成する要素のひとつで、証明書管理に必要な信用の核になっていま
す。この認証局の署名した証明書はすべて有効な証明書と見なされ、信頼のおける証明書として
扱われます。認証局は、機密性が非常に高くて安全な場所に置く必要があります。特に指定しな
い限り、認証局は、HP OpenView 管理サーバーの置かれているシステムにインストールされま
す。OVO 管理サーバーシステムはその一例です。
認証局は、信頼性の大本 ( ルート ) になっているので、自己署名付きルート証明書を使ってその
役割を果たします。認証局の動作に必要なルート証明書とそれに対応する秘密鍵は作成される
と、ある一定水準の保護を提供するファイルシステムに保管されます。認証局の初期化が正常に
終了した後は、承諾する証明書リクエストに対して、この認証局がルート証明書を使って署名す
ることになります。
54
第3章
セキュリティの概念
HTTPS ベースのセキュリティコンポーネント
証明書クライアント
証明書クライアントは管理対象ノードで動作し、証明書サーバー側の証明書リクエストハンド
ラーの相手方として、その役割を果たします。
証明書クライアントは、次のように動作します。
•
証明書クライアントは、そのノードに有効な証明書があるかどうかをチェックします。
•
そのノードに証明書がない場合は、ペアとなる新しい公開鍵と秘密鍵を生成し、そのノード
の一意な ID (OvCoreId の値 ) を使って証明書リクエストを作成します。証明書クライアン
トはこの証明書リクエストをその他のノードのプロパティと一緒に証明書サーバーへ送り、
そのレスポンスを待ちます。
ノードの DNS 名や IP アドレスといったその他のノードのプロパティは、証明書サーバー
で、証明書リクエストがどのシステムから発行されたかを調べたり、そのリクエストの承諾
可否を判断したりするための情報として使われます。
•
証明書クライアントは、新しい証明書を受け取ると、その証明書をノードにインストールし
ます。インストールが完了すると、証明書クライアントは、HTTPS ベースのすべての通信
にこの証明書を使います。
リクエストが正常に処理されなかった場合は、そのことを説明したエラー情報がログに格納
され、対応するステータスが設定されます。
証明書クライアントには、この他に次の機能があります。
•
証明書サーバーにアクセスして信頼できる最新のルート証明書を入手し、自分のところにあ
るルート証明書を更新する機能。この機能は、コマンド行ツール ovcert などを使って行う
ことができます。詳細は、ovcert のマンページを参照してください。
•
ファイルシステムからノード証明書とそれに対応する秘密鍵をインポートする機能。この機
能は、コマンド行インタフェース ovcert を使って行えます。詳細は、159 ページの「手作
業の分配に使う証明書を作成する方法」と 163 ページの「インストールキーを使って証明書
を手作業で分配する方法」を参照してください。非常に高い機密性が必要なシステムでは、
証明書を手作業でインストールすることもできます。
•
信頼できるルート証明書のインポート。
•
ステータス情報の表示。ステータスの値には、「OK、valid certificate ( 有効な証明書
)」
、「証明書がインストールされていません」、
「certificate requested ( 証明書リクエス
ト )」、および「証明書リクエストが拒絶されました」があります。
第3章
55
セキュリティの概念
HTTPS ベースのセキュリティコンポーネント
ルート証明書の更新と分配
1 つまたは複数のノードについて、信頼できるルート証明書を更新したい場合があります。この
ような状況は、たとえば、HP OpenView 証明書サーバーが複数個ある場合などに発生します。
このようなとき、現在の信頼できるルート証明書をすべて証明書クライアントに安全な方法で送
信することもできます。また通常は、認証局のルート証明書を送信するだけで十分です。しか
し、同じ環境内に認証局が複数ある場合などは、特定の証明書クライアントに 1 つまたは複数の
ルート証明書を分配して追加したいこともあります。
このような場合は、コマンド行ツール ovcert で証明書クライアントの「信頼できるルート証明
書の更新」機能を使います。詳細は、ovcert のマンページを参照してください。
56
第3章
セキュリティの概念
証明書サーバーが複数個ある環境
証明書サーバーが複数個ある環境
管理対象環境内に証明書サーバーが複数個存在することがあります。証明書サーバーがそれぞれ
動作している 2 つの既存の管理対象環境を統合して 1 つの環境にした場合、このような状況が発
生します。このような状況を合併と呼びます。
このような環境では、両方の証明書サーバーが、それぞれ自分の署名したルート証明書を使いま
す。そのため、一方の証明書サーバーにだけ属しているすべてのクライアントは、もう一方の証
明書サーバーにだけ属しているすべてのクライアントを信頼できません。この問題は、一方の証
明書サーバーのルート証明書をもう一方の証明書サーバーの信頼できるルート証明書へそれぞれ
追加することで解決できます。このようにした後、管理対象環境内のそれぞれのクライアントに
対して、自分の属する証明書サーバーから更新されたルート証明書のリストを受信するように指
示します。
注記
合併の際、1 方向にだけ信頼関係を設定することもできます。これは、多くの
ノードグループがそれぞれ自分たちの信頼する管理サーバーに管理されている状
況で非常に有効です。つまり、これらの管理サーバーの 1 つを上位管理サーバー
として使い、すべてのサブグループのすべてのノードを管理するようにすること
もできます。このようにすれば、上位管理サーバー以外の管理サーバーは上位管
理サーバーのノード群からは信頼されないので、それらのノード群は上位管理
サーバーでだけ管理できるようになります。
エージェントが複数の管理サーバーで管理されている場合には、何らかの証明書管理設定を行う
必要があります。デフォルトでは、各 OVO サーバーが独自の認証局を持ち、エージェントはこ
の認証局が承認する証明書だけを信頼します。MoM 環境の場合には、2 つ以上のマネージャ間
に信頼関係を確立し、それらの環境間で互いに通信できるようにする必要があります。
一般的な仕組みは、以下のものがあります。
•
2 つの既存の MoM 環境の合併
•
2 番目の OVO 管理サーバーにおける証明書の取り扱い
•
MoM 環境での共有 CA の利用
これらの仕組みについて、以降で詳細に説明します。
2 つの既存の MoM 環境の合併
エージェント AM1 を持つサーバー M1 に属する環境と、エージェント AM2 を持つサーバー M2
に属する環境があるとします。各サーバーには独自の認証局があるとします。
第3章
57
セキュリティの概念
証明書サーバーが複数個ある環境
以下の手順を実行して、2 つの環境を合併します。
注記
HA 環境および非 HA 環境とも同様な方法で処理します。次の手順は、両方の環
境でのインストールに使用できます。
1. 管理サーバーにある信頼できる証明書を同期化します。すなわち、M1 は M2 のルート証明書
を受け取り、M2 は M1 のルート証明書を受け取ります。
a. OVO 管理サーバー M1 で、以下のコマンドを実行します。
ovcert -exporttrusted -ovrg server -file <my_file>
b. <my_file> を、たとえば、ftp を使って、OVO 管理サーバー M2 へコピーします。
c.
M2 で以下のコマンドを実行します。
ovcert -importtrusted -ovrg server -file <my_file>
d. 以上の手順を管理サーバー M2 についても繰り返します。
e.
M1 と M2 が互いに他方のルート証明書を持っていることを確認するには、両方の管理
サーバーシステムで、以下のコマンドを実行します。
ovcert -list
2 つの信頼できる証明書が表示されます。
2. 他方の管理サーバーを、通常のノードとして OVO 登録ノードに設定します。M1 を M2 の登
録ノードにコア ID と共に追加する必要があります。さらに、M2 を M1 の登録ノードにコア
ID と共に追加する必要があります。
a. 次のようにして、ノード M1 を M2 の登録ノードに追加し、ノード M2 を M1 の登録ノー
ドに追加します。
管理者 GUI で次のように選択します。
[ アクション -> ノード -> 追加 ]
注記 : 次のようにコマンド行ツールを使うこともできます。
ノード M1 で、次のコマンドを入力します。
opcnode -add_node node_name=<M2> ¥
net_type=<network_type> mach_type=<machine_type> ¥
group_name=<node_group_name>
M2 で、次のコマンドを入力します。
58
第3章
セキュリティの概念
証明書サーバーが複数個ある環境
opcnode -add_node node_name=<M2> ¥
net_type=<network_type> mach_type=<machine_type> ¥
group_name=<node_group_name>
b. M1 の コア ID は、次のようにして M2 のデータベースに保存する必要があります。
M1 で ovcoreid コマンドを呼び出して、M1 のコア ID を表示します。
ovcoreid
表示された値をメモしてください。
M2 で opcnode コマンドを呼び出して、M2 のデータベースに M1 のコア ID を追加しま
す。
opcnode -chg_id node_name=<M1> id=<core_id_of_M1>
c.
M2 のコア ID は、次のようにして M1 のデータベースに保存する必要があります。
M2 で ovcoreid コマンドを呼び出して、M2 のコア ID を表示します。
ovcoreid
表示された値をメモしてください。
M1 で opcnode コマンドを呼び出して、M1 のデータベースに M2 のコア ID を追加しま
す。
opcnode -chg_id node_name=<M2> id=<core_id_of_M2>
次のコマンドを実行することによって、ノードがデータベースに正しく追加されたことを確
認できます。
a. M1 で次のコマンドを入力します。
opcnode -list_id node_list=<M2>
ノード M2 のコア ID が表示されます。
b. M2 で次のコマンドを入力します。
opcnode -list_id node_list=<M1>
ノード M1 のコア ID が表示されます。
注記
第3章
メッセージを表示するには、アップロードしたノードを ノードグループ に追
加する必要があります。
59
セキュリティの概念
証明書サーバーが複数個ある環境
3. opccfgupld と opccfgdwn を使って登録ノードを同期化します。M1 は M2 のエントリーを、
M2 は M1 のエントリーをそれぞれのコア ID と共に受け取ります。
4. [OVO 登録アプリケーション ] で、
[ 信用の更新 ] アプリケーションを使ってローカルのルート証
明書をアップデートします。
[ 証明書ツール -> 信用の更新 ]
各管理サーバーで、すべての必要な管理対象ノードを選択し、アプリケーションを実行しま
す。エージェントは証明書サーバーにアクセスして、新しいルート証明書を要求します。
アップデートされたことを確認するには、各管理対象ノードで次のコマンドを実行します。
ovcert -list
2 つの信頼できる証明書が表示されます。
注記
上記作業は、管理対象ノードで以下のコマンドを入力して、実行することも
できます。
ovcert -updatetrusted
注記
ここでの説明では、証明書サーバーは管理サーバーと同じサーバーに存在し
ます。
5. 両方のサーバーで担当マネージャのポリシーを作成または改版し、それぞれのエージェント
に配布します。
2 番目の OVO 管理サーバーにおける証明書の取り扱い
2 番目の OVO 管理サーバーが独自の認証局を持ち、バックアップ管理サーバーまたは専門技術
センターとして使われるものとします。サーバー M1 はエージェント AM1 を持ち、サーバー
M2 には最初はエージェントがないものとします。
1. 管理サーバーにある信頼できる証明書を同期化します。すなわち、M1 は M2 のルート証明書
を受け取り、M2 は M1 のルート証明書を受け取ります。
a. OVO 管理サーバー M1 で、以下のコマンドを実行します。
ovcert -exporttrusted -ovrg server -file <my_file>
b. <my_file> を、たとえば、ftp を使って、管理サーバー M2 へコピーします。
60
第3章
セキュリティの概念
証明書サーバーが複数個ある環境
c.
M2 で以下のコマンドを実行します。
ovcert -importtrusted -ovrg server -file <my_file>
d. 以上の手順を管理サーバー M2 についても繰り返します。
e.
M1 と M2 が互いに他方のルート証明書を持っていることを確認するには、両方の管理
サーバーシステムで、以下のコマンドを実行します。
ovcert -list
2 つの信頼できる証明書が表示されます。
2. 他方の管理サーバーを、通常のノードとして OVO 登録ノードに設定します。M1 を M2 の登
録ノードにコア ID と共に追加する必要があります。さらに、M2 を M1 の登録ノードにコア
ID と共に追加する必要があります。
a. 次のようにして、ノード M1 を M2 の登録ノードに追加し、ノード M2 を M1 の登録ノー
ドに追加します。
Motif の管理者 GUI で次のように選択してください。
[ アクション -> ノード -> 追加 ]
注記 : 次のようにコマンド行ツールを使うこともできます。
ノード M1 で、次のコマンドを入力します。
opcnode -add_node node_name=<M2> ¥
net_type=<network_type> mach_type=<machine_type> ¥
group_name=<node_group_name>
M2 で、次のコマンドを入力します。
opcnode -add_node node_name=<M2> ¥
net_type=<network_type> mach_type=<machine_type> ¥
group_name=<node_group_name>
b. M1 のコア ID は、次のようにして M2 のデータベースに保存する必要があります。
M1 で ovcoreid コマンドを呼び出して、M1 のコア ID を表示します。
ovcoreid
表示された値をメモしてください。
M2 で opcnode コマンドを呼び出して、M2 のデータベースに M1 のコア ID を追加しま
す。
opcnode -chg_id node_name=<M1> id=<core_id_of_M1>
第3章
61
セキュリティの概念
証明書サーバーが複数個ある環境
c.
M2 のコア ID は、次のようにして M1 のデータベースに保存する必要があります。
M2 で ovcoreid コマンドを呼び出して、M2 のコア ID を表示します。
ovcoreid
表示された値をメモしてください。
M1 で opcnode コマンドを呼び出して、M1 のデータベースに M2 のコア ID を追加しま
す。
opcnode -chg_id node_name=<M2> id=<core_id_of_M2>
次のコマンドを実行することによって、ノードがデータベースに正しく追加されたことを確
認できます。
a. M1 で次のコマンドを入力します。
opcnode -list_id node_list=<M2>
ノード M2 のコア ID が表示されます。
b. M2 で次のコマンドを入力します。
opcnode -list_id node_list=<M1>
ノード M1 のコア ID が表示されます。
注記
メッセージを表示するには、アップロードしたノードを ノードグループ に追
加する必要があります。
3. opccfgupld と opccfgdwn を使って登録ノードを同期化します。M2 は M1 のすべてのエー
ジェントから受信し、M1 は M2 のローカルエージェントを ( データベースに格納済みでは
なければ ) ロードします。
4. [ アプリケーションデスクトップ ] で、[ 信用の更新 ] アプリケーションを使って、M1 のルート証
明書をアップデートします。
[ 証明書ツール -> 信用の更新 ]
M1 で AM1 を選択し、アプリケーションを実行します。エージェントは証明書サーバーに
アクセスして、新しいルート証明書を要求します。
62
第3章
セキュリティの概念
証明書サーバーが複数個ある環境
注記
上記作業は、管理対象ノードで以下のコマンドを入力して、実行することも
できます。
ovcert -updatetrusted
注記
ここでの説明では、証明書サーバーは管理サーバーと同じサーバーに存在し
ます。
5. 両方のサーバーで担当マネージャのポリシーを作成または改版し、それぞれのエージェント
に配布します。M1 は、担当マネージャのポリシーをすべての管理対象ノードに配布する必
要があります。この場合、M1 および AM1 が管理対象ノードになります。M2 のローカル
エージェントが M1 の環境に属していなかった場合、M2 は M2 のローカルエージェントに
担当マネージャのポリシーを配布する必要があります。
MoM 環境での共有 CA の利用
ここまでで、別々の認証局を持った環境を合併する方法について、説明してきました。1 つの認
証局だけで構成することも可能ではあります。ただし、これは OVO MoM 管理対象環境をセッ
トアップする前に充分な検討をしておく必要があります。
1 つの認証局を共有することの不利な点は、各エージェントからこの 1 つの証明書サーバーへの
通信経路が必要になることです。これはインストール時にエージェントが証明書を要求できるよ
うに設定する場合、または後でエージェントシステムに追加証明書をインストールする必要があ
る場合に問題になります。
また、すべての OVO 管理サーバーとその管理対象ノードが 1 つの認証局に依存します。
注記
認証局を共有する方法は、推奨される構成方法ではありません。上述の、信頼で
きる証明書を使った方法が、推奨されます。
M1 には認証局があり、M2 にはそれがないものとします。
以下の手順を実行します。
1. M2 をインストールしたら、次のコマンドを使ってただちにローカルの証明書を削除します。
ovcert -remove <cert_id>
ovcert -remove -ovrg server <cert_id>
第3章
63
セキュリティの概念
証明書サーバーが複数個ある環境
2. 次のようにして、M1 の登録ノードに M2 を追加します。
ノード M1 で管理者 GUI を使用します。
[ アクション -> ノード -> 追加 ]
注記 : 次のようにコマンド行ツールを使うこともできます。
M1 で次のコマンドを入力します。
opcnode -add_node node_name=<M2> ¥
net_type=<network_type> mach_type=<machine_type> ¥
group_name=<node_group_name>
3. M1 で以下のコマンドを実行して、M2 用の証明書を作成します。
opccsacm -issue -name <M2> -coreid <core_ID_M2> ¥
-file <M2_cert> -pass <password>
注記
M2 のコア ID を表示するには、M1 システムで、以下のコマンドを実行しま
す。
ovcoreid -ovrg server
opccsacm の実行では、M2 のコア ID のデータベースへの追加も行なわれます。
4. 証明書を M2 (HA サーバー ) へコピーし、それをサーバーの証明書としてインストールしま
す。
ovcert -importcert -ovrg server -file <my_cert> ¥
-pass <password>
M2 が OVO HA クラスタサーバーではない場合には、リソースグループの server オプショ
ンを指定せずにこのコマンドを実行し、ノード証明書をインストールします。
ovcert -importcert -file <my_cert> -pass <password>
M2 が HA システムである場合には、各物理ノードに追加のノード証明書を作成します。M1
で以下のコマンドを実行します。
opccsacm -issue -name <hostname_M2_cluster_node> ¥
-coreid <OvCoreId_M2_cluster_node> -file <my_cert> ¥
-pass <password>
ノード証明書を M2 クラスタノードにコピーし、以下のコマンドを実行して、インストール
します。
64
第3章
セキュリティの概念
証明書サーバーが複数個ある環境
ovcert -importcert -file <my_cert> -pass <password>
5. bbc_inst_defaults ファイルにエントリーを追加することによって、M2 によってインス
トールされるすべての管理対象ノードに、それらの証明書サーバーが M1 であることを認識
させます。このファイルはエージェントのインストール用のプロファイルを自動的に生成す
るために使われます。このファイルは次の場所にあります。
/etc/opt/OV/share/conf/OpC/mgmt_sv/bbc_inst_defaults
注記
このファイルが存在しない場合には、次のサンプルファイルをテンプレート
として直ちにファイルを作成してください。
/etc/opt/OV/share/conf/OpC/mgmt_sv/bbc_inst_defaults.sampl
bbc_inst_defaults ファイルに、名前空間と証明書サーバーを追加します。
[sec.cm.client]
CERTIFICATE_SERVER <hostname_M1>
M2 のローカルエージェントで、以下のコマンドを実行します。
ovconfchg -ns sec.cm.client -set ¥
CERTIFICATE_SERVER <hostname_M1>
6. 次のコマンドを使って、M2 のシステムから証明書サーバー (ovcs) コンポーネントを登録解
除します。
ovcreg -del ovcs
7. 両方のサーバーで担当マネージャのポリシーを作成または改版し、それぞれのエージェント
に配布します。M1 は M2 によって管理されるすべてのエージェントに、担当マネージャの
ポリシーを配布する必要があります。M2 のローカルエージェントが M1 の環境に属してい
なかった場合、M2 は M2 のローカルエージェントに担当マネージャのポリシーを配布する
必要があります。
8. opccfgupld ツールおよび opccfgdwn ツールを使って、M1 の登録ノードの設定情報をダウ
ンロードし、M2 にアップロードします。
第3章
65
セキュリティの概念
リモートアクションの許可
リモートアクションの許可
OVO 管理環境では、リモートアクションは、セキュリティの観点から、特殊な扱いが必要です。
環境内の指定されたリモートシステム上で実行されることになる偽のリモートアクションは、管
理サーバーには送信できないようにする必要があります。ただし、管理対象システムがすべて安
全なシステムであるとは限らないので、非常に難しい問題です。場合によっては、未承認のユー
ザーでも root として管理対象ノードにアクセスできます。
また、サービスプロバイダで使用されている OVO 管理サーバーの一台は、複数の顧客環境を管
理する必要があります。このとき、特定の顧客セグメントに存在するシステムが別の顧客セグメ
ントのアクションをトリガーしないことを保証する必要があります。
OVO は特定のコマンドなどのアクション文字列が悪意のあるユーザーによって改ざんされるこ
とがないことを保証します。リモートアクションに関して、OVO 管理サーバーでは、以下の設
定が可能です。
•
(OVO 管理サーバーによってアクションが実行されることを許可する ) システムの指定。
•
許可するアクションを、HTTPS エージェントが発行する「署名付きアクション」に限定す
るかを指定。
リモートアクションは、OVO メッセージに含まれるアクションリクエストで、メッセージの発
行元とは異なるアクション実行対象のノードが指定されています。リモートアクションは、安全
に処理する必要があるため、次項で説明するセキュリティチェックの対象となります。リモート
アクションはこのセキュリティチェックを通過した場合にのみ実行されます。
リモートアクションを許可するためのサーバーの設定
メッセージマネージャでは、OVO 管理サーバーにある設定ファイルを使ってリモートアクショ
ンの許可を指定します。設定ファイルには、アクションの署名者として信頼できるシステムを定
義する trust セクションと、条件とアクションで構成されるルールのリストが含まれます。各ア
クションリクエストは定義されている順番に条件がチェックされます。条件が成立した段階で、
アクションリクエストの処理は停止します。
条件を指定すると、ソースノード、ターゲットノード、署名など、アクションリクエストのプロ
パティをチェックできます。アクションには、allow と deny の 2 種類を指定します。allow ア
クションは、アクションリクエストを許可することを意味します。deny アクションは、アク
ションリクエストを拒否することを意味します。
66
第3章
セキュリティの概念
リモートアクションの許可
許可に関するデータは、アクションを許可しなかった理由と共にログに記録されます。アクショ
ンが許可されなかった場合、アクションはメッセージから自動的に削除され、一致条件と署名の
ステータス情報がメッセージの注釈に追加されます。許可されなかったメッセージが GUI 上に
表示されることはなく、そのため誤って実行されることもありません。
ソースノードとターゲットノードは、それぞれノードグループまたは 1 つのノードと比較されま
す。管理サーバーには専用のキーワードが使われます。
新しい設定ファイルが存在しなかったり、ルールを含んでいない場合には、すべてのリモートア
クションは無効になります。管理サーバーの OvCoreId を含むデフォルトの設定ファイルが、製
品のインストールと同時にインストールされます。デフォルトの設定ファイルには、コメント形
式で、いくつかの例が含まれます。
メッセージマネージャは、起動時に次のファイルを読み込みます。
/etc/opt/OV/share/conf/OpC/mgmt_sv/remactconf.xml
このファイルは、実行時に再読み込みすることも可能です。
設定ファイルの構文は、XML ベースで、以下のスキーマに従います。
図 3-3
第3章
リモートアクション設定ファイルの構文
67
セキュリティの概念
リモートアクションの許可
表 3-1 リモートアクション設定ファイルのコンポーネント
要素
説明
config
config は、trust 要素と rule 要素のリストで構成されま
す。
trust
trust 要素は、nodeId 要素のリストで構成されます。各
nodeId 要素には、信頼できるノードの OvCoreId が含まれ
ます。
rule
各 rule は以下のコンポーネントで構成されます。
•
doc ( オプション )：説明文が含まれる。文字列
•
if ( オプション )：条件が含まれる
•
allow アクション、または deny アクション
allow アクション、または deny アクションは空で、ア
クションの実行を許可、または拒否するかを定義しま
す。
条件
条件は、一連のオプションのチェック項目で構成されます。
条件が成立するのは、含まれるすべてのチェック項目と一
致した場合だけです。チェック項目が定義されていない場
合、または 条件が定義されていない場合には、常に条件が
成立するとみなされます。
チェック項目には、以下の種類があります。
68
•
source
•
target
•
certified
第3章
セキュリティの概念
リモートアクションの許可
表 3-1 リモートアクション設定ファイルのコンポーネント ( 続き )
要素
説明
source
アクションリクエストのソースノードをチェックするため
に使われます。
target
アクションリクエストのターゲットノードをチェックする
ために使われます。
ソースノードとターゲットノードは、いずれも以下の選択
肢 ( 複数可 ) で構成されます。これらのチェックが成立する
のは、いずれかの要素が一致した場合です。
•
nodegroup
nodegroup 要素には、OVO データベースに格納されて
いるノードグループの名前が含まれます。要求した
ノードがそのノードグループのメンバーの場合に、条
件が成立します。
•
nodeId
nodeId 要素には、OvCoreId が含まれます。この
OvCoreId が要求したノードの ID の場合に、条件が成
立します。
•
mgmtsrv
mgmtsrv 要素は空です。要求したノードが管理サー
バーの場合に、条件が成立します。
certified
•
nodeAddress
•
nodename
certified チェック項目には、true と false の値が指定
できます。
true は、署名と証明書 ( 署名は証明書の所有者によって署
名されている ) が存在し、証明書の対象の OvCoreId が
trust 要素にリストされている場合にだけ条件が成立しま
す。
false を指定すると、その他のすべての場合に条件が成立
します。
第3章
69
セキュリティの概念
リモートアクションの許可
リモートアクション設定の例を、以下に示します。
<?xml version="1.0"?>
<config xmlns="http://openview.hp.com/xmlns/Act/Config/2002/08">
<rule>
<doc>Actions from Group2 to Group1 are always allowed</doc>
<if>
<source>
<nodegroup>Group2</nodegroup>
</source>
<target>
<nodegroup>Group1</nodegroup>
</target>
</if>
<allow/>
</rule>
<rule>
<doc>No actions from Group3 are allowed</doc>
<if>
<source>
<nodegroup>Group3</nodegroup>
</source>
</if>
<deny/>
</rule>
<rule>
<doc>Actions to Group3 are allowed if certified</doc>
<if>
<target>
<nodegroup>Group3</nodegroup>
</target>
<certified>true</certified>
</if>
<allow/>
</rule>
</config>
70
第3章
セキュリティの概念
代行ユーザーによるエージェントの実行
代行ユーザーによるエージェントの実行
UNIX システムの OVO プロセスは、通常、ユーザー root で動作し、Windows システムの場合
は System アカウントで動作します。root/ 管理者の特権を持つプロセスは、次のことが行えま
す。
•
OpenView のリソースへアクセスする。OpenView のファイルへアクセスできるのは、通常、
特権を持つアクセスだけに制限されています。
•
ユーザーのアクセス権をアプリケーションに固有な値に変更する。
•
ログファイルや設定ファイルなど、オペレーティングシステムのリソースへ直接アクセスす
る。
•
アプリケーションまたはオペレーティングシステムに固有なコマンドや実行可能プログラム
を起動する。
IT 環境内のシステムのなかには高い機密性を必要とするものがあります。こうしたシステムで
は、root の特権を持つプロセスの数を制限し、テスト済みで信頼の置ける少数のグループにだけ
その特権を許す必要があります。また、クリティカルなシステムリソースを操作したプロセスが
あれば、そのプロセスを正確に識別できた方が望ましいはずです。多くのアプリケーションが特
権ユーザーとして動作していると、こうした識別が困難です。
注記
ovswitchuser は、Windows プラットフォームの OVO HTTPS エージェントで
はサポートされません。
UNIX 管理対象ノードシステム上の OVO ソフトウェアは、root の全部の特権を持たないユー
ザーとして動作するように、設定することができます。このような動作形態は、「非 root で動作
させる」という用語でも表現します。エージェントを非 root で動作させるには、ノード上の
OVO プロセスに対して、OpenView 以外のファイルと実行可能プログラムへアクセスできる権
利を与える必要があります。
UNIX システム上のすべての OVO HTTPS エージェントは、ovswitchuser ツールを使うこと
で、非 root ユーザーで動作するように設定できます。
第3章
71
セキュリティの概念
代行ユーザーによるエージェントの実行
ovswitchuser ツールを使うと、特権が与えられた root ユーザーでなくても OVO 管理対象ノー
ド上の UNIX HTTPS エージェントを実行できるようになります。ovswitchuser ツールは、次
のような変更を行います。
•
次のグループ所有権を変更する
— インストールされているすべてのコンポーネントパッケージの登録済みファイルすべて
— <OVDataDir>にあるすべてのファイルとディレクトリ(サブディレクトリ以下にあるもの
もすべて含みます )
•
オペレーティングシステムのデーモン / サービスの登録を変更して、新しいユーザーの下で
OVO プロセスを起動する
OVO エージェントを代行ユーザーで動作させる場合の制限
代行ユーザーで実行されるエージェントには、次の制限があります。
警告
OVO 管理サーバープロセスは、必ずユーザー root で実行する必要があります。
ovswitchuser ツールは、OVO 管理サーバーシステムでは使えません。
注記
Windows プラットフォームの OVO HTTPS エージェントは、ovswitchuser を
サポートしません。Windows システムでは、System ユーザーで実行する必要が
あり、他のどのユーザーにも切り替えることはできません。
•
エージェントを実行するアカウントが適切な特権を持っている場合だけ、アクションが実行
されます。
•
エージェントのアカウントに適切な特権が設定されていない場合は、オペレーティングシス
テムのリソース ( ファイルなど ) にアクセスできません。
注記
72
sudo プログラムを実装すれば、アクセスの制限を回避することが可能です。
このプログラムを使うと、エージェントユーザーに対して、特定の操作を行
う権利を追加することができます。詳細は、81 ページの「UNIX エージェン
トでの sudo プログラムの使用方法」を参照してください。
第3章
セキュリティの概念
代行ユーザーによるエージェントの実行
代行ユーザーが実行するエージェントの設定
システム環境の準備
警告
ovswitchuser.sh は、OVO 管理サーバーシステムでは使わないでください。
OVO 管理サーバーの OVO エージェントは、ユーザー root で実行する必要があ
ります。
注記
ovswitchuser コマンドを使ってユーザーを変更したら、エージェントプロセス
をユーザー root ではなく、新しく割り当てたユーザーのもとで実行する必要が
あります。
エージェントが HTTPS エージェントの場合は、エージェントのグループとして UNIX グルー
プを指定する必要があります。エージェントを動作させることのできるユーザーは、すべてこの
グループに属する必要があります。
非 root の DCE エージェントを非 root の HTTPS エージェントに移行する場合には、注意しな
ければならない項目がいくつかあります。たとえば、非 root の DCE エージェントが、グループ
Security に属するユーザー OVO_Agent で動作していたとします。ユーザー OVO_Agent とスー
パーユーザーを除くと、どのユーザーもこのエージェントの実行時ファイルを読むことができま
せん。HTTPS エージェントの場合はグループレベルでパーミッションが設定され承諾されるの
で、グループ Security に属するユーザーであれば、どのユーザーでもエージェントの実行時
データにアクセスできます。そのため、新しいグループ Security2 を作成して、ユーザー
OVO_Agent をこの Security2 グループに編入する必要があります。そうしないと、グループ
Security に属する他のユーザーからも、秘密鍵を含むエージェントの実行時データにアクセス
できることになります。
注記
上述のケースで使ったユーザーとグループは、単なる例です。ユーザー名とグ
ループ名は、自由に指定することができます。
DCE エージェントから HTTPS エージェントへ移行する場合、DCE エージェントユーザーが属
しているグループの他のすべてのユーザーが信頼できるユーザーであれば、非 root で動作させ
る必要のある HTTPS エージェントに置き換える際に、何の移行手順も必要ありません。
HTTPS エージェントは DCE エージェントで使われていた同じユーザーのもとで動作します。
第3章
73
セキュリティの概念
代行ユーザーによるエージェントの実行
UNIX の umask の設定 － 「非 root」という概念は、エージェントを動作させるユーザーが特定
の UNIX グループに属していることを前提にしています。したがって、OV アプリケーションで
作成するファイルは、どのファイルのグループビットもセットされます。そのため、OV アプリ
ケーションを専用ユーザーで動作させながらログファイルなどのリソースを共有する、というこ
とも必要に応じて実現することができます。このことから、OV アプリケーションを実行する
ユーザーには、適切な umask を設定することをお勧めします。
umask の設定は、02 をお勧めします。022 を設定すると、複数のアプリケーションが異なる
ユーザーから実行された場合に問題を起こす可能性があります。
OVO エージェントだけがインストールされている場合と、すべてのアプリケーションが同じ
ユーザーによって実行されている場合は、umask は設定する必要がありません。
UNIX 管理対象ノード上の代行ユーザーを使ったエージェントのインストール
root の代行アカウントを使って管理対象ノードを実行するには、以下の手順を実行します。
1. エージェントソフトウェアを通常の手順でノードにインストールします。
2. 以下のコマンドを実行して、エージェントを停止します。
opcagt -kill
注記
次のコマンドは使わないでください。
opcagt -stop
これを使うと、エージェントプロセスは停止できますが、コア OpenView プ
ロセスは停止しません。後でエージェントプロセスを再起動するには、以下
のコマンドを実行します。
opcagt -start
コアプロセスは root ユーザーのもとで動作しているので、すべての他のプロ
セスも root ユーザーのもとで起動されます。
3. ユーザーの umask を設定して、グループパーミッションを与えます。
4. 次のように、ovswitchuser コマンドを実行します。
/opt/OV/bin/ovswitchuser.sh -existinguser <my_user> ¥
-existinggroup <my_trusted_group>
74
第3章
セキュリティの概念
代行ユーザーによるエージェントの実行
特に指定しない限り、OVO HTTPS エージェントのポートとして、ネットワーク通信用の
ポート 383 が使われます。これは root ユーザーだけがオープンできる特権ポートです。し
たがって、次の選択肢の中からいずれかを選んで、非 root エージェントがネットワークの通
信に使うポートを設定する必要があります。
5. 使う予定のポートを設定します。
予約された特権ポート 383 を続けて使う場合には、SUID ビットを以下の 1 番目に示す方法
で設定します。別のポートを使う場合には、以下の 2 番目に示す方法で ovconfchg コマン
ドを使いポートを再設定します。
警告
•
setuid の使用または PORTS 設定の変更のどちらかの方法で行う必要がありま
す。
通信ブローカの実行可能プログラムに対して SUID ビットを設定する。こうすれば、予約
されている特権ポート 383 をそのまま使えます。この選択肢を選択すると、通信ブロー
カはポートをオープンするときにだけ root 特権を使い、それ以外の動作はエージェント
ユーザーに戻って行うようになります。
次のコマンドを使って、ovbbccb バイナリの setuid ビットを設定します。
chmod 4550 /opt/OV/bin/ovbbccb
•
非特権の ovbbccb ポートを選択する。ポートを 383 から、1024 より大きな値のポートに
変更します。
HTTPS エージェントについては、HTTPS エージェントが root ユーザーで動作してい
ないシステムの通信ブローカポートを、非特権のポートに変更します。その結果、この
ノードの通信ブローカを使っているその他のアプリケーションには、すべて同じ制限が
適用されます。別のポートを使う場合には、「代行ユーザーが実行するエージェントのた
めの OVO 管理サーバーの設定」を参照してください。
管理対象ノードで、次のコマンドを実行します。
ovconfchg -ns bbc.cb.ports -set PORTS ¥
<FULL_DNS_NODE_NAME>:<NEW_PORT_NUMBER>
第3章
75
セキュリティの概念
代行ユーザーによるエージェントの実行
代行ユーザーが実行するエージェントのための OVO 管理サーバーの設定
管理対象ノードでデフォルトの 383 以外のポートを使っている場合には、OVO 管理サーバーで
もその設定を行う必要があります。またその場合は、特定のノードで使用するポートを、すべて
の OVO 管理サーバーに知らせる必要があります。そうしないと、OVO 管理サーバーは管理対
象ノードにアクセスできません。これは、OVO 管理サーバー上の bbc.cb.ports:PORTS 変数を
設定することで行います。
たとえば、管理対象ノードのホスト名が ovo_node.sales.mycom.com で、OVO 管理サーバー
のホスト名が ovo_srv.sales.mycom.com であるとします。また、
ovo_node.sales.mycom.com 上の新しい ovbbccb ポートが 8001 とします。
このポートの値は、管理対象ノードと OVO 管理サーバーに設定する必要があります。
ovbbccb ポートに別の値を設定する場合には、OVO 管理サーバーと管理対象ノードの双方で、
次のコマンドを実行します。
ovconfchg -ns bbc.cb.ports -set PORTS ¥
"ovo_node.sales.mycom.com:8001"
新しいポートの値を各管理対象ノードで個別に設定すると、非効率で、間違える可能性がありま
す。ワイルドカードが使えるので、以下の例に示すように、管理対象ノードのグループを指定す
る場合には、ワイルドカードを使ってください。
ドメイン sales.mycom.com 内のすべてのノードでポート 8001 を使うものとします。このポー
トをドメイン内のすべてのシステムに設定するには、OVO 管理サーバーと管理対象ノードの双
方で、次のコマンドを実行します。
ovconfchg -ns bbc.cb.ports -set PORTS ¥
"*.sales.mycom.com:8001"
ただし、OVO 管理サーバーでは、常にポート 383 を使うことをお勧めします。そのためには、
上述の手順を変更して、OVO 管理サーバーと管理対象ノードの双方で、次のコマンドを実行し
ます。
ovconfchg -ns bbc.cb.ports -set PORTS ¥
"ovo_srv.sales.mycom.com:383,*.sales.mycom.com:8001"
OVO 管理サーバーの bbc.cb.ports:PORTS エントリーは、常に最新のものにしておくことが重
要です。管理対象ノードで別の管理対象ノードがどのポートを使っているかを把握する必要性
は、特別なことがない限りありません。したがって、通常は、OVO 管理サーバーの設定と新し
くインストールした管理対象ノードエージェントの設定だけを考える必要があります。既存の
エージェントは、PORTS 設定を更新する必要がありません。
76
第3章
セキュリティの概念
代行ユーザーによるエージェントの実行
デフォルトポートの変更
管理サーバー上での変更を少なくするために、PORTS の設定は OVO 管理サーバーシステムで集
中管理することをお勧めします。また、ワイルドカードの使用をお勧めします。
パラメータの設定方法の例を示すサンプル設定ファイルが次の場所に用意されています。
/etc/opt/OV/share/conf/OpC/mgmt_sv/bbc_inst_defaults.sampl
bbc_inst_defaults.sampl のコピーを作成し、それを、bbc_inst_defaults と名前を換え
て、次に示す方法で変更してください。
bbc_inst_defaults ファイルのエントリーは、次の形式で作成します。
[bbc.cb.ports]
PORTS = ovo_srv.sales.mycom.com:383,*.sales.mycom.com:8001
こうしておけば、新しくインストールするエージェントには、「ovo_srv.sales.mycom.com は
ポート 383 を使い、*.sales.mycom.com に一致するエージェントはすべてがポート 8001 を使
う」という情報が自動的に設定されます。bbc_inst_defaults ファイルが「エージェントプロ
ファイル」のベースになります。新しい管理対象ノードには、このファイルが必ずインストール
されます。エージェントプロファイルについては、78 ページで詳しく説明されています。
新しい管理対象ノードシステムがドメイン *.sales.mycom.com に属する場合は、それまでに
行った管理対象ノードのインストールで、OVO 管理サーバーは正しく設定され、ポート 8001
が使われます。この設定は、OVO 管理サーバーで次のコマンドを使って確認できます。
ovconfget bbc.cb.ports
OVO 管理サーバーに正しい設定が行われていない場合には、bbc_inst_defaults ファイルに
ある値を使って次の形式で ovconfchg を実行し、OVO 管理サーバーを更新します。
ovconfchg -ns bbc.cb.ports -set PORTS ¥
"<ovo_server>:383,<system1>:<port1>,<system2>:<port2>, ¥
*.<domain1>:<port3>,*.<domain2>:<port4>"
第3章
77
セキュリティの概念
代行ユーザーによるエージェントの実行
エージェントプロファイル
OVO 上で維持するエージェントプロファイルは、インストール時にエージェントにコピーされ
る設定のリストです。このプロファイルには、bbc_inst_defaults ファイルで設定する必要が
ないいくつかのデフォルト値が含まれています。また、bbc_inst_defaults ファイルで定義さ
れた設定もエージェントプロファイルにコピーされます。
プロファイルは、エージェントの最初に行うすべてのタイプのインストールに関連します。
bbc_inst_defaults ファイルの使用は任意です。bbc_inst_defaults ファイルが存在する場
合には、このファイルからのデータをエージェントプロファイルに追加します。
手作業でエージェントをインストールする場合には、次のコマンドを使って、エージェントプロ
ファイルを作成します。
/opt/OV/bin/OpC/opcsw -create_inst_info <node>
プロファイルは、次の場所に格納されます。
/var/opt/OV/share/tmp/OpC/distrib/<hex_IP_addr_of_node>.i
注記
opcsw を使うと、<hex_IP_addr_of_node> が stdout に出力されます。
プロファイルをソフトウェアパッケージと共にノードにコピーし、次の形式でコマンドを入力し
ます。
opc_inst -config <profile_name> ...
ユーティリティ opcsw には、次のオプションがあります。
create_inst_info
このオプションは、opcsw -create_inst_info <node_specifier> のような形式で使います。
このコマンドを実行すると、<node_specifier> で指定した各ノードに対し、
/var/opt/OV/share/tmp/OpC/distrib/<hex_IP_addr>.i
というファイルが作成されます。
このファイルには、IP アドレスが <hex_IP_addr> のノードをインストールする時のデフォルト
値が含まれています。このファイルは、リモートからエージェントをインストールする時に、
inst.sh を使ってターゲットノードへ自動的にコピーされます。またこのファイルは、手作業で
エージェントをインストールするときにも使うことができます。
opcsw -create_inst_info コマンドを実行すると、管理サーバー上のファイル
/etc/opt/OV/share/conf/OpC/mgmt_sv/bbc_inst_defaults
78
第3章
セキュリティの概念
代行ユーザーによるエージェントの実行
にある設定データと、OVO データベースにある次の情報から、エージェントプロファイルが作
成されます。
•
CORE_ID: 管理対象ノードの OVCoreID です。OVO データベースの名前空間 sec.core に
CORE_ID の値があるとプロファイルに追加される、オプションのパラメータです。
CORE_ID パラメータがデータベースまたは管理対象ノードのいずれにも存在しない場合は、
そのエージェントに対して CORE_ID が自動的に作成されます。
•
MANAGER: 名前空間 sec.auth における一次 OVO 管理サーバーのロングホスト名です。
初期インストール後の設定、配布、メッセージ、およびアクションの実行に関連する処理
は、ノード MANAGER にだけその権限が与えられます。
•
MANAGER_ID: 名前空間 sec.auth における MANAGER の OVCoreID です。
MANAGER_ID は MANAGER に対応した ID で、許可チェックのために必要です。
•
CERTIFICATE_SERVER: 名前空間 sec.cm.client における、証明書発行元システム ( 認証局 )
のロングホスト名です。
管理対象ノードに有効なノード証明書がない場合は、ID として CORE_ID を使って、
CERTIFICATE_SERVER から証明書が発行されます。
•
PROXY
指定したホスト名に対してどのプロキシとポートを使うかを定義する情報です。
これらの 5 つのパラメータは、管理対象ノードの初期設定に必要となる最小限のパラメータで
す。たとえば、複数の OVO 管理サーバーに対して専用の認証局を 1 つ設定する場合には、
bbc_inst_defaults ファイルにあるこれらのパラメータを書き換えます。
第3章
79
セキュリティの概念
代行ユーザーによるエージェントの実行
代行ユーザーが実行するエージェントのアップグレードとパッチ
DCE/NCS エージェントのアップグレードとパッチでは、アップグレードとパッチのインストー
ルを含めた各エージェントソフトウェアのインストールが終了した後に、opcswitchuser を実
行する必要があります。これですべての OV ファイルとディレクトリの所有権が、ユーザーの指
定した所有者に変更されます。また、起動スクリプトが変更されて、OVO プロセスをこの特定
ユーザーで起動するように設定されます。opcswitchuser は、特定のシステムに追加の
OpenView モジュールをインストールするたびに実行して、新しいファイルの所有権を非 root
ユーザーに合うように変更する必要があります。
HTTPS エージェントのアップグレードとパッチを行う場合は、ovswitchuser を使いません。
HTTPS エージェントのアップグレードとパッチを行う方法は、以降に説明します。
ノードにコピーした後、手作業でインストール
注記
「ノードにコピーした後、手作業でインストールする」方法は、HTTPS ノードに
対してだけ有効です。
OVO の管理者がシステムに対して root のアクセス権を持っておらず、しかも OVO エージェン
トが非 root で動作しているということもあり得ます。しかしこのような場合でも、通信ブロー
カがそのノードで動作していれば、HTTPS エージェントではパスワードを入力する必要があり
ません。これは、パスワードがなくてもデータを転送できるからです。ただし、root のアクセス
権がないと、エージェントの完全なリモートインストール (116 ページの「手作業によるエー
ジェントのインストール」を参照 ) は実行できません。エージェントパッケージを管理対象ノー
ドシステムへコピーすることだけが可能で、インストールは、そのノードシステムで手作業に
よって行う必要があります。Solaris の pkgadd、Linux の rpm、HP-UX の swinstall のような
ネイティブのインストーラには、スーパーユーザーの特権が必要です。HTTPS ノードでのこの
ような作業を、「ノードにコピーした後、手作業でインストールする」方法と言います。
非 root エージェントを動作させている場合は、ネイティブインストーラからしかアクセスでき
ないサブエージェント、パッチ、または完全なアップグレードパッケージを配布すると、次の処
理が自動的に実行されます。
1. バイナリが /tmp/<pkg_name> にコピーされます。
2. インストールはこれより先に進みません。配布する側には root の権限がないのでその権限の
必要なネイティブインストーラを呼び出せないからです。
[OK] という表示が出て終了しますが、警告メッセージが生成されます。
80
第3章
セキュリティの概念
代行ユーザーによるエージェントの実行
3. インストールしようとしている管理対象ノードの管理者に、そのノードでパッケージが取り
扱えるようになったことを知らせます。この知らせを受けた管理対象ノードの管理者は、手
作業でエージェントをインストールする場合と同じように、opc_inst スクリプトを使って、
インストールを続けることができます。
注記
ブートストラップの転送方法には、HTTPS を使った転送が望まれます。ただし
その場合は、非 root エージェントのサブエージェント、パッチ、またはアップグ
レードをリモートからインストールしようとしたときにパスワードは要求されま
せんが、バイナリをコピーした時点で終了してしまいます。また、この後の作業
では root のパスワードが要求されないかわりに、インストールを明示的に指示す
る必要があります。手作業によるこの後半のインストール手順は、現在のエー
ジェントユーザーで実行します。
UNIX エージェントでの sudo プログラムの使用方法
注記
「ノードにコピーした後、手作業でインストールする」方法と sudo プログラムの
使用は、HTTPS ノードに対してだけ有効です。
必要な権限を取得するための 1 つの方法は、sudo のようなツールを組み込んで、OV_SUDO を設
定することです。Sudo を使うと、sudoers ファイルに設定されている内容に従って、許可され
たユーザーがスーパーユーザーまたは自分以外のユーザーとしてコマンドを実行できます。実際
に使われる実効 uid および gid は、passwd ファイルに設定されているそのターゲットユーザー
と同じ値に設定されます。また、ターゲットユーザーが root でない場合はグループベクトルも
初期化されます。特に指定しない限り、sudo ではユーザーの認証にパスワードを必要とします。
また、このパスワードには、デフォルトでユーザーのパスワードが要求されます。root のパス
ワードではありません。ユーザーが認証されるとタイムスタンプが更新され、ユーザーはしばら
くの間、パスワードなしで sudo を使うことができます。この時間のデフォルト値は 15 分で、
sudoers ファイルを変更していなければ、この値が使われます。
注記
sudo はフリーソフトウェアであり、BSD スタイルのライセンスで配布されてい
ます。このソフトウェアは、http://www.sudo.ws から入手できます。
sudo ソフトウェアは、OVO ソフトウェアパッケージに含まれていません。
Solaris の動作している管理対象ノードで、HTTPS エージェントが非 root ユーザー ovo_user
で実行されている場合を考えてみます。
手順は、次のとおりです。
第3章
81
セキュリティの概念
代行ユーザーによるエージェントの実行
1. /etc/sudoers ファイルを開きます。
2. /etc/sudoers ファイルに次の行を追加します。この編集には、vi /etc/sudoers コマンド
または visudo コマンドを使います。
ovo_user ALL=(root) NOPASSWD: /var/opt/OV/¥
installation/incoming/bundles/OVO-Client/opc_inst
インストールスクリプト opc_inst だけがスーパーユーザー root から呼び出されます。
注記
このコマンドは管理者 UI または opc_inst を使ったリモートインストールで
も有効です。その他の場合には、opc_inst への実際のパスに置き換える必要
があります。
NOPASSWD を指定しておかないと、スーパーユーザー (root) のパスワードではなく、そのユー
ザー自身のパスワード、つまりこの例ではユーザー ovo_user のパスワードを入力する必要があ
ります。
sudo プログラムのセットアップ方法
注記
ブートストラップによるインストールでは、OV_SUDO がサポートされていませ
ん。
OpenView のインストールユーティリティには次の形式のコードが含まれており、ネイティブイ
ンストーラを呼び出すように設定されています。
${OV_SUDO} opc_init
OV_SUDO 変数を設定しておかないと、空の文字列と見なされ、無視されます。
OV_SUDO 変数を設定しておくと、非 root ユーザーのログインシェルでこの変数をエクスポート
することも、インストールスクリプトで ovconfget ctrl.sudo を使って読み込み、環境変数に
追加することもできます。
注記
ovconfget ctrl.sudo を使って OV_SUDO 変数を読み込む方が、非 root ユーザー
のログインシェルからその値をエクスポートするよりも優先されます。
sudo を使った非 root エージェントのブートストラップインストールは、多くの場合、次の手順
で行う必要があります。
•
82
エージェントを root でインストールします。
第3章
セキュリティの概念
代行ユーザーによるエージェントの実行
•
/opt/OV/bin/ovswitchuser を呼び出して、適切なユーザーとグループを設定します。
•
次のコマンドを実行して、使用する sudo プログラムを設定します。
ovconfchg -ns ctrl.sudo -set OV_SUDO ¥
<my_sudo_with_full_path>
•
以下のコマンドを実行して、優先 sudo ユーザーを設定します。
ovconfchg -ns ctrl.sudo -set OV_SUDO_USER <my_sudo_user>
•
以下のコマンドを実行して、優先 sudo グループを設定します。
ovconfchg -ns ctrl.sudo -set OV_SUDO_GROUP <my_sudo_group>
注記
sudo を設定する方法の利点は、非 root の環境でもパスワードを入力しないで自
動的にサブエージェント、パッチ、およびアップグレードをインストールできる
ことです。これに対し、リモートからブートストラップでインストールする方法
では、OVO の管理者が管理対象ノードのスーパーユーザーのパスワードを知って
いる必要があります。
リモートエージェントのインストールでは、最初に、どのユーザーとしてエージェントが動作し
ているかということと、OV_SUDO が設定済みかどうかをチェックします。次にこのチェックの結
果を見て、「ノードにコピーした後、手作業でインストールする」方法が必要かどうかを判定し
ます。パスワードの必要なブートストラップインストールを選択するか自動インストールを選択
するかは、その結果次第です。
DCE と HTTPS の代行ユーザーの概念の比較
UNIX システム上のすべての OVO エージェントは、root 以外のユーザーのもとで実行するよう
に設定することができます。これは、DCE ベースまたは NCS ベースの UNIX エージェントの
場合には opcswitchuser ツールを、HTTPS エージェントの場合には ovswitchuser ツールを
使って、設定します。
DCE/NCS エージェントの場合は、任意の OV アプリケーションのすべてのファイルとディレク
トリには、opcswitchuser ツールによって同一のユーザーとグループを設定します。
DCE/NCS ノードで、以下のコマンドを実行します。
/opt/OV/bin/utils/opcswitchuser.sh <my_trusted_user> ¥
<my_group>
第3章
83
セキュリティの概念
代行ユーザーによるエージェントの実行
注記
opcswitchuser.sh は、すべてのプラットフォームで /opt/OV/ にあるとは限りま
せん。OVInstallDir と OVDataDir の実際の値を調べてください。
•
HTTPS エージェントの方は、動作させるユーザーに対して UNIX グループを選択する必要が
あります。DCE/NCS エージェントの方は、この作業が不要です。詳細は、73 ページの「シ
ステム環境の準備」を参照してください。
•
HTTPS エージェントの方は、割り当てたユーザーだけでなく、HTTPS エージェントのユー
ザーと同じグループに属する他のすべてのユーザーに対しても、ファイルのアクセス権が与
えられます。DCE/NCS エージェントの方は、割り当てたユーザーの下でしか動作させるこ
とができません。このことを例で示すと、OVO キューファイルのパーミッションは、
HTTPS の場合は 0660、DCE の場合は 0600 となります。
注記
•
エージェントプロセスの実行ユーザーを変更するときは、その前にそのユー
ザーの umask を設定してグループパーミッションを許可してから、エージェ
ントをシャットダウンします。
HTTPS エージェントのベースディレクトリには、group-id ビットが設定されます。
group-id ビットの設定によって、そのディレクトリの下に作成されるすべてのファイルが
エージェントのグループに属することが保証されます。この保証は、エージェントを動作さ
せているユーザーの一次グループがそのエージェントのファイル / ディレクトリのグループ
と異なる場合でも有効です。
たとえば、ユーザー OVO_Agent の一次グループが Security で、エージェントのファイル /
ディレクトリがグループ Security2 に属する場合を考えてみます。いま、OVO_Agent をグ
ループ Security2 に追加し、ユーザー OVO_Agent の下でエージェントを実行したとします
(OVO_Agent の一次グループは Security のままです )。ユーザー OVO_Agent の下で実行さ
れるエージェントが作成するファイルは、すべてが Security2 に属するようになります。
このメカニズムを使うと、OV コンポーネントに共通ファイルを共有させながら、異なる
ユーザーの下で動作させることができます。
•
set group-id ビットが設定されていると、medusa のようなセキュリティチェックツールで
警告メッセージが出されることがありますが、無視しても安全です。DCE/NCS エージェン
トの方では、このような警告は出されません。
•
DCE/NCS ノードには、「ノードにコピーした後、手作業でインストールする」方法がありま
せん。
•
DCE/NCS ノードには、sudo の概念がありません。
84
第3章
セキュリティの概念
代行ユーザーによるエージェントの実行
•
DCE/NCS ノードでは、非 root エージェントにパッチ / アップグレードをインストールするた
びに、opcswitchuser を呼び出す必要があります。HTTPS エージェントでは、その必要が
ありません。HTTPS エージェントの場合、ovswitchuser の呼び出しは、ブートストラッ
プインストールの後に 1 回行うだけで十分です。後で ovswitchuser を呼び出すこともあり
ますが、それは、グループ / ユーザーを変更する時だけです ( たとえばエージェントのグ
ループ / ユーザーを root に戻す場合 )。
第3章
85
セキュリティの概念
代行ユーザーによるエージェントの実行
86
第3章
4 HTTPS ノード管理の概念
第4章
87
HTTPS ノード管理の概念
HTTPS ノードの制御方法
HTTPS ノードの制御方法
OVO 管理サーバーでは、HTTPS ノードに対して次の機能を実行することができます。
•
HTTPS エージェントのリモート制御
•
HTTPS エージェントのリモートインストールまたは手作業によるインストール
•
パッチのリモートインストールまたは手作業によるインストール、および、エージェントの
リモートアップグレードまたは手作業によるアップグレード
•
設定情報のリモート配布または手作業による配布
•
HTTPS エージェントに対する複数の並列設定サーバーのサポート
•
ハートビートポーリング
•
HTTPS ノードのセキュリティ管理
•
OVO 管理サーバー API とユーティリティを使って行う、HTTPS ノードのサポート
ここでは、HTTPS ノードに対するいくつかの新しいコンセプトを次の項に分けて説明します。
•
89 ページの「HTTPS ノードへの設定情報の配布」
•
96 ページの「HTTPS ノードのハートビートポーリング」
•
98 ページの「HTTPS ノードのリモート制御」
•
31 ページの「OVO サーバーのコンポーネントとプロセス」
88
第4章
HTTPS ノード管理の概念
HTTPS ノードへの設定情報の配布
HTTPS ノードへの設定情報の配布
HTTPS エージェントへ設定情報を配布する方法は、DCE ベースノードの場合と少し異なりま
す。
•
HTTPS エージェントでは、テンプレートの代わりにポリシーを使います。
•
HTTPS エージェントでは、アクション、コマンド、モニターという言葉に代わってインス
トルメンテーションという総称を使います。
•
HTTPS エージェントでは、nodeinfo ファイルと opcinfo ファイルに代わって、名前と値の
ペアでポリシーを定義する設定パラメータスキーマを使います。
•
HTTPS エージェント用の mgrconf ファイルは、役割モデルベースのセキュリティ認証メカニ
ズムが使えるように拡張されています。
注記
同じ担当マネージャファイルを HTTPS と DCE 管理対象ノードの両方をサポー
トするために使うことができます。
しかし、担当マネージャファイルは HTTPS ノード用のみとして次のように作成
することができます。
/etc/opt/OV/share/conf/OpC/mgmt_sv/respmgrs/allnodes.bbc
このファイルが存在する場合、このファイルの優先度は allnodes ファイルより
高く、HTTPS ノードの <hex_IP_addr> ファイルより低くなります。このファイ
ル は、テンプレートと共に配布される allnodes ファイルと同じ方法でポリシー
と共に自動的に配布されます。
allnodes.bbc は、空か allnodes ファイルの設定のサブセットだけが含まれま
す。空の allnodes.bbc ファイルは、MoM 設定が HTTPS ノードに配布されない
ことを意味しています。担当マネージャファイルで指定された、HTTPS ノード
と関連するすべての OVO 管理サーバーシステムは通信タイプとして HTTPS を
使用し、OvCoreId を持つ必要があります。
以下の項で、HTTPS エージェントで導入された新しい設定管理のコンセプトを説明します。
第4章
89
HTTPS ノード管理の概念
HTTPS ノードへの設定情報の配布
ポリシー管理
ポリシーは XML で記述したテンプレートであり、データとメタ情報が厳密に区別されます。
ヘッダーには名前、タイプ、バージョン、あるいは状態などの属性が含まれます。ポリシーに対
しては、インストール、削除、有効化、無効化、および表示の 5 つの操作が実行できます。テン
プレートファイルの場合は、1 つのファイルに特定のソースタイプの個別のテンプレートがすべ
て入れられますが、ポリシーファイルの場合は、1 つのファイルに 1 つのテンプレート内容しか
入れられません。この内容がポリシーデータと呼ばれます。
ポリシーは、ovpolicy ツールを使って手作業でインストールや削除が行えます。ただし、いく
つかのガイドラインに従う必要があります
HTTPS エージェントでは既存の OVO テンプレートも使うことができます。この場合、既存の
OVO テンプレートは opcbbcdist プロセスが分配時にポリシーへ変換します。設定ファイルの
mgrconf と nodeinfo は、ポリシーとして扱われます。必要な mgrconf ファイルと nodeinfo
ファイルはそれぞれ 1 つだけで、一意のポリシー ID が使われます。
ヘッダーには、一意のポリシー ID の他に、ポリシーの名前とバージョン、ポリシータイプの名
前とバージョン、およびステータスが設定されます。これらの属性は、opcbbcdist がデータを
配布する時に生成します。
1 つのノードにインストールできるのは、1 つのバージョンのポリシーだけです。ポリシーは ID
で識別できますが、名前とポリシータイプも一意にする必要があります。
OVO サーバーから配布するポリシーにはすべて、バージョン番号 1 が割り当てられます (OVO
はポリシーのバージョン管理を行いません )。
ポリシーが初めて配布された時のステータスは、enabled ( 有効 ) に設定されます。システムに
そのポリシーがすでに存在していた場合は、そのポリシーのステータスを新しく配布されたポリ
シーが引き継ぎます。
HTTPS ノードには、ovpolicy のラッパーとして opctemplate というユーティリティがありま
す。このユーティリティを使えば、DCE ノードと同じ環境、たとえばアプリケーションのデス
クトップの中で定義を行うことができます。
インストルメンテーション管理
HTTPS ノードでは、アクション、コマンド、およびモニターの全ディレクトリがまとめられて
次のディレクトリに置き換えられました。
$OVDataDir/bin/instrumentation
このディレクトリのサブディレクトリの階層は、1 レベルです。インストルメンテーションプロ
グラムは、すべてこの場所にインストールされます。
90
第4章
HTTPS ノード管理の概念
HTTPS ノードへの設定情報の配布
注記
OVO 管理サーバー上では、次のディレクトリの下に実行可能プログラムのディレ
クトリがあります。
/var/opt/OV/share/databases
instrumentation ディレクトリは作成されず、アクション、コマンド、および
モニターの各ディレクトリが使われます。
注記
OVO のテンプレートでは、通常、アクション、コマンド、およびモニターの各実
行可能プログラムを参照しています。ポリシーの中でこれらの実行可能プログラ
ムがフルパスで指定されていない限り、この変更は影響ありません。というのは、
バイナリの新しい格納場所が、OVO のアクションエージェント、モニターエー
ジェント、ログファイルエンキャプスレータなどのユーティリティのパス変数に
追加されるからです。
OVO 管理サーバーのモニターディレクトリからエージェントに送られたファイルは、744 の
パーミッションでインストールされますが、その他のファイルは 755 のパーミッションでインス
トールされます。この設定値は DCE ベースノードの場合と同じです。
設定管理プロセスは、実行中の実行可能プログラムをアップデートすることもできます。その場
合、実行中の実行可能プログラムは、そのスクリプトとバイナリの名前が変更されますが、処理
自体は完了するまで実行されます。これらのプログラムを次に実行した時は、新しくインストー
ルされたファイルが使われます。
手作業によるポリシーとインストルメンテーションのインストール
ポリシーデータを管理対象ノードに直接コピーすることはできません。その理由は、エージェン
トは機密性の高い形式で設定データを受け取る必要があるからです。これは、管理対象ノード側
で、設定データが許可のない人によって不法に操作されないようにするために必要な制限です。
OVO 管理サーバーで opctmpldwn ツールを使い、手作業によるポリシーのインストールを準備
します。出力データは、管理サーバーシステムにある管理対象ノード専用のディレクトリに格納
されます。
opctmpldwn の処理は、対象が DCE ベースノードか HTTPS ノードかによって、少し違います。
その違いは次のとおりです。
•
対象が HTTPS ノードの場合は、nodeinfo と mgrconf のデータがポリシーと見なされ、上述
のディレクトリに格納されます。対象が DCE ベースノードの場合は、nodeinfo データが
無視されます。
第4章
91
HTTPS ノード管理の概念
HTTPS ノードへの設定情報の配布
•
機密性の保護方法がテンプレートとポリシーで異なります。テンプレートの方は、ノード固
有の鍵で暗号化されます。ポリシーの方は、データ部分が管理サーバーに固有な証明書を
使って署名されるものの、ヘッダー部分はそのファイルのパーミッションで保護されるだけ
です。
HTTPS エージェント分配マネージャ
opcbbcdist が、OVO 管理サーバーと HTTPS エージェントとの間で設定管理アダプタの役割
を果たします。その主な機能は、次のとおりです。
•
テンプレートをポリシーに変換する
•
既存のアクション、コマンド、モニターからインストルメンテーションを作成する
•
ECS テンプレートをポリシーとその関連サーキットに変換する
•
nodeinfo の設定値を HTTPS ノードで使える XPL 形式に変換する
opcbbcdist は、その他の通信タイプを扱う分配マネージャ opcdistm と協調して動作します。
opcdistm と同様、opcbbcdist は次の内部ファイルシステムインタフェースを使って、どの
データを配布すべきかの情報を取得します。
/var/opt/OV/share/tmp/OpC/distrib
opcbbcdist では、次の 4 つの設定カテゴリを区別して扱います。
•
ポリシー / テンプレート
•
インストルメンテーション ( アクション / コマンド / モニター )
•
nodeinfo
•
mgrconf
opcdistm とは違って、opcbbcdist が他の OVO 管理サーバーコンポーネントから受け付ける
リクエストの形式は、「deploy configuration types xyz to node abc」( 設定タイプ xyz
をノード abc へ配布する ) という形式だけです。この形式のリクエストは、GUI、設定 API、
opcragt -update、または opcragt -distrib によって発行されます。
opcbbcdist には自動リトライ機能があり、新しいデータが存在するノードへアクセスできな
かったときに起動されます。またこのリトライ機能は、opcragt -update を呼び出すことによ
り、手作業でも起動できます。
92
第4章
HTTPS ノード管理の概念
HTTPS ノードへの設定情報の配布
opcbbcdist と opcdistm は、特定ノードに対する処理が完了するとブラウザにメッセージを表
示して、設定データが正常に分配されたことを知らせてくれます。処理が完了しなかった場合に
は、たとえば Node Unreachable ( ノードにアクセスできません ) といったようなメッセージが
表示されます。
opcbbcdist では、インストルメンテーションデータを最初に転送し、その後でポリシーを転送
します。このようにするのは、実行可能プログラムがテンプレート内で参照されている場合の同
期問題を避けるためです。また、opcbbcdist は単純なトランザクションモデルに従って処理を
行います。つまり、「ある設定タイプのデータがすべて正常に配布できたら、次のカテゴリを処
理」します。トランザクションの観点からは、1 つの設定タイプの分配が 1 つのトランザクショ
ンとなります。1 つのトランザクションが失敗すると、そのトランザクションはロールバックさ
れ、後でリトライされます。この方式は、OVO サーバーのシャットダウンで opcbbcdist が停
止させられた場合にも適用されます。
設定のプッシュ
OVO 管理サーバーは、HTTPS ノードに対する設定の配布処理をすべて起動できます。その場
合、OVO サーバーは設定データをエージェントに一方的に送信 ( プッシュ ) します。そのため、
OVO 管理サーバーから管理対象ノードに対する処理を起動することによって機密性を高めるこ
とができます。
しかし、OVO 管理サーバーにも不利な点はあります。それは、新しい設定を分配しようとした
管理対象ノードがアクセスできなかったとき、その管理対象ノードは古いデータのまま動作しな
くてはならないということです。OVO 管理サーバーは、分配すべき設定データがあっても分配
できなかったノードを、すべてポーリングする必要があります。OVO 管理サーバーはこのポー
リング処理を次のタイミングで実行します。
•
保留中の各ノードに対して、少なくとも 1 時間に 1 回
•
サーバーの再起動時
•
設定処理が明示的に起動された時。具体的には、opcragt -update の実行、opcragt
-distrib の実行、GUI からの配布の実行、またはコマンドに対応した API を直接呼び出す
ことで設定処理が明示的に起動した時です。
注記
第4章
また、DCE ベースのエージェントは、システムの再起動またはエージェントの再
起動の後に、OVO 分配マネージャ opcdistm に新しい設定データがないかどうか
を尋ねます。
93
HTTPS ノード管理の概念
HTTPS ノードへの設定情報の配布
保留中の分配がないかどうかは、dist_mon.sh と呼ぶモニターでチェックされます。次の設定
転送ディレクトリに 30 分以上保留されているデータがあると、その分配先管理対象ノードを示
すメッセージが表示されます。
/var/opt/OV/share/tmp/OpC/distrib
差分分配
OVO の分配プロセスでは、特に指定しない限り、最後に設定を転送した後で変更または追加さ
れたデータだけを分配します。この方式を差分分配と呼びます。この方式を使うと、データの転
送量を最小限に抑えることができるだけでなく、インターセプタや他のサブエージェントに対す
る再設定リクエストの数を減らすことができます。また必要があれば、設定全体を管理対象ノー
ドに配布し直すこともできます。
差分分配モードで動作している OVO 管理サーバーでは、管理対象ノードにあるポリシーインベ
ントリと、インストルメンテーションが最後に分配された時のタイムスタンプを必要とします。
ポリシーインベントリの内容はポリシー割り当てリストと比較され、opcbbcdist が、ノードに
対するポリシーの削除やインストールに必要な処理を計算して実行します。インストルメンテー
ションの配布については、配布が最後に行われた時のタイムスタンプが、管理サーバーのインス
トルメンテーションディレクトリにあるファイルのタイムスタンプと比較されます。OVO 管理
サーバーに管理対象ノード上のファイルより新しい対応ファイルがあると、それらがすべて分配
されます。インストルメンテーションデータは、コマンド行で opcragt -purge コマンドを適
用しない限り、管理対象ノードから削除されることはありません。このコマンドは、管理者 UI
では実行できません。
複数の並列設定サーバー
HTTPS ノードについては、複数の並列構成のサーバーがサポートされています。OpenView の
ポリシーの概念にはポリシーに対する所有者という概念があり、1 つのエージェント上で、複数
の OpenView 製品がそれぞれのポリシーの下で独立して動作できるようになっています。この
概念を具体化する手段として、ポリシーヘッダーに owner ( 所有者 ) 属性が用意されており、
OVO 管理サーバーによって設定することができます。これは管理サーバー間の合意の概念に基
づく論理的な対応付であり、エージェント上の各設定 ( ポリシー ) を担当する管理サーバーを決
定します。
MoM 設定情報と nodeinfo はポリシーとみなされ、両方ともポリシーヘッダーには所有者の文字
列が含まれています。これらを削除したり変更できるのは所有者だけです。1 つの OVO 管理
サーバーに対応しているすべてのポリシー ( テンプレート ) は通常、この管理サーバーによって
のみ変更できます。これは、2 つの異なる管理サーバーは名前が異なるために、同一のエージェ
ントにポリシーを分配するときに相互に干渉することはないということです。しかし、1 つの管
理サーバーが、もう 1 つの管理サーバーによって同一エージェントに配布されたポリシーに干渉
94
第4章
HTTPS ノード管理の概念
HTTPS ノードへの設定情報の配布
する場合があります。同じ名前のテンプレートが、2 番目のサーバーによって同一のエージェン
トに割り当てて配布されるときには、ポリシーの既存のインスタンスが最初に削除され、新しい
所有者文字列で再び配布されます。もし必要であれば、エージェントにある opc 名前空間の
OPC_POLICY_OWNER 設定を使って、所有者文字列を手動で上書きすることもできます。所有者文
字列は次のとおりです。
OVO:<server_full_qualified_name>
第4章
95
HTTPS ノード管理の概念
HTTPS ノードのハートビートポーリング
HTTPS ノードのハートビートポーリング
HTTPS ノードと DCE ベースノードのハートビートポーリング (HBP) は非常に似ています。
OVO 管理対象ノードのハートビートポーリングは、OVO リクエストの送信プロセス
ovoareqsdr によって起動され、次の 3 つのフェーズに分けて実行されます。
•
リクエスト送信プロセス ovoareqsdr が対象ノードに ping パッケージを送信して、そのノー
ドにアクセスできるかどうかをチェックする
•
HTTPS エージェントの通信ブローカをポーリングする
•
OV Control RPC サーバーにリクエストする
注記
途中に ICMP フィルターが有効になっているファイアウォールがある場合は、
RPC_only モードを使って ping フェーズを省略することにより、そのファイア
ウォールを通過することができます。ただし、RPC_only モードではチェックがあ
まくなり、問題発生時にエラーメッセージから得られる詳細情報も減ります。
ポーリングの間隔は、ノードごとに異なる値を設定できます。
HTTPS ノードと DCE ベースノードの HBP エラーメッセージは非常に似ています。たとえば、
DCE ベースエージェントに対するメッセージ DCE rpcd is down は、HTTPS エージェントの
communication broker is down に対応し、同じエラー番号が割り当てられています。
注記
HTTPS ノードのハートビートポーリングでは、SSL を使いません。これは、
CPU の負荷を減らすためです。
ネットワークの負荷と CPU の負荷の軽減
ハートビートポーリングには、agent_sends_alive_packages というオプションがあります。
このオプションを有効にすると、エージェントは OVO 管理サーバーへ定期的に ping パッケー
ジを送信して、自分が正常に動作していることを知らせます。一方で OVO 管理サーバーでは、
その周期内にアライブパッケージを受信しなかった管理対象ノードが 1 つでもあると、そのとき
にだけポーリングを開始します。
96
第4章
HTTPS ノード管理の概念
HTTPS ノードのハートビートポーリング
このように、サーバーは、アライブパッケージが非常に少なく、しかも障害が発生したと考えら
れる場合にだけ、積極的にその役割を果たします。そのため、この方法を使うと、ネットワーク
と CPU の負荷が著しく軽減されます。この機能は、管理対象ノードと OVO 管理サーバーとの
間にファイアウォールがない大規模な環境を管理する場合に、非常に有利です。
第4章
97
HTTPS ノード管理の概念
HTTPS ノードのリモート制御
HTTPS ノードのリモート制御
OVO 管理サーバーからのエージェント制御は、opcragt ユーティリティを使って行います。サ
ポートされているどの操作も、HTTPS ノードと非 HTTPS ノードで同時に実行できます。これ
らの操作には、起動、停止、ステータス取得、一次マネージャの切替え、設定変数の取得と設
定、そして設定の分配があります。
HTTPS ノードには、opcagt というラッパーがあります。このユーティリティを使うと、オペ
レータのデスクトップからアプリケーションを起動するだけでリモート制御の作業を実行できま
す。またこのユーティリティでは、どの OVO 管理対象ノードに対してもその種類に関係なく適
用できる、共通のアクション定義をセットアップすることができます。
opcragt -status の出力形式は、他の opcragt と同様に、HTTPS ノードと DCE ベースノー
ドでよく似ています。エラーメッセージもとてもよく似ています。
サブエージェントは、HTTPS ノードでは名前で、DCE ノードでは番号で識別されます。そのた
め、次に示す設定ファイルの中に、別名を指定することもできます。
/etc/opt/OV/share/conf/OpC/mgmt_sv/subagt_aliases
別名の指定形式は、次のとおりです。
<alias>
<maps_to>
項目として 1 EA と 12 CODA が事前に定義されています。HTTPS ノードでは、自動的に -id 1
が -id EA と変換されるため、コマンドを次のように入力します。
opcragt -status -id 1 <BBC_nodes_and_DCE_nodes_list>
98
第4章
5 HTTPS ノードでの作業
第5章
99
HTTPS ノードでの作業
HTTPS ノードの設定
HTTPS ノードの設定
HTTPS ノードは、DCE-RPC ベースノードや NCS-RPC ベースノードと同じように設定しま
す。設定には、OVO Administrator のユーザーインタフェースにある [ ノードの追加 ]、[ ノード
の変更 ]、[ ノードのコピー ] の各ウィンドウまたは opcnode(1m) と [ ノード通信オプション ]
ウィンドウと [ ノードの拡張オプション ] ウィンドウを使います。
HTTPS ノードを作成するには、OVO の管理者となって、次の手順を実行します。
•
サポートされているプラットフォームに対して、新しい通信タイプ HTTP-Based を指定しま
す。
•
ノードの IP アドレスを静的にするか、DHCP を使って動的に割り当てるかを指定します。
147 ページの「DHCP クライアントシステム上での HTTPS エージェントの管理」を参照し
てください。
注記
通信タイプを DCE から HTTPS に変更する場合は、DCE エージェントソフト
ウェアは自動的に削除されます。ローカル設定やランタイムデータ (opcinfo
ファイル設定、ECS データとファクトストア、組み込みパフォーマンスコンポー
ネントデータベースファイルなど ) は、変換され HTTPS エージェントで再使用
されます。
HTTPS 通信のセキュリティは、証明書を使って実現します。そのため、HTTPS エージェント
のインストールでは次のような追加手順を実行する必要があります。
1. [ ノードの追加] ウィンドウを使って、管理対象ノードに OVO HTTPS エージェントソフトウェ
アをインストールします。インストールが終了すると、ノードは OVO 証明書サーバーに証
明書リクエストを自動的に送信します。OVO 証明書サーバーは、その証明書リクエストを
自動的に承認します。自動承諾機能が無効にされている場合、次の 2 つの手順を実行する必
要があります。
2. [OVO ノード証明書リクエスト ] ウィンドウから、証明書を承諾するノードを選択します。
3. 選択したノードに対して証明書リクエストを承諾します。
証明書を承諾したノードが保持エリア (Holding Area) ( デフォルト )、または名前空間
opc の設定情報 OPC_CSA_LAYOUT_GROUP で指定されているレイアウトグループに追加され
ます。
100
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
HTTPS ノードへの OVO ソフトウェアの自動インストール
OVO ソフトウェアのインストールは、図 5-1 に示す [ ノードの追加 ] ウィンドウを使って制御し
ます。
図 5-1
第5章
HTTPS ノードのための [ ノードの追加 / 変更 ] ウィンドウ
101
HTTPS ノードでの作業
HTTPS ノードの設定
注記
Windows には、UNIX のようなブート起動システムはありません。Windows で
ユーザーログインとは無関係に ovcd を起動するには、ovcd をサービスとして登
録しておく必要があります。エージェントをインストールすると、
START_ON_BOOT のデフォルト値に従って、サービスのスタートアップの種類が自
動または手動に設定されます。したがって、その後に START_ON_BOOT フラグを
変更しても、ovcd サービスの登録には反映されません。
Windows の場合は、サービスの起動を次の手順に従って手作業で変更する必要が
あります。
1. [ スタート -> 設定 -> コントロールパネル -> 管理ツール -> サービス] を選択しま
す。
2. [HP OpenView Ctrl Service] をダブルクリックし、[ プロパティ] ウィンドウ
の [ 全般 ] タブで、必要な [ スタートアップの種類 ] を設定します。
この設定は、次の作業を行う時にも指定できます。
GUI を使ったエージェントのインストール
この場合は、管理対象ノードを登録ノードに追加する際に [ ノードの追加 ] ウィン
ドウで [ システムリソースファイルを自動アップデート ] オプションを指定するこ
とができます。Windows ノードでこのオプションを指定すると、ovcd 制御サー
ビスの起動方法が自動として登録され、エージェントはリブート時に自動的に起
動されるようになります。このオプションを指定しないと、ovcd サービスは起動
方法が手動として登録されます。その場合、エージェントは、リブートを行なう
たびに手作業で起動する必要があります。
手作業によるエージェントのインストール
この場合は、opcactivate を使って -nb オプション ( またはそれに同値なオプ
ション ) を指定します。この方法でも、OVO GUI で [ システムリソースファイル
を自動アップデート ] を指定した場合と同じ効果が得られます。
エージェントをインストールする時に指定した設定情報は、OVO では変更できま
せん。これらの設定情報を変更するには、Windows のコントロールパネルを使い
ます。
102
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
注記
Windows では、エージェントのインストールスクリプト opc_inst.vbs を実行
するとログファイル opc_inst.log が作成され、そこにインストールの手順と結
果が自動的に記録されます。ただし、インストールスクリプトの実行中は、イン
ストールを実行しているユーザー ( デフォルトは Administrator) の %TMP% にロ
グが記録されます。
一時ファイルに記録されたログは、インストールが正常に終了した時、
<OVInstDir>¥data¥log へコピーされます。
注記
管理サーバーでは、インストール時に管理対象ノードへ配布する設定を定義でき
ます。多くのノードで使われる、通信ポートや http プロキシの設定などの基本的
パラメータが、この方法で定義できます。この方法は、通常以下の状況で使用し
ます。
•
サブネットやドメインに多くの OVO エージェントをインストールする必要が
ある場合。ファイアウォールの制限によって、通信ブローカのデフォルト
ポート (383) を使うことができなく、エージェントのインストール時に、各
ノードで手作業で通信ブローカポートを設定することを避けたい場合。
•
サブネットやドメイン内のノードが多くの設定を共有するため、中央拠点で
管理対象ノードのインストール時のデフォルトを設定する場合。
•
ファイアウォールを越えた位置にあるサブネットでは、OVO エージェントは
手作業でインストールします。インストールの共通部分は自動化できます。
これらの共通設定は、OVO 管理サーバー上の次のファイルに保存しておくことが
できます。
/etc/opt/OV/share/conf/OpC/mgmt_sv/bbc_inst_defaults
パラメータの設定方法の例が示されているサンプルの設定ファイルが次の場所に
用意されています。
/etc/opt/OV/share/conf/OpC/mgmt_sv/bbc_inst_defaults.sampl
bbc_inst_defaults.sampl のコピーを作成し、それを bbc_inst_defaults と
名前を換えて、サンプルファイルで示されている構文に従って変更します。
第5章
103
HTTPS ノードでの作業
HTTPS ノードの設定
注記
新しいノードに特定の OvCoreId を割り当てる場合には、エージェントソフト
ウェアをインストールする前に、手作業で次のようにして OvCoreId を追加しま
す。
OVO 管理サーバー上で、次のコマンドのどちらかを入力します。
opcnode -chg_id ... id=<id>
または
opcnode -add-node ... id=<id>
エージェントのインストール時に、指定した管理対象ノードには、OVO データ
ベースに格納されている OvCoreId が割り当てられます。
多くの管理サーバーによって管理されるノードを再インストールする場合には、
この手順を推奨します。元の OvCoreId を再使用することによって、すべての
OVO 管理サーバーを更新する必要がなくなります。
証明書を手作業でインストールする場合には、エージェントをインストールする
前に、OvCoreId の生成、証明書の作成、新しい OvCoreId を持つノードをデー
タベースに追加するなど、すべての準備作業を OVO 管理サーバーで行っておく
必要があります。これらの作業を完了した場合にのみ、エージェントソフトウェ
アを管理対象ノードにインストールすることができます。最後に証明書を管理対
象ノードにコピーする必要があります。
注記
HTTPS エージェントは通常、SYSTEM アカウントで実行されます。HTTPS エー
ジェントを インストールサーバーで実行している場合は、別のノードにアクセス
できなければなりません。SYSTEM アカウントを使った場合、これは不可能です。
インストールサーバーを使って、Windows エージェントのソフトウェアをインス
トールする場合、インストールサーバーとして動作している OVO エージェント
は、SYSTEM ( デフォルト ) として実行できません。この場合、エージェントを、
通常の Windows 認証方法で管理対象ノードの管理者用ドライブにアクセスでき
るユーザーアカウントで実行する必要があります。 これは通常次のいずれかの方
法で行ないます。
104
•
ドメイン管理者
•
Windows パススルー 認証 が使用可能 ( 両方のノードでユーザー / パスワード
が同一 )。
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
ovswitchuser コマンドを使って、インストールサーバーとして動作している
OVO エージェントが使用するユーザーアカウントを変更します。
ovswitchuser コマンドは通常、Windows の HTTPS エージェントではサポート
されていません。Windows の HTTPS エージェントは、インストールサーバーと
して使用されていない場合には、SYSTEM アカウントで実行しなければなりませ
ん。
OVO のソフトウェアを自動的にインストールするには、次の手順を実行します。
1. [OVO 登録ノード ] ウィンドウのメニューバーから、次のように選択します。
[ アクション : ノード -> 追加 ]
[ ノードの追加 ] ウィンドウ ( 図 5-1 を参照 ) が表示されるので、以降のステップに従って情
報を入力します。
2. システムの識別に使うラベルを入力します。
3. システムのホスト名を入力します。
4. 指定した HTTPS ノードの IP アドレスを動的に取得する場合は、[IP アドレス] の隣にある [ シ
ステムは IP を動的に取得する (DHCP)] ボックスにチェックを入れます。このチェックボッ
クスは、DHCP を使ってノードの IP アドレスを取得する場合に便利です。ノードの IP アド
レスを手作業で変更するか [ システムは IP を動的に取得する (DHCP)] を選択するかはシス
テムごとに違いますが、どちらの場合でも、その変更は OVO でも更新されます。DHCP の
使用を選択すると、OVO は管理対象ノードの IP アドレスの変更を自動的に処理します。こ
の処理で問題が発生することはないので、メッセージが紛失するということも、状態が乱れ
たり分からなくなったりするということもありません。
注記
[ システムは IP を動的に取得する (DHCP)] は、HTTPS ノードだけでサポート
されます。ホスト名の動的変更はサポートされません。
5. 管理対象ノードのタイプを選択します。[OVO 管理対象 ] がデフォルトです。
[ 管理対象ノードのタイプ ] も [ ノードデフォルト ] ウィンドウからアクセスできます。
注記
第5章
自動起動のアクションは、タイプがモニター対象になっている管理対象ノード
で実行されます。一方、オペレータ起動のアクションは、タイプがモニター
対象になっている管理対象ノードでは実行されません。
105
HTTPS ノードでの作業
HTTPS ノードの設定
注記
ノードのタイプとして [ メッセージ対象 ] を選択すると、そのノードにはソフ
トウェアとインストルメンテーションが分配されません。
HTTPS ノードの [ 管理対象ノードのタイプ ] を変更しても、nodeinfo ファイ
ルは管理対象ノードに分配されません。しかし、すべてのノードタイプを
[OVO 管理対象 ] から [ メッセージ対象 ] または [OVO 非管理対象 ] に変更する
と、ovcd 以外のエージェントプロセスがすべて停止します。
6. ハートビートポーリングの設定を入力します ( オプション )。
7. OVO 環境に管理対象ノードを追加するときは、[ インストール / 削除を自動化 ] オプションを選
択します ( オプション )。
[ ノード通信オプション ] ウィンドウから、表示されたノードで使う通信タイプと設定値を入
力します。このウィンドウにアクセスするには、[ ノードの追加 ]、[ ノードの変更 ]、または
[ ノードのコピー ] の各ウィンドウにある [ 通信オプション ...] ボタンをクリックします。
図 5-2
[ ノード通信オプション ] ウィンドウ
HTTPS 管理対象ノードの場合は、[ 通信タイプ ] として [HTTPS] が表示されます。また、参
考情報として一意な ID が [OVCoreID] フィールドに表示されます。
106
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
通信タイプを [HTTPS] から別の通信タイプに変えたり、その逆の変更を行ったりすると、そ
のノードのプラットフォームが自動的に変更され、新しく選択した通信タイプにだけ関連し
ている値はそのノードからすべて削除されてしまいます。
新しいノードのデフォルトの通信タイプは [HTTPS] です。HTTPS ベースのプラットフォーム
に SNMP ベースのエージェントプラットフォーム自動検出機能がある場合は、新しく追加
するノードに対して常にその機能が選択されます。
ノードのプラットフォームを変更するときは、必要に応じて、すべてのノードオプション、
通信オプション、および拡張オプションを今までの設定のままにします。このように既存の
設定を継承し、またモニタリングビューも特別なことがない限り同じにすることで、ノード
の管理を HTTPS ベースの管理に変更する作業が簡単になります。
Microsoft Windows で動作するノードでは、エージェントソフトウェアのインストール先
ルートディレクトリを、HTTPS エージェント用に設定することができます。
注記
HTTPS ノードについては、ログディレクトリや最大ログサイズをカスタマイ
ズできません。これは、HTTPS ノードの OpenView ではファイルシステム
のレイアウトとロギングのメカニズムが新しくなっているためです。
8. 対象となるノードが HTTPS ベースの高可用性クラスタシステムで構成する仮想ノードである
場合は、[ ノードの拡張オプション ] ウィンドウの [ クラスタ仮想ノード ] セクションでその情
報を必要であれば指定します。このウィンドウにアクセスするには、そのノードの [ ノード
の追加 ]、[ ノードの変更 ]、または [ ノードのコピー ] の各ウィンドウにある [ 拡張オプション
...] ボタンをクリックします。
HTTPS ノードとして管理するノードが複数のシステムから構成される仮想マシンである場
合には、[ クラスタ仮想ノード ] ボックスにチェックを入れるとともに、クラスタとその構成
要素システムに必要な情報を入力します。
必須フィールドに、クラスタを識別するためのクラスタの HA リソースグループ名を入力し
ます。
[ 追加 ] ボタンをクリックして、クラスタパッケージを構成する物理システムを [ クラスタ仮
想ノード ] 情報に追加します。
注記
第5章
仮想ノードに対しては、OVO 管理サーバー機能と 1 つのエージェント機能が
使えます。エージェントの機能として使えるのは、仮想ノードへポリシーと
インストルメンテーションを分配する機能だけです。ポリシーとインストル
メンテーションは、仮想ノードを構成するすべての物理ノードへ自動的に分
配されます。
107
HTTPS ノードでの作業
HTTPS ノードの設定
次のオプションは、仮想ノードに対しては使えません。
108
•
nodeinfo と mgrconf の分配
•
[ エージェントがアライブパケットを送信 ]
•
すべてのソフトウェアインストールとその関連オプション
•
ノードタイプ [ メッセージ対象 ]
•
[ バッファーサイズ制限 ]
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
注記
図 5-3
HTTPS ノードの文字コードセットは常に Unicode に設定されます。
[ ノードの拡張オプション ] ウィンドウ
OVO ソフトウェアを管理対象ノードにインストールしたときは、HTTPS 通信に必要な証明書
が作成されて分配されていることを確認してください。特に指定しなくても、証明書は自動的に
生成されます。証明書の作成と分配の手順は 150 ページの「証明書の作成と分配」で説明されて
います。
第5章
109
HTTPS ノードでの作業
HTTPS ノードの設定
DCE エージェントから HTTPS エージェントへの移行
警告
OVO エージェントソフトウェアのメジャーバージョンは、OVO 管理サーバーの
メジャーバージョン以下である必要があります。たとえば、OVO バージョン
A.08.10 の HTTPS エージェントは、OVO バージョン A.07.1x の管理サーバーと
は通信できません。
A.07.1x 管理サーバーと A.08.10 管理サーバーを持つフレキシブル管理環境で運
用している場合には、すべての管理サーバーを OVO バージョン A.08.10 にアッ
プグレードするまでは、すべての OVO エージェントはバージョン A.07.1x のま
までご利用ください。
注記
OVO 7.1 エージェントを HTTPS エージェントにアップグレードすると、
opcinfo ファイルが変換されます。opcinfo ファイルのコピーは、ローカルの
/tmp/opcinfo.save ファイルに保存されます。
DCE エージェントを HTTPS エージェントに移行するには、以下の手順を実行します。
1. OVO 管理サーバーで、次の手順を実行します。
エージェントのプロファイル生成の準備として、inst_defaults_base.ini ファイルが
ノードに対して適切に設定されているかを確認します。この手順は、サブネットまたはドメ
イン全体で、一度しか実行する必要がありません。
2. [ 登録ノード ] から、ノードを選択します。
[OVO 登録ノード ] ウィンドウの管理者 UI のメニューバーで、次のように操作して、[ ノード
の変更 ] ウィンドウ ( 図 5-1 を参照 ) を開きます。
[ アクション : ノード -> 変更 ]
[ ノードの変更 ] ウィンドウで、エージェントタイプを選択します。たとえば MS Windows
(HTTPS) です。
3. 次のメニュー項目を選択して、新しいエージェントソフトウェアをインストールします。
[ アクション : エージェント -> ソフトウェアと設定のインストール / 更新 ]
テンプレート、アクション、コマンド、およびモニターは、[OVO ソフトウェアと設定のイン
ストール / 更新 ] で選択した場合に、管理対象ノードシステムに再インストールされます。
110
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
DCE エージェントを削除するかどうかを確認するプロンプトが表示されたら、そのプロン
プトを承諾して、HTTPS エージェントのインストールを継続します。
ローカル DCE に固有のエージェント設定は、自動的に HTTPS エージェントのフォーマッ
トに変換されます。これには、opcinfo の設定、ECS のデータストアとファクトストア、組
み込みパフォーマンスエージェントデータベースファイルが含まれます。
4. リモートノードへのエージェントソフトウェアのインストールが終了したら、インストール
ステータスを以下のいずれかのコマンドで確認します。
•
管理対象ノードシステムでは、次のコマンドを実行します。
ovc -status
•
OVO 管理サーバーシステムでは、次のコマンドを実行します。
opcragt -status <nodename>
メッセージブラウザに配布が正常終了したことを示すメッセージが表示されます。
第5章
111
HTTPS ノードでの作業
HTTPS ノードの設定
MoM 環境でのアップグレード
MoM 環境でのアップグレードは、2 段階の手順で構成されます。
•
OVO 管理サーバーを OVO 8.1 にアップグレード
•
管理対象ノードを OVO 8.1 HTTPS エージェントにアップグレード
以下の手順を実行して、OVO 7.x MoM 環境を OVO 8.1 MoM 環境にアップグレードします。
1. 少なくとも 1 つの OVO 7.x 管理サーバーを OVO 8.1 管理サーバーにアップグレードします。
2. 110 ページの「DCE エージェントから HTTPS エージェントへの移行」での説明に従って、
DCE エージェントを HTTPS エージェントに移行します。
注記
OVO 7.x 管理サーバーは HTTPS エージェントをサポートしないので、移行
したシステムの管理はできません。
3. opccfgdwn ユーティリティを使って最初の OVO 8.1 管理サーバーから設定データをダウン
ロードします。詳細は、『HP OpenView Operations 管理サーバーインストールガイド』の
「現在の OVO A.07.1x 設定のダウンロード」を参照してください。
4. opccfgupld ユーティリティを使ってダウンロードした設定データを 2 番目以降の OVO 8.1
管理サーバーにアップロードします。詳細は、『HP OpenView Operations 管理サーバーイ
ンストールガイド』の「保存した OVO A.07.1x 設定のアップロード」を参照してください。
5. データベースに HTTPS エージェントのインストールフラグを設定します。このフラグが設
定されていない場合、アップロードされたノードがハートビートポーリングリストに自動的
に追加されないため、ハートビートポーリングと設定ファイルの分配を実行する際に問題が
発生します。
次のコマンドを実行します。
opcsw -i <https_node_name>
6. 手順 4 と 5 を他のすべての OVO 8.1 管理サーバーで実行します。
7. 2 つ以上のマネージャ間に信頼関係を確立し、環境間で相互に通信が行えるようにします。
60 ページの「2 番目の OVO 管理サーバーにおける証明書の取り扱い」で説明されている手
順を完了させます。
8. HTTPS ノード用の担当マネージャファイルを作成し、それをエージェントに配布します。
/etc/opt/OV/share/conf/OpC/mgmt_sv/respmgrs/allnodes.bbc
112
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
このファイルが存在する場合、このファイルの優先度は allnodes ファイルより高く、
HTTPS ノードの <hex_IP_addr> ファイルより低くなります。このファイル は、テンプ
レートと共に配布される allnodes ファイルと同じ方法でポリシーと共に自動的に配布され
ます。
allnodes.bbc は、空か allnodes ファイルの設定のサブセットだけが含まれます。空の
allnodes.bbc ファイルは、MoM 設定が HTTPS ノードに配布されていないこと、および
所有者が設定を最初に配布した管理サーバーと同じ場合には、すでに配布済みの MoM 設定
が削除されていることを意味しています。担当マネージャファイルで指定された、HTTPS
ノードと関連するすべての OVO 管理サーバーシステムは通信タイプとして HTTPS を使用
し、OvCoreId を持つ必要があります。
第5章
113
HTTPS ノードでの作業
HTTPS ノードの設定
HTTPS エージェントの DCE エージェントへの移行
注記
OVO 7.1 エージェントを HTTPS エージェントにアップグレードすると、
opcinfo ファイルは変換が行われます。opcinfo ファイルのコピーは、ローカル
の /tmp/opcinfo.save ファイルに保存されます。
しかし、HTTPS エージェントを DCE エージェントへ移行する場合には、設定情
報の opcinfo ファイルへの変換は行なわれません。eaagt 名前空間の設定情報を
取得して、その情報のコピーを作成する必要があります。このデータは HTTPS
エージェントを削除する前に、次のコマンドを実行すると表示されます。
ovconfget
DCE エージェントをインストールしたら、設定情報を手作業で opcinfo ファイ
ルに書き込み、各キーと値の間にある等号 = を削除します。
HTTPS エージェントを DCE エージェントへ移行するには、以下の手順を実行します。
1. HTTPS エージェントを DCE エージェントへ移行するときには、設定情報の opcinfo ファ
イルへの変換は行なわれません。
このデータは HTTPS エージェントを削除する前に、次のコマンドを実行して表示します。
ovconfget
eaagt 名前空間の設定情報を取得して、その情報のコピーを作成する必要があります。
2. [ 登録ノード ] からノードを選択します。
[OVO 登録ノード ] ウィンドウの管理者 UI のメニューバーで、次のように操作して、[ ノード
の変更 ] ウィンドウ ( 図 5-1 を参照 ) を開きます。
[ アクション : ノード -> 変更 ]
[ ノードの変更 ] ウィンドウで、エージェントタイプを選択します。たとえば MS Windows
(HTTPS) です。
3. 次のメニュー項目を選択して、新しいエージェントソフトウェアをインストールします。
[ アクション : エージェント -> ソフトウェアと設定のインストール / 更新 ]
テンプレート、アクション、コマンド、およびモニターは、[OVO ソフトウェアと設定のイン
ストール / 更新 ] で選択した場合に、管理対象ノードシステムに再インストールされます。
114
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
HTTPS エージェントを削除するかどうかを確認するプロンプトが表示されたら、そのプロ
ンプトを承諾して、DCE エージェントのインストールを継続します。
4. DCE エージェントをインストールしたら、HTTPS のインストールを基に設定情報を手作業
で opcinfo ファイルに書き込み、各キーと値の間にある等号 = を削除します。
5. リモートノードへのエージェントソフトウェアのインストールが終了したら、インストール
ステータスを以下のいずれかのコマンドで確認します。
•
管理対象ノードシステムでは、次のコマンドを実行します。
ovc -status
•
OVO 管理サーバーシステムでは、次のコマンドを実行します。
opcragt -status <nodename>
メッセージブラウザに配布が正常終了したことを示すメッセージが表示されます。
第5章
115
HTTPS ノードでの作業
HTTPS ノードの設定
手作業によるエージェントのインストール
状況によっては、OVO HTTPS エージェントソフトウェアを管理サーバーを使わずにインス
トールしたい場合があります。たとえば、手作業で事前にインストールしたシステムを準備して
おき、ネットワークにそのシステムを接続した段階で OVO の管理対象ノードとするというよう
なケースです。手作業によるインストールは、多くのシステムを特定の場所で集中的に用意した
り、通常のインストールとは違うネットワーク接続を設定したりする場合に便利です。また、シ
ステムがファイアウォールや HTTP プロキシの背後にあって、手作業でしかインストールでき
ないというケースもあります。
証明書をインストールするためのヒント
エージェントをインストールしたノードでは、OVO 管理サーバーの登録ノードリストにまだ追
加していない段階でも、証明書リクエストを発行できます。しかしこの段階で証明書リクエスト
を発行しても、登録ノードリストでどのノードにも自動的にはマップできないため、[ ノード証
明書リクエスト ] ウィンドウの証明書リクエストリストで保留扱いとなります。
[OVO ノード証明書リクエスト ] ウィンドウで [ 証明書リクエスト ] を選択した後、[ 登録ノードへ
ノードを追加 ] ボタンをクリックすることで、保持エリアにそのノードを追加できます。その場
合 [ ノードの追加 ] ウィンドウが開くので、フィールドを編集して、そのノードを保持エリアに
追加します。証明書リクエストは自動的にノードへマップされますが、この段階ではまだ承諾さ
れません。証明書リクエストの承諾は、管理者が必要に応じて手作業で行う必要があります。
証明書リクエストが承諾されると、証明書サーバーは証明書に署名して証明書クライアントに送
ります。証明書クライアントはここまできてはじめて証明書をノードにインストールできます。
注記
手作業によるエージェントインストールでは、タイプとしてリモート証明書分配
を使うことができます。
リモート証明書分配または手作業によるインポートで証明書をノードにインストールした後、証
明書クライアントから証明書サーバーに対して、証明書が正常にインストールできたことが知ら
されます。この知らせを受け取った証明書サーバーは、そのことを証明書サーバーアダプタに知
らせます。その時点で、証明書サーバーアダプタはデータベースで管理しているノード証明書の
状態をインストール済みに設定します。
証明書の詳細な処理方法は、150 ページの「証明書の作成と分配」を参照してください。
証明書の処理に関するトラブルシューティング は、201 ページの「証明書分配中に発生する問
題」を参照してください。
116
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
エージェントをパッケージファイルから手作業でインストールする方法
OVO 管理対象ノードとして管理するシステムに OVO HTTPS エージェントをインストールする
には、次の手順を実行します。
1. OVO エージェントパッケージ、インストールスクリプト、およびパッケージの説明を管理
対象ノードの一時ディレクトリにコピーします。
OVO 管理サーバーに必要なファイルは、次のとおりです。
•
HPOvBbc.<platform>
HPOvBbc.xml
•
HPOvConf.<platform>
HPOvConf.xml
•
HPOvCtrl.<platform>
HPOvCtrl.xml
•
HPOvDepl.<platform>
HPOvDepl.xml
•
HPOvEaAgt.<platform>
HPOvEaAgt.xml
•
HPOvPCO.<platform>
HPOvPCO.xml
•
HPOvPacc.<platform>
HPOvPacc.xml
•
HPOvPerlA.<platform>
HPOvPerlA.xml
•
HPOvSecCC.<platform>
HPOvSecCC.xml
•
HPOvSecCo.<platform>
HPOvSecCo.xml
•
第5章
HPOvXpl.<platform>
117
HTTPS ノードでの作業
HTTPS ノードの設定
HPOvXpl.xml
•
opc_inst (UNIX の場合 ) または opc_inst.vbs (Windows の場合 )
以下は、オプションの言語パッケージです。
•
HPOvLcja.<platform>
HPOvLcja.xml
•
HPOvEaAja.<platform>
HPOvEaAja.xml
•
HPOvEaAes.<platform>
HPOvEaAes.xml
•
HPOvEaAko.<platform>
HPOvEaAko.xml
•
HPOvEaAzS.<platform>
HPOvEaAzS.xml
.xml ファイルはすべてのアーキテクチャに共通です。
サポートされているプラットフォームのデポファイルには、プラットフォームを示すための
固有な拡張子 <platform> が付いています。<platform> の値は、次のとおりです。
depot.Z
HP-UX ノード用のファイル
sparc.Z
Solaris ノード用のファイル
rpm.gz
Linux ノード用のファイル
msi
Windows ノード用のファイル
これらのファイルは、管理サーバーの次のディレクトリにあります。
/<OvDataDir>/share/databases/OpC/mgd_node/vendor/ ¥
<vendor>/<newarch>/<ostype>/A.08.10.xx/RPC_BBC/
<vendor>/<newarch>/<ostype> の具体的な例を次に示します。
hp/pa-risc/hpux1100
hp/ia64-32/hpux1122
118
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
ms/x86/winnt
ms/ipf64/winxp
linux/x86/linux24
linux/ipf64/linux24
sun/sparc/solaris7
2. デフォルトプロファイルの作成
デフォルトプロファイルは次のコマンドを実行して作成する必要があります。
opcsw -create_inst_info <nodenames>
<nodenames> に指定された各ノードに対して、次のファイルが作成されます。
/var/opt/OV/share/tmp/OpC/distrib/<hex_IP_addr>.i
このファイルには、IP アドレスが <hex_IP_addr> であるノードのインストール時のデフォ
ルトが含まれます。このファイルはリモートエージェントのインストール (inst.sh) 時に自
動的にターゲットノードへコピーされます。また、手作業のエージェントインストールで使
うこともできます。
ノードを OVO データベースに追加した後で、<hex_IP_addr>.i プロファイルファイルを管
理対象ノードシステムにコピーします。プロファイルを有効にするには、次のコマンドのい
ずれかを実行します。
opc_inst -config <hex_IP_addr>.i
または
opcactivate -config <hex_IP_addr>.i
設定は local_settings に格納され、DCE ノードの opcinfo 設定と同様に、高い優先順位
を持ちます。
これらの共通設定は OVO 管理サーバーの次のファイルに保存しておくことができます。
/etc/opt/OV/share/conf/OpC/mgmt_sv/bbc_inst_defaults
パラメータの設定方法の例が記述されたサンプル設定ファイルは、次の場所にあります。
/etc/opt/OV/share/conf/OpC/mgmt_sv/bbc_inst_defaults.sampl
bbc_inst_defaults.sampl のコピーを作成し、それを bbc_inst_defaults と名前を換え
て、サンプルファイルで説明されている構文に従って変更します。
3. エージェントをインストールします。
第5章
119
HTTPS ノードでの作業
HTTPS ノードの設定
パッケージをコピーした一時ディレクトリに移り、次のコマンドを実行します。
UNIX システムの場合 :
a. エージェントインストールスクリプトのパーミッションを変更して、実行できるように
します。
chmod +x ./opc_inst
b. 次のコマンドを入力して、エージェントインストールスクリプトの実行を開始します。
./opc_inst -srv <management_server_name>
Windows システムの場合 :
次のコマンドを入力して、エージェントインストールスクリプトの実行を開始します。
opc_inst.vbs -srv <management_server_name>
opc_inst を使い、手作業でエージェントソフトウェアをインストールすることでも、ノー
ドをアクティブにできます。opc_inst ツールはバイナリをインストールした後、
opcactivate ツールを呼び出します。opcactivate は設定パラメータの初期値をいくつか
設定します。これ以外のアクティブ化の手順は不要です。
ノードシステムに対してエージェントのプリインストールだけ行っておき、設定は後で行う
というケースもあります ( たとえば、他部門が設定するような場合 )。このような場合は、
OVO 管理サーバーを指定しないで次のコマンドを実行します。
./opc_inst -no_start
このコマンドを実行するとエージェントソフトウェアはインストールされますが、エージェ
ントは起動しません。
ノードをアクティブにしてエージェントを起動するという必要が発生した時点で、次のコマ
ンドを実行します。
./opcactivate -srv <srv_name>
注記
OVO エージェントソフトウェアは、ノードを OVO ノードグループに追加し
た後でもインストールできます。
4. ノードのログファイルを調べます。
インストール中にエラーが発生していた場合は、その問題を解決して、インストールし直し
ます。エラー情報は、そのノードのネイティブインストーラのログファイルに書き込まれて
います。たとえば HP-UX の場合、ログファイルは次の場所にあります。
120
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
/var/adm/sw/swagent.log
またこれとは別に、opc_inst は、すべてのプラットフォームで次の場所にログファイルを
作成します。
/<OvDataDir>/log/install_bbc.log
5. OVO 管理サーバーで、プリインストールしたノードを [OVO 登録ノード ] ウィンドウに追加
します。
次のようにメニューを選択します。
[ アクション : ノード -> 追加 ]
6. OVO 管理サーバーで、OVO ノードグループにノードを追加します。
[OVO 登録ノードグループ ] ウィンドウのノードグループにノードをドラッグアンドドロップ
します。
または、
opcnode ツールを使います。
たとえば HP-UX 11 ノードの場合、次のコマンドを実行します。
/opt/OV/bin/OpC/opcnode -add_node mach_type=MACH_BBC_HPUX_PARISC ¥
net_type=NETWORK_IP group_name=<node_group> ¥
node_name=<node_name> node_label=<node_label>
詳細は、opcnode のマンページを参照してください。
7. データベースを更新して、ノードに対するハートビートポーリングを開始します。
ネットワークにノードを接続した後、次の手順を実行します。
OVO 管理サーバーで、コマンド行から次のコマンドを実行します。
/opt/OV/bin/OpC/opcsw -installed <node>
8. 管理対象ノードで OVO エージェントが動作していることを確認します。
次のコマンドを実行します。
/opt/OV/bin/OpC/opcragt -status <node>
注記
第5章
管理対象ノードには有効な証明書をインストールしておく必要があります。
証明書が無効であるとエージェントが動作しないので、確認できません。
121
HTTPS ノードでの作業
HTTPS ノードの設定
OVO に関連した変数の設定
注記
OVO 8.1 では、opcsvinfo ファイルを使いません。アップグレード中に次のディ
レクトリに格納されます。
/tmp/save710/
OVO 7.1 を OVO 8.1 にアップグレードしても、opcsvinfo ファイルは自動的に
は変換されません。opcsvinfo ファイルの内容を変換する場合には、そのファイ
ルを一時的な場所に格納し、次のツールを使ってください。
/opt/OV/contrib/OpC/opcinfoconv
opcinfo ファイルは、OVO 7.1 のエージェントを HTTPS エージェントへアップ
グレードする時に変換されます。そのコピーがローカルの /tmp/opcinfo.save
に格納されます。
OVO 管理サーバーで変数を設定するには、次の手順に従います。
1. 次のコマンドを入力します。
/opt/OV/bin/ovconfchg -ovrg server -ns opc -set <var_name> <value>
2. サーバープロセスを再起動します。
opcsvinfo ファイルにあった関連変数は、OVO 8.1 でもすべて使用します。OVO 8.1 のスキー
マでは名前空間を使う ( 上記の例で示されているパラメータ -ns) ので、opcsvinfo にあった以
前の変数はすべて、名前空間 opc を持つように変換されます。また、HTTPS ノード上では、
opcinfo/nodeinfo にある変数の名前空間が eaagt になります。ただし、DCE エージェントで
は、以前と同じように opcinfo ファイルを使います。
必要に応じて、名前空間には接尾辞としてプロセス名を付けることができます。たとえば、
DCE メッセージレシーバ opcmsgrd に対してポートを設定するには、次のコマンドを入力しま
す。
ovconfchg -ovrg server -ns opc.opcmsgrd -set OPC_COMM_PORT_RANGE 12345
OVO 管理サーバーで変数を読むには、次のコマンドを入力します。
/opt/OV/bin/ovconfget -ovrg server [ <namespace> [ <var_name> ] ]
このコマンドでは表示する対象として、すべての設定、名前空間のすべての設定、または 1 つの
変数を指定できます。
122
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
管理対象ノードの変数を読むには、-ovrg server オプションを指定しないで ovconfget コマ
ンドを実行します。
エージェント上で変数を設定するには、-ovrg server オプションを指定しないで ovconfchg
を実行します。
/opt/OV/bin/ovconfget [ <namespace> [ <var_name> ] ]
変数を削除するには、-clear オプションを指定して ovconfchg コマンドを実行します。
/opt/OV/bin/ovconfget -clear [ <namespace> [ <var_name> ] ]
ここでの説明以外にも、設定に関するドキュメントと例が次の場所に数多く置かれています。
/opt/OV/misc/xpl/conf/defaults/*.ini
第5章
123
HTTPS ノードでの作業
HTTPS ノードの設定
コピーイメージを使ったエージェントのインストール
同じようなノードを数多くインストールする場合は、代表的なノードの設定をコピーしたイメー
ジを作成し、そのイメージを基本にして他のノードのインストールに利用すると、作業がはかど
ります。
OVO では、次の 2 つのレベルでコピーイメージを作成すると便利です。
•
OVO 管理対象ノードにインストールされているエージェントソフトウェア
•
OVO 管理対象ノードにインストールされているエージェントソフトウェアとそのノードに
配布されたポリシー
コピーイメージには、コピー元ノードに固有な ID OvCoreId を含めないようにします。コピー
したすべてのノードに同じ ID が含まれていると手作業で修正しなければならないので、各ノー
ドを混乱することなく認識できるようになるまでに多くの労力が必要となります。
コピーイメージを使った OVO エージェントソフトウェアのインストールは、次の手順で行いま
す。
1. OVO をインストールし、コピー元ノードを設定します。
2. 次のコマンドを実行して、コピー元ノードの OvCoreID 値を削除します。
ovconfchg -ns sec.core -clear CORE_ID
3. 次のコマンドを実行して、コピー元ノードにインストールされている証明書をすべて表示し
ます。
/opt/OV/bin/ovcert -list
出力が次の形式で表示されます。
+----------------------------------------------+
| キーストアの内容
|
+----------------------------------------------+
| 証明書 :
|
| edb87a09-1511-75ff-13c1-f6aef454aa2b (*)
|
| edb...
|
+----------------------------------------------+
| 信頼できる証明書 :
|
| CA_edb66a23-1422-04ff-77c1-f1aef555aa1b
|
| CA_edb...
|
+----------------------------------------------+
4. 次のコマンドを実行して、コピー元ノードにインストールされている証明書をすべて削除し
ます。
/opt/OV/bin/ovcert -remove <certificate name>
124
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
次に例を示します。
/opt/OV/bin/ovcert -remove ¥
edb87a09-1511-75ff-13c1-f6aef454aa2b ¥
CA_edb66a23-1422-04ff-77c1-f1aef555aa1b
5. 証明書と OvCoreID 値のないシステムのコピーイメージを作成します。
6. 作成したイメージを新しいノードにコピーします。
7. 新しいノードで次のコマンドを実行し、新しい OvCoreID 値を作成します。
ovcoreid -create
注記
OvCoreID の値を削除していなかった場合は、-force オプションを使って上
書きする必要があります。
8. opcactivate コマンドを実行して、証明書リクエストを OVO 管理サーバーに送ります。
./opcactivate -srv <srv_name>
注記
第5章
コピー元ノードにポリシーがすでに配布されていた場合は、慎重に作業してくだ
さい。コピーイメージから作成した新しいノードの設定で、コピー元ノードを管
理している OVO 管理サーバーとは異なるサーバーへ報告するように指定すると、
元の OVO 管理サーバーの認証局が署名したポリシーは信頼性が失われてしまい
ます。これらのポリシーの信頼性を維持するには、新しいノードの mgrconf で、
元の OVO 管理サーバーのホスト名を二次マネージャとして追加します。
125
HTTPS ノードでの作業
HTTPS ノードの設定
ホスト名と IP アドレスの変更
1 つのノードに複数の IP アドレスとホスト名を割り当てて運用していることがよくあります。
ノードを別のサブネットのメンバーにするときは IP アドレスの変更が必要となりますが、その
場合は、IP アドレス、または完全修飾ドメイン名を変更します。
一般に HP-UX システムと Solaris システムでは、IP アドレスとそれに対応するホスト名の設定
を次のいずれかの方法で行います。
❏
/etc/hosts
❏
ドメインネームサービス (DNS)
❏
ネットワーク情報サービス (HP-UX では NIS、Solaris では NIS+)
ネームサーバーを使っていない環境からネームサーバーを使う環境 (DNS または BIND) に移行
した場合は、ネームサーバーから新しい IP アドレスにアクセスできることを確認してください。
ホスト名は、IP ネットワーク内で管理対象ノードを識別するために使います。1 つのノードに多
数の IP アドレスが割り当てられている場合は、ホスト名を使って特定のシステムを絞り込むこ
とができます。システムのホスト名は、UNIX の hostname(1) コマンドを使ったときに返され
る文字列です。
手作業による管理対象ノードのホスト名または IP アドレスの変更
注記
分散管理サーバー (MoM) 環境で OVO を運用している場合には、変更したノード
を制御またはモニターしているすべての管理サーバーシステムで、以下のように
手順を変更してください。
•
手順 1 ～ 9 は、変更したノードを制御またはモニターしているすべての管理
サーバーシステムで実行します。
•
手順 10 は、OVO テンプレート内で旧ホスト名を参照しているすべての OVO 管
理サーバーシステムで実行します。
注記
Service Navigator を使っている場合は、opcservice コマンド用のサービス設定
ファイルを確認してください。サービス設定ファイルにホスト名や IP アドレスが
含まれている場合は、opcservice を再起動する前に変更が必要なことがありま
す。詳細は、『HP OpenView Operations 管理サーバーインストールガイド』を参
照してください。
126
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
管理対象ノードのホスト名や IP アドレスを変更するには、以下の手順を実行します。
注記
ノードの IP アドレスを変更する予定がある場合は、IP アドレスを決めておくか、
またはノードを DHCP クライアントにする必要がありますが、ノード属性の設定
を「システムは IP を動的に取得する (DHCP)」にした方がはるかに安全で、便利
です。ただし、この属性を設定できるのは、HTTPS ノードのみです。
1. 新しい IP アドレスとホスト名が OVO 管理サーバー上で解決可能なことを確認します。
2. 新しいIPアドレスとホスト名が他のOVO管理対象ノードでまだ使われていないことを確認し
ます。
3. すべての OVO 管理サーバープロセスが動作していることを確認します。データベースプロセ
スについては、特に注意してください。
次のコマンドを入力して、OpenView プロセスを起動します。
ovc -start
ovstart ovacomm
opcsv -start
データベースが動作していない場合は、次のコマンドを実行して起動します。
/sbin/init.d/ovoracle start
4. OVO 管理対象ノードの IP アドレスまたはホスト名を変更します。
管理サーバーシステムで、変更するすべての管理対象ノードについて、OVO データベース
に登録されている管理対象ノードの IP アドレスまたはホスト名を変更します。
以下のいずれかの方法を使います。
❏
OVO の管理者 GUI を使う方法
OVO 管理者 GUI の [ ノードの変更 ] ウィンドウで IP アドレスまたはホスト名を変更し
ます。
•
IP アドレス
IP アドレスを変更するには、[ ノードの変更 ] ウィンドウを開き、[ ホスト名 ] フィー
ルドに新しい IP アドレスを入力して、Return を押します。新しい IP アドレスが
[IP アドレス ] オプションボックスに表示されます。
[OK] をクリックして、変更を保存します。
第5章
127
HTTPS ノードでの作業
HTTPS ノードの設定
•
ホスト名
ホスト名を変更するには、[ ノードの変更 ] ウィンドウを開き、[ ホスト名 ] フィール
ドに新しいホスト名を入力して、Return を押します。
[OK] をクリックして、変更を保存します。
注記
❏
変更後の IP アドレスとホスト名は、OVO 管理サーバーで解決できる必
要があります。
コマンド行を使う方法
IP アドレス / ホスト名を、コマンド行ツール opcchgaddr を使って変更します。この方
法は、ホスト名と IP アドレスが OVO 管理サーバー上で解決できない場合に使うようお
勧めします。
次のコマンドを実行します。
/opt/OV/contrib/OpC/opcchgaddr -sync -force -label ¥
<label> IP <old_addr> <old_name> IP <new_addr> <new_name>
-sync
ホスト名や IP アドレスの変更を、OVO のランタイムコンポーネント
と同期させます。
-force
ネームサービスを使いません。データベースに重複したホスト名が
あってもチェックしません。
-label <label> ノードのラベルを <label> に変更します。新しいラベルは [ 登録ノー
ド ] に表示されます。
<old_addr>
ノードの変更前の IP アドレス。
<new_addr>
( 名前を変更する ) ノードの変更後の IP アドレス。
<old_name>
ノードの変更前の名前。
<new_name>
( 名前を変更する ) ノードの変更後の名前。
このコマンドの詳細は、opcchgaddr(1M) のマンページを参照してください。
5. 管理サーバーシステムをそのままにして OVO 管理対象ノードについてのみ IP アドレスを変
更した場合は、その新しい IP アドレスが管理対象ノードに設定されていることを確認しま
す。
128
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
6. (DCE/NCS ノードでのみ行う手順 )。OVO 管理対象ノードのホスト名のみを変更した場合は、
最後の分配時にキャッシュしたテンプレートを、次のようにして削除し、OVO にテンプ
レートをデータベースから再度作成させます。
cd /etc/opt/OV/share/conf/OpC/mgmt_sv/templates
rm -f `find . -type f`
7. (DCE/NCS ノードでのみ行う手順 )。OVO 管理対象ノードのホスト名のみを変更した場合は、
次の手順を実行して、すべての管理対象ノードにテンプレートを再分配します。
a. メインウィンドウのいずれかで、[ アクション: エージェント->ソフトウェアと設定のイン
ストール / 更新 ] を実行します。
b. [OVO ソフトウェアと設定のインストール / 更新] ウィンドウで、[テンプレート]を選択し
ます。
c.
[ 強制アップデート ] と [ ノードリスト中で要アップデートのノード ] を選択します。
d. [ 登録ノード ] ウィンドウで管理対象ノードを選択し、[OVO ソフトウェアと設定のインス
トール / 更新 ] ウィンドウの [ マップ選択の取り込み ] をクリックします。
e.
[OK] をクリックします。
8. 次のコマンドを実行して、管理対象ノードのエージェントを再起動します。
/opt/OV/bin/OpC/opcragt -start <node_name>
9. ネットワークノードマネージャをアップデートします。
NNM では IP アドレスとホスト名の変更をすでに検出しているかもしれません。これは
NNM の設定やその他のタイミングによります。
管理サーバーで、ホスト名または IP アドレスを変更するすべての OVO 管理対象ノードに対
し、次の手順を実行します。
a. ping コマンドを実行し、OpenView の把握しているホスト名と IP アドレスを、変更した
ホスト名と IP アドレスにアップデートします。
ping <new_name>
b. 次のコマンドを実行して、OpenView のトポロジデータベースをアップデートします。
/opt/OV/bin/nmdemandpoll <new_name>
10. オペレータ用の GUI ブラウザを再ロードします。
第5章
129
HTTPS ノードでの作業
HTTPS ノードの設定
いずれかの OVO メインウィンドウで次のメニューオプションを使い、OVO の管理者用
GUI とオペレータ用 GUI を再起動します。
[ ファイル : セッションの再起動 ]
注記
Motif GUI を使って変更対象ノードを担当しているオペレータに対しては、
ノードが変更される前と後にその旨を知らせるポップアップメッセージが表
示されます。しかし、Motif GUI を使っていない場合は、ノードを変更して
も、ポップアップメッセージは表示されません。
JAVA GUI を使って変更対象ノードを担当しているオペレータに対しては、
変更を知らせるポップアップメッセージが表示されません。このようなオペ
レータには、信頼できる方法 ( たとえば、OVO メッセ－ジ ) を使って知らせる
必要があります。
管理対象ノードのホスト名または IP アドレスの自動的な変更
ここでの説明は、通信タイプが DCE/NCS または HTTPS で、管理対象ノードのタイプが「モニ
タ対象」
、
「OVO 管理対象」、または「メッセージ対象」のノードをカバーしています。ただし、
少し違う個所もあるので、注意してください。
この処理は複雑なので、それを簡単にするための新しいコマンド行ユーティリティが、OVO 管
理サーバーにいくつか用意されています。
注記
HTTPS エージェントソフトウェアを管理サーバーにインストールしておく必要
があります。
上述の手順 1 ～ 9 は、次のスクリプトで実行できます。
/opt/OV/bin/OpC/utils/opc_node_change.pl
このスクリプトを実行すると opc メッセージの送信も行われるので、オペレータはブラウザを手
作業で再ロードするのみで済みます。
opc_node_change.pl [-h[elp]|-?] ¥
-oldname OLD_FQDN -oldaddr OLD_IP_ADDR ¥
-newname NEW_FQDN -newaddr NEW_IP_ADDR[,NEW_IP_ADDR,...] ¥
[-nnmupdate -netmask 999.999.999.999 -macaddr XX:XX:XX:XX:XX:XX ¥
[-hook CMDNAME] [-nnmtopofix]]
130
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
NNM のアップデートが不要な場合 ( たとえば、NNM の機能を使っていない場合 ) は NNM を
アップデートしなくても問題はありませんが、不安であれば、-nnmupdate オプションを使って
ください。基本的な使い方は、OLD_FQDN ( 変更前の完全修飾ドメイン名 ) と OLD_IP_ADDR の値
として、管理サーバーに登録されているホスト名と IP アドレスを指定し、NEW_FQDN と
NEW_IP_ADDR の値として新しいホスト名と IP アドレスを指定するだけです。
NNM を更新する必要がある場合は、オプション -nnmupdate を指定する必要があります。この
オプションを使うときは、ノードのネットマスク情報とアダプタ /MAC アドレスの情報を指定す
る必要があります。MAC アドレスは、オプション -macaddr を使ってコロン付きの 16 進表現
で指定するか、コールバックコマンド行ユーティリティをオプション -hook のパラメータとし
て指定します。オプション -hook のパラメータとして指定するコマンドでは、パラメータとし
て NEW_FQDN と NEW_IP_ADDR を必要とし、MAC アドレスを MAC=XX:XX:XX:XX:XX:XX 形式で
標準出力に出力し、終了コード 0 で終了する必要があります。-hook オプションで指定するコマ
ンドの例としては、次のスクリプトを参照してください。
/opt/OV/contrib/OpC/opcgetmacaddr.sh
このスクリプトでは、指定したノードの MAC アドレスを取得するために、
/opt/OV/bin/snmpget を使っています。このスクリプトは、SNMPv2 をサポートしている
ノードでのみ、正しく動作します。
オプション -nnmtopofix は、NNM の設定にある問題を修正する場合にのみ必要です。ホスト
名または IP アドレスを変更したノードで問題が発生した場合に、このオプションを使います。
注記
-nnmtopofix オプションは、時間とリソースを大きく消費します。
ノードの設定と名前解決の比較
コマンド行ユーティリティ opc_chk_node_res.pl を使うことで、ノードの設定が名前解決と
一致しているかどうかをチェックすることができます。このユーティリティは次の場所にありま
す。
/opt/OV/bin/OpC/utils/opc_chk_node_res.pl
注記
第5章
opc_chk_node_res.pl コマンドを実行した場合、設定済みノードの数と名前解
決のメカニズムによっては、データベースとネットワークに大きな負荷がかかる
ことがあります。
131
HTTPS ノードでの作業
HTTPS ノードの設定
設定した名前または IP アドレスに不一致が見つかると、そのたびに不一致に関する情報が標準
出力に出力され、OVO メッセージが送信されます。OVO メッセージには、名前または IP アド
レスの新しい値 ( 評価できた場合 ) が含まれています。このユーティリティには、チェック対象
または送信メッセージの数を制限するためのオプションがあります。
opc_chk_node_res.pl [-h[elp]] [-quiet] [-max ###] ¥
[-check all|managed|external] ¥
[-name FQDN|-addr DOTTED_IP_ADDR]
-help
ここに書かれている内容が表示されます。
-quiet
STDOUT に何も出力しません。
-max ###
このコマンドが送信する OVO メッセージの数を制限する場
合に、このオプションを使用します。パラメータ (###) のデ
フォルト値は 200 です。
メッセージの数を制限しないときは、-1 を指定します。
-check all|managed|external チェックの数を制限したい場合に、このオプションを使用し
ます。パラメータのデフォルト値は all です。
-name FQDN
完全修飾ドメイン名でチェック対象ノードを 1 つ指定する
場合に、このオプションを使用します。
-addr DOTTED_IP_ADDR
IP アドレス ( たとえば、192.168.1.1) でチェック対象ノー
ドを 1 つ指定する場合に、このオプションを使用します。
送信される OVO メッセージのパラメータは、スクリプトを使ってカスタマイズできます。
132
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
OVO におけるプロキシ
ネットワークゲートウェイサーバーにあるファイアウォールプログラムとそれに付随したポリ
シーは、プライベートネットワークのリソースを外部のユーザーから保護するためのゲートウェ
イとして使われます。一般に、イントラネット内のユーザーは許された範囲のインターネットに
アクセスできますが、外部のユーザーは、ファイアウォールによって組織内のリソースのアクセ
スが制御されます。
ファイアウォールには、次に示す 2 つの基本的なカテゴリがあります。
•
ネットワークレベルで動作する IP パケットフィルター
•
アプリケーションレベルで動作するプロキシサーバー ( たとえば Web のプロキシ )
プロキシの実体はソフトウェアアプリケーションであり、インターネットから入ってくるデータ
パケットのヘッダーと内容を調べ、そのデータの送信先システムを保護するために必要なアク
ションを実行します。プロキシはセキュリティポリシーと連動して、受け付けることのできない
情報を削除したり、リクエストそのものを完全に廃棄したりします。
セキュリティの観点から見ると、アプリケーションレベルのプロキシには次に示すような大きな
利点があります。
•
アプリケーションレベルでパケットを調べることができるので、きめ細かいセキュリティ制
御とアクセス制御を行えます。たとえば、.exe ファイルのような特定タイプのファイル転
送を制限するということも可能です。
•
ファイアウォールに対する「サービス拒否 (DoS)」攻撃からイントラネットを守ることがで
きます。
ただし、プロキシ使用の欠点もあります。引き合いによく出される欠点は、次の 2 つです。
•
ホストシステムのコンピュータリソースを大量に消費します。しかし、最近では高性能のコ
ンピュータがかなり安く入手できるようになったため、この欠点は問題にはならなくなりま
した。
•
プロキシは特定のアプリケーションプログラムに合わせて作成する必要があります。プロキ
シの作成が容易ではないプログラムがあるので、万能ではありません。
プロキシサーバーは、内部ネットワークにアクセスさせる前に、すべての情報を止めて、検査し
ます。したがって、プロキシを使うと、内部ネットワークと「外界」との間を直接接続すること
はできなくなくなります。ユーザーが外部に向けて情報を発信する場合は、プロキシの認証を受
ける必要があります。イントラネット内のクライアントがインターネットにリクエストを発信す
ると、実際にはプロキシがそのリクエストを受け取ります。プロキシは NAT (Network Address
Translation) を使ってパケットの発信元 IP アドレスをプロキシサーバーの IP アドレスに変更
し、内部ネットワークのユーザーの ID を外部から隠します。プロキシサーバーがリクエストを
通過させて送信先アドレスに送るのは、設定されているポリシーのすべての要件にそのリクエス
第5章
133
HTTPS ノードでの作業
HTTPS ノードの設定
トが適合している場合だけです。リクエストに対するレスポンスを受信したときの動作はこの逆
です。外部から送られてきたレスポンスは、安全と見なされた場合にだけ、イントラネットワー
ク内のターゲットクライアントに転送されます。レスポンスの発信元アドレスは変更されません
が、送信先アドレスはファイアウォール内のリクエスト元マシンのアドレスに戻されます。この
メカニズムによって、どのネットワークシステムとの間にも制御の利かない直接ルートがなくな
り、ネットワークのセキュリティが大幅に向上します。
プロキシサーバーには、次に示す 2 つの基本的なタイプがあります。
•
シングルホームホスト
プロキシサーバーにカードとアドレスをそれぞれ 1 つだけ持たせ、インターネットルーター
が、プロキシサーバーへのリクエストの転送と、ネットワークに対するその他すべての情報
のブロックを担当します。
•
デュアルホームホストまたはマルチホームホスト
プロキシサーバーに複数のネットワークカードを接続します。内部ネットワークからのリク
エストはこの中のいずれか 1 つのネットワークカードに送られます。インターネットから送
られてくる情報は別のネットワークカードが受信します。ネットワークカード間のルーティ
ングは行えないように設定されます。そのため、ネットワークカードで送信情報と受信情報
を直接結び付けることはできません。どの情報をどこに送るかはプロキシサーバーがすべて
決定します。
134
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
プロキシの構成
大部分の「LAN - インターネット - LAN」接続アーキテクチャは、次に示す図またはそのサブ
セットで表すことができます。
図 5-4
HTTP プロキシの模式図
内部の LAN-A には、OVO 管理サーバーと HTTP プロキシが置かれています。
内部の LAN とインターネットおよび外界との間は、ファイアウォールによって分離されていま
す。
外部の LAN-B には、HTTPS 管理対象ノードと HTTP プロキシが置かれています。
第5章
135
HTTPS ノードでの作業
HTTPS ノードの設定
プロキシの通信は、次に示す図またはそのサブセットで表すことができます。
図 5-5
HTTP プロキシのインフラストラクチャ
A: 直接通信。プロキシを通りません。ファイアウォールは次の接続をすべて受け入れる必要が
あります。
*.internal.mycom.com:* から *.external.mycom.com:TARGET_PORT への接続
*.external.mycom.com.* から *.internal.mycom.com:SOURCE_PORT への接続
B: ドメイン internal.mycom.com では proxy_01 がプロキシになっていて、ドメイン
external.mycom.com にアクセスします。ファイアウォールは次の接続をすべて受け入れる必
要があります。
proxy_01.internal.mycom.com:* から *.external.mycom.com:TARGET_PORT への接続
ドメイン external.mycom.com では proxy_02 がプロキシになっていて、ドメイン
internal.mycom.com にアクセスします。ファイアウォールは次の接続をすべて受け入れる必
要があります。
proxy_01.internal.mycom.com から *.internal.mycom.com:SOURCE_PORT への接続
C: ドメイン internal.mycom.com では proxy_01 が、また、ドメイン external.mycom.com
では proxy_02 はそれぞれプロキシになっています。proxy_01 は proxy_02 にアクセスし、
proxy_02 は proxy_01 にアクセスします。ファイアウォールは次の接続をすべて受け入れる必
136
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
要があります。
proxy_01.internal.mycom.com:* から proxy_02.external.mycom.com:PROXY_B_PORT へ
の接続
proxy_02.external.mycom.com:* から proxy_01.internal.mycom.com:PROXY_A_PORT へ
の接続
OVO 管理対象ノードが通信に使うプロキシは、ノードごとに指定する必要があります。このプ
ロキシは、ovconfchg コマンドを使って名前空間 bbc.http 内で設定し、bbc.ini ファイルに
保存します。bbc.ini は、手作業で編集してはなりません。
構文
ovconfchg -ns <namespace> -set <attr> <value>
パラメータは次のとおりです。
-ns <namespace>
次の「-set <attr> <value>」オプションで使う名前空間
を指定します。
-set <attr> <value>
現在の名前空間で、属性 ( プロキシ ) と値 ( ポートおよびア
ドレス ) を設定します。
たとえば、次のように指定します。
ovconfchg -ns bbc.http -set PROXY
"web-proxy:8088-(*.mycom.com)+(*.a.mycom.com;*)"
この例では、指定したホスト名に対して使うプロキシとポートを定義しています。
フォーマット :
proxy:port +(a)-(b);proxy2:port2+(a)-(b); ...;
a: このプロキシを使うホスト名のリストです。ホスト名はコンマまたはセミコロンでそれぞれを
区切って指定します。
b: このプロキシを使わないホスト名のリストです。ホスト名はコンマまたはセミコロンでそれぞ
れを区切って指定します。
最初にマッチしたプロキシが使われます。
ホスト名の代わりに IP アドレスを使うこともできます。したがって、15.*.*.* や
15:*:*:*:*:*:*:* も有効です。ただし、この場合には、正確な数のドットやコロンを指定する
必要があります。IP バージョン 6 は現在サポートされていませんが、将来はサポートされる予
定です。
PROXY=web-proxy:8088-(*.hp.com)+(*.a.hp.com;*)
第5章
137
HTTPS ノードでの作業
HTTPS ノードの設定
プロキシ web-proxy がポート 8088 を通して、*.hp.com に該当するホスト ( たとえば、
www.hp.com) を除くすべてのサーバー (*) で使われます。*.a.hp.com にマッチするホスト、た
とえば、merlin.a.hp.com ではこのプロキシサーバーが使われます。
HTTP プロキシの背後で行う手作業のエージェントインストール
プロキシの背後にあるノードにエージェントを手作業でインストールする場合は、次の専用手順
が必要です。
1. HTTPS エージェントソフトウェアをインストールするシステムに、必要なファイルをすべ
てコピーします。HTTPS エージェントソフトウェアを手作業でインストールする方法は、
116 ページの「手作業によるエージェントのインストール」を参照してください。
2. 次のコマンドを実行して、エージェントのインストールスクリプトを起動します。
./opc_inst
このコマンドは、サーバーや証明書サーバーのオプションを指定して実行することもできま
す。
3. プロキシのパラメータを設定します。その例を次に示します。
ovconfchg -ns bbc.http -set PROXY
"web-proxy:8088-(*.mycom.com)+(*.a.mycom.com;*)"
4. ノードをアクティブにしてエージェントを起動する必要がある場合は、次のコマンドを実行
します。
./opcactivate -srv <srv_name>
管理対象ノードでのプロキシの設定
OVO 管理対象ノードでプロキシを設定するには、次の手順を実行します。
1. 管理対象ノードシステムでエージェントソフトウェアをインストールします。インストール
は手作業になります。ターゲットシステムにはまだアクセスできないので、リモートからイ
ンストールすることはできません。HTTPS エージェントを手作業でインストールする方法
は、116 ページの「手作業によるエージェントのインストール」を参照してください。
2. OVO エージェントが OVO 管理サーバーと通信するときに使うプロキシを設定します。その
例を次に示します。
ovconfchg -ns bbc.http -set PROXY
"web-proxy:8088-(*.mycom.com)+(*.a.mycom.com;*)"
3. 次のコマンドを実行して、すべてのエージェントプロセスを停止します。
138
第5章
HTTPS ノードでの作業
HTTPS ノードの設定
ovc -kill
4. 次のコマンドを実行してエージェントを再起動し、プロキシの変更を登録します。
ovc -start
OVO 管理サーバーでのプロキシの設定
OVO 管理対象ノードでプロキシの設定を変更するには、次の手順を実行します。
1. OVO 管理サーバーがその管理対象ノードと通信するときに使うプロキシを設定します。その
例を次に示します。
ovconfchg -ns bbc.http -set PROXY
"web-proxy:8088-(*.mycom.com)+(*.a.mycom.com;*)"
2. 次のコマンドを実行して、すべての OVO プロセスを停止します。
ovstop ovoacomm
/opt/OV/bin/OpC/ovc -kill
3. 次のコマンドを実行してプロセスを再起動し、プロキシの変更を登録します。
ovstart ovoacomm
/opt/OV/bin/OpC/opcsv -start
/opt/OV/bin/OpC/opcagt -start
第5章
139
HTTPS ノードでの作業
HTTPS ノードの設定
エージェントの削除
エージェントは、HTTPS 管理対象ノードから自動または手作業で削除できます。
エージェントの自動削除
エージェントを自動的に削除する方法は、『OVO システム管理リファレンスガイド』を参照して
ください。
手作業によるエージェントの削除
OVO エージェントを HTTPS 管理対象ノードから手作業で削除するには、次の手順を実行しま
す。
UNIX 管理対象ノードの場合 :
1. インストールディレクトリに移動します。
cd /opt/OV/bin/OpC/install
2. 次のコマンドを実行します。
./opc_inst -r
Windows 管理対象ノードの場合 :
1. 管理対象ノードで実行されているすべての OVO エージェントを停止します。
2. 次のコマンドを実行します。
$INSTALLDIR¥bin¥OpC¥install¥opc_inst.vbs -r
削除エラー
削除中にエラーが発生した場合は、そのノードの削除ログファイルをチェックします。そのノー
ドのネイティブインストーラのログファイルにエラー情報が書き込まれています。たとえば
HP-UX では、次の場所にログファイルがあります。
/var/adm/sw/swagent.log と /var/adm/sw/swremove.log
Windows 管理対象ノードの場合は、次の場所にログファイルがあります。
%SYSTEMROOT%¥temp¥inst.log
またこれとは別に、opc_inst は、すべてのプラットフォームで次の場所にログファイルを作成
します。
/<OvDataDir>/log/install_bbc.log
140
第5章
HTTPS ノードでの作業
OVO の仮想ノード
OVO の仮想ノード
クラスタは複数のシステムまたはノードの集合であり、全体が 1 つの単位となって、アプリケー
ション、システムリソース、データをユーザーに提供するように、動作します。Veritas
Cluster、Sun Cluster または TruCluster のような最新のクラスタ環境では、アプリケーション
はリソースの複合体として表現されます。これらのリソースはリソースグループを構成し、リ
ソースグループがクラスタ環境で動作するアプリケーションを表現します。各リソースは、この
複合体の中で特定の機能を実行します。
OVO 8.1 から、ノードクラスタを管理するモデルが拡張され、クラスタ環境で動作するすべての
OV アプリケーションに共通なメカニズムが用意されました。OV アプリケーションは、リソー
スの集合体またはグループとして表現されます。
用語
OVO では、高可用性を説明するために次の用語と略語が使われています。
クラスタ
クラスタ管理ソフトウェアの制御下で動作する複数の同等なシステムをまとめ
たグループ。クラスタ管理ソフトウェアとして MC/ServiceGuard (MC/SC)、
Veritas Cluster、Sun Cluster などがサポートされています。
HA リソースグループ
高可用性アプリケーションの名前。
仮想ノード
特定の HARG が動作している物理的なノードのグループに対して付けられる
共通名。ノードグループ自体は、クラスタを構成するノード群のサブセットで
す。仮想ノードには、通常、名前と IP アドレスを割り当てます。そうするこ
とで名前解決の認識対象となり、通常のシステムと同じようにアドレス指定で
きるようになります。仮想ノードはクラスタの一部で、OVO 登録ノードのメ
ンバーです。
物理ノード
HARG のホストとして動作できる単一システムです。複数の物理ノードが集
まって 1 つの仮想ノードを構成します。それぞれの物理ノードは、OVO 登録
ノードのメンバーです。
仮想ノードの概念
仮想ノードは、共通の HA リソースグループ名でリンクされている物理ノードのグループです。
これらの物理ノード上のエージェントのクラスタ対応 (ClAw) の拡張機能では、パッケージ自身
が仮想ノード内で切り換えできるように、物理ノードのポリシーを切り換えることができます。
第5章
141
HTTPS ノードでの作業
OVO の仮想ノード
管理対象ノードを HA リソースグループ名を使ってリンクすることには、以下の利点があります。
•
HA リソースグループの範囲で検出されたイベントは、たとえば、仮想ノードに割り当てられ
たポリシーによって、その名前を発行元ノードの名前として受信できる。
•
管理ステーションの GUI で正しいフィルター処理と強調表示が可能になる。
•
サービス名とメッセージキーの相関処理によって、本来の意味でのクラスタ管理が可能にな
る。
注記
これらの機能が利用できるのは、HTTPS ノードだけです。
仮想ノードには 1 つの HA リソースグループ名だけを割り当てることができます。
1 つの HA リソースグループ名を複数の仮想ノードに割り当てることは可能ですが、これらの仮
想ノードが特定の共通物理ノードを共有することはできません。理由は、両方の仮想ノードに割
り当てられているポリシーで 2 回同じ HARG が受信されたとき、エージェントのクラスタ対応
機能では仮想ノードを区別できなくなるからです。
OVO への仮想ノードの追加
仮想ノードの追加は、[OVO 登録ノード ] ウィンドウを使って、次のように行います。
注記
最初にノードを物理ノードとして登録ノードに追加しておき、その後、[ ノードの
変更 ] ウィンドウの [ クラスタ仮想ノード ] を選択して、仮想ノードに変更するこ
とができます。
OVO では、仮想ノードを直接物理ノードに戻すことはできません。そうするため
には、ノードを登録ノードから削除して、その後追加し直す必要があります。
1. 次のように選択して、[ ノードの追加 ] ウィンドウを開きます。
[ アクション : ノード -> 追加 ]
2. ノード関連の必要な情報を入力します。
142
•
ホスト名
•
IP アドレス
•
ノードの通信タイプ。HTTPS または DCE を指定します。
•
[ クラスタ仮想ノード ] チェックボックスをチェックします。
第5章
HTTPS ノードでの作業
OVO の仮想ノード
•
物理ノードのリストを入力します。仮想ノードではありません。すべてのノードは、同
じ通信タイプである必要があります。
•
クラスタでホストする HA リソースグループ名
注記
クラスタを構成するすべてのノードは、OVO 登録ノードのメンバーにも
なっている必要があります。また、ノードタイプの特性 ( プラットフォー
ム、オペレーティングシステム、通信タイプ ) が同じである必要がありま
す。
DHCP ノードは仮想ノードにできません。
クラスタの物理ノードとして仮想ノード自体を指定することはできませ
ん。
3. [OK] をクリックします。
opcnode(1m) を使った仮想ノードの設定
仮想ノードは opccfgupld(1m) ユーティリティまたは opcnode(1m) ユーティリティを使って
OVO 登録ノードにアップロードして設定することも可能です。
opcnode(1m) には、以下の新しいコールパラメータが追加されました。
-set_virtual
node_list = "node1 node2 ..."
cluster_package = HARG_name
使用例 :
./opcnode -set_virtual node_name=ovguest3 node_list="talence ovguest3"
OVO での仮想ノードの変更
仮想ノードの変更は、[OVO 登録ノード ] ウィンドウを使って、次のように行います。
1. [ 登録ノード ] ウィンドウで、変更する仮想ノードを選択します。
2. 次のように選択して、[ ノードの変更 ] ウィンドウを開きます。
[ アクション : ノード -> 変更 ]
3. 仮想ノード関連の情報を変更します。変更できるのは次の情報です。
第5章
143
HTTPS ノードでの作業
OVO の仮想ノード
•
HA リソースグループ名
•
物理ノードのリスト
注記
クラスタを構成するすべてのノードは、OVO 登録ノードのメンバーにも
なっている必要があります。また、ノードタイプの特性 ( プラットフォー
ム、オペレーティングシステム、通信タイプ ) が同じである必要がありま
す。
クラスタの物理ノードとして仮想ノード自体を指定することはできませ
ん。
4. [OK] をクリックします。
OVO からの仮想ノードの削除
OVO 登録ノードからの仮想ノードの削除は、[OVO 登録ノード ] ウィンドウを使って、次のよう
に行います。
1. [ 登録ノード ] ウィンドウで、削除する仮想ノードを選択します。
2. 次のように選択して、指定したノードを削除します。
[ アクション : ノード -> 削除 ]
OVO の仮想ノードへのポリシーの割当て
注記
ポリシーはユーザー変数 <$MSG_GEN_NODE_NAME> を含むように定義できます。
カスタムメッセージ属性 namespace と instance の値が設定されている場合、
HTTPS 仮想ノードに割り当てられるポリシーの <$MSG_NODE_NAME> は仮想ノー
ド名を表わし、<$MSG_GEN_NODE_NAME> はイベントの物理ノード名を表わしてい
ます。
仮想ノードへのポリシーの割当ては、[OVO 登録ノード ] ウィンドウを使って、次のように行いま
す。
1. [ 登録ノード ] ウィンドウで、[De-assigned/Removed] からポリシーを割り当てる仮想ノード
を選択します。
2. 次のように選択して、[ テンプレートの指定 ] ウィンドウを開きます。
144
第5章
HTTPS ノードでの作業
OVO の仮想ノード
[ アクション : エージェント -> テンプレートの指定 ]
3. [ 追加 ...] ウィンドウを開きます。
4. 仮想ノード名と割り当てるポリシーを入力します。
5. [OK] をクリックします。
OVO の仮想ノードからのポリシーの削除
仮想ノードからのポリシーの削除は、[OVO 登録ノード ] ウィンドウを使って、次のように行いま
す。
1. [ 登録ノード ] ウィンドウで、ポリシーを削除する仮想ノードを選択します。
2. 次のように選択して、[ テンプレートの指定 ] ウィンドウを開きます。
[ アクション : エージェント -> テンプレートの指定 ]
3. [ 追加 ...] ウィンドウを開きます。
4. 削除するポリシーの行を選択します。このとき、ポリシーはノードとポリシーの組で選択し
ます。
5. [OK] をクリックします。
第5章
145
HTTPS ノードでの作業
OVO の仮想ノード
OVO での仮想ノードへのポリシーの配布
仮想ノードに割り当てられたポリシーは、仮想ノードへの [ ソフトウェアと設定のインストール
/ 更新 ] の処理中に関連する物理ノードに配布されます。
仮想ノードへのポリシーの配布は、[OVO 登録ノード ] ウィンドウを使って、次のように行いま
す。
1. [ 登録ノード ] ウィンドウで、ポリシーが配布される仮想ノードを選択します。
2. 次のようにして、[OVO ソフトウェアと設定のインストール / 更新 ] ウィンドウを開きます。
[ アクション : エージェント -> ソフトウェアと設定のインストール / 更新 ]
3. 配布するポリシーを選択します。
4. [OK] をクリックして、選択した仮想ノードに属するすべての物理ノードへポリシーを分配し
ます。
仮想ノードへ分配すれば、すべての対応する物理ノードへも、自動的に分配されます。指定した
仮想ノードに属し、割り当てられた管理対象ノードへ送信されるすべてのポリシーに、関連する
HA リソースグループ名が追加されます。
物理ノードが別の仮想ノードに属するようにアップデートされると、HA リソースグループ名の
集合は、そのノードを含むように拡張されます。その結果、物理ノードに送信される各ポリシー
には、それが属する仮想ノードに結び付けられたすべての HA リソースグループ名が含まれるよ
うになります。
OVO での仮想ノードに関するポリシーの構成の変更
ポリシーの変更は、次の手順で行います。
1. [ メッセージソースのテンプレート ] ウィンドウでポリシーを開きます。
2. ポリシーに対して必要な変更を行います。
3. [OK] をクリックして変更を確認し、ウィンドウを閉じます。
変更したポリシーは、この後で新しいポリシーの配布を起動したときに、すべての物理ノー
ド上でアップデートされます。
146
第5章
HTTPS ノードでの作業
DHCP クライアントシステム上での HTTPS エージェントの管理
DHCP クライアントシステム上での HTTPS エージェントの管理
DHCP サーバーは、IP ネットワークに存在するコンピュータに対して、DHCP (Dynamic Host
Configuration Protocol) を使ってネットワークの設定を動的に割り当てます。この動的な割当て
の主な目的は、大規模 IP ネットワークの管理に必要な作業を減らすとともに、コンピュータの
IP アドレスを必要に応じて分配することです。
DHCP はクライアント - サーバー型のアプリケーションです。コンピュータが DHCP サーバー
に接続すると、このサーバーからそのコンピュータに対して一時的な IP アドレスが割り当てら
れます。コンピュータはその IP アドレスを一時割当ての期限が切れるまで使います。期限が切
れた時にまだ IP アドレスが必要なときは、新しい IP アドレスへ置き換えることになります。
DHCP の主な利点は、そのアドレス指定方法が完全に動的であることです。ネットワークで
DHCP サーバーが動作していれば、そのネットワーク内では、IP アドレスを再設定することな
くコンピュータを追加したり移動したりできます。
OVO では、DHCP クライアントシステムで動作する OVO HTTPS エージェントも管理すること
ができます。この OVO ソリューションは、特定の DHCP 製品や DNS 製品には依存しません。
ただし、これには次の条件が必要です。
•
ノード名が変わらないこと。MoM (manager-of-manager) 環境であっても、ノードの識別に
はノード名が使われます。
•
DHCP と DNS が同期していること。
•
一日のうちに変更される IP アドレスの数が比較的少なく、IP アドレスの変更 (IPCE; IP
Address Change Event) が大量に発生する場合の対応が不要なこと。OVO エージェントは、
ネットワークインタフェースに IP アドレスの変更があると、このイベントを送信します。
•
Java GUI、管理者およびオペレータ UI の各プロセスで、IP アドレスの変更を自動的に更新
しないこと。IP アドレス変更に関する警告を受信した場合は、管理者とオペレータは UI プ
ロセスを再起動して最新の IP アドレス情報をロードする必要があります。
•
エージェントの DHCP サポートがエージェントおよびサーバーごとに設定できること。
•
IP アドレスの動的な変更が、起動時だけでなく実行時にも可能なこと。
IP アドレスの変更をチェックする周期は、管理対象ノード上の IPADDR_CHECK_INTERVAL
変数で設定できます。
第5章
147
HTTPS ノードでの作業
DHCP クライアントシステム上での HTTPS エージェントの管理
OVO での DHCP の設定
DHCP 用の変数
DHCP に固有な管理サーバープロセスの動作は、次の変数を使って設定します。
OPC_DUMMY_IP_RANGE 1.1.1.*
OVO/UNIX 管理サーバーは、IP 変更リクエストの処理で IP アドレスの重複を検出すると、
OPC_IP_DUMMY_IP_RANGE の範囲内で次に空いている IP アドレスを使います。この文字列は、
[1-9*].[1-9*].[1-9*].[1-9*] の形式で指定します。少なくとも 1 つの数字を指定する必要
があります。デフォルトは、1.1.1.* です。
OPC_IPCE_RETRY_NUM 10
ノードから報告された IP アドレスが DNS に登録されている IP アドレスとすべて一致しない
と、その IP アドレス変更イベントはバッファーに入れられます。この場合、バッファーに入れ
られた各イベントごとに、OPC_IPCE_RETRY_NUM 変数で指定された最大回数だけ、リトライさ
れます。デフォルトは、10 回です。
OPC_IPCE_RETRY_INTERVAL 180
OPC_IPCE_RETRY_INTERVAL の時間が経過すると、バッファーに入れられているすべての IP 変
更イベントが再び処理されます。デフォルトは、180 秒です。
DHCP 用の opcnode 変数
opcnode コマンドには次の DHCP オプションがあります。
opcnode -add dynamic_ip=yes|no node_name=<fully qualified domain name>
オプション -add を使う場合は、パラメータ dynamic_ip を指定します。dynamic_ip として
yes を指定することで、Administrator UI の [ ノードの変更 ] ウィンドウで DHCP を選択した場
合と同様、OVO 管理サーバーがこの新しいノードから IP アドレス変更イベントを受け入れるよ
うに設定できます。
opcnode -chg_iptype dynamic_ip=yes|no -node_list=<List of nodes>
dynamic_ip として yes を指定することで、Administrator UI の [ ノードの変更 ] ダイアログで
DHCP を選択した場合と同様、OVO 管理サーバーがこの変更されたノードからの IP アドレス
変更イベントを受け入れるように設定できます。
148
第5章
HTTPS ノードでの作業
DHCP クライアントシステム上での HTTPS エージェントの管理
dhcp_postproc.sh を使った NNM の同期
dhcp_postproc.sh ツールは、管理サーバープロセス ovoareqsdr が IP アドレス変更イベント
を正常に処理した後に使います。このツールは、ノードの IP アドレスが変更された後で NNM
の同期を取ります。このツールによってノードのホスト名とその新しい IP アドレスを取得しま
す。
設定
DHCP クライアントでエージェントの管理を有効にする
DHCP クライアントで HTTPS エージェントの管理を有効にするには、次の手順を実行します。
1. DHCP と DNS の同期を取ります。その方法として、たとえば、DHCP サーバーをアップデー
トします。同期させないと、OVO 管理サーバーは IP アドレス変更イベントをいっさい処理
できません。また、システム全体の性能も低下します。
2. NNM を設定して DHCP を処理するようにします。その方法は、OVO のオンラインヘルプに
ある「アクセス不可の DHCP IP アドレスの削除」のセクションを参照してください。
3. /opt/OV/contrib/OpC/dhcp_postproc.sh をカスタマイズします。
スクリプトを環境に合わせてカスタマイズします。次のエントリーが特に重要です。
NETMASK="255.255.248.0"
# netmask
MAXRETRY=5
# number of retries for opctranm
SLEEP_TIME=10
# sleep this amount of seconds
# before the next retry
TRACE="off"
# on=do (or off=do not) create
# lots of tracefiles in /tmp
NETMON_TOPO_FIX="OFF"
# off is highly recommended
FORCE_NODEINFO_DIST
# off
opcmsg または opcwall の呼び出しを追加することもできます。
第5章
149
HTTPS ノードでの作業
証明書の作成と分配
証明書の作成と分配
ネットワークの通信に暗号化を伴う SSL (Secure Socket Layer) プロトコルを使う場合は、証明
書が必要です。このネットワーク通信では、サーバー側の認証とクライアント側の認証を行いま
す。管理対象環境のノードは証明書を使って識別します。2 つのノード間で行う「SSL ハンド
シェーク」は、相手 ( 入り側ノード ) の示してきた証明書の発行局がこちら側 ( 受信ノード ) で
信頼できる発行局であると証明できたときにだけ、正常に行われます。
証明書は、自動または手作業でインストールできます。詳細は、以下の項を参照してください。
•
153 ページの「証明書の自動分配」
•
159 ページの「手作業の分配に使う証明書を作成する方法」
•
163 ページの「インストールキーを使って証明書を手作業で分配する方法」
証明書のインストールは、OVO メッセージで監視できます。証明書リクエストが自動的に承諾
されると、証明書が正常に分配されたことを確認する通知メッセージが、メッセージブラウザに
送られます。証明書リクエストが自動的には承諾されなかった場合は、メッセージブラウザに
メッセージが表示されて、リクエストの拒否理由と、管理者がこの問題を解決するために取るべ
き手順が示されます。
証明書の管理は、[ ノード証明書リクエスト ] ウィンドウから行います。このウィンドウは、次の
ように選択して開きます。
[ アクション : ノード -> OVO ノード証明書リクエスト ]
[ ノード証明書リクエスト ] ウィンドウでは、次の管理作業を行えます。
•
証明書リクエストの承諾、拒否、削除
•
証明書リクエストと登録ノード内の対応するノードとのマッピング
•
証明書リクエストの流れの追跡
•
保持エリアへのノードの追加
150
第5章
HTTPS ノードでの作業
証明書の作成と分配
ノードリストボックスに表示されているノードを選択して、[ 承諾 ]、[ 拒否 ]、[ 削除 ] などのア
クションを起動すると、そのアクションが実行され、ノードがリストボックスから削除されま
す。リストの内容は証明書サーバーによって更新されることがあります。また、ウィンドウ内の
リストは 10 分ごとに自動的に更新されます。
図 5-6
[ ノード証明書リクエスト ] ウィンドウ
[ ノード証明書リクエスト ] ウィンドウに表示されるノード情報
ホスト名
証明書リクエスト発行側ノードのホスト名 (ID として一意ではありません )
IP アドレス
証明書リクエスト発行側ノードの IP アドレス (ID として一意ではありま
せん )
OvCoreID
OVO HTTPS ノードを一意に識別できる唯一の ID。リクエストを承諾する
と、この OvCoreID のノードから発信されるすべての通信を承諾したことにな
ります。ホスト名は変更できますが、OVCoreID はノードを示す一意な ID と
してそのままです。
マップ先
リストにある証明書リクエストのマップ先ノードのホスト名。まだマップされ
ていないリクエストの [ マップ先 ] カラムは空欄になっています。[ すべての
マップされた要求を選択 ] をクリックすると、ホスト名が [ マップ先 ] カラムに
表示されているホスト名と同じすべての証明書リクエストが選択されます。
157 ページの「指定したノードへマップ」を参照してください。
第5章
151
HTTPS ノードでの作業
証明書の作成と分配
プラットフォーム OVO 管理対象ノードのオペレーティングシステム
152
第5章
HTTPS ノードでの作業
証明書の作成と分配
証明書の自動分配
証明書の最も一般的な分配方法は、OVO に証明書の作成、承諾、および分配を自動的に行わせ
ることです。図 5-7 に、OVO が HTTPS 管理対象ノードに証明書を発行する例を示します。
図 5-7
証明書の分配処理
HTTPS エージェントソフトウェアを管理対象ノードシステムにインストールすると、そのノー
ドシステムの証明書管理クライアントは、秘密鍵と証明書リクエストを作成します。秘密鍵は、
ネットワークを経由してサーバーシステムへ証明書リクエストを送信する際に、その証明書リク
エストの暗号化に使われます。自動承諾はデフォルト設定では有効で、自動承諾待ち時間は 30
分に設定されています。リクエストが設定されている待ち時間以内に到着しなかった場合には、
[ ノード証明書リクエスト ] ウィンドウを使って、手作業で処理する必要があります。この待ち
時間を変更するには、次のコマンドを使います。
ovconfchg -ovrg server -ns opc -set ¥
OPC_CSA_AUTOGRANT_INTERVAL <time interval in minutes>
メッセージが正しい鍵で暗号化されている場合に限って、受信側管理サーバーはその送信者を信
頼します。この方法では完全なセキュリティを確保できないので、高度な機密性を要する環境で
は推奨できませんが、リクエストをプレーンテキストで送信するよりは安全です。このモード
は、証明書リクエストと署名付き証明書の送信を短時間で済ませたい場合にだけで使います。
第5章
153
HTTPS ノードでの作業
証明書の作成と分配
機密性を要する環境では、証明書リクエストの自動承諾を無効にしておき、リクエストごとに管
理者が判断した後で、その有効性を承諾するようお勧めします。自動承諾を無効にするには、次
のコマンドを実行します。
ovconfchg -ovrg server -ns opc -set ¥
OPC_CSA_USE_AUTOGRANT <TRUE|FALSE>
しかし、証明書を手作業でインストールするのがもっとも安全な方法であることに変わりはあり
ません。
注記
OpenView の秘密鍵は、HP Openview の HTTPS セキュリティソフトウェアの一
部となっており、HTTPS ベースの HP Openview アプリケーションでは、特に指
定しない限り、この秘密鍵が使われます。ただし、OpenView がインストールさ
れているどのシステムでも、この秘密鍵は同じです。
OpenView の秘密鍵は、ユーザーの設定した鍵で置き換えることができます。
OpenView では、この秘密鍵のことを、設定可能な秘密鍵と呼びます。設定可能
な秘密鍵の置き換えは、管理環境を設定する前に行うことができます。証明書リ
クエストに使う秘密鍵を置き換える場合は、どのシステムでも証明書サーバーと
同じものを使うようにしてください。
設定可能な秘密鍵を使うことで、クライアントシステムが別の証明書サーバーシ
ステム、たとえば、HP OpenView をインストールした他のシステムに証明書を
リクエストできなくすることができます。
注記
証明書サーバーシステムは、証明書を作成して分配する前にセットアップされて
アクティブになっている必要があります。
証明書の分配を自動的に行わせるには、HTTPS エージェントソフトウェアを管理対象ノードシ
ステムにインストールします。インストールが終わると、OVO によって次の手順が実行されま
す。
1. 管理対象ノードで、認証管理クライアントが新しい公開鍵 / 秘密鍵のペアを生成します。
2. 管理対象ノードシステムで、そのノードシステム用の証明書リクエストの発行が起動されま
す。
3. 生成された秘密鍵が、暗号化されたファイルとして保管されます。
4. 証明書リクエストがこの秘密鍵によって暗号化され、証明書サーバーシステムに送信されま
す。この段階では、まだこのノードシステムに有効な証明書がないので、SSL 接続を使わな
いで送信されます。
154
第5章
HTTPS ノードでの作業
証明書の作成と分配
5. 証明書サーバーで証明書リクエストが復号化されます。正常に復号化された証明書リクエス
トは、保留中の証明書リクエストを置くプールに追加されます。またこれと同時に、登録さ
れているすべてのコンポーネントに通知が送られ、OVO イベントブラウザに、対応するエ
ントリーが表示されます。
6. 証明書リクエストが、事前に設定されているいくつかの条件に従って、承諾または拒否され
ます。条件には、たとえば、HTTPS エージェントソフトウェアをノードシステムにインス
トールしてから 2 分以内にリクエストが発行されたかというようなものがあります。
注記
この手順の中で最もセキュリティが必要な部分は、証明書リクエストの承諾
です。リクエストの承諾者には、承諾者となる正当な根拠が求められます。
たとえば、あるノードにパッケージを配布した後でリクエストを待っている
管理者がいたとします。この場合、そのノードから証明書サーバーに送られ
てきた証明書リクエストについては、その管理者が承諾者になるだけの根拠
があるといえます。
7. リクエストが承諾されると、証明書サーバーが証明書リクエストに署名します。署名された
証明書は秘密鍵によって暗号化され、発行元ノードシステムに送信されます。
証明書リクエストが拒否されると、サーバーシステムからノードシステムに対して、リクエ
ストが拒否されたことを示すメッセージが送られます。またこれと同時に、OVO イベント
ブラウザにも対応するエントリーが表示されます。
8. ノードシステムの証明書クライアントがこのレスポンスを受信します。証明書が承諾される
と、その新しい証明書がインストールされ、認証された接続で SSL が使えるようになりま
す。
証明書リクエストが拒否されると、証明書クライアントはその情報を保管して、リトライが
自動的には行えないようにします。
第5章
155
HTTPS ノードでの作業
証明書の作成と分配
HTTPS 管理対象ノードに対する証明書の管理
証明書管理は、図 5-6 に示す [ OVO ノード証明書リクエスト ] ウィンドウを使って行います。
[OVO ノード証明書リクエスト ] ウィンドウは、次の手順で開きます。
•
[登録ノード]ウィンドウの[アクション]メニューをクリックして[ノード: 追加...]を選択し、
ノード関連のサブマップから [ OVO ノード証明書リクエスト ] メニュー項目を選択します。
または、次の操作を実行します。
•
証明書関連のメッセージを右クリックして、[ OVO ノード証明書リクエスト ] メニュー項目を
選択します。
[ ノード証明書リクエスト ] ウィンドウで実行できるアクション
承諾
選択した証明書リクエストを承諾します。承諾できるのはマップ済みのリクエ
ストだけです。この操作が終了すると、証明書サーバーによって、ホスト名の
リストが自動的に更新されます。
承諾できなかった証明書リクエストは選択中のままで残り、エラーメッセージ
が表示されます。
選択した証明書リクエストの中にまだマップされてないリクエストがあった場
合は、そのリクエストが無視され、マップされていない証明書リクエストは承
諾できないということを知らせるメッセージが表示されます。選択した証明書
リクエストにマップ済みの証明書リクエストが 1 つもない場合は、[ 承諾 ] ボ
タンが灰色になって押せなくなります。
拒否
選択した証明書リクエストを拒否します。この操作が終了すると、証明書サー
バーによってホスト名のリストが自動的に更新されます。証明書リクエストの
拒否は、マップ済みか否かに関係なく行えます。証明書リクエストが選択され
ている状態では、[ 拒否 ] ボタンが常に有効になっています。
削除
選択した証明書リクエストを削除します。この操作が終了すると、証明書サー
バーによってホスト名のリストが自動的に更新されます。どの証明書リクエス
トでも削除できます。証明書リクエストが選択されている状態では、[ 削除 ]
ボタンが常に有効になっています。
すべてのマップされたリクエストを選択
マップ済みの証明書リクエストを選択します。ボタンは常に有効になっていま
す。キューで待機しているリクエストのリストに選択されている証明書リクエ
ストが 1 つもないときは、このボタンを押すと、リストの中にあるマップ済み
のリクエストがすべて選択されます。証明書リクエストが 1 つでも選択されて
いるときにこのボタンを押すと、最初に選択されていたリクエストの中から、
まだマップされていないリクエストがすべて選択解除されます。
156
第5章
HTTPS ノードでの作業
証明書の作成と分配
すべての不明なノードを選択
登録ノードにないノードから発行されたリクエストを選択するときに使いま
す。証明書リクエストが 1 つでも選択されているときにこのボタンを押すと、
最初に選択されていたリクエストの中から、登録ノードに存在しないノードか
ら発行されたすべてのリクエストが選択解除されます。
登録ノードへノードを追加
証明書リクエストの発行元ノードを追加します。このボタンは、次の条件が 1
つでも満たされていれば有効になります。
•
選択した証明書リクエストの中に、まだマップされていないリクエストが
1 つでもある
•
選択した証明書リクエストの中に、そのホスト名がマップ先と異なるだけ
でなく登録ノードにもないリクエストが 1 つでもある
選択した証明書リクエストが 1 つだけの場合は、ホスト名とプラットフォーム
のタイプがすでに設定 / 選択された状態で [ ノードの追加 ] ウィンドウが開き
ます。
複数の証明書リクエストを選択してこのボタンを押すと、確認ボックスがポッ
プアップして表示され、複数のノードが登録ノードに追加されるがそれでよい
かという警告が出されます。
[OK] をクリックすると、ノードが保持エリアに追加されます。ノードが保持
エリアに追加されると、対応するメッセージがメッセージブラウザに送られま
す。すべてのノードが正常に追加されると、重要度が正常域のメッセージが送
られます。正常に追加できなかったノードが 1 つでもあると、重要度が危険域
のメッセージと、保持エリアへの追加に失敗したノードのリストが送られま
す。
[ キャンセル ] をクリックすると、どのノードも保持エリアに追加されませ
ん。
証明書リクエストの項目をダブルクリックしたときは、選択した項目が 1 つだ
けで、しかもその証明書リクエストがまだマップされていないか、あるいはホ
スト名がマップ先と異なるかまたは登録ノードにない場合にのみ、[ ノードの追
加 ] ダイアログが開きます。
指定したノードへマップ
選択した証明書リクエストをマップします。このボタンは、マップされていな
い証明書リクエストを 1 つだけ選択したときと、リクエストのホスト名がマッ
プ先とは異なる場合に有効になります。システムは HTTPS OVO ノードであ
る必要があります。正常にマッピング操作が終了すると、そのマッピング状況
に従ってマップ先のホスト名が変更されます。
第5章
157
HTTPS ノードでの作業
証明書の作成と分配
証明書リクエストを証明書リクエストの発行元とは異なるホスト名のノードへ
マップしようとすると、ポップアップウィンドウが開き、強制操作が必要であ
るという警告が表示されます。
OK
158
動的な更新を停止して、[ ノード証明書リクエスト ] ウィンドウを閉じます。
第5章
HTTPS ノードでの作業
証明書の作成と分配
手作業の分配に使う証明書を作成する方法
証明書の分配は手作業だけですべて行えます。また、そのようにすることで、SSL 通信が有効に
なる前にネットワークを通して証明書関連の情報を送信するという危険性を避けることができま
す。ここで説明する方法では、証明書サーバーで公開鍵と秘密鍵のペアを生成し、ノードシステ
ムに運搬します。この方法は、証明書や鍵をネットワーク上に流したくないというほど高い機密
性が要求される環境でしばしば使われます。
注記
証明書サーバーシステムは、証明書を生成して分配する前にセットアップを完了
し、アクティブにしておく必要があります。
証明書サーバーで作成した証明書を手作業で分配するには、以下の手順を実行します。
1. 特別に大きな環境を扱う場合には、bbc_inst_defaults ファイルを作成して、OVO 管理
サーバー上の管理対象ノードの共通設定を用意することができます。このファイルは次の場
所に存在する必要があります。
/etc/opt/OV/share/conf/OpC/mgmt_sv/bbc_inst_defaults
名前空間 sec.cm.client で、各ノードに次のタイプのエントリーを追加して、ノードの分
配タイプを手動に設定します。
<IP address> : CERTIFICATE_DEPLOYMENT_TYPE = MANUAL
例:
192.168.10.17 : CERTIFICATE_DEPLOYMENT_TYPE = MANUAL
IP アドレスにはワイルドカードを使って、ノードの範囲を指定することができます。
詳細は、次のファイルを参照してください。
/etc/opt/OV/share/conf/OpC/mgmt_sv/bbc_inst_defaults.sampl
また、bbc_inst_defaults ファイルの使用方法の例については、77 ページの「デフォルト
ポートの変更」と 78 ページの「エージェントプロファイル」も参照してください。
2. OVO HTTPS エージェントソフトウェアを手作業でインストールする場合には、117 ページ
の「エージェントをパッケージファイルから手作業でインストールする方法」の手順 2 の説
明に従って、デフォルトのプロファイルを作成してください。
3. 指定したノードに OVO HTTPS エージェントソフトウェアを、GUI を使って、手作業で、
またはリモートで、インストールします。
4. 指定したノードに割り当てられた OvCoreId の値をメモに記録します。OvCoreId は以下の
いずれかのコマンドを使って調べることができます。
第5章
159
HTTPS ノードでの作業
証明書の作成と分配
•
ovcoreid
•
ovconfget sec.core
管理者 GUI を使ってエージェントを新しくインストールすると、新しい OvCoreId が作成
されます。しかし、その管理対象ノードに対する OvCoreId が OVO データベースにすでに
存在する場合には、それが優先的に使われます。
エージェントソフトウェアを手作業でインストールする場合には、プロファイルを作成し、
それとソフトウェアパッケージを管理対象ノードシステムにコピーする必要があります。プ
ロファイルには、OVO データベースから取り出されたオリジナルの OvCoreId が含まれま
す。このプロファイルを次のコマンドを使って、インストールします。
opc_inst -config <profile>
注記
リモートシステムに格納されている OvCoreId は、次のコマンドを使って調
べることができます。
bbcutil -ping http://<remote system>
リモートシステムでは通信ブローカを動作させておく必要があります。
また、OvCoreId は、以下のコマンドを使ってローカルに表示することができ
ます。
ovcoreid
OVO データベース内で管理対象ノード用に格納されている OvCoreId の値
は、次のコマンドを使って表示できます。
opcnode -list_id node_list=<nodename>
5. OVO 管理サーバーシステムで、対象となるノードが OVO 登録ノードに追加されていること
を確認します。
6. 証明書サーバーシステムで OpenView の管理者となって opccsacm コマンド行ツールを使い、
対象となるノードの署名付き証明書とそれに対応する秘密鍵を手作業で作成します。この作
業では、作成したデータを暗号化するためにパスワードを指定する必要があります。
注記
160
対象ノードへ OVO HTTPS エージェントソフトウェアをインストールする前
に証明書を作成する必要がある場合は、以下のコマンドで OvCoreId (coreid
パラメータ ) を指定します。OvCoreId は作成されており、データベースに格
第5章
HTTPS ノードでの作業
証明書の作成と分配
納されています。この OvCoreId は、証明書のファイル名の一部に使われま
す。管理対象ノードがすでに OVO データベースに格納されている場合には、
OvCoreId は次のコマンドで検索できます。
opcnode -list_id node_list=<node name>
この値は、対応するノードシステムに OVO HTTPS エージェントソフトウェ
アをインストールした後で、次のコマンドを使って設定する必要があります。
ovcoreid -set <id> -force
OvCoreId がすでに格納されている場合には、管理対象ノードの値を使いま
す。
リモートシステム上に格納されている OvCoreId は、次のコマンドを使って
調べることができます。
bbcutil -ping http://<remote system>
通信ブローカがリモートシステム上で動作している必要があります。
また、次のコマンドを使って、ローカルに OvCoreId を表示することもでき
ます。
ovcoreid
対象となるノードの証明書を作成するには、OVO 管理サーバーシステムで、次のコマンド
を実行します。
opccsacm -issue -file <filename> [-pass <password>] ¥
-name <full_qual_hostname> -coreid <OvCoreId>
このツールは、作成する証明書を暗号化するためのパスワードを問い合わせてきます。この
パスワードは、後で管理対象ノードシステムに証明書をインポートするときの復号化で必要
となります。
7. bbc_inst_defaults ファイル内に、または次のコマンドで、インストールタイプを MANUAL
に設定します。
ovconfchg -nssec.cm.client -set ¥
CERTIFICATE_DEPLOYMENT_TYPE MANUAL
署名付き証明書とそれに対応する秘密鍵およびルート証明書をすべて含むファイルを、フ
ロッピーディスクまたは他のポータブルメディアにコピーします。
-file オプションが省略されている場合には、このファイルは次のディレクトリに置かれて
います。
第5章
161
HTTPS ノードでの作業
証明書の作成と分配
/<OvDataDir>/temp/OpC/certificates
ファイル名の形式は次のとおりです。
<hostname>-OvCoreId.p12
8. ノードシステムに移動し、次のコマンドを使ってローカルでエージェントを停止させます。
ovc -stop
9. コマンド行ツールの ovcert を使って、ポータブルメディアから証明書、信頼できるルート証
明書、秘密鍵をインストールします。証明書をインストールする時にパスワードが要求され
るので、手順 6 で指定したパスワードを入力します。
次のコマンドを実行して、証明書をインポートします。
ovcert -importcert -file <file created in step 6>
ツールから、手順 6 で指定したパスワードを問い合わせてきます。
注記
秘密鍵の入っているメディアは、資格のある人だけが使えるように厳しく管
理する必要があります。
10. インストールが終了したら、管理対象ノードから証明書インストールファイルを削除し、さ
らにポータブルメディアの内容を削除するか、ポータブルメディアを安全な場所に保管しま
す。
11. 次のコマンドを使って、エージェントをローカルに起動します。
ovc -start
12. 証明書サーバーシステムから証明書インポート用に作成したファイルを削除します。
162
第5章
HTTPS ノードでの作業
証明書の作成と分配
インストールキーを使って証明書を手作業で分配する方法
インストールキーを使って証明書を手作業で分配する方法には、秘密鍵がその所属システムから
外には出ないという利点があります。しかし、ノードシステムに証明書をインストールしてしま
うまでは、いくつかのセキュリティ関連データをネットワーク上に流す必要があります。
注記
証明書サーバーシステムは、証明書を作成して分配する前にセットアップしてお
く必要があります。
注記
OVO 管理サーバーで手作業で証明書を作成し、インストールキーを使って証明書
をインストールした場合には、OVO エージェントソフトウェアを管理対象ノード
システムに手作業でインストールする必要があります。詳細は、116 ページの
「手作業によるエージェントのインストール」を参照してください。
インストールキーを使って証明書を手作業で分配するには、次の手順を実行します。
1. 証明書サーバーシステムで OpenView の管理者となり、新しいインストールキーの作成を起
動します。作成したキーを暗号化するためのパスワードを用意します。
opccsacm -geninstkey -file <filename> [-pass <password>]
証明書サーバーは、作成したキーをインストールキーのレポジトリに追加するとともに、い
くつかの管理情報とともにファイルに書き込みます。
2. インストールキーの情報が入ったこのファイルを、フロッピーディスクまたは他のポータブ
ルメディアにコピーします。
3. 対象となるノードシステムのある場所に移動し、ovcert コマンド行ツールを使って、新しい
証明書リクエストの発行を起動します。新しい公開鍵と秘密鍵のペアが生成されます。次の
コマンドを実行します。
ovcert -certreq -instkey <filename>
暗号化されたリクエストが証明書サーバーに送信されます。
証明書サーバーは、レポジトリにあるキーを使ってリクエストを復号化します。正しいインス
トールキーが使われていれば、証明書サーバーはそのリクエストを自動的に承諾し、署名付きの
証明書をノードに返します。この時点で、インストールキーがレポジトリから削除されます。無
効なインストールキーが使われていた場合は、リクエストが自動的に拒否されます。
第5章
163
HTTPS ノードでの作業
複数の並列設定サーバー
複数の並列設定サーバー
共有コンポーネントでポリシーを使うことができます。複数の OV 製品がエージェント上でポリ
シーを独自の考え方で利用して動作します。HTTPS 管理対象ノードでは、複数の並列設定サー
バーがサポートされます。
ここで複数の並列設定サーバーを使う状況を説明しておきます。サービスプロバイダは、一連の
顧客システムのハードウェアとオペレーティングシステムを管理します。顧客自身は、同じノー
ドグループで稼動しているアプリケーションを管理します。サービスプロバイダと顧客は OVO
管理サーバーを使って、これらのシステムを管理します。ソリューションは以下の形態で導入さ
れます。
•
サービスプロバイダと顧客は独自の証明書を作成するが、信頼関係については合意してい
る。そのため、エージェントは両方の OVO 管理サーバーからのアクションと設定リクエス
トを受け入れることができる。
•
サービスプロバイダと顧客は担当マネージャテンプレート (mgrconf) ファイルについて合意
している。一方が一次マネージャとなり、他方が専門技術センターになる。両方とも承認済
みマネージャとしてリストされる。
•
専門技術センターには、設定の配布も許可される。担当マネージャファイルで設定された
メッセージターゲット規則と条件が一致する特定の属性を持ったすべてのポリシーを提供で
きる。それにより、関連メッセージが専門技術センターに送信され、それ以外は一次マネー
ジャに送信される。
HTTPS 管理対象ノードは、複数の設定サーバーをサポートすることができます。このサーバー
は一次マネージャです。設定サーバーは (opcragt -primmgr) で切り換えることができます。こ
れはバックアップ管理サーバーのコンセプトです。しかし、バックアップ管理サーバーと一次管
理サーバーの設定が少しでも異なる場合には、テンプレートやインストルメンテーションが配布
されたときのエージェントに対する設定もまた異なる場合があります。一次管理サーバーから配
布されたインストルメンテーションには変更は発生しません。ただし、バックアップ管理サー
バーから新たなインストルメンテーションファイルが配布されるとエージェントに追加されま
す。一次管理サーバーおよびバックアップ管理サーバーが同じ所有者文字列を使用している場
合、またはポリシーが同一の場合には、そのポリシーだけが書き換えられます。エージェントに
ある他のすべてのポリシーは、異なる所有者に属しているため変更は発生しません。ポリシーが
同一かどうかを判断する方法は、次の 2 つです。
•
ポリシー ID が同一かをチェックする。
•
ポリシー名、ポリシータイプ、およびポリシーバージョンは同一で、ポリシー ID が異なっ
ているかをチェックする。
164
第5章
HTTPS ノードでの作業
複数の並列設定サーバー
ポリシーを削除できるのはその所有者だけです。ポリシーの削除については、次のような重要な
状況を考慮する必要があります。
ここでバックアップ管理サーバーにおける状況を考えてみます。最初に 一次管理サーバー (A) が
エージェント (G) にポリシー (PA) を 配布します。ポリシー (PA) の所有者は (A) です。
次に、バックアップ管理サーバー (B) は、同一のポリシー (PA) を同一のエージェント (G) に配
布します。同一ポリシーが配布されたため、所有者が (A) の既存のポリシー (PA) は削除され、
バックアップ管理サーバー (B) からのポリシーが再インストールされます。再インストールされ
たポリシー (PA) の所有者は (B) になります。
最後に、一次管理サーバー (A) が、ポリシー (PA) の割り当てを解除し同一のエージェント (G) に
テンプレートを配布します。
ポリシー (PA) の所有者は (B) なので、結果的にはエージェント (G) から削除されません。この場
合、バックアップ管理サーバー (B) だけがポリシーを削除できます。
OVO の専門技術センターコンセプトでは、特定のタイプのメッセージを専用サーバーに転送で
きます。しかし、専門技術センターはメッセージ処理を担当しており、設定の配布は管理できま
せん。バックアップ管理サーバーは担当マネージャテンプレート (mgrconf) ファイルの
secondary-manager 文で定義されます。専門技術センターは、メッセージターゲット規則と
action-allowed-manager エントリーで定義されます。
OpenView の担当マネージャコンセプトは、以下の用語に基づいています。
•
OV アクセス権
OV コンポーネントにはアクセス権が定義できます。アクションを実行したり、ファイルを
配布したり、設定を行なうための権利です。これらの権利は、事前に設定された OpenView
の役割にマップされます。たとえば、管理対象ノードへのリモートアクセスを禁止するとい
うように 設定情報を変更して、マッピングを変更することができます。
•
OV で定義済みの役割の引き継ぎ
OVO 管理サーバーは、OpenView に定義されている役割を引き継ぐことができます。管理
サーバーと役割とのマッピングは、担当マネージャのポリシーと初期マネージャの設定で定
義されます。これによって、担当マネージャポリシーの配布が実行できます。
•
ローカルユーザーの役割
ローカルユーザーは、適切なシステム権限 ( たとえば、root) が与えられれば、すべての権
利を持ちます。
•
初期マネージャまたは承認済みマネージャの役割
第5章
165
HTTPS ノードでの作業
複数の並列設定サーバー
このマネージャには、必要に応じてリモートアクセスができるように、すべての権利が与え
られて、インストール時に設定されます。このノードはセキュリティ名前空間で、MANAGER
と MANAGER_ID を設定することで定義されます。初期マネージャは 1 つしか存在できませ
ん。
•
二次マネージャの役割
二次マネージャは、アクションの実行権、設定の配布権など、すべての権利を持ちます。担
当マネージャポリシーには、複数の二次マネージャが定義できます。初期マネージャと二次
マネージャによって、設定サーバーのグループを構成できます。
•
アクションが許可されたマネージャの役割
アクションが許可されたマネージャは、アクションの実行権しか持ちません。担当マネー
ジャのポリシーには、アクションが許可された複数のマネージャを定義できます。
•
定義済みの認証局
インストール時にはセキュリティ名前空間 sec.cm.client に CERTIFICATE_SERVER が設定
されます。これは、管理対象ノードの有効な登録済みの証明書を取得するときにアクセスす
る、認証局を持つシステムを定義しています。
複数の設定サーバーのセットアップ
HTTPS ノードに配布されるポリシーには、所有者属性があります。
OVO:<server_fully_qualified_name>
そのため、2 つの OVO 管理サーバーが、同一エージェントにポリシーを分配しても問題は発生
しません。
バックアップ管理サーバーが必要な場合には、opc 名前空間にある次の設定情報を使って、デ
フォルトの所有者文字列を書き換えます。
OPC_POLICY_OWNER
それにより、一次管理サーバーとバックアップ管理サーバーは、同じ所有者文字列を持つことに
なります。バックアップ管理サーバーと専門技術センターを混在させる状況も設定できます。つ
まり、バックアップ管理サーバーには同じ所有者文字列を持たせ、専門技術センターには異なる
所有者文字列を持たせます。ただし、管理サーバーは、所有者文字列を 1 つしか持てないことに
注意してください。そのため、マネージャを特定の OVO ドメインのバックアップサーバーとし
て動作させ、同時に別の OVO ドメインの専門技術センターとして動作させることはできませ
ん。
166
第5章
HTTPS ノードでの作業
複数の並列設定サーバー
ローカルポリシーユーティリティ ovpolicy は、デフォルトではシステム上のすべてのポリシー
を変更できます。特定の所有者に属するポリシーを選択する場合には、-owner オプションを指
定します。
すべての所有者の全ポリシーを表示するには、次のコマンドを使います。
ovpolicy -l
my_srv だけのポリシーを表示するには、次のコマンドを使います。
ovpolicy -l -owner OVO:<my_srv_full_qualified_name>
ovpolicy は、ポリシーの所有者文字列を変更するために使うこともできます。たとえば、管理
対象ノードへの設定ファイルの再配布を行なわずに OVO 管理サーバーの所有者文字列を変更す
る場合などです。
ポリシーはその ID 、ポリシー名、ポリシータイプおよびポリシーバージョンによって識別され
ます。ID が存在すれば、ID は名前とポリシータイプを加えたものより、高い優先順位を持ちま
す。
ポリシーが同一であるかは、次のいずれかの方法で判断できます。
•
同一のポリシー ID
•
ポリシー名、ポリシータイプ、およびポリシーバージョンは同一であるが、ポリシー ID は
異なる。
同一のポリシーは、ポリシー所有者とは関係なく複数のサーバーで変更できます。
こうすることで、エージェントにインストールする同一ポリシーのインスタンス数を抑制し、同
一の問題に対して複数のメッセージを発生させないようにできます。
同じ設定データを配布するために複数のサーバーが使われている場合には、それらはバックアッ
プ管理サーバーとして動作し、それらのデータは同期させる必要があります。そのために、1 つ
のサーバーを設定配布用に割り当て、このサーバーのデータをダウンロードして、その他のサー
バーにアップロードします。
複数の設定サーバーをセットアップするには、57 ページの「証明書サーバーが複数個ある環境」
の手順を参照し、最初に複数の設定サーバー間の信頼を確立してから設定情報をダウンロードし
てアップロードします。設定情報をダウンロードしてアップロードする場合は、次の手順を参照
してください。
以下の手順を実行して、管理サーバーの登録ノード設定情報をダウンロードして、バックアップ
管理サーバーにアップロードします。
1. 次のようなディレクトリ階層を作成します。
mkdir -p /tmp/<manag_server_name>/C
第5章
167
HTTPS ノードでの作業
複数の並列設定サーバー
2. ファイル download.dfs を作成し、そのファイルに NODE_BANK の行を追加します。
vi /tmp/<manag_server_name>/C/download.dfs
NODE_BANK;
3. ダウンロードを開始します。
opccfgdwn -backup -force download.dfs /tmp/<manag_srv_name>
4. ダウンロードした設定データの tar アーカイブを作成し、それを ftp を使ってバックアップ
管理サーバーに転送します。
tar cvf /tmp/<manag_server_name>.tar /tmp/<manag_srv_name>
バックアップ管理サーバーで、切り換え対象となるすべてのノードをインポートします。設定情
報をアップロードすることで、管理対象ノードの OvCoreId もアップロードされます。
1. 前の手順でバックアップ管理サーバーに転送した tar アーカイブを展開します。
tar xvf /tmp/<managserver_name>.tar
2. ノードをバックアップ管理サーバーにアップロードします。サーバープロセスを停止し、次
のコマンドを使って設定情報をアップロードします。
opccfgupld -add -subentity /tmp/<manag_server_name>
3. アップロードの完了した HTTPS エージェントノードのすべての OvCoreId を、次のコマン
ドを使って表示します。
opcnode -list_id node_list=<https_agent_node_name>
4. アップロードの完了したすべての HTTPS エージェントノードで、次のコマンドを実行しま
す。
opcsw -i <https_agent_node_name>
5. アップロードの完了したノードをノードグループに追加します。そうしないとメッセージが
表示できません。
専門技術センターの環境がある場合には、所有者属性を持った担当マネージャポリシーは、1 つ
の OVO 管理サーバーからのみインストールできます。エージェントは 1 つの担当マネージャポ
リシーしかサポートできません。
所有者の概念については、次の例によって複数の設定サーバー間での処理方法が理解できます。
ここに管理サーバー A と管理サーバー B、ポリシー X とポリシー Y があるとします。ポリシー
X を管理サーバー A と 管理サーバー B の両方からエージェントに新たに割り当てます。ポリ
シー Y は、同じエージェントに管理サーバー A からだけ新たに割り当てます。
168
第5章
HTTPS ノードでの作業
複数の並列設定サーバー
サーバー A とサーバー B が使用する所有者文字列が異なる場合。サーバー A が使用する所有者
文字列は「A」で、サーバー B が使用する所有者文字列は「B」です。
1. 設定情報を分配します。
a. サーバー A から、ポリシーを差分分配モードおよび強制分配モードで分配した場合 :
ポリシー X と ポリシー Y を配布し所有者は「A」となります。
b. サーバー B から、ポリシーを差分分配モードで分配した場合 :
ポリシー X は変更されません。ポリシー X はインストール済みなので、その状態は変わ
らず所有者「A」のままです。ポリシー Y も変更されません。所有者は「A」のままで
す。
サーバー B から、ポリシーを強制分配モードで分配した場合 :
ポリシー X は上書きされ所有者は「B」となります。
ポリシー Y は変更されません。所有者は「A」のままです。
2. ポリシー X の割り当てを解除し分配を実行します。
a. サーバー A から、ポリシーを差分分配モードおよび強制分配モードで分配した場合 :
ポリシー X の所有者が「A」の場合、ポリシー X はエージェントから削除されます。
ポリシー X の所有者が「B」の場合、所有者文字列が異なるためポリシー X の状態は変
わりません。
b. サーバー B から、ポリシーを差分分配モードおよび強制分配モードで分配した場合 :
ポリシー X の所有者が「A」の場合、所有者文字列が異なるためポリシー X の状態は変
わりません。
ポリシー X の所有者が「B」の場合、ポリシー X はエージェントから削除されます。
3. サーバー A から差分分配モードおよび強制分配モードで、ポリシー Y を割り当て解除しま
す。
ポリシー Y は削除されます。
サーバー A とサーバー B が使用する所有者文字列が「A」で同一の場合
1. 設定情報を分配します。
a. サーバー A から、ポリシーを差分分配モードおよび強制分配モードで分配した場合 :
ポリシー X と ポリシー Y を配布し、所有者は「A」となります。
第5章
169
HTTPS ノードでの作業
複数の並列設定サーバー
b. サーバー B から、ポリシーを差分分配モードで分配した場合 :
ポリシー X は変更されず所有者は「A」のままです。ポリシー Y は削除されます。
サーバー B から、ポリシーを強制分配モードで分配した場合 :
ポリシー X は上書きされますが所有者は「A」のままです。ポリシー Y は削除されます。
2. ポリシー X の割り当てを解除し分配を実行します。
a. サーバー A から、ポリシーを差分分配モードおよび強制分配モードで分配した場合 :
ポリシー X は削除されます。
b. サーバー B から、ポリシーを 差分分配モードおよび強制分配モードで分配した場合 :
ポリシー X は削除されます。
3. サーバー A から差分分配モードおよび強制分配モードで、ポリシー Y を割り当て解除しま
す。
ポリシー Y は削除されます。
複数のサーバーがある環境では、差分分配モードと強制分配モードを使うことができます。強制
分配モードを使うと、ポリシーが異なる管理サーバーによって所有されていても呼び出した所有
者のすべてのポリシーおよび同一のポリシーすべてが書き換えられます。同一でないポリシーの
場合、差分分配モードと強制分配モードでは、配置解除されているポリシーだけが同一の所有者
によって削除されます。HTTPS ノードのすべての OpenView アプリケーションからすべてのポ
リシーを削除して再配置するには、次のコマンドを使います。
opcragt -distrib -purge -templates <nodename>
インストルメンテーションの配布は累積的に行なわれます。つまり、差分インストールと強制イ
ンストールのいずれでも、エージェントから削除されるファイルはなく、既存の設定情報のアッ
プデートと新規の設定情報の追加だけが行なわれます。
エージェントのインストルメンテーションディレクトリのすべての設定データを削除して再イン
ストールする場合には、次のコマンドを使います。
opcragt -distrib -purge -actions -monitors -commands <nodenames>
OVO エージェントの名前空間 eaagt には OPC_PRIMARY_MGR と呼ばれる設定があります。次の
コマンドを実行すると、ここには OVO 管理サーバーのホスト名が設定されます。
opcragt -primmgr
OPC_PRIMARY_MGR が設定されていなかったり、不当な設定だった場合には、OVO 管理サーバー
は MANAGER の設定で指定されます。不当な設定とは、OPC_PRIMARY_MGR が、二次マネージャ、
アクションが許可されたマネージャ、初期マネージャのいずれとしても指定されていないことを
170
第5章
HTTPS ノードでの作業
複数の並列設定サーバー
意味します。OPC_PRIMARY_MGR はメッセージ関連の設定であり、メッセージを OVO 管理サー
バーに送信するために担当マネージャポリシーのメッセージターゲット規則で使われる
$OPC_PRIMARY_MGR 変数へマップされます。
OVO が管理する既存の環境にバックアップ管理サーバーを追加するときには、次の 2 つの状況
を考慮する必要があります。
•
一次管理サーバー A とバックアップ管理サーバー B があり、一次管理サーバー A をバック
アップ管理サーバー B に切り替えました。一次管理サーバー A とバックアップ管理サー
バー B は同期していると仮定します。
バックアップ管理サーバー B の所有者文字列を保持することにしました。つまり一次管理
サーバー A の所有者文字列は、バックアップ管理サーバー B の所有者文字列と異なること
になります。一次管理サーバー A とバックアップ管理サーバー B が同期している場合には、
バックアップ管理サーバー B で、mgrconf (MoM 設定 ) および nodeinfo を除いてすべての
ポリシーを管理できます。mgrconf と nodeinfo はその所有者のみが変更または削除できま
す。一次管理サーバー A が、mgrconf および nodeinfo を配布しているので、これらの 2
つのポリシーは、一次管理サーバー A が所有者です。 一次管理サーバー A だけがこれらのポ
リシーを更新する権利を持っています。ポリシーを変更する必要がある場合には、ovpolicy
コマンド行ツールを使って、ポリシーヘッダーにある所有者属性を手動で変更します。
管理サーバーシステム上で、管理対象ノードにある mgrconf および nodeinfo の所有者属性
をリモートで変更したい場合には、次のコマンドを実行します。
nodeinfo の場合
ovpolicy -setowner ¥
OVO:<your_full_qualified_mgmt_server_name> -host ¥
<your_managed_node_name> -poltype configsettings
mgrconf の場合
ovpolicy -setowner ¥
OVO:<your_full_qualified_mgmt_server_name> -host ¥
<your_managed_node_name> -poltype mgrconf
管理対象ノード上で、mgrconf および nodeinfo の所有者属性をローカルで変更したい場合
には、次のコマンドを実行します。
nodeinfo の場合
ovpolicy -setowner ¥
OVO:<your_full_qualified_mgmt_server_name> -poltype ¥
configsettings
第5章
171
HTTPS ノードでの作業
複数の並列設定サーバー
mgrconf の場合
ovpolicy -setowner ¥
OVO:<your_full_qualified_mgmt_server_name> -poltype ¥
mgrconf
次のコマンドを実行することによって、変更結果を確認できます。
リモートの場合
ovpolicy -l -host <your_managed_node_name> -owner ¥
OVO:<your_full_qualified_mgmt_server_name>
ローカルの場合
ovpolicy -l -owner ¥ OVO:<your_full_qualified_mgmt_server_name>
管理対象ノードにあるポリシーが、どの管理サーバーに属しているかの全体像を知りたい場
合には、次のコマンドを実行します。
リモートの場合
ovpolicy -l -host <your_managed_node_name> -level 2
ローカルの場合
ovpolicy -l -level 2
•
一次管理サーバー A とバックアップ管理サーバー B が同期していない場合に、所有者文字
列が異なっていると、管理対象ノードにおいて予想以上の数のポリシーが存在することにな
ります。これはポリシーの所有者しかポリシーを削除できないからです。164 ページの「複
数の並列設定サーバー」も参照してください。ポリシーを削除するには、管理対象ノードで
ovpolicy -remove コマンドを実行します。
この場合、バックアップ管理サーバーでも同じ所有者文字列を使うと便利です。配布された
すべてのポリシーを管理できるだけでなくエージェントに予想以上にポリシーが残ることに
はなりません。しかし、上述したように mgrconf および nodeinfo ポリシーについては、所
有者文字列を変更してからこれらのポリシーを配布した場合を除き、考慮をする必要があり
ます。一次管理サーバーは、常にこれらの 2 つのポリシーの所有権を保持しています。ポリ
シーを変更したり削除できるのはその所有者だけです。
当社は、一次管理サーバーとバックアップ管理サーバーの両方で同一の所有者文字列を使う
ことを強く推奨します。一次管理サーバーに所有者文字列を保持し、一次管理サーバーの所
有者文字列をバックアップ管理サーバーに設定してください。
172
第5章
HTTPS ノードでの作業
複数の並列設定サーバー
OVO 7 と OVO 8 の相違と下位互換性
MoM の概念における変更点と下位互換性に関する情報は、以下のとおりです。
•
二次マネージャは HTTPS エージェントでのみアクションの実行権を持ちます。OVO 7.x の
担当マネージャファイルは、変更なしに、OVO 8.1 エージェントで使うことができます。
•
二次マネージャは、HTTPS エージェントでは一次マネージャを切り換えることなく設定
データを配布できます。DCE エージェントでは最初に次のコマンドを使って一次マネー
ジャを切り換える必要があります。
opcragt -primmgr
マネージャのメッセージ割当てでは、opcragt -primmgr は一次メッセージターゲットマ
ネージャを変更します。
•
設定情報の配布を行なう場合に、二次サーバーから新しい設定が配布 (opcragt -primmgr
コール ) されても、HTTPS エージェントから既存の設定情報は削除されません。DCE エー
ジェントの場合には、一次サーバーと二次サーバーが同じように設定されていないときに
は、削除される可能性があります。
•
ノードに割り当てられたテンプレートがない場合、サーバーは DCE エージェントのすべて
の設定情報を削除しますが、HTTPS エージェントについては、別のサーバーと同じ所有者
文字列を使わなければ、何も変更しません。一次マネージャではないマネージャから設定の
配布 (opcragt -primmgr コール以外 ) を実行する場合、DCE ノードは変更されません。
エージェントが混在する環境では、1 つの設定サーバーだけを使う必要があります。この
サーバーでは、データを配布する前に、1 回だけ opcragt -primmgr コールを実行する必要
があります。HTTPS エージェントだけの環境では、設定サーバーとメッセージターゲット
サーバーが分離しているので、柔軟性が高くなっています。
•
すべての OVO 7.x MoM テンプレートは、HTTPS エージェントでも使うことができます。
ただし、HTTPS エージェントは OVO 7.x 管理サーバーとは通信できません。そのため、
HTTPS エージェントの担当マネージャポリシーで参照されるすべての OVO 管理サーバー
は、OVO 8.1 にアップグレードする必要があります。管理サーバーには、OVO 7.x から
OVO 8.1 への移行をサポートするための MoM 設定ファイル allnodes.bbc が用意されてい
ます。このファイルは、HTTPS ノードへのデータの配布に関して、allnodes ファイルよ
り高い優先順位を持ちます。allnodes.bbc では OVO 8.1 の管理サーバーだけを含む必要が
あります。すべてのサーバーがアップデートされれば、allnodes に移すことができます。
•
担当マネージャポリシーから参照されるすべての OVO 管理サーバーを登録ノードに追加し、
そのコア ID をデータベースに追加しておく必要があります。OvCoreId は担当マネージャポ
リシーの配布時に担当マネージャポリシーに自動的に追加されます。HTTPS 管理対象ノー
ドでは、承諾された OvCoreId に基づいて、サーバーの承諾が行なわれます。
第5章
173
HTTPS ノードでの作業
複数の並列設定サーバー
•
174
HTTPS ノードで MoM 環境を構築した場合には、いくつかの証明書関連の設定情報を作成
する必要があります。詳細は、57 ページの「証明書サーバーが複数個ある環境」を参照して
ください。
第5章
A HTTPS ベース通信のトラブルシューティン
グ
付録 A
175
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
トラブルシューティング
たとえば、メッセージブラウザにメッセージが到着しないとか、ソフトウェアやインストルメン
テーションが配布されないといったような事態が発生して、OVO/UNIX 管理サーバーと
HTTPS エージェントとの間で行っていた通信が中断されたと思われる場合は、以降で説明する
適切なトラブルシューティングの手順を実行します。
以下の対処方法に関する説明に進む前に、新しい HTTPS エージェントとそこで行われる通信の
概念 ( 証明書など ) をよく理解してください。
ここで説明するガイドラインでは、OVO 管理サーバー、認証局サーバーと OVO 管理対象ノー
ドエージェント間で発生する HTTPS 通信の問題に焦点を当てて、考えられる対処方法を説明し
ます。
説明の前提として、OVO HTTPS エージェントソフトウェアがインストールされているにもか
かわらず、OVO 管理サーバーと OVO 管理対象ノードとの間で一方向または双方向で問題が発
生する場合を扱います。
ほとんどの場合、OVO 管理サーバーと認証局サーバーは同じシステムにインストールされてい
ます。
OVO 8.1 管理サーバーと OVO HTTPS エージェントが通信する際に発生する問題のトラブル
シューティングには、次の方法があります。
•
ツールを使ったトラブルシューティング
•
ロギング
•
プロセスのトラブルシューティング
ツールを使ったトラブルシューティング
HTTPS ベースのアプリケーションに対する ping の実行
HTTPS ベースのアプリケーションに対して ping を実行することで、そのアプリケーションが
動作していてレスポンス可能な状態にあるかどうかをテストすることができます。また ping は、
アプリケーションで SSL が有効になっているかどうかを調べるために使うこともできます。
bbcutil ユーティリティでは、このために、コマンド行パラメータ -ping が用意されています。
このパラメータを指定することにより、HTTPS ベースの HP OpenView アプリケーションに対
して ping を実行することができます。
176
付録 A
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
具体的には、次のコマンドを使って、対象となる HTTPS ベースアプリケーションを指定し、
ping を実行します。
<OvInstallDir>/bin/bbcutil -ping [<hostname_or_ip_addr>] [count]
たとえば、次のように実行します。
HTTP
bbcutil -ping http://...
HTTPS
bbcutil -ping https://...
このコマンドを実行すると、<hostname_or_ip_addr> で指定したノードで通信サービスが動作
しているかどうかが調べられます。ホスト名 ( または IP アドレス ) を指定しないと、localhost
が指定されたものと見なされます。ホスト名 ( または IP アドレス ) の後にオプションで繰り返
し回数を指定できます。繰り返し回数を指定すると、その分だけ ping が繰り返し実行されます。
コマンド行パラメータの詳細は、bbcutil のマンページを参照してください。
HTTPS ベースアプリケーションの現在のステータスの表示
指定した場所の HTTPS ベースアプリケーションに対して、現在のステータスを表示するように
リクエストすることができます。
アプリケーションを指定して照会を行うには、次のコマンドを使います。
bbcutil -status <hostname_or_ip_addr:port>
このコマンドを実行すると、<hostname_or_ip_addr:port> で指定した場所 ( ホスト名 : ポー
ト ) の通信サーバーに対して、そのサーバーの現在のステータスの詳細が照会されます。
コマンド行パラメータの詳細は、bbcutil のマンページを参照してください。ポートを指定しな
いと、通信ブローカのポート番号が使われます。
通信ブローカに登録されているすべてのアプリケーションの表示
指定した場所の通信ブローカに対して、そこに登録されているすべてのアプリケーションを表示
するようにリクエストすることができます。
通信ブローカを指定してそこに登録されているすべてのアプリケーションを表示するようにリク
エストするには、次のコマンドを使います。
bbcutil -registrations|-reg <hostname_or_ip_addr>
このコマンドを実行すると、<hostname_or_ip_addr> で指定したノードの通信ブローカに対し
て、登録されているすべてのアプリケーションを表示するリクエストが送られます。ホスト名 (
または IP アドレス ) を省略すると、localhost が指定されたものと見なされます。
通信ブローカのコマンド行パラメータの詳細は、bbcutil のマンページを参照してください。
付録 A
177
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
what 文字列
どの実行形式プログラムにも、UNIX の what コマンドで検索できる詳細な文字列が含まれてお
り、インストールされている HTTPS ベース通信ソフトウェアのバージョンを正確に調べること
ができます。また、Microsoft Windows の実行形式プログラムにも、標準的なプロパティ文字列
が含まれています。
HTTPS ノードにインストールされている全 OV ファイルセットの一覧表示
インストールされている OpenView の製品とコンポーネントの一覧は、ovdeploy ツールを使っ
て表示することができます。その情報は、次の 3 レベルで表示できます。
•
インベントリの基本情報
•
インベントリの詳細情報
•
インベントリのネイティブ情報
以降の項で、インベントリ一覧の表示方法を説明するとともに、その出力例を示します。
インベントリの基本情報
インベントリの基本情報を表示するには、次のコマンドを入力します。
ovdeploy -inv -host <hostname>
次にその例を示します。
ovdeploy -inv -host hp_System_002
NAME
ARCHITECTURE
HP OpenView HTTP Communication
Windows 4.0 5.0 5.1 5.2
HP OpenView Deployment
Windows 4.0 5.0 5.1 5.2
HP OpenView Security Certificate Management
Windows 4.0 5.0 5.1 5.2
HP OpenView Security Core
Windows 4.0 5.0 5.1 5.2
...
178
VERSION
TYPE
05.00.070
package
02.00.070
package
01.00.070
package
02.00.070
package
付録 A
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
インベントリの詳細情報
インベントリの詳細情報を表示するには、次のコマンドを入力します。
ovdeploy -inv -all -host <hostname>
次にその例を示します。
ovdeploy -inv -all -host hp_System_002
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<inventory xmlns=">http://openview.hp.com/xmlns/depl/2003/inventory">
<host>hpspi002.bbn.hp.com</host>
<date>Thursday, October 30, 2003 12:24:48 PM</date>
<package>
<name>HP OpenView HTTP Communication</name>
<version>05.00.070</version>
<systemtype>IA32</systemtype>
<ostype>Windows</ostype>
<osvendor>MS</osvendor>
<osversion>4.0 5.0 5.1 5.2</osversion>
<osbits>32</osbits>
<nativeinstallertype>msi</nativeinstallertype>
</package>
<package>
<name>HP OpenView Deployment</name>
<version>02.00.070</version>
<systemtype>IA32</systemtype>
...
インベントリのネイティブ情報
インベントリのネイティブ情報を表示するには、次のコマンドを入力します。
ovdeploy -inv -it native -host <hostname>
次にその例を示します。
ovdeploy -inv -it native -host hp_System_002
NAME
WebFldrs XP
HP OpenView Core Library
HP OpenView Certificate Management Client
HP OpenView HTTP Communication
付録 A
VERSION
9.50.5318
2.50.70
1.0.70
5.0.70
179
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
ActivePerl 5.6.1 Build
HP OpenView Deployment
Microsoft FrontPage Client - English
633 5.6.633
2.0.70
7.00.9209
標準の TCP/IP ツール
SSL が有効になっていない場合には、telnet のような標準の TCP/IP ツールを使うことで、HP
OpenView の HTTPS ベースアプリケーションにアクセスできます。telnet を使って HTTPS
ベースアプリケーションに対する ping を実行するには、次のコマンドを実行します。
telnet に対して PING の行を入力した場合は、改行を 2 回押す必要があります。
telnet セッションを終了させるには、Ctrl+D を押した後、Return を押します。
telnet <host> <port>
PING /Hewlett-Packard/OpenView/BBC/ping HTTP/1.1
出力は次のようになります。
HTTP/1.1 200 OK
content-length: 0
content-type: text/html
date: Thu, 08 Aug 2002 08:20:24 GMT
senderid: fd7dc9c4-4626-74ff-9e5a09bffbae
server: BBC X.05.00.01.00; ovbbccb 05.00.100
「HTTP status 200 OK」という行が表示されれば、HTTPS ベースアプリケーションがリクエス
トを認識して、正常にレスポンスしています。これ以外のステータスが報告された場合は、リク
エストにエラーがあるか、またはその他にエラーがあったことを意味しています。
エラーコードの一覧は、次の Web ページを参照してください。
http://www.w3.org/Protocols/rfc2616/rfc2616.html
時間のかかる RPC コール
RPC コールに時間がかかってデフォルトのタイムアウト時間 (5 分 ) が過ぎると、次のエラー
メッセージが表示されることがあります。たとえばポリシーをインストールしている時は次のよ
うに表示されます。
エラー :
ホスト '<hostname>' に接続している間に、一般的な I/O の例外が発生しました。
(xpl-117) データを待っている間にタイムアウトが発生しました。
または
180
付録 A
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
エラー :
ホスト '<hostname>' 上で設定サーバーが動作していません。
設定サービスが動作状態にあるかどうかを調べてください。
(bbc-71) アドレスに対してアクティブなサーバープロセスがありません :
https://<hostname>/com.hp.ov.conf.core/bbcrpcserver
このような状況は、たとえば、PolicyPackage インタフェースを使って OvConf から 1000 個も
のポリシーをインストールしたり、接続やターゲットマシンが遅かったりした場合に発生しま
す。
こうした事態は、次のように通信のタイムアウト ( レスポンスのタイムアウト ) 値を変更するこ
とで避けることができます。
ターゲットシステムで、次のコマンドを使って必要なタイムアウト値を入力します。
ovconfchg -ns bbc.cb -set RESPONSE_TIMEOUT <seconds>
OVO 管理サーバーで、次のコマンドを使って必要なタイムアウト値を入力します。
ovconfchg -ns bbc.http.ext.conf -set RESPONSE_TIMEOUT <seconds>
注記
どちらのノードでも、RESPONSE_TIMEOUT パラメータを設定する必要がありま
す。
ロギング
セキュリティの規則に違反したエラーは、ログファイルに記録されます。HTTPS ベースサー
バーの場合は、ロギングを有効にしておくと、これ以外にすべてのクライアントアクセスもログ
に記録されます。
クライアントアクセスをログファイル /var/opt/OV/datafiles/System.bin にすべて記録す
るには、次のコマンドを使って LOG_SERVER_ACCESS パラメータの値を設定します。
ovconfchg -ns bbc.cb -set LOG_SERVER_ACCESS true
このように設定すれば、通信ブローカに対するアクセスをすべてログに記録することができま
す。ログを表示するには、次のテキストファイルを開きます。
<OvDataDir>/log/System.txt
これ以外にすべての OV 通信ブローカに対するアクセスもログに記録する場合は、次のコマンド
を使います。
ovconfchg -ns bbc.http -set LOG_SERVER_ACCESS true
さらに、設定 / 配布アプリケーションに対するクライアントからのアクセスもすべてログに記録
する場合は、次のコマンドを使います。
付録 A
181
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
ovconfchg -ns bbc.http.ext.conf -set LOG_SERVER_ACCESS true
182
付録 A
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
管理サーバーと HTTPS エージェントとの間で発生する通信の問題
通信の問題が発生した領域を次のように分けて対処します。
•
183 ページの「基本ネットワークのトラブルシューティング」
•
185 ページの「基本 HTTP 通信のトラブルシューティング」
•
192 ページの「HTTP 通信における認証と証明書のトラブルシューティング」
•
197 ページの「OVO 通信のトラブルシューティング」
基本ネットワークのトラブルシューティング
基本ネットワークのトラブルシューティングでは、次のコマンドを使います。
ping
<SYSTEMPATH>/ping
nslookup
<SYSTEMPATH>/nslookup
telnet
<SYSTEMPATH>/telnet
ovgethostbyname
<INSTALLDIR>/bin/ovgethostbyname
(Solaris でのみ、nslookup の代わりに使用 )
注記
OVO 管理サーバーまたは認証局サーバーと OVO 管理対象ノードとの間の通信が
次の場所を通過しなければならないときは、以下に説明する方法では対処できな
いことがあります。
•
ファイアウォール
•
NAT
•
HTTP プロキシ
詳細は、ネットワーク管理者に尋ねてください。
付録 A
183
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
基本ネットワークの問題をチェックするには、次の手順をすべて実行します。
1. 影響の出ているすべてのシステムで、OVO 管理サーバー、認証局サーバー、および OVO 管
理対象ノードの名前解決が一致しているかどうかをチェックします。
すべてのシステムで他のすべてのシステムを対象に、完全修飾ドメイン名 (FQDN) を使って
ping および nslookup (Solaris では ovgethostbyname) を実行します。具体的には次のコ
マンドを実行します。
bbcutil -gettarget <nodename>
2. すべてのシステム (OVO 管理サーバー、認証局サーバー、および OVO 管理対象ノード ) にア
クセスできるかどうかをチェックします。
次のいずれかのコマンドを使います。
•
<OvInstallDir>/bin/bbcutil -ping <FQDN>
•
telnet <FQDN>
3. Web ブラウザを使って通信ブローカに接続を試み、HTTP 通信が行えるかどうかをチェック
します。このチェックでは、前提として通信ブローカ (ovbbccb) が動作していなければなり
ません。
次のコマンドを実行して、割り当てられている <AGENT-BBC-PORT> の値を検索します。
bbcutil -getcbport <agenthostname>
たとえば、次のコマンドを入力したものとします。
bbcutil -getcbport mysystem.mycom.com
結果が次の形式で表示されます。
mysystem.mycom.com:8008
OVO 管理サーバーシステムで Web ブラウザをオープンし、次の URL を入力します。
http://<OVO managed node>:<AGENT-BBC-PORT>/ ¥
Hewlett-Packard/OpenView/BBC/
<AGENT-BBC-PORT> のデフォルトのポート番号は 383 です。
この手順を、管理対象ノードから OVO 管理サーバーまで繰り返します。
http://<OVO management server>:<AGENT-BBC-PORT>/ ¥
Hewlett-Packard/OpenView/BBC/
184
付録 A
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
HP OpenView BBC Information Modules のページが表示され、ping と status をチェッ
クしたり、登録されているサービスと OVO リソースグループ (ovrg) の一覧を調べたりする
ことができます。
基本 HTTP 通信のトラブルシューティング
基本 HTTP 通信のトラブルシューティングでは、次のコマンドを使います。
ovc
<INSTALLDIR>/bin/ovc
ovconfget
<INSTALLDIR>/bin/ovconfget
ovbbccb
<INSTALLDIR>/bin/ovbbccb
ps
<SYSTEMPATH>/ps
注記
OVO 管理サーバーまたは認証局サーバーと OVO 管理対象ノードとの間の通信が
次の場所を通過しなければならないときでも、ここで説明するチェック内容は正
常に行えなければなりません。
•
ファイアウォール
•
NAT
•
HTTP プロキシ
正常に行えないときは、ネットワーク管理者に詳細を尋ねてください。
注記
付録 A
OVO 管理サーバーまたは認証局サーバーと OVO 管理対象ノードとの間の通信で
ファイアウォールの通過が許可されていないときは、HTTP プロキシを使う必要
があります ( 対応する項を参照してください )。
185
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
HTTP 通信の問題をチェックするには、次の手順をすべて実行します。
1. すべてのシステム (OVO 管理サーバー、認証局サーバー、および OVO 管理対象ノード ) で次
のチェックを行います。
次のコマンドを使って、OV 通信ブローカ (ovbbccb) が動作しているかどうかを調べます。
ovc -status
ovbbccb プロセスが「動作中」である必要があります。コマンドの出力は次のような形式で
表示されます。
ovcd
OV Control
CORE
(2785)
動作中
ovbbccb
OV Communication Broker
CORE
(2786)
動作中
ovconfd
OV Config and Deploy
CORE
(2787)
動作中
ovcs
OV Certificate Server
SERVER
(3024)
動作中
coda
OV Performance Core
AGENT
(2798)
動作中
opcmsga
OVO Message Agent
AGENT,EA
(2799)
動作中
opcacta
OVO Action Agent
AGENT,EA
(2800)
動作中
opcmsgi
OVO Message Interceptor
AGENT,EA
(2801)
動作中
opcle
OVO Logfile Encapsulator
AGENT,EA
(2805)
動作中
opcmona
OVO Monitor Agent
AGENT,EA
(2806)
動作中
opctrapi
OVO SNMP Trap Interceptor
AGENT,EA
(2810)
動作中
次のコマンドを実行します。
ps <OPT> | grep ovbbccb
ovbbccb の行が表示されなければなりません。
次のコマンドを実行します。
<OvInstallDir>/bin/bbcutil -status
ovbbccb のステータスが ok になっていなければなりません。
186
付録 A
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
注記
次のコマンドを実行し、表示されたポートをメモに記録します。
bbcutil -getcbport <hostname>
•
OVO 管理対象ノードでは <AGENT-PORT> を記録します。
•
OVO 管理サーバーでは <MGMT-SRV-PORT> を記録します。
•
認証局サーバーでは <CA-SRV-PORT> を記録します。
次のコマンドを使って、通信ブローカを起動します。
ovc -start
エラーメッセージが出なければ、正常です。
ovbbccb が動作していなければ、次の手順を実行します。
a. 次のファイルで、ログファイルに記録されているエラーメッセージをチェックします。
<OvDataDir>/log/System.txt
b. 次のコマンドを使って、通信ブローカを起動します。
<OvInstallDir>/bin/bbcutil -nodaemon -verbose
問題が少しでもあれば、起動時に詳細なエラー情報が表示されます。また起動時には、
使用するポート番号も表示されます。
c.
詳細な情報が必要なときは、次のコマンドを使います。
OVBBC_TRACE=true <OvInstallDir>/bin/ ¥
bbcutil -nodaemon -verbose
このコマンドを実行すると、詳細な情報が大量に表示されます。この詳細情報は、OV
トレースを使うことでも得られます。
2. 次のコマンドを使って、通信ブローカの使っているポートがどのように設定されているかを
チェックします。
a. 次のコマンドを実行して、通信ブローカのポートをすべて一覧表示します。
bbcutil -getcbport <hostname>
b. 次のコマンドを使い、そのノードに対するデフォルトの DOMAIN パラメータが正しく設定
されているかどうかをチェックします。
ovconfget bbc.http DOMAIN
付録 A
187
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
このパラメータには、デフォルトのドメイン ( たとえば、myco.com) が設定されていな
ければなりません。このパラメータ値を使って、上記の手順 2.a で得られた結果から該
当するものを探します。
c.
次のコマンドを使って、プロセスが通信ブローカのポートをオープンして接続をリスン
しているかどうかをチェックします。
netstat -an | grep ¥.383
次のような行が表示されれば、正常です ( 表示の詳細はプラットフォームごとに違いま
す )。
tcp
0
0
*.383
*.*
LISTEN
LISTEN と表示されれば、プロセスは指定のポートでリスンしています。しかし、
LISTEN と表示されるのにもかかわらず通信ブローカが動作していないときは、他のプ
ロセスがそのポートを使っていて、通信ブローカが起動できないという状況にあります。
このような状況は手順 1.a と 1.b で確認できます。
3. 次のコマンドを入力し、HTTP 通信の機能をチェックします。
OVO 管理サーバーと認証局サーバーでは、次のコマンドを実行します。
<OvInstallDir>/bin/bbcutil -ping http://OVO managed node:<AGENT-PORT>/
OVO 管理対象ノードでは次のコマンドを実行します。
<OvInstallDir>/bin/bbcutil -ping ¥
http://OVO management server:<MGMT-SRV-PORT>/
<OvInstallDir>/bin/bbcutil -ping ¥
http://Certificate Authority server:<CA-SRV-PORT>/
どちらの場合も、次のように表示されれば正常です。
status=eServiceOK
4. 各ノードで、通信ブローカのポート設定が正しいかどうかをチェックします。このとき、
URI でポート番号を指定しないようにします。OV の通信では、通信ブローカのポート番号
を自分自身で解決できなければなりません。ping でポート番号を指定すると成功して、ポー
ト番号を指定しないと失敗するようであれば、そのノードは正しく設定されていません。そ
のときは手順 2 に戻ってください。
5. 次のコマンドを使って、HTTP プロキシが正しく設定されているかどうかをチェックします。
bbcutil -gettarget <nodename>
たとえば、次のコマンドを入力したとします。
188
付録 A
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
bbcutil -gettarget mysystem.mycom.com
出力が次の形式で表示されます。
Node: mysystem.mycom.com:8008 (14.133.123.10)
プロキシが設定されていれば、表示されます。
たとえば、次のコマンドを入力したとします。
bbcutil -gettarget www.mycom.com
出力が次の形式で表示されます。
HTTP Proxy: web-proxy:8008 (14.193.1.10)
ovconfget bbc.http PROXY
好ましいことではありませんが、アプリケーションは自分の使うプロキシをかってに設定し
ている可能性があります。上記の設定はすべてのノードで有効ですが、アプリケーションに
よっては、次に示すように、自分の名前空間の中でこれらの値を無視しているかもしれませ
ん。
ovconfget bbc.http.ext.<comp id>.<appname>
<comp id> や <appname> が不明なものであったときは、ovconfget を使って、先頭が次の
文字で始まる名前空間内のすべてのプロキシの設定全体をチェックしてください。
bbc.http.ext
6. OVO 管理サーバーと認証局サーバーシステムで、プロキシが動作しているかどうかと
CONNECT コマンドをサポートしているかどうかをチェックします。
注記
空白行に大きな意味があります。
プラットフォームによっては、telnet セッションで入力したコマンドをエ
コーできないものもあります。
次のコマンドを入力します。
telnet <proxy> <proxy port>
CONNECT <AGENT>:<AGENT PORT> HTTP/1.0
PING /Hewlett-Packard/OpenView/BBC/ HTTP/1.0
telnet セッションを終了するときは Ctrl+D を入力します。
付録 A
189
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
出力は次のような形式で表示されます。ターゲットシステムで通信ブローカが動作していれ
ば、HTTPS のステータスは 200 OK となるはずです。
HTTP/1.1 200 OK
cache-control: no-cache
content-type: text/html
date: Fri, 06 Feb 2004 15:15:02 GMT
senderid: fd7dc9e4-4626-74ff-084a-9e5a09bffbae
server: BBC 05.00.101; ovbbccb 05.00.101HP OpenView BBC Information Modules:
Node:
Application:
Version:
Modules:
ping.bbn.hp.com
ovbbccb
05.00.101
ping
status
services
ovrg
Connection closed by foreign host.
7. OVO 管理対象ノードで、プロキシが動作しているかどうかと CONNECT コマンドをサポートし
ているかどうかをチェックします。
注記
空白行が必要です。
プラットフォームによっては、telnet セッションで入力したコマンドをエ
コーできないものもあります。
次のコマンドを入力します。
telnet <proxy> <proxy port>
CONNECT <MGMT-SRV>:<MGMT-SRV PORT> HTTP/1.0
PING /Hewlett-Packard/OpenView/BBC/ HTTP/1.0
または
telnet <proxy> <proxy port>
CONNECT <CA-SRV>:<CA-SRV PORT> HTTP/1.0
PING /Hewlett-Packard/OpenView/BBC/ HTTP/1.0
telnet セッションを終了するときは Ctrl+D を入力します。
出力の例は、1 つ前の手順を参考にしてください。
190
付録 A
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
8. 通信ブローカに対する HTTP アクセスのロギングを有効にします。
ovconfchg -ns bbc.cb -set LOG_SERVER_ACCESS true
このコマンドを実行すると、通信ブローカに対するすべてのアクセスがログに記録され始め
ます。ログの内容を見るには、次のコマンドを使います。
ovlogdump <OvDataDir>/log/System.bin
すべての OV サーバーに対するアクセスもログに記録したいときは、次のコマンドを使いま
す。
ovconfchg -ns bbc.http -set LOG_SERVER_ACCESS true
付録 A
191
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
HTTP 通信における認証と証明書のトラブルシューティング
基本 HTTP 通信のトラブルシューティングでは、次のコマンドを使います。
ovc
<INSTALLDIR>/bin/ovc
ovconfget
<INSTALLDIR>/bin/ovconfget
ovconfchg
<INSTALLDIR>/bin/ovconfchg
ovcoreid
<INSTALLDIR>/bin/ovcoreid
ovcert
<INSTALLDIR>/bin/ovcert
bbcutil
<INSTALLDIR>/bin/bbcutil
認証と証明書に関連した HTTP 通信の問題をチェックするには、次の手順をすべて実行します。
1. 各システムの OvCoreID をチェックします。
OVO 管理サーバーまたは認証局サーバーで、次のコマンドを入力します。
ovcoreid -ovreg server
OVO 管理対象ノードで、次のコマンドを入力します。
ovcoreid
表示された次の OvCoreID の値をすべてメモに記録します。
•
<MGMT-SRV-COREID>
•
<CA-SRV-COREID>
•
<AGENT-COREID>
2. OVO 管理サーバーまたは認証局サーバーと、OVO 管理対象ノードで次のコマンドを使い、
証明書をチェックします。
ovcert -list
192
付録 A
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
注記
OVO 管理サーバーシステムまたは認証局システムには、次の 3 つの証明書が
保管されています。
•
OVO 管理サーバーの証明書
•
認証局の証明書
•
ノード / エージェントの証明書
OVO 管理サーバーがクラスタ ( 高可用性環境 ) 上にインストールされている
場合は、OVO 管理サーバーの証明書とその管理サーバー上のエージェントの
証明書は同じものではありません。しかし、クラスタでないシステムに OVO
管理サーバーがインストールされている場合は、同じ証明書が使われていな
ければなりません。
各システムに少なくとも次の証明書がなくてはなりません。
OVO 管理対象ノード
| 証明書 :
|
<AGENT-COREID>
|
|
(*)
OVO 管理サーバーまたは認証局サーバー
| 証明書 :
|
<MGMT-SRV-COREID>|<CA-SRV-COREID>
(*)
|
|
すべてのシステム
| 信頼できる証明書 :
|
<CA-SRV-COREID>
注記
|
|
(*) は、その証明書に対して秘密鍵が使えることを表しています。
これらの証明書が一つでもないときは、150 ページの「証明書の作成と分配」を参照して必
要な証明書を作成してください。
付録 A
193
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
インストールされている証明書についてさらに詳細な情報が必要なときは、次のコマンドを
使います。
OVO 管理対象ノード
ovcert -check
OVO 管理サーバー
ovcert -check -ovrg server
出力の例を次に示します。
セットされた OvCoreId
インストールされた秘密鍵
インストールされた証明書
有効な証明書
インストールされた信頼できる証明書
信頼できる有効な証明書
:
:
:
:
:
:
OK
OK
OK
OK
OK
OK
チェックが成功しました。
インストールされている証明書の有効性をチェックするには、次のコマンドを使って、その
日がインストールされている証明書の valid from から valid to までの期間内にあること
を確認します。
ovcert -certinfo <CertificateID>
注記
信頼のおける証明書の CertificateID は、証明書サーバーの OvCoreID に接頭
辞 CA_ が付いたものです。
出力の例を次に示します。
# ovcert -certinfo 071ba862-3e0d-74ff-0be4-b6e57d0058f2
194
Type
:
Subject CN :
Subject DN :
X509Certificate
071ba862-3e0d-74ff-0be4-b6e57d0058f2
L: alien2.ext.bbn.com
O: Hewlett-Packard
OU: OpenView
CN: 071ba862-3e0d-74ff-0be4-b6e57d0058f2
Issuer CN
Issuer DN
CA_99300c4e-f399-74fd-0b3d-8938de9900e4
L: tcbbn054.bbn.hp.com
O: Hewlett-Packard
OU: OpenView
:
:
付録 A
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
CN: CA_99300c4e-f399-74fd-0b3d-8938de9900e4
04
01/27/04 12:32:48 GMT
01/22/24 14:32:48 GMT
60:72:29:E6:B8:11:7B:6B:9C:82:20:5E:AF:DB:D0: ...
Serial no. :
Valid from :
Valid to
:
Hash (SHA1):
注記
OVO 管理サーバーシステムには HTTPS エージェントもインストールされて
います。
OVO 管理サーバーシステムで ovcert -list を呼び出すと、その OVO 管理
サーバーシステムに存在するエージェントについて、その証明書の詳細情報
を得ることができます。
3. 次のコマンドを使って、HTTPS 通信の機能をチェックします。
注記
OVO 管理サーバーまたは認証局サーバーと OVO 管理対象ノードとの間の通
信が次の場所を通過しなければならないときでも、ここで説明するチェック
内容は正常に行えなければなりません。
•
ファイアウォール
•
NAT
•
HTTP プロキシ
正常に行えないときは、ネットワーク管理者に詳細を尋ねてください。
注記
付録 A
OVO 管理サーバーまたは認証局サーバーと OVO 管理対象ノードとの間の通
信でファイアウォールの通過が許可されていないときは、HTTP プロキシを
使う必要があります ( 対応する項を参照してください )。
195
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
OVO 管理サーバーまたは認証局サーバー
<OvInstallDir>/bin/bbcutil -ping ¥
https://<OVO managed node name>:<AGENT-PORT>/
OVO 管理対象ノード
<OvInstallDir>/bin/bbcutil -ping ¥
https://<OVO management server name>:<MGMT-SRV-PORT>/
<OvInstallDir>/bin/bbcutil -ping ¥
https://Certificate Authority server:<CA-SRV-PORT>/
どの呼び出しに対しても、次のように報告されなければなりません。
status=eServiceOK
また、報告された OvCoreID が最初の手順でメモに記録しておいた OvCoreID と一致してい
なければなりません。
coreID=<COREID>
196
付録 A
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
OVO 通信のトラブルシューティング
OVO 通信のトラブルシューティングでは、次のコマンドを使います。
ovc
<INSTALLDIR>/bin/ovc
ovconfget
<INSTALLDIR>/bin/ovconfget
ovconfchg
<INSTALLDIR>/bin/ovconfchg
ovcoreid
<INSTALLDIR>/bin/ovcoreid
ovpolicy
<INSTALLDIR>/bin/ovpolicy
ovcs
<INSTALLDIR>/bin/ovcs
opcagt
<INSTALLDIR>/bin/OpC/opcagt
opcragt
<INSTALLDIR>/bin/OpC/opcragt
opcscsa
<INSTALLDIR>/bin/OpC/opcscsa
opcscsam
<INSTALLDIR>/bin/OpC/opcscsam
opcsv
<INSTALLDIR>/bin/OpC/opcsv
opcnode
<INSTALLDIR>/bin/OpC/opcnode
opc
/usr/bin/OpC/opc
OVO 通信の問題をチェックするには、次の手順をすべて実行します。
1. OVO 管理対象ノードが OVO 登録ノードにあることを確認します。
2. OVO 管理対象ノードの完全修飾ドメイン名 (FQDN) が一致していることを確認します。
3. OVO 管理対象ノードの通信タイプが HTTPS になっていることを確認します。
4. OVO 管理対象ノードの OvCoreID が一致していることを確認します。
次のコマンドを使って、OVO データベース内に保存されている OVO 管理対象ノードの
OvCoreID 値をチェックします。
opcnode -list_id node_list=<OVO managed node>
OvCoreID 値が <AGENT-COREID> と同じでなければなりません。
OVO 管理対象ノードの OvCoreID は、次のコマンドを使って OVO 管理サーバーから変更で
きます。
opcnode -chg_id node_name=<OVO managed node> id=<AGENT-COREID>
付録 A
197
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
また OvCoreID は、OVO 管理対象ノードでも次のコマンドを使って変更できます。
ovcoreid -set <NEW-AGENT-COREID>
注記
システムの OvCoreId の変更はノードの ID を変更することになるので、慎重
に実行してください。メッセージなど、ノードに関連するデータはすべてそ
のノードの OvCoreId を介してリンクされています。OvCoreID の変更は、
経験の深いユーザーが行うようにしてください。特に OVO 管理サーバーの変
更については、変更内容とその変更による影響を正確に把握 / 判断できる熟練
者だけに実行を制限してください。
5. 次のコマンドを使って、OVO 管理サーバープロセスが動作していることをチェックします。
opcsv -status
登録されているすべてのプロセスが「動作中 」の状態になっていなければなりません。
ovc -status
登録されているすべてのコアプロセスが「動作中」の状態になっていなければなりません。
6. 自分が次のグループに対して責任を持っていることを確認してください。
•
OVO 管理対象ノードとそのノードグループ
•
メッセージグループ
メッセージブラウザを再ロードします。
7. 保留中の証明書リクエストをチェックします。
認証局サーバーで次のコマンドを入力します。
opccsa -list_pending -l
出力の一覧に OVO 管理対象ノードが存在するかどうか ( ノード名、IP アドレス、または
OvCoreID で識別 ) とすべてのパラメータに整合性があるかどうかをチェックします。
次のコマンドを使い、手作業で保留証明書リクエストを承諾します。
opccsa -grant <NODE>|<COREID>
パラメータに整合性がないときは、OVO 管理サーバーと OVO 管理対象ノードで必要な値に
変更します。
OVO 管理対象ノードで次のコマンドを使い、すべてのプロセスを停止します。
ovc -kill
198
付録 A
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
次のコマンドを使って、すべてのプロセスが停止したことを確認した後、プロセスを再起動
します。
ps <OPT> | grep /opt/OV
ovc -start
注記
証明書リクエストの発行を手作業で起動するには、まず最初に次のコマンド
を使って、証明書がまだひとつもインストールされていないことを確認しま
す。
ovcert -status
証明書がインストールされていなければ、次のコマンドを入力します。
ovcert -certreq
証明書がすでにインストールされていると、次のエラーメッセージが表示さ
れます。
エラー : (sec.cm.client-125) このノードの有効な証明書が既にインストー
ルされています。
8. OVO 管理対象ノード上のメッセージブラウザに OVO 管理対象ノードのメッセージが表示さ
れていなければ、次のチェックを行います。
•
プロセスがすべて動作中であるかどうかをチェックします。
ovc -status
登録されているプロセスがすべて動作していなければなりません。またどのプロセスも
重複して動作していてはなりません。
•
該当するポリシーが配布されているかどうかをチェックします。
ovpolicy -list
•
MANAGER、MANAGER_ID、および CERTIFICATE_SERVER の設定値をチェックします。
ovconfget sec.cm.client CERTIFICATE_SERVER
この設定値は、認証局サーバーと一致している必要があります。
ovconfget sec.core.auth MANAGER
この設定値は、OVO 管理サーバーと一致している必要があります。
ovconfget sec.core.auth MANAGER_ID
付録 A
199
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
この設定値は、OVO 管理サーバーの OvCoreID と一致している必要があります。
ovconfget eaagt OPC_PRIMARY_MGR
この値は設定されていなくてもかまいませんが、設定されていた場合は、OVO 管理サー
バーと一致している必要があります。
注記
その OVO 管理サーバーが一次マネージャになっていない場合は、さらに
チェックする必要があります。
次のファイルの中にある OVO 管理サーバーの値は整合性がなければなりません。
<DATADIR>/datafiles/policies/mgrconf/<ID>_data
•
メッセージ除外の設定値をチェックします。
•
メッセージバッファリングの設定値をチェックします。
•
メッセージバッファーファイルのサイズが増えつつあるかどうかをチェックします。
ls -l <DATADIR>/tmp/OpC/msgagtdf
または OVO 管理サーバーで次のコマンドを実行します。
opcragt -status <nodename>
•
転送すべきメッセージをサーバーへ送ります。
opcmsg a=appl o=object msg_t=<my_text>
•
メッセージマネージャキューファイルにメッセージが残っていないかどうかをチェック
します。
strings /var/opt/OV/share/tmp/OpC/mgmt_sv/msgmgrq | grep <my_text>
9. OVO 管理対象ノードに対する DEPLOYMENT、ACTIONS、または HBP が失敗するときは、OVO
管理対象ノードで次のコマンドを実行してエージェントのステータスをチェックします。
opcragt -status
このコマンドの報告に問題が見つからなければ、問題は HTTPS とは関係ありません。
200
付録 A
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
証明書分配中に発生する問題
証明書サーバーアダプタで管理している保留証明書リクエストのリストに同じノードに対する保
留証明書リクエストが 2 つ存在する、といった事態が証明書の分配中に発生することがありま
す。
こうした事態は、たとえばそのノードから証明書リクエストが発行されたときに発生する可能性
があります。発行された証明書リクエストは、承諾されないまま保留状態で証明書サーバーアダ
プタの内部リストに残ることがあります。そうした状態でエージェントソフトウェアを削除して
再インストールすると、保留されているリクエストとは別の証明書リクエストが発行されること
になります。ただし、その場合はノードの再インストールで新しい OvCOreID が作成されるた
め、その新しいリクエストには新しい OvCoreID が使われます。しかし、この証明書リクエスト
も保留証明書リクエストのリストに残されることになります。
保留証明書リクエストの一覧には、証明書リクエストを OVO 管理サーバーが受信したときのタ
イムスタンプが含まれています。それにより、どの証明書リクエストが新しくて有効なものかど
うかが明確になります。最も新しい証明書リクエストを承諾し、他の古いリクエストを削除しま
す。
こうした状況になっていることが分かった場合には、次の 2 つの対処方法があります。
•
OVO の管理者としてログインし、問題のあるノードから発行された証明書リクエストをすべ
て削除した後、次のコマンドを使って新しい証明書リクエストを発行する。
ovcert -certreq
このように対処すると、そのノードの証明書リクエストは 1 つだけになり、通常どおりに
マップして承諾することができます。99 ページの第 5 章 「HTTPS ノードでの作業」を参照
してください。
•
当該ノードで管理者としてovcert -certreqコマンドを実行できないために新しい証明書リ
クエストを発行できないときは、次のコマンドを実行して、そのノードから有効な
OvCoreID を検索します。
<OvInstallDir>/bin/bbcutil -ping <nodename>
証明書リクエストをすべて一覧表示し、OvCoreID の有効な証明書リクエストだけを承諾し
て、他のリクエストをすべて削除します。
付録 A
201
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
OVO 管理サーバー上の無効な OvCoreId
OVO 管理サーバーをインストールし直すと、新しい OvCoreId が割り当てられます。その場合、
既存のポリシーの署名に使われていた OvCoreId が無効になることがあります。管理対象ノード
にポリシーをロードする際の署名の確認にはこの新しい OVO 管理サーバーの OvCoreId が使わ
れるので、無効になった OVO 管理サーバーの古い OvCoreId でポリシーが署名されていると、
インターセプタから、確認に失敗したというメッセージが表示されます。
注記
OVO 管理サーバーノードへローカルに分配されたポリシーでも、署名が無効に
なっていることがあります。
たとえば、opcmsgi と opcmona ではポリシーの読み込みに失敗し、opcle では正常に読み込め
たものとします。
この場合、次のような形式でエラーメッセージが表示されます。
40-1867 Cannot validate policy signature.
このような状況が発生するのを避けるには、以下の処理を実行します。
OVO 管理サーバーシステムで、次の手順を実行します。
1. 次のディレクトリの内容を削除します。
/etc/opt/OV/share/conf/OpC/mgmt_sv/templates/utf8/ux_compress
2. 既存のポリシーをすべて削除します。
ovpolicy -remove -all
または、次のディレクトリにあるすべてのファイルを手作業で削除します。
/var/opt/OV/datafiles/policies
3. OpenView のプロセスをすべて停止します。
ovc -kill
4. 以下のコマンドを実行して、MANAGER_ID の値をチェックします。それぞれのコマンドにつ
いて、その出力の例も一緒に示します。
ovcoreid
edb78a08-1431-74ff-17c1-f4aef838aa2b
opcnode -list_id node_list="<mgmt_srv_nodename>"
202
付録 A
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
ノードの ID リスト :
Name = <nodename> ID = edb78a08-1431-74f4aef838aa2b
ovcert -list
+-----------------------------------------------------+
| キーストアの内容
|
+-----------------------------------------------------+
| 証明書 :
|
|
edb78a08-1431-74ff-17c1-f4aef838aa2b (*)
|
+-----------------------------------------------------+
| 信頼できる証明書 :
|
|
CA_edb78a08-1431-74ff-17c1-f4aef838aa2b
|
+-----------------------------------------------------+
これらすべてのコマンドに対して同じ MANAGER_ID の値が返れば正常です。
値が同じでない場合は、ovcert -list コマンドから返された MANAGER_ID の値を使い、次
の手順で、誤っている値を修正します。
•
ovcoreid コマンドから返された MANAGER_ID の値が ovcert -list コマンドから返され
た値と一致しない場合は、次のコマンドを実行して、OVO 管理サーバーの OvCoreId を
リセットします。
ovconfchg -ns sec.core.auth -set MANAGER_ID <mgmt_srv_coreid>
•
ovcoreidコマンドから返されたMANAGER_IDの値がopcnode -list_*コマンドから返さ
れた値と一致しない場合は、次のコマンドを実行して、OVO 管理サーバーの OvCoreId
をリセットします。
opcnode -chg_id node_name="<mgmt_srv_nodename>"
5. OpenView のプロセスを起動します。
ovc -start
管理対象ノードで以下の手順を実行します ( 管理対象ノードが OVO 管理サーバーシステムでな
い場合 )。
1. 既存のポリシーをすべて削除します。
ovpolicy -remove -all
または、次のディレクトリにあるすべてのファイルを手作業で削除します。
/var/opt/OV/datafiles/policies
付録 A
203
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
2. OpenView のプロセスをすべて停止します。
ovc -kill
3. 既存の証明書をリストにして表示します。
ovcert -list
+---------------------------------------------------------+
| キーストアの内容
|
+---------------------------------------------------------+
| 証明書 :
|
| adb66a06-1666-23aa-18b1-e4dcf454bb3a (*)
|
+---------------------------------------------------------+
| 信頼できる証明書 :
|
| CA_edb78a08-1431-74ff-17c1-f4aef838aa2b
|
+---------------------------------------------------------+
4. 前の手順で表示された証明書をすべて削除します。
ovcert -remove <cert_id>
5. この管理対象ノードの MANAGER_ID の値として、OVO 管理サーバーの OvCoreId (OVO 管理
サーバーで ovcoreid コマンドから返された値 ( 上述の手順を参照 )) を設定します。
ovconfchg -ns sec.core.auth -set MANAGER_ID <mgmt_srv_OvCoreId>
6. OpenView のプロセスを起動します。
ovc -start
既存の証明書が削除されているので、新しい証明書リクエストが自動的に発行されます。こ
のリクエストを OVO 管理サーバーの GUI で確認します。
OVO 管理サーバーシステムで以下の手順を実行します。
1. OVO 管理サーバーの GUI を使って、該当の管理対象ノードから証明書リクエストが到着して
いるかどうかをチェックし、必要があれば、その保留リクエストを承諾します。
次のようなメッセージが表示されます。
証明書がノードに正しくインストールされました。
2. OVO 管理者GUI を使ってOVO 管理サーバーと問題となっているOVO 管理対象ノードのノー
ド設定を一時的に変更し、nodeinfo ポリシーを再配布できるようにします。
この変更は後で戻すことができます。
opcragt -distrib -templates -force <mgmt_Server hostname>
204
付録 A
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
opcragt -distrib -templates -force <node hostname>
3. 必要に応じてノードの設定を元の値に戻し、OVO 管理サーバーと影響のある OVO 管理対象
ノードにテンプレートを配布します。
OVO での証明書のバックアップと復元方法
秘密鍵がなくなったり、秘密鍵や証明書にエラーが発生した場合の影響は、十分に認識しておく
必要があります。しかし、秘密鍵や証明書は、アップロードする、ダウンロードする、通常の設
定ファイルには含まれていません。
OVO 管理サーバーには、証明書とそれに対応する秘密鍵およびコア ID のバックアップと復元を
行なうためのユーティリティがあります。
/opt/OV/bin/OpC/opcsvcertbackup
このユーティリティには、以下のオプションがあります。
•
-remove
OVO 管理サーバーから、以下の項目を含むすべての証明書を削除します。
— 認証局のルート証明書とその秘密鍵
— サーバー証明書とその秘密鍵
— OVO 管理サーバーのノード証明書
削除するときには、自動的にバックアップが作成されます。
•
-backup
次の場所に、tar アーカイブが作成されます。
/tmp/opcsvcertbackup.<date_time>.tar
<date_time> のフォーマットは、YYMMDD_hhmmss の形式です。
デフォルトの記憶場所は、-file オプションを使って変更できます。
記録される情報は、以下のとおりです。
— 認証局のルート証明書、秘密鍵、ID
— OVO 管理サーバーの証明書、秘密鍵、コア ID
— ノードの証明書、秘密鍵、コア ID
データはパスワードを指定した -pass オプションを使って、機密保護する必要があります。
付録 A
205
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
tar アーカイブには、次の名前のテキストファイルが含まれます。
opcsvcertbackup.<date_time>.txt
これは、アーカイブを整理するときに役に立つ情報であり、バックアップされた証明書の
OvCoreIds、ホスト名、バックアップのタイムスタンプなどの情報を含みます。ただし、こ
れらの情報は復元時には使われません。
•
-restore
-backup オプションを使って作成された tar ファイルは、このオプションを使って復元する
ことができます。
ファイル名は、-file オプションを使って指定する必要があります。バックアップの作成時
に使ったパスワードを、-pass オプションで指定する必要があります。
認証局、OVO 管理サーバー、ノードの証明書や秘密鍵が、OVO 管理サーバーシステムにす
でに存在していて、バックアップアーカイブの中に格納されている値と同一でない場合に
は、復元は実行されません。
これを避けるには、-force オプションを使って強制的に復元を実行します。
opcsvcertbackup でも、復元されるべき証明書の OvCoreIds が、OVO データベースに格
納されている OvCoreIds と一致しない場合には、エラーを返します。-force オプションを
指定した場合には、OvCoreIds が書き換えられ、確認メッセージが表示されます。
証明書のバックアップを作成 / 使用する時期
opcsvcertbackup を使ってバックアップを作成 / 使用するのが望ましい時期は、以下のとおり
です。
•
OVO の最初のインストール
OVO 管理サーバーを正常にインストールした場合には、次のコマンドを使って証明書デー
タのバックアップを作成することが特に重要です。
opcsvcertbackup -backup
その結果作成される tar アーカイブは、安全な場所に保管してください。
•
別のシステムに OVO 管理サーバーの再インストール
別のシステムに標準の OVO 管理サーバーインストールを実行します。新たにインストール
したシステムに、オリジナルの OVO 管理サーバーのバックアップを次のコマンドを使って
インストールします。
opcsvcertbackup -restore -file <filename> -pass <password> -force
206
付録 A
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
注記
•
サーバーをインストールしたことによって、認証局、OVO 管理サーバー、
ノードの証明書が自動的に作成されているので、-force オプションを指定す
る必要があります。管理対象ノードはオリジナルのインストールで作成され
た証明書を使うように設定されているので、新しく作成された証明書は使え
ない証明書です。
復元
何らかの情報が誤って削除された場合には、次のコマンドを使います。
opcsvcertbackup -restore -file <filename> -pass <password>
エラー出力がないかどうかを注意深く調べてください。
•
設定エラーの復元
force オプションを指定しない通常の復元が正常に行なわれなかった場合には、
opcsvcertbackup が生成したエラーメッセージを調べます。これでも問題が解決できない
場合には、次のコマンドを実行して、証明書関連の情報を削除します。
opcsvcertbackup -remove
または、次のコマンドを実行して、存在する証明書を直接書き換えます。
opcsvcertbackup -restore -file <filename> -pass <password> -force
•
MoM 環境での証明書の信頼関係の設定
証明書の信頼関係を作成したら、新しいバックアップを作成してください。こうすると、復
元が必要になった場合に、追加されたルート証明書も復元されることが確実になります。
•
共有 CA の設定
共有 CA を設定する場合は、次のコマンドを実行するのが便利で、2 番目の OVO 管理サー
バーから不必要な証明書を削除します。
opcsvcertbackup -remove
詳細は、57 ページの「証明書サーバーが複数個ある環境」を参照してください。
付録 A
207
HTTPS ベース通信のトラブルシューティング
トラブルシューティング
208
付録 A
B HTTPS ベース通信の設定方法
付録 B
209
HTTPS ベース通信の設定方法
通信の設定パラメータ
通信の設定パラメータ
HP OpenView アプリケーションは、設定パラメータを使うことで、システムごとにカスタマイ
ズできます。通信ブローカの設定パラメータは bbc.ini で定義します。このファイルは次の場
所にあります。
<OVDataDir>/conf/confpar/bbc.ini
通信に使うパラメータは、212 ページの「HTTPS 通信の設定ファイル」で説明してあります。
通信ブローカの名前空間には bbc.cb を使います。これとは別に、bbc.cb.ports という形式も
使えます。この形式は、すべてのノードで通信ブローカのポート番号を指定する場合に使いま
す。この形式を使えば、複数の通信ブローカにそれぞれ別のポート番号を割り当てて使うことが
できます。この設定の方が、名前空間 bbc.cb で定義されている SERVER_PORT パラメータより
優先します。
注記
名前空間は一意の URL (Uniform Resource Locator) です。
次の URL はその例です。
www.anyco.com、abc.xyz
名前空間は非常に単純であるため、XML (Extensible Markup Language) 文書の
中で要素名や属性名を名前空間 (URL) に関連付けることで、その要素や属性を簡
単に修飾することができます。
ネットワークにおける通信ブローカのポート番号は、名前空間 bbc.cb.ports 内で名前と値の
ペアを定義することによって識別できるようになります。名前と値のペアは次の構文で定義しま
す。
NAME=<host>:<port> または NAME=<domain>:<port>
ホスト / ポートまたドメイン / ポートの組合せは、1 行に何個も定義できます。ただし、複数個
定義する場合は、それぞれをコンマまたはセミコロンで区切ります。
ドメインは *.domainname の形式で定義します。このドメインに参加している場合は、通常、
この指定されたポートが使われます。エントリーは、定義が詳細なほど優先されます。名前には
この名前空間内で一意なものを指定する必要がありますが、名前 / 値の対で名前の部分は無視さ
れます。エントリーの例を次に示します。
•
HP=jago.sales.hp.com:1383, *.sales.hp.com:1384; *.hp.com:1385
•
SUN= *.sun.com:1500
210
付録 B
HTTPS ベース通信の設定方法
通信の設定パラメータ
この例の定義に従えば、ホスト jago.sales.hp.com で動作する通信ブローカはポート番号
1383 を使います。
また、ドメイン sales.hp.com 内の他のすべてのホストは、ポート番号 1384 を使います。そし
て、ドメイン hp.com 内の他のすべてのホストは、ポート番号 1385 を使います。一方、ドメイ
ン sun.com 内のホストは、ポート番号 1500 を使います。他のすべてのホストは、デフォルトの
ポート番号 383 を使います。
付録 B
211
HTTPS ベース通信の設定方法
HTTPS 通信の設定ファイル
HTTPS 通信の設定ファイル
bbc.ini(4)
名前
bbc.ini – HTTPS 通信用の設定ファイル
説明
bbc.ini は HTTPS 通信を使用する OVO 管理対象ノードの設定ファイルで、次の場所に格納さ
れています。
/<OVDataDir>/conf/confpar
設定ファイルは、名前空間の見出しで始まるセクションにそれぞれの名前空間用の設定が記述さ
れる構成を持ちます。bbc.ini ファイルには以下に示す名前空間が含まれます。各名前空間で可
能な設定とデフォルトの設定を説明します。
bbc.cb
通信ブローカの名前空間です。以下のパラメータが使用できます。
string CHROOT_PATH = <path>
UNIX システムでのみ使用されます。UNIX システムでは chroot によるパス
が ovbbccb プロセスによって使用されます。このパラメータを設定すると、
ovbbccb プロセスは実効ルートとしてこのパスを使用し、それによってアク
セスをファイルシステムの限定された場所に制限します。デフォルトは、
<OvDataDir> です。このパラメータは、MS Windows と Sun Solaris 7 シス
テムでは無視されます。chroot の詳細は、chroot のマンページを参照して
ください。
bool SSL_REQUIRED = false
このパラメータに true を設定すると、通信ブローカは、通信ブローカへのす
べての管理する接続に対して、SSL 認証を要求します。このパラメータに
false を設定すると、通信ブローカへの非 SSL 接続が許可されます。
bool LOCAL_CONTROL_ONLY = false
このパラメータに true を設定すると、通信ブローカは start や stop といっ
た管理コマンドの実行をローカル接続だけに許可します。
212
付録 B
HTTPS ベース通信の設定方法
HTTPS 通信の設定ファイル
bool LOG_SERVER_ACCESS = false
このパラメータに true を設定すると、サーバーへのすべてのアクセスはログ
に記録されます。送信側の IP アドレス、リクエストされた HTTP アドレス、
リクエストされた HTTP メソッド、およびレスポンスステータスが記録され
ます。
int SERVER_PORT = 383
デフォルトではこのポートには 383 が設定されます。このポートは通信ブ
ローカがリクエストを受信するために使用します。名前空間 [bbc.cb.ports]
でポートが設定されている場合には、このパラメータよりも優先されます。
string SERVER_BIND_ADDR = <address>
サーバーポート用のバインドアドレスです。デフォルトは INADDR_ANY です。
bbc.cb.ports
Communication-Broker-Port の名前空間です。このパラメータによって、ホスト内のアプリ
ケーションからアクセスされる、ネットワーク内のすべての通信ブローカ用のポートのリストを
定義します。デフォルトのポート番号は、すべての通信ブローカに対し 383 です。以下のパラ
メータを使用できます。
string PORTS
この設定パラメータはすべてのノードで同一に設定する必要があります。特定
のホストで通信ブローカのポート番号を変更するには、このパラメータに、た
とえば、name.hp.com:8000 のように、ホスト名を追加します。アスタリス
ク「*」をワイルドカードとして使って、たとえば、*.hp.com:8001 のように
ネットワーク全体を指すことができます。また、次の例のように、ホスト名の
リストでは、項目を区切るためにコンマ「,」またはセミコロン「;」を使いま
す。
name.hp.com:8000, *.hp.com:8001
これらの例では、「hp.com」で終わるすべてのホスト名は、BBC 通信ブロー
カがポート 8001 を使うように構成しています。ただし、ホスト「name」だ
けは、ポート 8000 を使います。それ以外のホストはすべてデフォルトのポー
ト 383 を使います。
IP アドレスとワイルドカードであるアスタリスク (*) を使って、次のように、
ホストを指定することもできます。
15.0.0.1:8002, 15.*.*.*:8003
付録 B
213
HTTPS ベース通信の設定方法
HTTPS 通信の設定ファイル
bbc.http
ノード固有の設定を行うための HTTP 名前空間です。アプリケーション固有の設定については、
bbc.http.ext.* の項を参照してください。アプリケーション固有の bbc.http.ext.* の設定は、
bbc.http のノード固有の設定に優先することに注意してください。以下のパラメータを使うこ
とができます。
int SERVER_PORT = 0
デフォルトではこのポートは 0 に設定されます。0 に設定されている場合に
は、オペレーティングシステムは最初に使用可能なポート番号を割り当てま
す。これはアプリケーション <appName> がリクエストを受信するために使う
ポートです。このパラメータを bbc.http.ext.<appName> 名前空間で明示的
に設定することが、デフォルトとは異なるアプリケーション固有の値を設定す
ることになることに注意してください。
string SERVER_BIND_ADDR = <address>
サーバーポート用のバインドアドレスです。デフォルトは localhost です。
string CLIENT_PORT = 0
クライアントリクエストに対するバインドポートです。たとえば、
10000-10020 のようにポート範囲を指定することもできます。これは、リク
エストの発信元のバインドポートです。デフォルトのポートは 0 です。オペ
レーティングシステムは最初に使用可能なポートを割り当てます。
MS Windows システムは再使用のためのポートを即座に解放しないことに注
意してください。したがって、MS Windows システムではこのパラメータは
範囲を広く設定する必要があります。
string CLIENT_BIND_ADDR = <address>
クライアントポートに対するバインドアドレスです。デフォルトは
INADDR_ANY です。
bool LOG_SERVER_ACCESS = false
このパラメータに true を設定すると、サーバーへのすべてのアクセスではロ
グが作成され、送信側の IP アドレス、リクエストされた HTTP アドレス、リ
クエストされた HTTP メソッド、およびレスポンスステータスが記録されま
す。
string PROXY
指定したホスト名で使われるプロキシとポートを定義します。
214
付録 B
HTTPS ベース通信の設定方法
HTTPS 通信の設定ファイル
形式 :
proxy:port +(a)-(b);proxy2:port2+(a)-(b); ...;
a: コンマまたはセミコロンで区切られたホスト名のリストであり、ここで指定
されたプロキシが使われます。
b: コンマまたはセミコロンで区切られたホスト名のリストであり、このホスト
名ではここで指定されたプロキシを使いません。
最初に照合したプロキシが選択されます。
ホスト名の代わりに IP アドレスを使うこともできるので、15.*.*.* や
15:*:*:*:*:*:*:* も有効な表現です。ただし、ドットやコロンの数は正確
に指定してください。IP バージョン 6 のサポートは現在は未提供ですが、将
来は提供する予定です。
bbc.fx
ノード固有の設定を行うための BBC File-Transfer の名前空間です。アプリケーション固有の設
定については、bbc.fx.ext.* の項を参照してください。アプリケーション固有の bbc.fx.ext.*
の設定は、bbc.fx のノード固有の設定に優先することに注意してください。以下のパラメータ
を使うことができます。
int FX_MAX_RETRIES = 3
オブジェクトを正常に転送するために試みられるリトライの最大数です。
string FX_BASE_DIRECTORY = <directory path>
ファイルがアップロードまたはダウンロードされるベースディレクトリです。
デフォルトのディレクトリは <OvDataDir> です。
string FX_TEMP_DIRECTORY = <directory path>
アップロードするファイルをアップロードしている最中に一時的に保存してお
くための一時的なディレクトリです。アップロードが完了すれば、ファイルは
<directory path> に移されます。デフォルトのディレクトリは
<OvDataDir>/tmp/bbc/fx です。
string FX_UPLOAD_DIRECTORY = <directory path>
ファイルをアップロードする対象のディレクトリです。デフォルトはベース
ディレクトリです。アップロードする対象のディレクトリは、この設定パラ
メータによって書き換えることができます。デフォルトのディレクトリは
FX_BASE_DIRECTORY です。
付録 B
215
HTTPS ベース通信の設定方法
HTTPS 通信の設定ファイル
bbc.snf
ノード固有の設定を行うための BBC Store-and-Forward の名前空間です。アプリケーション固
有の設定については、bbc.snf.ext.* の項を参照してください。アプリケーション固有の
bbc.snf.ext.* の設定は、bbc.snf のノード固有の設定に優先することに注意してください。
以下のパラメータを使うことができます。
string BUFFER_PATH = <path>
バッファー対象のリクエストが格納される SNF パスを指定します。デフォル
トは次のとおりです。
<OVDataDir>/datafiles/bbc/snf/<appName>
int MAX_FILE_BUFFER_SIZE = 0
バッファーとしてハードディスクを使うことが許されるディスク容量の最大値
を指定します。
0 = 制限なし
bbc.http.ext.*
HTTP External-Communication の名前空間は、bbc.http.ext.<compID>.<appName> と
bbc.http.ext.<appName> です。
これはアプリケーション固有の Dynamic External-Communication の名前空間です。アプリ
ケーション固有の bbc.http.ext.* の設定は、bbc.http のノード固有の設定に優先することに
注意してください。
bbc.http.ext.* 名前空間で使うことのできるパラメータのリストについては、bbc.http の項
を参照してください。
bbc.fx.ext.*
外部コンポーネントとアプリケーション固有の設定を行うための Dynamic File-Transfer (fx) 名
前空間です。アプリケーション固有の bbc.fx.ext.* の設定は、bbc.fx のノード固有の設定に
優先することに注意してください。
File Transfer External の名前空間は、 bbc.fx.ext.<compID>.<appName> と
bbc.fx.ext.<appName> です。
bbc.fx.ext.* 名前空間で使うことのできるパラメータのリストについては、bbc.fx の項を参
照してください。
216
付録 B
HTTPS ベース通信の設定方法
HTTPS 通信の設定ファイル
bbc.snf.ext.*
外部コンポーネントとアプリケーション固有の設定を行うための Dynamic Store-and-Forward
(snf) 名前空間です。アプリケーション固有の bbc.snf.ext.* の設定は、bbc.snf のノード固
有の設定に優先することに注意してください。
Store and Forward External の名前空間は、 bbc.snf.ext.<compID>.<appName> と
bbc.snf.ext.<appName> です。
bbc.snf.ext.* 名前空間で使うことのできるパラメータのリストについては、bbc.snf の項を
参照してください。
著者
bbc.ini は、HP で開発されました。
例
PROXY=web-proxy:8088-(*.hp.com)+(*.a.hp.com;*)
プロキシ web-proxy は、たとえば www.hp.com のように *.hp.com に一致するホストを除き、
ポート 8088 を持つすべてのサーバー (*) で使われます。ホスト名が merlin.a.hp.com のよう
に *.a.hp.com に一致する場合には、プロキシサーバーが使われます。
参照
ovbbccb (1)
付録 B
217
HTTPS ベース通信の設定方法
HTTPS 通信の設定ファイル
218
付録 B
C HTTPS 通信のアーキテクチャ
付録 C
219
HTTPS 通信のアーキテクチャ
通信ブローカのアーキテクチャ
通信ブローカのアーキテクチャ
通信ブローカはローカルノードのプロキシとして動作し、そのノード上のすべてのアプリケー
ションに対する中心的な入口となります。データを受信するアプリケーションは、通信ブローカ
にそのアドレスを登録します。登録の際には、そのアプリケーションがデータの受信に使うポー
トの番号、プロトコル、バインドアドレス、およびベースパスを指定します。他のアプリケー
ションは、ローカルにあるかリモートにあるかに関係なく、そのアプリケーションの場所を通信
ブローカに照会したり、通信ブローカをプロキシとして使って登録済みアプリケーションにリク
エストを転送したりします。通信ブローカは標準の OpenView 設定ファイルからその設定デー
タをロードします。
通信ブローカには次の特長があります。
•
通信ブローカを使うことにより、ノードの通信を単一ポートで制御することができます。つ
まり、このノードの登録済みサーバーに対するリクエストはすべて、通信ブローカを通して
送信先へ転送されます。このとき、通信ブローカは、HTTP プロキシが HTTP リクエスト
を転送する場合と同様に、登録済みサーバーへ透過的にリクエストを転送します。通信ブ
ローカのデフォルトポートは 383 ですが、変更することも可能です。
•
UNIX システムでは、通信ブローカを起動する時に chroot を実行することで、セキュリティ
をさらに強化することができます。具体的には、chroot を実行してルートディレクトリを
特定のパスに設定し、ファイルシステムの中で通信ブローカプロセスから見える領域を制限
します。そうすることで、ハッカーに見える部分を減らすことができます。
•
UNIX システムでは、通信ブローカに 1024 より大きいポート番号を使うことで、非 root のプ
ロセスとして実行することができます。
•
UNIX システムでは、通信ブローカを設定することで、ポートを開設するときにのみ root で
動作させ、その他の操作では非 root で動作させる、ということが可能です。
•
通信ブローカは、次のように実装できます。
— デーモンとして動作させる (UNIX システムの場合 )
— Windows NT のサービスとしてインストールする (Windows NT システムの場合 )
•
通信ブローカの制御コマンドをローカルノードでだけ実行できるように制限することができ
ます。
•
通信ブローカは、ネットワークを介して送信するデータを SSL で暗号化します。
220
付録 C
HTTPS 通信のアーキテクチャ
通信ブローカのアーキテクチャ
•
通信ブローカでは、保証された送信元 ID と受信先 ID を使って、SSL 認証を実行します。
図 C-1
通信ブローカのアーキテクチャ
通信ブローカには、そのノードで着信データを受け入れるためのポートとして、少なくとも 1 つ
のポートを設定します。このポートは、ノードを識別できるようにするために OpenView ID
(OVCoreID) と関連付けられます。高可用性ノードでは、通信ブローカで複数のポートを使える
ように設定することができます。各ポートには、お互いに異なる ID が割り当てられます。SSL
を有効にすると、このポートに X509 証明書が設定されます。アプリケーションは、この証明書
によって、メッセージの送信元および受信先の本人確認を行うことができます。
通信ブローカにアプリケーションを登録すると、そのノードで通信ブローカがオープンしている
すべての受信ポートに自動的に登録されます。これらのポートは、通信ブローカの起動と同時に
デフォルトの名前空間 bbc.cb と結び付けられ、自動的にアクティブとなります。それ以外の
ポートは、起動後に動的にアクティブまたは非アクティブになります。詳細は、通信ブローカの
コマンド行インタフェースのパラメータを参照してください。
付録 C
221
HTTPS 通信のアーキテクチャ
通信ブローカのアーキテクチャ
222
付録 C
D ファイアウォールと HTTPS 通信
付録 D
223
ファイアウォールと HTTPS 通信
ファイアウォールの仕組み
ファイアウォールの仕組み
ファイアウォールは、ネットワークに接続された企業内の各システムを外部の攻撃から保護する
ために使います。ファイアウォールを置く場所は、企業のプライベートなイントラネットとイン
ターネットを分離する位置にするのが普通です。レベルの異なる複数のファイアウォールを実装
することもよく行われます。この方法は、信頼性のそれほど高くない環境からのアクセスを制限
して、高い信頼性の求められている環境を保護するという目的で使われます。たとえば、一般に
研究部門や財務部門はセキュリティの最も高い環境に閉じ込める必要がありますが、反対に直販
部門は外部からアクセスしやすくする必要があります。一方、イントラネット内のシステムは、
ある条件の下で、ファイアウォールの外側にあるインターネット上のシステム、たとえば DMZ (
インターネット上の非武装地帯 ) にあるシステムへアクセスすることが許されます。またファイ
アウォールによって、インターネット上のシステムからファイアウォールの内側にあるプライ
ベートなイントラネットにアクセスすることが許可される場合もあります。いずれの場合でも、
このような制御を行うには、ファイアウォールを設定する必要があります。
HP OpenView の HTTPS 通信にはそのための機能があり、ファイアウォールの管理者は、HP
OpenView アプリケーションを設定して、ファイアウォール経由で通信できるようにすることが
できます。
イントラネットからインターネット上のアプリケーションへアクセスする －
HTTP プロキシを使う方法
システムによっては、プライベートなイントラネットにある HTTPS ベースの HP OpenView ア
プリケーションから、ファイアウォールの外側にあるパブリックインターネットまたは非武装地
帯 (DMZ) 上のアプリケーションにアクセスすることが必要な場合もあります。この場合、
OpenView アプリケーションがトランザクションの開始側となり、インターネット上のアクセス
先サーバーアプリケーションに対してクライアントとして動作します。サーバーアプリケーショ
ンは、HTTP サーバーとして動作する別の OpenView アプリケーションであることも、まった
く別の HTTP サーバーアプリケーションであることもあります。この形態の一般的な例は、プ
ライベートなイントラネットから Web ブラウザを使ってインターネット上の Web サーバーにア
クセスするパターンです。このパターンでは、イントラネット内の Web ブラウザがクライアン
トになります。この場合は、ブラウザに HTTP プロキシを設定し、リクエストをファイア
ウォールの外側へ送信してインターネット上の Web サーバーにアクセスできるようにする必要
があります。Web ブラウザがファイアウォールを直接越えようとしても、ファイアウォールで
許可が下りないので、ファイアウォールは、HTTP プロキシがファイアウォールを越えられるよ
うに設定します。これと同様に、HTTP プロキシを使ってファイアウォールを越えられるよう
に、HP OpenView の HTTPS 通信アプリケーションを設定することもできます。
224
付録 D
ファイアウォールと HTTPS 通信
ファイアウォールの仕組み
イントラネットからインターネット上のアプリケーションへアクセスする －
HTTP プロキシを使わない方法
プライベートなイントラネット内にある HTTPS ベースの HP OpenView アプリケーションに
よっては、ファイアウォールの外側にあるインターネット上のアプリケーションに対して、
HTTP プロキシを使わないでアクセスできる必要がある場合もあります。この場合、プライベー
トなイントラネット上の HP OpenView アプリケーションがファイアウォールを越えられるよう
に、ファイアウォールを設定する必要があります。このパターンは、HTTP プロキシがファイア
ウォールを越えられるように設定する方法と非常に似ています。つまり、ファイアウォールの管
理者は、トランザクション用の送信元および送信先ポートを設定して、ファイアウォールを越え
る通信を制限します。送信元ポートを指定する設定パラメータは CLIENT_PORT ですが、この設
定パラメータは、トランザクションを開始する時に HP OpenView アプリケーションから設定す
ることができます。イントラネット上の HTTP サーバーにアクセスするときは、URL (Uniform
Resource Locator または Identifiers) で目的とする送信先ポートを指定します。このポートが送
信先ノードの通信ブローカのポートになります。
インターネット上の OpenView アプリケーションからプライベートなイントラ
ネット内のアプリケーションへアクセスする
インターネット上にある HTTPS ベースの HP OpenView アプリケーションから、プライベート
なイントラネット上のアプリケーションにアクセスしたい場合があります。このような外部から
のアクセスはファイアウォールを通す必要があり、通常は、組織の判断でのみ許可します。また
許可するといっても、ファイアウォールの管理者によってそのアクセスが非常に制限されます。
アクセスを開始したアプリケーション、すなわちクライアントアプリケーションは、HTTP プロ
キシを使ってファイアウォールを越えるか、または直接、ファイアウォールを越えます。HTTP
プロキシはファイアウォールの外側にあるので、ファイアウォールを設定して HTTP プロキシ
が越えられるようにする必要があります。プロキシがカスケード状に配置されている環境では、
HTTP プロキシからプライベートなイントラネット上のサーバーへのアクセスは、直接行われる
かまたは他のプロキシを経由して行われます。いずれの場合でも、HTTPS 通信を行う HP
OpenView のクライアントアプリケーションは、同じように設定します。ただし、HTTP プロキ
シには別の設定が必要です。
インターネット上の OpenView アプリケーションからプライベートなイントラ
ネット内のアプリケーションへアクセスする － HTTP プロキシを使わない方法
インターネット上にある HTTPS ベースの HP OpenView アプリケーションから、HTTP プロキ
シを使わないで、プライベートなイントラネット上のアプリケーションにアクセスしたい場合が
あります。このようなケースは、ファイアウォールを設定して、クライアントとなる HP
付録 D
225
ファイアウォールと HTTPS 通信
ファイアウォールの仕組み
OpenView アプリケーションがファイアウォールを越えられるようにする必要があります。ただ
しその場合でも、ファイアウォール管理者がそのトランザクション用に送信元ポートと送信先
ポートを設定して、ファイアウォールを越える通信を制限することができます。送信元ポートを
指定する設定パラメータは CLIENT_PORT ですが、この設定パラメータは、トランザクションを
開始する時に HP OpenView アプリケーションから設定することができます。イントラネット上
の HTTP サーバーにアクセスするときは、URL で目的とする送信先ポートを指定します。この
ポートが送信先ノードの通信ブローカのポートになります。
送信先サーバーを通信ブローカに登録しておけば、送信先ポートの番号は常に通信ブローカの
ポート番号になります。このようにすれば、ファイアウォールの設定が簡単になります。管理者
がファイアウォールに設定しなければならない送信先ポートの数が大幅に減るからです。
226
付録 D
E OVO 8.1 クイックスタートガイド
付録 E
227
OVO 8.1 クイックスタートガイド
OVO 7.x ユーザーのための OVO 8.1 クイックスタートガイド
OVO 7.x ユーザーのための OVO 8.1 クイックスタートガイド
OVO 8.1 の新しいコマンドと OVO 7.1 のコマンドとの対応の概要を、表 E-1 に示します。各コ
マンドの詳細については、コマンドのマンページを参照してください。
OVO 8.1 の最も重要なコマンドは、39 ページの「OVO の HTTPS 通信管理コマンド」を参照し
てください。
注記
表 E-1
opcagt や opctemplate などのラッパーユティリティでは、DCE ベースの
opcxxx コマンドとは異なる表示形式で出力されます。
OVO 7.x と OVO 8.1 とのコマンド対応表
OVO 7.x コマンド
OVO 8.1 コマンド
opcagt
ovc
-help
ovc -help
-start
ovc -start AGENT
ovc -restart AGENT
-stop
ovc -stop
-status
ovc -status
-kill
ovc -kill
-trace
ovc -trace
-version
ovc -version
opcragt
ovdeploy, ovconfpar
-agent_version
ovdeploy -inv -host <node>
-get_config_var
ovconfpar -get
-set_config_var
ovconfpar -set
228
付録 E
OVO 8.1 クイックスタートガイド
OVO 7.x ユーザーのための OVO 8.1 クイックスタートガイド
表 E-1
OVO 7.x と OVO 8.1 とのコマンド対応表 ( 続き )
OVO 7.x コマンド
OVO 8.1 コマンド
opctemplate
ovpolicy
-help
ovpolicy -help
-l
ovpolicy -list
-e
ovpolicy -enable
-d
ovpolicy -disable
opcsv
ovc
-help
ovc -help
-start
ovc -start SERVER
-restart SERVER
-stop
ovc -stop
-status
ovc -status
-trace
ovc -trace
opctranm
ovdeploy (HTTPS エージェント )
opctranm (DCE エージェント )
付録 E
229
OVO 8.1 クイックスタートガイド
OVO 7.x ユーザーのための OVO 8.1 クイックスタートガイド
230
付録 E
索引
A
Adobe Portable Document Format －参照
PDF ドキュメント
B
bbc.ini 設定ファイル , 212
bbcutil, 39
D
DCE エージェント
HTTPS からの移行 , 114
DCE エージェント
HTTPS への移行 , 110
代行ユーザーの概念 , 83
DCE エージェントとの比較 , 33
コマンド , 35
設定情報の配布 , 33
トラブルシューティング , 37
パフォーマンス , 35
複数の並列設定サーバー , 34
プロセス , 36
分配マネージャ , 34
リソース要件 , 34
Developer's Toolkit ドキュメント , 18
DHCP
HTTPS エージェント , 147
NNM の同期 , 149
opcnode 変数 , 148
エージェントの管理 , 149
変数 , 148
E
ECS Designer ドキュメント , 18
Event Correlation Service Designer －参照
ECS Designer ドキュメント
G
GUI
ドキュメント
Java, 22 ‐ 23
Motif, 21 ‐ 22
H
HA リソースグループ , 141
HP OpenView Event Correlation Service
Designer －参照 ECS Designer ドキュメ
ント
索引
HTTPS agent
quick start information, 228
HTTPS エージェント
DCE エージェントとの比較 , 33
コマンド , 35
設定情報の配布 , 33
トラブルシューティング , 37
パフォーマンス , 35
複数の並列設定サーバー , 34
プロセス , 36
分配マネージャ , 34
リソース要件 , 34
DHCP, 147
NNM の同期 , 149
opcnode 変数 , 148
管理 , 149
変数 , 148
アーキテクチャ , 29
インストルメンテーション管理 , 90
インターネット通信 , 225
コマンド , 35
コンポーネント , 29
差分分配 , 94
サポートされているプラットフォーム , 30
証明書のトラブルシューティング , 192, 201
設定情報の配布 , 89
設定のプッシュ , 93
代行ユーザー , 71
DCE エージェントとの比較 , 83
sudo, 81
アップグレード , 80
インストール , 74
エージェントプロファイル , 78
管理サーバーの設定 , 76
準備 , 73
制限 , 72
デフォルトポートの変更 , 77
パッチ , 80
通信のトラブルシューティング , 183, 185,
197
ディレクトリ構造 , 38
トラブルシューティング , 37
認証のトラブルシューティング , 192
ネットワークのトラブルシューティング ,
183
ハートビートポーリング , 96
CPU の負荷の軽減 , 96
ネットワークの負荷の軽減 , 96
パフォーマンス , 35
231
索引
ファイアウォールとプロキシ , 224
ファイアウォールの仕組み , 224
複数の並列設定サーバー , 94
プロセス , 36
分配マネージャ , 92
リモート制御 , 98
HTTPS 通信
概念 , 44
コマンド , 39
bbcutil, 39
opccsa, 41
opccsacm, 41
ovc, 39
ovcert, 41
ovconfchg, 39
ovconfget, 39
ovcoreid, 39
ovpolicy, 40
利点 , 27, 45
安全 , 46
オープン , 47
スケーラブル , 48
ファイアウォールとの親和性 , 45
HTTPS ノード
DCE への移行 , 114
HTTPS ノード
DCE からの移行 , 110
IP アドレスの変更 , 126
自動 , 130
手作業 , 126
インストール
コピーイメージを使った , 124
ソフトウェア , 101
手作業 , 116
パッケージファイルから手作業で , 117
プロキシの背後での手作業 , 138
管理サーバーのプロキシ , 139
削除
エージェントソフトウェアを自動的に ,
140
エージェントソフトウェアを手作業で ,
140
問題 , 140
指定したノードへ証明書をマップ , 157
すべての不明なノードを選択 , 157
制御方法 , 88
設定 , 100
登録ノードへ追加 , 157
名前解決 , 131
232
変数 , 122
ホスト名の変更 , 126
自動 , 130
手作業 , 126
ポリシー管理 , 90
I
IP アドレス , 151
自動的な変更 , 130
手作業による変更 , 126
変更 , 126
M
MoM
合併 , 57
証明書サーバーの共有 , 63
Motif GUI ドキュメント , 21 ‐ 22
N
NNM
DHCP の同期 , 149
O
opccsa, 41
opccsacm, 41
opcinfo, 122
opcnode
DHCP 変数 , 148
opcsvinfo, 122
OpenView Event Correlation Service
Designer －参照 ECS Designer ドキュメ
ント
ovc, 39
ovcert, 41
ovconfget, 39
OvCoreID, 151
ovcoreid, 39
OVDataDir, 38
OVInstallDir, 38
OVO 管理サーバー
OvCoreId, 202
証明書のトラブルシューティング , 201
通信のトラブルシューティング , 197
ovpolicy, 40
ovrc, 39
索引
索引
P
PDF ドキュメント , 15
ping
アプリケーション , 176
Portable Document Format －参照 PDF ド
キュメント
R
RPC
タイムアウト , 180
S
sudo
使用方法 , 81
セットアップ , 82
SunMC ドキュメント , 18
T
TCP/IP
ツール , 180
W
what 文字列 , 178
あ
アーキテクチャ
HTTPS エージェント , 29
通信ブローカ , 220
アプリケーション
ping, 176
ステータス , 177
通信ブローカに登録されている , 177
い
印刷製本ドキュメント , 16 ‐ 17
印刷表記法 －参照 ドキュメント表記法
インストール
OV ファイルセット , 178
インベントリの基本情報 , 178
インベントリの詳細情報 , 179
インベントリのネイティブ情報 , 179
エージェントソフトウェア , 101
キー , 163
コピーイメージからの , 124
手作業 , 116
パッケージファイルから手作業で , 117
索引
プロキシの背後での手作業 , 138
インストルメンテーション
管理 , 90
手作業によるインストール , 91
え
エージェントプロファイル
sudo, 81
アップグレード , 80
代行ユーザー , 78
パッチ , 80
お
オンラインドキュメント
説明 , 19
か
仮想ノード , 141
HA リソースグループ , 141
クラスタ , 141
削除 , 144
追加 , 142
物理ノード , 141
変更 , 143
ポリシーの削除 , 145
ポリシーの配布 , 146
ポリシーの変更 , 146
ポリシーの割当て , 144
関連ドキュメント
Developer's Toolkit, 18
ECS Designer, 18
PDF, 15
SunMC, 18
印刷製本 , 16 ‐ 17
オンライン , 19, 21 ‐ 23
追加 , 18
き
キーストア , 50
く
クラスタ , 141
こ
更新
ルート証明書 , 56
構文
233
索引
プロキシ , 137
コピーイメージ , 124
コマンド
bbcutil, 39
HTTPS 通信 , 39
opccsa, 41
opccsacm, 41
ovc, 39
ovcert, 41
ovconfget, 39
ovcoreid, 39
ovpolicy, 40
ovrc, 39
エージェント , 35
コンポーネント
HTTPS エージェント , 29
さ
削除
エージェントソフトウェア , 140
自動 , 140
手作業 , 140
問題 , 140
差分分配 , 94
サポートされているプラットフォーム , 30
し
証明書 , 53
IP アドレス , 151
opcsvcertbackup, 205
OvCoreID, 151
OvCoreId のトラブルシューティング , 202
インストールキー , 163
管理 , 156
拒否 , 156
作成 , 150, 159
指定したノードへマップ , 157
自動分配 , 153
すべての不明なノードを選択 , 157
手作業で分配 , 163
登録ノードへノードを追加 , 157
トラブルシューティング , 192
バックアップ , 205
復元 , 205
プラットフォーム , 152
分配 , 150
分配のトラブルシューティング , 201
ホスト名 , 151
234
マップ先 , 151
マップされたすべてのリクエストを選択 ,
156
リクエストウィンドウ , 151
リクエストの削除 , 156
リクエストの承諾 , 156
証明書クライアント , 55, 50
証明書サーバー , 50, 54
合併 , 57
共有 , 63
複数 , 57, 60
証明書サーバーの共有 , 63
証明書の管理 , 156
証明書の作成 , 159
シングルホームホスト , 134
す
スケーラビリティ , 48
ステータス
アプリケーション , 177
せ
セキュリティ
概念 , 46
キーストア , 50
コンポーネント , 50
証明書 , 53
証明書クライアント , 50, 55
証明書サーバー , 50, 54
合併 , 57
共有 , 63
複数 , 57, 60
代行ユーザー , 71
DCE エージェントとの比較 , 83
sudo, 81
アップグレード , 80
インストール , 74
エージェントプロファイル , 78
管理サーバーの設定 , 76
準備 , 73
制限 , 72
デフォルトポートの変更 , 77
パッチ , 80
認証局 , 54
ルート証明書 , 53
更新 , 56
分配 , 56
設定
索引
索引
bbc.ini ファイル , 212
HTTPS ノード , 100
通信パラメータ , 210
プロキシ , 135
設定情報
サーバー
複数の並列 , 94
配布 , 33, 89
プッシュ , 93
そ
ソフトウェア
インストール , 101
コピーイメージからの , 124
手作業 , 116
パッケージファイルから手作業で , 117
プロキシの背後での手作業 , 138
た
代行ユーザー , 71
DCE エージェントとの比較 , 83
sudo, 81
アップグレード , 80
インストール , 74
エージェントプロファイル , 78
管理サーバーの設定 , 76
準備 , 73
制限 , 72
デフォルトポートの変更 , 77
パッチ , 80
つ
追加のドキュメント , 18
通信
HTTPS の概念 , 44
HTTPS の利点 , 45
安全 , 46
オープン , 47
スケーラブル , 48
ファイアウォールとの親和性 , 45
OVO で処理可能な , 28
OVO のトラブルシューティング , 197
設定パラメータ , 210
設定ファイル , 212
トラブルシューティング , 183, 185
ファイアウォールとインターネット , 225
ファイアウォールとプロキシ , 224
ファイアウォールの仕組み , 224
索引
通信ブローカ
アーキテクチャ , 220
登録されているアプリケーション , 177
て
ディレクトリ
OVDataDir, 38
OVInstallDir, 38
構造 , 38
手作業によるインストール
インストルメンテーション , 91
ポリシー , 91
デュアルホームホスト , 134
と
登録ノード
ノードを追加 , 157
ドキュメント表記法 , 13 ‐ 14
ドキュメント、関連
Developer’s Toolkit, 18
ECS Designer, 18
Java GUI, 22 ‐ 23
Motif GUI, 21 ‐ 22
PDF, 15
SunMC, 18
印刷製本 , 16 ‐ 17
オンライン , 19, 21 ‐ 23
追加 , 18
トラブルシューティング , 176
OvCoreId, 202
OVO 通信 , 197
RPC コール , 180
TCP/IP ツール , 180
what 文字列 , 178
アプリケーションに対する ping, 176
アプリケーションのステータス , 177
インストールされている OV ファイルセット
, 178
インベントリの基本情報 , 178
インベントリの詳細情報 , 179
インベントリのネイティブ情報 , 179
証明書 , 192
証明書の分配 , 201
通信 , 183, 185
ツール , 176
登録されているアプリケーション , 177
認証 , 192
ネットワーク , 183
235
索引
ロギング , 181
な
名前解決 , 131
に
認証
トラブルシューティング , 192
認証局 , 54
ね
ネットワーク
トラブルシューティング , 183
の
ノード証明書リクエスト , 151
は
ハートビートポーリング , 96
CPU の負荷の軽減 , 96
ネットワークの負荷の軽減 , 96
配布 , 33
バックアップ
証明書 , 205
パフォーマンス
エージェント , 35
トラブルシューティング , 37
ひ
表記法、ドキュメント , 13 ‐ 14
ふ
ファイアウォール , 45
インターネット通信 , 225
仕組み , 224
プロキシ , 224
ファイルセット
インストールされている OV のリスト , 178
インベントリの基本情報 , 178
インベントリの詳細情報 , 179
インベントリのネイティブ情報 , 179
復元
証明書 , 205
複数の証明書サーバー , 57, 60
複数の証明書サーバー環境の合併 , 57
複数の並列設定サーバー , 94
236
物理ノード , 141
不明なノード
すべてを選択 , 157
プラットフォーム , 152
プロキシ , 133
エージェントソフトウェアの手作業によるイ
ンストール , 138
管理サーバーの , 139
構文 , 137
シングルホームホスト , 134
設定 , 135
デュアルホームホスト , 134
マルチホームホスト , 134
プロセス
エージェント , 36
分配
証明書 , 163
証明書を自動的に , 153
ルート証明書 , 56
分配マネージャ , 34, 92
へ
並列設定サーバー , 34
変数
opcinfo, 122
opcsvinfo, 122
設定 , 122
ほ
ホスト名 , 151
自動的な変更 , 130
手作業による変更 , 126
変更 , 126
ポリシー
仮想ノードからの削除 , 145
仮想ノードでのポリシーの変更 , 146
仮想ノードへのポリシーの配布 , 146
仮想ノードへの割当て , 144
手作業によるインストール , 91
ポリシー管理 , 90
ま
マップ先 , 151
マップされたリクエスト
すべてを選択 , 156
マルチホームホスト , 134
索引
索引
り
リクエストの拒否 , 156
リクエストの削除 , 156
リクエストの承諾 , 156
リソース要件 , 34
リモート制御 , 98
る
ルート証明書 , 53
更新 , 56
分配 , 56
ろ
ロギング , 181
索引
237
索引
238
索引