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 werden einen Weg finden, Ihnen zu helfen!

Bemerkung

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

Übersicht über die unterstützen Migrationsmöglichkeiten¶

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

Die grundsätzliche Migrationsstrategie.

Dies ist der reguläre Weg, um eine Migration durchzuführen. Viele weitere Varianten sind möglich:

Wechsel des Servers:

Eine Migration mit gleichzeitigem Wechsel zu einem neuen Applikationsserver.

Trennung von Applikation und Webserver:

Sie haben die Möglichkeit, den Anwendungs- und Datenbankserver auf einem gemeinsamen oder zwei verschiedenen Servern laufen lassen – unabhängig davon, wie das beim OTRS- / ((OTRS)) Community Edition-Vorgängersystem war.

Verschiedene Datenbanken:

Sie können von jeder der unterstützten Datenbanken zu einer anderen migrieren.

Wechsel des Betriebssystems:

Sie können während der Migration von jedem unterstützten Betriebssystem zu jedem anderen unterstützten Betriebssystem wechseln.

Docker:

Auch die Migration zu einer Docker-basierten OTOBO 10-Installation ist möglich.
A variant of the general strategy where the database migration is streamlined.

Use the ETL-like migration when the source database mustn’t suffer from increased load or when access to the source database is a bottleneck. In the general strategy, the data is row by row first read from the otrs database and then inserted into the OTOBO database. In this variant, the complete otrs database tables are first exported, then transformed, and then imported into the otobo database.
Migration von einer Oracle-basierten OTRS 6 Installation zu einer Oracle-basierten OTOBO Installation.

This is a special case that is not supported by the general migration strategy. This means that a variant of the streamlined strategy must be used.

Warnung

Alle Strategien funktionieren sowohl für Docker-basierte als auch für native Installationen. Bei der Docker-basierten Installation gibt es einige Besonderheiten zu beachten. Sie werden in den optionalen Schritten behandelt.

Bemerkung

Es ist auch möglich, die OTRS Datenbank vor der Migration auf den OTOBO Datenbankserver zu klonen. Auf diese Weise kann die allgemeine Migrationsstrategie beschleunigt werden.

Migrationsvoraussetzungen¶

Grundvoraussetzung für eine Migration ist, dass Sie bereits eine laufende ((OTRS)) Community Edition oder ein OTRS 6.0.* haben und dass deren Konfiguration und Daten in OTOBO übernommen werden sollen.

Warnung

Please consider carefully whether you really need the data and configuration. Experience shows that quite often a new start is the better option. This is because in many cases the previously used installation and configuration was rather suboptimal anyways. It might also make sense to only transfer the ticket data and to change the basic configuration to OTOBO Best Practice. We are happy to advise you, please get in touch at hello@otobo.de or ask your question in the OTOBO Community forum at https://forum.otobo.org/.

Sie benötigen eine betriebsbereite OTOBO-Installation als Ausgangpunkt für die Migration!
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.
Wenn Sie auf einen anderen Server migrieren möchten, muss der OTOBO-Webserver in der Lage sein, auf das Verzeichnis zuzugreifen, in dem die ((OTRS)) Community Edition oder OTRS 6.0.* installiert sind. Meist ist dies das Verzeichnis /opt/otrs auf dem Server, auf dem das OTRS läuft. Der Lesezugriff erfolgt über SSH oder Dateisystem-Mounts.
Die otrs-Datenbank muss von dem Server aus erreichbar sein, auf dem OTOBO läuft. Externe Hosts müssen Lesezugriff haben. Wo kein Zugriff möglich ist oder die Migration beschleunigt werden soll, kann auch mit einem Datenbank-Dump gearbeitet werden.

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

Under Apache, there are pitfalls with running two independent mod_perl applications under on the same webserver. Therefore, it is advised to run OTRS and OTOBO on separate webservers. Alternatively remove the OTRS configuration from Apache before installing OTOBO. Use the command a2query -s and check the directories /etc/apache2/sites-available and /etc/apache2/sites-enabled for inspecting which configurations are currently available and which are enabled.

