[AnteIde Marić]

Hallo,

Gestern habe ich versucht, die Produktionsversionen OTRS 6 Community Edition und OTOBO 10.1 (Docker) zu migrieren. Die Produktionsdatenbank befindet sich auf MySQL. Ich habe die Migration gestartet und nachdem alle Datenbanktabellen kopiert wurden, werden alle kopierten Tabellen gelöscht (ich habe dies in MariaDB im Container otobo-db-1 überprüft) und das Kopieren der Tabellen beginnt von vorne??

Ich kann nicht glauben, dass das passiert ist :O Ist das ein Witz?

In der Testumgebung (mit Testdatenbank) hatte ich jedes Mal eine erfolgreiche Migration. Ich weiß nicht, was hier passiert ist. Mir bleibt nur, das Skript migration.pl zu finden und es zu untersuchen, um zu sehen, was passiert ist. Kann jemand helfen?

Die Datenbank ist 38 GB groß.

In den Protokollen sind keine Fehler sichtbar.

Migrationsprotokoll

 

[AnteIde Marić]

Ich kann das Skript migration.pl nirgendwo finden, weder auf dem Server (Docker-Container) noch auf GitHub?

[Stefan Härter]

Hallo AnteIde,

um die letzte Frage zuerst zu beantworten: Ist das Skript möglicherweise das hier? https://github.com/RotherOSS/otobo/blob/rel-10_1/bin/cgi-bin/migration.pl

Was die Datenbank angeht, um sicherzugehen, dass ich das richtig verstanden habe: Ist das Skript zweimal durchgelaufen? Ist es unterbrochen worden? Wie kann ich das reproduzieren?

Beste Grüße
Stefan

[Stefan Rother]

Hallo Antelde,

nein, die Tabellen werden nicht alle gelöscht und es fängt automatisch von vorne an, dieses Verhalten hatte ich noch nie.

Ich denke auch nicht, dass es Dir weiterhilft die Skripte zu untersuchen (diese befinden sich unter Kernel/System/MigrateFromOTRS), aber ich glaube Du unterschätzt die Komplexität.

Wenn es im Testsystem funktioniert hat, dann würde ich überlegen was bei der Produktivmigration anders gelaufen ist. Wir migrieren jede Woche Systeme von OTRS zu OTOBO und verwenden auch die gleichen Skripte, die allen zur Verfügung stehen.

Ansonsten helfen wir auch gerne, machen die Migration für Euch, oder beantworten Fragen bei konkreten Problemen im Rahmen eines Supportvertrages.

Schöne Grüße,

Stefan

Team OTOBO

 

[AnteIde Marić]

@Stefan Härter
Ich habe auch dieses Skript gefunden: https://github.com/RotherOSS/otobo/blob/rel-10_1/bin/cgi-bin/migration.pl, aber ich glaube nicht, dass es das ist, das wir brauchen. Es kümmert sich nicht um Aufgaben wie das Kopieren der Datenbank zwischen Servern, das Migrieren von Dateien von OTRS nach OTOBO oder andere notwendige Schritte.

Zum Migrationsproblem:

Ich habe die offizielle Migrationsanleitung befolgt und das Skript ausgeführt. Anfangs schien es, als würde der Prozess beim Schritt „ticket_history“-Tabelle kopieren hängen bleiben. Das war jedoch mein Fehler – ich habe die falschen Parameter betrachtet und eine falsche Annahme getroffen. Der Prozess hat einfach nur länger gedauert.

Leider habe ich den otobo-db-Container zu diesem Zeitpunkt gestoppt, wodurch das Migrationsskript (wie zu erwarten) fehlgeschlagen ist. Anschließend hat ein Kollege die „ticket_history“-Tabelle gemäß folgender Anweisungen geändert:

• Alle article_id-Werte, die auf NULL gesetzt waren, wurden auf INT(0) geändert.

Wir werden dies rückgängig machen.

Ich habe das Migrationsskript neu gestartet, aber es schien von selbst abzubrechen. Der Button „Migration starten“ wurde wieder verfügbar. Ich habe das Skript ein drittes Mal gestartet, und nachdem alle Tabellen kopiert wurden, geschah etwas Ungewöhnliches – weniger als eine Minute später wurden die Tabellen laut Logs erneut von Anfang an kopiert.

Als ich das bemerkte, bin ich in den otobo-db-1-Container gegangen und habe festgestellt, dass die migrierte Datenbank leer war. Zum Beispiel:

MariaDB [otobo]> SELECT * FROM ticket_history ORDER BY id DESC LIMIT 1;
Empty set (0.000 sec)

Das sind also die Schritte, um das Problem zu reproduzieren.

Ehrlich gesagt bin ich von diesem Verhalten überrascht. Die Dokumentation von OTOBO ist ausgezeichnet, daher habe ich solche Probleme nicht erwartet – und doch stehen wir jetzt hier. 😢

@Stefan Rother
Konntest du die angehängten Logs, das Migrationsprotokoll, schon überprüfen?

Es scheint, dass die Tabellen erneut automatisch kopiert wurden – würdest du dem zustimmen?

Vielen Dank, dass du den Pfad zu den Skripten geteilt hast. Wie du erwähnt hast, scheinen sie recht komplex zu sein, und daher würde ich es vorziehen, nicht zu tief in sie einzutauchen.

Ich schätze deinen Rat, die Unterschiede zwischen der Test- und Produktionsdatenbankmigration zu vergleichen.

Zur Orientierung habe ich außerdem das vollständige Logfile angehängt.

Vielen Dank für deine Antworten und deine Unterstützung!

