summaryrefslogtreecommitdiffstats
path: root/docs/html/postinstall-check.html
diff options
context:
space:
mode:
Diffstat (limited to 'docs/html/postinstall-check.html')
-rw-r--r--docs/html/postinstall-check.html375
1 files changed, 375 insertions, 0 deletions
diff --git a/docs/html/postinstall-check.html b/docs/html/postinstall-check.html
new file mode 100644
index 000000000..9a1f52c36
--- /dev/null
+++ b/docs/html/postinstall-check.html
@@ -0,0 +1,375 @@
+<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 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 "editparams.cgi" in your web browser. For
+ instance, to edit parameters at mozilla.org, the URL would
+ be <A
+HREF="http://bugzilla.mozilla.org/editparams.cgi"
+TARGET="_top"
+> http://bugzilla.mozilla.org/editparams.cgi</A
+>, also
+ available under the "edit parameters" link on your query
+ page.
+ </P
+></LI
+><LI
+><P
+> Set "maintainer" 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
+> Set "urlbase" to the URL reference for your Bugzilla
+ installation. If your bugzilla query page is at
+ http://www.foo.com/bugzilla/query.cgi, your url base is
+ http://www.foo.com/bugzilla/
+ </P
+></LI
+><LI
+><P
+> Set "usebuggroups" to "on" <EM
+>only</EM
+> if you
+ need to restrict access to products. I suggest leaving this
+ parameter <EM
+>off</EM
+> while initially testing
+ your Bugzilla.
+ </P
+></LI
+><LI
+><P
+> Set "usebuggroupsentry" to "on" if you want to restrict
+ access to products. 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
+> 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 may frequently
+ need to manually synchronize your databases, or schedule
+ nightly syncs via "cron"
+ </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.
+ </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
+> 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.
+ 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
+> 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
+> Ensure "newemailtech" is "on". Your users will thank you.
+ This is the default in the post-2.12 world, and is only an
+ issue if you are upgrading.
+ </P
+></LI
+><LI
+><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 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".
+ </P
+></LI
+><LI
+><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.
+ <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
+> Set "supportwatchers" 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
+> \ No newline at end of file