Schlagwörter: ,

Ansicht von 6 Antwort-Themen
  • Autor
    Beiträge
    • #34286
      Niklas Maurer
      Teilnehmer

        Hallo an die Otobo community,

        Ich bei der Testphase der Migration von OTRS 6.0.39 auf Otobo 10.1.11 über den folgenden Satz gestolpert:

        Bitte überlegen Sie genau, ob es wirklich sinnvoll ist, bestehende Daten und Konfiguration zu übernehmen. Unsere Erfahrung zeigt, dass die bisher genutzte Installation und Konfiguration in viele Fällen eher suboptimal und ein sauberer Neustart die bessere Option ist. Auch kann es sinnvoll sein, nur die Ticketdaten zu übertragen und die Grundkonfiguration gemäß OTOBO Best Practice vorzunehmen. Hierzu beraten wir Sie gerne, wenden Sie sich einfach per Mail an hallo@otobo.de oder stellen Sie Ihre Fragen im OTOBO Community Forum unter https://forum.otobo.org/.

        Ich finde dazu allerdings keinerlei Hilfen oder Forumposts.

        Die AI schlägt vor einfach nur einen begrenzten Satz an Tabellen aus der OTRS DB mit mysqldump zu exportieren:

        mysqldump -u root -p –no-create-info otrs ticket article attachment dynamic_field dynamic_field_value > otrs_tickets_with_custom_fields.sql

        Dabei wäre mir aber nicht klar wie man hier zwischen benötigten und nicht benötigten Tabellen unterscheidet.

        – Benötigt würden:
        1. Tickets
        2. Custom Fields
        3. (Attachments (liegen auf dem FS))
        4. Kunden
        5. Kundebenutzer
        6. Mailqueues
        7. Automatische Antworten

        Nicht zwingend benötigt werden z.B. die Agenten, Rollen und Gruppen, da ich die gerne neu glattziehen würde.

        Gibt es hier ggf. irgendwo eine Anleitung oder mehr Hintergrundinformation zu dieser Expliziten Warnung in den Voraussetzungen?
        Selbst zu dem genannten Beispiel „Ticketdaten zu übertragen“ fehlt mir hier mehr Detailwissen.

        Vielen Dank im voraus!

      • #34287
        Stefan Rother
        Administrator

          Hallo Niklas,

          so wie die KI es beschreibt, wird es nicht funktionieren. Wenn Du die Migration alleine durchführen willst, verwende den ganz normalen Weg, wie hier beschrieben:

          https://doc.otobo.org/manual/installation/11.0/en/content/migration-from-otrs.html

          Bitte alles migrieren und danach OTOB anpassen.

          Schöne Grüße,

          Stefan Rother

        • #34289
          Niklas Maurer
          Teilnehmer

            Hallo Stefan,

            ok vielen Dank.
            Ich habe die Migration erfolgreich durchgeführt und auch alle Folgeschritte der Anleitung liefen problemlos durch.

            Allerdings fehlt in der Otobo Datenbank jetzt die Tabelle „sessions“ so dass ich mich nicht mehr anmelden kann.
            Vor der Migration lief die Anmeldung in der „sauberen/frischen“ Otobo Installation.
            Wie kann das passiert sein und wie kann ich das lösen?

          • #34290
            Niklas Maurer
            Teilnehmer

              Korrektur, die Tabelle existiert, aber:

              [Mon Feb 24 18:03:11 2025] -e: DBD::mysql::db do failed: Data too long for column ‚data_value‘ at row 6 at /opt/otobo/bin/psgi-bin/../../Kernel/System/DB.pm line 560.
              ERROR: OTOBO-CGI-10 Perl: 5.36.0 OS: linux Time: Mon Feb 24 17:03:11 2025

              Message: Data too long for column ‚data_value‘ at row 6, SQL: ‚INSERT INTO sessions (session_id, data_key, data_value, serialized) VALUES (?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?),(?,?,?,?)‘

              RemoteAddress: 192.168.103.13
              RequestURI: /otobo/index.pl

            • #34291
              Niklas Maurer
              Teilnehmer

                Als Test habe ich mit
                ALTER TABLE sessions MODIFY COLUMN data_value LONGTEXT;

                getestet. Es sieht so aus, dass der data_key UserRemoteUserAgent mit 111 bytes zu groß für die Tabelle ist.

              • #34292
                Stefan Rother
                Administrator

                  Hallo Niklas,

                  die Tabelle Session ist nicht Dein Problem und die Inhalte der Tabelle werden wahrscheinlich überhaupt nicht migriert, warum auch.

                  Bei der Migration wurde auch die Konfiguration übernommen (auch die Optionen aus otrs/Kernel/Config.pm), ich denke deshalb klappt die Anmeldung nicht mehr.

                  Wenn die Migration sauber durchgelaufen ist, ist alles in Ordnung und Du musst NICHTS mehr an den Tabellen ändern.

                  Schau bitte in die Logdateien, aber es sollte lediglich eine fehlerhafte Konfiguration vorliegen oder der neue Server ist nicht für das Zugriff auf die verwendeten Dienste freigeschaltet?

                  Gegen was authentifizierst Du Dich denn? Lokal oder gegen ein LDAP/AD/ExterneDB?

                  Nach der Migration musst Du Dich mit den alten OTRS Zugangsdaten authentifizieren.

                  Schöne Grüße,

                  Stefan

                • #34295
                  Niklas Maurer
                  Teilnehmer

                    Hallo Stefan,

                    danke für deine Hilfe!
                    Ich authentifiziere gegen LDAP(AD)

                    Ich will auch nichts an den Tabellen ändern, wenn ich die Migration der Produktion mache. Ich hatte die Änderung an der Tabelle nur vorgenommen um herauszufinden was da versucht wird einzuspielen mit dem insert.

                    Ich lag falsch, die problematischen Werte scheinen von einem insert beim login zu kommen.
                    Kannst Du mir eventuell helfen die Fehlkonfiguratioj zu finden?

                    Der CSV Export der Tabelle nur für den größten Wert gibt mir:

                    id session_id data_key data_value serialized
                    6 Lm6x5VrIqlcWo3aQpyJJoB1NrzlwT6P9 GraphWidget1003-Stats {„Bar“:{„State“:{„Style“:“stacked“},“Filter“:[„1″,“1234″,“2“ <-hier kommenjetzt tausende Einträge, z.B. jede Menge E-Mails>, „beispielemail@test.com“]}} 0

                    Könnte es etwas mit dem Stats modul zu tun haben?

                Ansicht von 6 Antwort-Themen
                • Du musst angemeldet sein, um auf dieses Thema antworten zu können.