Im folgenden Artikel vergleichen wir OTOBO und OTRS. Dabei vergleichen wir die OTRS Versionen 7 und 8 mit dem OTOBO Ticketsystem.

‍

Was ist OTRS?

OTRS steht für "Open-source Ticket Request System". Es handelt sich dabei um eine webbasierte Helpdesk-Software, die für das Management von Support-Anfragen, Anfragen zu Störungen oder anderen Vorgängen im Kundenservice eingesetzt wird.

Mit OTRS können Unternehmen und Organisationen Anfragen von Kunden oder Nutzern über verschiedene Kanäle wie E-Mail, Telefon, Chat oder soziale Medien verwalten. Die Software bietet Funktionen wie Ticket-Management, Service-Level-Agreements (SLAs), Eskalationsprozesse, automatisierte Workflows, Wissensdatenbanken und Berichterstattungsfunktionen.

OTRS ist ein sehr flexibles System und kann für verschiedene Branchen und Anwendungsfälle angepasst werden. Es wird von kleinen und mittelständischen Unternehmen sowie von großen Organisationen und Behörden genutzt, um den Kundensupport und Service-Management-Prozesse zu optimieren.

OTRS Version 7

OTRS Version 7 bietet eine Vielzahl von Funktionen und Features, um die Verwaltung von Tickets und den Kundensupport zu verbessern. Hier sind einige der wichtigsten Features:

1. Multi-Channel-Ticket-Erstellung: Kunden können Tickets über verschiedene Kanäle wie E-Mail, Webformular, Telefon und Chat erstellen, was es einfach macht, Tickets zu erstellen und den Supportprozess zu beschleunigen.
2. Automatisierung von Supportprozessen: Das System bietet umfangreiche Automatisierungsmöglichkeiten, um den Supportprozess zu optimieren, einschließlich der Zuweisung von Tickets an bestimmte Agenten oder Gruppen, der Priorisierung von Tickets und der Eskalation von Tickets an höhere Instanzen.
3. SLA-Management: OTRS ermöglicht die Verwaltung von Service Level Agreements (SLAs), um sicherzustellen, dass Kundenanfragen innerhalb der vereinbarten Zeit bearbeitet werden.
4. Integration von Wissensmanagement: Das integrierte Wissensmanagement-System ermöglicht den Zugriff auf vordefinierte Antworten auf häufig gestellte Fragen, um schnellere Lösungen bereitzustellen.
5. Self-Service-Portal: Kunden können über ein Self-Service-Portal auf ihr Ticket zugreifen, den Status verfolgen und Updates erhalten, was die Kundenzufriedenheit erhöht.
6. Reporting und Analyse: OTRS bietet umfassende Reporting- und Analysemöglichkeiten, um die Leistung des Supportteams zu überwachen und Einblicke in Trends und Problembereiche zu gewinnen.
7. Mobile App: OTRS bietet eine mobile App für iOS- und Android-Geräte, mit der Agenten Tickets unterwegs bearbeiten können.
8. Sicherheit und Datenschutz: OTRS bietet umfassende Sicherheits- und Datenschutzfunktionen, einschließlich SSL-Verschlüsselung, Zugriffskontrolle und Datenschutzrichtlinien.

OTRS Version 8

OTRS Version 8 bietet eine Vielzahl neuer Funktionen und Verbesserungen im Vergleich zur Vorgängerversion OTRS Version 7. Hier sind einige der wichtigsten Features:

1. Künstliche Intelligenz: OTRS Version 8 integriert künstliche Intelligenz (KI) und maschinelles Lernen, um die Ticketbearbeitung und Automatisierung zu verbessern. Die KI kann z. B. Tickets automatisch klassifizieren, den richtigen Agenten zuweisen und Lösungsvorschläge auf Basis von vorherigen Lösungen bieten.
2. Verbesserte Self-Service-Funktionen: OTRS Version 8 bietet erweiterte Self-Service-Funktionen für Kunden, um Tickets einfach zu erstellen, den Status zu überwachen und Antworten auf häufig gestellte Fragen zu finden.
3. Verbesserte Integration von Wissensmanagement: OTRS Version 8 bietet verbesserte Integration von Wissensmanagement-Systemen, um schnellere und präzisere Lösungen für Kunden bereitzustellen.
4. Verbesserte Benutzeroberfläche: OTRS Version 8 bietet eine verbesserte Benutzeroberfläche, die die Navigation und Suche erleichtert und eine bessere Übersicht über den Supportprozess bietet.
5. Erweiterte Automatisierungsmöglichkeiten: OTRS Version 8 bietet erweiterte Automatisierungsmöglichkeiten, um den Supportprozess weiter zu optimieren, einschließlich der Automatisierung von Eskalationen, Zuweisungen und Antworten auf häufig gestellte Fragen.
6. Mehrsprachigkeit: OTRS Version 8 unterstützt mehrere Sprachen, was die Anpassung an die Bedürfnisse internationaler Unternehmen erleichtert.
7. Verbesserte Sicherheits- und Datenschutzfunktionen: OTRS Version 8 bietet verbesserte Sicherheits- und Datenschutzfunktionen, einschließlich der Möglichkeit, Verschlüsselung und Zugriffskontrollen zu konfigurieren.
8. Erweiterte Reporting- und Analysemöglichkeiten: OTRS Version 8 bietet erweiterte Reporting- und Analysemöglichkeiten, um Einblicke in die Leistung des Supportteams und Kundenfeedback zu erhalten.

Was ist OTOBO?

OTRS (Open Ticket Request System) ist ein Ticketsystem, das zur Verwaltung von Kundensupport-Tickets verwendet wird.

Zu den Funktionen von Otobo gehören Multi-Channel-Ticket-Erstellung, Automatisierung von Supportprozessen, SLA-Management, Wissensmanagement-Integration, Self-Service-Portal, Reporting und Analyse, mobile App-Unterstützung, Sicherheit und Datenschutz.

Otobo verfügt über eine benutzerfreundliche Oberfläche, die es den Benutzern erleichtert, Tickets zu erstellen und zu verwalten. Es ist auch einfach zu installieren und zu konfigurieren, was es ideal für kleine und mittelständische Unternehmen macht, die eine kostengünstige und dennoch leistungsfähige Kundensupport-Lösung benötigen.

‍

OTRS OTOBO Migration

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!

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:

1. Die grundsätzliche Migrationsstrategie.
2. Dies ist der reguläre Weg, um eine Migration durchzuführen. Viele weitere Varianten sind möglich:
3. Wechsel des Servers:
4. Eine Migration mit gleichzeitigem Wechsel zu einem neuen Applikationsserver.
5. Trennung von Applikation und Webserver:
6. 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.
7. Verschiedene Datenbanken:
8. Sie können von jeder der unterstützten Datenbanken zu einer anderen migrieren.
9. Wechsel des Betriebssystems:
10. Sie können während der Migration von jedem unterstützten Betriebssystem zu jedem anderen unterstützten Betriebssystem wechseln.
11. Docker:
12. Auch die Migration zu einer Docker-basierten OTOBO 10-Installation ist möglich.
13. Eine Variante des allgemeinen Vorgehens, bei der die Datenbankmigration gestreamlint durchgeführt wird.
14. 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.
15. Migration von einer Oracle-basierten OTRS 6 Installation zu einer Oracle-basierten OTOBO Installation.
16. Dies ist ein Sonderfall der nicht durch die grundsätzliche Migrationsstrategie beachtet wird. Dies bedeutet, dass eine Variante der gestreamlinten Strategie verwendet werden muss.

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

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

2. Sie benötigen eine betriebsbereite OTOBO-Installation als Ausgangpunkt für die Migration!
3. Auf dieser OTOBO-Instanz müssen alle OPM-Pakete installiert sein, die Sie bisher in Ihrem OTRS nutzen und künftig in OTOBO nutzen möchten.
4. 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.
5. 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> /opt/otrs/bin/Cron.sh stop
otrs> /opt/otrs/bin/otrs.Daemon.pl stop --force

Clear the Caches and the Operational Data

The cached data and the operational data doesn’t have to be migrated. The mail queue should at this point already be empty.

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

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:

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

Konzentrieren wir uns hier auf Option a..

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

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

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

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

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

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

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!

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

Bekannte Probleme bei der Migration

1. Login after migration not possible

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

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

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

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 PasswortrichtlinieStandardPasswordMinSize8PasswordMin2Lower2UpperCharactersJaPasswordNeedDigitJaPasswordHistory10PasswordTTL30 TagePasswordWarnBeforeExpiry5 TagePasswordChangeAfterFirstLoginJa

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.

Es gibt viele Wege um ein Schema zu klonen. In den Befehlbeispielen verwenden wir expdb und impdb, die unter der Haube Data Pump benutzen.

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.

1. Stoppen Sie otobo

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

-- in the OTOBO database
DROP USER otobo CASCADE

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

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

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

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

Bemerkung

Wird auf eine OTOBO-Version migriert, die größer oder gleich 10.1 ist, muss das Skript /opt/otobo/scripts/DBUpdate-to-10.1.pl ausgeführt werden, um die Tabellen stats_report & data_storage zu erstellen, die neu in der Version 10.1 hinzugefügt wurden.

Optionaler Schritt: Gestreamlinte Migration der Datenbank (nur für Experten und Spezialszenarien)

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

Nach der Umwandlung können wir die Tabellen im OTOBO-Schema mit den umgewandelten Daten aus OTRS überschreiben. Effektiv benötigen wir keine einzelne Dump-Datei, sondern mehrere SQL-Skripte.

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

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'

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

‍