Bugzilla:FAQ:Administrative Questions - Revision history

MaxKanatAlexander: Replaced content with 'See Bugzilla:FAQ#Administrative_Questions.'

2010-03-19T13:26:04Z

Replaced content with 'See Bugzilla:FAQ#Administrative_Questions.'

← Older revision		Revision as of 13:26, 19 March 2010
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?==~~

	Enable the "utf8" parameter, and then run checksetup.pl. Read the output of checksetup.pl and do exactly what it says to do. Don't try to do any UTF-8 conversion of a Bugzilla database yourself, just follow the instructions.

	~~{{Navigation Bugzilla FAQ}}~~

	~~[[category:Bugzilla\|F]]~~

MaxKanatAlexander: /* How do I migrate previous database to UTF-8 format? */

2010-03-19T05:10:55Z

How do I migrate previous database to UTF-8 format?

← Older revision		Revision as of 05:10, 19 March 2010
Line 90:		Line 90:
	== How do I migrate previous database to UTF-8 format?==		== How do I migrate previous database to UTF-8 format?==

	~~(Needs filling~~.)		Enable the "utf8" parameter, and then run checksetup.pl. Read the output of checksetup.pl and do exactly what it says to do. Don't try to do any UTF-8 conversion of a Bugzilla database yourself, just follow the instructions.

	{{Navigation Bugzilla FAQ}}		{{Navigation Bugzilla FAQ}}

	[[category:Bugzilla\|F]]		[[category:Bugzilla\|F]]

MaxKanatAlexander: /* How do I move a Bugzilla installation from one machine to another? */

2010-03-19T05:09:04Z

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

