-
Beiträge
-
-
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. -
Hallo Ferdinand,
sorry für die schlechten Erfahrungen.
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
bin/otobo.Console.pl Admin::Config::Read --setting-name HTTPSForceRedirectüberprüfen ob die Einstellung wie vermutet ist.
Mit
bin/otobo.Console.pl Admin::Config::Update --reset --setting-name HTTPSForceRedirectkann dann die Einstellung zurückgesetzt werden.
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.
Viele Grüße,
Bernhard
-
-
Ich habe es doch nun selbst herausgefunden. Am docker Host kann man z.B. einfach folgendes machen
- docker exec otobo_web_1 bin/otobo.Console.pl Admin::Config::Read –setting-name HTTPSForceRedirect
Hierbei wird vom Docker Host ein Befehl zum OTOBO Container „otobo_web_1“ geschickt und ausgeführt.
Viele Grüße
-
-
Hallo Bernhard,
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
-
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.