6160
6167
CLASS="section"
6172
>4.5. UNIX (non-root) Installation Notes</A
6180
>4.5.1. Introduction</A
6183
>If you are running a *NIX OS as non-root, either due
6184
to lack of access (web hosts, for example) or for security
6185
reasons, this will detail how to install Bugzilla on such
6186
a setup. It is recommended that you read through the
6188
HREF="#installation"
6189
>Bugzilla Installation</A
6191
first to get an idea on the installation steps required.
6192
(These notes will reference to steps in that guide.)</P
6203
>You may have MySQL installed as root. If you're
6204
setting up an account with a web host, a MySQL account
6205
needs to be set up for you. From there, you can create
6206
the bugs account, or use the account given to you.</P
6221
SRC="../images/warning.gif"
6228
>You may have problems trying to set up
6232
> permissions to the database.
6233
If you're using a web host, chances are that you have a
6234
separate database which is already locked down (or one big
6235
database with limited/no access to the other areas), but you
6236
may want to ask your system adminstrator what the security
6237
settings are set to, and/or run the <B
6243
>Also, you will probably not be able to change the MySQL
6244
root user password (for obvious reasons), so skip that
6256
>4.5.2.1. Running MySQL as Non-Root</A
6264
>4.5.2.1.1. The Custom Configuration Method</A
6267
>Create a file .my.cnf in your
6268
home directory (using /home/foo in this example)
6279
CLASS="programlisting"
6281
datadir=/home/foo/mymysql
6282
socket=/home/foo/mymysql/thesock
6286
socket=/home/foo/mymysql/thesock
6294
err-log=/home/foo/mymysql/the.log
6295
pid-file=/home/foo/mymysql/the.pid
6308
>4.5.2.1.2. The Custom Built Method</A
6311
>You can install MySQL as a not-root, if you really need to.
6312
Build it with PREFIX set to <TT
6314
>/home/foo/mysql</TT
6316
or use pre-installed executables, specifying that you want
6317
to put all of the data files in <TT
6319
>/home/foo/mysql/data</TT
6321
If there is another MySQL server running on the system that you
6322
do not own, use the -P option to specify a TCP port that is not
6331
>4.5.2.1.3. Starting the Server</A
6334
>After your mysqld program is built and any .my.cnf file is
6335
in place, you must initialize the databases (ONCE).</P
6352
>mysql_install_db</B
6360
>Then start the daemon with</P
6377
>safe_mysql &</B
6385
>After you start mysqld the first time, you then connect to
6389
> permissions to other
6390
users. (Again, the MySQL root account has nothing to do with
6391
the *NIX root account.)</P
6406
SRC="../images/note.gif"
6413
>You will need to start the daemons yourself. You can either
6414
ask your system administrator to add them to system startup files, or
6415
add a crontab entry that runs a script to check on these daemons
6416
and restart them if needed.</P
6435
SRC="../images/warning.gif"
6442
>Do NOT run daemons or other services on a server without first
6443
consulting your system administrator! Daemons use up system resources
6444
and running one may be in violation of your terms of service for any
6445
machine on which you are a user!</P
6462
>On the extremely rare chance that you don't have Perl on
6463
the machine, you will have to build the sources
6464
yourself. The following commands should get your system
6465
installed with your own personal version of Perl:</P
6482
>wget http://perl.com/CPAN/src/stable.tar.gz</B
6490
>tar zvxf stable.tar.gz</B
6499
> (or whatever the version of Perl is called)
6506
>sh Configure -de -Dprefix=/home/foo/perl</B
6514
>make && make test && make install</B
6522
>Once you have Perl installed into a directory (probably
6527
change the locations on the scripts, which is detailed later on
6536
>4.5.4. Perl Modules</A
6539
>Installing the Perl modules as a non-root user is probably the
6540
hardest part of the process. There are two different methods: a
6541
completely independant Perl with its own modules, or personal
6542
modules using the current (root installed) version of Perl. The
6543
independant method takes up quite a bit of disk space, but is
6544
less complex, while the mixed method only uses as much space as the
6545
modules themselves, but takes more work to setup.</P
6552
>4.5.4.1. The Independant Method</A
6555
>The independant method requires that you install your own
6556
personal version of Perl, as detailed in the previous section. Once
6557
installed, you can start the CPAN shell with the following
6576
>/home/foo/perl/bin/perl -MCPAN -e 'shell'</B
6604
>install Bundle::Bugzilla</B
6614
>With this method, module installation will usually go a lot
6615
smoother, but if you have any hang-ups, you can consult the next
6624
>4.5.4.2. The Mixed Method</A
6627
>First, you'll need to configure CPAN to
6628
install modules in your home directory. The CPAN FAQ says the
6629
following on this issue:</P
6640
CLASS="programlisting"
6641
> 5) I am not root, how can I install a module in a personal directory?
6643
You will most probably like something like this:
6645
o conf makepl_arg "LIB=~/myperl/lib \
6646
INSTALLMAN1DIR=~/myperl/man/man1 \
6647
INSTALLMAN3DIR=~/myperl/man/man3"
6648
install Sybase::Sybperl
6650
You can make this setting permanent like all "o conf" settings with "o conf commit".
6652
You will have to add ~/myperl/man to the MANPATH environment variable and also tell your Perl programs to
6653
look into ~/myperl/lib, e.g. by including
6655
use lib "$ENV{HOME}/myperl/lib";
6657
or setting the PERL5LIB environment variable.
6659
Another thing you should bear in mind is that the UNINST parameter should never be set if you are not root.</PRE
6667
>So, you will need to create a Perl directory in your home
6668
directory, as well as the <TT
6683
> directories in that
6684
Perl directory. Set the MANPATH variable and PERL5LIB variable, so
6685
that the installation of the modules goes smoother. (Setting
6686
UNINST=0 in your "make install" options, on the CPAN first-time
6687
configuration, is also a good idea.)</P
6689
>After that, go into the CPAN shell:</P
6707
>perl -MCPAN -e 'shell'</B
6717
>From there, you will need to type in the above "o conf" command
6718
and commit the changes. Then you can run through the installation:</P
6736
>install Bundle::Bugzilla</B
6746
>Most of the module installation process should go smoothly. However,
6747
you may have some problems with Template. When you first start, you will
6748
want to try to install Template with the XS Stash options on. If this
6749
doesn't work, it may spit out C compiler error messages and croak back
6750
to the CPAN shell prompt. So, redo the install, and turn it off. (In fact,
6751
say no to all of the Template questions.) It may also start failing on a
6752
few of the tests. If the total tests passed is a reasonable figure (90+%),
6753
force the install with the following command:</P
6771
>force install Template</B
6781
>You may also want to install the other optional modules:</P
6806
>install Chart::Base</B
6814
>install MIME::Parser</B
6829
>4.5.5. HTTP Server</A
6832
>Ideally, this also needs to be installed as root and
6833
run under a special webserver account. As long as
6834
the web server will allow the running of *.cgi files outside of a
6835
cgi-bin, and a way of denying web access to certain files (such as a
6836
.htaccess file), you should be good in this department.</P
6843
>4.5.5.1. Running Apache as Non-Root</A
6846
>You can run Apache as a non-root user, but the port will need
6847
to be set to one above 1024. If you type <B
6851
you will get a list of the variables that your system copy of httpd
6852
uses. One of those, namely HTTPD_ROOT, tells you where that
6853
installation looks for its config information.</P
6855
>From there, you can copy the config files to your own home
6856
directory to start editing. When you edit those and then use the -d
6857
option to override the HTTPD_ROOT compiled into the web server, you
6858
get control of your own customized web server.</P
6873
SRC="../images/note.gif"
6880
>You will need to start the daemons yourself. You can either
6881
ask your system administrator to add them to system startup files, or
6882
add a crontab entry that runs a script to check on these daemons
6883
and restart them if needed.</P
6902
SRC="../images/warning.gif"
6909
>Do NOT run daemons or other services on a server without first
6910
consulting your system administrator! Daemons use up system resources
6911
and running one may be in violation of your terms of service for any
6912
machine on which you are a user!</P
6928
>Since you probably can't set up a symbolic link to
6931
>/usr/bonsaitools/bin/perl</TT
6932
> as a non-root user,
6933
you will need to hack the scripts to point to the right Perl:</P
6944
CLASS="programlisting"
6946
's@#\!/usr/bonsaitools/bin/perl@#\!/usr/bin/perl@' *cgi *pl Bug.pm
6947
processmail syncshadowdb</PRE
6957
> to match the location
6958
of Perl on your machine. If you had to install Perl as non-root,
6959
this would be the location in your home directory.
6975
SRC="../images/note.gif"
6982
>Version 2.17+ of Bugzilla now already has the scripts
6992
>Of course, the scripts will not work if they don't know the
6993
location of your newly install Perl modules, so you will have to hack
6994
the scripts to look for those, too:</P
7005
CLASS="programlisting"
7007
's@use strict\;@use strict\; use lib \"/home/foo/perl/lib\"\;@'
7008
*cgi *pl Bug.pm processmail syncshadowdb</PRE
7017
>/home/foo/perl/lib</TT
7019
your personal Perl library directory. You can probably skip this
7020
step if you are using the independant method of Perl module
7031
> file, it will list the Perl
7032
modules it finds. If one is missing, go back and double-check the
7033
module installation from the CPAN shell, then delete the
7037
> file and try again.</P
7052
SRC="../images/warning.gif"
7059
>The one option in <TT
7063
might have problems with is the web server group. If you can't
7064
successfully browse to the <TT
7068
a Forbidden error), you may have to relax your permissions,
7069
and blank out the web server group. Of course, this may pose
7070
as a security risk. Having a properly jailed shell and/or
7071
limited access to shell accounts may lessen the security risk,
7072
but use at your own risk.</P
6162
7082
CLASS="section"
6164
7084
NAME="troubleshooting"
6166
>4.5. Troubleshooting</H1
7085
>4.6. Troubleshooting</A
6168
7088
>This section gives solutions to common Bugzilla installation
6172
7092
CLASS="section"
6174
7094
CLASS="section"
6178
>4.5.1. Bundle::Bugzilla makes me upgrade to Perl 5.6.1</H2
7097
>4.6.1. Bundle::Bugzilla makes me upgrade to Perl 5.6.1</A
6180
7100
> Try executing <B
6181
7101
CLASS="command"
12153
NAME="faq-phb-reloginEveryone"
12158
Why do users have to log in every time they access a page? This
12159
affects everyone who accesses my Bugzilla. (If this only affects
12160
some of your users, see the next FAQ item.)
12169
The most-likely cause is that the "cookiepath" parameter is not set
12170
correctly in the Bugzilla configuration. You can change this (if
12171
you're a Bugzilla administrator) from the editparams.cgi page
12175
> The value of the cookiepath parameter should be the actual directory
12176
containing your Bugzilla installation, <EM
12178
end-user's web browser</EM
12179
>. Leading and trailing slashes are
12180
mandatory. You can also set the cookiepath to any directory which
12181
is a parent of the Bugzilla directory (such as '/', the root
12182
directory). But you can't put something that isn't at least
12183
a partial match or it won't work. What you're actually doing
12184
is restricting the end-user's browser to sending the cookies
12185
back only to that directory.
12188
> How do you know if you want your specific Bugzilla directory or the
12192
> If you have only one Bugzilla running on the server, and you
12193
don't mind having other applications on the same server with it
12194
being able to see the cookies (you might be doing this on purpose
12195
if you have other things on your site that share authentication with
12196
Bugzilla), then you'll want to have the cookiepath set to "/", or to
12197
a sufficiently-high enough directory that all of the involved apps
12198
can see the cookies.
12209
CLASS="literallayout"
12211
urlbase is <A
12212
HREF="http://bugzilla.mozilla.org/"
12214
>http://bugzilla.mozilla.org/</A
12216
cookiepath is /<br>
12218
urlbase is <A
12219
HREF="http://tools.mysite.tld/bugzilla/"
12221
>http://tools.mysite.tld/bugzilla/</A
12223
but you have http://tools.mysite.tld/someotherapp/ which shares<br>
12224
authentication with your Bugzilla<br>
12225
cookiepath is /<br>
12226
</P
12231
> On the other hand, if you have more than one Bugzilla
12232
running on the server (some people do - we do on landfill)
12233
then you need to have the cookiepath restricted enough
12234
so that the different Bugzillas don't
12235
confuse their cookies with one another.
12246
CLASS="literallayout"
12248
urlbase is <A
12249
HREF="http://landfill.bugzilla.org/bugzilla-tip/"
12251
>http://landfill.bugzilla.org/bugzilla-tip/</A
12253
cookiepath is /bugzilla-tip/<br>
12255
urlbase is <A
12256
HREF="http://landfill.bugzilla.org/bugzilla-2.16-branch/"
12258
>http://landfill.bugzilla.org/bugzilla-2.16-branch/</A
12260
cookiepath is /bugzilla-2.16-branch/<br>
12261
</P
12266
> If you had cookiepath set to / at any point in the past and
12267
need to set it to something more restrictive (i.e. /bugzilla/),
12268
you can safely do this without requiring users to delete
12269
their Bugzilla-related cookies in their browser (this is
12270
true starting with Bugzilla 2.17.7 and Bugzilla 2.16.5).
12280
NAME="faq-phb-reloginSome"
12285
Why do users have to log in every time they access a page? This
12286
only seems to affect some of my Bugzilla's users, others stay
12296
First, make sure cookies are enabled in the user's browser.
12299
> If that doesn't fix the problem, it may be that
12300
the user's ISP implements a rotating proxy server. This causes
12301
the user's effective IP address (the address which the Bugzilla server
12302
perceives him coming from) to change periodically. Since
12303
Bugzilla cookies are tied to a specific IP address, each time
12304
the effective address changes, the user will have to log in again.
12307
> In newer versions of Bugzilla (2.17.1 and later) there is a
12308
parameter called "loginnetmask", which you can use to set the
12309
number of bits of the user's IP address to require to be matched
12310
when authenticating the cookies. If you set this to something less
12311
than 32, then the user will be given a checkbox for "Restrict this
12312
login to my IP address" on the login screen, which defaults to
12313
checked. If they leave the box checked, Bugzilla will behave the
12314
same as it did before, requiring an exact match on their IP address
12315
to remain logged in. If they uncheck the box, then only the left
12316
side of their IP address (up to the number of bits you specified in
12317
the parameter) has to match to remain logged in.
11066
12323
CLASS="qandadiv"