Upgrade von OTRS 3.3 auf OTRS 4

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.

Wenn Sie eine ältere Version von OTRS einsetzen, müssen sie zuerst dem Upgrade-Pfad zur 3.1 folgen (1.1->1.2->1.3->2.0->2.1->2.2->2.3->2.4->3.0->3.1->3.2->3.3 ...)! Sie müssen ein vollständiges Upgrade auf jede Zwischen-Version inklusive der Datenbankänderungen und der Perlskripte durchführen.

Bitte beachten Sie, falls Sie von OTRS 2.2 oder früher upgraden, müssen Sie einen extra Schritt durchführen; bitte lesen Sie dazu http://bugs.otrs.org/show_bug.cgi?id=6798.

Innerhalb einer Minor-Version können Sie einzelne Patch-Level-Versionen überspringen, falls Sie upgraden wollen. Beispielsweise können Sie direkt von OTRS 4 Patchlevel 2 auf OTRS 4 Patchlevel 6 upgraden. Wenn Sie so ein "Patch-Level-Upgrade" durchführen, können Sie Schritt 6, 11, 13 und 14 überspringen.

Es wird empfohlen zuerst ein Test-Update auf einem seperaten Testsystem durchzuführen

Schritt 1: Stoppen Sie alle relevanten Dienste.

Stellen Sie sicher, dass keine Services oder Cronjobs mehr laufen, die versuchen auf OTRS zuzugreifen. Das hängt von ihrer Servicekonfiguration ab, anbei ein Beispiel:

shell> /etc/init.d/cron stop
shell> /etc/init.d/postfix stop
shell> /etc/init.d/apache stop
            

stoppen der OTRS Cronjobs und des Schedulers (in dieser Reihenfolge):

shell> cd /opt/otrs/
shell> bin/Cron.sh stop
shell> bin/otrs.Scheduler.pl -a stop
            

