24.3. ABRT の設定

ABRT では、問題のライフサイクルは イベント によって決定されます。例を示します。
  • イベント 1 — 問題データのディレクトリー作成
  • イベント 2 — 問題データの分析
  • イベント 3 — 問題の Bugzilla 報告
問題が検出されると、ABRT はその問題を既存の問題データと比較し、同じ問題が記録されているかどうかを確認します。記録されている場合には、その既存の問題データが更新され、最新の (重複している) 問題は再度記録されません。問題が ABRT で認識されない場合は、problem-data directory (問題データディレクトリー) が作成されます。問題データディレクトリーは通常、以下のようなファイルで構成されます: analyzer、architecture、coredump、cmdline、executable、kernel、os_release、reason、time、uid。
backtrace などの他のファイルは、問題の分析中に作成される場合があります。これは、使用するアナライザーメソッドやその設定によって異なります。これらのファイルには、それぞれシステムおよび問題自体についての固有の情報が格納されます。たとえば kernel ファイルには、クラッシュしたカーネルのバージョンが記録されます。
問題データディレクトリーが作成され、問題データが収集された後は、 ABRT GUI またはコマンドラインの abrt-cli ユーティリティーを使ってその問題を処理することができます。記録された問題の処理に関する ABRT ツールについての詳細は、「検出された問題の処理」 を参照してください。

24.3.1. イベントの設定

ABRT のイベントは、プラグイン を使って実際のレポーティング操作を行います。プラグインはコンパクトなユーティリティーで、問題データディレクトリーのコンテンツを処理するためにイベントが呼び出します。プラグインを使うことで、ABRT は問題を様々な宛先に報告できます。また、ほとんどの報告先に関しては、何らかの設定が必要になります。たとえば、Bugzilla では、ユーザー名とパスワード、および Bugzilla サービスのインスタンスを指す URL が必要になります。
設定詳細の中にはデフォルト値を含めることが可能なものもありますが (Bugzilla URLなど)、適切なデフォルト値を設定できないものもあります (ユーザー名など)。ABRT は、このような設定を、システムワイドの設定には /etc/libreport/events/ ディレクトリーの、ユーザー固有の設定には $HOME/.cache/abrt/events/ ディレクトリーの report_Bugzilla.conf のような設定ファイルで探します。設定ファイルには、ディレクティブと値のペアが含まれています。
これらのファイルは、イベントの実行と問題データディレクトリーの処理のために最小限必要なものです。gnome-abrt ツールと abrt-cli ツールはこれらのファイルから設定データを読み取り、実行するイベントにこれを渡します。
イベントに関する追加情報 (環境変数としてイベントに渡すことができるパラメーターの説明、名前、タイプ、その他の属性など) は、/usr/share/libreport/events/ ディレクトリーの event_name.xml ファイルに格納されています。このファイルは、ユーザーインターフェースをより使いやすくするために gnome-abrt および abrt-cli で使用されます。標準インストールを変更する場合以外には、このファイルは編集しないでください。編集する場合は、対象ファイルを /etc/libreport/events/ ディレクトリーにコピーして、新規ファイルを修正してください。これらのファイルには、以下の情報が含まれています。
  • ユーザーフレンドリーなイベント名および説明 (Bugzilla、Bugzilla バグトラッカーへのレポート)
  • イベントが正常に実行されるために必要な問題データディレクトリー内のアイテム一覧
  • 送信するおよび送信しないデフォルトおよび必須の選択アイテム
  • GUI がデータ見直しを要求するかどうか
  • 存在する設定オプション、それらのタイプ (文字列、ブール値など)、デフォルト値、プロンプト文字列など。これらにより、GUI が適切な設定ダイアログを構築できます。
たとえば、report_Logger イベントは、出力名をパラメーターとして受け入れます。それぞれの event_name.xml ファイルを使用することで、ABRT GUI は、選択されたイベントに対してどのパラメーターを指定することができるかを判断し、ユーザーはそれらのパラメーターの値を設定できるようになります。設定された値は、ABRT GUI で保存され、イベントが後で呼び出される際に再利用されます。ABRT GUI は GNOME Keyring ツールを使って設定オプションを保存し、これらをイベントに渡すことでテキスト設定ファイルからのデータを上書きすることに注意してください。
グラフィカルの Configuration ウィンドウを開くには、実行中の gnome-abrt アプリケーションのインスタンスから Automatic Bug Reporting Tool → Preferences (設定) を選びます。このウィンドウでは、GUI 使用したレポーティングのプロセス中に選択可能な全イベントの一覧が表示されます。設定可能なイベントを選択すると、Configure ボタンがクリックできる状態となり、そのイベントの設定値を修正することができます。
ABRT イベントの設定

図24.1 ABRT イベントの設定

重要

/etc/libreport/ ディレクトリー階層内のファイルはすべて、全ユーザーが読み取り可能となっており、グローバル設定として使用するためにあります。このため、ユーザー名、パスワード、その他の機密データは、これらのファイル内に保存しないことが推奨されます。ユーザー別の設定 (GUI アプリケーションで設定され、$HOME の所有者のみが読み取り可能) は、GNOME Keyring に安全に保管されます。または、abrt-cli で使用するには、$HOME/.abrt/ 内のテキスト設定ファイルに保管することもできます。
以下の表では、ABRT の標準インストールで提供される、デフォルトの分析、収集、レポートイベントの一部を表示しています。ここでは、/etc/libreport/events.d/ ディレクトリーからの各イベントの名前、識別子、設定ファイルと簡単な説明を一覧表示しています。設定ファイルはイベント識別子を使用しますが、ABRT GUI では個別のイベント名が望ましいことに注意してください。また、すべてのイベントで GUI を使った設定ができるわけではないことにも注意してください。カスタムイベントの定義方法についての情報は、「カスタムイベントの作成」 を参照してください。

表24.1 標準 ABRT イベント

名前識別子および設定ファイル詳細
uReport
report_uReport
 
μReport を FAF サーバーにアップロードします。
Mailx
report_Mailx
mailx_event.conf
問題レポートを Mailx ユーティリティーを介して指定のメールアドレスに送信します。
Bugzilla
report_Bugzilla
bugzilla_event.conf
問題を Bugzilla バグトラッカーの指定インストールにレポートします。
Red Hat Customer Support
report_RHTSupport
rhtsupport_event.conf
問題を Red Hat テクニカルサポートシステムに報告します。
Analyze C/C++ Crash
analyze_CCpp
ccpp_event.conf
コアダンプをリモートの retrace サーバーに送信して分析します。または、リモート分析が失敗した場合は、ローカルの分析を実行します。
Report uploader
report_Uploader
uploader_event.conf
FTP または SCP プロトコルを使用して、問題データの tarball (.tar.gz) アーカイブを、選択した宛先にアップロードします。
Analyze VM core
analyze_VMcore
vmcore_event.conf
カーネル oops の問題データに対して GDB (GNU デバッガ) を実行し、カーネルの backtrace を生成します。
Local GNU Debugger
analyze_LocalGDB
ccpp_event.conf
アプリケーションの問題データに対して GDB (GNU デバッガ) を実行し、問題の backtrace を生成します。
Collect .xsession-errors
analyze_xsession_errors
ccpp_event.conf
~/.xsession-errors ファイルから関連性のある行を問題レポートに保存します。
Logger
report_Logger
print_event.conf
問題レポートを作成して、それを指定のローカルファイルに保存します。
Kerneloops.org
report_Kerneloops
koops_event.conf
カーネルの問題を kerneloops.org の oops トラッカーに送信します。

24.3.2. カスタムイベントの作成

各イベントは、それぞれの設定ファイル内の単一のルール構造によって定義されます。これらの設定ファイルは、通常 /etc/libreport/events.d/ ディレクトリーに格納されます。これらの設定ファイルは、主要設定ファイル /etc/libreport/report_event.conf によって読み込まれます。abrt は /etc/libreport/events.d/ に含まれているスクリプトを実行するので、デフォルトの設定ファイルは編集する必要がありません。このファイルはシェルのメタ文字 (*、$、? など) を受け入れ、その位置に対する相対パスを解釈します。
各 ルール は行頭に空白文字を入れない行で開始します。その後に続く、空白 文字または タブ 文字で始まる行は、すべてこのルールの一部とみなされます。各 ルール は、条件 パートと プログラム パートの 2 部で構成されます。条件パートには、以下のいずれかの形式で条件が記載されます。
  • VAR=VAL
  • VAR!=VAL
  • VAL~=REGEX
ここで、
  • VAR は、EVENT のキーワードまたは問題データディレクトリーの要素の名前です (executable、package、hostname など)。
  • VAL は、イベントまたは問題データの要素名です。
  • REGEX は正規表現です。
プログラムパートは、プログラム名とシェルが解釈可能なコードで構成されます。条件パートにある全条件が有効な場合、プログラムパートがシェルで実行されます。以下は イベント の一例です。 
EVENT=post-create date > /tmp/dt
        echo $HOSTNAME `uname -r`
このイベントは、現在の日付と時刻で /tmp/dt ファイルの内容を上書きし、マシンのホスト名とカーネルのバージョンを標準出力に表示します。
より複雑なイベント (実際の事前設定済みイベントの一例) の例は以下のようになります。このイベントは、abrt-ccpp サービスを使用して処理された問題の問題レポートに ~/.xsession-errors ファイルの関連する行を保存します。クラッシュ発生時点で、クラッシュしたアプリケーションに X11 ライブラリーが読み込まれていることが条件になります。 
EVENT=analyze_xsession_errors analyzer=CCpp dso_list~=.*/libX11.*
        test -f ~/.xsession-errors || { echo "No ~/.xsession-errors"; exit 1; }
        test -r ~/.xsession-errors || { echo "Can't read ~/.xsession-errors"; exit 1; }
        executable=`cat executable` &&
        base_executable=${executable##*/} &&
        grep -F -e "$base_executable" ~/.xsession-errors | tail -999 >xsession_errors &&
        echo "Element 'xsession_errors' saved"
使用される可能性のあるイベントのセットは限定されていません。システム管理者は、必要に応じてイベントを /etc/libreport/events.d/ ディレクトリーに追加できます。
現在、ABRT と libreport の標準インストールでは、以下のイベント名が提供されています。
post-create
このイベントは、abrtd により、新規に作成された問題データディレクトリーを処理するために実行されます。post-create イベントが実行されると、abrtd は、新規の問題データが既存の問題ディレクトリーと一致するかどうかを確認します。一致する問題ディレクトリーがある場合には、それが更新され、新規の問題データは破棄されます。post-create の定義内にスクリプトがゼロ以外の値で存在する場合、abrtd はプロセスを終了し、問題データをドロップすることに注意してください。
notify、notify-dup
notify イベントは、post-create の完了後に実行されます。このイベントが実行されると、問題に注意する必要があることをユーザーが確認できます。notify-dup も同様ですが、これは同一問題が重複して発生した場合に使用されます。
analyze_name_suffix
ここでの name_suffix は、イベント名の置き換え可能な部分です。このイベントは、収集データの処理に使用されます。たとえば、analyze_LocalGDB は GNU Debugger (GDB) ユーティリティー使用してアプリケーションのコアダンプを処理し、クラッシュのバックトレースを生成します。
collect_name_suffix
ここでの name_suffix は、イベント名の調整可能な部分です。このイベントは、問題に関する追加情報を収集するために使用されます。
report_name_suffix
ここでの name_suffix は、イベント名の調整可能な部分です。このイベントは、問題を報告するために使用されます。

24.3.3. 自動レポーティングの設定

ABRT は、検出されたすべての問題またはクラッシュの最初の匿名レポート (μReports とも呼ぶ) をユーザーの対話なしに自動送信するように設定できます。自動レポーティングがオンになっていると、クラッシュ検出の直後に、通常クラッシュレポーティングプロセスの最初に送信される μReport が送信されます。これにより、同一クラッシュについてのサポートケースの重複を効果的に防ぐことができます。自動レポーティング機能を有効にするには、root で以下のコマンドを発行します。 
~]# abrt-auto-reporting enabled
上記のコマンドは、/etc/abrt/abrt.conf 設定ファイル内の AutoreportingEnabled ディレクティブを yes に設定します。このシステムワイドの設定は、システムの全ユーザーに適用されます。このオプションを有効にすると、グラフィカルデスクトップ環境でも自動レポーティングが有効になることに注意してください。ABRT GUI の自動レポーティングのみを有効にするには、Problem Reporting Configuration ウィンドウ内で Automatically send uReport オプションを YES に切り替えてください。このウィンドウを開くには、gnome-abrt アプリケーションの実行中のインスタンス内で Automatic Bug Reporting Tool → ABRT Configuration を選択します。このアプリケーションを起動するには、アプリケーション → 諸ツール → 自動バグ報告ツール (ABRT) に移動します。
ABRT 問題報告ツールの設定

図24.2 ABRT 問題報告ツールの設定

デフォルトでは、ABRT はクラッシュを検出すると、問題の基本情報とともに μReport を Red Hat の ABRT サーバーに提出します。サーバーは問題が既知のものかどうかを判断し、既知の場合はそのケースの URL と問題の簡単な説明を提供します。既知でない場合は、ユーザーに報告するように促します。

注記

μReport (マイクロレポート) は、バイナリークラッシュやカーネル oops などの問題を表す JSON オブジェクトです。これらのレポートは、簡潔で、システム内部で使用でき、完全に匿名になるように設計されています。これらの特長があるために、これらのレポートを自動レポーティングで使用することができます。μReports を使用してバグの発生を追跡することはできますが、通常はエンジニアがバグを修正するのに必要な情報は十分に提供されません。サポートケースを作成するには、詳細なバグレポートが必要になります。
自動レポーティング機能の動作について、μReport の送信から別の動作に変更するには、/etc/abrt/abrt.conf 設定ファイル内の AutoreportingEvent ディレクティブの値を別の ABRT イベントに向けるように修正する必要があります。標準イベントの概要については、表24.1「標準 ABRT イベント」 を参照してください。