[Sandro Simeth]

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?

[Sandro Simeth]

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 …

[Sandro Simeth]

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.`

[bes]

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

 

 

 

 

[Autor]

Beiträge