Schritt 2: Sichern Sie alles unter /opt/otrs/

  • Kernel/Config.pm

  • Kernel/Config/GenericAgent.pm

  • Kernel/Config/Files/ZZZAuto.pm

  • var/*

  • ebenfalls die Datenbank

Schritt 3: Stellen Sie sicher, dass Sie alles gesichert haben ;-)

Schritt 4: Installieren Sie das neue Release (tar oder RPM)

Schritt 4.1: Mit dem Tarball:

shell> cd /opt
shell> mv otrs otrs-old
shell> tar -xzf otrs-x.x.x.tar.gz
shell> mv otrs-x.x.x otrs
            
Wiederherstellen alter Konfiguration Dateien

  • Kernel/Config.pm

  • Kernel/Config/GenericAgent.pm

  • Kernel/Config/Files/ZZZAuto.pm

Wiederherstellung TicketCounter.log

Damit OTRS mit der richtigen Ticketnummer weiter arbeitet, stellen Sie die Datei TicketCounter.log in $OTRS_HOME/var/log/ wieder her. Das ist vorallem dann wichtig, wenn Sie inkrementelle Ticketnummern verwenden.

Wiederherstellung article data

Wenn Sie OTRS so konfiguriert haben, dass Artikeldaten im Dateisystem gespeichert werden, müssen Sie den Ordner article nach $OTRS_HOME/var/ wiederherstellen.

Setzen Sie die Datei-Berechtigungen.

Führen Sie

shell> cd /opt/otrs/
shell> bin/otrs.SetPermissions.pl
                

mit den benötigten Berechtigungen für Ihr System aus. Zum Beispiel:

  • Webserver der als OTRS user läuft:

    shell> bin/otrs.SetPermissions.pl --web-group=otrs
                    

  • Webserver der als wwwrun User läuft (z.B.: SUSE):

    shell> bin/otrs.SetPermissions.pl --web-group=wwwrun
                    

  • Webserver der als apache User läuft: (z.B.: Red Hat, CentOS):

    shell> bin/otrs.SetPermissions.pl --web-group=apache
                    

  • Webserver der als www-data User läuft (z.B.: Debian, Ubuntu):

    shell> bin/otrs.SetPermissions.pl --web-group=www-data
                    

Schritt 4.2: Mit RPM

shell> rpm -Uvh otrs-x.x.x.-01.rpm
            

In diesem Fall stellt das RPM-Update die alten Konfigurationsdateien automatisch wieder her.

Schritt 5: Überprüfung benötigter Perl-Module

Versichern Sie sich dass alle benötigten Perl-Module auf Ihrem System installiert sind und installieren Sie alle Module die fehlen.

shell> /opt/otrs/bin/otrs.CheckModules.pl
        

Schritt 6: Anwenden der Datenbankänderungen

Schritt 6.1: Datenbankschema-Update

MySQL:

Anmerkung: Tabellen die während des MySQL Upgrade-Prozesses erstellt werden, werden mit der Standard Storage-Engine Ihres MySQL-Servers erstellt. in MySQL 5.5. ist die Standard Storage-EngineInnoDB. Wenn bereits existierende Tabellen z.B.: "users", eine andere Storage-Engine z.B.: MyISAM besitzen, wird beim Erstellen der Fremdschlüssel eine Fehlermeldung ausgegeben.

Sie haben zwei Möglichkeiten: Sie können die Standard Storage-Engine Ihres MySQL-Servers zurück auf MyISAM stellen, so dass neue Tabellen die gleiche Storage-Engine wie die existierenden Tabellen besitzen, oder die ändern die Storage-Engine der existierenden Tabellen auf InnoDB.

Jegliche Probleme in Bezug auf die Storage-Engine wird durch das Skript otrs.CheckDB.pl gemeldet. Bitte führen Sie dieses Skript aus, um zu überprüfen ob eventuell Störungen vorliegen.

shell> cd /opt/otrs/
shell> bin/otrs.CheckDB.pl
shell> cat scripts/DBUpdate-to-4.mysql.sql | mysql -p -f -u root otrs
                

PostgreSQL:

shell> cd /opt/otrs/
shell> cat scripts/DBUpdate-to-4.postgresql.sql | psql --set ON_ERROR_STOP=on --single-transaction otrs otrs
                

Schritt 6.2: Datenbank-Migrationsskript

Führen Sie das Migrationsskript (als User otrs, NICHT als root):

shell> scripts/DBUpdate-to-4.pl
            

Fahren Sie nicht mit dem Upgrade-Prozess fort, wenn dieses Skript Fehler anzeigt. Andernfalls riskieren Sie einen Datenverlust.

Schritt 7: Eigene Themes

Hinweis: Die OTRS-Themes von 3.3 sind NICHT zu OTRS 4 kompatibel, verwenden Sie ihre alten Themes daher nicht weiter!

Themes befinden sich in /opt/otrs/Kernel/Output/HTML/*/*.tt.

Beachten Sie das OTRS 4 mit einer neuen Template-Engine basierend auf dem Template::Toolkit ausgeliefert wird. Alle selbsterstellen Vorlagen müssen vom DTL in das neue Format konvertiert werden. Detaillierte Anweisungen finden Sie im Entwickler Handbuch.

Schritt 8: Erneuern des Konfigurations-Caches und Löschen der Caches

Bitte führen Sie (als User otrs, nicht als root):

shell> bin/otrs.RebuildConfig.pl
shell> bin/otrs.DeleteCache.pl
        

Schritt 9: Starten Sie die Dienste neu.

Zum Beispiel (hängt von Ihren verwendeten Services ab):

shell> /etc/init.d/apache start
shell> /etc/init.d/postfix start
shell> /etc/init.d/cron start
        

Nun können Sie sich in Ihr System einloggen.

Schritt 10: Überprüfen der installierten Pakete

Anmerkung

Die OTRS 3.3 PAkete sind NICHT kompatibel mit OTRS 4, somit müssen Sie auch die Pakete upgraden!

Die folgenden Pakete werden nach einem Upgrade automatisch deinstalliert (wenn sie zuvor installiert waren):

  • OTRSGenericInterfaceREST

  • OTRSMyServices

  • OTRSStatsRestrictionByDateTimeDF

  • Support

Schritt 11: Überprüfen der GenericAgent Jobs

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.

Schritt 12: Aktualisieren und Aktivieren der Cronjobs

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.

Schritt 13: Aktualisieren der Kundendatenbankkonfiguration

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).

Schritt 14: Erneutes aufbauen des Ticket-Index

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.

Schritt 14: Gut gemacht!