• Diese Antwort wurde geändert vor 1 Monat von AnteIde Marić.

[Stefan Rother]

Hi,

für mich sieht es aus, als wurde der Cache gelöscht. Dann beginnt OTOBO wieder von vorne, wenn otobo/migration.pl neu aufgerufen wird.

Bei der Migration kann es vorkommen, dass die Verbindung im Browser beendet wird (wenn die Migration sehr lange dauert, oder es eine Netzwerkunterbrechung gibt, oder wenn ein externer Proxy verwendet wird).

Dann ist es das einfachste abzuwarten, bis im Log auch die Tabelle xml_storage fertig übertragen wurde. (mit „top“ oder „ps aux“ zusätzlich kontrollieren). Bis dahin einfach bitte NICHTS unternehmen, das Skript läuft im Hintergrund weiter.

Sobald dann der Datenbankteil erledigt ist, nochmal /otobo/migration.pl aufrufen (Es wird eine Meldung angezeigt, dass ein Cache existiert, diesen bitte NICHT löschen lassen).

Dann geht es sofort mit dem nächsten Punkt weiter und die Konfiguration wird migriert.

Und bitte dafür sorgen, dass nicht jemand anderes auch testet und migration.pl aufruft.

Dann sollte die Migration auch klappen.

Wenn nicht, wir bieten OTOBO Consulting und Support, um das System zuverlässig auf OTOBO zu migrieren und das kostet auch nicht die Welt, wenn man überlegt wie viele Lizenzkosten gespart werden.

Viel Glück!

Stefan
Team OTOBO

[AnteIde Marić]

Ich habe den Cache definitiv nicht gelöscht, da mein Ziel darin besteht, die Migration zu beschleunigen und nicht zu verlangsamen.

Ich kann bestätigen, dass ich die Phase des Datenbankkopierens erfolgreich abgeschlossen habe und derzeit dabei bin, Dateien von OTRS nach OTOBO zu kopieren.

Allerdings bin ich auf ein Berechtigungsproblem gestoßen. Die Logs aus dem Container *otobo-web-1* zeigen folgende Fehler:

2024-12-24T07:21:11.950751281Z cp: cannot create regular file '/opt/otobo//var/article/2022/07/11/3136873/file-1.content_type': Permission denied
2024-12-24T07:21:11.950776850Z cp: cannot create regular file '/opt/otobo//var/article/2022/07/11/3136873/plain.txt': Permission denied
2024-12-24T07:21:11.950901483Z cp: cannot create regular file '/opt/otobo//var/article/2022/07/11/3136956/file-1': Permission denied
2024-12-24T07:21:11.950947971Z cp: cannot create regular file '/opt/otobo//var/article/2022/07/11/3136956/file-1.content_type': Permission denied
2024-12-24T07:21:11.950989621Z cp: cannot create regular file '/opt/otobo//var/article/2022/07/11/3136956/plain.txt': Permission denied
2024-12-24T07:21:11.951139991Z cp: cannot create regular file '/opt/otobo//var/article/2022/07/11/3137039/file-2': Permission denied
2024-12-24T07:21:11.951155842Z cp: cannot create regular file '/opt/otobo//var/article/2022/07/11/3137039/file-2.content_type': Permission denied

Dieses Problem trat bereits bei der Migration in der Testumgebung auf. Damit die Tickets in OTOBO korrekt funktionieren, musste ich das Skript /opt/otobo/bin/otobo.SetPermissions.pl im Container *otobo-web-1* ausführen. Leider hat das damals nicht funktioniert, sodass ich die Berechtigungen manuell ändern musste, um das Problem zu beheben.

Da ich in der Produktionsumgebung deutlich mehr Dateien habe, möchte ich dieses Skript korrekt ausführen.

### Probleme, auf die ich gestoßen bin:

1. **Ausführung des Skripts als regulärer Benutzer (otobo):**

otobo@b087f8829d05:~/bin$ ./otobo.SetPermissions.pl
ERROR: Please run this script as superuser (root).

2. **Ausführung des Skripts als root im Container:**

[root@otobo-test bin]# docker exec -ti –user root otobo-web-1 /bin/bash
root@b087f8829d05:/opt/otobo# cd bin
root@b087f8829d05:/opt/otobo/bin# ./otobo.SetPermissions.pl
Can’t open perl script „./otobo.SetPermissions.pl“: Permission denied

3. **Ändern der Berechtigungen durch den Benutzer otobo:**
Ich habe die Berechtigungen der Datei ./otobo.SetPermissions.pl auf 775 gesetzt, aber beim Ausführen als root erhielt ich folgende Fehler:

...

ERROR: could not change /var/article/2024/06/13/699801 permissions 777 -> 2775: Operation not permitted
ERROR: could not change /var/article/2024/06/13/699801/file-2 permissions 777 -> 660: Operation not permitted
Can’t opendir(/opt/otobo/Kernel/Config/Files/User): Permission denied at ./otobo.SetPermissions.pl line 198.

...

4. **Ausführung des Skripts mit der Option --otobo-user:**
Ich habe folgendes ausgeführt:

./otobo.SetPermissions.pl --otobo-user=otobom

Doch die gleichen Fehler traten auf, und ich bin unsicher, welche Parameter korrekt sind.

### Mögliche Lösung:
Das Einzige, was ich noch nicht ausprobiert habe, ist, das Skript mit root-Rechten im Kontext des Benutzers otobo auszuführen (mit sudo). Allerdings kenne ich das root-Passwort des Containers *otobo-web-1* nicht.

• Diese Antwort wurde geändert vor 4 Wochen, 1 Tag von AnteIde Marić.

[Autor]

Beiträge