Skip to content

bugzilla
bugzilla
Commit c88af85f authored by jake%bugzilla.org's avatar jake%bugzilla.org
Browse files
Options

Bug 271360 - Moving the Troubleshooting section into an appendix instead. Also,…

Bug 271360 - Moving the Troubleshooting section into an appendix instead. Also, moved a few items out of the FAQ and into this new appendix.
parent 30165fd1
Expand all Show whitespace changes
Inline Side-by-side
Showing with 13 additions and 316 deletions
docs/xml/Bugzilla-Guide.xml
View file @ c88af85f
......@@ -14,6 +14,7 @@
<!ENTITY integration SYSTEM "integration.xml">
<!ENTITY index SYSTEM "index.xml">
<!ENTITY customization SYSTEM "customization.xml">
<!ENTITY troubleshooting SYSTEM "troubleshooting.xml">
<!ENTITY patches SYSTEM "patches.xml">
<!ENTITY introduction SYSTEM "introduction.xml">
<!ENTITY modules SYSTEM "modules.xml">
......@@ -156,6 +157,9 @@
<!-- Appendix: The Frequently Asked Questions -->
&faq;
<!-- Appendix: Troubleshooting -->
&troubleshooting;
<!-- Appendix: Custom Patches -->
&patches;
......@@ -194,3 +198,4 @@ sgml-shorttag:t
sgml-tag-region-if-active:t
End:
-->
docs/xml/faq.xml
View file @ c88af85f
......@@ -584,129 +584,6 @@ perl -pi -e 's@#\!/usr/bin/perl@#\!/usr/local/bin/perl@' *cgi *pl
</answer>
</qandaentry>
<qandaentry>
<question id="faq-phb-reloginEveryone">
<para>
Why do users have to log in every time they access a page? This
affects everyone who accesses my Bugzilla. (If this only affects
some of your users, see the next FAQ item.)
</para>
</question>
<answer>
<para>
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.
</para>
<para>
The value of the cookiepath parameter should be the actual directory
containing your Bugzilla installation, <emphasis>as seen by the
end-user's web browser</emphasis>. 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.
</para>
<para>
How do you know if you want your specific Bugzilla directory or the
whole site?
</para>
<para>
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.
</para>
<para>
Examples:
<blockquote>
<literallayout>
urlbase is <ulink url="http://bugzilla.mozilla.org/"/>
cookiepath is /
urlbase is <ulink url="http://tools.mysite.tld/bugzilla/"/>
but you have http://tools.mysite.tld/someotherapp/ which shares
authentication with your Bugzilla
cookiepath is /
</literallayout>
</blockquote>
</para>
<para>
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.
</para>
<para>
Examples:
<blockquote>
<literallayout>
urlbase is <ulink url="http://landfill.bugzilla.org/bugzilla-tip/"/>
cookiepath is /bugzilla-tip/
urlbase is <ulink url="http://landfill.bugzilla.org/bugzilla-2.16-branch/"/>
cookiepath is /bugzilla-2.16-branch/
</literallayout>
</blockquote>
</para>
<para>
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.17.7 and Bugzilla 2.16.5).
</para>
</answer>
</qandaentry>
<qandaentry>
<question id="faq-phb-reloginSome">
<para>
Why do users have to log in every time they access a page? This
only seems to affect some of my Bugzilla's users, others stay
logged in.
</para>
</question>
<answer>
<para>
First, make sure cookies are enabled in the user's browser.
</para>
<para>
If that doesn't fix the problem, it may be that
the user's ISP implements a rotating proxy server. This causes
the user's effective IP address (the address which the Bugzilla server
perceives him coming from) to change periodically. Since
Bugzilla cookies are tied to a specific IP address, each time
the effective address changes, the user will have to log in again.
</para>
<para>
In newer versions of Bugzilla (2.17.1 and later) 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, then the user will be given a checkbox for "Restrict this
login to my IP address" on the login screen, which defaults to
checked. If they leave the box checked, Bugzilla will behave the
same as it did before, requiring an exact match on their IP address
to remain logged in. If they uncheck the box, then only the left
side of their IP address (up to the number of bits you specified in
the parameter) has to match to remain logged in.
</para>
</answer>
</qandaentry>
</qandadiv>
<qandadiv id="faq-security">
......@@ -719,12 +596,19 @@ perl -pi -e 's@#\!/usr/bin/perl@#\!/usr/local/bin/perl@' *cgi *pl
(I've followed the instructions in the installation section of this guide)?
</para>
</question>
<!-- Should we really even answer this question? -->
<answer>
<para>
Run MySQL like this: "mysqld --skip-grant-tables". Please remember <emphasis>this
makes MySQL as secure as taping a $100 to the floor of a football stadium
bathroom for safekeeping.</emphasis>
</para>
<warning>
<para>This can't be stressed enough. Doing this is a bad idea.
Please consult <xref linkend="security-mysql"/> of this guide and
the MySQL documentation for better solutions.
</para>
</warning>
</answer>
</qandaentry>
......
docs/xml/installation.xml
View file @ c88af85f
<!-- <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"> -->
<!-- $Id: installation.xml,v 1.82 2004/12/02 04:21:27 jake%bugzilla.org Exp $ -->
<!-- $Id: installation.xml,v 1.83 2004/12/07 11:41:59 jake%bugzilla.org Exp $ -->
<chapter id="installing-bugzilla">
<title>Installing Bugzilla</title>
......@@ -1738,198 +1738,6 @@ pid-file=/home/foo/mymysql/the.pid
</section>
</section>
<section id="troubleshooting">
<title>Troubleshooting</title>
<para>This section gives solutions to common Bugzilla installation
problems. If none of the section headings seems to match your
problem, read the general advice.
</para>
<section id="general-advice">
<title>General Advice</title>
<para>
If you can't get <filename>checksetup.pl</filename> 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
<ulink url="news://news.mozilla.org/netscape.public.mozilla.webtools">netscape.public.mozilla.webtools</ulink>
newsgroup.
</para>
<para>
If you have made it all the way through
<xref linkend="installation"/> (Installation) and
<xref linkend="configuration"/> (Configuration) but
accessing the Bugzilla URL doesn't work,
the first thing to do is to check your webserver error log. For
Apache, this is often located at
<filename>/etc/logs/httpd/error_log</filename>. 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.
</para>
</section>
<section>
<title>The Apache webserver is not serving Bugzilla pages</title>
<para>
After you have run <command>checksetup.pl</command> twice,
run <command>testserver.pl http://yoursite.yourdomain/yoururl</command>
to confirm that your webserver is configured properly for
Bugzilla.
</para>
<programlisting><![CDATA[./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.
]]></programlisting>
</section>
<section>
<title>I installed a Perl module, but
<filename>checksetup.pl</filename> claims it's not installed!</title>
<para>
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 <filename>checksetup.pl</filename>. This will make sure you
are installing the modules in the right place.
</para>
</section>
<section>
<title>Bundle::Bugzilla makes me upgrade to Perl 5.6.1</title>
<para>
Try executing <command>perl -MCPAN -e 'install CPAN'</command>
and then continuing.
</para>
<para>
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.
</para>
</section>
<section>
<title>DBD::Sponge::db prepare failed</title>
<para>
The following error message may appear due to a bug in DBD::mysql
(over which the Bugzilla team have no control):
</para>
<programlisting><![CDATA[ DBD::Sponge::db prepare failed: Cannot determine NUM_OF_FIELDS at D:/Perl/site/lib/DBD/mysql.pm line 248.
SV = NULL(0x0) at 0x20fc444
REFCNT = 1
FLAGS = (PADBUSY,PADMY)
]]></programlisting>
<para>
To fix this, go to
<filename>&lt;path-to-perl&gt;/lib/DBD/sponge.pm</filename>
in your Perl installation and replace
</para>
<programlisting><![CDATA[ my $numFields;
if ($attribs->{'NUM_OF_FIELDS'}) {
$numFields = $attribs->{'NUM_OF_FIELDS'};
} elsif ($attribs->{'NAME'}) {
$numFields = @{$attribs->{NAME}};
]]></programlisting>
<para>
by
</para>
<programlisting><![CDATA[ my $numFields;
if ($attribs->{'NUM_OF_FIELDS'}) {
$numFields = $attribs->{'NUM_OF_FIELDS'};
} elsif ($attribs->{'NAMES'}) {
$numFields = @{$attribs->{NAMES}};
]]></programlisting>
<para>
(note the S added to NAME.)
</para>
</section>
<section id="paranoid-security">
<title>cannot chdir(/var/spool/mqueue)</title>
<para>If you are installing Bugzilla on SuSE Linux, or some other
distributions with
<quote>paranoid</quote>
security options, it is possible that the checksetup.pl script may fail
with the error:
<programlisting><![CDATA[cannot chdir(/var/spool/mqueue): Permission denied
]]></programlisting>
</para>
<para>
This is because your
<filename>/var/spool/mqueue</filename>
directory has a mode of
<quote>drwx------</quote>. Type
<command>chmod 755
<filename>/var/spool/mqueue</filename>
</command>
as root to fix this problem.
</para>
</section>
<section id="trouble-filetemp">
<title>Your vendor has not defined Fcntl macro O_NOINHERIT</title>
<para>This is caused by a bug in the version of
<productname>File::Temp</productname> that is distributed with perl
5.6.0. Many minor variations of this error have been reported:
</para>
<programlisting>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.</programlisting>
<para>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 <ulink url="../xml/filetemp.patch">patch file</ulink>.
</para>
<programlisting><![CDATA[--- File/Temp.pm.orig Thu Feb 6 16:26:00 2003
+++ File/Temp.pm Thu Feb 6 16:26:23 2003
@@ -205,6 +205,7 @@
# eg CGI::Carp
local $SIG{__DIE__} = sub {};
local $SIG{__WARN__} = sub {};
+ local *CORE::GLOBAL::die = sub {};
$bit = &$func();
1;
};
@@ -226,6 +227,7 @@
# eg CGI::Carp
local $SIG{__DIE__} = sub {};
local $SIG{__WARN__} = sub {};
+ local *CORE::GLOBAL::die = sub {};
$bit = &$func();
1;
};]]></programlisting>
</section>
</section>
</chapter>
<!-- Keep this comment at the end of the file
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment