Migration von ((OTRS)) Community Edition zu OTOBO

Willkommen und vielen Dank, dass Sie sich für OTOBO entschieden haben! OTRS, ((OTRS)) Community Edition und OTOBO sind in ihrer Anwendung sehr umfassend und flexibel. OTOBO ist ein OTRS Nachfolger und Teil der open source ticket system Landschaft — daher erfordert jede Migration zu OTOBO eine gründliche Vorbereitung und möglicherweise auch etwas Nacharbeit.

Bitte nehmen Sie sich Zeit für die Migration und folgen Sie diesen Anweisungen Schritt für Schritt.

Hinweis

Nach der Migration sind die zuvor in ((OTRS)) Community Edition 6 verfügbaren Daten in OTOBO 10 verfügbar. Wir ändern keine Daten der OTRS 6 Installation während der Migration.

OTOBO Migration Überblick

Mit der OTOBO Migrations-Schnittstelle ist es möglich, die folgenden Migrationsstrategien zu verwenden:

1. Die allgemeine Migrationsstrategie.

   Dies ist der reguläre Weg, eine Migration durchzuführen. Viele verschiedene Kombinationen werden unterstützt:

   • Serverwechsel: Migrieren und gleichzeitig zu einem neuen Anwendungsserver wechseln.

   • Separate Anwendungs- und Webserver: Sie haben die Wahl, ob Sie Anwendungs- und Datenbankserver auf demselben Host oder auf jeweils einem dedizierten Host betreiben wollen. Diese Wahl ist unabhängig von der vorherigen Einrichtung in OTRS / ((OTRS)) Community Edition.

   • Verschiedene Datenbanken: Von einer beliebigen unterstützten Datenbank zu einer anderen unterstützten Datenbank migrieren.

   • Verschiedene Betriebssysteme: Von jedem unterstützten Betriebssystem zu einem anderen unterstützten Betriebssystem wechseln.

   • Docker: Zu einer Docker-basierten Installation von OTOBO 10 migrieren.

2. Eine Variante der allgemeinen Strategie, bei der die Datenbankmigration optimiert wird.

Verwenden Sie die ETL-ähnliche Migration, wenn die Quelldatenbank nicht durch erhöhte Last belastet werden darf oder wenn der Zugriff auf die Quelldatenbank ein Engpass ist. In der allgemeinen Strategie werden die Daten Zeile für Zeile zuerst aus der otrs-Datenbank gelesen und dann in die OTOBO-Datenbank eingefügt. In dieser Variante werden die kompletten otrs-Datenbanktabellen zuerst exportiert, dann transformiert und dann in die otobo-Datenbank importiert.

3. Migration von einer auf Oracle basierenden ((OTRS)) Community Edition 6 Installation zu einer auf Oracle basierenden OTOBO Installation.

Dies ist ein Sonderfall, der von der allgemeinen Migrationsstrategie nicht unterstützt wird. Das bedeutet, dass eine Variante der optimierten Strategie verwendet werden muss.

Achtung

Alle Strategien funktionieren sowohl für Docker-basierten als auch für native Installationen. Aber für Docker-basierte Installationen müssen einige Besonderheiten berücksichtigt werden. Diese Besonderheiten werden in den optionalen Schritten behandelt.

Hinweis

Es ist auch machbar, die ((OTRS)) Community Edition-Datenbank vor der eigentlichen Migration auf den OTOBO-Datenbankserver zu klonen. Dies kann die allgemeine Migrationsstrategie beschleunigen.

Migrationsanforderungen

1. Grundvoraussetzung für eine Migration ist, dass Sie bereits eine ((OTRS)) Community Edition oder OTRS 6.0.* laufen haben und sowohl Konfiguration als auch Daten auf OTOBO übertragen möchten.

   Achtung

   Bitte überlegen Sie sorgfältig, ob Sie die Daten und Konfiguration wirklich benötigen. Die Erfahrung zeigt, dass in vielen Fällen ein Neuanfang die bessere Option ist. Dies liegt daran, dass die zuvor verwendete Installation und Konfiguration oft eher suboptimal war. Es könnte auch sinnvoll sein, nur die Ticketdaten zu übertragen und die Grundkonfiguration auf OTOBO Best Practices umzustellen.

2. Sie benötigen eine laufende OTOBO Installation, um von dort aus die Migration zu starten!

3. Diese OTOBO Installation muss alle OPM-Pakete enthalten, die in Ihrem ((OTRS)) Community Edition installiert sind und die Sie auch in OTOBO verwenden möchten.

4. Wenn Sie planen, auf einen anderen Server zu migrieren, muss der OTOBO-Webserver auf den Speicherort zugreifen können, wo Ihre ((OTRS)) Community Edition oder OTRS 6.0._ installiert ist. In den meisten Fällen handelt es sich um das Verzeichnis _/opt/otrs* auf dem Server, auf dem ((OTRS)) Community Edition läuft. Der Lesezugriff kann über SSH oder über Dateisystem-Mounts erfolgen.

5. Die ((otrs)) Community Edition-Datenbank muss vom Server, auf dem OTOBO läuft, zugänglich sein. Readonly-Zugriff muss für externe Hosts gewährt werden. Wenn der Zugriff nicht möglich ist oder wenn die Geschwindigkeit der Migration optimiert werden soll, dann ist ein Dump der Datenbank ausreichend.

Hinweis

Falls SSH- und Datenbankzugriff zwischen den Servern nicht möglich ist, migrieren Sie bitte ((OTRS)) Community Edition zu OTOBO auf demselben Server und bewegen Sie dann erst die neue Installation.

Schritt für Schritt Anleitung

Schritt 1: OTOBO Installation

Bitte beginnen Sie mit der Installation eines neuen OTOBO-Systems. Ihre alte OTRS / ((OTRS)) Community Edition-Installation wird auf dieses neue System migriert.

Achtung

Unter Apache gibt es Fallstricke beim Betrieb von zwei unabhängigen mod_perl-Anwendungen auf demselben Webserver. Daher wird empfohlen, ((OTRS)) Community Edition und OTOBO auf getrennten Webservern zu betreiben. Alternativ sollte die OTRS-Konfiguration aus Apache entfernt werden, bevor OTOBO installiert wird. Verwenden Sie den Befehl a2query -s und überprüfen Sie die Verzeichnisse /etc/apache2/sites-available und /etc/apache2/sites-enabled, um zu sehen, welche Konfigurationen derzeit verfügbar und aktiviert sind.

Nach Abschluss der Installation melden Sie sich bitte als root@localhost an. Navigieren Sie zum OTOBO Admin-Bereich Admin -> Pakete und installieren Sie alle erforderlichen OTOBO OPM-Pakete.

Die folgenden OPM-Pakete und ((OTRS)) Community Edition “Feature Addons” müssen NICHT und sollten NICHT installiert werden, da diese Funktionen bereits im OTOBO-Standard enthalten sind:

• OTRSHideShowDynamicField
• RotherOSSHideShowDynamicField
• TicketForms
• RotherOSS-LongEscalationPerformanceBoost
• Znuny4OTRS-AdvancedDynamicFields
• Znuny4OTRS-AutoSelect
• Znuny4OTRS-EscalationSuspend
• OTRSEscalationSuspend
• OTRSDynamicFieldDatabase
• OTRSDynamicFieldWebService
• OTRSBruteForceAttackProtection
• Znuny4OTRS-ExternalURLJump
• Znuny4OTRS-QuickClose
• Znuny4OTRS-AutoCheckbox
• OTRSSystemConfigurationHistory
• Znuny4OTRS-PasswordPolicy

Die folgenden OTOBO-Pakete wurden in OTOBO 10+ integriert. Das bedeutet, dass sie nicht im Zielsystem installiert werden sollten, wenn das Zielsystem OTOBO 10+ ist. - ImportExport

Schritt 2: SecureMode deaktivieren

Nachdem Sie OTOBO installiert haben, melden Sie sich bitte erneut im OTOBO Admin-Bereich an Admin -> Systemkonfiguration und deaktivieren die Konfigurationsoption SecureMode.

Hinweis

Vergessen Sie nicht, die geänderte Einstellung tatsächlich zu implementieren.

Schritt 3: OTOBO Daemon stoppen

Dies ist notwendig, wenn der OTOBO Daemon tatsächlich läuft. Das Stoppen des Daemons ist unterschiedlich zwischen Docker-basierten und nicht Docker-basierten Installationen.

Im Nicht-Docker-Fall führen Sie die folgenden Befehle als Benutzer otobo aus:

# falls Sie als root angemeldet sind

root> su - otobo

otobo> /opt/otobo/bin/Cron.sh stop

otobo> /opt/otobo/bin/otobo.Daemon.pl stop --force

Wenn OTOBO in Docker läuft, müssen Sie lediglich den Dienst daemon stoppen:

docker_admin> cd /opt/otobo-docker

docker_admin> docker-compose stop daemon

docker_admin> docker-compose ps     # otobo_daemon_1 sollte mit dem Code 0 beendet haben

Hinweis

Es wird empfohlen, an diesem Punkt ein Backup des gesamten OTOBO-Systems durchzuführen. Wenn während der Migration etwas schiefgeht, müssen Sie nicht den gesamten Installationsprozess wiederholen, sondern können stattdessen das Backup für eine neue Migration importieren.

Tipp

Wir empfehlen Ihnen, das Kapitel OTOBO Backup backup-restore zu lesen.

Optional /opt/otrs mounten

Oft soll OTOBO auf einem neuen Server laufen, wo /opt/otrs anfangs nicht verfügbar ist. In diesen Fällen kann das Verzeichnis /opt/otrs auf dem ((OTRS)) Community Edition-Server in das Dateisystem des OTOBO-Servers eingebunden werden. Wenn ein reguläres Netzwerk-Mount nicht möglich ist, könnte sshfs eine Option sein.

Optional: sshpass und rsync

Dieser Schritt ist nur notwendig, wenn Sie ((OTRS)) Community Edition von einem anderen Server migrieren möchten und /opt/otrs vom Remote-Server nicht auf dem OTOBO-Server eingebunden wurde.

Die Werkzeuge sshpass und rsync werden benötigt, damit migration.pl Dateien per ssh kopieren kann. Um sshpass zu installieren, melden Sie sich bitte als Benutzer root auf dem Server an und führen Sie einen der folgenden Befehle aus:

sshpass unter Debian / Ubuntu Linux installieren

sudo apt install sshpass

sshpass unter RHEL/CentOS Linux installieren

sudo yum install sshpass

sshpass unter Fedora Linux installieren

sudo dnf install sshpass

sshpass unter OpenSUSE Linux installieren

sudo zypper install sshpass

Das Gleiche muss für rsync geschehen, wenn es noch nicht verfügbar ist.

Schritt 4: Vorbereitung

Hinweis

Stellen Sie sicher, dass Sie auch ein gültiges Backup Ihres OTRS / ((OTRS)) Community Edition-Systems haben. Ja, wir berühren während der Migration keine ((OTRS)) Community Edition-Daten, aber manchmal reicht schon ein falscher Eintrag, um Probleme zu verursachen.

Nun sind wir bereit für die Migration. Zunächst müssen wir sicherstellen, dass keine Tickets mehr bearbeitet werden und sich keine Benutzer bei ((OTRS)) Community Edition anmelden:

Bitte loggen Sie sich in den ((OTRS)) Community Edition Admin-Bereich Admin -> Systemwartung ein und fügen Sie einen neuen Systemwartungsslot für einige Stunden hinzu. Löschen Sie danach alle Agenten- und Benutzersitzungen (Admin -> Sitzungen) und loggen Sie sich aus.

Alle relevanten Dienste und den OTRS-Daemon stoppen

Stellen Sie bitte sicher, dass keine Dienste oder Cron-Jobs laufen.

su - otrs
/opt/otrs/bin/Cron.sh stop
/opt/otrs/bin/otrs.Daemon.pl stop --force

Die Zwischenspeicher und Betriebsdaten löschen

Die zwischengespeicherten Daten und die Betriebsdaten müssen nicht migriert werden. Die E-Mail-Queue sollte zu diesem Zeitpunkt bereits leer sein.

su - otrs
/opt/otrs/bin/otrs.Console.pl Maint::Cache::Delete
/opt/otrs/bin/otrs.Console.pl Maint::Session::DeleteAll
/opt/otrs/bin/otrs.Console.pl Maint::Loader::CacheCleanup
/opt/otrs/bin/otrs.Console.pl Maint::WebUploadCache::Cleanup
/opt/otrs/bin/otrs.Console.pl Maint::Email::MailQueue --delete-all

Optional Schritt für Docker

Es gibt einige Besonderheiten zu beachten, wenn Ihre OTOBO-Installation unter Docker läuft. Das relevanteste: Prozesse, die in einem Docker-Container laufen, können generell keine Verzeichnisse außerhalb des Containers zugreifen. Es gibt jedoch eine Ausnahme: Verzeichnisse, die als Volumes in den Container eingebunden sind, können zugegriffen werden. Beachten Sie auch, dass die MariaDB-Datenbank, die in otobo_db_1 (otobo-db-1 in neueren docker compose Versionen) läuft, nicht direkt von außerhalb des Container-Netzwerks zugänglich ist.

Hinweis

In den Beispielen Befehlen gehen wir davon aus, dass der Benutzer docker_admin für die Interaktion mit Docker verwendet wird. Der Docker-Administrator kann entweder der root-Benutzer des Docker-Hosts oder ein dedizierter Benutzer mit den erforderlichen Berechtigungen sein.

Kopieren Sie /opt/otrs in das Volume otobo_opt_otobo

Container Namen

In alten docker compose Versionen sind die Container Namen otobo_web_1, otobo_db_1 und otobo_daemon_1. In neueren Versionen sind die Container Namen otobo-web-1, otobo-db-1 und otobo-daemon-1.

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

Es gibt mindestens zwei praktikable Möglichkeiten:

a. Kopieren Sie /opt/otrs in das bestehende Volume otobo_opt_otobo

b. Binden Sie /opt/otrs als zusätzliches Volume ein

Konzentrieren wir uns hier auf Option a..

Zunächst müssen wir herausfinden, wo das Volume otobo_opt_otobo auf dem Docker-Host verfügbar ist.

 otobo_opt_otobo_mp=$(docker volume inspect --format '{{ .Mountpoint }}' otobo_opt_otobo)
echo $otobo_opt_otobo_mp

Für sicheres Kopieren verwenden wir rsync. Je nach Ihrer Docker-Konfiguration muss der Befehl rsync möglicherweise mit sudo ausgeführt werden.

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
ls -la $otobo_opt_otobo_mp/var/tmp/copied_otrs  # nur zur Überprüfung
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
sudo ls -la $otobo_opt_otobo_mp/var/tmp/copied_otrs  # nur zur Überprüfung

Dieses kopierte Verzeichnis wird innerhalb des Containers als /opt/otobo/var/tmp/copied_otrs verfügbar sein.

Schritt 5: Daten migrieren

Docker Compose Command

In alten Docker Compose Versionen wurde der Befehl docker-compose verwendet. In neueren Versionen wird docker compose verwendet.

Bitte verwenden Sie das Webmigrations-Tool unter http://localhost/otobo/migration.pl. Beachten Sie, dass Sie möglicherweise “localhost” durch Ihren OTOBO-Hostnamen ersetzen und möglicherweise Ihren nicht standardmäßigen Port hinzufügen müssen. Die Anwendung leitet Sie dann durch den Migrationsprozess.

Achtung

Manchmal wird eine Warnung angezeigt, dass die Deaktivierung des SecureMode nicht erkannt wurde. Bitte starten Sie in diesem Fall den Webserver neu. Das zwingt den Webserver, die aktuelle Konfiguration einzulesen.

service apache2 restart
cd /opt/otobo-docker
docker-compose restart web
docker-compose ps

Hinweis

Wenn OTOBO in einem Docker-Container läuft, behalten Sie die Standardeinstellungen localhost für den OTRS-Server und_/opt/otobo/var/tmp/copied_otrs_ für das OTRS-Home-Verzeichnis bei. Dies ist der Pfad der Daten, die im optionalen Schritt kopiert wurden.

Hinweis

Die Standardwerte für OTRS-Datenbanknutzer und -passwort werden aus Kernel/Config.pm im OTRS-Home-Verzeichnis übernommen. Ändern Sie die vorgeschlagenen Einstellungen, wenn Sie einen dedizierten Datenbanknutzer für die Migration verwenden. Ändern Sie auch die Einstellungen, wenn Sie mit einer Datenbank arbeiten, die in den otobo_db_1 Docker-Container kopiert wurde.

Hinweis

Im Docker-Fall ist eine Datenbank, die auf dem Docker-Host läuft, nicht über 127.0.0.1 innerhalb des Docker-Containers erreichbar. Das bedeutet, dass die Einstellung 127.0.0.1 nicht gültig für das Eingabefeld OTRS-Server sein wird. Geben Sie in diesem Fall eine der alternativen IP-Adressen ein, die vom Befehl hostname --all-ip-addresses für OTRS-Server gemeldet werden.

Hinweis

Bei der Migration zu einem neuen Anwendungsserver oder zu einer Docker-basierten Installation kann die Datenbank oft nicht von der Zielinstallation aus zugegriffen werden. Dies liegt normalerweise daran, dass der otobo Datenbanknutzer nur vom Host, auf dem die Datenbank läuft, verbinden kann. Um den Zugriff dennoch zu ermöglichen, wird empfohlen, einen dedizierten Datenbanknutzer für die Migration zu erstellen, z.B. CREATE USER 'otrs_migration'@'%' IDENTIFIED BY 'otrs_migration'; und GRANT SELECT, SHOW VIEW ON otrs.* TO 'otrs_migration'@'%';. Dieser Nutzer kann nach der Migration wieder gelöscht werden: DROP USER 'otrs_migration'@'%'.

Benutzerspezifische Einstellungen in Kernel/Config.pm werden von der alten OTRS-Installation auf die neue OTOBO-Installation übertragen. Wenn Sie benutzerspezifische Einstellungen haben, sollten Sie einen Blick auf die migrierte Datei /opt/otobo/Kernel/Config.pm werfen. Möglicherweise möchten Sie benutzerdefinierte Pfade oder LDAP-Einstellungen anpassen. Im besten Fall stellen Sie fest, dass einige benutzerdefinierte Einstellungen nicht mehr benötigt werden.

Wenn die Migration abgeschlossen ist, nehmen Sie sich bitte Zeit und testen Sie das gesamte System. Sobald Sie entschieden haben, dass die Migration erfolgreich war und Sie OTOBO von jetzt an verwenden möchten, starten Sie den OTOBO-Daemon:

su - otobo
/opt/otobo/bin/Cron.sh start
/opt/otobo/bin/otobo.Daemon.pl start

Im Docker-Fall:

cd ~/otobo-docker
docker-compose start daemon

Schritt 6: Clean-Up

1. Deinstallieren Sie sshpass, wenn Sie es nicht mehr benötigen.

2. Löschen Sie die Datenbanken und Datenbanknutzer, die speziell für die Migration erstellt wurden, falls vorhanden.

3. Viel Spaß mit OTOBO!

Bekannte Migrationsprobleme

Anmeldung nach der Migration nicht möglich

Während unserer Migrationstests hatte der für die Migration verwendete Browser manchmal Probleme. Nach dem Neustart des Browsers wurde dieses Problem normalerweise gelöst. Bei Safari war es manchmal notwendig, die alte OTRS-Sitzung manuell zu löschen.

Finale Seite der Migration hat ein seltsames Layout

Das kann passieren, wenn die Einstellung ScriptAlias einen nicht standardmäßigen Wert hat. Die Migration ersetzt einfach otrs durch otobo. Das kann dazu führen, dass die CSS- und JavaScript-Dateien in OTOBO nicht mehr abgerufen werden können. Wenn dies der Fall ist, überprüfen Sie bitte die Einstellungen in Kernel/Config.pm und ändern Sie diese zurück auf vernünftige Werte.

Migration stoppt wegen MySQL-Fehlern

Auf Systemen, die in der Vergangenheit Probleme bei einem Upgrade hatten, kann der Migrationsprozess aufgrund von MySQL-Fehlern in den Tabellen ticket und ticket_history stoppen. In der Regel handelt es sich dabei um NULL-Werte in der Quelltabelle, die in der Zieltabelle nicht mehr zulässig sind. Diese Konflikte müssen manuell gelöst werden, bevor Sie die Migration fortsetzen können.

Ab OTOBO 10.0.12 gibt es eine Prüfung in migration.pl, die auf NULL-Werte vor der Datenübertragung prüft. Beachten Sie, dass die Lösung immer noch manuell durchgeführt werden muss.

Fehler in Schritt 5 bei der Migration zu PostgreSQL

In diesen Fällen wird die nicht sehr hilfreiche Nachricht “Das System konnte die Datenübertragung nicht abschließen.” von migration.pl angezeigt. Das Apache-Logfile und das OTOBO-Logfile zeigen eine aussagekräftigere Nachricht: ” Fehlermeldung: ERROR: permission denied to set parameter “session_replication_role”, SQL: ‘set session_replication_role to replica;’” Um dem Datenbanknutzer otobo die benötigten Superuser-Privilegien zu gewähren, führen Sie folgenden Befehl als PostgreSQL-Admin aus: ALTER USER otobo WITH SUPERUSER;. Versuchen Sie dann erneut, http://localhost/otobo/migration.pl auszuführen. Nach der Migration, kehren Sie zum normalen Zustand zurück, indem Sie ALTER USER otobo WITH NOSUPERUSER ausführen.

Es ist noch nicht klar, ob die erweiterten Privilegien in jedem Setup gewährt werden müssen.

Tipp

Die Diskussion in OTOBO Forum

Probleme mit dem Deployment der zusammengeführten Systemkonfiguration

Die Systemkonfiguration wird migriert, nachdem die Datenbanktabellen migriert wurden. In diesem Kontext bedeutet Migration, dass die Standardeinstellungen von OTOBO mit der Systemkonfiguration des Quell-OTRS-Systems zusammengeführt werden. In diesem Schritt können Inkonsistenzen auftreten. Ein Beispiel aus der Praxis ist die Einstellung Ticket::Frontend::AgentTicketQuickClose###State. Diese Einstellung ist neu in OTOBO 10 und der Standardwert ist der Status closed successful. Aber diese Einstellung ist ungültig, wenn der Status closed successful im Quellsystem gelöscht oder umbenannt wurde. Diese Inkonsistenz wird als Fehler im Migrationschritt Migrate configuration settings erkannt. Die zusammengeführte Systemkonfiguration wird tatsächlich in der Datenbank gespeichert, aber zusätzliche Gültigkeitsprüfungen werden während der Bereitstellung durchgeführt.

Das Problem muss manuell mittels OTOBO-Konsolenbefehlen behoben werden.

• Listet die Inkonsistenzen mit dem Befehl bin/otobo.Console.pl Admin::Config::ListInvalid auf.

• Beheben Sie die ungültigen Werte interaktiv mit bin/otobo.Console.pl Admin::Config::FixInvalid.

• Deployen Sie die gesammelten Änderungen von migration.pl, einschließlich des deaktivierten SecureMode, mit bin/otobo.Console.pl Maint::Config::Rebuild.

Nach diesen manuellen Schritten sollten Sie in der Lage sein, migration.pl erneut auszuführen. Die Migration wird mit dem Schritt fortgesetzt, in dem der Fehler auftrat.

Abschließende Manuelle Aufgaben

Passwortrichtlinienregeln

Mit OTOBO 10 tritt eine neue Standard-Passwortrichtlinie für Agenten- und Kundenbenutzer in Kraft, wenn die lokale Authentifizierung verwendet wird. Die Passwortrichtlinienregeln können in der Systemkonfiguration (PreferencesGroups###Password und CustomerPersonalPreference###Password) geändert werden.

| Passwortrichtlinienregel | Standard |

|-------------------------------------------|--------------------|

| PasswordMinSize | 8 |

| PasswordMin2Lower2UpperCharacters | Ja |

| PasswordNeedDigit | Ja |

| PasswordHistory | 10 |

| PasswordTTL | 30 Tage |

| PasswordWarnBeforeExpiry | 5 Tage |

| PasswordChangeAfterFirstLogin | Ja |

Unter Docker: Manuell migrieren von Cron-Jobs

In einer nicht Docker-basierten Installation von OTOBO gibt es mindestens einen Cron-Job, der die Gesundheit des Daemons überprüft. Unter Docker existiert dieser Cron-Job nicht mehr. Darüber hinaus läuft kein Cron-Daemon in einem der Docker-Container. Dies bedeutet, dass Sie nach einer individuellen Lösung für OTRS-Systeme mit benutzerspezifischen Cron-Jobs suchen müssen (z. B. Backup der Datenbank).

Migration von Oracle zu Oracle

Für die Migration zu Oracle muss die ETL-ähnliche Strategie angewendet werden. Dies liegt daran, dass Oracle keinen einfachen Weg bietet, die Überprüfung von Fremdschlüsseln vorübergehend auszuschalten.

Auf dem OTOBO-Host muss ein Oracle-Client sowie das Perl-Modul DBD::Oracle installiert sein.

Hinweis

Bei Verwendung des Oracle-Instant-Clients ist auch das optionale SDK für die Installation von DBD:: Oracle erforderlich.

Es gibt viele Möglichkeiten, ein Schema zu klonen. In den Beispielbefehlen verwenden wir expdp und impdp, die Data Pump unter der Haube nutzen.

Hinweis

Die in dieser Dokumentation gezeigten Verbindungsstrings beziehen sich auf den Fall, wenn sowohl die Quell- als auch die Zieldatenbank in einem Docker-Container laufen. Siehe auch https://github.com/bschmalhofer/otobo-ideas/blob/master/oracle.md.

1. Bereinigung von otobo

Stoppen Sie den Webserver für otobo, damit die DB-Verbindung für otobo geschlossen wird.

DROP USER otobo CASCADE

2. Export des gesamten OTRS-Schemas.

mkdir /tmp/otrs_dump_dir

CREATE DIRECTORY OTRS_DUMP_DIR AS '/tmp/otrs_dump_dir';

GRANT READ, WRITE ON DIRECTORY OTRS_DUMP_DIR TO sys;

expdp \"sys/Oradoc_db1@//127.0.0.1/orclpdb1.localdomain as sysdba\" schemas=otrs directory=OTRS_DUMP_DIR dumpfile=otrs.dmp logfile=expdpotrs.log

3. Das OTRS-Schema importieren und das Schema in ‘otobo’ umbenennen.

impdp \"sys/Oradoc_db1@//127.0.0.1/orclpdb1.localdomain as sysdba\" directory=OTRS_DUMP_DIR dumpfile=otrs.dmp logfile=impdpotobo.log remap_schema=otrs:otobo

select owner, table_name from all_tables where table_name like 'ARTICLE_DATA_OT%_CHAT';
    ALTER USER otobo IDENTIFIED BY XXXXXX;

4. Anpassen des geklonten Schemas otobo

cd /opt/otobo

scripts/backup.pl --backup-type migratefromotrs # es ist in Ordnung, dass der Befehl nur von der otobo Datenbank weiß, nur die letzte Zeile ist relevant

sqlplus otobo/otobo@//127.0.0.1/orclpdb1.localdomain < /home/bernhard/devel/OTOBO/otobo/2021-03-31_13-36-55/orclpdb1.localdomain_post.sql >sqlplus.out 2>&1

Zur Kontrolle mit `select owner, table_name from all_tables where table_name like 'ARTICLE_DATA_OT%_CHAT';

5. Starten Sie den Webserver für OTOBO erneut

6. Fahren Sie mit Schritt 5 fort, das heißt, führen Sie migration.pl aus.

Hinweis

Wenn auf eine OTOBO-Version größer oder gleich 10.1 migriert wird, muss das Skript /opt/otobo/scripts/DBUpdate-to-10.1.pl ausgeführt werden, um die neu in Version 10.1 hinzugefügten Tabellen stats_report und data_storage zu erstellen.

Optional: Vereinfachte Migration der Datenbank (nur für Experten und spezielle Szenarien)

In der allgemeinen Migrationsstrategie werden alle Daten in den Datenbanktabellen Zeile für Zeile von der OTRS-Datenbank in die OTOBO-Datenbank kopiert. Das Exportieren der Daten aus der OTRS-Datenbank und das Importieren in die OTOBO-Datenbank kann Zeit sparen und ist in einigen Fällen stabiler.

Hinweis

Diese Variante funktioniert sowohl für Docker-basierten als auch für native Installationen.

Hinweis

Diese Anweisungen gehen davon aus, dass ((OTRS)) Community Edition MySQL als Backend verwendet.

Zuallererst benötigen wir einen Dump der benötigten OTRS-Datenbanktabellen. Dann müssen wir einige Transformationen durchführen:

• Konvertierung des Zeichensatzes zu utf8mb4

• Umbenennung einiger Tabellen

• Kürzung einiger Tabellenspalten

Nach der Transformation können wir die Tabellen im OTOBO-Schema mit den transformierten Daten aus OTRS überschreiben. Effektiv benötigen wir nicht eine einzige Dump-Datei, sondern mehrere SQL-Skripte.

Wenn mysqldump installiert ist und eine Verbindung zur OTRS-Datenbank möglich ist, können Sie den Datenbankdump direkt auf dem Docker-Host erstellen. Dieser Fall wird durch das Skript bin/backup.pl unterstützt.

Achtung

Dies erfordert, dass eine OTOBO-Installation auf dem Docker-Host verfügbar ist.

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

Hinweis

Alternativ kann die Datenbank auf einem anderen Server gesichert und anschließend auf den Docker-Host übertragen werden. Eine einfache Möglichkeit, dies zu tun, besteht darin, /opt/otobo auf den Server zu kopieren, auf dem OTRS läuft, und den gleichen Befehl wie oben auszuführen.

Das Skript bin/backup.pl erzeugt vier SQL-Skripte in einem Dump-Verzeichnis, z.B. in 2021-04-13_12-13-04. Um die SQL-Skripte auszuführen, müssen wir den Befehl mysql ausführen.

Native Installation:

cd <dump_dir>
mysql -u root -p<root_secret> otobo < otrs_pre.sql
mysql -u root -p<root_secret> otobo < otrs_schema_for_otobo.sql
mysql -u root -p<root_secret> otobo < otrs_data.sql
mysql -u root -p<root_secret> otobo < otrs_post.sql

Docker-basierte Installation:

Führen Sie den Befehl mysql innerhalb des Docker-Containers db aus, um die Datenbank-Dump-Dateien zu importieren. Beachten Sie, dass das Passwort für den Datenbank-Root nun das Passwort ist, das in der Datei .env auf dem Docker-Host festgelegt wurde.

cd /opt/otobo-docker
docker-compose exec -T db mysql -u root -p<root_secret> otobo < /opt/otobo/<dump_dir>/otrs_pre.sql
docker-compose exec -T db mysql -u root -p<root_secret> otobo < /opt/otobo/<dump_dir>/otrs_schema_for_otobo.sql
docker-compose exec -T db mysql -u root -p<root_secret> otobo < /opt/otobo/<dump_dir>/otrs_data.sql
docker-compose exec -T db mysql -u root -p<root_secret> otobo < /opt/otobo/<dump_dir>/otrs_post.sql

Für eine schnelle Überprüfung, ob der Import funktioniert hat, können Sie die folgenden Befehle ausführen.

mysql -u root -p<root_secret> -e 'SHOW DATABASES'
mysql -u root -p<root_secret> otobo -e 'SHOW TABLES'
mysql -u root -p<root_secret> otobo -e 'SHOW CREATE TABLE ticket'

oder bei Ausführung unter Docker

docker-compose exec -T db mysql -u root -p<root_secret> -e 'SHOW DATABASES'
docker-compose exec -T db mysql -u root -p<root_secret> otobo -e 'SHOW TABLES'
docker-compose exec -T db mysql -u root -p<root_secret> otobo -e 'SHOW CREATE TABLE ticket'

Die Datenbank ist nun migriert. Dies bedeutet, dass wir im nächsten Schritt die Datenbankmigration überspringen können. Achten Sie auf das entsprechende Kontrollkästchen.

OTRS sicher zu OTOBO migrieren

Planen Sie Datenübernahme, Testlauf, Erweiterungsprüfung und Go-live gemeinsam mit einem OTOBO-Spezialisten.

Migration besprechen

Häufig gestellte Fragen

Kann ich von der OTRS Community Edition zu OTOBO migrieren?

Ja. Diese Anleitung beschreibt Anforderungen und Schritte, damit Sie Daten sicher nach OTOBO übernehmen können.

Was sollte ich vor der Migration von OTRS nach OTOBO tun?

Installieren Sie eine lauffähige OTOBO-Instanz, sichern Sie das OTRS-System und prüfen Sie die Migrationsanforderungen auf dieser Seite.

Warum zu OTOBO 11 migrieren?

OTOBO 11 führt das Open-Source-Ticketsystem mit aktuellen Funktionen, Sicherheitsupdates und einem aktiven OTRS-Fork weiter.

Was sollte ich über Optional: sshpass und rsync wissen?

Dieser Schritt ist nur notwendig, wenn Sie ((OTRS)) Community Edition von einem anderen Server migrieren möchten und _/opt/otrs_ vom Remote-Server nicht auf dem OTOBO-Server eingebunden wurde. Die Werkzeuge `sshpass` und `rsync` werden benötigt, damit _migration.pl_ Dateien per ssh kopieren kann…

Wie funktioniert Migration stoppt wegen MySQL-Fehlern?

Auf Systemen, die in der Vergangenheit Probleme bei einem Upgrade hatten, kann der Migrationsprozess aufgrund von MySQL-Fehlern in den Tabellen _ticket_ und _ticket_history_ stoppen. In der Regel handelt es sich dabei um NULL-Werte in der Quelltabelle, die in der Zieltabelle nicht mehr zulässig…