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 Automatic Bug Reporting Tool Préférences à 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 Configurer et modifier les paramètres de cet événement.
Configurer des événements ABRT

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 ».
Tableau 22.1. Événements ABRT standard
NomIdentificateur et fichier de configurationDescription
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énement post-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énement post-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 que post-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
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 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 Automatic Bug Reporting Tool ABRT Configuration à partir d'une instance de l'application gnome-abrt en cours d'exécution. Pour lancer l'application, veuillez vous rendre sur Applications Sundry Automatic Bug Reporting Tool.
Configuration des rapports de problèmes ABRT

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.
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.