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