この章では、Instant Messaging のインストール中および配備中に発生する可能性の高い問題を列挙し、ウォッチドッグの概要について説明します。各種システムコンポーネントによってさまざまな処理実行時に生成されるログ情報は、問題の切り分けや障害追跡を行う際に、極めて重要な役割を果たします。また、監視フレームワークエージェントを使用すると Instant Messaging プロセスの稼働状況を監視して問題を発生前に阻止すること、利用レベルを評価して配備の規模を決定すること、および停止時間の発生を防ぐことができます。この章に含まれる節は、次のとおりです。
サーバー、マルチプレクサ、ウォッチドッグ、カレンダエージェント、クライアントロギングの管理方法の詳細や、ログファイルのデフォルトの場所については、第 13 章「Instant Messaging のロギングの管理」を参照してください。
Instant Messenger には、クライアントのトラブルシューティングをしやすくする方法が 2 つ用意されています。クライアントシステムに関する実行時情報の収集のほかに、必要に応じて Instant Messenger ログファイルの生成も行うことができます。
Instant Messenger クライアントから、クライアントシステムに関する情報を取得できます。
Instant Messenger で「ヘルプ」->「バージョン情報」を選択します。
「バージョン情報」ダイアログボックスが開きます。
「詳細」タブを選択します。
「詳細」タブには、障害追跡時に利用できるクライアントシステムに関する情報が表示されます。
クライアントログは必要に応じて生成します。デフォルトではログは生成されません。クライアントロギングの設定方法については、「Instant Messenger のロギングの管理」を参照してください。
問題のいくつかを以下に列挙します。また、それらの原因や、問題の解決に役立つ情報についても説明します。
「Sun JavaTM System Portal Server 7 2006Q1 以降でメッセージのアーカイブが行われない」
「patchrm および patchadd の実行後に Instant Messenger リソースのカスタマイズ内容が失われる」
「Access Manager コンソール (amconsole
) に Instant Messaging サービスが表示されない」
リダイレクトサーバーを正常に配備するには、XMPP リダイレクションをサポートするクライアントを使用する必要があります。Instant Messenger の 2006Q1 以降を使用してください。他社製クライアントを使用する場合には、そのクライアントが XMPP リダイレクションをサポートしていることを確認してください。
XMPP/HTTP ゲートウェイ が 2 つのドメインにサービスを提供している場合に、im.jnlp ファイル内にその一方のドメインのみに対する引数が含まれていると、ドメインの一覧に含まれないユーザーは認証することができません。たとえば、im.jnlp ファイルに次の引数が含まれているとします。
<argument>domain=mydomain.siroe.com</argument> |
mydomain 以外のドメインからログインしようとするユーザーはエラーを受け取り、認証を行えません。この問題を回避するには、ほかのドメインに対して認証を行うように Instant Messenger を設定する必要があります。
im.jnlp リソースファイルを開きます。
ドメイン引数のエントリを削除します。
たとえば、次の情報を削除します。
<argument>domain=mydomain.siroe.com</argument> |
Instant Messenger を再度ダウンロードします。
Instant Messenger を実行します。
ログインページが表示されます。
「詳細」をクリックします。
ログインページが展開され、クライアントの接続設定が表示されます。
「サーバー」テキストボックスにゲートウェイへの URL を入力し、?to=domain を追加します。
たとえば、ユーザーが mydomain.siroe.com の一部である場合、次の情報を URL に追加します。
?to=mydomain.siroe.com |
この設定をテストするには、有効なユーザー名とパスワードを使ってログインします。
Sun Java System Portal Server 7 2006Q1 以降でポータルアーカイブを設定したのにメッセージのアーカイブが行われない場合には、iim.conf 内で iim_arch.portal.search パラメータが設定されていることを確認してください。
iim_arch.portal.search="Portal Server Search URL" |
ここで、Portal Server Search URL は Portal Server の検索 URL です。たとえば、次のように入力します。
iim_arch.portal.search="http://portal.siroe.com:8080/search1/search" |
(問題番号: 6361796) patchrm と patchadd のプロセスは、クライアントリソースを再配備します。これが発生すると、すべてのカスタマイズ済みファイルが上書きされます。これらのアクションを実行する前に、保存するすべてのカスタマイズ済みファイルをバックアップする必要があります。
Instant Messaging はデフォルトで、受信者がオフラインの場合のインスタントメッセージの転送先となる電子メールアドレスを、mail 属性に基づいて決定します。ディレクトリが mail 属性を電子メールアドレスとして使用しない場合、ディレクトリと同じ属性を使用するように Instant Messaging を設定する必要があります。
iim.conf を開きます。
iim.conf の場所、およびこのファイルを変更する手順については、「iim.conf ファイルの構文」を参照してください。
iim_ldap.user.mailattr パラメータの値を、ディレクトリが電子メールアドレスをユーザーエントリに格納する際に使用する属性に変更します。
カレンダポップアップが期待どおりに配信されない場合は、この節の説明に従ってその設定のトラブルシューティングを行うことができます。カレンダポップアップの設定手順については、第 16 章「カレンダのポップアップリマインダの使用」を参照してください。
カレンダポップアップ設定でもっともよくあるエラーは、設定ファイル内でパラメータ名が正しく入力されていないことです。これには、タイプミスやパラメータ名のスペルミスが含まれます。iim.conf と ics.conf のすべての設定パラメータとその値が正しく入力されていることを確認してください。ポップアップがすでに設定済みである場合には、表 A–11 に基づいてその必須パラメータと実際のエントリとを比較してください。
Instant Messaging と Calendar Server の設定ファイルが正しいにもかかわらず、ポップアップが依然として期待どおりに届かない場合には、カレンダクライアントと Instant Messenger が正しく設定されていることを確認してください。
カレンダクライアントにログインします。
タイムゾーンの設定が正しいことを確認します。
Calendar Express を使用している場合は、メニューから「ツール」->「オプション」->「設定」を選択します。
電子メールリマインダのスケジュールを作成します。
Calendar Express を使用している場合は、メニューから「ツール」->「オプション」->「設定」を選択します。
設定を保存します。
同じユーザーを使って Instant Messenger にログインします。
「ツール」->「設定」を選択します。
「設定」ダイアログボックスが表示されます。
「アラート」タブを選択します。
「カレンダリマインダーを表示」チェックボックスをオンにし、「了解」をクリックします。
Instant Messenger ユーザーをログインしたままにしておきます。
カレンダクライアントで設定された時刻に、電子メールアラートとポップアップをユーザーが受信したかどうかを確認します。
電子メールアラートを受信しなかった場合、カレンダクライアントは正しく設定されていません。より詳しいトラブルシューティング情報については、カレンダクライアントのマニュアルを参照してください。
電子メールアラートは受信したがカレンダポップアップは受信しなかった場合で、サーバーとクライアントのどちらも正しく設定してある場合は、xmppd.log で詳細をチェックしてください。このログの設定を DEBUG などの、より冗長な設定に変更する必要がある可能性があります。ログレベルの変更手順については、「iim.conf のパラメータを使用して Instant Messaging コンポーネントのログレベルを設定する」を参照してください。
Sun Java System Access Manager で SSO を使用している場合、Access Manager サーバーと Instant Messaging サーバーが同じ Web コンテナを使用するように設定する必要があります。
この問題の原因となっている可能性のあるものを、以下に列挙します。
アプレットページ内のコードベースが間違っている。
MIME タイプ「Application/x-java-jnlp-file」が、Web コンテナ設定内に定義されていない。
プラグインまたは Java Web Start がインストールされていないか、正常に機能していない。
互換性のあるバージョンの Java が利用できない状態にある。
セキュリティーの例外。.jar ファイルの署名を検証できない。
必要な情報を得るには、次の場所を確認してください。
Java Web Start またはプラグインのエラー情報 (例外スタックトレースや起動ページ)
ブラウザ上のアプレットページソース
この問題の原因となっている可能性のあるものを、以下に列挙します。
Instant Messaging サーバーまたはマルチプレクサが実行されていない。
アプレット記述子ファイル (.jnlp または .html) 内に指定されているマルチプレクサのホスト名またはポート番号が正しくない。
Instant Messenger とマルチプレクサの SSL 設定が食い違っている。
クライアントとサーバーのバージョンが一致していない。
診断情報を得るには、次の場所を確認してください。
Instant Messaging サーバーおよびマルチプレクサのログファイル。
Instant Messenger のログ。
Instant Messenger の「バージョン情報」ダイアログボックスの「詳細」タブ。
この問題の原因となっている可能性のあるものを、以下に列挙します。
LDAP サーバーへのアクセス時に問題が発生した。たとえば、LDAP サーバーが停止している場合や、スキーマ違反などによってプロビジョニングエラーが発生した場合など。
エンドユーザーが見つからない。
資格情報が無効である。
Instant Messenger のセッションが無効である。
診断情報を得るには、次の場所を確認してください。
Instant Messaging サーバー、アイデンティティー認証、および LDAP に関するログファイル。
Sun Java System Access Manager を使用する配備では、ディレクトリ内のユーザーエントリに iplanet-am-managed-person オブジェクトクラスが含まれていることを確認。Instant Messaging サーバーは、Access Manager 配備内で有効なユーザーを検索する際にこのオブジェクトクラスを使用します。このオブジェクトクラスの詳細や、Access Manager がこのオブジェクトクラスをどのように使用するかについては、Sun Java System Access Manager のマニュアルを参照してください。
この問題の原因となっている可能性のあるものを、以下に列挙します。
サーバーがセッショントークンを検証できない。
Instant Messaging チャネルが正しく設定されていない。たとえば、Instant Messaging サーバーのホストまたはポート、あるいはその両方が正しくない。
プラグインまたは Java Web Start がインストールされていないか、正常に機能していない。
エンドユーザーが見つからない。つまり、Instant Messaging サーバーが LDAP 検索を実行するときにエンドユーザーを見つけることができない。
診断情報を得るには、次の場所を確認してください。
Instant Messaging サーバーおよび Instant Messaging チャネルのログ。
この問題の原因となっている可能性のあるものを、以下に列挙します。
コンテンツは実際にはアーカイブされているが、エンドユーザーの権限が不足しているために、そのコンテンツにアクセスできない。
コンテンツがまだデータベースにコミットされていない。
Instant Messaging サーバーでアーカイブプロバイダが無効になっている。
診断情報を得るには、次の場所を確認してください。
Instant Messaging サーバーログファイルとアーカイブログファイル。
この問題の原因となっている可能性のあるものを、以下に列挙します。
サーバーの識別が正しくない。
SSL 設定の不一致。
診断情報を得るには、次の場所を確認してください。
両方のサーバーでの Instant Messaging サーバーログファイル。
Instant Messaging のインストールまたはアンインストール中に致命的なエラーが発生した場合、システムが不整合な状態に陥る可能性があります。そのような状態では、インストール、アンインストールのどちらも完了できなくなります。こうした場合、インストールを最初からやり直せるように、Instant Messaging のすべてのコンポーネントを手動で削除する必要があります。クリーンアップ手順は、パッケージの削除とレジストリ情報の削除から構成されます。
次回のインストールで必要となる可能性のある情報のすべてを、バックアップします。
手順については、「Instant Messaging データのバックアップ」を参照してください。
製品のレジストリ情報を手動で編集します。
Solaris 9 の場合、次のコマンドを実行します。
prodreg(1) |
ほかのすべてのオペレーティングシステムの場合は、次のようにします。
productregistry.xml を編集し、このファイルから Instant Messaging の XML 要素をすべて削除します。
デフォルトでは、この productregistry XML ファイルは次の場所に格納されています。
Solaris の場合: /var/sadm/install/productregistry
Linux の場合: /var/tmp/productregistry
次のパッケージまたは RPM が残っている場合は、それらを削除します。
SUNWiim
SUNWiimc
SUNWiimd
SUNWiimid
SUNWiimin
SUNWiimjd
SUNWiimm
SUNWiimc-l10n
SUNWiimd-l10n
SUNWiimid-l10n
SUNWiimin-l10n
amconsole
) に Instant Messaging サービスが表示されないInstant Messaging が Sun Java System Application Server 配備内の Access Manager ポリシーを使用する場合、Instant Messaging の設定完了時に Application Server を再起動する必要があります。Application Server を再起動しないと、Access Manager コンソール (amconsole
) 内に Instant Messaging サービスが表示されません。
LDAP に関する次のような問題が、特定の配備環境で発生する可能性があります。iim.conf 内の対応する LDAP パラメータを変更してください。
デフォルトでは、Instant Messaging サーバーは LDAP ディレクトリの匿名検索を実行します。しかし一般的なサイトでは、任意のユーザーがすべての情報を検索して取得してしまわないように、ディレクトリに対する匿名検索は禁止されています。サイトのディレクトリがそのような匿名検索を禁止するように設定されていて、かつインストール後の設定時にバインド資格を指定しなかった場合、バインドと検索実行を行うためのユーザー ID とパスワードを使って Instant Messaging サーバーを設定する必要があります。
必要な資格情報を設定するには、iim_ldap.usergroupbinddn と iim_ldap.usergroupbindcred の各パラメータを使用します。
iim.conf を開きます。
iim.conf の場所、およびこのファイルを変更する手順については、「iim.conf ファイルの構文」を参照してください。
サーバーがディレクトリへのバインドに使用する DN を、iim_ldap.usergroupbinddn の値として指定します。
iim_ldap.usergroupbinddn=bind-DN |
バインド DN に対応するパスワードを、iim_ldap.usergroupbindcred の値として指定します
iim_ldap.usergroupbindcred=password |
ファイルを保存して閉じます。
Instant Messenger が連絡先の名前を表示する方法をカスタマイズすることができます。Instant Messenger が連絡先の名前を表示するために使用するデフォルトの属性は、cn です。連絡先の名前は、First Name、Last Name として表示されます。たとえば、Frank Smith, Mary Jones のようになります。
連絡先の名前の表示に使用する属性を指定するには、iim_ldap.userdisplay および iim_ldap.groupdisplay パラメータを使用します。
iim.conf を開きます。
iim.conf の場所、およびこのファイルを変更する手順については、「iim.conf ファイルの構文」を参照してください。
ユーザー名の表示に使用する属性を、iim_ldap.userdisplay の値として指定します。
iim_ldap.userdisplay=user-name-attribute |
グループ名の表示に使用する属性を、iim_ldap.groupdisplay の値として指定します。
iim_ldap.groupdisplay=group-name-attribute |
ファイルを保存して閉じます。
ワイルドカードの使用を許可するようにディレクトリのインデックスが作成されている場合に、連絡先の名前の検索中にワイルドカードを使用できるようにするには、ワイルドカード検索を許可するように Instant Messaging サーバーを設定する必要があります。ただし、ユーザー ID のインデックスが部分文字列検索用に作成されているのでなければ、ワイルドカード検索を許可するとパフォーマンスが低下する恐れがあります。Instant Messaging でワイルドカード検索を許可する手順については、「クライアントユーザーによる連絡先の検索方法の変更」を参照してください。
ディレクトリが標準でないオブジェクトクラスを使ってユーザーとグループを定義している場合、対応する iim_ldap.* パラメータを変更し、inetorgperson と groupofuniquenames を実際の値で置き換える必要があります。
LDAP パラメータの一覧については、「LDAP およびユーザー登録の設定パラメータ」を参照してください。
iim.conf を開きます。
iim.conf の場所、およびこのファイルを変更する手順については、「iim.conf ファイルの構文」を参照してください。
inetorgperson を検索し、ディレクトリ内でユーザーの定義に使用されているオブジェクトクラスで置き換えます。
groupofuniquenames を検索し、ディレクトリ内でグループの定義に使用されているオブジェクトクラスで置き換えます。
ファイルを保存して閉じます。
ディレクトリが uid 属性をユーザー認証に使用しない場合、ディレクトリで使用されている属性を使って Instant Messaging サーバーを設定する必要があります。Instant Messaging はデフォルトで uid を使用します。また、値に uid を含む各フィルタパラメータを変更する必要もあります。
ユーザー認証に使用する属性を指定するには、iim_ldap.loginfilter パラメータを使用します。
iim.conf を開きます。
iim.conf の場所、およびこのファイルを変更する手順については、「iim.conf ファイルの構文」を参照してください。
次のパラメータ内で uid を検索し、ユーザー認証に使用する属性で置き換えます。
iim_ldap.loginfilter
iim_ldap.usergroupbyidsearchfilter
ファイルを保存して閉じます。
ディレクトリが uid 属性をユーザー ID として使用しない場合、ディレクトリで使用されている属性を使って Instant Messaging サーバーを設定する必要があります。Instant Messaging はデフォルトで uid を使用します。さらに、インデックスが作成されていない属性を検索することによるパフォーマンス低下を防げるよう、ディレクトリ内で属性のインデックスを作成するようにしてください。
ユーザー ID に使用する属性を指定するには、iim_ldap.user.uidattr パラメータを使用します。
iim.conf を開きます。
iim.conf の場所、およびこのファイルを変更する手順については、「iim.conf ファイルの構文」を参照してください。
ユーザー ID として使用する属性を、iim_ldap.user.uidattr の値として指定します。
デフォルト値は uid です。
たとえば、loginname 属性を使用するには、iim_ldap.user.uidattr 属性を次のように設定します。
iim_ldap.user.uidattr=loginname
ファイルを保存して閉じます。
インデックス指示を LDAP のインデックス規則に追加します。
index loginname eq
サーバープール内のサーバー間で Presence ステータスが共有されないというエラーが発生した場合、次のことを行います。
サーバー間通信が有効になるようにノードが正しく設定されていることを確認します。設定パラメータと対応する値の一覧については、「サーバープール内の Instant Messaging サーバー間におけるサーバー間通信の設定」を参照してください。
サーバー間のセッション確立エラーがログファイルに含まれていないかチェックします。
Instant Messaging には、監視活動に役立つエージェントが提供されています。このエージェントは、mfwk (monitoring framework management) エージェントと呼ばれます。mfwk エージェントは、CAC (Common Agent Container) に含まれます。mfwk エージェントは Instant Messaging とともにインストールされます。CAC は Java ES に付属しており、Java ES インストーラを使ってインストールされます。監視機能のインストール、有効化、および管理の詳細や、監視対象となる Instant Messaging オブジェクトの概要については、『Sun Java Enterprise System 5 監視ガイド (UNIX 版)』を参照してください。
ウォッチドッグプロセスはサーバーとマルチプレクサを監視し、コンポーネントが停止していることを判別した場合にコンポーネントの再起動を試みます。
ウォッチドッグは、サーバーに対して定期的に接続を確立することにより、サーバーが実行中であるかどうかを判別します。これには、サーバー上の設定に基づき、サーバーに直接接続する場合と、マルチプレクサを通じて接続する場合があります。ウォッチドッグは、サーバーの動作ステータスの調査を試みます。ステータスを判別できない場合、サーバーへの接続を確立しようとします。動作ステータスの調査と接続確立のどちらの処理にも失敗した場合、ウォッチドッグはサーバーを停止および再起動します。
ウォッチドッグを使用する前に、imadmin status コマンドを使用してウォッチドッグが有効で実行中であることを確認してください。デフォルトでは、Instant Messaging のインストール時にウォッチドッグは有効に設定され、実行されています。
imadmin ユーティリティーの詳細については、付録 C 「Instant Messaging imadmin ツールリファレンス」を参照してください。
ウォッチドッグのステータスを確認するには、imadmin コマンド行ユーティリティーを使用します。
imadmin コマンド行ユーティリティーが格納されているディレクトリに移動します。
cd im-svr-base/sbin |
imadmin status を実行します。
./imadmin status watchdog |
imadmin ユーティリティーによって、ウォッチドッグの現在のステータスが返されます。
デフォルトでは、Instant Messaging のインストール時にウォッチドッグは有効に設定されます。iim.conf 内の設定パラメータによってウォッチドッグの有効化と無効化を行うことができます。
iim.conf を開きます。
iim.conf の場所、およびこのファイルを変更する手順については、「iim.conf ファイルの構文」を参照してください。
iim_wd.enable パラメータを次のように設定して、ウォッチドッグを有効または無効にします。
ウォッチドッグを有効にする場合: iim_wd.enable=true
ウォッチドッグを無効にする場合: iim_wd.enable=false
iim.conf ファイルを保存して閉じます。
Instant Messaging サーバーの設定を更新します。
cd im-svr-base/sbin |
./imadmin refresh |
ウォッチドッグのロギング管理は、サーバー、マルチプレクサ、およびカレンダエージェントのロギング管理と同じ方法で行うことができます。ウォッチドッグのログファイルは、im-db-base/log/iim_wd.log として保存されます。
ウォッチドッグを含むすべての Instant Messaging コンポーネントのロギングレベルを設定する方法の詳細については、第 13 章「Instant Messaging のロギングの管理」を参照してください。