305a7218e6
known outstanding doc bug! Yay release. Still many things to fix. Aren't there always? git-svn-id: svn://10.0.0.236/trunk@101604 18797224-902f-48f8-a5cc-f745e15eee43
559 lines
13 KiB
HTML
559 lines
13 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Post-Installation Checklist</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.61
|
|
"><LINK
|
|
REL="HOME"
|
|
TITLE="The Bugzilla Guide"
|
|
HREF="index.html"><LINK
|
|
REL="UP"
|
|
TITLE="Administering Bugzilla"
|
|
HREF="administration.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Administering Bugzilla"
|
|
HREF="administration.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="User Administration"
|
|
HREF="useradmin.html"></HEAD
|
|
><BODY
|
|
CLASS="SECTION"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>The Bugzilla Guide</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="administration.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
>Chapter 4. Administering Bugzilla</TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="useradmin.html"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECTION"
|
|
><H1
|
|
CLASS="SECTION"
|
|
><A
|
|
NAME="POSTINSTALL-CHECK"
|
|
>4.1. Post-Installation Checklist</A
|
|
></H1
|
|
><P
|
|
> After installation, follow the checklist below to help ensure
|
|
that you have a successful installation. If you do not see a
|
|
recommended setting for a parameter, consider leaving it at the
|
|
default while you perform your initial tests on your Bugzilla
|
|
setup.
|
|
</P
|
|
><DIV
|
|
CLASS="PROCEDURE"
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> Bring up <TT
|
|
CLASS="FILENAME"
|
|
>editparams.cgi</TT
|
|
> in your web
|
|
browser. This should be available as the <SPAN
|
|
CLASS="QUOTE"
|
|
>"edit
|
|
parameters"</SPAN
|
|
> link from any Bugzilla screen once you
|
|
have logged in.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>The <SPAN
|
|
CLASS="QUOTE"
|
|
>"maintainer"</SPAN
|
|
> is the email address of
|
|
the person responsible for maintaining this Bugzilla
|
|
installation. The maintainer need not be a valid Bugzilla
|
|
user. Error pages, error emails, and administrative mail
|
|
will be sent with the maintainer as the return email
|
|
address.</P
|
|
><P
|
|
> Set <SPAN
|
|
CLASS="QUOTE"
|
|
>"maintainer"</SPAN
|
|
> to <EM
|
|
>your</EM
|
|
> email address.
|
|
This allows Bugzilla's error messages to display your email
|
|
address and allow people to contact you for help.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>The <SPAN
|
|
CLASS="QUOTE"
|
|
>"urlbase"</SPAN
|
|
> parameter defines the fully
|
|
qualified domain name and web server path to your Bugzilla
|
|
installation.</P
|
|
><P
|
|
> For example, if your bugzilla query page is
|
|
http://www.foo.com/bugzilla/query.cgi, set your
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"urlbase"</SPAN
|
|
> is http://www.foo.com/bugzilla/.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><SPAN
|
|
CLASS="QUOTE"
|
|
>"usebuggroups"</SPAN
|
|
> dictates whether or not to
|
|
implement group-based security for Bugzilla. If set,
|
|
Bugzilla bugs can have an associated groupmask defining
|
|
which groups of users are allowed to see and edit the
|
|
bug.</P
|
|
><P
|
|
> Set "usebuggroups" to "on" <EM
|
|
>only</EM
|
|
> if you
|
|
may wish to restrict access to products. I suggest leaving
|
|
this parameter <EM
|
|
>off</EM
|
|
> while initially
|
|
testing your Bugzilla.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <SPAN
|
|
CLASS="QUOTE"
|
|
>"usebuggroupsentry"</SPAN
|
|
>, when set to
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"on"</SPAN
|
|
>, requires that all bugs have an associated
|
|
groupmask when submitted. This parameter is made for those
|
|
installations where product isolation is a necessity.
|
|
</P
|
|
><P
|
|
> Set "usebuggroupsentry" to "on" if you absolutely need to
|
|
restrict access to bugs from the moment they are submitted
|
|
through resolution. Once again, if you are simply testing
|
|
your installation, I suggest against turning this parameter
|
|
on; the strict security checking may stop you from being
|
|
able to modify your new entries.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> You run into an interesting problem when Bugzilla reaches a
|
|
high level of continuous activity. MySQL supports only
|
|
table-level write locking. What this means is that if
|
|
someone needs to make a change to a bug, they will lock the
|
|
entire table until the operation is complete. Locking for
|
|
write also blocks reads until the write is complete. The
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"shadowdb"</SPAN
|
|
> parameter was designed to get around
|
|
this limitation. While only a single user is allowed to
|
|
write to a table at a time, reads can continue unimpeded on
|
|
a read-only shadow copy of the database. Although your
|
|
database size will double, a shadow database can cause an
|
|
enormous performance improvement when implemented on
|
|
extremely high-traffic Bugzilla databases.
|
|
</P
|
|
><P
|
|
> Set "shadowdb" to "bug_shadowdb" if you will be running a
|
|
*very* large installation of Bugzilla. The shadow database
|
|
enables many simultaneous users to read and write to the
|
|
database without interfering with one another.
|
|
<DIV
|
|
CLASS="NOTE"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="NOTE"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> Enabling "shadowdb" can adversely affect the stability
|
|
of your installation of Bugzilla. You should regularly
|
|
check that your database is in sync. It is often
|
|
advisable to force a shadow database sync nightly via
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"cron"</SPAN
|
|
>.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
> Once again, in testing you should avoid this option
|
|
-- use it if or when you <EM
|
|
>need</EM
|
|
> to use
|
|
it, and have repeatedly run into the problem it was designed
|
|
to solve -- very long wait times while attempting to commit
|
|
a change to the database. Mozilla.org began needing
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"shadowdb"</SPAN
|
|
> when they reached around 40,000
|
|
Bugzilla users with several hundred Bugzilla bug changes and
|
|
comments per day.
|
|
</P
|
|
><P
|
|
> If you use the "shadowdb" option, it is only natural that
|
|
you should turn the "queryagainstshadowdb" option "On" as
|
|
well. Otherwise you are replicating data into a shadow
|
|
database for no reason!
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><SPAN
|
|
CLASS="QUOTE"
|
|
>"headerhtml"</SPAN
|
|
>, <SPAN
|
|
CLASS="QUOTE"
|
|
>"footerhtml"</SPAN
|
|
>,
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"errorhtml"</SPAN
|
|
>, <SPAN
|
|
CLASS="QUOTE"
|
|
>"bannerhtml"</SPAN
|
|
>, and
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"blurbhtml"</SPAN
|
|
> are all templates which control
|
|
display of headers, footers, errors, banners, and additional
|
|
data. We could go into some detail regarding the usage of
|
|
these, but it is really best just to monkey around with them
|
|
a bit to see what they do. I strongly recommend you copy
|
|
your <TT
|
|
CLASS="FILENAME"
|
|
>data/params</TT
|
|
> file somewhere safe
|
|
before playing with these values, though. If they are
|
|
changed dramatically, it may make it impossible for you to
|
|
display Bugzilla pages to fix the problem until you have
|
|
restored your <TT
|
|
CLASS="FILENAME"
|
|
>data/params</TT
|
|
> file.</P
|
|
><P
|
|
> If you have custom logos or HTML you must put in place to
|
|
fit within your site design guidelines, place the code in
|
|
the "headerhtml", "footerhtml", "errorhtml", "bannerhtml",
|
|
or "blurbhtml" text boxes.
|
|
<DIV
|
|
CLASS="NOTE"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="NOTE"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> The "headerhtml" text box is the HTML printed out
|
|
<EM
|
|
>before</EM
|
|
> any other code on the page,
|
|
except the CONTENT-TYPE header sent by the Bugzilla
|
|
engine. If you have a special banner, put the code for
|
|
it in "bannerhtml". You may want to leave these settings
|
|
at the defaults initially.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><SPAN
|
|
CLASS="QUOTE"
|
|
>"passwordmail"</SPAN
|
|
> is rather simple. Every
|
|
time a user creates an account, the text of this parameter
|
|
is read as the text to send to the new user along with their
|
|
password message.</P
|
|
><P
|
|
> Add any text you wish to the "passwordmail" parameter box.
|
|
For instance, many people choose to use this box to give a
|
|
quick training blurb about how to use Bugzilla at your site.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><SPAN
|
|
CLASS="QUOTE"
|
|
>"useqacontact"</SPAN
|
|
> allows you to define an
|
|
email address for each component, in addition to that of the
|
|
default owner, who will be sent carbon copies of incoming
|
|
bugs. The critical difference between a QA Contact and an
|
|
Owner is that the QA Contact follows the component. If you
|
|
reassign a bug from component A to component B, the QA
|
|
Contact for that bug will change with the reassignment,
|
|
regardless of owner.</P
|
|
><P
|
|
><SPAN
|
|
CLASS="QUOTE"
|
|
>"usestatuswhiteboard"</SPAN
|
|
> defines whether you
|
|
wish to have a free-form, overwritable field associated with
|
|
each bug. The advantage of the Status Whiteboard is that it
|
|
can be deleted or modified with ease, and provides an
|
|
easily-searchable field for indexing some bugs that have
|
|
some trait in common. Many people will put <SPAN
|
|
CLASS="QUOTE"
|
|
>"help
|
|
wanted"</SPAN
|
|
>, <SPAN
|
|
CLASS="QUOTE"
|
|
>"stalled"</SPAN
|
|
>, or <SPAN
|
|
CLASS="QUOTE"
|
|
>"waiting
|
|
on reply from somebody"</SPAN
|
|
> messages into the Status
|
|
Whiteboard field so those who peruse the bugs are aware of
|
|
their status even more than that which can be indicated by
|
|
the Resolution fields.</P
|
|
><P
|
|
> Do you want to use the QA Contact ("useqacontact") and
|
|
status whiteboard ("usestatuswhiteboard") fields? These
|
|
fields are useful because they allow for more flexibility,
|
|
particularly when you have an existing Quality Assurance
|
|
and/or Release Engineering team, but they may not be needed
|
|
for many smaller installations.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Set "whinedays" to the amount of days you want to let bugs
|
|
go in the "New" or "Reopened" state before notifying people
|
|
they have untouched new bugs. If you do not plan to use
|
|
this feature, simply do not set up the whining cron job
|
|
described in the installation instructions, or set this
|
|
value to "0" (never whine).
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><SPAN
|
|
CLASS="QUOTE"
|
|
>"commenton"</SPAN
|
|
> fields allow you to dictate
|
|
what changes can pass without comment, and which must have a
|
|
comment from the person who changed them. Often,
|
|
administrators will allow users to add themselves to the CC
|
|
list, accept bugs, or change the Status Whiteboard without
|
|
adding a comment as to their reasons for the change, yet
|
|
require that most other changes come with an
|
|
explanation.</P
|
|
><P
|
|
> Set the "commenton" options according to your site policy.
|
|
It is a wise idea to require comments when users resolve,
|
|
reassign, or reopen bugs at the very least.
|
|
<DIV
|
|
CLASS="NOTE"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="NOTE"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
> It is generally far better to require a developer
|
|
comment when resolving bugs than not. Few things are
|
|
more annoying to bug database users than having a
|
|
developer mark a bug "fixed" without any comment as to
|
|
what the fix was (or even that it was truly fixed!)
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>The <SPAN
|
|
CLASS="QUOTE"
|
|
>"supportwatchers"</SPAN
|
|
> option can be an
|
|
exceptionally powerful tool in the hands of a power Bugzilla
|
|
user. By enabling this option, you allow users to receive
|
|
email updates whenever other users receive email updates.
|
|
This is, of course, subject to the groupset restrictions on
|
|
the bug; if the <SPAN
|
|
CLASS="QUOTE"
|
|
>"watcher"</SPAN
|
|
> would not normally be
|
|
allowed to view a bug, the watcher cannot get around the
|
|
system by setting herself up to watch the bugs of someone
|
|
with bugs outside her priveleges. She would still only
|
|
receive email updates for those bugs she could normally
|
|
view.</P
|
|
><P
|
|
>For Bugzilla sites which require strong inter-Product
|
|
security to prevent snooping, watchers are not a good
|
|
idea.</P
|
|
><P
|
|
> However, for most sites you should set
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"supportwatchers"</SPAN
|
|
> to "On". This feature is
|
|
helpful for team leads to monitor progress in their
|
|
respective areas, and can offer many other benefits, such as
|
|
allowing a developer to pick up a former engineer's bugs
|
|
without requiring her to change all the information in the
|
|
bug.
|
|
</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="administration.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="useradmin.html"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Administering Bugzilla</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="administration.html"
|
|
>Up</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>User Administration</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |