From 1a6e346ca51799b197070f0f2837e5fd8d930311 Mon Sep 17 00:00:00 2001
From: "jake%bugzilla.org" <>
Date: Fri, 4 Apr 2008 11:46:20 +0000
Subject: Bug 191034, step 1 - Refactoring the installation chapter to provide
sections for OS Specific notes and configuration help on multiple web
servers. Also added some terms to the glossary.
---
docs/en/xml/administration.xml | 473 +++++++++++++++++++++++++++++------------
1 file changed, 336 insertions(+), 137 deletions(-)
(limited to 'docs/en/xml/administration.xml')
diff --git a/docs/en/xml/administration.xml b/docs/en/xml/administration.xml
index 847527203..3cd55a616 100644
--- a/docs/en/xml/administration.xml
+++ b/docs/en/xml/administration.xml
@@ -38,27 +38,24 @@
- usebuggroups:
- This dictates whether or not to implement group-based security for
- Bugzilla. If set, Bugzilla bugs can have an associated 'group',
- defining which users are allowed to see and edit the
- bug.
-
- Set "usebuggroups" to "on"
- only
- if you may wish to restrict access to particular bugs to certain
- groups of users. I suggest leaving
- this parameter off
- while initially testing your Bugzilla.
+ makeproductgroups:
+ This dictates whether or not to automatically create groups
+ when new products are created.
+
- usebuggroupsentry:
- Bugzilla Products can have a group associated with them, so that
- certain users can only see bugs in certain products. When this parameter
- is set to on
, this places all newly-created bugs in the
- group for their product immediately.
+ useentrygroupdefault:
+ Bugzilla products can have a group associated with them, so that
+ certain users can only see bugs in certain products. When this
+ parameter is set to on
, this
+ causes the initial group controls on newly created products
+ to place all newly-created bugs in the group
+ having the same name as the product immediately.
+ After a product is initially created, the group controls
+ can be further adjusted without interference by
+ this mechanism.
@@ -648,44 +645,83 @@
Groups allow the administrator
to isolate bugs or products that should only be seen by certain people.
- There are two types of group - Generic Groups, and Product-Based Groups.
+ The association between products and groups is controlled from
+ the product edit page under Edit Group Controls.
+
+
+
+ If the makeproductgroups param is on, a new group will be automatically
+ created for every new product.
- Product-Based Groups are matched with products, and allow you to restrict
- access to bugs on a per-product basis. They are enabled using the
- usebuggroups Param. Turning on the usebuggroupsentry
- Param will mean bugs automatically get added to their product group when
- filed.
+ On the product edit page, there is a page to edit the
+ Group Controls
+ for a product and determine which groups are applicable, default,
+ and mandatory for each product as well as controlling entry
+ for each product and being able to set bugs in a product to be
+ totally read-only unless some group restrictions are met.
- Generic Groups have no special relationship to products;
- you create them, and put bugs in them
- as required. One example of the use of Generic Groups
- is Mozilla's "Security" group,
- into which security-sensitive bugs are placed until fixed. Only the
- Mozilla Security Team are members of this group.
+ For each group, it is possible to specify if membership in that
+ group is...
+
+
+
+ required for bug entry,
+
+
+
+
+ Not applicable to this product(NA),
+ a possible restriction for a member of the
+ group to place on a bug in this product(Shown),
+ a default restriction for a member of the
+ group to place on a bug in this product(Default),
+ or a mandatory restriction to be placed on bugs
+ in this product(Mandatory).
+
+
+
+
+ Not applicable by non-members to this product(NA),
+ a possible restriction for a non-member of the
+ group to place on a bug in this product(Shown),
+ a default restriction for a non-member of the
+ group to place on a bug in this product(Default),
+ or a mandatory restriction to be placed on bugs
+ in this product when entered by a non-member(Mandatory).
+
+
+
+
+ required in order to make any change
+ to bugs in this product including comments.
+
+
+
- To create Generic Groups:
+ To create Groups:
- Select the "groups"
+ Select the groups
link in the footer.
- Take a moment to understand the instructions on the "Edit
- Groups" screen, then select the "Add Group" link.
+ Take a moment to understand the instructions on the Edit
+ Groups
screen, then select the Add Group
link.
- Fill out the "Group", "Description", and
- "User RegExp" fields. "New User RegExp" allows you to automatically
+ Fill out the Group
, Description
,
+ and User RegExp
fields.
+ User RegExp
allows you to automatically
place all users who fulfill the Regular Expression into the new group.
- When you have finished, click "Add".
+ When you have finished, click Add
.
The User Regexp is a perl regexp and, if not anchored, will match
any part of an address. So, if you do not want to grant access
@@ -701,28 +737,15 @@
- To use Product-Based Groups:
-
-
-
- Turn on "usebuggroups" and "usebuggroupsentry" in the "Edit
- Parameters" screen.
-
-
-
-
- In future, when you create a Product, a matching group will be
- automatically created. If you need to add a Product Group to
- a Product which was created before you turned on usebuggroups,
- then simply create a new group, as outlined above, with the
- same name as the Product.
-
-
-
Note that group permissions are such that you need to be a member
of all the groups a bug is in, for whatever
- reason, to see that bug.
+ reason, to see that bug. Similarly, you must be a member
+ of all of the entry groups for a product
+ to add bugs to a product and you must be a member
+ of all of the canedit groups for a product
+ in order to make any change to bugs in that
+ product.
@@ -750,12 +773,6 @@
To secure your installation:
-
- Ensure you are running at least MysQL version 3.22.32 or newer.
- Earlier versions had notable security holes and (from a security
- point of view) poor default configuration choices.
-
-
There is no substitute for understanding the tools on your
@@ -768,9 +785,9 @@
- 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.
+ 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.
@@ -798,27 +815,45 @@
Ensure you have adequate access controls for the
- $BUGZILLA_HOME/data/ directory, as well as the
- $BUGZILLA_HOME/localconfig file.
+ $BUGZILLA_HOME/data/ directory, as well as the
+ $BUGZILLA_HOME/localconfig file.
The localconfig file stores your "bugs" database account password.
In addition, some
- files under $BUGZILLA_HOME/data/ store sensitive information.
+ files under $BUGZILLA_HOME/data/ store sensitive
+ information.
- 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.
+ Also, beware that some text editors create backup files in the
+ current working directory so you need to also secure files like
+ localconfig~.
+
+
+
+ Simply blocking .*localconfig.*
+ won't work because the QuickSearch feature requires the web browser
+ to be able to retrieve localconfig.js and
+ others may be introduced in the future (see
+ bug
+ 186383 for more information.
+
+
+
+ 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.
+
If you are using a web server that does not support the
- .htaccess control method,
+ .htaccess control method,
you are at risk!
After installing, check to see if you can view the file
- "localconfig" in your web browser (e.g.:
+ localconfig in your web browser (e.g.:
http://bugzilla.mozilla.org/localconfig
@@ -827,11 +862,14 @@
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.
+
+
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.
+ a webservergroup set in the localconfig file,
+ then Bugzilla will have to make certain files world readable and/or
+ writable.
THIS IS INSECURE!
. This means that anyone who can get access to your system can do
@@ -844,44 +882,44 @@
installation.
- On Apache, you can use .htaccess files to protect access to
- these directories, as outlined in
- Bug
- 57161
+ On Apache, you can use .htaccess files to
+ protect access to these directories, as outlined in Bugs
+
+ 57161 and
+
+ 186383
- for the localconfig file, and
+ for the localconfig file, and
Bug
65572
- for adequate protection in your data/ directory.
+ for adequate protection in your data/ directory.
+ Also, don't forget about the template/ and
+ Bugzilla/ directories and to allow access to the
+ data/webdot directory for the
+ 192.20.225.10 IP address if you are
+ using webdot from research.att.com. The easiest way to
+ accomplish this is to set $create_htaccess to 1
+ in localconfig. However, the information below
+ is provided for those that want to know exactly what is created.
+
- Note the instructions which follow are Apache-specific. If you
+ FIX ME BEFORE RELEASE!!!!!
+ 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.
- Place the following text into a file named ".htaccess",
- readable by your web server, in your $BUGZILLA_HOME/data directory.
- <Files comments> allow from all </Files>
- deny from all
-
-
- Place the following text into a file named ".htaccess",
- readable by your web server, in your $BUGZILLA_HOME/ directory.
- <Files localconfig> deny from all </Files>
- allow from all
-
-
- Template Customisation
+ Template Customization
- One of the large changes for 2.16 was the templatisation of the
+ One of the large changes for 2.16 was the templatization of the
entire user-facing UI, using the
Template Toolkit.
Administrators can now configure the look and feel of Bugzilla without
@@ -890,9 +928,9 @@
- Templatisation also makes localised versions of Bugzilla possible,
+ Templatization also makes localized versions of Bugzilla possible,
for the first time. In the future, a Bugzilla installation may
- have templates installed for multiple localisations, and select
+ have templates installed for multiple localizations, and select
which ones to use based on the user's browser language setting.
@@ -903,7 +941,7 @@
and which you use depends mainly on how you upgrade Bugzilla. The
template directory structure is that there's a top level directory,
template, which contains a directory for
- each installed localisation. The default English templates are
+ each installed localization. The default English templates are
therefore in en. Underneath that, there
is the default directory and optionally the
custom directory. The default
@@ -913,7 +951,7 @@
- The first method of making customisations is to directly edit the
+ The first method of making customizations is to directly edit the
templates in template/en/default. This is
probably the best method for small changes if you are going to use
the CVS method of upgrading, because if you then execute a
@@ -1066,7 +1104,7 @@
There are a few templates you may be particularly interested in
- customising for your installation.
+ customizing for your installation.
@@ -1087,7 +1125,7 @@
global/banner.html.tmpl:
This contains the "banner", the part of the header that appears
at the top of all Bugzilla pages. The default banner is reasonably
- barren, so you'll probably want to customise this to give your
+ barren, so you'll probably want to customize this to give your
installation a distinctive look and feel. It is recommended you
preserve the Bugzilla version number in some form so the version
you are running can be determined, and users know what docs to read.
@@ -1168,7 +1206,7 @@
- Change Permission Customisation
+ Change Permission Customization
@@ -1190,7 +1228,7 @@
- For maximum flexibility, customising this means editing Bugzilla's Perl
+ For maximum flexibility, customizing this means editing Bugzilla's Perl
code. This gives the administrator complete control over exactly who is
allowed to do what. The relevant function is called
CheckCanChangeField(),
@@ -1222,7 +1260,7 @@
- More complex customisations are not much harder. Basically, you add
+ More complex customizations are not much harder. Basically, you add
a check in the right place in the function, i.e. after all the variables
you are using have been set up. So, don't look at $ownerid before
$ownerid has been obtained from the database. You can either add a
@@ -1257,42 +1295,203 @@
For a list of possible field names, look in
data/versioncache for the list called
@::log_columns. If you need help writing custom
- rules for your organisation, ask in the newsgroup.
+ rules for your organization, ask in the newsgroup.
Upgrading to New Releases
- A plain Bugzilla is fairly easy to upgrade from one version to a
- newer one. Always read the release notes to see if there are any issues
- that you might need to take note of. It is recommended that you take a
- backup of your database and your entire Bugzilla installation before attempting an
- upgrade. You can upgrade a 'clean' installation by untarring a new
- tarball over the old installation. If you are upgrading from 2.12 or
- later, and have cvs installed, you can type cvs -z3 update,
- and resolve conflicts if there are any.
+ Upgrading Bugzilla is something we all want to do from time to time,
+ be it to get new features or pick up the latest security fix. How easy
+ it is to update depends on a few factors.
-
- However, things get a bit more complicated if you've made
- changes to Bugzilla's code. In this case, you may have to re-make or
- reapply those changes. One good method is to take a diff of your customised
- version against the original, so you can survey all that you've changed.
- Hopefully, templatisation will reduce the need for
- this in the future.
-
- From version 2.8 onwards, Bugzilla databases can be automatically
- carried forward during an upgrade. However, because the developers of
- Bugzilla are constantly adding new
- tables, columns and fields, you'll probably get SQL errors if you just
- update the code and attempt to use Bugzilla. Always run the
- checksetup.pl
- script whenever you upgrade your installation.
-
- If you are running Bugzilla version 2.8 or lower, and wish to
- upgrade to the latest version, please consult the file,
- "UPGRADING-pre-2.8" in the Bugzilla root directory after untarring the
- archive.
+
+
+
+ If the new version is a revision or a new point release
+
+
+ How many, if any, local changes have been made
+
+
+
+ There are also three different methods to upgrade your installation.
+
+
+
+
+ Using CVS ()
+
+
+ Downloading a new tarball ()
+
+
+ Applying the relevant patches ()
+
+
+
+ Which options are available to you may depend on how large a jump
+ you are making and/or your network configuration.
+
+
+ Revisions are normally released to fix security vulnerabilities
+ and are distinguished by an increase in the third number. For example,
+ when 2.16.2 was released, it was a revision to 2.16.1.
+
+
+ Point releases are normally released when the Bugzilla team feels
+ that there has been a significant amount of progress made between the
+ last point release and the current time. These are often proceeded by a
+ stabilization period and release candidates, however the use of
+ development versions or release candidates is beyond the scope of this
+ document. Point releases can be distinguished by an increase in the
+ second number, or minor version. For example, 2.16.2 is a newer point
+ release than 2.14.5.
+
+
+ The examples in this section are written as if you were updating
+ to version 2.16.2. The procedures are the same regardless if you are
+ updating to a new point release or a new revision. However, the chance
+ of running into trouble increases when upgrading to a new point release,
+ escpecially if you've made local changes.
+
+
+ These examples also assume that your Bugzilla installation is at
+ /var/www/html/bugzilla. If that is not the case,
+ simply substitute the proper paths where appropriate.
+
+
+
+ Upgrading using CVS
+
+ Every release of Bugzilla, whether it is a revision or a point
+ release, is tagged in CVS. Also, every tarball we have distributed
+ since version 2.12 has been primed for using CVS. This does, however,
+ require that you are able to access cvs-mirror.mozilla.org on port
+ 2401.
+
+
+ If you can do this, updating using CVS is probably the most
+ painless method, especially if you have a lot of local changes.
+
+
+
+
+
+bash$ cd /var/www/html/bugzilla
+bash$ cvs login
+Logging in to :pserver:anonymous@cvs-mirror.mozilla.org:2401/cvsroot
+CVS password: anonymous
+bash$ cvs -q update -r BUGZILLA-2_16_2 -dP
+P checksetup.pl
+P collectstats.pl
+P globals.pl
+P docs/rel_notes.txt
+P template/en/default/list/quips.html.tmpl
+
+
+
+
+ If a line in the output from cvs update
+ begins with a C that represents a
+ file with local changes that CVS was unable to properly merge. You
+ need to resolve these conflicts manually before Bugzilla (or at
+ least the portion using that file) will be usable.
+
+
+
+
+ You also need to run ./checksetup.pl
+ before your Bugzilla upgrade will be complete.
+
+
+
+
+
+
+ Upgrading using the tarball
+
+ If you are unable or unwilling to use CVS, another option that's
+ always available is to download the latest tarball. This is the most
+ difficult option to use, especially if you have local changes.
+
+
+
+bash$ cd /var/www/html
+bash$ wget ftp://ftp.mozilla.org/pub/webtools/bugzilla-2.16.2.tar.gz
+Output omitted
+bash$ tar xzvf bugzilla-2.16.2.tar.gz
+bugzilla-2.16.2/
+bugzilla-2.16.2/.cvsignore
+bugzilla-2.16.2/1x1.gif
+Output truncated
+bash$ cd bugzilla-2.16.2
+bash$ cp ../bugzilla/localconfig* .
+bash$ cp -r ../bugzilla/data .
+bash$ cd ..
+bash$ mv bugzilla bugzilla.old
+bash$ mv bugzilla-2.16.2 bugzilla
+bash$ cd bugzilla
+bash$ ./checksetup.pl
+Output omitted
+
+
+
+
+ The cp commands both end with periods which
+ is a very important detail, it tells the shell that the destination
+ directory is the current working directory. Also, the period at the
+ beginning of the ./checksetup.pl is important and
+ can not be omitted.
+
+
+
+
+ You will now have to reapply any changes you have made to your
+ local installation manually.
+
+
+
+
+
+
+ Upgrading using patches
+
+ The Bugzilla team will normally make a patch file available for
+ revisions to go from the most recent revision to the new one. You could
+ also read the release notes and grab the patches attached to the
+ mentioned bug, but it is safer to use the released patch file as
+ sometimes patches get changed before they get checked in (for minor
+ spelling fixes and the like). It is also theorectically possible to
+ scour the fixed bug list and pick and choose which patches to apply
+ from a point release, but this is not recommended either as what you'll
+ end up with is a hodge podge Bugzilla that isn't really any version.
+ This would also make it more difficult to upgrade in the future.
+
+
+
+bash$ cd /var/www/html/bugzilla
+bash$ wget ftp://ftp.mozilla.org/pub/webtools/bugzilla-2.16.1-to-2.16.2.diff.gz
+Output omitted
+bash$ gunzip bugzilla-2.16.1-to-2.16.2.diff.gz
+bash$ patch -p1 < bugzilla-2.16.1-to-2.16.2.diff
+patching file checksetup.pl
+patching file collectstats.pl
+patching file globals.pl
+
+
+
+
+ If you do this, beware that this doesn't change the entires in
+ your CVS directory so it may make
+ updates using CVS () more difficult in the
+ future.
+
+
+
+
+
--
cgit v1.2.3-24-g4f1b