Migration der SysConfig schlägt fehl

Schlagwörter: Migration, OTRS, SYSCONFIG, XML to DB

Ansicht von 6 Antwort-Threads

Autor

Beiträge
- 5. Januar 2021 um 8:56 Uhr - Views: 1867 #10444
  Daniel Ehrlich
  Teilnehmer
  Hallo liebes Team & Community,
  
  wir sind gerade dabei unser OTRS 6.30 auf die letzte verfügbare OTOBO Version zu migrieren. Leider bricht die Migration immer kurz vor dem Ende mit der folgendenen Fehlermeldung ab:
  
  Leider fehlt uns an der Stelle ein wenig der Ansatz zum troubleshooten. Hat jemand eine Idee, womit der Abbruch in zusammenhang stehen könnte. Die Basis des Systems bildet ein Linux Debian 10 und die sich im Einsatz befindene Datenbank ist eine MySQL v5.7. Das zu migrierende OTRS 6.30 ist ziemlich einfach gehalten und über die Standarteinstellungen hinaus wurde nichts an dem System verändert.
  
  Vielen Dank vorab für Ihre Zeit.
  
  Mit freundlichen Grüßen
  
  Daniel
- 14. Januar 2021 um 8:58 Uhr #10556
  Stefan Rother
  Administrator
  Hallo Daniel,
  
  bitte entschuldige die späte Antwort.
  
  Das die Migration an dieser Stelle abbricht ist komisch. Hast Du Dich denn genau an die Migrationsanleitung auf https://doc.otobo.org/manual/installation/stable/en/content/migration-from-otrs-6.html gehalten? Vor allem den Daemon auf dem alten OTRS System sicher deaktiviert? Ist eventuell schon die Konfiguration auf dem OTRS System korrupt? Das kannst Du testen, indem Du
  
  /opt/otrs/bin/otrs.Console.pl Admin::Config::ListInvalid
  
  ausführst. Wir haben noch einige Fehler behoben an der Migration in der kommenden OTOBO Version 10.0.7 – diese wird nächste Woche veröffentlicht – aber ich bin mir nicht sicher ob das wirklich an OTOBO liegt, oder das Problem schon in OTRS existiert. Das könntest Du aber bitte mit der neuen Version nochmal testen, wenn möglich.
  
  Ansonsten wäre noch wichtig, was im Log steht, wenn die Migration abbricht.
  
  Gerne können wir die Migration auch für Euch durchführen, dann können wir nach der Migration Euer System noch einem kurzen Review unterziehen. Damit ist dann sichergestellt, dass OTOBO in Zukunft zu 100% sauber konfiguriert ist. Bei Bedarf sende bitte eine kurze E-Mail an hallo@otobo.de.
  
  Vielen Dank und schöne Grüße,
  
  Stefan Rother
  
  Team OTOBO
- 1. Februar 2021 um 10:59 Uhr #10790
  Yannick Wysocki
  Teilnehmer
  Hallo liebes Otobo-Team & Community,
  
  ich habe mich exakt an die Migrationsanleitung gehalten und leider genau dasselbe Problem wie Daniel:
  
  Bei mir handelt es sich um eine OTOBO installation in Docker, was an dieser Stelle aber praktisch keinen Unterschied zur legacy installation/migration machen dürfte.
  
  Migriert wird von OTRS6 auf OTOBO und das Datenbank-Backup „otrs_data.sql“ umfasst ca 15 GB an Größe.
  
  Getestet habe ich auch bereits mit der aktuellsten Version und sichergestellt, dass ich nicht mit veralteten Docker Images arbeite.
  
  Ich habe (laut Hinweis in der Migrationsanleitung) bereits versucht, die Migration mit anderen, extra angelegten, Datenbank-Usern -auch mit root-Rechten- durchzuführen, doch leider erfolglos.
  
  Um auszuschließen, dass der Sprung der Datenbank-Version evtl. Probleme verursacht (MariaDB 5.5.65 -> MariaDB 10.5), habe ich getestet, vor Start des Migrations-Wizards, ein „mysql_upgrade“ durchzuführen. Der Befehl wurde, ohne Fehlermeldung, ausgeführt, jedoch half dies der Migration leider nicht weiter.
  
  Mir scheint es, als würden (während das migrations-script ausgeführt wird) zu schreibende Werte aus der SysConfig nicht so bereinigt zu werden, dass das DBMS damit was anfangen kann. Bzw. könnte ich meinen, es wird versucht, ungültige Werte in die Datenbank zu schreiben, die nicht ordnungsgemäß aus dem XML-Format konvertiert wurden (Bauchgefühl).
  
  Habt Ihr zufälligerweise Tipps und Hinweise, wie die SysConfig bereinigt werden kann, sodass das Schreiben in die Datenbank funktioniert?
  
  Da ich mich nun schon seit knapp 2 Monaten immer wieder mit dieser Schwierigkeit beschäftige, echt nicht mehr weiter weiß und das Thema allmählich immer dringender abzuschließen ist, bin ich extrem dankbar für jede Hilfe und jeden Lösungsansatz.
  
  Ganz großen Dank im Voraus!
  
  Beste Grüße
  
  Yannick Wysocki
- 1. Februar 2021 um 11:57 Uhr #10791
  Sven Oesterling
  Administrator
  Hallo Daniel, Hallo Yannick,
  
  ich kann nicht zu 100% sagen, was da schief läuft, aber vielleicht können wir es zusammen debuggen – das wäre auch für uns interessant. Prinzipiell ist es so, dass die Migration bis dahin erstmal gelaufen ist, und solange ihr auf dem Server nicht den Cache löscht, könnt ihr auch genau da wieder einsteigen.
  
  Als Vorbereitung müsstet ihr die Migration bis zu dieser Stelle durchführen, euch dann per Kommandozeile auf den Server einloggen und euch im Fall von einer „normalen“ Installation mit:
  
  su otobo
  cd /opt/otobo
  
  im Fall von docker via:
  
  docker exec -it otobo_web_1 bash
  
  in das otobo-Verzeichnis begeben. Dort führt ihr dann bitte folgendes aus:
  
  bin/otobo.Console.pl Maint::Config::Rebuild --cleanup
  
  Das wird (aller Wahrscheinlichkeit nach) nicht auf Anhieb funktionieren, weil es im Endeffekt genau das gleiche anstößt, was während der Migration passiert, aber es sollte Fehler auswerfen, die ihr mir hier reinkopieren könnt. Letztlich werden irgendwo ungültige Werte auftauchen, und vielleicht muss man ein paar Dinge zurücksetzen. Die nächsten Schritte schreib ich, sobald wir sehen, worum es sich handelt.
  
  Viele Grüße, Sven
- 1. Februar 2021 um 12:09 Uhr #10796
  Yannick Wysocki
  Teilnehmer
  Hallo zusammen,
  
  ich habe noch eine Ergänzung.
  
  Der Befehl zum Prüfen der Konfiguration schlägt bei mir leider fehl:
  
  [root@otrs ~]# su - otrs
  Last login: Thu Jan 7 20:40:49 CET 2021 on pts/0
  -bash-4.2$ /opt/otrs/bin/otrs.Console.pl Admin::Config::ListInvalid
  Error: Could not find Kernel::System::Console::Command::Admin::Config::ListInvalid.
  
  Die logs des otobo_db_1 sehen, während der Migrationsschritts „SysConfig in DB schreiben“ folgendermaßen aus (Auch, wenn für die Datenbank root oder ein anderer User gewählt wird!!):
  
  2021-02-01 10:46:36 380 [Warning] Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES)
  2021-02-01 10:46:36 381 [Warning] Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES)
  2021-02-01 10:46:36 382 [Warning] Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES)
  2021-02-01 10:46:36 383 [Warning] Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES)
  2021-02-01 10:46:36 384 [Warning] Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES)
  2021-02-01 10:46:36 385 [Warning] Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES)
  
  Die 172.19.0.5 ist bei mir die Adresse des otobo_web_1 containers.
  
  [root@docker-002 ~]# docker inspect otobo_web_1 | grep IP
  „LinkLocalIPv6Address“: „“,
  „LinkLocalIPv6PrefixLen“: 0,
  „SecondaryIPAddresses“: null,
  „SecondaryIPv6Addresses“: null,
  „GlobalIPv6Address“: „“,
  „GlobalIPv6PrefixLen“: 0,
  „IPAddress“: „“,
  „IPPrefixLen“: 0,
  „IPv6Gateway“: „“,
  „IPAMConfig“: null,
  „IPAddress“: „172.19.0.5“,
  „IPPrefixLen“: 16,
  „IPv6Gateway“: „“,
  „GlobalIPv6Address“: „“,
  „GlobalIPv6PrefixLen“: 0,
  
  Es scheint also, als würde der otobo user, der im otobo_web_1 container existiert, genommen werden, um Änderungen im otobo_db_1 vorzunehmen. Dieser hat dort natürlich keine Schreib-Berechtigungen und sollte, meiner Ansicht nach, auch keine benötigen, denn dafür geben wir ja im Migrationswizard schon den spezifischen Datenbank-User mit.
  
  Sollte es sich hier um ein separates Problem handeln, das nicht direkt mit dem Fehlschlagen des o.g. Migrationsschrittes zusammenhängt, kann hieraus gerne ein neuer Thread erstellt werden.
  
  Ich werde mal versuchen, dem spezifischen otobo user des otobo_web_1 containers Schreibrechte auf die OTRS-/OTOBO-Datenbank zu geben um zu schauen, ob sich das Verhalten dann ändert und die Migration erfolgreich abschließt.
  
  Beste Grüße
  
  Yannick
- 1. Februar 2021 um 12:26 Uhr #10797
  Yannick Wysocki
  Teilnehmer
  Hallo Sven,
  
  danke dir für die schnelle Antwort, ich bin begeistert!!
  
  Hier der Output des „Config Rebuild -Scripts“ in gekürzter Form. Im Prinzip ist es immer dieselbe Fehlermeldung:
  
  [root@docker-002 ~]# docker exec -it otobo_web_1 /bin/bash
  otobo@ae92d6e74dba:~$ bin/otobo.Console.pl Maint::Config::Rebuild --cleanup
  [Mon Feb 1 11:21:48 2021] otobo.Console.pl: DBI connect(‚database=otobo;host=db;‘,’otobo‘,…) failed: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES) at /opt/otobo/Kernel/System/DB.pm line 332.
  ERROR: OTOBO-otobo.Console.pl-Maint::Config::Rebuild-10 Perl: 5.32.0 OS: linux Time: Mon Feb 1 11:21:48 2021
  
  Message: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES)
  
  Traceback (80):
  Module: Kernel::System::DB::Prepare Line: 820
  Module: Kernel::System::PID::PIDGet Line: 169
  Module: Kernel::System::Console::Command::Maint::Config::Rebuild::PreRun Line: 71
  Module: (eval) Line: 454
  Module: Kernel::System::Console::BaseCommand::Execute Line: 454
  Module: Kernel::System::Console::InterfaceConsole::Run Line: 88
  Module: bin/otobo.Console.pl Line: 35
  
  [Mon Feb 1 11:21:48 2021] otobo.Console.pl: DBI connect(‚database=otobo;host=db;‘,’otobo‘,…) failed: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES) at /opt/otobo/Kernel/System/DB.pm line 332.
  ERROR: OTOBO-otobo.Console.pl-Maint::Config::Rebuild-10 Perl: 5.32.0 OS: linux Time: Mon Feb 1 11:21:48 2021
  
  Message: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES)
  
  Traceback (80):
  Module: Kernel::System::DB::Prepare Line: 820
  Module: Kernel::System::PID::PIDGet Line: 169
  Module: Kernel::System::PID::PIDCreate Line: 97
  Module: Kernel::System::Console::Command::Maint::Config::Rebuild::PreRun Line: 76
  Module: (eval) Line: 454
  Module: Kernel::System::Console::BaseCommand::Execute Line: 454
  Module: Kernel::System::Console::InterfaceConsole::Run Line: 88
  Module: bin/otobo.Console.pl Line: 35
  
  [Mon Feb 1 11:21:48 2021] otobo.Console.pl: DBI connect(‚database=otobo;host=db;‘,’otobo‘,…) failed: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES) at /opt/otobo/Kernel/System/DB.pm line 332.
  ERROR: OTOBO-otobo.Console.pl-Maint::Config::Rebuild-10 Perl: 5.32.0 OS: linux Time: Mon Feb 1 11:21:48 2021
  
  Message: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES)
  
  Traceback (80):
  Module: Kernel::System::DB::Do Line: 605
  Module: Kernel::System::PID::PIDDelete Line: 232
  Module: Kernel::System::PID::PIDCreate Line: 123
  Module: Kernel::System::Console::Command::Maint::Config::Rebuild::PreRun Line: 76
  Module: (eval) Line: 454
  Module: Kernel::System::Console::BaseCommand::Execute Line: 454
  Module: Kernel::System::Console::InterfaceConsole::Run Line: 88
  Module: bin/otobo.Console.pl Line: 35
  
  [Mon Feb 1 11:21:48 2021] otobo.Console.pl: DBI connect(‚database=otobo;host=db;‘,’otobo‘,…) failed: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES) at /opt/otobo/Kernel/System/DB.pm line 332.
  ERROR: OTOBO-otobo.Console.pl-Maint::Config::Rebuild-10 Perl: 5.32.0 OS: linux Time: Mon Feb 1 11:21:48 2021
  
  Message: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES)
  
  Traceback (80):
  Module: Kernel::System::DB::Do Line: 605
  Module: Kernel::System::PID::PIDCreate Line: 132
  Module: Kernel::System::Console::Command::Maint::Config::Rebuild::PreRun Line: 76
  Module: (eval) Line: 454
  Module: Kernel::System::Console::BaseCommand::Execute Line: 454
  Module: Kernel::System::Console::InterfaceConsole::Run Line: 88
  Module: bin/otobo.Console.pl Line: 35
  
  [Mon Feb 1 11:21:48 2021] otobo.Console.pl: DBI connect(‚database=otobo;host=db;‘,’otobo‘,…) failed: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES) at /opt/otobo/Kernel/System/DB.pm line 332.
  ERROR: OTOBO-otobo.Console.pl-Maint::Config::Rebuild-10 Perl: 5.32.0 OS: linux Time: Mon Feb 1 11:21:48 2021
  
  Message: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES)
  
  Traceback (80):
  Module: Kernel::System::DB::Prepare Line: 820
  Module: Kernel::System::PID::PIDGet Line: 169
  Module: Kernel::System::Console::Command::Maint::Config::Rebuild::PreRun Line: 80
  Module: (eval) Line: 454
  Module: Kernel::System::Console::BaseCommand::Execute Line: 454
  Module: Kernel::System::Console::InterfaceConsole::Run Line: 88
  Module: bin/otobo.Console.pl Line: 35
  
  There is another system configuration rebuild in progress, waiting…
  
  [Mon Feb 1 11:21:48 2021] otobo.Console.pl: DBI connect(‚database=otobo;host=db;‘,’otobo‘,…) failed: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES) at /opt/otobo/Kernel/System/DB.pm line 332.
  ERROR: OTOBO-otobo.Console.pl-Maint::Config::Rebuild-10 Perl: 5.32.0 OS: linux Time: Mon Feb 1 11:21:48 2021
  
  Message: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES)
  
  Traceback (80):
  Module: Kernel::System::DB::Prepare Line: 820
  Module: Kernel::System::PID::PIDGet Line: 169
  Module: Kernel::System::Console::Command::Maint::Config::Rebuild::PreRun Line: 71
  Module: (eval) Line: 454
  Module: Kernel::System::Console::BaseCommand::Execute Line: 454
  Module: Kernel::System::Console::InterfaceConsole::Run Line: 88
  Module: bin/otobo.Console.pl Line: 35
  
  [Mon Feb 1 11:21:48 2021] otobo.Console.pl: DBI connect(‚database=otobo;host=db;‘,’otobo‘,…) failed: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES) at /opt/otobo/Kernel/System/DB.pm line 332.
  ERROR: OTOBO-otobo.Console.pl-Maint::Config::Rebuild-10 Perl: 5.32.0 OS: linux Time: Mon Feb 1 11:21:48 2021
  
  Message: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES)
  
  Traceback (80):
  Module: Kernel::System::DB::Prepare Line: 820
  Module: Kernel::System::PID::PIDGet Line: 169
  Module: Kernel::System::PID::PIDCreate Line: 97
  Module: Kernel::System::Console::Command::Maint::Config::Rebuild::PreRun Line: 76
  Module: (eval) Line: 454
  Module: Kernel::System::Console::BaseCommand::Execute Line: 454
  Module: Kernel::System::Console::InterfaceConsole::Run Line: 88
  Module: bin/otobo.Console.pl Line: 35
  
  [Mon Feb 1 11:21:48 2021] otobo.Console.pl: DBI connect(‚database=otobo;host=db;‘,’otobo‘,…) failed: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES) at /opt/otobo/Kernel/System/DB.pm line 332.
  ERROR: OTOBO-otobo.Console.pl-Maint::Config::Rebuild-10 Perl: 5.32.0 OS: linux Time: Mon Feb 1 11:21:48 2021
  
  Message: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES)
  
  Traceback (80):
  Module: Kernel::System::DB::Do Line: 605
  Module: Kernel::System::PID::PIDDelete Line: 232
  Module: Kernel::System::PID::PIDCreate Line: 123
  Module: Kernel::System::Console::Command::Maint::Config::Rebuild::PreRun Line: 76
  Module: (eval) Line: 454
  Module: Kernel::System::Console::BaseCommand::Execute Line: 454
  Module: Kernel::System::Console::InterfaceConsole::Run Line: 88
  Module: bin/otobo.Console.pl Line: 35
  
  [Mon Feb 1 11:21:48 2021] otobo.Console.pl: DBI connect(‚database=otobo;host=db;‘,’otobo‘,…) failed: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES) at /opt/otobo/Kernel/System/DB.pm line 332.
  ERROR: OTOBO-otobo.Console.pl-Maint::Config::Rebuild-10 Perl: 5.32.0 OS: linux Time: Mon Feb 1 11:21:48 2021
  
  Message: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES)
  
  Traceback (80):
  Module: Kernel::System::DB::Do Line: 605
  Module: Kernel::System::PID::PIDCreate Line: 132
  Module: Kernel::System::Console::Command::Maint::Config::Rebuild::PreRun Line: 76
  Module: (eval) Line: 454
  Module: Kernel::System::Console::BaseCommand::Execute Line: 454
  Module: Kernel::System::Console::InterfaceConsole::Run Line: 88
  Module: bin/otobo.Console.pl Line: 35
  
  [Mon Feb 1 11:21:48 2021] otobo.Console.pl: DBI connect(‚database=otobo;host=db;‘,’otobo‘,…) failed: Access denied for user ‚otobo’@’172.19.0.5‘ (using password: YES) at /opt/otobo/Kernel/System/DB.pm line 332.
  
  […]
  
  Ich hoffe, du kannst damit was anfangen.
  
  Danke nochmal für die Unterstützung!
  
  Beste Grüße
  
  Yannick
