-
Beiträge
-
-
-
Hallo,
im Migrationsschritt OTOBOFrameworkVersionCheck wird überprüft ob das Dateisystem mit der ursprünglichen OTRS Installation, in der Regel /opt/otrs, vernünftig aussieht. Dabei wird auch die Datei /opt/otrs/RELEASE analysiert. Die Erwartungshaltung ist dass als Produkt entweder ‚OTRS‘ oder ‚Znuny LTS‘ konfiguriert ist. Wenn „PRODUCT =“ fehlt, oder etwas anderes eingetragen ist, dann wird vorsichtshalber die Migration abgebrochen.
In meiner Testumgebung habe ich beispielsweise:
PRODUCT = Znuny LTS
VERSION = 6.0.35
BUILDDATE = Wed Jun 2 10:43:44 CEST 2021
BUILDHOST = znuny.01
COMMIT_ID = 848d6c03857900c0f16a40f4e7b4ed7c639bbf1eZur Behebung des Problems muss man also überprüfen was in der „web migration GUI“ als Quellverzeichnis eingetragen ist und was in diesem Verzeichnis in der Datei RELEASE steht.
Wenn dort etwas sinnvolles steht, also eine valide OTRS 6 entsprechende Produktbezeichnun außer ‚OTRS‘ oder ‚Znuny LTS‘, dann bitte Bescheid sagen. Wir, das OTOBO Team, erweitern dann den Check.
Viele Grüße,
Bernhard Schmalhofer
-
Vielen Dank für die Antwort.
In der RELEASE Datei stand bei PRODUCT ((OTRS)) Community Edition, was angeblich die Probleme bereitet hat. Die Ersetzung mit OTRS hat die Migration weitergeleitet zum Schritt 4 (bin gespannt wie/ob es funktioniert).
Ich schlage vor, dass es in die Anleitung für die Migration reinkommt oder der Umzug-Script angepasst wird .
Gruß
Irina Schäfer
-
Hallo Frau Schäfer,
ich habe den Migrationsschritt erweitert, siehe https://github.com/RotherOSS/otobo/issues/1317. Die Änderung ist dann in OTOBO 10.0.14 enthalten.
Die Meldung „Kein OTRS-System gefunden!“ ist dann auch etwas ausführlicher, die Anpassung der Migrationsanleitung ist damit nicht mehr notwendig.
Viele Grüße,
Bernhard Schmalhofer
-
-
-
Die Fehlersuche ergab:
[Error][Kernel::System::MigrateFromOTRS::CloneDB::Driver::Base::DataTransfer][Line:833]: MySQL client ran out of memory, SQL: ‚SELECT id, article_id, filename, content_size, content_type, content_id, content_alternative, disposition, content, create_time, create_by, change_time, change_by FROM article_data_mime_attachment LIMIT 400000000‘:
Nicht genug Arbeitsspeicher?
-
Leider funktioniert es nicht, bei der Datenbank Migration kommen ständig Fehler, auch bei „Streamlined migration of the database“.
Oft ist es You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‚)‘ at line 1, SQL: ‚SELECT id, name FROM ticket_state WHERE valid_id IN ( )‚
Oder No Valid for valid found!
MariaDB V. 10.1.48 auf Ubuntu 18.04.6 LTS
-
Hallo Frau Schäfer,
die gepostete SQL-Abfrage kommt anscheinend von der Methode
Kernel::System::State::StateList(). Wo genau diese Methode bei der Migration verwendet wird ist mir nicht klar, aber das ist nicht das Entscheidende. Signifikant ist dass im SELECT eine leere Liste verwendet wird. Der Inhalt der Liste sollte eigentlich der einzelne Wert 1 sein. Dieser Wert kommt im Normalfall aus der Tabelle valid. Ich vermute also dass bei der „Streamlined migration of the database“ die Datenbank nicht vollständig übertragen wurde. Können Sie in der Quell- und in der Ziel-Datenbank die Tabelle valid überprüfen? Diese Tabelle sollte drei Werte enthalten: „valid“, „invalid“, „invalid-temporarily“.Viele Grüße,
Bernhard Schmalhofer
-
Hallo Herr Schmalhofer,
danke für Support.
Nach ewigen Versuchen und Anpassungen in MariaDB/InnoDB (wie innodb_file_format u.ä.) hat es doch geklappt die Datenbank zu kopieren (per Streamlined migration) und dann auch die Migration durchzuführen.
Im großen und ganzen sieht es gut aus – nur während der Migration musste ich einige Einstellungen für Migration ändern (mit Console.pl Admin::Config::ListInvalid) und fixen. Lustigerweise musste ich danach die gleiche Einstellungen wieder auf ihre Ausgangswerte ändern, sonnst wurden immer die Fehler rausgegeben.
Gruß,
Irina
-
-
-
Der erneute Versuch eine Migration durchzuführen scheitert an der anderen Stelle. :(
Beim Schritt 4 (Migrieren) kommt die Fehlermeldung über die Konfigurationseinstellungen und ein Vorschlag sie zu beseitigen aus Konsole „/bin/otobo.Console.pl Admin::Config::Listinvalid“ – läuft eigentlich gut. Fehler beseitigt.
Und danach funktioniert die Migration nicht mehr – angeblich ist „SecureMod“ nicht deaktiviert. Der Restart/Neustart des Apaches bringt nichts. Mit dem alten „root@localhost“ kann ich mich bei Otobo nicht mehr anmelden, mit meinem Benutzer mit Adminrechten aus OTRS kann ich mich schon anmelden aber habe keine Adminrechte.
Welche Möglichkeiten gibt es noch?
Gruß
Irina
-
So, Update.
Ich konnte durch hinzufügen von „$Self->{‚SecureMode‘} = 0;“ in die OTOBO Config.pm die Migration nochmal starten. Und stecke jetzt beim Versuch „bin/otobo.Console.pl Admin::Config::FixInvalid“ durchzuführen. Die Settings für SMIME::CertPath und PrivatePath konnten nicht gefixt (ist klar) und nicht übersprungen werden.
Screenshots: Erstmal überspringen
Und dann bei Rebuild:
Kann man es wirklich nicht überspringen?
-
Wenn Du die Pfade hast, könntest Du mit
perl bin/otobo.Console.pl Admin::Config::Update –setting-name SMIME::CertPath –value …
arbeiten
-
Genau das habe ich gerade gemacht ;) Beide auf 0 gesetzt (ob es richtig war?) Aber dann hat das „Rebuild“ funktioniert und die Migration ist bis zu Ende weitergegangen.
Den Fehler mit „SecureMod“ finde ich trotzdem ärgerlich.
Dann
-
-
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.