Migration von OTRS / ((OTRS)) Community Edition Version 6 auf OTOBO 10

Hallo und danke, dass Sie sich für OTOBO entschieden haben!

OTRS, ((OTRS)) Community Edition und OTOBO sind Systeme mit umfassender Funktionalität, die große Flexibilität bieten. Deshalb erfordert jede Migration sorgfältige Vorbereitung und möglicherweise auch Nacharbeiten.

Bitte nehmen Sie sich deshalb Zeit für die Migration und befolgen Sie die Anleitung Schritt für Schritt.

Probleme oder Fragen? Kein Grund zu Verzweifeln :) Rufen Sie unsere Support-Hotline an, schreiben Sie uns eine E-Mail oder bitten Sie im OTOBO Community Forum unter https://forum.otobo.org/ um Unterstützung.

Wir finden bestimmt eine Möglichkeit, Ihnen zu helfen.

Bemerkung

Nach der Migration werden alle bisher in OTRS 6 verfügbaren Daten in OTOBO verfügbar sein. Die Daten in Ihrem OTRS-Ursprungssystem werden während der Migration nicht verändert.

Migrationsszenarien

Mit dem OTOBO Migrationstool können folgende Migrationen durchgeführt werden:

  1. Eine 1:1-Migration, bei der Applikationsserver und Datenbankserver beibehalten werden.

  2. Eine optimierte Migration, bei der zunächst die Quelldatenbank auf den Zieldatenbankserver kopiert wird.

  3. Eine allgemeine Migration, die viele Szenarien abdeckt.

    1. Serverwechsel: Eine Migration mit gleichzeitigem Wechsel zu einem neuen Applikationsserver.

    2. Separate application and web servers: It’s your choice whether you want to run application and database server on the same host or each on a dedictated host. This choice is regardless of the previous setup in OTRS / ((OTRS)) Community Edition.

    1. Verschiedene Datenbanken: Sie können von jeder der unterstützten Datenbanken zu jeder anderen migrieren.
    2. Verschiedene Betriebssysteme: Sie können während der Migration von jedem unterstützten Betriebssystem zu jedem anderen unterstützten BS wechseln.
    3. Docker: Auch die Migration zu einer Docker-basierten OTOBO 10-Installation ist möglich.

Migrationsvoraussetzungen

1. Basic requirement for a migration is that you already have an ((OTRS)) Community Edition or OTRS 6.0.* running, and that you want to transfer configuration and data to OTOBO.

Warnung

Bitte überlegen Sie genau, ob es wirklich sinnvoll ist, bestehende Daten und Konfiguration zu übernehmen. Unsere Erfahrung zeigt, dass die bisher genutzte Installation und Konfiguration in viele Fällen eher suboptimal und ein sauberer Neustart die bessere Option ist. Auch kann es sinnvoll sein, nur die Ticketdaten zu übertragen und die Grundkonfiguration gemäß OTOBO Best Practice vorzunehmen. Hierzu beraten wir Sie gerne, wenden Sie sich einfach per Mail an hallo@otobo.de oder stellen Sie Ihre Fragen im OTOBO Community Forum unter https://forum.otobo.org/.

  1. Sie benötigen eine betriebsbereite OTOBO-Installation als Ausgangpunkt für die Migration!
  2. Auf dieser OTOBO-Instanz müssen alle OPM-Pakete installiert sein, die Sie bisher in Ihrem OTRS nutzen und künftig in OTOBO nutzen möchten.

4. If you are planning to migrate to another server, then the OTOBO webserver must be able to access the location where your ((OTRS)) Community Edition or OTRS 6.0.* is installed. In most cases, this is the directory /opt/otrs on the server running OTRS. The read access can be effected via SSH or via file system mounts.

5. The otrs database must be accessible from the server running OTOBO. Readonly access must be granted for external hosts. If access is not possible, or when the speed of the migration should be optimised, then a dump of the database is sufficient.

Bemerkung

Sind SSH-Kommunikation und Datenbankzugriff von einem Server auf den anderen nicht möglich, migrieren Sie zunächst auf dem alten Server von OTRS zu OTOBO und ziehen die neue Instanz erst nachträglich um.

Schritt 1: Neues OTOBO-System installieren

Bitte beginnen Sie damit, das neue OTOBO-System zu installieren, auf das Sie Ihre OTRS / ((OTRS)) Community Edition anschließend migrieren möchten. Wir empfehlen dazu dringend, das Kapitel OTOBO Installation zu lesen. Installieren Sie Ihr System mit Docker, ist das Kapitel Installation mit Docker und Docker Compose relevant für Sie.

Warnung

Unter Apache kann es zu Problemen kommen, wenn zwei Anwendungen zeitgleich unter mod_perl auf demselben Server laufen. Abhilfe schafft hier die mod_perl-Einstellung PerlOptions +Parent. Sie sorgt dafür, dass die Anwendungen jeweils eigene Perl-Interpreter verwenden. Bitte prüfen Sie die Apache-Konfigurationsdateien im Verzeichnis /etc/apache2/sites-enabled und ergänzen Sie die Einstellung, falls sie noch nicht gesetzt ist.

Sobald die Installation abgeschlossen ist, melden Sie sich bitte in OTOBO an und öffnen im Admin-Bereich die Paketverwaltung (Administration -> Paketverwaltung). Dort können Sie alle benötigten OTOBO OPM-Pakete installieren.

Folgende OPM-Pakete und OTRS-„Feature Addons“ müssen und sollten NICHT installiert werden, da ihre Funktionalität bereits im OTOBO Standard enthalten ist:
  • OTRSHideShowDynamicField
  • RotherOSSHideShowDynamicField
  • TicketForms
  • RotherOSS-LongEscalationPerformanceBoost
  • Znuny4OTRS-AdvancedDynamicFields
  • Znuny4OTRS-AutoSelect
  • Znuny4OTRS-EscalationSuspend
  • OTRSEscalationSuspend
  • OTRSDynamicFieldAttachment
  • OTRSDynamicFieldDatabase
  • OTRSDynamicFieldWebService
  • OTRSBruteForceAttackProtection
  • Znuny4OTRS-ExternalURLJump
  • Znuny4OTRS-QuickClose
  • Znuny4OTRS-AutoCheckbox
  • OTRSSystemConfigurationHistory

Schritt 2: Neues OTOBO-System und Server vorbereiten

Bitte rufen Sie nach Abschluss der Installation erneut den OTOBO-Admin-Bereich auf, navigieren Sie zu Administration -> Systemkonfiguration und deaktivieren Sie die Konfig-Option SecureMode. Melden Sie sich nun als root-Benutzer am Server an und führen Sie folgende Befehle aus:

root> su - otobo
otobo>
otobo> /opt/otobo/bin/Cron.sh stop
otobo> /opt/otobo/bin/otobo.Daemon stop --force

Läuft OTOBO in Docker, genügt es, den Docker-Container otobo_daemon_1 zu stoppen:

docker_admin> cd /opt/otobo-docker
docker_admin> docker-compose stop daemon
docker_admin> docker-compose ps     # otobo_daemon_1 should have exited with the code 0

Bemerkung

Wir empfehlen, an dieser Stelle ein Backup des gesamten OTOBO-Systems zu erstellen. Treten dann während der Migration Probleme auf, müssen Sie nicht den gesamten Installationsprozess erneut durchlaufen, sondern können einfach das Backup importieren und eine neue Migration anstoßen.

Siehe auch

Hierzu empfehlen wir die Lektüre des Kapitels OTOBO Backup und Wiederherstellung.

sshpass installieren, um OTRS von einem anderen Server zu migrieren

Wir verwenden die Tools sshpass und rsync, um Dateien über eine SSH-Verbindung zu kopieren. Bitte melden Sie sich als root-Benutzer am Server an und führen Sie einen der folgenden Befehle aus, um sshpass zu installieren:

$ # Install sshpass under Debian / Ubuntu Linux
$ sudo apt-get install sshpass
$ #Install sshpass under RHEL/CentOS Linux
$ sudo yum install sshpass
$ # Install sshpass under Fedora
$ sudo dnf install sshpass
$ # Install sshpass under OpenSUSE Linux
$ sudo zypper install sshpass

Gehen Sie analog vor, wenn rsync noch nicht verfügbar ist.

Schritt 3a ohne Docker: OTRS / ((OTRS)) Community Edition Quellsystem vorbereiten

Bemerkung

Fahren Sie mit Schritt 3b fort, um auf eine Docker-basierte Installation zu migrieren.

Bemerkung

Stellen Sie sicher, dass für Ihr OTRS / ((OTRS)) Community Edition ein aktuelles und vollständiges Backup vorliegt. Selbst wenn die Daten im Quellsystem während der Migration nicht angetastet werden, kann unter Umständen schon ein einziger falscher Eintrag Probleme bereiten.

Damit sind die grundlegenden Voraussetzungen für die Migration geschaffen. Stellen Sie nun sicher, dass keine Tickets mehr bearbeitet werden und sich Benutzer nicht mehr in OTRS anmelden können:

Rufen Sie im OTRS-Admin-Bereich Administration ->  Systemwartung auf und fügen Sie ein neues Systemwartungs-Zeitfenster über einige Stunden hinzu. Löschen Sie anschließend alle Agenten- und User-Sitzungen (Administration ->  Sitzungsverwaltung) und melden Sie sich ab.

Alle relevanten Services und den OTRS Daemon stoppen

Versichern Sie sich, dass keine Dienste oder Crons Jobs mehr ausgeführt werden.

root> su - otrs
otrs>
otrs> /opt/otrs/bin/Cron.sh stop
otrs> /opt/otrs/bin/otrs.Daemon.pl stop --force
otrs> /opt/otrs/bin/otrs.Console.pl Maint::Cache::Delete
otrs> /opt/otrs/bin/otrs.Console.pl Maint::Session::DeleteAll
otrs> /opt/otrs/bin/otrs.Console.pl Maint::Loader::CacheCleanup
otrs> /opt/otrs/bin/otrs.Console.pl Maint::WebUploadCache::Cleanup

Schritt 3b Docker: Erforderliche Daten im Container verfügbar machen

Bei der Nutzung von Docker zur OTOBO-Installation sind einige Besonderheiten zu beachten. Die wichtigste: In einem Docker-Container ausgeführte Prozesse können grundsätzlich nicht auf Verzeichnisse außerhalb dieses Containers zugreifen. Einzige Ausnahme: Auf Verzeichnisse, die als Volumes in den Container gemounted werden, kann zugegriffen werden. Auch die in ``otobo_db_1``laufende MariaDB-Datenbank ist von außerhalb des Container-Netzwerks nicht direkt erreichbar.

Bemerkung

Wir gehen im Folgenden davon aus, dass zur Interaktion mit Docker der Benutzer docker_admin verwendet wird. Der Docker-Admin kann entweder der root-Benutzer des Docker-Host oder ein spezieller Benutzer mit den erforderlichen Berechtigungen sein.

/opt/otrs in das Volume otobo_opt_otobo kopieren

Wir gehen in diesem Abschnitt davon aus, dass das OTRS Home-Verzeichnis /opt/otrs auf dem Docker-Host verfügbar ist.

Sie haben mindestens zwei Möglichkeiten:

  1. /opt/otrs in das bestehende Volume otobo_opt_otobo kopieren
  2. /opt/otrs als zusätzliches Volume mounten

Konzentrieren wir uns hier auf Option a..

Als erstes müssen wir herausfinden, wo das Volume otobo_opt_otobo auf dem Docker-Host bereitsteht.

docker_admin> otobo_opt_otobo_mp=$(docker volume inspect --format '{{ .Mountpoint }}' otobo_opt_otobo)
docker_admin> echo $otobo_opt_otobo_mp  # just a sanity check

Wir nutzen rsync für einen sicheren Kopiervorgang. Je nach Dockerumgebung muss rsync möglicherweise mit sudo-Rechten ausgeführt werden.

docker_admin> # when docker_admin is root
docker_admin> rsync --recursive --safe-links --owner --group --chown 1000:1000 --perms --chmod "a-wx,Fu+r,Du+rx" /opt/otrs/ $otobo_opt_otobo_mp/var/tmp/copied_otrs
docker_admin> ls -la $otobo_opt_otobo_mp/var/tmp/copied_otrs  # just a sanity check

docker_admin> # when docker_admin is not root
docker_admin> sudo rsync --recursive --safe-links --owner --group --chown 1000:1000 --perms --chmod "a-wx,Fu+r,Du+rx" /opt/otrs/ $otobo_opt_otobo_mp/var/tmp/copied_otrs
docker_admin> sudo ls -la $otobo_opt_otobo_mp/var/tmp/copied_otrs  # just a sanity check

Das kopierte Verzeichnis wird im Container als /opt/otobo/var/tmp/copied_otrs verfügbar sein.

OTRS-Datenbankschema auf den Datenbankserver im Container kopieren

Bemerkung

Wir beschreiben hier nur die empfohlene Vorgehensweise. Die Migration von einer laufenden OTRS-Datenbank ist weiterhin möglich.

Bemerkung

Diese Anleitung setzt voraus, dass OTRS MySQL als Backend nutzt.

Grundsätzlich werden alle Daten in den Datenbanktabellen Zeile für Zeile aus der OTRS-Datenbank in die OTOBO-Datenbank kopiert. Dieser Vorgang ist zeitraubend und kann beschleunigt werden. Dazu erstellen wir eine temporäre Kopie der OTRS-Datenbank auf dem Server, auf dem die OTOBO-Datenbank läuft. In unserem Fall ist das der MariaDB-Server im Container otobo_db_1. Sobald die Arbeitskopie erstellt wurde, können alle relevanten OTRS-Tabellen in die OTOBO-Datenbank übernommen werden.

Zuallererst benötigen wir einen Dump der benötigten OTRS-Datenbanktabellen. Da die importierten Tabellen in die OTOBO-Datenbank kopiert werden, müssen wir außerdem den Zeichensatz auf utf8mb4 umstellen. Für eine sichere Konvertierung wird der Dump in die Dateien otrs_schema.sql und otrs_data.sql aufgeteilt.

Ist ``mysqldump``installiert und kann eine Verbindung zur OTRS-Datenbank hergestellt werden, können Sie den Datenbankdump direkt auf dem Docker-Host erstellen. Hierzu können Sie das Skript bin/backup.pl verwenden.

Warnung

Dies setzt voraus, dass eine OTRS-Installation auf dem Docker-Host verfügbar ist.

otobo> cd /opt/otobo
otobo> scripts/backup.pl -t migratefromotrs --db-name otrs --db-host=127.0.0.1 --db-user otrs --db-password "secret_otrs_password"

Alternativ können Sie die Datenbank auch auf einen anderen Server dumpen und anschließend auf den Docker-Host verschieben. Dazu können Sie folgende Beispielbefehle verwenden.

Warnung

Die angegebenen Befehle entfernen alle spezifischen MySQL-Kollationen. Sollten Sie solche in Ihrer Umgebung benötigen, denken Sie daran, diese von Hand wieder hinzuzufügen.

otobo> mysqldump -h localhost -u root -p --databases otrs --no-data --dump-date > otrs_schema.sql
otobo> sed -i.bak -e 's/DEFAULT CHARACTER SET utf8/DEFAULT CHARACTER SET utf8mb4/' -e 's/DEFAULT CHARSET=utf8/DEFAULT CHARSET=utf8mb4/' -e 's/COLLATE=\w\+/ /' otrs_schema.sql
otobo> mysqldump -h localhost -u root -p --databases otrs --no-create-info --no-create-db --dump-date > otrs_data.sql

Zum Importieren des Datenbankdumps nutzen wir mysql im Docker-Container otobo_db_1. Achtung: Das Passwort für den Datenbank-Root ist jetzt das in _.env_ definierte Passwort.

docker_admin> docker exec -i otobo_db_1 mysql -u root -p<root_secret> < otrs_schema.sql
docker_admin> docker exec -i otobo_db_1 mysql -u root -p<root_secret> < otrs_data.sql

Nutzen Sie die folgenden Befehlen, um zu überprüfen, ob der Import erfolgreich war.

docker_admin> docker exec -i otobo_db_1 mysql -u root -p<root_secret> -e 'SHOW DATABASES'
docker_admin> docker exec -i otobo_db_1 mysql -u root -p<root_secret> otrs -e 'SHOW TABLES'
docker_admin> docker exec -i otobo_db_1 mysql -u root -p<root_secret> otrs -e 'SHOW CREATE TABLE ticket'

Die kopierte Datenbank wird während der Migration vom Datenbankbenutzer otobo ausgelesen und angepasst. Deshalb muss otobo umfassende Rechte für die kopierte Datenbank erhalten.

docker_admin> # note that 'root' and 'otobo' have different passwords
docker_admin> docker exec -i otobo_db_1 mysql -u root  -p<root_secrect>       -e "GRANT SELECT, SHOW VIEW, UPDATE, DROP, ALTER ON otrs.* TO 'otobo'@'%'"
docker_admin> docker exec -i otobo_db_1 mysql -u otobo -p<otobo_secrect> otrs -e "SELECT COUNT(*), DATABASE(), USER(), NOW() FROM ticket"

Wenn Sie das webbasierte Migrationstool verwenden, geben Sie bitte folgende Werte ein, wenn Sie dazu aufgefordert werden:

  • ‚db‘ als Host der OTRS-Datenbank
  • ‚otobo‘ als Benutzer der OTRS-Datenbank
  • das Passwort des Datenbankbenutzers ‚otobo‘ als Passwort des OTRS-Datenbankbenutzers
  • ‚otrs‘ als Name der OTRS-Datenbank

Schritt 4: Migration durchführen!

Bitte verwenden Sie das Web-Migrationstool, das Sie unter http://localhost/otobo/migration.pl finden (ersetzen Sie „localhost“ durch Ihren OTOBO Host und ergänzen Sie ggf. den Port). Es führt Sie Schritt für Schritt durch den Prozess.

Warnung

Gelegentlich wird eine Warnung angezeigt, dass die Deaktivierung des SecureMode nicht erkannt wurde. Bitte starten Sie in diesem Fall den Webserver neu. So wird die aktuelle Konfiguration eingelesen.

docker_admin> cd /opt/otobo-docker
docker_admin> docker-compose restart web
docker_admin> docker-compose ps     # otobo_web_1 should be running again

Bemerkung

Wird OTOBO in einem Docker Container ausgeführt, behalten Sie die Standardeinstellungen localhost für den OTRS-Server und /opt/otobo/var/tmp/copied_otrs für das OTRS-Home-Verzeichnis bei. Dieser Pfad führt zu den in Schritt 3b kopierten Daten.

Bemerkung

Die Standardwerte für den OTRS-Datenbankbenutzer und dessen Passwort werden der Kernel/Config.pm im OTRS-Homeverzeichnis entnommen. Ändern Sie die vorgeschlagenen Einstellungen, wenn Sie einen speziellen Datenbankbenutzer für die Migration verwenden möchten. Passen Sie die Einstellungen auch dann an, wenn Sie mit einer Datenbank arbeiten, die in den otobo_db_1 Docker Container kopiert wurde.

Bemerkung

Wenn Sie Docker nutzen, kann die Datenbank auf dem Docker-Host nicht über 127.0.0.1 erreicht werden. Die Einstellung 127.0.0.1``ist deshalb kein gültiger Wert für das Eingabefeld ``OTRS Server. Geben Sie stattdessen eine der alternativen IP-Adressen an, die Sie mit hostname --all-ip-addresses für OTRS Server ermittelt haben.

