From 546ace5f776513f87318f793aca3a7cd47eed543 Mon Sep 17 00:00:00 2001 From: "jake%bugzilla.org" <> Date: Fri, 4 Apr 2008 11:48:14 +0000 Subject: Add id's to sections that didn't have them. --- docs/en/xml/troubleshooting.xml | 141 ++++++++++++++++++++++------------------ 1 file changed, 76 insertions(+), 65 deletions(-) (limited to 'docs/en/xml/troubleshooting.xml') diff --git a/docs/en/xml/troubleshooting.xml b/docs/en/xml/troubleshooting.xml index 223c8a135..cd4e721d2 100644 --- a/docs/en/xml/troubleshooting.xml +++ b/docs/en/xml/troubleshooting.xml @@ -1,5 +1,5 @@ - + Troubleshooting @@ -15,40 +15,27 @@ completion, it normally explains what's wrong and how to fix it. If you can't work it out, or if it's being uncommunicative, post the errors in the - mozilla.support.bugzilla + netscape.public.mozilla.webtools newsgroup. If you have made it all the way through (Installation) and (Configuration) but accessing the Bugzilla - URL doesn't work, the first thing to do is to check your web server error + URL doesn't work, the first thing to do is to check your webserver error log. For Apache, this is often located at /etc/logs/httpd/error_log. The error messages you see may be self-explanatory enough to enable you to diagnose and fix the problem. If not, see below for some commonly-encountered errors. If that doesn't help, post the errors to the newsgroup. - - - Bugzilla can also log all user-based errors (and many code-based errors) - that occur, without polluting the web server's error log. To enable - Bugzilla error logging, create a file that Bugzilla can write to, named - errorlog, in the Bugzilla data - directory. Errors will be logged as they occur, and will include the type - of the error, the IP address and username (if available) of the user who - triggered the error, and the values of all environment variables; if a - form was being submitted, the data in the form will also be included. - To disable error logging, delete or rename the - errorlog file. -
- The Apache web server is not serving Bugzilla pages + The Apache webserver is not serving Bugzilla pages After you have run checksetup.pl twice, run testserver.pl http://yoursite.yourdomain/yoururl - to confirm that your web server is configured properly for + to confirm that your webserver is configured properly for Bugzilla. @@ -75,13 +62,31 @@ TEST-OK Webserver is preventing fetch of http://landfill.bugzilla.org/bugzilla-t - The permissions on your library directories are set incorrectly. - They must, at the very least, be readable by the web server user or - group. It is recommended that they be world readable. + The permissions on your library directories are set incorrectly. + They must, at the very least, be readable by the webserver user or + group. It is recommended that they be world readable.
+ +
+ Bundle::Bugzilla makes me upgrade to Perl 5.6.1 + + Try executing perl -MCPAN -e 'install CPAN' + and then continuing. + + + Certain older versions of the CPAN toolset were somewhat naive about + how to upgrade Perl modules. When a couple of modules got rolled into the + core Perl distribution for 5.6.1, CPAN thought that the best way to get + those modules up to date was to haul down the Perl distribution itself and + build it. Needless to say, this has caused headaches for just about + everybody. Upgrading to a newer version of CPAN with the + commandline above should fix things. + +
+
DBD::Sponge::db prepare failed @@ -139,12 +144,55 @@ TEST-OK Webserver is preventing fetch of http://landfill.bugzilla.org/bugzilla-t
+
+ Your vendor has not defined Fcntl macro O_NOINHERIT + + This is caused by a bug in the version of + File::Temp that is distributed with perl + 5.6.0. Many minor variations of this error have been reported: + + + Your vendor has not defined Fcntl macro O_NOINHERIT, used +at /usr/lib/perl5/site_perl/5.6.0/File/Temp.pm line 208. + +Your vendor has not defined Fcntl macro O_EXLOCK, used +at /usr/lib/perl5/site_perl/5.6.0/File/Temp.pm line 210. + +Your vendor has not defined Fcntl macro O_TEMPORARY, used +at /usr/lib/perl5/site_perl/5.6.0/File/Temp.pm line 233. + + Numerous people have reported that upgrading to version 5.6.1 + or higher solved the problem for them. A less involved fix is to apply + the following patch, which is also + available as a patch file. + + + +
+
Everybody is constantly being forced to relogin The most-likely cause is that the cookiepath parameter is not set correctly in the Bugzilla configuration. You can change this (if - you're a Bugzilla administrator) from the editparams.cgi page via the web interface. + you're a Bugzilla administrator) from the editparams.cgi page via the web. The value of the cookiepath parameter should be the actual directory @@ -209,11 +257,13 @@ TEST-OK Webserver is preventing fetch of http://landfill.bugzilla.org/bugzilla-t past and need to set it to something more restrictive (i.e. /bugzilla/), you can safely do this without requiring users to delete their Bugzilla-related cookies in their - browser (this is true starting with Bugzilla 2.18 and Bugzilla 2.16.5). + browser (this is true starting with + + Bugzilla 2.18 and Bugzilla 2.16.5).
-
+
Some users are constantly being forced to relogin First, make sure cookies are enabled in the user's browser. @@ -227,7 +277,8 @@ TEST-OK Webserver is preventing fetch of http://landfill.bugzilla.org/bugzilla-t log in again. - If you are using 2.18 (or later), there is a + If you are using 2.18 + , there is a parameter called loginnetmask, which you can use to set the number of bits of the user's IP address to require to be matched when authenticating the cookies. If you set this to something less than 32, @@ -242,46 +293,6 @@ TEST-OK Webserver is preventing fetch of http://landfill.bugzilla.org/bugzilla-t
-
- <filename>index.cgi</filename> doesn't show up unless specified in the URL - - You probably need to set up your web server in such a way that it - will serve the index.cgi page as an index page. - - - If you are using Apache, you can do this by adding - index.cgi to the end of the - DirectoryIndex line - as mentioned in . - - -
- -
- - checksetup.pl reports "Client does not support authentication protocol - requested by server..." - - - - This error is occurring because you are using the new password - encryption that comes with MySQL 4.1, while your - DBD::mysql module was compiled against an - older version of MySQL. If you recompile DBD::mysql - against the current MySQL libraries (or just obtain a newer version - of this module) then the error may go away. - - - - If that does not fix the problem, or if you cannot recompile the - existing module (e.g. you're running Windows) and/or don't want to - replace it (e.g. you want to keep using a packaged version), then a - workaround is available from the MySQL docs: - - - -
-