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

Notiz

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.

Warnung

Alle Strategien funktionieren sowohl für Docker-basierte 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.

Notiz

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.

   Warnung

   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.

Notiz

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

Warnung

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.

Notiz

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

Notiz

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.

Tips

Wir empfehlen Ihnen, das Kapitel OTOBO 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-get install sshpass

$ # sshpass unter RHEL/CentOS Linux installieren

$ sudo yum install sshpass

$ # sshpass unter Fedora 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

Notiz

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.

root> su - otrs

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

otrs> /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-Warteschlange sollte zu diesem Zeitpunkt bereits leer sein.

root> su - otrs

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

otrs> /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 läuft, nicht direkt von außerhalb des Container-Netzwerks zugänglich ist.

Notiz

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

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.

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

docker_admin> echo $otobo_opt_otobo_mp  # nur zur Überprüfung

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

docker_admin> # wenn docker_admin root ist

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  # nur zur Überprüfung

docker_admin> # wenn docker_admin nicht root ist

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  # 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

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.

Warnung

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.

# native Installation

root> service apache2 restart

# Docker-basierte Installation

docker_admin> cd /opt/otobo-docker

docker_admin> docker-compose restart web

docker_admin> docker-compose ps     # otobo_web_1 sollte wieder laufen

Notiz

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.

Notiz

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.

Notiz

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.

Notiz

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:

root> su - otobo

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

otobo> /opt/otobo/bin/otobo.Daemon.pl start

Im Docker-Fall:

docker_admin> cd ~/otobo-docker

docker_admin> 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

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

2. Die finale Seite der Migration hat ein seltsames Layout aufgrund fehlender CSS-Dateien

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.

3. Migration stoppt aufgrund von 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.

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

Tips

Die Diskussion in https://otobo.de/de/forums/topic/otrs-6-mysql-migration-to-otobo-postgresql/.

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

Schritt 7: Manuelle Aufgaben

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

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

Notiz

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.

Notiz

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.

-- in der OTOBO-Datenbank

DROP USER otobo CASCADE

2. Export des gesamten OTRS-Schemas.

mkdir /tmp/otrs_dump_dir

-- in der OTRS-Datenbank

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

-- in der OTOBO-Datenbank

-- zur Kontrolle

select owner, table_name from all_tables where table_name like 'ARTICLE_DATA_OT%_CHAT';

-- optional, setzen Sie das Passwort für den Benutzer otobo

    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.

Notiz

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.

Notiz

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

Notiz

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.

Warnung

Dies erfordert, dass eine OTOBO-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"

Notiz

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:

otobo> cd <dump_dir>

otobo> mysql -u root -p<root_secret> otobo < otrs_pre.sql

otobo> mysql -u root -p<root_secret> otobo < otrs_schema_for_otobo.sql

otobo> mysql -u root -p<root_secret> otobo < otrs_data.sql

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

docker_admin> cd /opt/otobo-docker

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

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

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

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

otobo> mysql -u root -p<root_secret> -e 'SHOW DATABASES'

otobo> mysql -u root -p<root_secret> otobo -e 'SHOW TABLES'

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

oder bei Ausführung unter Docker

docker_admin> docker-compose exec -T db mysql -u root -p<root_secret> -e 'SHOW DATABASES'

docker_admin> docker-compose exec -T db mysql -u root -p<root_secret> otobo -e 'SHOW TABLES'

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