These instructions are for people upgrading OTRS from 3.3 to 4 or from a 4 to a later patchlevel release 4 and applies both for RPM and source code (tarball) upgrades.
If you are running a lower version of OTRS you have to follow the upgrade path to 3.3 first (1.1->1.2->1.3->2.0->2.1->2.2->2.3->2.4->3.0->3.1->3.2->3.3)! You need to perform a full upgrade to every version in between, including database changes and the upgrading perl script.
Please note that if you upgrade from OTRS 2.2 or earlier, you have to take an extra step.
Within a single minor version you can skip patch level releases if you want to upgrade. For instance you can upgrade directly from OTRS 4 patchlevel 2 to version 4 patchlevel 6. If you need to do such a "patch level upgrade", you should skip steps 6, 11, 13 and 14.
It is highly recommended to perform a test update on a separate testing machine first.
Please make sure there are no more running services or cronjobs that try to access OTRS. This will depend on your service configuration, here is an example:
shell> /etc/init.d/cron stop
shell> /etc/init.d/postfix stop
shell> /etc/init.d/apache stop
Stop OTRS cronjobs and the scheduler (in this order):
shell> cd /opt/otrs/
shell> bin/Cron.sh stop
shell> bin/otrs.Scheduler.pl -a stop
Kernel/Config.pm
Kernel/Config/GenericAgent.pm
Kernel/Config/Files/ZZZAuto.pm
var/*
as well as the database
shell> cd /opt
shell> mv otrs otrs-old
shell> tar -xzf otrs-x.x.x.tar.gz
shell> mv otrs-x.x.x otrs
Kernel/Config.pm
Kernel/Config/GenericAgent.pm
Kernel/Config/Files/ZZZAuto.pm
In order to let OTRS continue with the correct ticket number, restore the TicketCounter.log to
/opt/otrs/var/log/. This is especially important if you use incremental ticketnumbers.
If you configured OTRS to store article data in the filesystem you have to restore the article folder to /opt/otrs/var/.
Please execute
shell> cd /opt/otrs/
shell> bin/otrs.SetPermissions.pl
with the permissions needed for your system setup. For example:
Web server which runs as the OTRS user:
shell> bin/otrs.SetPermissions.pl --web-group=otrs
Webserver with wwwrun user (e. g. SUSE):
shell> bin/otrs.SetPermissions.pl --web-group=wwwrun
Webserver with apache user (e. g. Red Hat, CentOS):
shell> bin/otrs.SetPermissions.pl --web-group=apache
Webserver with www-data user (e. g. Debian, Ubuntu):
shell> bin/otrs.SetPermissions.pl --web-group=www-data
Verify that all needed perl modules are installed on your system and install any modules that might be missing.
shell> /opt/otrs/bin/otrs.CheckModules.pl
Note: new tables created in the MySQL UPGRADING process will be created with the
default table storage engine set in your MySQL server.
In MySQL 5.5 the new default type is InnoDB.
If existing tables, e.g. "users", have the table storage engine e.g. MyISAM,
then an error will be displayed when creating the foreign key constraints.
You have two options: you can change the default storage engine of MySQL back to MyISAM
so that new tables will have the same engine as the existing tables,
or change the existing tables to use InnoDB as storage engine.
Any problems with regards to the storage engine will be reported by the
otrs.CheckDB.pl script, so please run it to check for possible issues.
shell> cd /opt/otrs/
shell> bin/otrs.CheckDB.pl
shell> cat scripts/DBUpdate-to-4.mysql.sql | mysql -p -f -u root otrs
Note: The OTRS themes of 3.3 are NOT compatible with OTRS 4, so don't use your old themes!
Themes are located under /opt/otrs/Kernel/Output/HTML/*/*.tt.
Please note that OTRS 4 comes with a new templating engine based on Template::Toolkit. All customized templates must be converted from DTL to the new format. Please see the development manual for detailed instructions.
Please run (as user otrs, not as root):
shell> bin/otrs.RebuildConfig.pl
shell> bin/otrs.DeleteCache.pl
e. g. (depends on used services):
shell> /etc/init.d/apache start
shell> /etc/init.d/postfix start
shell> /etc/init.d/cron start
Now you can log into your system.
The OTRS packages of 3.3 are NOT compatible with OTRS 4, so you have to perform a package upgrade!
The following packages are automatically uninstalled after the upgrade process (if they where installed before):
OTRSGenericInterfaceREST
OTRSMyServices
OTRSStatsRestrictionByDateTimeDF
Support
If you have any GenericAgent jobs (or even any custom developments)
that automatically set ProcessID or ActivityID dynamic fields,
you need to update these to set the fields to the new long EntityIDs
that were generated by DBUpdate-to-4.pl.
There are several OTRS default cronjobs in /opt/otrs/var/cron/*.dist.
They can be activated by copying them without the ".dist" filename extension.
Do this to make sure you get the latest versions of the cronjobs and new cronjobs
as well.
shell> cd /opt/otrs/var/cron
shell> for foo in *.dist; do cp $foo `basename $foo .dist`; done
Please check the copied files and re-apply any customizations that you might have made.
To schedule these cronjobs on your system, you can use the script Cron.sh.
Make sure to execute it as the otrs user!
shell> /opt/otrs/bin/Cron.sh start
This will also cause the OTRS Scheduler to be started.
If you're using an external customer database and this database does NOT provide the OTRS specific fields
create_time, create_by, change_time and change_by, please set ForeignDB => 1
for $Self->{CustomerUser} and $Self->{CustomerCompany}
(see Kernel/Config/Defaults.pm).
Please run bin/otrs.RebuildTicketIndex.pl to regenerate the ticket index.
This can be done in the background to calculate the ticket numbers for the queue view screens.
You can already use your system.