Ich habe diese Woche auf einem Linux-Server (Debian Bullseye) Otobo mittels „docker compose“ aufgesetzt.
Es handelt sich zwar nur um ein Demo-System, das soll aber langsam in ein Produktivsystem umgebaut werden. Ich bin eigentlich nur die Installationsanleitung für HTTPS durchgegangen: in der Datei .env ein Root-DB-Passwort gesetzt, die zwei Dateinamen für das Zertifikatspaar angepasst (es handelt sich um ein Zertifikat von der internen CA und ich weiss, wie ein nginx-Zertifikat aussehen muss) und ein SSL-Volume für nginx angelegt.
Das hat alles ohne Probleme geklappt. Ich konnte den Webinstaller durchlaufen lassen, nur den Punkt mit den Emails hab ich übersprungen, weil er nach wie vor nicht funktioniert. Danach konnte ich mich ohne Probleme am Host über https://<fqdn>/otobo/index.pl als root@localhost anmelden . Keine Fehlermeldung zum Zertifikat (ist ja ein gültiges), kein Problem mit dem root-Passwort. Alles hat funktioniert.
Ich hab dann mal ein paar Sachen konfiguriert (System-Mailadresse, SMTP und IMAP-Postfach, einen Kalender und erste Einstellungen in den Core-Einstellungen). Nach wie vor keine Probleme.
Nachdem es bisher gut funktioniert hat habe ich begonnen, in der Systemkonfiguration Werte anzupassen (Ticketansichten, etc.), auch das hat noch funktioniert, ich konnte die auch alle übernehmen/aktivieren doch auf einmal war das System nicht mehr erreichbar.
Es kam in den Browsern immer nur eine Fehlermeldung, dass die Seite nicht erreichbar sei. Was mir allerdings aufgefallen ist:
die Url war jetzt auf einmal: https://<fqdn>:8443/otobo/index.pl
Und das bleibt auch so, egal was ich mache – der Port 8443 geht nicht mehr weg und die ganze Konfiguration und die Arbeit von mehreren Stunden ist weg. Ich habe es mit einem zweiten Browser versucht (zuerst Firefox, dann Chrome), auf einem anderen Rechner mit zwei Browsern, ich hab es sogar von einem Server, der im gleichen Subnet steht, aus versucht – immer kommt dieser Port 8443.
Ich habe dann mal Testweise otobo_nginx_1 gelöscht (docker rm) und in der .env-Datei als https-Port 443 angegeben. Laut docker ps macht der Container das auch, allerdings ist das im Browser egal, weil der Redirect auf Port 8443 trotzdem sofort wieder schlagend wird.
Kennt wer das Problem und v.a. weiss wer, wieso das auf einmal mitten im Arbeiten passiert?
Ich habe nun einen neues Otobo aufgesetzt, allerdings weiss ich gerade nicht so recht, ob ich das fertig aufsetzen soll oder nicht. Wenn da andere Leute anfangen, ihre Sachen einzupflegen (Antwort-Templates, etc.) und dann auf einmal der Server mit den Daten weg ist wird keine Freude aufkommen.
Ich habe versucht eine mögliche Ursache des Effekts zu finden. In OTOBO gibt es mehrere Redirekts, Meine Vermutung ist dass der Redirect des Features, oder Bugs, HTTPSForceRedirect zuschlägt. Zuerst einmal die Beschreibung des Normalzustandes:
Im Docker-Service web läuft der Webserver Gazelle für HTTP unter dem Port 5000
Im Docker-Service nginx läuft ein Nginx auf Port 8443 welcher einen Reverse Proxy für den Service web darstellt
Zusätzlich horcht der Service nginx auch auf HTTP Port 80 welcher nur redirects auf HTTPS Port 443 macht
Docker Compose macht Port 8443 von nginx als Port 443 auf dem Docker Host sichtbar.
Aus Browsersicht ist also nur HTTPS auf Port 443 relevant. Aus Sicht von Gazelle im Service web kommen die Anfragen von nginx der auf Port 8443 angefragt wird.
Im Agenten-Interface gibt es die Einstellung HTTPSForceRedirect die ebenfalls einen Redirekt auf HTTPS leisten will. Im Docker-Context vermute ich aber dass dieser Redirekt ins Leere läuft, also den falschen Redirect auf Port 8443 macht. Siehe Zeile 124 in https://github.com/RotherOSS/otobo/blob/rel-10_0/Kernel/System/Web/InterfaceAgent.pm .
Haben Sie die fehlerhafte Installation noch zur Hand? Wenn ja dann könnten Sie mit
Mit OTOBO 10.0 konnte ich den Effekt nachvollziehen. In OTOBO 10.1. trat der Fehler nicht mehr auf. Nichtsdestotrotz ist unter Docker die Aktivierung von HTTPSForceRedirect nicht zu empfehlen.
sorry für die späte Rückmeldung und danke für die ausführliche Antwort.
Es war wirklich die Einstellung „HTTPSForceRedirect“ Schuld.
Ich konnte es zwar nicht mehr an der defekten Installation testen (weil zu dem Zeitpunkt hatte ich bereits eine neue Instanz aufgesetzt), allerdings war es mir noch möglich aus der DB der alten Installation die Tabelle „sysconfig_modified“ zu exportieren und alle Werte bis auf den HTTPS-Redirect in die neue Installation zu übernehmen. Seitdem läuft die Otobo-Installation ohne Probleme.
Der Fehler ist passiert, weil meine bisherigen OTRS-Installation normale Installationen waren und ich nicht daran gedacht habe, dass ja der Reverse-Proxy und Docker schon dafür sorgen, dass nur HTTPS möglich ist.
Danke übrigens für den Hinweis wie man einen Wert wieder auf den Standardwert setzen kann – sehr praktisch.
Viele Grüße
Franz
Autor
Beiträge
Ansicht von 2 Antwort-Themen
Du musst angemeldet sein, um auf dieses Thema antworten zu können.
Wir verwenden Cookies, um diese Website optimal gestalten und laufend verbessern zu können. Für Analyse und Statistik nutzen wir Google Analytics (anonymisiert).
Unsere Website verwendet Cookies. Cookies sind kleine Textdateien, die beim Aufruf von Websites im Internetbrowser bzw. vom Internetbrowser auf Ihrem Endgerät gespeichert werden. Diese Cookies enthalten eine charakteristische Zeichenfolge, die eine eindeutige Identifizierung des Browsers beim erneuten Aufrufen der Website ermöglichen.
Sie können das Setzen von Cookies jederzeit über eine entsprechende Einstellung in Ihrem Internetbrowser verhindern. Bereits gesetzte Cookies können jederzeit manuell oder automatisiert gelöscht werden. Dies ist in allen gängigen Internetbrowsern möglich. Wird das Setzen von Cookies im Browser deaktiviert, sind unter Umständen nicht alle Funktionen der Website vollumfänglich nutzbar.
Wir gehen grundsätzlich sehr sparsam mit Cookies um.
Detaillierte Informationen finden Sie in Abschnitt 4 unserer Hinweise zum Datenschutz.
Technisch erforderliche Cookies
Diese Cookies sind erforderlich, um die Darstellung dieser Website und einiger ihrer Features zu gewährleisten.
Deshalb bieten wir hier auch keine Möglichkeit an, diese Cookies zu deaktivieren.
Dessen ungeachtet können Sie jederzeit durch entsprechende Einstellungen in Ihrem Browser alle Cookies deaktivieren. Unter Umständen stehen Ihnen dann nicht mehr alle Funktionalitäten dieser Website zur Verfügung.
Weitere Informationen zu den gesetzten Cookies und zur Speicherdauer finden Sie in Abschnitt 4 unserer Hinweise zum Datenschutz.
Cookies von Google Analytics
Beim Besuch der Website werden Cookies von Google Analytics gesetzt, die eine Analyse der Benutzung unserer Website durch Sie ermöglichen. Ihre IP-Adresse wird dabei durch technische Vorkehrungen pseudonymisiert (IP-Anonymisierung und Deaktivierung der User-ID). Eine Zuordnung der Daten zum aufrufenden Nutzer ist daher nicht mehr möglich. Die Daten werden nicht gemeinsam mit anderen personenbezogenen Daten der Nutzer gespeichert.
Wenn Sie nicht möchten, dass wir Ihren Besuch auf unserer Website verfolgen, können Sie das Tracking in Ihrem Browser hier deaktivieren:
Hinweise zum Datenschutz
Detaillierte Informationen zum Einsatz von Cookies sowie unsere Datenschutzerklärung finden Sie hier: