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.html318
1 files changed, 0 insertions, 318 deletions
diff --git a/docs/html/postinstall-check.html b/docs/html/postinstall-check.html
deleted file mode 100644
index 2ab4a39ce..000000000
--- a/docs/html/postinstall-check.html
+++ /dev/null
@@ -1,318 +0,0 @@
-<HTML
-><HEAD
-><TITLE
->Post-Installation Checklist</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.64
-"><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 3. 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"
->3.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 "1" <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 "1" 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"
-><BLOCKQUOTE
-CLASS="NOTE"
-><P
-><B
->Note: </B
-> 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
-></BLOCKQUOTE
-></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"
-><BLOCKQUOTE
-CLASS="NOTE"
-><P
-><B
->Note: </B
-> 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
-></BLOCKQUOTE
-></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 README, 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"
-><BLOCKQUOTE
-CLASS="NOTE"
-><P
-><B
->Note: </B
-> 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
-></BLOCKQUOTE
-></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