[deployment-guide/comm-rel: 709/727] fixed minor bugs in ABRT chapter, updated Log files chapter
Jaromir Hradilek
jhradile at fedoraproject.org
Tue Oct 19 13:25:25 UTC 2010
commit ce2545a9aa361f5467f63a16548ae43fc4897d9d
Author: Martin Prpic <mprpic at redhat.com>
Date: Wed Oct 6 16:38:58 2010 +0200
fixed minor bugs in ABRT chapter, updated Log files chapter
en-US/ABRT.xml | 29 ++++++++--------
en-US/Log_Files.xml | 89 +++++++++++++++++++++++++++++++++++++++++++++-----
2 files changed, 94 insertions(+), 24 deletions(-)
---
diff --git a/en-US/ABRT.xml b/en-US/ABRT.xml
index f5bf7fb..8c68a71 100644
--- a/en-US/ABRT.xml
+++ b/en-US/ABRT.xml
@@ -276,7 +276,7 @@ Starting abrt daemon: [ OK ]</screen>
</listitem>
</itemizedlist>
<para>
- When the <guilabel>No SSL verify</guilabel> option is checked, the <systemitem class="protocol">SSL</systemitem> protocol is not used when sending the data over the network.
+ 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>
@@ -373,7 +373,7 @@ Starting abrt daemon: [ OK ]</screen>
</listitem>
</itemizedlist>
<para>
- When the <guilabel>No SSL verify</guilabel> option is checked, the <systemitem class="protocol">SSL</systemitem> protocol is not used when sending the data over the network.
+ When <guilabel>No 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>
@@ -401,7 +401,7 @@ Starting abrt daemon: [ OK ]</screen>
<section id="generating-backtrace">
<title>Generating Backtraces</title>
<para>
- In order to analyze a reported crash, developers need as much details about the crash as possible. A <firstterm>stack backtrace</firstterm> is an important source of information when a crash in a binary program (caught by the <command>CCpp</command> analyzer plugin) occurs.
+ In order to analyze a reported crash, developers need as much detail about the crash as possible. A <firstterm>stack backtrace</firstterm> is an important source of information when a crash in a binary program (caught by the <command>CCpp</command> analyzer plugin) occurs.
</para>
<para>
<application>ABRT</application> is configured to generate a backtrace whenever a crash is reported through the <application>ABRT</application> GUI application or the <application>ABRT</application> command line interface.
@@ -417,7 +417,7 @@ Starting abrt daemon: [ OK ]</screen>
</listitem>
<listitem>
<para>
- It queries <application>Yum</application> to determine which <package>debuginfo</package> packages correspond to all the files extracted from the crash dump. This is the first potentially slow operation. <application>Yum</application> may need to refresh the <parameter>filelists</parameter> of various repositories in order to find the correct package names. This process may take up to few minutes.
+ It queries <application>Yum</application> to determine which <package>debuginfo</package> packages correspond to all the files extracted from the crash dump. This is the first potentially slow operation. <application>Yum</application> may need to refresh the <parameter>filelists</parameter> of various repositories in order to find the correct package names. This process may take a few minutes.
</para>
</listitem>
<listitem>
@@ -530,7 +530,7 @@ tmp]# yumdownloader --enablerepo=*debuginfo* --quiet coreutils
<para>Crashes detected by <application>ABRT</application> can be viewed, reported, and deleted using the command line interface.</para>
<section>
<title>Viewing Crashes</title>
- <para>To get a list of all crashes, simply enter <command>abrt-cli --list</command> or <command>abrt-cli -l</command>:</para>
+ <para>To get a list of all crashes, simply enter <command>abrt-cli --list</command> or <command>abrt-cli -l</command>:</para>
<screen>
~]$ <command>abrt-cli --list</command>
0.
@@ -552,11 +552,10 @@ tmp]# yumdownloader --enablerepo=*debuginfo* --quiet coreutils
</section>
<section>
<title>Reporting Crashes</title>
- <para>To report certain crash, you enter <command>abrt-cli <replaceable>--report/-r</replaceable> <UUID></command>, where <varname>UUID</varname> is a field from <command>abrt-cli <replaceable>--list/-l</replaceable>
- </command>. You do not need to remember the exact <varname>UUID</varname>; either use a mouse to copy and paste it, or enter a unique prefix and press <keycap function="tab"><ENTER></keycap>.</para>
+ <para>To report a certain crash, enter <command>abrt-cli --report <replaceable><UUID></replaceable></command> or <command>abrt-cli --r <replaceable><UUID></replaceable></command>, where <varname>UUID</varname> is a Universally Unique Identifier of a crash from the list of crashes; to view this list, execute the <command>abrt-cli --list</command> command. You do not need to remember the exact <varname>UUID</varname>; either use a mouse to copy and paste it, or enter a unique prefix and press <keycap function="enter"><ENTER></keycap>.</para>
<screen>
~]$ <command>abrt-cli --report 480</command>
- <keycap function="tab"><ENTER></keycap>
+ <keycap function="enter"><ENTER></keycap>
>> Starting report creation...
</screen>
<para>
@@ -568,7 +567,7 @@ tmp]# yumdownloader --enablerepo=*debuginfo* --quiet coreutils
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 if you want to send the report. Respond <keycap>Y</keycap> to send the report or <keycap>N</keycap> to cancel it.</para>
+ <para>When you are done with the report, save your changes and close the editor. You will be asked which of the enabled <application>ABRT</application> plugins you want to use to send the report. Respond <keycap>Y</keycap> to send the report using your desired plugin or <keycap>N</keycap> to skip a plugin you wish not to use.</para>
</section>
<section>
<title>Deleting Crashes</title>
@@ -658,21 +657,21 @@ export <varname>VISUAL</varname>=<userinput>emacs</userinput>
<title>[ AnalyzerActionsAndReporters ] Section Directives</title>
<para>This section allows you to associate certain analyzer actions and reporter actions to run when <application>ABRT</application> catches kernel oopses or crashes in C, C++ or Python programs. The actions and reporters specified in any of the directives below will run only if you run <command>abrt-gui</command> or <command>abrt-cli</command> and report the crash that occurred. If you do not specify any actions and reporters in these directives, you will not be able to report a crash via <command>abrt-gui</command> or <command>abrt-cli</command>. The order of actions and reporters is important. Commenting out a directive, will cause <application>ABRT</application> not to catch the crashes associated with that directive. For example, commenting out the Kerneloops line will cause <application>ABRT</application> not to catch kernel oopses.</para>
<varlistentry>
- <term>Kerneloops = ReportUploader, RHTSupport</term>
+ <term>Kerneloops = RHTSupport, Logger</term>
<listitem>
- <para>This directive specifies that, for kernel oopses, the ReportUploader and RHTSupport reporters will be run.</para>
+ <para>This directive specifies that, for kernel oopses, both the RHTSupport and Logger reporters will be run.</para>
</listitem>
</varlistentry>
<varlistentry>
- <term>CCpp = ReportUploader, RHTSupport</term>
+ <term>CCpp = RHTSupport, Logger</term>
<listitem>
- <para>This directive specifies that, when C or C++ program crashes occur, both the ReportUploader and RHTSupport reporters will be run.</para>
+ <para>This directive specifies that, when C or C++ program crashes occur, both the RHTSupport and Logger reporters will be run.</para>
</listitem>
</varlistentry>
<varlistentry>
- <term>Python = ReportUploader, RHTSupport</term>
+ <term>Python = RHTSupport, Logger</term>
<listitem>
- <para>This directive specifies that, when Python program crashes occur, both the ReportUploader and RHTSupport reporters will be run.</para>
+ <para>This directive specifies that, when Python program crashes occur, both the RHTSupport and Logger reporters will be run.</para>
</listitem>
</varlistentry>
</variablelist>
diff --git a/en-US/Log_Files.xml b/en-US/Log_Files.xml
index e625c2d..6c08699 100644
--- a/en-US/Log_Files.xml
+++ b/en-US/Log_Files.xml
@@ -75,13 +75,13 @@
<note>
<title>Note</title>
<para>
- Any empty lines or any text following a hash sign (#) are comments and are not processed.
+ In your <filename>/etc/rsyslog.conf</filename> configuration file, any empty lines or any text following a hash sign (#) are comments and are not processed.
</para>
</note>
<section id="s2-modules">
<title>Modules</title>
<para>
- Due to its modular design, <command>rsyslog</command> offers a variety of modules which provide dynamic functionality. Note that modules can be written by third parties. Essentially, modules are comprised of various configuration directives that become available when a module is loaded. To load a module, use the following syntax:
+ Due to its modular design, <command>rsyslog</command> offers a variety of <firstterm>modules</firstterm> which provide dynamic functionality. Note that modules can be written by third parties. Essentially, modules are comprised of various configuration directives that become available when a module is loaded. To load a module, use the following syntax:
</para>
<screen>
$ModLoad <replaceable><MODULE></replaceable>
@@ -122,7 +122,7 @@ $ModLoad imfile
</para>
</listitem>
<listitem>
- <para>go
+ <para>
String Generator Modules — String generator modules generate strings based on the message content and strongly cooperate with the template feature provided by <command>rsyslog</command>. For more information on templates, refer to . The name of a string generator module always starts with the <literal>sm</literal> prefix, such as <command>smfile</command>, <command>smtradfile</command>, etc.
</para>
</listitem>
@@ -145,7 +145,7 @@ $ModLoad imfile
<section id="s2-global-directives">
<title>Global Directives</title>
<para>
- Global directives specify configuration options that apply to the <systemitem class="daemon">rsyslogd</systemitem> daemon. All of the global directives must start with a dollar sign (<literal>$</literal>). Only one directive can be specified per line. The following is an example of a global directive that specifies the maximum size of the syslog message queue:</para>
+ <firstterm>Global directives</firstterm> specify configuration options that apply to the <systemitem class="daemon">rsyslogd</systemitem> daemon. All of the global directives must start with a dollar sign (<literal>$</literal>). Only one directive can be specified per line. The following is an example of a global directive that specifies the maximum size of the syslog message queue:</para>
<screen>
$MainMsgQueueSize
</screen>
@@ -159,12 +159,12 @@ $MainMsgQueueSize
<section id="s2-rules">
<title>Rules</title>
<para>
- A rule specifies the cooperation of a selector with an action. To define a rule in your <filename>/etc/rsyslog.conf</filename> configuration file, define both, a selector and an action, on one line and separate them with one or more spaces or tabs. For more information on selectors, refer to <xref linkend="s3-selectors"/> and for information on actions, refer to <xref linkend="s3-actions"/>.
+ A rule specifies the cooperation of a <firstterm>selector</firstterm> with an <firstterm>action</firstterm>. To define a rule in your <filename>/etc/rsyslog.conf</filename> configuration file, define both, a selector and an action, on one line and separate them with one or more spaces or tabs. For more information on selectors, refer to <xref linkend="s3-selectors"/> and for information on actions, refer to <xref linkend="s3-actions"/>.
</para>
<section id="s3-selectors">
<title>Selectors</title>
<para>
- Selectors filter syslog messages based on two conditions: facility and priority. The following is an example of a selector:
+ Selectors filter syslog messages based on two conditions: <firstterm>facility</firstterm> and <firstterm>priority</firstterm>. The following is an example of a selector:
</para>
<screen>
<replaceable><FACILITY></replaceable>.<replaceable><PRIORITY></replaceable>
@@ -191,7 +191,7 @@ $MainMsgQueueSize
In addition to the keywords specified above, you may also use an asterisk (<literal>*</literal>) to define all facilities or priorities (depending on where you place the asterisk, before or after the dot). Specifying the keyword <literal>none</literal> serves for facilities with no given priorities.
</para>
<para>
- You may also define multiple facilities and priorities simply by separating them with a comma (<literal>,</literal>). To define multiple selectors on one line, separate them with a semi-colon (<literal>;</literal>).
+ To define multiple facilities and priorities, simply separate them with a comma (<literal>,</literal>). To define multiple selectors on one line, separate them with a semi-colon (<literal>;</literal>).
</para>
<para>
The following are a few examples of simple selectors:
@@ -203,14 +203,85 @@ kern.* # Selects all kernel syslog messages with any priority
mail.crit # Selects all mail syslog messages with priority <command>crit</command> and higher.
</screen>
<screen>
-cron.!info,!debug # Selects all cron syslog messages but those with the <command>info</command> or <command>debug</command> priority.
+cron.!info,!debug # Selects all cron syslog messages except those with the <command>info</command> or <command>debug</command> priority.
</screen>
</section>
+ <!-- TODO!!!!!!!!!!!!!!!!!!!!
+
+ check for terms "syslog message" and "syslog file"
+
+ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+ -->
<section id="s3-actions">
<title>Actions</title>
<para>
- Actions specify what is to be done with the messages filtered out by the defined selector.
+ Actions specify what is to be done with the messages filtered out by the defined selector. The following are some of the actions you can define in your rule:
</para>
+ <!-- VARIABLE LIST!
+
+ !!!!!!!!!!!!!!!!!!!!!!!!!!!
+ -->
+ <itemizedlist>
+ <listitem>
+ <para>
+ Syslog message placement — The majority of actions specify to which log file a syslog message is saved. This is done by specifying a file path after your already defined selector. The following is a rule comprised of a selector that selects all <application>cron</application> syslog messages and an action that saves them into the <filename>/var/log/cron</filename> log file:
+ </para>
+ <screen>cron. /var/log/cron
+ </screen>
+ <para>
+ Use a dash mark (<literal>-</literal>) as a prefix of the file path you specified if you want to omit syncing the desired log file after every syslog message is generated.
+ </para>
+ <para>
+ Your specified file path can be either static or dynamic. Static files are represented by a simple file path as was shown in the example above. Dynamic files are represented by a template and a question mark (<literal>?</literal>) prefix. For more information on templates, refer to <xref linkend="s2-templates"/>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Sending syslog messages over the network — <command>rsyslog</command> allows you to send and receive syslog messages over the network. This feature allows to administer syslog messages of multiple hosts on one machine. To forward syslog messages to a remote machine, use the following syntax:
+ </para>
+ <screen>@(<replaceable><OPTION></replaceable>,<replaceable><MORE OPTIONS></replaceable>)<replaceable><HOST></replaceable>:<replaceable><PORT></replaceable>
+ </screen>
+ <para>
+ where:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ the at sign (<literal>@</literal>) indicates that the syslog messages are forwarded to a host using the <systemitem class="protocol">UDP</systemitem> protocol. To use the <systemitem class="protocol">TCP</systemitem> protocol, use two at signs with no space between them (<literal>@@</literal>),
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ the <replaceable><OPTION></replaceable> and <replaceable><MORE OPTIONS></replaceable> specify TBD
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem>
+ <para>
+
+ </para>
+ </listitem>
+ </itemizedlist>
+
+
+
+ <!-- most actions specify where a specific syslog message will be "placed"
+ - The filename can be either static (always the same) or dynamic (different based on message received)
+ - Creating directories is also supported?
+
+ syslog messages can also be sent over the network and receive messages from remote hosts.
+
+ can be sent to specific users, groups of users
+
+ discard
+
+ including a template, more on templates in ... Beware: templates MUST be defined BEFORE they are used
+
+ -->
+ <para>
+ <!-- TODO: specifying multiple actions!!! -->
+ </para>
</section>
</section>
<section id="s2-templates">
More information about the docs-commits
mailing list