[Rt-commit] rt branch, 4.0/upgrading-docs, created. rt-4.0.0rc6-41-g1b0da4e

Alex Vandiver alexmv at bestpractical.com
Mon Mar 14 19:38:11 EDT 2011


The branch, 4.0/upgrading-docs has been created
        at  1b0da4ee35397b5e092c50cef4c823c2a6d1c1d3 (commit)

- Log -----------------------------------------------------------------
commit 1b0da4ee35397b5e092c50cef4c823c2a6d1c1d3
Author: Alex Vandiver <alexmv at bestpractical.com>
Date:   Mon Mar 14 19:36:42 2011 -0400

    Fold UPGRADING into README, update prose
    
    This reduces the confusion of having two competing, slightly differing
    instruction sets for how to upgrade an existing RT instance.  It also
    rewords several sections to be more grammatical, and moves
    UPGRADING.mysql into doc/ with the rest of the supplemental upgrading
    instructions.

diff --git a/README b/README
index fd23960..971bbe1 100644
--- a/README
+++ b/README
@@ -2,17 +2,17 @@ RT is an enterprise-grade issue tracking system. It allows organizations
 to keep track of what needs to get done, who is working on which tasks,
 what's already been done, and when tasks were (or weren't) completed.
 
-RT doesn't cost anything to use, no matter how much you use it; it
-is freely available under the terms of Version 2 of the GNU General
-Public License.
+RT doesn't cost anything to use, no matter how much you use it; it is
+freely available under the terms of Version 2 of the GNU General Public
+License.
 
 RT is commercially-supported software. To purchase support, training,
 custom development, or professional services, please get in touch with
-us at sales at bestpractical.com.
+us at <sales at bestpractical.com>.
 
      Jesse Vincent
      Best Practical Solutions, LLC
-     March, 2010
+     March, 2011
 
 
 REQUIRED PACKAGES
@@ -20,8 +20,8 @@ REQUIRED PACKAGES
 
 o   Perl 5.8.3 or later (http://www.perl.org).
 
-        Perl versions prior to 5.8.3 contain bugs that could result
-        in data corruption. RT won't start on older versions.
+        Perl versions prior to 5.8.3 contain bugs that could result in
+        data corruption. RT won't start on older versions.
 
 o   A supported SQL database
 
@@ -38,163 +38,164 @@ o   Apache version 1.3.x or 2.x (http://httpd.apache.org)
         RT's FastCGI handler needs to access RT's configuration file.
 
 o   Various and sundry perl modules
-        A tool included with RT takes care of the installation of
-        most of these automatically during the install process.
 
-        The tool supplied with RT uses Perl's CPAN system
-        (http://www.cpan.org) to install modules. Some operating
-        systems package all or some of the modules required, and
-        you may be better off installing the modules that way.
+        A tool included with RT takes care of the installation of most
+        of these automatically during the install process.
+
+        The tool supplied with RT uses Perl's CPAN (http://www.cpan.org)
+        to install modules. Some operating systems package all or some
+        of the modules required, and you may be better off installing
+        the modules that way.
 
 
 GENERAL INSTALLATION
 --------------------
 
-1   Unpack this distribution other than where you want to install RT
+ 1) Unpack this distribution other than where you want to install RT.
+    To do this cleanly, run the following command:
 
-     To do this cleanly, run the following command:
+        tar xzvf rt.tar.gz -C /tmp
 
-       tar xzvf rt.tar.gz -C /tmp
+ 2) Run the "configure" script.  To see the list of options, run:
 
-2   Run the "configure" script.
+        ./configure --help
 
-       ./configure --help to see the list of options
-       ./configure (with the flags you want)
+    Peruse the options, then rerun ./configure with the flags you want.
 
     RT defaults to installing in /opt/rt4 with MySQL as its database. It
-    tries to guess which of www-data, www, apache or nobody your webserver
-    will run as, but you can override that behavior.  Note that the
-    default install directory in /opt/rt4 does not work under SELinux's
-    default configuration.
-
-    If you're upgrading RT please review the UPGRADING document at
-    this point. Some extensions you are using may have been integrated into the
-    core or there may be extra upgrade scripts to run. Use a new, clean
-    directory when you're upgrading to a new major release (for example
-    from 3.6.x to 3.8.x or to 4.0.x).
-
-3   Make sure that RT has everything it needs to run.
-
+    tries to guess which of www-data, www, apache or nobody your
+    webserver will run as, but you can override that behavior.  Note
+    that the default install directory in /opt/rt4 does not work under
+    SELinux's default configuration.
+
+    If you are upgrading from a previous version of RT, please review
+    the upgrade notes for the appropriate versions, which can be found
+    in docs/UPGRADING-* If you are coming from 3.8.6 to 4.0.x you should
+    review both the UPGRADING-3.8 and UPGRADING-4.0 file.  Similarly, if
+    you were coming from 3.6.7, you would want to review UPGRADING-3.6,
+    UPGRADING-3.8 and UPGRADING-4.0
+
+    It is particularly important that you read the warnings at the top of
+    UPGRADING-4.0 for some common issues.
+
+ 3) Make sure that RT has the Perl and system libraries it needs to run.
     Check for missing dependencies by running:
 
