diff options
Diffstat (limited to 'docs/html/postinstall-check.html')
| -rw-r--r-- | docs/html/postinstall-check.html | 318 |
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 |