From: Gervase Markham Date: Fri, 19 Sep 2014 12:17:49 +0000 (+0100) Subject: WIP X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=de9f196374fda438717226b11de5861acdcef65e;p=thirdparty%2Fbugzilla.git WIP --- diff --git a/docs/en/rst/installing/moving.rst b/docs/en/rst/installing/moving.rst index 3e5f1f33df..966acda072 100644 --- a/docs/en/rst/installing/moving.rst +++ b/docs/en/rst/installing/moving.rst @@ -15,16 +15,9 @@ things should still work. 1. Shut down your Bugzilla by loading the front page, going to :guilabel:`Administration` | :guilabel:`Parameters` | :guilabel:`General` - and putting some text into the :param:`shutdownhtml` parameter. + and putting some explanatory text into the :param:`shutdownhtml` parameter. -2. Make a backup of the bugs database. For a typical Bugzilla setup using - MySQL, such a command might look like this: - - :command:`mysqldump -u -p bugs > bugzilla-backup.sql` - - See the - `mysqldump documentation `_ - for more information on :file:`mysqldump`. +2. Make a :ref:`backup ` of the bugs database. 3. On your new machine, install Bugzilla using the instructions at :ref:`installing`. Look at the old machine if you need to know what values @@ -41,24 +34,25 @@ things should still work. one, update the :param:`urlbase` parameter in :file:`data/params.json` using a text editor. -7. Copy the database backup file :file:`bugzilla-backup.sql` file from your - old server to the new one. +7. Copy the database backup file from your old server to the new one. -8. Create an empty ``bugs`` database on the new server: +8. Create an empty ``bugs`` database on the new server. For MySQL, that would + look like this: :command:`mysql -u root -p -e "CREATE DATABASE bugs DEFAULT CHARACTER SET utf8;"` -9. Import your :file:`bugzilla-backup.sql` file into your new ``bugs`` database: +9. Import your backup file into your new ``bugs`` database. Again, for MySQL: - :command:`mysql -u root -p bugs < bugzilla-backup.sql` + :command:`mysql -u root -p bugs < $BACKUP_FILE_NAME` If you get an error about "packet too large" or "MySQL server has gone away", you need to adjust the ``max_allowed_packet`` setting in - your :file:`my.cnf` file (usually :file:`/etc/my.cnf`) file to be larger - than the largest attachment ever added to your Bugzilla. + your :file:`my.cnf` file (usually :file:`/etc/my.cnf`) file to match or + exceed the value configured in the same file in your old version of MySQL. - 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 there are *any* errors during this step, you have to work out what + went wrong, and then drop the database, create it again using the step + above, and run the import again. 10. Run :file:`checksetup.pl` to make sure all is OK. (Unless you are using a newer version of Bugzilla on your new server, this @@ -66,6 +60,7 @@ things should still work. :command:`./checksetup.pl` -11. Activate your new Bugzilla by loading the front page, going to - :guilabel:`Administration` | :guilabel:`Parameters` | :guilabel:`General` - and removing the text from the :param:`shutdownhtml` parameter. +11. Activate your new Bugzilla by loading the front page on the new server, + going to :guilabel:`Administration` | :guilabel:`Parameters` | + :guilabel:`General` and removing the text from the :param:`shutdownhtml` + parameter. diff --git a/docs/en/rst/installing/post-install-config.rst b/docs/en/rst/installing/post-install-config.rst index b94f12956a..270743d565 100644 --- a/docs/en/rst/installing/post-install-config.rst +++ b/docs/en/rst/installing/post-install-config.rst @@ -9,8 +9,10 @@ then click :guilabel:`Administration` in the header, and then :guilabel:`Parameters`. You will see the different parameter sections down the left hand side of the page. -Essential -========= +.. _config-essential-params: + +Essential Parameters +==================== There are a few parameters which it is very important to define (or explicitly decide not to change). @@ -38,6 +40,13 @@ If you don't want just anyone able to read your Bugzilla, set the :param:`requirelogin` parameter in the :guilabel:`User Authentication` section, and change or clear the :param:`createemailregexp` parameter. +.. _config-products: + +Products, Components, Versions and Milestones +============================================= + +.. todo:: WRITE ME + .. _optional-features: Optional diff --git a/docs/en/rst/maintaining/backups.rst b/docs/en/rst/maintaining/backups.rst index 1c59dc26f4..bef3c3ada4 100644 --- a/docs/en/rst/maintaining/backups.rst +++ b/docs/en/rst/maintaining/backups.rst @@ -17,6 +17,12 @@ MySQL :command:`mysqldump --opt -u $USERNAME -p $DATABASENAME > backup.sql` +See the +`mysqldump documentation `_ +for more information on :file:`mysqldump`. + +.. todo:: Mention max_allowed_packet? + PostgreSQL ---------- diff --git a/docs/en/rst/upgrading/overview.rst b/docs/en/rst/upgrading/overview.rst index ad081aed3e..cab23521be 100644 --- a/docs/en/rst/upgrading/overview.rst +++ b/docs/en/rst/upgrading/overview.rst @@ -11,13 +11,13 @@ the method by which you obtain the code along the way. upgraded Bugzilla. If you wish to revert to the old Bugzilla version for any reason, you will have to restore your system from a backup. Those with critical data or large installations may wish - to trial the upgrade on a development server first, using a copy of the + to test the upgrade on a development server first, using a copy of the production data and configuration. Bugzilla uses the Git version control system to store its code. A modern Bugzilla installation consists of a checkout of a stable version of the code from our Git repository. This makes upgrading much easier. If this is -true of you, see :ref:`upgrading-with-git`. +true of your installation, see :ref:`upgrading-with-git`. Before Git, we used to use Bazaar and, before that, CVS. If your installation of Bugzilla consists of a checkout from one of those two systems, you need to diff --git a/docs/en/rst/upgrading/upgrading-from-1.rst.inc b/docs/en/rst/upgrading/upgrading-from-1.rst.inc index 0fc333e94f..a53d050d74 100644 --- a/docs/en/rst/upgrading/upgrading-from-1.rst.inc +++ b/docs/en/rst/upgrading/upgrading-from-1.rst.inc @@ -14,7 +14,10 @@ point release for your major version, so if you aren't running that, you may want to do a minor upgrade first. .. todo:: Is this actually necessary? It adds several extra steps. What are we - trying to avoid here? + trying to avoid here? If we do have to do it, can we avoid them + having to work out the latest point release manually? And do the + bzr and CVS update commands take the full version number including + the third digit, or do they just take major and minor? First, you need to find what version of Bugzilla you are using. It should be in the top right corner of the front page but, if not, open the file diff --git a/docs/en/rst/upgrading/upgrading-from-2.rst.inc b/docs/en/rst/upgrading/upgrading-from-2.rst.inc index e7213da0b9..5d413ed777 100644 --- a/docs/en/rst/upgrading/upgrading-from-2.rst.inc +++ b/docs/en/rst/upgrading/upgrading-from-2.rst.inc @@ -76,7 +76,7 @@ Swap The New Version In Now we swap the directories over, and run checksetup.pl to confirm that all is well. From the directory containing the :file:`bugzilla` and -:file:`bugzilla-git` directories, run: +:file:`bugzilla-new` directories, run: :command:`mv bugzilla bugzilla-old` diff --git a/docs/en/rst/upgrading/upgrading-with-git.rst b/docs/en/rst/upgrading/upgrading-with-git.rst index a7067eba2d..6bcf29f15c 100644 --- a/docs/en/rst/upgrading/upgrading-with-git.rst +++ b/docs/en/rst/upgrading/upgrading-with-git.rst @@ -23,9 +23,6 @@ steps to take: Upgraders" sections, if present. They may make you aware of additional considerations. -.. todo:: We need to make these more accessible - they are currently rather hard - to find. We could collate them on a single page with no intervening cruft. - #. Run the :ref:`sanity-check` on your installation. Attempt to fix all warnings that the page produces before you start, or it's possible that you may experience problems during your upgrade. @@ -40,9 +37,8 @@ Customized Bugzilla? If you have modified the code or templates of your Bugzilla, then upgrading requires a bit more thought and effort than the simple process -below. A discussion of the various methods of updating compared with -degree and methods of local customization can be found in -:ref:`template-method`. +below. See :ref:`template-method` for a discussion of the various methods of +customization that may have been used. The larger the jump you are trying to make, the more difficult it is going to be to upgrade if you have made local customizations.