-       make testdeps
+        make testdeps
 
-4   If the script reports any missing dependencies, install them by hand
-    or run the following command as a user who has permission to install perl
-    modules on your system:
+ 4) If the script reports any missing dependencies, install them by
+    hand, or run the following command as a user who has permission to
+    install perl modules on your system:
 
-       make fixdeps
+        make fixdeps
 
     Some modules require user input or environment variables to install
     correctly, so it may be necessary to install them manually.
 
-    If you are installing with CPAN module older than 1.84, you will need to
-    start CPAN (by running perl -MCPAN -e shell) and upgrade the CPAN shell
-    with:
-
-       install CPAN
-
-    If you are unsure of your CPAN version, it will be printed when you run the
-    shell.
+    If you are installing with CPAN module older than 1.84, you will
+    need to start CPAN (by running perl -MCPAN -e shell) and upgrade the
+    CPAN shell with:
 
-    If you are having trouble installing GD or Graphviz, you should install
-    gd-devel and the graphviz libraries using your distribution's package
-    manager.
+        install CPAN
 
-5   Check to make sure everything was installed properly.
+    If you are unsure of your CPAN version, it will be printed when you
+    run the shell.
 
-       make testdeps
+    If you are having trouble installing GD or Graphviz, you should
+    install gd-devel and the graphviz libraries using your
+    distribution's package manager.
 
-     It might sometimes be necessary to run "make fixdeps" several times
-     to install all necessary perl modules.
+ 5) Check to make sure everything was installed properly.
 
-6   If this is a new installation (not an upgrade):
+        make testdeps
 
-     As a user with permission to install RT in your chosen directory, type:
+    It might sometimes be necessary to run "make fixdeps" several times
+    to install all necessary perl modules.
 
-       make install
+6a) If this is a NEW installation (not an upgrade):
 
-     To configure RT with the web installer, run:
+      As a user with permission to install RT in your chosen directory,
+      type:
 
-       /opt/rt4/sbin/rt-server
+          make install
 
-     and follow the instructions.  Once completed, you should now have
-     a working RT instance running with te standalone rt-server.
-     Press Ctrl-C to stop it, and proceed to Step 9 to configure
-     recommended deployment environment for production.
+      To configure RT with the web installer, run:
 
-     To configure RT manually, you must setup etc/RT_SiteConfig.pm in
-     your RT installation directory.  You'll need to add any values
-     you need to change from the defaults in etc/RT_Config.pm
+          /opt/rt4/sbin/rt-server
 
-     As a user with permission to read RT's configuration file, type:
+      and follow the instructions.  Once completed, you should now have a
+      working RT instance running with the standalone rt-server.  Press
+      Ctrl-C to stop it, and proceed to Step 7 to configure recommended
+      deployment environment for production.
 
-       make initialize-database
+      To configure RT manually, you must setup etc/RT_SiteConfig.pm in
+      your RT installation directory.  You'll need to add any values you
+      need to change from the defaults in etc/RT_Config.pm
 
-     If the make fails, type:
+      As a user with permission to read RT's configuration file, type:
 
-       make dropdb
+          make initialize-database
 
-     and start over from step 6
+      If the make fails, type:
 
-7   If you're upgrading from RT 3.0 or newer:
+          make dropdb
 
-     Read through the UPGRADING document included in this distribution. If
-     you're using MySQL, read through UPGRADING.mysql as well.
+      and re-run 'make initialize-database'.
 
-     It includes special upgrade instructions that will help you get this
-     new version of RT up and running smoothly.
+6b) If you are UPGRADING from a previous installation:
 
-     As a user with permission to install RT in your chosen installation
-     directory, type:
+      Before upgrading, always ensure that you have a complete current
+      backup. If you don't have a current backup, upgrading your database
+      could accidentally damage it and lose data, or worse.
 
-       make upgrade
+      If you are using MySQL, please read the instructions in
+      docs/UPGRADING.mysql as well to ensure that you do not corrupt
+      existing data.
 
-     This will install new binaries, config files and libraries without
-     overwriting your RT database.
+      First, stop your webserver.  You may also wish to put incoming email
+      into a hold queue, to avoid temporary delivery failure messages if
+      your upgrade is expected to take several hours.
 
-     Update etc/RT_SiteConfig.pm in your RT installation directory.
-     You'll need to add any new values you need to change from the defaults
-     in etc/RT_Config.pm
+      Next, install new binaries, config files and libraries by running:
 
-     You may also need to update RT's database.  You can do this with
-     the rt-setup-database tool.  Replace root with the name of the dba
-     user on your database (root is the default for MySQL).
+          make upgrade
 
-     You will be prompted for your previous version of RT (such as 3.6.4)
-     so that we can calculate which database updates to apply
+      This will also display the appropriate rt-setup-database command to
+      upgrade your database.  You should back up your database before
+      running this command.  When you run it, you will be prompted for
+      your previous version of RT (such as 3.6.4) so that the appropriate
+      set of database upgrades can be applied.
 
-     You should back up your database before running this command.
+      Finally, clear the Mason cache dir:
 
-       /opt/rt4/sbin/rt-setup-database --dba root --prompt-for-dba-password --action upgrade
+          rm -fr /opt/rt4/var/mason_data/obj
 
-     Clear mason cache dir:
+      You may then start your web server again.
 
-       rm -fr /opt/rt4/var/mason_data/obj
+ 7) Configure the web server, as described in docs/web_deployment.pod,
+    and the email gateway, as described below.
 
-     Stop and start web-server.
+    NOTE: root's password for the web interface is "password" (without
+    the quotes).  Not changing this is a SECURITY risk!
 
+    Once you've set up the web interface, consider setting up automatic
+    logout for inactive sessions. For more information about how to do
+    that, run:
 
-8  If you're upgrading from RT 2.0:
+        perldoc /path/to/rt/sbin/rt-clean-sessions
 
-    Read more in UPGRADING and docs/UPGRADING-2.x
+ 8) Set up users, groups, queues, scrips and access control.
 
-9  Configure the web server, as described in docs/web_deployment.pod, and
-   the email gateway, as described below.
+    Until you do this, RT will not be able to send or receive email, nor
+    will it be more than marginally functional.  This is not an optional
+    step.
 
-     NOTE: root's password for the web interface is "password"
-     (without the quotes).  Not changing this is a SECURITY risk!
-
-     Once you've set up the web interface, consider setting up automatic
-     logout for inactive sessions. For more information about how to do that,
-     run: perldoc /path/to/rt/sbin/rt-clean-sessions
-
-10  Set up automated recurring tasks (cronjobs):
+ 9) Set up automated recurring tasks (cronjobs):
 
     To generate email digest messages, you must arrange for the provided
     utility to be run once daily, and once weekly. You may also want to
-    arrange for the rt-email-dashboards utility to be run hourly.
-    For example, if your task scheduler is cron, you can configure it as
+    arrange for the rt-email-dashboards utility to be run hourly.  For
+    example, if your task scheduler is cron, you can configure it as
     follows:
 
         crontab -e    # as the RT administrator (probably root)
@@ -203,64 +204,42 @@ GENERAL INSTALLATION
         0 0 * * 0 /opt/rt4/sbin/rt-email-digest -m weekly
         0 * * * * /opt/rt4/sbin/rt-email-dashboards
 
+10) Configure the RT email gateway.  To let email flow to your RT
+    server, you need to add a few lines of configuration to your mail
+    server's "aliases" file. These lines "pipe" incoming email messages
+    from your mail server to RT.
 
-11   Set up users, groups, queues, scrips and access control.
-
-    Until you do this, RT will not be able to send or receive email,
-    nor will it be more than marginally functional.  This is not an
-    optional step.
-
-
-SETTING UP THE MAIL GATEWAY
----------------------------
+    Add the following lines to /etc/aliases (or your local equivalent)
+    on your mail server:
 
-To let email flow to your RT server, you need to add a few lines of
-configuration to your mail server's "aliases" file. These lines "pipe"
-incoming email messages from your mail server to RT.
+        rt:         "|/opt/rt4/bin/rt-mailgate --queue general --action correspond --url http://rt.example.com/"
+        rt-comment: "|/opt/rt4/bin/rt-mailgate --queue general --action comment --url http://rt.example.com/"
 
