Commit 1a6e346c authored by jake%bugzilla.org's avatar jake%bugzilla.org

Bug 191034, step 1 - Refactoring the installation chapter to provide sections…

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.
parent bac2db7f
...@@ -38,27 +38,24 @@ ...@@ -38,27 +38,24 @@
<step> <step>
<para> <para>
<command>usebuggroups</command>: <command>makeproductgroups</command>:
This dictates whether or not to implement group-based security for This dictates whether or not to automatically create groups
Bugzilla. If set, Bugzilla bugs can have an associated 'group', when new products are created.
defining which users are allowed to see and edit the </para>
bug.</para>
<para>Set "usebuggroups" to "on"
<emphasis>only</emphasis>
if you may wish to restrict access to particular bugs to certain
groups of users. I suggest leaving
this parameter <emphasis>off</emphasis>
while initially testing your Bugzilla.</para>
</step> </step>
<step> <step>
<para> <para>
<command>usebuggroupsentry</command>: <command>useentrygroupdefault</command>:
Bugzilla Products can have a group associated with them, so that Bugzilla products can have a group associated with them, so that
certain users can only see bugs in certain products. When this parameter certain users can only see bugs in certain products. When this
is set to <quote>on</quote>, this places all newly-created bugs in the parameter is set to <quote>on</quote>, this
group for their product immediately.</para> 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.</para>
</step> </step>
<step> <step>
...@@ -648,44 +645,83 @@ ...@@ -648,44 +645,83 @@
<para>Groups allow the administrator <para>Groups allow the administrator
to isolate bugs or products that should only be seen by certain people. 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 <quote>Edit Group Controls.</quote>
</para>
<para>
If the makeproductgroups param is on, a new group will be automatically
created for every new product.
</para> </para>
<para> <para>
Product-Based Groups are matched with products, and allow you to restrict On the product edit page, there is a page to edit the
access to bugs on a per-product basis. They are enabled using the <quote>Group Controls</quote>
usebuggroups Param. Turning on the usebuggroupsentry for a product and determine which groups are applicable, default,
Param will mean bugs automatically get added to their product group when and mandatory for each product as well as controlling entry
filed. for each product and being able to set bugs in a product to be
totally read-only unless some group restrictions are met.
</para> </para>
<para> <para>
Generic Groups have no special relationship to products; For each group, it is possible to specify if membership in that
you create them, and put bugs in them group is...
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.
</para> </para>
<orderedlist>
<listitem>
<para>
required for bug entry,
</para>
</listitem>
<listitem>
<para>
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).
</para>
</listitem>
<listitem>
<para>
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).
</para>
</listitem>
<listitem>
<para>
required in order to make <emphasis>any</emphasis> change
to bugs in this product <emphasis>including comments.</emphasis>
</para>
</listitem>
</orderedlist>
<para>To create Generic Groups:</para> <para>To create Groups:</para>
<orderedlist> <orderedlist>
<listitem> <listitem>
<para>Select the "groups" <para>Select the <quote>groups</quote>
link in the footer.</para> link in the footer.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Take a moment to understand the instructions on the "Edit <para>Take a moment to understand the instructions on the <quote>Edit
Groups" screen, then select the "Add Group" link.</para> Groups</quote> screen, then select the <quote>Add Group</quote> link.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Fill out the "Group", "Description", and <para>Fill out the <quote>Group</quote>, <quote>Description</quote>,
"User RegExp" fields. "New User RegExp" allows you to automatically and <quote>User RegExp</quote> fields.
<quote>User RegExp</quote> allows you to automatically
place all users who fulfill the Regular Expression into the new group. place all users who fulfill the Regular Expression into the new group.
When you have finished, click "Add".</para> When you have finished, click <quote>Add</quote>.</para>
<warning> <warning>
<para>The User Regexp is a perl regexp and, if not anchored, will match <para>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 any part of an address. So, if you do not want to grant access
...@@ -701,28 +737,15 @@ ...@@ -701,28 +737,15 @@
</listitem> </listitem>
</orderedlist> </orderedlist>
<para>To use Product-Based Groups:</para>
<orderedlist>
<listitem>
<para>Turn on "usebuggroups" and "usebuggroupsentry" in the "Edit
Parameters" screen.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
</orderedlist>
<para> <para>
Note that group permissions are such that you need to be a member Note that group permissions are such that you need to be a member
of <emphasis>all</emphasis> the groups a bug is in, for whatever of <emphasis>all</emphasis> 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 <emphasis>all</emphasis> of the entry groups for a product
to add bugs to a product and you must be a member
of <emphasis>all</emphasis> of the canedit groups for a product
in order to make <emphasis>any</emphasis> change to bugs in that
product.
</para> </para>
</section> </section>
...@@ -751,12 +774,6 @@ ...@@ -751,12 +774,6 @@
<orderedlist> <orderedlist>
<listitem> <listitem>
<para>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.</para>
</listitem>
<listitem>
<para> <para>
<emphasis>There is no substitute for understanding the tools on your <emphasis>There is no substitute for understanding the tools on your
system!</emphasis> system!</emphasis>
...@@ -768,9 +785,9 @@ ...@@ -768,9 +785,9 @@
</listitem> </listitem>
<listitem> <listitem>
<para>Lock down /etc/inetd.conf. Heck, disable inet entirely on this <para>Lock down <filename>/etc/inetd.conf</filename>. Heck, disable
box. It should only listen to port 25 for Sendmail and port 80 for inet entirely on this box. It should only listen to port 25 for
Apache.</para> Sendmail and port 80 for Apache.</para>
</listitem> </listitem>
<listitem> <listitem>
...@@ -798,27 +815,45 @@ ...@@ -798,27 +815,45 @@
<listitem> <listitem>
<para>Ensure you have adequate access controls for the <para>Ensure you have adequate access controls for the
$BUGZILLA_HOME/data/ directory, as well as the <filename>$BUGZILLA_HOME/data/</filename> directory, as well as the
$BUGZILLA_HOME/localconfig file. <filename>$BUGZILLA_HOME/localconfig</filename> file.
The localconfig file stores your "bugs" database account password. The localconfig file stores your "bugs" database account password.
In addition, some In addition, some
files under $BUGZILLA_HOME/data/ store sensitive information. files under <filename>$BUGZILLA_HOME/data/</filename> store sensitive
information.
</para> </para>
<para>Bugzilla provides default .htaccess files to protect the most <para>Also, beware that some text editors create backup files in the
common Apache installations. However, you should verify these are current working directory so you need to also secure files like
adequate according to the site-wide security policy of your web <filename>localconfig~</filename>.
server, and ensure that the .htaccess files are allowed to </para>
"override" default permissions set in your Apache configuration
files. Covering Apache security is beyond the scope of this Guide; <note>
please consult the Apache documentation for details.</para> <para>Simply blocking <computeroutput>.*localconfig.*</computeroutput>
won't work because the QuickSearch feature requires the web browser
to be able to retrieve <filename>localconfig.js</filename> and
others may be introduced in the future (see
<ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=186383">bug
186383</ulink> for more information.
</para>
</note>
<para>Bugzilla provides default <filename>.htaccess</filename> 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 <filename>.htaccess</filename>
files are allowed to <quote>override</quote> 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 <para>If you are using a web server that does not support the
.htaccess control method, <filename>.htaccess</filename> control method,
<emphasis>you are at risk!</emphasis> <emphasis>you are at risk!</emphasis>
After installing, check to see if you can view the file After installing, check to see if you can view the file
"localconfig" in your web browser (e.g.: <filename>localconfig</filename> in your web browser (e.g.:
<ulink url="http://bugzilla.mozilla.org/localconfig"> <ulink url="http://bugzilla.mozilla.org/localconfig">
http://bugzilla.mozilla.org/localconfig</ulink> http://bugzilla.mozilla.org/localconfig</ulink>
...@@ -827,11 +862,14 @@ ...@@ -827,11 +862,14 @@
problem before deploying Bugzilla. If, however, it gives you a problem before deploying Bugzilla. If, however, it gives you a
"Forbidden" error, then it probably respects the .htaccess "Forbidden" error, then it probably respects the .htaccess
conventions and you are good to go.</para> conventions and you are good to go.</para>
</listitem>
<listitem>
<para>When you run checksetup.pl, the script will attempt to modify <para>When you run checksetup.pl, the script will attempt to modify
various permissions on files which Bugzilla uses. If you do not have various permissions on files which Bugzilla uses. If you do not have
a webservergroup set in the localconfig file, then Bugzilla will have a webservergroup set in the <filename>localconfig</filename> file,
to make certain files world readable and/or writable. then Bugzilla will have to make certain files world readable and/or
writable.
<emphasis>THIS IS INSECURE!</emphasis> <emphasis>THIS IS INSECURE!</emphasis>
. This means that anyone who can get access to your system can do . This means that anyone who can get access to your system can do
...@@ -844,44 +882,44 @@ ...@@ -844,44 +882,44 @@
installation.</para> installation.</para>
</note> </note>
<para>On Apache, you can use .htaccess files to protect access to <para>On Apache, you can use <filename>.htaccess</filename> files to
these directories, as outlined in protect access to these directories, as outlined in Bugs
<ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=57161">Bug <ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=57161">
57161</ulink> 57161</ulink> and
<ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=186383">
186383</ulink>
for the localconfig file, and for the <filename>localconfig</filename> file, and
<ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=65572">Bug <ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=65572">Bug
65572</ulink> 65572</ulink>
for adequate protection in your data/ directory.</para> for adequate protection in your <filename>data/</filename> directory.
Also, don't forget about the <filename>template/</filename> and
<filename>Bugzilla/</filename> directories and to allow access to the
<filename>data/webdot</filename> directory for the
<computeroutput>192.20.225.10</computeroutput> IP address if you are
using webdot from research.att.com. The easiest way to
accomplish this is to set <function>$create_htaccess</function> to 1
in <filename>localconfig</filename>. However, the information below
is provided for those that want to know exactly what is created.
</para>
<para>Note the instructions which follow are Apache-specific. If you <para>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 use IIS, Netscape, or other non-Apache web servers, please consult
your system documentation for how to secure these files from being your system documentation for how to secure these files from being
transmitted to curious users.</para> 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>&lt;Files comments&gt; allow from all &lt;/Files&gt;
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>&lt;Files localconfig&gt; deny from all &lt;/Files&gt;
allow from all</literallayout>
</para>
</listitem> </listitem>
</orderedlist> </orderedlist>
</para> </para>
</section> </section>
<section id="cust-templates"> <section id="cust-templates">
<title>Template Customisation</title> <title>Template Customization</title>
<para> <para>
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 entire user-facing UI, using the
<ulink url="http://www.template-toolkit.org">Template Toolkit</ulink>. <ulink url="http://www.template-toolkit.org">Template Toolkit</ulink>.
Administrators can now configure the look and feel of Bugzilla without Administrators can now configure the look and feel of Bugzilla without
...@@ -890,9 +928,9 @@ ...@@ -890,9 +928,9 @@
</para> </para>
<para> <para>
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 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. which ones to use based on the user's browser language setting.
</para> </para>
...@@ -903,7 +941,7 @@ ...@@ -903,7 +941,7 @@
and which you use depends mainly on how you upgrade Bugzilla. The and which you use depends mainly on how you upgrade Bugzilla. The
template directory structure is that there's a top level directory, template directory structure is that there's a top level directory,
<filename>template</filename>, which contains a directory for <filename>template</filename>, which contains a directory for
each installed localisation. The default English templates are each installed localization. The default English templates are
therefore in <filename>en</filename>. Underneath that, there therefore in <filename>en</filename>. Underneath that, there
is the <filename>default</filename> directory and optionally the is the <filename>default</filename> directory and optionally the
<filename>custom</filename> directory. The <filename>default</filename> <filename>custom</filename> directory. The <filename>default</filename>
...@@ -913,7 +951,7 @@ ...@@ -913,7 +951,7 @@
</para> </para>
<para> <para>
The first method of making customisations is to directly edit the The first method of making customizations is to directly edit the
templates in <filename>template/en/default</filename>. This is templates in <filename>template/en/default</filename>. This is
probably the best method for small changes if you are going to use probably the best method for small changes if you are going to use
the CVS method of upgrading, because if you then execute a the CVS method of upgrading, because if you then execute a
...@@ -1066,7 +1104,7 @@ ...@@ -1066,7 +1104,7 @@
<para> <para>
There are a few templates you may be particularly interested in There are a few templates you may be particularly interested in
customising for your installation. customizing for your installation.
</para> </para>
<para> <para>
...@@ -1087,7 +1125,7 @@ ...@@ -1087,7 +1125,7 @@
<command>global/banner.html.tmpl</command>: <command>global/banner.html.tmpl</command>:
This contains the "banner", the part of the header that appears This contains the "banner", the part of the header that appears
at the top of all Bugzilla pages. The default banner is reasonably 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 installation a distinctive look and feel. It is recommended you
preserve the Bugzilla version number in some form so the version preserve the Bugzilla version number in some form so the version
you are running can be determined, and users know what docs to read. you are running can be determined, and users know what docs to read.
...@@ -1168,7 +1206,7 @@ ...@@ -1168,7 +1206,7 @@
</section> </section>
<section id="cust-change-permissions"> <section id="cust-change-permissions">
<title>Change Permission Customisation</title> <title>Change Permission Customization</title>
<warning> <warning>
<para> <para>
...@@ -1190,7 +1228,7 @@ ...@@ -1190,7 +1228,7 @@
</para> </para>
<para> <para>
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 code. This gives the administrator complete control over exactly who is
allowed to do what. The relevant function is called allowed to do what. The relevant function is called
<filename>CheckCanChangeField()</filename>, <filename>CheckCanChangeField()</filename>,
...@@ -1222,7 +1260,7 @@ ...@@ -1222,7 +1260,7 @@
</para> </para>
<para> <para>
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 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 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 $ownerid has been obtained from the database. You can either add a
...@@ -1257,42 +1295,203 @@ ...@@ -1257,42 +1295,203 @@
For a list of possible field names, look in For a list of possible field names, look in
<filename>data/versioncache</filename> for the list called <filename>data/versioncache</filename> for the list called
<filename>@::log_columns</filename>. If you need help writing custom <filename>@::log_columns</filename>. If you need help writing custom
rules for your organisation, ask in the newsgroup. rules for your organization, ask in the newsgroup.
</para> </para>
</section> </section>
<section id="upgrading"> <section id="upgrading">
<title>Upgrading to New Releases</title> <title>Upgrading to New Releases</title>
<para>A plain Bugzilla is fairly easy to upgrade from one version to a <para>Upgrading Bugzilla is something we all want to do from time to time,
newer one. Always read the release notes to see if there are any issues be it to get new features or pick up the latest security fix. How easy
that you might need to take note of. It is recommended that you take a it is to update depends on a few factors.
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 <filename>cvs -z3 update</filename>,
and resolve conflicts if there are any.
</para> </para>
<para>However, things get a bit more complicated if you've made <itemizedlist>
changes to Bugzilla's code. In this case, you may have to re-make or <listitem>
reapply those changes. One good method is to take a diff of your customised <para>If the new version is a revision or a new point release</para>
version against the original, so you can survey all that you've changed. </listitem>
Hopefully, templatisation will reduce the need for <listitem>
this in the future.</para> <para>How many, if any, local changes have been made</para>
</listitem>
<para>From version 2.8 onwards, Bugzilla databases can be automatically </itemizedlist>
carried forward during an upgrade. However, because the developers of
Bugzilla are constantly adding new <para>There are also three different methods to upgrade your installation.
tables, columns and fields, you'll probably get SQL errors if you just </para>
update the code and attempt to use Bugzilla. Always run the
<filename>checksetup.pl</filename> <orderedlist>
script whenever you upgrade your installation.</para> <listitem>
<para>Using CVS (<xref linkend="upgrade-cvs"/>)</para>
<para>If you are running Bugzilla version 2.8 or lower, and wish to </listitem>
upgrade to the latest version, please consult the file, <listitem>
"UPGRADING-pre-2.8" in the Bugzilla root directory after untarring the <para>Downloading a new tarball (<xref linkend="upgrade-tarball"/>)</para>
archive.</para> </listitem>
<listitem>
<para>Applying the relevant patches (<xref linkend="upgrade-patches"/>)</para>
</listitem>
</orderedlist>
<para>Which options are available to you may depend on how large a jump
you are making and/or your network configuration.
</para>
<para>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.
</para>
<para>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.
</para>
<para>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.
</para>
<para>These examples also assume that your Bugzilla installation is at
<filename>/var/www/html/bugzilla</filename>. If that is not the case,
simply substitute the proper paths where appropriate.
</para>
<example id="upgrade-cvs">
<title>Upgrading using CVS</title>
<para>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.
<tip>
<para>If you can do this, updating using CVS is probably the most
painless method, especially if you have a lot of local changes.
</para>
</tip>
</para>
<programlisting>
bash$ <command>cd /var/www/html/bugzilla</command>
bash$ <command>cvs login</command>
Logging in to :pserver:anonymous@cvs-mirror.mozilla.org:2401/cvsroot
CVS password: <command>anonymous</command>
bash$ <command>cvs -q update -r BUGZILLA-2_16_2 -dP</command>
P checksetup.pl
P collectstats.pl
P globals.pl
P docs/rel_notes.txt
P template/en/default/list/quips.html.tmpl
</programlisting>
<para>
<caution>
<para>If a line in the output from <command>cvs update</command>
begins with a <computeroutput>C</computeroutput> 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.
</para>
</caution>
<note>
<para>You also need to run <command>./checksetup.pl</command>
before your Bugzilla upgrade will be complete.
</para>
</note>
</para>
</example>
<example id="upgrade-tarball">
<title>Upgrading using the tarball</title>
<para>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.
</para>
<programlisting>
bash$ <command>cd /var/www/html</command>
bash$ <command>wget ftp://ftp.mozilla.org/pub/webtools/bugzilla-2.16.2.tar.gz</command>
<emphasis>Output omitted</emphasis>
bash$ <command>tar xzvf bugzilla-2.16.2.tar.gz</command>
bugzilla-2.16.2/
bugzilla-2.16.2/.cvsignore
bugzilla-2.16.2/1x1.gif
<emphasis>Output truncated</emphasis>
bash$ <command>cd bugzilla-2.16.2</command>
bash$ <command>cp ../bugzilla/localconfig* .</command>
bash$ <command>cp -r ../bugzilla/data .</command>
bash$ <command>cd ..</command>
bash$ <command>mv bugzilla bugzilla.old</command>
bash$ <command>mv bugzilla-2.16.2 bugzilla</command>
bash$ <command>cd bugzilla</command>
bash$ <command>./checksetup.pl</command>
<emphasis>Output omitted</emphasis>
</programlisting>
<para>
<warning>
<para>The <command>cp</command> 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 <command>./checksetup.pl</command> is important and
can not be omitted.
</para>
</warning>
<note>
<para>You will now have to reapply any changes you have made to your
local installation manually.
</para>
</note>
</para>
</example>
<example id="upgrade-patches">
<title>Upgrading using patches</title>
<para>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.
</para>
<programlisting>
bash$ <command>cd /var/www/html/bugzilla</command>
bash$ <command>wget ftp://ftp.mozilla.org/pub/webtools/bugzilla-2.16.1-to-2.16.2.diff.gz</command>
<emphasis>Output omitted</emphasis>
bash$ <command>gunzip bugzilla-2.16.1-to-2.16.2.diff.gz</command>
bash$ <command>patch -p1 &lt; bugzilla-2.16.1-to-2.16.2.diff</command>
patching file checksetup.pl
patching file collectstats.pl
patching file globals.pl
</programlisting>
<para>
<caution>
<para>If you do this, beware that this doesn't change the entires in
your <filename id="dir">CVS</filename> directory so it may make
updates using CVS (<xref linkend="upgrade-cvs"/>) more difficult in the
future.
</para>
</caution>
</para>
</example>
</section> </section>
<!-- Integrating Bugzilla with Third-Party Tools --> <!-- Integrating Bugzilla with Third-Party Tools -->
......
...@@ -24,23 +24,66 @@ ...@@ -24,23 +24,66 @@
<glossdiv id="gloss-a"> <glossdiv id="gloss-a">
<title>A</title> <title>A</title>
<glossentry> <glossentry id="gloss-apache">
<glossterm>Apache</glossterm> <glossterm>Apache</glossterm>
<glossdef> <glossdef>
<para>In this context, Apache is the web server most commonly used <para>In this context, Apache is the web server most commonly used
for serving up for serving up Bugzilla
<glossterm>Bugzilla</glossterm>
pages. Contrary to popular belief, the apache web server has nothing pages. Contrary to popular belief, the apache web server has nothing
to do with the ancient and noble Native American tribe, but instead to do with the ancient and noble Native American tribe, but instead
derived its name from the fact that it was derived its name from the fact that it was
<quote>a patchy</quote> <quote>a patchy</quote>
version of the original version of the original
<acronym>NCSA</acronym> <acronym>NCSA</acronym>
world-wide-web server.</para> world-wide-web server.</para>
<variablelist>
<title>Useful Directives when configuring Bugzilla</title>
<varlistentry>
<term><computeroutput><ulink url="http://httpd.apache.org/docs-2.0/mod/core.html#addhandler">AddHandler</ulink></computeroutput></term>
<listitem>
<para>Tell Apache that it's OK to run CGI scripts.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput><ulink url="http://httpd.apache.org/docs-2.0/mod/core.html#allowoverride">AllowOverride</ulink></computeroutput></term>
<term><computeroutput><ulink url="http://httpd.apache.org/docs-2.0/mod/core.html#options">Options</ulink></computeroutput></term>
<listitem>
<para>These directives are used to tell Apache many things about
the directory they apply to. For Bugzilla's purposes, we need
them to allow script execution and <filename>.htaccess</filename>
overrides.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput><ulink url="http://httpd.apache.org/docs-2.0/mod/mod_dir.html#directoryindex">DirectoryIndex</ulink></computeroutput></term>
<listitem>
<para>Used to tell Apache what files are indexes. If you can
not add <filename>index.cgi</filename> to the list of valid files,
you'll need to set <computeroutput>$index_html</computeroutput> to
1 in <filename>localconfig</filename> so
<command>./checksetup.pl</command> will create an
<filename>index.html</filename> that redirects to
<filename>index.cgi</filename>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput><ulink url="http://httpd.apache.org/docs-2.0/mod/core.html#scriptinterpretersource">ScriptInterpreterSource</ulink></computeroutput></term>
<listitem>
<para>Used when running Apache on windows so the shebang line
doesn't have to be changed in every Bugzilla script.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>For more information about how to configure Apache for Bugzilla,
see <xref linkend="http-apache"/>.
</para>
</glossdef> </glossdef>
</glossentry> </glossentry>
</glossdiv> </glossdiv>
...@@ -89,6 +132,17 @@ ...@@ -89,6 +132,17 @@
<title> <title>
</title> </title>
<glossentry id="gloss-cgi">
<glossterm>Common Gateway Interface</glossterm>
<acronym>CGI</acronym>
<glossdef>
<para><acronym>CGI</acronym> is an acronym for Common Gateway Interface. This is
a standard for interfacing an external application with a web server. Bugzilla
is an example of a <acronym>CGI</acronym> application.
</para>
</glossdef>
</glossentry>
<glossentry id="gloss-component"> <glossentry id="gloss-component">
<glossterm>Component</glossterm> <glossterm>Component</glossterm>
...@@ -138,10 +192,9 @@ ...@@ -138,10 +192,9 @@
</glossdiv> </glossdiv>
<glossdiv id="gloss-g"> <glossdiv id="gloss-g">
<title> <title>G</title>
</title>
<glossentry> <glossentry id="gloss-groups">
<glossterm>Groups</glossterm> <glossterm>Groups</glossterm>
<glossdef> <glossdef>
...@@ -159,6 +212,18 @@ ...@@ -159,6 +212,18 @@
</glossentry> </glossentry>
</glossdiv> </glossdiv>
<glossdiv id="gloss-j">
<title>J</title>
<glossentry id="gloss-javascript">
<glossterm>JavaScript</glossterm>
<glossdef>
<para>JavaScript is cool, we should talk about it.
</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv id="gloss-m"> <glossdiv id="gloss-m">
<title>M</title> <title>M</title>
...@@ -291,6 +356,18 @@ ...@@ -291,6 +356,18 @@
fixed, or an enhancement will be implemented.</para> fixed, or an enhancement will be implemented.</para>
</glossdef> </glossdef>
</glossentry> </glossentry>
<glossentry id="gloss-tcl">
<glossterm>Tool Command Language</glossterm>
<acronym>TCL</acronym>
<glossdef>
<para>TCL is an open source scripting language available for Windows,
Macintosh, and Unix based systems. Bugzilla 1.0 was written in TCL but
never released. The first release of Bugzilla was 2.0, which was when
it was ported to perl.
</para>
</glossdef>
</glossentry>
</glossdiv> </glossdiv>
<glossdiv id="gloss-z"> <glossdiv id="gloss-z">
......
...@@ -5,20 +5,20 @@ ...@@ -5,20 +5,20 @@
<section id="stepbystep" xreflabel="Bugzilla Installation Step-by-step"> <section id="stepbystep" xreflabel="Bugzilla Installation Step-by-step">
<title>Step-by-step Install</title> <title>Step-by-step Install</title>
<section> <section id="intstall-into">
<title>Introduction</title> <title>Introduction</title>
<para>Bugzilla has been successfully installed under Solaris, Linux, <para>Bugzilla has been successfully installed under Solaris, Linux,
and Win32. Win32 is not yet officially supported, but many people and Win32. Win32 is not yet officially supported, but many people
have got it working fine. have got it working fine.
Please see the Please see
<xref linkend="win32" /> <xref linkend="os-win32" />
for further advice on getting Bugzilla to work on Microsoft for further advice on getting Bugzilla to work on Microsoft
Windows.</para> Windows.</para>
</section> </section>
<section> <section id="install-package-list">
<title>Package List</title> <title>Package List</title>
<note> <note>
...@@ -483,7 +483,7 @@ ...@@ -483,7 +483,7 @@
<para>The GD library was written by Thomas Boutell a long while ago to <para>The GD library was written by Thomas Boutell a long while ago to
programatically generate images in C. Since then it's become the programatically generate images in C. Since then it's become the
defacto standard for programatic image construction. The Perl bindings defacto standard for programmatic image construction. The Perl bindings
to it found in the GD library are used on millions of web pages to to it found in the GD library are used on millions of web pages to
generate graphs on the fly. That's what Bugzilla will be using it for generate graphs on the fly. That's what Bugzilla will be using it for
so you must install it if you want any of the graphing to work.</para> so you must install it if you want any of the graphing to work.</para>
...@@ -523,65 +523,22 @@ ...@@ -523,65 +523,22 @@
</section> </section>
<section> <section id="sbs-http">
<title>HTTP Server</title> <title>HTTP Server</title>
<para>You have a freedom of choice here - Apache, Netscape or any other <para>You have freedom of choice here, pretty much any web server that
server on UNIX would do. You can run the web server on a is capable of running <glossterm linkend="gloss-cgi">CGI</glossterm>
different machine than MySQL, but need to adjust the MySQL scripts will work. <xref linkend="http"/> has more information about
<quote>bugs</quote> configuring web servers to work with Bugzilla.
user permissions accordingly. </para>
<note> <note>
<para>We strongly recommend Apache as the web server to use. The <para>We strongly recommend Apache as the web server to use. The
Bugzilla Guide installation instructions, in general, assume you are Bugzilla Guide installation instructions, in general, assume you are
using Apache. If you have got Bugzilla working using another webserver, using Apache. If you have got Bugzilla working using another webserver,
please share your experiences with us.</para> please share your experiences with us.</para>
</note> </note>
</para>
<para>You'll want to make sure that your web server will <emphasis>run</emphasis>
any file
with the .cgi extension as a CGI program and not simply display the source
code. If you're
using Apache that means uncommenting the following line in the httpd.conf
file:
<programlisting>
AddHandler cgi-script .cgi
</programlisting>
</para>
<para>With Apache you'll also want to make sure that within the
httpd.conf file these lines:
<programlisting><![CDATA[
Options +ExecCGI
AllowOverride Limit
]]></programlisting>
are in the stanza that covers the directories into which you intend to
put the bugzilla .html and .cgi files.
<note>
<para>AllowOverride Limit allows the use of a Deny statement in the
.htaccess file generated by checksetup.pl</para>
<para>Users of older versions of Apache may find the above lines
in the srm.conf and access.conf files, respectively.</para>
</note>
</para>
<warning>
<para>There are important files and directories that should not be a
served by the HTTP server - most files in the
<quote>data</quote>
directory and the
<quote>localconfig</quote>
file. You should configure your HTTP server to not serve
these files. Failure to do so will expose critical passwords and
other data. Please see
<xref linkend="htaccess" />
for details on how to do this for Apache; the checksetup.pl
script should create appropriate .htaccess files for you.</para>
</warning>
</section> </section>
<section> <section>
...@@ -598,7 +555,7 @@ AllowOverride Limit ...@@ -598,7 +555,7 @@ AllowOverride Limit
<tip> <tip>
<para>If you symlink the bugzilla directory into your Apache's HTML <para>If you symlink the bugzilla directory into your Apache's HTML
heirarchy, you may receive hierarchy, you may receive
<errorname>Forbidden</errorname> <errorname>Forbidden</errorname>
errors unless you add the errors unless you add the
<quote>FollowSymLinks</quote> <quote>FollowSymLinks</quote>
...@@ -829,7 +786,7 @@ perl -pi -e 's@#\!/usr/bonsaitools/bin/perl@#\!/usr/bin/perl@' *cgi *pl Bug.pm p ...@@ -829,7 +786,7 @@ perl -pi -e 's@#\!/usr/bonsaitools/bin/perl@#\!/usr/bin/perl@' *cgi *pl Bug.pm p
</simplelist> </simplelist>
</para> </para>
<para>This means anyone from anywhere on the internet can not only drop <para>This means anyone from anywhere on the Internet can not only drop
the database with one SQL command, and they can write as root to the the database with one SQL command, and they can write as root to the
system.</para> system.</para>
...@@ -1005,7 +962,7 @@ perl -pi -e 's@#\!/usr/bonsaitools/bin/perl@#\!/usr/bin/perl@' *cgi *pl Bug.pm p ...@@ -1005,7 +962,7 @@ perl -pi -e 's@#\!/usr/bonsaitools/bin/perl@#\!/usr/bin/perl@' *cgi *pl Bug.pm p
Alternatively, you could set up a webdot server, or use the AT&amp;T Alternatively, you could set up a webdot server, or use the AT&amp;T
public webdot server (the public webdot server (the
default for the webdotbase param). Note that AT&amp;T's server won't work default for the webdotbase param). Note that AT&amp;T's server won't work
if Bugzilla is only accessible using HTTPS. if Bugzilla is only accessible using HARTS.
</para> </para>
</section> </section>
...@@ -1335,762 +1292,460 @@ bash# perl -pi -e "s/Content-Type\: text\/html/Content-Type\: text\/html\; chars ...@@ -1335,762 +1292,460 @@ bash# perl -pi -e "s/Content-Type\: text\/html/Content-Type\: text\/html\; chars
</section> </section>
</section> </section>
<section id="win32" xreflabel="Win32 Installation Notes"> <section id="os-specific">
<title>Win32 Installation Notes</title> <title>OS Specific Installation Notes</title>
<para>This section covers installation on Microsoft Windows. <para>Many aspects of the Bugzilla installation can be affected by the
Bugzilla has been made to work on Win32 platforms, but the Bugzilla team the operating system you choose to install it on. Sometimes it can be made
wish to emphasise that The easiest way to install Bugzilla on easier and others more difficult. This section will attempt to help you
Intel-archiecture machines understand both the difficulties of running on specific operating systems
is to install some variant of GNU/Linux, then follow the UNIX and the utilities available to make it easier.
installation instructions in this Guide. If you have any influence in the
platform choice for running this system, please choose GNU/Linux instead
of Microsoft Windows.</para>
<warning>
<para>After that warning, here's the situation for 2.16
and Windows. It doesn't work at all out of the box.
You are almost certainly better off getting
the 2.17 version from CVS (after consultation with the Bugzilla Team to
make sure you are pulling on a stable day) because we'll be doing a load
of work to make the Win32 experience more pleasant than it is now.
</para>
</warning>
<para>
If you still want to try this, to have any hope of getting it to work,
you'll need to apply the
<ulink url="">mail patch</ulink> from
<ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=124174">bug 124174</ulink>.
After that, you'll need to read the (outdated) installation
instructions below, some (probably a lot better) <ulink url="http://bugzilla.mozilla.org/attachment.cgi?id=84430&amp;action=view">more
recent ones</ulink> kindly provided by Toms Baugis and Jean-Sebastien
Guay, and also check the
<ulink url="http://www.bugzilla.org/releases/2.16/docs/win32.html">Bugzilla 2.16 Win32 update page
</ulink>. If we get time,
we'll write some better installation instructions for 2.16 and put
them up there. But no promises.
</para> </para>
<section id="wininstall" xreflabel="Win32 Installation: Step-by-step">
<title>Win32 Installation: Step-by-step</title>
<note> <para>If you have anything to add or notes for an operating system not
<para>You should be familiar with, and cross-reference, the rest of covered, please file a bug in &bzg-bugs;.
the </para>
<xref linkend="installation" />
section while performing your Win32 installation.</para> <section id="os-win32">
<title>Microsoft Windows</title>
<para>Making Bugzilla work on Microsoft Windows is no picnic. Support <para>Making Bugzilla work on windows is still a very painful processes.
for Win32 has improved dramatically in the last few releases, but, if The Bugzilla Team is working to make it easier, but that goal is not
you choose to proceed, you should be a considered a top priority. If you wish to run Bugzilla, we still
<emphasis>very</emphasis> recommend doing so on a Unix based system such as GNU/Linux. As of this
writing, all members of the Bugzilla team and all known large installations
run on Unix based systems.
</para>
skilled Windows Systems Administrator with strong troubleshooting <para>If after hearing all that, you have enough pain tolerance to attempt
abilities, a high tolerance for pain, and moderate perl skills. installing Bugzilla on Win32, here are some pointers.
Bugzilla on NT requires hacking source code and implementing some <![%bz-devel;[
advanced utilities. What follows is the recommended installation Because this is a development version of the guide, these instructions
procedure for Win32; additional suggestions are provided in are subject to change without notice. In fact, the Bugzilla Team hopes
<xref linkend="faq" /> they do as we would like to have Bugzilla resonabally close to "out of
the box" compatibility by the 2.18 release.
]]>
</para>
.</para> <section id="win32-perl">
</note> <title>Win32 Perl</title>
<procedure> <para>Perl for Windows can be obtained from <ulink
<step> url="http://www.activestate.com/">ActiveState</ulink>. You should be
<para>Install able to find a compiled binary at <ulink
<ulink url="http://www.apache.org/">Apache Web Server</ulink> url="http://aspn.activestate.com/ASPN/Downloads/ActivePerl/">http://aspn.activestate.com/ASPN/Downloads/ActivePerl/</ulink>.
</para>
</section>
for Windows, and copy the Bugzilla files somewhere Apache can serve <section id="win32-perl-modules">
them. Please follow all the instructions referenced in <title>Perl Modules on Win32</title>
<xref linkend="installation" />
regarding your Apache configuration, particularly instructions <para>Bugzilla on Windows requires the same perl modules found in
regarding the <xref linkend="install-package-list"/>. The main difference is that
<quote>AddHandler</quote> windows uses <command>ppm</command> instead of CPAN.
</para>
parameter and <programlisting>
<quote>ExecCGI</quote> C:\perl&gt; <command>ppm &lt;module name&gt;</command>
</programlisting>
.</para> <note>
<para>The above syntax should work for all modules with the exception
of Template Toolkit. The <ulink
url="http://tt2.org/download.html#win32">Template Toolkit website</ulink>
suggests using the instructions on <ulink
url="http://openinteract.sourceforge.net/">OpenInteract's website</ulink>.
</para>
</note>
<note> <note>
<para>You may also use Internet Information Server or Personal <para>A complete list of modules that can be installed using ppm can
Web Server for this purpose. However, setup is quite different. be found at <ulink url="http://www.activestate.com/PPMPackages/5.6plus">http://www.activestate.com/PPMPackages/5.6plus</ulink>.
If ActivePerl doesn't seem to handle your file associations </para>
correctly (for .cgi and .pl files), please consult </note>
<xref linkend="faq" /> </section>
.</para> <section id="win32-code-changes">
<title>Code changes required to run on win32</title>
<para>If you are going to use IIS, if on Windows NT you must be <para>Unfortunately, Bugzilla still doesn't run "out of the box" on
updated to at least Service Pack 4. Windows 2000 ships with a Windows. There is work in progress to make this easier, but until that
sufficient version of IIS.</para> happens code will have to be modified. This section is an attempt to
</note> list the required changes. It is an attempt to be all inclusive, but
</step> there may be other changes required. If you find something is missing,
please file a bug in &bzg-bugs;.
</para>
<step> <section id="win32-code-checksetup">
<para>Install <title>Changes to <filename>checksetup.pl</filename></title>
<ulink url="http://www.activestate.com/">ActivePerl</ulink>
for Windows. Check <para>In <filename>checksetup.pl</filename>, the line reading:</para>
<ulink
url="http://aspn.activestate.com/ASPN/Downloads/ActivePerl/">
http://aspn.activestate.com/ASPN/Downloads/ActivePerl</ulink>
for a current compiled binary.</para> <programlisting>
my $mysql_binaries = `which mysql`;
</programlisting>
<para>to</para>
<programlisting>
my $mysql_binaries = "D:\\mysql\\bin\\mysql";
</programlisting>
<para>Please also check the following links to fully understand the <para>And you'll also need to change:</para>
status of ActivePerl on Win32:
<ulink url="http://language.perl.com/newdocs/pod/perlport.html">
Perl Porting</ulink>
, and <programlisting>
<ulink my $webservergid = getgrnam($my_webservergroup)
url="http://ftp.univie.ac.at/packages/perl/ports/nt/FAQ/perlwin32faq5.html"> </programlisting>
Perl on Win32 FAQ</ulink> <para>to</para>
</para> <programlisting>
</step> my $webservergid = '8'
</programlisting>
<step> </section>
<para>Use ppm from your perl\bin directory to install the following
packs: DBI, DBD-Mysql, TimeDate, Chart, Date-Calc, Date-Manip, GD,
AppConfig, and Template. You may need to extract them from .zip
format using Winzip or other unzip program first. Most of these
additional ppm modules can be downloaded from ActiveState, but
AppConfig and Template should be obtained from OpenInteract using
<ulink type="http" url="http://openinteract.sourceforge.net/">the
instructions on the Template Toolkit web site</ulink>
.</para>
<note>
<para>You can find a list of modules at
<ulink
url="http://www.activestate.com/PPMPackages/zips/5xx-builds-only">
http://www.activestate.com/PPMPackages/zips/5xx-builds-only/</ulink>
or
<ulink url="http://www.activestate.com/PPMPackages/5.6plus">
http://www.activestate.com/PPMPackages/5.6plus</ulink>
</para>
</note>
<para>The syntax for ppm is: <section id="win32-code-mail">
<computeroutput> <title>Making mail work</title>
<prompt>C:&gt;</prompt>
<command>ppm &lt;modulename&gt;</command> <para>The easiest way to get mail working is to use the mail patches
</computeroutput> on <ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=124174">bug
124174</ulink>. With any luck, this patch will receive the required
reviews and integrated into the main Bugzilla distribution very soon.
Until that happens, there's at least one report of this patch working
well on Windows.
</para> </para>
<example> </section>
<title>Installing ActivePerl ppd Modules on Microsoft
Windows</title>
<para>
<prompt>C:&gt;</prompt>
<command>ppm
<option>DBD-Mysql</option>
</command>
</para>
<para>Watch your capitalization!</para> <section>
</example> <title>System Calls</title>
<para>ActiveState's 5.6Plus directory also contains an AppConfig <para>In order to get system calls to work on win32's perl, you need
ppm, so you might see the following error when trying to install to tell the windows shell what interpreter to use. This is done by
the version at OpenInteract:</para> changing the <function>system</function> calls. You will need to
search all of Bugzilla's code for <function>system</function> calls.
To tell perl your interpreter, it needs to be the first argument to
the <function>system</function> call. For example, you'll need to
change:
</para>
<!-- We'll need a different example when there's no more processmail -->
<programlisting>
system("./processmail", $id, $exporter);
</programlisting>
<para>with</para>
<programlisting>
system("C:\\perl\\bin\\perl", "processmail", $id, $exporter);
</programlisting>
<para> <para>Notice that the <computeroutput>./</computeroutput> is also
<computeroutput>Error installing package 'AppConfig': Read a PPD removed.
for 'AppConfig', but it is not intended for this build of Perl
(MSWin32-x86-multi-thread)</computeroutput>
</para> </para>
<para>If so, download both <tip>
<ulink <para>The <command>grep</command> command is very helpful in finding
url="http://openinteract.sourceforge.net/ppmpackages/AppConfig.tar.gz"> these <function>system</function> calls, assuming you have the
the tarball</ulink> <productname class="trade">cygwin</productname> utilities.
</para>
</tip>
and </section>
<ulink
url="http://openinteract.sourceforge.net/ppmpackages/AppConfig.ppd">
the ppd</ulink>
directly from OpenInteract, then run ppm from within the same </section>
directory to which you downloaded those files and install the
package by referencing the ppd file explicitly via in the install
command, f.e.:
<example>
<title>Installing OpenInteract ppd Modules manually on Microsoft
Windows</title>
<para> <section id="win32-http">
<computeroutput> <title>Serving the web pages</title>
<command>install
<filename>C:\AppConfig.ppd</filename>
</command>
</computeroutput>
</para>
</example>
</para>
</step>
<step> <para>As is the case on Unix based systems, any web server should be
<para>Install MySQL for NT. able to handle Bugzilla; however, the Bugzilla Team still recommends
<note> Apache whenever asked. No matter what web server you choose, be sure
<para>You can download MySQL for Windows NT from to pay attention to the security notes in <xref linkend="security"/>.
<ulink url="http://www.mysql.com/">MySQL.com</ulink> More information on configuring specific web servers can be found in
<xref linkend="http"/>.
</para>
. Some find it helpful to use the WinMySqlAdmin utility, included <note>
with the download, to set up the database.</para> <para>If using Apache on windows, you can set the <ulink
</note> url="http://httpd.apache.org/docs-2.0/mod/core.html#scriptinterpretersource">ScriptInterpreterSource</ulink>
directive in your Apache config, if you don't do this, you'll have
to modify the first line of every script to contain your path to
perl instead of <filename>/usr/bonsaitools/bin/perl</filename>.
</para> </para>
</step> </note>
<step>
<para>Setup MySQL</para>
<substeps>
<step>
<para>
<computeroutput>
<prompt>C:&gt;</prompt>
<command>C:\mysql\bin\mysql -u root mysql</command>
</computeroutput>
</para>
</step>
<step>
<para>
<computeroutput>
<prompt>mysql&gt;</prompt>
<command>DELETE FROM user WHERE Host='localhost' AND
User='';</command>
</computeroutput>
</para>
</step>
<step>
<para>
<computeroutput>
<prompt>mysql&gt;</prompt>
<command>UPDATE user SET Password=PASSWORD ('new_password')
WHERE user='root';</command>
</computeroutput>
</para>
<para>
<quote>new_password</quote>
, above, indicates whatever password you wish to use for your
<quote>root</quote>
user.</para>
</step>
<step id="ntbugs-password">
<para>
<computeroutput>
<prompt>mysql&gt;</prompt>
<command>GRANT SELECT, INSERT, UPDATE, DELETE, INDEX,
ALTER, CREATE, DROP, REFERENCES ON bugs.* to bugs@localhost
IDENTIFIED BY 'bugs_password';</command>
</computeroutput>
</para>
<para>
<quote>bugs_password</quote>
, above, indicates whatever password you wish to use for your
<quote>bugs</quote>
user.</para>
</step>
<step>
<para>
<computeroutput>
<prompt>mysql&gt;</prompt>
<command>FLUSH PRIVILEGES;</command>
</computeroutput>
</para>
</step>
<step>
<para>
<computeroutput>
<prompt>mysql&gt;</prompt>
<command>create database bugs;</command>
</computeroutput>
</para>
</step>
<step>
<para>
<computeroutput>
<prompt>mysql&gt;</prompt>
<command>exit;</command>
</computeroutput>
</para>
</step>
<step>
<para>
<computeroutput>
<prompt>C:&gt;</prompt>
<command>C:\mysql\bin\mysqladmin -u root -p
reload</command>
</computeroutput>
</para>
</step>
</substeps>
</step>
<step>
<para>Edit
<filename>checksetup.pl</filename>
in your Bugzilla directory. Change this line:</para>
<para> </section>
<programlisting>my $webservergid =
getgrnam($my_webservergroup);</programlisting>
</para>
<para>to</para> </section>
<para> <section id="os-macosx">
<programlisting>my $webservergid = <title><productname>Mac OS X</productname></title>
$my_webservergroup;</programlisting>
<!-- XXX - Clean me up... (Mac OS X) -->
<para>There are a lot of common libraries and utilities out there that
Apple did not include with Mac OS X, but which run perfectly well on it.
The GD library, which Bugzilla needs to do bug graphs, is one of
these.</para>
<para>The easiest way to get a lot of these is with a program called
Fink, which is similar in nature to the CPAN installer, but installs
common GNU utilities. Fink is available from
<ulink url="http://sourceforge.net/projects/fink/"/>.</para>
<para>Follow the instructions for setting up Fink. Once it's installed,
you'll want to run the following as root:
<command>fink install gd</command>
</para>
<para>It will prompt you for a number of dependencies, type 'y' and hit
enter to install all of the dependencies. Then watch it work.</para>
<para>To prevent creating conflicts with the software that Apple installs
by default, Fink creates its own directory tree at /sw where it installs
most of the software that it installs. This means your libraries and
headers for libgd will be at /sw/lib and /sw/include instead of /usr/lib
and /usr/local/include. Because of these changed locations for the
libraries, the Perl GD module will not install directly via CPAN, because it
looks for the specific paths instead of getting them from your
environment. But there's a way around that :-)</para>
<para>Instead of typing
<quote>install GD</quote>
at the
<prompt>cpan&gt;</prompt>
prompt, type
<command>look GD</command>.
This should go through the motions of downloading the latest version of
the GD module, then it will open a shell and drop you into the build
directory. Apply <ulink url="../sgml/gd-makefile.patch">this patch</ulink>
to the Makefile.PL file (save the
patch into a file and use the command
<command>patch &lt; patchfile</command>.)
</para>
<para>Then, run these commands to finish the installation of the GD
module:
<simplelist>
<member>
<command>perl Makefile.PL</command>
</member>
or the name of the group you wish to own the files explicitly: <member>
<programlisting>my $webservergid = <command>make</command>
'Administrators'</programlisting> </member>
</para>
</step>
<step> <member>
<para>Run <command>make test</command>
<filename>checksetup.pl</filename> </member>
from the Bugzilla directory.</para> <member>
</step> <command>make install</command>
</member>
<step> <member>And don't forget to run
<para>Edit <command>exit</command>
<filename>localconfig</filename>
to suit your requirements. Set to get back to CPAN.</member>
<varname>$db_pass</varname> </simplelist>
</para>
to your </section>
<quote>bugs_password</quote>
from </section>
<xref linkend="ntbugs-password" />
, and <section id="http">
<varname>$webservergroup</varname> <title>HTTP Server Configuration</title>
to <para>The Bugzilla Team recommends Apache when using Bugzilla, however, any web server
<quote>8</quote> that can be configured to run <glossterm linkend="gloss-cgi">CGI</glossterm> scripts
should be able to handle Bugzilla. No matter what web server you choose, but
especially if you choose something other than Apache, you should be sure to read
<xref linkend="security"/>.
</para>
.</para> <para>The plan for this section is to eventually document the specifics of how to lock
down permissions on individual web servers.
</para>
<note> <section id="http-apache">
<para>Not sure on the <title>Apache <productname>httpd</productname></title>
<quote>8</quote>
<para>As mentioned above, the Bugzilla Team recommends Apache for use
with Bugzilla. You will have to make sure that Apache is properly
configured to run the Bugzilla CGI scripts. You also need to make sure
that the <filename>.htaccess</filename> files created by
<command>./checksetup.pl</command> (shown in <xref linkend="http-apache-htaccess"/>
for the curious) are allowed to override Apache's normal access
permissions or else important password information may be exposed to the
Internet.
</para>
<para>Many Apache installations are not configured to run scripts
anywhere but in the <filename class="directory">cgi-bin</filename>
directory; however, we recommend that Bugzilla not be installed in the
<filename class="directory">cgi-bin</filename>, otherwise the static
files such as images and <xref linkend="gloss-javascript"/>
will not work correctly. To allow scripts to run in the normal
web space, the following changes should be made to your
<filename>httpd.conf</filename> file.
</para>
for <para>To allow files with a .cgi extension to be run, make sure the
<varname>$webservergroup</varname> following line exists and is uncommented:</para>
<programlisting>
AddHandler cgi-script .cgi
</programlisting>
above. If it's wrong, please send corrections.</para> <para>To allow <filename>.htaccess</filename> files to override
</note> permissions and .cgi files to run in the Bugzilla directory, make sure
</step> the following two lines are in a <computeroutput>Directory</computeroutput>
directive that applies to the Bugzilla directory on your system
(either the Bugzilla directory or one of its parents).
</para>
<programlisting>
Options +ExecCGI
AllowOverride Limit
</programlisting>
<step> <note>
<para>Edit <para>For more information on Apache and its directives, see the
<filename>defparams.pl</filename> glossary entry on <xref linkend="gloss-apache"/>.
</para>
</note>
to suit your requirements. Particularly, set <example id="http-apache-htaccess">
<varname>DefParam("maintainer")</varname> <title><filename>.htaccess</filename> files for Apache</title>
<para><filename>$BUGZILLA_HOME/.htaccess</filename>
<programlisting><![CDATA[
# don't allow people to retrieve non-cgi executable files or our private data
<FilesMatch ^(.*\.pl|.*localconfig.*|processmail|runtests.sh)$>
deny from all
</FilesMatch>
<FilesMatch ^(localconfig.js|localconfig.rdf)$>
allow from all
</FilesMatch>
]]></programlisting>
</para>
and <para><filename>$BUGZILLA_HOME/data/.htaccess</filename>
<varname>DefParam("urlbase") to match your install.</varname> <programlisting><![CDATA[
# nothing in this directory is retrievable unless overriden by an .htaccess
# in a subdirectory; the only exception is duplicates.rdf, which is used by
# duplicates.xul and must be loadable over the web
deny from all
<Files duplicates.rdf>
allow from all
</Files>
]]></programlisting>
</para> </para>
<note> <para><filename>$BUGZILLA_HOME/data/webdot</filename>
<para>This is yet another step I'm not sure of, since the <programlisting><![CDATA[
maintainer of this documentation does not maintain Bugzilla on # Restrict access to .dot files to the public webdot server at research.att.com
NT. If you can confirm or deny that this step is required, please # if research.att.com ever changed their IP, or if you use a different
let me know.</para> # webdot server, you'll need to edit this
</note> <FilesMatch ^[0-9]+\.dot$>
</step> Allow from 192.20.225.10
Deny from all
<step> </FilesMatch>
<note>
<para>There are several alternatives to Sendmail that will work # Allow access by a local copy of 'dot' to .png, .gif, .jpg, and
on Win32. The one mentioned here is a # .map files
<emphasis>suggestion</emphasis> <FilesMatch ^[0-9]+\.(png|gif|jpg|map)$>
Allow from all
, not a requirement. Some other mail packages that can work </FilesMatch>
include
<ulink url="http://www.blat.net/">BLAT</ulink> # And no directory listings, either.
Deny from all
, ]]></programlisting>
<ulink url="http://www.geocel.com/windmail/">Windmail</ulink> </para>
,
<ulink url="http://www.dynamicstate.com/">Mercury
Sendmail</ulink>
, and the CPAN Net::SMTP Perl module (available in .ppm). Every
option requires some hacking of the Perl scripts for Bugzilla to
make it work. The option here simply requires the least.</para>
</note>
<procedure>
<step>
<para>Download NTsendmail, available from
<ulink url="http://www.ntsendmail.com/">
www.ntsendmail.com</ulink>
. You must have a "real" mail server which allows you to relay
off it in your $ENV{"NTsendmail"} (which you should probably
place in globals.pl)</para>
</step>
<step>
<para>Put ntsendmail.pm into your .\perl\lib directory.</para>
</step>
<step>
<para>Add to globals.pl:</para>
<programlisting># these settings configure the NTsendmail
process use NTsendmail;
$ENV{"NTsendmail"}="your.smtpserver.box";
$ENV{"NTsendmail_debug"}=1;
$ENV{"NTsendmail_max_tries"}=5;</programlisting>
<note>
<para>Some mention to also edit
<varname>$db_pass</varname>
in
<filename>globals.pl</filename>
to be your
<quote>bugs_password</quote>
. Although this may get you around some problem
authenticating to your database, since globals.pl is not
normally restricted by
<filename>.htaccess</filename>
, your database password is exposed to whoever uses your web
server.</para>
</note>
</step>
<step>
<para>Find and comment out all occurences of
<quote>
<command>open(SENDMAIL</command>
</quote>
in your Bugzilla directory. Then replace them with:
<programlisting># new sendmail functionality my $mail=new
NTsendmail; my $from="bugzilla\@your.machine.name.tld"; my
$to=$login; my $subject=$urlbase;
$mail-&gt;send($from,$to,$subject,$msg);</programlisting>
</para>
<note>
<para>Some have found success using the commercial product,
<productname>Windmail</productname>
. You could try replacing your sendmail calls with:
<programlisting>open SENDMAIL,
"|\"C:/General/Web/tools/Windmail 4.0 Beta/windmail\" -t &gt;
mail.log";</programlisting>
or something to that effect.</para>
</note>
</step>
</procedure>
</step>
<step>
<para>Change all references in all files from
<filename>processmail</filename>
to
<filename>processmail.pl</filename>
, and rename
<filename>processmail</filename>
to
<filename>processmail.pl</filename>
.</para>
<note>
<para>Many think this may be a change we want to make for
main-tree Bugzilla. It's painless for the UNIX folks, and will
make the Win32 people happier.</para>
</note>
<note>
<para>Some people have suggested using the Net::SMTP Perl module
instead of NTsendmail or the other options listed here. You can
change processmail.pl to make this work.
<programlisting>
<![CDATA[
my $smtp = Net::SMTP->new('<Name of your SMTP server>'); #connect to SMTP server
$smtp->mail('<your name>@<you smpt server>');# use the sender's adress here
$smtp->to($tolist); # recipient's address
$smtp->data(); # Start the mail
$smtp->datasend($msg);
$smtp->dataend(); # Finish sending the mail
$smtp->quit; # Close the SMTP connection
$logstr = "$logstr; mail sent to $tolist $cclist";
}
]]> <para><filename>$BUGZILLA_HOME/Bugzilla/.htaccess</filename>
</programlisting>
here is a test mail program for Net::SMTP:
<programlisting>
<![CDATA[
use Net::SMTP;
my $smtp = Net::SMTP->new('<Name of your SMTP server', Timeout => 30, Debug
=> 1, ); # connect to SMTP server
$smtp->auth;
$smtp->mail('you@yourcompany.com');# use the sender's adress
here
$smtp->to('someotherAddress@someotherdomain.com'); #
recipient's address
$smtp->data(); # Start the mail
$smtp->datasend('test');
$smtp->dataend(); # Finish sending the mail
$smtp->quit; # Close the SMTP connection
exit;
]]>
</programlisting>
</para>
</note>
</step>
<step>
<note>
<para>This step is optional if you are using IIS or another web
server which only decides on an interpreter based upon the file
extension (.pl), rather than the
<quote>shebang</quote>
line (#/usr/bonsaitools/bin/perl)</para>
</note>
<para>Modify the path to perl on the first line (#!) of all files
to point to your Perl installation, and add
<quote>perl</quote>
to the beginning of all Perl system calls that use a perl script as
an argument. This may take you a while. There is a
<quote>setperl.csh</quote>
utility to speed part of this procedure, available in the
<xref linkend="patches" />
section of The Bugzilla Guide. However, it requires the Cygwin
GNU-compatible environment for Win32 be set up in order to work.
See
<ulink url="http://www.cygwin.com/">http://www.cygwin.com/</ulink>
for details on obtaining Cygwin.</para>
</step>
<step>
<para>Modify the invocation of all system() calls in all perl
scripts in your Bugzilla directory. You should specify the full
path to perl for each system() call. For instance, change this line
in processmail:
<programlisting> <programlisting>
<![CDATA[ # nothing in this directory is retrievable unless overriden by an .htaccess
system ("./processmail",@ARGLIST); # in a subdirectory
</programlisting> to deny from all
<programlisting>
system ("C:\\perl\\bin\\perl", "processmail", @ARGLIST);
]]>
</programlisting> </programlisting>
</para> </para>
</step>
</procedure>
<tip> <para><filename>$BUGZILLA_HOME/template/.htaccess</filename>
<para>If you are using IIS or Personal Web Server, you must add cgi <programlisting>
relationships to Properties -&gt; Home directory (tab) -&gt; # nothing in this directory is retrievable unless overriden by an .htaccess
Application Settings (section) -&gt; Configuration (button), such # in a subdirectory
as:</para> deny from all
</programlisting>
</para>
<para> </example>
<programlisting>.cgi to: &lt;perl install directory&gt;\perl.exe %s
%s .pl to: &lt;perl install directory&gt;\perl.exe %s %s
GET,HEAD,POST</programlisting>
Change the path to Perl to match your install, of course.</para>
</tip>
</section> </section>
<section id="addlwintips"> <section id="http-iis">
<title>Additional Windows Tips</title> <title>Microsoft <productname>Internet Information Services</productname></title>
<tip> <para>If you need, or for some reason even want, to use Microsoft's
<para>From Andrew Pearson: <productname>Internet Information Services</productname> or
<blockquote> <productname>Personal Web Server</productname> you should be able
<para>You can make Bugzilla work with Personal Web Server for to. You will need to configure them to know how to run CGI scripts,
Windows 98 and higher, as well as for IIS 4.0. Microsoft has however. This is described in Microsoft Knowledge Base article
information available at <ulink url="http://support.microsoft.com/support/kb/articles/Q245/2/25.asp">Q245225 </ulink>
<ulink for <productname>Internet Information Services</productname> and
url=" http://support.microsoft.com/support/kb/articles/Q231/9/98.ASP"> <ulink url="http://support.microsoft.com/support/kb/articles/Q231/9/98.asp">Q231998</ulink>
http://support.microsoft.com/support/kb/articles/Q231/9/98.ASP</ulink> for <productname>Personal Web Server</productname>.
</para> </para>
<para>Basically you need to add two String Keys in the registry at
the following location:</para>
<para> <para>Also, and this can't be stressed enough, make sure that files such as
<programlisting> <filename>localconfig</filename> and your <filename class="directory">data</filename>
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ScriptMap</programlisting> directory are secured as described in <xref linkend="security"/>.
</para> </para>
<para>The keys should be called ".pl" and ".cgi", and both should </section>
have a value something like:
<command>c:/perl/bin/perl.exe "%s" "%s"</command>
</para>
<para>The KB article only talks about .pl, but it goes into more <section id="http-aol">
detail and provides a perl test script.</para> <title>AOL Server</title>
</blockquote>
</para>
</tip>
<tip> <para>Ben FrantzDale reported success using AOL Server with Bugzilla. He
<para>If attempting to run Bugzilla 2.12 or older, you will need to reported his experience and what appears below is based on that.
remove encrypt() calls from the Perl source. This is </para>
<emphasis>not necessary</emphasis>
for Bugzilla 2.13 and later, which includes the current release, <para>AOL Server will have to be configured to run
Bugzilla &amp;bz-ver;. <glossterm linkend="gloss-cgi">CGI</glossterm> scripts, please consult
<example> the documentation that came with your server for more information on
<title>Removing encrypt() for Windows NT Bugzilla version 2.12 or how to do this.
earlier</title> </para>
<para>Replace this: <para>Because AOL Server doesn't support <filename>.htaccess</filename>
<programlisting>SendSQL("SELECT encrypt(" . SqlQuote($enteredpwd) . files, you'll have to create a <glossterm linkend="gloss-tcl">TCL</glossterm>
", " . SQLQuote(substr($realcryptpwd, 0, 2)) . ")"); my script. You should create an <filename>aolserver/modules/tcl/filter.tcl</filename>
$enteredcryptpwd = FetchOneColumn();</programlisting> file (the filename shouldn't matter) with the following contents (change
<computeroutput>/bugzilla/</computeroutput> to the web-based path to
your Bugzilla installation):
</para>
with this: <programlisting>
<programlisting>my $enteredcryptpwd = $enteredpwd</programlisting> ns_register_filter preauth GET /bugzilla/localconfig filter_deny
ns_register_filter preauth GET /bugzilla/*.pl filter_deny
ns_register_filter preauth GET /bugzilla/localconfig filter_deny
ns_register_filter preauth GET /bugzilla/processmail filter_deny
ns_register_filter preauth GET /bugzilla/syncshadowdb filter_deny
ns_register_filter preauth GET /bugzilla/runtests.sh filter_deny
proc filter_deny { why } {
ns_log Notice "filter_deny"
return "filter_return"
}
</programlisting>
in cgi.pl.</para> <warning>
</example> <para>This doesn't appear to account for everything mentioned in
<xref linkend="security"/>. In particular, it doesn't block access
to the <filename class="directory">data</filename> or
<filename class="directory">template</filename> directories. It also
doesn't account for the editor backup files that were the topic of
<ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=186383">bug
186383</ulink>, <ulink
url="http://online.securityfocus.com/bid/6501">Bugtraq ID 6501</ulink>,
and a partial cause for the 2.16.2 release.
</para> </para>
</tip> </warning>
</section> </section>
</section> </section>
<section id="osx">
<title>Mac OS X Installation Notes</title>
<para>There are a lot of common libraries and utilities out there that
Apple did not include with Mac OS X, but which run perfectly well on it.
The GD library, which Bugzilla needs to do bug graphs, is one of
these.</para>
<para>The easiest way to get a lot of these is with a program called
Fink, which is similar in nature to the CPAN installer, but installs
common GNU utilities. Fink is available from
&lt;http://sourceforge.net/projects/fink/&gt;.</para>
<para>Follow the instructions for setting up Fink. Once it's installed,
you'll want to run the following as root:
<command>fink install gd</command>
</para>
<para>It will prompt you for a number of dependencies, type 'y' and hit
enter to install all of the dependencies. Then watch it work.</para>
<para>To prevent creating conflicts with the software that Apple installs
by default, Fink creates its own directory tree at /sw where it installs
most of the software that it installs. This means your libraries and
headers for libgd will be at /sw/lib and /sw/include instead of /usr/lib
and /usr/local/include. Because of these changed locations for the
libraries, the Perl GD module will not install directly via CPAN, because it
looks for the specific paths instead of getting them from your
environment. But there's a way around that :-)</para>
<para>Instead of typing
<quote>install GD</quote>
at the
<prompt>cpan&gt;</prompt>
prompt, type
<command>look GD</command>.
This should go through the motions of downloading the latest version of
the GD module, then it will open a shell and drop you into the build
directory. Apply <ulink url="../sgml/gd-makefile.patch">this patch</ulink>
to the Makefile.PL file (save the
patch into a file and use the command
<command>patch &lt; patchfile</command>.)
</para>
<para>Then, run these commands to finish the installation of the GD
module:
<simplelist>
<member>
<command>perl Makefile.PL</command>
</member>
<member>
<command>make</command>
</member>
<member>
<command>make test</command>
</member>
<member>
<command>make install</command>
</member>
<member>And don't forget to run
<command>exit</command>
to get back to CPAN.</member>
</simplelist>
</para>
</section>
<section id="troubleshooting"> <section id="troubleshooting">
<title>Troubleshooting</title> <title>Troubleshooting</title>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment