Bugzilla:FAQ:Administrative Questions

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, but commits to the database must wait until the tables are unlocked. Bugzilla databases are typically very small, and backups routinely take less than a minute. If your database is larger, you may want to look into alternate backup techniques, such as database replication, or backing up from a read-only mirror. (Read up on these in the MySQL docs on the MySQL site.)

How can I update the code and the database using CVS?

1. 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).
2. Make the Bugzilla directory your current directory.
3. 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.
4. 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 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 bug 162060.

How do I move a Bugzilla installation from one machine to another?

Use mysqldump to make a backup of the bugs database. For a typical Bugzilla setup, such a command might look like this:

/usr/bin/mysqldump -u(username) -p(password) --database bugs > bugzilla-backup.txt

See the mysqldump documentation for more information on using the tool, including how to restore your copy onto the destination machine.

• 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 'user' and 'password' params out of the command line.

On your new machine, follow the instructions found in Chapter 2 as far as setting up the physical environment of the new machine with perl, webserver, modules, etc. Having done that, you can either: copy your entire Bugzilla directory from the old machine to a new one (if you want to keep your existing code and modifications), or download a newer version (if you are planning to upgrade at the same time). Even if you are upgrading to clean code, you will still want to bring over the localconfig file, and the data directory from the old machine, as they contain configuration information that you probably won't want to re-create.

• If the location or port number of your SQL server changed as part of the move, you'll need to update the appropriate variables in localconfig before taking the next step.

Once you have your code in place, and your database has been restored from the backup you made in step 1, run checksetup.pl. This will upgrade your database (if necessary), rebuild your templates, etc.

Bugzilla list of FAQ

General Questions · Managerial Questions · Administrative Questions · Software Matrix · Bugzilla Security · Bugzilla Email · Bugzilla Database · Bugzilla and Win32 · Bugzilla Usage · Bugzilla Hacking