Tweaks to Thorsten's submissions.

diff --git a/docs/en/rst/administering/parameters.rst b/docs/en/rst/administering/parameters.rst
index 9efe5b5e3dc98cb291cfb47ef0682fb840e0f8a9..1f031239a818c5fa10752ffcdb8159bd17637edb 100644 (file)
--- a/docs/en/rst/administering/parameters.rst
+++ b/docs/en/rst/administering/parameters.rst
@@ -241,10 +241,10 @@ maxattachmentsize
 maxlocalattachment
     The maximum size (in megabytes) of attachments to be stored locally on the web server. If set to a value lower than the :param:`maxattachmentsize` parameter, attachments will never be kept on the local filesystem.
 
-       If this feature is useful to you highly depends on your DBMS used and the environment in which you are hosting your Bugzilla. Some DBMS might just not perform well with large binary data saved directly in a database compared to mature file systems like ext4, which are heavily optimized to do exactly that. Attachments stored in a plain directory might as well be easier to backup and restore, depending on how you choosed to implement such processes, because you might have simple file system snapshots available in file systems like BTRFS or NTFS and can browse a backed up directly using a normal file browser, which isn't possible with most of the backups for many DBMSs. Some file systems liek ZFS even provide deduplication support which might help you to reduce the overall size needed for your attachments, depending on your data, users etc. On the opposite, most of the web servers may have just little amount of storage available at all compared to what's mostly provided to DBMS.
-
-       In conclusion it really all depends, but you should keep in mind that currently Bugzilla is not able to transfer attachmens from one storage to another if you change your mind, it only behaves differently after you changed the configuration. The already available data will always stay in it's current storage.
-
+    Whether you use this feature or not depends on your environment. Reasons to store some or all attachments as files might include poor database performance for large binary blobs, ease of backup/restore/browsing, or even filesystem-level deduplication support. However, you need to be aware of any limits on how much data your webserver environment can store. If in doubt, leave the value at 0.
+    
+    Note that changing this value does not affect any already-submitted attachments.
+    
 .. _param-bug-change-policies:
 
 Bug Change Policies

diff --git a/docs/en/rst/customizing/faq.rst b/docs/en/rst/customizing/faq.rst
index 40a986a8c175ada71fc1ab5bf5e237cc39a14fc9..19f8b59ffa11b3b87eda46efd5979cc7682270a2 100644 (file)
--- a/docs/en/rst/customizing/faq.rst
+++ b/docs/en/rst/customizing/faq.rst
@@ -1,3 +1,4 @@
+
 .. _customization-faq:
 
 Customization FAQ
@@ -24,9 +25,3 @@ How do I...
   
 ...alter who can change what field when?
   See :ref:`who-can-change-what`.
-
-...make Bugzilla send mails?
-  See :ref:`email` and check the settings according to your environment, especially you should check if a maybe configured SMTP server can be reached from your Bugzilla server and if the maybe needed auth credentials are valid. If things seem correct and your mails are still not send, check if your OS uses SELinux or AppArmor which may prevent your web server from sending mails. httpd_can_sendmail_ often needs to get activated. If all those things don't help, activate :param:`smtp_debug` and check your webserver logs.
-
-  .. _httpd_can_sendmail: http://selinuxproject.org/page/ApacheRecipes#Allow_the_Apache_HTTP_Server_to_send_mail
-  .. todo:: Ask Thorsten for his input on what questions are common.

diff --git a/docs/en/rst/installing/apache.rst b/docs/en/rst/installing/apache.rst
index f467d8e50b2b98d595ab5044f45ee5ef6de1de5e..f6411d73f8049633305511450fadc7263bb37991 100644 (file)
--- a/docs/en/rst/installing/apache.rst
+++ b/docs/en/rst/installing/apache.rst
@@ -97,9 +97,8 @@ and mod_perl.
 
    .. warning:: You should also ensure that you have disabled ``KeepAlive``
       support in your Apache install when utilizing Bugzilla under mod_perl
-      or you may suffer from `performance penalty`_
-
-      .. `performance penalty`_: http://modperlbook.org/html/11-4-KeepAlive.html
+      or you may suffer a
+      `performance penalty <http://modperlbook.org/html/11-4-KeepAlive.html>`_.
 
 On restarting Apache, Bugzilla should now be running within the
 mod_perl environment.

diff --git a/docs/en/rst/installing/essential-post-install-config.rst b/docs/en/rst/installing/essential-post-install-config.rst
index 975bbadee910d799f23d52bb7c008de56607e019..3882c16a2868eea859628a8de5a6855fcbd5995a 100644 (file)
--- a/docs/en/rst/installing/essential-post-install-config.rst
+++ b/docs/en/rst/installing/essential-post-install-config.rst
@@ -96,17 +96,7 @@ This section corresponds to choosing a :param:`mail_delivery_method` of
 Unless you know what you are doing, and can deal with the possible problems
 of spam, bounces and blacklists, it is probably unwise to set up your own
 mail server just for Bugzilla. However, if you wish to do so, some guidance
-follows. Besides setting up a complete, local distinct mail server just for
-Bugzilla, :paramval:`Sendmail` can as well be used if you really don't want
-to do that: Especially on Windows there's a little application called
-sendmail.exe_ which provides sendmail compatible calling conventions and
-encapsulates the SMTP communication to another mail server. This may be
-useful if you have trouble getting Perl packages for SMTP including encrypted
-communication and such installed on Windows and therefore can't use Bugzilla's
-buil-in support for SMTP. Like Bugzilla, sendmail.exe_ can be configured to
-log SMTP communcation to files in case of problems.
-
-    .. _sendmail.exe: http://glob.com.au/sendmail/
+follows.
 
 On Linux, any Sendmail-compatible MTA (Mail Transfer Agent) will
 suffice.  Sendmail, Postfix, qmail and Exim are examples of common
@@ -123,6 +113,14 @@ On Mac OS X 10.3 and later, `Postfix <http://www.postfix.org/>`_
 is used as the built-in email server.  Postfix provides an executable
 that mimics sendmail enough to satisfy Bugzilla.
 
+On Windows, if you find yourself unable to use Bugzilla's built-in SMTP
+support (e.g. because the necessary Perl modules are not available), you can
+use :paramval:`Sendmail` with a little application called
+`sendmail.exe <http://glob.com.au/sendmail/>`_, which provides
+sendmail-compatible calling conventions and encapsulates the SMTP
+communication to another mail server. Like Bugzilla, :command:`sendmail.exe`
+can be configured to log SMTP communication to a file in case of problems.
+
 Detailed information on configuring an MTA is outside the scope of this
 document. Consult the manual for the specific MTA you choose for detailed
 installation instructions. Each of these programs will have their own
@@ -134,6 +132,20 @@ list of services for the machine.
 If a simple mail sent with the command-line :file:`mail` program
 succeeds, then Bugzilla should also be fine.
 
+Troubleshooting
+---------------
+
+If you are having trouble, check that any configured SMTP server can be
+reached from your Bugzilla server and that any given authentication
+credentials are valid. If these things seem correct and your mails are still
+not sending, check if your OS uses SELinux or AppArmor. Either of these
+may prevent your web server from sending email. The SELinux boolean
+`httpd_can_sendmail <http://selinuxproject.org/page/ApacheRecipes#Allow_the_Apache_HTTP_Server_to_send_mail>`_
+may need to be set to True.
+   
+If all those things don't help, activate the :param:`smtp_debug` parameter
+and check your webserver logs.
+
 .. _config-products:
 
 Products, Components, Versions and Milestones