- 3. Februar 2021 um 16:56 Uhr #10812
  Stefan Rother
  Administrator
  Hallo zusammen,
  
  ich denke, wie schon oben geschrieben, dass die SysConfig im OTRS System korrupt war oder irgendwelche ungültigen Werte enthält. Dies bitte unbedingt vor der Migration überprüfen. Der Fehler mit MySQL ist ein Folgefehler für mich, ich denke dass die Konfiguration durch den Abbruch korrupt ist und eventuell die DB Informationen in der Datei Kernel/Config.pm nicht mehr stimmen.
  
  Ich würde es nochmal neu anfangen, einfach um auf Nummer sicher zu gehen. Den OTOBO Docker Container zurücksetzen, neu die Pakete einspielen und dann wie in der Doku beschrieben vorgehen.
  
  Wichtig, bitte überprüft und säubert vorher die Konfiguration in OTRS, dann Daemon aus und SecureMode aus.
  
  Und dann nochmal erneut die Migration genau nach Anweisung durchführen.
  
  Ich hoffe es klappt dann, ansonsten kann ich Euch nur anbieten die Migration mit Euch gemeinsam zu machen (oder für Euch), vielleicht hat Euer OTRS ja irgendwelche Probleme die ich nicht sehe von hier.
  
  Alles Gute,
  
  Stefan
  
  Team OTOBO
Autor

Beiträge