From 4105a4885d093295c71dd5d08e160b3e6cc7ee0f Mon Sep 17 00:00:00 2001 From: Gervase Markham Date: Fri, 17 Jan 2014 10:15:14 +0000 Subject: Bug 912064 - convert docs to ReStructured Text (.rst) format. r,a=justdave. --- docs/en/xml/troubleshooting.xml | 287 ---------------------------------------- 1 file changed, 287 deletions(-) delete mode 100644 docs/en/xml/troubleshooting.xml (limited to 'docs/en/xml/troubleshooting.xml') diff --git a/docs/en/xml/troubleshooting.xml b/docs/en/xml/troubleshooting.xml deleted file mode 100644 index 7dcf75238..000000000 --- a/docs/en/xml/troubleshooting.xml +++ /dev/null @@ -1,287 +0,0 @@ - - - - %myents; -]> - - -Troubleshooting - - This section gives solutions to common Bugzilla installation - problems. If none of the section headings seems to match your - problem, read the general advice. - - -
- General Advice - If you can't get checksetup.pl to run to - 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 - 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 - 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 - After you have run checksetup.pl twice, - run testserver.pl http://yoursite.yourdomain/yoururl - to confirm that your web server is configured properly for - Bugzilla. - - -bash$ ./testserver.pl http://landfill.bugzilla.org/bugzilla-tip -TEST-OK Webserver is running under group id in $webservergroup. -TEST-OK Got ant picture. -TEST-OK Webserver is executing CGIs. -TEST-OK Webserver is preventing fetch of http://landfill.bugzilla.org/bugzilla-tip/localconfig. - -
- -
- I installed a Perl module, but - <filename>checksetup.pl</filename> claims it's not installed! - - This could be caused by one of two things: - - - You have two versions of Perl on your machine. You are installing - modules into one, and Bugzilla is using the other. Rerun the CPAN - commands (or manual compile) using the full path to Perl from the - top of checksetup.pl. This will make sure you - are installing the modules in the right place. - - - - 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. - - - -
- -
- DBD::Sponge::db prepare failed - - The following error message may appear due to a bug in DBD::mysql - (over which the Bugzilla team have no control): - - - - - To fix this, go to - <path-to-perl>/lib/DBD/sponge.pm - in your Perl installation and replace - - -{'NUM_OF_FIELDS'}) { - $numFields = $attribs->{'NUM_OF_FIELDS'}; - } elsif ($attribs->{'NAME'}) { - $numFields = @{$attribs->{NAME}}; -]]> - - with - -{'NUM_OF_FIELDS'}) { - $numFields = $attribs->{'NUM_OF_FIELDS'}; - } elsif ($attribs->{'NAMES'}) { - $numFields = @{$attribs->{NAMES}}; -]]> - - (note the S added to NAME.) -
- -
- cannot chdir(/var/spool/mqueue) - - If you are installing Bugzilla on SuSE Linux, or some other - distributions with paranoid security options, it is - possible that the checksetup.pl script may fail with the error: - - - - This is because your /var/spool/mqueue - directory has a mode of drwx------. - Type chmod 755 /var/spool/mqueue - as root to fix this problem. This will allow any process running on your - machine the ability to read the - /var/spool/mqueue directory. - -
- -
- 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. - - - The value of the cookiepath parameter should be the actual directory - containing your Bugzilla installation, as seen by the end-user's - web browser. Leading and trailing slashes are mandatory. You can - also set the cookiepath to any directory which is a parent of the Bugzilla - directory (such as '/', the root directory). But you can't put something - that isn't at least a partial match or it won't work. What you're actually - doing is restricting the end-user's browser to sending the cookies back only - to that directory. - - - How do you know if you want your specific Bugzilla directory or the - whole site? - - - If you have only one Bugzilla running on the server, and you don't - mind having other applications on the same server with it being able to see - the cookies (you might be doing this on purpose if you have other things on - your site that share authentication with Bugzilla), then you'll want to have - the cookiepath set to "/", or to a sufficiently-high enough directory that - all of the involved apps can see the cookies. - - - - Examples of urlbase/cookiepath pairs for sharing login cookies - -
- -urlbase is http://bugzilla.mozilla.org/ -cookiepath is / - -urlbase is http://tools.mysite.tld/bugzilla/ - but you have http://tools.mysite.tld/someotherapp/ which shares - authentication with your Bugzilla -cookiepath is / - -
- - - On the other hand, if you have more than one Bugzilla running on the - server (some people do - we do on landfill) then you need to have the - cookiepath restricted enough so that the different Bugzillas don't - confuse their cookies with one another. - - - - - Examples of urlbase/cookiepath pairs to restrict the login cookie -
- -urlbase is http://landfill.bugzilla.org/bugzilla-tip/ -cookiepath is /bugzilla-tip/ - -urlbase is http://landfill.bugzilla.org/bugzilla-4.0-branch/ -cookiepath is /bugzilla-4.0-branch/ - -
- - - If you had cookiepath set to / at any point in the - 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). - -
- -
- <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: - - - -
- - - - -- cgit v1.2.3-24-g4f1b