зеркало из https://github.com/mozilla/pjs.git
1389 строки
56 KiB
XML
1389 строки
56 KiB
XML
<!-- <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook V4.1//EN"> -->
|
|
<chapter id="administration">
|
|
<title>Administering Bugzilla</title>
|
|
|
|
<subtitle>Or, I just got this cool thing installed. Now what the heck do I
|
|
do with it?</subtitle>
|
|
|
|
<para>So you followed
|
|
<quote>
|
|
<xref linkend="installation" />
|
|
</quote>
|
|
|
|
to the letter, and logged into Bugzilla for the very first time with your
|
|
super-duper god account. You sit, contentedly staring at the Bugzilla Query
|
|
Screen, the worst of the whole mad business of installing this terrific
|
|
program behind you. It seems, though, you have nothing yet to query! Your
|
|
first act of business should be to setup the operating parameters for
|
|
Bugzilla so you can get busy getting data into your bug tracker.</para>
|
|
|
|
<section id="postinstall-check">
|
|
<title>Post-Installation Checklist</title>
|
|
|
|
<para>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.</para>
|
|
|
|
<indexterm>
|
|
<primary>checklist</primary>
|
|
</indexterm>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>Bring up
|
|
<filename>editparams.cgi</filename>
|
|
|
|
in your web browser. This should be available as the
|
|
<quote>edit parameters</quote>
|
|
|
|
link from any Bugzilla screen once you have logged in.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>The
|
|
<quote>maintainer</quote>
|
|
|
|
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.</para>
|
|
|
|
<para>Set
|
|
<quote>maintainer</quote>
|
|
|
|
to
|
|
<emphasis>your</emphasis>
|
|
|
|
email address. This allows Bugzilla's error messages to display your
|
|
email address and allow people to contact you for help.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>The
|
|
<quote>urlbase</quote>
|
|
|
|
parameter defines the fully qualified domain name and web server path
|
|
to your Bugzilla installation.</para>
|
|
|
|
<para>For example, if your bugzilla query page is
|
|
http://www.foo.com/bugzilla/query.cgi, set your
|
|
<quote>urlbase</quote>
|
|
|
|
is http://www.foo.com/bugzilla/.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
<quote>usebuggroups</quote>
|
|
|
|
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.</para>
|
|
|
|
<para>Set "usebuggroups" to "on"
|
|
<emphasis>only</emphasis>
|
|
|
|
if you may wish to restrict access to products. I suggest leaving
|
|
this parameter
|
|
<emphasis>off</emphasis>
|
|
|
|
while initially testing your Bugzilla.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
<quote>usebuggroupsentry</quote>
|
|
|
|
, when set to
|
|
<quote>on</quote>
|
|
|
|
, requires that all bugs have an associated groupmask when submitted.
|
|
This parameter is made for those installations where product
|
|
isolation is a necessity.</para>
|
|
|
|
<para>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.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>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
|
|
<quote>shadowdb</quote>
|
|
|
|
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.</para>
|
|
|
|
<para>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.
|
|
<note>
|
|
<para>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
|
|
<quote>cron</quote>
|
|
|
|
.</para>
|
|
</note>
|
|
|
|
Once again, in testing you should avoid this option -- use it if or
|
|
when you
|
|
<emphasis>need</emphasis>
|
|
|
|
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
|
|
<quote>shadowdb</quote>
|
|
|
|
when they reached around 40,000 Bugzilla users with several hundred
|
|
Bugzilla bug changes and comments per day.</para>
|
|
|
|
<para>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!</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
<quote>headerhtml</quote>
|
|
|
|
,
|
|
<quote>footerhtml</quote>
|
|
|
|
,
|
|
<quote>errorhtml</quote>
|
|
|
|
,
|
|
<quote>bannerhtml</quote>
|
|
|
|
, and
|
|
<quote>blurbhtml</quote>
|
|
|
|
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
|
|
<filename>data/params</filename>
|
|
|
|
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
|
|
<filename>data/params</filename>
|
|
|
|
file.</para>
|
|
|
|
<para>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.
|
|
<note>
|
|
<para>The "headerhtml" text box is the HTML printed out
|
|
<emphasis>before</emphasis>
|
|
|
|
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.</para>
|
|
</note>
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
<quote>passwordmail</quote>
|
|
|
|
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.</para>
|
|
|
|
<para>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.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
<quote>useqacontact</quote>
|
|
|
|
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.</para>
|
|
|
|
<para>
|
|
<quote>usestatuswhiteboard</quote>
|
|
|
|
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
|
|
<quote>help wanted</quote>
|
|
|
|
,
|
|
<quote>stalled</quote>
|
|
|
|
, or
|
|
<quote>waiting on reply from somebody</quote>
|
|
|
|
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.</para>
|
|
|
|
<para>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.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>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).</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>
|
|
<quote>commenton</quote>
|
|
|
|
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.</para>
|
|
|
|
<para>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.
|
|
<note>
|
|
<para>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!)</para>
|
|
</note>
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>The
|
|
<quote>supportwatchers</quote>
|
|
|
|
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
|
|
<quote>watcher</quote>
|
|
|
|
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.</para>
|
|
|
|
<para>For Bugzilla sites which require strong inter-Product security
|
|
to prevent snooping, watchers are not a good idea.</para>
|
|
|
|
<para>However, for most sites you should set
|
|
<quote>supportwatchers</quote>
|
|
|
|
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.</para>
|
|
</step>
|
|
</procedure>
|
|
</section>
|
|
|
|
<section id="useradmin">
|
|
<title>User Administration</title>
|
|
|
|
<para>User administration is one of the easiest parts of Bugzilla.
|
|
Keeping it from getting out of hand, however, can become a
|
|
challenge.</para>
|
|
|
|
<section id="defaultuser">
|
|
<title>Creating the Default User</title>
|
|
|
|
<para>When you first run checksetup.pl after installing Bugzilla, it
|
|
will prompt you for the administrative username (email address) and
|
|
password for this "super user". If for some reason you were to delete
|
|
the "super user" account, re-running checksetup.pl will again prompt
|
|
you for this username and password.</para>
|
|
|
|
<tip>
|
|
<para>If you wish to add more administrative users, you must use the
|
|
MySQL interface. Run "mysql" from the command line, and use these
|
|
commands ("mysql>" denotes the mysql prompt, not something you
|
|
should type in):
|
|
<command>
|
|
<prompt>mysql></prompt>
|
|
|
|
use bugs;</command>
|
|
|
|
<command>
|
|
<prompt>mysql></prompt>
|
|
|
|
update profiles set groupset=0x7ffffffffffffff where login_name =
|
|
"(user's login name)";</command>
|
|
</para>
|
|
|
|
<para>Yes, that is
|
|
<emphasis>fourteen</emphasis>
|
|
|
|
<quote>f</quote>
|
|
|
|
's. A whole lot of f-ing going on if you want to create a new
|
|
administator.</para>
|
|
</tip>
|
|
</section>
|
|
|
|
<section id="manageusers">
|
|
<title>Managing Other Users</title>
|
|
|
|
<section id="login">
|
|
<title>Logging In</title>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Open the index.html page for your Bugzilla installation in
|
|
your browser window.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Click the "Query Existing Bug Reports" link.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Click the "Log In" link at the foot of the page.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Type your email address, and the password which was emailed
|
|
to you when you created your Bugzilla account, into the spaces
|
|
provided.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Congratulations, you are logged in!</para>
|
|
</section>
|
|
|
|
<section id="createnewusers">
|
|
<title>Creating new users</title>
|
|
|
|
<para>Your users can create their own user accounts by clicking the
|
|
"New Account" link at the bottom of each page. However, should you
|
|
desire to create user accounts ahead of time, here is how you do
|
|
it.</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>After logging in, click the "Users" link at the footer of
|
|
the query page.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>To see a specific user, type a portion of their login name
|
|
in the box provided and click "submit". To see all users, simply
|
|
click the "submit" button. You must click "submit" here to be
|
|
able to add a new user.</para>
|
|
|
|
<tip>
|
|
<para>More functionality is available via the list on the
|
|
right-hand side of the text entry box. You can match what you
|
|
type as a case-insensitive substring (the default) of all users
|
|
on your system, a case-sensitive regular expression (please see
|
|
the
|
|
<command>man regexp</command>
|
|
|
|
manual page for details on regular expression syntax), or a
|
|
<emphasis>reverse</emphasis>
|
|
|
|
regular expression match, where every user name which does NOT
|
|
match the regular expression is selected.</para>
|
|
</tip>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Click the "Add New User" link at the bottom of the user
|
|
list</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Fill out the form presented. This page is self-explanatory.
|
|
When done, click "submit".</para>
|
|
|
|
<note>
|
|
<para>Adding a user this way will
|
|
<emphasis>not</emphasis>
|
|
|
|
send an email informing them of their username and password.
|
|
While useful for creating dummy accounts (watchers which
|
|
shuttle mail to another system, for instance, or email
|
|
addresses which are a mailing list), in general it is
|
|
preferable to log out and use the
|
|
<quote>New Account</quote>
|
|
|
|
button to create users, as it will pre-populate all the
|
|
required fields and also notify the user of her account name
|
|
and password.</para>
|
|
</note>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section id="disableusers">
|
|
<title>Disabling Users</title>
|
|
|
|
<para>I bet you noticed that big "Disabled Text" entry box available
|
|
from the "Add New User" screen, when you edit an account? By entering
|
|
any text in this box and selecting "submit", you have prevented the
|
|
user from using Bugzilla via the web interface. Your explanation,
|
|
written in this text box, will be presented to the user the next time
|
|
she attempts to use the system.
|
|
<warning>
|
|
<para>Don't disable your own administrative account, or you will
|
|
hate life!</para>
|
|
|
|
<para>At this time,
|
|
<quote>Disabled Text</quote>
|
|
|
|
does not prevent a user from using the email interface. If you have
|
|
the email interface enabled, they can still continue to submit bugs
|
|
and comments that way. We need a patch to fix this.</para>
|
|
</warning>
|
|
</para>
|
|
</section>
|
|
|
|
<section id="modifyusers">
|
|
<title>Modifying Users</title>
|
|
|
|
<para>Here I will attempt to describe the function of each option on
|
|
the Edit User screen.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Login Name</emphasis>
|
|
|
|
: This is generally the user's email address. However, if you
|
|
have edited your system parameters, this may just be the user's
|
|
login name or some other identifier.
|
|
<tip>
|
|
<para>For compatability reasons, you should probably stick with
|
|
email addresses as user login names. It will make your life
|
|
easier.</para>
|
|
</tip>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Real Name</emphasis>
|
|
|
|
: Duh!</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Password</emphasis>
|
|
|
|
: You can change the user password here. It is normal to only see
|
|
asterisks.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Disable Text</emphasis>
|
|
|
|
: If you type anything in this box, including just a space, the
|
|
user account is disabled from making any changes to bugs via the
|
|
web interface, and what you type in this box is presented as the
|
|
reason.
|
|
<warning>
|
|
<para>Don't disable the administrator account!</para>
|
|
</warning>
|
|
|
|
<note>
|
|
<para>As of this writing, the user can still submit bugs via
|
|
the e-mail gateway, if you set it up, despite the disabled text
|
|
field. The e-mail gateway should
|
|
<emphasis>not</emphasis>
|
|
|
|
be enabled for secure installations of Bugzilla.</para>
|
|
</note>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>CanConfirm</emphasis>
|
|
|
|
: This field is only used if you have enabled "unconfirmed"
|
|
status in your parameters screen. If you enable this for a user,
|
|
that user can then move bugs from "Unconfirmed" to "Confirmed"
|
|
status (e.g.: "New" status). Be judicious about allowing users to
|
|
turn this bit on for other users.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Creategroups</emphasis>
|
|
|
|
: This option will allow a user to create and destroy groups in
|
|
Bugzilla. Unless you are using the Bugzilla GroupSentry security
|
|
option "usebuggroupsentry" in your parameters, this setting has
|
|
no effect.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Editbugs</emphasis>
|
|
|
|
: Unless a user has this bit set, they can only edit those bugs
|
|
for which they are the assignee or the reporter.
|
|
<note>
|
|
<para>Leaving this option unchecked does not prevent users from
|
|
adding comments to a bug! They simply cannot change a bug
|
|
priority, severity, etc. unless they are the assignee or
|
|
reporter.</para>
|
|
</note>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Editcomponents</emphasis>
|
|
|
|
: This flag allows a user to create new products and components,
|
|
as well as modify and destroy those that have no bugs associated
|
|
with them. If a product or component has bugs associated with it,
|
|
those bugs must be moved to a different product or component
|
|
before Bugzilla will allow them to be destroyed. The name of a
|
|
product or component can be changed without affecting the
|
|
associated bugs, but it tends to annoy the hell out of your users
|
|
when these change a lot.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Editkeywords</emphasis>
|
|
|
|
: If you use Bugzilla's keyword functionality, enabling this
|
|
feature allows a user can create and destroy keywords. As always,
|
|
the keywords for existing bugs containing the keyword the user
|
|
wishes to destroy must be changed before Bugzilla will allow it
|
|
to die. You must be very careful about creating too many new
|
|
keywords if you run a very large Bugzilla installation; keywords
|
|
are global variables across products, and you can often run into
|
|
a phenomenon called "keyword bloat". This confuses users, and
|
|
then the feature goes unused.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Editusers</emphasis>
|
|
|
|
: This flag allows a user do what you're doing right now: edit
|
|
other users. This will allow those with the right to do so to
|
|
remove administrator privileges from other users or grant them to
|
|
themselves. Enable with care.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>PRODUCT</emphasis>
|
|
|
|
: PRODUCT bugs access. This allows an administrator, with
|
|
product-level granularity, to specify in which products a user
|
|
can edit bugs. The user must still have the "editbugs" privelege
|
|
to edit bugs in this area; this simply restricts them from even
|
|
seeing bugs outside these boundaries if the administrator has
|
|
enabled the group sentry parameter "usebuggroupsentry". Unless
|
|
you are using bug groups, this option has no effect.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="programadmin">
|
|
<title>Product, Component, Milestone, and Version Administration</title>
|
|
|
|
<epigraph>
|
|
<para>Dear Lord, we have to get our users to do WHAT?</para>
|
|
</epigraph>
|
|
|
|
<section id="products">
|
|
<title>Products</title>
|
|
|
|
<subtitle>Formerly, and in some spots still, called
|
|
"Programs"</subtitle>
|
|
|
|
<para>
|
|
<glossterm linkend="gloss-product" baseform="product">
|
|
Products</glossterm>
|
|
|
|
are the broadest category in Bugzilla, and you should have the least of
|
|
these. If your company makes computer games, you should have one
|
|
product per game, and possibly a few special products (website,
|
|
meetings...)</para>
|
|
|
|
<para>A Product (formerly called "Program", and still referred to that
|
|
way in some portions of the source code) controls some very important
|
|
functions. The number of "votes" available for users to vote for the
|
|
most important bugs is set per-product, as is the number of votes
|
|
required to move a bug automatically from the UNCONFIRMED status to the
|
|
NEW status. One can close a Product for further bug entry and define
|
|
various Versions available from the Edit product screen.</para>
|
|
|
|
<para>To create a new product:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Select "components" from the yellow footer</para>
|
|
|
|
<tip>
|
|
<para>It may seem counterintuitive to click "components" when you
|
|
want to edit the properties associated with Products. This is one
|
|
of a long list of things we want in Bugzilla 3.0...</para>
|
|
</tip>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Select the "Add" link to the right of "Add a new
|
|
product".</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Enter the name of the product and a description. The
|
|
Description field is free-form.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<tip>
|
|
<para>Don't worry about the "Closed for bug entry", "Maximum Votes
|
|
per person", "Maximum votes a person can put on a single bug",
|
|
"Number of votes a bug in this Product needs to automatically get out
|
|
of the UNCOMFIRMED state", and "Version" options yet. We'll cover
|
|
those in a few moments.</para>
|
|
</tip>
|
|
</section>
|
|
|
|
<section id="components">
|
|
<title>Components</title>
|
|
|
|
<para>Components are subsections of a Product.
|
|
<example>
|
|
<title>Creating some Components</title>
|
|
|
|
<informalexample>
|
|
<para>The computer game you are designing may have a "UI"
|
|
component, an "API" component, a "Sound System" component, and a
|
|
"Plugins" component, each overseen by a different programmer. It
|
|
often makes sense to divide Components in Bugzilla according to the
|
|
natural divisions of responsibility within your Product or
|
|
company.</para>
|
|
</informalexample>
|
|
</example>
|
|
|
|
Each component has a owner and (if you turned it on in the parameters),
|
|
a QA Contact. The owner should be the primary person who fixes bugs in
|
|
that component. The QA Contact should be the person who will ensure
|
|
these bugs are completely fixed. The Owner, QA Contact, and Reporter
|
|
will get email when new bugs are created in this Component and when
|
|
these bugs change. Default Owner and Default QA Contact fields only
|
|
dictate the
|
|
<emphasis>default assignments</emphasis>
|
|
|
|
; the Owner and QA Contact fields in a bug are otherwise unrelated to
|
|
the Component.</para>
|
|
|
|
<para>To create a new Component:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Select the "Edit components" link from the "Edit product"
|
|
page</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Select the "Add" link to the right of the "Add a new
|
|
component" text on the "Select Component" page.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Fill out the "Component" field, a short "Description", and
|
|
the "Initial Owner". The Component and Description fields are
|
|
free-form; the "Initial Owner" field must be that of a user ID
|
|
already existing in the database. If the initial owner does not
|
|
exist, Bugzilla will refuse to create the component.
|
|
<tip>
|
|
<para>Is your "Default Owner" a user who is not yet in the
|
|
database? No problem.
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Select the "Log out" link on the footer of the
|
|
page.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Select the "New Account" link on the footer of the
|
|
"Relogin" page</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Type in the email address of the default owner you want
|
|
to create in the "E-mail address" field, and her full name in
|
|
the "Real name" field, then select the "Submit Query"
|
|
button.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Now select "Log in" again, type in your login
|
|
information, and you can modify the product to use the
|
|
Default Owner information you require.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</para>
|
|
</tip>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Either Edit more components or return to the Bugzilla Query
|
|
Page. To return to the Product you were editing, you must select
|
|
the Components link as before.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section id="versions">
|
|
<title>Versions</title>
|
|
|
|
<para>Versions are the revisions of the product, such as "Flinders
|
|
3.1", "Flinders 95", and "Flinders 2000". Using Versions helps you
|
|
isolate code changes and are an aid in reporting.
|
|
<example>
|
|
<title>Common Use of Versions</title>
|
|
|
|
<informalexample>
|
|
<para>A user reports a bug against Version "Beta 2.0" of your
|
|
product. The current Version of your software is "Release Candidate
|
|
1", and no longer has the bug. This will help you triage and
|
|
classify bugs according to their relevance. It is also possible
|
|
people may report bugs against bleeding-edge beta versions that are
|
|
not evident in older versions of the software. This can help
|
|
isolate code changes that caused the bug</para>
|
|
</informalexample>
|
|
</example>
|
|
|
|
<example>
|
|
<title>A Different Use of Versions</title>
|
|
|
|
<informalexample>
|
|
<para>This field has been used to good effect by an online service
|
|
provider in a slightly different way. They had three versions of
|
|
the product: "Production", "QA", and "Dev". Although it may be the
|
|
same product, a bug in the development environment is not normally
|
|
as critical as a Production bug, nor does it need to be reported
|
|
publicly. When used in conjunction with Target Milestones, one can
|
|
easily specify the environment where a bug can be reproduced, and
|
|
the Milestone by which it will be fixed.</para>
|
|
</informalexample>
|
|
</example>
|
|
</para>
|
|
|
|
<para>To create and edit Versions:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>From the "Edit product" screen, select "Edit Versions"</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You will notice that the product already has the default
|
|
version "undefined". If your product doesn't use version numbers,
|
|
you may want to leave this as it is or edit it so that it is "---".
|
|
You can then go back to the edit versions page and add new versions
|
|
to your product.</para>
|
|
|
|
<para>Otherwise, click the "Add" button to the right of the "Add a
|
|
new version" text.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Enter the name of the Version. This can be free-form
|
|
characters up to the limit of the text box. Then select the "Add"
|
|
button.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>At this point you can select "Edit" to edit more Versions, or
|
|
return to the "Query" page, from which you can navigate back to the
|
|
product through the "components" link at the foot of the Query
|
|
page.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section id="milestones">
|
|
<title>Milestones</title>
|
|
|
|
<para>Milestones are "targets" that you plan to get a bug fixed by. For
|
|
example, you have a bug that you plan to fix for your 3.0 release, it
|
|
would be assigned the milestone of 3.0. Or, you have a bug that you
|
|
plan to fix for 2.8, this would have a milestone of 2.8.</para>
|
|
|
|
<note>
|
|
<para>Milestone options will only appear for a Product if you turned
|
|
the "usetargetmilestone" field in the "Edit Parameters" screen
|
|
"On".</para>
|
|
</note>
|
|
|
|
<para>To create new Milestones, set Default Milestones, and set
|
|
Milestone URL:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Select "edit milestones"</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Select "Add" to the right of the "Add a new milestone"
|
|
text</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Enter the name of the Milestone in the "Milestone" field. You
|
|
can optionally set the "Sortkey", which is a positive or negative
|
|
number (-255 to 255) that defines where in the list this particular
|
|
milestone appears. Select "Add".</para>
|
|
|
|
<example>
|
|
<title>Using SortKey with Target Milestone</title>
|
|
|
|
<informalexample>
|
|
<para>Let's say you create a target milestone called "Release
|
|
1.0", with Sortkey set to "0". Later, you realize that you will
|
|
have a public beta, called "Beta1". You can create a Milestone
|
|
called "Beta1", with a Sortkey of "-1" in order to ensure
|
|
people will see the Target Milestone of "Beta1" earlier on the
|
|
list than "Release 1.0"</para>
|
|
</informalexample>
|
|
</example>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If you want to add more milestones, select the "Edit" link.
|
|
If you don't, well shoot, you have to go back to the "query" page
|
|
and select "components" again, and make your way back to the
|
|
Product you were editing.
|
|
<note>
|
|
<para>This is another in the list of unusual user interface
|
|
decisions that we'd like to get cleaned up. Shouldn't there be a
|
|
link to the effect of "edit the Product I was editing when I
|
|
ended up here"? In any case, clicking "components" in the footer
|
|
takes you back to the "Select product" screen, from which you can
|
|
begin editing your product again.</para>
|
|
</note>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>From the Edit product screen again (once you've made your way
|
|
back), enter the URL for a description of what your milestones are
|
|
for this product in the "Milestone URL" field. It should be of the
|
|
format "http://www.foo.com/bugzilla/product_milestones.html"</para>
|
|
|
|
<para>Some common uses of this field include product descriptions,
|
|
product roadmaps, and of course a simple description of the meaning
|
|
of each milestone.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If you're using Target Milestones, the "Default Milestone"
|
|
field must have some kind of entry. If you really don't care if
|
|
people set coherent Target Milestones, simply leave this at the
|
|
default, "---". However, controlling and regularly updating the
|
|
Default Milestone field is a powerful tool when reporting the
|
|
status of projects.</para>
|
|
|
|
<para>Select the "Update" button when you are done.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section id="voting">
|
|
<title>Voting</title>
|
|
|
|
<para>The concept of "voting" is a poorly understood, yet powerful
|
|
feature for the management of open-source projects. Each user is
|
|
assigned so many Votes per product, which they can freely reassign (or
|
|
assign multiple votes to a single bug). This allows developers to gauge
|
|
user need for a particular enhancement or bugfix. By allowing bugs with
|
|
a certain number of votes to automatically move from "UNCONFIRMED" to
|
|
"NEW", users of the bug system can help high-priority bugs garner
|
|
attention so they don't sit for a long time awaiting triage.</para>
|
|
|
|
<para>The daunting challenge of Votes is deciding where you draw the
|
|
line for a "vocal majority". If you only have a user base of 100 users,
|
|
setting a low threshold for bugs to move from UNCONFIRMED to NEW makes
|
|
sense. As the Bugzilla user base expands, however, these thresholds
|
|
must be re-evaluated. You should gauge whether this feature is worth
|
|
the time and close monitoring involved, and perhaps forego
|
|
implementation until you have a critical mass of users who demand
|
|
it.</para>
|
|
|
|
<para>To modify Voting settings:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Navigate to the "Edit product" screen for the Product you
|
|
wish to modify</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Set "Maximum Votes per person" to your calculated value.
|
|
Setting this field to "0" disables voting.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Set "Maximum Votes a person can put on a single bug" to your
|
|
calculated value. It should probably be some number lower than the
|
|
"Maximum votes per person". Setting this field to "0" disables
|
|
voting, but leaves the voting options open to the user. This is
|
|
confusing.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Set "Number of votes a bug in this product needs to
|
|
automatically get out of the UNCONFIRMED state" to your calculated
|
|
number. Setting this field to "0" disables the automatic move of
|
|
bugs from UNCONFIRMED to NEW. Some people advocate leaving this at
|
|
"0", but of what use are Votes if your Bugzilla user base is unable
|
|
to affect which bugs appear on Development radar?
|
|
<tip>
|
|
<para>You should probably set this number to higher than a small
|
|
coalition of Bugzilla users can influence it. Most sites use this
|
|
as a "referendum" mechanism -- if users are able to vote a bug
|
|
out of UNCONFIRMED, it is a
|
|
<emphasis>really</emphasis>
|
|
|
|
bad bug!</para>
|
|
</tip>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Once you have adjusted the values to your preference, select
|
|
the "Update" button.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section id="groups">
|
|
<title>Groups and Group Security</title>
|
|
|
|
<para>Groups can be very useful in bugzilla, because they allow users
|
|
to isolate bugs or products that should only be seen by certain people.
|
|
Groups can also be a complicated minefield of interdependencies and
|
|
weirdness if mismanaged.
|
|
<example>
|
|
<title>When to Use Group Security</title>
|
|
|
|
<informalexample>
|
|
<para>Many Bugzilla sites isolate "Security-related" bugs from all
|
|
other bugs. This way, they can have a fix ready before the security
|
|
vulnerability is announced to the world. You can create a
|
|
"Security" product which, by default, has no members, and only add
|
|
members to the group (in their individual User page, as described
|
|
under User Administration) who should have priveleged access to
|
|
"Security" bugs. Alternately, you may create a Group independently
|
|
of any Product, and change the Group mask on individual bugs to
|
|
restrict access to members only of certain Groups.</para>
|
|
</informalexample>
|
|
</example>
|
|
|
|
Groups only work if you enable the "usebuggroups" paramater. In
|
|
addition, if the "usebuggroupsentry" parameter is "On", one can
|
|
restrict access to products by groups, so that only members of a
|
|
product group are able to view bugs within that product. Group security
|
|
in Bugzilla can be divided into two categories: Generic and
|
|
Product-Based.</para>
|
|
|
|
<note>
|
|
<para>Groups in Bugzilla are a complicated beast that evolved out of
|
|
very simple user permission bitmasks, apparently itself derived from
|
|
common concepts in UNIX access controls. A "bitmask" is a
|
|
fixed-length number whose value can describe one, and only one, set
|
|
of states. For instance, UNIX file permissions are assigned bitmask
|
|
values: "execute" has a value of 1, "write" has a value of 2, and
|
|
"read" has a value of 4. Add them together, and a file can be read,
|
|
written to, and executed if it has a bitmask of "7". (This is a
|
|
simplified example -- anybody who knows UNIX security knows there is
|
|
much more to it than this. Please bear with me for the purpose of
|
|
this note.) The only way a bitmask scheme can work is by doubling the
|
|
bit count for each value. Thus if UNIX wanted to offer another file
|
|
permission, the next would have to be a value of 8, then the next 16,
|
|
the next 32, etc.</para>
|
|
|
|
<para>Similarly, Bugzilla offers a bitmask to define group
|
|
permissions, with an internal limit of 64. Several are already
|
|
occupied by built-in permissions. The way around this limitation is
|
|
to avoid assigning groups to products if you have many products,
|
|
avoid bloating of group lists, and religiously prune irrelevant
|
|
groups. In reality, most installations of Bugzilla support far fewer
|
|
than 64 groups, so this limitation has not hit for most sites, but it
|
|
is on the table to be revised for Bugzilla 3.0 because it interferes
|
|
with the security schemes of some administrators.</para>
|
|
</note>
|
|
|
|
<para>To enable Generic Group Security ("usebuggroups"):</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Turn "On" "usebuggroups" in the "Edit Parameters"
|
|
screen.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You will generally have no groups set up. Select the "groups"
|
|
link in the footer.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Take a moment to understand the instructions on the "Edit
|
|
Groups" screen. Once you feel confident you understand what is
|
|
expected of you, select the "Add Group" link.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Fill out the "New Name" (remember, no spaces!), "New
|
|
Description", and "New User RegExp" fields. "New User RegExp"
|
|
allows you to automatically place all users who fulfill the Regular
|
|
Expression into the new group.
|
|
<example>
|
|
<title>Creating a New Group</title>
|
|
|
|
<informalexample>
|
|
<para>I created a group called DefaultGroup with a description
|
|
of
|
|
<quote>This is simply a group to play with</quote>
|
|
|
|
, and a New User RegExp of
|
|
<quote>.*@mydomain.tld</quote>
|
|
|
|
. This new group automatically includes all Bugzilla users with
|
|
"@mydomain.tld" at the end of their user id. When I finished,
|
|
my new group was assigned bit #128.</para>
|
|
</informalexample>
|
|
</example>
|
|
|
|
When you have finished, select the Add button.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>To enable Product-Based Group Security
|
|
(usebuggroupsentry):</para>
|
|
|
|
<warning>
|
|
<para>Don't forget that you only have 64 groups masks available,
|
|
total, for your installation of Bugzilla! If you plan on having more
|
|
than 50 products in your individual Bugzilla installation, and
|
|
require group security for your products, you should consider either
|
|
running multiple Bugzillas or using Generic Group Security instead of
|
|
Product-Based ("usebuggroupsentry") Group Security.</para>
|
|
</warning>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Turn "On" "usebuggroups" and "usebuggroupsentry" in the "Edit
|
|
Parameters" screen.</para>
|
|
|
|
<warning>
|
|
<para>"usebuggroupsentry" has the capacity to prevent the
|
|
administrative user from directly altering bugs because of
|
|
conflicting group permissions. If you plan on using
|
|
"usebuggroupsentry", you should plan on restricting
|
|
administrative account usage to administrative duties only. In
|
|
other words, manage bugs with an unpriveleged user account, and
|
|
manage users, groups, Products, etc. with the administrative
|
|
account.</para>
|
|
</warning>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You will generally have no Groups set up, unless you enabled
|
|
"usebuggroupsentry" prior to creating any Products. To create
|
|
"Generic Group Security" groups, follow the instructions given
|
|
above. To create Product-Based Group security, simply follow the
|
|
instructions for creating a new Product. If you need to add users
|
|
to these new groups as you create them, you will find the option to
|
|
add them to the group available under the "Edit User"
|
|
screens.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>You may find this example illustrative for how bug groups work.
|
|
<example>
|
|
<title>Bugzilla Groups</title>
|
|
|
|
<literallayout>Bugzilla Groups example ----------------------- For
|
|
this example, let us suppose we have four groups, call them Group1,
|
|
Group2, Group3, and Group4. We have 5 users, User1, User2, User3,
|
|
User4, User5. We have 8 bugs, Bug1, ..., Bug8. Group membership is
|
|
defined by this chart: (X denotes that user is in that group.) (I
|
|
apologize for the nasty formatting of this table. Try viewing it in a
|
|
text-based browser or something for now. -MPB) G G G G r r r r o o o
|
|
o u u u u p p p p 1 2 3 4 +-+-+-+-+ User1|X| | | | +-+-+-+-+ User2|
|
|
|X| | | +-+-+-+-+ User3|X| |X| | +-+-+-+-+ User4|X|X|X| | +-+-+-+-+
|
|
User5| | | | | +-+-+-+-+ Bug restrictions are defined by this chart:
|
|
(X denotes that bug is restricted to that group.) G G G G r r r r o o
|
|
o o u u u u p p p p 1 2 3 4 +-+-+-+-+ Bug1| | | | | +-+-+-+-+ Bug2|
|
|
|X| | | +-+-+-+-+ Bug3| | |X| | +-+-+-+-+ Bug4| | | |X| +-+-+-+-+
|
|
Bug5|X|X| | | +-+-+-+-+ Bug6|X| |X| | +-+-+-+-+ Bug7|X|X|X| |
|
|
+-+-+-+-+ Bug8|X|X|X|X| +-+-+-+-+ Who can see each bug? Bug1 has no
|
|
group restrictions. Therefore, Bug1 can be seen by any user, whatever
|
|
their group membership. This is going to be the only bug that User5
|
|
can see, because User5 isn't in any groups. Bug2 can be seen by
|
|
anyone in Group2, that is User2 and User4. Bug3 can be seen by anyone
|
|
in Group3, that is User3 and User4. Bug4 can be seen by anyone in
|
|
Group4. Nobody is in Group4, so none of these users can see Bug4.
|
|
Bug5 can be seen by anyone who is in _both_ Group1 and Group2. This
|
|
is only User4. User1 cannot see it because he is not in Group2, and
|
|
User2 cannot see it because she is not in Group1. Bug6 can be seen by
|
|
anyone who is in both Group1 and Group3. This would include User3 and
|
|
User4. Similar to Bug5, User1 cannot see Bug6 because he is not in
|
|
Group3. Bug7 can be seen by anyone who is in Group1, Group2, and
|
|
Group3. This is only User4. All of the others are missing at least
|
|
one of those group privileges, and thus cannot see the bug. Bug8 can
|
|
be seen by anyone who is in Group1, Group2, Group3, and Group4. There
|
|
is nobody in all four of these groups, so nobody can see Bug8. It
|
|
doesn't matter that User4 is in Group1, Group2, and Group3, since he
|
|
isn't in Group4.</literallayout>
|
|
</example>
|
|
</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="security">
|
|
<title>Bugzilla Security</title>
|
|
|
|
<epigraph>
|
|
<para>Putting your money in a wall safe is better protection than
|
|
depending on the fact that no one knows that you hide your money in a
|
|
mayonnaise jar in your fridge.</para>
|
|
</epigraph>
|
|
|
|
<note>
|
|
<para>Poorly-configured MySQL, Bugzilla, and FTP installations have
|
|
given attackers full access to systems in the past. Please take these
|
|
guidelines seriously, even for Bugzilla machines hidden away behind
|
|
your firewall. 80% of all computer trespassers are insiders, not
|
|
anonymous crackers.</para>
|
|
</note>
|
|
|
|
<para>Secure your installation.
|
|
<note>
|
|
<para>These instructions must, of necessity, be somewhat vague since
|
|
Bugzilla runs on so many different platforms. If you have refinements
|
|
of these directions for specific platforms, please submit them to
|
|
<ulink url="mailto://mozilla-webtools@mozilla.org">
|
|
mozilla-webtools@mozilla.org</ulink>
|
|
</para>
|
|
</note>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Ensure you are running at least MysQL version 3.22.32 or newer.
|
|
Earlier versions had notable security holes and poorly secured
|
|
default configuration choices.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>There is no substitute for understanding the tools on your
|
|
system!</emphasis>
|
|
|
|
Read
|
|
<ulink
|
|
url="http://www.mysql.com/documentation/mysql/bychapter/manual_Privilege_system.html">
|
|
The MySQL Privilege System</ulink>
|
|
|
|
until you can recite it from memory!</para>
|
|
|
|
<para>At the very least, ensure you password the "mysql -u root"
|
|
account and the "bugs" account, establish grant table rights (consult
|
|
the Keystone guide in Appendix C: The Bugzilla Database for some
|
|
easy-to-use details) that do not allow CREATE, DROP, RELOAD,
|
|
SHUTDOWN, and PROCESS for user "bugs". I wrote up the Keystone advice
|
|
back when I knew far less about security than I do now : )</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Lock down /etc/inetd.conf. Heck, disable inet entirely on this
|
|
box. It should only listen to port 25 for Sendmail and port 80 for
|
|
Apache.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Do not run Apache as
|
|
<quote>nobody</quote>
|
|
|
|
. This will require very lax permissions in your Bugzilla
|
|
directories. Run it, instead, as a user with a name, set via your
|
|
httpd.conf file.
|
|
<note>
|
|
<para>
|
|
<quote>nobody</quote>
|
|
|
|
is a real user on UNIX systems. Having a process run as user id
|
|
<quote>nobody</quote>
|
|
|
|
is absolutely no protection against system crackers versus using
|
|
any other user account. As a general security measure, I recommend
|
|
you create unique user ID's for each daemon running on your system
|
|
and, if possible, use "chroot" to jail that process away from the
|
|
rest of your system.</para>
|
|
</note>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Ensure you have adequate access controls for the
|
|
$BUGZILLA_HOME/data/ and $BUGZILLA_HOME/shadow/ directories, as well
|
|
as the $BUGZILLA_HOME/localconfig and $BUGZILLA_HOME/globals.pl
|
|
files. The localconfig file stores your "bugs" user password, which
|
|
would be terrible to have in the hands of a criminal, while the
|
|
"globals.pl" stores some default information regarding your
|
|
installation which could aid a system cracker. In addition, some
|
|
files under $BUGZILLA_HOME/data/ store sensitive information, and
|
|
$BUGZILLA_HOME/shadow/ stores bug information for faster retrieval.
|
|
If you fail to secure these directories and this file, you will
|
|
expose bug information to those who may not be allowed to see
|
|
it.</para>
|
|
|
|
<note>
|
|
<para>Bugzilla provides default .htaccess files to protect the most
|
|
common Apache installations. However, you should verify these are
|
|
adequate according to the site-wide security policy of your web
|
|
server, and ensure that the .htaccess files are allowed to
|
|
"override" default permissions set in your Apache configuration
|
|
files. Covering Apache security is beyond the scope of this Guide;
|
|
please consult the Apache documentation for details.</para>
|
|
|
|
<para>If you are using a web server that does not support the
|
|
.htaccess control method,
|
|
<emphasis>you are at risk!</emphasis>
|
|
|
|
After installing, check to see if you can view the file
|
|
"localconfig" in your web browser (e.g.:
|
|
<ulink url="http://bugzilla.mozilla.org/localconfig">
|
|
http://bugzilla.mozilla.org/localconfig</ulink>
|
|
|
|
). If you can read the contents of this file, your web server has
|
|
not secured your bugzilla directory properly and you must fix this
|
|
problem before deploying Bugzilla. If, however, it gives you a
|
|
"Forbidden" error, then it probably respects the .htaccess
|
|
conventions and you are good to go.</para>
|
|
</note>
|
|
|
|
<para>When you run checksetup.pl, the script will attempt to modify
|
|
various permissions on files which Bugzilla uses. If you do not have
|
|
a webservergroup set in the localconfig file, then Bugzilla will have
|
|
to make certain files world readable and/or writable.
|
|
<emphasis>THIS IS INSECURE!</emphasis>
|
|
|
|
. This means that anyone who can get access to your system can do
|
|
whatever they want to your Bugzilla installation.</para>
|
|
|
|
<note>
|
|
<para>This also means that if your webserver runs all cgi scripts
|
|
as the same user/group, anyone on the system who can run cgi
|
|
scripts will be able to take control of your Bugzilla
|
|
installation.</para>
|
|
</note>
|
|
|
|
<para>On Apache, you can use .htaccess files to protect access to
|
|
these directories, as outlined in
|
|
<ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=57161">Bug
|
|
57161</ulink>
|
|
|
|
for the localconfig file, and
|
|
<ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=65572">Bug
|
|
65572</ulink>
|
|
|
|
for adequate protection in your data/ and shadow/ directories.</para>
|
|
|
|
<para>Note the instructions which follow are Apache-specific. If you
|
|
use IIS, Netscape, or other non-Apache web servers, please consult
|
|
your system documentation for how to secure these files from being
|
|
transmitted to curious users.</para>
|
|
|
|
<para>Place the following text into a file named ".htaccess",
|
|
readable by your web server, in your $BUGZILLA_HOME/data directory.
|
|
<literallayout><Files comments> allow from all </Files>
|
|
deny from all</literallayout>
|
|
</para>
|
|
|
|
<para>Place the following text into a file named ".htaccess",
|
|
readable by your web server, in your $BUGZILLA_HOME/ directory.
|
|
<literallayout><Files localconfig> deny from all </Files>
|
|
allow from all</literallayout>
|
|
</para>
|
|
|
|
<para>Place the following text into a file named ".htaccess",
|
|
readable by your web server, in your $BUGZILLA_HOME/shadow directory.
|
|
|
|
<literallayout>deny from all</literallayout>
|
|
</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</para>
|
|
</section>
|
|
</chapter>
|
|
|
|
<!-- Keep this comment at the end of the file
|
|
Local variables:
|
|
mode: sgml
|
|
sgml-always-quote-attributes:t
|
|
sgml-auto-insert-required-elements:t
|
|
sgml-balanced-tag-edit:t
|
|
sgml-exposed-tags:nil
|
|
sgml-general-insert-case:lower
|
|
sgml-indent-data:t
|
|
sgml-indent-step:2
|
|
sgml-local-catalogs:nil
|
|
sgml-local-ecat-files:nil
|
|
sgml-minimize-attributes:nil
|
|
sgml-namecase-general:t
|
|
sgml-omittag:t
|
|
sgml-parent-document:("Bugzilla-Guide.sgml" "book" "chapter")
|
|
sgml-shorttag:t
|
|
sgml-tag-region-if-active:t
|
|
End:
|
|
-->
|
|
|