[deployment-guide/comm-rel: 547/727] added tourbleshooting backtrace generation section, changed the alarm icon screenshot, small modific
Jaromir Hradilek
jhradile at fedoraproject.org
Tue Oct 19 13:10:56 UTC 2010
commit a7bbca4a71ab6dab3c57a7b6355daaf22e71dca3
Author: Martin Prpic <mprpic at redhat.com>
Date: Wed Sep 1 17:48:54 2010 +0200
added tourbleshooting backtrace generation section, changed the alarm icon screenshot, small modification to Email and Samba ch.
en-US/ABRT.xml | 164 +++++++++++++++-----
en-US/Email.xml | 2 +-
en-US/Samba.xml | 20 ++-
en-US/images/ABRT-Notification_Area_alarm_icon.png | Bin 1009 -> 1187 bytes
4 files changed, 138 insertions(+), 48 deletions(-)
---
diff --git a/en-US/ABRT.xml b/en-US/ABRT.xml
index e6742a1..31bf220 100644
--- a/en-US/ABRT.xml
+++ b/en-US/ABRT.xml
@@ -6,7 +6,7 @@
<section>
<title>Overview</title>
<para>
- <application>ABRT</application> is the <application>Automatic Bug-Reporting Tool</application>. <application>ABRT</application> consists of a daemon that runs silently in the background most of the time. It springs into action when an application crashes. It then collects the relevant crash data such as a core file if there is one, the crashing application's command line parameters, and other contextual puzzle pieces of forensic utility. Finally, <application>ABRT</application> is capable of reporting crash data to a relevant issue tracker, such as Bugzilla. Reporting crash data to a relevant issue tracker can be configured to happen automatically at every detected crash, or crash dumps can be stored locally, reviewed, reported, and deleted manually by a user. <application>ABRT</application>'s various plugins analyze crash data from applications written in the C, C++ and Python language, as well as report crashes to relevant issue trackers.
+ <application>ABRT</application> is the <application>Automatic Bug-Reporting Tool</application>. <application>ABRT</application> consists of a daemon that runs silently in the background most of the time. It springs into action when an application crashes. It then collects the relevant crash data such as a core file if there is one, the crashing application's command line parameters, and other contextual puzzle pieces of forensic utility. Finally, <application>ABRT</application> is capable of reporting crash data to a relevant issue tracker, such as RHTSupport. Reporting crash data to a relevant issue tracker can be configured to happen automatically at every detected crash, or crash dumps can be stored locally, reviewed, reported, and deleted manually by a user. <application>ABRT</application>'s various plugins analyze crash data from applications written in the C, C++ and Python language, as well as report crashes to relevant issue trackers.
</para>
<para>The <application>ABRT</application> package consists of:
</para>
@@ -47,7 +47,7 @@
</mediaobject>
<para>A number of additional packages can be installed to provide <application>ABRT</application> plugins and addons. To view all the available <application>ABRT</application> packages, type the following command:
<screen>
-<command>yum list all |grep abrt</command>
+<command>~]$ yum list all | grep abrt</command>
</screen>
</para>
<!-- mprpic: list of all plugins removed, more on plugins in the Plugins section
@@ -94,6 +94,7 @@
<section>
<title>Installing and Running ABRT</title>
<para>By default, <application>ABRT</application> should be installed on your system, the <systemitem class="daemon">abrtd</systemitem> daemon configured to run at boot time, and <application>abrt-applet</application> to run in the Notification Area of your desktop session.
+ </para>
<note>
<title>Note: Installing the <application>ABRT</application> packages</title>
<para>In order to use <application>ABRT</application>, first ensure the <command>abrt-desktop</command> package is installed on your system by running, as root:
@@ -101,22 +102,18 @@
<screen>~]# <command>yum install abrt-desktop</command>
</screen>
<para>For more information on installing packages with Yum, refer to <xref linkend="sec-Installing"/>.</para>
- </note>
- You can check whether <application>ABRT</application> is installed by running:</para>
- <screen>~]$ <command>yum install abrt-desktop</command>
- </screen>
- <para>
- For more information on installing packages with Yum, refer to <xref linkend="sec-Installing"/>.
- </para>
+ </note>
<para>
- <application>ABRT</application> is typically configured to start up at boot time. You can check that the <systemitem class="daemon">abrtd</systemitem> daemon is running by issuing the command:</para>
+ <application>ABRT</application> is typically configured to start up at boot time. You can check that the <systemitem class="daemon">abrtd</systemitem> daemon is running by running the following command, as root:</para>
<screen>~]# <command>service abrtd status</command>
abrt (pid 1559) is running...</screen>
<para>If you receive <computeroutput>abrt is stopped</computeroutput>, you can start the <systemitem class="daemon">abrtd</systemitem>
service by running, as root:</para>
<screen>~]# <command>service abrtd start</command>
Starting abrt daemon: [ OK ]</screen>
- <para>You can ensure that the <systemitem class="daemon">abrtd</systemitem> service initializes at startup time by running the <command>chkconfig abrtd on</command> command as root.</para>
+ <para>You can ensure that the <systemitem class="daemon">abrtd</systemitem> service initializes at startup time by running the following command, as root:</para>
+ <screen>~]# <command>chkconfig abrtd on</command>
+ </screen>
<para>
<application>ABRT</application>'s applet can be started by hand by running the <command>abrt-applet</command> program as a normal user when logged into your desktop session, or by arranging for it to be started when the GUI session is initialized. For example, on the GNOME desktop, this can be configured in <menuchoice><guimenu>System</guimenu>
<guimenuitem>Preferences</guimenuitem>
@@ -143,7 +140,7 @@ Starting abrt daemon: [ OK ]</screen>
<para>
<application>ABRT</application> offers a variety of analyzer plugins and reporter plugins. These plugins are described in the following two sections. Not all of the plugins mentioned in the following sections are installed by default. To view all available plugins, run the following command:
<screen>
-<command>]$ yum list all |grep abrt-plugin-*</command>
+<command>]$ yum list all | grep abrt-plugin-*</command>
</screen>
</para>
<section id="analyzer-plugins">
@@ -188,7 +185,7 @@ Starting abrt daemon: [ OK ]</screen>
<term>RHTSupport</term>
<listitem>
<para>
- TBD
+ — Reports crashes into the Red Hat Technical Support system. Intended for users of &MAJOROS;.
</para>
</listitem>
</varlistentry>
@@ -204,7 +201,7 @@ Starting abrt daemon: [ OK ]</screen>
<term>Report Uploader</term>
<listitem>
<para>
- — Reports crashes into an anonymous <systemitem class="protocol">FTP</systemitem> site associated with a ticketing system.
+ — Uploads a tarball with crash data into a <systemitem class="protocol">FTP</systemitem>/<systemitem class="protocol">SCP</systemitem> server
</para>
</listitem>
</varlistentry>
@@ -212,12 +209,12 @@ Starting abrt daemon: [ OK ]</screen>
<term>Bugzilla</term>
<listitem>
<para>
- — Reports crashes into Bugzilla in the form of Bugzilla bugs.
+ — Reports crashes into Bugzilla in the form of Bugzilla database entries.
</para>
<note>
<title>Note</title>
<para>
- The use of the Bugzilla plugin to report crashes into Bugzilla in the form of bugs is strongly discouraged. Please use the RHTSupport plugin to report crashes into the Red Hat Ticketing System instead.
+ The use of the Bugzilla plugin to report crashes into Bugzilla in the form of Bugzilla database entries is strongly discouraged. Please use the RHTSupport plugin to report crashes into the Red Hat Ticketing System instead.
</para>
</note>
</listitem>
@@ -245,9 +242,6 @@ Starting abrt daemon: [ OK ]</screen>
All of the <filename>/etc/abrt/plugins/*.conf</filename> configuration files 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 $HOME only) are stored in the Gnome keyring or can be stored in a text file in <filename>$HOME/.abrt/*.conf</filename> for use in <command>abrt-cli</command>.
</para>
</note>
- <para>
- The following is a list of all configuration options available for each configurable plugin in the <application>ABRT</application> GUI application.
- </para>
<mediaobject id="mediaobj-abrt-plugins">
<imageobject>
<imagedata align="center" fileref="images/ABRT-plugins.png" format="PNG"/>
@@ -256,12 +250,35 @@ Starting abrt daemon: [ OK ]</screen>
<para>ABRT Plugins</para>
</caption>
</mediaobject>
+ <para>
+ The following is a list of all configuration options available for each configurable plugin in the <application>ABRT</application> GUI application.
+ </para>
<variablelist>
<varlistentry>
<term>RHTSupport</term>
<listitem>
<para>
- TBD
+ In the <guilabel>RHTSupport plugin configuration</guilabel>, you can configure the following parameters:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <guilabel>RHTSupport URL</guilabel> — Specifies the RHTSupport URL where crash dumps are sent (by default, set to <ulink url="https://api.access.redhat.com/rs"/>).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <guilabel>Login</guilabel> — User login which is used to log into RHTSupport and create a RHTSupport database entry for a reported crash.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <guilabel>Password</guilabel> — Password used to log into RHTSupport.
+ </para>
+ </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.
</para>
</listitem>
</varlistentry>
@@ -343,12 +360,12 @@ Starting abrt daemon: [ OK ]</screen>
<itemizedlist>
<listitem>
<para>
- <guilabel>Bugzilla URL</guilabel> — Specifies the Bugzilla URL where crash dumps are sent (by default, set to <systemitem class="domainname">https://bugzilla.redhat.com</systemitem>).
+ <guilabel>Bugzilla URL</guilabel> — Specifies the Bugzilla URL where crash dumps are sent (by default, set to <ulink url="https://bugzilla.redhat.com"/>).
</para>
</listitem>
<listitem>
<para>
- <guilabel>Login (email)</guilabel> — User login which is used to log into Bugzilla and create a bug for a reported crash.
+ <guilabel>Login (email)</guilabel> — User login which is used to log into Bugzilla and create a Bugzilla database entry for a reported crash.
</para>
</listitem>
<listitem>
@@ -397,7 +414,7 @@ Starting abrt daemon: [ OK ]</screen>
<itemizedlist>
<listitem>
<para>
- It examines the core dump (which consists of the recorded contents of the memory of an application at a specific time), which is saved in the crash dump file. From this file, <application>ABRT</application> extracts the information about the crashed binary program and information about every loaded dynamic library.
+ It examines the core dump (which consists of the recorded contents of the memory of an application at a specific time), which is saved in the crash dump directory. From this file, <application>ABRT</application> extracts the information about the crashed binary program and information about every loaded dynamic library.
</para>
</listitem>
<listitem>
@@ -449,8 +466,71 @@ Starting abrt daemon: [ OK ]</screen>
<section id="troubleshooting">
<title>Troubleshooting Backtrace Generation</title>
<para>
- In some cases, a long delay in the <application>ABRT</application> GUI application occurs after choosing a crash and pressing the <guibutton>Report</guibutton> button. In this case, open the <guibutton>Details</guibutton> in the <guilabel>Generating backtrace</guilabel> window and examine the provided messages. [***TO_BE_EXPANDED***]
+ In some cases, a long delay in the <application>ABRT</application> GUI application occurs after choosing a crash and pressing the <guibutton>Report</guibutton> button. In this case, open the <guibutton>Details</guibutton> in the <guilabel>Generating backtrace</guilabel> window and examine the messages.
+ </para>
+ <para>
+ The following is a typical output seen in the <guilabel>Generating backtrace</guilabel> window:
+ </para>
+ <screen>
+Starting the debuginfo installation
+Getting list of build IDs
+12 missing debuginfos, getting package list from cache
+12 missing debuginfos, getting package list from repositories
+Downloading 7 packages
+Download 1/7: acl-debuginfo-2.2.49-6.fc13.x86_64
+Unpacking: acl-debuginfo-2.2.49-6.fc13.x86_64.rpm
+Caching debuginfo:
+usr/lib/debug/.build-id/3d/e20df1db609bd9313b1dc440796004f95911fd.debug
+Download 2/7: firefox-debuginfo-3.6.7-1.fc13.x86_64
+Unpacking: firefox-debuginfo-3.6.7-1.fc13.x86_64.rpm
+Caching debuginfo:
+usr/lib/debug/.build-id/3d/b29c9308cb276431ce8854a2d88cf83518afc6.debug
+Caching debuginfo:
+usr/lib/debug/.build-id/a3/86884285365c8288e4e761ec034fafaa1daee1.debug
+...
+ </screen>
+ <para>
+ This process is performed by the <application>/usr/bin/abrt-debuginfo-install</application> shell script. This script uses a temporary directory (e.g. <filename>/var/run/abrt/tmp-29177-1283344373</filename>) for its operations. Normally, this directory is removed when <application>abrt-debuginfo-install</application> exits.
</para>
+ <para>
+ If the <package>debuginfo</package> installation hangs, or is unable to download anything, you may debug the problem by editing the <application>abrt-debuginfo-install</application> script. Change the following parameters:
+ </para>
+ <screen>
+debug=false
+keep_tmp=false
+ </screen>
+ <para>
+ at the top of the script to:
+ </para>
+ <screen>
+debug=true
+keep_tmp=true
+ </screen>
+ <para>
+ The first parameter instructs <application>abrt-debuginfo-install</application> to be verbose, the second parameter instructs <application>abrt-debuginfo-install</application> to not delete the <filename>/var/run/abrt/tmp-NNN-NNN</filename> directory. You can examine the log files in this directory to provide you with useful error messages.
+ </para>
+ <para>
+ <application>abrt-debuginfo-install</application> uses <application>yum</application> and <application>yumdownloader</application> to handle the <package>debuginfo</package> packages. In order to quickly check that your <application>yum</application> configuration does not cause any problems which prevent <application>abrt-debuginfo-install</application> from working properly, change to the <filename>/tmp</filename> directory and run the following commands, as root:
+ </para>
+ <screen>
+tmp]# yum --enablerepo=*debuginfo* --quiet provides /usr/bin/true
+tmp]# yumdownloader --enablerepo=*debuginfo* --quiet coreutils
+ </screen>
+ <para>
+ Both of these commands should complete successfully, with no error messages. The second command should download the <filename>coreutils-*.rpm</filename> file. If any error messages appear, check your <application>yum</application> configuration in the files in the <filename>/etc/yum.repos.d/*</filename> directory and the <filename>/etc/yum/*</filename> directory. If any of these commands hang, check that you do not have another instance of <application>yum</application> running, and that your network connection is working properly.
+ </para>
+ <para>
+ The following is the end of a typical output seen in the <guilabel>Generating backtrace</guilabel> window:
+ <screen>
+...
+Download 7/7: zlib-debuginfo-1.2.3-23.fc12.x86_64
+Unpacking: zlib-debuginfo-1.2.3-23.fc12.x86_64.rpm
+Caching debuginfo:
+usr/lib/debug/.build-id/f7/933750da80f555321576e72b375caf7a3cc075.debug
+All needed debuginfos are present
+Generating backtrace
+ </screen>
+ </para>
</section>
</section>
<section>
@@ -460,7 +540,7 @@ Starting abrt daemon: [ OK ]</screen>
<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>
<screen>
-~]# <command>abrt-cli --list</command>
+~]$ <command>abrt-cli --list</command>
0.
UID : 500
UUID : 784b06666020e9f43718d99bf2649f19b4f251a9
@@ -483,7 +563,7 @@ Starting abrt daemon: [ OK ]</screen>
<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>
<screen>
-~]# <command>abrt-cli --report 480</command>
+~]$ <command>abrt-cli --report 480</command>
<keycap function="tab"><ENTER></keycap>
>> Starting report creation...
</screen>
@@ -517,7 +597,7 @@ export <varname>VISUAL</varname>=<userinput>emacs</userinput>
</screen>
<para>The following configuration directives are currently supported in <filename>/etc/abrt/abrt.conf</filename>.</para>
<variablelist>
- <title>[ Common ] Section Directives</title>
+ <title>[ Common ] Section Directives</title>
<varlistentry>
<term>OpenGPGCheck = <replaceable><yes/no></replaceable>
</term>
@@ -530,7 +610,7 @@ export <varname>VISUAL</varname>=<userinput>emacs</userinput>
</optional>
</term>
<listitem>
- <para>Crashes in packages 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, list them here separated by commas.</para>
+ <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>
@@ -583,42 +663,42 @@ export <varname>VISUAL</varname>=<userinput>emacs</userinput>
</varlistentry>
</variablelist>
<variablelist>
- <title>[ AnalyzerActionsAndReporters ] Section Directives</title>
+ <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 = TicketUploader, Bugzilla</term>
+ <term>Kerneloops = ReportUploader, RHTSupport</term>
<listitem>
- <para>This directive specifies that, for kernel oopses, the TicketUploader and Bugzilla reporters will be run.</para>
+ <para>This directive specifies that, for kernel oopses, the ReportUploader and RHTSupport reporters will be run.</para>
</listitem>
</varlistentry>
<varlistentry>
- <term>CCpp = TicketUploader, Bugzilla</term>
+ <term>CCpp = ReportUploader, RHTSupport</term>
<listitem>
- <para>This directive specifies that, when C or C++ program crashes occur, both the TicketUploader and Bugzilla reporters will be run.</para>
+ <para>This directive specifies that, when C or C++ program crashes occur, both the ReportUploader and RHTSupport reporters will be run.</para>
</listitem>
</varlistentry>
<varlistentry>
- <term>Python = TicketUploader, Bugzilla</term>
+ <term>Python = ReportUploader, RHTSupport</term>
<listitem>
- <para>This directive specifies that, when Python program crashes occur, both the TicketUploader and Bugzilla reporters will be run.</para>
+ <para>This directive specifies that, when Python program crashes occur, both the ReportUploader and RHTSupport reporters will be run.</para>
</listitem>
</varlistentry>
</variablelist>
<para>
- Each of these destinations' details can be specified in the corresponding <filename>plugins/*.conf</filename> file. For example, <filename>plugins/Bugzilla.conf</filename> specifies which Bugzilla URL to use (set to <ulink url="https://bugzilla.redhat.com/"/> by default), the user's login name, password for logging in to the Bugzilla site, etc. All these options can also be configured through the <command>abrt-gui</command> application (for more information on plugin configuration refer to <xref linkend="abrt-plugins"/>).
+ Each of these destinations' details can be specified in the corresponding <filename>plugins/*.conf</filename> file. For example, <filename>plugins/RHTSupport.conf</filename> specifies which RHTSupport URL to use (set to <ulink url="https://api.access.redhat.com/rs"/> by default), the user's login name, password for logging in to the RHTSupport site, etc. All these options can also be configured through the <command>abrt-gui</command> application (for more information on plugin configuration refer to <xref linkend="abrt-plugins"/>).
</para>
<variablelist>
- <title>[ Cron ] Section Directives</title>
+ <title>[ Cron ] Section Directives</title>
<varlistentry>
<term>
<replaceable><time></replaceable> = <replaceable><action_to_run></replaceable>
</term>
<listitem>
- <para>The <computeroutput>[ Cron ]</computeroutput> section of <filename>abrt.conf</filename> allows you to specify the exact time, or elapsed amount of time between, when <application>ABRT</application> should run a certain action, such as scanning for kernel oopses or performing file transfers. You can list further actions to run by appending them to the end of this section.</para>
+ <para>The <computeroutput>[ Cron ]</computeroutput> section of <filename>abrt.conf</filename> allows you to specify the exact time, or elapsed amount of time between, when <application>ABRT</application> should run a certain action, such as scanning for kernel oopses or performing file transfers. You can list further actions to run by appending them to the end of this section.</para>
<example id="ex-_Cron__section_of__etc_abrt_abrt.conf">
- <title>[ Cron ] section of /etc/abrt/abrt.conf</title>
+ <title>[ Cron ] section of /etc/abrt/abrt.conf</title>
<screen># Which Action plugins to run repeatedly
-[ Cron ]
+[ Cron ]
# h:m - at h:m
# s - every s seconds
120 = KerneloopsScanner
@@ -706,7 +786,7 @@ URL = ftp://USERNAME:PASSWORD@SERVERNAME/var/spool/abrt-upload/
</listitem>
<listitem>
<para>
- To automatically send the crash reports to the server system immediately after the crash occurs, is detected, and saved, set the <varname>ActionsAndReporters</varname> directive in the <filename>/etc/abrt/abrt.conf</filename> configuration file to the following:
+ To automatically send the crash reports to the server system immediately after the crash occurs, is detected, and saved, set the <varname>[ ActionsAndReporters ]</varname> directive in the <filename>/etc/abrt/abrt.conf</filename> configuration file to the following:
<screen>
ActionsAndReporters = ReportUploader
</screen>
@@ -714,7 +794,7 @@ ActionsAndReporters = ReportUploader
</listitem>
<listitem>
<para>
- Setting the <parameter>ReportUploader</parameter> to be a reporter plugin for a specific crash type in the <literal>[AnalyzerActionsAndReporters]</literal> section of the <filename>/etc/abrt/abrt.conf</filename> configuration file will require user interaction before the crash dump is sent to the server system. The user will be required to run <application>abrt-cli</application> or <application>abrt-gui</application> and instruct <systemitem class="daemon">abrtd</systemitem> to report the crash and send it to the server system. For example, if you want all crash types to use this method, edit your <filename>/etc/abrt/abrt.conf</filename> configuration file in the following way:
+ # Alternatively, if user interaction is required before the crash dump is sent to the server system, set the <parameter>ReportUploader</parameter> to be a reporter plugin for a specific crash type in the <literal>[ AnalyzerActionsAndReporters ]</literal> section of the <filename>/etc/abrt/abrt.conf</filename> configuration file. The user will be required to run <application>abrt-cli</application> or <application>abrt-gui</application> and instruct the <systemitem class="daemon">abrtd</systemitem> daemon to report the crash and send it to the server system. For example, if you want all crash types to use this method, edit the <literal>[ AnalyzerActionsAndReporters ]</literal> section in your <filename>/etc/abrt/abrt.conf</filename> configuration file in the following way:
</para>
<screen>
Kerneloops = ReportUploader
diff --git a/en-US/Email.xml b/en-US/Email.xml
index ae341d9..bc92ca8 100644
--- a/en-US/Email.xml
+++ b/en-US/Email.xml
@@ -527,7 +527,7 @@ search_base = dc=example, dc=com
<screen>~]# <command>service sendmail restart</command>
</screen>
</important>
- <para>The default configuration which ships with &MAJOROS; works for most <systemitem class="protocol">SMTP</systemitem>-only sites. However, it does not work for <firstterm>UUCP</firstterm> (<firstterm>UNIX to UNIX Copy</firstterm>) sites. If using UUCP mail transfers, the <filename>/etc/mail/sendmail.mc</filename> file must be reconfigured and a new <filename>/etc/mail/sendmail.cf</filename> file must be generated.</para>
+ <para>The default configuration which ships with &MAJOROS; works for most <systemitem class="protocol">SMTP</systemitem>-only sites. However, it does not work for <firstterm>UUCP</firstterm> (<firstterm>UNIX-to-UNIX Copy Protocol</firstterm>) sites. If using UUCP mail transfers, the <filename>/etc/mail/sendmail.mc</filename> file must be reconfigured and a new <filename>/etc/mail/sendmail.cf</filename> file must be generated.</para>
<para>Consult the <filename>/usr/share/sendmail-cf/README</filename> file before editing any files in the directories under the <filename>/usr/share/sendmail-cf</filename> directory, as they can affect the future configuration of the <filename>/etc/mail/sendmail.cf</filename> file.</para>
</section>
<section
diff --git a/en-US/Samba.xml b/en-US/Samba.xml
index 3d5ad58..8b42906 100644
--- a/en-US/Samba.xml
+++ b/en-US/Samba.xml
@@ -1360,13 +1360,13 @@ security = share
<command>ldapsam</command>
</term>
<listitem>
- <para>The <command>ldapsam</command> back end provides an optimal distributed account installation method for Samba. LDAP is optimal because of its ability to replicate its database to any number of servers using the OpenLDAP <command>slurpd</command> daemon. LDAP databases are light-weight and scalable, and as such are preferred by large enterprises.</para>
+ <para>The <command>ldapsam</command> back end provides an optimal distributed account installation method for Samba. LDAP is optimal because of its ability to replicate its database to any number of servers such as the <application>Red Hat Directory Server</application> or an <application>OpenLDAP Server</application>. LDAP databases are light-weight and scalable, and as such are preferred by large enterprises. Installation and configuration of directory servers is beyond the scope of this chapter. For more information on the <application>Red Hat Directory Server</application>, refer to the <citetitle>Red Hat Directory Server 8.2 Deployment Guide</citetitle> <!-- TBD6: link to the Red Hat Directory Server 8.2 DG -->. For more information on LDAP, refer to <xref linkend="ch-Lightweight_Directory_Access_Protocol_LDAP"/></para>
<para>If you are upgrading from a previous version of Samba to 3.0, note that the <filename>/usr/share/doc/samba-<replaceable><version></replaceable>/LDAP/samba.schema</filename> has changed. This file contains the <firstterm>attribute syntax definitions</firstterm> and <firstterm>objectclass definitions</firstterm> that the <command>ldapsam</command> back end will need in order to function properly.</para>
<para>As such, if you are using the <command>ldapsam</command> back end for your Samba server, you will need to configure <command>slapd</command> to include this schema file. Refer to <xref
linkend="s1-ldap-files-schemas"/> for directions on how to do this.</para>
<note>
<title>Note</title>
- <para>You will need to have the <filename>openldap-server</filename> package installed if you want to use the <command>ldapsam</command> back end.</para>
+ <para>You need to have the <filename>openldap-server</filename> package installed if you want to use the <command>ldapsam</command> back end.</para>
</note>
<!-- RHEL5: tech review: cut!
perfect for most organizations, especially large enterprises. LDAP is definitely the "wave of the future" with regards to Samba. Improvements to LDAP are
@@ -2161,17 +2161,27 @@ Press enter to see a dump of your service definitions
<itemizedlist>
<listitem>
<para>
- <command>man smb.conf</command>
+ <command>smb.conf</command>
</para>
</listitem>
<listitem>
<para>
- man X
+ <command>samba</command>
</para>
</listitem>
<listitem>
<para>
- man Y
+ <command>smbd</command>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <command>nmbd</command>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <command>winbind</command>
</para>
</listitem>
</itemizedlist>
diff --git a/en-US/images/ABRT-Notification_Area_alarm_icon.png b/en-US/images/ABRT-Notification_Area_alarm_icon.png
index f737aff..4d3ef28 100644
Binary files a/en-US/images/ABRT-Notification_Area_alarm_icon.png and b/en-US/images/ABRT-Notification_Area_alarm_icon.png differ
More information about the docs-commits
mailing list