Topic Resolution: Resolved

Tagged: 

Viewing 3 reply threads
  • Author
    Posts
    • #10893
      Sandro Simeth
      Participant

      Hi,

      ich habe eine Docker Installation von Otobo laufen und bekomme nach einem Redeploy folgenden Fehler vom WEB-Container:

       

      Da ich den Fehler nicht finden konnte habe ich ein neues System deployed und wollte das Backup einspielen. Leider bekomme ich folgende Fehler:

       

       

      Also die Tabellen und den Inhalt hat er wohl angelegt. Aber einloggen kann ich mich trotzdem nicht: 500 internal Server Error. Kein Eintrag in var/log/otobo.log

       

      Kann jemand helfen?

    • #10894
      Sandro Simeth
      Participant

      Wordfense will irgendwie mein Logs nicht haben:

       

      otobo@web-5fbd767557-b6dj7:~$ ./scripts/restore.pl -b 2021-02-15_13-45-27/ -d /opt/otobo
      Restore 2021-02-15_13-45-27/Config.tar.gz …
      Restore 2021-02-15_13-45-27/Application.tar.gz …
      tar: .: Cannot utime: Operation not permitted
      tar: .: Cannot change mode to rwxrwx—: Operation not permitted
      tar: Exiting with failure status due to previous errors
      create MySQL
      Restore database into MySQL …

    • #10895
      Sandro Simeth
      Participant

      Ich muss es etwas kürzen:

      Error while loading otobo.psgi: Can’t load application from file „dbviewer.pl“: Array reference of pattern/handler pairs required to dispatch exceptions at dbviewer.pl line 93.`

    • #10898
      bes
      Participant

      Hallo Sandro,

      zuerst das Einfache. Die Ursache der Fehlermeldung ist klar und nachvollziehbar. Siehe https://github.com/RotherOSS/otobo/issues/785 . Die Historie ist dass aktuell beim Bauen von Docker Images die jeweils aktuellen Perl-Pakete von CPAN verwendet werden. In der Distribution  Mojolicious  hat sich zwischen 10.0.7 und 10.0.8 ein Interface geändert und im OTOBO Code musste deshalb eine Anpassung gemacht werden. Ich denke in Zukunft werden wir vorsichtiger mit CPAN-Updates bei patch-level Releases sein. Der Effekt ist dass der Inhalt von /opt/otobo mit dem Docker-Image zusammen passen muss.

      Interessanter ist wie es zu dieser Situation kam. Meine Vermutung ist dass /opt/otobo noch auf 10.0.7 ist, während das Docker Image bereits auf OTOBO 10.0.8 ist. Das sollte mit folgenden Befehlen überprüfbar sein:

      • docker exec -it otobo_web_1 cat /opt/otobo/RELEASE
      • docker exec -it otobo_web_1 cat /opt/otobo_install/otobo_next/RELEASE

      Ich vermute dass folgende Sequenz stattgefunden hat:

      1. OTOBO 10.0.7 läuft
      2. docker-compose pull     => rotheross/otobo:latest ist jetzt auf 10.0.8,   otobo_web_1 ist davon zuerst unberührt
      3. docker-compose down
      4. docker-compose up -d     => Das laufende Image otobo_web_1 ist jetzt auf 10.0.8, /opt/otobo immer noch auf 10.0.7
      5. Der bekannte Fehler tritt auf

      Zur Behebung gibt es zwei Möglichkeiten: Alles auf 10.0.8 oder alles zurück auf 10.0.7.

      Wenn sicher ist, daß es an der OTOBO Software keine lokalen Änderungen gegeben hat, dann kann man den Upgrade auf 10.0.8 machen. Die Anleitung dazu steht in https://doc.otobo.org/manual/installation/stable/en/content/updating-docker.html. Wenn es nicht sicher ist, dann zurück auf 10.0.7:

      1. In .env bei den Variable OTOBO_IMAGE_OTOBO, OTOBO_IMAGE_OTOBO_ELASTICSEARCH und OTOBO_IMAGE_OTOBO_NGINX die Marke ‚latest‘ zu ‚10.0.7‘ ändern
      2. docker-compose down
      3. docker-compose ps         (nur zur Sicherheit)
      4. docker-compose up -d

      Ich hoffe das hilft, und viele Grüße,

      Bernhard

       

       

       

       

Viewing 3 reply threads
  • You must be logged in to reply to this topic.