トラブルシューティング

CentOS エンドポイントへのパッチ適用時に問題が発生した場合は、ログ・ファイルを確認して、発生した問題およびエラーの修正方法を判断します。

ログ・ファイル

トラブルシューティングの精度を上げるために、エラー報告とエラー処理をより明確に示すことで、ロギングを強化しています。

CentOSPluginR2.log

CentOS ダウンロード・プラグイン R2 の実行に関連するダウンロードの結果がリストされています。情報量はロギング・レベルによって異なります。

このログの場所は以下のとおりです。

Windows システムの場合: %PROGRAM FILES%\BigFix Enterprise\BES Server\DownloadPlugins\CentOSR2Protocol
Linux システムの場合: /var/opt/BESServer/DownloadPlugins/CentOSR2Protocol

以下のログ・ファイルが、ディレクトリー /var/opt/BESClient/EDRDeployData のクライアント・フォルダーにあります。

EDR_DeploymentResults.txt: EDR デプロイメントの結果と YUM の出力がリストされています。

register-repo.log: 「CentOS カスタム・リポジトリー管理」ダッシュボードのリポジトリー登録アクションの実行結果が記録されます。

unregister-repo.log: 「CentOS カスタム・リポジトリー管理」ダッシュボードのリポジトリー登録解除アクションの実行結果が記録されます。
yum_history.log: 「YUM トランザクション履歴」ダッシュボードからの実行結果が記録されます。

その他の有用なログ・ファイル:

yum.log: これは YUM がデフォルトで /var/log/yum.log に生成する正式なログです。YUM 関連のすべての操作およびトランザクションが記録されます。

ダウンロード・プラグインのロギング・レベル

ロギング・レベルは、CentOS ダウンロード・プラグイン R2 がログ・ファイルに書き込む詳細情報の量を決定します。%PROGRAM FILES%\BigFix Enterprise\BES Server\DownloadPlugins\CentOSR2Protocol\plugin.ini ファイルでロギング・レベルを設定します。

注: ロギング・レベルの値では、大/小文字が区別されます。

以下のロギング・レベルは、ログに記録される情報量が少ない順にリストされています。

ERROR: ダウンロード・プラグインの実行に関連するエラーが出力されます。このようなエラーは、致命的エラーが発生する直前であることを示している場合があります。
WARNING: ダウンロードの失敗と、失敗の理由に関する情報が出力されます。
INFO: ダウンロードの進行状況とダウンロードの成功に関する一般情報が、最小限のトレース情報とともに出力されます。
DEBUG: 問題のトラブルシューティングに使用される詳細情報が出力されます。これは、使用可能なレベルの中で最も詳細なレベルです。

注: ロギング・レベルを DEBUG に設定すると、ログに記録する情報の量が増えるため、パフォーマンスに影響が及ぶ可能性があります。ロギング・レベルを DEBUG に上げるのは、問題を調査するときだけにとどめる必要があります。

クライアントのデバッグ・ログを有効にする

「パッチ・サポート」サイトから、「Linux パッチ適用のデバッグ・ログを有効化するようにクライアント設定を構成する (Configure the client setting to enable the Debug Log for Linux Patching)」Fixlet (ID #57) を使用します。

プリフェッチ・プラグインのエラー

アクション・スクリプトの execute prefetch plug-in が含まれる行で失敗した Fixlet でアクションを実行した場合、同じプリフェッチ・プラグインに対するすべてのアクション・スクリプトからのそれ以降の呼び出しが、そのエンドポイントで失敗する可能性があります。スクリプトがブラックリストに登録された可能性があり、プリフェッチ・プラグインがエラーになります。

確認するには、クライアント・ログを調べます。プリフェッチ・プラグインを実行する Fixlet アクションに対して、以下のメッセージのいずれかが見つかります。

execute prefetch plug-in' didn't complete within 300 seconds. Black listing plug-ins 
matching the sha1 hash of 'name of 'bash' until agent is restarted.

Execute prefetch plug-in attempting to reuse plug-in which took too long earlier.

この問題を解決するには、以下のアクションを実行します。

BigFix クライアントを再始動して、ブラックリストをクリアします。
_BESClient_ActionManager_PrefetchPlugInTimeoutSeconds クライアント構成設定に、パッチで依存関係をインストールして解決するための十分な時間を設定します。このクライアント設定は、クライアントがスクリプトをブラックリストに登録する前に待機する時間を示します。パッチ・サポート・サイトで使用できる「プリフェッチ・プラグインのタイムアウトの変更 (Change Timeout for Prefetch Plugins)」タスクを使用して、この設定を 30 分 (1800 秒) に設定できます。

注: _BESClient_ActionManager_PrefetchPlugInTimeoutSeconds 設定は、エンドポイントおよびインストール中の Fixlet によって異なります。最適な値を求めるには、最も遅いエンドポイントで設定を 3,000 秒などの高い値に設定し、大きな Fixlet を実行して所要時間を確認します。その時間に 2 を乗算した値を使用できます。あるいは、推奨値ではうまくいかない場合は、クライアント設定を 600 秒に設定し、適宜調整していきます。

/var を noexec としてマウントした場合のエラー

使用可能なすべての Fixlet は、デフォルトでは、エンドポイント上のパーティションである /var ディレクトリーから直接実行される実行可能ファイルを使用します。/var が noexec オプションを使用して設定されている場合、CentOS ダウンロード・プラグイン R2 またはカスタム・リポジトリー・ソリューションのいずれを使用しているかにかかわらず、Fixlet は動作しません。そのため、以下の手順を実行して、/var ディレクトリーが noexec オプションを使用して設定されないようにする必要があります。

クライアント・ログを確認して、プリフェッチ・プラグインから exit code 126 が返されているかどうかを調べます。例:

root ユーザーとして mount を実行し、現在使用されているマウント・オプションを確認します。

[root@host ~]# mount
/dev/mapper/vg_data-lv_root on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw) 
/dev/sda1 on /boot type ext4 (rw,nodev) 
/dev/mapper/vg_data-lv_var on /var type ext4 (rw,noexec,nosuid,nodev) 
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

/var が noexec に設定されている場合は、以下のいずれかのアクションを実行する必要があります。

noexec マウント・オプションを解除する。
/var/opt/BESClient を noexec でない別のパーティションに移動し、そこへのシンボリック・リンクを元の場所に作成する。
「_BESClient_LinuxPatch_executable_directory のパスの設定 (Set the path for _BESClient_LinuxPatch_executable_directory)」Fixlet を実行して、パッチ適用の実行可能ファイルを実行するための代替ディレクトリーを指定します。ディレクトリー・パスは、有効な絶対パス名でなければなりません。使用できるのは英数字、スラッシュ、および下線のみです。

GPG キーがない

適用時の問題を回避するためには、パッチ Fixlet を適用する前にFixlet サイトから入手可能な「RPM-GPG-KEY-centos-release のインポート (Import RPM-GPG-KEY-centos-release)」タスク (ID# 301) を適用します。

リポジトリー・メタデータが大きすぎる

パッチ適用で使用されるリポジトリー・メタデータは、ベンダーによって提供されるものであり、サイズが大きい場合があります。/var ディレクトリーにメタデータを保管するための十分なスペースがない場合は、そのエンドポイント上でメタデータを保管できるだけの十分なスペースを持つ代替ディレクトリーを設定します。「_BESClient_LinuxPatch_metadata_directory のパスの設定 (Set the path for _BESClient_LinuxPatch_metadata_directory)」を使用すると、リポジトリー・メタデータが作成されるディレクトリーを設定できます。

BigFix Patch ダウンロード・プラグインの構成時に Null エラーが発生する

Null エラーを回避するために、BigFix サーバーと BigFix サーバー上の BigFix クライアントは必ず同じバージョンにしてください。このエラーが発生するのは、BigFix サーバー 8. x バージョンと 9.x バージョンが異なる方法で暗号化を処理するためです。Bigfix サーバー上のクライアントのバージョンを使用して BigFix サーバーのバージョンが判別され、Bigfix サーバーと BigFix サーバー上のクライアントのバージョンが同じであると想定されます。

BigFix サーバーと BigFix サーバー上の BigFix クライアントのバージョンが一致することを確認して、ダウンロード・プラグインの構成時に Null エラーが発生しないようにしてください。少なくとも、バージョンは、同じメジャー・バージョン・レベル (たとえば、8.x または 9.x) でなければなりません。