Sobald die Installation abgeschlossen ist, melden Sie sich bitte in OTOBO als root@localhost 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
OTRSDynamicFieldDatabase
OTRSDynamicFieldWebService
OTRSBruteForceAttackProtection
Znuny4OTRS-ExternalURLJump
Znuny4OTRS-QuickClose
Znuny4OTRS-AutoCheckbox
OTRSSystemConfigurationHistory
Znuny4OTRS-PasswordPolicy

Schritt 2: `SecureMode` in OTOBO deaktivieren¶

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.

Bemerkung

Bitte vergessen Sie nicht, die geänderte Einstellung anschließend in Betrieb zu nehmen.

Schritt 3: OTOBO-Daemon stoppen¶

Dies ist nötig, wenn der OTOBO Daemon aktuell läuft. Das Vorgehen, um den OTOBO Daemon zu stoppen unterscheidet sich bei Docker-basierten und nicht-Docker-basierten (nativen) Installationen.

Bei nicht-Docker-basierten Installationen führen Sie die folgenden Befehle als User otobo aus:

# in case you are logged in as root
root> su - otobo

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

Läuft OTOBO in Docker, genügt es, den Dienst daemon 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.

Optionaler Schritt: Für leichteren Zugriff /opt/otrs einhängen¶

In vielen Fällen soll OTOBO auf einem neuen Server laufen, auf dem /opt/otrs noch nicht zur Verfügung steht. In diesen Fällen kann das /opt/otrs-Verzeichnis des OTRS-Servers in das Dateisystem auf dem OTOBO-Server eingehängt werden. Falls ein normales Einhängen über das Netzwerk nicht möglich ist, können Sie beispielsweise auf sshfs zurückgreifen.

Optionaler Schritt: Installieren von `sshpass` und `rsync`, wenn /opt/otrs über SSH kopiert werden soll¶

Dieser Schritt ist nur dann nötig, wenn Sie OTRS von einem anderen Server migrieren möchten und /opt/otrs des OTRS-Servers nicht auf dem OTOBO-Server eingehängt wurde.

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:

$ # 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 4: OTRS / ((OTRS)) Community Edition Quellsystem vorbereiten¶

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

Optionaler Schritt für 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:

/opt/otrs in das bestehende Volume otobo_opt_otobo kopieren

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

Optional Step: Streamlined migration of the database¶

Bei der allgemeinen Migrationsstrategie werden alle Daten der Datenbanktabellen Zeile für Zeile von der OTRS-Datenbank in die OTOBO-Datenbank kopiert. In manchen Fällen kann ein Export der OTRS-Datenbank und der anschließende Import in die OTOBO-Datenbank schneller und zuverlässiger sein.

Bemerkung

Diese Variante funktioniert sowohl bei Docker-basierten als auch bei nativen Installationen.

Bemerkung

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

Zuerst muss ein Datenbank-Dump der OTRS-Tabellen erstellt werden. Anschließend führen wir ein paar Transformationen durch:

Konvertierung des Zeichensatzes auf utf8mb4

umbenennen einiger Tabellen

Kürzung bestimmter Tabellenspalten

After the transfomation we can overwrite the tables in the OTOBO schema with the transformed data from OTRS. Effectively we need not a single dump file, but several SQL scripts.

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"

Bemerkung

Alternatively, the database can be dumped on another server and then be transferred to the Docker host afterwards. An easy way to do this is to copy /opt/otobo to the server running OTRS and perform the same command as above.

Das Script bin/backup.pl generiert vier SQL-Dateien in einem Dump-Verzeichnis, z.B. in 2021-04-13_12-13-04. Um diese SQL-Dateien auszuführen, wird der Kommandozeilenbefehl mysql genutzt.

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 OTOBO-Installation:

Run the command mysql within the Docker container db for importing the database dump files. Note that the password for the database root is now the password that has been set up in the file .env on the Docker host.

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

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

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

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 wurde nun migriert. Das bedeutet, dass Sie im nächsten Schritt die Datenbankmigration überspringen können. Beachten Sie hierzu die entsprechende Checkbox.

Schritt 5: 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). Der Assistent 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.

# native installation
root> service apache2 restart

# Docker-based installation
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 im optionalen Schritt 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'@'%'.

Custom settings in Kernel/Config.pm are carried over from the old OTRS installation to the new OTOBO installation. When you have custom settings, then please take a look at the migrated file /opt/otobo/Kernel/Config.pm. You might want to adapt custom pathes or LDAP settings. In the best case you might find that some custom setting are longer needed.

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

In der Docker-Umgebung:

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

Schritt 6: Nach der erfolgreichen Migration!¶

Deinstallieren Sie sshpass, wenn Sie es nicht mehr benötigen.
Löschen Sie ggf. speziell für die Migration angelegte Datenbanken und Datenbankbenutzer.
Viel Vergnügen mit OTOBO!

Bekannte Probleme bei der Migration¶

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.

3. Migration stops due to MySQL errors¶

Auf Systemen, bei denen es in der Vergangenheit Probleme mit Upgrades gab, wird der Migrationsprozess unter Umständen wegen MySQL-Fehlern in den Tabellen ticket und ticket_history unterbrochen. Typischerweise stammen diese Fehler von NULL-Werten in der Quell-Tabelle, die in der Ziel-Tabelle nicht mehr erlaubt sind. Diese Konflikte müssen manuell behoben werden, bevor die Migration fortgesetzt werden kann.

Seit OTOBO 10.0.12 gibt es in migration.pl eine Überprüfung auf NULL Werte, bevor die Daten übertragen werden. Bitte beachten Sie, dass die Behebung trotzdem manuell durchgeführt werden muss.

4. Errors in Step 5 when migrating to PostgreSQL¶

In these cases the not so helpful message „System was unable to complete data transfer.“ is shown by migration.pl. The Apache logfile, and the OTOBO logfile, show a more meaningful message: „Message: ERROR: permission denied to set parameter „session_replication_role“, SQL: ‚set session_replication_role to replica;‘“. In order to give the database user otobo the needed superuser privileges, run the following statement as the PostgreSQL admin: ALTER USER otobo WITH SUPERUSER;. Then retry running http://localhost/otobo/migration.pl. After the migration, return to the normal state by running ALTER USER otobo WITH NOSUPERUSER.

Es ist bisher nicht geklärt, ob die erweiterten Berechtigungen in jedem Setup gewährt werden müssen.

Siehe auch

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

5. Problems with the Deployment the Merged System Configuration¶

The system configuration is migrated after the database tables were migrated. In this context, migration means merging the default settings of OTOBO with the system configuration of the source OTRS system. Inconsistencies can arise in this step. An real life example is the setting Ticket::Frontend::AgentTicketQuickClose###State. This setting is new in OTOBO 10 and the default value is the state closed successful. But this setting is invalid when the state closed successful has been dropped or renamed in the source system. This inconsistency is detected as an error in the migration step Migrate configuration settings. Actually, the merged system configuration is stored in the database, but additional validity checks are performed during deployment.

Das Problem muss manuell mit Hilfe der OTOBO Konsolenbefehle gelöst werden.

Auflistung der Inkonsistenzen mit Hilfe des Befehls bin/otobo.Console.pl Admin::Config::ListInvalid
Ungültige Werte können mit Hilfe des Befehls bin/otobo.Console.pl Admin::Config::FixInvalid interaktiv behoben werden
Nehmen Sie die gesammelten Änderungen durch migration.pl inklusive des deaktivierten SecureMode mit bin/otobo.Console.pl Maint::Config::Rebuild in Betrieb

Nach diesen manuellen Schritten sollten Sie migration.pl erneut ausführen können. Die Migration setzt dann an dem Schritt fort, bei dem der Fehler aufgetreten ist.

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.

Spezielle Themen¶

Migration von Oracle zu Oracle¶

For migration to Oracle the ETL-like strategy must be employed. This is because Oracle provides no easy way to temporarily turn off foreign key checks.

Auf dem OTOBO Server müssen ein Oracle Client und das Perl Modul DBD::Oracle installiert sein.

Bemerkung

Falls der Oracle Instant Client genutzt wird, ist zusätzlich das optionale SDK nötig, um DBD::Oracle zu installieren.

There are many ways of cloning a schema. In the sample commands we use expdb and impdb which use Data Pump under the hood.

Bemerkung

Die Verbindungseinstellungen in dieser Dokumentation gehen davon aus, dass die Quell- und Ziel-Datenbank in einem Docker Container laufen. Mehr dazu unter https://github.com/bschmalhofer/otobo-ideas/blob/master/oracle.md.

Stoppen Sie otobo

Stoppen Sie den OTOBO Webserver, damit die Verbindung zur otobo Datenbank geschlossen wird.

-- in the OTOBO database
DROP USER otobo CASCADE

Export des kompletten OTRS Schemas.

mkdir /tmp/otrs_dump_dir

-- in the OTRS database
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

Import des OTRS Schemas und Umbenennung zu ‚otobo‘.

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 the OTOBO database
-- double check
select owner, table_name from all_tables where table_name like 'ARTICLE_DATA_OT%_CHAT';

-- optionally, set the password for the user otobo
    ALTER USER otobo IDENTIFIED BY XXXXXX;

Anpassung des geklonten otobo Schemas

cd /opt/otobo
scripts/backup.pl --backup-type migratefromotrs # it's OK that the command knows only about the otobo database, only last line is 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
double check with `select owner, table_name from all_tables where table_name like 'ARTICLE_DATA_OT%_CHAT';

Starten Sie den Webserver für otobo wieder
Fahren Sie mit Schritt 5 migration.pl fort.

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

Übersicht über die unterstützen Migrationsmöglichkeiten¶

Migrationsvoraussetzungen¶

Schritt 1: Neues OTOBO-System installieren¶

Schritt 2: SecureMode in OTOBO deaktivieren¶

Schritt 3: OTOBO-Daemon stoppen¶

Optionaler Schritt: Für leichteren Zugriff /opt/otrs einhängen¶

Optionaler Schritt: Installieren von sshpass und rsync, wenn /opt/otrs über SSH kopiert werden soll¶

Schritt 4: OTRS / ((OTRS)) Community Edition Quellsystem vorbereiten¶

Alle relevanten Services und den OTRS Daemon stoppen¶

Optionaler Schritt für Docker: Erforderliche Daten im Container verfügbar machen¶

/opt/otrs in das Volume otobo_opt_otobo kopieren¶

Optional Step: Streamlined migration of the database¶

Schritt 5: Migration durchführen!¶

Schritt 6: Nach der erfolgreichen Migration!¶

Bekannte Probleme bei der Migration¶

1. Login after migration not possible¶

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

3. Migration stops due to MySQL errors¶

4. Errors in Step 5 when migrating to PostgreSQL¶

5. Problems with the Deployment the Merged System Configuration¶

Schritt 7: Manuelle Aufgaben und Anpassungen¶

1. Password policy rules¶

2. Under Docker: Manually migrate cron jobs¶

Spezielle Themen¶

Migration von Oracle zu Oracle¶

Schritt 2: `SecureMode` in OTOBO deaktivieren¶

Optionaler Schritt: Installieren von `sshpass` und `rsync`, wenn /opt/otrs über SSH kopiert werden soll¶