Migration von ((OTRS)) Community Edition zu Znuny

This content is not available in your language yet.

Migration von ((OTRS)) Community Edition zu Znuny

Willkommen und vielen Dank, dass Sie sich für Znuny entschieden haben! OTRS, ((OTRS)) Community Edition und Znuny sind in ihrer Anwendung sehr umfassend und flexibel. Daher erfordert jede Migration zu Znuny 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.

::: info

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

:::

Znuny Migration Überblick

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

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 Znuny 10 migrieren.
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 Znuny-Datenbank eingefügt. In dieser Variante werden die kompletten otrs-Datenbanktabellen zuerst exportiert, dann transformiert und dann in die otobo-Datenbank importiert.

Migration von einer auf Oracle basierenden ((OTRS)) Community Edition 6 Installation zu einer auf Oracle basierenden Znuny 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.

::: warning

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.

:::

::: info

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

:::

Migrationsanforderungen

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 Znuny übertragen möchten.

::: warning

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 Znuny Best Practices umzustellen.

:::
Sie benötigen eine laufende Znuny Installation, um von dort aus die Migration zu starten!
Diese Znuny Installation muss alle OPM-Pakete enthalten, die in Ihrem ((OTRS)) Community Edition installiert sind und die Sie auch in Znuny verwenden möchten.
Wenn Sie planen, auf einen anderen Server zu migrieren, muss der Znuny-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.
Die ((otrs)) Community Edition-Datenbank muss vom Server, auf dem Znuny 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.

::: info

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

:::

Schritt für Schritt Anleitung

Schritt 1: Znuny Installation

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

::: warning

Unter Apache gibt es Fallstricke beim Betrieb von zwei unabhängigen mod_perl-Anwendungen auf demselben Webserver. Daher wird empfohlen, ((OTRS)) Community Edition und Znuny auf getrennten Webservern zu betreiben. Alternativ sollte die OTRS-Konfiguration aus Apache entfernt werden, bevor Znuny 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 Znuny Admin-Bereich Admin -> Pakete und installieren Sie alle erforderlichen Znuny 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 Znuny-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 Znuny-Pakete wurden in Znuny 10+ integriert. Das bedeutet, dass sie nicht im Zielsystem installiert werden sollten, wenn das Zielsystem Znuny 10+ ist. - ImportExport

Schritt 2: SecureMode deaktivieren

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

::: info

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

:::

Schritt 3: Znuny Daemon stoppen

Dies ist notwendig, wenn der Znuny 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:

a2query -s

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

Admin -> Pakete

:::: info

Es wird empfohlen, an diesem Punkt ein Backup des gesamten Znuny-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.

::: tip

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

:::

::: details Optional /opt/otrs mounten

Oft soll Znuny 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 Znuny-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 Znuny-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:

::: details sshpass unter Debian / Ubuntu Linux installieren Admin -> Systemkonfiguration :::

::: details sshpass unter RHEL/CentOS Linux installieren SecureMode :::

::: details sshpass unter Fedora Linux installieren daemon :::

::: details sshpass unter OpenSUSE Linux installieren backup-restore :::

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

Schritt 4: Vorbereitung

::: info

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.

sshfs

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.

sshpass

Optional Schritt für Docker

Es gibt einige Besonderheiten zu beachten, wenn Ihre Znuny-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.

::: info

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

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

rsync

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

sshpass

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

Schritt 5: Daten migrieren

:::note 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 Znuny-Hostnamen ersetzen und möglicherweise Ihren nicht standardmäßigen Port hinzufügen müssen. Die Anwendung leitet Sie dann durch den Migrationsprozess.

::: warning

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.

root

:::

::: info

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

:::

::: info

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.

:::

::: info

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.

:::

::: info

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 Znuny 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](../agents/agents.md) '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](../agents/agents.md) 'otrs_migration'@'%'.

:::

Benutzerspezifische Einstellungen in Kernel/Config.pm werden von der alten OTRS-Installation auf die neue Znuny-Installation übertragen. Wenn Sie benutzerspezifische Einstellungen haben, sollten Sie einen Blick auf die migrierte Datei /opt/Znuny/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 Znuny von jetzt an verwenden möchten, starten Sie den Znuny-Daemon:

Admin -> Systemwartung

Im Docker-Fall:

Admin -> Sitzungen

Schritt 6: Clean-Up

Deinstallieren Sie sshpass, wenn Sie es nicht mehr benötigen.
Löschen Sie die Datenbanken und Datenbanknutzer, die speziell für die Migration erstellt wurden, falls vorhanden.
Viel Spaß mit Znuny!

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 Znuny. Das kann dazu führen, dass die CSS- und JavaScript-Dateien in Znuny 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 Znuny 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 Znuny-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 Znuny die benötigten Superuser-Privilegien zu gewähren, führen Sie folgenden Befehl als PostgreSQL-Admin aus: ALTER USER [Znuny](../index.md) 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 [Znuny](../index.md) WITH NOSUPERUSER ausführen.

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

::: tip

Die Diskussion in Znuny 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 Znuny 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 Znuny 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 Znuny-Konsolenbefehlen behoben werden.

Listet die Inkonsistenzen mit dem Befehl bin/Znuny.Console.pl Admin::Config::ListInvalid auf.
Beheben Sie die ungültigen Werte interaktiv mit bin/Znuny.Console.pl Admin::Config::FixInvalid.
Deployen Sie die gesammelten Änderungen von migration.pl, einschließlich des deaktivierten SecureMode, mit bin/Znuny.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 Znuny 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 Znuny 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 Znuny-Host muss ein Oracle-Client sowie das Perl-Modul DBD::Oracle installiert sein.

::: info

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.

::: info

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.

:::

Bereinigung von Znuny

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

otobo_db_1

Export des gesamten OTRS-Schemas.

otobo_web_1

otobo_db_1

otobo_daemon_1

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

otobo-web-1

otobo-db-1

Anpassen des geklonten Schemas Znuny

otobo-daemon-1

Starten Sie den Webserver für Znuny erneut
Fahren Sie mit Schritt 5 fort, das heißt, führen Sie migration.pl aus.

::: info

Wenn auf eine Znuny-Version größer oder gleich 10.1 migriert wird, muss das Skript /opt/Znuny/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 Znuny-Datenbank kopiert. Das Exportieren der Daten aus der OTRS-Datenbank und das Importieren in die Znuny-Datenbank kann Zeit sparen und ist in einigen Fällen stabiler.

::: info

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

:::

::: info

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

::: warning

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

:::

rsync

::: info

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:

rsync

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.

sudo

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

docker-compose

oder bei Ausführung unter Docker

docker compose

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.