Bemerkung

Häufig kann das System nach der Migration auf einen neuen Anwendungsserver oder nach einer Docker-basierten Installation nicht auf die Datenbank zugreifen. Das liegt meist daran, dass der OTOBO-Datenbanknutzer sich nur von dem Host aus verbinden kann, auf dem auch die Datenbank läuft. Um dennoch Zugriff auf die Datenbank zu gewährleisten, empfehlen wir die Anlage eines speziellen Datenbankbenutzers für die Migration – z. B. CREATE USER 'otrs_migration'@'%' IDENTIFIED BY 'otrs_migration'; und GRANT SELECT, SHOW VIEW ON otrs.* TO 'otrs_migration'@'%';. Dieser Benutzer kann nach der Migration wieder gelöscht werden: DROP USER 'otrs_migration'@'%'.

Ist die Migration abgeschlossen, nehmen Sie sich bitte Zeit, um das System ausgiebig zu testen. Erst wenn Sie sicher sind, dass die Migration erfolgreich durchgeführt wurde und dass Sie von nun an mit OTOBO arbeiten möchten, starten Sie den OTOBO Daemon:

root> su - otobo
otobo>
otobo> /opt/otobo/bin/Cron.sh start
otobo> /opt/otobo/bin/otobo.Daemon start

In der Docker-Umgebung:

docker_admin> cd ~/otobo-docker
docker_admin> docker-compose start daemon

Schritt 5: Nach der Migration!

  1. Deinstallieren Sie sshpass, wenn Sie es nicht mehr benötigen.
  2. Löschen Sie ggf. den speziell für die Migration angelegten Datenbankbenutzer.
  3. Viel Vergnügen mit OTOBO!

Schritt 6: Bekannte Probleme bei der Migration

1. Login after migration not possible

Während unserer Migrationstests kam es gelegentlich zu Problemen mit dem für die Migration verwendeten Browser. Diese waren in der Regel nach einem Browser-Neustart gelöst. In Safari kann es erforderlich sein, die alte OTRS-Sitzung manuell zu löschen.

2. Final page of the migration has a strange layout due to missing CSS files

Kann vorkommen, wenn die Einstellung ScriptAlias keinen Standardwert enthält. Bei der Migration wird lediglich otrs durch otobo ersetzt. Das kann dazu führen, dass OTOBO nicht mehr korrekt auf CSS und JavaScript zugreifen kann. Bitte überprüfen Sie in diesem Fall die Einstellungen in Kernel/Config.pm und korrigieren Sie diese auf geeignete Werte.

Schritt 7: Manuelle Aufgaben und Anpassungen

1. Password policy rules

Mit OTOBO 10 wurde standardmäßig eine neue Passwortrichtlinie für Agenten und Kundenbenutzer eingeführt, wenn diese sich lokal authentifizieren. Die Regeln der Passwortrichtlinie können Sie in der Systemkonfiguration anpassen (PreferencesGroups###Password und CustomerPersonalPreference###Password).

Regel Passwortrichtlinie Standard
PasswordMinSize 8
PasswordMin2Lower2UpperCharacters Ja
PasswordNeedDigit Ja
PasswordHistory 10
PasswordTTL 30 Tage
PasswordWarnBeforeExpiry 5 Tage
PasswordChangeAfterFirstLogin Ja

2. Under Docker: Manually migrate cron jobs

Wird OTOBO nicht unter Docker installiert, gibt es mindestens einen Cron-Job, der den Zustand des Daemon überprüft. Unter Docker gibt es diesen Cron-Job nicht mehr. Darüber hinaus läuft in keinem der Docker-Container ein Cron-Daemon. Für OTRS-Systeme mit kundenspezifischen Cron-Jobs (z. B. Datenbank-Backups) müssen deshalb individuelle Lösungen gefunden werden.