-Add the following lines to /etc/aliases (or your local equivalent) on your mail server:
-
-rt:         "|/opt/rt4/bin/rt-mailgate --queue general --action correspond --url http://rt.example.com/"
-rt-comment: "|/opt/rt4/bin/rt-mailgate --queue general --action comment --url http://rt.example.com/"
-
-You'll need to add similar lines for each queue you want to be able
-to send email to. To find out more about how to configure RT's email
-gateway, type:
-
-       perldoc /opt/rt4/bin/rt-mailgate
+    You'll need to add similar lines for each queue you want to be able to
+    send email to. To find out more about how to configure RT's email
+    gateway, type:
 
+           perldoc /opt/rt4/bin/rt-mailgate
 
 
 GETTING HELP
 ------------
 
-If RT is mission-critical for you or if you use it heavily, we recommend that
-you purchase a commercial support contract.  Details on support contracts
-are available at http://www.bestpractical.com or by writing to
+If RT is mission-critical for you or if you use it heavily, we recommend
+that you purchase a commercial support contract.  Details on support
+contracts are available at http://www.bestpractical.com or by writing to
 <sales at bestpractical.com>.
 
-If you're interested in having RT extended or customized or would like more
-information about commercial support options, please send email to
+If you're interested in having RT extended or customized or would like
+more information about commercial support options, please send email to
 <sales at bestpractical.com> to discuss rates and availability.
 
 
+MAILING LISTS AND WIKI
+----------------------
 
-RT WEBSITE
-----------
-
-For current information about RT, check out the RT website at
-     http://www.bestpractical.com/
-
-You'll find screenshots, a pointer to the current version of RT, contributed
-patches, and lots of other great stuff.
-
-
-
-RT-USERS MAILING LIST
----------------------
-
-To keep up to date on the latest RT tips, techniques and extensions,
-you probably want to join the rt-users mailing list.  Send a message to:
+To keep up to date on the latest RT tips, techniques and extensions, you
+may wish to join the rt-users mailing list.  Send a message to:
 
       rt-users-request at lists.bestpractical.com
 
@@ -270,25 +249,33 @@ with the body of the message consisting of only the word:
 
 If you're interested in hacking on RT, you'll want to subscribe to
 <rt-devel at lists.bestpractical.com>.  Subscribe to it with instructions
-similar to those above.
+similar to those above.  Address questions about the stable release to
+the rt-users list, and questions about the development version to the
+rt-devel list.
+
+The RT wiki, at http://requesttracker.wikia.com/ , is also a potential
+resource.
+
 
-Address questions about the stable release to the rt-users list, and
-questions about the development version to the rt-devel list.  If you feel
-your questions are best not asked publicly, send them personally to
-<jesse at bestpractical.com>.
+SECURITY
+--------
 
+If you believe you've discovered a security issue in RT, please send an
+email to <security at bestpractical.com> with a detailed description of the
+issue, and a secure means to respond to you (such as your PGP public
+key).
 
 
 BUGS
 ----
 
 RT's a pretty complex application, and as you get up to speed, you might
-run into some trouble. Generally, it's best to ask about things you
-run into on the rt-users mailinglist (or pick up a commercial support
-contract from Best Practical). But, sometimes people do run into bugs. In
-the exceedingly unlikely event that you hit a bug in RT, please report
-it! We'd love to hear about problems you have with RT, so we can fix them.
-To report a bug, send email to rt-bugs at fsck.com.
+run into some trouble. Generally, it's best to ask about things you run
+into on the rt-users mailinglist (or pick up a commercial support
+contract from Best Practical). But, sometimes people do run into
+bugs. In the exceedingly unlikely event that you hit a bug in RT, please
+report it! We'd love to hear about problems you have with RT, so we can
+fix them.  To report a bug, send email to <rt-bugs at fsck.com>.
 
 
 # BEGIN BPS TAGGED BLOCK {{{
diff --git a/UPGRADING b/UPGRADING
deleted file mode 100644
index 2c7faee..0000000
--- a/UPGRADING
+++ /dev/null
@@ -1,15 +0,0 @@
-Before making any changes to your database, always ensure that you have a 
-complete current backup. If you don't have a current backup, you could 
-accidentally damage your database and lose data or worse.
-
-If you are using MySQL, please read the instructions in UPGRADING.mysql as
-well to ensure that you do not lose data in your upgrade.
-
-We have moved large upgrade changes and steps into
-docs/UPGRADING-version files which you should refer to for specific
-instructions.  If you are coming from 3.8.6 to 4.0.x you should review
-both the 3.8 and 4.0 file.  Similarly, if you were coming from 3.6.7,
-you would want to review 3.6, 3.8 and 4.0
-
-It is particularly important that you read the warnings at the top of
-UPGRADING-4.0 for some common issues.
diff --git a/UPGRADING.mysql b/UPGRADING.mysql
deleted file mode 100644
index 37b0dda..0000000
--- a/UPGRADING.mysql
+++ /dev/null
@@ -1,86 +0,0 @@
-MySQL 4.1 and greater implemented changes in character set handling
-that may result in RT failures: multiple login requests, binary attachments
-breakage, image custom fields breakage and more.
-
-In order to resolve this issue we've changed our schema for MySQL 4.1 and
-greater versions.
-
-If you're installing a new RT then you can skip this file.
-
-If you're migrating from MySQL 4.0 to MySQL 4.1 and newer then you MUST follow
-instructions at the bottom of this file.
-
-If you're upgrading RT from versions prior to 3.8.0 then you MUST follow
-instructions below even if your old RT was installed on MySQL 4.1 or newer.
-
-=== Upgrading RT from versions prior to 3.8.0 ===
-
-1) Backup RT's database. Use --default-character-set=binary if mysql
-server is 4.1 or newer. Test that you can restore from this backup.
-
-2) Follow instructions in the README file to step 7.
-
-3) Apply changes described in step 7, but only up to version 3.7.87.
-
-4) Apply the RT 3.8 schema upgrades. Included in RT is the script
-etc/upgrade/upgrade-mysql-schema.pl that generates SQL queries to 
-upgrade the database's schema. Run it:
-
-    perl etc/upgrade/upgrade-mysql-schema.pl db user pass > queries.sql
-
-If your mysql database is on a remote host, you can run the script
-like this instead
-
-    perl etc/upgrade/upgrade-mysql-schema.pl db:host user pass > queries.sql
-
-5) Check sanity of the SQL queries yourself or consult with your DBA.
-
-6) Apply the queries. Note that this step can take a while. It may require
-additional space on your hard drive comparable with size of your tables.
-
-    mysql -u root -p rt3 < queries.sql
-
-NOTE that 'rt3' is the default name of the RT database, change it in the
-command above if you're using a different name.
-
-This step should not produce any errors or warnings. If you see any, restore
-your database from the backup you made at step 1) and send a report to the
-rt-users at lists.bestpractical.com mailing list.
-
-7) Continue from step 7 in the README and apply other upgrades and 
-follow the remaining steps.
-
-8) Test everything. The most important parts you have to test:
-* binary attachments, like docs, PDFs, and images
-* binary custom fields
-* everything that may contain characters other than ASCII
-
-=== Migrating from MySQL 4.0 to MySQL 4.1 and newer ===
-
-Upgrading both MySQL and RT at the same time is a bad idea. The process becomes
-more complicated, more time consuming, greater chance to fail, and much harder
-to debug.
-
-It's better to perform the upgrade in two steps. First upgrade MySQL from 4.0
-to 4.1 or newer. Remember the following:
-
-* Don't use utf8 as MySQL's character set. This is the default in some
-  Linux distributions.
-* import/export MySQL dumps using binary character set.
-
-When you're sure that everything is fine, you may upgrade RT using the
-instructions above.
-
-If you still want to upgrade MySQL and RT simultaneously, then you can
-do the following:
-
-1) Install a new RT on MySQL 4.1 or newer.
-2) Test that this new clean RT works on this new database.
-3) Dump the database from MySQL 4.0.
-4) Configure MySQL 4.1 and newer to use Latin1 as default character set
-   everywhere.
-5) Import the dump into the new MySQL server, replacing your empty database you
-   created at step 1, use --default-character-set=binary on restore.
-6) At this point you have RT 3.8.x code base using an old database. You can
-   upgrade RT using the instructions above.
-
diff --git a/docs/UPGRADING-2.0 b/docs/UPGRADING-2.0
new file mode 100644
index 0000000..a935552
--- /dev/null
+++ b/docs/UPGRADING-2.0
@@ -0,0 +1,7 @@
+UPGRADING FROM 2.x:
+
+The core RT distribution does not contain the tool to upgrade RT from
+version 2.0; the tool, can be downloaded from CPAN at
+http://search.cpan.org/dist/RT-Extension-RT2toRT3/
+
+Further instructions may be found in that distribution's README file.
diff --git a/docs/UPGRADING-2.x b/docs/UPGRADING-2.x
deleted file mode 100644
index 40f5fda..0000000
--- a/docs/UPGRADING-2.x
+++ /dev/null
@@ -1,3 +0,0 @@
-UPGRADING FROM 2.x:
-
-See http://search.cpan.org/dist/RT-Extension-RT2toRT3/
diff --git a/docs/UPGRADING.mysql b/docs/UPGRADING.mysql
new file mode 100644
index 0000000..1064075
--- /dev/null
+++ b/docs/UPGRADING.mysql
@@ -0,0 +1,98 @@
+MySQL 4.1 and greater implemented changes in character set handling that
+may result in RT failures; specifically, multiple login requests, binary
+attachments breakage, image custom fields breakage and more.  In order
+to resolve this issue, we've changed our schema for MySQL 4.1 and above.
+
+If you're installing a new RT installation, you can skip this file
+entirely.
+
+If you're migrating from MySQL 4.0 to MySQL 4.1 or above, then you MUST
+follow instructions at the bottom of this file.
+
+If you're upgrading RT from versions prior to 3.8.0 then you MUST follow
+instructions below even if your old RT was installed on MySQL 4.1 or
+newer.
+
+
+
+=== Upgrading RT from versions prior to 3.8.0 ===
+
+ 1) Backup RT's database. Use --default-character-set=binary if mysql
+    server is 4.1 or newer. Test that you can restore from this backup.
+
+ 2) Follow instructions in the README file to step 6b.
+
+ 3) Apply changes described in step 6b, but only up to version 3.7.87.
+
+ 4) Apply the RT 3.8 schema upgrades. Included in RT is the script
+    etc/upgrade/upgrade-mysql-schema.pl that will generate the
+    appropriate SQL queries:
+
+        perl etc/upgrade/upgrade-mysql-schema.pl db user pass > queries.sql
+
+    If your mysql database is on a remote host, you can run the script
+    like this instead:
+
+        perl etc/upgrade/upgrade-mysql-schema.pl db:host user pass > queries.sql
+
+ 5) Check the sanity of the SQL queries in the queries.sql file
+    yourself, or consult with your DBA.
+
+ 6) Apply the queries. Note that this step can take a while; it may also
+    require additional space on your hard drive comparable with size of
+    your tables.
+
+        mysql -u root -p rt3 < queries.sql
+
+    NOTE that 'rt3' is the default name of the RT database, change it in
+    the command above if your database is named differently.
+
+    This step should not produce any errors or warnings. If you see any,
+    restore your database from the backup you made at step 1, and send a
+    report to the rt-users at lists.bestpractical.com mailing list.
+
+ 7) Re-run the rt-setup-database command from step 6b of the README,
+    applying the rest of the upgrades, and follow the README's remaining
+    steps.
+
+ 8) Test everything. The most important parts you have to test:
+     * binary attachments, like docs, PDFs, and images
+     * binary custom fields
+     * everything that may contain characters other than ASCII
+
+
+
+=== Migrating from MySQL 4.0 to MySQL 4.1 and newer ===
+
+Upgrading both MySQL and RT at the same time is a bad idea. The process
+becomes more complicated, more time consuming, has a greater chance to
+fail, and is much harder to debug.
+
+It is a much better idea to perform the upgrade in two steps. First
+upgrade MySQL from 4.0 to 4.1 or above, then complete the RT
+upgrade. Remember the following:
+
+* Don't use utf8 as MySQL's character set. This is the default in some
+  Linux distributions.
+* import/export MySQL dumps using binary character set.
+
+When you're sure that everything is fine, you may upgrade RT using the
+instructions above.
+
+If you still want to upgrade MySQL and RT simultaneously, then you can
+do the following:
+
+ 1) Install a new RT on MySQL 4.1 or newer.
+
+ 2) Test that this new clean RT works on this new database.
+
+ 3) Dump the database from MySQL 4.0.
+
+ 4) Configure MySQL 4.1 and newer to use Latin1 as default character set
+    everywhere.
+
+ 5) Import the dump into the new MySQL server, replacing your empty database you
+    created at step 1, use --default-character-set=binary on restore.
+
+ 6) At this point you have RT 3.8.x code base using an old database. You can
+    upgrade RT using the instructions above.

-----------------------------------------------------------------------


More information about the Rt-commit mailing list