-
Posts
-
-
Hallo,
zuerst einmal: Danke für das OTOBO Projekt und die wirklich gute und nachvollziehbaren Dokumentationen.
Ich habe heute eine erste Testmigration von OTRS 6.0.30 auf OTOBO 10.0.8 (Docker) unter Ubuntu 20.04 LTS durchgeführt.
Nach erfolgreicher Migration konnte ich mich an OTOBO anmelden, allerdings kann ich keine Tickets betrachten. Nach Anwahl eines Tickets erhalte ich lediglich „Internal Server Error“. Aufgrund des SysLogs vermute ich das fehlende Plugin „MasterSlave“ als Grund (Backend MasterSlave is invalid!).
Allerdings werden mir im PackageManager keine Pakete zur Auswahl angezeigt. Grund ist vermutlich die folgende Meldung im SysLog „Can’t perform POST on https://portal.rother-oss.com/otobo/public.pl: 500 SSL upgrade failed: SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed“
Hier im Forum konnte ich einen ähnlichen Fall finden Probleme mit Package Repository allerdings wäre es ja ein großer Zufall, wenn ausgerechnet jetzt wieder Zertifikate erneute worden wären. Daher vermute ich das Problem eher in meinem Installationsablauf.
Der Zugriff auf das Internet erfolgt über einen Proxy. Dieser wird aus dem Container heraus auch angesprochen, da ich den Request auf portal.rother-oss.com auch im Log des Proxy sehen kann und diese auch beantwortet werden.
Danke im Voraus für eure Unterstützung
Heiko
-
Hallo Heiko,
vielen Dank für Dein nettes Feedback. Die Dokumentation entspricht noch nicht unseren Wünschen, wir werden sie kontinuierlich weiter verbessern.
Hast Du den Proxy denn unter Admin-> Systemkonfiguration hinterlegt? Such dort einfach mal nach „Proxy“, bei mir waren es vier Treffer, die Deinen Fehler denke ich beheben könnten.
Ich denke aber, dass der Internal Server Error ein anderes Problem ist. Hier würde ich mir mal den genauen Fehler mit
root> docker logs otobo_web_1 -fausgeben lassen und wenn Du nicht weiter kommst hier posten.
Schönen Abend!
Stefan
Team OTOBO
-
Guten Morgen – das mit dem MasterSlave kann schon sein, wenn das nicht richtig installiert ist. Falls es mit dem ssl nicht klappt, kann man die Pakete auch immer händisch runterladen und einspielen: https://ftp.otobo.org/pub/otobo/packages/
Einen schönen Tag, Sven
-
Guten Morgen Stefan und Sven,
vielen Dank für die Unterstützung. Peinlich genug, aber das Lesen des Logs hat dann doch auch diesmal geholfen….
Wir haben in unserer OTRS 6 Installation aufgrund der Datenmenge die Attachments nicht in der DB, sondern im FileSystem. Das Setting für Ticket::Article::Backend::MIMEBase::ArticleDataDir hat unter otobo auf einen ungültigen Pfad (/opt/otobo-data) verwiesen. Ich vermute mal, dass dies eine Besonderheit der Docker-Umgebung ist, da es sich hier um den Mountpoint handelt und dort möglicherweise keine Schreibrechte bestehen
Nachdem ich ArticleDataDir auf /opt/otobo/otobo-data geändert habe, sind auch meine Tickets wieder abrufbar.
Gruß
Heiko
-
Guten Morgen erneut,
nach den weiteren Tests habe ich festgestellt, dass das SSL Problem vermutlich ein Settings aus der Migration ist. Vor der Durchführung der Migration funktionierte der Zugriff auf das Repository, danach jedoch nicht mehr.
Die Proxy-Einstellungen in der SysConfig habe ich geprüft und die sehen okay aus.
Weiterhin war nach der Migration die Suchbox für Elasticsearch aus der Oberfläche entfernt. Daher nähere ich mich jetzt in großen Schritten dem Punkt aus der Migrationsanleitung in dem es heißt: „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“
Wie kann ich denn erreichen, dass lediglich die Daten aus OTRS übernommen werden und die Konfiguration von OTOBO erhalten bleibt? Könnt ihr mir hier einen [W|L]ink geben ?
Danke
Heiko
-
Hallo Heiko,
ich denke ehrlich gesagt nicht, dass das das Problem ist. Wenn die Migration soweit durchgelaufen ist, kann es einfach sein, dass Aufgrund einer fehlerhaften SysConfig Option nicht alle Optionen übernommen wurden. Ich denke trotzdem Du bist auf dem richtigen Weg und kurz vor dem Ziel.
Ich würde jetzt wie folgt vorgehen:
1.) In Docker Container einloggen:
root> docker exec -it otobo_web_1 bash2.) Config überprüfen
otobo> bin/otobo.Console Admin::Config::ListInvalidund falls notwendig
otobo> bin/otobo.Console Admin::Config::FixInvalidausführen.
2.1) Danach zur Sicherheit nochmal
otobo> bin/otobo.Console.pl Maint::Config::Rebuild3.) ElasticSearch in Systemkonfiguration aktivieren überprüfen
Dazu unter Admin -> Systemkonfiguration folgende Optionen aktivieren:
Elasticsearch::ActiveFrontend::ToolBarModule###250-Ticket::ElasticsearchFulltextDanach einfach nochmal nach „Elasticsearch“ suchen und eventuell die zu speichernden Infos und Ansichten anpassen.
3.1) Elasticsearch Webservice überprüfen
Unter Docker Admin -> Webservice -> Elasticsearch -> OTOBO als Requester -> Netzwerktransport konfigurieren öffnen und dort den Endpunkt auf http://elastic:9200 ändern.
Dann den Webservice noch auf „gültig“ setzen.
3.2) Daten nach Elasticsearch migrieren
In der Console bitte folgendes ausführen:
bin/otobo.Console.pl Maint::Elasticsearch::Migration4.) Datei Kernel/Config.pm manuell überprüfen
Manchmal wird bei der Migration etwas zuviel umbenannt, zum Beispiel von OTRS in OTOBO. Daher die Datei nochmal durchgehen und schauen ob alle Benutzer und Passwörter etc. stimmen, wenn hier OTRS vorkam.
Jetzt sollte Dein System soweit einsatzfähig sein. Ich exportiere immer noch alle Änderungen aus Admin -> Systemkonfiguration -> Export und schaue mir an, wo eventuell noch nicht benötigte Optionen sich aus der Vergangenheit verstecken. Wenn obiges alles geklappt hat, dann liegt es meistens an einer Einstellung.
5.) Eventuell Pakete reinstallieren, falls sie ungültig angezeigt werden.
Wir werden zeitnah noch die gesamte Migration besser dokumentieren und weiter vereinfachen. Aber das sind die Schritte, die ich in so einem Fall abarbeite und ich bin damit bisher immer zu einem sauberen OTOBO gekommen.
Ich hoffe ich konnte Dir helfen!
Schöne Grüße,
Stefan
-
Hallo Stefan,
wow, der Beitrag sollte einen gelben Umschlag mit einem schwarzen Balken bekommen. „OTOBO Migration für Dummies“ ;-) Vielen Dank für die Unterstützung!
Da ich aktuell noch immer bei „Test-Migrationen“ bin:
- Kann ich die Mime-Attachments einfach von OTRS in den neuen Pfad von OTOBO kopieren, oder muss dabei etwas beachtet werden ?
- Gehe ich recht in der Annahme, dass wir Agent- und Customer-Skins besser neu erstellen, anstelle zu versuchen die alten zu übernehmen?
Während ich das schreibe hat Elasticsearch schon die ersten 9% der Artikel erhalten….
Gruß
Heiko
-
Hallo,
davon ausgehend, dass auch andere gelegentlich mit Layer-8 Problemen kämpfen: Hier noch die Lösung zu dem eigentlichen Thread-Thema „SSL Fehler….“
Deine erste Antwort Stefan war dann tatsächlich die Lösung. Vor der Migration war kein Proxy gesetzt. Nach der Migration wurden die Proxy-Einstellungen des Quell-OTRS natürlich übernommen. Da mir diese Einstellungen „bekannt“ vorkamen, hatte ich diese nicht in Frage gestellt. Allerdings habe ich dann feststellen müssen, dass dieser Proxy von dem Docker-Host nicht korrekt angesprochen werden konnte.
Nach Deaktivieren von Package::Proxy und WebUserAgent::Proxy konnte ich dann auch wieder auf das Repository zugreifen.
Heiko
-
Hi there!
I received the same error: SysLog „Can’t perform POST on https://portal.rother-oss.com/otobo/public.pl : 500 SSL upgrade failed: SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate :certificate verify failed“.
I have installed docker version with selfsign cetrificate.
I have disable SSL verification for WebUserAgent, and it is solve my problem.
WebUserAgent::DisableSSLVerification
set Enable
szabolcs
-
- You must be logged in to reply to this topic.