summaryrefslogtreecommitdiffstats
path: root/docs/html/postinstall-check.html
diff options
context:
space:
mode:
authorgerv%gerv.net <>2002-07-28 07:00:17 +0200
committergerv%gerv.net <>2002-07-28 07:00:17 +0200
commitd8caf6045d10344c431918128e3803ca497565f3 (patch)
tree1b2fbc50e442b6413a4ef0949e8ff7eed1df1361 /docs/html/postinstall-check.html
parenta9bb18746686c1bf5497e27f7ac2e12d0e3fc31a (diff)
downloadbugzilla-d8caf6045d10344c431918128e3803ca497565f3.tar.gz
bugzilla-d8caf6045d10344c431918128e3803ca497565f3.tar.xz
Merging new docs from 2.16 branch.
Diffstat (limited to 'docs/html/postinstall-check.html')
-rw-r--r--docs/html/postinstall-check.html565
1 files changed, 0 insertions, 565 deletions
diff --git a/docs/html/postinstall-check.html b/docs/html/postinstall-check.html
deleted file mode 100644
index f6a2e9310..000000000
--- a/docs/html/postinstall-check.html
+++ /dev/null
@@ -1,565 +0,0 @@
-<HTML
-><HEAD
-><TITLE
->Post-Installation Checklist</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
-"><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
-SUMMARY="Header navigation 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"
-ACCESSKEY="P"
->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"
-ACCESSKEY="N"
->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</H1
-><P
->&#13; 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
->&#13; 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
->&#13; 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
->&#13; 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
->&#13; 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
->&#13; <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
->&#13; 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
->&#13; 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
->&#13; 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
->&#13; 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
->&#13; 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
->&#13; 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
->&#13; 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
->&#13; 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
->&#13; 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
->&#13; 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
->&#13; 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
->&#13; 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 privileges. 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
->&#13; 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
-SUMMARY="Footer navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="administration.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="index.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="useradmin.html"
-ACCESSKEY="N"
->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"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->User Administration</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
-> \ No newline at end of file