22.3. Configurer ABRT
Le cycle de vie d'un problème est dirigé par des événements dans ABRT. Par exemple :
- Événement #1 — un répertoire de données des problèmes (« Problem-data directory ») est créé.
- Événement #2 — les données des problèmes sont analysées.
- Événement #3 — le problème est rapporté sur Bugzilla.
Lorsqu'un problème est détecté, ABRT le compare avec toutes les données des problèmes existants et détermine si le même problème a déjà été enregistré. Si c'est le cas, les données existantes du problème sont mises à jour, et le problème le plus récent (dupliqué) n'est pas ré-enregistré. Si le problème n'est pas reconnu par ABRT, un répertoire de données des problèmes est créé. Un répertoire de données des problèmes consiste habituellement en fichiers :
analyzer
, architecture
, coredump
, cmdline
, executable
, kernel
, os_release
, reason
, time
, et uid
.
D'autres fichiers, tels que
backtrace
, peuvent être créés pendant l'analyse du problème, selon la méthode de l'analyseur utilisée et ses paramètres de configuration. Chacun de ces fichiers contient des informations spécifiques sur le système et le problème. Par exemple, le fichier kernel
enregistre la version du noyau tombé en panne.
Une fois que le répertoire « Problem-data » est créé et que les données des problèmes sont collectées, le problème peut être traité en utilisant l'interface utilisateur graphique ABRT, ou l'utilitaire abrt-cli sur la ligne de commande. Veuillez consulter la Section 22.5, « Gestion des problèmes détectés » pour obtenir des informations supplémentaires sur les outils ABRT fournis pour travailler avec les problèmes enregistrés.
22.3.1. Configurer des événements
Les événements ABRT utilisent des greffons pour effectuer les opérations de rapport. Les greffons sont des utilitaires compacts appelés par les événements pour traiter le contenu des répertoires de données des problèmes. À l'aide des greffons, ABRT est capable de rapporter des problèmes sur diverses destinations, et presque toutes les destinations de rapports requièrent une certaine configuration. Par exemple, Bugzilla requiert un nom d'utilisateur, un mot de passe et un URL pointant vers une instance du service Bugzilla.
Certains détails de configuration peuvent avoir des valeurs par défaut (comme l'URL de Bugzilla), mais ce n'est pas le cas pour tous (par exemple un nom d'utilisateur). ABRT recherche ces paramètres dans les fichiers de configuration, tels que
report_Bugzilla.conf
, dans les répertoires /etc/libreport/events/
ou $HOME
/.cache/abrt/events/
pour les paramètres système globaux ou les paramètres spécifiques à l'utilisateur, respectivement. Les fichiers de configuration contiennent des paires de directives et de valeurs.
Ces fichiers correspondent au minimum absolu nécessaire à l'exécution d'événements et au traitement des répertoires de données des problèmes. Les outils
gnome-abrt
et abrt-cli
lisent les données de configuration de ces fichiers et les passent aux événements qu'ils exécutent.
Des informations supplémentaires sur les événements (comme les descriptions, les noms, les types de paramètres pouvant être passés en tant que variables d'environnements et autres propriétés) sont stockées dans les fichiers
event_name.xml
du répertoire /usr/share/libreport/events/
. Ces fichiers sont utilisés par gnome-abrt et abrt-cli pour rendre l'interface utilisateur plus conviviale. Ne modifiez pas ces fichiers à moins de souhaiter modifier l'installation standard. Si vous comptez modifier celle-ci, veuillez copier le fichier à modifier sur le répertoire /etc/libreport/events/
et modifiez le nouveau fichier. Ces fichiers peuvent contenir les informations suivantes :
- un nom d'événement convivial et une description (Bugzilla, rapport au suivi de bogues Bugzilla),
- une liste d'éléments d'un répertoire de données de problèmes dont on a besoin pour que l'événement réussisse,
- une sélection par défaut et une sélection obligatoire d'éléments à envoyer ou à ne pas envoyer,
- si la GUI doit demander de vérifier les données,
- quelles options de configuration existent, leurs types (chaîne, booléen, etc.), valeur par défaut, chaîne d'invite, etc. ; ceci permet à la GUI de créer les boîtes de dialogue appropriées.
Par exemple, l'événement
report_Logger
accepte un nom de fichier de sortie en tant que paramètre. En utilisant le fichier event_name.xml
respectif, l'interface utilisateur graphique ABRT détermine quels paramètres peuvent être spécifiés pour un événement sélectionné et permet à l'utilisateur de définir les valeurs de ces paramètres. Les valeurs sont enregistrées par l'interface utilisateur graphique ABRT et réutilisées lors des invocations ultérieures de ces événements. Remarquez que l'interface utilisateur graphique ABRT enregistre les options de configuration en utilisant l'outil GNOME Keyring, et en les passant aux événements, remplace les données provenant des fichiers de configuration en texte.
Pour ouvrir la fenêtre de Configuration graphique, veuillez choisir à partir d'une instance en cours d'exécution de l'application gnome-abrt. La fenêtre affiche une liste d'événements qui peuvent être sélectionnés pendant le processus de rapport lors de l'utilisation de la GUI. Lorsque vous sélectionnez l'un des événements configurables, vous pourrez cliquer sur le bouton et modifier les paramètres de cet événement.
Figure 22.1. Configurer des événements ABRT
Important
Tous les fichiers dans la hiérarchie du répertoire
/etc/libreport/
sont lisibles globalement et sont conçus pour être utilisés en tant que paramètres globaux. Ainsi, il n'est pas recommandé de stocker les noms d'utilisateurs, mots de passe, ou toutes autres données sensibles dedans. Les paramètres propres à l'utilisateur (paramétrés dans l'application de la GUI et uniquement lisible par le propriétaire de $HOME
) sont stockés de manière sécurisée dans GNOME Keyring ; il peuvent également être stockés dans un fichier de configuration texte dans $HOME
/.abrt/
pour une utilisation avec abrt-cli
.
Le tableau suivant affiche une sélection des événements d'analyse, de collecte et de rapport par défaut offerts par l'installation standard d'ABRT. Le tableau répertorie chaque nom, identificateur et fichier de configuration d'événement du répertoire
/etc/libreport/events.d/
, ainsi qu'une brève description. Remarquez qu'alors que les fichiers de configuration utilisent des identificateurs d'événements, l'interface utilisateur graphique ABRT fait référence aux événements individuels en utilisant leurs noms. Remarquez également que tous les événements ne peuvent pas être paramétrés à l'aide de la GUI. Pour obtenir des informations sur la manière de définit un événement personnalisé, veuillez consulter la Section 22.3.2, « Créer des événements personnalisés ».
Nom | Identificateur et fichier de configuration | Description |
---|---|---|
uReport |
report_uReport
| Téléverse un μReport sur un serveur FAF. |
Mailx |
report_Mailx
mailx_event.conf
| Envoie le rapport problématique via l'utilitaire Mailx vers une adresse électronique spécifiée. |
Bugzilla |
report_Bugzilla
bugzilla_event.conf
| Rapporte le problème à l'installation spécifiée de l'outil de suivi de bogues Bugzilla. |
Red Hat Customer Support |
report_RHTSupport
rhtsupport_event.conf
| Rapporte le problème au système de Support technique de Red Hat. |
Analyse d'un incident C ou C++ |
analyze_CCpp
ccpp_event.conf
| Envoie le vidage du noyau dans un serveur retrace distant pour analyses, ou effectue une analyse locale si celle à distance échoue. |
Téléverseur de rapports |
report_Uploader
uploader_event.conf
| Téléverse une archive tarball (.tar.gz ) avec des données problématiques sur la destination choisie, en utilisant le protocole FTP ou SCP . |
Analyser le vidage mémoire |
analyze_VMcore
vmcore_event.conf
| Exécute GDB (le débogueur GNU) sur les données problématiques d'un oops de noyau et génère un backtrace du noyau. |
Débogueur GNU local |
analyze_LocalGDB
ccpp_event.conf
| Exécute GDB (le débogueur GNU) sur les données problématiques d'une application et génère un backtrace du programme. |
Collect .xsession-errors |
analyze_xsession_errors
ccpp_event.conf
| Enregistre les lignes utiles du fichier ~/.xsession-errors sur le rapport de problème. |
Logger |
report_Logger
print_event.conf
| Crée un rapport sur le problème et l'enregistre sur un fichier local spécifié. |
Kerneloops.org |
report_Kerneloops
koops_event.conf
| Envoie un problème de noyau sur l'outil de suivi des oops sur kerneloops.org. |
22.3.2. Créer des événements personnalisés
Chaque événement est défini par une structure de règle dans un fichier de configuration respectif. Les fichiers de configuration sont habituellement stockés dans le répertoire
/etc/libreport/events.d/
. Ces fichiers de configuration sont chargés par le fichier de configuration principal, /etc/libreport/report_event.conf
. Vous n'avez nul besoin de modifier les fichiers de configuration par défaut car abr exécutera des scripts qui se trouvent dans /etc/libreport/events.d/
. Ce fichier accepte les métacaractères shell (*, $, ?, etc. ) et interprète les chemins relatifs en fonction de son emplacement.
Chaque règle commence par une ligne débutant par un caractère autre qu'un espace, et toute ligne suivante commençant par le caractère
espace
ou par le caractère de Tabulation
est considérée comme faisant partie de cette règle. Chaque règle consiste de deux parties, la partie condition et la partie programme. La partie condition contient des conditions sous l'une des formes suivantes :
- VAR=VAL
- VAR!=VAL
- VAL~=REGEX
où :
- VAR est soit le mot clé
EVENT
(événement) ou le nom d'un élément de répertoire de données problématiques (tel qu'executable
,package
,hostname
, etc. ), - VAL est soit le nom d'un événement ou d'un élément de données problématiques, et
- REGEX est une expression rationnelle.
La partie du programme est composée des noms de programmes et d'un code interprétable par shell. Si toutes les conditions de la partie Conditions sont valides, le programme sera exécuté dans le shell. Ci-dessous figure un exemple d'événement :
EVENT=post-create date > /tmp/dt echo $HOSTNAME `uname -r`
Cet événement remplacera le contenu du fichier
/tmp/dt
par l'heure et la date actuelles et imprimera le nom d'hôte de la machine et sa version de noyau dans la sortie standard.
Voici un exemple d'événement plus complexe, qui se trouve être l'un des événements prédéfinis. Celui-ci enregistre les lignes utiles du fichier
~/.xsession-errors
sur le rapport de problème d'un problème pour lequel le service abrt-ccpp
a été utilisé, à condition que des bibliothèques X11 aient été chargées au moment où l'application a échoué :
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"
L'ensemble d'événements possibles n'est pas encore définitif. Les administrateurs systèmes peuvent ajouter des événements en fonction de leurs besoins dans le répertoire
/etc/libreport/events.d/
.
Actuellement, les noms d'événements suivants sont fournis avec les installations standards d'ABRT et de libreport :
post-create
- Cet événement est exécuté par
abrtd
pour traiter les nouveaux répertoires de données problématiques créés. Lorsque l'événementpost-create
est exécuté,abrtd
vérifie si les nouvelles données problématiques correspondent à celles des répertoires de problèmes déjà existants. Si un tel répertoire de problèmes existe, les nouvelles données problématiques seront supprimées. Notez que si le script qui se trouve dans la définition de l'événementpost-create
existe avec une valeur non nulle,abrtd
interrompera le processus et abandonnera les données du problème. notify
,notify-dup
- L'événement
notify
est exécuté une fois quepost-create
est terminé. Lorsque l'événement est exécuté, l'utilisateur sait que le problème requiert son attention.notify-dup
est similaire, sauf qu'il est utilisé pour des instances dupliquées d'un même problème. analyze_name_suffix
- où name_suffix est la partie remplaçable du nom de l'événement. Cet événement est utilisé pour traiter les données collectées. Par exemple, l'événement
analyze_LocalGDB
utilise GNU Debugger (GDB) pour traiter l'image mémoire d'une application et produire un backtrace de l'incident. collect_name_suffix
- …où name_suffix est la partie ajustable du nom de l'événement. Cet événement est utilisé pour collecter des informations supplémentaires sur les problèmes.
report_name_suffix
- …où name_suffix est la partie ajustable du nom de l'événement. Cet événement est utilisé pour rapporter un problème.
22.3.3. Paramétrer les rapports automatiques
ABRT peut être configuré pour envoyer des rapports initiaux anonymes, ou μReports, de toute panne ou problème détecté automatiquement, sans interaction de la part de l'utilisateur. Lorsque les rapports automatiques sont activés, les μReport, qui sont normalement envoyés au début du processus de rapport d'incident, sont envoyés immédiatement après la détection d'un incident. Ceci permet d'éviter les cas de support dupliqués, basés sur des incidents identiques. Pour activer la fonctionnalité de rapport automatique, veuillez passer la commande suivante en tant qu'utilisateur
root
:
~]# abrt-auto-reporting enabled
La commande ci-dessus définit la directive à partir d'une instance de l'application gnome-abrt en cours d'exécution. Pour lancer l'application, veuillez vous rendre sur .
AutoreportingEnabled
(rapports automatiques activés) du fichier de configuration /etc/abrt/abrt.conf
sur « yes
». Ce paramètre global s'applique à tous les utilisateurs du système. Remarquez qu'en activant cette option, les rapports automatiques seront également activés dans l'environnement de bureau graphique. Pour activer les rapport automatiques dans l'interface utilisateur graphique ABRT uniquement, veuillez faire basculer l'option Envoyer des uReport automatiquement sur YES
dans la fenêtre Configuration des rapports de problèmes. Pour ouvrir cette fenêtre, veuillez choisir Figure 22.2. Configuration des rapports de problèmes ABRT
Lors de la détection d'un incident, par défaut, ABRT soumet un μReport avec des informations de base sur le problème au serveur ABRT de Red Hat. Le serveur détermine si le problème est connu et offre une courte description du problème ainsi qu'un URL du cas rapporté si celui-ci est connu, ou invite l'utilisateur à le rapporter s'il n'est pas connu.
Note
Un μReport (microrapport) est un objet JSON représentant un problème, tel qu'un incident binaire ou un oops de noyau. Ces rapports sont conçus de manière à être brefs, lisibles en machine, et complètement anonymes, ce qui explique pourquoi ils peuvent être utilisés pour des rapports automatisés. Les μReports permettent de se tenir au fait des incidences de bogues, mais ne fournissent pas suffisamment d'informations pour que les ingénieurs puissent corriger le bogue. Il fut un rapport de bogue complet pour pouvoir ouvrir un dossier de support technique.
Pour changer le comportement par défaut de l'outil de rapports automatique afin de ne plus envoyer de rapports μReport, modifiez la valeur de la directive
AutoreportingEvent
du fichier de configuration /etc/abrt/abrt.conf
de manière à pointer vers un événement ABRT différent. Veuillez consulter le Tableau 22.1, « Événements ABRT standard » pour un aperçu des événements standard.