[otrs] Upgrading from 3.0.x

[Rob Mitchell]

Greetings:
We have been using OTRS 3.0.11 ITSM with very good stability and success,
but now we'd like to upgrade to the latest version. The documentation
states:

"If you are running a lower version of OTRS you have to follow the upgrade
path to 4 first
(...3.0->3.1->3.2->3.3->4)!"

I don't have any problem with doing the upgrades in sequence as directed,
but I would prefer not to do so on the production server (an Amazon EC2 EBS
instance running Ubuntu). I'd rather build a test server on a current
clean build of the Ubuntu LTS version, upgrade that all the way up to the
current version on the test box, then ultimately I would like to install a
clean 5.0.x OTRS instance on a new EC2 VM and copy over the database and
our config and support files. After testing we can simply edit the A
Record to point to the new EC2 VM and press on. Does this sound like an
appropriate upgrade path?

In order to build a test environment to do this should I start off by
installing 3.0.11 on a test box, then restoring our OTRS directory and
restore a copy of the database, then upgrade to 3.1, or is it possible to
install a 3.1 instance and upgrade the database on it?
Thanks in advance for your advice.

Kind regards,
Rob in Memphis

[Gerald Young]

Your database needs to migrate through the 3.x releases, so consider that
you can't just skip the intermediate steps once you get it working on
staging.

As for the first step, you can very well start with 3.1.latest on the
staging server, restore your 3.0 database to it, then run the migration
steps in the UPGRAADING documentation.
For what you're attempting, you don't *have* to build 3.0.11 first on
staging, then blow away the files to upgrade to 3.1.latest ... with the
same database anyway.
Note that you will have to be cognizant of the 3.1->3.2 change from MyISAM
to InnoDB, but there's a utility to assist with that:
https://github.com/OTRS/otrs/blob/rel-3_2_18/bin/otrs.MySQLInnoDBSwitch.pl

There's more to it, of course, The docs are pretty good, but you should
note that much of your filesystem customization will need to adjust greatly
for the differing APIs.

Also, don't forget to include your Config.pm and Config Files that the
documentation asks for. They're important to make sure the configuration
changes process properly.

Please don't consider this as a substitute for the documentation. It
certainly doesn't contain all the instructions or caveats you'll encounter,
but you have not just a few steps to complete the upgrade.

Post by Rob Mitchell
We have been using OTRS 3.0.11 ITSM with very good stability and success,
but now we'd like to upgrade to the latest version. The documentation
"If you are running a lower version of OTRS you have to follow the upgrade
path to 4 first
(...3.0->3.1->3.2->3.3->4)!"
I don't have any problem with doing the upgrades in sequence as directed,
but I would prefer not to do so on the production server (an Amazon EC2 EBS
instance running Ubuntu). I'd rather build a test server on a current
clean build of the Ubuntu LTS version, upgrade that all the way up to the
current version on the test box, then ultimately I would like to install a
clean 5.0.x OTRS instance on a new EC2 VM and copy over the database and
our config and support files. After testing we can simply edit the A
Record to point to the new EC2 VM and press on. Does this sound like an
appropriate upgrade path?
In order to build a test environment to do this should I start off by
installing 3.0.11 on a test box, then restoring our OTRS directory and
restore a copy of the database, then upgrade to 3.1, or is it possible to
install a 3.1 instance and upgrade the database on it?
Thanks in advance for your advice.
Kind regards,
Rob in Memphis
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

[Rob Mitchell]

Thanks, Gerald, for your response. From the documentation I thought I'd be
in good shape. I've set up the test server with OTRS 3.1, stopped services
and copied over my config files from the 3.0.11 server:
/opt/otrs/Kernel/Config.pm
/opt/otrs/Kernel/Config/GenericAgent.pm
/opt/otrs/Kernel/Config/Files/ZZZAuto.pm

The database from 3.0.11 is restored to a database called otrs3, and
although I could use any username I added a user to the otrs3 database with
the same name and password as the production server and granted all
privileges to otrs3. I've logged onto MySQL using the new credentials and
made some table queries to make sure I can see the database properly with
the credentials that match the restored Config.pm file. Obviously root
works as well.

When I ran the command

cat scripts/DBUpdate-to-3.1.mysql.sql | mysql -p -f -u root otrs3

