Bugzilla:FAQ:Administrative Questions: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Replaced content with 'See Bugzilla:FAQ#Administrative_Questions.')
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
=[[Bugzilla:FAQ:Administrative_Questions|Administrative Questions]]=
See [[Bugzilla:FAQ#Administrative_Questions]].
==Does Bugzilla provide record locking when there is simultaneous access to the same bug? Does the second person get a notice that the bug is in use or how are they notified?==
Bugzilla does not lock records.
It provides mid-air collision detection --
which means that it warns a user when a commit is about to conflict
with commits recently made by another user,
and offers the second user a choice of options to deal with the conflict.
 
==Can users be on the system while a backup is in progress?==
Yes. You should use the commands included with your database software to run the backups of your Bugzilla data. You can find strategies for dealing with backup considerations at http://www.mysql.com/doc/B/a/Backup.html for MySQL and at http://www.postgresql.org/docs/8.0/static/backup.html for PostgreSQL.
 
== How can I update the code and the database using CVS?==
#Make a backup of both your Bugzilla directory and the database. For the Bugzilla directory this is as easy as doing cp -rp bugzilla bugzilla.bak. For the database, there's a number of options - see the MySQL docs and pick the one that fits you best (the easiest is to just make a physical copy of the database on the disk, but you have to have the database server shut down to do that without risking dataloss).
#Make the Bugzilla directory your current directory.
#Use '''cvs -q update -AdP''' if you want to update to the tip or '''cvs -q update -dP -rTAGNAME''' if you want a specific version (in that case you'll have to replace TAGNAME with a CVS tag name such as BUGZILLA-2_16_5).
#*If you've made no local changes, this should be very clean. If you have made local changes, then watch the cvs output for C results. If you get any lines that start with a C it means there were conflicts between your local changes and what's in CVS. You'll need to fix those manually before continuing.
#After resolving any conflicts that the cvs update operation generated, running ./checksetup.pl will take care of updating the database for you as well as any other changes required for the new version to operate.
#*Once you run checksetup.pl, the only way to go back is to restore the database backups. You can't "downgrade" the system cleanly under most circumstances.
 
See also the instructions in [http://www.bugzilla.org/docs/tip/html/upgrading.html#upgrade-cvs Section3.12.2.1].
 
== How do I make it so that bugs can have an UNCONFIRMED status?==
To use the UNCONFIRMED status,
you must have the 'usevotes' parameter set to "On".
You must then visit the editproducts.cgi page and set the
" Number of votes a bug in this product needs to automatically get
out of the UNCONFIRMED state" to be a non-zero number.
(You will have to do this for each product that wants to use the UNCONFIRMED state.)
If you do not actually want users to be able to vote for bugs entered
against this product, leave the "Maximum votes per person" value at '0'.
 
There is work being done to decouple the UNCONFIRMED state
from the 'usevotes' parameter for future versions of Bugzilla.
Follow the discussion and progress at [https://bugzilla.mozilla.org/show_bug.cgi?id=162060 bug 162060].
 
== How do I move a Bugzilla installation from one machine to another?==
 
1. Use mysqldump to make a backup of the bugs database.
For a typical Bugzilla setup, such a command might look like this:
 
  mysqldump -u(username) -p(password) bugs > bugzilla-backup.sql
 
See the
[http://dev.mysql.com/doc/mysql/en/mysqldump.html mysqldump documentation]
for more information on using the tool.
 
'''Note:''' Depending on the size of your database, and the power of your machine, the mysqldump command could be running long enough that the password would be visible to someone using the ps command. If you are on a multi-user machine, and this is a concern to you, create an entry in the file ~/.my.cnf that looks like this:
[mysqldump]
user=bugs
password=mypassword
and then leave the '-u' and '-p' params out of the command line.
 
2. On your new machine, follow the instructions found in
[http://www.bugzilla.org/docs/tip/html/installing-bugzilla.html Chapter 2]
as far as setting up the physical environment of the new machine with perl,
webserver, modules, etc.
 
3. You have to preserve the <code>data</code> directory and <code>localconfig</code> file from the old Bugzilla installation. So make sure to copy those from your old Bugzilla directory into your new Bugzilla directory. The new Bugzilla can be the same version you were running on the old server, or it can be a newer version.
 
4. If the new URL to your Bugzilla installation is different from the old one, you have to update the "urlbase" parameter in data/params (e.g. using a text editor). Else you may be redirected to your old installation when you log in.
 
5. If anything about your database configuration changed (location of the server, username, password, etc.) as part of the move, you'll need to update the appropriate variables in the <code>localconfig</code> file before taking the next step.
 
6. Copy the <code>bugzilla-backup.sql</code> file from your old server to the new one.
 
7. Create an empty "bugs" database on the new server. First, log in to your MySQL server like:
 
  mysql -u root -p
 
Enter your MySQL root pasword when prompted. Then create the database. If your old installlation was Bugzilla 3.2 or higher and had the "utf8" parameter turned '''on''', then you need to do this command:
 
  CREATE DATABASE bugs DEFAULT CHARACTER SET utf8;
 
If your old installation was before Bugzilla 3.2, or was Bugzilla 3.2 and higher with the utf8 parameter turned '''off'', you must do:
 
  CREATE DATABASE bugs DEFAULT CHARACTER SET latin1;
 
8. Exit MySQL, and import your <code>bugzilla-backup.sql</code> file into your new "bugs" database:
 
  mysql -u (username) -p(password) bugs < /path/to/bugzilla-backup.sql
 
If you get an error about "packet too large" or "mysql server has gone away", you need to adjust the <code>max_allowed_packet</code> setting in your <code>my.cnf</code> (usually in <code>/etc/my.cnf</code>) file to be larger than the largest attachment ever added to your Bugzilla.
 
If there are '''any''' errors during this step, you have to drop the database, create it again using the step above, and do the import again.
 
'''Note:''' If you are importing from a version of MySQL earlier than 4.1, you have to specify <code>--default-character-set=latin1</code> when importing the dump, or your database will be very strange and possibly corrupted, when imported.
 
9. Change to the new Bugzilla directory and run <code>checksetup.pl</code>. Everything at this point works exactly like the normal "Upgrading" or "Configuration" sections from the [http://www.bugzilla.org/docs/ Bugzilla Guide].
 
== How do I migrate previous database to UTF-8 format?==
 
(Needs filling.)
 
{{Navigation Bugzilla FAQ}}
 
[[category:Bugzilla|F]]

Latest revision as of 13:26, 19 March 2010

See Bugzilla:FAQ#Administrative_Questions.

Retrieved from "https://wiki.mozilla.org/index.php?title=Bugzilla:FAQ:Administrative_Questions&oldid=209824"