docs December 2013

docs@lists.fedoraproject.org

17 participants
38 discussions

#5214: Setup koji tags and repo for Docs
by Fedora Release Engineering 21 Jan '14

21 Jan '14

#5214: Setup koji tags and repo for Docs -----------------------------+------------------------ Reporter: crantila | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 18 Alpha | Component: koji Keywords: docs | Blocked By: Blocking: | -----------------------------+------------------------ Posted here as per [https://fedorahosted.org/fedora- infrastructure/ticket/3320] '''phenomenon''' To support simpler and more robust updates to docs.fp.o, need to setup koji to handle a new tag and repo for Docs. '''implementation recommendation''' <Sparks> What would be required to stand up a separate instance of koji for Docs? <dgilmore> Sparks: why would you want a seperate instance? <dgilmore> Sparks: i dont see any valid reason to do so <Sparks> dgilmore: For the Docs website. Publican has the ability publish documentation from packages (separate repo from the Fedora repo) for the website. We want to replace the git repo that operates it now. <dgilmore> Sparks: and why does that need a seperate koji? <Sparks> The git repo has gotten HUGE and is becoming an issue. <dgilmore> Sparks: so, why does that mean a seperate koji instance <dgilmore> Sparks: we could use a seperate tag and targets in koji <dgilmore> i dont see why it would need its own koji <Sparks> dgilmore: It's either that or try to get everyone setup as packagers. <dgilmore> Sparks: get everyone setup as packagers <Sparks> dgilmore: Except that they really won't be packagers. <dgilmore> Sparks: though you dont need to be a a packager to get a koji cert <dgilmore> you just need fas <dgilmore> Sparks: what would be the workflow? <Sparks> dgilmore: Okay, and with that we can send packages through koji and tag them separately? <Sparks> dgilmore: Basically we just tell Publican to build the package and submit it to koji. The Publican software does all the work. <dgilmore> Sparks: I still really dont know what your trying to do. pretend im an idiot(not really that hard) and explain what it is and how it should work <Sparks> dgilmore: I'm not far off... <Sparks> dgilmore: So Publican will make an SRPM package, submit it to koji destined for a repo. Our Publican backend will install those packages and publish the data to the website. <Sparks> ...as I understand it <dgilmore> Sparks: so we would need to set up seperate tags and tagets for it, defining a koji policy allowing srpms to be built. likely we would add a new group to koji and add people allowed to build docs to it and limit access to the tags/targets to people in that group <dgilmore> Sparks: so its all doable <Sparks> dgilmore: Well that's a lot easier. :) <Sparks> dgilmore: We already have a group in FAS for people that should have access (docs- publishers). Should I open a ticket? <dgilmore> Sparks: koji doesnt know anything about fas <dgilmore> Sparks: please file a ticket. We wont be able to make changes until after f17 is done <Sparks> dgilmore: That's fine. We're not completely ready for the transition so after F17 would be good. <Sparks> dgilmore: Thanks! -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5214> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 15

About System Administrator's Guide
by Rashadul Islam 31 Dec '13

31 Dec '13

Hi, I have highlighted my name on the Docs Project Guides Table<https://fedoraproject.org/wiki/Docs_Project_guides_table>. I am looking for all cooperation as I am new to maintain the System Administrator's Guide. Thank you Pete for the opportunity. -rashadul Key fingerprint = E27F 7100 0BA2 7212 CD3C A11F 7A38 DF4E F4EB A95C

1 0

Docs FAD 2014
by Eric Christensen 31 Dec '13

31 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 It's been a while[0] since we've all gathered around a table and broke bread (or pizza). I wonder if it's time to have another FAD and get people focused on knocking out some of the documentation problems we've seem to had over the past few releases with regards to new features (and old ones going away). We will also have a new publishing system by then (hopefully) so it might be good to make sure everyone is on the same page. With that, I introduce the idea of the Docs FAD 2014[1]. Since our group has become quite diverse (geographically, among other traits) I'm thinking that having two FADs linked by video teleconferencing would work the best. The Brno office already has said that they'd be interested in doing this and I'm hoping I can get the Raleigh office onboard as well. If you are interested in participating please add your name to the list[2] and include your means of travel (of if you're local say so). I'm going to try to get a budget for this to help people travel and stay. It would also be good to include weekends that you are available to do this in January. Thanks! [0] https://fedoraproject.org/wiki/FAD_SELF_2009 [1] https://fedoraproject.org/wiki/Docs_FAD_2014 [2] https://fedoraproject.org/wiki/Docs_FAD_2014#Participants - -- Eric - -------------------------------------------------- Eric "Sparks" Christensen Fedora Project sparks(a)fedoraproject.org - sparks(a)redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQGcBAEBCgAGBQJSik9hAAoJEB/kgVGp2CYvoFgL/21eqDddqGzaHs1j03petxMG OByisqAw6Lo8TxlnEy73WeOteFn78ehYd1FvWKTiJ6yibfIWzG4YYGl8Un8xIsm1 2e2RCwnzbRXnamFlfc3jOYTV3YayAmJ9sEIpYrrifKgWO9HECROpNX9ncvl9+Y74 GdH8dVklQARym3D6wwIUYbQh174gCtNdage1GAz+1vvHmyRRp2fcqlZP4PuTebcz yC+4WVxaODQOwi5extykTOZukInktETqh49fL53ahKJ8hd+kECJqVcKrdzNE85xG /r/KPjeT/FhK97kgQb5sewK6HhJ0Bj6QV2+pY3nVosHqhWEqXf0DGlbupyN8CvBv i5ORvJ9EOrA3cvO2QabEgtYkbftUC94izpu3f5NJ6trnGOQEsrC/MtDs9BhOmNn0 veW58MHGSrWCr6B3XaFrpAZZV7XVZv9lvv8v0md10J4mBggOXAwEEEJABdS2YMLi 6GwPbdxJrTlKOoBZ0n3ZSsqFDxhTAdN/SAaGAGBNTg== =n8Nh -----END PGP SIGNATURE-----

5 9

Re: [System Administrator's Guide] Automating_System_Tasks
by Rashadul Islam 31 Dec '13

31 Dec '13

On Tue, Dec 31, 2013 at 2:53 AM, Pete Travis <me(a)petetravis.com> wrote: > On 12/30/2013 06:17 PM, Pete Travis wrote: > > > On Dec 30, 2013 5:44 PM, "Rashadul Islam" <rashadul(a)fedoraproject.org> > wrote: > > > > commit 8bcd1feb7f276bc217c3938d92017b47fe189af8 Mon Sep 17 00:00:00 2001 > > Author: Rashadul Islam <rashadul(a)fedoraproject.org> > > Date: Mon, 30 Dec 2013 19:30:12 -0500 > > > > To up-to-date the Automating_System_Tasks; there is no > privileged update in this docment. > > > > --- > > Automating_System_Tasks.xml | 447 > ++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 447 insertions(+) > > create mode 100644 Automating_System_Tasks.xml > > > > diff --git a/Automating_System_Tasks.xml b/Automating_System_Tasks.xml > > new file mode 100644 > > index 0000000..3b3540f > > --- /dev/null > > +++ b/A.... > > Your method of creating patches produces a diff against an empty file > instead of the original. The patch won't apply, and we can't review to see > what you have changed because even an unchanged file results in a full diff > against /dev/null. > > Later today - as in 2-5 hours from now, once I'm home - I will add a > section to the documentation guide on this process. If you clone the > documentation guide's git repo now, a quick `git pull` will bring in the > instructions as soon as I reply here to say they are available. > > --Pete > > Looks like my phone needs a bigger reply-to-all button... > > You can find the promised instructions at > http://fedorapeople.org/groups/docs/docs-guide/sect-workflow-patching.html. Something went wrong with the formatting of the example patch at the > beginning of the section, so disregard it for now. After reading, if you > have any questions on the process or suggestions for improvements, do speak > up. > > -- > -- Pete Travis > - Fedora Docs Project Leader > - 'randomuser' on freenode > - immanetize(a)fedoraproject.org > > Thank you for the document which is awesome. I am trying to follow cloning through ssh but failed. Hope I can find a solution to solve the problems on the patch. Always good to hear from you.

1 0

Re: [System Administrator's Guide] Automating_System_Tasks
by Pete Travis 31 Dec '13

31 Dec '13

On 12/30/2013 06:17 PM, Pete Travis wrote: > > > On Dec 30, 2013 5:44 PM, "Rashadul Islam" <rashadul(a)fedoraproject.org > <mailto:rashadul@fedoraproject.org>> wrote: > > > > commit 8bcd1feb7f276bc217c3938d92017b47fe189af8 Mon Sep 17 00:00:00 2001 > > Author: Rashadul Islam <rashadul(a)fedoraproject.org > <mailto:rashadul@fedoraproject.org>> > > Date: Mon, 30 Dec 2013 19:30:12 -0500 > > > > To up-to-date the Automating_System_Tasks; there is no > privileged update in this docment. > > > > --- > > Automating_System_Tasks.xml | 447 > ++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 447 insertions(+) > > create mode 100644 Automating_System_Tasks.xml > > > > diff --git a/Automating_System_Tasks.xml b/Automating_System_Tasks.xml > > new file mode 100644 > > index 0000000..3b3540f > > --- /dev/null > > +++ b/A.... > > Your method of creating patches produces a diff against an empty file > instead of the original. The patch won't apply, and we can't review > to see what you have changed because even an unchanged file results in > a full diff against /dev/null. > > Later today - as in 2-5 hours from now, once I'm home - I will add a > section to the documentation guide on this process. If you clone the > documentation guide's git repo now, a quick `git pull` will bring in > the instructions as soon as I reply here to say they are available. > > --Pete > Looks like my phone needs a bigger reply-to-all button... You can find the promised instructions at http://fedorapeople.org/groups/docs/docs-guide/sect-workflow-patching.html . Something went wrong with the formatting of the example patch at the beginning of the section, so disregard it for now. After reading, if you have any questions on the process or suggestions for improvements, do speak up. -- -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode - immanetize(a)fedoraproject.org

1 0

[System Administrator's Guide] Automating_System_Tasks
by Rashadul Islam 30 Dec '13

30 Dec '13

commit 8bcd1feb7f276bc217c3938d92017b47fe189af8 Mon Sep 17 00:00:00 2001 Author: Rashadul Islam <rashadul(a)fedoraproject.org> Date: Mon, 30 Dec 2013 19:30:12 -0500 To up-to-date the Automating_System_Tasks; there is no privileged update in this docment. --- Automating_System_Tasks.xml | 447 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 447 insertions(+) create mode 100644 Automating_System_Tasks.xml diff --git a/Automating_System_Tasks.xml b/Automating_System_Tasks.xml new file mode 100644 index 0000000..3b3540f --- /dev/null +++ b/Automating_System_Tasks.xml @@ -0,0 +1,447 @@ +<?xml version='1.0'?> +<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> +<chapter id="ch-Automating_System_Tasks"> + <title>Automating System Tasks</title> + <indexterm significance="normal"> + <primary>Automated Tasks</primary> + </indexterm> + <para>In Linux, tasks, which are also known as <firstterm>jobs</firstterm>, can be configured to run automatically within a specified period of time, on a specified date, or when the system load average is below a specified number. &MAJOROS; is pre-configured to run important system tasks to keep the system updated. For example, the slocate database used by the <command>locate</command> command is updated daily. A system administrator can use automated tasks to perform periodic backups, monitor the system, run custom scripts, and more.</para> + <para>&MAJOROS; comes with several automated tasks utilities: <command>cron</command>, <command>at</command>, and <command>batch</command>.</para> + <indexterm significance="normal"> + <primary>Cron</primary> + </indexterm> + <section id="s1-autotasks-cron-anacron"> + <title>Cron and Anacron</title> + <indexterm significance="normal"> + <primary>anacron</primary> + </indexterm> + <indexterm significance="normal"> + <primary> + <filename>cron</filename> + </primary> + </indexterm> + <para>Both, <systemitem class="daemon">Cron</systemitem> and <systemitem class="daemon">Anacron</systemitem>, are daemons that can be used to schedule the execution of recurring tasks according to a combination of the time, day of the month, month, day of the week, and week.</para> + <para><systemitem + class="daemon">Cron</systemitem> assumes that the system is on continuously. If the system is not on when a job is scheduled, it is not executed. Cron allows jobs to be run as often as every minute. Anacron does not assume the system is always on, remembers every scheduled job, and executes it the next time the system is up. However, Anacron can only run a job once a day. + To schedule recurring jobs, refer to <xref linkend="s2-configuring-anacron-jobs"/> or <xref linkend="s2-configuring-cron-jobs"/>. To schedule one-time jobs, refer to <xref linkend="s1-autotasks-at-batch"/>.</para> + <para>To use the cron service, the <filename>cronie</filename> RPM package must be installed and the <command>crond</command> service must be running. <filename>anacron</filename> is a sub-package of <filename>cronie</filename>. To determine if these packages are installed, use the <command>rpm -q cronie cronie-anacron</command> command. </para> + + <section id="s2-autotasks-cron-service"> + <title>Starting and Stopping the Service</title> + <para>To determine if the service is running, use the following command:</para> + <screen><command>systemctl is-active crond.service</command></screen> + <para>To start the cron service, type the following at a shell prompt as <systemitem class="username">root</systemitem>:</para> + <screen><command>systemctl start crond.service</command></screen> + <para>To stop the service, run the following command as <systemitem class="username">root</systemitem>:</para> + <screen><command>systemctl stop crond.service</command></screen> + <para>It is recommended that you start the service at boot time. To do so, use the following command as <systemitem class="username">root</systemitem>:</para> + <screen><command>systemctl enable crond.service</command></screen> + <para> + Refer to <xref linkend="ch-Services_and_Daemons" /> for more information on how to configure services in &MAJOROS;. + </para> + </section> + <section id="s2-configuring-anacron-jobs"> + <title>Configuring Anacron Jobs</title> + <indexterm significance="normal"> + <primary>anacron</primary> + <secondary>anacron configuration file</secondary> + </indexterm> + <indexterm significance="normal"> + <primary> + <filename>anacrontab</filename> + </primary> + </indexterm> + <indexterm + significance="normal"> + <primary>anacron</primary> + <secondary>user-defined tasks</secondary> + </indexterm> + <indexterm + significance="normal"> + <primary> + <filename>/var/spool/anacron</filename> + </primary> + </indexterm> + <para>The main configuration file to schedule jobs is <filename>/etc/anacrontab</filename> (only <systemitem class="username">root</systemitem> is allowed to modify this file), which contains the following lines:</para> + <programlisting>SHELL=/bin/sh +PATH=/sbin:/bin:/usr/sbin:/usr/bin +MAILTO=root +# the maximal random delay added to the base delay of the jobs +RANDOM_DELAY=45 +# the jobs will be started during the following hours only +START_HOURS_RANGE=3-22 + +#period in days delay in minutes job-identifier command +1 5 cron.daily nice run-parts /etc/cron.daily +7 25 cron.weekly nice run-parts /etc/cron.weekly +@monthly 45 cron.monthly nice run-parts /etc/cron.monthly</programlisting> + <para> + The first three lines are variables used to configure the environment in which the anacron tasks are run. The <computeroutput>SHELL</computeroutput> variable tells the system which shell environment to use (in this example the bash shell). The <computeroutput>PATH</computeroutput> variable defines the path used to execute commands. The output of the anacron jobs are emailed to the username defined with the <computeroutput>MAILTO</computeroutput> variable. If the <computeroutput>MAILTO</computeroutput> variable is not defined, (i.e. is empty, <computeroutput>MAILTO=</computeroutput>), email is not sent. +</para> + <para> + The next two lines are variables that modify the time for each scheduled job. The <computeroutput>RANDOM_DELAY</computeroutput> variable denotes the maximum number of minutes that will be added to the <filename>delay in minutes</filename> variable which is specified for each job. The minimum delay value is set, by default, to 6 minutes. A <computeroutput>RANDOM_DELAY</computeroutput> set to 12 would therefore add, randomly, between 6 and 12 minutes to the <filename>delay in minutes</filename> for each job in that particular anacrontab. <computeroutput>RANDOM_DELAY</computeroutput> can also be set to a value below 6, or even 0. When set to 0, no random delay is added. This proves to be useful when, for example, more computers that share one network connection need to download the same data every day. The <computeroutput>START_HOURS_RANGE</computeroutput> variable defines an interval (in hours) when scheduled jobs can be run. In case this time interval is missed, for example , due to a power down, then scheduled jobs are not executed that day. +</para> + <para>The rest of the lines in the <filename>/etc/anacrontab</filename> file represent scheduled jobs and have the following format: +</para> + <programlisting>period in days delay in minutes job-identifier command</programlisting> + <itemizedlist> + <listitem> + <para> + <computeroutput>period in days</computeroutput> — specifies the frequency of execution of a job in days. This variable can be represented by an integer or a macro (<computeroutput>@daily</computeroutput>, <computeroutput>@weekly</computeroutput>, <computeroutput>@monthly</computeroutput>), where <computeroutput>@daily</computeroutput> denotes the same value as the integer 1, <computeroutput>@weekly</computeroutput> the same as 7, and <computeroutput>@monthly</computeroutput> specifies that the job is run once a month, independent on the length of the month. + </para> + </listitem> + <listitem> + <para> + <computeroutput>delay in minutes</computeroutput> — specifies the number of minutes anacron waits, if necessary, before executing a job. This variable is represented by an integer where 0 means no delay. + </para> + </listitem> + <listitem> + <para> + <computeroutput>job-identifier</computeroutput> — specifies a unique name of a job which is used in the log files. + </para> + </listitem> + <listitem> + <para> + <computeroutput>command</computeroutput> — specifies the command to execute. The command can either be a command such as <computeroutput>ls /proc >> /tmp/proc</computeroutput> or a command to execute a custom script. + </para> + </listitem> + </itemizedlist> + <para>Any lines that begin with a hash sign (#) are comments and are not processed.</para> + <section id="s3-anacron-examples"> + <title>Examples of Anacron Jobs </title> + <para>The following example shows a simple <filename>/etc/anacrontab</filename> file:</para> + <programlisting>SHELL=/bin/sh +PATH=/sbin:/bin:/usr/sbin:/usr/bin +MAILTO=root + +# the maximal random delay added to the base delay of the jobs +RANDOM_DELAY=30 +# the jobs will be started during the following hours only +START_HOURS_RANGE=16-20 + +#period in days delay in minutes job-identifier command +1 20 dailyjob nice run-parts /etc/cron.daily +7 25 weeklyjob /etc/weeklyjob.bash +@monthly 45 monthlyjob ls /proc >> /tmp/proc</programlisting> + <para> + All jobs defined in this <filename>anacrontab</filename> file are randomly delayed by 6-30 minutes and can be executed between 16:00 and 20:00. Thus, the first defined job will run anywhere between 16:26 and 16:50 every day. The command specified for this job will execute all present programs in the <filename>/etc/cron.daily</filename> directory (using the <command>run-parts</command> script which takes a directory as a command-line argument and sequentially executes every program within that directory). The second specified job will be executed once a week and will execute the <filename>weeklyjob.bash</filename> script in the <filename>/etc</filename> directory. The third job is executed once a month and runs a command to write the contents of the <filename>/proc</filename> to the <filename>/tmp/proc</filename> file (e.g. <computeroutput>ls /proc >> /tmp/proc</computeroutput>). +</para> +<section id="s3-disabling-anacron"> +<title>Disabling Anacron</title> +<para> + In case your system is continuously on and you do not require anacron to run your scheduled jobs, you may uninstall the <filename>cronie-anacron</filename> package. Thus, you will be able to define jobs using crontabs only. +</para> +</section> + </section> + </section> + <section id="s2-configuring-cron-jobs"> + <title>Configuring Cron Jobs</title> + <indexterm + significance="normal"> + <primary>cron</primary> + <secondary>user-defined tasks</secondary> + </indexterm> + <indexterm + significance="normal"> + <primary> + <filename>/var/spool/cron</filename> + </primary> + </indexterm> + <indexterm significance="normal"> + <primary>cron</primary> + <secondary>cron configuration file</secondary> + </indexterm> + <indexterm significance="normal"> + <primary> + <filename>crontab</filename> + </primary> + </indexterm> + <para> + The configuration file to configure cron jobs, <filename>/etc/crontab</filename> (only <systemitem class="username">root</systemitem> is allowed to modify this file), contains the following lines: + </para> + <programlisting>SHELL=/bin/bash +PATH=/sbin:/bin:/usr/sbin:/usr/bin +MAILTO=root +HOME=/ +# For details see man 4 crontabs +# Example of job definition: +# .---------------- minute (0 - 59) +# | .------------- hour (0 - 23) +# | | .---------- day of month (1 - 31) +# | | | .------- month (1 - 12) OR jan,feb,mar,apr ... +# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat +# | | | | | +# * * * * * user command to be executed</programlisting> + <para> + The first three lines contain the same variables as an <filename>anacrontab</filename> file, <computeroutput>SHELL</computeroutput>, <computeroutput>PATH</computeroutput> and <computeroutput>MAILTO</computeroutput>. For more information about these variables, refer to <xref linkend="s2-configuring-anacron-jobs"/>. The fourth line contains the <computeroutput>HOME</computeroutput> variable. The <computeroutput>HOME</computeroutput> variable can be used to set the home directory to use when executing commands or scripts. + </para> + <para> + The rest of the lines in the <filename>/etc/crontab</filename> file represent scheduled jobs and have the following format: + </para> + <programlisting>minute hour day month day of week user command</programlisting> + <itemizedlist> + <listitem> + <para> + <computeroutput>minute</computeroutput> — any integer from 0 to 59</para> + </listitem> + <listitem> + <para> + <computeroutput>hour</computeroutput> — any integer from 0 to 23</para> + </listitem> + <listitem> + <para> + <computeroutput>day</computeroutput> — any integer from 1 to 31 (must be a valid day if a month is specified)</para> + </listitem> + <listitem> + <para> + <computeroutput>month</computeroutput> — any integer from 1 to 12 (or the short name of the month such as jan or feb)</para> + </listitem> + <listitem> + <para> + <computeroutput>day of week</computeroutput> — any integer from 0 to 7, where 0 or 7 represents Sunday (or the short name of the week such as sun or mon)</para> + </listitem> + <listitem> + <para> + <computeroutput>user</computeroutput> — specifies the user under which the jobs are run + </para> + </listitem> + <listitem> + <para> + <computeroutput>command</computeroutput> — the command to execute (the command can either be a command such as <command>ls /proc >> /tmp/proc</command> or the command to execute a custom script)</para> + </listitem> + </itemizedlist> + <para>For any of the above values, an asterisk (*) can be used to specify all valid values. For example, an asterisk for the month value means execute the command every month within the constraints of the other values.</para> + <para>A hyphen (-) between integers specifies a range of integers. For example, <userinput>1-4</userinput> means the integers 1, 2, 3, and 4.</para> + <para>A list of values separated by commas (,) specifies a list. For example, <userinput>3, 4, 6, 8</userinput> indicates those four specific integers.</para> + <para>The forward slash (/) can be used to specify step values. The value of an integer can be skipped within a range by following the range with <userinput>/<replaceable>integer</replaceable></userinput>. For example, <userinput>0-59/2</userinput> can be used to define every other minute in the minute field. Step values can also be used with an asterisk. For instance, the value <userinput>*/3</userinput> can be used in the month field to run the task every third month.</para> + <para>Any lines that begin with a hash sign (#) are comments and are not processed.</para> + <para>Users other than <systemitem class="username">root</systemitem> can configure cron tasks by using the <command>crontab</command> utility. All user-defined crontabs are stored in the <filename>/var/spool/cron/</filename> directory and are executed using the usernames of the users that created them. To create a crontab as a user, login as that user and type the command <command>crontab -e</command> to edit the user's crontab using the editor specified by the <computeroutput>VISUAL</computeroutput> or <computeroutput>EDITOR</computeroutput> environment variable. The file uses the same format as <filename>/etc/crontab</filename>. When the changes to the crontab are saved, the crontab is stored according to username and written to the file <filename>/var/spool/cron/<replaceable>username</replaceable> + </filename>. To list the contents of your own personal crontab file, use the <command>crontab -l</command> command. </para> + <note> + <title>Do not specify a user</title> + <para> + When using the <command>crontab</command> utility, there is no need to specify a user when defining a job. + </para> + </note> + <para>The <filename>/etc/cron.d/</filename> directory contains files that have the same syntax as the <filename>/etc/crontab</filename> file. Only <systemitem class="username">root</systemitem> is allowed to create and modify files in this directory.</para> + <note> + <title>Do not restart the daemon to apply the changes</title> + <para>The cron daemon checks the <filename>/etc/anacrontab</filename> file, the <filename>/etc/crontab</filename> file, the <filename>/etc/cron.d/</filename> directory, and the <filename>/var/spool/cron/</filename> directory every minute for any changes. If any changes are found, they are loaded into memory. Thus, the daemon does not need to be restarted if an anacrontab or a crontab file is changed.</para> + </note> + </section> + <section id="s2-autotasks-cron-access"> + <title>Controlling Access to Cron</title> + <para>The <filename>/etc/cron.allow</filename> and <filename>/etc/cron.deny</filename> files are used to restrict access to cron. The format of both access control files is one username on each line. Whitespace is not permitted in either file. The cron daemon (<command>crond</command>) does not have to be restarted if the access control files are modified. The access control files are checked each time a user tries to add or delete a cron job.</para> + <para>The <systemitem class="username">root</systemitem> user can always use cron, regardless of the usernames listed in the access control files.</para> + <para>If the file <filename>cron.allow</filename> exists, only users listed in it are allowed to use cron, and the <filename>cron.deny</filename> file is ignored.</para> + <para>If <filename>cron.allow</filename> does not exist, users listed in <filename>cron.deny</filename> are not allowed to use cron.</para> + <para>Access can also be controlled through Pluggable Authentication Modules (PAM). These settings are stored in <filename>/etc/security/access.conf</filename>. For example, adding the following line in this file forbids creating crontabs for all users except the <systemitem class="username">root</systemitem> user: + </para> + <programlisting>-:ALL EXCEPT root :cron</programlisting> + <para> + The forbidden jobs are logged in an appropriate log file or, when using “crontab -e”, returned to the standard output. For more information, refer to <filename>access.conf.5</filename> (i.e. <command>man 5 access.conf</command>). + </para> + </section> + <section id="s2-black-white-listing-of-cron-jobs"> + <title>Black/White Listing of Cron Jobs</title> + <para> + Black/White listing of jobs is used to omit parts of the defined jobs that do not need to be executed. When calling the <command>run-parts</command> script on a cron folder, such as <filename>/etc/cron.daily</filename>, we can define which of the programs in this folder will not be executed by <command>run-parts</command>. + </para> + <para>To define a black list, create a <filename>jobs.deny</filename> file in the folder that <command>run-parts</command> will be executing from. For example, if we need to omit a particular program from /etc/cron.daily, then, a file <filename>/etc/cron.daily/jobs.deny</filename> has to be created. In this file, specify the names of the omitted programs from the same directory. These will not be executed when a command, such as <computeroutput>run-parts /etc/cron.daily</computeroutput>, is executed by a specific job.</para> + <para>To define a white list, create a <filename>jobs.allow</filename> file.</para> + <para> + The principles of <filename>jobs.deny</filename> and <filename>jobs.allow</filename> are the same as those of <filename>cron.deny</filename> and <filename>cron.allow</filename> described in section <xref linkend="s2-autotasks-cron-access"/>. + </para> + </section> + </section> + <section id="s1-autotasks-at-batch"> + <title>At and Batch</title> + <indexterm significance="normal"> + <primary> + <command>at</command> + </primary> + </indexterm> + <indexterm significance="normal"> + <primary> + <command>batch</command> + </primary> + </indexterm> + <para>While cron is used to schedule recurring tasks, the <command>at</command> command is used to schedule a one-time task at a specific time and the <command>batch</command> command is used to schedule a one-time task to be executed when the systems load average drops below 0.8.</para> + <para>To use <command>at</command> or <command>batch</command>, the <filename>at</filename> RPM package must be installed, and the <command>atd</command> service must be running. To determine if the package is installed, use the <command>rpm -q at</command> command. To determine if the service is running, use the following command:</para> + <screen><command>systemctl is-active atd.service</command></screen> + <section id="s2-autotasks-at-configuring"> + <title>Configuring At Jobs</title> + <para>To schedule a one-time job at a specific time, type the command <command>at <replaceable>time</replaceable> + </command>, where <command><replaceable>time</replaceable> + </command> is the time to execute the command.</para> + <para>The argument <replaceable>time</replaceable> can be one of the following:</para> + <itemizedlist> + <listitem> + <para>HH:MM format — For example, 04:00 specifies 4:00 a.m. If the time is already past, it is executed at the specified time the next day.</para> + </listitem> + <listitem> + <para>midnight — Specifies 12:00 a.m.</para> + </listitem> + <listitem> + <para>noon — Specifies 12:00 p.m.</para> + </listitem> + <listitem> + <para>teatime — Specifies 4:00 p.m.</para> + </listitem> + <listitem> + <para>month-name day year format — For example, January 15 2002 specifies the 15th day of January in the year 2002. The year is optional.</para> + </listitem> + <listitem> + <para>MMDDYY, MM/DD/YY, or MM.DD.YY formats — For example, 011502 for the 15th day of January in the year 2002.</para> + </listitem> + <listitem> + <para>now + time — time is in minutes, hours, days, or weeks. For example, now + 5 days specifies that the command should be executed at the same time five days from now.</para> + </listitem> + </itemizedlist> + <para>The time must be specified first, followed by the optional date. For more information about the time format, read the <filename>/usr/share/doc/at-<replaceable>version</replaceable>/timespec</filename> text file.</para> + <para>After typing the <command>at</command> command with the time argument, the <prompt>at></prompt> prompt is displayed. Type the command to execute, press <keycap>Enter</keycap>, and press <keycombo><keycap>Ctrl</keycap> + <keycap>D</keycap> + </keycombo> . Multiple commands can be specified by typing each command followed by the <keycap>Enter</keycap> key. After typing all the commands, press <keycap>Enter</keycap> to go to a blank line and press <keycombo><keycap>Ctrl</keycap> + <keycap>D</keycap> + </keycombo> . Alternatively, a shell script can be entered at the prompt, pressing <keycap>Enter</keycap> after each line in the script, and pressing <keycombo><keycap>Ctrl</keycap> + <keycap>D</keycap> + </keycombo> on a blank line to exit. If a script is entered, the shell used is the shell set in the user's <envar>SHELL</envar> environment, the user's login shell, or <command>/bin/sh</command> (whichever is found first).</para> + <para>If the set of commands or script tries to display information to standard output, the output is emailed to the user.</para> + <para>Use the command <command>atq</command> to view pending jobs. Refer to <xref linkend="s2-autotasks-at-batch-viewing"/> for more information.</para> + <para>Usage of the <command>at</command> command can be restricted. For more information, refer to <xref linkend="s2-autotasks-at-batch-controlling-access"/> for details.</para> + </section> + + <section id="s2-autotasks-batch-configuring"> + <title>Configuring Batch Jobs</title> + <para>To execute a one-time task when the load average is below 0.8, use the <command>batch</command> command.</para> + <para>After typing the <command>batch</command> command, the <prompt>at></prompt> prompt is displayed. Type the command to execute, press <keycap>Enter</keycap>, and press <keycombo><keycap>Ctrl</keycap> + <keycap>D</keycap> + </keycombo> . Multiple commands can be specified by typing each command followed by the <keycap>Enter</keycap> key. After typing all the commands, press <keycap>Enter</keycap> to go to a blank line and press <keycombo><keycap>Ctrl</keycap> + <keycap>D</keycap> + </keycombo> . Alternatively, a shell script can be entered at the prompt, pressing <keycap>Enter</keycap> after each line in the script, and pressing <keycombo><keycap>Ctrl</keycap> + <keycap>D</keycap> + </keycombo> on a blank line to exit. If a script is entered, the shell used is the shell set in the user's <envar>SHELL</envar> environment, the user's login shell, or <command>/bin/sh</command> (whichever is found first). As soon as the load average is below 0.8, the set of commands or script is executed.</para> + <para>If the set of commands or script tries to display information to standard out, the output is emailed to the user.</para> + <para>Use the command <command>atq</command> to view pending jobs. Refer to <xref linkend="s2-autotasks-at-batch-viewing"/> for more information.</para> + <para>Usage of the <command>batch</command> command can be restricted. For more information, refer to <xref linkend="s2-autotasks-at-batch-controlling-access"/> for details.</para> + </section> + <section id="s2-autotasks-at-batch-viewing"> + <title>Viewing Pending Jobs</title> + <para>To view pending <command>at</command> and <command>batch</command> jobs, use the <command>atq</command> command. The <command>atq</command> command displays a list of pending jobs, with each job on a line. Each line follows the job number, date, hour, job class, and username format. Users can only view their own jobs. If the <systemitem class="username">root</systemitem> user executes the <command>atq</command> command, all jobs for all users are displayed.</para> + </section> + <section id="s2-autotasks-commandline-options"> + <title>Additional Command Line Options</title> + <para>Additional command line options for <command>at</command> and <command>batch</command> include:</para> + <table id="tb-at-command-line-options"> + <title> + <command>at</command> and <command>batch</command> Command Line Options</title> + <tgroup cols="2"> + <colspec colname="option" colnum="1" colwidth="20*"/> + <colspec colname="description" colnum="2" colwidth="50*"/> + <thead> + <row> + <entry>Option</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry> + <option>-f</option> + </entry> + <entry> + Read the commands or shell script from a file instead of specifying them at the prompt. + </entry> + </row> + <row> + <entry> + <option>-m</option> + </entry> + <entry> + Send email to the user when the job has been completed. + </entry> + </row> + <row> + <entry> + <option>-v</option> + </entry> + <entry> + Display the time that the job is executed. + </entry> + </row> + </tbody> + </tgroup> + </table> + </section> + <section id="s2-autotasks-at-batch-controlling-access"> + <title>Controlling Access to At and Batch</title> + <para>The <filename>/etc/at.allow</filename> and <filename>/etc/at.deny</filename> files can be used to restrict access to the <command>at</command> and <command>batch</command> commands. The format of both access control files is one username on each line. Whitespace is not permitted in either file. The <command>at</command> daemon (<command>atd</command>) does not have to be restarted if the access control files are modified. The access control files are read each time a user tries to execute the <command>at</command> or <command>batch</command> commands.</para> + <para>The <systemitem class="username">root</systemitem> user can always execute <command>at</command> and <command>batch</command> commands, regardless of the access control files.</para> + <para>If the file <filename>at.allow</filename> exists, only users listed in it are allowed to use <command>at</command> or <command>batch</command>, and the <filename>at.deny</filename> file is ignored.</para> + <para>If <filename>at.allow</filename> does not exist, users listed in <filename>at.deny</filename> are not allowed to use <command>at</command> or <command>batch</command>.</para> + </section> + + <section id="s2-autotasks-at-batch-service"> + <title>Starting and Stopping the Service</title> + <para>To start the <command>at</command> service, use the following command as <systemitem class="username">root</systemitem>:</para> + <screen><command>systemctl start atd.service</command></screen> + <para>To stop the service, as <systemitem class="username">root</systemitem>, type the following at a shell prompt:</para> + <screen><command>systemctl stop atd.service</command></screen> + <para>It is recommended that you start the service at boot time. To do so, run the following command as <systemitem class="username">root</systemitem>:</para> + <screen><command>systemctl enable atd.service</command></screen> + <para> + Refer to <xref linkend="ch-Services_and_Daemons" /> for more information on how to configure services in &MAJOROS;. + </para> + </section> + </section> + + <section id="s1-autotasks-additional-resources"> + <title>Additional Resources</title> + <indexterm significance="normal"> + <primary>cron</primary> + <secondary>additional resources</secondary> + </indexterm> + <indexterm significance="normal"> + <primary>at</primary> + <secondary>additional resources</secondary> + </indexterm> + <indexterm significance="normal"> + <primary>batch</primary> + <secondary>additional resources</secondary> + </indexterm> + <para>To learn more about configuring automated tasks, refer to the following resources.</para> + + <section id="s2-autotasks-installed-docs"> + <title>Installed Documentation</title> + <itemizedlist> + <listitem> + <para> + <filename>cron</filename> man page — contains an overview of cron.</para> + </listitem> + <listitem> + <para> + <filename>crontab</filename> man pages in sections 1 and 5 — The man page in section 1 contains an overview of the <filename>crontab</filename> file. The man page in section 5 contains the format for the file and some example entries.</para> + </listitem> + <listitem> + <para> + <filename>anacron</filename> man page — contains an overview of anacron. + </para> + </listitem> + <listitem> + <para> + <filename>anacrontab</filename> man page — contains an overview of the <filename>anacrontab</filename> file. + </para> + </listitem> + <listitem> + <para> + <filename>/usr/share/doc/at-<replaceable>version</replaceable>/timespec</filename> contains more detailed information about the times that can be specified for cron jobs.</para> + </listitem> + <listitem> + <para> + <filename>at</filename> man page — description of <command>at</command> and <command>batch</command> and their command line options.</para> + </listitem> + </itemizedlist> + </section> + </section> +</chapter> -- 1.8.1.4

1 0

[System Administrator's Guide] Automatic Bug_Reporting Tool ABRT
by Rashadul Islam 30 Dec '13

30 Dec '13

commit fe9823c5d9510696053d31470aae9bd9d7c2a7a3 Mon Sep 17 00:00:00 2001 Author: Rashadul Islam <rashadul(a)fedoraproject.org> Date: Mon, 30 Dec 2013 18:16:33 -0500 There document is up-to-date and there is nothing to change. --- Automatic_Bug_Reporting_Tool_ABRT.xml | 1644 +++++++++++++++++++++++++++++++++ 1 file changed, 1644 insertions(+) create mode 100644 Automatic_Bug_Reporting_Tool_ABRT.xml diff --git a/Automatic_Bug_Reporting_Tool_ABRT.xml b/Automatic_Bug_Reporting_Tool_ABRT.xml new file mode 100644 index 0000000..8f09069 --- /dev/null +++ b/Automatic_Bug_Reporting_Tool_ABRT.xml @@ -0,0 +1,1644 @@ +<?xml version='1.0' encoding='utf-8' ?> +<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +<!ENTITY % BOOK_ENTITIES SYSTEM "<application>ABRT</application>-2.x.ent"> +%BOOK_ENTITIES; +]> +<chapter + id="ch-abrt"> + <title>Automatic Bug Reporting Tool (<application>ABRT</application>)</title> + <section + id="sect-abrt-overview"> + <title>Overview</title> + <important> + <title>Migration to <application>ABRT</application> version 2.0</title> + <para> + For Red Hat Enterprise Linux 6.2, the Automatic Bug Reporting Tool has been upgraded to version 2.0. The <application>ABRT</application> 2-series brings major improvements to automatic bug detection and reporting. + </para> + </important> + <para> + <application>ABRT</application> is the <application>Automatic Bug Reporting Tool</application>. <application>ABRT</application> consists of a daemon, <systemitem + class="daemon">abrtd</systemitem>, which runs silently in the background most of the time. It springs into action when an application crashes, or a kernel oops is detected. The daemon then collects the relevant problem data such as a core file if there is one, the crashing application's command line parameters, and other data of forensic utility. + </para> + <para> + <application>ABRT</application> currently supports detection of crashes in applications written in the C/C++ and Python languages, as well as kernel oopses. + </para> + <para> + <application>ABRT</application> is capable of reporting problems to a remote issue tracker. Reporting can be configured to happen automatically whenever an issue is detected, or problem data can be stored locally, reviewed, reported, and deleted manually by a user. The reporting tools can send problem data to a Bugzilla database, a Red Hat Technical Support (RHTSupport) site, upload it using <systemitem + class="protocol">FTP</systemitem>/<systemitem + class="protocol">SCP</systemitem>, email it, or write it to a file. + </para> + <para> + The part of <application>ABRT</application> which handles already-existing problem data (as opposed to, for example, creation of new problem data) has been factored out into a separate project, <application>libreport</application>. The <application>libreport</application> library provides a generic mechanism for analyzing and reporting problems, and it is used by applications other than <application>ABRT</application>. However, <application>ABRT</application> and <application>libreport</application> operation and configuration is closely integrated. They are therefore discussed as one in this document. + </para> + <para> + The <application>ABRT</application> packages provide the following crucial components, among others: + </para> + <itemizedlist> + <listitem> + <para> + <systemitem + class="daemon">abrtd</systemitem> — The <application>ABRT</application> daemon which runs under root as a background service. + </para> + </listitem> + <listitem> + <para> + <application>abrt-applet</application> — The program that receives messages from abrtd and informs you whenever a new problem occurs. + </para> + </listitem> + <listitem> + <para> + <application>abrt-gui</application> — The GUI application that shows collected problem data and allows you to further process it. + </para> + </listitem> + <listitem> + <para> + <application>abrt-cli</application> — The command line interface, which provides similar functionality to the GUI. + </para> + </listitem> + <listitem> + <para> + <systemitem + class="service">abrt-ccpp</systemitem> — The <application>ABRT</application> service that provides the C/C++ problems analyzer + </para> + </listitem> + <listitem> + <para> + <systemitem + class="service">abrt-oops</systemitem> — The <application>ABRT</application> service that provides the kernel oopses analyzer. + </para> + </listitem> + </itemizedlist> + </section> + <section + id="sect-abrt-installation"> + <title>Installing <application>ABRT</application> and Starting its Services</title> + <para> + As the first step in order to use <application>ABRT</application>, you should ensure that the <package>abrt-desktop</package> package is installed on your system by running the following command as the root user: + </para> + <screen>~]# <command>yum install abrt-desktop</command></screen> + <para> + With <package>abrt-desktop</package> installed, you will be able to use <application>ABRT</application> only in its graphical interface. If you intend to use <application>ABRT</application> on the command line, install the <package>abrt-cli</package> package: + </para> + <screen>~]# <command>yum install abrt-cli</command></screen> + <para> + For more information on how to install packages with the <application>Yum</application> package manager, refer to <xref + linkend="sec-Installing"/> + </para> + <para> + Your next step should be to verify that <systemitem + class="daemon">abrtd</systemitem> is running. The daemon is typically configured to start up at boot time. You can use the following command as root to verify its current status: + </para> + <screen>~]# <command>service abrtd status</command> + abrtd (pid 1535) is running...</screen> + <para> + If the <command>service</command> command returns the <computeroutput>abrt is stopped</computeroutput> message, the daemon is not running. It can be started for the current session by entering this command: + </para> + <screen>~]# <command>service abrtd start</command> +Starting abrt daemon: [ OK ]</screen> + <para> + You can run the following <command>chkconfig</command> command to ensure that the <systemitem + class="daemon">abrtd</systemitem> service initializes every time the system starts up: + </para> + <screen>~]# <command>chkconfig abrtd on</command></screen> + <para> + Similarly, you can follow the same steps to check and configure the <systemitem + class="service">abrt-ccpp</systemitem> service if you want <application>ABRT</application> to catch C/C++ crashes. To set <application>ABRT</application> to detect kernel oopses, use the same steps for the <systemitem + class="service">abrt-oops</systemitem> service. Note that this service cannot catch kernel oopses which cause the system to fail to become unresponsive or to reboot immediately. + </para> +  + <para> + Finally, you can verify that the <systemitem + class="service">ABRT notification applet</systemitem> is running: + </para> + <screen>~]$ <command>ps -el | grep abrt-applet</command> +0 S 500 2036 1824 0 80 0 - 61604 poll_s ? 00:00:00 abrt-applet</screen> + <para> + If the <application>ABRT</application> notification applet is not running, you can start it manually in your current desktop session by running the <systemitem + class="service">abrt-applet</systemitem> program: + </para> + <screen>~]$ <command>abrt-applet &</command> +[1] 2261</screen> + <para> + The applet can be configured to start automatically when your graphical desktop session starts. For example, on the GNOME desktop this can be achieved by accessing the <menuchoice><guimenu>System</guimenu> + <guisubmenu>Preferences</guisubmenu> + <guimenuitem>Startup Applications</guimenuitem> + </menuchoice> menu and ensuring that the <application>ABRT</application> notification applet is added to the list of programs and selected to run on at system startup. + </para> + <figure + id="fig-abrt-applet_setting-1"> + <title>Setting the <application>ABRT</application> notification applet to run automatically</title> + <mediaobject> + <imageobject> + <imagedata + fileref="images/abrt-applet_setting.png" + format="PNG" + scalefit="0" /> + </imageobject> + <textobject> + <para> + How to set <application>ABRT</application> notification applet to run automatically + </para> + </textobject> + </mediaobject> + </figure> + <figure + id="fig-abrt-applet_setting-2"> + <title>Setting <application>ABRT</application> notification applet to run automatically.</title> + <mediaobject> + <imageobject> + <imagedata + fileref="images/abrt-applet_setting2.png" + format="PNG" + scalefit="0" /> + </imageobject> + <textobject> + <para> + How to set the <application>ABRT</application> notification applet to run automatically. + </para> + </textobject> + </mediaobject> + </figure> + </section> + <section + id="sect-abrt-running"> + <title>Running <application>ABRT</application> + </title> + <para> + Whenever a problem is detected, <application>ABRT</application> compares it with all existing problem data and determines whether that same problem has been recorded. If it has been, the existing problem data is updated and the most recent (duplicate) problem is not recorded again. If this problem is not recognized by <application>ABRT</application>, a <emphasis + role="bold">problem data directory</emphasis> is created. A problem data directory typically consists of files such as: + </para> + <itemizedlist> + <listitem> + <para> + <filename>analyzer</filename> + </para> + </listitem> + <listitem> + <para> + <filename>architecture</filename> + </para> + </listitem> + <listitem> + <para> + <filename>coredump</filename> + </para> + </listitem> + <listitem> + <para> + <filename>cmdline</filename> + </para> + </listitem> + <listitem> + <para> + <filename>executable</filename> + </para> + </listitem> + <listitem> + <para> + <filename>kernel</filename> + </para> + </listitem> + <listitem> + <para> + <filename>os_release</filename> + </para> + </listitem> + <listitem> + <para> + <filename>reason</filename> + </para> + </listitem> + <listitem> + <para> + <filename>time</filename> + </para> + </listitem> + <listitem> + <para> + <filename>uid</filename> + </para> + </listitem> + </itemizedlist> + <para> + Other files, such as <filename>backtrace</filename>, can be created during analysis depending on which analyzer method is used and its configuration settings. Each of these files holds specific information about the system and the problem itself. For example, the <filename>kernel</filename> file records the version of the crashed kernel. + </para> + <section + id="sect-abrt-gui"> + <title>Using the Graphical User Interface</title> + <para> + The <application>ABRT</application> daemon sends a broadcast D-Bus message whenever a problem report is created. If the <application>ABRT</application> notification applet is running, it catches this message and displays an orange alarm icon in the Notification Area. You can open the <application>ABRT GUI</application> application using this icon. As an alternative, you can display the <application>ABRT</application> GUI by selecting the <menuchoice><guimenu>Application</guimenu> + <guisubmenu>System Tools</guisubmenu> + <guimenuitem>Automatic Bug Reporting Tool</guimenuitem> + </menuchoice> menu item. + </para> + <figure + id="fig-abrt-gui_access"> + <title>Running the <application>ABRT</application> GUI from the <guimenu>Applications</guimenu> menu.</title> + <mediaobject> + <imageobject> + <imagedata + fileref="images/abrt-gui_access.png" + format="PNG" + scalefit="0" /> + </imageobject> + <textobject> + <para> + Running the <application>ABRT</application> GUI from the <guimenu>Applications</guimenu> menu. + </para> + </textobject> + </mediaobject> + </figure> + <para> + Alternatively, you can run the <application>ABRT</application> GUI from the command line as follows: + </para> + <screen>~]$ <command>abrt-gui &</command></screen> + <para> + The <application>ABRT</application> GUI provides an easy and intuitive way of viewing, reporting and deleting of reported problems. The <application>ABRT</application> window displays a list of detected problems. Each problem entry consists of the name of the failing application, the reason why the application crashed, and the date of the last occurrence of the problem. + </para> + <figure + id="fig-abrt-gui_main_screen"> + <title>An example of running <application>ABRT</application> GUI.</title> + <mediaobject> + <imageobject> + <imagedata + fileref="images/abrt-gui_main_screen.png" + format="PNG" + scalefit="0" /> + </imageobject> + <textobject> + <para>ABRT displaying its list of crashed applications</para> + </textobject> + </mediaobject> + </figure> + <para> + If you double-click on a problem report line, you can access the detailed problem description and proceed with the process of determining how the problem should be analyzed, and where it should be reported. + </para> + <figure + id="fig-abrt-gui_problem_description"> + <title>A detailed problem data example.</title> + <mediaobject> + <imageobject> + <imagedata + fileref="images/abrt-gui_problem_description.png" + format="PNG" + scalefit="0" /> + </imageobject> + <textobject> + <para>Viewing detailed problem data</para> + </textobject> + </mediaobject> + </figure> + <para> + You are first asked to provide additional information about the problem which occurred. You should provide detailed information on how the problem happened and what steps should be done in order to reproduce it. In the next steps, choose how the problem will be analyzed and generate a backtrace depending on your configuration. You can skip the analysis and backtrace-generation steps but remember that developers need as much information about the problem as possible. You can always modify the backtrace and remove any sensitive information you do not want to provide before you send the problem data out. + </para> + <figure + id="fig-abrt-gui_select_analyzer"> + <title>Selecting how to analyze the problem.</title> + <mediaobject> + <imageobject> + <imagedata + fileref="images/abrt-gui_select_analyzer.png" + format="PNG" + scalefit="0" /> + </imageobject> + <textobject> + <para>Selecting how to analyze the problem.</para> + </textobject> + </mediaobject> + </figure> + <figure + id="fig-abrt-gui_problem_analyzing"> + <title>ABRT analyzing the problem</title> + <mediaobject> + <imageobject> + <imagedata + fileref="images/abrt-gui_problem_analyzing.png" + format="PNG" + scalefit="0" /> + </imageobject> + <textobject> + <para>ABRT analyzing the problem</para> + </textobject> + </mediaobject> + </figure> + <para>Next, choose how you want to report the issue. If you are using Red Hat Enterprise Linux, then Red Hat Customer Support is the preferred choice. </para> + <figure + id="fig-abrt-gui_select_reporter"> + <title>Selecting a problem reporter.</title> + <mediaobject> + <imageobject> + <imagedata + fileref="images/abrt-gui_select_reporter.png" + format="PNG" + scalefit="0" /> + </imageobject> + <textobject> + <para>Selecting a problem reporter.</para> + </textobject> + </mediaobject> + </figure> + <para> + If you choose to report to Red Hat Customer Support, and you have not configured this event yet, you will be warned that this event is not configured properly and you will be offered an option to do so. + </para> + <figure + id="fig-abrt-gui_rhtsupport_warning"> + <title>Warning - missing Red Hat Customer Support configuration.</title> + <mediaobject> + <imageobject> + <imagedata + fileref="images/abrt-gui_rhtsupport_warning.png" + format="PNG" + scalefit="0" /> + </imageobject> + <textobject> + <para>Warning - missing Red Hat Customer Support configuration.</para> + </textobject> + </mediaobject> + </figure> + <para> + Here, you need to provide your Red Hat login information (Refer to <xref linkend="sect-abrt-configuration-event_configuration_in_gui"/> for more information on how to acquire it and how to set this event.), otherwise you will fail to report the problem. + </para> + <figure + id="fig-abrt-gui_rhtsupport_configuration.png"> + <title>Red Hat Customer Support configuration window.</title> + <mediaobject> + <imageobject> + <imagedata + fileref="images/abrt-gui_rhtsupport_configuration.png" + format="PNG" + scalefit="0" /> + </imageobject> + <textobject> + <para>Red Hat Customer Support configuration window.</para> + </textobject> + </mediaobject> + </figure> + <para>After you have chosen a reporting method and have it set up correctly, review the backtrace and confirm the data to be reported.</para> + <figure + id="fig-abrt-gui_backtrace_review"> + <title>Reviewing the problem backtrace.</title> + <mediaobject> + <imageobject> + <imagedata + fileref="images/abrt-gui_backtrace_review.png" + format="PNG" + scalefit="0" /> + </imageobject> + <textobject> + <para>Reviewing the problem backtrace.</para> + </textobject> + </mediaobject> + </figure> + <figure + id="fig-abrt-gui_report_confirmation"> + <title>Confirming the data to report.</title> + <mediaobject> + <imageobject> + <imagedata + fileref="images/abrt-gui_report_confirmation.png" + format="PNG" + scalefit="0" /> + </imageobject> + <textobject> + <para>Confirming the data to report.</para> + </textobject> + </mediaobject> + </figure> + <para> + Finally, the problem data is sent to the chosen destination, and you can now decide whether to continue with reporting the problem using another available method or finish your work on this problem. If you have reported your problem to the Red Hat Customer Support database, a problem case is filed in the database. From now on, you will be informed about the problem resolution progress via email you provided during the process of reporting. You can also oversee the problem case using the URL that is provided to you by <application>ABRT</application> GUI when the problem case is created, or via emails received from Red Hat Support. + </para> + <figure + id="fig-abrt-gui_rhtsupport_reporting"> + <title>Problem is being reported to the Red Hat Customer Support database.</title> + <mediaobject> + <imageobject> + <imagedata + fileref="images/abrt-gui_rhtsupport_reporting.png" + format="PNG" + scalefit="0" /> + </imageobject> + <textobject> + <para>Problem is being reported to the Red Hat Customer Support database.</para> + </textobject> + </mediaobject> + </figure> + </section> + <section + id="sect-abrt-cli"> + <title>Using the Command Line Interface</title> + <para> + Problem data saved by <systemitem + class="daemon">abrtd</systemitem> can be viewed, reported, and deleted using the command line interface. + </para> + <para> + General usage of the <application>abrt-cli</application> tool can be described using the following syntax: + </para> + <synopsis> + <command>abrt-cli</command> <optional><option>--version</option></optional> <replaceable><command></replaceable> <optional><replaceable><args></replaceable></optional> + </synopsis> + <para>…where <replaceable><args></replaceable> stands for a problem data directory and/or options modifying the commands, and <replaceable><command></replaceable> is one of the following sub-commands: + </para> + <itemizedlist> + <listitem> + <para> + <command>list</command> — lists problems and views the problem data. + </para> + </listitem> + <listitem> + <para> + <command>report</command> — analyzes and reports problems. + </para> + </listitem> + <listitem> + <para> + <command>rm</command> — removes unneeded problems. + </para> + </listitem> + <listitem> + <para> + <command>info</command> — provides information about a particular problem. + </para> + </listitem> + </itemizedlist> + <para>To display help on particular <command>abrt-cli</command> command use:</para> + <synopsis> + <command>abrt-cli <replaceable><command></replaceable> + <option>--help</option> + </command> + </synopsis> + <para>The rest of the commands used with <application>abrt-cli</application> are described in the following sections.</para> + <section + id="sect-abrt-cli_viewing_problems"> + <title>Viewing Problems</title> + <para> + To view detected problems, enter the <command>abrt-cli list</command> command: + </para> + <screen>~]# <command>abrt-cli list</command> +Directory: /var/spool/abrt/ccpp-2011-09-13-10:18:14-2895 +count: 2 +executable: /usr/bin/gdb +package: gdb-7.2-48.el6 +time: Tue 13 Sep 2011 10:18:14 AM CEST +uid: 500 + +Directory: /var/spool/abrt/ccpp-2011-09-21-18:18:07-2841 +count: 1 +executable: /bin/bash +package: bash-4.1.2-8.el6 +time: Wed 21 Sep 2011 06:18:07 PM CEST +uid: 500</screen> +  + <itemizedlist> + <listitem> + <para> + <computeroutput>Directory</computeroutput> — Shows the problem data directory that contains all information about the problem.</para> + </listitem> + <listitem> + <para> + <computeroutput>count</computeroutput> — Shows how many times this particular problem occurred.</para> + </listitem> + <listitem> + <para> + <computeroutput>executable</computeroutput> — Indicates which binary or executable script crashed.</para> + </listitem> + <listitem> + <para> + <computeroutput>package</computeroutput> — Shows the name of the package that contains the program that caused the problem.</para> + </listitem> + <listitem> + <para> + <computeroutput>time</computeroutput> — Shows the date and time of the last occurrence of the problem.</para> + </listitem> + <listitem> + <para> + <computeroutput>uid</computeroutput> — Shows the ID of the user which ran the program that crashed.</para> + </listitem> + </itemizedlist> + <para>The following table shows options available with the <command>abrt-cli list</command> command. All options are mutually inclusive so you can combine them according to your need. The command output will be the most comprehensive if you combine all options, and you will receive the least details if you use no additional options. + </para> + <table + id="tab-abrt-cli_list"> + <title>The <command>abrt-cli list</command> command options</title> + <tgroup + cols="2"> + <colspec + colname="command" + colnum="1" + colwidth="30*"/> + <colspec + colname="argument" + colnum="2" + colwidth="70*"/> + <thead> + <row> + <entry> + Option + </entry> + <entry> + Description + </entry> + </row> + </thead> + <tbody> + <row> + <entry> + + </entry> + <entry> + With no additional option, the <command>abrt-cli list</command> command displays only basic information for problems that have not been reported yet. + </entry> + </row> + <row> + <entry> + <option>-d</option>, <option>--detailed</option> + </entry> + <entry> + Displays all stored information about problems listed, including a <filename>backtrace</filename> if it has already been generated. + </entry> + </row> + <row> + <entry> + <option>-f</option>, <option>--full</option> + </entry> + <entry> + Displays basic information for all problems including the already-reported ones. + </entry> + </row> + <row> + <entry> + <option>-v</option>, <option>--verbose</option> + </entry> + <entry> + Provides additional information on its actions. + </entry> + </row> + </tbody> + </tgroup> + </table> + <para> + If you want to view information just about one particular problem, you can use the command: + </para> + <synopsis> + <command>abrt-cli info</command> <replaceable><DIR></replaceable> + </synopsis> + <para> + …where <replaceable><DIR></replaceable> stands for the <emphasis + role="bold">problem data directory</emphasis> of the problem that is being viewed. The following table shows options available with the <command>abrt-cli info</command> command. All options are mutually inclusive so you can combine them according to your need. The command output will be the most comprehensive if you combine all options, and you will receive the least details if you use no additional options. + </para> + <table + id="tab-abrt-cli_info"> + <title>The <command>abrt-cli info</command> command options</title> + <tgroup + cols="2"> + <colspec + colname="command" + colnum="1" + colwidth="30*"/> + <colspec + colname="argument" + colnum="2" + colwidth="70*"/> + <thead> + <row> + <entry> + Option + </entry> + <entry> + Description + </entry> + </row> + </thead> + <tbody> + <row> + <entry> + + </entry> + <entry> + With no additional option, the <command>abrt-cli info</command> command displays only basic information for the problem specified by the <systemitem>problem data directory</systemitem> argument. + </entry> + </row> + <row> + <entry> + <option>-d</option>, <option>--detailed</option> + </entry> + <entry> + Displays all stored information for the problem specified by the <systemitem>problem data directory</systemitem> argument, including a <filename>backtrace</filename> if it has already been generated. + </entry> + </row> + <row> + <entry> + <option>-v</option>, <option>--verbose</option> + </entry> + <entry> + <command>abrt-cli info</command> provides additional information on its actions. + </entry> + </row> + </tbody> + </tgroup> + </table> + </section> + <section + id="sect-abrt-cli_reporting_problems"> + <title>Reporting Problems</title> + <para> + To report a certain problem, use the command:</para> + <synopsis> + <command>abrt-cli report <replaceable><DIR></replaceable></command> + </synopsis> + <para>...where <replaceable><DIR></replaceable> stands for the <emphasis + role="bold">problem data directory</emphasis> of the problem that is being reported. For example: + </para> + <screen>~]$ <command>abrt-cli report</command> <filename>/var/spool/abrt/ccpp-2011-09-13-10:18:14-2895</filename> +How you would like to analyze the problem? +1) Collect .xsession-errors +2) Local GNU Debugger +Select analyzer: _</screen> + <para> + <application>ABRT</application> prompts you to select an analyzer event for the problem that is being reported. After selecting an event, the problem is analyzed. This can take a considerable amount of time. When the problem report is ready, <command>abrt-cli</command> opens a text editor with the content of the report. You can see what is being reported, and you can fill in instructions on how to reproduce the crash and other comments. You should also check the backtrace, because the backtrace might be sent to a public server and viewed by anyone, depending on the problem reporter event settings. + </para> + <note> + <title>Selecting a preferred text editor</title> + <para> + You can choose which text editor is used to check the reports. <command>abrt-cli</command> uses the editor defined in the <envar>ABRT_EDITOR</envar> environment variable. If the variable is not defined, it checks the <envar>VISUAL</envar> and <envar>EDITOR</envar> variables. If none of these variables is set, <command>vi</command> is used. You can set the preferred editor in your <filename>.bashrc</filename> configuration file. For example, if you prefer GNU Emacs, add the following line to the file: + </para> + <screen>export <varname>VISUAL</varname>=<userinput>emacs</userinput></screen> + </note> + <para> + When you are done with the report, save your changes and close the editor. You will be asked which of the configured <application>ABRT</application> reporter events you want to use to send the report. + </para> + <screen>How would you like to report the problem? +1) Logger +2) Red Hat Customer Support +Select reporter(s): _</screen> + <para> + After selecting a reporting method, you can proceed with reviewing data to be sent with the report. The + following table shows options available with the <command>abrt-cli report</command> command. + </para> + <table + id="tab-abrt-cli_report"> + <title>The <command>abrt-cli report</command> command options</title> + <tgroup + cols="2"> + <colspec + colname="command" + colnum="1" + colwidth="30*"/> + <colspec + colname="argument" + colnum="2" + colwidth="70*"/> + <thead> + <row> + <entry> + Option + </entry> + <entry> + Description + </entry> + </row> + </thead> + <tbody> + <row> + <entry> + + </entry> + <entry> + With no additional option, the <command>abrt-cli report</command> provides the usual output. + </entry> + </row> + <row> + <entry> + <option>-v</option>, <option>--verbose</option> + </entry> + <entry> + <command>abrt-cli report</command> provides additional information on its actions. + </entry> + </row> + </tbody> + </tgroup> + </table> + </section> + <section + id="sect-abrt-cli_deleting_problems"> + <title> + Deleting Problems + </title> + <para> + If you are certain that you do not want to report a particular problem, you can delete it. To delete a problem so <application>ABRT</application> does not keep information about it, use the command: + </para> + <synopsis> + <command>abrt-cli rm <replaceable><DIR></replaceable></command> + </synopsis> + <para> + ...where <replaceable><DIR></replaceable> stands for the problem data directory of the problem being deleted. For example: + </para> + <screen>~]$ <command>abrt-cli rm</command> <filename>/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413</filename> +rm '/var/spool/abrt/ccpp-2011-09-12-18:37:24-4413'</screen> + <note> + <title>Deletion of a problem can lead to frequent ABRT notification</title> + <para> + Note that <application>ABRT</application> performs a detection of duplicate problems by comparing new problems with all locally saved problems. For a repeating crash, <application>ABRT</application> requires you to act upon it only once. However, if you delete the crash dump of that problem, the next time this specific problem occurs, <application>ABRT</application> will treat it as a new crash: <application>ABRT</application> will alert you about it, prompt you to fill in a description, and report it. To avoid having <application>ABRT</application> notifying you about a recurring problem, do not delete its problem data. + </para> + </note> + <para> + The following table shows options available with the <command>abrt-cli rm</command> command. + </para> + <table + id="tab-abrt-cli_rm"> + <title>The <command>abrt-cli rm</command> command options</title> + <tgroup + cols="2"> + <colspec + colname="command" + colnum="1" + colwidth="30*"/> + <colspec + colname="argument" + colnum="2" + colwidth="70*"/> + <thead> + <row> + <entry> + Option + </entry> + <entry> + Description + </entry> + </row> + </thead> + <tbody> + <row> + <entry> + + </entry> + <entry> + With no additional option, the <command>abrt-cli rm</command> . + </entry> + </row> + <row> + <entry> + <option>-v</option>, <option>--verbose</option> + </entry> + <entry> + <command>abrt-cli rm</command> provides additional information on its actions. + </entry> + </row> + </tbody> + </tgroup> + </table> + </section> + </section> + </section> + <section + id="sect-abrt-configuration"> + <title>Configuring ABRT</title> + <para> + A <emphasis>problem</emphasis> life cycle is driven by <emphasis>events</emphasis> in <application>ABRT</application>. For example: + </para> + <itemizedlist> + <listitem> + <para> + Event 1 — a problem data directory is created. + </para> + </listitem> + <listitem> + <para> + Event 2 — problem data is analyzed. + </para> + </listitem> + <listitem> + <para> + Event 3 — a problem is reported to Bugzilla. + </para> + </listitem> + </itemizedlist> + <para> + When a problem is detected and its defining data is stored, the problem is processed by running events on the + problem's data directory. For more information on events and how to define one, refer to <xref + linkend="sect-abrt-configuration-events"/>. Standard <application>ABRT</application> installation currently + supports several default events that can be selected and used during problem reporting process. Refer to <xref + linkend="sect-abrt-configuration-events-default_events"/> to see the list of these events. + </para> + <para> + Upon installation, <application>ABRT</application> and <application>libreport</application> place their respective configuration files into the several directories on a system: + </para> + <itemizedlist> + <listitem> + <para> + <filename>/etc/libreport/</filename> — contains the <filename>report_event.conf</filename> main configuration file. More information about this configuration file can be found in <xref + linkend="sect-abrt-configuration-events"/>. + </para> + </listitem> + <listitem> + <para> + <filename>/etc/libreport/events/</filename> — holds files specifying the default setting of predefined events. + </para> + </listitem> + <listitem> + <para> + <filename>/etc/libreport/events.d/</filename> — keeps configuration files defining events. + </para> + </listitem> + <listitem> + <para> + <filename>/etc/libreport/plugins/</filename> — contains configuration files of programs that take part in events. + </para> + </listitem> + <listitem> + <para> + <filename>/etc/abrt/</filename> — holds <application>ABRT</application> specific configuration files used to modify the behavior of <application>ABRT</application>'s services and programs. More information about certain specific configuration files can be found in <xref + linkend="sect-abrt-configuration-abrt"/>. + </para> + </listitem> + <listitem> + <para> + <filename>/etc/abrt/plugins/</filename> — keeps configuration files used to override the default setting of <application>ABRT</application>'s services and programs. For more information on some specific configuration files refer to <xref + linkend="sect-abrt-configuration-abrt"/>. + </para> + </listitem> + </itemizedlist> + <section + id="sect-abrt-configuration-events"> + <title>ABRT Events</title> + <para> + Each event is defined by one rule structure in a respective configuration file. The configuration files are typically stored in the <filename>/etc/libreport/events.d/</filename> directory. These configuration files are used by the main configuration file, <filename>/etc/libreport/report_event.conf</filename>. + </para> + <para> + The <filename>/etc/libreport/report_event.conf</filename> file consists of <emphasis>include + directives</emphasis> and <emphasis>rules</emphasis>. Rules are typically stored in other configuration files in + the <filename>/etc/libreport/events.d/</filename> directory. In the standard installation, the + <filename>/etc/libreport/report_event.conf</filename> file contains only one include directive: + </para> + <screen><code>include events.d/*.conf</code></screen> + <para> + If you would like to modify this file, please note that it respects shell metacharacters (*,$,?, etc.) and interprets relative paths relatively to its location. + </para> + <para> + Each <emphasis>rule</emphasis> starts with a line with a non-space leading character, all subsequent lines starting with the <systemitem>space</systemitem> character or the <systemitem>tab</systemitem> character are considered a part of this rule. Each <emphasis>rule</emphasis> consists of two parts, a <emphasis>condition</emphasis> part and a <emphasis>program</emphasis> part. The condition part contains conditions in one of the following forms: + </para> +<itemizedlist> + <listitem> + <para><replaceable>VAR</replaceable>=<replaceable>VAL</replaceable>,</para> + </listitem> + <listitem> + <para> + <replaceable>VAR</replaceable>!=<replaceable>VAL</replaceable>, or + </para> + </listitem> + <listitem> + <para> + <replaceable>VAL</replaceable>~=<replaceable>REGEX</replaceable> + </para> + </listitem> +</itemizedlist> + <para> + …where: + </para> + <itemizedlist> + <listitem> + <para><replaceable>VAR</replaceable> is either the <constant>EVENT</constant> key word or a name of a problem data + directory element (such as <filename>executable</filename>, <filename>package</filename>, + <filename>hostname</filename>, etc.),</para> + </listitem> + <listitem> + <para> + <replaceable>VAL</replaceable> is either a name of an event or a problem data element, and + </para> + </listitem> + <listitem> + <para> + <replaceable>REGEX</replaceable> is a regular expression. + </para> + </listitem> + </itemizedlist> + <para>The program part consists of program names and shell interpretable code. If all conditions in the condition part + are valid, the program part is run in the shell. The following is an <emphasis>event</emphasis> example: + </para> + <programlisting language="Bash">EVENT=post-create date > /tmp/dt + echo $HOSTNAME `uname -r`</programlisting> + <para> + This event would overwrite the contents of the <filename>/tmp/dt</filename> file with the current date and time, + and print the hostname of the machine and its kernel version on the standard output. + </para> + <para> + Here is an example of a yet more complex event which is actually one of the predefined events. It saves relevant + lines from the <filename>~/.xsession-errors</filename> file to the problem report for any problem for which the + <systemitem>abrt-ccpp</systemitem> services has been used to process that problem, and the crashed application + has loaded any X11 libraries at the time of crash: + </para> + <programlisting language="Bash">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"</programlisting> + <para> + The set of possible events is not hard-set. System administrators can add events according to their need. Currently, the following event names are provided with standard <application>ABRT</application> and <application>libreport</application> installation: + </para> + <variablelist> + <varlistentry> + <term> + <systemitem class="event">post-create</systemitem> + </term> + <listitem> + <para> + This event is run by <systemitem + class="daemon">abrtd</systemitem> on newly created problem data directories. When the <systemitem class="event">post-create</systemitem> event is run, <systemitem + class="daemon">abrtd</systemitem> checks whether the UUID identifier of the new problem data matches the UUID of any already existing problem directories. If such a problem directory exists, the new problem data is deleted. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + <systemitem class="event">analyze_<replaceable><NAME_SUFFIX></replaceable></systemitem> + </term> + <listitem> + <para> + …where <replaceable><NAME_SUFFIX></replaceable> is the adjustable part of the event name. This event is used to process collected data. For example, the <systemitem + class="event">analyze_LocalGDB</systemitem> runs the GNU Debugger (<application>GDB</application>) utility on a core dump of an application and produces a backtrace of a program. You can view the list of analyze events and choose from it using <application>abrt-gui</application>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + <systemitem class="event">collect_<replaceable><NAME_SUFFIX></replaceable></systemitem> + </term> + <listitem> + <para> + …where <replaceable><NAME_SUFFIX></replaceable> is the adjustable part of the event name. This event is used to collect additional information on a problem. You can view the list of collect events and choose from it using <application>abrt-gui</application>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + <systemitem class="event">report_<replaceable><NAME_SUFFIX></replaceable></systemitem> + </term> + <listitem> + <para> + …where <replaceable><NAME_SUFFIX></replaceable> is the adjustable part of the event name. This event is used to report a problem. You can view the list of report events and choose from it using <application>abrt-gui</application>. + </para> + </listitem> + </varlistentry> + </variablelist> + <para> + Additional information about events (such as their description, names and types of parameters which can be passed to them as environment variables, and other properties) is stored in the <filename>/etc/libreport/events/<replaceable><event_name></replaceable>.xml</filename> files. These files are used by <application>abrt-gui</application> and <application>abrt-cli</application> to make the user interface more friendly. Do not edit these files unless you want to modify the standard installation. + </para> + </section> + <section + id="sect-abrt-configuration-events-default_events"> + <title>Standard ABRT Installation Supported Events</title> + <para> + Standard <application>ABRT</application> installation currently provides a number of default analyzing, + collecting and reporting events. Some of these events are also configurable using the + <application>ABRT</application> GUI application (for more information on event configuration using + <application>ABRT</application> GUI, refer to <xref + linkend="sect-abrt-configuration-event_configuration_in_gui"/>). <application>ABRT</application> GUI only shows + the event's unique part of the name which is more readable the user, instead of the complete event name. For + example, the <systemitem class="event">analyze_xsession_errors</systemitem> event is shown as + <systemitem>Collect .xsession-errors</systemitem> in <application>ABRT</application> GUI. The following is + a list of default analyzing, collecting and reporting events provided by the standard installation of + <application>ABRT</application>: + </para> + <variablelist> + <varlistentry> + <term> + analyze_LocalGDB — Local GNU Debugger + </term> + <listitem> + <para> + Runs <application>GDB</application> (the GNU debugger) on problem data of an application and generates a <filename>backtrace</filename> of a program. It is defined in the <filename>/etc/libreport/events.d/ccpp_event.conf</filename> configuration file. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + analyze_xsession_errors — Collect .xsession-errors + </term> + <listitem> + <para> + Saves relevant lines from the <filename>~/.xsession-errors</filename> file to the problem report. It is defined in the <filename>/etc/libreport/events.d/ccpp_event.conf</filename> configuration file. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + report_Logger — Logger + </term> + <listitem> + <para> + Creates a problem report and saves it to a specified local file. It is defined in the <filename>/etc/libreport/events.d/print_event.conf</filename> configuration file. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + report_RHTSupport — Red Hat Customer Support + </term> + <listitem> + <para> + Reports problems to the Red Hat Technical Support system. This possibility is intended for users of Red Hat Enterprise Linux. It is defined in the <filename>/etc/libreport/events.d/rhtsupport_event.conf</filename> configuration file. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + report_Mailx — Mailx + </term> + <listitem> + <para> + Sends a problem report via the <application>Mailx</application> utility to a specified email address. It is defined in the <filename>/etc/libreport/events.d/mailx_event.conf</filename> configuration file. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + report_Kerneloops — Kerneloops.org + </term> + <listitem> + <para> + Sends a kernel problem to the oops tracker. It is defined in the <filename>/etc/libreport/events.d/koops_event.conf</filename> configuration file. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + report_Uploader — Report uploader + </term> + <listitem> + <para> + Uploads a tarball (.tar.gz) archive with problem data to the chosen destination using the <systemitem + class="protocol">FTP</systemitem> or the <systemitem + class="protocol">SCP</systemitem> protocol. It is defined in the <filename>/etc/libreport/events.d/uploader_event.conf</filename> configuration file. + </para> + </listitem> + </varlistentry> + </variablelist> + </section> + <section + id="sect-abrt-configuration-event_configuration_in_gui"> + <title>Event Configuration in ABRT GUI</title> + <para> + Events can use parameters passed to them as environment variables (for example, the <systemitem class="event">report_Logger</systemitem> event accepts an output file name as a parameter). Using the respective <filename>/etc/libreport/events/<replaceable><event_name></replaceable>.xml</filename> file, <application>ABRT</application> GUI determines which parameters can be specified for a selected event and allows a user to set the values for these parameters. These values are saved by <application>ABRT</application> GUI and reused on subsequent invocations of these events. + </para> + <para> + Open the <guilabel>Event Configuration</guilabel> window by clicking <menuchoice><guimenu>Edit</guimenu><guisubmenu>Preferences</guisubmenu></menuchoice>. This window shows a list of all available events that can be selected during the reporting process. When you select one of the configurable events, you can click the <guibutton>Configure Event</guibutton> button and you will be able to configure settings for that event. If you change any of the events' parameters, they are saved in the <application>Gnome</application> keyring and will be used in the future GUI sessions. + </para> + <note> + <title>Do not store sensitive data in global configuration files</title> + <para> + All files in the <filename>/etc/libreport/</filename> directory hierarchy are world readable and are meant to be used as global settings. Thus, it is not advisable to store usernames, passwords or any other sensitive data in them. The per-user settings (set in the GUI application and readable by the owner of <varname>$HOME</varname> only) are stored in the <application>Gnome</application> keyring or can be stored in a text file in <filename>$HOME/.abrt/*.conf</filename> for use in <command>abrt-cli</command>. + </para> + </note> + <figure + id="fig-abrt-gui_event_configuration"> + <title>The Event Configuration Window.</title> + <mediaobject> + <imageobject> + <imagedata + fileref="images/abrt-gui_event_configuration.png" + format="PNG" + scalefit="0" /> + </imageobject> + <textobject> + <para> + The Event Configuration Window. + </para> + </textobject> + </mediaobject> + </figure> + <para> + The following is a list of all configuration options available for each predefined event that is configurable in the <application>ABRT</application> GUI application. + </para> + <variablelist> + <varlistentry> + <term> + Logger + </term> + <listitem> + <para> + In the <guilabel>Logger</guilabel> event configuration window, you can configure the following parameter: + </para> + <itemizedlist> + <listitem> + <para> + <guilabel>Log file</guilabel> — Specifies a file into which the crash reports are saved (by default, set to <filename>/var/log/abrt.log</filename>). + </para> + </listitem> + </itemizedlist> + <para> + When the <guilabel>Append</guilabel> option is checked, the Logger event will append new crash reports to the log file specified in the <guilabel>Logger file</guilabel> option. When unchecked, the new crash report always replaces the previous one. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Red Hat Customer Support</term> + <listitem> + <para> + In the <guilabel>Red Hat Customer Support</guilabel> event configuration window, you can configure the following parameters: + </para> + <itemizedlist> + <listitem> + <para> + <guilabel>RH Portal URL</guilabel> — Specifies the Red Hat Customer Support URL where crash dumps are sent (by default, set to <ulink + url="https://api.access.redhat.com/rs"/>). + </para> + </listitem> + <listitem> + <para> + <guilabel>Username</guilabel> — User login which is used to log into Red Hat Customer Support and create a Red Hat Customer Support database entry for a reported crash. Use your <emphasis>Red Hat Login</emphasis> acquired by creating an account on <ulink + url="http://www.redhat.com/">http://www.redhat.com/</ulink>, the Red Hat Customer Portal (<ulink + url="https://access.redhat.com/home">https://access.redhat.com/home</ulink>) or the Red Hat Network (<ulink + url="https://rhn.redhat.com/">https://rhn.redhat.com/</ulink>). + </para> + </listitem> + <listitem> + <para> + <guilabel>Password</guilabel> — Password used to log into Red Hat Customer Support (that is, password associated with your <emphasis>Red Hat Login</emphasis>) + </para> + </listitem> + </itemizedlist> + <para> + When the <guilabel>SSL verify</guilabel> option is checked, the <systemitem + class="protocol">SSL</systemitem> protocol is used when sending the data over the network. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>MailX</term> + <listitem> + <para> + In the <guilabel>MailX</guilabel> event configuration window, you can configure the following parameters: + </para> + <itemizedlist> + <listitem> + <para> + <guilabel>Subject</guilabel> — A string that appears in the <literal>Subject</literal> field of a problem report email sent by <application>Mailx</application> (by default, set to <literal>"[abrt] detected a crash"</literal>). + </para> + </listitem> + <listitem> + <para> + <guilabel>Sender</guilabel> — A string that appears in the <literal>From</literal> field of a problem report email. + </para> + </listitem> + <listitem> + <para> + <guilabel>Recipient</guilabel> — Email address of the recipient of a problem report email. + </para> + </listitem> + </itemizedlist> + <para> + When the <guilabel>Send Binary Data</guilabel> option is checked, the problem report email will also contain all binary files associated with the problem in an attachment. The core dump file is also sent as an attachment. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Kerneloops.org</term> + <listitem> + <para> + In the <guilabel>Kerneloops.org</guilabel> event configuration window, you can configure the following parameter: + </para> + <itemizedlist> + <listitem> + <para> + <guilabel>Kerneloops URL</guilabel> — Specifies the URL where Kernel problems are reported to (by default, set to <ulink + url="http://submit.kerneloops.org/submitoops.php"/>) + </para> + </listitem> + </itemizedlist> + </listitem> + </varlistentry> + <varlistentry> + <term>Report Uploader</term> + <listitem> + <para> + In the <guilabel>Report Uploader</guilabel> event configuration widow, you can configure the following parameter: + </para> + <itemizedlist> + <listitem> + <para> + <guilabel>URL</guilabel> — Specifies the URL where a tarball containing compressed problem data is uploaded using the <systemitem + class="protocol">FTP</systemitem> or <systemitem + class="protocol">SCP</systemitem> protocol (by default, set to <literal>ftp://localhost:/tmp/upload</literal>). + </para> + </listitem> + </itemizedlist> + </listitem> + </varlistentry> + </variablelist> + </section> + <section + id="sect-abrt-configuration-abrt"> + <title>ABRT Specific Configuration</title> + <para> + Standard <application>ABRT</application> installation currently provides the following <application>ABRT</application> specific configuration files: + </para> + <itemizedlist> + <listitem> + <para> + <filename>/etc/abrt/abrt.conf</filename> — allows you to modify the behavior of the <systemitem + class="daemon">abrtd</systemitem> service. + </para> + </listitem> + <listitem> + <para> + <filename>/etc/abrt/abrt-action-save-package-data.conf</filename> — allows you to modify the behavior of the <application>abrt-action-save-package-data</application> program. + </para> + </listitem> + <listitem> + <para> + <filename>/etc/abrt/plugins/CCpp.conf</filename>, — allows you to modify the behavior of <application>ABRT</application>'s core catching hook. + </para> + </listitem> + </itemizedlist> + <para> + The following configuration directives are supported in the <filename>/etc/abrt/abrt.conf</filename> file: + </para> + <variablelist> + <varlistentry> + <term> + WatchCrashdumpArchiveDir = /var/spool/abrt-upload + </term> + <listitem> + <para> + This directive is commented out by default. Enable it if you want <systemitem + class="daemon">abrtd</systemitem> to auto-unpack crashdump tarball archives (.tar.gz) which are located in + the specified directory. In the example above, it is the <filename>/var/spool/abrt-upload/</filename> + directory. Whichever directory you specify in this directive, you must ensure that it exists and it is + writable for <systemitem class="daemon">abrtd</systemitem>. The <application>ABRT</application> daemon + will not create it automatically. + </para> + <warning> + <title>Do not modify this option in SELinux</title> + <para> + If you are using SELinux, do not modify the default setting of this option unless you reflect the change in SELinux rules. Changing the location for crashdump archives without previous modification of respective rules will cause SELinux denials. See the <systemitem>abrt_selinux(8)</systemitem> manual page for more information on running <application>ABRT</application> in SELinux. + </para> + <para> + Remember that if you enable this option when using SELinux, you need to execute the following command in order to set the appropriate boolean allowing <application>ABRT</application> to write into the public_content_rw_t domain: + </para> + <synopsis> + <command>setsebool -P abrt_anon_write 1</command> + </synopsis> + </warning> + </listitem> + </varlistentry> + <varlistentry> + <term> + MaxCrashReportsSize = <replaceable><size_in_megabytes></replaceable> + </term> + <listitem> + <para> + This option sets the amount of storage space, in megabytes, used by <application>ABRT</application> to store all problem information from all users. The default setting is <constant>1000</constant> MB. Once the quota specified here has been met, <application>ABRT</application> will continue catching problems, and in order to make room for the new crash dumps, it will delete the oldest and largest ones. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + DumpLocation = /var/spool/abrt + </term> + <listitem> + <para> + This directive is commented out by default. It specifies the location where problem data directories are created and in which problem core dumps and all other problem data are stored. The default location is set to the <filename>/var/spool/abrt</filename> directory. Whichever directory you specify in this directive, you must ensure that it exists and it is writable for <systemitem class="daemon">abrtd</systemitem>. + </para> + <warning> + <title>Do not modify this option in SELinux</title> + <para> + Do not modify the default setting of this option if you are using SELinux. Changing the dump location will cause SELinux denials unless you reflect the change in respective SELinux rules first. See the <systemitem>abrt_selinux(8)</systemitem> manual page for more information on running <application>ABRT</application> in SELinux. + </para> + <para> + Remember that if you enable this option when using SELinux, you need to execute the following command in order to set the appropriate boolean allowing <application>ABRT</application> to write into the public_content_rw_t domain: + </para> + <synopsis> + <command>setsebool -P abrt_anon_write 1</command> + </synopsis> + </warning> + </listitem> + </varlistentry> + </variablelist> + <para> + The following configuration directives are supported in the <filename>/etc/abrt/abrt-action-save-package-data.conf</filename> file: + </para> + <variablelist> + <varlistentry> + <term> + OpenGPGCheck = <replaceable><yes/no></replaceable> + </term> + <listitem> + <para> + Setting the <computeroutput>OpenGPGCheck</computeroutput> directive to <userinput>yes</userinput> (the default setting) tells <application>ABRT</application> to <emphasis>only</emphasis> analyze and handle crashes in applications provided by packages which are signed by the GPG keys whose locations are listed in the <filename>/etc/abrt/gpg_keys</filename> file. Setting <parameter>OpenGPGCheck</parameter> to <userinput>no</userinput> tells <application>ABRT</application> to catch crashes in all programs. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + BlackList = nspluginwrapper, valgrind, strace, <optional><replaceable><MORE_PACKAGES></replaceable> + </optional> + </term> + <listitem> + <para> + Crashes in packages and binaries listed after the <parameter>BlackList</parameter> directive will not be handled by <application>ABRT</application>. If you want <application>ABRT</application> to ignore other packages and binaries, list them here separated by commas. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + ProcessUnpackaged = <replaceable><yes/no></replaceable> + </term> + <listitem> + <para> + This directive tells <application>ABRT</application> whether to process crashes in executables that do not belong to any package. The default setting is <emphasis>no</emphasis>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + BlackListedPaths = <filename>/usr/share/doc/*</filename>, <filename>*/example*</filename> + </term> + <listitem> + <para> + Crashes in executables in these paths will be ignored by <application>ABRT</application>. + </para> + </listitem> + </varlistentry> + </variablelist> + <para> + The following configuration directives are supported in the <filename>/etc/abrt/plugins/CCpp.conf</filename> file: + </para> + <variablelist> + <varlistentry> + <term> + MakeCompatCore = <replaceable><yes/no></replaceable> + </term> + <listitem> + <para> + This directive specifies whether <application>ABRT</application>'s core catching hook should create a core file, as it could be done if <application>ABRT</application> would not be installed. The core file is typically created in the current directory of the crashed program but only if the <command>ulimit -c</command> setting allows it. The directive is set to <emphasis>yes</emphasis> by default. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + SaveBinaryImage = <replaceable><yes/no></replaceable> + </term> + <listitem> + <para> + This directive specifies whether <application>ABRT</application>'s core catching hook should save a binary image to a core dump. It is useful when debugging crashes which occurred in binaries that were deleted. The default setting is <emphasis>no</emphasis>. + </para> + </listitem> + </varlistentry> + </variablelist> + </section> + <section + id="sect-abrt-configuration-automatic_reporting"> + <title>Configuring Automatic Reporting</title> + <para> + ABRT can be configured to report any detected issues or crashes automatically without any user interaction. This can be achieved by specifying an analyze-and-report rule as a <emphasis>post-create</emphasis> rule. For example, you can instruct ABRT to report Python crashes to Bugzilla immediately without any user interaction by enabling the rule and replacing the <command>EVENT=report_Bugzilla</command> condition with the <command>EVENT=port-create</command> condition in the <filename>/etc/libreport/events.d/python_event.conf</filename> file: + </para> + <programlisting language="Bash">EVENT=post-create analyzer=Python + test -f component || abrt-action-save-package-data + reporter-bugzilla -c /etc/abrt/plugins/Bugzilla.conf</programlisting> + <warning> + <title><systemitem class="event">post-create</systemitem> runs with root privileges</title> + <para> + Please note that the <systemitem class="event">post-create</systemitem> event is run by <systemitem + class="daemon">abrtd</systemitem>, which usually runs with root privileges. + </para> + </warning> + </section> + <section + id="sect-abrt-configuration-proxy_servers"> + <title>Uploading and reporting using a proxy server</title> + <para> + The <application>reporter-bugzilla</application> and the <application>reporter-upload</application> tools respect the <envar>http_proxy</envar> and the <envar>ftp_proxy</envar> environment variables. When you use environment variables as a part of a reporting event, they inherit their values from the process which performs reporting, usually <application>abrt-gui</application> or <application>abrt-cli</application>. Therefore, you can specify <systemitem class="protocol">HTTP</systemitem> or <systemitem class="protocol">FTP</systemitem> proxy servers by using these variables in your working environment. + </para> + <para> + If you arrange these tools to be a part of the <systemitem + class="event">post-create</systemitem> event, they will run as children of the <systemitem + class="daemon">abrtd</systemitem> process. You should either adjust the environment of abrtd or modify the rules to set these variables. For example: + </para> + <programlisting language="Bash">EVENT=post-create analyzer=Python + test -f component || abrt-action-save-package-data + export http_proxy=http://proxy.server:8888/ + reporter-bugzilla -c /etc/abrt/plugins/Bugzilla.conf</programlisting> + </section> + </section> + <section + id="sect-abrt-centralized_crash_collection"> + <title>Configuring Centralized Crash Collection</title> + <para> + You can set up <application>ABRT</application> so that crash reports are collected from multiple systems and sent to a dedicated system for further processing. This is useful when an administrator does not want to log into hundreds of systems and manually check for crashes found by <application>ABRT</application>. In order to use this method, you need to install the <application>libreport-plugin-reportuploader</application> plug-in (<command>yum install libreport-plugin-reportuploader</command>). See the following sections on how to configure systems to use ABRT's centralized crash collection. + </para> + <section + id="sect-abrt-centralized_crash_collection-server"> + <title>Configuration Steps Required on a Dedicated System</title> + <para> + Complete the following steps on a dedicated (server) system: + </para> + <orderedlist> + <listitem> + <para> + Create a directory to which you want the crash reports to be uploaded to. Usually, <filename>/var/spool/abrt-upload/</filename> is used (the rest of the document assumes you are using this directory). Make sure this directory is writable by the abrt user. + </para> + <note> + <title>The abrt user and group</title> + <para> + When the <package>abrt-desktop</package> package is installed, it creates a new system user and a group, both named <systemitem + class="username">abrt</systemitem>. This user is used by the <systemitem + class="daemon">abrtd</systemitem> daemon, for example, as the owner:group of <filename>/var/spool/abrt/*</filename> directories. + </para> + </note> + </listitem> + <listitem> + <para> + In the <filename>/etc/abrt/abrt.conf</filename> configuration file, set the <varname>WatchCrashdumpArchiveDir</varname> directive to the following: + </para> + <screen>WatchCrashdumpArchiveDir = /var/spool/abrt-upload/</screen> + </listitem> + <listitem> + <para> + Choose your preferred upload mechanism; for example, <systemitem + class="protocol">FTP</systemitem> or <systemitem + class="protocol">SCP</systemitem>. For more information on how to configure <systemitem + class="protocol">FTP</systemitem>, refer to <xref + linkend="s1-FTP"/>. For more information on how to configure <systemitem + class="protocol">SCP</systemitem>, refer to <xref + linkend="s2-ssh-clients-scp"/>. + </para> + <para> + It is advisable to check whether your upload method works. For example, if you use <systemitem + class="protocol">FTP</systemitem>, upload a file using an interactive <systemitem + class="protocol">FTP</systemitem> client: + </para> + <screen>~]$ <command>ftp</command> +ftp> <command>open SERVERNAME</command> +Name: <userinput>USERNAME</userinput> +Password: <userinput>PASSWORD</userinput> +ftp> <command>cd /var/spool/abrt-upload</command> +250 Operation successful +ftp> <command>put TESTFILE</command> +ftp> <command>quit</command></screen> + <para> + Check whether <filename>TESTFILE</filename> appeared in the correct directory on the server system. + </para> + </listitem> + <listitem> + <para> + The <varname>MaxCrashReportsSize</varname> directive (in the <filename>/etc/abrt/abrt.conf</filename> configuration file) needs to be set to a larger value if the expected volume of crash data is larger than the default <constant>1000</constant> MB. + </para> + </listitem> + <listitem> + <para> + Consider whether you would like to generate a backtrace of C/C++ crashes. + </para> + <para> + You can disable backtrace generation on the server if you do not wish to generate backtraces at all, or if you decide to create them locally on the machine where a problem occurred. In the standard ABRT installation, a backtrace of a C/C++ crash is generated using the following rule in the <filename>/etc/libreport/events.d/ccpp_events.conf</filename> configuration file: + </para> + <programlisting language="Bash">EVENT=analyze_LocalGDB analyzer=CCpp + abrt-action-analyze-core.py --core=coredump -o build_ids && + abrt-action-install-debuginfo-to-abrt-cache --size_mb=4096 && + abrt-action-generate-backtrace && + abrt-action-analyze-backtrace</programlisting> + <para> + You can ensure that this rule is not applied for uploaded problem data by adding the <computeroutput>remote!=1</computeroutput> condition to the rule. + </para> + </listitem> + <listitem> + <para> + Decide whether you want to collect package information (the <option>package</option> and the <option>component</option> elements) in the problem data. Refer to <xref + linkend="sect-abrt-centralized_crash_collection-saving_package_information"/> to find out whether you need to collect package information in your centralized crash collection configuration and how to configure it properly. + </para> + </listitem> + </orderedlist> + </section> + <section + id="sect-abrt-centralized_crash_collection-client"> + <title>Configuration Steps Required on a Client System</title> + <para> + Complete the following steps on every client system which will use the central management method: + </para> + <orderedlist> + <listitem> + <para> + If you do not wish to generate a backtrace, or if you decided to generate it on a server system, you need to delete or comment out the corresponding rules in the <filename>/etc/libreport/events.d/ccpp_events.conf</filename> file. Refer to <xref + linkend="sect-abrt-centralized_crash_collection-server"/> for an example of such a example. + </para> + </listitem> + <listitem> + <para> + If you decided to not collect package information on client machines, delete, comment out or modify the rule which runs abrt-action-save-package-data in the <filename>/etc/libreport/events.d/abrt_event.conf</filename> file. Refer to <xref + linkend="sect-abrt-centralized_crash_collection-saving_package_information"/> to find out whether you need to collect package information in your centralized crash collection configuration and how to configure it properly. + </para> + </listitem> + <listitem> + <para> + Add a rule for uploading problem reports to the server system in the corresponding configuration file. For example, if you want to upload all problems automatically as soon as they are detected, you can use the following rule in the <filename>/etc/libreport/events.d/abrt_event.conf</filename> configuration file: + </para> + <programlisting lang="Bash">EVENT=post-create + reporter-upload -u scp://<replaceable>user</replaceable>:<replaceable>password</replaceable>@<replaceable>server</replaceable>.<replaceable>name</replaceable> + <replaceable>/directory</replaceable></programlisting> + <para> + Alternatively, you can use a similar rule that runs the reporter-upload program as the <systemitem class="event">report_<replaceable>SFX</replaceable></systemitem> event if you want to store problem data locally on clients and upload it later using ABRT GUI/CLI. The following is an example of such an event: + </para> + <programlisting lang="Bash">EVENT=report_UploadToMyServer + reporter-upload -u scp://<replaceable>user</replaceable>:<replaceable>password</replaceable>@<replaceable>server</replaceable>.<replaceable>name</replaceable> + <replaceable>/directory</replaceable></programlisting> + </listitem> + </orderedlist> + </section> + <section + id="sect-abrt-centralized_crash_collection-saving_package_information"> + <title>Saving Package Information</title> + <para> + In a single-machine <application>ABRT</application> installation, problems are usually reported to external bug databases such as RHTSupport or Bugzilla. Reporting to these bug databases usually requires knowledge about the component and package in which the problem occurred. The <systemitem class="event">post-create</systemitem> event runs the <application>abrt-action-save-package-data</application> tool (among other steps) in order to provide this information in the standard <application>ABRT</application> installation. + </para> + <para> + If you are setting up a centralized crash collection system, your requirements may be significantly different. Depending on your needs, you have two options: + </para> + <variablelist> + <varlistentry> + <term>Internal analysis of problems</term> + <listitem> + <para> + After collecting problem data, you do not need to collect package information if you plan to analyze problems in-house, without reporting them to any external bug databases. You might be also interested in collecting crashes that occur in programs written by your organization. Such programs do not belong to any package in the first place. In this case take the following steps on both, <emphasis>client systems</emphasis> and a <emphasis>dedicated crash collecting system</emphasis>: + </para> + <itemizedlist> + <listitem> + <para> + Remove the following rule from the <filename>/etc/libreport/events.d/abrt_event.conf</filename> file: + </para> + <programlisting lang="Bash">EVENT=post-create component= + abrt-action-save-package-data</programlisting> + </listitem> + <listitem> + <para> + Prevent deletion of problem data directories which do not correspond to any installed package by setting the following directive in the <filename>/etc/abrt/abrt-action-save-package-data.conf</filename> file: + </para> + <screen>ProcessUnpackaged = yes</screen> + </listitem> + </itemizedlist> + </listitem> + </varlistentry> + <varlistentry> + <term>Reporting to external bug database</term> + <listitem> + <para> + Alternatively, you may want to report crashes to RHTSupport or Bugzilla. In this case, you need to collect package information. Generally, client machines and dedicated crash collecting systems have non-identical sets of installed packages. Therefore, it may happen that problem data uploaded from a client does not correspond to any package installed on the dedicated crash collecting system. In the standard <application>ABRT</application> configuration, this will lead to deletion of problem data (ABRT will consider it to be a crash in an unpackaged executable). To prevent this from happening, it is necessary to modify <application>ABRT</application>'s configuration on the <emphasis>dedicated system</emphasis> in the following way: + </para> + <itemizedlist> + <listitem> + <para> + Prevent inadvertent collection of package information for problem data uploaded from client machines, by adding the <code>remote!=1</code> condition in the <filename>/etc/libreport/events.d/abrt_event.conf</filename> file: + <programlisting lang="Bash">EVENT=post-create remote!=1 component= + abrt-action-save-package-data</programlisting> + </para> + </listitem> + <listitem> + <para> + Prevent deletion of problem data directories which do not correspond to any installed package by setting the following directive in <filename>/etc/abrt/abrt-action-save-package-data.conf</filename>: + </para> + <screen>ProcessUnpackaged = yes</screen> + </listitem> + </itemizedlist> + <note> + <para> + Note that in this case, no such modifications are necessary on client systems: they continue to collect package information, and continue to ignore crashes in unpackaged executables. + </para> + </note> + </listitem> + </varlistentry> + </variablelist> + </section> + <section + id="sect-abrt-crash_detection_test"> + <title>Testing ABRT's Crash Detection</title> + <para> + After completing all the steps of the configuration process, the basic setup is finished. To test that this setup works properly use the <command>kill -s SEGV <replaceable>PID</replaceable> + </command> command to terminate a process on a client system. For example, start a <systemitem + class="process">sleep</systemitem> process and terminate it with the <command>kill</command> command in the following way: + </para> + <screen>~]$ <command>sleep 100 &</command> +[1] 2823 +~]$ <command>kill -s SEGV 2823</command></screen> + <para> + <application>ABRT</application> should detect a crash shortly after executing the <command>kill</command> command. Check that the crash was detected by <application>ABRT</application> on the client system (this can be checked by examining the appropriate syslog file, by running the <command>abrt-cli list --full</command> command, or by examining the crash dump created in the <filename>/var/spool/abrt</filename> directory), copied to the server system, unpacked on the server system and can be seen and acted upon using <command>abrt-cli</command> or <command>abrt-gui</command> on the server system. + </para> + </section> + </section> +  +</chapter> -- 1.8.1.4

1 0

Lowering the participation barrier for Fedora Docs
by Pete Travis 30 Dec '13

30 Dec '13

I took some time over the weekend to update my workstation to F20. It involved performing a lot of now routine tasks; installing the package set I use, pulling in the git repo I keep for $HOME, updating /etc/fstab to include network shares, adding a couple polkit rules for libvirt, blah blah. I'm sure we all have such a list. These are among many routine, everyday tasks for Fedora users. The kind of task that an experienced user could sit down and perform, and write up a how-to for the action on the fly while they do it. The kind of task that an inexperienced user would ask about on a forum, or on irc, or research with relatively specific search terms. I think of this as 'incidental' or 'case-specific' documentation, rather than generalized documentation as provided in the guides. Our existing documentation base is *great*, and anyone who reads through it all will surely come out with the ability to fill in the gaps and handle case-specific problems. We're teaching techniques and tools, not execution. However, between the broad nature of the guides and the SEO reality of a publican site, I think we are failing to reach many users that are actively looking for tutorial-format content. Publican based guides have one major shortcoming. The barrier to entry for potential contributors is high. I had a chance at Flock to have some candid conversation over beer with a few folks outside of the loyal Docs team, and there was a general consensus that while they might be willing to write some *incidental* documentation - again, my term - contributing to a guide was an ordeal they didn't have time for. We've seen this repeatedly with new contributors as well, people who start out with enthusiasm that fades when there isn't work that they can easily drop into. Contributing to a guide is *not* a casual endeavor; it requires us to not only learn docbook and the subject matter, but to be entirely self-motivated while working on a project owned by someone else. Fitting into the workflow is just as intimidating as learning the tools, if not more. I would like to try something different. We should have a product that leverages the experience and quality of our seasoned contributors and enables new contributors to get started. We should have something that helps inexperienced, impatient users. We should enable the Fedora community at large to participate in our efforts, and I think that means coming to them as much as them coming to us. If we have something easier to contribute to, more contributors will likely follow, and then contributors and content for guides as well. I've set up a quick demonstration[1] of some software that I think will address these concerns, a python application called "Nikola"[2]. I have a package review in progress for it, and have already packaged some dependencies. Briefly, it takes plain text files with ReStructuredText or Markdown and transforms them into fully themed static websites. It hooks in to transifex nicely as well. Take a look, you'll find a post detailing how the implementation might work, and a post for the kind of content I envision putting there. [1] http://appliance.randomuser.org/solutions/ [2] http://www.getnikola.com/ -- -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode - immanetize(a)fedoraproject.org

14 36

[System Administrator's Guide] Updating the fedora entities in Book Info
by Rashadul Islam 30 Dec '13

30 Dec '13

commit 0259a93b8bee8f4af2021ed33b6d19f85f467c67 Mon Sep 17 00:00:00 2001 Author: Rashadul Islam <rashadul(a)fedoraproject.org> Date: Mon, 30 Dec 2013 16:14:48 -0500 Replace the entity &PRODVER; in Book_info.xml --- Book_Info.xml | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 Book_Info.xml diff --git a/Book_Info.xml b/Book_Info.xml new file mode 100644 index 0000000..4efa7d6 --- /dev/null +++ b/Book_Info.xml @@ -0,0 +1,25 @@ +<?xml version='1.0'?> +<!DOCTYPE bookinfo PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +]> +<bookinfo> + <title>System Administrator's Guide</title> + <subtitle>Deployment, Configuration, and Administration of &PRODVER;</subtitle> + <productname>Fedora</productname> + <productnumber>20</productnumber> + <edition>1</edition> + <pubsnumber>1</pubsnumber> + <abstract> + <para> + The <citetitle pubwork="book">System Administrator's Guide</citetitle> documents relevant information regarding the deployment, configuration, and administration of Fedora &PRODVER;. It is oriented towards system administrators with a basic understanding of the system. + </para> + </abstract> + <corpauthor> + <inlinemediaobject> + <imageobject> + <imagedata fileref="Common_Content/images/title_logo.svg" format="SVG" /> + </imageobject> + </inlinemediaobject> + </corpauthor> + <xi:include href="Common_Content/Legal_Notice.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Author_Group.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> +</bookinfo> -- 1.8.1.4

1 0

Fedora Docs Meeting Minutes 30Dec2013
by Pete Travis 30 Dec '13

30 Dec '13

==================================================================================================== #fedora-meeting: Docs Project Meeting - Agenda: https://fedoraproject.org/wiki/Docs_Project_meetings ==================================================================================================== Meeting started by randomuser at 14:00:50 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-12-30/fedora_docs.2013… . Meeting summary --------------- * Roll Call (randomuser, 14:00:51) * New Writer Check-In (randomuser, 14:10:21) * LINK: https://fedoraproject.org/wiki/Category:Docs_Project_tasks?rd=Docs_Project_… (randomuser, 14:17:57) * ACTION: randomuser to clean up his mess with the release notes bugs (randomuser, 14:30:43) * Docs Website (randomuser, 14:37:28) * Free Play (randomuser, 14:51:28) Meeting ended at 15:00:59 UTC. Action Items ------------ * randomuser to clean up his mess with the release notes bugs Action Items, by person ----------------------- * randomuser * randomuser to clean up his mess with the release notes bugs * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * randomuser (60) * jjmcd (17) * ciupicri (11) * lnovich (8) * iWelcome (7) * zodbot (3) * nb (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode - immanetize(a)fedoraproject.org

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

docs December 2013