The script ran but yielded the following errors:

ERROR 1005 (HY000) at line 225: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 226: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 227: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 229: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 230: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 234: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 235: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 237: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 238: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 239: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)

MySQL documentation says this error (1005 with errno 150) results when a
foreign key constraint is not correctly formed. I can see in the script
that these line numbers are adding constraints, but I'm afraid I don't
understand what's supposed to happen that didn't happen. Can you shed any
light on what went awry with the FK constraint creations?

Thanks much,
Rob in Memphis

[Gerald Young]

This is very much the MyISAM/InnoDB issue.
https://www.google.com/search?q=site:forums.otterhub.org+can%27t+create+table

http://forums.otterhub.org/viewtopic.php?t=15765
http://forums.otterhub.org/viewtopic.php?t=16730

Post by Rob Mitchell
Thanks, Gerald, for your response. From the documentation I thought I'd
be in good shape. I've set up the test server with OTRS 3.1, stopped
/opt/otrs/Kernel/Config.pm
/opt/otrs/Kernel/Config/GenericAgent.pm
/opt/otrs/Kernel/Config/Files/ZZZAuto.pm
The database from 3.0.11 is restored to a database called otrs3, and
although I could use any username I added a user to the otrs3 database with
the same name and password as the production server and granted all
privileges to otrs3. I've logged onto MySQL using the new credentials and
made some table queries to make sure I can see the database properly with
the credentials that match the restored Config.pm file. Obviously root
works as well.
When I ran the command
cat scripts/DBUpdate-to-3.1.mysql.sql | mysql -p -f -u root otrs3
ERROR 1005 (HY000) at line 225: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 226: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 227: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 229: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 230: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 234: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 235: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 237: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 238: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
ERROR 1005 (HY000) at line 239: Can't create table 'otrs3.#sql-e40_45'
(errno: 150)
MySQL documentation says this error (1005 with errno 150) results when a
foreign key constraint is not correctly formed. I can see in the script
that these line numbers are adding constraints, but I'm afraid I don't
understand what's supposed to happen that didn't happen. Can you shed any
light on what went awry with the FK constraint creations?
Thanks much,
Rob in Memphis
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

[Rob Mitchell]

Gerald - you were correct.

After restoring the old database again, I altered the tables from MyISAM to
InnoDB. Once that was done the database upgrade SQL script, the perl
script, and the database post-upgrade all ran properly with no unexpected
errors. After I upgraded the installed packages the server seemed to have
full functionality, except for one thing.

The scheduler doesn't seem to be running.

I ran /opt/otrs/bin/otrs.Scheduler.pl -a start (as user otrs)
also ran /opt/otrs/bin/Cron.sh -start (also as user otrs)
Nothing appears to happen.

As root I run crontab -u otrs -e comes up with an empty crontab. Any
idea what I'm missing?
The main thing that's not happening is that fetchmail isn't getting the
mailed in tickets. Would really like to get this working as it is in
production.
Thanks again for your help and guidance. I'm pretty sure you'll be hearing
from me again as I continue the upgrade process

Rob in Memphis

OTRS 3.1.21
Ubuntu Server 14.04 LTS x64

[Gerald Young]

Make sure your var/cron isn't full of files only ending in .dist. Check the
docs.

Post by Rob Mitchell
Gerald - you were correct.
After restoring the old database again, I altered the tables from MyISAM
to InnoDB. Once that was done the database upgrade SQL script, the perl
script, and the database post-upgrade all ran properly with no unexpected
errors. After I upgraded the installed packages the server seemed to have
full functionality, except for one thing.
The scheduler doesn't seem to be running.
I ran /opt/otrs/bin/otrs.Scheduler.pl -a start (as user otrs)
also ran /opt/otrs/bin/Cron.sh -start (also as user otrs)
Nothing appears to happen.
As root I run crontab -u otrs -e comes up with an empty crontab. Any
idea what I'm missing?
The main thing that's not happening is that fetchmail isn't getting the
mailed in tickets. Would really like to get this working as it is in
production.
Thanks again for your help and guidance. I'm pretty sure you'll be
hearing from me again as I continue the upgrade process
Rob in Memphis
OTRS 3.1.21
Ubuntu Server 14.04 LTS x64
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs