Control Manager関連の問題が発生している場合、問題の調査には以下の情報が必要となります。
※Control Manager配下のServerProtect for Linux 3.0への配信不良の問題が発生している場合、下記の製品Q&Aも参照してください。
・アップデートの問題発生時の調査に必要な情報 [Solution ID 1302896]
1. 発生した問題、ServerProtectの使用環境に関する基本的な情報
(1) 問題は今も続いていますか。また、発生頻度はどのくらいありますか。
(2) 問題は簡単に再現できますか。
(3) 問題が再現できる場合は、その手順をお伝えください。
(4) 問題はServerProtectをインストールした全コンピュータ中の何台で起きていますか。
(5) 問題は特定のプラットフォームで起きていますか。
(6) この問題が起こる前、コンピュータは正常に動いていましたか。
(7) 問題が起こる前、システムまたはネットワークに変更を加えましたか。
(8) ServerProtectのSecurityPatchや弊社から個別に提供したHotfix（修正モジュール）を適用した経緯があれば、SecurityPatch名やHotfix名を教えてください。
2. Control Manager との疎通確認
ServerProtectをインストールしたコンピュータのブラウザへ下記のURLを入力し、へアクセス可能かどうかご確認ください。
https:// Control ManagerのIPアドレスまたはFQDN>:ポート/ControlManager/ClientCGI/cgiDelegate.dll
正常にアクセス可能な場合、下記のようなリターンコードの数値が表示されます。
表示されない場合は、その画面のスクリーンショットを取得してください。
8
-15205
3. OSの基本情報
(1) OSのバージョン情報
Red Hat Enterprise Linux の場合：
# cat /etc/redhat-release
SuSE Linux Enterprise Server / Novell Linux Desktop の場合：
# cat /etc/SuSE-release
MIRACLE LINUXの場合：
# cat /etc/miraclelinux-release
Asianuxの場合：
# cat /etc/asianux-release
(2) bootディレクトリの情報
# ls –al /boot
(3) カーネルおよびアーキテクチャの情報
# uname –a
# rpm –qa | grep kernel
(4) カーネルのrpmパッケージ情報
# rpm –qi kernel
(カーネルパッケージが複数インストールされている場合、uname –a の結果を元に現在起動中のカーネルのrpmパッケージ情報を取得します)
# rpm –qi kernel-2.6.9-5.EL (例)
(5) コンピュータ上に存在しているカーネルフックモジュール(KHM)の情報
# cd /opt/TrendMicro/SProtectLinux/SPLX.module
# ls -al | grep splxmod
(6) KHMのチェックサム
# md5sum /opt/TrendMicro/SProtectLinux/SPLX.module/*
(7) KHMのロード状況
# lsmod | grep splxmod
(8) splxサービスの現在の状態
# /etc/init.d/splx status
(9) SPLXのビルド情報
# rpm -qa | grep splx
(10) KHMのバージョン
# modinfo /opt/TrendMicro/SProtectLinux/SPLX.module/splxmod.o
(11) KHMの作成元について
弊社サポートセンターにご依頼いただき弊社より提供したKHMでしょうか、それともお客様独自にコンパイルされたKHMでしょうか。
以上の情報を”GeneralInfo.txt”と言うファイル名のテキストファイルへまとめて出力してください
4. システムのログファイル
初期設定では、/var/log/messages に記録されます。
ログローテートされたファイル(/var/log/messages.*)も含めて採取してください。
5. MCPエージェントのデバッグログ
(1) viなどのテキストエディタで、/opt/TrendMicro/SProtectLinux/tmsplx.xmlファイルの下記部分を編集します。(初期設定では下記の値が”1”になっています。)
<P Name=”ControlManagerDebug” value=”3”/>
(2) splxサービスを再起動します。
# /etc/init.d/splx restart
(3) 問題を再現させます。
(4) 手順(1)で編集したtmsplx.xmlファイルを元の値に戻します。
(5) splxサービスを再起動します。
# /etc/init.d/splx restart
(6) CDT(Case Diagnostic Tool)データの取得
※ MCPエージェントのデバッグログは、/opt/TrendMicro/SProtectLinux/EntityMain.logとして記録されますが、このファイルを含め調査に必要な基本情報が以下のツールによってまとめて取得可能です。
# /opt/TrendMicro/SProtectLinux/SPLX.util/DiagnosticTool
Collecting product info...
Collecting system info...
Collect info success!
上記コマンド実行後、/var/log/TrendMicro/CDT_Data/ 配下にある下記のファイルを取得してください。
YYYYMMDD-hhmmss.tgz
(YYYYMMDD-hhmmss は、データを取得した日時[年月日-時分秒])
※ tgzファイルの中身は、ファイル名と同じ名前のディレクトリ内に保存されています。
6. ServerProtectのデバッグログ
(1) viなどのテキストエディタで、/etc/syslog.confへ下記のエントリを追記します。
local3.debug /var/log/vsapiapp.log (vsapiapp デバッグログ用)
(2) syslogdデーモンを再起動します。
# /etc/init.d/syslog restart
(3) ServerProtectサービスを停止します。
# /etc/init.d/splx stop
(4) viなどのテキストエディタで、/opt/TrendMicro/SProtectLinux/tmsplx.xmlファイルの以下の部分を編集します。
P Name="UserDebugLevel" Value="5" (vsapiappデバッグログ用。初期設定では”1”)
(5) ServerProtectサービスを起動します。
/etc/init.d/splx start
(6) 問題を再現させます。
(7) 以下のファイルにデバッグログは出力されますので、これらを取得します。
/var/log/vsapiapp.log
(8) 手順(4)で書き換えたtmsplx.xmlファイルおよび、手順(1)で書き換えた/etc/syslog.confファイルを元の値に戻します。
(9) ServerProtectおよびsyslogdサービスを再起動し、デバッグモードを終了します。
# /etc/init.d/splx restart
# /etc/init.d/syslog restart
7. Control ManagerのIISログ
Control Manager側でIISのログを取得してください。
初期設定では、%SystemRoot%¥system32¥LogFiles¥W3SVC1 (%SystemRoot%はC:¥WINDOWSまたはC:¥WINNT)ディレクトリへ、exYYMMDD.logのファイル名で記録されます。(YYMMDDは年月日)
Control ManagerのWebサイトが「規定のWebサイト」以外にインストールされている場合、W3SVC1以外のディレクトリに記録される可能性がありますので、ログファイル内に”ControlManager” , “jakarta”等の記述がある事をご確認ください。