← Older revision		Revision as of 05:09, 19 March 2010
Line 35:		Line 35:

	== How do I move a Bugzilla installation from one machine to another?==		== How do I move a Bugzilla installation from one machine to another?==
	Use mysqldump to make a backup of the bugs database.
			1. Use mysqldump to make a backup of the bugs database.
	For a typical Bugzilla setup, such a command might look like this:		For a typical Bugzilla setup, such a command might look like this:
	~~/usr/bin/~~mysqldump -u(username) -p(password) ~~--database~~ bugs > bugzilla-backup.~~txt~~
			mysqldump -u(username) -p(password) bugs > bugzilla-backup.sql

	See the		See the
	[http://dev.mysql.com/doc/mysql/en/mysqldump.html mysqldump documentation]		[http://dev.mysql.com/doc/mysql/en/mysqldump.html mysqldump documentation]
	for more information on using the tool,		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:		'''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]		[mysqldump]
	user=bugs		user=bugs
	password=mypassword		password=mypassword
	and then leave the '~~user~~' and '~~password~~' params out of the command line.		and then leave the '-u' and '-p' params out of the command line.

	On your new machine, follow the instructions found in		2. On your new machine, follow the instructions found in
	[http://www.bugzilla.org/docs/tip/html/installing-bugzilla.html Chapter 2]		[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,		as far as setting up the physical environment of the new machine with perl,
	webserver, modules, etc.		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.~~

	~~'''Warning!~~ 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.		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.

	*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~~.		'''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.

	~~Once you have your code in place,~~ and ~~your database has been restored~~		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].
	~~from the backup you made in step 1,~~ run checksetup.pl.
	~~This will upgrade your database (if necessary), rebuild your templates, etc~~.

	== How do I migrate previous database to UTF-8 format?==		== How do I migrate previous database to UTF-8 format?==

LpSolit: /* How do I move a Bugzilla installation from one machine to another? */

2008-01-23T00:14:57Z

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

← Older revision		Revision as of 00:14, 23 January 2008
Line 61:		Line 61:
	as they contain configuration information		as they contain configuration information
	that you probably won't want to re-create.		that you probably won't want to re-create.

			'''Warning! 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.

	*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.		*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.

C1541: /* Can users be on the system while a backup is in progress? */ replace backup info with similar text to that in Managerial Questions section

2008-01-18T12:22:29Z

Can users be on the system while a backup is in progress?: replace backup info with similar text to that in Managerial Questions section

← Older revision		Revision as of 12:22, 18 January 2008
Line 8:		Line 8:

	==Can users be on the system while a backup is in progress?==		==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.~~		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.
	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?==		== How can I update the code and the database using CVS?==

Pkoistin: /* Administrative Questions */

2006-10-30T10:50:53Z

Administrative Questions

← Older revision		Revision as of 10:50, 30 October 2006
Line 73:		Line 73:
	from the backup you made in step 1, run checksetup.pl.		from the backup you made in step 1, run checksetup.pl.
	This will upgrade your database (if necessary), rebuild your templates, etc.		This will upgrade your database (if necessary), rebuild your templates, etc.

			== How do I migrate previous database to UTF-8 format?==

			(Needs filling.)

	{{Navigation Bugzilla FAQ}}		{{Navigation Bugzilla FAQ}}

	[[category:Bugzilla\|F]]		[[category:Bugzilla\|F]]

Tsahi: /* How do I move a Bugzilla installation from one machine to another? */ category|F

2006-06-13T07:58:24Z

How do I move a Bugzilla installation from one machine to another?: category|F

← Older revision		Revision as of 07:58, 13 June 2006
Line 74:		Line 74:
	This will upgrade your database (if necessary), rebuild your templates, etc.		This will upgrade your database (if necessary), rebuild your templates, etc.

	~~[[category:Bugzilla]]~~
	{{Navigation Bugzilla FAQ}}		{{Navigation Bugzilla FAQ}}

			[[category:Bugzilla\|F]]

Wurblzap at 20:44, 28 March 2006

2006-03-28T20:44:32Z

← Older revision		Revision as of 20:44, 28 March 2006
Line 1:		Line 1:
	~~=[[Bugzilla:FAQ:General_Questions\|General Questions]]=~~
	~~=[[Bugzilla:FAQ:Managerial_Questions\|Managerial Questions]]=~~
	=[[Bugzilla:FAQ:Administrative_Questions\|Administrative Questions]]=		=[[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?==		==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?==

Wurblzap: category:Bugzilla; ~nav

2006-03-28T20:40:48Z

category:Bugzilla; ~nav

← Older revision		Revision as of 20:40, 28 March 2006
Line 76:		Line 76:
	This will upgrade your database (if necessary), rebuild your templates, etc.		This will upgrade your database (if necessary), rebuild your templates, etc.

	=[[~~Bugzilla:FAQ:Bugzilla_Security\|Bugzilla Security]]=~~		[[category:Bugzilla]]
	~~=[[Bugzilla:FAQ:Bugzilla_Email\|Bugzilla Email]]=~~		{{Navigation Bugzilla FAQ}}
	~~=[[Bugzilla:FAQ:Bugzilla_Database\|Bugzilla Database]]=~~
	~~=[[Bugzilla~~:~~FAQ:Bugzilla_and_Win32\|~~Bugzilla ~~and Win32~~]]=
	~~=[[~~Bugzilla:FAQ~~:Bugzilla_Usage\|Bugzilla Usage]]=~~
	~~=[[Bugzilla:FAQ:Bugzilla_Hacking\|Bugzilla Hacking]]=~~

Victory: Bugzilla:FAQ 3. Administrative Questions

2006-03-17T08:06:19Z

Bugzilla:FAQ 3. Administrative Questions

New page

=[[Bugzilla:FAQ:General_Questions|General Questions]]=
=[[Bugzilla:FAQ:Managerial_Questions|Managerial Questions]]=
=[[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?==
#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?==
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
[http://dev.mysql.com/doc/mysql/en/mysqldump.html 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
[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.
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:FAQ:Bugzilla_Security|Bugzilla Security]]=
=[[Bugzilla:FAQ:Bugzilla_Email|Bugzilla Email]]=
=[[Bugzilla:FAQ:Bugzilla_Database|Bugzilla Database]]=
=[[Bugzilla:FAQ:Bugzilla_and_Win32|Bugzilla and Win32]]=
=[[Bugzilla:FAQ:Bugzilla_Usage|Bugzilla Usage]]=
=[[Bugzilla:FAQ:Bugzilla_Hacking|Bugzilla Hacking]]=