Topic Resolution: Resolved
Viewing 14 reply threads
  • Author
    Posts
    • 25. Oktober 2021 at 8:24 #12047
      Jan Eckhardt
      Participant

      Guten Tag,

      ich habe ein Problem mit dem OTOBO System.

      Nachdem ich mein OTRS 6 System nach OTOBO einwandfrei migrieren konnte, haben in den letzten Tests die eintreffenden Tickets nicht erstellt werden können. Der Versand funktionierte mit dem Daemon / Cron Job oder einem erzwungenen TicketSend Befehl via Konsole.

      Mein Problem:
      Eintreffende Tickets erscheinen nicht – und unter dem „Communication Log“ bekomme ich folgende Aussage:

       

      Die von OTOBO angegebene Bug-Reporting Seite existiert nicht mehr (404).

      Mein OTOBO: 10.0.13, Ubuntu 20, MariaDB
      Mein altes ORTS: OTRS 6.0.30, CentOS 7, MariaDB

    • 25. Oktober 2021 at 8:41 #12049
      Stefan Rother
      Keymaster

      Guten Morgen Herr Eckhardt,

      dieses Verhalten ist absolut unüblich und ich denke auf den ersten Blick, dass es sich nicht um einen Bug handelt, sondern um ein Konfigurationsproblem oder um einen Bug in einem Zusatzpaket (Welche Pakete sind bei Ihnen installiert?)

      Bitte öffnen sie eine Konsole und pipen Sie eine gespeicherte Nachricht die nicht importiert werden konnte nochmal ins System:

      root> su - otobo

      otobo> /opt/otobo/var/spool/problem-email-irgendeine | bin/otobo.Console.pl Maint::PostMaster::Read

      Anschließend posten Sie hier bitte nochmal den Fehler und die gesamte Ausgabe.

      Die OTOBO Bugs finden Sie nun unter https://github.com/RotherOSS/otobo/issues, gibt es irgendwo noch einen veralteten Link den wir anpassen müssen?

      Vielen Dank,

      Stefan

      Team OTOBO

       

    • 25. Oktober 2021 at 9:42 #12050
      Jan Eckhardt
      Participant

      Hallo Herr Rother,

      hier ist der Report, den ich aus der Konsole auslesen konnte.

       

      Ansonsten konnte ich keine weiteren Links finden, die ins Leere gehen.
      Ich habe keine Addons installiert, wie es bei OTRS6 der Fall war (Znuny QuickClose + Repo)

      Des Weiteren ist dies die liste per Ausgage durch: bin/otobo.CheckModules.pl –all

       

      Ich bedanke mich noch einmal für die schnelle Antwort!

       

      Gruß

      Jan

      • 25. Oktober 2021 at 10:02 #12055
        Sven Oesterling
        Keymaster

        Bei dem Console-Befehl steht ein „permission denied“ – da müssten Sie erstmal überprüfen, wie die Rechte genau gesetzt sind, bitte.

    • 25. Oktober 2021 at 9:53 #12052
      Renée Bäcker
      Participant

      Ist im Systemprotokoll noch etwas zu finden, *warum* die Tickets nicht erstellt werden?

       

      @Stefan: Hier ist der Link zu finden: https://github.com/RotherOSS/otobo/blob/79b86ace5c3fa6bdaf949bcf371cc23f5443c0a1/Kernel/System/PostMaster/NewTicket.pm#L600

    • 25. Oktober 2021 at 9:59 #12054
      Jan Eckhardt
      Participant

      Hallo Renèe,

      in welchem Systemprotokoll kann ich denn nachgucken für die Informationen, die du gerne haben möchtest?

      Unter „System Log“ habe ich noch das hier, was essenziell ähnlich zu dem Report von oben ist.

      Die Message ist CommunicationLog(ID:12,AccountType:-,AccountID:-,Direction:Incoming,Transport:Email,ObjectLogType:Connection,ObjectLogID:33)::Kernel::System::Console::Command::Maint::PostMaster::Read => Got no email on STDIN!

       

      Gruß

      Jan

    • 25. Oktober 2021 at 10:09 #12058
      Renée Bäcker
      Participant

      Hallo Jan,

      das ist prinzipiell die richtige Stelle an der Du schauen solltest. Aber erstmal musst Du das „permission denied“-Problem beheben.

    • 25. Oktober 2021 at 10:15 #12059
      Jan Eckhardt
      Participant

      Ich bin mir leider nicht sicher, wie ich das „Permission Denied“ Problem beheben kann.
      Die Unterordner und auch die Spool Mails sind mit den Rechten eigentlich richtig vergeben, oder nicht?

    • 25. Oktober 2021 at 10:20 #12060
      Renée Bäcker
      Participant

      setz mal noch ein „cat “ vor die Mail, also

      cat /opt/otobo/var/spool/mail-…. | perl bin/otobo.Console.pl Maint::PostMaster::Read

    • 25. Oktober 2021 at 10:31 #12061
      Jan Eckhardt
      Participant

      Das kommt dabei heraus!

       

    • 25. Oktober 2021 at 10:37 #12062
      Renée Bäcker
      Participant

      Die Spalte ‚ticket_answered‘ die da angemeckert wird gibt es originär in der Tabelle ticket nicht. Hattest Du irgendwelche Anpassungen im OTRS? Vielleicht nicht über Addons sondern über eigene Änderungen direkt in irgendwelchen Dateien?

    • 25. Oktober 2021 at 10:46 #12063
      Jan Eckhardt
      Participant

      Ich kann das nicht wirklich nachvollziehen.

      Ich habe das damalige OTRS nicht aufgesetzt, jedoch die komplette Migration von 3.36 auf 6.0.30 getätigt und überwacht.
      Was für Anpassungen alles gemacht wurden davor, kann ich nicht ganz in Erfahrung bringen.

      Letztlich ist dann wohl ein Eintrag in der MySQL / Datenbank kaputt.
      Ich weiß, dass wir in der Vergangenheit Probleme mit Anhängen von Datenbanksätzen aus 2014 hatten, bspw. Dort haben einfach Inhalte irgendwann gefehlt scheinbar.

      Was könnte man nun tun? Gibt es eine Möglichkeit die SQL Einträge nachzuholen oder wieder aufzubauen?
      Nach meines Erachtens wurde die damalige OTRS-Lösung nach Dokumentation aufgebaut. Leider bin ich gezwungen diese uralte Datenbank immer wieder mitzuziehen. Zumindest gab es keine Probleme diesbezüglich von OTRS 5.0.42 auf OTRS 6.0.30, was der letzte Schritt ja war, bevor ich zu OTOBO wechseln könnte. Nun verbleiben wir auf dem funktionsfähigen OTRS 6 für den Moment, bis OTOBO vielleicht doch bei uns noch laufen könnte.

    • 25. Oktober 2021 at 11:19 #12064
      Renée Bäcker
      Participant

      Du könntest in der Datenbank einfach einen Default setzen.

      Schau Dir mal mit

      DESCRIBE ticket

      die Tabelle an. Dann könntest Du mit

      ALTER TABLE ticket MODIFY ticket_answered … DEFAULT 0;

      einen Standardwert setzen. Das „…“ musst Du durch die Spaltendefinition (bsp. „NOT NULL INTEGER“, deswegen erst das DESCRIBE) ersetzen. Löschen würde ich die Spalte nicht, da die ja vermutlich mal eine Funktion hatte.

      Du solltest mal in dem /opt/otrs/-Verzeichnist (auf dem OTRS 6) einfach mal ein

      grep -r ticket_answered /opt/otrs/Kernel/*

      und

      grep -r ticket_answered /opt/otrs/Custom/*

      machen. Vielleicht findest Du dann heraus wo das herkommt und welche Funktion das hat. Vielleicht wird die Spalte auch in GenericAgents o.ä. verwendet.

    • 25. Oktober 2021 at 12:31 #12067
      Jan Eckhardt
      Participant

      So, ich habe jetzt mit:

      ALTER TABLE ticket ALTER COLUMN ticket_answered SET DEFAULT 0;

      einen Default value gesetzt.
      Nachdem ich ein Test-Ticket reingeschickt und manuell ge-fetched habe im Adminbreich.

      Nun sagt das Communication Log immer noch, dass das Ticket nicht erstellt werden kann, …

      allerdings sagt das Error log jetzt NICHT mehr, dass ticket_answered auf einen Fehler läuft, sondern Folgendes:

    • 25. Oktober 2021 at 12:36 #12068
      Jan Eckhardt
      Participant

      Das hier ist noch einmal die Einsicht in das
      DESCRIBE ticket;

      bezüglich der „ticket_answered“ Sache von oben, das sich jetzt wohl gefixt hat.

    • 25. Oktober 2021 at 13:39 #12069
      Jan Eckhardt
      Participant

      Ich habe dasselbe ebenfalls mit „group_id“ gemacht, dass ich den Default Wert auf 0 gesetzt habe, denn meine Error Logs spuckten ab jetzt „group_id“ aus und nicht mehr „ticket_answered“.
      Als ich das tat, klappte plötzlich alles wieder!

       

      Ich bedanke mich für alle Hilfe soweit!

       

      [SOLVED]

  • Author
    Posts
Viewing 14 reply threads
  • You must be logged in to reply to this topic.