We want to upgrade to RT 6.0.2 and so I’m wondering what the best approach is. We have a lot of customization we’ve done within our environment to facilitate SSO, along with server specific custom configs for Postfix etc., so we’d prefer to do in place rather than stand up a new installation and try to port everything over.
I’ve tried to get a sense of the upgrade process, and from what I’ve detemined thus far is that the version of MySQL will need to be upgraded prior to upgrading RT. I’m not at all familiar with this process, however the abundance of online resources make and inplace upgrade seem relatively straight forward…….back everything up, remove the MySQL 5.7 packages, install the MySQL 8.x packages, and the actual upgrade occurs automatically with first startup of MySQL 8 once it recognizes the older DB’s in the default data directory.
Is there anything I’d be required to do with RT once I’ve finsihed the upgrade of MySQL? Obviously the schema of the RT database will be alterted to become v8 compliant, but would I have to do anything else within RT’s existing configuration (5.0.4) to have it run seamlessly under MySQL 8 such as restarting RT, restarting the server, making config changes etc?
The recommended upgrade path isn’t actually much of an upgrade. It’s more like: rebuild from scratch then migrate.
RT 6.0 Upgrading says, “Upgrading to RT 6 over an existing RT 5 installation (/opt/rt5) is not recommended and will almost certainly cause issues. Instead, do a fresh install into /opt/rt6 (or your custom location) for the code portion of the upgrade. Then import your existing database and run the database upgrade steps using make upgrade-database.
We recommend this approach because of the large number of changes to the code base for this major release. We moved some things to new locations and old files are not removed as part of the upgrade process. These old files will still be detected by RT in some cases and will cause issues.
Installing a fresh code base will also allow you to evaluate your local modifications and configuration changes as you migrate to 6.0. If you have changes made directly to the RT code, it’s a good time to look at the hooks RT provides for custom code in extensions or in the local directory. See docs/writing_extensions.pod for more information.
I did the ‘upgrade’ from RT 4 to 5 and confirm that starting with a fresh VM and fresh install is the way to go.
I just did a 5.0.3 to 6.0.2 upgrade, although I was already running on a newer version of MySQL than you are and that introduces an extra wrinkle.
I strongly recommend the “Throw up a new server, install, test, then migrate database contents” route. The second that you try to migrate an existing MySQL database “in place”, you open yourself up to a potentially massive world of pain if it goes wrong for any reason.
Build new server, with up-to-date OS, Perl, MySQL/MariaDB
Install 6.0.2, fixdeps, set up an empty database
Check that the new server is working properly
Port your SSO and other modifications
Check the new server is working properly, with your mods active
Export your current database contents with mysql_dump
Blitz the new (empty) rt6 database and recreate it completely empty (mysql create database, not the RT initialise-database)
Load your MySQL 5 rt5 database into the new MySQL 8 rt6 database
Run the upgrade-database step
Check the server is working properly with your mods active and the current database contents visible.
Then, and only then, shut down your 5.0.4 instance, repeat steps 6-10, and either swap IP addresses on the VMs or adjust your DNS to point at the new instance.
At all points throughout that process, you have a functional version of RT available to you
I just did a 4.2.9 → 6.0.2, and I strongly recommend:
install a completely new server with a different IP address
install 6.0.2 from scratch
copy RT_SiteConfig.pm, dump old DB from old server and restore it to the new
read the release notes and take them seriously
run the upgrade script
put the new IP in your hosts file and try your new RT without any customization
take note of every step required from the dump of the old db to the restore, upgrade script and any subsequent adjustment that could be necessary, and of the elapsed time, because you will have to repeat them in the real migration
try to put in place each customization, one at a time, copying from your old local/ to the new local/ (if you modified sources directly, you will have to untar the old distribution and diff it). This will take time.
When you are satisfied, ask your pilot users to edit their hosts file and try it